Hi Yingzhen,
Thank you very much for your valuable comments, and we have added the YANG
section and updated all editorial issues according to your feedback. Please see
the link:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-anycast-flag-04. Usecase
section will be updated after discussion with the authors. Please see the
following answer for your qustion.
BR,
Ran
Original
From: YingzhenQu <[email protected]>
To: Acee Lindem <[email protected]>;
Cc: lsr <[email protected]>;[email protected]
<[email protected]>;
Date: 2025年08月26日 03:24
Subject: [Lsr] Re: WG Group Last Call on "Updates to Anycast Property
advertisement for OSPFv2" - draft-ietf-lsr-anycast-flag-03
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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.
Ran: Agreed. Thanks.
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].
Ran: Looks good. Thanks.
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.
Ran: Agreed. Thanks.
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.
Ran: Agreed. Thanks.
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?
Ran: The purpose of the "MUST" is to ensure backward compatibility.
Here's a example:
Old Router (B) advertises an anycast prefix without an AC-flag because it
doesn't support it.
New Router (A) receives the prefix from B. How does Router A know if this is a
anycast prefix (from an old router) or a regular node-specific prefix?
The "MUST" rule solves this by forcing New Router A to follow this logic:
Rule: If a prefix is advertised by only a single source and lacks the AC-flag,
a new router MUST assume it is a node-specific prefix.
nit: AC-flag is used for the first time in the document without any explanation.
Ran: An explanation has been added. Thanks.
113 3. Updates to Anycast Property advertisement for OSPFv2
Please consider: OSPFv2 Anycast Property Advertisement
Ran: Agreed.Thanks.
120 prefix, and it has been defines the below flags(see "OSPFv2 Extended
s/it has been defines/it has defined
Ran: Agreed. Thanks.
142 When the prefix is configured as anycast, the AC-Flag SHOULD be set.
s/the prefix/a prefix
Ran: Forgot to update. Noted, will update in version 05. Thanks.
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.
Ran: Please see 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.
Ran: Many thanks. Updated to the draft.
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]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
