[bess] Re: Opsdir last call review of draft-ietf-bess-evpn-mh-split-horizon-10
"Jorge Rabadan (Nokia)" <jorge.rabadan@nokia.com> Sun, 18 August 2024 01:20 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 DB98FC14CE3F; Sat, 17 Aug 2024 18:20:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.153
X-Spam-Level:
X-Spam-Status: No, score=-2.153 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, 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 RsrGpLWaP-6X; Sat, 17 Aug 2024 18:20:23 -0700 (PDT)
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2083.outbound.protection.outlook.com [40.107.223.83]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB687C14CE2C; Sat, 17 Aug 2024 18:20:22 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=j48W3/fo5+669VMOk0lZFOYh1aZjosf8lpqLTJw8gVrJvMyiqEDfRE7QLGEAPtnFRAV3gKl49r6rtwUeG6s9jCtWZRMMDyGlX8BSKcHC2Pmf60TfS44fQhnt2jOg1lMHR9jRbFogU25qup2osVaJ30hFYsEl3pz+hGBkbpWTYS5fxsRIVLwZdR0kW2jrdOsSYdh3xzOPrEqZVcT4POBe5ksttMo8h+Eb+7J2ESeBmy9cMUPmKvXj3dfJ/uhVhb9RK3mdNEtfvgtDGH2CimbCuC6jQj+DfieNR8l2lEq8ykc1ECWxvt4EKAuz2FDO59aYmo/YBp/0RUdM4hyw7QFrEQ==
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=xIYhZC3kIMDaG/z+vFSeosjeSFveJxGhcMtWxXoFNYI=; b=Q3AsG15QP7PvchPcg1jVMD/tNWQmFqgDYxJdCz2HBZ7whlvL3JggvFueAhhJ15Ey8V87LWdJhyzGdXE3xshtkYPlUDStnDxfu0PLNt4IjpWUB4XpqnXzHAPMP28wS921MGdfx1ccbZmFWwro56RYqw2DGuXDN2SKG8SqvpZTFehWeGLpxRdfYuvZWgsNYxTm4iCobROjebM65RmbJsDKrH92dZ3J36VqUJG4Xznc2OwYMrOTChWsQtH4CsvXbhTRU8xwufNHB06nrgvhFr4oZ/YGkGoEFfwog9idAVn3LkRUI4xCSHg1kHobTMx8pcWsToWEctgfCclEXwvf+25Wzw==
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=xIYhZC3kIMDaG/z+vFSeosjeSFveJxGhcMtWxXoFNYI=; b=dy/nhLEFkndRG5pdSwlEPL88567pwHQ6CG22sPfC+5yGbpIq4Z0PRq9vlqS76d+yMydCimr88Ht7WgEMQG1YxEmwWObf9KV+bBGxLF3LAFXgDOBo8al+kF+BsSBak8Y/d5KW7/KuIyvCfbnty4lFv4p/wDNMGj/7GnqdVu5ZkJXvHhkdS/yHtebj9KagIz44bmJkzrM862puMC2EGeE0ocF3Uw1fg1fzPj84T4e/RcGwHpByJEmVC2bmrQcjrG2ilu3c6qiBqViQn67w+pSxmYBYz4OGdrdC6Z0JiHc+OFZXI+dqal8p7gg3mhqZbNTxgF/6iu4W+cQ8wGPUTu84/w==
Received: from SA1PR08MB7215.namprd08.prod.outlook.com (2603:10b6:806:1a9::17) by LV8PR08MB9488.namprd08.prod.outlook.com (2603:10b6:408:1fb::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7875.21; Sun, 18 Aug 2024 01:20:19 +0000
Received: from SA1PR08MB7215.namprd08.prod.outlook.com ([fe80::b10c:f208:adaa:c369]) by SA1PR08MB7215.namprd08.prod.outlook.com ([fe80::b10c:f208:adaa:c369%3]) with mapi id 15.20.7849.021; Sun, 18 Aug 2024 01:20:19 +0000
From: "Jorge Rabadan (Nokia)" <jorge.rabadan@nokia.com>
To: Susan Hares <shares@ndzh.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>
Thread-Topic: Opsdir last call review of draft-ietf-bess-evpn-mh-split-horizon-10
Thread-Index: AQHa7mXInRnQmZ52KEqT7yihgAkq8LIqOkg2
Date: Sun, 18 Aug 2024 01:20:19 +0000
Message-ID: <SA1PR08MB72159C184A0EEF0A4125A044F7812@SA1PR08MB7215.namprd08.prod.outlook.com>
References: <172365237968.1101532.11030137776537854324@dt-datatracker-6df4c9dcf5-t2x2k>
In-Reply-To: <172365237968.1101532.11030137776537854324@dt-datatracker-6df4c9dcf5-t2x2k>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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_|LV8PR08MB9488:EE_
x-ms-office365-filtering-correlation-id: b02ec8ea-0023-4056-b834-08dcbf23ecb9
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|366016|38070700018;
x-microsoft-antispam-message-info: ondtEzvtKtxiPIQWdA8gSUNUwHPQ4mlgwJOlJUml1h8gmNG+fM9qz6uUCAn8kglrjr4zcqUIBzz1SICPDGKvh/+ApUo+o1qrvmZzWC8/eMc3VDWmfQ/cBpzMo3Jge+h8W6xybq9Ca23QrLm/X20R5U70X68ZZ2l10at7cTZnZW/kFOaS+lkwKsqJbeHY8HA1cLqAHQGD7KnotNWzmhfBxPvisvYAmh9iscnbCOb/aUTh1kVp6vFoHMHELuH39mKs061VYAs1KieenUsjCuI1xoLo+ymQ71xYXfM+EOZahTEfoikbFowidErX7vWtZPHalhybK94QCYCsWL+VXpBqfPhduMCTGFX/wUej45q1001JrLQ7uiZRniiM8Xw4xtMX9YGD7+uwQrXrzj6C5zsaggiY9l1Uz6ZsCGMIjEMm0xWUdvggjza+7XM4vOnCRcnz69KcAkibeaoTw05X9EOWbw1jA3ieYaaLUPxHkNEVJaRKl0wkPvd3sXVvJqWwnxZgMtZuDvKzdZFa6Z567zKAFafym1R4IifHZw9jlH2F2x0wP21+hD3cR+4ggtT+KnCv6N2ihDjoKJAoz7AlXjhb68xrCrlCorgO7hJmkJYm3k2+7bIsZ02lvCVI1ZdyFjdjn1SbRy0+14WOAPBvPQjfpax2/ae7J2SwahT5cjLGV9D8VnP6nwLBSicFNv1qeI23wiwPoTP32q4crGwk2BNwVf2tGY8B67ZVcX8m8p2MYHmlQDKcu1LT3xB4NUjTho5n/r7QLh0eqsH7NYm9T8YbX2EgsGVP6guK0QAlNORWsJKCAhPvTAEl4jlnWDv7Ip2rUR/0V9VBXO/bCE93o/TwKaOBCZQ7CPq9785p3L6cSfDe0ioXpFB13SdmiqS7HAvJx3yeFuY5OIcPZACJpv5YvM2ML6PQtHAzRsZdraAkcaSTiNyxR9nD+hb4923DaC7WNgMXwNawdghkWHI8E/NWpTA/bzSKwahS/4hmkUu3hv8a2QRDQo97/3HjPmRPq8HGcHuwGTAKf7xJ1P9XjRgwvqzvKeh783OpPYR7IEcYS2qa1aJHneWHIm1Q3qUsyPujP3gDi/bq0toJzGKCboGMJMTQTr88gKvzCH0rFT6vGOqfFMZsn6A7udnzADWNduM++eBZd8qm6BYT+07u5FES+gKj/gI1ydCWyLkp/vpof5tZ6yEv2y5v0ww6EqAP9iFUUnMQ31UXUcZ7vRScxl7Jgm6pGfmoazQMh+bMDjvUBvkP3cJeoFIQy6VZj4vJGSWjcMHNKX4ZfZNvg7xGKFoLwOs1x2pBtJC6CYwD7FiDbLAmf7xkmqs08lh05blZF34Cphyl2A/dSBOlNO8VGMoZeDlB/JoRbRi8bUmKvSxCT9E=
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)(376014)(1800799024)(366016)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: u/sxbLAz9ZPf6ab6m1HyXsECdWyHU0jMih+ZeqBRvRYLQCJU77viGrfcuXC30mFqu2MaOWFxilXknSBL5M7TcdpVkRCKZBE6e4zedDKYFIwCIvH98c/qZN2UBRbLxHxih9/tRg1N9XDN3hDIo/oDnqyReYLTF6xAFWpyq6/yFYz5bJLo8Z3ixNszkSlM8+pmx2Yu9LmSAREbh8+6jfAGbi32b9u/4LgX2SbqgW/1ekccaKSacXHIFiVHAhZ0L9OWQh1K3oydtFebGOhHy0SwFE/qgpEz43SQR5EWgM6jt0R5hWv4gMDmLrO/267xisGKg/SfX5l/I2oPYFYGNZ2VFHPRjBKNNgiXP8rgPV6w2po++l7cQmC9vbHDVTRjD54fHOaos3n8oI2epii2sG7r1Um//zlNfPD8AhdsB2VqeiwGt2nTgKxxZvpk4apj7jgk4HWCcezpUNk1ZVUCQwYn2JfcNRmKOJx7NZpaNGkelVcCn+HeEe5KfEFTNjxazzAqfMqaKo9dJC6MlKgsp6o0xvBCrYO04dTMpK4/lfj/mOk2XQu4gcInV0qr80tG91rbxbVO4cWwGBAfSkulTBM4zes2bZxKanpAssxYEbqOCKB9aMjJRN58vQckdQ9BaHSmpacCFIqGrmy5T2idYGctt6NcF/23k8iD4ZTT+ya0Yvi27/Iq3C/ALbIC5JhrROx7a5jhnL98B8bOsvxMcZhrSaZFY5WN1DIcfl1HUAOZ7UPAXen8xPxo10YJYt0cSVBWIodQs0XVeTa0ksLed7EFcK6et0mfZbsQYCsF87WsaNV6nYYhC5i9KMmrQku7EWQ7Xay7C1HB3ZOoLSC7rNr6j/LxS2aQVMcm4K/V6vaBT8TFnWuxdXC+jg1mM9DmuPHUhaX3GNxHnOY5EPJBalVTzjM5/GXgxCuttLgTVM6mQKrKxAYBix4jurp0CI0F7qOMleJTwEAKRFSnngFWk9zUvj9n0faEc7xNFPAqpq0ELlgEGHTwgQxpHaZAZlI8HPbqr1RkrhIXQq8oQ6OhCe8V8l/sGoEYFX+3Zm4Wl3f8Wx5xFt8Vi0JLKa/XQHZVahdMfyHyy58wvOw5wAlhuR+ukMuElPrHDtc2WtSzmB2E+tKSqDzRNJ3Gy5i6QAHwyGrFUitP5MNhOXEE75LfjVe2KJswCLWHvCANyGZElir8TjBrFdNOpHaU4HyU13AhQno8EExIhZefKUS53paVcz5Feby7c8JwH0bMo+Hf+BqJaGw++u2nYMG7hjFUBrws6dgF+iEV/1tmRo464N/A7Y1aq669cfqDjauiGM2qL8dW7kH9IdnaOSIy8NgWy0C7lnme7QEIrHYZZWQss9kWjFG7IandOt4g0BRMV8RZLm+Kt1YdW2qVJ94LCb4NNxr+9nCAygnNg3kMxKkk4ViK9z64wblKMz4S/IRBk1FwDQn/+2GIliqwsrGybnf5Q/DR7XEcUkG0Wxw211Mlfqz9/agqutH2L58NFkE72x8TSyDePMVQspgXHjdu8KxzqJB13ukWjb1KaotEgfnkLj6u/6EULWedO5bKneQVG3G2maM2UiCVFCQBUUTuEZsfVqBowVYEz0B1Z2YtA3ov5Al5bf/rsmbErO45J4gYbbLTMu+Wabo=
Content-Type: multipart/alternative; boundary="_000_SA1PR08MB72159C184A0EEF0A4125A044F7812SA1PR08MB7215namp_"
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: b02ec8ea-0023-4056-b834-08dcbf23ecb9
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2024 01:20:19.6085 (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: h8pAkEWCxyiKuIiAJjGvFzpB6dJaV8GzRBV1mjzw3Y7Gi76ET5gPeCUH1yXDxHJVfEXfAN3QYF3vVCp594hJ6Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV8PR08MB9488
Message-ID-Hash: OP65X5RU2SMFRXSPYQDNUYPKVLPHVMBT
X-Message-ID-Hash: OP65X5RU2SMFRXSPYQDNUYPKVLPHVMBT
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
CC: "bess@ietf.org" <bess@ietf.org>, "draft-ietf-bess-evpn-mh-split-horizon.all@ietf.org" <draft-ietf-bess-evpn-mh-split-horizon.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [bess] Re: Opsdir last call review of draft-ietf-bess-evpn-mh-split-horizon-10
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/9tcSS7cbyceC4YJ-Uf7gYI3CSGo>
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 Sue, Thanks very much for your review! Hopefully, version 11 addresses your concerns. Please see in-line with [jorge]. From: Susan Hares via Datatracker <noreply@ietf.org> Date: Wednesday, August 14, 2024 at 9:19 AM To: ops-dir@ietf.org <ops-dir@ietf.org> Cc: bess@ietf.org <bess@ietf.org>, draft-ietf-bess-evpn-mh-split-horizon.all@ietf.org <draft-ietf-bess-evpn-mh-split-horizon.all@ietf.org>, last-call@ietf.org <last-call@ietf.org> Subject: Opsdir last call review of draft-ietf-bess-evpn-mh-split-horizon-10 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. Reviewer: Susan Hares Review result: Has Issues This is OPS-DIR review. It should be take as any other WG LC comments Status: Has Issues and editorial NITS Summary: My main concerns are: 1) RFC9012 related concerns (a) descriptions associated with RFC9012 in sections 2.2 and 3.0 of this document, (b) Warnings about RFC9012 + RFC8365 interactions in Appendix A of RFC9012 (c) Lack of clarity of draft-ietf-bess-evpn-geneve in RFC9012 usage. 2) Error handling a) Lack of Error handling section b) assumptions on NVE actions under local bias (see section 1.2) What is good about the draft: a) Clear description and discussion of ESI Label-based Split Horizon and Local Bias, b) Clear delineation of default (Table 1) c) Consideration of BUM traffic ========== RFC 9012 issues 1) Section 2.2 paragraph 2 states: current text:/ As an example, egress NVEs that support IP-based MPLS tunnels, such as MPLSoGRE or MPLSoUDP, will advertise A-D per ES routes for the ES along with the BGP Encapsulation extended community, as defined in [RFC9012]. This extended community indicates the encapsulation type (MPLSoGRE or MPLSoUDP) and may use the SHT value of 01 or 10 to signify the intent to use Local Bias or ESI Label, respectively./ / It would be helpful to link this to a Encapsulation tunnel type in RFC9012 or other documents. Based on the definitions in your introduction: * MPLSoUDP: Multi-Protocol Label Switching over User Datagram Protocol, [RFC7510] * MPLSoGRE: Multi-Protocol Label Switching over Generic Network Encapsulation, [RFC4023]. What are the correct BGP Encapsulation tunnel types that MPLSoUDP and MPLSoGRE utilize in the extended community? Are you intending the following: * MPLSoGRE: Multi-Protocol Label Switching over Generic Network Encapsulation, MPLS-in-GRE (RFC9012 Tunnel type 11) * MPLSoUDP: Multi-Protocol Label Switching over User Datagram Protocol, [RFC7510], UDP Destintaion port (RFC9012 tunnel type 7)? If so, please specify in the text. If not, please indicate what are the valid RFC9012 tunnel types for these symbols. [jorge] we added a reference to the IANA registry and the corresponding tunnel type in the registry. Hopefully that clears the concern. 2. Section 2.2, paragraph 3, needs to give a direct link to RFC9012 tunnel types. Current text:/ An egress NVE MUST NOT use an SHT value other than 00 when advertising an A-D per ES route with encapsulation types such as VXLAN, NVGRE, MPLS, or no BGP tunnel encapsulation extended community, as specified in [RFC9012]. / Proposed text:/ An egress NVE MUST NOT use an SHT value other than 00 when advertising an A-D per ES route with RFC9012 Tunnel encapsulation types of VXLAN, NVGRE, and MPLS Label stack./ [jorge] added this: “An egress NVE MUST NOT use an SHT value other than 00 when advertising an A-D per ES route with [RFC9012<https://author-tools.ietf.org/api/export/a44944ea-dcfc-49bb-a19b-2111788223f7/draft-ietf-bess-evpn-mh-split-horizon-11.html#RFC9012>] Tunnel encapsulation types of VXLAN (type 8), NVGRE (type 9), MPLS (type 10), or no BGP tunnel encapsulation extended community at all.” Question to authors: What did you mean "No BGP tunnel encapsulation extended community"? If BGP passses a [RFC9012] tunnel, it must come with a tunnel type. Are you suggesting there is no "Encapsulation Extended Community" Attached? [jorge] Yes, from RFC8365: “The MPLS encapsulation tunnel type, listed in Section 11<https://www.rfc-editor.org/rfc/rfc8365#section-11>, is needed in order to distinguish between an advertising node that only supports non-MPLS encapsulations and one that supports MPLS and non-MPLS encapsulations. An advertising node that only supports MPLS encapsulation does not need to advertise any encapsulation tunnel types; i.e., if the BGP Encapsulation Extended Community is not present, then either MPLS encapsulation or a statically configured encapsulation is assumed.” 3. section 2.2, paragraph 4, Geneve tunnel Current text:/ An egress NVE advertising A-D per ES route(s) for an ES with GENEVE encapsulation MAY use an SHT value of 01 or 10. / New text:/ An egress NVE advertising A-D per ES route(s) for an ES with GENEVE tunnel encapsulation [RFC9012, I-D.ietf-bess-evpn-geneve] MAY use an SHT value of 01 or 10. / [jorge] added references. 4. issue with Geneve specification (draft-ietf-bess-evpn-geneve) RFC9012 only allows the Encapsulation Community to specify RFC9012 tunnel type. draft-ietf-bess-evpn-geneve specifies tunnel type Geneve (Value=19) and the Geneve Tunnel Options SubTLV for the EVPN (AFI: 25/ SAFI: 70). This definition indicates that the Geneve tunnels must have a Tunnel Encapsulation attribute with SubTLVs. draft-ietf-bess-evpn-geneve does not specify: a) What SubTLVs are valid for the Genve Tunnel Type in the Tunnel Encapsulation attribute. b) What validation procedures are used for the Geneve tunnel type with the tunnel encapsulation attribute. c) What happens if the Geneve tunnel type is specified on the Encapsulation Extended Community and a tunnel Encapsulation Attribute? d) What happens if the Geneve Tunnel type is specified in the Encapsulation Extended Community? [jorge] I agree those things can be clarified in draft-ietf-bess-evpn-geneve, it would be great if you can let the authors know your comments about this draft (I’m one of them, but it would be great if you can send all the comments relevant to that draft in a separate email, please. Thanks for bringing this up. 5. Need complete specification on what [RFC9012] tunnels are supported by this procedure. Please add a section or a table that indicates which tunnel types can be used for section 2.2 and 2.3. For example, is the Prefix-SID [RFC9012] a valid encapsulation? (see https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fbgp-tunnel-encapsulation%2Fbgp-tunnel-encapsulation.xhtml&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C45fe42f3de9d40c18ab708dcbc7ce775%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638592491890654525%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ijT12Yb47HnnnP1x7qO62zePCR88poAGGfbO%2B429THA%3D&reserved=0)<https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml> [jorge] table 1 specifies the encapsulations supported by this document, and then their definition is in section 1.1. That should address your comment. 6. Section 3, NVE announces multiple A-D with multiple Encapsulations If you have multiple A-D per ES routes for the same ES, will you have multiple encapsulation communities? [jorge] yes, as per RFC8365, which we refer to in this section. Section 3 - in the 4th paragraph suggests this point in the text: text:/ a. An A-D per ES route for ES-x may be advertised with multiple encapsulations, some of which support a single Split Horizon method. In this case, the Split Horizon Type (SHT) value MUST be 00. For instance, encapsulations such as {VXLAN, NVGRE}, {VXLAN, GENEVE}, or {MPLS, MPLSoGRE, MPLSoUDP} can be advertised in an A-D per ES route. In all these cases, the SHT value MUST be 00./ In addition, the GENEVE Encapsulation (per draft-ietf-bess-evpn-geneve-08.txt) can only be passed in a Tunnel Encapsulation Attribute [RFC9012]. [jorge] for the A-D per ES route yes, I agree. Not for the other EVPN route types. The error handling does not handle what happens if geneve encapsulation is in a extended community. [jorge] please check the version 11 diff for section 3. It addresses your comments. 7. Why does the text not suggest the possiblity of using the Tunnel Encapsulation Attribute as well as the encapsulation community? It seems that the SRv6 work would hint that the tunnel encapsulation Attribute should be considered in this draft. [jorge] this document does not define the procedures for each encapsulation. The scope is only the split horizon filtering procedures for the already defined encapsulations in EVPN. The specifications for EVPN and the different encapsulations are RFC8365 (for all NVO encapsulations), RFC7432 for MPLS, RFC9252 for SRv6, I-D.ietf-bess-evpn-geneve for GENEVE. Those specs define if the BGP encapsulation extended community or BGP Tunnel Encapsulation Attribute (or no indication of the encapsulation at all) is used along with the EVPN routes. Procedures + Error issues 1. Section 1.1, paragraph 2 - Local Bias Description could help build the case for NVE errors a) How does NVE track the IP Addresses(es) of other NVEs with which it shares multihomed ESs? What happens to local bias if the following occurs: a) NVEs incorrectly miss the IP addresses of other NVEs on the same multihomed ES. b) What happens if NVE does not filter out frames on the local interfaces connected to ESs that are shared with the same ingress NVE? [jorge] RFC8365 is the specification about local-bias and how the NVE tracks other NVEs. This document does not alter the local-bias specification. I would suggest to go through RFC8365 and if needed, discuss with the RFC8365 authors. As a WG participant I can also share my opinion, of course, and I’ll be happy to discuss. These errors can cause local bias to have errors. It needs to be stated what happens if these errors occur? There should be some error handling or "manageability" warnings in the text. [jorge] We added this note in section 1.2 to clarify that the procedures themselves are not modified: “Note that this document does not modify the Local Bias or the ESI Label Split Horizon procedures themselves, just focuses on the signaling and selection of the Split Horizon method to apply by the multihomed NVEs.” 2) Due to the complexity of the [RFC9012] issues and the text in sections 2 and 3, it would be good to have a manageability and an error handling section. The manageability section should summarize what operators need to configure and monitor. The error handling section should include RFC9012 error handling (see comments above) and what happens when assumptions (see the word "assume" in this text) does not occur. [jorge] see resolution of your comments above please. The use of RFC9012 in EVPN for the different encapsulations is specified in other standard documents, we are not modifying that in this document. Hopefully the new text help clarify the scope. Editorial NITS: Nit 1: Section 1.1, MPLS and non-MPLS NVO tunnels, 1st sentence. Old text:/ * MPLS and non-MPLS NVO tunnels: refer to Multi-Protocol Label Switching (or the absence of it) Network Virtualization Overlay tunnels. / Comment: This sentence is unclear and needs a rewrite. I think you man MPLS tunnels and non-MPLS NVO tunnels. [jorge] you’re right, fixed now. Nit 2: Section 1.2, paragraph beginning "Similarly, certain IP Tunnels -", In this paragraph, it would be very helpful to provide the sections in [I-D.ietf-bess-evpn-geneve], [RFC9252], and [RFC8986] My understanding is [RFC8986]- section 4.12, RFC9252 - section 6.1.1, draft-ietf-bess-evpn-geneve - section 4.1 [jorge] added, thx Nit 3: Section 2.1, paragraph 1 It would be helpful to augment the second sentence with the section in RFC8365 that is the default behavior. I found the default behavior in section 8.3.2. If this is correct, please add this to sentence 2. [jorge] added “section 8.3.1”, which I think it is what you meant, thanks. Nit 4: Section 2.1, SHT Bit descriptions old text/ 0 0 --> Default SHT. Backwards compatible with [RFC8365] and [RFC7432] / issue: wrap in this text extends past 72 lines, and gets cut off [jorge] fixed now, thx Nit 5: Section 2.1, paragraph 3, "treat-as-withdraw behavior". old text:/ If a route with any of the mentioned encapsulation options is received and has an SHT value different from 00, it SHOULD apply the treat-as-withdraw behavior./ new text:/ If a route with any of the mentioned encapsulation options is received and has an SHT value different from 00, it SHOULD apply the treat-as-withdraw behavior per [RFC7606]. / [jorge] added, thanks. Nit 6: section 2.2, second to last paragraph, beginning "An egress". reason: clarity of comma usage Old text:/ A value of 00 indicates the default behavior outlined in Table 1, which is to use Local Bias if no ESI-Label is present in the Ethernet option TLV, or if there is no Ethernet option TLV. / Suggested new text:/Old text:/ A value of 00 indicates the default behavior outlined in Table 1 which is to use Local Bias if: a)no ESI-Label is present in the Ethernet option TLV, or b) if there is no Ethernet option TLV. / [jorge] added, thanks. Thanks again for the thorough review! Jorge
- [bess] Opsdir last call review of draft-ietf-bess… Susan Hares via Datatracker
- [bess] Re: Opsdir last call review of draft-ietf-… Jorge Rabadan (Nokia)
- [bess] Re: Opsdir last call review of draft-ietf-… Susan Hares