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

Christian Hopps <chopps@chopps.org> Mon, 21 May 2018 17:08 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 23D3412E8C6 for <lsr@ietfa.amsl.com>; Mon, 21 May 2018 10:08:33 -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 muwCM6m131aa for <lsr@ietfa.amsl.com>; Mon, 21 May 2018 10:08:30 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3343E12D775 for <lsr@ietf.org>; Mon, 21 May 2018 10:08:30 -0700 (PDT)
Received: from [192.168.2.5] (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 5E9C060B2F; Mon, 21 May 2018 17:08:29 +0000 (UTC)
From: Christian Hopps <chopps@chopps.org>
Message-Id: <2C33BA76-F73E-4D11-8F86-04D97D56E6F2@chopps.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_B15B9F90-B4BB-4F17-A113-33AFA148992D"; 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 13:08:27 -0400
In-Reply-To: <0aea42173b704a29a8bf79773e361354@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> <22B658C1-AB82-42EE-AAC5-0320BA73510A@chopps.org> <0aea42173b704a29a8bf79773e361354@XCH-ALN-001.cisco.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ntYVuh0h_Tw6R7-XNA5WVok5eUs>
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 17:08:33 -0000

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.

Thanks,
Chris.

> On May 21, 2018, at 12:46 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com> 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
> Etc.
> 
> 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.
> 
>    Les
> 
> 
> 
> From: Christian Hopps <chopps@chopps.org>
> Sent: Monday, May 21, 2018 9:15 AM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> Cc: Acee Lindem (acee) <acee@cisco.com>om>; lsr@ietf.org
> 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) <ginsberg@cisco.com <mailto: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