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