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

From: mike shand <[email-masked]>
Date: Fri, 12 Oct 2007 13:05:45 +0100

I support the progression of this document, but would like to see the 
comments Stewart and I made earlier on the algorithm addressed and also 
the few points below.

In addition, I wonder whether there should be something up front which 
makes clear that this may only provide a partial solution (depending on 
the topology). I know this is implicit in the body of the text, but I 
think it would be useful to avoid any misunderstandings if the abstract 
were a little more explicit on this point.

How about adding after "...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. ..."

"The extent to which this goal can be met by this specification is 
dependant on the topology of the network."

    Mike

    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.

It might be better to say "failure of one or more links within a shared 
risk link group".

          Figure 5: Example where Continued Use of Alternate is Desirable

       This is an example of a case where the new primary is not a loop-free
       alternate before the failure and therefore may have been forwarding
       traffic through S. This will occur when the path via a previously
       upstream node is shorter than the the path via a loop-free alternate
       neighbor.  In these cases, it is useful to give sufficient time to
       ensure that the new primary neighbor and other nodes on the new
       primary path have switched to the new route.

I wonder if it should be pointed out that while this is a good strategy 
to minimize the occurrence of microloops, it does nothing to prevent any 
microloops which may occur more than one hop away.

       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.

We should probably add that if the primary link comes back before any of 
this has happened then you can just go back to using the primary link as 
if nothing had happened. That of course pre-supposes that the failure 
hadn't yet been advertised. If it HAS been advertised, then it requires 
another advertisement to put it back how it was, but in any case (I 
think) the old next hop can safely be used.

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

---

From: "Alia Atlas" <[email-masked]>
Date: Thu, 25 Oct 2007 11:41:01 -0400

Hi Mike,

> comments Stewart and I made earlier on the algorithm addressed and also

I addressed the comments on the algorithm in a separate email.  Here are
responses to your points below.

> dependant on the topology of the network."

Agreed.  I've added this.

    Mike
> It might be better to say "failure of one or more links within a shared

yes - changed

> microloops which may occur more than one hop away.

Immediately before that figure, the draft discusses how the techniques given
in the micro-loop prevention drafts should dictate the convergence rules.

I've prefaced the references to those drafts with

"There are techniques available to handle the micro-forwarding loops
that can occur in a networking during convergence."
to give it a bit more context.

> think) the old next hop can safely be used.

Once the failure has been advertised, I don't think we can just go back to
using
the old next hop.  It would depend on what else in the network has already
been
updated.  Can you explain why you don't think that additional micro-loops
might be
the result?

Also, generally, there are hold-down times on links so that they can't just
bounce
back up before the link change has been advertised.  I don't think this is a
very useful
optimization and I'm a bit concerned about putting it in now without some
more thought.

Alia