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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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 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