[email protected]
[Top] [All Lists]

Re: LFAs and OSPF with multiple intra-area AS-external or summary-routes

Subject: Re: LFAs and OSPF with multiple intra-area AS-external or summary-routes
From: Alex Zinin
Date: Tue, 8 Feb 2005 23:48:11 -0800

> Despite hunting the OSPF spec, I missed that bit; thanks for point it
> out.  Certain implementations, as you say, would load-balance in that 
> situation.

> 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 
> areas.

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
similar solution.

>>   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 
> respectively).


> 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
[email protected]

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