router isis 1
interface Loopback0
prefix-attributes anycast
Thx,
R.
On Thu, Sep 18, 2025 at 5:00 PM Peter Psenak <[email protected]> wrote:
Robert,
On 18/09/2025 15:51, Robert Raszuk wrote:
> Hi Ketan,
>
> One comment from me on your statement:
>
>> *The AC-flag simply indicates that the prefix has been
configured as
> anycast - i.e. originated by multiple routers.*
>
> IMO making any assumption and therefore any actions just based
on the
> configuration is fundamentally a bad design. The prefix may have
been
> configured as anycast 1 hour ago on two nodes, but since then
only one node
> is active and only one node is advertising it.
Anycast is a property of the prefix that operator decided on. It is a
hint to the other routers not to use this prefix for certain
things as
this prefix may be advertised by multiple routers and it is not a
misconfiguration. How many routers are advertising the prefix is
irrelevant, and it may vary over the time.
thanks,
Peter
>
> So how useful is such a flag ? It is only confusing. Treat this
as my
> comment in respect to such flag in OSPFv2, OSPFv3 or ISIS.
>
> Thx,
> Robert
>
>
>
> On Wed, Sep 17, 2025 at 2:20 PM Ketan Talaulikar
<[email protected]>
> wrote:
>
>> < 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
