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 > > # 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 > > ## 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]. > " > > 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 > > > 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 > > 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? > GV> should there be a logging in addition to the assumption that the NOT > transmitted bit is set to zero? > 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. > " > > 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. > " > > 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. Thanks, Acee > > GV> Should in addition of being ignored a logging/trap be sent to indictae > that something too long was received for processing? > > 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. > > 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]
