[bess] Re: draft-wang-bess-l3-accessible-evpn

"Ali Sajassi (sajassi)" <sajassi@cisco.com> Thu, 20 March 2025 22:50 UTC

Return-Path: <sajassi@cisco.com>
X-Original-To: bess@mail2.ietf.org
Delivered-To: bess@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id BE700FEEAF1; Thu, 20 Mar 2025 15:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -10.188
X-Spam-Level:
X-Spam-Status: No, score=-10.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=cisco.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gL9jVJ7I4k7Q; Thu, 20 Mar 2025 15:50:39 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 7FAF3FEEAC4; Thu, 20 Mar 2025 15:50:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=49568; q=dns/txt; s=iport01; t=1742511039; x=1743720639; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2I5uLV3R+z14Ew4PBE6Lp9ASEmtLNjCkBpuJ2VT+2p4=; b=Eu6EsZrnPngIp6pvWHWhv2gzzIjynb204jvmmwOOk63vQRGSRNu31Z+H BCjkbZ/ZnJu8C3PPCisaHoRnpYwdz1vBI8cb81j+2mb6DaMyFyvv7vQPr sYR0U8v6tzEVqA6eF1GgfqGU7e4pmr6LkgnbNSAV6rhovBO5KB6+zbNZG KgIn79fOye09Z4bq4R6u+oS734raRrtuJYnC18x5/pYj7Prv0aQYkom3q MF1UnKMCoahuZjAPBgP9vm04mDpjb7w/C4lZzCGSYtJKbR9ooJQczxoEo 1kXM3E36R1+HidIk4c4yleSU5e948s2a3/+98mDDaIqRskXUjTMxFhkg2 w==;
X-CSE-ConnectionGUID: sBllqGrDS5uOmtf3ZYL91Q==
X-CSE-MsgGUID: nxJI6LgdSPeZpDPQVXr5fw==
X-IPAS-Result: A0AFAACymtxn/4oQJK1aGgEBAQEBAQEBAQEDAQEBARIBAQEBAgIBAQEBZYEaBQEBAQELAYFAMVIHdoEcSASEUYFjgWkDhE5fiHYDgROdARSBVhQPAQEBDgE0EAQBAYNQgTcCFosLAiY0CQ4BAgQBAQEBAwIDAQEBAQEBAQEBAQELAQEFAQEBAgEHBYEOE4V7DYZaAQEBAQMSEQohGQQDCxACAQYCEQMBAQEhAQYDAgICLgEUCQgCBAEHBgUIEwIEAYJhghxIAwEQkl+PXQGBQAKKK3qBMoEB4BwGgUgBiE8BKoEzAg6DfzuEPCcbgg2BFAFCgjA4PoJhBIEpARIBIwwSBhACgyM6gi8EggMRBBdFFmAuAYENAgICAgICAgICAgICAgKBC4EMggCCBgIIA4FaSYEGgT6BB4ISBiiEDIRMgSNyb4EfAgEEgQoGOzgQgWiFNodgUnUiAyYzLAFVExcLBwWBKUMDgQ8jgSIFNAoqDjcBKYFjaUk6Ag0CNYIbfIIogheCNoQ+hECFUIIRgVwDAxYQgx91HIRAPYRjLVCCRR1AAwttPTcUGwUEgTUFoVh2ATqDUWtEJgRDDgIgAiSBFAUBBSAtBTGSUgUPJIMZSYtSjluTVIE+CoQbhhOGBZImg0AXqXFmmH4ijWOVKoVaAgQCBAUCDwEBBoFnPGlwcBU7gmdSGQ+Nfy4FEYNYhRO1L3gCAQEBNwIBBgEKAQEDCZFlAQE
IronPort-PHdr: A9a23:kJhdahfeVOBWExDnE0xSxlWOlGM/gIqcDmcuAtIPgrZKdOGk55v9e RGZ7vR2h1iPVoLeuLpIiOvT5rjpQndIoY2Av3YLbIFWWlcbhN8XkQ0tDI/NCUDyIPPwKS1vN M9DT1RiuXq8NCBo
IronPort-Data: A9a23:C3Vwaa0XP0Ij1UyE0vbD5bhwkn2cJEfYwER7XKvMYLTBsI5bpzxSy 2cXWjyCPK3eamb2c9Eka9m3oEsPupeDyNc3TwRr3Hw8FHgiRegpqji6wuYcGwvIc6UvmWo+t 512huHodZ5yFjmE4E/watANlFEkvYmQXL3wFeXYDS54QA5gWU8JhAlq8wIDqtYAbeORXUXU5 bsen+WFYAX4g2UuajpOg06+gEoHUMra6WtwUmMWPZinjHeG/1EJAZQWI72GLneQauF8Au6gS u/f+6qy92Xf8g1FIovNfmHTKxBirhb6ZGBiu1IOM0SQqkEqSh8ajs7XAMEhhXJ/0F1lqTzeJ OJl7vRcQS9xVkHFdX90vxNwS0mSNoUekFPLzOTWXcG7lyX7n3XQL/pGF2syOZQ34MpMXHxp8 OAWcwI8SkHavrfjqF67YrEEasULJc3vOsYb/3pn1zycVa9gSpHYSKKM7thdtNsyrpkRRrCFO YxAN3w2N0Sojx5nYj/7DLolleWhnWL+WzZZs1mS46Ew5gA/ySQtjOKyaYSMIofiqcN9mFa6h zzi8GjCOhwoLPCn8AS16C+imbqa9c/8cMdIfFGizdZgjUaI7m0eFBNQUkG0ydG1kEewR5dAI kobvyAjtrN38BfuR9L2UgajoXSAs1sRRcJWO+w39A/LzbDbizt1HUANSjpHLdhjv8gsSHlyj xmCnsjiAnpkt7j9pW+hy4p4ZAiaYEA9BWQDfiQDCwAC5rHeTEsb13ojkv4L/HaJs+DI
IronPort-HdrOrdr: A9a23:62y5Ra725AexmZUmJQPXwbWCI+orL9Y04lQ7vn2ZFiYlEfBwxv rPoB1E737JYW4qKQ8dcLC7VJVpQRvnhPhICPoqTMaftWjdySSVxe5ZnPHfKlHbaknDH6tmpN hdmstFeZPN5DpB/LvHCWCDer5KrqjkgcWVbKXlvgtQpGpRGthdBnJCe32m+zpNNXF77PQCZf 2hz/sCjQCNPV4QacO2DGQEWe/sm/3n/aiNXTc2QzQcxE2rlz2H1J7WeiL04v4ZaVxy6IZn1V KAvx3y562lvf3+4ATbzXXv45Nfn8ak4sdfBeSX4/JlagnEu0KNXsBMSreCtDc6rKWE81Axiu TBpB8mIoBa927RRGeouhHgsjOQkwrGqkWSi2Nws0GT5fARdwhKTPapQrgpNCcx3nBQ+e2UFp g7hl5x+aAnVS8o1x6Nl+QgHysa5XZc50BS0NL6SxdkINEjgHg7l/1FwGpFVJgHBy7084YhDa 1nC9zd/u9fdReAY2nepXQH+q3nYp0fJGbPfqE5gL3f7xFG2HRii0cIzs0WmXkNsJo7Vplf/u zBdqBljqtHQMMaZb90QL5pe7r6NkXdBRbXdG6CK1XuE68Kf3rLtp7s+b0woOWnYoYBwpc+kI nIFFlYqWkxcUTzDtDm5uwHzjndBGGmGTj9wMBX4JZ0/rX6WbrwKCWGDEsjlsOxys9vS/Ezm8 zDTq6+L8WTWlcGQ7w5qjHWSt1XMz0EXMUep9Y8XEjmmLO4FmTDjJ2uTMru
X-Talos-CUID: 9a23:XLKhTWvKUl8XzgtqiRjWmxib6Is+WHnZ1VjKD3TlFEFsVLPOe260qfpdxp8=
X-Talos-MUID: 9a23:c4XeMwY9jR5hZOBTsS/OpW9GO8tT26mcEGw1qKs2oZSKKnkl
X-IronPort-Anti-Spam-Filtered: true
Received: from alln-l-core-01.cisco.com ([173.36.16.138]) by alln-iport-2.cisco.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 20 Mar 2025 22:50:38 +0000
Received: from alln-opgw-5.cisco.com (alln-opgw-5.cisco.com [173.37.147.253]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by alln-l-core-01.cisco.com (Postfix) with ESMTPS id 90315180001A0; Thu, 20 Mar 2025 22:50:38 +0000 (GMT)
X-CSE-ConnectionGUID: E7hIxEdBTYu8ztMMEh7I6A==
X-CSE-MsgGUID: OExo9UtwS3+LE8EZ32nwDA==
Authentication-Results: alln-opgw-5.cisco.com; dkim=pass (signature verified) header.i=@cisco.com
X-IronPort-AV: E=Sophos;i="6.14,262,1736812800"; d="scan'208,217";a="24173506"
Received: from mail-bn8nam12lp2176.outbound.protection.outlook.com (HELO NAM12-BN8-obe.outbound.protection.outlook.com) ([104.47.55.176]) by alln-opgw-5.cisco.com with ESMTP/TLS/TLS_AES_256_GCM_SHA384; 20 Mar 2025 22:50:37 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=SC77hsepl4+O+zCxL2TLpM6dfWxc2rqeKJp7bOe0IAEFlCvYMkkJxYzo7lhW5OjlJPM99VvJP66HPSkkIGizqjFy5KQYwykd7p6UuPSuOn/SI0KyfQf3KsRmnjWMc07VEGZxgRPx3Y7USdmhrqalNdNepIaeUtmfHZ274j8BhYCq5+zh2Cd6Tj8LzEwfNAZB2T5HJHm0ql3sHJFXsQGVmo48cHuJ2PMUhwJw3xzHeVGYUC4DiK9rbWvoBBySFpjJ1Wv4o9DXk5jJFz6CX+1XSZfoXS6A40Fqp0x10TYQ/LXhj4YMLPIAF3C2h5ny5KKJdrkiYPgnb9cuxNVulKL1Zg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2I5uLV3R+z14Ew4PBE6Lp9ASEmtLNjCkBpuJ2VT+2p4=; b=APnaOoZkd7GjvWyumL/hr0ND3d+uJhR632f1NF3W+u+sQjPA+pjNun8dDuZXpF8EY/C8Zzp9cFlLwRSXxExppkH5AQY5SMWqLtIs/iK9PmiQLJxJj1hq57d2mkBULOh10TFXQdCwdGgS9hLbwX3MtxHaM6O5EdjrIlvjyLrgFlqS0dlZ3CM/gCpbA5gyTsKMrT+wKLb+/NiXcx3+79swlmluvzAQC0CnAqDUmwRXebZ4cm/wHFf2uI921p5K8Yx6Dl3pr2xC5/jKrS90I4Cvn3RqcGZiNA90r3sS7+J86YpLO0d+BZcsX0Zze3QPR9+af7x3FwHuPEx8I4Xo+oiDhA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
Received: from DS0PR11MB7734.namprd11.prod.outlook.com (2603:10b6:8:df::7) by CYXPR11MB8756.namprd11.prod.outlook.com (2603:10b6:930:d6::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8534.36; Thu, 20 Mar 2025 22:50:34 +0000
Received: from DS0PR11MB7734.namprd11.prod.outlook.com ([fe80::c8:8dc7:b32c:d323]) by DS0PR11MB7734.namprd11.prod.outlook.com ([fe80::c8:8dc7:b32c:d323%6]) with mapi id 15.20.8534.034; Thu, 20 Mar 2025 22:50:34 +0000
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>, Jeffrey Zhang <zzhang=40juniper.net@dmarc.ietf.org>
Thread-Topic: [bess] Re: draft-wang-bess-l3-accessible-evpn
Thread-Index: AQHbltBifP86mf2/IkO+cDEYA8IIB7N7/GaAgAAn3gCAAHk54g==
Date: Thu, 20 Mar 2025 22:50:34 +0000
Message-ID: <DS0PR11MB77347E085A49B5C56F173205B0D82@DS0PR11MB7734.namprd11.prod.outlook.com>
References: <DS0PR05MB95655695E985B36B85253A80D4D82@DS0PR05MB9565.namprd05.prod.outlook.com> <349AE23D-FDF0-4BEE-8007-72C81A388398@tsinghua.org.cn>
In-Reply-To: <349AE23D-FDF0-4BEE-8007-72C81A388398@tsinghua.org.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-reactions: allow
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DS0PR11MB7734:EE_|CYXPR11MB8756:EE_
x-ms-office365-filtering-correlation-id: cfea8477-ba10-4866-3f75-08dd68019fb6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|4022899009|366016|38070700018|8096899003|13003099007;
x-microsoft-antispam-message-info: EL0dAWaLsXAFrj62nAtXPgBX2Jq7lo4pRGV3f5r/RB3ulRZpPnMijDCphIVh7y8y0plCf80eOsrd1nrjtCBO0cEAUCjpTcmfdtKRp2AYxGw4ECOXsy0IukV/KlLpbTqAsVRypbJV45ohIgTVAnVHTY32jtnOgNtRstnjbe8c4bS2SwOmyV/6grMWGDke+fXAscDq3fu6D3eoB41Dhiu+x66u7F516Ea12moXC4AF09490Pfko4CvhodVNs/zLFjPTZuIgRWWSchxHIB1ySzp/JaElI+wq932Kqr87dc7mA6NBEuseUqj9YN4U7BMHnjmQaNGTmDtnxHblvBxJa3lsV9Hfn6+jZIerTpKcKpUatFA80u8XIbt2BpS4riH9fsTwFKP+8Kb5J/d/q/0OJa7yIir36bT9zO7ik3Niack4VzMjnTdFywvUneWVDdr2TgIhZiUruhNAV11jU6r6zHb+rk/Oo4lIYSSdhAw1WhvRP5x4KDnmrFlEs06FUCFNGyGX5AtI7ZPOlB6S/X3oay2A6HVcJvgeN53LKhV4hRA7ZWr5oeUMI8oBelVM59El4Pq5D1BBqeLYqdujfAd+ZFnXc4zJsn1DngN1ieVl8UUDWn55bRmQKHIw0YYudH0WNvevHxg7aGIcMf3v3sxjHA8UKJOalvBFvhKeWyjA56+A78pOxOIkayXDO8VQEXwfkFrfVAnagDlkj5vuKubmejtHPQLzTjdx6WcuBAw1AH2oWJvLpQo3KOdczOWUZAHESsgqoTJxneCoduyclPQ1SOX3adK/AenLe9QQSu4Tgw3F6IjFnGI71ymspn83AwfZtsTFe1uMSa8fQtJvu+OxguwKiyg5R4oohT3iEAQU2epZl3GX+Pml9Ppcei84Q64IXRp8QpOfvog/brqjSoWn3OlimFXGV9wt7OCMx5RnZLjUqjlOTC3TRCf958v1ATP63/9RkiwNpkaTjcDKYGaVOmfipwyIU8/uYkx3Xo5hmd2Hvq/ah/Fzvd48f8Mog3Mgl8g/ht44W0DvS3b1VxIYdh1wjoLQQs/CFa1lWFACYL0O2Kd9rjcVwLzl296XUfwTtDMkRhds2LmIBGhgNJi/T6t9JK6iIcmtyppR+okI9Xl0VFJUka3clHxfkZA2pp6tmkU9eFOxxwSBshYVWlRnoaJxjpNcIQeRiA7hsrLd1O0wqrBqB3uEZ109cI+33g0xey+AwEkez3v4OZWHFxBZYZ0oI1x1FyUSCXnRWxDvAPILp2To57wmd/A3iZbBUZ6YZrLAe/PLZWm4qvA2VpaGOiHl6DFsYbHTiYnJCku9BM6WOxA+501qRQXAquJNPECK/6kpgtZHN+xp5mXwft/T6oXIB1MAhwGxl54RjSISg8wm9pvetzqSCXn13X1GAyy9eRu/6zopu10FRDjmIMazF6vbg==
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DS0PR11MB7734.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(4022899009)(366016)(38070700018)(8096899003)(13003099007);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: rhL9le+0tnvVsI6+K9Yb5bOl+jXj2xOOzw+mljFq7Dpwx5Gu/5gsPXVbeI8AErXneBI69d57BfghG+z0PBc8wplCLiRokm+q66ZhfOiZ90KQsmq+NMtCUcMkz08i5S/Et6y4iGiS0zj/Gm4xn5koF071xBfLeCn4v/jIxQAr09LRyAjj01JStkqeLpuipcAELYIFfzzwEgOl1W3lUuSNzYWnXi2gRhWMG1y69EzAgHUU4De0wWG2EaWSb61VcVIqSyPSTkP/GsKc3U7FGpZWgJHmBteslMY8uX22bDAFMVEnzC9Oex5Al7mnhEzK1UzUPzeT8BjudwJY6/tLtnTvu85w6qpMlGOXvuAwQLlGxdC6DUwjiJ+DrT2zyCVbotyLSNgEYYPX+CmR5pNWdlg9pwE5Er7cj6wJLmkpcgdgJjH7D2R3yE0L2TnH2RTrKztfM+3xD65rIpBduvHzNJ2lCCfZMFck53Wo18HrGup4mFEa8AlxV3CYwBvXJFLEZKtGFMuGBqRTjKVATZUBHWUzOXaEEoOgwKaIhk4OJn5Ej4KbnvltbDjZdMxb6cXe+pLE6FZbAVKuwihPQ1UMDMsZinHajlsu18nlYNeMrLV+4O+3IHT+0xo0UTyfA4jMUe00tuhdBwZPVvPZHemd/wyMsgE0WfbZuH5WCUAihF0ZG37Niu6yjqDxncZxwozmfY7UW1f2S1IjLr0o2DMKW4563EitUvafM/TorkzmBuARZReFBZdDA+iwXMgqwDCIN/zRS3c9GO1S4oiqQjTZ4N7zQJN/qQhul9GTMrAmLIwA7Kn/UPXrxqUdO3o/3wm0UWkBAethy8Aq2Ll0xUZxbcY3sAs7sm1ffqBRm8j4TKEZfOD99dF3vOKw5V6QXShe6NCkE3m+br01I3laGNqC5aYoM/nUZKLdx139DpeqinzNDmnO1H1+Nm9NyjijnIkypDBn/N//p79Kk4G6sIBC4a28g2fFF5opdNmFCIz94GZx/E5yaNugbZqjZ71QzJlZ7V1XZZ3kwohg9UEf6jmvVfXs6/qMEQEs/JQN8QSSuPRCjMjZisjYR3DqWJeku3nZ9z5PwEEzHR3OhN0A22LVKxQwkxwjv2/FrOMAUITkb6hl5xMeumPqo1eufIA/yY1tiYGt55NtBZqMnvj4U5zrc+nmMeo160SunQInbjfNg1HCdLsIoanMpg03Lm/ifWJjaPYEgLGoNG5F1ODJRQ29GRj0L1r43YJ9teULxY58bAakYMxsAxGpT1Na6gW7drk5rfbpdAkpBkiLaL6TiumnX83o55YYSisuOtncHx2wI845CTwV5kXBDHO+6L4mI/2JFbWZfzPBy541GsZCwJwq3sqGugbNF0hMq8PREGDpKcqG8SghV3BZR4p2zokXg4KfneqCeDkt0Ccow3H+/th7VZt2/OlJ8cj1xOOakMvFX2KxI9fWkTCv8MC1nXkqp8ytwc/oJvW5Uq9Zy1ZdaA5H+cuq/DjiJmA1eaR8KlP268gObrVCHqHieKFyRhJ5x9ptJpt6tOUme9HxtdI0pXaX68hQKpj7A2g4DDnr+ysdMWAVi/4kRXPtCy/MA2Yf7OghVwa3owNqntYtFmN985fyPWeXlA==
Content-Type: multipart/alternative; boundary="_000_DS0PR11MB77347E085A49B5C56F173205B0D82DS0PR11MB7734namp_"
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB7734.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cfea8477-ba10-4866-3f75-08dd68019fb6
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2025 22:50:34.0134 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: AVpP55ZTj9Igac2xZR2I3peTAaGxjsuH4bv7yqX9e+YMe7IFThWMaBl7eoHRwkAYf9SZovxk0LOLp0RIMwhvEA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CYXPR11MB8756
X-Outbound-SMTP-Client: 173.37.147.253, alln-opgw-5.cisco.com
X-Outbound-Node: alln-l-core-01.cisco.com
Message-ID-Hash: BCF6GSOZ5OIQ7VW4H6HLOM2LTUOGGGAF
X-Message-ID-Hash: BCF6GSOZ5OIQ7VW4H6HLOM2LTUOGGGAF
X-MailFrom: sajassi@cisco.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bess.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Aijun Wang <wangaijun@tsinghua.org.cn>, BESS <bess@ietf.org>, "draft-wang-bess-l3-accessible-evpn@ietf.org" <draft-wang-bess-l3-accessible-evpn@ietf.org>, Jorge Rabadan <jorge.rabadan@nokia.com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [bess] Re: draft-wang-bess-l3-accessible-evpn
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/BzHi6C--PQ9fwyC8rSTJoMjc1co>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Owner: <mailto:bess-owner@ietf.org>
List-Post: <mailto:bess@ietf.org>
List-Subscribe: <mailto:bess-join@ietf.org>
List-Unsubscribe: <mailto:bess-leave@ietf.org>

Hi Aijun,

As I was explaining to you at the mic, what you are trying to do already exists and it works better than your proposal! Here are a few points to explain it in a further details:


  1.  Your draft doesn’t explain what issues or gaps currently exist in existing EVPN RFCs/drafts, and instead jumps into a proposal of needing LSI field in VxLAN header.
  2.  None of the EVPN experts are clear about what you are trying to do (including myself) and that’s why the questions from Jeffrey and Jorge.
  3.  As I mentioned at the mic, my guess is that you are trying to backhaul traffic from CEs to PEs (per figure-2) and then map the traffic to different EVPN service interfaces on PEs. For that the existing VxLAN constructs as explained in both RFC 7348 and RFC 8365 do the jobs and nothing else is needed. Furthermore, because CE does VxLAN encapsulation, it is not a CE but rather a PE and that’s one of the reasons for confusion when reading your draft.
  4.  VxLAN encapsulation allows for VLAN ID to be carried after VxLAN header and as explained in RFC 8365, that can be used to provide VLAN bundle (or VLAN aware bundle) service.


So here why you don’t need any new field (LSI field) in VxLAN header for traffic backhauling over MAN and mapping them to EVPN service interfaces at the PEs (in figure-2).

  1.  If VLAN based service mapping is needed at the PE, the VNI itself is sufficient!
  2.  If VLAN bundle service mapping is needed, then you carry VLAN ID after the VxLAN header per RFC 8365 (inner VLAN ID)
  3.  If VLAN-aware bundle service mapping is needed, then you can either use VNI or inner VLAN ID

Why existing RFC7348 and RFC8365 are better than your proposal? That is because

i)                    when you need to provide (b) above, you don’t need to do any VLAN ID provisioning on PEs because they will be transparent to them. Whereas in your proposal you need to configure LSIs on PEs!

ii)                   It doesn’t need a new field to do the job

iii)                 It doesn’t have any backward compatibility issues and interworking issues because it uses existing RFCs!

Cheers,
Ali

From: Aijun Wang <wangaijun@tsinghua.org.cn>
Date: Thursday, March 20, 2025 at 8:02 AM
To: Jeffrey Zhang <zzhang=40juniper.net@dmarc.ietf.org>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, BESS <bess@ietf.org>, draft-wang-bess-l3-accessible-evpn@ietf.org <draft-wang-bess-l3-accessible-evpn@ietf.org>, Jorge Rabadan <jorge.rabadan@nokia.com>
Subject: [bess] Re: draft-wang-bess-l3-accessible-evpn
Hi, Jeffery:

Yes, they are related to the MAC lookup, which can assure the traffic isolation in LSI based/LSI bundle/LSI aware bundle environment.

The related forwarding plane extension and control plane extension are only necessary for LSI aware bundle environment——in this situation, the destination MAC of incoming traffic will be looked up within the specified LSI BD domain only.

If there is no LSI value(which is different from the VNI value of backbone EVPN) associated with the income traffic, the above aim cannot be accomplished.

Aijun Wang
China Telecom


On Mar 20, 2025, at 19:39, Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org> wrote:

Hi Aijun,

My quote of RFC7432 is in this context:

“If your intention is to avoid the MAC lookup on the egress PE (which the draft does not talk about)” …

Is that your intention? If not, then the quote should simply be ignored.
If yes, your draft should be clear about that (it is not currently); and I will come back with more comments.

Jeffrey




Juniper Business Use Only
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Sent: Monday, March 17, 2025 7:06 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>; BESS <bess@ietf.org>; draft-wang-bess-l3-accessible-evpn@ietf.org; Jorge Rabadan <jorge.rabadan@nokia.com>
Subject: Re: [bess] draft-wang-bess-l3-accessible-evpn

[External Email. Be cautious of content]

Hi, Jeffery:

Thanks for your analysis.
Let’s try again to converge based on our current  mutual understandings.

First, the conclusion, the solution proposed in this document is necessary.

Here is the reasoning:
What you quoted at https://www.rfc-editor.org/rfc/rfc7432.html#section-9.2.1<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc7432.html*section-9.2.1__;Iw!!NEt6yMaO-gk!EVS8RAEKl0m4mLCuOqpNzbkMSq2HFrRlHCebswm9hv4cNcjVIUouszlapK9Cr_XiqJ9ekoWkbuol07Bc7idetStS$> is just the traditional layer 2 access EVPN services or one of our layer 3 accessible EVPN service(“LSI based EVPN services”), the protocol extensions proposed in draft-wang-bess-l3-accessible-evpn is mainly for “LSI Aware Bundle EVPN services”, which is not covered by the current RFC7432, or any other existing EVPN related services.

For example:



A PE may advertise the same single EVPN label for all MAC addresses

   in a given MAC-VRF.  This label assignment is referred to as a per

   MAC-VRF label assignment.



—-The above description corresponds to “Layer 2 VLAN Bundled EVPN Service”





Alternatively, a PE may advertise a unique

   EVPN label per <MAC-VRF, Ethernet tag> combination.  This label

   assignment is referred to as a per <MAC-VRF, Ethernet tag> label

   assignment.



—-The above description corresponds to “Layer 2 VLAN Based EVPN Service”





As a third option, a PE may advertise a unique EVPN

   label per <ESI, Ethernet tag> combination.  This label assignment is

   referred to as a per <ESI, Ethernet tag> label assignment.



—-The above description corresponds to “LSI Based EVPN Service”.



As a

   fourth option, a PE may advertise a unique EVPN label per MAC

   address.  This label assignment is referred to as a per MAC label

   assignment.



—-The above description is just for some very specific situations, and is not in the scope of current “Layer 2 Access EVPN Service” or the corresponding newly proposed “Layer 3 accessible EVPN service”





All of these label assignment methods have their

   trade-offs.

 The choice of a particular label assignment methodology

   is purely local to the PE that originates the route



Aijun Wang
China Telecom

Aijun Wang
China Telecom
On Mar 17, 2025, at 05:12, Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org<mailto:zzhang=40juniper.net@dmarc.ietf.org>> wrote:
Hi Aijun,

Now that the -08 revision has been published, let me bring this discussion to the WG. The email thread has some details that help clarify the intended use case and why the proposed solution is not needed or not good.

The draft does not clearly state it, but based on our discussions below, the PE-CE connection is a PW that terminates into the EVPN PE. There are two previous points that I want to re-emphasize here. I'll then explain why your proposed solution is not needed in my view.

- There are already deployed solutions of PWs terminating into VPN service PEs, including EVPN, w/o any protocol extensions
- On the EVPN side, there is no difference between "a PW terminates into a PW-PE, which then connects to EVPN PE via a physical L2 connection" and "a PW terminates into the EVPN PE directly"

Your solution requires the ingress EVPN PEs to put on the PW information that is used on the egress side. That is just unnecessary and not appropriate.

In the true L2 connection case, the MAC lookup on the egress PE leads to local forwarding information, including the outgoing AC and perhaps VID translation information.
In the PW terminating into EVPN PE case, the same lookup leads to local forwarding information, including the PW information, which is *local* and should not be advertised other EVPN PEs for them to put into the VXLAN header.

If your intention is to avoid the MAC lookup on the egress PE (which the draft does not talk about), it is an orthogonal issue (nothing to do with PW terminating into EVPN PE) that is already solved. Per RFC7432:

  A PE may advertise the same single EVPN label for all MAC addresses
  in a given MAC-VRF.  This label assignment is referred to as a per
  MAC-VRF label assignment.  Alternatively, a PE may advertise a unique
  EVPN label per <MAC-VRF, Ethernet tag> combination.  This label
  assignment is referred to as a per <MAC-VRF, Ethernet tag> label
  assignment.  As a third option, a PE may advertise a unique EVPN
  label per <ESI, Ethernet tag> combination.  This label assignment is
  referred to as a per <ESI, Ethernet tag> label assignment.  As a
  fourth option, a PE may advertise a unique EVPN label per MAC
  address.  This label assignment is referred to as
_______________________________________________
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-leave@ietf.org