Hi Robert, One quick response inline below with KT.
On Thu, Mar 21, 2024 at 10:37 PM Robert Raszuk <[email protected]> wrote: > Hi Ketan, > > That is my main point. So we define something which is only local to the > area. > > If this information will turn out to be very useful I am sure there is > going to be someone proposing to leak it :) Remember the UPA discussions ? > KT> Prefixes do get re-advertised (in OSPF we don't "leak" ;-)) across areas without necessarily being summarized. As mentioned, there is no discussion about summarization in this spec. Thanks, Ketan > > If so my real question is - should such information belong in IGP ? Or > maybe rather in DROID ( > https://datatracker.ietf.org/doc/html/draft-li-lsr-droid) ? > > Honestly I am still a bit struggling to understand the need for it. And > the draft is not very helpful ... > > > > * The prefix may be configured as anycast and it is useful for other > routers to know that the advertisement is for an anycast identifier.* > > or > > > > > > > > *2. Use-case In the absence of the N-flag, the node specific prefixes > need to be identified from the anycast prefixs. A prefix that is > advertised by a single node and without an AC-flag MUST be considered > node specific.* > > Especially the "use-case" looks to me like copy and paste error :) > > Thx, > Robert > > > On Thu, Mar 21, 2024 at 5:44 PM Ketan Talaulikar <[email protected]> > wrote: > >> Hi Robert, >> >> Summarization/aggregation does result in loss of individual prefixes' >> attributes. >> >> The draft does not intend to specify procedures for propagation of >> anycast attribute of individual prefixes to the summary since that is not >> something that is going to be robust. >> >> Thanks, >> Ketan >> >> >> On Thu, Mar 21, 2024 at 10:02 PM Robert Raszuk <[email protected]> wrote: >> >>> 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
