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

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Thu, 07 September 2017 13:55 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 2D547132D62; Thu, 7 Sep 2017 06:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.809
X-Spam-Level:
X-Spam-Status: No, score=-1.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, 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, URIBL_BLOCKED=0.001] autolearn=ham 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 bwgur2igbt7z; Thu, 7 Sep 2017 06:55:09 -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 A0C5B132F02; Thu, 7 Sep 2017 06:55:08 -0700 (PDT)
Received: from [85.158.138.179] by server-3.bemta-3.messagelabs.com id 4B/02-02046-9BF41B95; Thu, 07 Sep 2017 13:55:05 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTURzHd+5ju5k3r9Ppr2mvVSDmRvYw/4m CXhaYEUEZSd3ZbVtt03aXrIIepFbLIovKQjLFHr5ITSFTQ6TyFYUmpEvT0LTMHlRgq4ju3dEe /xw+v+/3/B7n8GNI9XOllhFcTsFh5606pR+1KKzKpa9JqEic3+JmY5s7i6lYz/UiOra1n19Ox tVc6VXFFRZ6iQ3EVtpiN6a4dtDmvLF+MvXhJ+TK+5avOoIKOpEb+TEUl0nCg1tDSjlQc+cIOO 4tJnHQhyCj7qUUTGKU3FKoLOlVyhzMzYYH2ado+RLJXUXwrOcmLRtB3HLI+CXXlS+tgqZzo1I CI7EBXnhWyjLFzYGvQ26fzHLboK9SlGXEhcBYaykhM8mFgmcwz8fAcVBY95TErIG3A79ozLMg 52WuCvM06Mg75XsNcJkqGDw+PJ5ggOrs9whzPDR/OqGS+4I0f9WbJHz/IwFn8rvGm0XC2KXvF B7ICH2v88dzreCpraEw74Gs2goaJ3fS4D3/iMBFw6GobzfWM5Rw4VG677PUXDI0536h8P9oob fzJMIcDm966umzKOLKP4/GbIeqOxcpmVkuEFouD1JYj4JrtZ+VmOfBjfx35AQ/bhgg/tWvIVU xihAFR5rg0EfHGowOi8nstPEWqz56/kKDTRBF3iRYeaNoSE6xVSJppQ4rFOgu+tG2thFNZQid hm2KqEhUTzGm7Nxv5kXzdsc+qyA2onCG0QEbv17yAh2CSXDtslilvZywgfHXBbPVss2KqbxNt Jiw1YqWMeXdvT8JptJ33ved5WP9Pwk1ZU+xC9pQNlhO4+Q08z77n6IT+96BpmmDWKRQKNT+qY LDZnH+74+gUAbpgli3XMXfYnf+6T0ijUVIYzmHy+WxnPxfS3sEpeu99Nyc7PZ1MxvuTY6xZvN UxJnRuDmemKvNmza6klcvPhaf/KE7RD9VmFkYULYsJzqrJOzJjJhvYZpXwoL2Wo8h4dDH0zWt n9e0J6R5b0cdcJtyj5YWbL49/bsmKVyz8mhiUMCSQ8TehqyDddULV6RHnXeNXOpSjNY3lhVsm d6WlamjRDMfHUk6RP43zHgl9OoDAAA=
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-8.tower-169.messagelabs.com!1504792501!125070905!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 24856 invoked from network); 7 Sep 2017 13:55:04 -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-8.tower-169.messagelabs.com with AES256-SHA256 encrypted SMTP; 7 Sep 2017 13:55:04 -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=NyBCu2YadjdhO2WF8Vh4AHh3HmVaCdvSauhaT6ixGow=; b=Roy+35V3nzb+cMa+7Ph9MOyOV0QuxCrKkuM7NjsJeS9oMHjHyZB4Kx8Lu19bJHgLSgVcO1LGwAuJduHiKKtinxlU5BIWx923+LcZl2/LINsAZMh42y2ghQmGqAngMtSS6Or/ji57qU5H8wHF1ma9nLeIRzPqWOmPKsoSlRk27KE=
Received: from AM4PR03MB1713.eurprd03.prod.outlook.com (10.167.88.15) by AM4PR03MB1604.eurprd03.prod.outlook.com (10.165.243.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Thu, 7 Sep 2017 13:54:59 +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.018; Thu, 7 Sep 2017 13:54:59 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "mpls@ietf.org" <mpls@ietf.org>
CC: "draft-shen-mpls-egress-protection-framework@ietf.org" <draft-shen-mpls-egress-protection-framework@ietf.org>, Stewart Bryant <stewart.bryant@gmail.com>
Thread-Topic: Adoption of draft-shen-mpls-egress-protection-framework
Thread-Index: AdMn4OLyXKADRfUKRCC1lUEYeszmrQ==
Date: Thu, 7 Sep 2017 13:54:59 +0000
Message-ID: <AM4PR03MB1713772A4348FC535728B6059D940@AM4PR03MB1713.eurprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.234.241.1]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR03MB1604; 6:JOzGyVxF9s1xsOd8YfoDbR4VmLFyBgX1M4AdI7+E42cBH8Qf9oYi56mDc54oN43jzqn+co9jnZQi2ToPv2BqHFuWgTsdEhtwv4ksTbtaB451a4lf4eTSEzdFUFr0p/0dryZYzevSu703NvcjAWw2SXv5dPdmgmidGcTlhzYShXJs1m6ojHCQ4ltJS6Q1zFWnWKw9MUITc//iOfdMBAe6Nx+o3tJ6RApJzbaClbgMRy8KKg4xRwfWGhOIhm2XosNUtRdGgedzDokbRzB8JecQkMz5Vdxq9uAex6XUdkCkkIf2YEBCyqxjgKOEqfLDzaq8ntacl+JaygS401Y3vJ5Zqg==; 5:RuMjSm1qwdNULEkjstD7zbtkwxW+iI0g+LnAX2zKrjLcEnue8OQ3fw432Rx78mnXqrnkcl0MxE2A+2ei5k2ItC9aA+kQVEv3uJmchhiPAZIX8pGYG7ZlaGqBWndvdN9xWW3HxTlWePBmK0DcdurmFA==; 24:CS9Xn9wHg7FLy7NH+wj61JK6fZUZ7t4OWEiajUz/nd5NZQNUoiulcEY9VQ0UatlNLS52TwWGS9lpVb2iFsIIutXrSt+Ko27Wb5oArq/NnKU=; 7:Mu43eH/hR5IkX5Oikc0IK3yTcpQPdASubIR5SBYxM7tVUgyJ48kR+Or5qRrUN07DhtnRsnmsFIF55ZHy25TZCqiMFv2oZS0YjGvDrOFixetuZ0Dj+ePOvwQERfQGfdxFmQD3ps80FpSN9by0+wTPamnbL+2KFGOyHZ/J+BeOf12uu9u60iM23LZAcrtILI8lG4EhA04T26I20H5w7naLY3S7Dgn8NVvqqs57iNGJ3YI=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 091d5afb-fd2c-4b30-209a-08d4f5f807c8
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM4PR03MB1604;
x-ms-traffictypediagnostic: AM4PR03MB1604:
x-exchange-antispam-report-test: UriScan:(72170088055959)(120809045254105)(21748063052155)(279101305709854);
x-microsoft-antispam-prvs: <AM4PR03MB160449EE50913F8CED66E1869D940@AM4PR03MB1604.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)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR03MB1604; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR03MB1604;
x-forefront-prvs: 04238CD941
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(252514010)(51444003)(189002)(25786009)(2351001)(478600001)(54356999)(72206003)(50986999)(101416001)(33656002)(8936002)(6916009)(3660700001)(105586002)(189998001)(7696004)(3280700002)(2906002)(86362001)(6506006)(7736002)(74316002)(106356001)(81156014)(1730700003)(81166006)(236005)(5660300001)(8676002)(54896002)(97736004)(53936002)(9686003)(6306002)(54906002)(99286003)(4326008)(230783001)(110136004)(39060400002)(6436002)(5630700001)(5250100002)(55016002)(5640700003)(2501003)(68736007)(2900100001)(413944005)(66066001)(14454004)(606006)(3846002)(102836003)(790700001)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1604; H:AM4PR03MB1713.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM4PR03MB1713772A4348FC535728B6059D940AM4PR03MB1713eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2017 13:54:59.6395 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1604
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/qTgHey2-MMdM8KEwwNoPPeshX7U>
Subject: [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: Thu, 07 Sep 2017 13:55:13 -0000

Dear colleagues,
I've read the draft in question<https://datatracker.ietf.org/doc/draft-shen-mpls-egress-protection-framework/?include_text=1> and I support its adoption as a WG document by the MPLS WG.

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).

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

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.

*         While alternative reasonably fast mechanisms for repair of egress node failures exist (e.g., see Section 6.2.1 of the BGP PIC draft<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-bgp-pic/?include_text=1>=1>, 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.

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.

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).

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.

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.

Hopefully these comments will be useful.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@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.
___________________________________________________________________________