Gunter, all, Thank you for the constructive discussion on this I-D. I think that we can park this point.
Looking forward seeing the new version with all the other agreed changes. Cheers, Med > -----Message d'origine----- > De : Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com> > Envoyé : jeudi 3 avril 2025 16:38 > À : Acee Lindem <acee.i...@gmail.com>; Ketan Talaulikar > <ketant.i...@gmail.com> > Cc : BOUCADAIR Mohamed INNOV/NET <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> > Objet : RE: [Lsr] Mohamed Boucadair's Yes on draft-ietf-lsr-ospf- > prefix-extended-flags-06: (with COMMENT) > > > 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > datatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5706%23section- > 3.4&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C19733850731e48 > d05dd108dd72bd29bd%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63 > 8792878946964391%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI > lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 > D%7C0%7C%7C%7C&sdata=w9C9EJpuPg0aHF8QbzeKK%2BhumWJRHA3lJ8dLQOfk6rI > %3D&reserved=0 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > datatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5706%23section- > 3.4&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C19733850731e48 > d05dd108dd72bd29bd%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63 > 8792878946986574%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI > lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 > D%7C0%7C%7C%7C&sdata=8FKZGGtSlUaANBE4DdMxCvG29oACWtc2np%2B4iq8y7Ak > %3D&reserved=0 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > datatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8362%23section- > 6.3&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C19733850731e48 > d05dd108dd72bd29bd%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63 > 8792878946996430%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI > lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3 > D%7C0%7C%7C%7C&sdata=gT%2Fr2dtTmHmTHTzP7D1PbYayQZ%2FS5SUDgckQee%2B > qf4Q%3D&reserved=0 while for OSPFv2 it was specified in > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F > datatracker.ietf.org%2Fdoc%2Fhtml%2Frfc3630%23section- > 2.3.2&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C19733850731e > 48d05dd108dd72bd29bd%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C > 638792878947005551%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWU > sIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D > %3D%7C0%7C%7C%7C&sdata=G%2FOl8Z0o%2Fh2M6F5RwxjReTSZNHWBDmC9ERGCfTq > LX2k%3D&reserved=0 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. ____________________________________________________________________________________________________________ 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
