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> Tue, 06 January 2015 21:02 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 7BAD81A0113; Tue, 6 Jan 2015 13:02:06 -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 UXOWWIlSWYy8; Tue, 6 Jan 2015 13:02:03 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 A09F91A6F2A; Tue, 6 Jan 2015 13:02:02 -0800 (PST)
Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 0D8BACD683244; Tue, 6 Jan 2015 21:01:54 +0000 (GMT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (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 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; Tue, 6 Jan 2015 16:01:57 -0500
From: "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>
To: "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/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgCqEA0A=
Date: Tue, 6 Jan 2015 21:01:57 +0000
Message-ID: <4A79394211F1AF4EB57D998426C9340D947C86E5@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com>
In-Reply-To: <4A79394211F1AF4EB57D998426C9340D947C1FD1@US70UWXCHMBA04.zam.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/NKzT9WzcXk-7JoJNbVZPUDSKUUI
X-Mailman-Approved-At: Wed, 07 Jan 2015 08:18:46 -0800
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: 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.

Regards,
Mustapha.

> -----Original Message-----
> From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui, Mustapha
> (Mustapha)
> Sent: Tuesday, December 16, 2014 12:22 PM
> To: 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 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