Hi Gunter & Acee，
A new version that addresses all comments has been uploaded. The link is
:https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-extended-flags/.
Thanks!
Best Regards,
Ran
From: AceeLindem <acee.i...@gmail.com>
To: 陈然00080434;
Cc: gunter.van_de_ve...@nokia.com
<gunter.van_de_ve...@nokia.com>;draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org
<draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org>;lsr <lsr@ietf.org>;
Date: 2025年01月19日 01:50
Subject: [Lsr] Re: [Shepherding AD review] review of for
draft-ietf-lsr-ospf-prefix-extended-flags-04
See two inlines.
> On Jan 18, 2025, at 11:26 AM, <chen....@zte.com.cn> <chen....@zte.com.cn>
> 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 <acee.i...@gmail.com>
> To: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>;
> Cc: draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org
> <draft-ietf-lsr-ospf-prefix-extended-fl...@ietf.org>;lsr <lsr@ietf.org>;
> 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 -- lsr@ietf.org
> To unsubscribe send an email to lsr-le...@ietf.org
> Gunter - thanks for the review and comments. See inline.
> Authors - please address.
>
>> On Jan 17, 2025, at 06:26, Gunter van de Velde (Nokia)
>> <gunter.van_de_ve...@nokia.com> 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 -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
_______________________________________________
Lsr mailing list -- lsr@ietf.org
To unsubscribe send an email to lsr-le...@ietf.org
