[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: Naiming Shen
Date: Tue, 23 Nov 2004 21:19:11 -0800
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.


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 ?

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.

thanks,
- 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";-)

thanks.
- Naiming

Curtis



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.

Cheers,
- 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
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg

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