Return-Path: 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 A53A412CBB752 for ; Thu, 20 Aug 2026 01:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1787212982; bh=wXPT9daf43P6ovNjAG+VCmpjMsqWhjIPxkdL0fQjdVM=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=q1l79sls6B4D3o3x+fRuOaP3ZLfsXqqqkQVfYw2KlvRKBXRaAB8VTY5aSCxjmub1/ HGMRzo0GAqICiSudIJGwOSBMeAc+Vf3bS73+fQpEE79AVykNS6v4FzA8PBj8ST12+K MvAsJq+63se8Wbc2gMwIqhzPC2Rb0zVdhHHlTDEM= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=nokia.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 M6B2930ZLVzO for ; Thu, 20 Aug 2026 01:03:01 -0700 (PDT) Received: from DUZPR83CU001.outbound.protection.outlook.com (mail-northeuropeazon11012027.outbound.protection.outlook.com [52.101.66.27]) (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 mail2.ietf.org (Postfix) with ESMTPS id BB42412CBB6C9 for ; Thu, 20 Aug 2026 01:02:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=kWS9OADy2web/QtKng89SbjbpyDZhv8iRJS+tMQRGWHo+SesXW3o2Ip/dPLy7RZPrP1dWuRSQSHURfYIxidRrx9dfzas0BX0b4/rjMw+1lelXKo2CpLV3krpgfPjDCyb9Hr4oaa8O8U2GK+mcKYz8WL1Y1j6fXJyAyRLQ7iHHtLSjvKwRJxwwRYNFw0gGqTvZMQ3H/C9pyKQt61CdZGo5WfAA1MTPGXDGizCSuqBTZ2hs348ATm+ki+FjBfNKqFy+auWEx2gX4Dx3mNOFfmqULziXNf/SJPqaLUcEEL6cKcUizb4ypbsjLwg5rStgI8MxWXRB15MATaEtMT/y4axiQ== 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=wXPT9daf43P6ovNjAG+VCmpjMsqWhjIPxkdL0fQjdVM=; b=pnlQR0nvQppTblrmzFoTDdLx0Q9PtVfzqseu21yUSrl8vnLlSuft0ZDSElXCgTZgvtCTnjlodvUZbR1am3mpn7qMe93SjagrHQBvu5K5voqItZVC/Eoz7uq393/MboXKZbq7RgNIzmSyuj33FtP03CgBLPEu9fRHunwuoRdL6dcTOFZYqMKb1i5sZXeLrrcInWjhdyv0PvzBnTXDm1mCZdC9RtzR0yR0jlEw9JYjs/k5KikJ5+sja0Axq0sCTKvFJSUTnD0NPmCagQuyG19VMOqWNeflCdzLGcLPE5Td2Ss88BE/w0rABtM9jEAFb8cyWEMv5i6iqPCZ4WNYwiDK9w== 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=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wXPT9daf43P6ovNjAG+VCmpjMsqWhjIPxkdL0fQjdVM=; b=nKBWI1jckcJ22aF9riaa5zU4iacw4O4vvc9HgJH4+NdDDrFBUG6nCsHJVpla0DmYQ2OVDBoJW8hheozWujL2nHEh7g8F9jzrlHmdQsRF4XAxKn0dicWG52dKRGZyDf2/u8ks3lmWfU7eV++RFVV/gBfLQzqirxPVL5wRvkkj65G5jPOu3lUjegfJnws/IL1YArlHTo4m64PGjJGiqb0+giljf6UNDmpxtyY1BmPKW8Q0CwG/LnFD/ol6hjwobSV+7QOflrWbDWhj1sRPJYK1k8srlkcUcBXPDt4YxKV1uLMSCLzHove/yirTOrMmOuoYvyLyGMk5uiRNpscuTeHGIA== Received: from AS1PR07MB8589.eurprd07.prod.outlook.com (2603:10a6:20b:470::16) by AM7PR07MB6213.eurprd07.prod.outlook.com (2603:10a6:20b:13b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.360.3; Thu, 20 Aug 2026 08:02:49 +0000 Received: from AS1PR07MB8589.eurprd07.prod.outlook.com ([fe80::97cf:fb0c:32ff:86c6]) by AS1PR07MB8589.eurprd07.prod.outlook.com ([fe80::97cf:fb0c:32ff:86c6%7]) with mapi id 15.21.0360.003; Thu, 20 Aug 2026 08:02:48 +0000 From: "Gunter van de Velde (Nokia)" To: Alexander Vainshtein Thread-Topic: [EXTERNAL] [Errata Rejected] RFC9135 (9000) Thread-Index: AQHdL+20iZEhgp133E6R9KblOSDEhramlAR8 Date: Thu, 20 Aug 2026 08:02:48 +0000 Message-ID: References: <178704871220.17.6468738798071161656@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: 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: AS1PR07MB8589:EE_|AM7PR07MB6213:EE_ x-ms-office365-filtering-correlation-id: 84b9a9be-7cc7-4f6e-cd76-08defe916d39 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|366016|376014|23010399003|22082099003|18002099003|6133799003|56012099006|3023799007|8096899003|38070700021|13003099007|10067099003|4143699003|11063799006; x-microsoft-antispam-message-info: O38qi/9aGPS0xljk0fwiOCkMgePPrUNnpELNz8jVNGJib/O9XNRQo5fLaRcxKZoPAWeRdzVntZJy11e75Hdbb3G07RMbXC0LmyZwCON603TWJdiCd2LYVLSXL8OX8DXBkqVbwA9dgLgj73YPo5JIKIXwfKCfZhLU8u+KTHvjPSeSac0RMMctW+u07NJ5mG7QrI7RdFLRx9kb1LLNSvZWZqY/ZSbGnEPHF7aHH8gRXi+GLg+EofS0XMhry6fruewl7f8GJSTKRAiwLM/H3a/ERx/39f2Mk3jYgMNaLooFdxGXhyk2mPLWCp1yVsQAYR9CIqrrQvjbdZg2BR0NkqPKQIdiJKBFE6pe65KOkgzU/98Gy3/EXmzEvaJwVMaIgaP9JeTW2yF7jfmgtnyG90wWGXAvQY89jUfZpbW+IpBseuiZZ1jEP2XcEDC5/XUfebJLhJKF9VHuwYapo3Dx7e8mUqSiRV802G6TWLad5nZi7PfDPILTM9BRzULOvsoYRWHRFxiWOicp8Dxzz+m5BKwPAfr8Ij2x8SvgZKNvPepAw1pKz+3gezGpoJOJpqFXZjtK5mTBj936kUnh8UZyi3X11HhlGesusw+W6UBKBOUVxAPfEI5aHvMXPSSTmyOyGA0v8kiX5QcCWBSpV/jQ1vlss0eUw4RVxDx8+DeMASOQTCo= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AS1PR07MB8589.eurprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(376014)(23010399003)(22082099003)(18002099003)(6133799003)(56012099006)(3023799007)(8096899003)(38070700021)(13003099007)(10067099003)(4143699003)(11063799006);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?hsAoEUhMvKz+LAM+YY0Cc2r4HLXVe8nXeJJSSfvtt0aGyyjpC1+7HNuPnd?= =?iso-8859-1?Q?Kdn432I8hQRsZgCS14FtUQUSrFJMfXS0R52TpRS2z6b/oiJ7CetVx9rTHM?= =?iso-8859-1?Q?HT5FR/LKkErP8+sxW4w5Fz3so8GWYfUBjG2vg4AhBS7eh+jR1lztej1oXF?= =?iso-8859-1?Q?yhwRm/Q4mPYu1ImPM/TPMZMdd6R++EQmQir3c2gpkaGT9RuUCuOKuPz5aH?= =?iso-8859-1?Q?rUhjauVFp12d0P9M8J69rShS3vAIHZMsAlWFNTSN5uU9E7c0TYoK9+LVwq?= =?iso-8859-1?Q?N09eatkz80HPDlveF8qzilSsGnZsK2YyQDPezxlFE58cocTBX0wtFM60Pd?= =?iso-8859-1?Q?EwLSMfEO43Hs6/zYsikJ0uFTR+9KlbFl364vF+VNZ4nmVrb1vPMzjBCmwl?= =?iso-8859-1?Q?tgfYgMWGtrSvGEshnZj5+qCf8wDU/g+mXSOu0z8fG+AMjfZfYxq3HcdUEm?= =?iso-8859-1?Q?Dgz6sZ6zHu0/Qyh8BlII+7oD+gAk7NiXmesfkAG9Y3oyirM4ttqAgJ1OhK?= =?iso-8859-1?Q?UpdNlcvvZGnXqZv1V80Xdd5zzKXwOEU73ELQSt18hT3ExEgTMR4MDvw7wJ?= =?iso-8859-1?Q?VTJ+zU/aDVApswpoqYRmAgcI9P2S0+NjwAPL6/StusVQqaG1Vih35LpcIz?= =?iso-8859-1?Q?LskOr+9PTEO8SGsE8/W6av4JXEI/Ht/EliOKg7kIYI7uxsCczTPFKa8+YY?= =?iso-8859-1?Q?Xw4G/rEexG8zq0p8ljpBe8Qe84gxhXCH8tGuG+jf5QVE3ZNtNA9N0ChAKS?= =?iso-8859-1?Q?etvjsWYbkTPPgvzC3AGK/cHFR51Y9zyfvzvi5800/Gn1e4lhs2tNE1kRrn?= =?iso-8859-1?Q?Vsori6Havl+lFUcbR3a1qqkaJ2OvFtUHaPmlwtw+CU/M2MtXBCHpNPf/lY?= =?iso-8859-1?Q?szCNBrdOOZHQvd8RCjMmCoiV8w3/i7v714g9u58qFN06pZjeIYgvQjcf0A?= =?iso-8859-1?Q?ch8ltwrFhyCOBE1bHfp80FwagicaO7U3opupP9myqiIuyWMgTWVh9ybTV9?= =?iso-8859-1?Q?DhDdoBfj/K1GYCLbC+8TEr2tFJylK7wCBrywy6VmKKXjLgIsmkOcwTEJJJ?= =?iso-8859-1?Q?eBIz0qu7Q/HsX01uK66RXyJ+pOd5rY8XweLumgfBpt3V5gE6PDPNKrMGM2?= =?iso-8859-1?Q?cwzW3cK4jYMkCyCJ01/ImDiWNIIVEQ0DwoAV5DdC7lhUQREhKbG7BydJw+?= =?iso-8859-1?Q?i1Nb0lrjjAsosO0AcvLKs6KjDFTtriftTj7Lt2BUVrdvDUWSaoD8svCdnZ?= =?iso-8859-1?Q?BCG/S8ApF4a5QAJ4ajyob3ZoZKlG6yTaa9hI3Bpo7WPHNRR2wIEOZwSTJV?= =?iso-8859-1?Q?SUO+MHA5hbZ56ori7eaqy4IfEPlMxweKZxlqW4cwBL4rEoAJAqBmAqpfIG?= =?iso-8859-1?Q?/s9eCxbE0ToRqhQRuxSQ267GfEZ2bC/WGmZjxQN0CP+km9+heJxiO/SqqQ?= =?iso-8859-1?Q?3qociP/ml2ingXDjF+u+efK/gOOKQOjthLcMmLTZfgPwJ3kiIcmB4XUhvR?= =?iso-8859-1?Q?ZHIOHYV4ahi8FyUmL2p4DYA02zvqJ0/iUbvmwFa+ZjbhPWQKmyy7GTbfEa?= =?iso-8859-1?Q?mTExgtdDVY1uyK8vs3vd78TTNRvSY3z0NhlBtB8prgrdn7HsVo/Qlp8xNY?= =?iso-8859-1?Q?ZnN0xFECLO8JV+YvH6uj+ZHCUbNbyN3jcvrMe3Br45MP4ahce/wxKzUw+Y?= =?iso-8859-1?Q?A1QcZJXtuct6y51Xpu8KBKottkrlZSMky5523L4yzI4/zR47rODLmXUyUP?= =?iso-8859-1?Q?iYuaOD+TUxMG9KG6G0gFDLD9fHOOlI0qjhmOzOCdN4jd4IurPPi2UhiaCI?= =?iso-8859-1?Q?s6dcB8B0rA=3D=3D?= Content-Type: multipart/alternative; boundary="_000_AS1PR07MB8589E918A5DD579DE10B1A26E0A42AS1PR07MB8589eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS1PR07MB8589.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 84b9a9be-7cc7-4f6e-cd76-08defe916d39 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2026 08:02:48.9293 (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: qSB6XQpOanxMXGi70sHbRB26bn73d6gGU9t22Eyy+1E2Wrag1wdXAEB8HNSyvYgy4hqDB2BmSDRFj8jf+mz70GAxVPjzheB5kGMIUbJ2TwA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6213 Message-ID-Hash: ZO72QQIOOVDG2DGJ7672BDJHQZFVNYJL X-Message-ID-Hash: ZO72QQIOOVDG2DGJ7672BDJHQZFVNYJL X-MailFrom: gunter.van_de_velde@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 CC: "bess@ietf.org" , "sajassi@gmail.com" , "Jorge Rabadan (Nokia)" , "sthoria@cisco.com" , "ssalam@cisco.com" , John Drake X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bbess=5D_Re=3A_=5BEXTERNAL=5D_=5BErrata_Rejected=5D_RFC9135_=289?= =?utf-8?q?000=29?= List-Id: BGP-Enabled ServiceS working group discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_AS1PR07MB8589E918A5DD579DE10B1A26E0A42AS1PR07MB8589eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Sasha, I'll check with the secretariat if there are prior experiences on this type= of errata (impacting several parts of the text) and will get back to you. G/ ________________________________ From: Alexander Vainshtein Sent: Wednesday, August 19, 2026 5:15 PM To: gunter Cc: bess@ietf.org ; sajassi@gmail.com ; J= orge Rabadan (Nokia) ; sthoria@cisco.com ; ssalam@cisco.com ; John Drake Subject: [bess] Re: [EXTERNAL] [Errata Rejected] RFC9135 (9000) CAUTION: This is an external email. Please be very careful when clicking li= nks or opening attachments. See the URL nok.it/ext for additional informati= on. Gunter, Lots of thanks for your detailed review of the Erratum and explanation of r= easons for rejecting it in spite of acknowledging the problem that has trig= gered its submission. I agree that the proposed correction, as written, contradict the last para = of Section 9.1.1 of RFC 9135 that says (the relevant text is highlighted): If the receiving NVE receives an EVPN RT-2 with only label1 and only a sing= le Route Target corresponding to IP-VRF; an EVPN RT-2 with only a single Ro= ute Target corresponding to MAC-VRF but with both label1 and label2; or an = EVPN RT-2 with a MAC address length of zero, then it MUST use the treat-as-= withdraw approach [RFC7606] = and SHOULD log an error message. The correction should either make an exception for IPv6 link-local address = in the marked or should make an exception for inclusion of Label2 field for= these addresses in Section 5.1. I am not sure that an Erratum that, one way or another, affects multiple te= xt fragments of the RFC, is the best way to handle the problem. If you think that submitting a modified Erratum addressing the contradictio= n mentioned above would help, I can do that. Regards, and lots of thanks in advance, Sasha From: rfc-editor@rfc-editor.org Sent: Tuesday, August 18, 2026 1:25 PM To: sthoria@cisco.com; Alexander Vainshtein = ; jdrake@juniper.net; jorge.rabadan@nokia.com; ssalam@cisco.com; sajassi@gm= ail.com Cc: rfc-editor@rfc-editor.org; bess@ietf.org; gunter@vandevelde.cc; iana@ia= na.org; iesg@ietf.org Subject: [EXTERNAL] [Errata Rejected] RFC9135 (9000) The following errata report has been rejected for RFC9135, "Integrated Routing and Bridging in Ethernet VPN (EVPN)" -------------------------------------- You may review the report below and at: https://errata.rfc-editor.org/eid9000/ -------------------------------------- Status: Rejected Type: Technical Reported by: Alexander ("Sasha") Vainshtein > Date Reported: June 10, 2026, 1:57 p.m. Rejected by: Gunter Van de Velde (IESG) Section 5.1 and 5.2 says: Original Text ------------- In Section 5.1: This route MUST be advertised with two Route Targets, one corresponding to = the MAC-VRF of the tenant's subnet and another corresponding to the tenant's IP-VRF. In Section 5.2: When a PE (e.g., PE2 in Figure 4 above) receives this EVPN MAC/IP Advertise= ment route, it performs the following: The MAC-VRF Route Target and Ethernet Tag, if the latter is non-zero, are u= sed to identify the correct MAC-VRF and bridge table, and if they are found, the MAC address is imported. The IP-VRF Route Target is used to identify the correct IP-VRF, and if it i= s found, the IP address is imported. Corrected Text -------------- In Section 5,1: This route MUST be advertised with two Route Targets, one corresponding to = the MAC-VRF of the tenant's subnet and another corresponding to the tenant'= s IP-VRF. The Route Targets corresponding to the tenants IP-VRF SHOULD be omitted if = the IP address the NLRI of teh route is a link-local IPv6 address. In Section 5.2: When a PE (e.g., PE2 in Figure 4 above) receives this EVPN MAC/IP Advertise= ment route, it performs the following: The MAC-VRF Route Target and Ethernet Tag, if the latter is non-zero, are u= sed to identify the correct MAC-VRF and bridge table, and if they are found, the MAC address is imported. If the IP address in the NLRI of the route is not an IPv6 link-local addres= s, the IP-VRF Route Target is used to identify the correct IP-VRF, and if i= t is found, the IP address is imported. Notes ----- Claim by submitter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D As per Section 2.5.6 of RFC 4291, "Routers must not forward any packets wit= h Link-Local source or destination addresses to other links". Therefore, these addresses MUST NOT be in the IP-VRF in ingress PE, and the= re is no need to attach Route Targets of the IP-VRF in the egress PE becaus= e they are used solely for identification of the importing IP-VRF in the in= gress PE. AD Review =3D=3D=3D=3D=3D=3D=3D I agree with the underlying observation that an IPv6 link-local address mus= t not become an inter-subnet forwarding route. However, I do not think the = proposed correction can be verified as written. RFC 4291 prohibits forwarding packets with link-local source or destination= addresses to another link, but this does not mean that link-local addresse= s cannot appear as interface- or zone-scoped state within an IP-VRF. More importantly, the proposed correction conflicts with RFC 9135 itself. S= ection 4.2 uses the presence of both Label2 and an IP-VRF Route Target to i= dentify symmetric IRB. Section 9.1.1 also says that an RT-2 carrying both L= abel1 and Label2 but only a MAC-VRF Route Target MUST be treated as withdra= wn. Omitting only the IP-VRF Route Target would therefore cause compliant r= eceivers to discard the route. There may be a valid clarification or protocol update here: a link-local MA= C/IP binding could perhaps be advertised only for MAC-VRF and Proxy-ND purp= oses, without Label2 or IP-VRF import. However, that would require coordina= ted changes to several sections and discussion in BESS. I therefore recommend rejecting this erratum as written and taking the unde= rlying IPv6 link-local handling question to the BESS working group. -------------------------------------- RFC9135 (draft-ietf-bess-evpn-inter-subnet-forwarding) -------------------------------------- Title : Integrated Routing and Bridging in Ethernet VPN (EVPN) Publication Date : October 2021 Author(s) : A. Sajassi, S. Salam, S. Thoria, J. Drake, J. Rabadan Category : Proposed Standard Source : bess (rtg) Stream : IETF Disclaimer This e-mail together with any attachments may contain information of Ribbon= Communications Inc. and its Affiliates that is confidential and/or proprie= tary for the sole use of the intended recipient. Any review, disclosure, re= liance or distribution by others or forwarding without express permission i= s strictly prohibited. If you are not the intended recipient, please notify= the sender immediately and then delete all copies, including any attachmen= ts. --_000_AS1PR07MB8589E918A5DD579DE10B1A26E0A42AS1PR07MB8589eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Sasha,

I'll check with the secretariat if there are prior experiences on this type= of errata (impacting several parts of the text) and will get back to you.<= /div>

G/


From: Alexander Vainshtein <Alexander.Vainshtein=3D40rbbn.com@dma= rc.ietf.org>
Sent: Wednesday, August 19, 2026 5:15 PM
To: gunter <gunter@vandevelde.cc>
Cc: bess@ietf.org <bess@ietf.org>; sajassi@gmail.com <sajas= si@gmail.com>; Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com>; st= horia@cisco.com <sthoria@cisco.com>; ssalam@cisco.com <ssalam@cisc= o.com>; John Drake <je_drake@yahoo.com>
Subject: [bess] Re: [EXTERNAL] [Errata Rejected] RFC9135 (9000)

 
CAUTION: This is= an external email. Please be very careful when clicking links or opening a= ttachments. See the URL nok.it/ext for additional information.

 

= Gunter,

= Lots of thanks for your detailed review of= the Erratum and explanation of reasons for rejecting it in spite of acknow= ledging the problem that has triggered its submission.

=  

= I agree that the proposed correction, as w= ritten, contradict the last para of Section 9.1.1 of RFC 9135 that says (the relevant text is highlighted):=

=  

If the receiving NVE receives an EVPN RT-2 with only la= bel1 and only a single Route Target corresponding to IP-VRF; an EVPN RT-2 with only a single Route Target corresponding to M= AC-VRF but with both label1 and label2; or an EVPN RT-2 with a MAC address length of zero, then it MUST&nbs= p;use the treat-as-withdraw approach [= RFC7606] and SHOULD log an error message.

= The correction should either make an excep= tion for IPv6 link-local address in the marked or = should make an exception for inclusion of Label2 field for these addresses = in Section 5.1.

=  

= I am not sure that an Erratum that, one wa= y or another, affects multiple text fragments of the RFC, is the best way t= o handle the problem.

=  

= If you think that submitting a modified Er= ratum addressing the contradiction mentioned above would help, I can do tha= t.

=  

= Regards, and lots of thanks in advance,

= Sasha

=  

From:= rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org>
Sent: Tuesday, August 18, 2026 1:25 PM
To: sthoria@cisco.com; Alexander Vainshtein <Alexander.Vainshtein= @rbbn.com>; jdrake@juniper.net; jorge.rabadan@nokia.com; ssalam@cisco.co= m; sajassi@gmail.com
Cc: rfc-editor@rfc-editor.org; bess@ietf.org; gunter@vandevelde.cc; = iana@iana.org; iesg@ietf.org
Subject: [EXTERNAL] [Errata Rejected] RFC9135 (9000)

 

The following errata report has been rejected for RFC9135,
"Integrated Routing and Bridging in Ethernet VPN (EVPN)"

--------------------------------------
You may review the report below and at:
https://errata.rfc-editor.org/e= id9000/

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

Status: Rejected
Type: Technical
Reported by: Alexander ("Sasha") Vainshtein <al= exander.vainshtein@rbbn.com>
Date Reported: June 10, 2026, 1:57 p.m.
Rejected by: Gunter Van de Velde (IESG)

Section 5.1 and 5.2 says:

Original Text
-------------
In Section 5.1:
This route MUST be advertised with two Route Targets, one corresponding to = the MAC-VRF of the tenant's subnet
and another corresponding to the tenant's IP-VRF.

In Section 5.2:
When a PE (e.g., PE2 in Figure 4 above) receives this EVPN MAC/IP Advertise= ment route, it performs the following:

The MAC-VRF Route Target and Ethernet Tag, if the latter is non-zero, are u= sed to identify the correct MAC-VRF and bridge table,
and if they are found, the MAC address is imported.
The IP-VRF Route Target is used to identify the correct IP-VRF, and if it i= s found, the IP address is imported.

Corrected Text
--------------
In Section 5,1:
This route MUST be advertised with two Route Targets, one corresponding to = the MAC-VRF of the tenant's subnet and another corresponding to the tenant'= s IP-VRF.
The Route Targets corresponding to the tenants IP-VRF SHOULD be omitted if = the IP address the NLRI of teh route is a link-local IPv6 address.

In Section 5.2:
When a PE (e.g., PE2 in Figure 4 above) receives this EVPN MAC/IP Advertise= ment route, it performs the following:

The MAC-VRF Route Target and Ethernet Tag, if the latter is non-zero, are u= sed to identify the correct MAC-VRF and bridge table,
and if they are found, the MAC address is imported.
If the IP address in the NLRI of the route is not an IPv6 link-local addres= s, the IP-VRF Route Target is used to identify the correct IP-VRF, and if i= t is found, the IP address is imported.

Notes
-----
Claim by submitter
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
As per Section 2.5.6 of RFC 4291, "Routers must not forward any packet= s with Link-Local source or destination addresses to other links".

Therefore, these addresses MUST NOT be in the IP-VRF in ingress PE, and the= re is no need to attach Route Targets of the IP-VRF in the egress PE becaus= e they are used solely for identification of the importing IP-VRF in the in= gress PE.

AD Review
=3D=3D=3D=3D=3D=3D=3D
I agree with the underlying observation that an IPv6 link-local address mus= t not become an inter-subnet forwarding route. However, I do not think the = proposed correction can be verified as written.

RFC 4291 prohibits forwarding packets with link-local source or destination= addresses to another link, but this does not mean that link-local addresse= s cannot appear as interface- or zone-scoped state within an IP-VRF.

More importantly, the proposed correction conflicts with RFC 9135 itself. S= ection 4.2 uses the presence of both Label2 and an IP-VRF Route Target to i= dentify symmetric IRB. Section 9.1.1 also says that an RT-2 carrying both L= abel1 and Label2 but only a MAC-VRF Route Target MUST be treated as withdrawn. Omitting only the IP-VRF Route = Target would therefore cause compliant receivers to discard the route.

There may be a valid clarification or protocol update here: a link-local MA= C/IP binding could perhaps be advertised only for MAC-VRF and Proxy-ND purp= oses, without Label2 or IP-VRF import. However, that would require coordina= ted changes to several sections and discussion in BESS.

I therefore recommend rejecting this erratum as written and taking the unde= rlying IPv6 link-local handling question to the BESS working group.

--------------------------------------
RFC9135 (draft-ietf-bess-evpn-inter-subnet-forwarding)
--------------------------------------
Title : Integrated Routing and Bridging in Ethernet VPN (EVPN)
Publication Date : October 2021
Author(s) : A. Sajassi, S. Salam, S. Thoria, J. Drake, J. Rabadan
Category : Proposed Standard
Source : bess (rtg)
Stream : IETF



Disclaimer

This e-mail together with any attachments may contain information of Ribbon= Communications Inc. and its Affiliates that is confidential and/or proprie= tary for the sole use of the intended recipient. Any review, disclosure, re= liance or distribution by others or forwarding without express permission is strictly prohibited. If you ar= e not the intended recipient, please notify the sender immediately and then= delete all copies, including any attachments.

--_000_AS1PR07MB8589E918A5DD579DE10B1A26E0A42AS1PR07MB8589eurp_--