See two inlines. > On Jan 18, 2025, at 11:26 AM, <[email protected]> <[email protected]> > wrote: > > Hi Acee， > Thank you so much for your help in answering questions. I truly appreciate it. > > Hi Gunter， > I really appreciate your review of the draft，and it’s especially valuable. > > Please see the details inline... > > Original > From: AceeLindem <[email protected]> > To: Gunter van de Velde (Nokia) <[email protected]>; > Cc: [email protected] > <[email protected]>;lsr <[email protected]>; > Date: 2025年01月17日 20:31 > Subject: [Lsr] Re: [Shepherding AD review] review of for > draft-ietf-lsr-ospf-prefix-extended-flags-04 > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Gunter - thanks for the review and comments. See inline. > Authors - please address. > >> On Jan 17, 2025, at 06:26, Gunter van de Velde (Nokia) >> <[email protected]> wrote: >> >> # Gunter Van de Velde, RTG AD, comments for >> draft-ietf-lsr-ospf-prefix-extended-flags-04 >> # the referenced line numbers are derived from the idnits tool: >> >> https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lsr-ospf-prefix-extended-flags-04.txt >> >>Ran: The next version will address the idnits. Thanks. >> # Many thanks for this document. It addresses and proposes a solution >> for a limited resource in OSPF. >> #GENERIC COMMENTS >> #================ >> ## Easy to understand document. Well written. Nearly ready to >> progress. My comments are mostly editorial. I did suggest a single BCP14 >> (must => MUST) change >> >>Ran: Sure. Thanks.## Maybe be more specific to identify t he LSAs where >> >>this new flags subTLV can be applied (see detailed comments). >> #DETAILED COMMENTS >> #================= >> 81 Each OSPF prefix is advertised with an 8-bit options field, >> using the >> 82 Prefix Options [RFC5340] and the flag field in the OSPFv2 >> Extended >> 83 Prefix TLV [RFC7684]. However for OSPFv3, all the Prefix >> Options >> 84 bits have already been assigned, and for OSPFv2, at the time >> of >> 85 writing, only 4 bits remain undefined in the OSPFv2 Extended >> Prefix >> 86 TLV. >> GV> for "using the Prefix Options [RFC5340]" I would of expected to see a >> reference to OSPFv2 prefix options. >> What about fixing with adding **in OSPFv3** as follows: >> " >> Each OSPF prefix is advertised with an 8-bit options field, using the >> Prefix Options [RFC5340] **in OSPFv3** and the flag field in the OSPFv2 >> Extended >> Prefix TLV [RFC7684]. >> " >> >>Ran: Sure. Thanks.GV> It would be helpful to be more explicit to >> >>identify in the introduction which LSAs have these TLV's as subTLV's. >> Maybe add more explicit info in introduction: >> eg. opaque lsa --> prefix-tlv --> prefix-options >> extended to opaque lsa --> prefix-tlv --> Prefix Attribute Flags Sub-TLVs >> >>Ran: Sure. We will work on adding clearer details in the introduction to >> >>ensure better understanding. >> 168 Length: Variable, dependent on the included Prefix Attribute >> Flags. >> 169 This indicates the length of the value portion in bytes. The >> length >> 170 MUST be a multiple of 4 octets. >> GV> What happens if the length is not a multiple of 4 octets? Should >> handling be prescribed in this document? >> GV> same observation for OSPFv3 >> >>Ran: I believe that if a sub-TLV is recognized but its length is not a >> >>multiple of 4 octets, the LSA should be considered malformed. I will add >> >>it. >> >> 179 Bits that are NOT transmitted MUST be treated as if they are >> set to 0 >> 180 on receipt. >> GV> I am confused. What is meant with a NOT transmitted Bit? How does >> recipient know or find out that a particular bit is not transmitted? >> >>Ran: "a NOT transmitted Bit" 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.
I didn't find this confusing but perhaps I'm too close to it. Maybe you could just say "Defined prefix flags that are not transmitted due to being beyond the transmitted length MUST...". >> >> GV> should there be a logging in addition to the assumption that the NOT >> transmitted bit is set to zero? >> >>Ran: Logging is necessary, I will add it. >> >> GV> same observation for OSPFv3 > > Definitely, there should be logging. We could ignore the Sub-TLV completely > in this case. > > >> 228 The Extended Flags field is a variable-length multiple of >> 32-bits >> 229 with flags allocated from starting with the most significant >> bit. >> 230 The bits in the Extended Flags field will be assigned in future >> 231 documents. This document does not define any flags. >> Unrecognized >> 232 flags in the Prefix Attribute Flags Sub-TLVs for OSPFv2 and >> OSPFv3 >> 233 must be forwarded without modification. Specifically, the >> entire >> 234 flag field must be copied unchanged into outgoing messages, >> 235 regardless of whether the implementation recognizes all the >> flags. >> GV> Slight rewording and one instance of BCP14 language added >> " >> The Extended Flags field is a variable-length field in multiples of >> 32 bits, with bits allocated as flags starting from the most significant >> bit. Future documents will assign these bits; this document does not define >> any flags. Unrecognized flags in the Prefix Attribute Flags Sub-TLVs for >> OSPFv2 and OSPFv3 MUST be forwarded without modification. Specifically, the >> entire flag field MUST be copied unchanged into outgoing messages, regardless >> of whether the implementation recognizes any or all flags. > Sure. >> >> >> >>Ran: Sure. >> " >> 237 Implementations MUST handle variable-length Prefix Attribute >> Flags >> 238 Sub-TLVs and beyond the flags field length supported MUST be >> ignored. >> " >> Implementations MUST handle variable-length Prefix Attribute Flags Sub-TLVs. >> Any portion of the field beyond the length supported by the >> implementation MUST be ignored. > > Sure. >> >> >> >>Ran: Sure. >> 240 An OSPFv2 router receiving multiple OSPFv2 Prefix Attribute >> Flags >> 241 Sub-TLVs in the same OSPFv2 Extended Prefix TLV MUST use the >> first >> 242 advertisement of this Sub-TLV and MUST ignore all remaining >> instances >> 243 of the Sub-TLV. >> " >> An OSPFv2 router receiving multiple OSPFv2 Prefix Attribute Flags Sub-TLVs in >> the same OSPFv2 Extended Prefix TLV MUST use only the first occurrence of the >> Sub-TLV and MUST ignore all subsequent instances of that Sub-TLV. >> " > > I’ll point out that we have the existing text in a number of documents. > However, basically you just added “only” and changed “remaining” to > subsequent. > >>Ran: Many thanks to acee for bringing this to our attention. I believe that > >>changing 'remaining' to 'subsequent' and adding 'only' were done to improve > >>clarity. While the core meaning stays the same, this revision aims to make > >>the language more precise and align it better with similar guidelines in > >>the document." I agree. Thanks, Acee > > Thanks, > Acee > > >> GV> Should in addition of being ignored a logging/trap be sent to indictae >> that something too long was received for processing? >> >>Ran: I don't think logging is necessary, but I'm open to further >> >>discussion if needed. >> >> 245 An OSPFv3 router receiving multiple OSPFv3 Prefix Attribute >> Flags >> 246 Sub-TLVs in a subsuming TLV MUST use the first advertisement of >> the >> 247 Sub-TLV and MUST ignore all remaining instances of the Sub-TLV >> in the >> 248 subsuming TLV. " >> Similarly, an OSPFv3 router receiving multiple OSPFv3 Prefix Attribute Flags >> Sub-TLVs >> within a subsuming TLV MUST use only the first occurrence of the Sub-TLV and >> MUST >> ignore all subsequent instances in that subsuming TLV. >> " >> 270 6. IANA Considerations >> GV> I suspect a cleanup confusion happened with early allocations. I see >> the TBD1 and TBD2 in the body of the text but not referenced in the IANA >> section. >> 166 Type: TBD1. >> 201 Type: TBD2. >> I suspect that TBD1 = 11 and that TBD2 = 37? Could this be clarified. >> >>Ran: I agree that further clarification is needed. I will include TBD1=11 >> >>and TBD2=37 in the IANA section. >> Once again, I truly appreciate both of you. >> Best Regards, >> Ran >> >> >> Many thanks again for this document, >> Kind Regards, >> Gunter Van de Velde, >> RTG AD > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
