Re: [Lsr] Publication has been requested for draft-ietf-lsr-ip-flexalgo-06

["Les Ginsberg (ginsberg)" <[e-mail]>]

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]<mailto:[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]>
> <mailto:[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]>>
>      > <mailto:[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]>>
>      >     <mailto:[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]>>
>     <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>>
>      >     Cc: <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>     <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>>,
>      >     <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>     <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>>,
>      >     <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>     <mailto:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>>>,
>     <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>
>      >     <mailto:[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]>> <mailto:[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>>
>      >
>