At 21:14 13/02/2005 -0500, Alia Atlas wrote:
> 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
> a single area; maybe its an implementation-specific decision but I
> 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).
The LFA draft currently doesn't really discuss ECMP and the protection
that may or may not be available via ECMP. For a particular destination
D, S may have multiple equal-cost primary next-hops.
In the following figure, S has three equal-cost paths via E1, E2 and E3.
[N]-----[ S ]--------[E3]
| 5 | |
20 | | |
| --------- | 2
| 5 | | 5 |
| [E1] [E2]------|
| | |
| 10 | 10 |
2 |--[D]--| 2
In this example, the primary next-hop to E1 can get link and node
protection from the primary next-hop to E3; it can only get node
protection from E2. E2 can't get node protection from E1 or E3; E2 can
get node protection and link protection from the loop-free neighbor N.
Simply having multiple primary next-hops does not guarantee the desired
type of protection. The basic question is whether it is preferable to use
an equal-cost path that doesn't provide all the desired types of
protection or an alternate path that does give the desired protection?
Should the draft discuss this issue or describe the use of other primary
next-hops as alternates in any more detail?
Yes, I think so. We had some text in our tunnels draft which addressed some
of this (section 4.6) , but the LAN case as you describe makes it more
complicated. I think if we are going to say you can use ECMP at all (which
I think we should), we need to say exactly under what conditions it is OK.
Rtgwg mailing list
Rtgwg mailing list