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

From: "Don Fedyk" <[email-masked]>
Date: Mon, 3 May 2004 15:00:34 -0400

Hi Alex
Please see comments inline.  

Regards,
Don
> -----Original Message-----
> From: Alex Zinin [mailto:[email-masked]]
> 
>  At this point I would like to solicit opinions on the following 
> points:
> 
>   1. Technical comments on the substance of the document

I support the document because it addresses a practical problem of
minimizing packet loss. As stated in the document, this is most noticeable
with certain real-time applications like voice.
> 
>   2. More specifically, comments on the U-Turn part (e.g. useful/not 
> useful,
>      comfortable/concerned with the approach, etc.)
I think the U-turn is useful. I can understand that the U-turn is a bit of a
difficult problem and solution to understand. I had a few discussions with
Alia myself before I was convinced the options and the pieces were complete.
I am comfortable with the U-turn mechanism and I believe it is useful
because:

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. 
2. U-turn alternates in the draft invoke the U-turn alternatives immediately
when no loop-free alternates exist, (after the fault is detected, but before
the SPF calculation and new FIB update is complete). 

> 
>   3. Should the WG use this document as the basis for work on the IP 
> fast
>      reroute topic

Others have pointed out that IP Fast reroute involves areas such as: Link
Change/Failure Detection, Link State Advertisements, SPF, FIB updates and
alternative routing. 

I agree. Each area is important. The local protect draft provides a basis
for work on alternative paths from the after failure detection time to the
FIB updates. This document is scoped to what you can do practically while
keeping state and logic dependence contained on a single node.  

Other areas related to fast IP reroute but out of scope for this document:
Fast detection of link failures.
Efficient LSA distribution.   
Fast SPF calculation.
Building logic for loop free alternates by other means.  

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

---

From: mike shand <[email-masked]>
Date: Tue, 04 May 2004 11:36:31 +0100

>coming back from a primary neighbor it just deals with it preventing loss or

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

---

From: "Don Fedyk" <[email-masked]>
Date: Tue, 4 May 2004 09:58:17 -0400

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.

Don

> From: mike shand [mailto:[email-masked]] 
> 
> >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.
>