Hi Bruno,
Please check inline below with KT3.
On Fri, Sep 19, 2025 at 6:22 PM <[email protected]> wrote:
Hi Ketan,
Thanks for your reply. We are definitely progressing.
Please see inline [Bruno2]
*From:* Ketan Talaulikar <[email protected]>
*Sent:* Thursday, September 18, 2025 7:46 PM
*To:* DECRAENE Bruno INNOV/NET <[email protected]>
*Cc:* [email protected]; [email protected]; [email protected];
[email protected]; [email protected];
[email protected]
*Subject:* Re: [Lsr] Re: Working Group Adoption Poll for "Updates to
Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
Hi Bruno,
Thanks for your responses and clarifications. Please check inline for
responses with KT2.
On Thu, Sep 18, 2025 at 9:49 PM <[email protected]> wrote:
Hi Ketan,
Thank for your quick answer.
Please see inline [Bruno]
*From:* Ketan Talaulikar <[email protected]>
*Sent:* Wednesday, September 17, 2025 2:18 PM
< as a co-author >
Hi Bruno,
Please check inline below.
On Wed, Sep 17, 2025 at 2:15 PM <[email protected]> wrote:
Thanks Acee, Chen, Ketan,
Thanks for the addition and clarification.
· Ketan has added the use-cases you were looking for
I’m not looking for use-cases.
KT> Thanks. We've got another comment from the RTGDIR reviewer (Jeffrey)
to take the use-cases out. We (authors) will take that section on use-cases
out unless we get feedback to retain/keep that section.
I was looking, and I’m still looking for a normative definition of the
semantic associated to the anycast signaling. In particular:
· What are the required conditions for the node advertising the AC flag
KT> Sec 1 says "An IP prefix may be configured as anycast and as such
the same value can be advertised by multiple routers."
· What are the properties that may be used by the nodes reading the AC
flag.
KT> Just the part that the prefix may be originated by more than one node
and does not uniquely identify a single node.
[Bruno] OK. Can this be indicated in the text?
Note also that the semantic seems very different than the “anycast”
semantic defined in RFCs 9352, 9513, 9402 as the latter defined “anycast”
as functionally equivalent. I fear that having multiple flags with the same
name ‘anycast’ and different semantics may be confusing for the future.
KT2> Yes, we can add that in the text. This document cannot get into
other functional aspects as it is only introducing this flag/property and
nothing else.
[Bruno2] OK. Works for me. Could you please specify the text that you
want to add? I have in mind something like “The only meaning of the AC-flag
is that the prefix is intended to be advertised by multiple nodes.”
KT3> That text works for me. Thanks.
You seem to refer to RFCs 9352, 9513, 9402. But those RFCs have specific
text about those conditions/properties, while your document does not.
e.g.
“All the nodes advertising the same anycast locator MUST instantiate the
exact same set of SIDs under that anycast locator.”
https://datatracker.ietf.org/doc/html/rfc9352#name-advertising-anycast-propert
https://datatracker.ietf.org/doc/html/rfc9513#name-advertisement-of-anycast-pr
“Within an anycast group, all routers in an SR domain MUST advertise the
same prefix with the same SID value.”
https://datatracker.ietf.org/doc/html/rfc8402
· I’m looking for a similar text in your document. And if you want to
make it general (encompassing SR-MPLS, SRv6, MPLS without SR, IP without
SR…), the definition also needs to be general.
KT> This document is simply advertising the property of the prefix and
nothing else. Therefore, it cannot make general statements about other
things. Those other documents also specified other aspects (SRv6 Locators,
SRv6 SIDs, and Prefix SIDs) and so could say more.
What’s worse, your definition/use of the anycast flag seems to be
different from the one in the above RFCs:
· Above RFC uses anycast as a “positive” signaling. i.e., one may use
this anycast prefix/segment because the next segment/header will be
consistently used on all the anycast nodes. In particular, the TI-LFA PLR
may use those anycast prefix.
KT> I am not sure which text in existing RFCs says that anycast prefix
may be used by the TI-LFA PLR in its repair path.
[Bruno] Not strictly an answer to your TI-LFA point, but related to
protection RFC 8402 says:
An Anycast segment or Anycast-SID enforces the ECMP-aware shortest-
path forwarding towards the closest node of the anycast set. This is
useful to express macro-engineering policies or protection
mechanisms.
KT2> Ah I see. I read the "protection" part to be more like an egress
protection scheme where anycast segments are used for the multihomed PE or
such scenarios.
[Bruno2] ack. (note that “protection” is used in the abstract of TI-LFA,
so in the absence of precision I read this as any type of protection)
[…]
Within an anycast group, all routers in an SR domain MUST advertise
the same prefix with the same SID value.
https://datatracker.ietf.org/doc/html/rfc8402#section-3.3
· Your draft seems to use anycast as a “negative” signaling. i.e., don’t
use this prefix as it’s anycast and next segment/header may not be
consistent. Quoting your usecase “Hence, only node segments (with or
without the N-flag) and not anycast segments (with the AC-flag) are to be
used for TI-LFA repair paths.”
KT> I do not follow this connotation of positive or negative here. Some
use-cases will look for and use anycast segments while others will avoid
using them. The AC-flag simply indicates that the prefix has been
configured as anycast - i.e. originated by multiple routers.
[Bruno] With my current understanding
· RFCs 9352, 9513, 8402 says: this SID/prefix advertised by multiple
routers is anycast and may be treated as functionally equal. Next
SID/header will have the same meaning on all nodes.
· This document says: this prefix advertised by multiple routers is
anycast and can’t be treated as functionally equal. Next SID/header may
have different meaning on all nodes.
KT2> Can you please help me with where you are reading that
interpretation from this document? Since this document is not introducing
any functional properties, it should not be talking about functional
equivalence or non-equivalence.
[Bruno2] “Not introducing any functional properties” is precisely the
text what I found was missing in the document, and which distinguish it
from the “anycast” meaning in RFC 8402, 9352, 9513. I believe you have
agreed to add this precision in the text.
I’m reading the interpretation that the anycast nodes are not
functionally equivalent from the following sentences
The selection of anycast prefix segments advertised by those nodes for
the TI-LFA repair path may result in loops as the traffic may get rerouted
to another node advertising the same anycast segment. Hence, only node
segments (with or without the N-flag) and not anycast segments (with the
AC-flag) are to be used for TI-LFA repair paths.
BTW this could be read as a change of TI-LFA RFC hence an UPDATE. I
understood that this use-case would be removed, in which case no
specification is saying that TI-LFA MUST NOT use prefix with AC-flag.
KT3> First, we are removing the use cases as previously agreed to, so all
that text goes away. I don't think this document should update the TI-LFA
spec and that spec is not wrong - it just uses a different wording.
Regardless, the point is that during TI-LFA computation, we pick nodes
and/or links that form the repair path and then pick the SIDs that will
ensure the packets will stay on that path. When anycast SID belonging to a
node on the repair path is picked, there is a possibility that the packet
goes to another node advertising the same (anycast) SID. That is about it
