RE: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for IPv6) to Proposed Standard

["Aissaoui, Mustapha (Mustapha)" <[e-mail]>]

Hi Rajiv,
I am good with your response below. Thanks!

Mustapha.

> -----Original Message-----
> From: Rajiv Asati (rajiva) [mailto:[e-mail]]
> Sent: Friday, January 09, 2015 10:28 PM
> To: Aissaoui, Mustapha (Mustapha); [e-mail]; IETF-Announce
> Cc: [e-mail]
> 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 <[e-mail]>
> Date: Friday, January 9, 2015 at 6:19 PM
> To: Rajiv Asati <[e-mail]>, IETF Discussion <[e-mail]>,
> IETF-Announce <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> 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:[e-mail]]
> >> Sent: Tuesday, January 06, 2015 6:03 PM
> >> To: Aissaoui, Mustapha (Mustapha); [e-mail]; IETF-Announce
> >> Cc: [e-mail]
> >> 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
> >><[e-mail]>
> >> Date: Tuesday, December 16, 2014 at 12:21 PM
> >> To: IETF Discussion <[e-mail]>, IETF-Announce
> >><[e-mail]>
> >> Cc: "[e-mail]" <[e-mail]>
> >> 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:[e-mail]] On Behalf Of The IESG
> >> >> Sent: Thursday, December 04, 2014 2:37 PM
> >> >> To: IETF-Announce
> >> >> Cc: [e-mail]
> >> >> 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
> >> >>[e-mail]
> >> >> mailing lists by 2014-12-18. Exceptionally, comments may be sent to
> >> >>[e-mail]
> >> >> 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
> >> >> [e-mail]
> >> >> https://www.ietf.org/mailman/listinfo/mpls
> >> >
> >> >_______________________________________________
> >> >mpls mailing list
> >> >[e-mail]
> >> >https://www.ietf.org/mailman/listinfo/mpls
> >