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

"Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com> Mon, 12 January 2015 15:52 UTC

Return-Path: <mustapha.aissaoui@alcatel-lucent.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EF11AC3B2; Mon, 12 Jan 2015 07:52:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQs7DTZ48kHb; Mon, 12 Jan 2015 07:52:42 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D9B1AC3AB; Mon, 12 Jan 2015 07:52:41 -0800 (PST)
Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 61EEBD9D64624; Mon, 12 Jan 2015 15:52:32 +0000 (GMT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t0CFqVpS032098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Jan 2015 10:52:34 -0500
Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.84]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Mon, 12 Jan 2015 10:52:23 -0500
From: "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>
To: "Rajiv Asati (rajiva)" <rajiva@cisco.com>, "ietf@ietf.org" <ietf@ietf.org>, IETF-Announce <ietf-announce@ietf.org>
Subject: RE: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for IPv6) to Proposed Standard
Thread-Topic: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for IPv6) to Proposed Standard
Thread-Index: AQHQD/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgCq3X4CABH7I4IAAgi6AgAPeSVA=
Date: Mon, 12 Jan 2015 15:52:23 +0000
Message-ID: <4A79394211F1AF4EB57D998426C9340D947CC61C@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com> <D0D1B861.243717%rajiva@cisco.com> <4A79394211F1AF4EB57D998426C9340D947CA71B@US70UWXCHMBA04.zam.alcatel-lucent.com> <D0D5F1E9.247EC2%rajiva@cisco.com>
In-Reply-To: <D0D5F1E9.247EC2%rajiva@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.16]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/Ch9Xw2jjgf5z7OH7Rjsf9IGy_N0>
Cc: "mpls@ietf.org" <mpls@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jan 2015 15:52:46 -0000

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

Mustapha.

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