In message <[email protected]>
Naiming Shen writes:
> Curtis Villamizar wrote:
> > 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.
> That's cool. I guess my concern was that not all the forwarding
> architecture has the indirect adjacency forwarding capability
> due to hardware or performance issues.
This is true. The performance issues of older hardware from specific
vendors is out of scope for a discussion of the protocols although it
is a practical consideration for providers that have certain older
hardware. I don't pretend to know which hardware can and can't do
this, but I do think its quite a lot of it.
OTOH if the goal of the provider is to support VOIP and the gateways
that need the fast restoration are in the IGP it might be good enough
to support fast restoration of the IGP only and let BGP catch up at
its own slower pace. Again this is a practical consideration for the
operator and out of scope for the protocol specs themselves.
> >>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.
> > Very true.
> >>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:
> > b--d--g,h,i...
> > / |
> > a -- e
> > \ |
> > c--f--q,r,s...
> > If the best path from a to d and from a to f used a-e, what is your
> > backup path for a-e?
> You meant when "e" is gone? wouldn't 'a' use a-b-d and a-c-f out ?
Yes. For the node disjoint case.
> > I also don't think NFRR covers SRLG in that case.
> which links are related in this 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.
> Agreed, if you can approve that something is "as simple as possible";-)
> - Naiming
Its the other way around. You have to prove that something works. If
it works use it unless you can find something simpler that also works.
When considering an alternative that seems simpler you have to prove
that it really does work. If you are having a lot of trouble proving
that it will work or even coming up with a convincing argument that it
should work, then you might want to stick with what you know works.
Anyway the point of the discussion we are having is to better
understand any limitations to IP FRR. If it usually works except when
X, we understand what X is. So far X seems to include SRLG and in
some techniques asymetric costs, and in all techniques under
discussion full coverage for all topologies, and maybe other things.
There is no consensus within the WG that any of this is a reason not
to continue, but we should discuss and known limitations and
acknowledge them in the framework document or individual documents.
Rtgwg mailing list