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 <[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
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
