Return-Path: 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 CCC9DC18DBBA; Wed, 10 Jul 2024 07:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 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_NONE=-0.0001, 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_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 gnHvGKgdYwS9; Wed, 10 Jul 2024 07:04:26 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2046.outbound.protection.outlook.com [40.107.21.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE26FC151068; Wed, 10 Jul 2024 07:04:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=NixjVKDjNU42Oe4aCopb2BqIVx5mDraCrw2HtODy4Xc9sjeGotVaY0e7bA4BTT2aSjQ1jomp9y2ODNVqBR5dhqAQMEosGomA+vofMSkL5XFbGYseDENNL930Gi98QYsLLxXe7rCkdVTrMbOW/I4wUgIqIaSVSDmXVlflgZZdOzQjDO1KFQrvv7PYkasf5gF3qzeTxb05jKOxSmLV9iD27c4MerhGMD0ytf5+69+M7+7tOWeEheAjS9w8Op30wR8jioDOW56SSHfgWVphdYHUHR8HPXPMaJItkC8K77lazzgPnmKIH6HCF1fap6ULiB1AKFAFZBC6Y99lpmpQgPYivQ== 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=Kaa0GRV7KhxCOcSC/fhnNfYpJp9PnH3XshmVTTrLsOk=; b=eFu1NtLNyZYOMQLi9Fut2FZEGH5+vxtJI17a3+oS9d50MmXMHgWVaYU09tvt7USE6rxR5DLZhZwzATDDhbM8vY2BCkmeuaEnTC5VTKfGHIb+5ebeD/wM2DWZEQqZtXL7D/9yZtPpTUNTktoeMWH4F4NkOZndMQgMgY2hr3kLMfSrUh95cNzVPqDVQ9N10KGKqtwBKx/jYT44cchzZs0FOn4BfSHasVO4L1NlvR5jd3V374GPeDLnr51msvHNE8RUW4mcEdKetDUsnL3mcSkSf4tIN4fmVaIgEj88+C96yn3L1X9uZq60Mcpd6IOwc4qAK3VBDCfmWjylv7llDT6u6Q== 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=Kaa0GRV7KhxCOcSC/fhnNfYpJp9PnH3XshmVTTrLsOk=; b=rj4BHkrS4elX14eKXkfBvW1EipfPDppRH3XqPCnkh+GbGt+KZhmXt2+YLsxOHd26Oi/dhgUxPLKQhlt8VSOeCmTErVbQW/vh/GUOFMm9lqAq3T6gmZrCnGs3mB6bHwAfFAf6Wrt482p2b6VIMLgg8SeObQFZ4mJzT5A0ZCwRR70TKHpafJjJCBXbSzwr3hlt2Uh04iNMzH+wvsyXeYeFCrUt3ICwG99TH7o5CfadxqRmTLqLcaVyonzEvimuTC2souTg3qfe9pRPnBdgJtqMRuYqJpWIhY9i0dJmh34/j+f9Kc3/TlGdts7E4b1JQbuupjN6FENb+523/Q5bTvwwGA== Received: from AS1PR07MB8589.eurprd07.prod.outlook.com (2603:10a6:20b:470::16) by AM8PR07MB8189.eurprd07.prod.outlook.com (2603:10a6:20b:320::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7762.20; Wed, 10 Jul 2024 14:04:17 +0000 Received: from AS1PR07MB8589.eurprd07.prod.outlook.com ([fe80::5ca6:f902:8e31:6f3e]) by AS1PR07MB8589.eurprd07.prod.outlook.com ([fe80::5ca6:f902:8e31:6f3e%6]) with mapi id 15.20.7762.016; Wed, 10 Jul 2024 14:04:17 +0000 From: "Gunter van de Velde (Nokia)" To: =?iso-8859-1?Q?Luc_Andr=E9_Burdet?= , "draft-ietf-bess-evpn-fast-df-recovery@ietf.org" Thread-Topic: [Shepherding AD review] review of draft-ietf-bess-evpn-fast-df-recovery-08 Thread-Index: AdqyhEE0/udg6AbaSrirv0DsStOLzQe+vtnIAFSRkHA= Date: Wed, 10 Jul 2024 14:04:17 +0000 Message-ID: References: In-Reply-To: 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: AS1PR07MB8589:EE_|AM8PR07MB8189:EE_ x-ms-office365-filtering-correlation-id: e10872b3-d8ef-4b9e-2902-08dca0e92ff1 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|1800799024|4022899009|366016|38070700018; x-microsoft-antispam-message-info: =?iso-8859-1?Q?C+KVAC4mIeA5KtI8pWPSZdpRG/MTwAD0Y5OCuN2FkbZaCF6n/FC8riD0YC?= =?iso-8859-1?Q?16BMhaK9PsOfODWysWn/Zuvfb9/kLbedaKcmij4Y80lj67wBYI/tKMr2Ox?= =?iso-8859-1?Q?1lDLUA2jGSlcWzJaumhfPmpvfFZFVwSNE/8VN9hODzullPo6qeMRS811s7?= =?iso-8859-1?Q?Ii+3JZ2sIu1ZO1rE7uOtifs0Q6mCYEj9lCrv902o7Z+P9pd/fGVOtfklJ0?= =?iso-8859-1?Q?MqQN9QYjP8lvyG5iFOZ02VhJvuwD3YhCI5POJSK0sFP3Zr1hi15PRQKB57?= =?iso-8859-1?Q?ykXM9QXYQQ77u7lwofRXiLGoMnbFYlVlX/ha5apnHAkJxBF2Y11ihapDxU?= =?iso-8859-1?Q?6a6WqoO5lHfNWQgbFMFymuGLcjt3AVWxGQpRt7mPSlUnGYdcFf1oIIt4TO?= =?iso-8859-1?Q?1ck9Wr6GgCnmmkwW9VWbLI5hLXjYf0kf+n33QzejMvMdJx6kTaQ8ydZ6x8?= =?iso-8859-1?Q?qz/aGkXRJ66jjbcukpawL/+6Q9aEyFSANULEOxlLqbakmyGAWFO7yHqmXb?= =?iso-8859-1?Q?Q8sUncwZJ3SH1Gm8SgG+zdweVuClj0CoP5/hiKMnhMksQ3m+izHhCYZt0T?= =?iso-8859-1?Q?hH9Z0kJwQAO67ZMDDLG/GMmZKwA7ndb/LmuTNwKgMUM6AIJ8akcqSBpfNc?= =?iso-8859-1?Q?sxyqVF0prkTtRFltAHgxXAiq/6ICd2kmHN0DC17MdaUmq445tdkBDSNWQd?= =?iso-8859-1?Q?/KJNLniwHI5E6WfFF2tspuMpn2z2nSJR9zBSHoXLDkZ10xIHlrNz22MPsN?= =?iso-8859-1?Q?kRcUW97iDgPj93xeOFr0h8DMWI0NICjeTGnesuHJx6jYCrvRGnyBWekTyr?= =?iso-8859-1?Q?lLxoKcBBUaZpRywGGJxHk72vYQNL1qWcJATnzg+jfQdLSkhjP87GzLB7+B?= =?iso-8859-1?Q?BTQ2AYXkBpg4H4goR/8xUNv/4WMrj/j1FqeB3w824mpINuebo+VXIqUrVU?= =?iso-8859-1?Q?N0yn0Pz6GVsgQRBK2Otssj4zI5WspHzIHgUDaLfGkZFfNBMsKMaOcYeVLQ?= =?iso-8859-1?Q?m72otIwSo8+Muz1ls2/PCFN11i2AVVyfFSqMDhNjfu5Mb+wZlZh//eLXQv?= =?iso-8859-1?Q?uoYTOZyn4ZUuH1BOv7Y0GcMjR9XtQlOn1ChAnYmzlaVDVGbjkorYvZWHi+?= =?iso-8859-1?Q?LigZrlAKiY1rUy9O9p2tgZvHNSjzLF5tBUt6XZwN5aTfORHsdF9dBCUho4?= =?iso-8859-1?Q?zl45vodCRKBZ6n5zmWV/od2bhj8q63q5QXZKMpeGCuNsJ8n/m6ftbe+Pb1?= =?iso-8859-1?Q?2DAgDhwVd7r4d2RFgDh0NmAXmlDDRLfQUw5BU1IeklX1lk7F/QRhafmow0?= =?iso-8859-1?Q?aUU/bMK9e1nMMFC0uwosZmUIwth0HYwZV4QibK+FCiGPSDWaRYlIdTgWT9?= =?iso-8859-1?Q?NOv6TepP5OOsQMZ6M/FYbyktZ+zGxC6jnCQvTXfpIYbzn0dIDrDLw=3D?= 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)(376014)(1800799024)(4022899009)(366016)(38070700018);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?tELJR/OUjK0JKB6R6EhC8ng6b+quTxoPBz4bQcRYlJYd0pjEkJwQ6dSme3?= =?iso-8859-1?Q?TH+RDNLdiydG9n2uYv/YbR9iSrTEpet91KI+57Z56hVtMfMXAxRjk26Nq/?= =?iso-8859-1?Q?tXCb3iFzbFVsnP5WrUaJ2S2P4r/JrAqUYHHyc60GAqvvRk5XAvP/cyTZK3?= =?iso-8859-1?Q?UBScoKcTaH8ThWWINJfHWFA5lzmVyPMMLcY1bWtaEQTeJIosw83nVF4PfY?= =?iso-8859-1?Q?FP50XqSiyvVf8NqDUSRGeoma+8aTcACaewDljnkg7tN0sQNRqMzz8WEPtY?= =?iso-8859-1?Q?4WT/kWC3dzJqydcNGJ48LVXSfvdpnwjeUM2atslWUxpSloa2As76SYuVYt?= =?iso-8859-1?Q?BjFTaejvNL01UU55sdA+iTnO3a2CGkj5yLMewj35j9f48y9lKohWy5lwt3?= =?iso-8859-1?Q?/kPHDNWZv5dy7ybRnRpuK5dABj1z3ZkVQkXCFH/m34iV8CAh+vStQY2pin?= =?iso-8859-1?Q?+wdxN7CiFRm6qrbvtA+NfYe4cotQUi77o3tZ16xRO8Bojo14210TRedlhU?= =?iso-8859-1?Q?0dNo6qLnQgvQK4G/RNEVY61OkUaqovcm74iPyW67RoH6Uqn49z/YzDgOjn?= =?iso-8859-1?Q?5WGlaVQfChXJaTQj3x6SVoXNuYnzwc4MD3/4ZN5c5Te2MIn2vUvtiyN1YD?= =?iso-8859-1?Q?QoNo6gx4SD4BzdQ2fn/nhKl5qlaP6l8xiGWttnNrJxkKOnMjwSZmjAxlSF?= =?iso-8859-1?Q?PR+83vOhvvOCwtpKP6bjBix0f/93yb0tEvOqXCj0mNkhRahq2jUEWv5aUy?= =?iso-8859-1?Q?d0CKfg4MAi7uFaH6hPDvSwH8l5s2oWtAP8rGJRzY3A0c08WtSN1xfxKYi4?= =?iso-8859-1?Q?aVEU/f7HDAiJXi8i4hcvketyccDAmJmvJgk11OV9LEIK/mjRneHlBYXopq?= =?iso-8859-1?Q?rrKjiiJGybKkYuWzdw7xbjQs/q9ovwsClPjTBC+9qQVxzwZ2SXx+/wcJDl?= =?iso-8859-1?Q?YSAw82plLkrqGck/yOn7umIiHNahk+Ub4yiEGG8iFWEBYSn3gfbCGV9Aux?= =?iso-8859-1?Q?vi3ZyPMbpl4w6a5EOa0ASnRRa7wyEoD0y4HNXK8Ps6h9eV2IKTZueJyf19?= =?iso-8859-1?Q?k/p+flyqjspoMmBeKwzN1llD+0+4uO8gkg6SrxzuQuZ1hvqD49NBSFbIYV?= =?iso-8859-1?Q?6Nl7FcKGFNAKE2qjui7rfSXgWofc5XFl/tZv7AqHlLbzKXJRK+8FnY5h++?= =?iso-8859-1?Q?zRcYq4dN67WVPkTfrVucHPdsknd8RV/Ep17KiHJUquZiXCXUxKx0l0bRcE?= =?iso-8859-1?Q?oIP/lBLTRZkjG89Tfg2u/0F+ZYXryBgINrkbVXYfBMCyFCf2809IFHVT6l?= =?iso-8859-1?Q?9XkkSF6B3ziC8YQTPHmw1TSut5zlXpETS7r1NuqQi4HwBfKUKwZU//kwkv?= =?iso-8859-1?Q?W4vW4GatdT9hqR/2QbN8mCFS2s6af5LPeJdv/G54P8KmqYnlNEC+a5DvZq?= =?iso-8859-1?Q?AZT53YbRRqMVqZWfo756vjYAn/o8nwlL4IGz8HMS9RD0oLuUPRsDLUc5iQ?= =?iso-8859-1?Q?t1FTSRRu01rZXXa7fWsE3zygtUXPHEXZD+OR7R53cj4H63Vqr9A3Rvuo5C?= =?iso-8859-1?Q?XyxHZQUehmz2ZZ10iHqy0UGWJw1ZkiXXCtW43OCOu1fe6WY4FPeGR4Ero2?= =?iso-8859-1?Q?3YTbYRzNd+MA8GKaHhEx1FvQ1wcAwQwq0YE/ZvcsWIZDPnJtXe7fi0uoCg?= =?iso-8859-1?Q?+P01g5Y/u5QjxJHl4W3FOvxUj6j33O1mXQBd+aT4oTnzvb9ibGe6/vDCKM?= =?iso-8859-1?Q?+p/g=3D=3D?= Content-Type: multipart/alternative; boundary="_000_AS1PR07MB858908A3B6F80BEDB2419012E0A42AS1PR07MB8589eurp_" 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: e10872b3-d8ef-4b9e-2902-08dca0e92ff1 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2024 14:04:17.1481 (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: /rZmcxS3kC6gf5A2gcEKDpz2cM6IS5Lr6gcXEq+8/FfSVgJbOzliuAELZUbBdhOW4Jy8S6Jd8d0PADczlPyvhj0FEyGpfMZ2v9XX9usUk6o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8189 Message-ID-Hash: MJBIY2OS7UXTOLYB3X5SC5ETXF4PWV5W X-Message-ID-Hash: MJBIY2OS7UXTOLYB3X5SC5ETXF4PWV5W 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' X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bbess=5D_Re=3A_=5BShepherding_AD_review=5D_review_of_draft-ietf-?= =?utf-8?q?bess-evpn-fast-df-recovery-08?= List-Id: BGP-Enabled ServiceS working group discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_AS1PR07MB858908A3B6F80BEDB2419012E0A42AS1PR07MB8589eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Luc Andr=E9, Authors & WG, IETF LC for draft-ietf-bess-evpn-fast-df-recovery-09 has been requested. Thanks for your patience. G/ From: Luc Andr=E9 Burdet Sent: Monday, July 8, 2024 11:42 PM To: Gunter van de Velde (Nokia) ; draft-ietf= -bess-evpn-fast-df-recovery@ietf.org Cc: 'BESS' Subject: Re: [Shepherding AD review] review of draft-ietf-bess-evpn-fast-df= -recovery-08 You don't often get email from laburdet.ietf@gmail.com. Learn why this is important 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. Hi Gunter, thanks for the thorough review and suggestions towards readabili= ty. I have uploaded -09 incorporating most of your suggestions with the excepti= on of very minor details: Ex: "largest (latest)" instead of s/largest/latest/... we're talking both v= alues and time meaning both largest and latest make sense - I just kept bot= h terms. Regards, Luc Andr=E9 Luc Andr=E9 Burdet | Cisco | laburdet.ietf@gmail.com | Tel: +1 613 254 4814 From: Gunter van de Velde (Nokia) > Date: Thursday, May 30, 2024 at 07:28 To: draft-ietf-bess-evpn-fast-df-recovery@ietf.org > Cc: 'BESS' > Subject: [bess] [Shepherding AD review] review of draft-ietf-bess-evpn-fast= -df-recovery-08 # Gunter Van de Velde, RTG AD, comments for draft-ietf-bess-evpn-fast-df-re= covery-08 Hi All, Please find here a shepherding AD review of draft-ietf-bess-evpn-fast-df-re= covery-08 I'm sorry it took a bit of time to get started on this draft. I've begun reviewing this document before we kick off the IETF Last Call pr= ocess. Once we address these points, we can move forward with the document = through the IESG chain. A big thank you to Adrian Farrel for his RTG-DIR review on the -07 version,= which helped improve the document to its -08 version and to Matthew Bocci = for the Shepherds write-up (4 July 2022) In my review, I've noted some final observations while going through the do= cument. For better readability, I've suggested some paragraph edits. One thing I noticed is that there's not much RFC 2119-based normative langu= age used. Maybe the authors can take another look and add or update the RFC= 2119 text where needed. You can find my review notes below. #GENERIC COMMENTS #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 88 Virtualization Overlay (NVO) and DC inte)rconnect (DCI) services= , and Typo with the ")" 100 multihomed Ethernet Segment. This DF election is achieved 101 independent of the number of EVPN Instances (EVIs) associated wi= th 102 that Ethernet Segment and it is performed via simple signaling 103 between the recovered node and each of the other nodes in the 104 multihomed group. I believe that the word 'simple' is reasonable subjective. It may be better= to replace with a construct using 'straightforward'. Possible rewrite: "This Designated Forwarder (DF) election is conducted independently of the = number of EVPN Instances (EVIs) associated with the Ethernet Segment and is= executed through straightforward signaling between the recovered node and = each of the other nodes in the multihomed group. " 105 This document updates the state machine described in Section 2.1= of Being more explicit in what is updated could be better. "This document updates the DF Election Finite State Machine (FSM) described= in Section 2.1 of" 131 In EVPN technology, multiple Provider Edge (PE) devices have the 132 ability to encap and decap data belonging to the same VLAN. In expand on encap and decap for better readability. 131 In EVPN technology, multiple Provider Edge (PE) devices have the 132 ability to encap and decap data belonging to the same VLAN. In 133 certain situations, this may cause L2 duplicates and even loops = if 134 there is a momentary overlap of forwarding roles between two or = more 135 PE devices, leading to broadcast storms. possible readability rewrite: "In EVPN technology, multiple Provider Edge (PE) devices possess the capabi= lity to encapsulate and decapsulate data associated with the same VLAN. Und= er certain conditions, this may result in Layer 2 duplicates and potential = loops if there is a temporary overlap in forwarding roles among two or more= PE devices, consequently leading to broadcast storms. " 137 EVPN [RFC7432] currently uses timer based synchronization among = PE 138 devices in a redundancy group that can result in duplications (a= nd 139 even loops) because of multiple DFs if the timer is too short or 140 packets being dropped if the timer is too long. RFC7432 is providing more a specification the using a timer. Hence a more e= xplicit text blob to document this property: "EVPN [RFC7432] currently specifies timer-based synchronization among PE de= vices within a redundancy group. This approach can lead to duplications and= potential loops due to multiple Designated Forwarders (DFs) if the timer i= nterval is too short, or to packet drops if the timer interval is too long.= " 142 Using split-horizon filtering (Section 8.3 of [RFC7432]) can pre= vent 143 loops (but not duplicates). However, if there are overlapping D= Fs in 144 two different sites at the same time for the same VLAN, the site 145 identifier will be different upon the packet re-entering the Eth= ernet 146 Segment and hence the split-horizon check will fail, leading to = L2 147 loops. Strange grammatical construct and usage of "()". Potential rewrite to corre= ct this assuming i kept the issue described correct: "Employing split-horizon filtering, as described in Section 8.3 of [RFC7432= ], can prevent loops but does not address duplicates. However, if there are= overlapping Designated Forwarders (DFs) at two different sites simultaneou= sly for the same VLAN, the site identifier will differ when the packet re-e= nters the Ethernet Segment. Consequently, the split-horizon check will fail= , resulting in Layer 2 loops. " 149 The updated DF procedures in [RFC8584] use the well known Highes= t 150 Random Weight (HRW) algorithm to avoid reshuffling of VLANs amon= g PE 151 devices in the redundancy group upon failure/recovery. This red= uces 152 the impact to VLANs not assigned to the failed/recovered ports a= nd 153 eliminates loops or duplicates at failure/recovery events. Is there a reference that can be used for the well known HRW algorithm? What about the following rewrite proposal for readability: "The updated Designated Forwarder (DF) procedures outlined in [RFC8584] uti= lize the well-known Highest Random Weight (HRW) algorithm to prevent the re= shuffling of VLANs among PE devices within the redundancy group during fail= ure or recovery events. This approach minimizes the impact on VLANs not ass= igned to the failed or recovered ports and eliminates the occurrence of loo= ps or duplicates during such events. " 179 a given VLAN is possible. Duplication of DF roles may eventuall= y 180 lead to duplication of traffic as well as L2 loops. in previous text the word 'overlap' was used while here the word Duplicatio= n of DF roles is used. 195 * Complicated handshake signamling mechanisms and state machine= s are 196 avoided in favor of a simple uni-directional signaling approa= ch. s/Complicated/Complex/ s/signamling/signaling/ 198 * The solution is backwards-compatible (see Section 4), by PEs 199 simply discarding the unrecognized new BGP Extended Community= . I think that the "The solution" seems reasonable opaque description. Maybe = we should explicit mention that this concerns the fast dr recovery solution= . I only noted this here as the first occurrence, but the more explicit tex= t can be used in multiple locations within the draft text. What about: "The fast df recovery solution maintains backwards compatibility (see Secti= on 4) by ensuring that PEs discard any unrecognized new BGP Extended Commun= ity." 201 * Existing DF Election algorithms are supported. s/are/remain/ 232 Upon receipt of that new BGP Extended Community, partner PEs can 233 determine the service carving time of the newly insterted PE. T= he 234 notion of skew is introduced to eliminate any potential duplicat= e 235 traffic or loops. The receiving partner PEs add a skew (default= =3D 236 -10ms) to the Service Carving Time to enforce this. The previou= sly 237 inserted PE(s) must carve first, followed shortly (skew) by the = newly 238 insterted PE. I got thrown off-guard with the word skew as a non-native English speaker. Maybe a small explanation would be helpful. What about the following: "Upon receipt of the new BGP Extended Community, partner PEs can determine = the service carving time of the newly inserted PE. To eliminate any potenti= al for duplicate traffic or loops, the concept of skew-a small time delay a= dded to the service carving process to ensure a controlled and orderly tran= sition when multiple Provider Edge (PE) devices are involved-is introduced.= The receiving partner PEs add a skew (default =3D -10ms) to the service ca= rving time to enforce this mechanism. This ensures that the previously inse= rted PEs complete their carving process first, followed shortly thereafter = (by the specified skew) by the newly inserted PE. " 240 To summarize, all peering PEs carve almost simultaneously at the= time 241 announced by the newly added/recovered PE. The newly inserted P= E 242 initiates the SCT, and carves immediately on its local timer exp= iry. 243 The previously inserted PE(s) receiving Ethernet Segment route (= RT-4) 244 with a SCT BGP extended community, carve shortly before Service 245 Carving Time. This text provides me some confusion. The term "to carve" generally means t= o cut or shape something from a larger piece, often with precision and care= . Hence i was a bit surprised to see this used here. May I assume that in the context of these network operations and specifical= ly within EVPN (Ethernet VPN) and MPLS (Multiprotocol Label Switching) envi= ronments, "to carve" typically refers to the process of determining and est= ablishing roles or responsibilities for forwarding traffic among Provider E= dge (PE) devices? If yes, maybe such text blob should be explicit mentioned somewhere in the = draft? 266 [RFC5905]. As the current NTP era value is not exchanged, a loc= al 267 clock which is "synchronized" but to the wrong era is outside of= the 268 scope of this document. What is era value? 257 1 2 3 258 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + 260 | Type =3D 0x06 | Sub-Type(0x0F)| Timestamp Seconds = ~ 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + 262 ~ Timestamp Seconds | Timestamp Fractional Seconds = | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= + a figure number/caption is missing. 269 The 64-bit timestamp of NTP consists of a 32-bit part for second= s and 270 a 32-bit part for fractional second: There seems to be a 32bit/64bit and 128bt timestamp according: https://datatracker.ietf.org/doc/html/rfc5905#section-6 Should description not align with all of these? 274 * Timestamp Fractional Seconds: the high order 16 bits of the N= TP 275 fractional seconds are encoded in this field. The use of a 1= 6-bit 276 fractional seconds yields adequate precision of 15 microsecon= ds 277 (2^-16 s). I assume that the lower order 16 bits are assumed to be '0'? Maybe that sho= uld be explicit called out? 296 This capability is used in conjunction with the agreed upon DF T= ype 297 (DF Election Type). For example if all the PEs in the Ethernet 298 Segment indicate having Time Synchronization capability and are 299 requesting the DF type to be HRW, then the HRW algorithm is used= in 300 conjunction with this capability. readability rewrite: "This capability is utilized in conjunction with the agreed-upon Designated= Forwarder (DF) Type (DF Election Type). For instance, if all the PE device= s in the Ethernet Segment indicate possessing Time Synchronization capabili= ty and request the DF Type to be Highest Random Weight (HRW), then the HRW = algorithm is employed in conjunction with this capability. " Note, what happens if one of the involved PEs do not support Time synchroni= sation capability? 309 The peering PE's FSM in DF_DONE which receives a RECV_ES transit= ions 310 to DF_CALC. Because of the SCT carried in the Ethernet-Segment 311 update, the output of the DF_CALC and transition back into DF_DO= NE 312 are delayed, as are accompanying forwarding updates to DF/NDF st= ate. This processes not so easy. I assume that all these are states of the FSM? Would the following be a correct rewrite for readability? "Upon receiving a RECV_ES message, the peering PE's Finite State Machine (F= SM) transitions from the DF_DONE (indicating the DF election process was co= mplete) state to the DF_CALC (indicating that a new DF calculation is neede= d) state . Due to the Service Carving Time (SCT) included in the Ethernet-S= egment update, the completion of the DF_CALC state and the subsequent trans= ition back to the DF_DONE state are delayed. This delay ensures proper sync= hronization and prevents conflicts. Consequently, the accompanying forwardi= ng updates to the Designated Forwarder (DF) and Non-Designated Forwarder (N= DF) states are also deferred. " 314 The corresponding actions when transitions are performed or stat= es 315 are entered/exited is modified as follows: 316 317 9. DF_CALC on CALCULATED: Mark the election result for the VLAN= or 318 Bundle. 319 320 9.1 Where SCT timestamp is present on the RECV_ES event of 321 Action 11, wait until the time indicated by the SCT bef= ore 322 continuing to 9.2. 323 324 9.2 Assume a DF/NDF for the local PE for the VLAN or VLAN 325 Bundle, and transition to DF_DONE. What about the following procedure text blob description for clarity: " The corresponding actions when transitions are performed or states are ente= red/exited are modified as follows: 9. DF_CALC on CALCULATED: Mark the election result for the VLAN or VLAN Bun= dle. 9.1. If an SCT timestamp is present during the RECV_ES event of Action 11, = wait until the time indicated by the SCT before proceeding to step 9.2. 9.2. Assume the role of DF or NDF for the local PE concerning the VLAN or V= LAN Bundle, and transition to the DF_DONE state. This revised approach ensures proper timing and synchronization in the DF e= lection process, avoiding conflicts and ensuring accurate forwarding update= s. " 329 Let's take Figure 1 as an example where initially PE2 had failed= and 330 PE1 had taken over. This example shows the problem with the 331 DF-Election mechanism in Section 8.5 of [RFC7432], using the val= ue of 332 the timer configured for all PEs on the Ethernet Segment. To make the text more proposed standard style, what about this textblob for= readability: "Consider Figure 1 as an example, where initially PE2 has failed and PE1 ha= s taken over. This scenario illustrates the problem with the DF-Election me= chanism described in Section 8.5 of [RFC7432], specifically in the context = of the timer value configured for all PEs on the Ethernet Segment. " 334 Based on Section 8.5 of [RFC7432] and using the default 3 second 335 timer in step 2: 337 1. Initial state: PE1 is in steady-state, PE2 is recovering 339 2. PE2 recovers at (absolute) time t=3D99 341 3. PE2 advertises RT-4 (sent at t=3D100) to partner PE1 343 4. PE2 starts a 3 second timer to allow the reception of RT-4 f= rom 344 other PE nodes 346 5. PE1 carves immediately on RT-4 reception, i.e. t=3D100 + min= imal 347 BGP propagation delay 349 6. PE2 carves at time t=3D103 350 351 [RFC7432] aims of favouring traffic being dropped over duplicate 352 traffic. With the above procedure, traffic drops will occur as = part 353 of each PE recovery sequence since PE1 has transitioned some VLA= Ns to 354 Non-Designated-Forwarder (NDF) immediately upon reception. 355 The timer value (default =3D 3 seconds) has a direct effect on t= he 356 duration of the packets being dropped. A shorter (especially ze= ro) 357 timer may, however, result in duplicate traffic or traffic loops= . What about: "Procedure Based on Section 8.5 of [RFC7432] with Default 3-Second Timer: 1. Initial State: PE1 is in a steady state, and PE2 is recovering. 2. Recovery: PE2 recovers at an absolute time of t=3D99. 3. Advertisement: PE2 advertises RT-4, sent at t=3D100, to partner PE1. 4. Timer Start: PE2 starts a 3-second timer to allow the reception of RT-4 = from other PE nodes. 5. Immediate Carving: PE1 carves immediately upon RT-4 reception, i.e., t= =3D100 plus minimal BGP propagation delay. 6. Delayed Carving: PE2 carves at time t=3D103. [RFC7432] favors traffic drops over duplicate traffic. With the above proce= dure, traffic drops will occur as part of each PE recovery sequence since P= E1 transitions some VLANs to Non-Designated Forwarder (NDF) immediately upo= n RT-4 reception. The timer value (default =3D 3 seconds) directly affects = the duration of the packet drops. A shorter (or zero) timer may result in d= uplicate traffic or traffic loops. " 359 Based on the Service Carving Time (SCT) approach: 361 1. Initial state: PE1 is in steady-state, PE2 is recovering 363 2. PE2 recovers at (absolute) time t=3D99 365 3. PE2 advertises RT-4 (sent at t=3D100) with target SCT value = t=3D103 366 to partner PE1 368 4. PE2 starts a 3 second timer to allow the reception of RT-4 f= rom 369 other PE nodes 371 5. PE1 starts service carving timer, with remaining time until = t=3D103 373 6. Both PE1 and PE2 carve at (absolute) time t=3D103 374 In fact, PE1 should carve slightly before PE2 (skew) to maintain= the 375 preference of minimal loss over duplicate traffic. The previous= ly 376 inserted PE2 that is recovering performs both transitions DF to = NDF 377 and NDF to DF per VLANs at the timer's expiry. Since the goal i= s to 378 prevent duplicates, the original PE1, which received the SCT wil= l 379 apply: 381 * DF to NDF transition at t=3DSCT minus skew, where both PEs ar= e NDF 382 for 'skew' amount of time 384 * NDF to DF transition at t=3DSCT 385 386 It is this split-behaviour which ensures a good transition of DF= role 387 with contained amount of loss. 388 389 Using SCT approach, the negative effect of the timer to allow th= e 390 reception of RT-4 from other PE nodes is mitigated. Furthermore= , the 391 BGP Ethernet Segment route (RT-4) transmission delay (from PE2 t= o 392 PE1) becomes a non-issue. The use of SCT approach remedies the 393 problem associated with this timer: the 3 second timer window is 394 shortened to the order of milliseconds. What about the following textblobs for readability: "Procedure Based on the Service Carving Time (SCT) Approach: 1. Initial State: PE1 is in a steady state, and PE2 is recovering. 2. Recovery: PE2 recovers at an absolute time of t=3D99. 3. Advertisement: PE2 advertises RT-4, sent at t=3D100, with a target SCT v= alue of t=3D103 to partner PE1. 4. Timer Start: PE2 starts a 3-second timer to allow the reception of RT-4 = from other PE nodes. 5. Service Carving Timer: PE1 starts the service carving timer, with the re= maining time until t=3D103. 6. Simultaneous Carving: Both PE1 and PE2 carve at an absolute time of t=3D= 103. To maintain the preference for minimal loss over duplicate traffic, PE1 sho= uld carve slightly before PE2 (with skew). The recovering PE2 performs both= DF to NDF and NDF to DF transitions per VLAN at the timer's expiry. The or= iginal PE1, which received the SCT, applies the following: * DF to NDF Transition: At t=3DSCT minus skew, where both PEs are NDF for t= he skew duration. * NDF to DF Transition: At t=3DSCT. This split-behavior ensures a smooth DF role transition with minimal loss. Using the SCT approach, the negative effect of the timer to allow the recep= tion of RT-4 from other PE nodes is mitigated. Furthermore, the BGP Etherne= t Segment route (RT-4) transmission delay (from PE2 to PE1) becomes a non-i= ssue. The SCT approach shortens the 3-second timer window to the order of m= illiseconds, addressing the associated problems. " 396 3.1. Concurrent Recoveries This section seems to be missing RFC2119 language on how nodes need to beha= ve with respect the procedures outlined in this document. 402 Election. A similar situation arises in staggered recovering PE= s, 403 when a second PE recovers at rougly a first PE's advertised SCT 404 expiry, and with its own new SCT-2 outside of the initial SCT wi= ndow. The word staggered is oddly used. What about the following: "A similar situation arises in sequentially recovering PEs, when a second P= E recovers approximately at the time of the first PE's advertised SCT expir= y, and with its own new SCT-2 outside of the initial SCT window." 406 In the case of multiple outstanding DF elections, one requested = by 407 each of the recovering PEs, the SCTs must simply be time-ordered= and 408 all PEs execute only a single DF Election at the service carving= time 409 corresponding to the largest received timestamp value. The DF 410 Election will involve all the active PEs in a single DF Election 411 update. To add to a similar edited writing style: "In the case of multiple concurrent DF elections, each initiated by one of = the recovering PEs, the SCTs must be ordered chronologically. All PEs shall= execute only a single DF Election at the service carving time correspondin= g to the latest received timestamp value. This DF Election will involve all= active PEs in a unified DF Election update. " However, it may require some formal RFC2119 language to make sure that impl= ementations behave according this procedure 413 Example: 415 1. Initial state: PE1 is in steady-state, all services elected = at 416 PE1. 418 2. PE2 recovers at time t=3D100, advertises RT-4 with target SC= T value 419 t=3D103 to partners (PE1) 421 3. PE2 starts a 3 second timer to allow the reception of RT-4 f= rom 422 other PE nodes 424 4. PE1 starts service carving timer, with remaining time until = t=3D103 426 5. PE3 recovers at time t=3D102, advertises RT-4 with target SC= T value 427 t=3D105 to partners (PE1, PE2) 429 6. PE3 starts a 3 second timer to allow the reception of RT-4 f= rom 430 other PE nodes 432 7. PE2 cancels the running timer, starts service carving timer = with 433 remaining time until t=3D105 435 8. PE1 updates service carving timer, with remaining time until 436 t=3D105 438 9. PE1, PE2 and PE3 carve at (absolute) time t=3D105 Example: 1. Initial State: PE1 is in a steady state, with all services elected at PE= 1. 2. Recovery of PE2: PE2 recovers at time t=3D100 and advertises RT-4 with a= target SCT value of t=3D103 to its partners (PE1). 3. Timer Initiation by PE2: PE2 starts a 3-second timer to allow the recept= ion of RT-4 from other PE nodes. 4. Timer Initiation by PE1: PE1 starts the service carving timer, with the = remaining time until t=3D103. 5. Recovery of PE3: PE3 recovers at time t=3D102 and advertises RT-4 with a= target SCT value of t=3D105 to its partners (PE1, PE2). 6. Timer Initiation by PE3: PE3 starts a 3-second timer to allow the recept= ion of RT-4 from other PE nodes. 7. Timer Update by PE2: PE2 cancels the running timer and starts the servic= e carving timer with the remaining time until t=3D105. 8. Timer Update by PE1: PE1 updates its service carving timer, with the rem= aining time until t=3D105. 9. Service Carving: PE1, PE2, and PE3 perform service carving at the absolu= te time of t=3D105. 446 4. Backwards Compatibility 447 448 Per redundancy group, for the DF election procedures to be globa= lly 449 convergent and unanimous, it is necessary that all the participa= ting 450 PEs agree on the DF Election algorithm to be used. It is, howev= er, 451 possible that some PEs continue to use the existing modulo-based= DF 452 election and do not rely on the new SCT BGP extended community. = PEs 453 running a baseline DF election mechanism will simply discard the= new 454 SCT BGP extended community as unrecognized. 455 456 A PE can indicate its willingness to support clock-synched carvi= ng by 457 signaling the new 'T' DF Election Capability as well as includin= g the 458 new Service Carving Time BGP extended community along with the 459 Ethernet Segment Route (Type-4). In the case where one or more = PEs 460 attached to the Ethernet Segment do not signal T=3D1, all PEs in= the 461 Ethernet Segment SHALL revert back to the [RFC7432] timer approa= ch. 462 This is especially important in the context of the VLAN shufflin= g 463 with more than 2 PEs. I am not sure what the modulo-based df is? is that the rfc7432 procedure? I= t was the first time that this was mentioned in this draft i believe. what about following rewrite proposal for readability, but please add refer= ence for the modulo-based election: "For the DF election procedures to achieve global convergence and unanimity= within a redundancy group, it is essential that all participating PEs agre= e on the DF election algorithm to be employed. However, it is possible that= some PEs may continue to use the existing modulo-based DF election algorit= hm and not utilize the new Service Carving Time (SCT) BGP extended communit= y. PEs that operate using the baseline DF election mechanism will simply di= scard the new SCT BGP extended community as unrecognized. A PE can indicate its willingness to support clock-synchronized carving by = signaling the new 'T' DF Election Capability and including the new SCT BGP = extended community along with the Ethernet Segment Route (Type-4). If one o= r more PEs attached to the Ethernet Segment do not signal T=3D1, then all P= Es in the Ethernet Segment SHALL revert to the timer-based approach as spec= ified in [RFC7432]. This reversion is particularly crucial in preventing VL= AN shuffling when more than two PEs are involved" 465 5. Security Considerations The conditions for when the SCT is far away in the future, it was not entir= ely clear or spelled out what an implementation should do. Maybe make it mo= re explicite in the textual decscription as a normative reference using RFC= 2119 language _______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-leave@ietf.org --_000_AS1PR07MB858908A3B6F80BEDB2419012E0A42AS1PR07MB8589eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Luc Andr=E9, Authors & WG,

 

IETF LC for draft-ietf-bess-evpn-fas= t-df-recovery-09 has been requested.

Thanks for your patience.=

 

G/

 

 

 

 

From: = Luc Andr=E9 Burdet <laburdet.ietf@gmail.com>
Sent: Monday, July 8, 2024 11:42 PM
To: Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.com>= ;; draft-ietf-bess-evpn-fast-df-recovery@ietf.org
Cc: 'BESS' <bess@ietf.org>
Subject: Re: [Shepherding AD review] review of draft-ietf-bess-evpn-= fast-df-recovery-08

 

You don't often get email from laburdet.ietf@gmail.com. Learn why this is important

 

 

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

 

Hi G= unter, thanks for the thorough review and suggestions towards readability.<= o:p>

I ha= ve uploaded -09 incorporating most of your suggestions with the exception o= f very minor details:

Ex: = “largest (latest)” instead of s/largest/latest/... we’re = talking both values and time meaning both largest and latest make sense = 211; I just kept both terms.

 

Regards,

Luc Andr=E9

 

Luc Andr=E9 Burdet |  Cisco &nb= sp;|  laburdet.ietf@gmail.com  |  Tel: +1 613 254 4814

 

 

From: Gunt= er van de Velde (Nokia) <gunter.van_de_velde=3D40nokia.com@dmarc.ietf.org&g= t;
Date: Thursday, May 30, 2024 at 07:28
To: draft-ietf-bess-evpn-fast-df-recovery@ietf.org <dra= ft-ietf-bess-evpn-fast-df-recovery@ietf.org>
Cc: 'BESS' <bess@ietf.org>= ;
Subject: [bess] [Shepherding AD review] review of draft-ietf-bess-ev= pn-fast-df-recovery-08

# Gu= nter Van de Velde, RTG AD, comments for draft-ietf-bess-evpn-fast-df-recove= ry-08

Hi All,

Please find here a shepherding AD review of draft-ietf-bess-evpn-fast-df-re= covery-08

I'm sorry it took a bit of time to get started on this draft.

I've begun reviewing this document before we kick off the IETF Last Call pr= ocess. Once we address these points, we can move forward with the document = through the IESG chain.

A big thank you to Adrian Farrel for his RTG-DIR review on the -07 version,= which helped improve the document to its -08 version and to Matthew Bocci = for the Shepherds write-up (4 July 2022)

In my review, I've noted some final observations while going through the do= cument. For better readability, I've suggested some paragraph edits.

One thing I noticed is that there's not much RFC 2119-based normative langu= age used. Maybe the authors can take another look and add or update the RFC= 2119 text where needed.

You can find my review notes below.

#GENERIC COMMENTS
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

88         Virtualization Overlay (= NVO) and DC inte)rconnect (DCI) services, and

Typo with the ")"

100        multihomed Ethernet Segment.&= nbsp; This DF election is achieved
101        independent of the number of = EVPN Instances (EVIs) associated with
102        that Ethernet Segment and it = is performed via simple signaling
103        between the recovered node an= d each of the other nodes in the
104        multihomed group.

I believe that the word 'simple' is reasonable subjective. It may be better= to replace with a construct using 'straightforward'. Possible rewrite:

"This Designated Forwarder (DF) election is conducted independently of= the number of EVPN Instances (EVIs) associated with the Ethernet Segment a= nd is executed through straightforward signaling between the recovered node= and each of the other nodes in the multihomed group.
"

105        This document updates the sta= te machine described in Section 2.1 of

Being more explicit in what is updated could be better.

"This document updates the DF Election Finite State Machine (FSM) desc= ribed in Section 2.1 of"

131        In EVPN technology, multiple = Provider Edge (PE) devices have the
132        ability to encap and decap da= ta belonging to the same VLAN.  In

expand on encap and decap for better readability.

131        In EVPN technology, multiple = Provider Edge (PE) devices have the
132        ability to encap and decap da= ta belonging to the same VLAN.  In
133        certain situations, this may = cause L2 duplicates and even loops if
134        there is a momentary overlap = of forwarding roles between two or more
135        PE devices, leading to broadc= ast storms.

possible readability rewrite:
"In EVPN technology, multiple Provider Edge (PE) devices possess the c= apability to encapsulate and decapsulate data associated with the same VLAN= . Under certain conditions, this may result in Layer 2 duplicates and poten= tial loops if there is a temporary overlap in forwarding roles among two or more PE devices, consequently leading to = broadcast storms.
"
137        EVPN [RFC7432] currently uses= timer based synchronization among PE
138        devices in a redundancy group= that can result in duplications (and
139        even loops) because of multip= le DFs if the timer is too short or
140        packets being dropped if the = timer is too long.

RFC7432 is providing more a specification the using a timer. Hence a more e= xplicit text blob to document this property:

"EVPN [RFC7432] currently specifies timer-based synchronization among = PE devices within a redundancy group. This approach can lead to duplication= s and potential loops due to multiple Designated Forwarders (DFs) if the ti= mer interval is too short, or to packet drops if the timer interval is too long."

142        Using split-horizon filtering= (Section 8.3 of [RFC7432]) can prevent
143        loops (but not duplicates).&n= bsp; However, if there are overlapping DFs in
144        two different sites at the sa= me time for the same VLAN, the site
145        identifier will be different = upon the packet re-entering the Ethernet
146        Segment and hence the split-h= orizon check will fail, leading to L2
147        loops.

Strange grammatical construct and usage of "()". Potential rewrit= e to correct this assuming i kept the issue described correct:

"Employing split-horizon filtering, as described in Section 8.3 of [RF= C7432], can prevent loops but does not address duplicates. However, if ther= e are overlapping Designated Forwarders (DFs) at two different sites simult= aneously for the same VLAN, the site identifier will differ when the packet re-enters the Ethernet Segment. Con= sequently, the split-horizon check will fail, resulting in Layer 2 loops. "

149        The updated DF procedures in = [RFC8584] use the well known Highest
150        Random Weight (HRW) algorithm= to avoid reshuffling of VLANs among PE
151        devices in the redundancy gro= up upon failure/recovery.  This reduces
152        the impact to VLANs not assig= ned to the failed/recovered ports and
153        eliminates loops or duplicate= s at failure/recovery events.

Is there a reference that can be used for the well known HRW algorithm? What about the following rewrite proposal for readability:

"The updated Designated Forwarder (DF) procedures outlined in [RFC8584= ] utilize the well-known Highest Random Weight (HRW) algorithm to prevent t= he reshuffling of VLANs among PE devices within the redundancy group during= failure or recovery events. This approach minimizes the impact on VLANs not assigned to the failed or recovered port= s and eliminates the occurrence of loops or duplicates during such events.<= br> "

179        a given VLAN is possible.&nbs= p; Duplication of DF roles may eventually
180        lead to duplication of traffi= c as well as L2 loops.

in previous text the word 'overlap' was used while here the word Duplicatio= n of DF roles is used.

195        *  Complicated handshake= signamling mechanisms and state machines are
196           avoided in = favor of a simple uni-directional signaling approach.

s/Complicated/Complex/
s/signamling/signaling/

198        *  The solution is backw= ards-compatible (see Section 4), by PEs
199           simply disc= arding the unrecognized new BGP Extended Community.

I think that the "The solution" seems reasonable opaque descripti= on. Maybe we should explicit mention that this concerns the fast dr recover= y solution. I only noted this here as the first occurrence, but the more ex= plicit text can be used in multiple locations within the draft text.

What about:
"The fast df recovery solution maintains backwards compatibility (see = Section 4) by ensuring that PEs discard any unrecognized new BGP Extended C= ommunity."

201        *  Existing DF Election = algorithms are supported.

s/are/remain/

232        Upon receipt of that new BGP = Extended Community, partner PEs can
233        determine the service carving= time of the newly insterted PE.  The
234        notion of skew is introduced = to eliminate any potential duplicate
235        traffic or loops.  The r= eceiving partner PEs add a skew (default =3D
236        -10ms) to the Service Carving= Time to enforce this.  The previously
237        inserted PE(s) must carve fir= st, followed shortly (skew) by the newly
238        insterted PE.

I got thrown off-guard with the word skew as a non-native English speaker.<= br> Maybe a small explanation would be helpful. What about the following:

"Upon receipt of the new BGP Extended Community, partner PEs can deter= mine the service carving time of the newly inserted PE. To eliminate any po= tential for duplicate traffic or loops, the concept of skew-a small time de= lay added to the service carving process to ensure a controlled and orderly transition when multiple Provider Edge = (PE) devices are involved-is introduced. The receiving partner PEs add a sk= ew (default =3D -10ms) to the service carving time to enforce this mechanis= m. This ensures that the previously inserted PEs complete their carving process first, followed shortly therea= fter (by the specified skew) by the newly inserted PE.
"

240        To summarize, all peering PEs= carve almost simultaneously at the time
241        announced by the newly added/= recovered PE.  The newly inserted PE
242        initiates the SCT, and carves= immediately on its local timer expiry.
243        The previously inserted PE(s)= receiving Ethernet Segment route (RT-4)
244        with a SCT BGP extended commu= nity, carve shortly before Service
245        Carving Time.

This text provides me some confusion. The term "to carve" general= ly means to cut or shape something from a larger piece, often with precisio= n and care. Hence i was a bit surprised to see this used here.

May I assume that in the context of these network operations and specifical= ly within EVPN (Ethernet VPN) and MPLS (Multiprotocol Label Switching) envi= ronments, "to carve" typically refers to the process of determini= ng and establishing roles or responsibilities for forwarding traffic among Provider Edge (PE) devices?

If yes, maybe such text blob should be explicit mentioned somewhere in the = draft?

266        [RFC5905].  As the curre= nt NTP era value is not exchanged, a local
267        clock which is "synchron= ized" but to the wrong era is outside of the
268        scope of this document.

What is era value?

257            =             &nb= sp;    1        &nbs= p;          2   = ;            &n= bsp;   3
258         0 1 2 3 4 5 6 7 8 9 0 1= 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
259        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
260        | Type =3D 0x06   |= Sub-Type(0x0F)|      Timestamp Seconds  = ;      ~
261        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
262        ~  Timestamp Seconds&nbs= p;           | Timestamp = Fractional Seconds  |
263        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

a figure number/caption is missing.

269        The 64-bit timestamp of NTP c= onsists of a 32-bit part for seconds and
270        a 32-bit part for fractional = second:

There seems to be a 32bit/64bit and 128bt timestamp according:
https:= //datatracker.ietf.org/doc/html/rfc5905#section-6
Should description not align with all of these?

274        *  Timestamp Fractional = Seconds: the high order 16 bits of the NTP
275           fractional = seconds are encoded in this field.  The use of a 16-bit
276           fractional = seconds yields adequate precision of 15 microseconds
277           (2^-16 s).<= br>
I assume that the lower order 16 bits are assumed to be '0'? Maybe that sho= uld be explicit called out?

296        This capability is used in co= njunction with the agreed upon DF Type
297        (DF Election Type).  For= example if all the PEs in the Ethernet
298        Segment indicate having Time = Synchronization capability and are
299        requesting the DF type to be = HRW, then the HRW algorithm is used in
300        conjunction with this capabil= ity.

readability rewrite:
"This capability is utilized in conjunction with the agreed-upon Desig= nated Forwarder (DF) Type (DF Election Type). For instance, if all the PE d= evices in the Ethernet Segment indicate possessing Time Synchronization cap= ability and request the DF Type to be Highest Random Weight (HRW), then the HRW algorithm is employed in conjunc= tion with this capability.
"

Note, what happens if one of the involved PEs do not support Time synchroni= sation capability?

309        The peering PE's FSM in DF_DO= NE which receives a RECV_ES transitions
310        to DF_CALC.  Because of = the SCT carried in the Ethernet-Segment
311        update, the output of the DF_= CALC and transition back into DF_DONE
312        are delayed, as are accompany= ing forwarding updates to DF/NDF state.

This processes not so easy. I assume that all these are states of the FSM?<= br> Would the following be a correct rewrite for readability?

"Upon receiving a RECV_ES message, the peering PE's Finite State Machi= ne (FSM) transitions from the DF_DONE (indicating the DF election process w= as complete) state to the DF_CALC (indicating that a new DF calculation is = needed) state . Due to the Service Carving Time (SCT) included in the Ethernet-Segment update, the completion of the = DF_CALC state and the subsequent transition back to the DF_DONE state are d= elayed. This delay ensures proper synchronization and prevents conflicts. C= onsequently, the accompanying forwarding updates to the Designated Forwarder (DF) and Non-Designated Forwarder (NDF= ) states are also deferred.
"

314        The corresponding actions whe= n transitions are performed or states
315        are entered/exited is modifie= d as follows:
316
317        9.  DF_CALC on CALCULATE= D: Mark the election result for the VLAN or
318            Bundl= e.
319
320            9.1&n= bsp; Where SCT timestamp is present on the RECV_ES event of
321            =      Action 11, wait until the time indicated by the SC= T before
322            =      continuing to 9.2.
323
324            9.2&n= bsp; Assume a DF/NDF for the local PE for the VLAN or VLAN
325            =      Bundle, and transition to DF_DONE.

What about the following procedure text blob description for clarity:

"
The corresponding actions when transitions are performed or states are ente= red/exited are modified as follows:

9. DF_CALC on CALCULATED: Mark the election result for the VLAN or VLAN Bun= dle.

9.1. If an SCT timestamp is present during the RECV_ES event of Action 11, = wait until the time indicated by the SCT before proceeding to step 9.2.

9.2. Assume the role of DF or NDF for the local PE concerning the VLAN or V= LAN Bundle, and transition to the DF_DONE state.

This revised approach ensures proper timing and synchronization in the DF e= lection process, avoiding conflicts and ensuring accurate forwarding update= s.
"

329        Let's take Figure 1 as an exa= mple where initially PE2 had failed and
330        PE1 had taken over.  Thi= s example shows the problem with the
331        DF-Election mechanism in Sect= ion 8.5 of [RFC7432], using the value of
332        the timer configured for all = PEs on the Ethernet Segment.

To make the text more proposed standard style, what about this textblob for= readability:

"Consider Figure 1 as an example, where initially PE2 has failed and P= E1 has taken over. This scenario illustrates the problem with the DF-Electi= on mechanism described in Section 8.5 of [RFC7432], specifically in the con= text of the timer value configured for all PEs on the Ethernet Segment.
"

334        Based on Section 8.5 of [RFC7= 432] and using the default 3 second
335        timer in step 2:
337        1.  Initial state: PE1 i= s in steady-state, PE2 is recovering
339        2.  PE2 recovers at (abs= olute) time t=3D99
341        3.  PE2 advertises RT-4 = (sent at t=3D100) to partner PE1
343        4.  PE2 starts a 3 secon= d timer to allow the reception of RT-4 from
344            other= PE nodes
346        5.  PE1 carves immediate= ly on RT-4 reception, i.e. t=3D100 + minimal
347            BGP p= ropagation delay
349        6.  PE2 carves at time t= =3D103
350
351        [RFC7432] aims of favouring t= raffic being dropped over duplicate
352        traffic.  With the above= procedure, traffic drops will occur as part
353        of each PE recovery sequence = since PE1 has transitioned some VLANs to
354        Non-Designated-Forwarder (NDF= ) immediately upon reception.
355        The timer value (default =3D = 3 seconds) has a direct effect on the
356        duration of the packets being= dropped.  A shorter (especially zero)
357        timer may, however, result in= duplicate traffic or traffic loops.

What about:

"Procedure Based on Section 8.5 of [RFC7432] with Default 3-Second Tim= er:
1. Initial State: PE1 is in a steady state, and PE2 is recovering.
2. Recovery: PE2 recovers at an absolute time of t=3D99.
3. Advertisement: PE2 advertises RT-4, sent at t=3D100, to partner PE1.
4. Timer Start: PE2 starts a 3-second timer to allow the reception of RT-4 = from other PE nodes.
5. Immediate Carving: PE1 carves immediately upon RT-4 reception, i.e., t= =3D100 plus minimal BGP propagation delay.
6. Delayed Carving: PE2 carves at time t=3D103.

[RFC7432] favors traffic drops over duplicate traffic. With the above proce= dure, traffic drops will occur as part of each PE recovery sequence since P= E1 transitions some VLANs to Non-Designated Forwarder (NDF) immediately upo= n RT-4 reception. The timer value (default =3D 3 seconds) directly affects the duration of the packet drops.= A shorter (or zero) timer may result in duplicate traffic or traffic loops= .
"

359        Based on the Service Carving = Time (SCT) approach:
361        1.  Initial state: PE1 i= s in steady-state, PE2 is recovering
363        2.  PE2 recovers at (abs= olute) time t=3D99
365        3.  PE2 advertises RT-4 = (sent at t=3D100) with target SCT value t=3D103
366            to pa= rtner PE1
368        4.  PE2 starts a 3 secon= d timer to allow the reception of RT-4 from
369            other= PE nodes
371        5.  PE1 starts service c= arving timer, with remaining time until t=3D103
373        6.  Both PE1 and PE2 car= ve at (absolute) time t=3D103
374        In fact, PE1 should carve sli= ghtly before PE2 (skew) to maintain the
375        preference of minimal loss ov= er duplicate traffic.  The previously
376        inserted PE2 that is recoveri= ng performs both transitions DF to NDF
377        and NDF to DF per VLANs at th= e timer's expiry.  Since the goal is to
378        prevent duplicates, the origi= nal PE1, which received the SCT will
379        apply:
381        *  DF to NDF transition = at t=3DSCT minus skew, where both PEs are NDF
382           for 'skew' = amount of time
384        *  NDF to DF transition = at t=3DSCT
385
386        It is this split-behaviour wh= ich ensures a good transition of DF role
387        with contained amount of loss= .
388
389        Using SCT approach, the negat= ive effect of the timer to allow the
390        reception of RT-4 from other = PE nodes is mitigated.  Furthermore, the
391        BGP Ethernet Segment route (R= T-4) transmission delay (from PE2 to
392        PE1) becomes a non-issue.&nbs= p; The use of SCT approach remedies the
393        problem associated with this = timer: the 3 second timer window is
394        shortened to the order of mil= liseconds.

What about the following textblobs for readability:

"Procedure Based on the Service Carving Time (SCT) Approach:
1. Initial State: PE1 is in a steady state, and PE2 is recovering.
2. Recovery: PE2 recovers at an absolute time of t=3D99.
3. Advertisement: PE2 advertises RT-4, sent at t=3D100, with a target SCT v= alue of t=3D103 to partner PE1.
4. Timer Start: PE2 starts a 3-second timer to allow the reception of RT-4 = from other PE nodes.
5. Service Carving Timer: PE1 starts the service carving timer, with the re= maining time until t=3D103.
6. Simultaneous Carving: Both PE1 and PE2 carve at an absolute time of t=3D= 103.

To maintain the preference for minimal loss over duplicate traffic, PE1 sho= uld carve slightly before PE2 (with skew). The recovering PE2 performs both= DF to NDF and NDF to DF transitions per VLAN at the timer's expiry. The or= iginal PE1, which received the SCT, applies the following:

* DF to NDF Transition: At t=3DSCT minus skew, where both PEs are NDF for t= he skew duration.
* NDF to DF Transition: At t=3DSCT.

This split-behavior ensures a smooth DF role transition with minimal loss.<= br>
Using the SCT approach, the negative effect of the timer to allow the recep= tion of RT-4 from other PE nodes is mitigated. Furthermore, the BGP Etherne= t Segment route (RT-4) transmission delay (from PE2 to PE1) becomes a non-i= ssue. The SCT approach shortens the 3-second timer window to the order of milliseconds, addressing the ass= ociated problems.
"

396     3.1.  Concurrent Recoveries

This section seems to be missing RFC2119 language on how nodes need to beha= ve with respect the procedures outlined in this document.

402        Election.  A similar sit= uation arises in staggered recovering PEs,
403        when a second PE recovers at = rougly a first PE's advertised SCT
404        expiry, and with its own new = SCT-2 outside of the initial SCT window.

The word staggered is oddly used. What about the following:

"A similar situation arises in sequentially recovering PEs, when a sec= ond PE recovers approximately at the time of the first PE's advertised SCT = expiry, and with its own new SCT-2 outside of the initial SCT window."=

406        In the case of multiple outst= anding DF elections, one requested by
407        each of the recovering PEs, t= he SCTs must simply be time-ordered and
408        all PEs execute only a single= DF Election at the service carving time
409        corresponding to the largest = received timestamp value.  The DF
410        Election will involve all the= active PEs in a single DF Election
411        update.

To add to a similar edited writing style:
"In the case of multiple concurrent DF elections, each initiated by on= e of the recovering PEs, the SCTs must be ordered chronologically. All PEs = shall execute only a single DF Election at the service carving time corresp= onding to the latest received timestamp value. This DF Election will involve all active PEs in a unified DF Electi= on update.
"

However, it may require some formal RFC2119 language to make sure that impl= ementations behave according this procedure

413        Example:
415        1.  Initial state: PE1 i= s in steady-state, all services elected at
416            PE1.<= br> 418        2.  PE2 recovers at time= t=3D100, advertises RT-4 with target SCT value
419            t=3D1= 03 to partners (PE1)
421        3.  PE2 starts a 3 secon= d timer to allow the reception of RT-4 from
422            other= PE nodes
424        4.  PE1 starts service c= arving timer, with remaining time until t=3D103
426        5.  PE3 recovers at time= t=3D102, advertises RT-4 with target SCT value
427            t=3D1= 05 to partners (PE1, PE2)
429        6.  PE3 starts a 3 secon= d timer to allow the reception of RT-4 from
430            other= PE nodes
432        7.  PE2 cancels the runn= ing timer, starts service carving timer with
433            remai= ning time until t=3D105
435        8.  PE1 updates service = carving timer, with remaining time until
436            t=3D1= 05
438        9.  PE1, PE2 and PE3 car= ve at (absolute) time t=3D105

Example:
1. Initial State: PE1 is in a steady state, with all services elected at PE= 1.
2. Recovery of PE2: PE2 recovers at time t=3D100 and advertises RT-4 with a= target SCT value of t=3D103 to its partners (PE1).
3. Timer Initiation by PE2: PE2 starts a 3-second timer to allow the recept= ion of RT-4 from other PE nodes.
4. Timer Initiation by PE1: PE1 starts the service carving timer, with the = remaining time until t=3D103.
5. Recovery of PE3: PE3 recovers at time t=3D102 and advertises RT-4 with a= target SCT value of t=3D105 to its partners (PE1, PE2).
6. Timer Initiation by PE3: PE3 starts a 3-second timer to allow the recept= ion of RT-4 from other PE nodes.
7. Timer Update by PE2: PE2 cancels the running timer and starts the servic= e carving timer with the remaining time until t=3D105.
8. Timer Update by PE1: PE1 updates its service carving timer, with the rem= aining time until t=3D105.
9. Service Carving: PE1, PE2, and PE3 perform service carving at the absolu= te time of t=3D105.

446     4.  Backwards Compatibility
447
448        Per redundancy group, for the= DF election procedures to be globally
449        convergent and unanimous, it = is necessary that all the participating
450        PEs agree on the DF Election = algorithm to be used.  It is, however,
451        possible that some PEs contin= ue to use the existing modulo-based DF
452        election and do not rely on t= he new SCT BGP extended community.  PEs
453        running a baseline DF electio= n mechanism will simply discard the new
454        SCT BGP extended community as= unrecognized.
455
456        A PE can indicate its willing= ness to support clock-synched carving by
457        signaling the new 'T' DF Elec= tion Capability as well as including the
458        new Service Carving Time BGP = extended community along with the
459        Ethernet Segment Route (Type-= 4).  In the case where one or more PEs
460        attached to the Ethernet Segm= ent do not signal T=3D1, all PEs in the
461        Ethernet Segment SHALL revert= back to the [RFC7432] timer approach.
462        This is especially important = in the context of the VLAN shuffling
463        with more than 2 PEs.

I am not sure what the modulo-based df is? is that the rfc7432 procedure? I= t was the first time that this was mentioned in this draft i believe.

what about following rewrite proposal for readability, but please add refer= ence for the modulo-based election:

"For the DF election procedures to achieve global convergence and unan= imity within a redundancy group, it is essential that all participating PEs= agree on the DF election algorithm to be employed. However, it is possible= that some PEs may continue to use the existing modulo-based DF election algorithm and not utilize the new Servic= e Carving Time (SCT) BGP extended community. PEs that operate using the bas= eline DF election mechanism will simply discard the new SCT BGP extended co= mmunity as unrecognized.

A PE can indicate its willingness to support clock-synchronized carving by = signaling the new 'T' DF Election Capability and including the new SCT BGP = extended community along with the Ethernet Segment Route (Type-4). If one o= r more PEs attached to the Ethernet Segment do not signal T=3D1, then all PEs in the Ethernet Segment SHALL re= vert to the timer-based approach as specified in [RFC7432]. This reversion = is particularly crucial in preventing VLAN shuffling when more than two PEs= are involved"

465     5.  Security Considerations

The conditions for when the SCT is far away in the future, it was not entir= ely clear or spelled out what an implementation should do. Maybe make it mo= re explicite in the textual decscription as a normative reference using RFC= 2119 language



_______________________________________________
BESS mailing list -- bess@ietf.org=
To unsubscribe send an email to bes= s-leave@ietf.org

--_000_AS1PR07MB858908A3B6F80BEDB2419012E0A42AS1PR07MB8589eurp_--