Re: [Lsr] Question on draft-qgp-lsr-isis-pics-yang

[Tony Przygienda <[e-mail]>]

per TLV may not be particularly good in lots of cases

1) some TLVs contain tons stuff which triggers all kind of "does that
support this" variants
2) most operators do not know ISIS TLV by heart but RFPs are basically
structured along RFCs so that's the resoluton I'm most concerned with

Generally, I think we will need a multi-axis representation or some kind of
groupings like "per RFC" for this to be easily consumable

I wouldn't know actually PICS belongs to ISO even, PICS was done under this
name in ATM as well (and called PICS Proforma, whatever the Proforma stood
for [ATM Forum was more test case oriented format], Joel will remember, he
was reading a lot of sci-fi paperbacks while we were hanging in there
around midnite while point by point was chewed ;-)

-- tony

On Fri, Nov 17, 2023 at 10:14 AM <[e-mail]> wrote:

>
>
>
>
>
>
> Orange Restricted
>
> *From:* Lsr <[e-mail]> *On Behalf Of *Acee Lindem
> *Sent:* Thursday, November 16, 2023 11:33 PM
> *To:* Les Ginsberg (ginsberg) <ginsberg=[e-mail]>
> *Cc:* Loa Andersson <[e-mail]>; [e-mail]
> *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) <
> ginsberg=[e-mail]> 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 <[e-mail]> On Behalf Of Loa Andersson
> Sent: Thursday, November 16, 2023 2:06 AM
> To: [e-mail]
> 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: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Bronze Dragon Consulting             phone: [phone]
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>