[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 11:52:49 -0800

  Couple of things here.

  The OSPF spec says that when an ASBR is reachable with the same cost through
  more than one area, the paths through a single area (with the highest area ID)
  must be picked. However, I do know certain implementations would load-balance
  in such situation.

  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.

  Regarding the cases, where traffic will still get diverted to another area--
  this is what the applicability statement is for. In other words, we provide
  a tool that (as always) has its own limitations. As long as the tool is
  practically useful, and limitations are carefully described in the AS, we're

  Thanks for looking at this!


Monday, February 7, 2005, 5:56:20 PM, Alia Atlas wrote:
> The behavior of loop-free alternates within a single area seems pretty 
> clear.  Things get a bit more interesting when considering multiple areas 
> for OSPF.  For instance, consider the following topology where the --- 
> lines indicate area 1 and the **** lines indicate area 2.

>                                    5
>                      [ A2 ] ************** [ Z ]
>                        *                     *
>                        *                     *
>                     10 *                     *
>               10       *    1                *
>    [ A1 ] ---------- [ S ]*****[ N2 ]        *
>      |                 |         *           *
>    5 |               5 |       1 *           *
>      |       5         |    1    *    13     *
>    [ X ] ----------- [ N1 ]----[ Y ] **** [ ASBR2]
>      |                                       *
>    5 |                                       * 10
>      |        10                             *
>    [ ASBR 1] ---- P                          P

> In the above topology, S learns two routes to the prefix P.  From area 1, S 
> learns an intra-area route to ASBR1 with a cost of 15 (25 to P); similarly 
> from area 2, S learns an intra-area route to ASBR2 with a cost of 15 (25 to 
> P).

> Assuming that S is doing ECMP, S would normally select both N1 and N2 as 
> primary next-hops.  The question is what should S select for alternates. S 
> could assume that N1 and N2 can be alternates for each other & provide both 
> link and node protection.  However, Y is also an ABR & sees a shorter path 
> to the prefix P via N1 in area 1.  Thus, although the primary path computed 
> by S for area 2 didn't use N1, traffic forwarded to N2 will go to Y and 
> thus to N1.

> Therefore, the two primary next-hops can't be guaranteed to provide 
> node-protection.  Similarly, there could be a broadcast interface between 
> S, N1 and Y in the above topology - and then link protection wouldn't be 
> provided.

> In a more absurd topology, S could not even have the topology information 
> available to in any way determine this.  This would be the case when 2 ABRs 
> were crossed.

> This seems to me to indicate that a primary next-hop SHOULD be protected by 
> an alternate next-hop from the same area; this implies the need to store an 
> alternate per (non-backbone) area primary next-hop to gain protection.

> Also, the ability of an alternate path to exit the area and (potentially) 
> return via the "protected" primary neighbor or a link to that neighbor may 
> need to be considered.  This could happen by crossing 2 ABRs, one of which 
> had a shorter intra-area route in the second area & the other which had a 
> shorter intra-area route in the first area - that was back through the 
> "protected" primary neighbor.

> I believe that both of the above are potentially of concern for inter-area 
> routes and AS-external routes.

> The first seems like it could be solved by requiring a primary next-hop be 
> protected by an alternate from the same area - even if there is an 
> equal-cost path via a different area.  The second seems more theoretically 
> problematic - though less realistic.  These issues appear to only exist for 
> the ABRs.

> Thoughts?  Have I missed anything?  Any suggestions on reasonable 
> compromise approaches?

> Thanks,
> Alia

> _______________________________________________
> Rtgwg mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rtgwg

Rtgwg mailing list
[email protected]

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