In general having knobs for every little feature, especially when backward compatible is undesirable. In this case, when backward compatible, not having a knob seems the most desirable. (at least from implementor perspective a knob must be tested (positive and negative testing) and costs surprisingly many resources to test it properly for no apparent reason when backward compatible)
G/ -----Original Message----- From: Acee Lindem <acee.i...@gmail.com> Sent: Thursday, April 3, 2025 4:15 PM To: Ketan Talaulikar <ketant.i...@gmail.com> Cc: mohamed.boucad...@orange.com; chen....@zte.com.cn; i...@ietf.org; draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org; lsr-cha...@ietf.org; lsr <lsr@ietf.org> Subject: Re: [Lsr] Mohamed Boucadair's Yes on draft-ietf-lsr-ospf-prefix-extended-flags-06: (with COMMENT) CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Ketan, I don't think mandating a configuration knob for a TLV is a good idea at all. As everyone working on routing protocols knows, TLVs are fully backward compatible and ignored by implementations that don't support them. We're not moving existing flags from other OSPF encodings to this TLV so there is no reason for a configuration knob. This is not to say that if there ever were a flag corresponding to a non-backward compatible feature wouldn't require a feature level knob. However, the issues MUST not be confused. We have three Routing ADs, do any of you disagree with me? Thanks, Acee > On Apr 3, 2025, at 9:35 AM, Ketan Talaulikar <ketant.i...@gmail.com> wrote: > > 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 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-chairs@ietf.o > rg <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-chairs@ietf.o > rg <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 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 while for OSPFv2 it > was specified in 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
