# 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 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. " 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. " 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. " 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]
