[email protected]
[Top] [All Lists]

draft-ietf-rtgwg-ipfrr-spec-base-09 - LC coments

Subject: draft-ietf-rtgwg-ipfrr-spec-base-09 - LC coments
From: Stewart Bryant
Date: Fri, 12 Oct 2007 11:58:09 +0100

    Basic Specification for IP Fast-Reroute: Loop-free Alternates


 The goal of this technology is to reduce the
  micro-looping and packet loss that happens while routers converge
  after a topology change due to a failure.

SB> This draft does not address microlooping - our other drafts do that.
SB> There really ought to be a health warning saying that there are
SB> other solutions with greater fault coverage, but this one
SB> is simple and does not need any co-operation from any other
SB> node in the network.

1.  Introduction

  As discussed in [I-D.ietf-rtgwg-ipfrr-framework],

SB> We need to ask the question of whether we need to LC the framework
SB> draft and whether we need to publish that first to raise the
SB> awareness level before we send this to IETF/IESG review?

  The mechanism also
  assumes that both the primary path and the alternate path are in the
  same routing area.

SB> I am trying to remember how fundamental to the solution that is.
SB> Unlike NV, LFA only uses cost information and we know the costs.
SB> There is discussion regarding this restriction for OSPF, but does
SB> the constraint also apply to ISIS?

                       /------|  S  |--\
                      /       +-----+   \
                     / 5               8 \
                    /                     \
                  +-----+                +-----+
                  |  E  |                | N_1 |
                  +-----+                +-----+
                     \                     /
                 \    \  4              3 /  /
                  \|   \                 / |/
                  -+    \    +-----+    /  +-
                         \---|  D  |---/

                        Figure 1: Basic Topology

SB> This picture is not too bad, others are worse - particularly
SB> the figure in the appendix. Would we help
SB> the reader if we published a pdf version of the RFC?

  network with this feature experiences less traffic loss and less
  micro-looping of packets than a network without IPFRR.  There are
  cases where micro-looping is still a possibility since IPFRR coverage
  varies but in the worst possible situation a network with IPFRR is
  equivalent with respect to traffic convergence to a network without

SB> Surely we are talking repair not uloop here?

1.1.  Failure Scenarios

  The alternate next-hop can protect against a single link failure, a
  single node failure, one or more shared risk link group failures, or
  a combination of these.  Whenever a failure occurs that is more
  extensive than what the alternate was intended to protect, there is
  the possibility of temporarily looping traffic (note again, that such
  a loop would only last until the next complete SPF calculation).

SB> which may be delayed by the loop prevention mechanism.

  If there are not other protection
  mechanisms a node failure is still a concern when only using link

SB> This sentence seems in the wrong place - or provides too little
SB> discussion on the issues concerning node failure.

  In Figure 2, S
  would be able to use N as an alternate, but N could not use S;

SB> s/alternate/downstream alternate/

  therefore N would have no alternate and would discard the traffic,
  thus avoiding the micro-loop.  A micro-loop due to the use of
  alternates can be avoided by using downstream paths because each
  succeeding router in the path to the destination must be closer to
  the destination than its predecessor (according to the topology prior
  to the failures).  Although use of downstream paths ensures that the
  micro-looping via alternates does not occur, such a restriction can
  severely limit the coverage of alternates.

SB> Might be better to reorder the discussion here a little for
SB> clarity.

  As shown above, the use of either a node protecting LFA or a
  downstream path provides protection against micro-looping in the
event of node failure.
SB> I don't think that you have explained NP LFA yet

  There are topologies where there may be
  either a node portecting LFA, a downstream path, both or neither.  A
  node may select either a node protecting LFA or a downstream path
  without risk of causing micro-loops in the event of node failure.

SB> neighbor node failure?

  Since the functionality 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.

SB> Should we just say NP LFA as L & NP LFA sounds like we have two
SB> protection mechanisms.

3.3.  Broadcast and NBMA Links

                      +-----+    15
                      |  S  |--------
                      +-----+       |
                         | 5        |
                         |          |
                         | 0        |
                       /----\ 0 5 +-----+
                       | PN |-----|  N  |
                       \----/     +-----+
                          | 0        |
                          |          | 8
                          | 5        |
                       +-----+ 5  +-----+
                       |  E  |----|  D  |
                       +-----+    +-----+

          Figure 3: Loop-Free Alternate that is Link-Protecting

  In Figure 3, N offers a loop-free alternate which is link-protecting.
  If the primary next-hop uses a broadcast link, then an alternate
  SHOULD be loop-free with respect to that link's pseudo-node to
  provide link protection.  This requirement is described in
  Inequality 4 below.

             D_opt(N, D) < D_opt(N, pseudo) + D_opt(pseudo, D)

SB> The diagram used the term PN, maybe the equation should as well.

4.1.  Terminating Use of Alternate

  An implementation SHOULD continue to use the alternate next-hops for
  packet forwarding even after the new routing information is available
  based on the new network topology.  The use of the alternate next-
  hops for packet forwarding SHOULD terminate:

  a.  if the new primary next-hop was loop-free prior to the topology
      change, or

  b.  if a configured hold-down, which represents a worst-case bound on
      the length of the network convergence transition, has expired, or

  c.  if notification of an unrelated topological change in the network
      is received.

SB> I think that list list needs to include the case where the network
SB> has converged (with or without the uloop prevention as applicable)

6.  Routing Aspects

6.1.  Multi-Homed Prefixes

                     5   +---+  4   +---+  5  +---+
                   ------| S |------| A |-----| B |
                   |     +---+      +---+     +---+
                   |       |                    |
                   |     5 |                  5 |
                   |       |                    |
                 +---+ 5 +---+   5       7    +---+
                 | C |---| E |------ p -------| F |
                 +---+   +---+                +---+

                      Figure 6: Multi-homed prefix

  If there exist multiple multi-homed prefixes that share the same
  connectivity and the difference in metrics to those routers, then a
  single node can be used to represent the set.  For instance, if in
  Figure 6 there were another prefix X that was connected to E with a
  metric of 1 and to F with a metric of 3, then that prefix X could use
  the same alternate next-hop as was computed for prefix p.

SB> I do not understand this simplification. I think that you are
SB> saying use p as a proxy for p', p'' etc. But if they have
SB> different costs don't you have to always use a different proxy?
SB> Say p' was connected to E at cost 1, but F at cost 1000, surely
SB> the packet would never get to F, or if it did, F would prefer
SB> to sent it via E and hence loop. Is there a must sent external
SB> assumption (which we considered for the tunnel solutions) that
SB> is assumed?

- Stewart

rtgwg mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>