Hi Ran, Ketan,
> On Jan 25, 2025, at 23:37, [email protected] wrote:
>
> 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/>https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-extended-flags/.
>
> <https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-extended-flags/>
> Thanks!
>
I think this version is worse than the
1. Why did you add "**in OSPFv3**” to the introduction? You don’t see this
asterisk notation in other IETF documents. Just say “OSPFv3 Prefix Options, see
appendix A.4.1.1 in [RFC5340]”.
2. Why did you add TBD1 and TBD2? Just use the temporarily IANA assigned
values in section 2.1 and 2.2.
3. The text you added at the end of the Introduction is problematic. It is
much longer than it needs to be and is confusing. For OSPFv3, it almost implies
this new sub-TLV replaces the existing prefix options.
Ketan - can you rewrite this? I could do this myself but it seems there
is enough experience among the five attributed co-authors to write something
that makes sense.
Thanks,
Acee
>
> Best Regards,
>
> Ran
>
>
>
> From: AceeLindem <[email protected]>
> To: 陈然00080434;
> Cc: [email protected]
> <[email protected]>;[email protected]
> <[email protected]>;lsr <[email protected]>;
> 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, <[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]
>
>
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
