RE: Segment protection failure when recovery LSPs overlap

["PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>]

Nic, 

RFC4873 by means of SRRO allows nodes to determine existence of
upstream/downstream recovery segments as carried in Path/Resv message.
Combined with RFC4426 and RFC4428 that refers to master/slave it results
that either C (or F) trigger a recovery action by means of disjoint
recovery segments. 

Thanks,
-d.

> -----Original Message-----
> From: Nic Neate [mailto:Nic.Neate@dataconnection.com] 
> Sent: Friday, February 20, 2009 4:05 PM
> To: ccamp@ops.ietf.org
> Cc: labn - Lou Berger; IBryskin@advaoptical.com; 
> PAPADIMITRIOU Dimitri; Aria - Adrian Farrel Personal
> Subject: Segment protection failure when recovery LSPs overlap
> 
> Hi CCAMP,
> 
> I'd like to raise one more issue with RFC4873 segment 
> recovery, which I believe will lead to data loss when 
> overlapping segment recovery LSPs are used.
> 
> RFC4873 allows topologies like this one:
> 
>                           K-----------L
>                          /             \
>                     A===B===C===D===E===F===G===H
>                              \             /
>                               I-----------J
> 
> A working LSP A-B-C-D-E-F-G-H is protected by two overlapping 
> segment recovery LSPs: B-K-L-F and C-I-J-G.  The recovery 
> scheme is 1:1 protection with extra traffic.
> 
> Suppose the link D-E fails:
> 
>                           K-----------L
>                          /             \
>                     A===B===C===D x E===F===G===H
>                              \             /
>                               I-----------J
> 
> My understanding is that the failure will be handled as follows.
> 
> -  D detects the link failure, and sends Notify to C (first 
> Notify object
>    in the received Path).  C and G exchanged Notify messages 
> to remove 
>    extra traffic from the C-I-J-G repair, and then send and receive 
>    traffic from the working LSP on C-I and G-J.
> 
> -  Meanwhile, E also detects the failure, and sends Notify to 
> F (first 
>    Notify object in the received Resv).  F likewise exchanges Notify
>    messages with B to remove extra traffic from the B-K-L-F 
> repair, and
>    and then send and receive working LSP traffic on B-K and F-L.
> 
> That results in the following data flow:
> 
>                           K----->-----L
>                          /             \
>                     A->-B <-C   D   E   F-> G<--H
>                              \             /
>                               I-----<-----J
> 
> Forward traffic reaches G on the link F-G.  However, G has 
> switched to send and receive on G-J, and so drops traffic 
> received from F.
> 
> Reverse traffic reaches B on C-B.  However, B has switched to 
> send and receive on B-K, and so drops traffic received from C.
> 
> Thus traffic is lost in both directions.
> 
> Can anyone point out an error in this analysis?  Is this a 
> topology that there is interest in supporting?
> 
> Thanks,
> 
> Nic
>