Hi Yingzhen, Thank you. Looks good to me.
--Bruno From: Yingzhen Qu <[email protected]> Sent: Thursday, July 4, 2024 6:57 AM To: DECRAENE Bruno INNOV/NET <[email protected]> Cc: Les Ginsberg (ginsberg) <[email protected]>; [email protected]; [email protected] Subject: [Lsr] 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, 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]<mailto:[email protected]>> wrote: Hi Yingzhen, Thanks for you answer. Please see inline [Bruno] From: Yingzhen Qu <[email protected]<mailto:[email protected]>> Sent: Tuesday, July 2, 2024 8:08 PM To: DECRAENE Bruno INNOV/NET <[email protected]<mailto:[email protected]>> Cc: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>> Sent: Thursday, June 27, 2024 6:34 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[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. ____________________________________________________________________________________________________________ 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]
