Re: [PWE3] Poll for WG adoption of draft-shen-pwe3-endpoint-fast-protection-04

Yimin Shen <yshen@juniper.net> Tue, 03 September 2013 15:25 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 49A3921E8120 for <pwe3@ietfa.amsl.com>; Tue, 3 Sep 2013 08:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 UrjmcbksF0dk for <pwe3@ietfa.amsl.com>; Tue, 3 Sep 2013 08:25:28 -0700 (PDT)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 90E5521E814E for <pwe3@ietf.org>; Tue, 3 Sep 2013 08:25:28 -0700 (PDT)
Received: from mail150-co1-R.bigfish.com (10.243.78.240) by CO1EHSOBE001.bigfish.com (10.243.66.64) with Microsoft SMTP Server id 14.1.225.22; Tue, 3 Sep 2013 15:25:27 +0000
Received: from mail150-co1 (localhost [127.0.0.1]) by mail150-co1-R.bigfish.com (Postfix) with ESMTP id E15F15C0085; Tue, 3 Sep 2013 15:25:27 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -23
X-BigFish: VPS-23(zz9371I542Iec9I1432I4015Idb82hzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275dhz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h9a9j1155h)
Received-SPF: pass (mail150-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=yshen@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(199002)(51704005)(164054003)(37854004)(377454003)(13464003)(19580405001)(83322001)(19580395003)(46102001)(65816001)(80022001)(66066001)(51856001)(69226001)(561944002)(80976001)(81342001)(81542001)(49866001)(50986001)(47976001)(47736001)(4396001)(74662001)(47446002)(74502001)(31966008)(74316001)(33646001)(81686001)(15975445006)(77096001)(56816003)(54316002)(76796001)(76576001)(59766001)(76786001)(53806001)(56776001)(77982001)(54356001)(76482001)(74366001)(83072001)(79102001)(63696002)(74876001)(74706001)(81816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB046; H:BY2PR05MB046.namprd05.prod.outlook.com; CLIP:66.129.232.2; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Received: from mail150-co1 (localhost.localdomain [127.0.0.1]) by mail150-co1 (MessageSwitch) id 1378221925784046_20441; Tue, 3 Sep 2013 15:25:25 +0000 (UTC)
Received: from CO1EHSMHS016.bigfish.com (unknown [10.243.78.237]) by mail150-co1.bigfish.com (Postfix) with ESMTP id B1FDC400041; Tue, 3 Sep 2013 15:25:25 +0000 (UTC)
Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS016.bigfish.com (10.243.66.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 3 Sep 2013 15:25:24 +0000
Received: from BY2PR05MB046.namprd05.prod.outlook.com (10.242.34.144) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.353.4; Tue, 3 Sep 2013 15:25:24 +0000
Received: from BY2PR05MB046.namprd05.prod.outlook.com (10.242.34.144) by BY2PR05MB046.namprd05.prod.outlook.com (10.242.34.144) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 3 Sep 2013 15:25:21 +0000
Received: from BY2PR05MB046.namprd05.prod.outlook.com ([169.254.10.19]) by BY2PR05MB046.namprd05.prod.outlook.com ([169.254.10.37]) with mapi id 15.00.0745.000; Tue, 3 Sep 2013 15:25:20 +0000
From: Yimin Shen <yshen@juniper.net>
To: Mingui Zhang <zhangmingui@huawei.com>, "pwe3@ietf.org" <pwe3@ietf.org>
Thread-Topic: [PWE3] Poll for WG adoption of draft-shen-pwe3-endpoint-fast-protection-04
Thread-Index: AQHOqEg/QjaSOHZOMUa0SQ37ViDvZZm0FlFA
Date: Tue, 03 Sep 2013 15:25:19 +0000
Message-ID: <301ab3c60e124f208b01ecb9df497eb3@BY2PR05MB046.namprd05.prod.outlook.com>
References: <CE466A08.4F679%matthew.bocci@alcatel-lucent.com> <4552F0907735844E9204A62BBDD325E7336131DB@nkgeml508-mbx.china.huawei.com>
In-Reply-To: <4552F0907735844E9204A62BBDD325E7336131DB@nkgeml508-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.232.2]
x-forefront-prvs: 09583628E0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: Re: [PWE3] Poll for WG adoption of draft-shen-pwe3-endpoint-fast-protection-04
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: Tue, 03 Sep 2013 15:25:42 -0000

Hi Mingui,

Thanks for your questions. Please inline...


Thanks,

-Yimin


-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Mingui Zhang
Sent: Monday, September 02, 2013 9:51 PM
To: pwe3@ietf.org
Subject: Re: [PWE3] Poll for WG adoption of draft-shen-pwe3-endpoint-fast-protection-04

Hi, 

I have read the draft and have the following comments and questions. 

1. When I read the ICCP draft and RFC 6718, I thought PW-RED offered the mechanism for PE and AC protection. Is there any difference between the solution here and the PW-RED?

[yshen] Yes, the difference is that PW redundancy (RFC 6718) is a global repair mechanism driven by control plane's reactions to failures, while the proposal in this draft is a local repair mechanism driven by data plane. In the later case, bypass path is pre-installed in the data plane, and invoked by a rapid failure detection. As described in the draft, these two mechanisms can really work in tandem and complement each other. IOW, the local repair performs a fast but temporary restoration for traffic, and PW redundancy moves traffic to another permanent and fully functional PW, at a relatively slower pace.
 
2. Whether providers need manually configure the protector?

[yshen] A certain amount of provisioning is expected on the protector, e.g. context ID, etc. But the detail is vendor specific.


3. There seems no detail for the proxy method to be followed by the implementers. Add a reference here or elaborate it?

[yshen] The draft provides a guideline for the proxy mode as below. This is because this mode doesn't require any IGP extension, it's generic, and it is not something new. You may find a little more detail in draft-minto-rsvp-lsp-egress-fast-protection. 

" One approach would be to advertise it as a
   virtual proxy node connected to both routers, with the link between
   the proxy node and the primary PE having a more preferable IGP or TE
   metric than the link between the proxy node and the protector."


4. I am glad to see there is some text talking about the " Revertive Behavior ". I was designing a protection mechanism before, knowing that this is not an easy problem to be solved. If the PLR revert to the new primary PW ahead of time (before the convergence). Loops or packet loss may happen. I remember I was asked by the question: how does the PLR determine the time to revertive? Timers are what I can think of. I wonder whether there is any better idea. 

[yshen] Local reversion should be triggered by control plane re-convergence after the failed link/node has been recovered. There should be no loop from the perspective of this draft.


5. A minor issue. What is "control plane repair"? See para3 of the introduction. I think both global repair and local repair involves both data plane and control plane behaviors. 

[yshen] The important question is - Who drives the traffic repair in the first place ? If it's the data plane that drives it purely based on link layer failure detection, it is local repair. If it is the control plane protocol (RSVP, LDP, IGP) on the adjacent router of the failure, it is called "control plane repair". If it is the control plane on the ingress router (i.e. PE), it is global repair. Of course, C-plane will slowly converge on the new topology caused by the failure, and eventually be update D-plane, but local repair should happen way before that, within 50 ms.


If I missed anything, please correct me.

Thanks,
Mingui


>-----Original Message-----
>From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of 
>Bocci, Matthew (Matthew)
>Sent: Friday, August 30, 2013 10:26 PM
>To: pwe3@ietf.org
>Subject: [PWE3] Poll for WG adoption of
>draft-shen-pwe3-endpoint-fast-protection-04
>
>This email begins a two week poll to help the chairs determine if there 
>is consensus to adopt draft-shen-pwe3-endpoint-fast-protection-04 as an 
>PWE3 working group draft.
>
>The draft can be found here:
>http://tools.ietf.org/id/draft-shen-pwe3-endpoint-fast-protection-04.tx
>t
>
>Please read the draft and indicate to the list if you support adoption, 
>or if you do not support adoption (giving reasons).
>
>Please note that this is only a call for adoption. There needs to be 
>consensus that this draft is a good basis for the work, but it does not 
>need to be perfect at this stage.
>
>The poll for adoption will close in two weeks time, on Friday 13th September.
>
>Best regards,
>
>Matthew
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3