At 02:48 AM 2/9/2005, Alex Zinin wrote:
Yes, we need to consider the transit area case, since it makes it possible for
routing entries to have next-hops in more than one area. This is standard
behavior. Once this is solved, non-standard things like ECMP to ASEs and
multiple non-bb area (as in e.g. RFC3509) would most probably benefit from a
>> I agree with your suggestion to require the protecting neighbor to be
>> in the
>> same area. I'd like us to keep the mechanism as simple as practically
>> feasible. As we gain experience and feel more comfortable going
>> further, we'll
>> be able to extend this.
> The problem is that this isn't a completely simple solution - from an
> implementation perspective. There are two issues. First, say that we've
> got two primary next-hops P1 and P2 (in areas 1 and 2 respectively) with
> their associated alternates A1 and A2 (again in areas 1 and 2
> Now, if the link to P1 fails, does all traffic suddenly get
> routed to A1 in preference to the equal-cost P2? Do I put the traffic that
> was going to P1 onto A1 and leave the other traffic on P2? Arguably, if
> there are alternates on the path from P2, then those could be used (if
> there's a corresponding failure on that path). Say the failure is of P1
> and the path from P2 reenters the area via node Y. Then it is possible
> that Y's LFA in that area is S itself.
Do you have an example for this scenario? A diagram would make it easier to
analyze. Also, I think one implicit thing here that's worth made explicit is
what we mean by a single failure in the FRR fundamentals. Case 1: it is a
failure per complete set of areas. Case 2: single failure per area. It seems
that reducing to case 1 may make things simpler.
I hadn't gotten to considering case 2; I'm still on case 1.
Here's an example. In this case --- are area 1 and **** are area 2. S is
connected via a virtual link to ABR1 in area 1 and by a virtual link to
ABR2 in area 2. Y isn't connected to the backbone; it could also have
virtual links in the two areas to ABR1 and ABR2 if needed.
[ A1 ]-----[ S ]*****[ P2 ]
| | *
| 5 | * 1
| | 1 *
10 | [ P1 ]-----[ Y ]
| | *
| 5 | * 13
| 5 | *
[ABR1]----[ B ] [ ABR2 ]
10 | | 10
Summary Prefix 1 Summary Prefix 1
> This latter is really just another case of the alternate next-hop not
> via the intra-area path computed but into a different area. If we can
> solve that one (I like applicability statements if we can frame it clearly
> :-), then perhaps this becomes a non-issue.
> Second, there's a practical limitation of how many next-hops (primary or
> alternate) one may store with a particular route. This could limit the
> number of areas that a router can take a shortest-path from. Granted, a
> router may only support ECMP up to some number - but previously only 1 or
> 2 (worst-case with ECMP to two neighbors across the same interface) extra
> next-hops were ever needed to store alternates. Now it could be one for
> every area - or even 2 (in the worst-case).
How about we look at it this way: what we're interested in is protection,
whether this is ECMP or LFA. Removing increased memory consumption from
consideration as something we'll have to deal with anyways: if an
is constrained to support N next-hops only, and all of the slots for a
taken, well then one option is to not install LFAs at all--the route is
protected with ECMP after all. Should the topology change such that some slots
become available--one can add LFAs there.
True - but the ECMP may not give protection in the multi-area paths.
> The second is "just" an implementability concern - it's certainly possible
> but just more complex. For the first, I think we may wish to define
> rules/recommendations. Of course, we've not defined the rules for ECMP in
> a single area; maybe its an implementation-specific decision but I
> bears a bit of discussion.
Yes, let's discuss this a bit and see if anything needs to be recommended or
some explanatory text added to the document.
OK. I'll start a separate thread on ECMP considerations (with examples).
Rtgwg mailing list