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

Christian Hopps <chopps@chopps.org> Mon, 21 May 2018 16:14 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EF412E8CA for <lsr@ietfa.amsl.com>; Mon, 21 May 2018 09:14:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PMqgZGUaryi for <lsr@ietfa.amsl.com>; Mon, 21 May 2018 09:14:56 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4F04512EAA3 for <lsr@ietf.org>; Mon, 21 May 2018 09:14:49 -0700 (PDT)
Received: from stubbs.lan (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 85D1F60B2F; Mon, 21 May 2018 16:14:48 +0000 (UTC)
From: Christian Hopps <chopps@chopps.org>
Message-Id: <22B658C1-AB82-42EE-AAC5-0320BA73510A@chopps.org>
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: <1edb59cc76f64de4b8462200061cbba4@XCH-ALN-001.cisco.com>
Cc: "Acee Lindem (acee)" <acee@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
References: <612C3B15-9DD2-48C0-A5E5-B999D07AD1D7@cisco.com> <8c0d3e38bfe04b1a973f3cb4285840e8@XCH-ALN-001.cisco.com> <F02D7E3F-15D4-4C8C-89DE-D6F69AA71323@chopps.org> <7686e04b209b4520b5a2f25e96da310d@XCH-ALN-001.cisco.com> <3E609B6F-7AAB-442A-85E4-BBE2BBD4AA70@chopps.org> <14aca4c3177e44dabb66995e3187029a@XCH-ALN-001.cisco.com> <168AA42F-82CA-4882-977C-856FCBC6E6EE@chopps.org> <1edb59cc76f64de4b8462200061cbba4@XCH-ALN-001.cisco.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/IfVzhcOOYSEAyv0hVZh5Bz5crC0>
Subject: Re: [Lsr] Flex Algo merge work, IS-IS and OSPF FAD sub-TLVs
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 May 2018 16:15:07 -0000

> On May 21, 2018, at 11:46 AM, Les Ginsberg (ginsberg) <ginsberg@cisco.com> 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 https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml> 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.

Thanks,
Chris.

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