Re: [Lsr] Working Group Adoption Poll for "Updates to Anycast Property advertisement for OSPFv2" - draft-chen-lsr-anycast-flag-06

[Robert Raszuk <[e-mail]>]

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 <[e-mail]>
wrote:

> Hi Bruno,
>
> Please check inline below with KT2 for responses.
>
>
> On Thu, Mar 21, 2024 at 7:16 PM <[e-mail]> wrote:
>
>> Hi Ketan,
>>
>>
>>
>> Thanks for your quick reply.
>>
>> Please see inline [Bruno]
>>
>>
>>
>> *From:* Ketan Talaulikar <[e-mail]>
>> *Sent:* Thursday, March 21, 2024 2:18 PM
>> *To:* DECRAENE Bruno INNOV/NET <[e-mail]>
>> *Cc:* Acee Lindem <[e-mail]>; lsr <[e-mail]>;
>> [e-mail]; Dongjie (Jimmy) <
>> [e-mail]>; Tony Przygienda <[e-mail]>
>> *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 <[e-mail]> 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 <[e-mail]> *On Behalf Of *Tony Przygienda
>> *Sent:* Wednesday, March 20, 2024 5:44 PM
>> *To:* Acee Lindem <[e-mail]>
>> *Cc:* Ketan Talaulikar <[e-mail]>; Dongjie (Jimmy) <
>> [e-mail]>; lsr <[e-mail]>;
>> [e-mail]
>> *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 <[e-mail]> wrote:
>>
>> Hi Ketan,
>>
>>
>>
>> On Mar 20, 2024, at 12:07, Ketan Talaulikar <[e-mail]>
>> 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 <[e-mail]> wrote:
>>
>>
>>
>> > On Mar 20, 2024, at 11:17 AM, Ketan Talaulikar <[e-mail]>
>> 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 <[e-mail]>
>> 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) <[e-mail]>
>> 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 <[e-mail]> On Behalf Of Acee Lindem
>> > > Sent: Wednesday, March 20, 2024 4:43 AM
>> > > To: lsr <[e-mail]>
>> > > Cc: [e-mail]
>> > > 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
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/lsr
>> >
>>
>>
>>
>> _______________________________________________
>> Lsr mailing list
>> [e-mail]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>