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

"Les Ginsberg (ginsberg)" <> Mon, 21 May 2018 17:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2351D12E8C6 for <>; Mon, 21 May 2018 10:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 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, 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 CWOnlF3VKft2 for <>; Mon, 21 May 2018 10:19:35 -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 A4AC212D87B for <>; Mon, 21 May 2018 10:19:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=31844; q=dns/txt; s=iport; t=1526923175; x=1528132775; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=npU0Qsi7fYMMjhiXezqCyF6nNRyRYAtPqTW4fInAvXs=; b=eSgj94nmJnDVhBhhHLCwPdke1SSBZaha9XE/bt9653zeBhuDw7/HJ5OQ 3fq1DKIqJi2Ewr7wsIIXGQyG/2mG+/VA2dbNWVSxGtEQJF+SRpWZuCEjg PofnFKcgaJm3FaO/eSoGKKOZ83zjSVoKAk+Isjh2dxdVmskC1pYjW/zni Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnAADm/gJb/5hdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYJNdmF9KAqDa4gEjHOBeYEPkzaBeAslhEcCGoF/ITQYAQI?= =?us-ascii?q?BAQEBAQECbBwMhSgBAQEBAyMKTBACAQYCDgMEAQEhBwMCAgIwFAkIAgQOBQi?= =?us-ascii?q?DHIEbZA+MOZtDghyIQYIKBYg1gVQ/gQ6CXy6EUwEBNQ8QgkqCVAKRFIc4CQK?= =?us-ascii?q?OTY0FkFACERMBgSQBHDiBUnAVgn6LEIU+bwGNfIEfgRgBAQ?=
X-IronPort-AV: E=Sophos;i="5.49,426,1520899200"; d="scan'208,217";a="396687289"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 May 2018 17:19:34 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w4LHJYmN020240 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 May 2018 17:19:34 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 21 May 2018 12:19:33 -0500
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Mon, 21 May 2018 12:19:33 -0500
From: "Les Ginsberg (ginsberg)" <>
To: Christian Hopps <>
CC: "Acee Lindem (acee)" <>, "" <>
Thread-Topic: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs
Thread-Index: AQHT7rSaiHAWoyz3a0iRubot8Dm8UqQ1nILggAHAzoD//9yh8IAA0/2AgADBBXCAAapPgP//3OvggABd6ID//6834AAL+PGAAAolZLA=
Date: Mon, 21 May 2018 17:19:33 +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: multipart/alternative; boundary="_000_f02c0b0d5b8c4b9abe519904324dfe47XCHALN001ciscocom_"
MIME-Version: 1.0
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 17:19:39 -0000

Chris –

To be “absolutely clear”, I object to the sharing of the “protocol type” field at any level.
We are not talking about “content”.


From: Christian Hopps <>
Sent: Monday, May 21, 2018 10:08 AM
To: Les Ginsberg (ginsberg) <>
Cc: Acee Lindem (acee) <>om>;
Subject: Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs

Ok, so your position is that b/c the defined content takes the form of type-len-value the registry for it cannot be shared, but if, like IGP Algorithm, it had "just" been a collection of values sharing would be fine.

Peter was OK with sharing the registry. I am as well.

Let's let others chime in.


On May 21, 2018, at 12:46 PM, Les Ginsberg (ginsberg) <<>> wrote:

Chris –

I think you are making this thread far more confusing than necessary.
Protocol code points include:

Top level TLV types
Sub-TLV types
Sub-sub-TLV types

Obviously a sub-TLV is “contained” in a TLV
And a “sub-sub-TLV” is contained within a sub-TLV

This does not alter the fact that all of these type identifiers are protocol specific and are managed in protocol specific registries. There are many existing examples of this.

The values managed in the “IGP Algorithm” registry are not used as a “type” identifier at any level in the protocol. They are the values advertised within the “container” – whether that container is a TLV or a sub-TLV or…

If we cannot agree on this then we will never agree on anything.

“types” at any level are protocol specific and should be managed on protocol specific registries.


From: Christian Hopps <<>>
Sent: Monday, May 21, 2018 9:15 AM
To: Les Ginsberg (ginsberg) <<>>
Cc: Acee Lindem (acee) <<>>;<>
Subject: Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs

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.