Re: [mpls] RtgDir review: draft-ietf-mpls-egress-ptotection-framework-03

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Wed, 12 December 2018 09:41 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 C13E813114A; Wed, 12 Dec 2018 01:41:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 nAI9z1MTNX4F; Wed, 12 Dec 2018 01:41:22 -0800 (PST)
Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.4]) (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 700CD12777C; Wed, 12 Dec 2018 01:41:21 -0800 (PST)
Received: from [46.226.52.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-a.eu-west-1.aws.symcld.net id 6D/D9-09000-FB7D01C5; Wed, 12 Dec 2018 09:41:19 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkl+JIrShJLcpLzFFi42Ix0fyhorvvukC Mwez37Ba3t6tZ3Fq6ktXi5JwfzBYL1jxlt9i+/BuLA6vHkiU/mTyuN11lD2CKYs3MS8qvSGDN eDupouD0EvaK+etbmBoYN8xg72Lk4mARWMQsMentQkYQR0hgGpPEo3n7mSCcx4wSZxqWA5Vxc rAJ2EpsWn2XDcQWEVCSuL9rN1gHs8BrRomuP4vBioQFvCRmfXrOClHkLXHyTTczhO0n8WvKPz CbRUBV4vbMA0AbODh4BRIletZxQSxbwCRx/nYvWC+jgJjE91NrmEBsZgFxiVtP5oPZEgICEkv 2nGeGsEUlXj7+B1WfJHH/KcgLIHFFiRn35rBD2LISl+Z3gx0qIXCTTeLRn26oQboSH6ZOhRrk KzGhbQU7yEESAsoSW17EQoTvMEp0PqqCsHUktl1ZAVVeIHFj5w2o+XISq3ofskDMv8sscbbxK tQcGYn+deUQ8ftsErdPr2IBaRASSJY4MeczVMMTJomH3w4xT2DUnoXkUQg7T2LF1sOsIDavgK DEyZlPWGYBzWUW0JRYv0sfokRRYkr3Q3YIW0Oidc5cdmTxBYzsqxgtkooy0zNKchMzc3QNDQx 0DQ2NdA0tTXSNjEz1Eqt0E/VSS3XLU4tLdA31EsuL9Yorc5NzUvTyUks2MQITW0rBoYc7GM8t Tz/EKMnBpCTKe2WpQIwQX1J+SmVGYnFGfFFpTmrxIUYZDg4lCd5914BygkWp6akVaZk5wBQLk 5bg4FES4W0CSfMWFyTmFmemQ6ROMYZzrJrRMYOZ4xGYfAEm34HJBzNB5JUznUCyY92yOcwcxz u/zmEWYsnLz0uVEuf9BDJOAGRcRmke3DJYDrnEKCslzMvIwMAgxFOQWpSbWYIq/4pRnINRSZj 3z0mgKTyZeSVwN70COpcJ6NycLUwg55YkIqSkGhgnfzi85bPs1puvglj61Yw3ujXOMNudu+TG xeZl/U6v9bL3NLz1XXZ92ZaatnPzGVf5XgpcXVV7cPFLlfgfJubNkt6ns7QYvwb/5GTiPvt0t 8qVHZ+Yk+x+2hX90tnYtrHl2o3zT5POlP/Y42TcJ+Y//9qKi8rxz7X21zf8fCTn5bAysyPTjt lRiaU4I9FQi7moOBEAcE2OuBwEAAA=
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-2.tower-265.messagelabs.com!1544607674!4840718!1
X-Originating-IP: [52.41.248.36]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.14.24; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 23279 invoked from network); 12 Dec 2018 09:41:16 -0000
Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR01-DB5-obe.outbound.protection.outlook.com) (52.41.248.36) by server-2.tower-265.messagelabs.com with AES256-SHA256 encrypted SMTP; 12 Dec 2018 09:41:16 -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:X-MS-Exchange-SenderADCheck; bh=64OdxtB84ZBKtaD2pUbdifRFg0Ro5OxiLDc4mFbT0OA=; b=EyIw6U5qZgOo2IOSsVCWP4YCwIMWBw3X4hJia7zsiXsmE+jcCEcoRGNyFZRiNcmZEtoTclLNBJbnJzN612XiJtFdMSusj/JhyXNXydZcHGbZQRs874Tw5PRmERYP2YA9RlNyzboi/TuLI7b1TmDBZBaO4E+T0zjQqaeYXnzP3bw=
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB2007.eurprd03.prod.outlook.com (10.167.227.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.19; Wed, 12 Dec 2018 09:41:11 +0000
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::f507:afb2:b9c1:58c4]) by DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::f507:afb2:b9c1:58c4%2]) with mapi id 15.20.1425.016; Wed, 12 Dec 2018 09:41:11 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Yimin Shen <yshen@juniper.net>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-egress-protection-framework.all@ietf.org" <draft-ietf-mpls-egress-protection-framework.all@ietf.org>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>
Thread-Topic: RtgDir review: draft-ietf-mpls-egress-ptotection-framework-03
Thread-Index: AdR8MjymUP2LtqqCRvO1Anp1Nk3O/ALIazaAABqmdaACctktgAAbf4QgAAE1ceA=
Date: Wed, 12 Dec 2018 09:41:11 +0000
Message-ID: <DB5PR0301MB1909D8782E8FE6EE3271F1E79DA70@DB5PR0301MB1909.eurprd03.prod.outlook.com>
References: <DB5PR0301MB1909DAA9F3E05FB21A70C1509DD90@DB5PR0301MB1909.eurprd03.prod.outlook.com> <19B9F992-7DAB-478C-9F16-B641ABC898FA@juniper.net> <DB5PR0301MB1909C6ACB5F3513858A4F19D9DD20@DB5PR0301MB1909.eurprd03.prod.outlook.com> <BBAF38CE-1465-472D-A5EF-0832730376CA@juniper.net>
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; DB5PR0301MB2007; 6:G6CxclxgR26TIo9y+kke+aaIJcndC5sR28HqLL8SbGSClaYiW/LB7BReJ5oGiG3SgXiM/TZ+EcYN1oV+G0+2HN2SXQkLqSjosY5Go1op5sCCIstHb3/sfhheVWS25Ry6aplfKEBsyooxAU+1VoVj7qJ39mUqukiK1RA2CGxD08hJrJvKRtZxqGQ94JWXxe3PEHFlABb1wPDZsPV71M0peFaLmIpDGc+xcAKWpYObkGfVkdDtGnC9iVroPO6n7YTbNXeqS0jtkSu2ShNtFWg/PDtDyggz1ULFurmbLEZ21lCtlyo0YbohIeU3HlCobtEGMyVet2rNhXq3JS1oKYxLqzGFHwWxUB4MfdyDzmQVWMZxcy7989BIK/JwaI4+N1K0V+QRjXNUS0rvxVShMjYEkj+npeelvaWneLTRWXtclntQloGCPnqD9ilzfKUfU6U4Es66CMW7wQIpJTPdCZgW9g==; 5:cVcS9yo4TT72gFDkL02uAC5aZyg66lfflfOZJtkJzl/j3mMkgFPahUH40X6m6fWzgP4DxFGKsoklrqoZO3F6eCVPgu/22aWCe4+OF+2Zr7av+7/DlkbdWKgcuiwSxF1phl2jsL7AkYIqep13NA09kH8QpYpjMdtSvyiAmqhtwXw=; 7:ikgRnHsOssw4+EPwG9+R6WbwELhysWKezne8DXY3Bd4VplyoOBbPGmOR8KZ/3dk1oLEQPp68ke0pwtvC45rKECGnevSaVNBLfatygDAAngpdserxOC5W2gxci+QUJMfMgJG3LGKZcv3BokiCeLr40Q==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 9419cb3a-203c-444d-c974-08d66015f392
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DB5PR0301MB2007;
x-ms-traffictypediagnostic: DB5PR0301MB2007:
x-microsoft-antispam-prvs: <DB5PR0301MB2007742112D8D039715215079DA70@DB5PR0301MB2007.eurprd03.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231455)(999002)(944501520)(52105112)(10201501046)(93006095)(93001095)(3002001)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:DB5PR0301MB2007; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB2007;
x-forefront-prvs: 0884AAA693
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(346002)(136003)(39860400002)(199004)(51444003)(189003)(51914003)(252514010)(256004)(6306002)(5024004)(6116002)(33656002)(6506007)(53546011)(105586002)(102836004)(4744004)(71200400001)(5660300001)(446003)(186003)(66066001)(26005)(6436002)(790700001)(476003)(68736007)(14444005)(93886005)(71190400001)(76176011)(606006)(486006)(54906003)(316002)(3846002)(14454004)(7696005)(6246003)(97736004)(25786009)(81156014)(229853002)(8936002)(54896002)(106356001)(86362001)(2906002)(8676002)(478600001)(1941001)(81166006)(6916009)(53946003)(9686003)(53936002)(66574011)(99286004)(4326008)(236005)(55016002)(72206003)(7736002)(74316002)(579004)(559001)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB2007; H:DB5PR0301MB1909.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: f8f+nPUOghgytZU7S0EJRFfGr30kIO47nJbFbSpQvx+t3AweGMH5bXx6vF2xXyD6+3u9z9znnY3/X823ZnpBb4UTCzn7JUl/r6vGWg8iDl856FqmBXlsL9JF4i3bBNX5HdcB7po9gTC4rcuYfrV1uSrAYKgPrE87KZGCJiiHFLwMXI+Z58NFIFEZO7KRrlmOvm6kiGHWBtGXvrEr4r0x8+wudeKK3sManinprbSREfZhLwjCcWPC5AvQTGsaoNea+JM+ToH1ZdWM5N+wpoez5A4yf/t1/Emx8lot8KmVFC0Svn7SbWPy87XxQumYhGCA
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB5PR0301MB1909D8782E8FE6EE3271F1E79DA70DB5PR0301MB1909_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9419cb3a-203c-444d-c974-08d66015f392
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2018 09:41:11.4915 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB2007
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/Rr-V5cwquJnB17vDoAGbqOC8Lik>
Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-egress-ptotection-framework-03
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 12 Dec 2018 09:41:27 -0000

Yimin and all,
To clarify my issue #4 in the previous email.


RFC 7432 in Section 12 says that “The principles behind the following procedures are borrowed from the split-horizon forwarding rules in VPLS solutions [RFC4761<https://tools.ietf.org/html/rfc4761>;] [RFC4762<https://tools.ietf.org/html/rfc4762>].”



However, RFC 4761 and RFC 4762 define the split-horizon rules differently:


-     RFC 4761 in Section 4.2.5 states that “Split horizon forwarding rules apply to broadcast and multicast packets, as well as packets to an unknown MAC address”

-     RFC 4762 in Section 4.4 states that “a PE MUST NOT forward traffic from one PW to another in the same VPLS mesh”, it does not differentiate between BUM and “known unicast” traffic.

While RFC 7432 is aligned with RFC 4761 in its definition of the split-horizon rules, the rule introduced in RFC 4762 is much simpler to implement, and it is not explicitly prohibited by RFC 7432.


Regards,
Sasha

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

From: Alexander Vainshtein
Sent: Wednesday, December 12, 2018 11:20 AM
To: 'Yimin Shen' <yshen@juniper.net>;
Cc: rtg-dir@ietf.org; mpls@ietf.org; draft-ietf-mpls-egress-protection-framework.all@ietf.org; rtg-ads@ietf.org
Subject: RE: RtgDir review: draft-ietf-mpls-egress-ptotection-framework-03

Yimin,
Lots of thanks for the message.

I think that use of the protection framework described in the draft for protection of EVPN-based MP2MP services requires clarification of several issues. I am not sure I can provide a full list, but, at least, the following should be considered:

1.       It seems that in order for egress protection to work, Ethernet links connecting the primary Egress PE and the Protector to the customer site must participate in a common multi-homed Ethernet Segment. If this is correct, it should be specified explicitly

2.       If the multi-homing Ethernet Segment above operates in the Single-Active mode, and if the Primary PE is the DF on this segment for the specific service you try to protect, then, to the best of my understanding, the proposed protection scheme will not protect anything, because the Protector will declare the relevant VLANs as blocked to the CE (e.g., using MVRP as described in Section 8.5 of RFC 7432. The Protector will only unblock these VLANs when it is elected as the DF – but this will not happen until it will learn that the primary Egress PE or the link that connects it to the CE have failed. (If the Primary PE was not a DF, there would be nothing to protect).

3.       If the If the multi-homing Ethernet Segment above operates in the All-Active mode, and if the Primary PE is the DF on this segment for the specific service you try to protect, then:

a.       In the case of the primary PE failure “known unicast” traffic will be  protected by the proposed scheme

b.       The Protector will discard any BUM traffic it received for this service until it is elected as the DF.
Whether this behavior would count as protection for the service in question or not depends on the significance of multicast traffic in this service.

4.       RFC 7432 defines in Section 12 that Ethernet frames with unknown unicast Destination MAC addresses received from another PE MUST NOT ever be forwarded by the receiving PE to any other PE, only locally. While RFC 7432 restricts this to just unknown unicast frames, I suspect that most implementations do not forward EVPN-encapsulated frames they receive  to other PEs in any case (I can be wrong here, of course) just to be on the safe side when it comes to Ethernet loop prevention. Such implementations would have problems with using the proposed protection scheme for protection against failures of the attachment circuit where the primary Egress PE acts as the PLR.

I do not know if the list above is complete and whether all the issues I’ve raised are relevant, but I think that applicability of the egress protection  framework to EVPN requires some additional thought (and, eventually, a dedicated document). Simply saying that “EVPN can be supported in a similar manner as Layer 3 VPN” could be misleading IMHO.

Hopefully these notes would be useful.

Regards,
Sasha

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

From: Yimin Shen <yshen@juniper.net<mailto:yshen@juniper.net>>
Sent: Wednesday, December 12, 2018 2:44 AM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
Cc: rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org>; draft-ietf-mpls-egress-protection-framework.all@ietf.org<mailto:draft-ietf-mpls-egress-protection-framework.all@ietf.org>; rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>
Subject: Re: RtgDir review: draft-ietf-mpls-egress-ptotection-framework-03

Hi Sasah,

a.       L2VPN services that use EVPN technology would neither suffer from an empty FIB in the protecting MAC-VRF nor use EVPN application labels for MAC learning. But I cannot say whether they do or do not introduce some other issues with the proposed framework – this would require serious in-depth analysis. Meanwhile such services look to me like another case when an explicit definition of “left FFS” or “to be addressed in a separate document” would be very much in place.

EVPN can be supported in a similar manner as Layer 3 VPN, although this document doesn’t provide a detailed example.

Thanks,

-- Yimin


From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
Date: Thursday, November 29, 2018 at 3:50 AM
To: Yimin Shen <yshen@juniper.net<mailto:yshen@juniper.net>>
Cc: "rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>" <rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>>, "mpls@ietf.org<mailto:mpls@ietf.org>" <mpls@ietf.org<mailto:mpls@ietf.org>>, "draft-ietf-mpls-egress-protection-framework.all@ietf.org<mailto:draft-ietf-mpls-egress-protection-framework.all@ietf.org>" <draft-ietf-mpls-egress-protection-framework.all@ietf.org<mailto:draft-ietf-mpls-egress-protection-framework.all@ietf.org>>, "rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>" <rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>>
Subject: RE: RtgDir review: draft-ietf-mpls-egress-ptotection-framework-03

Yimin,
Lots of thanks for a prompt and very encouraging response.

It seems that all my comments would be resolved with the proposed changes. I will be waiting for the next revision of the draft to confirm that.

Please see some remarks inline below.

Regards,
Sasha

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

From: Yimin Shen <yshen@juniper.net<mailto:yshen@juniper.net>>
Sent: Thursday, November 29, 2018 2:53 AM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>; rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>
Cc: rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org>; draft-ietf-mpls-egress-protection-framework.all@ietf.org<mailto:draft-ietf-mpls-egress-protection-framework.all@ietf.org>
Subject: Re: RtgDir review: draft-ietf-mpls-egress-ptotection-framework-03

Hi Sasha,

Thanks very much again for the detailed review and the constructive comments and suggestions!

Please see [yshen] inline below.

Thanks,
-- Yimin


From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
Date: Tuesday, November 20, 2018 at 4:41 AM
To: "rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>" <rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>>
Cc: "rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>" <rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>>, "mpls@ietf.org<mailto:mpls@ietf.org>" <mpls@ietf.org<mailto:mpls@ietf.org>>, "draft-ietf-mpls-egress-protection-framework.all@ietf.org<mailto:draft-ietf-mpls-egress-protection-framework.all@ietf.org>" <draft-ietf-mpls-egress-protection-framework.all@ietf.org<mailto:draft-ietf-mpls-egress-protection-framework.all@ietf.org>>
Subject: RtgDir review: draft-ietf-mpls-egress-ptotection-framework-03
Resent-From: <alias-bounces@ietf.org<mailto:alias-bounces@ietf.org>>
Resent-To: <yshen@juniper.net<mailto:yshen@juniper.net>>, Jeyananth <minto@juniper.net<mailto:minto@juniper.net>>, <bruno.decraene@orange.com<mailto:bruno.decraene@orange.com>>, <hannes@rtbrick.com<mailto:hannes@rtbrick.com>>, <c.michel@telekom.de<mailto:c.michel@telekom.de>>, <huaimo.chen@huawei.com<mailto:huaimo.chen@huawei.com>>, <jiangyuanlong@huawei.com<mailto:jiangyuanlong@huawei.com>>, <tsaad@cisco.com<mailto:tsaad@cisco.com>>, <n.leymann@telekom.de<mailto:n.leymann@telekom.de>>, <loa@pi.nu<mailto:loa@pi.nu>>, <martin.vigoureux@nokia.com<mailto:martin.vigoureux@nokia.com>>, <db3546@att.com<mailto:db3546@att.com>>, <aretana.ietf@gmail.com<mailto:aretana.ietf@gmail.com>>, Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>
Resent-Date: Tuesday, November 20, 2018 at 4:41 AM


Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_rtg_trac_wiki_RtgDir&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=xu90MfAW_jm6lYh6hyEgpJehTmsKq0dHrkE5tND9658&s=lmNRlXjT4KG6xOton77vla3JlOuHmrmtA-DTbeS-eI8&e=>

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.
Document: draft-ietf-mpls-egress-protection-framework-03
Reviewer: Alexander (“Sasha”) Vainshtein
Review date: 19-Nov-18
IETF LC End Date: Not known
Intend status: Standards Track

Summary:
I have some minor concerns about this document that I think should be resolved before publication.

Comments:
The draft is well written, requires from the reader has good understanding of multiple technologies including:

  *   context label spaces and context labels RFC 5331
  *   local and remote LFA mechanisms (RFC 5286 and RFC 7490)
  *   Segment Routing Mirror SIDs (RFC 8402) and more.
I doubt it is suitable reading for a beginner, but I also doubt any required background could be skipped.

This is a framework document, with at least one “specialization” of this framework already being published as RFC 8104<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8104&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=xu90MfAW_jm6lYh6hyEgpJehTmsKq0dHrkE5tND9658&s=ZQnSkVQtt1y5mvUspbxj3ex47FimKytILN6VNLAAXIk&e=>;.  I assume that other “specialization” documents are on the way.

I have hold a very constructive off-list discussion with the authors before posting this review. Some of my comments have been already acknowledged. I would like to thank the authors and, especially, Yimin, for cooperation.

Caveat:
I have done an unsolicited review of the precursor individual draft<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_mpls_current_msg17033.html&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=2-nT7xvtgxYac4wpYxwo_jh5rZM2uwTLxgRhaObwYug&m=xu90MfAW_jm6lYh6hyEgpJehTmsKq0dHrkE5tND9658&s=zeQV7i8GATWDPu-c_ILYWpjPkln0Wz5-0D6Al_gpPFU&e=>;. From my POV, the document has been quite in good shape even then, so I may be considered as positively biased (the current version acknowledges my comments). I have noticed that the majority of my then comments have been successfully resolved in the current version of the draft.

[yshen] Thanks again!

Major Issues: No major issues found

Minor Issues:

1)      The document seems to be ambiguous  with regard to expected coverage of L2VPN services by the framework it defines:
a.       On one hand, the requirement for the framework in the 2nd bullet in Section 4 says that it MUST “accommodate existing and future IP/MPLS services, including layer-2 VPNs, layer-3 VPNs, hierarchical LSP, and others”
b.       On the other hand, the overview of the framework (in Section 1) says that “When a PLR does local repair, the protector is responsible for performing "context label switching" for rerouted MPLS service packets and "context IP forwarding" for rerouted IP service packets, to allow the service packets to continue to reach the service destinations”. i.e., MAC-based switching seems to be excluded from the protector responsibility.
c.       Section 3 of the draft only defines the terms “Context label switching”  and “Context IP forwarding”. This also suggests that Context Layer-2 switching is not covered by the framework

[yshen] Actually, this framework does allow a context label to point to a layer-2 switching table, if the packets coming to a protector have a layer-2 header (rather than a label or IP header) below the context label, which could be the case of MAC address table.  In theory, a context label may point to any type of look-up table. IOW, depending the use case, any meaningful context-based “layer-N” forwarding/switching is allowed by this framework. We will add a section to the end of draft to make it future compatible.[[Sasha]] Sounds good. I will be waiting for the actual text in the next revision of the draft.

2)      I have some doubts regarding applicability of the egress protection framework defined in the draft  to VPLS-based (RFC 4761 and/or RFC 4762)  services because:
a.       With VPLS, CE multi-homing always operates in single-active mode. As a consequence:

                                                               i.      Prior to failure of the primary egress, the VSI that represents the service in the Protector PE would not learn any MAC addresses

                                                             ii.      If the PLR redirects “known unicast” traffic intended for the primary egress PE to the protector, the VSI that locally represents protected service there would flood this traffic as “unknown unicast” and, as such, probably subject it to rate limiting.

                                                           iii.      From the POV of the customer of the VPLS service,  this means that redirecting traffic to the protecting VSI, by and of itself would not fully restore the service, since substantial part of the customer traffic would be dropped until MAC learning in the protecting VSI is completed
b.       It is also worth noting that in VPLS received application labels do not only define egress VSI as the context for the MAC-based switching but also identify remote ingress VSI for MAC learning. Extending such identification to cover also application labels of the redirected traffic looks quite non-trivial to me
c.       I see these concerns as minor issues because, as explained above, it is not clear to me whether the framework is supposed to cover VPLS services. An explicit caveat (possibly defining applicability of the framework to VPLS services as “left FFS”, or to be discussed in a separate document”) would suffice to resolve them IMHO
d.       L2VPN services that use EVPN technology would neither suffer from an empty FIB in the protecting MAC-VRF nor use EVPN application labels for MAC learning. But I cannot say whether they do or do not introduce some other issues with the proposed framework – this would require serious in-depth analysis. Meanwhile such services look to me like another case when an explicit definition of “left FFS” or “to be addressed in a separate document” would be very much in place.

[yshen] We will mention VPLS and EVPN for future study, as well as services where no other router is able to learn or establish its own connectivity with service destination in advance of a primary PE failure, to serve as a protector.[[Sasha]] This should suffice I think.

3)      The example of applying the egress protection framework to BGP/MPLS IP VPN (RFC 4364) in Section 8 is explicitly restricted to scenario when both the primary egress VRF and the protector VRF use per-VRF label allocation scheme.
a.       With this scheme, the usage of the proposed egress protection framework is quite straightforward.
b.       However, RFC 4364 defines several label allocation schemes and states that the label allocation scheme can be selected independently in each PE without any impact on interoperability. It is not clear to me, to which extent IP VPN services that use different label allocation schemes in different egress PEs would be covered by the proposed framework
c.       Since we are only speaking about an example in a framework document, there is no need to describe a complete solution here. Simply noting the need for elaboration with regard to other VPN application label allocation schemes  (including the possible mismatch in the primary and protector egress PEs) and sending the reader to a (future) dedicated document would suffice IMHO.

[yshen] We will clarify that the primary PE (PE2) may allocate VPN labels by using per-VRF, per-route, or per-interface mode. The protector (PE3) should set up the nexthop for each label route in pe2.mpls table as below:
-          If the VPN label is a per-VRF label, the nexthop of the label route should point to the protection VRF.
-          If the VPN label is a per-route label, the nexthop of the label route should be based on the protector’s own connectivity with the IP prefix.
-          If the VPN label is a per-interface label, there are two cases. (A) If the distribution of IP prefixes over the interfaces on the primary PE aligns completely with the distribution of IP prefixes over the interfaces on the protector, the nexthop of the label route should point to the corresponding interface of the IP prefix on the protector. (B) Otherwise (or for simplicity), the nexthop of the label route should point to the protection VRF.
[[Sasha]] Would it not be simpler to say that, regardless of the way the primary egress PE allocates its VPN application labels, the Protector should always treat them as pointing to the relevant VRF and performing context IP forwarding? The logic that matches routes learned by the primary egress PE and by the Protector would be complicated and eventually could fall back to the same scheme – so what is the gain?

4)      Section 5.8 describes 3 possible approaches to advertisement of the Context ID IP address in IGP. But it does not define any of these approaches as “MUST to implement”. This looks to me like an opening for interoperability issues between implementations that support different approaches. On the other hand, I am not sure whether a framework document is the right place to select a MUST to implement option, especially when the expected areas of applicability are quite different:
a.       The “proxy mode” approach imposes minimal (if any) specific requirements on the routing and TE domain (i.e., no dedicated extensions in IGP,  just support of some FRR mechanism by the signaling protocol used for the tunnel setup)
b.       The “alias mode” seems to require support of at least Segment Routing extensions to the relevant IGP in the routing domain as well as support of the Mirror SID in all potential PLRs. Therefore I think that it is a native scheme to be used in the SR-MPLS environments, but problematic in the environments that do not use SR-MPLS for setup of any LSPs
c.       The definition of the “stub link mode” is accompanied by a somewhat vague caveat: “The correctness of the egress-protected tunnels and the bypass tunnels relies on the path computations for the any-cast IP  address performed by the ingress routers and PLR.  Therefore, care MUST be taken for the applicability of this approach to a given network topology”.  Some clarification here would be welcome IMHO, especially since no analog of this mode could be found in RFC 8104.
d.       I have looked up Section 4.3 in RFC 8104 that discusses two approaches (equivalents of the Proxy and Alias modes in this draft) to advertisement of Context ID, and found the following text there (the critical fragment is highlighted):
   The mechanism in this document intends to be flexible on the approach
   used by a network, as long as it satisfies the above requirements for
   the transport tunnel path and bypass tunnel path.  In theory, the
   network can use one approach for context ID X and another approach
   for context ID Y.  For a given context ID, all relevant routers,
   including primary PE, protector, and PLR, must support and agree on
   the chosen approach.  The coordination between the routers can be
   achieved by configuration.
Adding such ( or similar) text to Section 5.8 looks to me as a reasonable compromise between being excessively strict and being excessively flexible in a framework document.

[yshen] We will add similar text to the draft. As a framework, the draft presents and discusses a number of options in a general manner. These options are technically equal and all feasible, although they each may have pros and cons. This is also based on our goal to make egress protection applicable to a variety of networks of different technologies. Hence, the draft does not mandate any option as a MUST. That decision of which option to use in a given network is left to the specific technology deployed and the vendors involved.
[[Sasha]] This should do it IMHO.

Nits:

  1.  RFC 2119 is mentioned in the text, but does not appear as a Normative reference (BTW, I have pointed to this fact in my unsolicited review more than a year ago, but it still remains unresolved)
  2.  RFC 8174 is neither mentioned in the text (as seems to be the norm these days) nor appears as a Normative reference.

[yshen] We will add these RFCs to the normative reference section.
[[Sasha]] And to refer to them in the “Specification of Requirements” section.

Regards,
Sasha

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

___________________________________________________________________________

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

___________________________________________________________________________

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