[email protected]
[Top] [All Lists]

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

Subject: Re: Comments on draft-ietf-rtgwg-ipfrr-spec-base-09
From: mike shand
Date: Mon, 12 Nov 2007 09:42:26 +0000
Ah yes, of course. Perhaps "NP only" would be sufficient clarification.

    Mike

Alia Atlas wrote:


On Nov 9, 2007 12:01 PM, mike shand <[email protected]> wrote:
Alia,
    The added classification of alternates looks fine, except I am completely confused about your statement about NP. See inline.

    Mike

Alia Atlas wrote:
Dear Rüdiger,

On 10/12/07, Rüdiger A Martin <[email protected] > wrote:
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.

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

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'm completely confused by this last statement. Surely it is possible to have a node protecting LFA on a pt-pt interface?

Yes - but I have already categorized that case as an alternate that is LP and NP.    This is discussing alternates that are
only NP.  I'll make it clearer.

Thanks,
Alia


_______________________________________________
rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg
<Prev in Thread] Current Thread [Next in Thread>