Speaking as WG member: Ok - I can see that I’m in the minority here in thinking this should be at a less granular level than specific TLVs. We can see where the more granular definition takes us and I’ll help with the OSPFv2/OSPFv3 models.
Hopefully, the enthusiasm for implementation will match our IGP protocol support modeling efforts. Thanks, Acee > On Nov 17, 2023, at 4:14 AM, [email protected] wrote: > > Orange Restricted > From: Lsr <[email protected]> On Behalf Of Acee Lindem > Sent: Thursday, November 16, 2023 11:33 PM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Loa Andersson <[email protected]>; [email protected] > Subject: Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang > 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. > [Bruno] +1 > I agree that the level of granularity is key. > I’d rather call for a significant granularity (but I’d welcome any pushback). > Personally, I don’t see why per TLV granularity would not be ok: it’s ok to > implement which is more work, so just listing the supported TLV and sub-TLV > should be doable. In any case, operators, pre-sales and support engineers > will likely need this information some day. So let’s just fill it once for > all and have it available for all persons. > I’d would even call for more granularity. E.g. for RFC 5130, for “32-bit > Administrative Tag Sub-TLV 1”, “On receipt, an implementation MAY consider > only one encoded tag, in which case, the first encoded tag MUST be considered > and any additional tags ignored. » > To me, if the WG bothered making such granularity at the > feature/TLV/implementation level, we need such granularity at the reporting > level. And that’s not theoretical, I had to check that for a project a month > ago. At best, it’s indicated in the vendors documentation, so the data is > there, so let’s make it friendly to digest. At worst, we need to involve > expensive people 😉. > If we want less granularity, let’s do less granularity in spec (everything is > MUST) > https://datatracker.ietf.org/doc/html/rfc5130#section-3.1 > Thanks, > --Bruno > 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]> 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]> On Behalf Of Loa Andersson > Sent: Thursday, November 16, 2023 2:06 AM > To: [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] > Senior MPLS Expert [email protected] > Bronze Dragon Consulting phone: +46 739 81 21 64 > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
