Re: [Idr] Implementations of draft-ietf-idr-bgpls-segment-routing-epe (draft-ietf-ospf-link-overload)

"Acee Lindem (acee)" <> Thu, 12 April 2018 13:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 591BE12711D; Thu, 12 Apr 2018 06:22:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, 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 Hw2TGWGu944O; Thu, 12 Apr 2018 06:22:40 -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 70B3F12708C; Thu, 12 Apr 2018 06:22:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=33992; q=dns/txt; s=iport; t=1523539360; x=1524748960; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+BQF5BI5pXRiSO8ssiCFXkiVcULyOKYVAAk/BnhHUdI=; b=X3JGHzUD3mMFhfSpWr+qe6rqJPM5vnTKDzwcHhlOw8VKIlDml51LheLT mY/GVVnCGUdLmjKfVolOt2wiDxPSq4D2Xh30ZzKS1rClHJrwdn7oePPzR 4BF/ET58MQraeCmC4grFQHF4N0aSsfOCj+RB0sclFMUS4bufyy2yibIss s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxAABvXc9a/5ldJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJNdWFvKAqDWYgCjRCBUyGBD4Zmi30UgWcLHoRlAhqCByE?= =?us-ascii?q?0GAECAQEBAQEBAmwcDIUiAQEBAQMjVhACAQgOAwMBAiEHAwICAh8RFAkIAgQ?= =?us-ascii?q?BDQWEKUwDFQ+nNYIchwkNgSuCKgWHfYITgQ8jDIJcgk9CAgIBAYEkWBaCSjC?= =?us-ascii?q?CJAKIFIhLhlIsCAKFVIVkgn2MRIkjPYYLAhETAYEkARw4gVJwFToqAYIYCYI?= =?us-ascii?q?XFxGISIU+bwGNaYEXAQE?=
X-IronPort-AV: E=Sophos; i="5.48,441,1517875200"; d="scan'208,217"; a="97396667"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2018 13:22:39 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w3CDMdYr015151 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Apr 2018 13:22:39 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 12 Apr 2018 09:22:38 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Thu, 12 Apr 2018 09:22:38 -0400
From: "Acee Lindem (acee)" <>
To: Alvaro Retana <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Implementations of draft-ietf-idr-bgpls-segment-routing-epe (draft-ietf-ospf-link-overload)
Thread-Index: AQHTzdhRBkh67Y0yeE6B6I9CtvfdhKP0SyaAgAkdc4D//75cgA==
Date: Thu, 12 Apr 2018 13:22:38 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_BD49E3C79ABE4905BE560BF9197B2513ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Idr] Implementations of draft-ietf-idr-bgpls-segment-routing-epe (draft-ietf-ospf-link-overload)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Apr 2018 13:22:47 -0000

Hi Alvaro,

Ok – it sounds like you have this under control ;^) Retain 1101 for BGP EPE and use the assign a new value for the OSPF Link Overload Attribute…


From: Alvaro Retana <>
Date: Thursday, April 12, 2018 at 9:17 AM
To: Acee Lindem <>om>, IDR List <>
Cc: "" <>rg>, "" <>rg>, "" <>
Subject: Re: Implementations of draft-ietf-idr-bgpls-segment-routing-epe (draft-ietf-ospf-link-overload)

On April 6, 2018 at 6:05:52 PM, Acee Lindem (acee) (<>) wrote:


There are implementations and deployments -
Also, it looks to me that 1101 is assigned to Peer Node SID already -
Also, I do not see early allocation for the BGP-LS OSPF Link Overload TLV although one is requested in the corresponding draft. Hence, I don’t see what the problem is.

Let me try again.  In short, I’m trying to figure out how serious the problem is...

The early allocation for the BGP-LS OSPF Link Overload TLV was (mistakenly) requested from the BGP-LS NLRI-Types registry [1] and a value of 1101 was assigned.  As you know, that mistake was detected late in the process (during IESG Evaluation!) and fixed in the -15 version of draft-ietf-ospf-link-overload (-16 is the current one).

The BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs registry [2] is the correct registry, and, as you point above, the 1101 value there was assigned to the Peer Node SID (draft-ietf-idr-bgpls-segment-routing-epe).

With this e-mail, and a similar one I sent to the lsr WG, I am trying to figure out the impact (if any) to existing implementation from what could be seen as overlapping assignments, and the actions we may need IANA to take.  For example, if there were implementations of draft-ietf-ospf-link-overload *and* draft-ietf-idr-bgpls-segment-routing-epe with the same value (1101) then we would have a significant problem.  However, the only answer in the lsr list has been to point out that there are no known implementations of draft-ietf-ospf-link-overload — and, from this thread, there is confirmation that implementations of draft-ietf-idr-bgpls-segment-routing-epe exist.

This is probably the best result, and makes the registry cleanup easier.






From: Alvaro Retana <<>>
Date: Friday, April 6, 2018 at 2:51 PM
To: IDR List <<>>
Cc: "<>" <<>>, "<>" <<>>, "<>" <<>>, Acee Lindem <<>>
Subject: Implementations of draft-ietf-idr-bgpls-segment-routing-epe (draft-ietf-ospf-link-overload)

Dear idr WG:

draft-ietf-ospf-link-overload [1] defines a new BGP-LS Graceful-Link-Shutdown TLV.  When an early allocation was requested, it was mistakenly requested from the "BGP-LS NLRI-Types" registry [2], not from the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs” registry [3].  IANA allocated a value according to the request: 1101.

The mistake wasn't noticed until the document was in IESG Evaluation -- we are in the process of correcting it.  However, the 1101 code point in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs” registry corresponds to the Peer-Node-SID, an early allocation made to draft-ietf-idr-bgpls-segment-routing-epe [4], which says that "several early implementations exist".

Are there implementations of draft-ietf-idr-bgpls-segment-routing-epe with the 1101 code point?  Are there deployments of those implementations?