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) <ginsb...@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 <cho...@chopps.org> > Sent: Monday, May 21, 2018 9:15 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Acee Lindem (acee) <a...@cisco.com>; 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) <ginsb...@cisco.com > <mailto:ginsb...@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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
