IETF Logo Mail Archive

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 14:14 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 749C61A8875; Fri, 19 Dec 2014 06:14:30 -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 1E3LztDoHhN2; Fri, 19 Dec 2014 06:14:23 -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 1302A1A1A99; Fri, 19 Dec 2014 06:14:22 -0800 (PST)
Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 2D148F69C149C; Fri, 19 Dec 2014 14:14:17 +0000 (GMT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id sBJEEHbK011681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Dec 2014 09:14:17 -0500
Received: from US70UWXCHMBA04.zam.alcatel-lucent.com ([169.254.12.84]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 09:14:17 -0500
From: "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>
To: "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//7nVwA==
Date: Fri, 19 Dec 2014 14:14:17 +0000
Message-ID: <4A79394211F1AF4EB57D998426C9340D947C48D5@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>
In-Reply-To: <201412191424.45419.mark.tinka@seacom.mu>
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/IcH8C6IcPQ7acwPg-4c5N9wNcSw
X-Mailman-Approved-At: Fri, 19 Dec 2014 09:59:17 -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 14:14:30 -0000

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.

v2.23.0 | Report a Bug | By Email