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

Alvaro Retana <> Thu, 12 April 2018 13:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D978A12708C; Thu, 12 Apr 2018 06:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DbwvwXKtCxL4; Thu, 12 Apr 2018 06:17:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 36A621201F2; Thu, 12 Apr 2018 06:17:35 -0700 (PDT)
Received: by with SMTP id m22-v6so5911410otf.8; Thu, 12 Apr 2018 06:17:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=EUho6P7DduNLn+mWaCj91XcXNg9uxgSn0ygv9kDBG/M=; b=juv3p+N3wD1Pp3Cp3vJnqxACmwIR3euxx9K5yrycx1l/yVMSrygolMHgcgANeJNT6n 1dgeqIZAGQDC8GNFCfRuGoSzUE21P16xbza2YUXotVTHS0ZC0SnYfqkE51Ygo2cyS9vm dhkeBCJQoGvN1uAQPtgRFqXKNUyBkAMQbhBVc2IXQijv4skZqGEJeGs8OtgIh9+ccbP+ QCJeyKNaLi6aKgQxr1k8Jn2PzUh6BIiG/zRL4aiafXg88iwPErD7rSxCFzBv6Y7b+8Ky DH2McJZPQT+SAX8lehgFoR9mma2S0fVOaiATUCynI7mwExhvTYnEbQNQPUk4jg2cS42r Qlhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=EUho6P7DduNLn+mWaCj91XcXNg9uxgSn0ygv9kDBG/M=; b=a6HO7+zeUCBPFYamZiPXtvRHgq2cLcD7Pc87q3QXwIN1mUQuQok3hBuR6wFJeB2PeB yuwwLRs2QmXiDGoYzjxuRC/BV/6ioqQoVEnOOe5gFWb+vqMdspg7PgVEd/vFSKttkCiE wqhhxD+AfcaSbMJr7Fx6x3cbPOttc8/aT2byHcJaFQX8Es5MIGF4btpTcB1bnV0HuBWX dH+rhZYvg0hKGnsv0Zt5loOyhBY0W7mt5ofAOpRBE9Y2BByL7DGcgXqFCGyXeC6B5OEp 0AlT2ccbDF2kvOuDjFHB26PrCk7GV+j1CXrGWAqlc9Eh0TkeLIMlVy2CK9Dz5M1f41Kd zZKw==
X-Gm-Message-State: ALQs6tCbOCxCJKIDSIml7aIxubJOywlSM5/N0LAhjd9LhFQIAeOjHkNt ld/Pj+6dbP+ec+CwYIvQtQdk8ah2lOIanK78dik=
X-Google-Smtp-Source: AIpwx48lsPyOvEwfXY9QiYDzzCuIh+dHv2j3iqBfwdN24zHmGwhkeYP6VeNpSuAhbyAGS1wBZ+d8Titu3tEi9cGq7QE=
X-Received: by 2002:a9d:ba8:: with SMTP id 37-v6mr587770oth.268.1523539054524; Thu, 12 Apr 2018 06:17:34 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 12 Apr 2018 06:17:33 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
X-Mailer: Airmail (467)
MIME-Version: 1.0
Date: Thu, 12 Apr 2018 06:17:33 -0700
Message-ID: <>
To: "Acee Lindem (acee)" <>, "" <>
Cc: "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000257e6c0569a694db"
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:17:38 -0000

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

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
*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: "" <>gt;, "" <>gt;, "" <>gt;, Acee Lindem <>
Subject: Implementations of draft-ietf-idr-bgpls-segment-routing-epe

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?