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.
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.
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.
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.
Curtis Villamizar wrote:
In message <[email protected]>
Naiming Shen writes:
Alia Atlas wrote:
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
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.
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.
Rtgwg mailing list