< 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
