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

Yimin Shen <yshen@juniper.net> Tue, 12 August 2014 15:24 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 579B61A03F1 for <pwe3@ietfa.amsl.com>; Tue, 12 Aug 2014 08:24:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 klXpuqIzlgHE for <pwe3@ietfa.amsl.com>; Tue, 12 Aug 2014 08:24:32 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EE061A03E4 for <pwe3@ietf.org>; Tue, 12 Aug 2014 08:24:31 -0700 (PDT)
Received: from BY2PR05MB222.namprd05.prod.outlook.com (10.242.41.151) by BY2PR05MB744.namprd05.prod.outlook.com (10.141.223.148) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Tue, 12 Aug 2014 15:24:30 +0000
Received: from BY2PR05MB728.namprd05.prod.outlook.com (10.141.223.25) by BY2PR05MB222.namprd05.prod.outlook.com (10.242.41.151) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Tue, 12 Aug 2014 15:24:27 +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; Tue, 12 Aug 2014 15:24:27 +0000
From: Yimin Shen <yshen@juniper.net>
To: "Stewart Bryant (stbryant)" <stbryant@cisco.com>
Thread-Topic: [PWE3] WG Last Call for draft-ietf-pwe3-endpoint-fast-protection-01
Thread-Index: AQHPqByPzRsIO8QlbkK+kbMBZ9MDf5u3AuAAgAAZ0oCAABjewIABFRcAgADf/TCACF0AgIAA3TgQgADA4ICAADbOAIAAzcgwgAEfc4CAAYjQ4IACkWQAgABFdICAABBsAIACOATwgAAUOYCAASozwA==
Date: Tue, 12 Aug 2014 15:24:27 +0000
Message-ID: <fbe4066b005742d2a5ab10cd6cc3af91@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>, <379439d133a548a29a8d5193c9e2620f@BY2PR05MB728.namprd05.prod.outlook.com> <5C6C292D-0DC7-4B96-A24C-026BA778EE27@cisco.com>
In-Reply-To: <5C6C292D-0DC7-4B96-A24C-026BA778EE27@cisco.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:;UriScan:;
x-forefront-prvs: 0301360BF5
x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(164054003)(52604005)(377454003)(189002)(252514010)(199003)(110136001)(21056001)(93886004)(85306004)(4396001)(95666004)(66066001)(99286002)(19300405004)(106116001)(105586002)(106356001)(64706001)(85852003)(33646002)(19609705001)(20776003)(18717965001)(101416001)(15202345003)(86362001)(2656002)(31966008)(74662001)(79102001)(77982001)(76482001)(46102001)(92566001)(16236675004)(76176999)(50986999)(87936001)(19625215002)(83072002)(19580405001)(81342001)(15975445006)(80022001)(99396002)(74502001)(54356999)(74316001)(107046002)(83322001)(81542001)(76576001)(19580395003)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR05MB222; H:BY2PR05MB728.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_fbe4066b005742d2a5ab10cd6cc3af91BY2PR05MB728namprd05pro_"
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/pwe3/B56gW27xIvOk82Pf4ZoPQvaOkSo
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: Tue, 12 Aug 2014 15:24:40 -0000

Hi Stewart,

Thanks for pointing this out. We will explicitly describe these cases in the draft. Even if traffic may arrive at CE on both ACs, it should not cause an issue for the CE, because either the CE doesn't care about packet order (case A), or packet order of sub-flow associated with a FAT label is still preserved (case B).


Thanks,

/Yimin


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



Sent from my iPad

On 11 Aug 2014, at 22:53, "Yimin Shen" <yshen@juniper.net<mailto:yshen@juniper.net>> wrote:
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.

Only when

A) the CW is present

and

B) there is no FAT label, or I suppose no EL if you chose to do it that way.

The point is that with some PEs you only care about flow order not absolute order.

If you want to put them out of scope then fine, but you have to either explicitly state the restriction, or fix the problem, and without taking either of those approaches you get traffic split over both ACs.

Stewart


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<mailto: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