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> Fri, 19 December 2014 19:11 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 83A731ACD6A; Fri, 19 Dec 2014 11:11:04 -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 KojBAC1jviPP; Fri, 19 Dec 2014 11:10:52 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (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 95C361A9072; Fri, 19 Dec 2014 11:10:52 -0800 (PST)
Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 4D9B270F1716; Fri, 19 Dec 2014 19:10:47 +0000 (GMT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id sBJJAmOT030351 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Dec 2014 14:10:48 -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; Fri, 19 Dec 2014 14:10:48 -0500
From: "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>
To: "afarrel@juniper.net" <afarrel@juniper.net>, "mark.tinka@seacom.mu" <mark.tinka@seacom.mu>
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/m6uliIBH9faEWPZUJhwqq2TZyJQy9AgApvIICAACbQ0IAAx8AAgAAnohCAASpngP//xxbAgAGHa4D//7nVwIAAqhCA//+yBpA=
Date: Fri, 19 Dec 2014 19:10:47 +0000
Message-ID: <4A79394211F1AF4EB57D998426C9340D947C4A74@US70UWXCHMBA04.zam.alcatel-lucent.com>
References: <20141204193700.25973.18733.idtracker@ietfa.amsl.com> <201412181827.34972.mark.tinka@seacom.mu> <4A79394211F1AF4EB57D998426C9340D947C4616@US70UWXCHMBA04.zam.alcatel-lucent.com> <201412191424.45419.mark.tinka@seacom.mu> <4A79394211F1AF4EB57D998426C9340D947C48D5@US70UWXCHMBA04.zam.alcatel-lucent.com> <078001d01bb8$ba013c80$2e03b580$@juniper.net>
In-Reply-To: <078001d01bb8$ba013c80$2e03b580$@juniper.net>
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/NY2X9nybBmXciiVyMcbteQBMQck
X-Mailman-Approved-At: Mon, 22 Dec 2014 08:04:39 -0800
Cc: "mpls@ietf.org" <mpls@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, 'IETF-Announce' <ietf-announce@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: Fri, 19 Dec 2014 19:11:04 -0000

Hi Adrian,
We found interop issues with two other widely deployed implementations in which the LDP IPv4 session was brought down. 

One implementation was with receiving IPv6 addresses over the LDPv4 session and the behavior did not seem to change with a few versions of the implementation we tried. The second implementation was with IPv6 FECs over the LDPv4 session. This last one was fixed in a subsequent release but we lately found out that there were still issues with withdrawing/releasing the IPv6 FECs.

The issue exists in both p2p and broadcast interfaces. The thing is that as soon as a router is upgraded to this implementation, it will automatically begin advertising IPv6 addresses and IPv6 FECs over the LDPv4 session. Based on testing so far, and we have not tested all possible OS and hardware versions, we believe it is risky to advertise these by default and hence our proposal to play it safe and only advertise them if the peer LSR explicitly advertised its support for IPv6 FECs by including the IPv6 FEC capability in the session initialization. 

The draft now added a similar check using the dual-stack capability TLV at the adjacency level instead of our proposal of using the capability TLV at the session level. It does complicate the check of the peer capabilities and as such I provided comments in the last call email to clarify the behavior of that proposal.

Regards,
Mustapha.

> -----Original Message-----
> From: Adrian Farrel [mailto:afarrel@juniper.net]
> Sent: Friday, December 19, 2014 1:22 PM
> To: Aissaoui, Mustapha (Mustapha); mark.tinka@seacom.mu
> Cc: mpls@ietf.org; ietf@ietf.org; 'IETF-Announce'
> Subject: RE: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for
> IPv6) to Proposed Standard
> 
> Mustapha,
> 
> It will fall to me to try to draw some form of consensus out of this discussion so I
> have would like to clarify some things.
> 
> Are you reporting an interop problem with widely deployed implementations, or an
> interop problem with one release of one implementation? The latter is what I would
> call a bug, since the problem is a failure to conform to 5036. The former is, of
> course, a bigger problem.
> 
> Are you reporting a problem that is exclusive to multi-access links? While this is an
> important use case, it is a little marginal.
> 
> In short, do you have a corner case comprising of:
> - multi-access link
> - combined legacy v4 nodes and new v6 nodes
> - a non-conformant v4 node
> ...or is the problem larger than that?
> 
> Thanks,
> Adrian
> 
> > -----Original Message-----
> > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Aissaoui,
> > Mustapha
> > (Mustapha)
> > Sent: 19 December 2014 14:14
> > To: mark.tinka@seacom.mu
> > Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce
> > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt>
> > (Updates to
> LDP for
> > IPv6) to Proposed Standard
> >
> > Hi Mark,
> > Indeed the reason I raised the issue in the summer was to make sure we
> > do not disrupt existing LDPv4 deployments and that we do not need to
> > upgrade a LDPv4 node which does not comply to this LDPv6 spec. So,
> > both proposed methods put the onus on the LDPv6 compliant node to
> > automatically detect a router which is not compliant to LDPv6 such
> > that it will not send to that node LDP IPv6 FECs
> and
> > IPv6 addresses.
> >
> > >From that perspective, the draft now addressed the issue. My latest
> > >message
> > was raising concerns about the specific method added to the draft and
> > by which the LDPv6 compliant LSR goes about addressing the issue.
> >
> > I hope this clarifies the situation.
> >
> > Regards,
> > Mustapha.
> >
> > > -----Original Message-----
> > > From: Mark Tinka [mailto:mark.tinka@seacom.mu]
> > > Sent: Friday, December 19, 2014 7:25 AM
> > > To: Aissaoui, Mustapha (Mustapha)
> > > Cc: mpls@ietf.org; ietf@ietf.org; IETF-Announce
> > > Subject: Re: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt>
> > > (Updates to
> LDP
> > for
> > > IPv6) to Proposed Standard
> > >
> > > On Friday, December 19, 2014 01:25:15 AM Aissaoui, Mustapha
> > > (Mustapha) wrote:
> > >
> > > > What we were debating is if we should use the LDP capability TLV
> > > > mechanism which LDP uses to advertise any new capability not
> > > > supported by previous implementations versus overloading another
> > > > TLV which was not meant for capability discovery.
> > >
> > > As an operator, having to upgrade a non-compliant device that is not
> > > yet
> ready
> > to
> > > run LDPv6 so that a neighboring LDPv6-capable device planning to run
> > > LDPv6
> > can
> > > still form
> > > LDPv4 adjacencies is quite heavy-handed.
> > >
> > > Upgrading a device for anything LDPv6 should, ideally, be in the
> > > interest of
> > getting
> > > LDPv6 deployed, and not to prevent
> > > LDPv4 adjacency tear-down due to capability incompatibility.
> > >
> > > On the other hand, it might be worthwhile looking into adding a knob
> > > for an
> > LDPv6-
> > > compliant device to tell it to have backwards compatibility with
> non-compliant
> > > devices on the wire. Since one would, in all likelihood, be
> > > upgrading a non-
> > compliant
> > > device to make it compliant, the heavy-hand makes sense here since
> > > an
> > operator
> > > needs to get the code in anyway.
> > >
> > > Mark.
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org
> > https://www.ietf.org/mailman/listinfo/mpls