Return-Path: X-Original-To: int-dir@ietfa.amsl.com Delivered-To: int-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22327C16940D; Thu, 2 Jan 2025 16:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-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 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 0v8mcu5cWMCd; Thu, 2 Jan 2025 16:57:02 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2094.outbound.protection.outlook.com [40.107.243.94]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7F3C1654F2; Thu, 2 Jan 2025 16:57:01 -0800 (PST) ARC-Seal: i=3; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=wKtIWYf9PtgnSLduZjKS6394PqY8OAgphG2BCwpN+1gchG9QWZ1CBALnOGUJEeKB2RS3InL2aP2XAh3TA6G22Ft5XdewCsc+MppDFhAWrRGsR0gHbz09Wk2IjJ05cMu32jhT8UdOBn+QMW+mF+xHiSk9CGv2g7jjy1C0pTamAUYlvYRxLb2qOLn//+jimv2GErJ/4nm6ulmTos8tWpq9ckBQyGLpGpGIEXedsUhwIPjN4u2vmOcWmwmWqZTA22O/G5VD4Z99Os3DH+F4MYnus1uyikbiUe0+oXP6XwJyXJAK+gajCNJUj2JWH9X3GPkkTumKaGf2ZMBT2CbiH9pQ3A== ARC-Message-Signature: i=3; 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=MRLZ3xQ7ARwQPVzXuorZGfrWb486Gauncc4HREMtlCc=; b=kVbaqZHMtXvutiB9sqAsAAVs26UC5Lh+eXNPKaEgyVa5iS/NlAWbWc+FXV0dwhwwsP0ILJ28Jtjm/qUUfQRpyiaay36Bwb9BwlIAsAYE6guE4zClW9sq6B97WTDiM12+XKC+lC5wsbnd8ltNpnDrME7gU0BN/IBl4i10IUTSG0CIiOKK8mVlg8UfTyEezS7+T1Wdb3MGT3M6zPuRkHmH0s00BALNz99yL7F3QruajWPkYHamr6UMEa2CrhBmAqFo3YW11Vw30rTuqVTbJTan40Dje3fq5Fha7cezS+TCgUf5cXyq280n4qYZlZ2LLmLklHPMiK+dS5cdYmlfUlUDcA== ARC-Authentication-Results: i=3; mx.microsoft.com 1; spf=pass (sender ip is 104.47.66.47) smtp.rcpttodomain=aft.network smtp.mailfrom=ndzh.com; dmarc=bestguesspass action=none header.from=ndzh.com; dkim=none (message not signed); arc=pass (0 oda=0 ltdi=0 93) Received: from BN9PR03CA0335.namprd03.prod.outlook.com (2603:10b6:408:f6::10) by MW5PR08MB8359.namprd08.prod.outlook.com (2603:10b6:303:1c7::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.11; Fri, 3 Jan 2025 00:56:54 +0000 Received: from MN1PEPF0000ECD9.namprd02.prod.outlook.com (2603:10b6:408:f6:cafe::7c) by BN9PR03CA0335.outlook.office365.com (2603:10b6:408:f6::10) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8314.12 via Frontend Transport; Fri, 3 Jan 2025 00:56:53 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 104.47.66.47) smtp.mailfrom=ndzh.com; dkim=none (message not signed) header.d=none;dmarc=bestguesspass action=none header.from=ndzh.com; Received-SPF: Pass (protection.outlook.com: domain of ndzh.com designates 104.47.66.47 as permitted sender) receiver=protection.outlook.com; client-ip=104.47.66.47; helo=NAM12-MW2-obe.outbound.protection.outlook.com; pr=C Received: from obx-outbound.inkyphishfence.com (35.166.188.152) by MN1PEPF0000ECD9.mail.protection.outlook.com (10.167.242.138) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8314.11 via Frontend Transport; Fri, 3 Jan 2025 00:56:52 +0000 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=inkyphishfence.com; s=arc-20181011; t=1735865811; h=mime-version : message-id : date : subject : to : from; bh=MRLZ3xQ7ARwQPVzXuorZGfrWb486Gauncc4HREMtlCc=; b=ws130YbH++XzcVHTKG0ntIiq+Iu0FI3XApu/vrYHTPA5IY+2bKHj3flocUNgHRAUm7TaS t48h4IbWw/rRpJ4CefUvhRvqSHkQxrcxczLy1VdbUkORfoKlqI405DDgWu7NDPCYcB7+4xl lP97cgq0GUX5lL/vTOj4LeQUveIKEvE= ARC-Authentication-Results: i=2; obx-inbound.inkyphishfence.com; spf=pass smtp.mailfrom=ndzh.com; dmarc=pass header.from=ndzh.com; dkim=pass header.d=ndzh.com; arc=pass ARC-Seal: i=2; cv=pass; a=rsa-sha256; d=inkyphishfence.com; s=arc-20181011; t=1735865811; b=h3XK+G5cNRi1RxGOb6CGoOc4HWrpilGLG+eV8Dn9HPhZKMfl9Y89bIwGXq3gvjMJWbMox d4usJKTihYHyxYQIBY+j6gi0guAc1PHB51OPyohp9b+j+ZNfTgRgHxLBkGzQOxfuv9ZbhcH pZwGXZTwSep5IL7YJoCxZUcObg6kbls= Authentication-Results-Original: obx-inbound.inkyphishfence.com; spf=pass smtp.mailfrom=ndzh.com; dmarc=pass header.from=ndzh.com; dkim=pass header.d=ndzh.com; arc=pass Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2047.outbound.protection.outlook.com [104.47.66.47]) by obx-inbound.inkyphishfence.com (Postfix) with ESMTPS id 3A423C9F2B; Fri, 3 Jan 2025 00:56:51 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ppph26h4iAvBGvpfjFJF5spX0Z/7bqQmBiCot6A7EYn/IrwQZjtt3NfxRBM6k8gQZdjf4cY52OI3FLwKhzabTwi0fgyBt50o2rtJfvlTfmplfLtGAZTFKGKEAZumVKmda9gbcYNfHmY3zhB84dKJsxyicWyoymH0u4VIoH0f7NDTNtO5Eo+qrbagVZlDXlkFeND528oO1fcxXS6cYvtjQN2xcTA6dzSNesNtXsofpQbIkGN8PlWPcj3N2NxsZ8mM27gWZwMhC3qjuOJlfzs/RljYTYfl2KxcqhC8lV7uORhLftYFipsNE0olfuQJ3ihaCvRuNw5KWJUQD8AWk3/dBQ== 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=9SZbP5ZNhydWOxSSJUAr6XWVcp27Qgo2/06D+lUYk8c=; b=oUVgas+mS0V88+VCi5vQpi3QQFyejU/VltxcsnOjNqW3KKe9TyCpeLp5ajydQo9HZ0zm1tKqjRUdu6/qizYoom6L3zzdHQgpKQeTnyAw4KupojhyhT+Pcv0jgrRhH2KJy/T5ySufjkfxyDto6dhOoD00a74LJAEVUlRfQgkqnZ7vegqH8e5UgziRTDsNa8T4vvvYQNyh++AzkCmnTs3dF/NqodNY37MuBm9b73O6gU08DokRyjAEYfcnmAqf6COxPU+Vqb1WpQGAlN8AmcjDRD3PGHPvlqc+fZLjWYu1FcnXl6fXn/QaqG3EuEq18rZIamv0ys6KaNmhSNp2ZVz6PQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ndzh.com; dmarc=pass action=none header.from=ndzh.com; dkim=pass header.d=ndzh.com; arc=none Received: from CO1PR08MB6611.namprd08.prod.outlook.com (2603:10b6:303:98::12) by DS7PR08MB10580.namprd08.prod.outlook.com (2603:10b6:8:251::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8314.13; Fri, 3 Jan 2025 00:56:43 +0000 Received: from CO1PR08MB6611.namprd08.prod.outlook.com ([fe80::7744:8abd:9769:c2bf]) by CO1PR08MB6611.namprd08.prod.outlook.com ([fe80::7744:8abd:9769:c2bf%7]) with mapi id 15.20.8314.013; Fri, 3 Jan 2025 00:56:43 +0000 From: Susan Hares To: Antoine FRESSANCOURT , Antoine Fressancourt , "int-dir@ietf.org" Thread-Topic: Intdir early review of draft-ietf-idr-sdwan-edge-discovery-17 Thread-Index: AQHbKrQkaJ7NEvvLt0mbj6ny48K+zrK5Rf0AgAclkYCARBFvcA== Date: Fri, 3 Jan 2025 00:56:43 +0000 Message-ID: References: <173028310233.76447.9399728875049130196@dt-datatracker-84cf84bdcc-xfz57> <6dc163bd21a2454191144bc4733f97fd@huawei.com> In-Reply-To: <6dc163bd21a2454191144bc4733f97fd@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ndzh.com; x-ms-traffictypediagnostic: CO1PR08MB6611:EE_|DS7PR08MB10580:EE_|MN1PEPF0000ECD9:EE_|MW5PR08MB8359:EE_ X-MS-Office365-Filtering-Correlation-Id: 3d0ab6a6-a55c-4fc0-4f9e-08dd2b91834e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|10070799003|1800799024|376014|366016|8096899003|38070700018; X-Microsoft-Antispam-Message-Info-Original: =?us-ascii?Q?WNMuzOj/9rPH9aeVbz+BgpbIE70A9iAWSAKgpQ2z8mT7MqdkY7hk2yTQ7wtJ?= =?us-ascii?Q?3LKcMxOuPNqdLtr4fMRepKJY/2PKo+kuHhbYPh9E4T3EhqUGtg/vYcMISlXc?= =?us-ascii?Q?WmbcwjgKWWng9KfYl2A8/OD5wn5APS+18i4mVsQdxyQSuGRbsc6hNP/vHyKl?= =?us-ascii?Q?a0UVUervsiVl5uTtbVHimHa7HgkfFm2E7ponvBkXt/yMDWU500p9fSNLJejY?= =?us-ascii?Q?Dlg7bZfYoNSxwrP2Yt3UH9Wsvkr1VQjb54hYgeH3wZrH4m3XWdUHPF1m2kVx?= =?us-ascii?Q?MAWk7ropGP79UugSdR1kGsqdWeI/M9pjU2ueTbuTTgXCm/vorgZFOTgOkk8g?= =?us-ascii?Q?EfI310ULqLexS2p10G7mYlJYVDKqie/C1EbSj+NFquPceeBueq2UQ3O3lU9o?= =?us-ascii?Q?rikmWX/KPfeBP13YFX1MdCRC6zj0FKmPcBepAJ9ueMulRxr/QLLhOYwoEATv?= =?us-ascii?Q?A6758IcFfR52aMHAg3z75LMzJFaH4erpC0ChYYinFNsIKQjnnnVmzBwCKU4g?= =?us-ascii?Q?rQVJ5FbAn8S1cHmkBWRqeyIrhDsG+5mgVZLyTKEZigW2hGPqwNzyTkL8vPeT?= =?us-ascii?Q?InE4AbOyv0aVr+AaVAhjYEPBVTOj1ouu0FS3fN/UN19+y/S3/2NFW2/EVtm+?= =?us-ascii?Q?Te6HA4TrxSM2oSbAC6t++87qd2N1TqaQQL+RhOs9KzM9+2CO9AWvVXP446pu?= =?us-ascii?Q?whVHwMDHzla93MFf6BQzhFdnFBuYKUEowmeXtgDNOJ4ocb8QyaxCRpEs5zt5?= =?us-ascii?Q?2GqDlafVgUoE8PctxO1g/df1QdqaAhQ7oE66pngC14Op//zc2BHhf3/bfiGy?= =?us-ascii?Q?jmC0YlrFtlAgZE4Jnzp7ZyXiLdPR+4J5BOwi1fZ8s2mDkbqWeQjC3hiy+kB1?= =?us-ascii?Q?GSq8WjWD/k9RhmCKtj3pS1Kcl1KDi0Tja1q+nXwQxPc67uhsa9oDG+c6wDYg?= =?us-ascii?Q?BterrEsd6z1MGJdVJOm/b5N8nzN+zxZUW+5icWoUZAYui0WuMiNYzH6cOmWp?= =?us-ascii?Q?vvek+GXAF7hSm3JiAGRb5Phv+oYQjkWT4dCfJKWqEcnnbRuO8sXs5OqYqdTh?= =?us-ascii?Q?nplIQzx+A8RfNQ6B4V1BjmX7nXyvOub75uyaIL6WMwegKJYZ97rKHJUGtA5/?= =?us-ascii?Q?6p+utufhwk038u74wEHh+FjLLFMnOTQmVlEjbFgJ6oSNGE0X5Ii66dKkfBw+?= =?us-ascii?Q?9lVuelqqePDCCpAOG0lnCstN5w3FlR/sFb9g/6Ef637Pd+bos2d5km1WqgK9?= =?us-ascii?Q?AzdU9rFlvKYwaVjmYfsRlccSB03DlPLQWT2V1fORdVfzgbei08fUtlP2d8ZD?= =?us-ascii?Q?/RQOVMcvA4CQTkZu+SlU3Na6vwoF+nflKaucuPwhHKZjb/0/7ke7giYQVCPu?= =?us-ascii?Q?X5RR/F5K/7G1b82YnVj4MSk9+h7nTXFQlhRZ2EUmznJ7cqP6iiSWAuM3xn14?= =?us-ascii?Q?RBQfui6Kf+85v7GCfojNrLx/rKHgQNyx?= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CO1PR08MB6611.namprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(10070799003)(1800799024)(376014)(366016)(8096899003)(38070700018);DIR:OUT;SFP:1102; Content-Type: multipart/alternative; boundary="_000_CO1PR08MB6611203528378729D788CE97B3152CO1PR08MB6611namp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS7PR08MB10580 X-Inky-Outbound-Processed: True X-EOPAttributedMessage: 0 X-MS-Exchange-SkipListedInternetSender: ip=[104.47.66.47];domain=NAM12-MW2-obe.outbound.protection.outlook.com X-MS-Exchange-ExternalOriginalInternetSender: ip=[104.47.66.47];domain=NAM12-MW2-obe.outbound.protection.outlook.com X-MS-Exchange-Transport-CrossTenantHeadersStripped: MN1PEPF0000ECD9.namprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 1b00e607-c4b7-42a9-0ef4-08dd2b917d8e X-IPW-GroupMember: False X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|1800799024|14060799003|36860700013|156008|82310400026|35042699022|8096899003; X-Microsoft-Antispam-Message-Info: GmJFS8HTLGofA8gN4RkOQfXYnv/ZM0nUflURQ6xbbhtEsX1qjrK1y+XHV94x+D455DaelyS8tJqUZhq1iv0xJvxl01m1qUtUh1t7zbVm1zVwBE7xI4VvZTriuBfuhUxBicQGKDXfOTxGspaD9jFcJYPxOwql0Pr3m04d1HY6Fa8DF9cQcmH15Zv9wHsizmXDx4Sjt5acpBGO+dPYbyoUDpsWVrpvTvcFw+BmbdOp349e7gEa8YduFT0enBtd54IY1tJ+KsdrGrZLJNysxDxCvNK3UWhMxm/Ov7P3uS7vW2aTVJB2eZqBws/WJ4f4Hjr8tLW9whSEwzStKK3Ok8ApeKzK0UnH42DnZax7nx3yEo/JJ8IN65xIOvInwjELQuJwaPh0U6BGo5/wGiYGUnG5IdVBSV4zky+vZIQbq3dBMyvUk5jNVg81C7Ja46aLzLRWKzmF46ufDfo5p3A6KkRCiVE8z2aq4vop5pv/9Ic7ZWOk2TNeI4BKGX9IE9F/yC2EKMPOvgr1KX8PFgJ6U0JlH+S0pq7U9PMIbttZRP8KyteDa6NxC5o8UeAZIcG4YogW2BQFTggu7a518t+YboNDmDB6jRh2Dlx7Xydew/VrRg0ejvFY2tfkY/oRSxcwxJxC+rjM61rNvNczpFAJzmtVbfDBXXddZcefoZ2uCYPmL1YQCY/3oT6LdbhKXgA/NsPhdLt047zksN3D3JDmr7uFX+VULGW1mUvc7R9iAGgObqRaemwFZmXXGt2fVEZ5NqtvjkWA3Ra9ZuIUTPa5VKje705DroiQ3amS2aI//1VkYro= X-Forefront-Antispam-Report: CIP:35.166.188.152;CTRY:US;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:NAM12-MW2-obe.outbound.protection.outlook.com;PTR:mail-mw2nam12lp2047.outbound.protection.outlook.com;CAT:NONE;SFS:(13230040)(376014)(1800799024)(14060799003)(36860700013)(156008)(82310400026)(35042699022)(8096899003);DIR:OUT;SFP:1102; X-OriginatorOrg: ndzh.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jan 2025 00:56:52.7647 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3d0ab6a6-a55c-4fc0-4f9e-08dd2b91834e X-MS-Exchange-CrossTenant-Id: d6c573f1-34ce-4e5a-8411-94cc752db3e5 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d6c573f1-34ce-4e5a-8411-94cc752db3e5;Ip=[35.166.188.152];Helo=[obx-outbound.inkyphishfence.com] X-MS-Exchange-CrossTenant-AuthSource: MN1PEPF0000ECD9.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR08MB8359 Message-ID-Hash: P7Y3QNGBU5NCNBECHV5FWMFDWKLIVD4F X-Message-ID-Hash: P7Y3QNGBU5NCNBECHV5FWMFDWKLIVD4F X-MailFrom: shares@ndzh.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-int-dir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "draft-ietf-idr-sdwan-edge-discovery.all@ietf.org" , "idr@ietf.org" , John Scudder X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BInt-dir=5D_Re=3A_Intdir_early_review_of_draft-ietf-idr-sdwan-ed?= =?utf-8?q?ge-discovery-17?= List-Id: "This list is for discussion between the members of the Internet Area directorate." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --_000_CO1PR08MB6611203528378729D788CE97B3152CO1PR08MB6611namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Antoine: I want to thank you again for your detailed review. It helped me decide to= rewrite the document instead of limping along with the fractured text. You should find -19 at: https://datatracker.ietf.org/doc/draft-ietf-idr-sdwan-edge-discovery/ Some clean-up issues for the RTG-DIR require -20, so I'd like your feedback= on the rewrite. Your DISCUSS level issues and Technical questions are l= isted below. See [Sue-3] for answers. I plan to add the following if you approved: 1. definition of authorized BGP peers in section 1.3 (see DISCUSS-2) 2. Some comment that underscores that this implementation is only for wa= lled gardens (see DISCUSS-5) I also tried to edit the NITs, but I missed the following NITS. These will= be addressed in -20. 1. Encaps-EC - should be Encap-EC 2. * In page 14, section 5.4, "the" is missing in "An SD-WAN VPN ID is s= ame as a client VPN...". - missed 3. * In page 14, section 6, a verb is missing in "The hybrid SD-WAN unde= rlay tunnel UPDATE is to advertise the detailed..." - missed 4. 3rd paragraph in section 11 (Security Considerations) - noted as your= page 34, section 11 I've released a -19 with the rewrite, but there are open issues: 1. RTG-DIR open issues - that need feedback from implementers. Section 3.2.2 - There are open issues regarding the interaction between BGP= Update Next Hop, Tunnel Encapsulation Egress Endpoint, and the SD-WAN-Node= ID. Due to IDR's rule about implementations, I need to check with the implement= ers to see what checks are implemented. At a high level, the BGP Peer orig= inating should be the BGP Update Next Hop for the Update message and the SD= -WAN-Node ID. The Tunnel Egress must be loosely associated with the Port-= Local-ID. Section 3.2 or 3.2.3 - I need to indicate what optional BGP attributes can = be associated with the SD-WAN Underly NLRI. 1. SEC-DIR - I need to add 2 new abbreviations (IPsec SA and SA) plus a = pointer in the Security considerations. 2. OPS-DIR - No additional fixes. Sue From: Antoine FRESSANCOURT Sent: Wednesday, November 20, 2024 10:26 AM To: Susan Hares ; Antoine Fressancourt ; int-dir@ietf.org Cc: draft-ietf-idr-sdwan-edge-discovery.all@ietf.org; idr@ietf.org; John Sc= udder Subject: RE: Intdir early review of draft-ietf-idr-sdwan-edge-discovery-17 Hello, Thanks for your answers to the comments I made in the review of the = document. I will answer some requests for clarification and discuss some of= your answers inline with the text of your previou External (antoine.fressancourt=3D40huawei.com@dmarc.ietf.org) Report This Email FAQ GoDaddy Advanced Email Security, Powered by INKY Hello, Thanks for your answers to the comments I made in the review of the documen= t. I will answer some requests for clarification and discuss some of your answ= ers inline with the text of your previous message. My comments and answers = are prefixed with [AFT]. I stripped some text that was not necessary to und= erstand the discussion from this answer. Best regards, -- Antoine [....] [Discuss-1] * In section 3.3.1, two types of encoding for the Client Route UPDATE messa= ges are given, "Barebones" and Tunnel Encaps Attribute, while they are desc= ribed only in section 5. [Sue:] RFC9012 defines two forms of a Tunnel Encapsulation attribute: 1: An Extended Community with just the Tunnel ID defined in RFC9012 as "Bar= ebones", 2: a Tunnel Encapsulation Attribute. So, are you asking for these definitions to be reiterated in the definition= s? [AFT] In the text, I think that the one paragraph description that basically stat= es what you write in your answer should be placed before the first use or p= resentation of BGP messages using either encoding. A more detailed descript= ion can be avoided with a reference to RFC 9012, but for the sake of clarit= y, I think positioning this simplified definition before section 3.3.1 is b= etter. [Sue-3]: I have placed additional text on page 17 (pdf) in the section 3.1 = in the heading "Encoding:". Is this enough? [Discuss-2] * In section 3.4, the behavior of the RR mentions authorized BGP peers, but= the document does not give an idea about where and how those authorized BG= P peers are set. [Sue:] Most BGP drafts concerning RR authorized peers assume local configu= ration specifies 1. peer address, and b) some secure link. Are you askin= g that "authorized BGP peers" be defined prior to the use of the term in se= ction 3.4. [AFT] Providing the explanation you give as an answer to this point in the text w= ould make the text clearer in my view. Besides, if this behavior is clearly= explained in another document, I think it would be interesting to point to= this document as an informative reference. [Sue-3]: Section 1.0 has been rewritten to reestablish the link from draft= -ietf-idr-sdwan-edge-discovery-19 to draft-ietf-bess-sdwan-usage. Section 2.2 has been rewritten to provide the high-level logical example of= the mechanisms. Within section 2.2, section 2.2.3 paragraph 2 indicates th= at existing BGP Update mechanism control how RRs distribute routes. Sectio= n 2.2.4, provides a logical example where we state "RR Policy". Section 2.= 6 applies this to SD-WAN segmentation. These descriptions come before the = mechanisms in section 3. Should I add the term "authorized BGP peers" in = the definitions. What do you think? [Discuss-3] * In section 4.2, the text mentions that the RR speaks to the BGP clients = over IPSec while section 3.4 mentions a secure transport session (e.g. TLS) Sue: BGP works over Transport layer. Contrary to the actual specification = many implementations use TLS or TCP over IP-SEC or other means of securing= the text. Would adding this level of detail to section 3.4 resolve this "= DISCUSS" level issue? Or are you looking for something else? [AFT] My remark stems from an inconsistency between the text in sections 3.4 and = 4.2. For the sake of clarifying, I think that you should clearly state the = assumptions you are making about the security and integrity of the channel = you are using to convey the BGP messages, and point to the documents descri= bing the secure transport mechanisms you would use. [Sue-3:] Section 1.0, paragraph 2 states the assumption of a secure connect= ion between RR and each BGP Peer supporting SD-WAN. This paragraph states = the establishment of the secure channel is outside the scope of the documen= t. Section 2-4 have been rewritten into a single section (section 2) and = references to MEF[70.1], MEF[70.2], and draft-ietf-bess-sdwan-usage-25. In= section 2, Figures 2 and 3 reiterate that the BGP connections to the RR ar= e over secure links or secure transports. In the new section 2, sections = 2.2.3 and 2.6 try to resolve the RR secure transport. ---- [Discuss-4] * In section 8, the text refers to the IPSec-SA-ID, and assumes it has been= set but very little details are given in the document as to how this ID is= set, negotiated or provisioned in the IPSec SA endpoints. References are m= ade to other RFCs, but the text would benefit from a description of the mec= hanism the authors are considering using. [Sue-2] First of all, BGP is not setting up the IPsec tunnel. It is only= passing parameters so the tunnel can be set-up. Second, if it is helpful= to provide a description of the mechanism, it can be added. However, it s= eems you have something in mind. Would you mind providing 4 bullet points = on what you'd like added. [AFT] The only thing I have in mind is the objective to make the document's text = clear enough to allow implementers to develop interoperable implementations [Sue-3]: All section relating to IPsec SA SubTLVs have been reformatted wi= th a new format that I am proposing (as IDR co-chair) for all BGP Tunnel-en= capsulation Attributes. We have two interoperable implementations of this = technology since IDR requires 2 implementations. We have also discussed a= third company switching to this format from their proprietary form. [Discuss -5] * In section 11, the text describes "walled garden SD-WAN deployments" but = does not state the differences with a more open SD-WAN deployment. [Sue-3]: There is no plan for "more open" SD-WAN deployments of Secure SD-W= AN L3VPN and Secure SD-WAN Links. The Secure EVPN document (draft-ietf-bess-secure-evpn-02) discusses this p= oint, but it is not directly linked with SD-WAN. [Discuss-6] In general, the document tends to give the detail of the formatting used in= the messages and TLVs before describing the protocol mechanism using those messages. The general understanding of the protocol's mechanism would be im= proved if this were done the other way round. [Sue-3]: RTG-DIR wanted: general description of protocol mechanisms (sect= ion 2), detail of formatting (section 3.1 - 3.3) and details on protocol me= chanisms (section 3.4-3.6). This rewrite follows that document. Please le= t me know if this resolves your discuss-6. [Technical question-1] * In section 6.1 about the SD-WAN NLRI, it is mentioned that "Route type ou= tside of 1 are out of scope for this document": Are other route types used = in private or experimental deployments? What is the justification for using 2 = bytes to carry a route type that is associated a single value in the docume= nt's context? [Sue-3] Let give you a bit more of the background on why we are allowing a = different route type. First let me start with links to existing WG work: * draft-ietf-rtgwg-multisegment-sdwan-01 specifies a changes to the GEN= EVE header for SDWAN multiple segments. * EVPN uses the Tunnel Encapsulation Attribute (TEA) in BGP to pass the= Geneve header information (draft-ietf-bess-evpn-geneve-08). * The EVPN usage of TEA is not fully specified (P.S. I am the IDR co-ch= air that reviews all TEA drafts). * The Geneve is one encapsulation that might be used within the SD-WAN = hybrid tunnel as it bundles tunnel. * It is unclear if the Route-1 format would handle the EVPN with Geneve= case. * The work is on-going in IDR, BESS and RTGWG. [Technical questions 2 (bundled) ]: * In section 7 about the Extended port attribute TLV, 1 byte is dedicated t= o both the NAT type and the Encap type to encode 7 and 2 possibilities whil= e the transport network ID and the Routing Domain ID need to be globally un= ique, which requires space: wouldn't it be possible to reallocate some spac= e from the 2 first fields to give more space to the two later fields? * In the same section, is it always necessary to carry the Public IP and Pu= blic port fields? Can a flag be used to signal the presence of those two fi= elds if necessary? * In section 7.1.1, in the design of the Underlay Network Transport subsubT= LV, why are the connection and port type described rather than their underl= ying properties (bandwidth, cost, latency, jitter, packet loss...)? Describing t= he underlay link's characteristics in a more abstract way could help the TL= V be more generic. [Sue-3]: One my co-authors reached out to the implementers with your commen= ts. The implementers agreed they could be more efficient, but the code is = deployed. The implementers may propose new TLV that is more efficient. Ho= wever, the current code is deployed. [IDR chair hat on]: Due to IDR's requirement for implementation and fieldin= g, we do allow for revision and deprecation of the TLVs. [IDR chair hat off]; * In section 8.5 about the simplified IPSec SA sub-TLV, is it necessary to = allocate a full byte to both the Transform and the IPSec mode fields? [Sue-3]: One my co-authors reached out to the implementers with your commen= ts. Again, the TLV could be more efficient, but it is deployed. [Should] The following are other issues I found with this document that SHOULD be corrected before publication: [Should-1] It is to be noted that Figure 1 extensively uses public IP(v4) addresses. Proper private addresses should be used for the addresses in the SD-WAN rea= lm, while public underlay addresses should be clearly marked as example address= es not to be reused in public deployments [sue-3]: Section 2 and figure 1 has been rewritten to use logical addresses= . [NIT-comments] "[MP_REACH_NLRI] - has been removed. [MEF-70.1] and [MEF70.2] have been added. NIT Comments related to section 3 and 4 - have bene rewritten. * In page 6, section 3.3.1, is "[Encap-EC]" a reference to a document, or a specific section to a document? --_000_CO1PR08MB6611203528378729D788CE97B3152CO1PR08MB6611namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Antoine:=20

 

I=20want=20to= =20thank=20you=20again=20for=20your=20detailed=20review. =20It=20helpe= d=20me=20decide=20to=20rewrite=20the=20document=20instead=20of=20limping=20= along=20with=20the=20fractured=20text.

 

You=20should=20= find=20-19=20at:=20

https:= //datatracker.ietf.org/doc/draft-ietf-idr-sdwan-edge-discovery/

 

Some=20clean-up= =20issues=20for=20the=20RTG-DIR=20require=20-20,=20so=20I’d=20like=20= your=20feedback=20on=20the=20rewrite.  =20 Your=20DISCUSS=20= level=20issues=20and=20Technical=20questions=20are=20listed=20below.=20&nbs= p;See=20[Sue-3]=20for=20answers.

 

I=20plan=20to= =20add=20the=20following=20if=20you=20approved:

definition=20of=20authoriz= ed=20BGP=20peers=20in=20section=201.3=20 (see=20DISCUSS-2) Som= e=20comment=20that=20underscores=20that=20this=20implementation=20is=20only= =20for=20walled=20gardens=20(see=20DISCUSS-5) &nb= sp;

I=20also=20trie= d=20to=20edit=20the=20NITs,=20but=20I=20missed=20the=20following=20NITS.&nb= sp;=20These=20will=20be=20addressed=20in=20-20.

Encaps-EC=20–=20should=20be=20Enca= p-EC=20 *=20In=20page=2014,=20section=205.4,=20&= quot;the"=20is=20missing=20in=20"An=20SD-WAN=20VPN=20ID=20is=20sa= me=20as=20a=20client=20VPN...".=20–=20missed *=20In=20page=2014,=20section=206,=20a= =20verb=20is=20missing=20in=20"The=20hybrid=20SD-WAN=20underlay=20tunn= el=20UPDATE=20is=20to=20advertise=20the=20detailed..."=20–=20mis= sed 3rd=20paragraph=20in=20sectio= n=2011=20(Security=20Considerations)=20–=20noted=20as=20your=20page= =2034,=20section=2011   &nb= sp;  

 

I’ve=20re= leased=20a=20-19=20with=20the=20rewrite,=20but=20there=20are=20open=20issue= s:

 

RTG-DIR=20open=20issues=20= –=20that=20need=20feedback=20from=20implementers. &nb= sp;

Section= =203.2.2=20–=20There=20are=20open=20issues=20regarding=20the=20intera= ction=20between=20BGP=20Update=20Next=20Hop,=20Tunnel=20Encapsulation=20Egr= ess=20Endpoint,=20and=20the=20SD-WAN-Node=20ID.

Due=20to= =20IDR’s=20rule=20about=20implementations,=20I=20need=20to=20check=20= with=20the=20implementers=20to=20see=20what=20checks=20are=20implemented.&n= bsp;=20At=20a=20high=20level,=20the=20BGP=20Peer=20originating=20should=20b= e=20the=20BGP=20Update=20Next=20Hop=20for=20the =20Update=20message=20and=20the=20SD-WAN-Node=20ID. =20 The=20Tun= nel=20Egress=20must=20be=20loosely=20associated=20with=20the=20Port-Local-I= D.

 

Section= =203.2=20or=203.2.3=20–=20I=20need=20to=20indicate=20what=20optional= =20BGP=20attributes=20can=20be=20associated=20with=20the=20SD-WAN=20Underly= =20NLRI. 

 

SEC—DIR=20–=20= I=20need=20to=20add=202=20new=20abbreviations=20(IPsec=20SA=20and=20SA)=20p= lus=20a=20pointer=20in=20the=20Security=20considerations. OPS= -DIR=20 -=20No=20additional=20fixes. Sue=20

 

From:=20Antoine=20FRESSANCOURT= =20<antoine.fressancourt=3D40huawei.com@dmarc.ietf.org>
Sent:=20Wednesday,=20November=2020,=202024=2010:26=20AM
To:=20Susan=20Hares=20<shares@ndzh.com>;=20Antoine=20Fressanco= urt=20<antoine@aft.network>;=20int-dir@ietf.org
Cc:=20draft-ietf-idr-sdwan-edge-discovery.all@ietf.org;=20idr@ietf.o= rg;=20John=20Scudder=20<jgs@juniper.net>
Subject:=20RE:=20Intdir=20early=20review=20of=20draft-ietf-idr-sdwan= -edge-discovery-17

 

=  

Hello,

 

Thanks=20for=20your=20answers=20to=20the=20commen= ts=20I=20made=20in=20the=20review=20of=20the=20document.

 

I=20will=20answer=20some=20requests=20for=20clari= fication=20and=20discuss=20some=20of=20your=20answers=20inline=20with=20the= =20text=20of=20your=20previous=20message.=20My=20comments=20and=20answers= =20are=20prefixed=20with=20[AFT].=20I=20stripped=20some=20text=20that=20was= =20not=20necessary=20to=20understand=20the =20discussion=20from=20this=20answer.

 

Best=20regards,

--

Antoine

 

[....]

 

 

[Discuss-1]

*=20In=20section=203.3.1,=20two=20types=20of=20en= coding=20for=20the=20Client=20Route=20UPDATE=20messages=20are=20given,=20&q= uot;Barebones"=20and=20Tunnel=20Encaps=20Attribute,=20while=20they=20a= re=20described=20only=20in=20section=205.

  

[Sue:]  RFC9012=20defines=20two=20forms= =20of=20a=20Tunnel=20Encapsulation=20attribute:

1:=20An=20Extended=20Community=20with=20just=20th= e=20Tunnel=20ID=20defined=20in=20RFC9012=20as=20"Barebones",=

2:=20a=20Tunnel=20Encapsulation=20Attribute.=

So,=20are=20you=20asking=20for=20these=20definiti= ons=20to=20be=20reiterated=20in=20the=20definitions?

 

[AFT]

In=20the=20text,=20I=20think=20that=20the=20one= =20paragraph=20description=20that=20basically=20states=20what=20you=20write= =20in=20your=20answer=20should=20be=20placed=20before=20the=20first=20use= =20or=20presentation=20of=20BGP=20messages=20using=20either=20encoding.=20A= =20more=20detailed=20description=20can=20be =20avoided=20with=20a=20reference=20to=20RFC=209012,=20but=20for=20the=20sa= ke=20of=20clarity,=20I=20think=20positioning=20this=20simplified=20definiti= on=20before=20section=203.3.1=20is=20better.

 

[Sue-3]:=20I=20have=20placed=20additional= =20text=20on=20page=2017=20(pdf)=20in=20the=20section=203.1=20in=20the=20he= ading=20“Encoding:”. =20Is=20this=20enough? =

 

[Discuss-2]

*=20In=20section=203.4,=20the=20behavior=20of=20t= he=20RR=20mentions=20authorized=20BGP=20peers,=20but=20the=20document=20doe= s=20not=20give=20an=20idea=20about=20where=20and=20how=20those=20authorized= =20BGP=20peers are=20set.

 

[Sue:]  Most=20BGP=20drafts=20concernin= g=20RR=20authorized=20peers=20assume=20local=20configuration=20specifies=20=  1.  peer=20address,=20and=20b)=20some=20secure=20link. = ; Are=20you=20asking=20that=20"authorized=20BGP=20peers"=20b= e=20defined=20prior=20to=20the=20use=20of=20the=20term=20in=20section=203.4= .

  

[AFT]

Providing=20the=20explanation=20you=20give=20as= =20an=20answer=20to=20this=20point=20in=20the=20text=20would=20make=20the= =20text=20clearer=20in=20my=20view.=20Besides,=20if=20this=20behavior=20is= =20clearly=20explained=20in=20another=20document,=20I=20think=20it=20would= =20be=20interesting=20to=20point=20to=20this=20document =20as=20an=20informative=20reference.

 

= [Sue-3]:=20 Section=201.0=20has=20been=20rewritten=20to=20reestablish= =20the=20link=20from=20draft-ietf-idr-sdwan-edge-discovery-19=20to=20draft-= ietf-bess-sdwan-usage. 

= Section=202.2=20has=20been=20rewritten=20to=20provide=20the=20high-level=20= logical=20example=20of=20the=20mechanisms.=20Within=20section=202.2,=20sect= ion=202.2.3=20paragraph=202=20indicates=20that=20existing=20BGP=20Update=20= mechanism=20control =20how=20RRs=20distribute=20routes. =20Section=202.2.4,=20provides=20a= =20logical=20example=20where=20we=20state=20“RR=20Policy”.=20&n= bsp;Section=202.6=20applies=20this=20to=20SD-WAN=20segmentation. =20Th= ese=20descriptions=20come=20before=20the=20mechanisms=20in=20section=203.= =20  Should=20I=20add=20the=20term=20“authorized=20BGP=20pe= ers” =20in=20the=20definitions. =20What=20do=20you=20think?=20

   

[Discuss-3]

 *=20In=20section=204.2,=20the=20text=20ment= ions=20that=20the=20RR=20speaks=20to=20the=20BGP=20clients=20over

IPSec=20while=20section=203.4=20mentions=20a=20se= cure=20transport=20session=20(e.g.=20TLS)

 

Sue:=20BGP=20works=20over=20Transport=20layer.&nb= sp; Contrary=20to=20the=20actual=20specification=20many=20implementati= ons=20use=20TLS=20or=20TCP=20over=20IP-SEC  or=20other=20means=20= of=20securing=20the=20text. =20Would=20adding=20this=20level=20of=20de= tail=20to=20section=203.4=20resolve=20this=20"DISCUSS"=20level =20issue?

 Or=20are=20you=20looking=20for=20something= =20else?

 

[AFT]

My=20remark=20stems=20from=20an=20inconsistency= =20between=20the=20text=20in=20sections=203.4=20and=204.2.=20For=20the=20sa= ke=20of=20clarifying,=20I=20think=20that=20you=20should=20clearly=20state= =20the=20assumptions=20you=20are=20making=20about=20the=20security=20and=20= integrity=20of=20the=20channel=20you=20are=20using =20to=20convey=20the=20BGP=20messages,=20and=20point=20to=20the=20documents= =20describing=20the=20secure=20transport=20mechanisms=20you=20would=20use.<= o:p>

 

= [Sue-3:]=20Section=201.0,=20paragraph=202=20states=20the=20assumption=20of= =20a=20secure=20connection=20between=20RR=20and=20each=20BGP=20Peer=20suppo= rting=20SD-WAN.=20 This=20paragraph=20states=20the=20establishment=20o= f=20the=20secure=20channel =20is=20outside=20the=20scope=20of=20the=20document.=20  Section= =202-4=20have=20been=20rewritten=20into=20a=20single=20section=20(section= =202)=20and=20references=20to=20MEF[70.1],=20MEF[70.2],=20and=20draft-ietf-= bess-sdwan-usage-25. =20In=20section=202,=20Figures=202=20and=203=20re= iterate=20that=20the=20BGP=20connections=20to=20the=20RR =20are=20over=20secure=20links=20or=20secure=20transports.=20  In= =20the=20new=20section=202,=20sections=202.2.3=20and=202.6=20try=20to=20res= olve=20the=20RR=20secure=20transport.

 

----

 

[Discuss-4]

*=20In=20section=208,=20the=20text=20refers=20to= =20the=20IPSec-SA-ID,=20and=20assumes=20it=20has=20been=20set=20but=20very= =20little=20details=20are=20given=20in=20the=20document=20as=20to=20how=20t= his=20ID=20is=20set,=20negotiated=20or=20provisioned=20in=20the=20IPSec=20S= A=20endpoints.=20References=20are=20made=20to=20other =20RFCs,=20but=20the=20text=20would=20benefit=20from=20a=20description=20of= =20the=20mechanism=20the authors=20are=20considering=20using.

 

[Sue-2]   First=20of=20all,=20BGP= =20is=20not=20setting=20up=20the=20IPsec=20tunnel.  It=20is=20onl= y=20passing=20parameters=20so=20the=20tunnel=20can=20be=20set-up. &nbs= p; Second,=20if=20it=20is=20helpful=20to=20provide=20a=20description= =20of=20the=20mechanism,=20it=20can=20be=20added.  However,=20it= =20seems=20you=20have =20something=20in=20mind.  Would=20you=20mind=20providing=204=20b= ullet=20points=20on=20what=20you'd=20like=20added.

 

[AFT]

The=20only=20thing=20I=20have=20in=20mind=20is=20= the=20objective=20to=20make=20the=20document's=20text=20clear=20enough=20to= =20allow=20implementers=20to=20develop=20interoperable=20implementations

 

= [Sue-3]:=20All=20section=20relating=20to=20IPsec=20SA=20SubTLVs=20 hav= e=20been=20reformatted=20with=20a=20new=20format=20that=20I=20am=20proposin= g=20(as=20IDR=20co-chair)=20for=20all=20BGP=20Tunnel-encapsulation=20Attrib= utes.=20 We=20have=20two=20interoperable =20implementations=20of=20this=20technology=20since=20IDR=20requires=202=20= implementations.=20  We=20have=20also=20discussed=20a=20third=20c= ompany=20switching=20to=20this=20format=20from=20their=20proprietary=20form= . 

 

[Discuss=20-5]=20

*=20In=20section=2011,=20the=20text=20describes= =20"walled=20garden=20SD-WAN=20deployments"=20but=20does=20not=20= state=20the=20differences=20with=20a=20more=20open=20SD-WAN=20deployment.

[Sue-3]:=20There=20is=20no=20plan=20for=20= “more=20open”=20SD-WAN=20deployments=20of=20Secure=20SD-WAN=20L= 3VPN=20and=20Secure=20SD-WAN=20Links. =20 

The=20Secure=20EVPN=20document=20 (dr= aft-ietf-bess-secure-evpn-02)=20discusses=20this=20point,=20but=20it=20is= =20not=20directly=20linked=20with=20SD-WAN.

 

[Discuss-6]=20 

In=20general,=20the=20document=20tends=20to=20giv= e=20the=20detail=20of=20the=20formatting=20used=20in=20the=20messages=20and= =20TLVs=20before=20describing=20the=20protocol=20mechanism=20using=20those<= o:p>

messages.=20The=20general=20understanding=20of=20= the=20protocol's=20mechanism=20would=20be=20improved=20if=20this=20were=20d= one=20the=20other=20way=20round.

[Sue-3]: =20RTG-DIR= =20wanted:=20general=20description =20of=20protocol=20mechanisms=20(se= ction=202),=20detail=20of=20formatting=20(section=203.1=20–=203.3)=20= and=20details=20on=20protocol=20mechanisms =20(section=203.4-3.6). =20This=20rewrite=20follows=20that=20document.=  =20Please=20let=20me=20know=20if=20this=20resolves=20your=20discuss-6.

 <= /p> [Technical=20q= uestion-1]

*=20In=20section=206.1=20about=20the=20SD-WAN=20N= LRI,=20it=20is=20mentioned=20that=20"Route=20type=20outside=20of=201= =20are=20out=20of=20scope=20for=20this=20document":=20Are=20other=20ro= ute=20types=20used=20in

private=20or=20experimental=20deployments?=20What= =20is=20the=20justification=20for=20using=202=20bytes=20to=20carry=20a=20ro= ute=20type=20that=20is=20associated=20a=20single=20value=20in=20the=20docum= ent's=20context?

 

[Sue-3]=20Let=20give=20you=20a=20bit=20more=20of= =20the=20background=20on=20why=20we=20are=20allowing=20a=20different=20rout= e=20type. =20First=20let=20me=20start=20with=20links=20to=20existing= =20WG=20work:

draft-ietf-rtgwg-multisegment-sdwan-01=20specifies=20a=20changes=20to=20t= he=20GENEVE=20header=20for=20SDWAN=20multiple=20segments. EVPN=20uses=20the=20Tunnel=20Encapsulation=20Attribute=20= (TEA)=20in=20BGP=20to=20pass=20the=20Geneve=20header=20information=20(draft= -ietf-bess-evpn-geneve-08). The=20EVPN=20usage=20of=20TEA=20is=20not=20fully=20specif= ied=20(P.S.=20I=20am=20the=20IDR=20co-chair=20that=20reviews=20all=20TEA=20= drafts).  The=20Geneve=20is=20one=20encapsulation=20that=20might=20= be=20used=20within=20the=20SD-WAN=20hybrid=20tunnel=20as=20it=20bundles=20t= unnel.  It=20is=20unclear=20if=20the=20Route-1=20format=20would= =20handle=20the=20EVPN=20with=20Geneve=20case. The=20work=20is=20on-going=20in=20IDR,=20BESS=20and=20RTG= WG.  

[Technical=20questions=202=20(bundled)=20]:=20=  

*=20In=20section=207=20about=20the=20Extended=20p= ort=20attribute=20TLV,=201=20byte=20is=20dedicated=20to=20both=20the=20NAT= =20type=20and=20the=20Encap=20type=20to=20encode=207=20and=202=20possibilit= ies=20while=20the=20transport=20network=20ID=20and=20the=20Routing=20Domain= =20ID=20need=20to=20be=20globally=20unique,=20which =20requires=20space:=20wouldn't=20it=20be=20possible=20to=20reallocate=20so= me=20space=20from=20the=202=20first=20fields=20to=20give=20more=20space=20t= o=20the=20two=20later=20fields?

 

*=20In=20the=20same=20section,=20is=20it=20always= =20necessary=20to=20carry=20the=20Public=20IP=20and=20Public=20port=20field= s?=20Can=20a=20flag=20be=20used=20to=20signal=20the=20presence=20of=20those= =20two=20fields=20if=20necessary?

 

*=20In=20section=207.1.1,=20in=20the=20design=20o= f=20the=20Underlay=20Network=20Transport=20subsubTLV,=20why=20are=20the=20c= onnection=20and=20port=20type=20described=20rather=20than=20their=20underly= ing

properties=20(bandwidth,=20cost,=20latency,=20jit= ter,=20packet=20loss...)?=20Describing=20the=20underlay=20link's=20characte= ristics=20in=20a=20more=20abstract=20way=20could=20help=20the=20TLV=20be

more=20generic.

 

[Sue-3]:=20One=20my=20co-authors=20reached= =20out=20to=20the=20implementers=20with=20your=20comments. =20The=20im= plementers=20agreed=20they=20could=20be=20more=20efficient,=20but=20the=20c= ode=20is=20deployed. =20The=20implementers =20may=20propose=20new=20TLV=20that=20is=20more=20efficient. =20Howeve= r,=20the=20current=20code=20is=20deployed. 

 

[IDR=20chair=20hat=20on]:=20Due=20to=20IDR= ’s=20requirement=20for=20implementation=20and=20fielding,=20we=20do= =20allow=20for=20revision=20and=20deprecation=20of=20the=20TLVs.

[IDR=20chair=20hat=20off];

 

*=20In=20section=208.5=20about=20the=20simplified= =20IPSec=20SA=20sub-TLV,=20is=20it=20necessary=20to=20allocate=20a=20full= =20byte=20to=20both=20the=20Transform=20and=20the=20IPSec=20mode=20fields?<= o:p>

 

[Sue-3]:=20One=20my=20co-authors=20reached= =20out=20to=20the=20implementers=20with=20your=20comments. =20Again,= =20the=20TLV=20could=20be=20more=20efficient,=20but=20it=20is=20deployed.&n= bsp;

 

[Should]=20

The=20following=20are=20other=20issues=20I=20foun= d=20with=20this=20document=20that=20SHOULD=20be

corrected=20before=20publication:

 

[Should-1]=20

It=20is=20to=20be=20noted=20that=20Figure=201=20e= xtensively=20uses=20public=20IP(v4)=20addresses.

Proper=20private=20addresses=20should=20be=20used= =20for=20the=20addresses=20in=20the=20SD-WAN=20realm,

while=20public=20underlay=20addresses=20should=20= be=20clearly=20marked=20as=20example=20addresses

not=20to=20be=20reused=20in=20public=20deployment= s

 

[sue-3]:=20Section=202=20and=20figure=201=20has= =20been=20rewritten=20to=20use=20logical=20addresses.

 

[NIT-comments]

"[MP_REACH_NLRI]=20–=20has=20been=20re= moved. =20 

[MEF-70.1]=20and=20[MEF70.2]=20have=20been=20adde= d.=20

 

NIT=20Comments=20related=20to=20section=203=20and= =204=20–=20have=20bene=20rewritten.

 

*=20In=20page=206,=20section=203.3.1,=20is=20&quo= t;[Encap-EC]"=20a=20reference=20to=20a=20document,=20or=20a=

specific=20section=20to=20a=20document?

 

 

--_000_CO1PR08MB6611203528378729D788CE97B3152CO1PR08MB6611namp_--