– especially in the forwarding plane – and would not be my first
choice as a solution.
??
Les
From: Lsr On Behalf Of Robert Raszuk
Sent: Tuesday, May 17, 2022 10:58 AM
To: Peter Psenak (ppsenak)
Cc: lsr
Subject: Re: [Lsr] Publication has been requested for
draft-ietf-lsr-ip-flexalgo-06
Hi Peter
Robert.
On 18/05/2022 13:18, Robert Raszuk wrote:
Peter,
This was not my question ...
Section 10 of soon to be published RFC clearly states that *"IGP
restoration will be fast and additional protection mechanisms will not
be required." *
We can remove that sentence if you don't like it.
Peter,
This was not my question ...
Section 10 of soon to be published RFC clearly states that *"IGP restoration
will be fast and additional protection mechanisms will not be required." *
Those "additional mechanisms" are listed further like LFA, FRR with all its
flavors which of course can be
Robert,
On 18/05/2022 10:53, Robert Raszuk wrote:
Peter,
It is not about someone thinking if this is a good idea or not. It is
about practical aspects of real deployments.
But ok section 10 of the subject draft says something pretty interesting:
/10. Protection
In many networks where
Missed it - sorry:
s/ control plane CPUs and data plane FIBs / control plane CPUs and data
plane FIBs with LFA or R-LFA enabled per topo/
On Wed, May 18, 2022 at 10:53 AM Robert Raszuk wrote:
> Peter,
>
> It is not about someone thinking if this is a good idea or not. It is
> about practical
Peter,
It is not about someone thinking if this is a good idea or not. It is
about practical aspects of real deployments.
But ok section 10 of the subject draft says something pretty interesting:
*10. Protection In many networks where IGP Flexible Algorithms are
deployed, IGP
Robert,
I really do not want to get into fallback between algorithms. If someone
really thinks it is a good idea, he can write a separate document and
describe the use case and how to do that safely. But please not in the
base flex-algo specification.
thanks,
Peter
On 17/05/2022 19:58,
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
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
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 ?
If so the repair must be setup on each topology, otherwise repair will be
long as it would need to
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
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.
So if I have http traffic vs streaming vs voice going to the same load
balancer (same dst IP address)
12 matches
Mail list logo
