Re: [mpls] Doubts on draft-helvoort-mpls-tp-ring-protection-switching-03

Huub helvoort <huub.van.helvoort@huawei.com> Mon, 04 February 2013 14:55 UTC

Return-Path: <huub.van.helvoort@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED4F21F861F for <mpls@ietfa.amsl.com>; Mon, 4 Feb 2013 06:55:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZayAAzU7PqOp for <mpls@ietfa.amsl.com>; Mon, 4 Feb 2013 06:55:03 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C473721F85FE for <mpls@ietf.org>; Mon, 4 Feb 2013 06:55:02 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APK64063; Mon, 04 Feb 2013 14:55:00 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 4 Feb 2013 14:54:06 +0000
Received: from LHREML509-MBX.china.huawei.com ([10.201.4.177]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Mon, 4 Feb 2013 22:54:50 +0800
From: Huub helvoort <huub.van.helvoort@huawei.com>
To: Naveen T <naveen.thanikachalam@yahoo.in>, MRPS Helvoort <draft-helvoort-mpls-tp-ring-protection-switching@tools.ietf.org>, MPLS <mpls@ietf.org>
Thread-Topic: [mpls] Doubts on draft-helvoort-mpls-tp-ring-protection-switching-03
Thread-Index: AQHOAr38rq1P2AQsjk+MZMOi/qJYnZhphySAgAAkKiiAAAvrgIAADNyE
Date: Mon, 04 Feb 2013 14:54:49 +0000
Message-ID: <73E555AA235F3846B8051DB38C8776272E5ACFEC@lhreml509-mbx>
References: <1359970168.93490.YahooMailNeo@web190901.mail.sg3.yahoo.com>, <1359975401.56110.YahooMailNeo@web190906.mail.sg3.yahoo.com> <73E555AA235F3846B8051DB38C8776272E5ACF9A@lhreml509-mbx>, <1359985727.14648.YahooMailNeo@web190902.mail.sg3.yahoo.com>
In-Reply-To: <1359985727.14648.YahooMailNeo@web190902.mail.sg3.yahoo.com>
Accept-Language: en-GB, en-US, zh-CN
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.217.152]
Content-Type: multipart/alternative; boundary="_000_73E555AA235F3846B8051DB38C8776272E5ACFEClhreml509mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [mpls] Doubts on draft-helvoort-mpls-tp-ring-protection-switching-03
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Feb 2013 14:55:04 -0000

Dear Naveen,

You replied:

> Thank you very much for clearing up my doubts. Your answers addressed my concerns.

You're welcome.

> I have two more questions.

[Huub] OK.

> This is with respect to the link failure example in the Wrapping solution as described in section 3.1.2.1. As proposed by the solution, when a failure occurs on the link between B and C, the traffic flow and the label usage are as below:
A[W1]->B[P6]->A[P1]->F[P2]->E[P3]->D[P4]->C[W3]->D

[Huub] Indeed.

> Consider the case where the packet has traversed the ring on the protection path (...D[P4]->C) and is now at node C. At this point in time, if the link between B and C comes back up again, i.e., it is operational again, then;

[Huub] do you mean: the failure on the section B C is repaired and the defect (e.g SF) has cleared, and the WTR (wait-to-restore) timer expired?

At that moment the traffic from W2 is forwarded to W3 again and the forwarding of P4 to W3 is disabled.

1) Will the node C swap the label it receives (P4) with the protection label P3 and forward the packet to B? If so, there is a possibility that the packet continues to traverse the ring via the protection path in the loop, or;

[Huub] indeed the traffic from P4 is forwarded to P3, but note that the TTL will be decremented, and the packet discarded when TTL==0, so it will not loop forever.

2) Will the node C always swap the label it receives (P4) with the working label W3 and forward the packet to D irrespective of whether there is a failure on the link between C and B?



[Huub] no that is not the case, because that would mean that packets are duplicated at C if the trafic P4 is merged with traffic W2 into W3. Also, because the Protection LSPs are shared on the ring, these LSPs should only be used during a protection switch.

Best reagrds, Huub.

________________________________
From: Huub helvoort <huub.van.helvoort@huawei.com>
To: Naveen T <naveen.thanikachalam@yahoo.in>; MRPS Helvoort <draft-helvoort-mpls-tp-ring-protection-switching@tools.ietf.org>
Sent: Monday, 4 February 2013 6:50 PM
Subject: RE: [mpls] Doubts on draft-helvoort-mpls-tp-ring-protection-switching-03



Dear Naveen,

Thank you very much for your patience.

The last two weeks I have been traveling, and email access was very limited.

Please find below the answers to your questions [Huub].

> The proposed solution recommends the usage of section layer OAM to find signal failures on a link. Since the two nodes will be able to detect failures at either end of a link using the link OAM, why would it be a necessity to send the APS payload to the adjacent node in the direction opposite to the failure?

[Huub] The nodes at each side of a section (e.g. Nodes A and B) can detect failures. However the failure may have occurred only in one direction, e.g node A --> B, the APS message s used to informA that B has detected a failure and will switch to protection, A will have to switch to protection too.
[Huub] also if a node fails e.g. node B located between nodes A and C then both A and C will detect the failure of
the section connecting them to B, and they have to inform the other side C resp. A that they will perform a protectiuoin switch based on the detected failure.
[Huub] there may be more than a single section or node failure in the ring, all the nodes in the ring have to be aware of the failure and its location to take proper protection switch consequent actions.

> If the switching commands Lockout, Manual Switch and Forced Switch are taken out of the equation, and assuming that a signal failure will be the only reason considered for a switch-over, will it still be necessary to use the APS protocol at all?

[Huub] also in this case the APS messages sent colockwise and counter-clockwise will be necessary to inform all the nodes in the ring of the fault location and the switch action. There may be point-to-multipoint connections on the ring, and each node has to decide wich signal should be used.

I hope this addresses your concerns.

Best regards, Huub.

--
================================================================
Always remember that you are unique...just like everyone else...