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. 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? 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. > > +--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. > 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. > > 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. > > 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. >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
