< 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.
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.
- 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. Both RFCs 9352
and 9513 enabled the signaling of this anycast property of prefixes in
IS-IS and OSPFv3 - so, I am failing to understand what is the concern with
doing the same for OSPFv2 as well.
Thanks,
Ketan
--Bruno
*From:* [email protected] <[email protected]>
*Sent:* Friday, September 12, 2025 11:15 AM
*To:* [email protected]; DECRAENE Bruno INNOV/NET <
[email protected]>
*Cc:* [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 Acee, Bruno,
We have updated the draft according to your feedback. Please see the
diff :
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-anycast-flag-06.
Ketan has added the use-cases you were looking for, and we have also made
several improvements to the document's overall clarity and organization.
We would appreciate it if you could review this latest version.
Best regards,
Ran (on behalf of the co-authors)
Original
*From: *AceeLindem <[email protected]>
*To: *Ketan Talaulikar <[email protected]>;
*Cc: *Bruno Decraene <[email protected]>;lsr <[email protected]>;Dongjie
(Jimmy) <[email protected]>;Tony Przygienda <[email protected]>;
[email protected] <
[email protected]>;
*Date: *2025年08月30日 18:29
*Subject: [Lsr] Re: Working Group Adoption Poll for "Updates to Anycast
Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06*
Hey Ketan - You still need to respond to this.
Thanks,
Acee
On Aug 18, 2025, at 9:20 AM, Ketan Talaulikar <[email protected]
wrote:
Hi Acee,
I was away and hence the delay but I've now responded to the IPR poll.
Regarding the update, I don't think I got to it. Please give me some time to
dig into this and get back. Will work with co-authors to update/respond by next
week.
Thanks,
Ketan
On Thu, Aug 14, 2025 at 3:31 PM Acee Lindem <[email protected]
wrote:
Hi Ketan,
I still need your response to the WG last call IPR poll. Also, have you
completed your update to the document to address these comments.
Thanks,
Acee
On Apr 8, 2024, at 4:59 AM, Ketan Talaulikar <[email protected]
wrote:
Hi Bruno,
Apologies for the delay in response due to my time off. I may be slow in
response for a couple of weeks more and will need more time to update/rework
the draft based on the comments received.
Please check inline below for responses.
On Fri, Mar 22, 2024 at 7:46 PM <[email protected]> wrote:
Hi Ketan,
Top posting in effort to also take a step back.
I could understand the following sematic for the anycast flag: (beware) this
prefix may be an anycast prefix
KT> I would say "this prefix IS an anycast prefix" - the operator has
provisioned it as anycast and so the routers/controllers will consider the prefix as anycast.
In which case, this is an additional indication, it’s not mandated for any
existing behavior, existing behaviors are unchanged and routers needs to be
equally capable of handling anycast prefix which don’t have this AC-flag (just
like today).
Does this align with your objective?
KT> These "existing behaviors" that you refer to are not specified in any RFC and while I
am aware of some implementations that do so, we should be careful to not assume that these are
standards. The objective of this document is to simply standardize the Anycast flag that is introduced
in this document and that this is an indication provisioned by the operator. Anything more/further -
either related to use-cases or "existing behaviors" is outside the scope of this OSPFv2
specific document.
If so, I have the following comments:
“A prefix that is advertised by a single node and without an AC-flag MUST be
considered node specific.” (*2)
I disagree with this sentence which change the existing behavior and does not
align with the above semantic.
For prefix without the AC-flag, one has no new information compared to today
and the behavior should be unchanged.
The semantic is AC-flag set à anycast prefix (semantic is not: AC-flag unset à
prefix is unicasted)
KT> Please see my previous comment about anycast behavior. Also, the above text
has been published as RFC9352/9513 for ISIS and OSPFv3 - so I am afraid, but this
behavior has been standardized already. OSPFv2 with be consistent with the other
IGPs in this behavior.
“Both SR-MPLS prefix-SID and IPv4 prefix may be configured as anycast and as
such the same value can be advertised by multiple routers.”
Sorry I’m not familiar with OSPF, but ideally the semantic would be the same
for IS-IS. For IS-IS, multiple L1L2 routers (or ASBR) would typically advertise
the same prefix when those prefixes are redistributed from another area/domain.
My reading is that the advertisement of the same prefix by multiple ASBR/L1L2
routers does not qualify those prefix as anycast. Is that a correct
understanding?
KT> Yes, you are correct. This is not anycast. We can clarify this.
Regardless, I would welcome a clear definition of “anycast” in the context
of IGP. (for MPLS, I guess that we could say that a prefix is advertised by
multiple LERs but I’m not sure there is an equivalent term for IGP)
KT> It is the same IP address that is associated with and therefore originated
by those nodes.
Some minor comments:
“The AC-Flag MUST be preserved when re-advertising the prefix across areas. »
Ideally also across (IGP) redistribution. (I guess one could say that this
implementation specific but if we need the AC-flag we also need it across
domains)
KT> Agree.
A priori, removing the term “SR-MPLS” does not change the fact that the
AC-flag could be set on SR-MPLS SID. So the removal seem mostly cosmetic^W
editorial to me
😉
KT> The flag is set on the prefix and not the SID. It does get associated with
SID but ultimately it is the property of the prefix and not the SID.
Thanks,
Ketan
Thanks
--Bruno
From: Ketan Talaulikar <[email protected]>
Sent: Friday, March 22, 2024 3:30 AM
To: DECRAENE Bruno INNOV/NET <[email protected]>
Cc: Acee Lindem <[email protected]>; lsr <[email protected]>;
[email protected]; Dongjie (Jimmy) <
[email protected]>; Tony Przygienda <[email protected]>
Subject: Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property
advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
Hi Bruno,
Please check inline below with KT3.
On Thu, Mar 21, 2024 at 11:28 PM <[email protected]
wrote:
Hi Ketan,
Please see inline [Bruno2]
From: Ketan Talaulikar <[email protected]>
Sent: Thursday, March 21, 2024 4:19 PM
To: DECRAENE Bruno INNOV/NET <[email protected]>
Cc: Acee Lindem <[email protected]>; lsr <[email protected]>;
[email protected]; Dongjie (Jimmy) <
[email protected]>; Tony Przygienda <[email protected]>
Subject: Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property
advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
Hi Bruno,
Please check inline below with KT2 for responses.
On Thu, Mar 21, 2024 at 7:16 PM <[email protected]
wrote:
Hi Ketan,
Thanks for your quick reply.
Please see inline [Bruno]
From: Ketan Talaulikar <[email protected]>
Sent: Thursday, March 21, 2024 2:18 PM
To: DECRAENE Bruno INNOV/NET <[email protected]>
Cc: Acee Lindem <[email protected]>; lsr <[email protected]>;
[email protected]; Dongjie (Jimmy) <
[email protected]>; Tony Przygienda <[email protected]>
Subject: Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property
advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06
Hi Bruno,
Thanks for your feedback. Please check inline below for responses.
On Thu, Mar 21, 2024 at 4:12 PM <[email protected]
wrote:
Hi all,
I would also welcome a clear specification of the semantics.
Such that the meaning and implications are clear on both the originator and the
receivers/consumers.
e.g., from the originator standpoint:
- The originator MAY advertise the Anycast Flag if CONDITIONS1 are met (which
allow for some useful features such as….)
- The originator MUST advertise the Anycast Flag if CONDITIONS1 are met
(otherwise this breaks …)
Please specify the CONDITIONS1.
KT> Whether a prefix is anycast or not is configured by the operator. This
spec does not require implementations to detect that a prefix that it is
originating is also being originated from another node and hence may be an anycast
advertisement. We can clarify the same in the document.
[Bruno] As an operator, why would I configure this? What for? What are the
possible drawbacks? (i.e., can this be configured on all prefixes regardless of
their anycast status)
KT2> If anycast property is configured on all prefixes, then it is an
indication that none of those prefixes resolve to a unique node. That has
consequences in terms of usage. E.g., taking the TI-LFA repair path use-case, we
won't find the Node SID to be used to form the repair segment-list
