Subject: LFAs and ECMP

From: Alia Atlas <[email-masked]>
Date: Sun, 13 Feb 2005 21:14:23 -0500

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

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.

        20         3
   [N]-----[ S ]--------[E3]
    |      5 |            |
20 |        |            |
    |    ---------        | 2
    |  5 |       | 5      |
    |   [E1]    [E2]------|
    |    |       |
    | 10 |    10 |
    |---[A]     [B]
         |       |
       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?

Alia

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

---

From: mike shand <[email-masked]>
Date: Mon, 14 Feb 2005 11:33:10 +0000

At 21:14 13/02/2005 -0500, Alia Atlas wrote:

>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.
>
>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.
>
>an equal-cost path that doesn't provide all the desired types of 
>protection or an alternate path that does give the desired protection?
>

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.

         Mike

---

From: Alia Atlas <[email-masked]>
Date: Mon, 14 Feb 2005 11:38:55 -0500

At 06:33 AM 2/14/2005, mike shand wrote:
>>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 
>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.

So describe the above example as a case of how ECMP doesn't guarantee 
protection - and then up to the implementation/operator to decide what the 
preference between protection type and cost is?

Alia

---

From: mike shand <[email-masked]>
Date: Mon, 14 Feb 2005 17:15:53 +0000

At 11:38 14/02/2005 -0500, Alia Atlas wrote:
>>(which I think we should), we need to say exactly under what conditions 
>>it is OK.
>

Don't we already have to discuss the same sort of issues with respect to 
LFAs? ie. you may be able to get a viable LFA where you couldn't otherwise 
by relaxing the protection type.

But if it were a choice between using an ECMP which may not actually 
protect against the failure, and using an LFA which is guaranteed to 
protect against any failure, then I think I would probably choose the 
latter. It is only in cases where there was no "perfect" LFA that I might 
be tempted to use a less than unconditionally OK ECMP (or even LFA).

But as you say, to some extent it is an operator/implementation choice.

         Mike

---

From: Alia Atlas <[email-masked]>
Date: Mon, 14 Feb 2005 15:21:37 -0500

At 12:15 PM 2/14/2005, mike shand wrote:
>>protection - and then up to the implementation/operator to decide what 
>>the preference between protection type and cost is?
>

We do.  The draft describes the selection of an alternate for each primary 
next-hop, so it's really part of that...  I can just add in an advisory bit 
with the example.

>be tempted to use a less than unconditionally OK ECMP (or even LFA).

Right.  The draft says one should pick an alternate that gives the best 
protection possible.

>But as you say, to some extent it is an operator/implementation choice.

So I'll clarify a bit with the example - and leave it as the should.

Alia

---

From: Alex Zinin <[email-masked]>
Date: Tue, 15 Feb 2005 13:50:27 -0800

Alia,

  When adding text on this to the document, please make sure the difference
  between using ECMP for load-balancing BF and using ECMP and LFAs for
  protection AF is emphasized.

  Another question we may want to think about is load-balancing AF via multiple
  LFAs.
  
-- 
Alex
http://www.psg.com/~zinin

---

From: Alia Atlas <[email-masked]>
Date: Tue, 15 Feb 2005 17:24:37 -0500

Alex,

>   protection AF is emphasized.

Will do.

>   Another question we may want to think about is load-balancing AF via 

I don't believe that anything in the draft prevents this - it may not be 
explicitly called out.  It can certainly be the case with ECMP.  I can 
specify that a router SHOULD select at least one alternate, if available.

I'll try to get an updated section on this piece out tomorrow.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Wed, 16 Feb 2005 06:11:43 -0500

Here is the text that I'm adding to the LFA draft.  Please let me know if 
this covers the issues sufficiently.

2.4  ECMP and Alternates

    With equal-cost multi-path, a prefix may have multiple primary
    next-hops that are used to forward traffic.  When a particular
    primary next-hop fails, alternate next-hops should be used to
    preserve the traffic.  These alternate next-hops may themselves also
    be primary next-hops, but need not be.  Other primary next-hops are
    not guaranteed to provide protection against the failure scenarios of
    concern.

                            20 L1      L3  3
                          |      5 | L2         |
                       20 |        |            |
                          |    ---------        | 2
                          |  5 |       | 5      |
                          |   [E1]    [E2]------|
                          |    |       |
                          | 10 |    10 |
                          |---[A]     [B]
                               |       |
                             2 |--[D]--| 2

    Figure 4: ECMP where Primary Next-Hops Provide Limited Protection

    In Figure 4 S has three primary next-hops to reach D; these are L2 to
    E1, L2 to E2 and L3 to E3.  The primary next-hop L1 to E1 can obtain
    link and node protection from L3 to E3, which is one of the other
    primary next-hops; L1 to E1 cannot obtain link protection from the
    other primary next-hop L2 to E2.  Similarly, the primary next-hop L2
    to E2 can only get node protection from L2 to E1 and can only get
    link protection from L3 to E3.  The third primary next-hop E3 can
    obtain link and node protection from L2 to E1, but can only get link
    protection from L2 to E2.  It is possible for both the primary
    next-hop L2 to E2 and the primary next-hop L2 to E1 to obtain an
    alternate next-hop that provides both link and node protection by
    using L1.

    Alternate next-hops are determined for each primary next-hop
    separately.  As with alternate selection in the non-ECMP case, these
    alternate next-hops should maximize the coverage of the failure
    cases.

Alia