[Lsr] Protection between flex-algo topologies

[Robert Raszuk <[e-mail]>]

/* As this departs from ip-flexalgo topic adjusting the subject line */

Hi Les,

I am not so much focusing on fallback just making sure I did not miss any
paragraph or draft which already would describe how to provide protection
in other then on a per topology basis.

Yes, fallbacks are tricky if you relax constraints. To put it in better
perspective fallbacks are easy for overlays. For underlays they may work
(as mentioned to Peter under unidirectional single protect constraint). But
"may work" perhaps is too weak.

Your suggestion to add fallback links to topologies with higher metric is
actually pretty cool. I did not think about it so having this little thread
seems already fruitful :)

But that still requires you to run computations for your favourite LFA type
multiple times (topo by topo) even if those algorithms only different in
some additional non forwarding related processing functions (different
function per slice basis). Speaking of which it seems that the ability to
specify per flex-algo additional processing on packets could have valid use
cases. But forwarding wise the topologies can be identical.

In such cases it seems that it could be very useful to still recognize in a
control plane the uniqueness while a data plane would be common. It looks
to me like we have all pieces of the puzzle here and all what is needed is
to rearrange it a bit.

What do you think ?

Thx,
Robert


On Wed, May 18, 2022 at 9:39 PM Les Ginsberg (ginsberg) <[e-mail]>
wrote:

> Robert –
>
>
>
> It isn’t clear to me why you are focused on “fallback” as a solution here.
>
> If you are willing to allow traffic that prefers the “Algo-X topology” to
> use other paths in the event of link/node failures, it seems
> straightforward – using the new metrics being defined in
> https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo-bw-con/ - to
> include other links in the Algo-X topology and apply a high cost to them so
> they won’t be used unless the more preferred links are  unavailable.
>
>
>
> I think you and I both have some experience with “fallback”. It is complex
> to implement – especially in the forwarding plane – and would not be my
> first choice as a solution.
>
>
>
> ??
>
>
>
>     Les
>
>
>
>
>
> *From:* Lsr <[e-mail]> *On Behalf Of * Robert Raszuk
> *Sent:* Tuesday, May 17, 2022 10:58 AM
> *To:* Peter Psenak (ppsenak) <[e-mail]>
> *Cc:* lsr <[e-mail]>
> *Subject:* Re: [Lsr] Publication has been requested for
> draft-ietf-lsr-ip-flexalgo-06
>
>
>
> Hi Peter,
>
>
>
> Enabling local protection on all nodes in all topologies may also not be
> the best thing to do (for various reasons).
>
>
>
> While I agree that general fallback may be fragile, how about limited
> fallback and only to one special "protection topology" which would have few
> constraints allowing us to do such fallback safely ?
>
>
>
> I guess for ip flex-algo which is a subject of this thread this would not
> be possible, but for SR flex-algo I think this may work pretty well
> allowing N:1 fast connectivity restoration.
>
>
>
> Thx,
>
> Robert
>
>
>
> On Tue, May 17, 2022 at 2:19 PM Peter Psenak <[e-mail]> wrote:
>
> Robert,
>
> On 17/05/2022 14:14, Robert Raszuk wrote:
> > Ok cool - thx Peter !
> >
> > More general question - for any FlexAlgo model (incl. SR):
> >
> > Is fallback between topologies - say during failure of primary one -
> > only allowed on the ingress to the network ?
>
> no. Fallback between flex-algos has never been a requirement and is not
> part of the flex-algo specification.
>
> I consider it a dangerous thing to do. It may work under certain
> conditions, but may cause loops under different ones.
>
> thanks,
> Peter
>
>
> >
> > If so the repair must be setup on each topology, otherwise repair will
> > be long as it would need to wait for igp flooding and ingress switchover
> > trigger ?
> >
> > Obviously for IP flex algo it would be much much longer as given prefix
> > needs to be completely reflooded network wide and purged from original
> > topo. Ouch considering time to trigger such action.
> >
> > Many thanks,
> > R.
> >
> > On Tue, May 17, 2022, 13:35 Peter Psenak <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     Hi Robert,
> >
> >
> >     On 17/05/2022 12:11, Robert Raszuk wrote:
> >      >
> >      > Actually I would like to further clarify if workaround 1 is even
> >     doable ...
> >      >
> >      > It seems to me that the IP flexalgo paradigm does not have a way
> for
> >      > more granular then destination prefix forwarding.
> >
> >     that is correct. In IP flex-algo the prefix itself is bound to the
> >     algorithm.
> >
> >      >
> >      > So if I have http traffic vs streaming vs voice going to the same
> >     load
> >      > balancer (same dst IP address) there seems to be no way to map
> some
> >      > traffic (based on say port number) to take specific topology.
> >
> >     no, you can not do that with IP flex-algo.
> >
> >
> >      >
> >      > That's pretty coarse and frankly very limiting for applicability
> >     of IP
> >      > flex-algo. If I am correct the draft should be very
> >     explicit about this
> >      > before publication.
> >
> >     please look at the latest version of the draft, section 3:
> >
> >
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-3
> >     <
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ip-flexalgo#section-3
> >
> >
> >     thanks,
> >     Peter
> >
> >      >
> >      > Kind regards
> >      > R.
> >      >
> >      > On Tue, May 17, 2022 at 12:01 PM Robert Raszuk <[e-mail]
> >     <mailto:[e-mail]>
> >      > <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
> >      >
> >      >     Folks,
> >      >
> >      >     A bit related to Aijun's point but I have question to
> >     the text from
> >      >     the draft he quoted:
> >      >
> >      >         In cases where a prefix advertisement is received in both
> >     a IPv4
> >      >         Prefix Reachability TLV and an IPv4 Algorithm Prefix
> >     Reachability
> >      >         TLV, the IPv4 Prefix Reachability advertisement MUST be
> >     preferred
> >      >         when installing entries in the forwarding plane.
> >      >
> >      >     Does this really mean that I can not for a given prefix say
> >     /24 use
> >      >     default topology for best effort traffic and new flex-algo
> >     topology
> >      >     for specific application ?
> >      >
> >      >     Is the "workaround 1" to always build two new topologies for
> such
> >      >     /24 prefix (one following base topo and one new) and never
> >     advertise
> >      >     it in base topology ?
> >      >
> >      >     Is the "workaround 2" to forget about native forwarding and
> >     use for
> >      >     example SR and mark the packets such that SID pool
> >     corresponding to
> >      >     base topology forwarding will be separate from SID pool
> >      >     corresponding to new flex-algo topology ?
> >      >
> >      >     Many thx,
> >      >     Robert
> >      >
> >      >
> >      >     ---------- Forwarded message ---------
> >      >     From: *Acee Lindem via Datatracker* <[e-mail]
> >     <mailto:[e-mail]>
> >      >     <mailto:[e-mail] <mailto:[e-mail]>>>
> >      >     Date: Mon, May 16, 2022 at 3:36 PM
> >      >     Subject: [Lsr] Publication has been requested for
> >      >     draft-ietf-lsr-ip-flexalgo-06
> >      >     To: <[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>
> >      >     Cc: <[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>,
> >      >     <[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>,
> >      >     <[e-mail] <mailto:[e-mail]>
> >     <mailto:[e-mail] <mailto:[e-mail]>>>,
> >     <[e-mail] <mailto:[e-mail]>
> >      >     <mailto:[e-mail] <mailto:[e-mail]>>>
> >      >
> >      >
> >      >     Acee Lindem has requested publication of
> >      >     draft-ietf-lsr-ip-flexalgo-06 as Proposed Standard on behalf
> >     of the
> >      >     LSR working group.
> >      >
> >      >     Please verify the document's state at
> >      > https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
> >     <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/>
> >      >     <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/
> >     <https://datatracker.ietf.org/doc/draft-ietf-lsr-ip-flexalgo/>>
> >      >
> >      >
> >      >     _______________________________________________
> >      >     Lsr mailing list
> >      > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> >     <mailto:[e-mail]>>
> >      > https://www.ietf.org/mailman/listinfo/lsr
> >     <https://www.ietf.org/mailman/listinfo/lsr>
> >      >     <https://www.ietf.org/mailman/listinfo/lsr
> >     <https://www.ietf.org/mailman/listinfo/lsr>>
> >      >
> >
>
>