At 02:52 PM 2/8/2005, Alex Zinin wrote:
Couple of things here.
The OSPF spec says that when an ASBR is reachable with the same cost
more than one area, the paths through a single area (with the highest
must be picked. However, I do know certain implementations would
in such situation.
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
I agree with your suggestion to require the protecting neighbor to be
same area. I'd like us to keep the mechanism as simple as practically
feasible. As we gain experience and feel more comfortable going
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.
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).
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.
Regarding the cases, where traffic will still get diverted to another
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,
I'd be happy to see it solved with an applicability statement - but I'm not
certain of how to specify it.
Thanks for looking at this!
The joys of implementation :-) Thanks actually go to Srinivas and Namrata
for pointing out the lack of specification :-(
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.
> [ 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
> 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
> 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
> 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
> 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
> were crossed.
> This seems to me to indicate that a primary next-hop SHOULD be
> an alternate next-hop from the same area; this implies the need to
> 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
> the ABRs.
> Thoughts? Have I missed anything? Any suggestions on reasonable
> compromise approaches?
> Rtgwg mailing list
> [email protected]
Rtgwg mailing list