Hi Peter, Ok but why is this a property of an IP prefix and not a SID (considering TI-LFA examples). Both are a bit different things wouldn't you agree ?
Btw in your example this seems not even property of a prefix ... this is property of the interface (ie. all IPv4 or IPv6 prefixes configured under loopback 0 will be marked as ACs )? 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 > > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
