Hi Rajiv, I am good with your response below. Thanks! Mustapha. > -----Original Message----- > From: Rajiv Asati (rajiva) [mailto:rajiva@xxxxxxxxx] > Sent: Friday, January 09, 2015 10:28 PM > To: Aissaoui, Mustapha (Mustapha); ietf@xxxxxxxx; IETF-Announce > Cc: mpls@xxxxxxxx > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for > IPv6) to Proposed Standard > > Hi Mustapha, > > Thanks for the clarity. > > 1. You have a fair point. While it is implicit that section 2.5.5 of RFC > 5036 (maintaining hello adj) would apply, it is reasonable to make it explicit. We > can add the below text - > > //A Dual-stack LSR MUST still follow section 2.5.5 of RFC5036 and check for > matching Hello messages from the peer (either all Hellos also include the Dual- > stack capability (with same TR value) or none do).// > > > > 2. This is already covered in both 3a and 3b by the following verbiage "However, if > IPv6 hellos are also received at any time from that neighbor..” in the beginning of > 2nd para. Note "at any time” here. > > The text is sufficient, IMHO. > > 3. Closed. > > 4.5. Ok. The following "(even if IP capability negotiation for IPv6 address family > was done)” is appended to make it explicit. And Thanks for catching the copy- > paste error. :) Fixed. > > Closed. > > > -- > Cheers, > Rajiv Asati > Distinguished Engineer, Cisco > > > > > > -----Original Message----- > From: <Aissaoui>, Mustapha Aissaoui <mustapha.aissaoui@xxxxxxxxxxxxxxxxxx> > Date: Friday, January 9, 2015 at 6:19 PM > To: Rajiv Asati <rajiva@xxxxxxxxx>, IETF Discussion <ietf@xxxxxxxx>, > IETF-Announce <ietf-announce@xxxxxxxx> > Cc: "mpls@xxxxxxxx" <mpls@xxxxxxxx> > Subject: RE: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates > to LDP for IPv6) to Proposed Standard > > >Hi Rajiv, > >Thanks for the reply. I added some follow-up inline below. > > > >Regards, > >Mustapha. > > > >> -----Original Message----- > >> From: Rajiv Asati (rajiva) [mailto:rajiva@xxxxxxxxx] > >> Sent: Tuesday, January 06, 2015 6:03 PM > >> To: Aissaoui, Mustapha (Mustapha); ietf@xxxxxxxx; IETF-Announce > >> Cc: mpls@xxxxxxxx > >> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> > >>(Updates to LDP for > >> IPv6) to Proposed Standard > >> > >> Hi Mustapha, > >> > >> > Having said that, I want to keep the spirit of cooperation and make > >> >sure we get this draft published. To that effect, I am not opposed to > >> >its publication as long as the following points are clarified in the > >> >draft since now FEC capability of the LSR peer is determined by a > >> >check a both adjacency and session levels: > >> > >> Thanks for pointing out the below scenarios. We think that all but one > >>are either > >> covered or require editorial changes. > >> > >> > >> 1. This scenario (sending hellos with DS capability on fewer interfaces > >>for a peer) > >> does NOT look realistic, since hitless upgrading a router would result > >>in sending > >> v4+v6 hellos either with DS capability or without DS capability (for a > >>DS peer, > >> assuming the peer was enabled for DS LDP, default or not, in an > >>implementation). > >> > >> Perhaps, you had a different scenario in mind. > >MA> This could occur during a hitless upgrade for Hello adjacencies from > >different line cards during a transient time. I will not insist on this > >point but I found the draft lacks what action to take if the Hello > >messages received on parallel links from the same LSR are not consistent, > >meaning they have different TR values or the message on one link do not > >have the DS capability. The only thing I found is this paragraph in > >Section 6.1.1 but it does not say what to do if an LSR receives > >inconsistent Hello messages: > >" > >An LSR MUST convey the same transport connection preference ("TR" > > field value) in all (link and targeted) Hellos that advertise the > > same label space to the same peer and/or on same interface. This > > ensures that two LSRs linked by multiple Hello adjacencies using the > > same label spaces play the same connection establishment role for > > each adjacency. > >" > > > >> 2. Yes. This scenario is well covered in section 6.1.1 point#3. > >> > >> > >> // > >> 3. If "Dual-stack capability" TLV is NOT present, and > >> > >> Š > >> resulting in any established LDPoIPv4 session being reset > >> and a fatal Notification message being sent (with status > >> > >> Š > >> > >> // > >MA> What I was talking about is a transition from state 2a to state 3a or > >from state 2b to state 3b in Section 6.1.1. Perhaps one way to explicitly > >state that the session is bounced would be to add something like this to > >items 2a and 2b of Section 6..1.1: > >" > >2. If "Dual-stack capability" TLV is present, and remote > > preference matches with the local preference, then: > > > > a) If TR=0100 (LDPoIPv4), then determine the active/passive > > roles for TCP connection using IPv4 transport address as > > defined in section 2.5.2 of RFC 5036. > > > > b) If TR=0110 (LDPoIPv6), then determine the active/passive > > roles for TCP connection by using IPv6 transport address > > as defined in section 2.5.2 of RFC 5036. > > *If subsequently to establishing the LDP session, the Hello messages > >from the peer > > do not include the Dual-stack capability TLV, the session is > >terminated and a fatal Notification message is sent with status code > >of 'Dual-Stack Non-Compliance' (IANA allocation TBD).* > >" > > > > > >> > >> 3. Yes (to the expected behavior). This is somewhat covered in bullet > >>#1 in section > >> 6.1.1, but we can make it explicit by adding "or does not get > >>recognized² as below: > >> > >> > >> OLD: > >> If "Dual-stack capability" TLV is present and remote preference does > >>not match > >> with the local preference,.. > >> > >> > >> NEW: > >> If "Dual-stack capability" TLV is present and remote preference does > >>not match > >> with the local preference (or does not get recognized),.. > >MA> Your proposed modification does address this comment. Thank you. > > > > > >> 4 and 5. Yes (to the expected behavior). It is implicit in section 7.2 > >>para 4. > >> > >> //.. > >> An LSR MAY further constrain the advertisement of FEC-label bindings > >>for a > >> particular address family by negotiating the IP Capability...// > >> > >> Are you suggesting to make it explicit? > >MA> Yes I wanted something more explicit. This section certainly says the > >IPv6 prefix FEC capability can further constrain a particular FEC type > >which is allowed by the check of the DS capability TLV. It however does > >not discuss the negative case, i.e., the DS capability TLV did not allow > >a FEC type but the IP capability allowed it. > >I believe the following addition to an earlier paragraph in Section 7.2 > >would help clarify this: > >" > >If an LSR enabled with Dual-stack LDP for a peer and > > > > 1. Is NOT able to find the Dual-stack capability TLV in the > > incoming IPv4 LDP hello messages from that peer, then the LSR > > MUST NOT advertise IPv6 FEC-label bindings to the peer *even if > >it received an IP capability > > from the peer indicating the enabling of the IPv6 FEC type*. > >" > >BTW, there is a "copy & paste" mistake in the following paragraph in the > >same Section 7.2. The "via ADDRESS message" is not correct here since > >this is about FEC distribution, hence Label Mapping message, and not > >address distribution. > >" > >If an LSR is enabled with Single-stack LDP for any peer, then it > > MUST advertise (via ADDRESS message) FEC-Label bindings for the > > enabled address family, and accept FEC-Label bindings for the > > enabled address family. > >" > > > >> -- > >> Cheers, > >> Rajiv Asati > >> Distinguished Engineer, Cisco > >> > >> > >> > >> > >> > >> -----Original Message----- > >> From: <Aissaoui>, Mustapha Aissaoui > >><mustapha.aissaoui@xxxxxxxxxxxxxxxxxx> > >> Date: Tuesday, December 16, 2014 at 12:21 PM > >> To: IETF Discussion <ietf@xxxxxxxx>, IETF-Announce > >><ietf-announce@xxxxxxxx> > >> Cc: "mpls@xxxxxxxx" <mpls@xxxxxxxx> > >> Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> > >>(Updates > >> to LDP for IPv6) to Proposed Standard > >> > >> >Hi Adrian and all, > >> >I was the one who raised the interop issues we found while testing our > >> >implementation of LDP IPv6 against existing and deployed > >>implementations. > >> >I proposed a simple method of using the existing FEC advertisement > >> >capability at the session level as a way for an LSR to detect if an > >> >implementation support LDP IPv6 FECs and IPv6 addresses. This existing > >> >FEC advertisement capability at session level is defined in > >> >draft-ietf-mpls-ldp-ip-pw-capability-08 but with the limitation that it > >> >can be used only to disable support of IPv6 FECs in LDP Initialization > >> >Message; we proposed to generalize the method to also indicate explicit > >> >support for IPv6 FECs and IPv6 Addresses in LDP Initialization Message. > >> >This method is safe and was also used with mLDP P2MP and MP2MP FECs > >> when > >> >they were introduced. The intent here is that all session level > >> >capabilities in LDP should follow RFC 5561 approach. > >> > > >> >There was an individual contributor which supported the proposal on the > >> >mailing list but the authors chose to ignore it and went with a > >>proposal > >> >which overloaded the meaning of the dual-stack capability TLV. > >>Regardless > >> >of the merit of either method, the discussion on the MPLS mailing list > >> >was not closed properly from my perspective. > >> > > >> >Now here is the concern I raised with using the dual-stack capability. > >> >Not only this TLV is an adjacency level feature which is has nothing to > >> >do with FEC capability advertisement, but it is introducing complexity > >>in > >> >the implementation which now has to check dual-stack capability for > >> >*each* adjacency to the peer *and* the session level FEC capability to > >> >decide what the peer is capable of at the *session level*. > >> > > >> >Having said that, I want to keep the spirit of cooperation and make > >>sure > >> >we get this draft published. To that effect, I am not opposed to its > >> >publication as long as the following points are clarified in the draft > >> >since now FEC capability of the LSR peer is determined by a check a > >>both > >> >adjacency and session levels: > >> > > >> >1. The draft is missing the behavior when multiple adjacencies exist to > >> >the same LSR and the peer LSR advertised the dual-stack capability only > >> >over a subset of these Hello adjacencies. > >> >I assume here the peer LSR is considered to be dual-stack capable as > >>soon > >> >as any of the Hello adjacencies includes the dual-stack capability. > >>This > >> >would allow a hitless upgrade scenario from an older implementation to > >> >one which complies to this draft > >> > > >> >2. Similarly, what would be the behavior if a hello adjacency changes > >> >from sending the dual-stack capability to not sending it? This would be > >> >for example in a hitless downgrade to a version of LDP which does not > >> >comply to this draft. > >> >I assume here that the session must be bounced since the LSRs need a > >> >clean state to not send IPv6 addresses and IPv6 FECs. > >> > > >> >3. The document defines 2 values for the dual-stack capability TR. It > >> >does not mention the behavior when an unknown value is received. > >> >Will that be considered a fatal error? > >> > > >> >4. The draft is missing the behavior of when the peer LSR does not > >> >advertise the dual-stack capability in all the Hello adjacencies but it > >> >advertised the enabling or disabling of the IPv6 prefix FEC capability > >>in > >> >the session initialization message. > >> >I assume here that the absence of the dual-stack capability overrides > >>any > >> >session level IPv6 FEC prefix capability advertisement. > >> > > >> >5. The draft is missing the behavior of when the peer LSR does not > >> >advertise the dual-stack capability in all the Hello adjacencies but it > >> >advertised the enabling of the IPv6 prefix FEC capability in the > >>session > >> >Capability message. > >> >I assume the same behavior as in (4) applies here. > >> > > >> >Regards, > >> >Mustapha. > >> > > >> >> -----Original Message----- > >> >> From: mpls [mailto:mpls-bounces@xxxxxxxx] On Behalf Of The IESG > >> >> Sent: Thursday, December 04, 2014 2:37 PM > >> >> To: IETF-Announce > >> >> Cc: mpls@xxxxxxxx > >> >> Subject: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates > >> >>to LDP for IPv6) > >> >> to Proposed Standard > >> >> > >> >> > >> >> The IESG has received a request from the Multiprotocol Label > >>Switching > >> >>WG > >> >> (mpls) to consider the following document: > >> >> - 'Updates to LDP for IPv6' > >> >> <draft-ietf-mpls-ldp-ipv6-14.txt> as Proposed Standard > >> >> > >> >> The IESG plans to make a decision in the next few weeks, and solicits > >> >>final > >> >> comments on this action. Please send substantive comments to the > >> >>ietf@xxxxxxxx > >> >> mailing lists by 2014-12-18. Exceptionally, comments may be sent to > >> >>iesg@xxxxxxxx > >> >> instead. In either case, please retain the beginning of the Subject > >> >>line to allow > >> >> automated sorting. > >> >> > >> >> Abstract > >> >> > >> >> The Label Distribution Protocol (LDP) specification defines > >> >> procedures to exchange label bindings over either IPv4, or IPv6 or > >> >> both networks. This document corrects and clarifies the LDP > >>behavior > >> >> when IPv6 network is used (with or without IPv4). This document > >> >> updates RFC 5036 and RFC 6720. > >> >> > >> >> The file can be obtained via > >> >> http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ > >> >> > >> >> IESG discussion can be tracked via > >> >> http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ballot/ > >> >> > >> >> > >> >> No IPR declarations have been submitted directly on this I-D. > >> >> > >> >> _______________________________________________ > >> >> mpls mailing list > >> >> mpls@xxxxxxxx > >> >> https://www.ietf.org/mailman/listinfo/mpls > >> > > >> >_______________________________________________ > >> >mpls mailing list > >> >mpls@xxxxxxxx > >> >https://www.ietf.org/mailman/listinfo/mpls > >