Re: [mpls] Adoption of draft-shen-mpls-egress-protection-framework

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Sat, 09 September 2017 09:32 UTC

Return-Path: <Alexander.Vainshtein@ecitele.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 D7EDC132A1A; Sat, 9 Sep 2017 02:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Level:
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com
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 X8rH4fCISzZ5; Sat, 9 Sep 2017 02:32:05 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A04132E24; Sat, 9 Sep 2017 02:32:05 -0700 (PDT)
Received: from [85.158.138.179] by server-3.bemta-3.messagelabs.com id 35/8D-02046-315B3B95; Sat, 09 Sep 2017 09:32:03 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSfUxNcRjH7++ec+49tQ6/7i09EubQllrJy1Z MXpJpNtb8gSzj3BzdO/elnXPKbdaY1CzvzR+6TKWM8pbeJJktrBeM8lokFFEZyeQlcc49Cf+c fX/P5/v8vs/v7KEJQ6XOn+adEi/YOSur8yTnTKhwhhory+PDv0qRDQ9KyMi2k8VUZNMLLvLSq S/kIjL2sqtdH1tU9E0b+3jnQ30csY6y2E0O50bKfLWwn0huFZ0NGZnEDnREyEaeNImzCOisf6 hXDgaco4W+Vzd16qEDQXXbDZl40DocBWVn2nWK9sEsdNRcQYqJwNcQDJfuphRgxDFQd+uNXjU thfqcvpGGefDreIa7TuJpkJV3GimawQlQPNBKqWkHETxpfu5u8MAL4X6PmobwOBhsOqtVNIH9 oK0rz60BYyiqvUuo2hfedQ5Tqt8EHa8LkFpn4e31HL2qJ0JL3h731IBdeqhpfjoCwqDy0HsZ0 LJeAa5PaaqcChVv16v2D1robXo6khsMHb1nCNWTAP0Fa9XyFmj5nEOp/gcU3Nr3klJBANy9+H Ek94AO8ju73MCAE6Hh2AB5EIW4/nmbS76XwNPhQs0MtTwFDu95qXe5/5c3NOZ2kfmILEFBIi+ k8kLorIgwk2BJMks2zmINnRk+O8zGiyKXxFs5kxiW6LCVIXlttms0qBrturqyDo2ntawvU1NY Hm8YY3JsSjNzonmDkGLlxToUQNMsMFKFzLwFPol3brZY5d37g4H2Yn2Y2+UyZsRkziZaklTUh ObSR1rbh7R0mftbOvhiSGsg7Q477+/HfFMasNJgTrGPXvdnm1vQRH8jgzQajcErmRdsFul/3o P8aMQamVXKVF4WuzSa2iMPpJUHkrpLlYEk7i/y34GWRGSmRFWt2rYgPdp7kuBMf1R8btZFVuA Yn8mxmfvs/WvX0H31ZGpAyY+iZ7WCFzkfBUY35uaen47vnIjRd9c2fw+KK7m3f/FPR+/g9km1 idHdnlFbw6UQz4Qrz0NWbx67LPtmYEyQpmw5+r7w8fG0qi8mQ3Ph2aPLnsQFGxvXzN7LkqKZm xlMCCL3GxA3QIrIAwAA
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-12.tower-169.messagelabs.com!1504949519!114482206!1
X-Originating-IP: [52.27.180.120]
X-StarScan-Received:
X-StarScan-Version: 9.4.45; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 13799 invoked from network); 9 Sep 2017 09:32:02 -0000
Received: from ec2-52-27-180-120.us-west-2.compute.amazonaws.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) (52.27.180.120) by server-12.tower-169.messagelabs.com with AES256-SHA256 encrypted SMTP; 9 Sep 2017 09:32:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Gc875u7Cb6WBj2b6E4W/bzOE3WXh2X4iRQkROO1W3Io=; b=BObbIVXdEp5sGnh55U2iRP7hwo0SM1oBlGGVshFmYt60mngJXyd2G3gEawa1TS3mxEcF6wHTKF0pR3jwaVg6KY0ziZvuVSuos1DYrWBEgznamYEdp8JklNdZiJGOUuMd1MCzlBg7aj+qsoC5N14ntA61jPHiIZ9v7SFRPKykSCw=
Received: from AM4PR03MB1713.eurprd03.prod.outlook.com (10.167.88.15) by AM4PR03MB1634.eurprd03.prod.outlook.com (10.165.243.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Sat, 9 Sep 2017 09:31:57 +0000
Received: from AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::f42b:1f96:a353:d871]) by AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::f42b:1f96:a353:d871%13]) with mapi id 15.20.0013.023; Sat, 9 Sep 2017 09:31:57 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Yimin Shen <yshen@juniper.net>
CC: "draft-shen-mpls-egress-protection-framework@ietf.org" <draft-shen-mpls-egress-protection-framework@ietf.org>, Stewart Bryant <stewart.bryant@gmail.com>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: Adoption of draft-shen-mpls-egress-protection-framework
Thread-Index: AdMn4OLyXKADRfUKRCC1lUEYeszmrQA1XPmAACXjlJA=
Date: Sat, 9 Sep 2017 09:31:57 +0000
Message-ID: <AM4PR03MB17138ADF911EA5E2EE81F4859D6A0@AM4PR03MB1713.eurprd03.prod.outlook.com>
References: <AM4PR03MB1713772A4348FC535728B6059D940@AM4PR03MB1713.eurprd03.prod.outlook.com> <CFB8BC8D-06FF-4579-8CCB-06AAF03457FD@juniper.net>
In-Reply-To: <CFB8BC8D-06FF-4579-8CCB-06AAF03457FD@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [109.67.129.151]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR03MB1634; 6:157bzBYFmGSbBbDC42Hf90nQ8ETHYJ3RO4Cw2MNuMLrUc9+RmdidOD1b3fRz1mUL+5ByhxJ9ZdMxkvRKJGAH/XxmPxOYY9bB0da42Y77o6s80XqhxUvYUkp5StIvantHYrnGCRCRJxIFsumvWKA+AJTTChu4dlTz5w8wwT94inRqRP8Kpabe2wFwTovzqvYESyhaMMjk8RR+plnNamqbEOiMmn75HcgNTvgo35hDxytAn8k7elKO/IgYw2XzpiFbZjYUPHx5QbIHlElGTfKH9Cgv+Nq8u6CBwkCXGGQHtZDPFwCJ4grGLEOIIXKG/14VtidgH3EW835cYnAuuCp4Mw==; 5:UH9ayVU001KVEnlWkDlK0DpmhBKVlqthQxGBkBHX4jgZpQSxujFHM7QZ/p9pB4zxFDT6YAmyNH113AOPrJv8mCWknyVEFmuUyf7S8Y/Fa7xNIapUE3gGvU3ExVV/8Bbrjox6ZoH8edV03aJcSOOvPwdg69hZmr5SYpnuqr1jCqw=; 24:vdxo+NsqfXbbiHZu61xjyfMeYy8q3WfbEXqBpu28tby+W4JIBvLVzV4InqPA9TcdS/vrfCaROEBkDW8fpmRqYS6WVw3FEUIo+e+Xe4AxLTM=; 7:V6gpG/Xk8lx7CqJcdIctyWKWWamfPO5LXHr831iVo3lVIeTsPx+URjmysHTcVBIEfTiVXhZf3D8IwGRVQiwZkPcs27cvUlO6UGMy135Dn/3KHwwb7S6hL/EWv2MMzff1Ya84m7EFkOA6+LM0MIKLZWxQIK1hwtJ/8PzrlqNPXpySm+mI7uEYOoc6429u3GghTSqpaoBZ22rnHBWY/i6h8cBQ9OC7SRJGWljkp81hleM=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: a351ad2f-8986-4cc1-8b21-08d4f7659dbf
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR03MB1634;
x-ms-traffictypediagnostic: AM4PR03MB1634:
x-exchange-antispam-report-test: UriScan:(72170088055959)(138986009662008)(279101305709854);
x-microsoft-antispam-prvs: <AM4PR03MB1634ED5C1765C2471E1F3A9D9D6A0@AM4PR03MB1634.eurprd03.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR03MB1634; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR03MB1634;
x-forefront-prvs: 0425A67DEF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(189002)(252514010)(51444003)(43784003)(199003)(101416001)(6436002)(7736002)(305945005)(229853002)(8676002)(81166006)(81156014)(6506006)(86362001)(106356001)(5250100002)(8936002)(102836003)(189998001)(66066001)(230783001)(4326008)(105586002)(97736004)(3846002)(1941001)(6116002)(3660700001)(6246003)(110136004)(8666007)(2906002)(7696004)(53936002)(25786009)(14454004)(9686003)(55016002)(54906002)(33656002)(99286003)(478600001)(53546010)(2900100001)(54356999)(76176999)(50986999)(74316002)(2950100002)(6916009)(5660300001)(72206003)(39060400002)(68736007)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1634; H:AM4PR03MB1713.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Sep 2017 09:31:57.5791 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1634
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/e3M-Z1dBh46S5NLEf89XFJ7zWzI>
Subject: Re: [mpls] Adoption of draft-shen-mpls-egress-protection-framework
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 09 Sep 2017 09:32:08 -0000

Yimin,
Lots of thanks for a prompt response.

The proposed changes to the draft definitely look like going in the right direction to me.
Once the new version of the draft is published, I will look them up and, if necessary, provide more comments.

I hope that the draft will be adopted soon  - it definitely addresses a relevant problem and, as I've said already, defines a solution that, within well-understood scope (local repair of the egress node failure), AFAIK, does not have any alternatives.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

-----Original Message-----
From: Yimin Shen [mailto:yshen@juniper.net] 
Sent: Friday, September 8, 2017 10:23 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>om>; mpls@ietf.org
Cc: draft-shen-mpls-egress-protection-framework@ietf.org; Stewart Bryant <stewart.bryant@gmail.com>
Subject: Re: Adoption of draft-shen-mpls-egress-protection-framework

Hi Sasha,

Thanks for your detailed review, and kind suggestions and support for this draft!

Please see inline for our response, and we will incorporate these changes in the next revision.

Thnaks,

Yimin Shen
Juniper Networks

--------------------------
Dear colleagues,

I’ve read the draft in question and I support its adoption as a WG document by the MPLS WG.

[yshen] Thanks again ! 




At the same time I have several issues with the current text that, from my POV, should be resolved as the document is progressed. I would like to emphasize that I do not see these issues as blockers for the document adoption.

Here is the list:

The Requirements Language:

I have seen several occurrences of mixed usage of the IETF capitalized “MUST” and the non-normative “must” in the same sentence or in multiple sentences forming (from my POV) a common context within the document. Gere are just two examples (offending words are highlighted):

·         In section 5.10: “The context ID must be advertised in such a manner that any egress-protected tunnels MUST have E as tailend, and any egress-protection bypass tunnels MUST have P as tailend while avoiding E”

·         In section 5.13: ”In order to achieve this, the protector MUST maintain such kind of service labels in dedicated label spaces on a per protected egress {E, P} basis, i.e. one label space for each egress router that it protects. Also, there must be a session of service label distribution protocol between each egress router and the protector”

I have also found at least one text fragment where the IETF capitalized “MUST” appears very close to a non-normative “should” making it very difficult to understand what is and what is not required (again, the offending words are highlighted):

·         In section 5.8: “The bypass tunnel MUST have the property that it should not be affected by any topology change caused by an egress node failure”

I have found at least one text fragment that looks to me like specification of OPTIONAL behavior, but the IETF capitalized “MAY” is not used:

·         In section 5.2: “In a case where a PLR does not have a fast and reliable mechanism to detect a node failure or distinguish between a link failure and a  node failure, it may conservatively treat a link failure as a node failure and trigger egress node protection”.

(Please note that the quoted fragments are just examples, and there may be more such fragments in the draft).

[yshen] Will go through the document and fix all the cases.
 



Last but not least, RFC 2119 is quoted in Section 2, but is not listed as a normative reference.

[yshen] Will fix this.
 



Egress Link Failure:

The draft proposes a common framework for local repair of both egress link failures and egress node failures. From mu POV, these two cases are different. In particular:

·         Local repair of egress link failures can be achieved by many different mechanisms, including some that do not require support of context-specific label spaces in the protector. One such mechanism is even mentioned as “Option 2” for egress link protection in Section 6 of the draft, and, AFAIK, similar mechanisms have been successfully deployed by some vendors.

[yshen] Yes, this draft does consider this kind of egress-link protection mechanisms, hence list them as an option in the above section. Will clarify this further.

·         While alternative reasonably fast mechanisms for repair of egress node failures exist (e.g., see Section 6.2.1 of the BGP PIC draft, these mechanisms are applied at the service ingress PE and therefore should be classified as global repair mechanisms). 

I think that clear differentiation between the two cases (with Informative reference to the BGP PIC draft etc.) would be most helpful.

[yshen] Sure. Will mention BGP PIC as an example of global repair (as it is driven by ingress routers), and refer to the relevant draft. 




Egress Node Failure:

·         The draft is somewhat vague about detection of egress node failure as opposed to detection of failure of the link between the penultimate LSR and the egress node. Section 5.2 only says that “All the local failure detection mechanisms used by PLRs in transit link/node protection are applicable to egress node failure detection” leaving it to the reader/implementer to guess whether some other methods (e.g., monitoring the state of a multi-hop IP BFD session between stable IP addresses owned by these two devices) can be used for reasonably fast and reliable detection of egress node failures.

·         One well-known method for reliable (but slow) detection of the node failure is to wait for IGP to converge and to check whether the node is still present in the updated LSDB. AFAIK, there are deployed BGP PIC implementations that use this method to trigger BGP Edge PIC repair. However, I believe that this method is definitely not suitable as a trigger for local repair mechanisms, and I think that the authors should clarify their position on this point, one way or another.

·         The draft states in section 5.2 that “In a case where a PLR does not have a fast and reliable mechanism to    detect a node failure or distinguish between a link failure and a node failure, it may conservatively treat a link failure as a node failure and trigger egress node protection”.  This leaves open the question  of the PLR that can reliably and reasonably fast differentiate between these two cases (link failure and egress failure). In particular, the draft should describe the possible modes of behavior that the user can select for the PLR, and the ways to avoid race conditions between multiple protection schemes being applied simultaneously.

[yshen] Good point!  For clarity, I will add a new section for failure detection, to list common detection methods and address applicability, like the following:
 
1)  If the PLR has reasonably fast mechanisms (i.e. faster than control plane failure detection) to detect and differentiate a link failure and an egress node failure, it may set up both link protection and egress node protection, and trigger one and only one protection upon a corresponding failure. There should be no race condition between the two protections.

2)  The PLR may have fast mechanisms to detect a link failure and an egress node failure, but cannot distinguish them. Or, the PLR may have a fast mechanism to detect a link failure only, but not an egress node failure. In these cases, the PLR has two options:

2.1) It may set up link protection only, and leave the egress node failure to global repair and control protocol convergence. 

2.2) It may set up egress node protection only, and treat a link failure as a trigger for the egress node protection. However, the assumption is that treating a link failure as an egress node failure should not have a negative impact on services. Otherwise, it should also set up link protection only, and leave the egress node failure to global repair and control protocol convergence.




 Context ID Visibility:

Section 5.10 discusses various ways in which reachability of the Context ID can be advertised in IGP, i.e., within a specific AS. But I have not found any mention of inter-AS visibility of the Context ID. As a consequence, it is not clear to me whether the framework defined in the draft is applicable to MPLS services that cross multiple AS, e.g., with inter-AS IP VPN option C. From my POV, if the draft is only applicable to intra-AS services, this should be explicitly stated in the document (preferably, in the Applicability Statement section). 

[yshen] Both inter-AS and inter-area are supported. We will describe how context IDs are propagated across multiple AS/areas. Essentially, a context ID is an IP address. Hence, its inter-AS/area visibility can be achieved in the same manner as that of a regular IP address.



The role of traffic engineering in setup of bypass tunnels:

The draft states that “any egress-protection bypass tunnels MUST have P as tailend while avoiding E” (Section 5.9).  It also states that “The bypass tunnel MUST have the property that it  should not be affected by any topology change caused by an egress node failure” (Section 5.8). These statements look to me as implicit requirements to use some traffic-engineering technique for setup of the bypass tunnels and should be clarified in the draft. In particular, from my POV addressing these requirements with LDP used for setup of the bypass tunnels as described in Section 5.11, item [2], is non-trivial and therefore deserves detailed explanation. Depending on the details, some references (e.g., references to RFC 5286 and RFC 7490), that currently appear as Informational, may have to be promoted to Normative.

[yshen] The path computation for a bypass tunnel does not necessarily require TE. All we need is an algorithm which can take an avoided node (i.e. the egress node, in this case) as a constraint. Of course, such kind of algorithm is commonly used for TE, but it should not be tied to TE by its nature. In the case of LDP, we can set up the bypass tunnel by using various LFA mechanisms, which are actually good non-TE examples of the kind of path computation algorithm.




Bypass tunnels and segment routing:

I may have missed something important, but it seems that the technique described in Section 5.11, item 4, is just a variation of the hierarchical LSP technique when the context segment is used as a single hop LSP on top of a bypass LSP set up using SR. If so, it makes sense to merge items 3 and 4 of Section 5.11.

[yshen] Agreed. Will combined them.
 



Hopefully these comments will be useful.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein at ecitele.com




___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________