In message <[email protected]>
Naiming Shen writes:
> Another issue I have not seen any discussion on the
> list is how fast the "FRR" can be accomplished on the
> node for a IPFRR scheme.
> For MPLS LSPs and it's FRR, a node may only have hundreds
> or thousands of LSPs, it's not common to see 10s of
> thousands LSPs using the same interface on a node.
There might be a larger number of LDP and/or VPN labels, but not
MPLS/TE LSPs. So I agree completely. Thousands is rare. I've not
yet heard of anyone actually getting to 10,000.
> For IPFRR, we need to consider maybe half a million routes
> pointing to the same nexthop, it's very different in
> scaling comparing to MPLS LSPs.
That is done with a two stage forwarding. IPFRR protects IGP
destinations and routes are mapped into IGP destinations. The IGP
destinations are protected, then switched over first, then any BGP
routes that map into different IGP routes as a result of the topology
change see a route change. Its faster and avoids the problem of
needing to jam a few hundred thousand entries into hardware to get the
fast recovery to work.
> if a scheme requires to change each one of the nexthop
> in response to link/node failure for a million routes, it
> may not be 'fast' enough to be considered as fast-reroute.
> Just want to mention that for NFRR, since it's only dealing
> with a known nexthop, regardless of the number of routes
> using this nexthop, it only needs to have one operation
> to redirect to an alternative nexthop. It works the
> same if there is only a hundred routes pointing to it, or
> one million routes pointing to it.
How do you do node protection in this case:
a -- e
If the best path from a to d and from a to f used a-e, what is your
backup path for a-e?
I also don't think NFRR covers SRLG in that case.
> For non-nexthop based IPFRR schemes, another level of
> redirection can be introduced, but this also will increase
> the complexity of the scheme for implementation. When
> anyone wants to compare comlexity of mechanisms, we
> need to keep this in mind.
> - Naiming
Reducing complexity is a worthy goal, but you know what Einstein said
about as simple as possible but no simpler. If it no longer works
we've gone to a solution which is too simple.
> Curtis Villamizar wrote:
> > In message <[email protected]>
> > Naiming Shen writes:
> >>Hi Alia,
> >>Alia Atlas wrote:
> >>>Hi Naiming,
> >>>At 02:47 PM 11/22/2004, Naiming Shen wrote:
> >>>>>Sure. We can have a different protocol in the network solely for
> >>>>>resiliency to create those source-routed tunnels with the associated
> >>>>>complexity, but at least it wouldn't be MPLS :-)
> >>>>Well, the main purpose is to enable backbone IP tunnels with the
> >>>>capability of TE, IPFRR is just a side effect of that :-)
> >>>Coming full circle, I suppose. :-)
> >>The reason it seems comming to a full circle is that, I keep waiting for
> >>a simpler solution, and yet to see one ;-)
> > I think this work exists due to anti-MPLS sentiment and a need for
> > FRR. The alternative (IP FRR) may be proving to be problematic and
> > the argument that there is something hard about doing MPLS FRR seems
> > to be losing credibility )or maybe just more so when FRR is added to
> > the list of requirements).
> >>>If a network is already doing TE and is willing to do the configuration,
> >>>etc., then it makes sense to use TE Fast-Reroute. Whether the
> >>>forwarding path is MPLS or IP seems irrelevant to me in that piece of
> >>>the discussion.
> >>I thought that was relevant in this IPFRR discussion, otherwise there is
> >>no way the NFRR solution should be outside this discussion. In terms of
> >>configuration "complication", it's all relative thing. People need to
> >>do comparison for their network in order to reach some conclusion.
> >>Also, the NFRR or MPLS TE configuration is mostly implementation issue,
> >>majority of that can be automated just like the IPFRR approaches
> >>discussed in this working group.
> >>- Naiming
> > Yep. Agree completely. The requirement *not* to use MPLS may not be
> > based on any technical issue.
> > Anyway we may be either out of scope or committing herasy as far as
> > this WG is concerned.
> > Curtis
Rtgwg mailing list