[email protected]
[Top] [All Lists]

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

Subject: Re: LFAs and OSPF with multiple intra-area AS-external or summary-routes
From: Alia Atlas
Date: Wed, 09 Feb 2005 11:31:58 -0500

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

              10        1
      [ 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 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.
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 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.
OK.  I'll start a separate thread on ECMP considerations (with examples).


Rtgwg mailing list
[email protected]

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