Hi Bruno, I've published version -02. Hopefully it addressed your comments.
As for RFC 8688, the L2 bundle member link attributes are applicable to more than just SR. This will be a separate YANG module. The question is whether to have it in the same draft with PICS for 8667 or a new draft. Thoughts? Thanks, Yingzhen On Wed, Jul 3, 2024 at 12:43 AM <[email protected]> wrote: > Hi Yingzhen, > > > > Thanks for you answer. > > Please see inline [Bruno] > > > > > > *From:* Yingzhen Qu <[email protected]> > *Sent:* Tuesday, July 2, 2024 8:08 PM > *To:* DECRAENE Bruno INNOV/NET <[email protected]> > *Cc:* Les Ginsberg (ginsberg) <[email protected]>; > [email protected]; [email protected] > *Subject:* Re: draft-qgp-lsr-isis-pics-srmpls-yang-01 > > > > *CAUTION* : This email originated outside the company. Do not click on > any links or open attachments unless you are expecting them from the > sender. > > *ATTENTION* : Cet e-mail provient de l'extérieur de l'entreprise. Ne > cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de > connaitre l'expéditeur. > > > > Hi Bruno, > > > > Thanks for the review and comments. This is very helpful. > > > > As I mentioned during my presentation of the drafts, the level of details > specified in the model is very important and subjective. We really need > people, especially with operational experiences of the feature, to provide > us feedback. > > [Bruno] Thanks > > > > Please see my answers below. > > > > Thanks, > > Yingzhen > > > > > > On Tue, Jul 2, 2024 at 9:28 AM <[email protected]> wrote: > > Hi authors, all > > Thanks for the draft. I would support its progression. (and we want more > PICS drafts 😉 ) > > I've quickly read the draft. Please find below some comments. > > > " +--ro prefix-sid-sub-tlv-support? isis-pics:support" > > I think that it would be good to have the detail on a per TLV basis (TLVs > 135, 235, 236, 237). > Especially as some implementations are partial (e.g., support IPv4 but not > IPv6) > > [Yingzhen]: I understand an implementation may not support multi-topology, > so the prefix-sid sub-tlv is not included in TLV 235 and 237. However, for > IPv4 (TLV135) and IPv6 (TLV236), isn't the "i-bit" and "v-bit" in the SR > capability enough? > > > > [Bruno] My understanding is that the V-flag advertises a dataplane > capability. e.g., as a guess, the ability for the router to process an > “IPv6 Explicit NULL Label” (which could for example be added below an IPv4 > Prefix SID). > > While prefix-sid-sub-tlv-support is a control plane capability (mapping a > FEC to a label) > > I would assume that all router supporting IPv6 (and MPLS) would support > the V-flag. On the other hand, some router supporting IPv6 were not > supporting IPv6 prefix SID. At least in the early days, but I would assume > this may not have changed. > > > > To some extent, same comment for the adj_SID TLVs. > > I would also propose to explicit the support of the flags. > May be using the flag numbers for currently undefined flags. > Again, some implementations do not support all flags. (e.g., V and L > flags. However for those ones it's a bit more tricky as some implementation > may support a single value (e.g. unset for some flags and set for some > others flags) > > [Yingzhen]: Totally agree with you, the support of the flags is indeed > tricky. Also it's hard to pick what flags to be included in the model. I > personally don't think it's a good idea and useful to include all flags. I > actually once did this and decided to remove the flags, as I feel too much > information is not very useful. However, I agree with adding some flag > support if these flags are considered important. As you see I included > i-bit and v-bit. > > > > [Bruno] ok. Looks reasonable and I agree with you > > For prefix-SID: > > I guess the E and P flags are supported by all implementations as they are > associated with “MUST”. (OTOH I tend to be occasionally negatively > surprised by implementations not supporting MUST. A typical example would > be with RFC3107. They would still claim being compliant with RFC though…) > > V/L-flags support is a MUST. But the support of “1”/set is optional and > would impact interop. So may be reporting the ability to set each (to 1). > Now, both flags are not independent (cf §2.1.1.1) so probably reporting a > single PICS (e.g., prefix-sid-flag-L-set-support. > > > > BTW, as a “naming” question, do we need to add the “-support” suffix to > all PICS? Very open question as I don’t have an opinion. May be factoring > it to the parent hierarchy? isis-pics-sr-mpls-support > > > > > +--ro sid-label-binding-tlv-support? isis-pics:support > > This TLV has multiple usages. Originally to advertise Binding SIDs but > this has been removed from the RFC. Currently for Mapping Server and for > Mirror SID. So there would be a need to distinguish usages for > implementations which may support one but not the other(s). > > > > [Yingzhen]: Good point. I will add a distinction for these two usages. > > > > [Bruno] Thanks. > > > > Also for mapping server, I think some implementations had split this into > 2 separates features: reception of the TLV and emission (MS configuration). > Given that implementations have (had?) this level of details, PICS probably > also needs it. > > [Yingzhen]: I will add support for mapping server: sending and receiving, > or receiving only. > > > > [Bruno] Excellent, thanks. > > > > > Thanks for having included the support of SR capability flags as they > advertise a significant feature (IPv6 support) and some implementations may > not support it. > > What about adding rfc8668 in the scope (L2 bundle). Not as priority for me > so I won't insist but this could easily be in the scope of this document. > > [Yingzhen]: I will look at this and see whether to include it in the same > module or have a separate module. > > > > [Bruno] Perfect. > > > > Thanks Yingzhen > > > Editorial: > * In yang descriptions, > - sometimes "tlv" is used, sometimes "TLV" is used. Consistency would > probably be better. RFC 8667 uses TLV. > - I would have a personal preference to add the Type number. E.g. > :s/Support of prefix-sid sub-tlv/Support of prefix-sid sub-tlv (Type 3). > > * The list of authors of the model does not match the list of authors of > the draft. > * The document does not seem to use RFC2119 keywords. So may be this > boilerplate section is not needed. > > > > [Yingzhen]: I'll upload a new version soon and address these editorial > issues. > > > > Thanks, > Regards, > --Bruno > > Orange Restricted > > -----Original Message----- > From: Les Ginsberg (ginsberg) <[email protected]> > Sent: Thursday, June 27, 2024 6:34 PM > To: [email protected] > Cc: [email protected]; [email protected]; > [email protected] > Subject: [Lsr] WG Adoption Call for PICS Drafts > > > -------------------------------------------------------------------------------------------------------------- > CAUTION : This email originated outside the company. Do not click on any > links or open attachments unless you are expecting them from the sender. > > ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez > pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre > l'expéditeur. > > -------------------------------------------------------------------------------------------------------------- > > WG Chairs - > > The authors of: > > https://datatracker.ietf.org/doc/draft-qgp-lsr-isis-pics-srmpls-yang/ > https://datatracker.ietf.org/doc/draft-qgp-lsr-isis-pics-yang/ > > request WG adoption for these two drafts. > > Thanx for your prompt attention to this request. > > Les (on behalf of the draft authors) > > > > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > ____________________________________________________________________________________________________________ > 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. > > ____________________________________________________________________________________________________________ > 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] To unsubscribe send an email to [email protected]
