Tony,
On 20/03/2024 18:51, Tony Przygienda wrote:
hmm, Peter, thanks for clarification but wasn't A the attach flag is
OSPF in 7684?
yes, here we define AC-flag.
In ISIS it's in the SR support draft and hence I would ask here as
well to somehow clarify that "this is for SR purposes" and call the
draft accordingly before we get it confused with today's semantics.
And possibly call the flag the "SR-anycast flag" or some such thing
that clarifies it does not have anything to do with "normal" OSPF
pseudo-anycast
the flag is independent of the SR. It's the property of how the prefix
is advertised, independent of the prefix having labels advertised for
it. I would prefer to keep it independent of the SR.
One can use the anycast as his BGP-NH for example to achieve load
balancing, which does not need any SR.
I buy your 2nd use case
I don't get the first, are we talking TI-LFA with SR only? because
otherwise it's a tunnel and hence doesn't matter whether it traversed
an anycast . So for me it looks like SR specific thing again.
that one is SR specific, but it does not mean another non SR use cases
can not exist.
thanks,
Peter
thanks
-- tony
On Wed, Mar 20, 2024 at 6:22 PM Peter Psenak <[email protected]> wrote:
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
