[bess] Re: https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html (section 1.3
"Jorge Rabadan (Nokia)" <jorge.rabadan@nokia.com> Thu, 31 October 2024 20:30 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 0E8C3C18DB8B; Thu, 31 Oct 2024 13:30:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.242
X-Spam-Level:
X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nokia.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPb48wc3TCri; Thu, 31 Oct 2024 13:30:37 -0700 (PDT)
Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam04on2063.outbound.protection.outlook.com [40.107.101.63]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C32C14F617; Thu, 31 Oct 2024 13:30:37 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GjUmt2nHm79D2a125LOl1n9WCezZvdQStoHIotniTXhn+NFzZ6qYppS3BQYlfmqoVHGrM1ANexC2sMevVL7oISS5mdYObhbfc5kft1oAliMN3fIszgPcqyHXG1X2EIoU32Gm7UM6VGbU9A5arqyxD0IvIVm777flJfkBAxUa4opDx1T382fb5bKwKePhNFKS9JoZ0RPSLzAbDGgSnXVm1CfbqA/quZ8279lX6ypmJgdW5bKcgRxfTqjwt0CeOW32vsku5/zLSwvORrDgnLb5lOinEJy+VoWmb5yRz3w74KMuM+xgTbqaCW3LTBr5L0kbScM+PlfPNF700iFhSbOsGw==
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=XU0YzMQimlT+H9e7qGDnVJmu3R/HFbMnL8n80cSMVRU=; b=s9nyJiznmF5Ka+O1wqICUzHIUCIpn4WBu1UFGbeW8b32rT4YfyK3v1WJFlp2Bcu6vPxx8ojOLRC7whB0M38oCEm3RLo/cfGt2qQk9K9WmHuThDAlcmGx0pyvdPb7oDGs8uUq4uU6+a8T7DMF94SYTwcZscaezrP9YNDs1mi97eCsr0L9RdG/JTqMgsLpmF1d4YN7Bd2zRO1qtJdF+QgUUQFmraj9L0IpmNTenqQrlYMZWheUxO4Qbn4N76Go3vlP0ZTNiMF1A2AZbGbbQWTzr3s5tigB/kYbCdY+JDAcE0B4unza+GdVOsb1OyJAUMVzvgYl9vEFPqdiVY7sM3Sd3w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XU0YzMQimlT+H9e7qGDnVJmu3R/HFbMnL8n80cSMVRU=; b=rs6EFQy4vIDoEy+u1caL+nQizPldcR43mylL/yxzU/jaOQdbQKrR8UgpgnzioWopwamlUPmOiUe4D6ti60HLLxrrMbtNL7EfHBJlCpGHknJfTX7C6m9QUORF4/z9JRfS9WUbxk6r2iB2VhJkhfDnWN3F9VCqJ9EXXZZL804/otkXab1Xo03VaE+VpfcFa3wIuMiCMPJ/qdOsuYzzb8Ck6Ko1hF7iEzMf9cYoKQUAnEs+BkPriPDjizfMozp5g+5Nw2XDToET3Csyq3K3WkzDDmUUOW9EvWzHSLu9WoPI185sQy6hcPo09gB+3ou48158yeySOdoHiElhqX5xWpsELg==
Received: from SA1PR08MB7215.namprd08.prod.outlook.com (2603:10b6:806:1a9::17) by PH0PR08MB7672.namprd08.prod.outlook.com (2603:10b6:510:dc::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8114.20; Thu, 31 Oct 2024 20:30:29 +0000
Received: from SA1PR08MB7215.namprd08.prod.outlook.com ([fe80::b10c:f208:adaa:c369]) by SA1PR08MB7215.namprd08.prod.outlook.com ([fe80::b10c:f208:adaa:c369%4]) with mapi id 15.20.8093.025; Thu, 31 Oct 2024 20:30:29 +0000
From: "Jorge Rabadan (Nokia)" <jorge.rabadan@nokia.com>
To: "Dikshit, Saumya" <saumya.dikshit@hpe.com>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html (section 1.3
Thread-Index: AQHas2XdpxVSYotrBEiSfGvqSEnm7LG26qeAgAstwoCAC8facYAmqqmAgA90gICAIABvgIB92qwm
Date: Thu, 31 Oct 2024 20:30:00 +0000
Message-ID: <SA1PR08MB7215B0E809822A4E0610870AF7552@SA1PR08MB7215.namprd08.prod.outlook.com>
References: <DM4PR84MB1830AEC3FCC57F3A127AF76382572@DM4PR84MB1830.NAMPRD84.PROD.OUTLOOK.COM> <DM4PR84MB183025E380A2252E6595458782232@DM4PR84MB1830.NAMPRD84.PROD.OUTLOOK.COM> <DS7PR08MB6862B8659BFE7F8879676987F7232@DS7PR08MB6862.namprd08.prod.outlook.com> <SJ0PR84MB211019903AA1E46B96FD333294222@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM> <SJ0PR84MB2110A60429186B4FA4DA6F7894222@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM> <DS7PR08MB68625EBC660A5368B3FF570DF7222@DS7PR08MB6862.namprd08.prod.outlook.com> <SJ0PR84MB2110C87E22D7B85FBF24E96C94212@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM> <DS7PR08MB6862C39B9F94C271860BBF78F7212@DS7PR08MB6862.namprd08.prod.outlook.com> <SJ0PR84MB21109651BA55F702D2F47ED994272@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM> <SJ0PR84MB2110EE3528A98FD89BBC205494F32@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM> <SJ0PR84MB2110253E84BFFC3F3D944ACC94FC2@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM> <SJ0PR84MB21103149AEAFA14F48BA9E0B94F82@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM> <SJ0PR84MB2110D62E2BA46558F9077E6A94C72@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM> <SA1PR08MB721530C521B18B703D3EB7A5F7CE2@SA1PR08MB7215.namprd08.prod.outlook.com> <SJ0PR84MB211058A7C223095C3678553894A72@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM> <SJ0PR84MB21106B4AF6E14F88D2EB21D594A92@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM> <SJ0PR84MB21101C7CD55FB1BD89F812DC94852@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM>
In-Reply-To: <SJ0PR84MB21101C7CD55FB1BD89F812DC94852@SJ0PR84MB2110.NAMPRD84.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-reactions: allow
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SA1PR08MB7215:EE_|PH0PR08MB7672:EE_
x-ms-office365-filtering-correlation-id: 4d39fddf-f152-4127-9225-08dcf9ead9c3
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|366016|1800799024|376014|8096899003|38070700018;
x-microsoft-antispam-message-info: 1xg5QXjycAX5+jvU3yfcu5c/2Pa4xxtdzGBJzS0wlv9KPFuCAa9q/DihU3eUULQIlW19zfSDF/QVf4k18wZVM1WC2ThDlC/DAmq27HRB5juW3/tKhJQjxf7xG4EE5io4KkrkLdYXEyxvILcxA6RnkcMTzXo2mVC+lnQgZ4bBBPKVEsFUw7MMAX1WnKpXnxEg9mnSGuuY5DLoo5I74H80/7dfj1JCnL9guROcjPzAigKUheJXhBvNwLmLxOy6QNo/l4P0LvIBDHQDM+KUySZpW3EeC5m8PM0x5Un7SbvqmZOvub0Q5fPLO2v1Dm9c09tHg6QjoD0XLDEKV1M0Ph5noXI27nJSfX96vletL7dBcsOkAX4hGHxpdzSReE82QivDixoPwdtBQ13NAwLdMYGk+EJ8OV7LzAS1lkW6JHZ/HhhfBmtFKoAHEItN2/SIR8BOY0UtzM1bli3f2i5modVV7hGmM17sFmjZCLrv4YdcNrIduwXL65o3bOoPPCMkRBHdAd6qI+SDJ0WkMPk6gv6tQC5wX6MIUheYccXY5/At1xdfxQ0lFqqWtes/R5EKn3vbdimZGtr5EeMnx3bhjdxjRItJ1qhmnU0nDTN26GIM/dQGNLgUoU10YuLBUYkRUE2G9TrW52mRYzXgXBx9iYYs7NFjGK2JgvUI0ltXtkDq+H2s7izcYvQJe6oiArB6Hh8tLu2zAKRzwEkxLKPK01JrXFPhctA0xiY74oLMufuX6edtjfdBwKmZJp8WQFCyaAl98HtK5UHzW7UNPhchv/dxSrcSlx1nGA0HKcsuCxLbzgFR6r1i+xApbnqsOuX+x+hLw2ORM1RtzFC1cNyewRCNK9F7GM3XatNIdLMUfSNYtZAkjsX4tHsCI6eDwl/T7oVppNZ7Z4jl3q3aMBYOaENPXVJKzFCriOWOWynW0uEh/F+IAyXNXaJDvyU0zXWsVk4cjgUSrdYF+iqLvYix6mxDr/upCPT7uwlOIYX0tRHp4m9C5rOy4X3X7o4eDZATqcYPP76qi67EyErGyYguBR1DeLYp4DUhnJPkD48QUzXWo0EBoHMhIDFXGXS6aMvN64ePL0ZLxttHtGTcVJV5amGEoXHO3QlMMEOyqRZhHibsJRDjXONQdNBH2BBfUJGFtTueI525DytBvcdEPKZmPwvIdEOWjZ0Fc8wglCZalK108KXVJWjE6SQ8/x7ivL88ZzMYzOhBuCWgZLod3GMcskfbrlhiltDuIKYQv11T3emVjjS9J56g9HDRBTqsBFyJ2FBmhECxgw8lbUiaABPdSHNC93XoX8NuLDCNE6pRs7Iu7xWocwk6zrV6N1IZefhKlaxo+JydyRqVVEdA+eklQqxa0w==
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SA1PR08MB7215.namprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(8096899003)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 5n0dHWzpFXl7fahL0LpTMpct9X8kXVThSTbUzfwS0aAZkxS0Wn0CUj1TgdCmlttPHEg0sBMgjKiNgUzSedcClRzjWN5NkQf+t7iAhGE4up77KQugoSr+9mgzwO20wFJFJaFB+Vz7jHBAPAp4GBucAcGfhAaH35gA/qqw/ZqCXRiFpxpSs3bodT94Ztj6ZshlCpPK51i0YzO+xPrxq1OOh3tB8AtUwRJ50arSQQH83hlNggUGBRyu3hhURbWm0hP95HcE7M9ZlR810lmxfwSFYryn1UGeSXNWssInL1e1tTasG5RcX0IjPdvjzz+9auigc9B8Pcf7T5p5/w0yHnNzy5YgdeQ7/koxeq+dT6E5QNlbT/T3UBNfY/w7/JSIbbY57yttGhHYJtNyLY+lWJVM8iZEI5LdGrIdudE9skUQpMUMrcp9zxh5E0QqJAtSUbTTAsLoF1aXd8NQBePBjortrzxeWTEGjqVF69mf8odtg3FO0LxL3SH7qaKWUarLTldQ+7cbxUiSgWWqG80FxU+BHm3e9AbwpWPRwP0SJ7DfvRhyB6MIBh6S6/SxcFY4gXPY8YtgHFLxhhsGfhWew8LtuKrbv1GBc5VuaIM/fVV81s96FRUL+1lABnnXi0NOMIrKJbu3oFZQz5j/1xxvLxvnAW4r8RbXmozwfGq4AbMpd2NLJBxnB6PbfY9E66nxZgaML37bii+EMNHcrFa3VlCFA6MyJL2s5XGGjt6JZk3VR2dzMHOnJ2mutWd+AS+Lo+xOWhngwZV4fwqHU3Lfb5Bjb6Bs3klZOPlm0zHK49+wrzq9v9SJDsPh1cqWlZ42my7wzWTIi9hfheEUbHAjudYP09ttQUX8avhDFarb5FpdspiwSXhgtPF/xrzZ+evO8vpqZLDyibMNk6TYZaApcqxdRsDvpgEdcBufrV8dMkYiOkA2C0F7gNrie02HsfxnlGxptIEEnnMpxd5LPeqQuM3n7shEQh6vnXgvkaj71LRgddV7lWhtXNGAJF02j3VZNv+A4fSRMuJ4H59YxLYMkufm9U+84pH0R+/sOtLo6NYPOcFH1W0RtHXRmwSTyPbqDyJUCF/28kdfQ4k/bAK5D7HboSYQCZ8B5LE0YR1bKr45cMzX1XGa0pr2ejl58PmfSZVIcFNEDTn8Sbnij3M4D1eMg4fKQz97fbQaHY4oT6KIRo+Rtq0Yx6gZQFLWNvl8sF7DN5YCBY7wPqCQT8JkSIqy9QNhGbmWK75xU7AuxBFaXZ+dIXQ9o3LBGK74p+IBJyOPWJFe8pMwl4Sb+WdTOqyV1y46J6/IM83XGv8onb4Hp25I9LtVYBLo8097kT3PKlSXCbfZeNfTdRrxxXK7tFNnAe9lT3txY6vGGfmW6FWBv8zmZW19ULYZaj+pxqEsWVYLA4DYo0eTOcCbcVJbDClbKfGgKDC68dSPs13EU0T11sNRVhQDZC276DC6tyb3mOur25he86QMZehnk8+ImGuCb5LPaCFQ5+TUaTYLe3EHmbsALW7lelzxkTk2zDwxdfPJL+CGYGWspdiTmplGZa6MuYbFk0tjF2TkTrbKRjvSigca+VNG+aTPTCupFQTn/+bA
Content-Type: multipart/related; boundary="_004_SA1PR08MB7215B0E809822A4E0610870AF7552SA1PR08MB7215namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SA1PR08MB7215.namprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4d39fddf-f152-4127-9225-08dcf9ead9c3
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2024 20:30:25.0594 (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-CrossTenant-userprincipalname: aUQX3LzTbB7cdxSTJ3a7I5qCgT/1Gv4YirtO68rxBVZwP8Jwry39txncRyx/B/x8tQ0/cig7Yljlez1klXbd6w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR08MB7672
Message-ID-Hash: PUAOPKA3LZKFJOXESNGDR4JJ4LOPDJ72
X-Message-ID-Hash: PUAOPKA3LZKFJOXESNGDR4JJ4LOPDJ72
X-MailFrom: jorge.rabadan@nokia.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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [bess] Re: https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html (section 1.3
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/99_yFpfhAxndwTM4vP2U9KEuUxQ>
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 Saumya, A bit delayed, but here you are. Please see my comments in-line with [jorge]. From: Dikshit, Saumya Sent: Saturday, July 13, 2024 1:17 PM To: Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>>; bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>; bess@ietf.org<mailto:bess@ietf.org> Subject: RE: https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html (section 1.3 Hi Jorge, Thanks for the reply. I am responding separately for the following statement, as it may require a different scenario to be added for IP-vrf-to-IP-vrf IRB interface less model as I mentioned in my original email. >>>“VRF If your centralized gateway is somewhere else, then PE1 and PE2 are not attached to the IP-VRF and then we talk about a different scenario.” [cid:image001.png@01DAECE1.6C0DA040] Consider the above topology: · PE1/2 are hosting interface-less VRF (vrf red) and · vrf-red is extended to PE3 and PE4. · PE4 is the centralized gateway for prefixes in vrf-red. The snooping up of CE1 credentials and publishing it to PE3, helps in solving the problem of traffic going via centralized gateway, i,e extra hop (PE4) for the EVPN tunnel. Hence, it helps in having the reachability of CE1 directly from PE3 via PE1/2, instead of going via PE4. For example, the traffic from CE2 to CE1 would have traversed the path CE2->[PE3 to PE4 tunnel]-> [PE4 to PE1/2 tunnel]->CE1. But with the solution at hand in this draft, the optimized path from CE2 to CE1, is direct: CE2->[PE3 to PE1/2 tunnel] -> CE1 [jorge] you say PE1/PE2 are attached to vrf-red, so I see no difference from the scenario in section 1.3.2. Thanks. Jorge We need to create a subsection/section in the draft to capture the above deployment scenario. Regards, Saumya. From: Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>> Sent: Tuesday, June 18, 2024 11:14 PM To: Dikshit, Saumya <saumya.dikshit@hpe.com<mailto:saumya.dikshit@hpe.com>>; bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>; bess@ietf.org<mailto:bess@ietf.org> Subject: Re: https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html (section 1.3 Hi Saumya, Thanks for your patience. “Section https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html#section-1.2<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html*section-1.2__;Iw!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBli5LTvd1X$> Multi-Homing for IP Prefix Routes in the Interface-less IP-VRF-to-IP-VRF Model<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html*name-multi-homing-for-ip-prefix-__;Iw!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBli-r46S2c$> talks about leveraging ESI towards CE and snoop up ARP/ND to draw up the host credentials. Can we assume that this scenario consists of layer-2 Vteps only (PE1/PE2) with respect to the Vlans (might be no mapping EVIs) over which ARP/ND is snooped. Typically these deployments have a gateway (may or may-not be EVPN-IRB interface) somewhere in the network ( can be a centralized routing placement). Is this section trying to call out a layer-3 gateway-less network for the tenant behind CE ? Vlans on hosts behind CE are not extended beyond PE1/2 in this network.” As stated in the title, the scenario is about multihoming for IP Prefix routes in the EVPN IFL (interface-less) IP-VRF-to-IP-VRF model. This means PE1, PE2 and PE3 are attached to the IP-VRF of the same tenant – as it is also written in the description. H1’s ARP/ND packets are snooped and learned on PE1 IRB’s ARP/ND cache. The IP, i.e. IP1/32, programmed in the route table of the IP-VRF and advertised in an IP Prefix route. If your centralized gateway is somewhere else, then PE1 and PE2 are not attached to the IP-VRF and then we talk about a different scenario. Hope it helps. Thanks. Jorge From: Dikshit, Saumya <saumya.dikshit@hpe.com<mailto:saumya.dikshit@hpe.com>> Date: Monday, June 10, 2024 at 10:26 PM To: Dikshit, Saumya <saumya.dikshit@hpe.com<mailto:saumya.dikshit@hpe.com>>, bess-chairs@ietf.org<mailto:bess-chairs@ietf.org> <bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>> Subject: [bess] Re: https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html__;!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBli0vPbkL2$> (section 1.3 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Any help would be appreciated From: Dikshit, Saumya <saumya.dikshit@hpe.com<mailto:saumya.dikshit@hpe.com>> Sent: Tuesday, June 4, 2024 8:12 AM To: bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>; bess@ietf.org<mailto:bess@ietf.org> Subject: [bess] Re: https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html__;!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBli0vPbkL2$> (section 1.3 Kindly help on below query. From: Dikshit, Saumya <saumya.dikshit@hpe.com<mailto:saumya.dikshit@hpe.com>> Sent: Friday, May 31, 2024 7:51 PM To: draft-sajassi-bess-evpn-ip-aliasing@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing@ietf.org> Cc: bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>; bess@ietf.org<mailto:bess@ietf.org> Subject: [bess] https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html__;!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBli0vPbkL2$> (section 1.3 Hello Authors of draft https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html__;!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBli0vPbkL2$> Section https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html#section-1.2<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html*section-1.2__;Iw!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBli5LTvd1X$> Multi-Homing for IP Prefix Routes in the Interface-less IP-VRF-to-IP-VRF Model<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html*name-multi-homing-for-ip-prefix-__;Iw!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBli-r46S2c$> talks about leveraging ESI towards CE and snoop up ARP/ND to draw up the host credentials. Can we assume that this scenario consists of layer-2 Vteps only (PE1/PE2) with respect to the Vlans (might be no mapping EVIs) over which ARP/ND is snooped. Typically these deployments have a gateway (may or may-not be EVPN-IRB interface) somewhere in the network ( can be a centralized routing placement). Is this section trying to call out a layer-3 gateway-less network for the tenant behind CE ? Vlans on hosts behind CE are not extended beyond PE1/2 in this network. Kindly help clarify the specific deployment we are covering here. Regards, Saumya. From: Dikshit, Saumya Sent: Thursday, May 30, 2024 2:00 PM To: Jorge Rabadan (Nokia) <jorge.rabadan=40nokia.com@dmarc.ietf.org<mailto:jorge.rabadan=40nokia.com@dmarc.ietf.org>>; bess@ietf.org<mailto:bess@ietf.org>; draft-sajassi-bess-evpn-ip-aliasing@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing@ietf.org> Cc: bess-chairs@ietf.org<mailto:bess-chairs@ietf.org> Subject: Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html__;!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBli0vPbkL2$> [changing the draft version in the subject line] Hi Jorge, In section https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html#section-1.3.1<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html*section-1.3.1__;Iw!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBlixHQGiU4$> IP Aliasing for EVPN IP Prefix routes<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-01.html*name-ip-aliasing-for-evpn-ip-pre__;Iw!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBli-u483Le$> On the multihoming PEs (PE1/2): Routing towards tenant can also be enabled-on/tied-to physical ports (enabled for routing), irrespective of the protocol (OSPF/BGP/ISIS/static-routes) ? Is the configuration of BD mandated to enable routing towards the tenant CE as shown in the diagram. If yes, then we need to create a sub-case in section 1.3.1 for handling scenarios for native-routing interfaces. AFAIK, any prefix learning from tenant (CE1) over the routing protocol, can be published in context of EVI (mapped to tenant VRF) in RT-5. Underlying medium should be routing enabled. Regards, Saumya. From: BESS <bess-bounces@ietf.org<mailto:bess-bounces@ietf.org>> On Behalf Of Dikshit, Saumya Sent: Friday, March 8, 2024 4:52 PM To: Jorge Rabadan (Nokia) <jorge.rabadan=40nokia.com@dmarc.ietf.org<mailto:jorge.rabadan=40nokia.com@dmarc.ietf.org>>; Allu, Ramaprasad <ramprasad.na@hpe.com<mailto:ramprasad.na@hpe.com>>; bess@ietf.org<mailto:bess@ietf.org>; draft-sajassi-bess-evpn-ip-aliasing@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing@ietf.org> Cc: bess-chairs@ietf.org<mailto:bess-chairs@ietf.org> Subject: Re: [bess] Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html__;!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBliwwzBs8A$> Hi Jorge, Thanks for responding. Please see inline. Regards, Saumya. From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Jorge Rabadan (Nokia) Sent: Thursday, March 7, 2024 6:42 AM To: Dikshit, Saumya <saumya.dikshit@hpe.com<mailto:saumya.dikshit@hpe.com>>; Allu, Ramaprasad <ramprasad.na@hpe.com<mailto:ramprasad.na@hpe.com>>; bess@ietf.org<mailto:bess@ietf.org>; draft-sajassi-bess-evpn-ip-aliasing@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing@ietf.org> Cc: bess-chairs@ietf.org<mailto:bess-chairs@ietf.org> Subject: Re: [bess] Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html__;!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBliwwzBs8A$> Hi Saumya, Having a different RD for the MAC/IP Advertisement route and the IP A-D per EVI route for the same ESI does not impose any issues. The RD should not be used in the EVPN IP route resolution process. [SD]Agree, its not about the route resolution. Its more from the send side configuration. I would rather simplify the configuration to hold one RD for IP-VRF instance and another one MAC-VRF instance. RT-2 is a special case where-in the learnings via ARP/ND or live Layer-2 traffic is being published against a MAC-VRF. And an addendum in rfc9135 to leverage this publishing for /32 routes as an organic extension. The absorption of routes purely based on Route Target extended communities and hence MAC-VRF RD was being published. But note this is also the case for Ethernet Aliasing. [SD] Ethernet Aliasing shall fall in line, as RD in MAC-VRF can be leveraged for Ethernet A-D per EVI and also MAC/IP NLRI in RT-2. As you can see in the route resolution section of this draft, you also need to use the IP A-D per ES route for the resolution of the EVPN IP route (being RT2 or RT5 in this document), and the RD of the IP A-D per ES route is a type 1 RD with the loopback followed by a unique number, and this would not match the IP-VRF or MAC-VRF RD. [SD] How do I apply this to RT-2, where the NLRI will carry the ESI from the Ethernet segment. It can be same for both MAC-aliasing and IP-aliasing. A question arises here, as to How do I choose which ESI to carry if I want to publish MAC+IP for both IP-aliasing and MAC-aliasing, if they are not same ? So personally, I don’t see this causing any interop issues or any issues at all. [SD] It’s more of a usage/configuration on send side and marrying the IP-aliasing with MAC-aliasing via RT-2 and it should be captured in this draft Having said that, there is a generic resolution issue for inter-domain option b, that prevents the mass withdraw (per ES) from working in these scenarios. If you were thinking about this, all the issues and potential solutions (including RD based correlation) are documented here: draft-rabadan-bess-evpn-inter-domain-opt-b-03 (ietf.org)<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-rabadan-bess-evpn-inter-domain-opt-b-03*section-3.1__;Iw!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBli3FuZBzr$> If you think we should highlight in this other draft that the RT2 RD and the IP A-D per EVI route RD will not match, it is something that we can certainly do. Just let us know. [SD] Let me go through this draft and get back. But I think we need to do some clarification on signaling the co-existence of MAC-aliasing and IP-aliasing leveraging the ESI and RD values. Thanks. Jorge From: Dikshit, Saumya <saumya.dikshit@hpe.com<mailto:saumya.dikshit@hpe.com>> Date: Wednesday, March 6, 2024 at 3:42 AM To: Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>>, Allu, Ramaprasad <ramprasad.na@hpe.com<mailto:ramprasad.na@hpe.com>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, draft-sajassi-bess-evpn-ip-aliasing@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing@ietf.org> <draft-sajassi-bess-evpn-ip-aliasing@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing@ietf.org>> Cc: bess-chairs@ietf.org<mailto:bess-chairs@ietf.org> <bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>> Subject: RE: Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html__;!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBliwwzBs8A$> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Jorge, I completely understand that IP AD per EVI route should carry the IP-VRF RD. But with IP-aliasing, we are creating case where-in: an attached ES is leveraged for both MAC-aliasing and IP-aliasing (host routes) via MAC routes and /32 routes respectively Both are being published via the same NLRI in RT-2 as MAC/IP and L2VNI and L3VNI There should be an common association (other than the ES.) between IP AD per EVI and the Host routes which are absorbed for IP-aliasing, The common denominator should also include RD (configured on the EVI mapped to the vrf) on the send side It’s confusing that RD carried in MAC/IP is the VLAN RD (as per EVPN standards, cannot content that). But we are also signaling host-routes for layer-3 multi-homing and leveraging it RD as an index on the receive side. Even though the corresponding IP-AD per EVI is signaled with vrf configured RD (and rightly so) Somehow this is not coming together organically We should call out the above mismatch (and/or absorption procedure for the IP-aliasing of host routes) in the draft. Regards, Saumya. From: Jorge Rabadan (Nokia) [mailto:jorge.rabadan@nokia.com] Sent: Tuesday, March 5, 2024 7:53 PM To: Dikshit, Saumya <saumya.dikshit@hpe.com<mailto:saumya.dikshit@hpe.com>>; Allu, Ramaprasad <ramprasad.na@hpe.com<mailto:ramprasad.na@hpe.com>>; bess@ietf.org<mailto:bess@ietf.org>; draft-sajassi-bess-evpn-ip-aliasing@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing@ietf.org> Cc: bess-chairs@ietf.org<mailto:bess-chairs@ietf.org> Subject: Re: Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html__;!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBliwwzBs8A$> Hi Saumya, This spec does not change anything for the advertisement of MAC/IP Advertisement routes or IP Prefix routes, it only introduces IP A-D per EVI/ES routes. If you are using the same ES for the stretched Broadcast Domain and the IP-VRFs (Ethernet aliasing for layer-2 and IP Aliasing for layer-3), MAC/IP Advertisement routes are advertised with the RD of the MAC-VRF of origin and so are Ethernet A-D per EVI routes for the ES. IP A-D per EVI routes are advertised with the IP-VRF RD. Hope it helps. Thanks. Jorge From: Dikshit, Saumya <saumya.dikshit@hpe.com<mailto:saumya.dikshit@hpe.com>> Date: Monday, March 4, 2024 at 6:40 PM To: Dikshit, Saumya <saumya.dikshit@hpe.com<mailto:saumya.dikshit@hpe.com>>, Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com<mailto:jorge.rabadan@nokia.com>>, Allu, Ramaprasad <ramprasad.na@hpe.com<mailto:ramprasad.na@hpe.com>>, bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, draft-sajassi-bess-evpn-ip-aliasing@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing@ietf.org> <draft-sajassi-bess-evpn-ip-aliasing@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing@ietf.org>> Cc: bess-chairs@ietf.org<mailto:bess-chairs@ietf.org> <bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>> Subject: RE: Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html__;!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBliwwzBs8A$> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Just to elaborate further, Below might be the scenario where both MAC aliasing (MAC routes) and IP-aliasing (for /32 host routes) is needed in mixed deployment of Symmetric IRB fabric. Fabric may have mixed-bag of PEs, where-in, some of them have VRF-extended (/32 routes) while others have only subnet extended (MAC). Regards, Saumya. From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Dikshit, Saumya Sent: Tuesday, March 5, 2024 7:53 AM To: Jorge Rabadan (Nokia) <jorge.rabadan=40nokia.com@dmarc.ietf.org<mailto:jorge.rabadan=40nokia.com@dmarc.ietf.org>>; Allu, Ramaprasad <ramprasad.na@hpe.com<mailto:ramprasad.na@hpe.com>>; bess@ietf.org<mailto:bess@ietf.org>; draft-sajassi-bess-evpn-ip-aliasing@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing@ietf.org> Cc: bess-chairs@ietf.org<mailto:bess-chairs@ietf.org> Subject: Re: [bess] Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html__;!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBliwwzBs8A$> Hi Jorge, Is this the same RD for IP VRF (uniquely defined for IP-AD per EVI route), that should be leveraged for host routes in Route Type-2 and Prefix Routes in Route Type-5 ? Is that the safe assumption (as per rfc9135/9134) ? In case yes, then If we have a unique RD for the IP-VRF, what RD should be used for the NLRI in the Route-Type-2 carrying MAC/IP for tied to MAC-VRF and IP-VRF ? Should it be MAC-VRF RD or IP-VRF RD. Regards, Saumya. From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Jorge Rabadan (Nokia) Sent: Tuesday, March 5, 2024 1:57 AM To: Allu, Ramaprasad <ramprasad.na@hpe.com<mailto:ramprasad.na@hpe.com>>; bess@ietf.org<mailto:bess@ietf.org>; draft-sajassi-bess-evpn-ip-aliasing@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing@ietf.org> Cc: bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>; Dikshit, Saumya <saumya.dikshit@hpe.com<mailto:saumya.dikshit@hpe.com>> Subject: Re: [bess] Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html__;!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBliwwzBs8A$> Hi Ramaprasad, About this: “If MPLS label field is not considered for BGP route key, then BGP RIB will have only one route entry at any given point of time. That is, IP A-D per EVI route overwrites Ethernet AD per EVI and vice-versa if same RD is used for IP-VRF and MAC-VRF.” The Ethernet AD per EVI route and IP AD per EVI routes must use different RDs. It was sort of implicit, since the former one uses the RD of the MAC-VRF and the latter the RD of the IP-VRF, but we added this in rev 01 to make sure there is no misunderstanding: * The Route-Distinguisher is for the corresponding IP-VRF. The Route-Distinguisher allocated for the IP-VRF MUST be unique in the PE. Hope it helps. Thank you, Jorge From: Allu, Ramaprasad <ramprasad.na@hpe.com<mailto:ramprasad.na@hpe.com>> Date: Sunday, March 3, 2024 at 10:04 PM To: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, draft-sajassi-bess-evpn-ip-aliasing@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing@ietf.org> <draft-sajassi-bess-evpn-ip-aliasing@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing@ietf.org>> Cc: bess-chairs@ietf.org<mailto:bess-chairs@ietf.org> <bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>>, Dikshit, Saumya <saumya.dikshit@hpe.com<mailto:saumya.dikshit@hpe.com>> Subject: Re: Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html__;!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBliwwzBs8A$> You don't often get email from ramprasad.na@hpe.com<mailto:ramprasad.na@hpe.com>. Learn why this is important<https://urldefense.com/v3/__https:/aka.ms/LearnAboutSenderIdentification__;!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBli7aqbonf$> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Authors, Gentle reminder. Can you please take a look at it and respond to below query? Thanks, Ramaprasad From: Allu, Ramaprasad <ramprasad.na@hpe.com<mailto:ramprasad.na@hpe.com>> Date: Wednesday, 21 February 2024 at 5:40 PM To: bess@ietf.org<mailto:bess@ietf.org> <bess@ietf.org<mailto:bess@ietf.org>>, draft-sajassi-bess-evpn-ip-aliasing@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing@ietf.org> <draft-sajassi-bess-evpn-ip-aliasing@ietf.org<mailto:draft-sajassi-bess-evpn-ip-aliasing@ietf.org>> Cc: bess-chairs@ietf.org<mailto:bess-chairs@ietf.org> <bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>>, Dikshit, Saumya <saumya.dikshit@hpe.com<mailto:saumya.dikshit@hpe.com>> Subject: Queries to authors of https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html__;!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBliwwzBs8A$> Hi Authors of draft https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-bess-evpn-ip-aliasing-00.html__;!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBliwwzBs8A$> I have a following query on the draft. Please help with your response. Context of section https://www.ietf.org/archive/id/draft-sajassi-bess-evpn-ip-aliasing-09.html#section-3.1<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-sajassi-bess-evpn-ip-aliasing-09.html*section-3.1__;Iw!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBli4RVms1V$>, In the section, it is mentioned that the construction of the IP A-D per EVI route is same as that of the Ethernet A-D per EVI route. The NLRI consists of the following, +---------------------------------------+ | Route Distinguisher (RD) (8 octets) | +---------------------------------------+ |Ethernet Segment Identifier (10 octets)| +---------------------------------------+ | Ethernet Tag ID (4 octets) | +---------------------------------------+ | MPLS Label (3 octets) | +---------------------------------------+ And as per https://www.rfc-editor.org/rfc/rfc7432.html#section-7.1<https://urldefense.com/v3/__https:/www.rfc-editor.org/rfc/rfc7432.html*section-7.1__;Iw!!NpxR!k3YSoI4TNYpzxjM-dPXAPBciVD4GzvpkRfOVPFBapI5WL0Y6cfhemzPXoeWb8jvFbq5gd8HvKJELIcBlixTMs9N2$>, “ for the purpose of BGP route key processing, only the Ethernet Segment Identifier and the Ethernet Tag ID are considered to be part of the prefix in the NLRI. The MPLS Label field is to be treated as a route attribute as opposed to being part of the route” If MPLS label field is not considered for BGP route key, then BGP RIB will have only one route entry at any given point of time. That is, IP A-D per EVI route overwrites Ethernet AD per EVI and vice-versa if same RD is used for IP-VRF and MAC-VRF. Is there any reason for explicit mention of not using MPLS label field as key for BGP route or not carrying two labels one for Ethernet A-D per EVI and another for IP-AD per VRF? In this case, I see only MPLS Label (VNI in case of VXLAN) is the distinguisher if same RD is used for both IP-VRF and MAC-VRF. And to keep two separate routes in BGP RIB, we need to use MPLS label also one of the keys in addition to RD, ESI and ETAG fields. Or Carry both the labels and extended communities as part of single A-D per EVI route and store single route in the global BGP RIB. Please let me know what you think. Thanks, Ramaprasad
- [bess] Queries to authors of https://www.ietf.org… Allu, Ramaprasad
- Re: [bess] Queries to authors of https://www.ietf… Allu, Ramaprasad
- Re: [bess] Queries to authors of https://www.ietf… Jorge Rabadan (Nokia)
- Re: [bess] Queries to authors of https://www.ietf… Dikshit, Saumya
- Re: [bess] Queries to authors of https://www.ietf… Dikshit, Saumya
- Re: [bess] Queries to authors of https://www.ietf… Jorge Rabadan (Nokia)
- Re: [bess] Queries to authors of https://www.ietf… Dikshit, Saumya
- Re: [bess] Queries to authors of https://www.ietf… Jorge Rabadan (Nokia)
- Re: [bess] Queries to authors of https://www.ietf… Dikshit, Saumya
- [bess] Queries to authors of https://www.ietf.org… Dikshit, Saumya
- [bess] https://www.ietf.org/archive/id/draft-ietf… Dikshit, Saumya
- [bess] Re: https://www.ietf.org/archive/id/draft-… Dikshit, Saumya
- [bess] Re: https://www.ietf.org/archive/id/draft-… Dikshit, Saumya
- [bess] Re: https://www.ietf.org/archive/id/draft-… Jorge Rabadan (Nokia)
- [bess] Queries to authors of https://www.ietf.org… Dikshit, Saumya
- [bess] Re: https://www.ietf.org/archive/id/draft-… Dikshit, Saumya
- [bess] Re: Queries to authors of https://www.ietf… Jorge Rabadan (Nokia)
- [bess] Re: https://www.ietf.org/archive/id/draft-… Dikshit, Saumya
- [bess] Re: Queries to authors of https://www.ietf… Dikshit, Saumya
- [bess] Re: https://www.ietf.org/archive/id/draft-… Dikshit, Saumya
- [bess] Re: https://www.ietf.org/archive/id/draft-… Dikshit, Saumya
- [bess] Re: https://www.ietf.org/archive/id/draft-… Dikshit, Saumya
- [bess] Re: Queries to authors of https://www.ietf… Dikshit, Saumya
- [bess] Re: https://www.ietf.org/archive/id/draft-… Dikshit, Saumya
- [bess] Re: Queries to authors of https://www.ietf… Dikshit, Saumya
- [bess] Re: https://www.ietf.org/archive/id/draft-… Jorge Rabadan (Nokia)
- [bess] Re: Queries to authors of https://www.ietf… Dikshit, Saumya
- [bess] Re: Queries to authors of https://www.ietf… Dikshit, Saumya
- [bess] Re: Queries to authors of https://www.ietf… Jorge Rabadan (Nokia)