Subject: RE: Review Call: draft-atlas-ip-local-protect-00.txt as WG item

From: mike shand <[email-masked]>
Date: Tue, 04 May 2004 15:22:24 +0100

At 09:58 04/05/2004 -0400, Don Fedyk wrote:
>Hi Mike
>
>First lets make it clear we are talking about a subset of packets that are
>affected by transient conditions. So following this lets say conditions are
>such that some percent of packets are not delivered or looped when the
>U-turn logic is invoked whereas currently 100 percent of these same packets
>are not delivered or looped. Both condition produce packet loss as viewed
>from outside the network. But comparing them, doing the U-turn logic has
>much less packet loss.  This seems beneficial to me.

Yes, its beneficial in some cases. Some other cases will loop, and some 
other cases will be dropped because the node didn't have a U-turn path.

But I was just pointing out that taking your statement

"the logic for U-turn does not need to know why the
packet is coming back from a primary neighbor it just deals with it
preventing loss or black hole effects."

at face value may lead one to suppose that ALL such looping problems were 
prevented, which is not the case.

         Mike

>Don
>
> > -----Original Message-----
> > From: mike shand [mailto:[email-masked]]
> >
> > At 15:00 03/05/2004 -0400, Don Fedyk wrote:
> > >1. U-turns can happen for momentary periods in any packet
> > network after
> > >the SPF and the FIB update on downstream nodes.  Nodal
> > updates are not
> > >synchronous and the logic for U-turn does not need to know why the
> > >packet is coming back from a primary neighbor it just deals with it
> > >preventing loss or black hole effects.
> >
> > But surely, when the U-turn is invoked because of desynchronized FIB
> > updates there is no guarantee that the packet will be delivered
> > successfully. The packet will be sent on a path computed to
> > avoid the next
> > next hop. This might be OK, but it equally might not. It
> > might take it to
> > another place where the U-turn would be triggered by
> > desynchronized FIBs,
> > and the repair path for that U-turn might lead back to the first case.
> >
> > It would appear that this introduces unpredictable behaviour into the
> > network, which isn't desirable.
> >
> >          Mike
> >
> >
> >
> >

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

---

From: Alia Atlas <[email-masked]>
Date: Tue, 04 May 2004 15:41:25 -0400

Hi Mike,

>other cases will be dropped because the node didn't have a U-turn path.

The cases where it would loop require something like the following, where A 
is sending the traffic to some D downstream:

          [A]----[B]
            |       |
            |       |
          [E] ----[C[

where A is using an updated topology and thinks that B is its primary,
           B is using the old topology and thinks that A is its primary and 
C is its loop-free node-protecting alternate
         C is using the old topology and thinks that E is its primary
         E is using the new topology and thinks that C is its primary and A 
is its loop-free node-protecting alternate

In this case, there are two upstream forwarding loops required simultaneous 
and a relatively constrained topology.

Alia