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

Huub van Helvoort <huubatwork@gmail.com> Fri, 08 February 2013 22:40 UTC

Return-Path: <huubatwork@gmail.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 8241621F8BD4 for <mpls@ietfa.amsl.com>; Fri, 8 Feb 2013 14:40:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 R7KSjWmpbPTT for <mpls@ietfa.amsl.com>; Fri, 8 Feb 2013 14:40:28 -0800 (PST)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id 76FC121F8B64 for <mpls@ietf.org>; Fri, 8 Feb 2013 14:40:28 -0800 (PST)
Received: by mail-wi0-f176.google.com with SMTP id hm14so1438345wib.3 for <mpls@ietf.org>; Fri, 08 Feb 2013 14:40:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:disposition-notification-to:date:from :reply-to:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=DpPATMFIoQzGUNQhQ4HIMqSnFPQdv0qkKKxxe8HA1pM=; b=fShrBLJLzEb4nQ/dw2P5pN6dUHTqewhB028UtCD5GVkz5/ugRm/Hlx4n46Rx/IXP6i eoyYEV1zmheuTOk8o0PGw6injV0/dm/YPmWawmOSw+OWNkWOrF5K0sRDGP2ItTf+0uqd EbaxBUiHVY/fwa/TOLepWofOnylZLcNxi/K7XS5/4V0vqfdQOZk9tk7rarK7lWJmD5RI AjDnljepHUn23LvAUlTdKzSbxKLR3m/EyProa8Tx3nLd2RPTRccMYf6P6V7/WJoe6KUB CU6YB92PV5DRuoVei+D04kjKXlLYIyFSD1v2O4WrXXDteri6WkIpNKHz5TB/7Nn/fbY8 SvSA==
X-Received: by 10.180.85.8 with SMTP id d8mr5244506wiz.4.1360363227312; Fri, 08 Feb 2013 14:40:27 -0800 (PST)
Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPS id l3sm18167647wiy.8.2013.02.08.14.40.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 14:40:26 -0800 (PST)
Message-ID: <51157ED8.70809@gmail.com>
Date: Fri, 08 Feb 2013 23:40:24 +0100
From: Huub van Helvoort <huubatwork@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Naveen T <naveen.thanikachalam@yahoo.in>
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> <1360214925.97363.YahooMailNeo@web190901.mail.sg3.yahoo.com>
In-Reply-To: <1360214925.97363.YahooMailNeo@web190901.mail.sg3.yahoo.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: MRPS Helvoort <draft-helvoort-mpls-tp-ring-protection-switching@tools.ietf.org>, MPLS <mpls@ietf.org>
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: huubatwork@gmail.com
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: Fri, 08 Feb 2013 22:40:29 -0000

Dear Naveen,

You write:

> 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.

In Transport Networks in general co-routed bidirectional path are used.
This has the advantage that the propagation delay is the same in
forward and backward direction. In general the shortest path will be
configured around the ring.

> Let's consider the forward path of the LSP 1 as: A->B->C->D (Clockwise
> direction) and, the reverse 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

Indeed.

> 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?

In your scenario the traffic on the reverse path will not be switched
because the wrapping of all working traffic to the protection LSPs and
back will take place only in nodes B and C.

> Or, will it 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?

I would not say it is sufficient, but is is due to the way traffic
is wrapped. Not only LSP1 but all working traffic between B and C
is wrapped.

> If traffic on both the forward and reverse path LSPs are switched to
 > the protection path, then, it is bidirectional switching.

Indeed, but again: only the forward and reverse working traffic between
nodes B and C is switched to the protection LSPs.

> But, if only the traffic on the affected LSP is switched on to the
 > protection path, then, it is unidirectional switching.

No, the switching is still bi-directional, but in your scenario
only the traffic of LSP1 that passes nodes B and C is switched.

> Does this draft recommend unidirectional switching?

No, it recommends bi-directional switching.
Together with the preference for co-routed bi-dirtectional LSPs
I will capture this in the next rev. of the draft.

Cheers, Huub.


-- 
*****************************************************************
               请记住,你是独一无二的,就像其他每一个人一样