Subject: Comments on draft-ietf-rtgwg-ipfrr-spec-base-09

From: Rüdiger A Martin <[email-masked]>
Date: Fri, 12 Oct 2007 17:09:13 +0200

Dear Alia, dear Alex,

we have taken a look at your document and would like to add a few 
comments to the discussion already going on:

- The concept of node protecting LFAs is first mentioned on page 6. The 
definition and explanation follows later.

- There are several kinds of loop-free alternates. But the suggested 
order of preference among those different LFAs does not become clear at 
all in the draft. So there should be some paragraph where all possible 
candidate types are listed and described with their pros and cons. That 
description should include the protected failure types but also the 
behavior in case of unprotected failures: e.g., I miss a clear statement 
that downstream LFAs do not create any loops no matter what kind of 
failures may happen. Based on this, a clear suggestion for an order of 
preference can be given.

- Page 7: "Since the funcionality of link and node protecting LFAs is 
greater than that of downstream paths, a router SHOULD select a link and 
node protecting LFA over a downstream path." - That reads like 
downstream paths are generally worse. But of course a downstream link- 
and node-protecting LFA is better than a non-downstream link- and 
node-protecting LFA. So this point is strongly related to the point 
mentioned earlier concerning the order of preference.

- A few comments on the algorithm on page 16 (besides I agree with 
Stewarts comments):
       * Step 10: This means, if the router prefers other primary next 
hops, it prefers them no matter what kind of failures (links or nodes) 
they protect. So this algorithm prefers a link-protecting primary over a 
link- and node-protecting downstream LFA. (Depending on the order of the 
candidates - see below.)
       * The output of the algorithm depends on the order of the 
candidate next hops.
             1) Imagine that H_1 is a link-protecting primary next hop. 
H_2 is a link- and node-protecting downstream LFA. Then H_1 will be 
selected in the first iteration. During the second iteration, step 11 
selects H2 instead.
            2) Now imagine H_1' = H_2 and H_2' = H_1. Then the first 
iteration selects H_1'. However, the second iteration selects H_2' as 
the candidate in step 10. So the final result is H1.
          I think this problem is due to the missing order of preference.

Besides we really appreciate this document and support the progression 
of the document after consideration of the comments from above. We think 
that Mike's idea to include explicitly that this may only provide a 
partial solution is worth considering. But maybe together with the 
statement that this is a really simple and easy to implement approach 
since it does not require any support (i.e. signalling) from other routers.

Best regards,
Rüdiger

-- 
_______________________________________________________

             Dipl.-Inform. Rüdiger Martin
 Department of Distributed Systems (Informatik III)
Insitute of Computer Science, University of Würzburg
        Am Hubland, 97074 Würzburg, Germany
         [email-masked]
              Tel: +49 931 888-6651
              Fax: +49 931 888-6632 

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

---

From: "Alia Atlas" <[email-masked]>
Date: Thu, 25 Oct 2007 13:33:52 -0400

Dear Rüdiger,

> definition and explanation follows later.

True - The first place a node protecting LFA is mentioned, I've added a
reference to the section with the definition.
I don't see a clean way of defining it at/before that location.

> failures may happen. Based on this, a clear suggestion for an order of

Yes, we didn't have consensus about the order of preferences - and it
depends
on what other types of protection are available in the network.  I agree
that this
would be useful.  How does the following added section (after 3.6) sound?

"3.7.  LFA types and Trade-offs

   LFAs can provide different amounts of protection and the decision
   about which type to prefer is dependent upon network topology and
   other techniques in use in the network.  This section describes the
   different protection levels and the trade-offs associated with each.

   1.  Primary Next-hop: When there are equal-cost primary next-hops,
       using one as an alternate is guaranteed to not cause micro-loops
       involving S. Traffic flows across the paths that the network will
       converge to, but congestion may be experienced on the primary
       paths since traffic is sent across fewer.  All primary next-hops
       are downstream paths.

   2.  Downstream Paths: A downstream path, unlike an LFA, is guaranteed
       not to cause a micro-loop involving S regardless of the actual
       failure detected.  However, the expected coverage of such
       alternates in a network is expected to be poor.  All downstream
       paths are LFAs.

   3.  LFA: An LFA can have good coverage of a network, depending on
       topology.  However, it is possible to get micro-loops involving S
       if a more severe failure occurs than is protected against.

   The different types of protection are abbreviated as LP (link-
   protecting), NP (node-protecting) and SP (SRLG-protecting).

   a.  LP, NP, and SP: If such an alternate exists, it gives protection
       against all failures.

   b.  LP and NP: Many networks may handle SRLG failures via another
       method or may focus on node and link failures as being more
       common.

   c.  LP: A network may handle node failures via a high availability
       technique and be concerned primarily about protecting the more
       common link failure case.

   d.  NP: These only exist on interfaces that aren't point-to-point.
       If link protection is handled in a different layer, then an NP
       alternate may be acceptable.
"

I'd welcome suggestions on how to improve this.

> mentioned earlier concerning the order of preference.

Added the clarification of "link-protecting downstream paths".

> link- and node-protecting downstream LFA. (Depending on the order of the

True -  this is intended to reflect the behavior for the network once it has
converged.
I could instead embed the preference at Step 16 - but that flexibility is
there already.

>           I think this problem is due to the missing order of preference.

Ah - nope - it is due to a missing step - added between step 10 & 11.

"If cand_type is not PRIMARY, P_i.alt_type is PRIMARY and the router prefers
other primary next-
        hops for use as the alternate, then continue to the next candidate
next-hop"

> since it does not require any support (i.e. signalling) from other

Ok - so at the end of the abstract, I've added

"This simple approach does not require any support from other routers.  The
extent to which this goal can be met by this specification is
dependent on the topology of the network."

Thanks for the comments and suggestions!

Alia

Best regards,