Hi Yingzhen, Thanks for you answer. Please see inline [Bruno]
From: Yingzhen Qu <yingzhen.i...@gmail.com> Sent: Tuesday, July 2, 2024 8:08 PM To: DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com> Cc: Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>; draft-qgp-lsr-isis-pics-srmpls-yang.auth...@ietf.org; lsr@ietf.org 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 <bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>> 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) <ginsberg=40cisco....@dmarc.ietf.org<mailto:40cisco....@dmarc.ietf.org>> Sent: Thursday, June 27, 2024 6:34 PM To: lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org> Cc: lsr@ietf.org<mailto:lsr@ietf.org>; draft-qgp-lsr-isis-pics-srmpls-yang.auth...@ietf.org<mailto:draft-qgp-lsr-isis-pics-srmpls-yang.auth...@ietf.org>; draft-qgp-lsr-isis-pics-yang.auth...@ietf.org<mailto:draft-qgp-lsr-isis-pics-yang.auth...@ietf.org> 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 -- lsr@ietf.org<mailto:lsr@ietf.org> To unsubscribe send an email to lsr-le...@ietf.org<mailto:lsr-le...@ietf.org> ____________________________________________________________________________________________________________ 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 -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
