Ran, Med, See inline.
> On Apr 1, 2025, at 6:05 AM, chen....@zte.com.cn wrote: > > 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.) > > > > > > Please refer to > > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > > > > for more information about how to handle DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-extended-flags/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Hi Ran, Detao, Peter, Ketan, and Liyan, > > > > Thank you for the effort put into this specification. This is an important > > piece of work. > > > > I definitely support this. I have some few comments that I’d like to be > > addressed, especially the first three comments and the comment in Section 3. > > > > # General > > > > ## Should we have a recommendation whether the remaining flags are assigned > > first vs. use of the sub-TLV? I think we need a guidance (not rigid, > > though). > > I don't even know what you mean by this question - I doubt the authors do. > >> Med, I assume your question is about whether, when someone wants to > >> allocate a new bit, they should first use the remaining bits in the > >> existing Options field or apply for a new bit in this sub-TLV. > Ran: Thanks. We will clarify it. > [Med] Thanks. > > > ## 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. I don't know why anyone would think otherwise. Here is the mother of all OSPF variable-length flag field specifications and this statement was not needed: https://www.rfc-editor.org/rfc/rfc7770.html#section-2.4 The OSPF variable-length flag fields are not like the bars in the Centurion Lounges where you can only get one drink at a time 😎 > > > > ## 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. We don't need or even want configuration for this. The TLV itself is fully backward compatible and the features that define flags will need to address backward compatibility in their respective documents. Thanks, Acee > > > > > ## (nit) Please use terms to be consistent with the use in RFC8362 (sub-TLV, > > etc.). > Ran: Sure. Thanks. > [Med] ACK > > > ## (nit) Use explicit references (with sections) to help readers to find > > where > > to look. > Ran: ACK. Thanks. > [Med] ACK > > > ## (nit) Be consistent with the IANA registry names > Ran: ACK. Thanks. > [Med] ACK > > > # Abstract: Please indicate that the sub-TLV applies for both versions > > > > OLD: > > Each OSPF prefix can be advertised with an 8-bit field to indicate > > specific properties of that prefix. However, all the OSPFv3 Prefix > > Options bits have already been assigned and only a few bits remain > > unassigned in the flags field of the OSPFv2 Extended Prefix TLV. > > > > This document solves the problem of insufficient prefix options bits > > by defining variable-length Prefix Attribute Flags Sub-TLV for OSPF. > > > > NEW: > > Each OSPF prefix can be advertised with an 8-bit field to indicate > > specific properties of that prefix. However, all the OSPFv3 Prefix > > Options bits have already been assigned and only a few bits remain > > unassigned in the flags field of the OSPFv2 Extended Prefix TLV. > > > > This document solves this problem by defining variable-length Prefix > > Attribute Flags sub-TLV for OSPF. This sub-TLV is applicable to OSPFv2 > > and OSPFv3. > Ran: ACK. Thanks. > [Med] Thanks > > > # Section 2: > > > > ## (nits) Fix several nits > > > > OLD: > > This document defines variable-Length Prefix Attribute Flags Sub-TLVs > > for OSPFv2 and OSPFv3. These Sub-TLVs specify the variable-flag > > fields to advertise additional attributes associated with OSPF > > prefixs i.e., the advertisement and processing of the existing fixed- > > size prefix attribute flags remains unchanged. > > > > NEW: > > This document defines variable-Length Prefix Attribute Flags sub-TLV > > for OSPFv2 and OSPFv3. Such Sub-TLV specifies the variable-flag > > fields to advertise additional attributes associated with OSPF > > prefixes. The advertisement and processing of the existing fixed- > > size prefix attribute flags remain unchanged. > Ran: ACK. Thanks. > [Med] Thanks > > > ## (nit) Add caption and call them in the text. For example, > > > > OLD: > > The format of OSPFv2/OSPFv3 Prefix Attribute Flags Sub-TLVs is: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > // Prefix Attribute Flags (Variable) // > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > NEW: > > The format of OSPFv2/OSPFv3 Prefix Attribute Flags sub-TLV is shown in > > Figure 1. > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > // Prefix Attribute Flags (Variable) // > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 1: Format of OSPFv2/OSPFv3 Prefix Attribute Flags Sub-TLV > Ran: ACK. Thanks. > [Med] Thanks. > > > ## I don’t parse what is meant by “defined prefix flags” in the following: > > > > CURRENT: > > Defined prefix flags that are not > > transmitted due to being beyond the transmitted length MUST be > > treated as being set to 0. > Ran: Defined prefix flags refers to a bit that is expected but not > advertised. Consider a scenario where a node wants the 64th bit to be 1 , but > only 32 bits of the flag are advertised to it. In this case, the status of > 64th bit is unknown, so we assume it is set to 0. I'll include an explanation > in the text. > [Med] Thank you. > > > # Should the event covered in this part be logged? > > > > CURRENT: > > When multiple instances of an OSPFv2/OSPFv3 Prefix Attribute Flags > > Sub-TLVs are received within the same TLV, an implementation MUST use > > only the first occurrence of the Sub-TLV and MUST ignore all > > subsequent instances of the Sub-TLV. > Ran: We propose that implementations may log this event with appropriate > rate-limiting, noting that RFC 9513 Section 7.1 and RFC 9352 Section 9 > currently do not provide explicit recommendations regarding logging for > similar TLVs/Sub-TLVs. > [Med] Log + rate-limit is definitely the right approach. > > (nit) Maybe better to reword as follows: > > > > NEW: > > When multiple instances of the OSPFv2/OSPFv3 Prefix Attribute Flags > > sub-TLV are received within the same TLV, an implementation MUST use > > only the first occurrence of the sub-TLV and MUST ignore all > > subsequent instances of the sub-TLV. > Ran: ACK. Thanks. > [Med] ACK > > > # 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! > > > CURRENT: > > The Prefix Attribute Flags Sub-TLVs defined in this document does not > > introduce any backward compatibility issues. An implementation that > > does not recognize the OSPFv2/OSPFv3 Prefix Attribute Flags Sub-TLV > > MUST ignore the Sub-TLV > > (nit) We may consider: s/The Prefix Attribute Flags Sub-TLVs defined in this > > document/The Prefix Attribute Flags sub-TLV does not > Ran: ACK. Thanks. > [Med] ACK > > > # Section 5: We may add subsections for each OSPF version to better organize > > the actions (and also avoid orphan subsections): > > > > OLD: > > 5.1. OSPFv2 Prefix Attribute Flags Sub-TLV Registry > > 5.1.1. OSPFv2 Prefix Extended Flags Field Registry > > 5.2. OSPFv3 Prefix Attribute Flags Sub-TLV Registry > > 5.2.1. OSPFv3 Prefix Extended Flags Field Registry > > > > NEW > > 5.1. OSPFv2 > > 5.1.1. OSPFv2 Prefix Attribute Flags Sub-TLV Registry > > 5.1.2. OSPFv2 Prefix Extended Flags Field Registry > > 5.2. OSPFv3 > > 5.2.1. OSPFv3 Prefix Attribute Flags Sub-TLV Registry > > 5.2.2. OSPFv3 Prefix Extended Flags Field Registry > Ran: ACK. Thanks. > [Med] ACK > > > # FWIW, the full review with other minor edits/nits can be found at: > > > > * pdf: > > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-lsr-ospf-prefix-extended-flags-06-rev%20Med.pdf > > * doc: > > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-lsr-ospf-prefix-extended-flags-06-rev%20Med.doc > > > > Feel free to grab whatever useful there. > Ran： Many thanks！ > > Best Regards， > Ran > > > Cheers, > > Med > > > > > > > > _______________________________________________ > Lsr mailing list -- lsr@ietf.org > To unsubscribe send an email to lsr-le...@ietf.org > > ____________________________________________________________________________________________________________ > 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
