[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Segment protection failure when recovery LSPs overlap
Hi Dimitri,
We had wondered about the SRRO as a possible solution to this problem as well. However, there are a couple of issues as the protocol currently stands.
- SRROs can only be present in Path messages between the merge node and the egress, and in Resv messages between the branch node and the ingress. See http://tools.ietf.org/html/rfc4873#section-2 and http://tools.ietf.org/html/rfc4873#section-5.2. Therefore, C does not have the SRRO for recovery LSP B-K-L-F, and F does not have the SRRO for recovery LSP C-I-J-G.
- The inclusion of the SRRO is optional, controlled via the segment-recording-desired flag in the SESSION_ATTRIBUTE object (http://tools.ietf.org/html/rfc4873#section-5.2). If the SRRO is required in order to avoid data loss then it needs to be mandatory.
So I think we need a protocol extension in order to provide a signaling-based solution.
Nic
-----Original Message-----
From: ALU - Dimitri Papadimitriou
Sent: 21 February 2009 23:51
To: Nic Neate; ccamp@ops.ietf.org
Cc: labn - Lou Berger; IBryskin@advaoptical.com; Aria - Adrian Farrel Personal
Subject: RE: Segment protection failure when recovery LSPs overlap
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
>