Re: [bess] A question on using EVPN label and Alias label in load balancing

"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> Mon, 18 February 2019 13:54 UTC

Return-Path: <jorge.rabadan@nokia.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 536CB128B01 for <bess@ietfa.amsl.com>; Mon, 18 Feb 2019 05:54:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 mwRZRM0y6Qbj for <bess@ietfa.amsl.com>; Mon, 18 Feb 2019 05:54:28 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40122.outbound.protection.outlook.com [40.107.4.122]) (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 95D5A130F1D for <bess@ietf.org>; Mon, 18 Feb 2019 05:54:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w6quzoW2GQ6VHuDzJCd1GVo95rcwsFnPhv6i8rP6xdI=; b=j+JUVfZLSr7SAeft+cL9WjXwAAIIFmffmWMDDTPE64kG/LM4Qk4rKy3f1xS0cqiJakKUqkUNL2+c9YYmV+FZQht4+ReOttWhDpnGgffGcRA8JIBES+JBBJJvrpugNKzrP9id8qbyIDjLxWmecEbq8mkUBkp62QSARxeRrvZMJNc=
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com (52.134.82.20) by AM0PR07MB4404.eurprd07.prod.outlook.com (52.133.52.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.9; Mon, 18 Feb 2019 13:54:24 +0000
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::8984:5912:788d:6446]) by AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::8984:5912:788d:6446%3]) with mapi id 15.20.1643.008; Mon, 18 Feb 2019 13:54:24 +0000
From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
To: Jide Akintola <jidept=40yahoo.com@dmarc.ietf.org>, "bess@ietf.org" <bess@ietf.org>, Jaikumar Somasundaram <jaikumar.somasundaram@ericsson.com>
CC: Jide Akintola <jide@xpresspath.net>
Thread-Topic: [bess] A question on using EVPN label and Alias label in load balancing
Thread-Index: AdTHcbErZmw+1mCUS+adcDYdx9UwoAAC6MkAAABzEuAAAWVMAAAFR6+A
Date: Mon, 18 Feb 2019 13:54:24 +0000
Message-ID: <7A8B346B-EEBE-4C3A-AC09-5EAB714C2D85@nokia.com>
References: <VI1PR07MB43023EB901D72DA93049332886630@VI1PR07MB4302.eurprd07.prod.outlook.com> <83625784.899773.1550489420551@mail.yahoo.com> <VI1PR07MB4302B49CACF63ABFCAB0917186630@VI1PR07MB4302.eurprd07.prod.outlook.com> <1786068588.911432.1550492590378@mail.yahoo.com>
In-Reply-To: <1786068588.911432.1550492590378@mail.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.16.0.190211
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jorge.rabadan@nokia.com;
x-originating-ip: [135.245.20.26]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: acf5a683-73fc-4227-1ec0-08d695a8971c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600110)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM0PR07MB4404;
x-ms-traffictypediagnostic: AM0PR07MB4404:
x-ms-exchange-purlcount: 1
x-microsoft-exchange-diagnostics: 1;AM0PR07MB4404;23:Mq0yfwrDPIIjCW0uqH8O5d941YVKKaKFN/BvOzQtFP/85HmasXbPiXWhbXm1mYXSRW7Y7103GofDVqthvUu6KEhNxGfJMWnKuw9P7OMLZyaZHWYNNDw3OG8S1LQLirOe/nMo/lodagBPfI5lZ9yIl3yBTfWzyDM+OlkktXSZw2kWc6Fxf56Gwy0JGeK1xEzClBvSAssw1QmIu4xLDS6mLo+wpvVcoAiMUdsbErZhtJGYG/dJ8PA5Phm97VOb2jzLBfjs1D4wIu7U0aNJOFqupg6Gr0RWjd90ZwMXomiSB0GC7nom1QaRoxlVZuP4Ft12IsQteXjfFJOG5yI6X9b0OstNpYpAFAr+BzkoZyNgGKDRiEVhzhKdSzyEu/T2b8vr7B2JEEif8JfuMF1DDumTcMLmfmBHDM9SFEVYeoDJL5tDreUd8uXVMhbuEF8+d6p7AJAj4QZmkxQy8EwzFYnw2sQCII0cMZK5hgDcB2ELoCfZf3FQ8DsHBFLgLnxpddbGMFWpHcTklefGFO25cS7NCQPnhRbcafqL3J9cUXAyM1P5SdyXe7REE6FoB7JQOeGSAvK83CWFnsk72zXsxxiTk4bf3WmtE+1H3wLJtsle5nkrLzuavE2O+mkDzxWliZcmAcaMeJivsbBwl0u+rJc5EdbVY3MlSz/iRL1bO6MPBotFGfDj0ZJDCCQMQl3TUjljLz3AciI/4Fi4EmJSBJXt8RDHijkWK8plrazJ/jnkal13uqGvt7eeZKI0u+wwHUFM0SoPBOLh96EHqJ8bMEMTN8VI5AXgjg3WM5d9nGGFnuwspldHKyQOZqXAIQrsoIxznVj/3vapqAyT1wIxDWnQ3Ugigx/v0QEcTHPqAG5n+/i3e9+uByqsOoBApUnwbYq4WGtfCLNQyG8222JeK9fKvj+Movi7iNhKL9hHr8Wf4NYo8gIgTiFfGb20ZJL6dqbngMJWDQRfVwIp1s4CAEeTA2nq6FvN0sJRw6B78DXalgWbJ5oEkzDRREX/v5PcFxRN9M9NhjMS8WeycjTtbkOD5TcOoo6r6+/ZsFIG4fMYDVi9Wuw/m43FGcn6vbmda4osb/x+vOktLm3T3qL6430gBR8tdFZr7C8QaSLWT4DIPKrkAkQUedn1LScvpbe0FAY+KMUw30v29MDgyn2u42gwV8y5WfrccTYjDSUOKLne6keXMqmXzdwB7g6jWXJcBN/jYCMkv+4Odux+jU4To1sAgNIvyRMzR4eshwiTPq2vJPoEfgr0dyOnWddpfNJdGuOMlYVm2vU4B/e7hyJ8BchbJPMdOVIre3cFWvJqkXZMgPxVLGdOlQMSEdp7sJidi/yEzvhGGATqAplaGQ1AODnjaSXKYJ/gKcdvIWszYbhm5SJ01uvpkyK1R2P0+wZLL6i7
x-microsoft-antispam-prvs: <AM0PR07MB440416B29A5BA3BE7D1A0A0FF7630@AM0PR07MB4404.eurprd07.prod.outlook.com>
x-forefront-prvs: 09525C61DB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(366004)(376002)(396003)(346002)(53754006)(189003)(199004)(6486002)(110136005)(71200400001)(53546011)(58126008)(2616005)(106356001)(6506007)(8936002)(316002)(76176011)(99286004)(102836004)(446003)(105586002)(71190400001)(4326008)(25786009)(486006)(26005)(81156014)(82746002)(606006)(2906002)(6436002)(476003)(66066001)(229853002)(6246003)(8676002)(86362001)(236005)(2501003)(97736004)(93886005)(6116002)(54896002)(81166006)(6306002)(256004)(478600001)(53946003)(6512007)(5660300002)(36756003)(11346002)(186003)(83716004)(53936002)(3846002)(33656002)(68736007)(14454004)(7736002)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4404; H:AM0PR07MB3844.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 5IGVFZcdkQQLVK1Fml7MsTbcwzzofVMn4bb8M+DBUJdaEAAT7CdI14k5D0fe5Mju/rT3XMsWgW2P75O2lZqSHtczQZ4PoG3+fgJq1wVqYxeYgnKveEq2PvVEFxZn0ErQ7QXg24nBD3Mmtj/KT1v/FU9pWntNlRnk5PaSKn8vHd1lBsrIhK51qv6icW1RUq6W25bI6Pv5AeIEr9buylfz+62jo7ploVZ09x1OK6SOkXrjZEMY7HTepOdg6iSAk2TFiSGNOHm+UnvI7ac31pbP6GfOdRQXHtrMyzqB0g2MTK51WvNce6WonGDcJgqqv+xUZKcIXnnZczAdhBCPqo5w+WU6URk0AOkl3Ivf/kKwRK3ceVOHsVWBbfDGMtF8Bd6bXWtr4GwAkNuBnMMMJAIcDqBzjLbcbMRF/vamz7kYTo8=
Content-Type: multipart/alternative; boundary="_000_7A8B346BEEBE4C3AAC095EAB714C2D85nokiacom_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: acf5a683-73fc-4227-1ec0-08d695a8971c
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2019 13:54:24.0409 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4404
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/YwtkZm7qnfVCBODH50ax2GfQn94>
Subject: Re: [bess] A question on using EVPN label and Alias label in load balancing
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: Mon, 18 Feb 2019 13:54:32 -0000

It “sounds” to me that Jaikumar’s question might be related to comparing MPLS-based vs MAC-based forwarding models.
RFC8388 may help, sections 6-8.

My 2 cents.

Thx
Jorge

From: BESS <bess-bounces@ietf.org> on behalf of Jide Akintola <jidept=40yahoo.com@dmarc.ietf.org>
Date: Monday, February 18, 2019 at 1:23 PM
To: "bess@ietf.org" <bess@ietf.org>, Jaikumar Somasundaram <jaikumar.somasundaram@ericsson.com>
Cc: Jide Akintola <jide@xpresspath.net>
Subject: Re: [bess] A question on using EVPN label and Alias label in load balancing

Hi Jaikumar,

You need to make a distinction between Alias label and several other EVPN routes labels defined in the RFC7432. Kindly check that RFC for the route encoding and their different usage/function.

As detailed in my previous email, alias label is a "hint" to the remote PE to load balance traffic, they are not used to do the actual traffic load balance.


Many thanks.

Cheers,

Jide


On Monday, 18 February 2019, 11:48:21 GMT, Jaikumar Somasundaram <jaikumar.somasundaram@ericsson.com> wrote:



Thanks a lot Jide, for the reply.

Please find my response below [Jai]



Thanks & Regards

Jaikumar S



From: Jide Akintola <jidept@yahoo.com>
Sent: Monday, February 18, 2019 5:00 PM
To: bess@ietf.org; Jaikumar Somasundaram <jaikumar.somasundaram@ericsson.com>
Subject: Re: [bess] A question on using EVPN label and Alias label in load balancing



Hi Jaikumar,



As per the rfc, aliasing is define as the ability of a PE to signal that it has reachability to an EVPN instance on a given ES even when it has learned no MAC addresses from that EVI/ES. It is advertised with Ethernet A-D per EVI type 1 routes..

Aliasing improves load-balancing by allowing remote VNEs to continue to load-balance traffic evenly though they have only received a single MAC/IP from a single ingress VNE. Meaning a remote PE that receives a MAC/IP Advertisement route (type 2 route) with a non-reserved ESI would consider the advertised MAC address to be reachable via all PEs that have advertised reachability to that MAC address EVI/ES via the Ethernet A-D per EVI route.

In your example, it would mean that if MAC1 is only learned by PE3 from PE1, but because PE3 has received Ethernet A-D per EVI type 1 route with aliasing label from PE2, it would consider that MAC1 is also reacheable via PE2 and would load balance traffic destined for MAC1 to both PE1 and PE2.

For cases where the MAC1 is learnt from PE1 and PE2 by PE3, then aliasing should not come into play.

[Jai] Any reason why we should not use Alias label to reach any of PE1 or PE2. I see the only difference between EPN label and Alias label is that Mac look up will happen but Alias label does not expect the MAC entry to be present and so no MAC lookup is required

and simply forward it on the ESI port/link. Please correct me if something is not right.


There are some optimization done by some vendor using proxy advertisement via PE2 to mitigate traffic loss for cases where say PE3 only learns MAC1 from say PE1 and say you lost PE1.



Many thanks.

Cheers,

Jide





On Monday, 18 February 2019, 10:08:02 GMT, Jaikumar Somasundaram <jaikumar.somasundaram@ericsson.com<mailto:jaikumar.somasundaram@ericsson.com>> wrote:





Hi All,

                     --------------

                     |            |

              PORT1 |  DEVICE1   |PORT3

       --------------|     PE1    |-------------

       |      1/5    |  2.2.2.2   | 1/4         |

       |             |            |             |

       |             --------------             |

       |PORT1              |PORT2               |PORT2

--------------            |             +------------+            --------------

 |            |            |             |            |            |            |

 | DEVICE4    |            |             |            |PORT1       | DEVICE4    |

 | (CE1)      |            |             |   DEVICE3  |------------| (CE2)      |

 | Multi-home |            |             |     PE3     |       PORT3| Single home|

 |            |            |             |   4.4.4.4  |            |            |

--------------            |             +------------+            --------------

       |PORT2              |1/1                |PORT3

       |                   |PORT2              | 1/6

       |             --------------            |

       |             |            |            |

       |       PORT1 |  DEVICE2   |            |

       --------------|    PE2     |-------------

                1/4  |  3.3.3.3   |PORT3

                     |            |1/4

                     --------------



Let’s say CE1 is connected to PE1 and PE2 (all-active case)

and PE1 and PE2 learn same MAC1 entry (say different destination)

PE3 will learn MAC1 from both PE1 and PE2 with their respective

EVPN label (Assume BGP ECMP is enabled). As part of load balancing,

should PE3 always use EVPN label to send the frame destined to MAC1

or can Alias label also be used? what is the need of using EVPN label?



Thanks & Regards

Jaikumar S



_______________________________________________
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess