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]
