> Despite hunting the OSPF spec, I missed that bit; thanks for point it
> out. Certain implementations, as you say, would load-balance in that
> I guess the question is whether this is preferable behavior or becomes bad
> when doing IP FRR.
> I believe that the same problem can exist with an inter-area route if a
> router is in two non-backbone areas and isn't in the backbone area. I'm
> still thinking about whether the problem might exist if it is in the
> backbone area and connected by multiple virtual links in different transit
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 single
failure per complete set of areas. Case 2: single failure per area. It seems
that reducing to case 1 may make things simpler.
> This latter is really just another case of the alternate next-hop not going
> 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 implementation
is constrained to support N next-hops only, and all of the slots for a route are
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.
> 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 think it
> 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.
Rtgwg mailing list