Hi Ran, Thanks - it looks good to me. Acee > On Aug 29, 2025, at 5:54 AM, [email protected] wrote: > > Hi Acee，Yingzhen, > We have uploaded a new version，please refer to the > link：https://datatracker.ietf.org/doc/html/draft-ietf-lsr-anycast-flag-04. > The attachment is the difference between the new version and the previous > version. > The new version has added a YANG section and updated the draft based on > Yingzhen's comments. The usecase-related content will be updated after > discussion with the author. Thanks. > > BR, > Ran > Original > From: AceeLindem <[email protected]> > To: 陈然00080434; > Cc: [email protected] > <[email protected]>;lsr > <[email protected]>;[email protected] <[email protected]>; > Date: 2025年08月27日 18:27 > Subject: [Lsr] Re: WG Group Last Call on "Updates to Anycast Property > advertisement for OSPFv2" - draft-ietf-lsr-anycast-flag-03 > Hi Ran, > Sounds good. > Thanks, > Acee > > > On Aug 27, 2025, at 2:20 AM, [email protected] wrote: > > > > Hi Acee， > > Thank you very much for requesting the YANG doctor review on our draft. > > I'll complete the addition of the YANG section to the draft this week. > > Regarding the anycast use case, I will follow up with Ketan next week to > > discuss and confirm the content. > > > > Best regards, > > Ran > > > > Original > > From: AceeLindem <[email protected]> > > To: [email protected] > > <[email protected]>; > > Cc: lsr <[email protected]>;Yingzhen Qu <[email protected]>; > > Date: 2025年08月27日 06:53 > > Subject: [Lsr] Re: WG Group Last Call on "Updates to Anycast Property > > advertisement for OSPFv2" - draft-ietf-lsr-anycast-flag-03 > > I've requested a YANG doctors review on this draft so it would be good if > > someone added the YANG section with the provided augmentations. > > > > I'm also hoping Ketan will finally add the use case for knowledge of > > whether or not a given prefix is an anycast address. > > > > Thanks, > > Acee > > > > > On Aug 25, 2025, at 7:07 PM, Acee Lindem <[email protected]> wrote: > > > > > > 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] > > > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > <draft-ietf-lsr-anycast-flag-04.diff.html>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
