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

Naveen T <naveen.thanikachalam@yahoo.in> Thu, 07 February 2013 05:29 UTC

Return-Path: <naveen.thanikachalam@yahoo.in>
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 7134721E8047 for <mpls@ietfa.amsl.com>; Wed, 6 Feb 2013 21:29:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.641
X-Spam-Level:
X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, J_CHICKENPOX_15=0.6]
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 mklxtZ41l7lu for <mpls@ietfa.amsl.com>; Wed, 6 Feb 2013 21:29:02 -0800 (PST)
Received: from nm25-vm3.bullet.mail.sg3.yahoo.com (nm25-vm3.bullet.mail.sg3.yahoo.com [106.10.151.98]) by ietfa.amsl.com (Postfix) with ESMTP id 9568021F84D1 for <mpls@ietf.org>; Wed, 6 Feb 2013 21:28:56 -0800 (PST)
Received: from [106.10.166.119] by nm25.bullet.mail.sg3.yahoo.com with NNFMP; 07 Feb 2013 05:28:48 -0000
Received: from [106.10.150.26] by tm8.bullet.mail.sg3.yahoo.com with NNFMP; 07 Feb 2013 05:28:46 -0000
Received: from [127.0.0.1] by omp1027.mail.sg3.yahoo.com with NNFMP; 07 Feb 2013 05:28:46 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 172796.85467.bm@omp1027.mail.sg3.yahoo.com
Received: (qmail 1083 invoked by uid 60001); 7 Feb 2013 05:28:46 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.in; s=s1024; t=1360214926; bh=5TAv7nFdxC3yjKh9MvNpRHFIlDjFlsHAkQAwDGml9L0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mjOOu9JXVjsreN24Tr1e3uJLkwSLQ0IpG59Qlw5J/whf6mneDgHAmIUiFgu3DUWvni4QnmMcubK8SDsOdlO9edGStV1dVtuSKeMw4hjn2ERQjvJNR3F1Hjh1bA8naXKflP0++Kap+TYHqMSixYJB4N90IPwFkyLaYERYIFv9i08=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.in; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=f1P0B4uPK62p45/XHDKmmxKSowj++v0My2gk4FtWMgS3hajYkVB76WtbUf3aZOL73xDuWZtYkCf7Zj7q+smuGiz/y6zha1uMuQvbA3IklTZt/eHe2lJZAT1RxZRauPg1pVY/oWDNLX5GuwZi51yJq763s/TUqzjndM72NpeUROg=;
X-YMail-OSG: yS5f_OUVM1nV3Nk_BMi5_BQL8sG1HOMxBz5Uc0r9Vx2ROBw .q9LQfkvyY9Fw5f1Lc8Wze3Hqc0UvTxI5hFOZmFX6ZZYTquCcyi_zrI17kic BfsELCNx29O7oI3bgtNO5q9PEf1tBdRpsIypl5BspdSYYsGXGnhno7DarobH cz355o8Ok1JiCO21noJ26AhL05FRjGnwxS3GhrJ4kCnH6TL4bbVDvAxfMTAr dfhK8eHX.pwcjdvTfiqAOA6jdYoTw8JhTC_8D1co_Ylr_2VIXjW2UEJ.nXot f.pkBCSbgy0Wue0V7nrFrOm8TQ.ifM13BoEfVGCifTqMRET_cLVdbOnM2la_ D9eSlxWmGqzYLzQUOCaMcMRbLGzZ7jWyuGTIZNiTe3OktIZWUFPypzzh_7lS p891w5DL6W8xPULdqCM28Lm0STIar6GflQ87SIZrlOX6zMefNH9tPuc7GCdk SJPU-
Received: from [115.112.61.194] by web190901.mail.sg3.yahoo.com via HTTP; Thu, 07 Feb 2013 13:28:45 SGT
X-Rocket-MIMEInfo: 001.001, RGVhciBIdXViLMKgCkNvbnNpZGVyaW5nIHRoZSB0b3BvbG9neSBiZWxvdywgSSBoYXZlIGEgcXVlc3Rpb24uCgrCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCArLS0tLS0rIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgICstLS0tLSsKwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqB8IMKgRiDCoHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwgwqBBIMKgfC0tLS0tLS0tLS0tLS0BMAEBAQE-
X-Mailer: YahooMailWebService/0.8.132.503
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> <73E555AA235F3846B8051DB38C8776272E5ACFEC@lhreml509-mbx>
Message-ID: <1360214925.97363.YahooMailNeo@web190901.mail.sg3.yahoo.com>
Date: Thu, 07 Feb 2013 13:28:45 +0800
From: Naveen T <naveen.thanikachalam@yahoo.in>
To: Huub helvoort <huub.van.helvoort@huawei.com>, MRPS Helvoort <draft-helvoort-mpls-tp-ring-protection-switching@tools.ietf.org>, MPLS <mpls@ietf.org>
In-Reply-To: <73E555AA235F3846B8051DB38C8776272E5ACFEC@lhreml509-mbx>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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
Reply-To: Naveen T <naveen.thanikachalam@yahoo.in>
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: Thu, 07 Feb 2013 05:29:03 -0000

Dear Huub, 
Considering the topology below, I have a question.

                                      +-----+                         +-----+
                                       |  F  |--------------------------|  A  |--------------- LSP 1
                                      +-----+                         +-----+ 
                                      /                                         \
                                     /                                           \
                                    /                                             \
                            +-----+                                              +-----+
                             |  E  |                                               |  B  |
                            +-----+                                              +-----+
                                    \                                              /
                                     \                                            /
                                      \                                          /
                                      +-----+                         +-----+
              LSP 1 ---------------|  D  |--------------------------|  C  |
                                      +-----+                         +-----+ 

In case of an associated bidirectional path, the forward and reverse path LSPs may span between the same end pointsbut via different transit nodes.

Let's consider the forward path of the LSP 1 as: A->B->C->D (Clockwise direction) and, thereverse path of the LSP 1 as: D->E->F->A (Clockwise direction).
With this topology, if the link between B->C fails, then, only the forward path LSP will be affected and APS PDUs will be sent via the protection path from B->C and C->B to inform each other of the signal failure and eventually, the traffic on the forward path LSP will be switched to the protection path.
However, the reverse path LSP, D->E->F->A, will not be affected by the link failure between B->C

In this scenario, will there be a necessity to switch the traffic on the reverse path (unaffected by the signal failure between B->C) LSP to the protection path? 
Or, willit be sufficient to switch just the traffic on the forward path LSP to the protection path and leave the traffic on the reverse path LSP as it is?

If traffic on both the forward and reverse path LSPs are switched to the protection path, then, it is bidirectional switching.
But, if only the traffic on the affected LSP is switched on to the protection path, then, it is unidirectional switching.
Does this draft recommend unidirectional switching?
Thanks and Regards,
Naveen T

________________________________
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> 
Sent: Monday, 4 February 2013 8:24 PM
Subject: RE: [mpls] Doubts on draft-helvoort-mpls-tp-ring-protection-switching-03



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 onthe section B C is repaired and the defect (e.gSF) 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 traficP4 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
nodein the direction opposite to the failure?

[Huub] The nodes ateach side of a section (e.g. Nodes A and B) can detect failures. However the failure may have occurred only in one direction, e.gnode A --> B, the APS message sused to informAthat 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. nodeB located between nodes A and C then both A and C will detect the failure of
thesection connecting them to B, and they have to inform the other side C resp. A that they will perform a protectiuoinswitch 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 protectionswitch 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 colockwiseand 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 wichsignal should be used.

I hope this addresses your concerns.

Best regards, Huub.

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