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

[Peter Psenak <[e-mail]>]

Tony,

there are two use cases:

1. Your application wants to exclude address that is anycast - an 
example of where this can be used internally by IGP is a TI-LFA or 
uloop, when picking up the address of the node over which we want to do 
the enforcement. There is a N bit as well, but in case there is no 
address with the N-bit, you want to exclude anycast addresses.

2. Your application want to use only anycast addresses - inter-domain 
SRTE with anycast address for ASBRs. SRTE is using the IGP topology 
provided by BGP-LS.

BTW, the A-bit exists in ISIS and OSPFv3. We are just filling the gap 
with this draft.

thanks,
Peter



On 20/03/2024 17:44, Tony Przygienda wrote:
> 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.

please see the TI-LFA, uloop use case that is internal to IGP.


> 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
>