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

"Adrian Farrel" <afarrel@juniper.net> Fri, 19 December 2014 18:22 UTC

Return-Path: <afarrel@juniper.net>
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 2CD351ACCF9; Fri, 19 Dec 2014 10:22:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
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 V-l1VlOAkqzi; Fri, 19 Dec 2014 10:22:33 -0800 (PST)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABED1ACD1E; Fri, 19 Dec 2014 10:22:32 -0800 (PST)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBJIMST0010459; Fri, 19 Dec 2014 18:22:29 GMT
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id sBJIMPnm010395 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 19 Dec 2014 18:22:26 GMT
From: "Adrian Farrel" <afarrel@juniper.net>
To: "'Aissaoui, Mustapha \(Mustapha\)'" <mustapha.aissaoui@alcatel-lucent.com>, <mark.tinka@seacom.mu>
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>
In-Reply-To: <4A79394211F1AF4EB57D998426C9340D947C48D5@US70UWXCHMBA04.zam.alcatel-lucent.com>
Subject: RE: [mpls] Last Call: <draft-ietf-mpls-ldp-ipv6-14.txt> (Updates to LDP for IPv6) to Proposed Standard
Date: Fri, 19 Dec 2014 18:22:17 -0000
Message-ID: <078001d01bb8$ba013c80$2e03b580$@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQEavZr4LLvEoVKVBHX9h497xfv8bQFic8MEArQt0NUBhvNK4AIMca6CncSj6vA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21188.002
X-TM-AS-Result: No--40.018-10.0-31-10
X-imss-scan-details: No--40.018-10.0-31-10
X-TMASE-MatchedRID: Ojx+9XBBWGvZNO+XkKeVnSrFJXkaeddx6hUo8ujhEXt9c66OtqoXQuiY +s2L3xQETzZrG+KJluYuLLrhEK94BjM9Cwl5qH1FcgRuMUq2K0gvmfQHDKJ1l9igeTkdjx3hbd6 rGhWOAwT4JyR+b5tvoPG399+Ui/tdWTXzX6U+UCa21u7MJ+0iRTzr4TJKjukKuIwLnB3Aqp0GF+ E6mzeNqN9RlPzeVuQQHIDypuQ6GngxcSfgz4Zxa/FPDHhQkgxyVddl4Ia+kJPPhdXKEUVkchmyT BaqiJvcfeB8ZkBTx8v96qgBvkbYNGWETisY1v9qOaKAZa7BhDzHqyfFy3TE0kst+Oj0y0ls2D/7 bUIJlF2iwcw4+Mrtw2c4B71z5rPYeACX81jEw+u/akshkYK9vygaoyC9I8oNmlaAItiONP32v20 RxLDyN2sSgW01iDQLeyKvlsbWzZYhvNeGEEojjwTgsVt779d+Y2JnK7gKcXL7/v/5alNYeh852j gffnmIULzpjrEhojrN/2wFL5/vDMb0m1re9TVL/s8l/i/pT2u31G6CKdUG1fYiLRVJ915DWLk7K HjvnCRXPwnnY5XL5LppSwuYPeB79p+FCsxUVBOGCLqQvRi5SGFqPXSLpNdAQr2qXCJMSV91k+gP 1XamtJsoi2XrUn/JyeMtMD9QOgCk8oKXKhRLPI2j49Ftap9EkGUtrowrXLg=
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/iSlC-B1zxRO9ZmuaH2BuCvxPZOY
X-Mailman-Approved-At: Mon, 22 Dec 2014 07:58:59 -0800
Cc: mpls@ietf.org, ietf@ietf.org, 'IETF-Announce' <ietf-announce@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: afarrel@juniper.net
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 18:22:35 -0000

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