Alia Atlas wrote:
At 01:26 PM 11/23/2004, Naiming Shen wrote:
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.
Each of those LSPs requires separate forwarding state, both for primary
and for backup, because there is a different label or label stack involved.
For good scaling, it is desirable to be able to fail-over from primary
to backup based on a next-hop event regardless of the number of LSPs.
yes, it's regardless of the number of LSPs for each LSP switch-over,
but the total switch-over time is linear to the number of LSPs affected.
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.
A difference is that most of those routes can use the same forwarding
state as that associated with one or more IGP nodes.
Thus, while there may be more routes than LSPs, there is indirection
yes, indirection makes it scalable. but a hardware design or an
existing forwarding engine may not want to do indirection due to
extra processing at forwarding time.
This is more clearly seen with LDP, where that vast number of routes can
be and generally is reduced down to a small number of FECs.
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.
Absolutely. Implementation does matter. You can do TE-FRR way too slow
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.
This seems to me to be missing several points.
First, if only link protection is desired, then all routes that are
using a particular link can be given the same alternate; this may mean
that some destinations aren't protected when they could have been, but
it's a first pass simplification. This is the case regardless of
whether NFRR is used or some other mechanism; it is simply a side-effect
of the far end of the link proxying for all destinations reached through
yes, I guess my comment was more related to the link-protection case,
which is simple enough and most vendors will just do it.
Second, if node protection is desired, then it is necessary, in NFRR as
in any of the tunneling schemes, to track the next-next-hop for each
route or IGP destination. In that case, you need to organize
indirection of routes to primary & alternate based upon the next-next-hop.
NFRR provides no added benefit that I can see here. If one has the
ability to add that extra level of indirecton (desirable anyway for fast
IGP convergence), then that level can be added in to handle any of these
For the hardware can do indirection of adjacencies, you are right,
that's not a big problem. But even that, NFRR is only concerned about
a couple of next-nexthop adjacencies and the traffic is for sure
being switched over to the next-nexthop nodes. For non-nexthop schemes,
I guess one needs to worry about BGP nexthops which are IGP nodes,
and next-nexthops of those IGP routes, so there is more complexities
to figure out those alternative indirections. And in the case of
inter-area node-protection of ABR router, this will be rather tricky.
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.
As I said above, I don't think that a non-nexthop based IPFRR scheme
adds another level of indirection. It is the same level that is
necessary for node protection.
Rtgwg mailing list