Re: [bess] A question about RFC 8317

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Fri, 21 December 2018 07:29 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057A912F295 for <bess@ietfa.amsl.com>; Thu, 20 Dec 2018 23:29:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 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] 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 DPP20UYnoJjr for <bess@ietfa.amsl.com>; Thu, 20 Dec 2018 23:29:27 -0800 (PST)
Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.5]) (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 C5EFE12F1A6 for <bess@ietf.org>; Thu, 20 Dec 2018 23:29:26 -0800 (PST)
Received: from [85.158.142.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-a.eu-central-1.aws.symcld.net id 01/03-17018-F469C1C5; Fri, 21 Dec 2018 07:29:19 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA2WTfWwTdRjH97u7Xo9lXY6uuGezM1pDTHAtHe6 Pi9HEaMCCUXwhhJguetvqWm272XZYiMaqicAIdMyWbV2llI0hc5ZtIVNh0WYDi5vbZDKGXSp0 lEC7rDTgFB1a73rtxPjPL597vt/n7ZKHwqWdVCmls9t0FjNrVJD5ROX9J+3KFw7KteroZBnzW agdZ7yRZ5jInb9I5ronKGJCCS/JJMc/IpiOeCdiYoeOi5+iNHGnF2lcS/0iTVfXH5hm5sNpsS YSnsI0Sd8C+SL5qshgrq63vy7St471YQ2n74jsXS2MAyXCoia0giLoIzgMhAqbUD4lpZ0YHPV Ni4WPywjutkQQ7yLpJ2Hg8wjJCzK6B8HhmWaCF3A6jODju1U8F9FK+GBhH8azjFbBmaPdhMDr oPPMLBLarYapK6czHgldBR7nlyTPUvoJ6G0JcH6KWsE16zhk4MOIvg9+H+3FhFbFEI75Mgy0D KLnx0iBV0H86t8iwV8Nl6/5EV8GaAVcubVWsJTBlG8vEniGhP6RzQIrIeV24wI/DwdanCIh9W E4eaOK3xboGILgZCrbag24Il9k/UZIpS9kx3kAevZFCYGTOMwe2CCwHLyT+3GhUDcJJwJOkbB uDZzz3iaaUbnnntU8nA+n9yC4cL0V82R+0Ur4vj1GCCYzLA76SYHVcHPChwv8KHT757O8Fvp/ HUf/j5fD0m9N2dyHYHbaLRKadSE4EvtO7OG25k2Og0U5j2tvVJzLbf/6EpGLh85OY8u5Y78cx 3Kmof40dm/yYSTtQUy1xVCnt5lYg1FZoVYrKyoeU65TVlaq2J1KVqVrVNbozDYLy4kq9h2ryr rDVGOsVZl1tgHEnUTt21j5V+iWv24YlVCYYpVkzinXSgur62t36Fmr/jVLo1FnHUZyilKA5JP 9nLbSoqvT2d8wGLm7yslAFShkki1uTpZYG1iT1VAnSKPoOepSMN2KUz1tu9twai7zJjPv7kC3 F6dCexa9uJQw15t1pcUSg4srQfMl9I3m5Qa5251CZaVFEpSXlyctaNBZTAbbf/UEKqaQokji5 AcpMJhty3MkuBExbsT8pzMj2th/pVIHelOx8Zj22Z8nT9xYrNnuGpkzz73nHjl73pYaPFboH/ /zHHpkde9GR5u2Y9fmrSXh9CbH9m9f3vZuQ3Ci5If5gMa04ce4Vs08LqnCy4JLw0P+LW/h78d 3NmPp+Zc2Xezr+yl6+9SCXb1+cHRI9sqD8m8UyQlLIrDrU9tQ6tqp9VcvltxUEFY9W7EGt1jZ fwDyPaiLtgQAAA==
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-23.tower-226.messagelabs.com!1545377354!3396378!1
X-Originating-IP: [52.27.180.120]
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 8814 invoked from network); 21 Dec 2018 07:29:17 -0000
Received: from us-west-2c.mta.dlp.protect.symantec.com (HELO EUR04-DB3-obe.outbound.protection.outlook.com) (52.27.180.120) by server-23.tower-226.messagelabs.com with AES256-SHA256 encrypted SMTP; 21 Dec 2018 07:29:17 -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=Uj/UckLQ6q3W0P7zuBwa5C+etTiXY6pnXg5vO3MUb6o=; b=HNb/Smmn/iodyYkEdhtsCiotgOcDSD0NOuRFuoEWEIidhoYfmozx/yIxQj2bbLLzW9E3wroRsDJhYNkj9ZVwW/jVzZ/u3+3IwRK7Bc/ZgFyhysMMY7JiWH5pl+CddvoqVL0Wc3wAbxKwM8XZPsf5vcAdEjOFGoYo+84CuDN013Q=
Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.29) by AM0PR03MB5121.eurprd03.prod.outlook.com (20.178.83.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.17; Fri, 21 Dec 2018 07:29:12 +0000
Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::dd0e:6be2:6377:6f6d]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::dd0e:6be2:6377:6f6d%4]) with mapi id 15.20.1446.022; Fri, 21 Dec 2018 07:29:12 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "Luc Andre Burdet (lburdet)" <lburdet@cisco.com>
CC: "John E Drake (jdrake@juniper.net)" <jdrake@juniper.net>, "Samer Salam (ssalam)" <ssalam@cisco.com>, "ju1738@att.com" <ju1738@att.com>, "sboutros@vmware.com" <sboutros@vmware.com>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [bess] A question about RFC 8317
Thread-Index: AQHUmIuG3DLW7twqeEiFNu4Ffx5oZ6WIzKV3
Date: Fri, 21 Dec 2018 07:29:12 +0000
Message-ID: <AM0PR03MB3828D05165673CE99839521B9DB80@AM0PR03MB3828.eurprd03.prod.outlook.com>
References: <FB8ACA89-C01B-4D83-9750-C33F258FE490@cisco.com>
In-Reply-To: <FB8ACA89-C01B-4D83-9750-C33F258FE490@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [52.142.119.208]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR03MB5121; 6:aJHmHg0CCNJFzNpoQ6WtmtUWHmabSZC86T9JMKJtSUd81TYv8kz8S/Ifz0ixQbUavBA9V/Y9FYKyKo4pKAgzWM0bjmK2dg1OcvfJkRH588riKzhdQifWJtw/QDG7ubhBldC/YvKTA1YSnEZZ9SUmMIC5PZgtolj0fRTybPP0QoFMLGcxbSSMQM2MH9NGsUI5kb7ErHjSK9/82tIBGb1pGONnpAq8ApaXkT/r8lrzB8sq41WiKT07bzm7YB3Scq30ucjvoavz0X9R5CKsFYZ+ZpF86X0igYwXTAjymCVNju4YE5yVm04qRlG+4HiOY1tarX78FzzZQDt69t4uzrJ2DkCEYiD9AexXQAuIckCsTUVKBkOxmTNWX13U66c1KTwJmbEZZINsicaQIgmWMC/q5hqGKKNBtozaUblLWl1N3VqYP4yiHYHBvx9uOWl8jTrr271oK1HBuLNxdFXQZCxcfQ==; 5:vT29paLqVZModhF/m71344XFq/AMMcOGRNEvEegM8iW6aThDjKgkjqvqg97C1KSuRySp9wrQaEG5SKzblybod6cCTTlMfHg46VOljtHS6nf1km0vx4eMr8Ww4VXRhJscG6fN7HVpwNb/FkCH0Hvh1RQFjKDrLgWEfM8zf3Oy0EU=; 7:P3wkPkdjzwJyC5+Q/4GupkrYO3CW0SjkPDOYwcwptm+EU3jKK0AM4DBeKAMRCDeuK6J1XgJQ+Y7oExt2klO6/uJty2CEUTaOsNYih3SBNW+CuvSip2JoneCt6WH9CjxYe46N1PtOZetpjrNmu0vMZQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: c9ff9f43-2b88-4e01-ed9c-08d66716013a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM0PR03MB5121;
x-ms-traffictypediagnostic: AM0PR03MB5121:
x-microsoft-antispam-prvs: <AM0PR03MB5121C0161EF020A5BA849B039DB80@AM0PR03MB5121.eurprd03.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(5005026)(102415395)(6040522)(2401047)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231475)(944501520)(4983020)(52105112)(6055026)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:AM0PR03MB5121; BCL:0; PCL:0; RULEID:; SRVR:AM0PR03MB5121;
x-forefront-prvs: 0893636978
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(39860400002)(136003)(376002)(366004)(53234004)(51874003)(189003)(51914003)(199004)(446003)(486006)(11346002)(256004)(14444005)(105586002)(236005)(9686003)(71190400001)(71200400001)(476003)(6506007)(186003)(53546011)(66066001)(7696005)(76176011)(26005)(102836004)(97736004)(106356001)(81166006)(99936001)(6116002)(3846002)(606006)(72206003)(8676002)(25786009)(81156014)(2906002)(54906003)(99286004)(478600001)(6246003)(86362001)(110136005)(316002)(733005)(74316002)(68736007)(7736002)(33656002)(6436002)(54556002)(53936002)(55016002)(6306002)(5660300001)(14454004)(4326008)(8936002)(229853002)(54896002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB5121; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: A+ENH0LeJGAZWRu+GPGpSz3AyMZ791YQX7puCPaVoO1Ou66oDAlF0bO4xGczHuWuQnde+G6icI7Wx7qnvLMaR6WGVsy3ZxVF4c1STjPKWt4jjDed7oxqBFq3Oehh/vWwuEWxiYw5V0Nv4LjQIiwrY4GwqqfZxm63m+4CkO4jeZaMrsUI8p450K4EXX/wVuxOwWqsAkakhDzdcpodWnyEnAlqAXmeFlEh8KhURBKiNzjrLt5eAI3/x8sXm5mT5bESkv6H9dT/obioXOV12ZgV8lTZVQ6QM8ajspLe52rFlNH7Yqo/itEHXHW7sDEMXALO
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/related; boundary="_005_AM0PR03MB3828D05165673CE99839521B9DB80AM0PR03MB3828eurp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c9ff9f43-2b88-4e01-ed9c-08d66716013a
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2018 07:29:12.5243 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB5121
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/kj2MpOL4Hyp8-bH0YBVUvT3XPDM>
Subject: Re: [bess] A question about RFC 8317
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Dec 2018 07:29:31 -0000

Luc,
Lots of thanks for the comment.
I fully afree that local split horizon rules must be configured in the MAC-VRFs in PE2 and PE3 to prevent local leaf-to-leaf forwarding.
I did  not mention it because it was not relevant for the problem with the "two RTs" scheme. According to Jorge, this problem is real, and the "two RTs" scheme sgould nit be used in this scenario.

Regards,
Sasha

Thumb typed by Sasha Vainshtein

________________________________
From: Luc Andre Burdet (lburdet) <lburdet@cisco.com>
Sent: Thursday, December 20, 2018 7:43:33 PM
To: Rabadan, Jorge (Nokia - US/Mountain View); Alexander Vainshtein; Ali Sajassi (sajassi)
Cc: John E Drake (jdrake@juniper.net); Samer Salam (ssalam); ju1738@att.com; sboutros@vmware.com; bess@ietf.org
Subject: Re: [bess] A question about RFC 8317

Sasha,
I would add only to Jorge’s response that in your topology below:
“PE3 would flood anything for which MAC DA is unknown to both local ESes.”
For traffic in the reverse direction (Leaf@PE3 -> Root@PE1) you’d want to add an administratively configured split-horizon between green and blue ACs at PE2 & PE3 because otherwise you may locally switch(or flood) leaf-leaf at PE2/PE3 which should be disallowed.

Regards,
Luc André

[http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]




Luc André Burdet
lburdet@cisco.com<mailto:lburdet@cisco.com>
Tel: +1 613 254 4814






Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Cisco.com<http://www.cisco.com/web/CA/>







From: BESS <bess-bounces@ietf.org> on behalf of "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
Date: Thursday, December 20, 2018 at 12:32
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>om>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>
Cc: "John E Drake (jdrake@juniper.net)" <jdrake@juniper.net>et>, "Samer Salam (ssalam)" <ssalam@cisco.com>om>, "ju1738@att.com" <ju1738@att.com>om>, "sboutros@vmware.com" <sboutros@vmware.com>om>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] A question about RFC 8317

Hi Sasha,

What you are explaining is correct.

PE3 would flood anything for which MAC DA is unknown to both local ESes. That is normal behavior, only that in this case CE-1’s MAC will not be learned on PE3 until CE-1 hashes the traffic to PE3 and not only PE2 (which will happen if you have a decent number of flows). *Technically speaking*, the E-Tree solution works since you don’t have leaf-to-leaf communication. However, I would not use the two RT solution in this scenario since it could create unnecessary flooding to local ESes as you describe.

For this scenario I would always use a single RT per EVI, ingress filtering for unicast (based on the leaf indication on MAC/IP routes), and egress filtering for BUM based on leaf label, as explained in RFC8317.

My two cents.

Thank you.
Jorge


From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Date: Thursday, December 20, 2018 at 12:30 PM
To: "Ali Sajassi <sajassi@cisco.com> (sajassi@cisco.com)" <sajassi@cisco.com>
Cc: "Samer Salam (ssalam)" <ssalam@cisco.com>om>, "John E Drake (jdrake@juniper.net)" <jdrake@juniper.net>et>, "ju1738@att.com" <ju1738@att.com>om>, "sboutros@vmware.com" <sboutros@vmware.com>om>, "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>om>, "bess@ietf.org" <bess@ietf.org>
Subject: A question about RFC 8317

Ali and all,
I have read RFC 8317<https://tools.ietf.org/html/rfc8317>17>, and I would like to clarify a question dealing with Leaf ACs of an EVPN-based E-Tree service on All-Active Multi-Homed Ethernet Segments (MH ES).

The reference model for my question is shown in the Embedded diagram below.


[cid:image002.png@01D49865.895588B0]

It shows an EVPN E-tree service with one Root customer site and two leaf customer sites, where each Leaf CE is dual-homed to the same pair of PEs using two different All-Active multi-homed Ethernet Segments.

Suppose that the scheme with two RTs (one identifying the Root site and the other identifying the Leaf sites) is used as described in 4.3.1.

Suppose also that each MAC-VRF uses per MAC-VRF label assignment as defined in section 9.2.1 of RFC 7432, i.e., advertises exactly one EVPN application label that identifies it as the Egress MAC-VRF, while the disposition of the received Ethernet frame within this MAC-VRF is based on the destination MAC address. In this case the per MAC-VRF label can be also used as the “aliasing” label in the per EVI EAD route.

PE-1 will receive and accept per EVI EAD routes for both MH ES for PE-2 and PE-3 with the corresponding “aliasing” labels.

Suppose that MAC-VRF in PE-2 learns some {MAC, IP} pair  {X, Y}  locally from the Leaf CE-1 and advertises this pair in the EVPN MAC/IP Advertisement route. With the “two RTs” scheme this route will be accepted by the MAC-VRF in PE-1 but it will not be accepted by the MAC-VRF in PE3. As a consequence:

-          MAC-VRF in PE-1 will know that this pair has been learned from the “blue” all-active MH ES, and therefore can decide to send locally received unicast frames with destination MAC address X to PE-3 using the corresponding “aliasing label”. No other labels will be included in the EVN encapsulation of such  frames because they are received from the Root AC.

-          MAC-VRF in PE-3 will not know anything about MAC address X, therefore, when it receives an EVPN-encapsulated frame with this destination, it will treat it as an “unknown unicast” and flood it to both Leaf CE-1 (where it should be sent) and to Leaf CE-2 (where it should not be sent).

Is this what is really supposed to happen in this scenario? If not, what did I miss in the E-tree EVPN solution?

Regards, and lots of thanks in advance,
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.
___________________________________________________________________________



___________________________________________________________________________

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