[email protected]
[Top] [All Lists]

Re: questions on draft-bryant-ipfrr-tunnels-01.txt

Subject: Re: questions on draft-bryant-ipfrr-tunnels-01.txt
From: Alia Atlas
Date: Tue, 23 Nov 2004 14:08:51 -0500
Hi Naiming,

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.
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 possible.
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 also.

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 that link.
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 IPFRR
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
[email protected]

<Prev in Thread] Current Thread [Next in Thread>