I agree, the granularity would depend on the feature/RFC. Another aspect I have seen in TLV implementations is, Receiving side processing is supported But sending side isn’t. It may be useful to introduce this sending support/receiving support notion in the Model.
Rgds Shraddha Juniper Business Use Only From: Lsr <[email protected]> On Behalf Of Yingzhen Qu Sent: Friday, November 17, 2023 4:28 AM To: Tony Li <[email protected]> Cc: Acee Lindem <[email protected]>; Les Ginsberg (ginsberg) <[email protected]>; Loa Andersson <[email protected]>; [email protected] Subject: Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang [External Email. Be cautious of content] Speaking as a co-author of the draft, I'm open to name suggestions. As for granularity, I'd say this really varies per RFC/feature. We want to make it useful for operators but not too tedious to implement. Realistically, we won't be able to have modules for all existing RFCs, so it's more about new RFCs. The WG should decide the level of feature granularity as part of the document when it is to be published. Thanks, Yingzhen On Thu, Nov 16, 2023 at 2:44 PM Tony Li <[email protected]<mailto:[email protected]>> wrote: Hi Acee, I concur that a simpler name is better and am fine with what you propose. Or pretty much anything other than ‘PICS’. :-) I disagree that feature level granularity is sufficient. Example: suppose an implementation supports traffic engineering. Is that sufficient for an operator? Is that enough to ensure interoperability? I’m not convinced. Does the node support administrative groups? What about extended administrative groups? Maybe we don’t need to be at the individual TLV level for every feature, but it sure would be nice to call out each and every option that an implementation may support. Yes, I realize that it’s a giant hassle, but if we ever want to get to the world when network management is fully automated, we will need to make everything transparent. Regards, Tony On Nov 16, 2023, at 2:32 PM, Acee Lindem <[email protected]<mailto:[email protected]>> wrote: Speaking as a WG contributor: Hi Les, I think a simpler name is better - perhaps ietf-isis-feature-support.yang with YANG prefix isis-fs would be better. Which brings me to my next and more important point… Like carbon neutrality, everyone at the LSR WG meeting who had an opinion thought such a YANG model would be operationally useful. However, I think the level of granularity is key. I believe that having a separate data node for each TLV/sub-TLV as was done in the example ietf-isis-pics-sr-mpls.yang module is way too granular to be useful. Rather, the YANG reporting should be done at the feature level. Also, does a distinction need to be made as to whether the IS-IS node supports the feature or both supports it and has it enabled (as would be the case for non-backward compatible features)? Thanks, Acee On Nov 16, 2023, at 15:30, Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> wrote: Loa - I agree with you that simply "IS-IS Support" may not be the best choice. Although, the meeting minutes have not yet been posted, as I recall my response to Tony Li's suggestion of "IS-IS Support" was "Yes - something like that." The draft authors have not yet discussed this - but we will and share the proposed new name. Other suggestions welcomed. Les -----Original Message----- From: Lsr <[email protected]<mailto:[email protected]>> On Behalf Of Loa Andersson Sent: Thursday, November 16, 2023 2:06 AM To: [email protected]<mailto:[email protected]> Subject: [Lsr] Question on draft-qgp-lsr-isis-pics-yang Working Group, During the presentation of draft-qgp-lsr-isis-pics-yang there was a rather strong opposition in the chat against using the ISO-term "PICS" in an IETF document. I think the term "Support" was suggested (excuse me if I missed something), but I'm not that impressed, and would rather like to see something like - "Supported Protocol Aspects". /Loa -- Loa Andersson email: [email protected]<mailto:[email protected]> Senior MPLS Expert [email protected]<mailto:[email protected]> Bronze Dragon Consulting phone: +46 739 81 21 64 _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!AmsjkBCy0yHxrbD6NS2ZmpxU8QbJxg2rUSNQ7npAzi3Fpg-37UalrnCrsfgORXyb1N_nJDZY85nfvI4k1HJU-lwx$> _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!AmsjkBCy0yHxrbD6NS2ZmpxU8QbJxg2rUSNQ7npAzi3Fpg-37UalrnCrsfgORXyb1N_nJDZY85nfvI4k1HJU-lwx$> _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!AmsjkBCy0yHxrbD6NS2ZmpxU8QbJxg2rUSNQ7npAzi3Fpg-37UalrnCrsfgORXyb1N_nJDZY85nfvI4k1HJU-lwx$> _______________________________________________ Lsr mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!AmsjkBCy0yHxrbD6NS2ZmpxU8QbJxg2rUSNQ7npAzi3Fpg-37UalrnCrsfgORXyb1N_nJDZY85nfvI4k1HJU-lwx$>
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
