draft-ietf-pim-port-03 wglc

WGLC responses Thomas suggested a long list of changes, mostly editorial –I believe I addressed all Dimitri also had comments –Yakov further commented on one of those –Fixed the editorial issues –I will list the non-editorial ones

Issue 1 Introduction mentions "This specification enables greater scalability in multicast deployment since the processing required for protocol state maintenance can be reduced". Can authors explain how leaving PIM state maintenance unmodified (see Intro) but adding TCP state reduces protocol state ? My response: Amount of processing goes down since no periodic J/Ps, do we need to explain this? We need some additional state, but there is less processing.

Issue 2 Introduction mentions "This document will specify how periodic JP message transmission can be eliminated by using TCP [RFC0761] or SCTP [RFC4960] as the reliable transport mechanism for JP messages Where is the periodic message elimination described in this document (beside the two sentences in the middle of Section 2) My response: Section 2 says: –PIM Over Reliable Transport (PORT) is a simple extension to PIMv2 for refresh reduction of PIM JP messages. It involves sending incremental rather than periodic JPs over a TCP/SCTP connection between PIM neighbors. –When PORT is used, only incremental JPs are sent from downstream routers to upstream routers. As such, downstream routers do not generate periodic JPs for routes which RPF to a PORT-capable neighbor. –Do we need anything more?

Issue 3 Section 4: why switching to PORT mode occurs upon Hello reception? and not upon TCP connection establishment? My response: –This was a design choice made some IETFs ago and was discussed in the wg –The main problem is that it is possible that one peer thinks the connection is up, the other down –One may use PORT, the other not –There may be issues with reordering and a delayed datagram prune may cancel a PORT join and not get recovered since no periodic PORT join –The current approach is more deterministic

Issue 4 Section 5: introduces the Type "instance ID" field what the size of this field ? What happens in case of Instance mismatch ? To what "instance" refers to ? My response: –The instance ID field is 64 bits –We only define type 0 which means the ID is not used, ignored by receiver. No mismatch –If new documents define types, then those could talk about mismatch for the specific type –Should we specify how to handle unknown types? Ignore entire message?

Issue 5 Section 6: there is no description of explicit tracking on non point-to-point interfaces. Can authors describe tracking for the other types of interfaces ? That is exactly what we are describing here. For point-to-point you don't really need to do explicit tracking, or rather, tracking is implicit.

Issue 6 Is there any use of TCP-based, keep-alive mechanism to determine if PIM neighbors are reachable ? My response: –It’s not quite clear whether keep-alive is needed, we discussed this before –Without keep-alive you may only notice a connection is down if trying to send What to do if it is down? –Can we assume that if PIM Hello and other PIM datagram messages get through then TCP also gets through? –We could easily specify keep-alive in a new document later if needed –Or we can specify it as an option now