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

"Ketan Talaulikar (ketant)" <> Wed, 13 June 2018 06:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A339130DE5; Tue, 12 Jun 2018 23:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zVo86g8pFe5E; Tue, 12 Jun 2018 23:05:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB7B0130DE4; Tue, 12 Jun 2018 23:05:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3582; q=dns/txt; s=iport; t=1528869929; x=1530079529; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=T8sldE26GPSaxjyTxYCakl2x9hLZQYDuLmlwyXEPGmI=; b=mJr4VEDp8GUQSZl9RPN9Y1fo6rut7P34h0WdNfiInqDrv5E18So0aY/Y K5PO0MnaW2UD8lhlfMX50SlyayWNexnmO0k90UKdFVwhFVYJPSk4v0q0+ iVJ4TmXWSvrh2c4k73u0jdDZYC62z+B1DAFBApbVJ3MXSN/9JSk9UxNhg g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ChAACDsyBb/5xdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNDYn8oCotzjGmBf5RmgXgLGA2ERwKCNCE0GAECAQEBAQE?= =?us-ascii?q?BAm0cDIUoAQEBBAEBODQXBAIBCBEEAQEfCQcnCxQJCAEBBAESCIMcgX8Pry6?= =?us-ascii?q?IRoFoiEiBVD+BD4MMgxEBAQIBARaBIIV8ApkHCQKFcoh+gUdBgzyHdYoJhwo?= =?us-ascii?q?CERMBgSQdOIFScBUaIYJDCYsIhT5vjUCBLYEaAQE?=
X-IronPort-AV: E=Sophos;i="5.51,217,1526342400"; d="scan'208";a="399160366"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jun 2018 06:05:28 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w5D65Si6027221 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 13 Jun 2018 06:05:28 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 13 Jun 2018 01:05:28 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Wed, 13 Jun 2018 01:05:28 -0500
From: "Ketan Talaulikar (ketant)" <>
To: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <>, "" <>, "" <>, "" <>
Thread-Topic: Signalling ERLD (ISIS, OSPF and BGP-LS)
Thread-Index: AdQCVS4zJNJrYGL7RvyJWFnJWJ9mLgAhqsxQ
Date: Wed, 13 Jun 2018 06:05:28 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Lsr] Signalling ERLD (ISIS, OSPF and BGP-LS)
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Jun 2018 06:05:38 -0000

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.


-----Original Message-----
From: Idr <> On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: 12 June 2018 19:28
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 (
* 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?)


-----Original Message-----
From: Idr [] On Behalf Of
Sent: Tuesday, June 12, 2018 15:25
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

   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:

There are also htmlized versions available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:

Idr mailing list

Idr mailing list