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

Christian Hopps <> Mon, 21 May 2018 12:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C74141270A0 for <>; Mon, 21 May 2018 05:44:19 -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 ORLDphnIXRNe for <>; Mon, 21 May 2018 05:44:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 78481127077 for <>; Mon, 21 May 2018 05:44:17 -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 A598360B2F; Mon, 21 May 2018 12:44:16 +0000 (UTC)
From: Christian Hopps <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_F9482D5C-27DE-4537-9E47-BE546C56DF8C"; 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 08:44:15 -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 12:44:20 -0000

On May 20, 2018, at 12:33 PM, Les Ginsberg (ginsberg) <> wrote:
> Chris-
> I am happy to see that the scope of this discussion is narrowing. I think the scope of what your proposing is much more appropriate for discussion - but we are in still not in agreement.

This has never changed for me, so I'm glad that we are understanding each other better. :)

>> I agree! IGP algorithm is a great example, and I'm glad you agree that it was a
>> good idea. The content of the "Sub-TLVs of the FAD TLV" are in the same way
>> shared by both protocols. The types and the values are defined exactly the
>> same for both protocols. The *only* difference is the encoding of the type
>> (and length) value, the semantics are the same.
> [Les:] There is a qualitative difference between having a common registry to identify a protocol independent attribute and having a common registry to define a protocol scoped type value.
> I appreciate that in this case we are defining a new container (FAD) which will have sub-containers that are applicable to both protocols. And I agree that it seems very hard to imagine any future sub-container which would not be applicable to both protocols. And I also agree that assigning the same type value to each sub-TLV for both protocols (now and in the future) is practical - and perhaps even desirable.

Great. BTW, nice renaming to "container" here.

> Nevertheless, the "type" which identifies the sub-container is a protocol scoped attribute.  The fact that we could use a common number in this case does not mean it is conceptually correct to consider the value as protocol independent.
> Let's please keep the definitions in registries which have the correct scope - which in the case of TLV/sub-TLV types is per/protocol.

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