Hi Jürgen，
Many thanks for your review! Please see inline...
BR，
Ran
Original
From: JürgenSchönwälderviaDatatracker <[email protected]>
To: [email protected] <[email protected]>;
Cc: [email protected]
<[email protected]>;[email protected]
<[email protected]>;[email protected] <[email protected]>;
Date: 2025年11月20日 20:41
Subject: draft-ietf-lsr-anycast-flag-08 ietf last call Opsdir review
Document: draft-ietf-lsr-anycast-flag
Title: OSPFv2 Anycast Property Advertisement
Reviewer: Jürgen Schönwälder
Review result: Has Issues
I have reviewed draft-ietf-lsr-anycast-flag-08. I have ticked "has
issues" since there is no "I have questions" choice - and what follows
may just show my lack of familiarity with OSPF.
While the abstract clearly states the purpose of the document
('defines a new flag in the OSPFv2 Extended Prefix TLV Flags to
advertise the anycast property'), the introduction does not really do
that but it goes right into technical details before stating the
purpose of the document. (And as a first time reader, I was not sure
why all these details matter - but more on that later). Anyway, this
is entirely stylistic.>Ran：I believe the Introduction section follows the
standard logical progression
typical of IETF RFC introductions: it first presents the problem statement,
then
introduces the relevant background, and finally states the draft's purpose.
I was not sure what the N-bit is, which is discussed in section 2. I
guess routing people know the N-bit by heart but for the less informed
reader, it may help to spell out what it is and where it is defined.
Perhaps also explain why it is a bad idea to set both the N-bit and
the new AC-flag. It seems that the words 'bit' and 'flag' are used
interchangeably here, but perhaps refer to things defined as -bit
always as bit and things defined as -flag always as flag? Again, this
is stylistic.
>Ran：I appreciate the recognition. The N-flag reference citation will be added.
section2:
Original content: The AC-flag and the N-bit MUST NOT both be set. If both
N-flag and AC-flag are set,
the receiving routers MUST ignore the N-flag.
Updated content: The AC-flag and the N-flag (section 2.1 of [RFC7684]) MUST NOT
both be set.
If both N-flag and AC-flag are set, the receiving routers MUST ignore the
N-flag.
While searching for the definition of the N-bit, I ended up looking
into RFC 9513 and I found that there is also an AC-bit define where I
spotted an N-bit. Since this I-D also defines an AC-flag, can this
name clash lead to confusion? I guess I am bit lost on the context as
I am not deeply familiar with OSPF specifications. I guess this is
what the text in the introduction tried to explain. So probably it all
makes sense but on first read I did not get it. Anyway, what happens
to the older AC bit, is it they still needed? Can there be situations
where AC-bit and AC flag come together and may disagree?
>Ran：The AC-bit defined in [RFC 9513] is carried within the OSPFv3 Prefix
>Options field.
This means its scope is strictly limited to the OSPFv3 protocol. It cannot be
utilized by OSPFv2.
Conversely, the AC-flag defined in this draft is introduced specifically for
the OSPFv2 protocol
(carried in the OSPFv2 Extended Prefix TLV Flags field).
The new YANG leaf 'anycast-flag' is augmenting an ospf interface. The
description says "Sets the prefix as an anycast address." Is it clear
which prefix is meant?
>Ran：The prefix meant is the interface address's prefix
From an operational perspective, what is the effect of setting the
AC-flag on an anycast address versus not setting it (which is likely
the current behavior)?
>Ran：The prefix is explicitly identified as anycast, regardless of
the number of advertising nodes. This simplifies the forwarding logic.
Not setting the flag forces routers to rely on implicit discovery (checking
the LSDB for multiple identical prefixes), which is less efficient and prone to
loss of the anycast property across area boundaries.
Does setting this flag cause other routers to
change their behavior?
>Ran：
Supported Routers: Yes. Routers that support the AC-flag will use it to
apply new, optimized anycast-specific behaviors (e.g., excluding the prefix
from
TI-LFA calculations).
Unsupported Routers: No. Unsupported routers will simply ignore the new
AC-flag,
treating the prefix based on existing OSPF rules.
What should an operator do if some of the
routers support the new AC-flag but others don't?
>Ran：The network supports mixed deployment. Operators do not need special
procedures. Unsupported routers will ignore the flag, and supported routers
will
utilize it. The new feature can be deployed incrementally._______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
