Hi, This thread seems to have dried up. AFAICS there is no change needed to the document.
Anything further to say before I ask Russ to clear his Discuss? Thanks, Adrian > -----Original Message----- > From: Stig Venaas [mailto:[email protected]] > Sent: 08 November 2011 04:02 > To: Suresh Krishnan > Cc: [email protected]; General Area Review Team; Russ > Housley > Subject: Re: Gen-ART Telechat review of draft-ietf-pim-port-09.txt > > On 07.11.2011 15:39, Suresh Krishnan wrote: > > Hi Stig, > > > > On 11/03/2011 02:28 PM, Stig Venaas wrote: > >> Thanks for the review, see below. > >> > >> On 11/1/2011 4:18 PM, Suresh Krishnan wrote: > >>> I have been selected as the General Area Review Team (Gen-ART) > >>> reviewer for this draft (for background on Gen-ART, please see > >>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > >>> > >>> Please wait for direction from your document shepherd > >>> or AD before posting a new version of the draft. > >>> > >>> Document: draft-ietf-pim-port-09.txt > >>> Reviewer: Suresh Krishnan > >>> Review Date: 2011/11/01 > >>> IESG Telechat date: 2011/11/03 > >>> > >>> Summary: This document is almost ready for publication as an > >>> Experimental RFC but I have a few comments. > >>> > >>> Minor > >>> ===== > >>> > >>> Section 3.1 > >>> > >>> * From my reading of the document, it is not clear whether we can have a > >>> node advertise multiple capability options of the same transport > >>> protocol (say PIM-over-TCP-Capable) in the same message. e.g. A dual > >>> stack node might want to advertise its capability to do both IPv4 and > >>> IPv6. Is this possible? If so, how? > >> > >> For PIM we generally (not just PORT) use Hello Options in IPv4 PIM > >> Hello's for IPv4 capabilities and Hello Options in IPv6 PIM Hello's > >> for IPv6 capabilities. The two are completely separate. > >> > >> If a router supports PORT for both IPv4 and IPv6, it will send one > >> option in the IPv4 Hello, and another in the IPv6 Hello. > >> > >> In section 4 it says: > >> > >> The decisions whether to use PORT, which transport, and which > >> Connection IDs to use are performed independently for IPv4 and > >> IPv6. Thus, if PORT is used both for IPv4 and IPv6, both IPv4 and > >> IPv6 PIM Hello messages MUST be sent, both containing PORT Hello > >> options. > >> > >> I think this is pretty clear. > > > > That clarifies a bit, but I am still unclear as to how the protocol > > selection takes place. e.g. Does IPv6+SCTP take precedence over IPv4+TCP. > > As it says, it is done independently for IPv4 and IPv6. So in that case > you would have IPv6 PIM using SCTP, while IPv4 PIM using TCP. > > You would only have connection sharing if IPv6 PIM and IPv4 PIM end up > using the same transport and same end-point addresses. This is all in > the document. > > > >> > >>> Section 4.7 > >>> > >>> * Section 4 talks about the router with the lower connection ID > >>> initiating the transport layer connection but this does not really map > >>> into the rules mentioned in Section 4.7. Specifically, I am not sure > >>> Rule 3 for Node A in Section 4.7 conveys the same intent as section 4. > >> > >> Note that we also allow doing connections on-demand. In that case they > >> one with the higher address may open a connection. That is the reason > >> for rule 3. > >> > >> See end of section 4.5 where it says: > >> > >> Note that for TCP, it is the router with the lower Connection ID that > >> decides whether to open a connection immediately, or on-demand. The > >> router with the higher Connection ID SHOULD only initiate a > >> connection on-demand. That is, if it needs to send a Join/Prune > >> message and there is no currently established connection. > >> > >> Do you still think something is not clear? > > > > The text only describes the when it is *acceptable* for a router with a > > higher connection ID to initiate a connection, not when it should > > *actually* do so. Specifically section 4.7 should cover this. > > It says "SHOULD only initiate a connection on-demand". This means > that it is initiated if a join/prune needs to be sent. I think this > is clear enough, but note that this doesn't have to be very strict. It > is unfortunate if the one with the higher ID always tries to initiate a > connection, but there isn't much harm if it does. It wouldn't break > anything. > > Stig > > > Thanks > > Suresh _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
