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<mailto: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<mailto:chen....@zte.com.cn> <chen....@zte.com.cn<mailto:chen....@zte.com.cn>> Envoyé : mardi 1 avril 2025 12:05 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Cc : acee.i...@gmail.com<mailto:acee.i...@gmail.com>; i...@ietf.org<mailto:i...@ietf.org>; draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org<mailto:draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org>; lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; lsr@ietf.org<mailto: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<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> To: 陈然00080434;acee.i...@gmail.com<mailto:00080434%3bacee.i...@gmail.com> <acee.i...@gmail.com<mailto:acee.i...@gmail.com>>; Cc: i...@ietf.org<mailto:i...@ietf.org> <i...@ietf.org<mailto:i...@ietf.org>>;draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org<mailto:draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org> <draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org<mailto:draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org>>;lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org> <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>>;lsr@ietf.org<mailto:lsr@ietf.org> <lsr@ietf.org<mailto: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<mailto:chen....@zte.com.cn> <chen....@zte.com.cn<mailto:chen....@zte.com.cn>> Envoyé : jeudi 27 mars 2025 09:07 À : acee.i...@gmail.com<mailto:acee.i...@gmail.com>; BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Cc : i...@ietf.org<mailto:i...@ietf.org>; draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org<mailto:draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org>; lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>; lsr@ietf.org<mailto: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<mailto:acee.i...@gmail.com>> To: Mohamed Boucadair <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>; Cc: The IESG <i...@ietf.org<mailto:i...@ietf.org>>;draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org<mailto:draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org> <draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org<mailto:draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org>>;lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org> <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>>;lsr <lsr@ietf.org<mailto: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<mailto: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
