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. 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. >> >> >> > > [Bruno2] Given OSPFv2, by SR you mean SR-MPLS I guess. For TI-LFA, if >> > > you want a Node SID, why not simply picking a SID having the N flag. >> > > That’s its semantic. Also with SR-MPLS we don’t do much aggregation so >> > > I’m not sure to see use for prefix. (by prefix, I mean not a /32 address) >> >> > > KT3> Yes, that is why we had the N flag for that specific use case. I >> > > assume there are no concerns with the use of the N flag and its >> > > semantics. >> >> > > I would propose those points be discussed in the operation >> > > considerations section of this draft. >> > > In the absence of reason, this is not likely be configured IMHO. >> >> > > KT2> Sure. Thanks for that feedback. We can certainly do that in the >> > > draft. I hope this isn't blocking the adoption in your view though, >> > > right? >> >> > > [Bruno2] I haven’t asked for blocking the adoption. I asked for >> > > clearly specified semantic. >> > > e.g., from the receiver standpoint: >> >> > > What does this mean to have this Anycast Flag set? What properties are >> > > being signaled? (a priori this may be already specified by CONDITIONS1 >> > > above) >> >> > > KT> In addition to the previous response, for the receiver this means >> > > that the same prefix MAY be advertised from more than one node (that may >> > > be happening now or may happen in the future). This can be clarified as >> > > well. >> > > [Bruno] OK. If this is happening now, this is a priori already visible >> > > in the LSDB. >> >> >> > > KT2> This is tricky. If the prefix is originated in a different >> > > domain, it gets tricky to determine if the prefix is anycast or >> > > dual-homed since the LSDB has a local area/domain view. >> >> > > [Bruno2] Agreed for prefix. For Node-SID you have the N-flag. >> > > Regarding origination in another domain, would the ABR/L1L2 node be able >> > > to detect this and set the anycast flag by itself? >> >> > > KT3> It cannot if the case is of anycast originating from different >> > > domains/areas. >> >> > > Any reason to duplicate the info (I would guess that’s easier for >> > > implementation but since this is not guaranteed to be implemented one >> > > would need to also check in the LSDB. So doubling the work). >> >> > > KT2> This extension brings in simplicity for the receivers provided >> > > that operators can configure this property. >> >> > > [Bruno2] aka moving the complexity to the service provider. I guess >> > > you would not be surprised if I prefer the other way around (have >> > > computer do the job instead of humans, have vendors do the job rather >> > > than operator >> 😉 >> ) Configuring states and having to maintain/updates them forever is akin to >> a technical debt to me. >> >> > > KT3> Here, I think, we may have a point of disagreement. While it is >> > > outside the scope of this document, I hope we agree that there is a lot >> > > more involved in the configuration of anycast prefix and the >> > > service/use-case behind it. The Anycast property config provides a very >> > > small additional "state" to be provisioned as part of a larger anycast >> > > service/use-case provisioning. It allows the operator to robustly >> > > indicate this property of the prefix (they know it is anycast) via the >> > > IGP without requiring routers and applications to algorithmically figure >> > > this out (that might not always be correct). I think of it as a useful >> > > optional lego block in the set of IGP extensions. >> > > KT2> Like I mentioned above, this starts to get more complicated in >> > > multi-domain scenarios. Perhaps we can think of this as the complexities >> > > that we experience in determining this property via an LSDB/topology-db >> > > that motivate us to bring forth this easier and more robust way. >> >> > > Any specific reason requiring the knowledge of the future? >> >> > > KT2> Perhaps at time T1, there are two nodes originating the prefix. >> > > Then at time T2, one of them goes down (or becomes disconnected), do we >> > > assume that the prefix is now not anycast? Then what happens if that >> > > other node comes back up again. For certain use-cases where anycast >> > > prefix is not desired, it may be helpful to completely avoid use of this >> > > prefix. The operator knows their design and addressing and perhaps is >> > > able to provision this prefix property correctly from the outset. >> >> > > [Bruno2] I guess there could be such use cases. But a priori in the >> > > general case, when that other node come back 1) before IGP convergence >> > > nothing change from a routing standpoint, 2) during routing convergence >> > > you know about this other node and can do what you want. This includes >> > > updating your FRR protection. If this is really a concerned (to assume >> > > anycast status while it’s not certain) I find a sentence problematic in >> > > the draft “A prefix that is advertised by a single node and without an >> > > AC-flag MUST be considered node specific. ». TIn fact, the receiver does >> > > not know whether this is a node specific prefix or an anycast prefix >> > > advertised by a node not supporting this extension (or an operator not >> > > doing the right configuration). >> >> > > KT3> We have the N and the AC flag. If they are configured properly, >> > > then there is no ambiguity. But what if they are not? What if there is a >> > > prefix w/o either of the flags set and say for the use-case like TI-LFA >> > > we need to use that as a node identifier (because there is nothing else >> > > from that node). That is the ambiguity that we are trying to cover. Btw, >> > > that same text is there in RFC9352/9513 and therefore also in this >> > > document for consistency across the IGPs. >> > > If this is specific to SR, please say so. >> > > KT> It is not specific to SR, it is a property of an IP prefix. >> >> > > But even in this sub-case, SR anycast has some conditions, both for >> > > SR-MPLS and SRv6. >> >> > > KT> This document does not discuss either SR-MPLS or SRv6 anycast. It >> > > covers an OSPFv2 extension to simply advertise the anycast property of >> > > any IP prefix. The discussion of SR anycast belongs to some other >> > > (SPRING) document ;-) >> >> > > [Bruno2] I’m sorry but “SR-MPLS” is the second word in the abstract. So >> > > I believe this document covers SR-MPLS. IMO anything specific to SR-MPLS >> > > caused by this document should be covered in this document. >> >> > > KT3> That is a mistake that Les has also pointed out. We will fix that. >> > > >> > > SR-MPLS: https://datatracker.ietf.org/doc/html/rfc8402#section-3.3.1 >> >> >> > > “determining the second label is impossible unless A1 and A2 allocated >> > > the same label value to the same prefix.” >> > > “Using an anycast segment without configuring identical SRGBs on all >> >> > > nodes belonging to the same anycast group may lead to misrouting (in >> > > an MPLS VPN deployment, some traffic may leak between VPNs).” >> >> > > So for SR-MPLS, where we did not have anycast flag at the time, the >> > > burden of respecting the conditions seems to be on the receiver. In >> > > which case, Anycast flag didn’t seem to be required. >> >> > > KT> True. But that was also beyond the anycast property of the prefix >> > > - it also involves checking the Prefix SID associated with it (plus >> > > other considerations) and that is something quite different. >> >> > > [Bruno2] That’s about anycast SR-MPLS SID which is the scope of your >> > > document. >> > > KT3> Agree >> > > SRv6: >> https://datatracker.ietf.org/doc/html/rfc9352#name-advertising-anycast-propert >> >> > > “All the nodes advertising the same anycast locator MUST instantiate the >> > > exact same set of SIDs under that anycast locator. Failure to do so may >> > > result in traffic being dropped or misrouted.” >> > > >> >> > > So for SRv6 the burden is on the originator, and we felt the need to >> > > define an anycast flag. >> >> > > KT> Note that RFC9352 does not restrict the advertisement of anycast >> > > property of the prefix to SRv6. It applies to all IPv4/IPv6 prefixes - >> > > irrespective of SRv6, SR-MPLSv4, SR-MPLSv6 or plain old IP. This is the >> > > same for RFC9513 - since OSPFv3 supports IPv4/IPv6 prefixes as well as >> > > SRv6, SR-MPLSv4, and SR-MPLSv6. >> >> > > [Bruno] Indeed. And note that RFC9352 did specify some specific >> > > conditions (MUST) before a node may advertise this anycast flag. A >> > > priori there is a reason for this. A priori the same reason would apply >> > > to SR-MPLS, no? So why this sentence has not also been copied from >> > > RFC9352 and adapted for SR-MPLS? (the sentence is “All the nodes >> > > advertising the same anycast locator MUST instantiate the exact same set >> > > of SIDs under that anycast locator. Failure to do so may result in >> > > traffic being dropped or misrouted.”) >> >> > > KT2> You have a good point. All I can say is that RFC9352/9513 were >> > > focussed on SRv6 extensions and therefore covered only those aspects. >> > > This document is not an SR extension and I feel it is better that these >> > > aspects related to SR anycast (SR-MPLS or SRv6) are covered in a >> > > separate document in a more holistic manner. >> >> > > [Bruno2] On my side, speaking about holistic manner, I would a priori >> > > have a preference for the document defining the anycast flag to cover >> > > the anycast properties in an holistic manner. >> >> > > KT3> I understand your point of view. My view is that, the way >> > > existing RFCs stand, we cover only the base protocol semantics of >> > > anycast in this document and cover the overall SR anycast aspects in a >> > > separate (SPRING?) document such that it also covers those aspects for >> > > ISIS and OSPFv3. >> > > Interestingly, the conditions seem different… >> >> > > Authors seems to use RFC9352 and RFC9513 as a justification. I’m not >> > > familiar with OSPFv2 but my understanding is that it does not advertise >> > > SRv6 SID. So presumably there are some differences >> > > KT> I hope the previous responses clarify. >> > > “The prefix may be configured as anycast” >> >> > > Putting the burden on the network operator is not helping clarifying the >> > > semantic. We need the receivers/consumers and the network operators to >> > > have the same understanding of the semantic. (not to mention all >> > > implementations on the receiver side) >> > > KT> I hope again the previous responses have clarified. >> >> > > [Bruno] Not yet. Cf my first point about an operation considerations >> > > section. >> > > KT2> Ack for introducing operational considerations. >> > > So please specify the semantic. >> > > This may eventually lead to further discussion (e.g., on SR-MPLS) >> >> > > KT> That discussion is important and we've had offline conversations >> > > about that. However, IMHO, that is beyond the scope of this document and >> > > this thread. >> > > [Bruno] Too early to tell on my side. >> > > KT2> How about now? :-) >> >> > > [Bruno2] I’d say this discussion in this is in scope of this document. >> > > Another thread works for me. I picked that thread as I don’t usually >> > > read OSPF documents but have been convinced by Tony P.’s argument. >> >> > > In summary, I understand a bit more the point of view of this >> > > document. But I’m still concerned that different implementations could >> > > have a different reaction to this flag. For a link state protocol this >> > > seem possibly problematic. >> >> > > KT3> OK. Let me take a step back. The Anycast property of the prefix >> > > has been defined for 2 of the 3 IGPs - this document is covering that >> > > 3rd IGP. As authors, we have already shared the various updates that we >> > > have agreed to make to the document to clarify the semantics of the >> > > anycast property of a prefix in OSPFv2. We will continue to incorporate >> > > WG inputs should the document be adopted. However, as co-author, I do >> > > not agree that it is in the scope of this document to delve into the >> > > use-case (they are informative examples and so will be very brief about >> > > them in this document) and the document should also not delve into the >> > > broader SR anycast aspects. That later discussion belongs in SPRING. I >> > > will leave the adoption of the document with that proposed scoping to >> > > the WG decision. >> > > Thanks, >> > > Ketan >> > > Thanks >> > > --Bruno >> > > Thanks, >> > > Ketan >> > > Thanks, >> > > --Bruno >> > > Thanks, >> > > Ketan >> > > Thank you >> > > --Bruno >> > > From: Lsr <[email protected]> On Behalf Of Tony Przygienda >> > > Sent: Wednesday, March 20, 2024 5:44 PM >> > > To: Acee Lindem <[email protected]> >> > > Cc: Ketan Talaulikar <[email protected]>; Dongjie (Jimmy) < >> [email protected]>; lsr <[email protected]>; >> [email protected] >> >> > > Subject: Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast >> > > Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06 >> > > I think the draft is somewhat superfluous and worse, can generate >> > > completely unclear semantics >> >> > > 1) First, seeing the justification I doubt we need that flag. if the >> > > only need is for the SR controller to know it's anycast since it >> > > computes some paths this can be done by configuring the prefix on the >> > > controller itself. It's all centralized anyway. >> >> > > 2) OSPF today due to SPF limitations has a "baked-in weird anycast" >> > > since if prefixes are ECMP (from pont of view of a source) they become >> > > anycast, otherwise they ain't. I think the anycast SID suffers from same >> > > limi8ation and is hence not a "real anycast" (if _real anycast_ means >> > > something that independent of metrics balances on the prefix). Hence >> > > this draft saying "it's anycast" has completely unclear semantics to me, >> > > worse, possibly broken ones. What do I do as a router when this flag is >> > > not around but two instances of the prefix are ECMP to me? What do I do >> > > on another router when those two instances have anycast but they are not >> > > ECMP? What will happen if the ECMP is lost due to ABR re-advertising >> > > where the "flag must be preserved" . >> >> > > 3) There is one good use case from my experience and this is to >> > > differentiate between a prefix moving between routers (mobility) and >> > > real anycast. That needs however far more stuff in terms of timestamping >> > > the prefix. pascal wrote and added that very carefully to rift if there >> > > is desire here to add proper anycast semantics support to the protocol. >> >> > > So I'm not in favor in adopting this unless the semantic is clearly >> > > written out for this flag and the according procedures specified >> > > (mobility? behavior on lack/presence of flag of normal routers etc). >> > > Saying " >> >> > > It >> >> > > is useful for other routers to know that the advertisement is for an >> > > anycast identifier. >> > > " is not a use case or justification for adding this. >> > > if this is "anycast in case of SR computed paths that are not ECMP" >> > > then the draft needs to say so and call it "SR anycast" or some such >> > > stuff. If it is something else I'd like to understand the semantics of >> > > this flag before this is adopted. >> >> > > -- tony >> > > On Wed, Mar 20, 2024 at 5:10 PM Acee Lindem < >> [email protected]> wrote: >> > > Hi Ketan, >> > > On Mar 20, 2024, at 12:07, Ketan Talaulikar <[email protected] >> > wrote: >> > > Sure, Acee. We can take that on :-) >> > > I hope it is ok that this is done post adoption? >> > > Yup. I realize this is a simple draft to fill an IGP gap but I did ask >> > > the question below. Hopefully, we can get to WG last call quickly. >> >> > > Thanks, >> > > Acee >> > > Thanks, >> > > Ketan >> > > On Wed, Mar 20, 2024 at 9:35 PM Acee Lindem <[email protected] >> > wrote: >> > > >> > > >> > > > On Mar 20, 2024, at 11:17 AM, Ketan Talaulikar < >> [email protected]> wrote: >> > > > >> > > > Hi Acee/Jie, >> > > > >> >> > > > The most common users of the anycast property of a prefix are external >> > > > controllers/PCE that perform path computation exercises. As an >> > > > example, knowing the anycast prefix of a pair of redundant ABRs allows >> > > > that anycast prefix SID to be in a SRTE path across the ABRs with >> > > > protection against one of those ABR nodes going down or getting >> > > > disconnected. There are other use cases. An example of local use on >> > > > the router by IGPs is to avoid picking anycast SIDs in the repair >> > > > segment-list prepared for TI-LFA protection - this is because it could >> > > > cause an undesirable path that may not be aligned during the FRR >> > > > window and/or post-convergence. >> > > > >> >> > > > That said, since ISIS (RFC9352) and OSPFv3 (RFC9513) didn't have the >> > > > burden of this justification of an use-case, I hope the same burden >> > > > would not fall on this OSPFv2 document simply because it only has this >> > > > one specific extension. >> > > >> >> > > But they also weren't added in a draft specifically devoted to the >> > > Anycast flag. It would be good to list the examples above as potential >> > > use cases. >> > > >> > > >> > > Thanks, >> > > Acee >> > > >> > > >> > > >> > > > >> > > > Thanks, >> > > > Ketan >> > > > >> > > > >> > > > On Wed, Mar 20, 2024 at 8:16 PM Acee Lindem <[email protected] >> > wrote: >> > > > Hi Jie, >> > > > >> > > > I asked this when the flag was added to IS-IS and then to OSPFv3. I >> > > > agree it would be good to know why knowing a prefix is an Anycast >> > > > address is "useful" when the whole point is that you use the closest >> > > > one (or some other criteria). >> >> > > > >> > > > Thanks, >> > > > Acee >> > > > >> > > > > On Mar 20, 2024, at 9:09 AM, Dongjie (Jimmy) <[email protected] >> > wrote: >> > > > > >> > > > > Hi authors, >> > > > > >> > > > > I just read this document. Maybe I didn't follow the previous >> > > > > discussion, but it seems in the current version it does not describe >> > > > > how this newly defined flag would be used by the receiving IGP nodes? >> >> > > > > >> > > > > Best regards, >> > > > > Jie >> > > > > >> > > > > -----Original Message----- >> > > > > From: Lsr <[email protected]> On Behalf Of Acee Lindem >> > > > > Sent: Wednesday, March 20, 2024 4:43 AM >> > > > > To: lsr <[email protected]> >> > > > > Cc: [email protected] >> >> > > > > Subject: [Lsr] Working Group Adoption Poll for "Updates to Anycast >> > > > > Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06 >> > > > > >> > > > > >> > > > > This starts the Working Group adoption call for >> > > > > draft-chen-lsr-anycast-flag. This is a simple OSPFv2 maintenance >> > > > > draft adding an Anycast flag for IPv4 prefixes to align with IS-IS >> > > > > and OSPFv3. >> >> > > > > >> > > > > Please send your support or objection to this list before April 6th, >> > > > > 2024. >> >> > > > > >> > > > > Thanks, >> > > > > Acee >> > > > > >> > > > > >> > > > > _______________________________________________ >> > > > > Lsr mailing list >> > > > > [email protected] >> > > > > https://www.ietf.org/mailman/listinfo/lsr >> > > > >> > > _______________________________________________ >> > > Lsr mailing list >> > > [email protected] >> > > https://www.ietf.org/mailman/listinfo/lsr >> >> > > ____________________________________________________________________________________________________________ >> >> > > Ce message et ses pieces jointes peuvent contenir des informations >> > > confidentielles ou privilegiees et ne doivent donc >> >> > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> > > recu ce message par erreur, veuillez le signaler >> >> > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> > > electroniques etant susceptibles d'alteration, >> >> > > Orange decline toute responsabilite si ce message a ete altere, deforme >> > > ou falsifie. Merci. >> > > >> >> > > This message and its attachments may contain confidential or privileged >> > > information that may be protected by law; >> > > they should not be distributed, used or copied without authorisation. >> >> > > If you have received this email in error, please notify the sender and >> > > delete this message and its attachments. >> >> > > As emails may be altered, Orange is not liable for messages that have >> > > been modified, changed or falsified. >> > > Thank you. >> >> > > ____________________________________________________________________________________________________________ >> >> > > Ce message et ses pieces jointes peuvent contenir des informations >> > > confidentielles ou privilegiees et ne doivent donc >> >> > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> > > recu ce message par erreur, veuillez le signaler >> >> > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> > > electroniques etant susceptibles d'alteration, >> >> > > Orange decline toute responsabilite si ce message a ete altere, deforme >> > > ou falsifie. Merci. >> > > >> >> > > This message and its attachments may contain confidential or privileged >> > > information that may be protected by law; >> > > they should not be distributed, used or copied without authorisation. >> >> > > If you have received this email in error, please notify the sender and >> > > delete this message and its attachments. >> >> > > As emails may be altered, Orange is not liable for messages that have >> > > been modified, changed or falsified. >> > > Thank you. >> >> > > ____________________________________________________________________________________________________________ >> >> > > Ce message et ses pieces jointes peuvent contenir des informations >> > > confidentielles ou privilegiees et ne doivent donc >> >> > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> > > recu ce message par erreur, veuillez le signaler >> >> > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> > > electroniques etant susceptibles d'alteration, >> >> > > Orange decline toute responsabilite si ce message a ete altere, deforme >> > > ou falsifie. Merci. >> > > >> >> > > This message and its attachments may contain confidential or privileged >> > > information that may be protected by law; >> > > they should not be distributed, used or copied without authorisation. >> >> > > If you have received this email in error, please notify the sender and >> > > delete this message and its attachments. >> >> > > As emails may be altered, Orange is not liable for messages that have >> > > been modified, changed or falsified. >> > > Thank you. >> >> > > ____________________________________________________________________________________________________________ >> >> > > Ce message et ses pieces jointes peuvent contenir des informations >> > > confidentielles ou privilegiees et ne doivent donc >> >> > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> > > recu ce message par erreur, veuillez le signaler >> >> > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> > > electroniques etant susceptibles d'alteration, >> >> > > Orange decline toute responsabilite si ce message a ete altere, deforme >> > > ou falsifie. Merci. >> > > >> >> > > This message and its attachments may contain confidential or privileged >> > > information that may be protected by law; >> > > they should not be distributed, used or copied without authorisation. >> >> > > If you have received this email in error, please notify the sender and >> > > delete this message and its attachments. >> >> > > As emails may be altered, Orange is not liable for messages that have >> > > been modified, changed or falsified. >> > > Thank you. >> > >> >> _______________________________________________ >> Lsr mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> >> >> ____________________________________________________________________________________________________________ >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >> ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >> Thank you. >> >> _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
