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 <[email protected]> On Behalf Of Robert Raszuk
Sent: Tuesday, May 17, 2022 10:58 AM
To: Peter Psenak (ppsenak) <[email protected]>
Cc: lsr <[email protected]>
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
<[email protected]<mailto:[email protected]>> 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
> <[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>> 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
> <[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> > <mailto:[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>>> 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*
> <[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> > <mailto:[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>>>
> > Date: Mon, May 16, 2022 at 3:36 PM
> > Subject: [Lsr] Publication has been requested for
> > draft-ietf-lsr-ip-flexalgo-06
> > To: <[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> <mailto:[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>>>
> > Cc: <[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> <mailto:[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>>>,
> > <[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> <mailto:[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>>>,
> > <[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> <mailto:[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>>>,
> <[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> > <mailto:[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>>>
> >
> >
> > 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
> > [email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>
> <mailto:[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>>
> > 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>>
> >
>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
