[PWE3] clarification on draft-shen-pwe3-endpoint-fast-protection

Yimin Shen <yshen@juniper.net> Mon, 02 April 2012 22:41 UTC

Return-Path: <yshen@juniper.net>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2461421F85ED for <pwe3@ietfa.amsl.com>; Mon, 2 Apr 2012 15:41:59 -0700 (PDT)
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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-M5PBOo0zRY for <pwe3@ietfa.amsl.com>; Mon, 2 Apr 2012 15:41:58 -0700 (PDT)
Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id DC86621F85D6 for <pwe3@ietf.org>; Mon, 2 Apr 2012 15:41:48 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKT3orLETs8IrEHyVpsYVJGHyInNqKjmne@postini.com; Mon, 02 Apr 2012 15:41:56 PDT
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 2 Apr 2012 15:41:48 -0700
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 2 Apr 2012 18:41:47 -0400
From: Yimin Shen <yshen@juniper.net>
To: "draft-shen-pwe3-endpoint-fast-protection@tools.ietf.org" <draft-shen-pwe3-endpoint-fast-protection@tools.ietf.org>
Date: Mon, 02 Apr 2012 18:41:44 -0400
Thread-Topic: clarification on draft-shen-pwe3-endpoint-fast-protection
Thread-Index: Ac0RIceimIGYuhmjS36uZMx4y1+LCQ==
Message-ID: <DF7F294AF4153D498141CBEFADB17704C70D88E727@EMBX01-WF.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "pwe3@ietf.org" <pwe3@ietf.org>
Subject: [PWE3] clarification on draft-shen-pwe3-endpoint-fast-protection
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pwe3>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 22:41:59 -0000

Hi,

I'd like thank all your valuable comments on this draft during IETF. This email is a follow-up to the discussions.

What this draft specifies is a local repair mechanism that can be used by a router (i.e. PLR) immediately upstream of a PW egress endpoint failure to protect PW traffic. Essentially, the PLR sets up a bypass tunnel (of any type, such as MPLS tunnel) to a protector, in anticipation of a failure. When the failure happens, the PLR will simply redirect PW packets to the protector via this bypass tunnel. The PW packets will have the original PW label unchanged. Hence, the protector will forward the packets to the target CE based the PW label (i.e. upstream assigned label) by using the context-specific label switching technique. 

The advantage of this local repair mechanism is the capability of fast restoration in the order of 10s of milliseconds. This is because both failure detection and packet redirection are performed at the PLR that is directly adjacent to the failure.

Of course, since there is a link/node failure in the network, global repair (i.e. reroute of transport tunnel or switch to a backup tunnel by ingress PE) or control-plane repair (i.e. reroute of transport tunnel by intermediate transit router) may also follow the failure event. However, these procedures are driven by routers that are not adjacent to the failure, and they may dependent on control plane convergence. Therefore, they are relatively slow, compared to the local repair mechanism. 

Note that before a global repair or control-plane repair takes an effect, PW traffic is protected by the local repair mechanism without any loss. IOW, PW traffic continues to flow over the original transport tunnel to the PLR where it then flows over the bypass tunnel to the protector and then towards the CE. 

When the global repair or control-plane repair kicks in, PW traffic will be switched to use a new transport tunnel or a new path, and traffic over the bypass tunnel will drain out eventually. In this case, packet re-ordering may occur before the PW packets completely drain out over the bypass tunnel. However, this is not an issue specific to this local repair mechanism, but rather a common/generic issue when traffic is switched from one transport tunnel to another transport tunnel. IOW, a short window is always needed for the traffic to drain out over the old tunnel. Therefore, it should not be considered as an issue of this draft.

Hope I have clarified the difference and relationship between local repair and global/control-plain repair. 

Please continue to provide your comments and suggestions through email. Thanks in advance!



Thanks,

-Yimin Shen
 Juniper Networks