Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS)

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 13 June 2018 15:42 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3E51294D0; Wed, 13 Jun 2018 08:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 uo_OwyNhq40Z; Wed, 13 Jun 2018 08:42:28 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47811127148; Wed, 13 Jun 2018 08:42:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8155; q=dns/txt; s=iport; t=1528904548; x=1530114148; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7rq9vIVRzT2M9yHEVvzHr8PWJ1BWhxnyNjrMLznMD18=; b=DfHPbo35BXZ5KJaveaQQDvFRnhNW9eSR8PQDxy6gvLZUvFmFHJQquAb6 D1vyhs5Z2kf9clKvEBbzFchJ3USBQmDVvaEuuFmTU/XDQmzCDFtuOxZ6D QGKIxrEqgqg/xhLWOQfblI1dFPDHO8liKlscPrhbWTSCRhB5EYlyFuPdp 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8AAATOyFb/5pdJa1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNIYn8oCotzjGmBf5RpgXgLGA2ERwKCNyE0GAECAQEBAQE?= =?us-ascii?q?BAm0cDIUoAQEBAQMBATg0FwQCAQgRBAEBHwkHJwsUCQgBAQQBEggTgwmBfw+?= =?us-ascii?q?uPIN6AYRMgWiIS4FUP4EPgg5+gxEBAQIBARaBIIV8ApkKCQKFcoh/gUdBgz2?= =?us-ascii?q?Hd4drgh+HDAIREwGBJB04gVJwFRohgkMJiwiFCAE1b4xjgS2BGgEB?=
X-IronPort-AV: E=Sophos;i="5.51,219,1526342400"; d="scan'208";a="128672234"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jun 2018 15:42:15 +0000
Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w5DFgF8K003226 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jun 2018 15:42:15 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 13 Jun 2018 10:42:14 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1320.000; Wed, 13 Jun 2018 10:42:14 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>, "idr@ietf.org" <idr@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: Signalling ERLD (ISIS, OSPF and BGP-LS)
Thread-Index: AdQCVS4zJNJrYGL7RvyJWFnJWJ9mLgAhqsxQAAPpAwAAAcpz8AAATSsgAA3381A=
Date: Wed, 13 Jun 2018 15:42:14 +0000
Message-ID: <eda066dc9b0c4502af7e125a7d613c44@XCH-ALN-001.cisco.com>
References: <AM5PR0701MB17290B271DD58F23E0E3EA86E07F0@AM5PR0701MB1729.eurprd07.prod.outlook.com> <741c5584debc4bc7821292de52f8d6c4@XCH-ALN-008.cisco.com> <AM5PR0701MB172929505908F164E3DCA377E07E0@AM5PR0701MB1729.eurprd07.prod.outlook.com> <5c494d4e76cf4fa1adcb695f4ee4b59e@XCH-ALN-008.cisco.com> <AM5PR0701MB1729C0A2324D84DBB71AA269E07E0@AM5PR0701MB1729.eurprd07.prod.outlook.com>
In-Reply-To: <AM5PR0701MB1729C0A2324D84DBB71AA269E07E0@AM5PR0701MB1729.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.52.209]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/nWQ5UpUeMXgLgN43uactsKSaqdI>
Subject: Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jun 2018 15:42:32 -0000

Gunter -

I strongly support Option #2 and strongly support Ketan's recommendation that an MSD sub-type be used to advertise ERLD.
This is the unified framework that the MSD advertisement has been designed to support.

The following documents provide a unified definition of this mechanism:

https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/
https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-msd/
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/

(The last one needs a refresh.)

If we can update the related ERLD documents to align I think we will have an excellent solution.

 (Note: in the case of https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/ perhaps that can be combined with https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/  - but I leave that to the respective authors to work out.)

   Les



> -----Original Message-----
> From: Lsr <lsr-bounces@ietf.org> On Behalf Of Van De Velde, Gunter (Nokia
> - BE/Antwerp)
> Sent: Wednesday, June 13, 2018 2:10 AM
> To: Ketan Talaulikar (ketant) <ketant@cisco.com>om>; idr@ietf.org; lsr@ietf.org;
> spring@ietf.org
> Subject: Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS)
> 
> It is desirable that same understanding of TLVs ([ELC, RLD] or [ERLD]) are
> signaled for ISIS, OSPF and BGP-LS.
> 
> If the WG's can manage to agree upon a decision (option1/2/3 or 4), then
> next, have a look into how to encode the TLV so that we have a clean
> technological solution space.
> 
> G/
> 
> -----Original Message-----
> From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
> Sent: Wednesday, June 13, 2018 10:45
> To: Van De Velde, Gunter (Nokia - BE/Antwerp)
> <gunter.van_de_velde@nokia.com>om>; idr@ietf.org; lsr@ietf.org;
> spring@ietf.org
> Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)
> 
> Hi Gunter,
> 
> In that case, I concur with you that option (2) is better than the others. My
> only difference in opinion is that ERLD not have its own separate TLV but
> instead get advertised as a new MSD sub-type - it is just a different encoding.
> 
> Thanks,
> Ketan
> 
> -----Original Message-----
> From: Van De Velde, Gunter (Nokia - BE/Antwerp)
> <gunter.van_de_velde@nokia.com>
> Sent: 13 June 2018 13:55
> To: Ketan Talaulikar (ketant) <ketant@cisco.com>om>; idr@ietf.org; lsr@ietf.org;
> spring@ietf.org
> Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)
> 
> Indeed, the debate that made BGP-LS to go down the ERLD path is of
> pragmatic motivation.
> 
> The major Readable Label Depth use-case is entropy. Hence, if the ERLD TLV
> is available, then ELC can be implicitly assumed. No pragmatic reason to signal
> separately, as it just make things more complex then should be.
> 
> >From a holistic perspective having something similar, yet different, in both
> IGP and BGP-LS encoding seems to make little sense and only bring
> confusion (router/controller implementers and network operators).
> 
> The ways to address this in IGP and BGP-LS going forward:
> 1) do nothing and leave all as it is (it has potential to create massive
> confusion)
> 2) only signal ERLD TLV in IGP and BGP
> 3) signal ELC TLV and RLD TLV (unclear pragmatic value of explicit signaling of
> ELC TLV compared to option (2))
> 4) signal ELC TLV, RLD TLV and ERLD TLV (it has all, but is much much more
> complex as option (2))
> 
> I believe that option (2) is the best option:
> * it bring the needed readable label depth value to operators
> * most simple solution for implementers (routers and controller)
> * easy to understand with no confusion
> * is compliant with draft-ietf-mpls-spring-entropy-label-10
> 
> G/
> 
> -----Original Message-----
> From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com]
> Sent: Wednesday, June 13, 2018 08:05
> To: Van De Velde, Gunter (Nokia - BE/Antwerp)
> <gunter.van_de_velde@nokia.com>om>; idr@ietf.org; lsr@ietf.org;
> spring@ietf.org
> Subject: RE: Signalling ERLD (ISIS, OSPF and BGP-LS)
> 
> Hi Gunter,
> 
> The difference in IGP signalling seems to be because the ELC is a capability
> which is advertised differently than ERLD which is a limit. Are you saying that
> ELC does not have value by itself without the ERLD?
> 
> IMHO it makes sense to retain ELC as capability of the router (as specified in
> the IGP specs) and position ERLD as a MSD sub-type for indicating the limit.
> This way we have the flexibility of signalling ERLD both per node and per
> ingress link/LC level.
> 
> Thanks,
> Ketan
> 
> -----Original Message-----
> From: Idr <idr-bounces@ietf.org> On Behalf Of Van De Velde, Gunter (Nokia
> - BE/Antwerp)
> Sent: 12 June 2018 19:28
> To: idr@ietf.org; lsr@ietf.org; spring@ietf.org
> Subject: [Idr] Signalling ERLD (ISIS, OSPF and BGP-LS)
> 
> In LSR WG the following drafts document the signaling of ELC and RLD:
> * draft-ietf-ospf-mpls-elc
> * draft-ietf-isis-mpls-elc
> 
> When exporting this information using BGP-LS encoding to a controller, there
> is need for BGP-LS extension by means of new TLVs.
> 
> BGP-LS is signaling ERLD (entropy capable readable label depth) ISIS/OSPF is
> signaling individually ELC and RLD
> 
> I was working upon the IANA section, and discovered some inconsistency
> that should be addressed:
> * Why is IGP signaling individual ELC and RLD? ERLD is what was decided upon
> (https://tools.ietf.org/html/draft-ietf-mpls-spring-entropy-label-10)
> * What are the plans to request IANA code points for these drafts?
> * (E)RLD seems to have meaning only from NODE perspective, (I assume that
> LINK ERLD is not of any value at all, is that a correct assumption?)
> 
> G/
> 
> 
> -----Original Message-----
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of internet-
> drafts@ietf.org
> Sent: Tuesday, June 12, 2018 15:25
> To: i-d-announce@ietf.org
> Cc: idr@ietf.org
> Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Inter-Domain Routing WG of the IETF.
> 
>         Title           : Signalling ERLD using BGP-LS
>         Authors         : Gunter Van de Velde
>                           Wim Henderickx
>                           Matthew Bocci
>                           Keyur Patel
> 	Filename        : draft-ietf-idr-bgp-ls-segment-routing-rld-02.txt
> 	Pages           : 6
> 	Date            : 2018-06-12
> 
> Abstract:
>    This document defines the attribute encoding to use for BGP-LS to
>    expose ERLD "Entropy capable Readable Label Depth" from a node to a
>    centralised controller (PCE/SDN).
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-rld/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-rld-02
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-
> rld-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-rld-
> 02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr