Hi Acee, Med and I discussed this and he feels it would be good to have a control knob for this sub-TLV origination (i.e., uber control over all flags that might be introduced in it) in a future OSPF YANG augmentation. We have differing opinions, however, I will leave this to your judgement.
Thanks, Ketan On Wed, Apr 2, 2025 at 9:44 PM Ketan Talaulikar <ketant.i...@gmail.com> wrote: > Hi Med, > > I can't claim to speak for the WG or for my co-authors, but I don't think > we want to go down the path of having control knobs for all and sundry > protocol encodings (especially when they don't have any backward > compatibility impact). I am very much on board with providing operators > controls, but for features that they would like to enable/disable. > > Perhaps we can just agree to disagree on this one? > > Thanks, > Ketan > > > On Wed, Apr 2, 2025 at 8:04 PM <mohamed.boucad...@orange.com> wrote: > >> Re-, >> >> >> >> Thanks, Ketan. >> >> >> >> Your proposed change to the Unrecognized TLVs and sub-TLVs part works for >> me. >> >> >> >> The only remaining point is: >> >> > >> >> > ## Should we have configuration parameters to control the use of the flags >> > (e.g., rfc8362#appendix-A)? >> >> No. Configuration will be described in the future documents that define the >> bits. >> >> >> *[Med] I was not referring to the individual flags, but to the function >> introduced in this spec. Please refer to the guidance at: >> https://datatracker.ietf.org/doc/html/rfc5706#section-3.4 >> <https://datatracker.ietf.org/doc/html/rfc5706#section-3.4> * >> >> *Ran1 : By default, this Sub-TLV is not sent unless the corresponding >> bit needs to be transmitted. The receiver can handle it based on its own >> capabilities. This draft does not specifically require the addition of a >> control mechanism.* >> >> *[Med] The case I have in mind is when upgrading the network with a mix >> of capable and non-capable routers. I’d like to control when the extended >> flags can be used, hence the control knob raised in my comment.* >> >> KT> The extended flags sub-TLV is an encoding and not a functionality. >> Hence, does not require a control knob - especially given that the protocol >> has built-in mechanism to ignore (parse over) unknown/unrecognized >> encodings. The control knobs may come into play for specific bits that >> future documents may introduce. >> >> >> >> >> >> I guess by functionality you refer to the meaning that is associated with >> a flags. Glad to hear that control knobs will be defined for those, but for >> the upgrade listed above, I’m concerned by the lack of global control. For >> example, disabling sending globally the extended flags is more optimal than >> going and disabling sending each flag (that would be defined in the future). >> >> >> >> Cheers, >> >> Med >> >> >> >> *De :* Ketan Talaulikar <ketant.i...@gmail.com> >> *Envoyé :* mercredi 2 avril 2025 15:49 >> *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> >> *Cc :* chen....@zte.com.cn; acee.i...@gmail.com; i...@ietf.org; >> draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org; lsr-cha...@ietf.org; >> lsr@ietf.org >> *Objet :* Re: [Lsr] Re: Mohamed Boucadair's Yes on >> draft-ietf-lsr-ospf-prefix-extended-flags-06: (with COMMENT) >> >> >> >> >> >> < speaking as a co-author of this document > >> >> >> >> Hi Med, >> >> >> >> Please check inline below for response with KT >> >> >> >> >> >> On Wed, Apr 2, 2025 at 7:05 PM <mohamed.boucad...@orange.com> wrote: >> >> Hi Ran, >> >> >> >> Please see comments prefixes with *[Med] *inline. >> >> >> >> Striped parts that I think are resolved. Thank you. >> >> >> >> Cheers, >> >> Med >> >> >> >> *De :* chen....@zte.com.cn <chen....@zte.com.cn> >> *Envoyé :* mardi 1 avril 2025 12:05 >> *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> >> *Cc :* acee.i...@gmail.com; i...@ietf.org; >> draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org; lsr-cha...@ietf.org; >> lsr@ietf.org >> *Objet :* Re: [Lsr] Re: Mohamed Boucadair's Yes on >> draft-ietf-lsr-ospf-prefix-extended-flags-06: (with COMMENT) >> >> >> >> Hi Med, >> >> Sorry for late reply, please see inline... >> >> Best Regards, >> >> Ran >> >> Original >> >> *From: *mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> >> >> *To: *陈然00080434;acee.i...@gmail.com <acee.i...@gmail.com>; >> >> *Cc: *i...@ietf.org <i...@ietf.org>; >> draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org < >> draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org>;lsr-cha...@ietf.org < >> lsr-cha...@ietf.org>;lsr@ietf.org <lsr@ietf.org>; >> >> *Date: *2025年03月28日 00:55 >> >> *Subject: RE: [Lsr] Re: Mohamed Boucadair's Yes on >> draft-ietf-lsr-ospf-prefix-extended-flags-06: (with COMMENT)* >> >> Hi Ran, >> >> >> >> Thank you for the follow-up. >> >> >> >> Please see inline. >> >> >> >> Cheers, >> >> Med >> >> >> >> *De :* chen....@zte.com.cn <chen....@zte.com.cn> >> *Envoyé :* jeudi 27 mars 2025 09:07 >> *À :* acee.i...@gmail.com; BOUCADAIR Mohamed INNOV/NET < >> mohamed.boucad...@orange.com> >> *Cc :* i...@ietf.org; draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org; >> lsr-cha...@ietf.org; lsr@ietf.org >> *Objet :* Re: [Lsr] Re: Mohamed Boucadair's Yes on >> draft-ietf-lsr-ospf-prefix-extended-flags-06: (with COMMENT) >> >> >> >> >> >> Hi Med, >> >> Thank you for your review and support of this work. We appreciate your >> thoughtful comments and suggestions. >> >> We would also like to thank Acee for his valuable input. Please see >> inline... >> >> >> >> Original >> >> *From: *AceeLindem <acee.i...@gmail.com> >> >> *To: *Mohamed Boucadair <mohamed.boucad...@orange.com>; >> >> *Cc: *The IESG <i...@ietf.org>; >> draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org < >> draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org>;lsr-cha...@ietf.org < >> lsr-cha...@ietf.org>;lsr <lsr@ietf.org>; >> >> *Date: *2025年03月26日 08:57 >> >> *Subject: [Lsr] Re: Mohamed Boucadair's Yes on >> draft-ietf-lsr-ospf-prefix-extended-flags-06: (with COMMENT)* >> >> Speaking as document shepherd: >> >> Hi Med, >> >> See inline. >> >> >> > On Mar 25, 2025, at 4:28 AM, Mohamed Boucadair via Datatracker < >> nore...@ietf.org> wrote: >> > >> > Mohamed Boucadair has entered the following ballot position for >> > draft-ietf-lsr-ospf-prefix-extended-flags-06: Yes >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut this >> > introductory paragraph, however.) >> > >> > >> *..*.. >> >> >> > ## Not sure if this is assumed, but is it allowed that a group of bits >> (e.g., 2 >> > bits) may be allocated for one single purpose? >> The current description seems to >> > assume that flags will be allocated individually. >> >> This is not limited by the specification so if one were to define a Trid >> (i.e., 3 states), it could take 2 bits. >> >> However, the draft that defines this should deal with that. It need not be >> here. >> >> >> *[Med] I would add a mention about this.* >> >> >> >> *Ran1 : The flags defined in this draft may use either a single bit or >> multiple bits to represent a state, as determined by the specific >> requirements of the draft defining them. If needed, we can add a sentence >> to explicitly state this. Please let us know if this addresses your >> concern.* >> >> >> >> *[Med] Thanks for adding this.* >> >> >> >> > >> >> > ## Should we have configuration parameters to control the use of the flags >> > (e.g., rfc8362#appendix-A)? >> >> No. Configuration will be described in the future documents that define the >> bits. >> >> >> *[Med] I was not referring to the individual flags, but to the function >> introduced in this spec. Please refer to the guidance at: >> https://datatracker.ietf.org/doc/html/rfc5706#section-3.4 >> <https://datatracker.ietf.org/doc/html/rfc5706#section-3.4> * >> >> >> >> *Ran1 : By default, this Sub-TLV is not sent unless the corresponding bit >> needs to be transmitted. The receiver can handle it based on its own >> capabilities. This draft does not specifically require the addition of a >> control mechanism.* >> >> *[Med] The case I have in mind is when upgrading the network with a mix >> of capable and non-capable routers. I’d like to control when the extended >> flags can be used, hence the control knob raised in my comment.* >> >> >> >> KT> The extended flags sub-TLV is an encoding and not a functionality. >> Hence, does not require a control knob - especially given that the protocol >> has built-in mechanism to ignore (parse over) unknown/unrecognized >> encodings. The control knobs may come into play for specific bits that >> future documents may introduce. >> >> >> >> >> > # Section 3: MUST seems redundant with “Unrecognized TLVs and sub-TLVs are >> >> > ignored” stated in rfc8362#section-6 >> >> Ran：Thank you for your feedback. We discussed this sentence previously >> with Acee (one of the authors of RFC8362), Ketan, Gunter, and other >> authors, and reached a consensus on the approach. >> >> *[Med] Aaah, still the MUST is redundant with 8362, which governs this >> extension. You can simple update the text and say “per Section 6 of >> [RFC8362], ….” * >> >> *Ran1:Well,that was discussed before :). For OSPFv3 extended LSAs, this >> has been specified in the base specification here >> https://datatracker.ietf.org/doc/html/rfc8362#section-6.3 >> <https://datatracker.ietf.org/doc/html/rfc8362#section-6.3> while for >> OSPFv2 it was specified in >> https://datatracker.ietf.org/doc/html/rfc3630#section-2.3.2 >> <https://datatracker.ietf.org/doc/html/rfc3630#section-2.3.2> in the >> context of TE Opaque LSAs that has been inherited/followed by others >> including the RFC7684. Thanks!* >> >> *[Med] I still don’t follow the rationale here. We are not defining a new >> behavior as far as I know.* >> >> >> >> KT> Agree, it is not a new behavior. Perhaps >> >> >> >> An implementation that does not recognize the OSPFv2/OSPFv3 Prefix >> Attribute Flags Sub-TLV would ignore the Sub-TLV as per normal TLV >> processing operations (refer section 6.3 of [RFC3630] and section 2.3.2 of >> [RFC8362]). >> >> >> >> Thanks, >> >> Ketan >> >> >> >> ____________________________________________________________________________________________________________ >> 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
