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

"Aissaoui, Mustapha (Mustapha)" <> Tue, 06 January 2015 21:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7BAD81A0113; Tue, 6 Jan 2015 13:02:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.91
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UXOWWIlSWYy8; Tue, 6 Jan 2015 13:02:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A09F91A6F2A; Tue, 6 Jan 2015 13:02:02 -0800 (PST)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id 0D8BACD683244; Tue, 6 Jan 2015 21:01:54 +0000 (GMT)
Received: from ( []) by (GMO) with ESMTP id t06L1vfB029472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 6 Jan 2015 16:01:57 -0500
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 16:01:57 -0500
From: "Aissaoui, Mustapha (Mustapha)" <>
To: "" <>, IETF-Announce <>
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/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgCqEA0A=
Date: Tue, 6 Jan 2015 21:01:57 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 07 Jan 2015 08:18:46 -0800
Cc: "" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Jan 2015 21:02:06 -0000

Adrian and authors,
Can we also close on the IANA assignment for the new TLVs and specifically for the Dual-Stack Capability TLV?

I assume this will be drawn from the Common Hello Parameters range of the LDP TLV Type Name Space. The next available value is 0x0409. I appreciate if you could confirm this value.


> -----Original Message-----
> From: mpls [] On Behalf Of Aissaoui, Mustapha
> (Mustapha)
> Sent: Tuesday, December 16, 2014 12:22 PM
> To:; IETF-Announce
> Cc:
> 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 [] On Behalf Of The IESG
> > Sent: Thursday, December 04, 2014 2:37 PM
> > To: IETF-Announce
> > Cc:
> > 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
> > mailing lists by 2014-12-18. Exceptionally, comments may
> > be sent to 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
> >
> >
> > IESG discussion can be tracked via
> >
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> > _______________________________________________
> > mpls mailing list
> >
> >
> _______________________________________________
> mpls mailing list