Hi Jie
Very welcome!
I was actually referring to “SR” Flex Algo not IP Flex Algo comment I
made. This is a bit confusing which is why I brought it up.
Since the original Flex Algo draft is the base draft for Flex Algo it was
termed by the authors “IGP Flex Algo” not “SR Flex Algo” as the base
Hi Gyan,
Thanks for your review and useful comments.
The VTN concept is introduced in VPN+ framework
(https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn) in TEAS, and
its relationship with NRP is described in that document. VTN can be used to
support VPN+ service, which provides a
Robert –
Any SPF/CSPF – including that done for FRR – is per topology.
Fallback does not give you LFA – and if you tried to calculate a “fallback
topology” that would give you LFA I don’t see any advantage over existing FRR
techniques.
My comment regarding fallback has to do with the
/* 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
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
Hi John
Agreed FAD is restrictive with 128 values. Agreed.
Very good point and great idea!
Kind Regards
Gyan
On Wed, May 18, 2022 at 9:13 AM John E Drake wrote:
> Gyan,
>
>
>
> I don’t think we want a 1:1 mapping between NRP and FAD because it is a
> too restrictive and because it
Gyan,
I don't think we want a 1:1 mapping between NRP and FAD because it is a too
restrictive and because it unnecessarily burns through FADs. Rather, what I
think we want is a set of resource SIDs, one per-NRP that are allocated by each
node that is part of a FAD on each of its links that
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
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.
Title : IGP Flexible Algorithm
Authors : Peter Psenak
Shraddha Hegde
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,
14 matches
Mail list logo
