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

[Christian Hopps <[e-mail]>]

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) <[e-mail]> 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 <[e-mail]>
> Sent: Monday, May 21, 2018 9:15 AM
> To: Les Ginsberg (ginsberg) <[e-mail]>
> Cc: Acee Lindem (acee) <[e-mail]>; [e-mail]
> 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) <[e-mail] <mailto:[e-mail]>> 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