Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01

Yimin Shen <yshen@juniper.net> Mon, 11 August 2014 20:53 UTC

Return-Path: <yshen@juniper.net>
X-Original-To: pwe3@ietfa.amsl.com
Delivered-To: pwe3@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A141A00E2 for <pwe3@ietfa.amsl.com>; Mon, 11 Aug 2014 13:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRrDFen0G7By for <pwe3@ietfa.amsl.com>; Mon, 11 Aug 2014 13:53:55 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE291A00D8 for <pwe3@ietf.org>; Mon, 11 Aug 2014 13:53:55 -0700 (PDT)
Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB223.namprd05.prod.outlook.com (10.242.41.141) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Mon, 11 Aug 2014 20:53:52 +0000
Received: from BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) by BY2PR05MB728.namprd05.prod.outlook.com ([10.141.223.25]) with mapi id 15.00.1005.008; Mon, 11 Aug 2014 20:53:52 +0000
From: Yimin Shen <yshen@juniper.net>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "Stewart Bryant (stbryant)" <stbryant@cisco.com>
Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01
Thread-Index: AQHPqByPzRsIO8QlbkK+kbMBZ9MDf5u3AuAAgAAZ0oCAABjewIABFRcAgADf/TCACF0AgIAA3TgQgADA4ICAADbOAIAAzcgwgAEfc4CAAYjQ4IACkWQAgABFdICAABBsAIACOATw
Date: Mon, 11 Aug 2014 20:53:51 +0000
Message-ID: <379439d133a548a29a8d5193c9e2620f@BY2PR05MB728.namprd05.prod.outlook.com>
References: <201407251524.s6PFOPn92012@magenta.juniper.net> <53D79504.4050904@cisco.com> <a8d070daae424ec0b9f338edfd0cde7c@AM3PR03MB612.eurprd03.prod.outlook.com> <04f15bedf2be4c7480d3e9ca01bdfd7f@BY2PR05MB728.namprd05.prod.outlook.com> <2597291f7b074922b690e4b06999cf1a@AM3PR03MB612.eurprd03.prod.outlook.com>, <30e13900814f41a681151971cbe9ebef@BY2PR05MB728.namprd05.prod.outlook.com> <1407215578702.64387@ecitele.com>, <2280b8e0d5f94a60badab91a2237181b@BY2PR05MB728.namprd05.prod.outlook.com> <1407304503657.72312@ecitele.com> <f8c4d4382dda4f7d94ce61b4b421fe4f@AM3PR03MB612.eurprd03.prod.outlook.com> <046050cb2d254a139b4650b2d7f93075@BY2PR05MB728.namprd05.prod.outlook.com> <09ab595ab24a46a0a4e87ebeb2cd185a@AM3PR03MB612.eurprd03.prod.outlook.com>, <2afb5c963e054aef929f38dcb3defa07@BY2PR05MB728.namprd05.prod.outlook.com>, <1407647722694.18724@ecitele.com> <004289D0-C473-4C1D-8A76-B42757F599A2@cisco.com> <ee672591563c40fda0cd2debd238db26@AM3PR03MB612.eurprd03.prod.outlook.com>
In-Reply-To: <ee672591563c40fda0cd2debd238db26@AM3PR03MB612.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.10]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;
x-forefront-prvs: 03008837BD
x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(164054003)(189002)(199002)(252514010)(74316001)(76176999)(20776003)(15975445006)(50986999)(16236675004)(106116001)(18717965001)(64706001)(76482001)(101416001)(81342001)(74502001)(74662001)(31966008)(80022001)(81542001)(19609705001)(66066001)(105586002)(85306004)(106356001)(99396002)(92566001)(107046002)(93886004)(86362001)(85852003)(77982001)(19625215002)(15202345003)(76576001)(19300405004)(95666004)(33646002)(19580405001)(99286002)(2656002)(21056001)(19580395003)(54356999)(46102001)(83072002)(87936001)(83322001)(79102001)(4396001)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB223; H:BY2PR05MB728.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_379439d133a548a29a8d5193c9e2620fBY2PR05MB728namprd05pro_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/1ZJ4g9hcKa7SSUV1dfBEDJ5PXs0
Cc: Yakov Rekhter <yakov@juniper.net>, "Eric Rosen \(erosen\)" <erosen@cisco.com>, "pwe3@ietf.org" <pwe3@ietf.org>
Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Pseudowire Emulation 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, 11 Aug 2014 20:53:59 -0000

Hi Stewart, Sasha,

In LDP, a transit router may have ECMP to a give FEC (of egress PE), as you mentioned. If this LSP carries multiple PWs, the hash algorithm on the router should map a given PW to one and only one path, in order to preserve packet order on the egress PE.

Let's look at an example in the context of this draft. Suppose this transit router has 3 ECMP to the primary egress PE. On path_1 and path_2, the router is the penultimate hop, most likely because this router has 2 parallel links to the primary PE. On path_3, it is not the penultimate hop, because there are other downstream routers. Also, suppose there are 3 PWs to the egress PE, and the hash algorithm has mapped PW_1 to path_1, PW_2 to path_2, and PW_3 to path_3. Hence, this router serves as PLR for PW_1 and PW_2, but not for PW_3.

The PLR will set up a bypass tunnel to protect PW_1 and PW_2.  (Theoretically it could also set up 2 bypass tunnels to protect PW_1 and PW_2 separately, but it doesn't really matter here). The PLR will then attach the bypass as a backup nexthop to Path_1, and a backup nexthop to Path_2.

Now, the PLR detects a link failure over Path_1. In the dataplane, the PLR reacts to this event by moving PW_1's packets to the bypass. It will not do anything for PW_2 or PW_3, because their paths are still up. IOW, PW_2 and PW_3 are not affected. From CE's perspective, the CE will be receiving PW_1's traffic over the backup AC, while continuing to receive PW_2 and PW_3's traffic over the primary AC.

Likewise, if the router detects a failure of PW_2 or PW_3, the other 2 PWs will not be affected.

Thanks,

/Yimin


From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Sunday, August 10, 2014 6:23 AM
To: Stewart Bryant (stbryant)
Cc: Yimin Shen; Yakov Rekhter; pwe3@ietf.org; Eric Rosen (erosen)
Subject: RE: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01

Stewart,

My reading of your email is like following:

1.       Within the scope of the draft the PLR is always the penultimate P LSR on the LSP terminated by the Primary PE. I believe that the draft states that explicitly

2.       The PLR cannot differentiate between the failure of the link connecting it to the Primary PE and failure of the Primary PE in a timely manner; hence every time such a link fails, the PLR assumes failure of the Primary PE to be on the safe side. T

3.       With ECMP in the PSN, there typically would be several LSPs terminated by the Primary PE, each with its own PLR. So if the link between one of these PLRs and the Primary PE fails, it would apply the mechanisms defined in the draft, while the rest of the PLRs would not do anything.

4.       As a consequence, the dual-homed PE would receive some flows of the traffic crossing a flow-aware pw from one AC and some - from the other AC.  The draft does not specify that this is possible and that the CE should be able to cope with this situation.

Is my interpretation correct?

Regards,
       Sasha
Email: Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>
Mobile: 054-9266302

From: Stewart Bryant (stbryant) [mailto:stbryant@cisco.com]
Sent: Sunday, August 10, 2014 12:24 PM
To: Alexander Vainshtein
Cc: Yimin Shen; Yakov Rekhter; pwe3@ietf.org<mailto:pwe3@ietf.org>; Eric Rosen (erosen)
Subject: Re: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01


ECMP paths to xPEs naturally form and disappear in LDP PSNs (they are a fundamental property of that PSN type) and it is entirely normal  to find an ECMP to an xPE.

So, if you have a PW that is load balancing (again quite normal) and one of the attachments to the xPE fails, you can legitimately end  up with some traffic on one egress AC and some on another.

please you confirm that this design works correctly when a PE gets its traffic from both ACs?

Stewart