Chris - From: Christian Hopps <cho...@chopps.org> Sent: Monday, May 21, 2018 5:44 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 20, 2018, at 12:33 PM, Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> wrote: Chris- I am happy to see that the scope of this discussion is narrowing. I think the scope of what your proposing is much more appropriate for discussion - but we are in still not in agreement. This has never changed for me, so I'm glad that we are understanding each other better. :) I agree! IGP algorithm is a great example, and I'm glad you agree that it was a good idea. The content of the "Sub-TLVs of the FAD TLV" are in the same way shared by both protocols. The types and the values are defined exactly the same for both protocols. The *only* difference is the encoding of the type (and length) value, the semantics are the same. [Les:] There is a qualitative difference between having a common registry to identify a protocol independent attribute and having a common registry to define a protocol scoped type value. I appreciate that in this case we are defining a new container (FAD) which will have sub-containers that are applicable to both protocols. And I agree that it seems very hard to imagine any future sub-container which would not be applicable to both protocols. And I also agree that assigning the same type value to each sub-TLV for both protocols (now and in the future) is practical - and perhaps even desirable. Great. BTW, nice renaming to "container" here. Nevertheless, the "type" which identifies the sub-container is a protocol scoped attribute. The fact that we could use a common number in this case does not mean it is conceptually correct to consider the value as protocol independent. Let's please keep the definitions in registries which have the correct scope - which in the case of TLV/sub-TLV types is per/protocol. 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. 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. 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? I don't. Les Thanks, Chris. Les
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
