Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs

Christian Hopps <> Mon, 21 May 2018 16:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81EF412E8CA for <>; Mon, 21 May 2018 09:14:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0PMqgZGUaryi for <>; Mon, 21 May 2018 09:14:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4F04512EAA3 for <>; Mon, 21 May 2018 09:14:49 -0700 (PDT)
Received: from stubbs.lan ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 85D1F60B2F; Mon, 21 May 2018 16:14:48 +0000 (UTC)
From: Christian Hopps <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_187ACDC5-6E3E-43F2-BE21-43A36EAD7C42"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Mon, 21 May 2018 12:14:47 -0400
In-Reply-To: <>
Cc: "Acee Lindem (acee)" <>, "" <>
To: "Les Ginsberg (ginsberg)" <>
References: <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <>
Subject: Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 May 2018 16:15:07 -0000

> On May 21, 2018, at 11:46 AM, Les Ginsberg (ginsberg) <> wrote:
> I fail to see any difference from the IGP algorithm case, which you agreed with.
>   SR Algorithm container:
>     - distributed as a TLV inside Router Information Opaque LSA
>     - distributed as a sub-TLV inside Router Capability TLV
>   IGP Algorithm: The container content which is defined using a common registry.
> [Les:] The SR Algorithm “container identifier” is NOT managed by the IGP Algorithm Registry. It is only the algorithm identifiers– which are advertised inside the protocol specific containers – which are managed by the shared registry.
> Here, however, you are proposing to manage the identifier for the container (not its contents) in a shared registry. That I object to.

Unfortunately, you are incorrect here, I never made that proposal. I presented various options we might choose to share commonality, none of them had to do with sharing top-level code-points, all of them had to do strictly with the content of the FAD [sub-]TLV which is being entirely defined by the document in question.

>  TLV/sub-TLV codepoints are a protocol property. That is why they are managed in protocol specific registries.
> You are now proposing to take “some” protocol specific identifiers and manage them in a protocol independent registry. This is wrong.

I'm talking about the content of the FAD [sub-]TLV only, just like IGP Algorithm registry is defining the content for the SR Algorithm [sub-]TLV, they are completely analogous.

> You think it makes sense to go to <> to find all the IS-IS TLV/sub-TLV codepoints EXCEPT for a few which you want to put into a shared IS-IS/OSPF registry?

This is silly, perhaps not intended but it's very close to a straw man. I know I wrote in an early mail explicitly that my intent had nothing to do with back over anything, so no.


> I don’t.
>    Les
> Thanks,
> Chris.
>   Les