Hi, Isn't this knowledge gone outside of the local area when ABR does summarization ? If so, is this really practically useful ?
Thx, R. On Thu, Mar 21, 2024 at 4:19 PM Ketan Talaulikar <[email protected]> wrote: > 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. > > >> 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? > > >> >> >> 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. > > >> 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. 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. > > >> >> >> >> >> >> >> 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 ;-) >> >> >> >> >> >> 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. >> >> >> >> >> >> 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. > > >> >> >> >> >> 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? :-) > > 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. >> >> _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
