Authors, Please add the YANG data module provided by Yingzhen to the draft. You can use https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-ls-link-infinity/ <https://datatracker.ietf.org/doct-ietf-lsr-ospf-ls-link-infinity/> as an example. Note that in addition to Section 5 there are additions required to the "Security Considerations" relative to the YANG data model.
Thanks, Acee > On Aug 25, 2025, at 3:23 PM, Yingzhen Qu <[email protected]> wrote: > > Hi, > > I've reviewed the document and have the following comments for the authors to > consider. > > How about changing the title of the document to "OSPFv2 Anycast Property > Advertisement"? > > 21 Each OSPF prefix is advertised along with an 8-bit field of > 22 capabilities, by using the flag flield in the OSPFv2 Extended Prefix > 23 TLV, but the definition of anycast flag to identify the IPv4 prefix > 24 as anycast has not yet been defined. > I don't think we need this in the Abstract. > > 90 The Flags field of the OSPFv2 Extended Prefix TLV (Section 2.1 of > 91 [RFC7684]) has 5 unassigned bits remaining (see "OSPFv2 Extended > 92 Prefix TLV Flags" IANA registry [IANA-OSPFv2-EPF]). > Suggested text: > The flags field of he OSPFv2 Extended Prefix TLV (Section 2.1 of > [RFC7684]) can be found in "OSPFv2 Extended > Prefix TLV Flags" IANA registry [IANA-OSPFv2-EPF]. > > 94 This document updates [RFC7684], by defining a new flag in the OSPFv2 > 95 Extended Prefix TLV Flags [RFC7684] to advertise the anycast property > 96 for an IPv4 prefix. > This document doesn't update RFC7684. > Suggested text: > This document defines a new flag in the OSPFv2 > Extended Prefix TLV Flags [RFC7684] to advertise the anycast property > for an IPv4 prefix. > > 106 2. Use-case > > 108 In the absence of the N-flag, the node specific prefixes need to be > 109 identified from the anycast prefixs. A prefix that is advertised by > 110 a single node and without an AC-flag MUST be considered node > 111 specific. > The use case needs to be collaborated with more details. > Question: > "A prefix that is advertised by a single node and without an AC-flag MUST be > considered node specific." > I don't understand this sentence. Router A supporting what's defined in this > document may receive advertisement from Router B which doesn't support > AC-flag. Router B will advertise an anycast prefix without AC-flag. What > difference will this "MUST" do? > nit: AC-flag is used for the first time in the document without any > explanation. > > 113 3. Updates to Anycast Property advertisement for OSPFv2 > Please consider: OSPFv2 Anycast Property Advertisement > > 120 prefix, and it has been defines the below flags(see "OSPFv2 Extended > s/it has been defines/it has defined > > 142 When the prefix is configured as anycast, the AC-Flag SHOULD be set. > s/the prefix/a prefix > > 155 A prefix that is advertised by a single node and without an AC-flag > 156 MUST be considered node specific prefix. > same question as above. > > I'm attaching a YANG module and its tree. The module adds the ac-flag > definition and configuration of a prefix as anycast. Please let me know if > you have any questions. > > Thanks, > Yingzhen > > > > On Thu, Aug 14, 2025 at 2:59 AM Acee Lindem <[email protected]> wrote: > LSR WG, > > This begins a 2-week WG last call on draft-ietf-lsr-any-flag-03. Please > indicate your support or objection to this list prior to Friday, August 29h, > 2025. > > Thanks, > Acee > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] > <ietf-ospf-anycast-flag.yang><ietf-ospf-anycast-flag.tree> _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
