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<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> To: 陈然00080434;acee.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 <draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org<mailto:draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org>>;lsr-cha...@ietf.org <lsr-cha...@ietf.org<mailto:lsr-cha...@ietf.org>>;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 <draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org<mailto:draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org>>;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. > # 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. ____________________________________________________________________________________________________________ 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
