Re: [Idr] Opsdir early review of draft-ietf-idr-bgp-car-02
"Dhananjaya Rao (dhrao)" <dhrao@cisco.com> Wed, 17 January 2024 07:41 UTC
Return-Path: <dhrao@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291B7C14F68F; Tue, 16 Jan 2024 23:41:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.905
X-Spam-Level:
X-Spam-Status: No, score=-11.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Lyvr1ktqg3ip; Tue, 16 Jan 2024 23:41:09 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (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 DDDA3C14F686; Tue, 16 Jan 2024 23:41:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=65340; q=dns/txt; s=iport; t=1705477269; x=1706686869; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8gLtqUPM828UhbpWTQoModCAQT2AMqWCPo2DexTwYmQ=; b=P6zUn4s45hKyMkSBY5rjFloiuLLcpkTo/CRrgtZ1rm77iJDTAIfY6GgM /xl4LnqdKOcvRmfAFWTYBSLZX3PkRm3w4f5KdcSzQ4c8jWeyCCN4pgELl HFFn84+0j/PcT71DJT0e9JW4kcm3Mnkh38RQYlijl5XEgNYo1HAONcinP M=;
X-CSE-ConnectionGUID: 5pbnZqIpRiyRTmF5lwnxLQ==
X-CSE-MsgGUID: qJA3UzdLRx2Owof+U9X3Eg==
X-IPAS-Result: A0ANAACDg6dlmJRdJa1aHAEBAQEBAQcBARIBAQQEAQFlgRYHAQELAYE1MVJ6AoEXSIRSg0wDhE5fiGcDi16FYYxEFIERA1YPAQEBDQEBRAQBAYUGAhaHLwImNAkOAQIEAQEBAQMCAwEBAQEBAQEBBgEBBQEBAQIBBwUUAQEBAQEBAQEeGQUOECeFeYZFAQEBAQMSCAlWEAIBBgIRAwECDhMBBgMCAgIeERQJCAIEDgUIDAcHgl4BghcUAzEDAZgbj04BgUACiih6gTKBAYIWBbAbDYJVgUgBh3wEGgFoZgEBgWyCD4RXJxuBSUSBFUKCaD6CH4FeLBweFoMlOYIvBIEVKVaCMDY0AxMTgi4DgT2FQAQBPwIlgSSFLlJ5IwN9CARcDxsQHjcREBMNAwhuHQIxPAMFAwQyChIMCyEFE0IDQAZJCwMCGgUDAwSBMAUNGgIQGgYMJgMDEkkCEBQDOAMDBgMKMQMwVUEMUANlHzIJPA8MGgIbHg0nIwIsQAMRBRACFgMkFgQ2EQkLJgMqBjoCEgwGBgldJhYJBCUDCAQDVAMjdBEDBAoDFAcLB3mCFQYDRB1AAwttPRQhFBsFBIE2BZN1gkIBAQI6LgYCYgQLElYCJCAVBAEgCxoSAw4VFgIdDQkvkigUEAEBEoNXixiOSJNASnAKhBGBXJlHBIYlF4QBjHWGdo5jgl9kmFKCUY8YkTkED4UMAgQCBAUCDgEBBoFjOi2BLnAVGoMIUhkPgzyKawIDBQgJk092OwIHAQoBAQMJiHAtgUoBAQ
IronPort-PHdr: A9a23:WzZW3R9LXZzwDv9uWOToyV9kXcBvk7zwOghQ7YIolPcSNK+i5J/le kfY4KYlgFzIWNDD4ulfw6rNsq/mUHAd+5vJrn0YcZJNWhNEwcUblgAtGoiEXGXwLeXhaGoxG 8ERHER98SSDOFNOUN37e0WUp3Sz6TAIHRCqOQpvL+PdEY/JhMPx3Oe3qNXfZgxSj2+laKhpZ FWu+B/ctMQdncNuK71kzBzPrzoAd7FdxHhjIhSYmBOU2w==
IronPort-Data: A9a23:nwn9AKtn3qYO58WlRGkQgrsL/efnVHxeMUV32f8akzHdYApBsoF/q tZmKTiCPPqJMGOgfNF0b4W0/EIPsJWEyocyHlBkrChmFXsVgMeUXt7xwmUckM+xwmwvaGo9s q3yv/GZdJhcokf0/0rrav656yAkiclkf5KkYMbcICd9WAR4fykojBNnioYRj5Vh6TSDK1vlV eja/YuHZTdJ5xYuajhIs/va9ks01BjPkGpwUmIWNKgjUGD2zxH5PLpHTYmtIn3xRJVjH+LSb 44vG5ngows1Vz90Yj+Uuu6Tnn8iG9Y+DiDS4pZiYJVOtzAZzsAEPgnXA9JHAatfo23hc9mcU 7yhv7ToIesiFvWkdOjwz3C0HgkmVZCq9oMrLlDiqcaV/VTna0Ht0s9SCW9rOZIe6sJOVDQmG fwwcFjhbziZjO6whbm8UOQp355lJ8jwN4RZsXZlpd3bJa95GtaYHOObvpkBgGdYasNmRZ4yY +IVaSBmazzLYgZEPREcD5dWcOKA3yamKmQG8g3IzUYxy3Hx5VdMwrTJCsqPXcONS4Zoz3bDi 22TqgwVBTlBaYTAkmDamp62vcfOkTnTWY8OGvu/7PECqFGJz2IPTRwbSVX+oPWjz0SxQ5dUI lZS8y4qhak/6ELtScPyNzW/uGXBsh8Gc9tdD+N87xuCopc4+C6DDWQCCzVGctFj7ZVwTj0x3 VjPlNTsbdByjFGLYS+F/LGmtBKqAykEF1MHS3IAUg0Vx+C29enfkSnzZtpkFae0iPj8Fjfx3 y2GoUACa1M70J9jO0KToACvvt68mqUlWDLZ8ek+Y45IxhlyaIjgbIuy5B2Ct7BLLZ2SSR+Ku 31sdymiAAImU8zleM+lGbll8FSVCxCta2y0bblHRMZJythV0yT/Fb28GRknTKuTDu4KeCXyf GjYsh5L6ZlYMROCNPAvPt7rWpVylfC9TbwJs8w4iPIQOvCdkyfarUlTibK4jggBbWB1yP5vZ 83HGSpSJS9FVfsPIMWKqxc1iuJzmXtkmgs/tLjwzg+s1vKFdWWJRLIeeFqIZaZR0U93iFu9z jqrDOPTk083eLSnOkH/qNdPRXhUdiJTLc6t9KRqmhurf1AO9JcJUaGBmNvMuuVNwsxoqws/1 ijkBxAJlAul2i2vxMfjQikLVY4DlK1X9BoTFSctJl2vnXMkZO6SAG03LfPboZFPGDRf8MNJ
IronPort-HdrOrdr: A9a23:WmgNj6o9E3gdAmqeAyux72kaV5tiLNV00zEX/kB9WHVpm5Oj5q OTdaUgtSMc1gxxZJh5o6H/BEDhex/hHZ4c2/h2AV7QZniWhILIFvAv0WKM+UybJ8STzJ846U 4kSdkANDSSNyk0sS+Z2njELz9I+rDum87Y55a6854ud3AXV0gK1XYBNu/vKDwMeOAwP+tAKH Pz3LshmxOQPV4sQoCQAH4DU+Lfp9vNuq7HTHc9bSIP2U2ltx/tzKT1PSS5834lPg+nx41MzU H11yjCoomzufCyzRHRk0XJ6Y5NpdfnwtxfQOSRl8k8MFzX+0eVTbUkf4fHkCE+oemp5lpvus LLuQ0cM8N67G6UVn2poCHqxxLr3F8Vmj/fIB6j8DjeSP7CNXcH4vl69MZkm9zimg0dVeRHoe B2NqSixtxq5F377X3ADpPzJmFXfwKP0AkfeKgo/jJiuU90Us4LkWTZl3klSKsoDWb07psqH/ JpC9yZ7PFKcUmCZ3ScpWV3xsewN05DVStub3Jy8/B96QIm1ExR3g8d3ogSj30A/JUyR91N4P nFKL1hkPVLQtUNZaxwCe8dSY/vY1a9DC7kISaXOxDqBasHM3XCp9r+56g0/vijfNgNwIEpkJ rMXVtEvSo5el7oC8eJwJpXmyq9ClmVTHDo0IVT9pJ5srrzSP7iNjCCUkknl4+6r/AWEqTgKo CO0VJtcojexEfVaPJ0NlfFKutvwFElIbgohuo=
X-Talos-CUID: 9a23:1eKUsGE4pPBRZ44fqmI67EQSKNkEakfc3U3sJmHlDXlvWJmsHAo=
X-Talos-MUID: 9a23:KkxWSA3M4kv9KJG2SeN+lVONFzUj+oaHU30fnbE8q5OjKit+eArMvG+aTdpy
X-IronPort-Anti-Spam-Filtered: true
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jan 2024 07:41:07 +0000
Received: from alln-opgw-4.cisco.com (alln-opgw-4.cisco.com [173.37.147.252]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 40H7f7B3022569 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 17 Jan 2024 07:41:07 GMT
X-CSE-ConnectionGUID: bm4TCnLYShiE3tpkXSQMuA==
X-CSE-MsgGUID: JEqDBghlRmOk+nqwq/vIAA==
Authentication-Results: alln-opgw-4.cisco.com; dkim=pass (signature verified) header.i=@cisco.com; spf=Pass smtp.mailfrom=dhrao@cisco.com; dmarc=pass (p=reject dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="6.05,200,1701129600"; d="scan'208,217";a="20292049"
Received: from mail-mw2nam10lp2101.outbound.protection.outlook.com (HELO NAM10-MW2-obe.outbound.protection.outlook.com) ([104.47.55.101]) by alln-opgw-4.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jan 2024 07:41:06 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I7qLCcfvuBsTW5nyKmbr5DEVzNjVcMO+jkvr8P1VunSW6Bhff3W4e3qNpAqe0CjR+wGrI/cM0WA1ySEWAUJLXdUDRy1SttcnNETVcI+rS7cuAxdkfvtQoUVru8dL/Q0zojBcTNvageSAP6gRgDOg1pmjSo2hW0yNOmKMHvOYFN7apAXDzsrl32+9OdKHks3OHWVgN3TXlzClci1QLMy8qO+gsE/anBnVXyfNIy3VKjs/hn18BmluP8DloAfhY9wLKthEoAR5q2VXrumgWwmeMUN+SeYMuE2H1ksAVjLL4zoi/9RAIdQSGl0iKqQJpQW4q8ZjJlZZKue7ZLKhLGjntQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=8gLtqUPM828UhbpWTQoModCAQT2AMqWCPo2DexTwYmQ=; b=YqKXrSWGybT1R5VXmB+AAZ41lWm4NEGjgTyXF1pBP63mfJ/0CNyfjOlTfJxdFnUAK9PEs0+56MJEkFdQOeh4O4BPtBIc0EHlohgjv44FvegyAtcuhWL9uCJTDV9PhLyyrCV2R56k0vM9nEf6bYk9OgYotNKUJYsSbGvHt7/msbfz3kOOoUe0r+O+P4WOBCB07JySQe28lTNRm95doCKGetHIs3pSdGy+/Uw+cvtqBegnrAx+F0Au1uhl/2iYm3Y/PahK6+P4xMUaPaFI0vthP7bqtXWBtbGRrjZVTj7XHK4gTyuDyPP/tAs2GM/TrrcjQfqk6oibM+ttM/2FdXc2Ww==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
Received: from BY5PR11MB4273.namprd11.prod.outlook.com (2603:10b6:a03:1c9::32) by DM4PR11MB6117.namprd11.prod.outlook.com (2603:10b6:8:b3::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7181.30; Wed, 17 Jan 2024 07:41:03 +0000
Received: from BY5PR11MB4273.namprd11.prod.outlook.com ([fe80::527:fd94:758d:a3e3]) by BY5PR11MB4273.namprd11.prod.outlook.com ([fe80::527:fd94:758d:a3e3%5]) with mapi id 15.20.7181.029; Wed, 17 Jan 2024 07:41:03 +0000
From: "Dhananjaya Rao (dhrao)" <dhrao@cisco.com>
To: Yingzhen Qu <yingzhen.ietf@gmail.com>
CC: "ops-dir@ietf.org" <ops-dir@ietf.org>, "draft-ietf-idr-bgp-car.all@ietf.org" <draft-ietf-idr-bgp-car.all@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: Opsdir early review of draft-ietf-idr-bgp-car-02
Thread-Index: AQHZ1TGOjiaOGlmZ3EK+NlRM6GSAHrB7n3ltgADEkwCATZr6gIAUhOyo
Date: Wed, 17 Jan 2024 07:41:03 +0000
Message-ID: <BY5PR11MB42730383CD356BC9ABC8005DB0722@BY5PR11MB4273.namprd11.prod.outlook.com>
References: <169273366797.57910.11605264693841606773@ietfa.amsl.com> <BY5PR11MB4273E92CB9071A0A1CEB0D9FB0B1A@BY5PR11MB4273.namprd11.prod.outlook.com> <CABY-gONT+5_WZBTOZ69AeF5Z6VXFjsrCad_J3zr+WgXbm=Zt5A@mail.gmail.com> <CABY-gOOsmLdCeBSLrC7zVFKHmcUs1s1TjrObJ3WvNH90jMD0Bg@mail.gmail.com>
In-Reply-To: <CABY-gOOsmLdCeBSLrC7zVFKHmcUs1s1TjrObJ3WvNH90jMD0Bg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BY5PR11MB4273:EE_|DM4PR11MB6117:EE_
x-ms-office365-filtering-correlation-id: 6f79f22a-b2a6-4d2b-8ab8-08dc172fa814
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VEInzNEvtfJDfj1LHeGzFAx3AHiI9GiyavIWgEyg19eilqr8Y707Qj58Ss4YIbtjnuGErzWKITHWPd0wiYJi/LQBK9xYE/+QEBh3jfy3UVIOp0qUHpTqcmIiMo8viZREUFBiIka444OcEu4slsOMXgB5N6LP+RGWvMFnN3Ps24WGz2uxU0A4D1akQ3UiAt9Rf+mC451huqk6KiGL7BsB/dt5/Iz/JM5cQEY3dvAQEafPCAQmjj3rTimV9mJ0RGkJH1fwrXQbCyGHEtKieH5cLdqZNvOp3/d+0Q5eTsNLVtgQOoWu0tVshIgsLTm2zSXtr7mqNYEYqWCXDTMZLLOMFDdTJp06aVgLKx4vzwNIoHnTBDV+rQnwqy5iTis1oK94WipNTiXZ254AbD3t1vx2AY5vz6m6Zf2wyi7wtq1YYhxYOPgzy+u6ykaKXWwtC5XNe2fD11+pBn8YLJ2Do1Tj2KDL7yCItABdsTfBkEWev9ko92n3sAoT5gNXJv3826L1oVn2B0M/jXgjAKRVeXpjOWZJn08tfr7Yxq/Km5VFL96fWZ38IV6iyt3qB/OpTSopqqZfERgsWQC1TjisR9IhucH9ylWa6O6qb0b+OX71Mwh/8V+s/2mqiKfy4KUcR6De
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4273.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(366004)(136003)(346002)(376002)(396003)(39860400002)(230922051799003)(186009)(64100799003)(1800799012)(451199024)(38070700009)(55016003)(83380400001)(66574015)(478600001)(30864003)(5660300002)(4326008)(9326002)(52536014)(6506007)(316002)(8936002)(64756008)(66946007)(54906003)(6916009)(66556008)(71200400001)(9686003)(66476007)(26005)(76116006)(66446008)(8676002)(122000001)(53546011)(38100700002)(7696005)(2906002)(41300700001)(86362001)(33656002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: +AVdTWL0ZIOelQoZiINNgL4/SHUvsBMOKZAUuNHqEPFgGrTyF2hgEE3Zypjdstw09CvdiThz4BevRJMTvL3kvzgGOHsZP5BZUbO7V5LZe9NmPhpoiGUaWi60++h0/0fuyLqv8Hzg5fQxpkDCRvqFs1gljQWBWt0eovCqUzAecVI8p5ed/mBpEhdOr/Li45J2CG5q4Hp7WiAXgrW61aFrOH1RUYFTYgfiDq+iUZr0p+Z6OJ4Kc2OIY8Y4V/xqkB6+mKs4E8FAc4w4rpV2GbDfs7GSd5zjBan4oRuwN2In0EmG5oBYmjqnLX8imYoyxVAkbQq6saJ64ZWWHn+7WhIOSSN/tN8Bd511D5kBkOG71EDH9fvA21sYR9cEREv0fqge6sJTZA4mZWLMgLYJu2vmJl9iSGjuywkaOCAuEBqNuGgP117OcVS1uPIQs7/Zc8leogbI+I26kI3Ey9DhafuJKoSkGST8E5yn3q+JlbTZQFyDmOOKb1VZfDnsg1fykcEohrRLoPdonsnIYKIv2LcFq3/WcKneQT+3DavxfLMyJnqLGKelm+RPjJPRYPply9U/hF+6RZNRts9wI00Zfi3cwc0JD2lPNgVsNyE8crAEtjDYtOg6miaaz3F0bSG7+EPLik9gvRjj5Cm09U74AfXoEkHZUcSixugsGsdaJyFUwSLb5iTsDiod6PVwfS1u0Da0wRBaEFBEjrKviDQkR+jnqkN5KvHz3csiesqSpjttiSRwM5d2c4Yw3F+bPYdzIlbrU/puttNP6BiIJ8kQHsXk0hbRD65SUMuT5c2RnPov6RCrDAvW59ALIWB/5uaw7KF75UZwI17NCpN0581H6vk8+MW8lguJ2hoLdPUAjMcTW1YUxgE1iFJK4lJTqr+ttJ9KQindQKrcT7JaB/aBGk430k9mHL9fBDJSoVVRx46ICGcWf8c4piuSorCKvan1+m/nvGP3Tri4FipmPvO0TpKDfPs4m350gdnKARO7ulxo2MKe0E6lZoz1eUoTQbbtpTvrd6Al4qj9gSZVARCgRSZcgijazcAA/AMH0Ph1MvyhmVc0sFi9FTuEh7D/I8FiBvGawU3S2m+2kYE4IIvfYTcpMg0+0LvjpnU4w2GDi6FPECPOp++7RK+99WYGiCxMCQaMpmuikkWLVqLAikxnABLS06v6fnrGLnOLwO5SS7/L9SkgvwEQXwKtLMVG0avOy0KlAdPgHjhQFInaFya2d/FrqKFKGrOpMyhJYzXU92XtDwFIebx9HbrKeXxlrAPQRPdvhv0z9vcgVsnN05X8WOSLYTnuGwif39WC2xGv0A5gH8ByZAmeU79TEvwNRP6gO5dDTVJfg44Gg2ifhC/WvXVjf2GDRYMKuympXfScKdwtTdvU78sGJ+uIyp18cpFteT5kDagxgd0X5oGioHhB4qey71j2g9eia+/Uu7KCqJRddy4OljXLvogEJfdlUOk7DEbIVfYszOqlfYOUXuweBdlTvMjavy09aSjF6EJgU6o63Ebmd4zFS2fa/2cbJcCxoko77M0T32cadT5BDogwzcDqXqEz7S1ppaLMVdmkXynmeUh329GPb5rrNpSB7eTgjNRD
Content-Type: multipart/alternative; boundary="_000_BY5PR11MB42730383CD356BC9ABC8005DB0722BY5PR11MB4273namp_"
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4273.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6f79f22a-b2a6-4d2b-8ab8-08dc172fa814
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2024 07:41:03.0273 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jasAFoM5IshzHuRvPPwDBqZVMS18nFvk0aSPjL9ndGRh56GdIGh0t9qIw/O7dOGg
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6117
X-Outbound-SMTP-Client: 173.37.147.252, alln-opgw-4.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/8fzjfCGpxCTRdZFKZujPLzWzJwE>
Subject: Re: [Idr] Opsdir early review of draft-ietf-idr-bgp-car-02
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jan 2024 07:41:13 -0000
Hello Yingzhen, Thank you so much for your reviews. Will fix the nit. Regards, -Dhananjaya From: Yingzhen Qu <yingzhen.ietf@gmail.com> Date: Wednesday, January 3, 2024 at 10:10 PM To: Dhananjaya Rao (dhrao) <dhrao@cisco.com> Cc: ops-dir@ietf.org <ops-dir@ietf.org>, draft-ietf-idr-bgp-car.all@ietf.org <draft-ietf-idr-bgp-car.all@ietf.org>, idr@ietf.org <idr@ietf.org> Subject: Re: Opsdir early review of draft-ietf-idr-bgp-car-02 Hi Dhananjaya, Thanks for updating the draft and addressing my comments. I've read version -05, the overall quality and readability of the document have been improved substantially. All my major concerns have been answered, especially about why type 2 NLRI is needed. One nits I noticed is that on the front page, it says co-authors are listed in section 11, which should be section 13. Looking forward to your update presentation in the upcoming interim meeting. Thanks, Yingzhen On Wed, Nov 15, 2023 at 1:03 PM Yingzhen Qu <yingzhen.ietf@gmail.com<mailto:yingzhen.ietf@gmail.com>> wrote: HI Dhananjaya, Ack. Thanks for addressing my comments. I'll review the updated draft and get back to you. Thanks, Yingzhen On Wed, Nov 15, 2023 at 2:35 AM Dhananjaya Rao (dhrao) <dhrao@cisco.com<mailto:dhrao@cisco.com>> wrote: Hi Yingzhen, Thank you once again for your thoughtful review. We’ve made a couple of updates to the draft. I’m hoping they address most of the comments and feedback you had provided. I’ve also included some clarifications inline (please check for DR#). From: Yingzhen Qu via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> Date: Wednesday, August 23, 2023 at 1:18 AM To: ops-dir@ietf.org<mailto:ops-dir@ietf.org> <ops-dir@ietf.org<mailto:ops-dir@ietf.org>> Cc: draft-ietf-idr-bgp-car.all@ietf.org<mailto:draft-ietf-idr-bgp-car.all@ietf.org> <draft-ietf-idr-bgp-car.all@ietf.org<mailto:draft-ietf-idr-bgp-car.all@ietf.org>>, idr@ietf.org<mailto:idr@ietf.org> <idr@ietf.org<mailto:idr@ietf.org>> Subject: Opsdir early review of draft-ietf-idr-bgp-car-02 Reviewer: Yingzhen Qu Review result: Has Issues Hi, Thanks for the draft. I am the assigned OPSDIR reviewer to conduct an "early" review of this draft. General comments: There are lots of abbreviations in the draft. I'd suggest to add them in the the terminology section. For example, I'd assume BR means Border Router, but there might be different guessing. DR# Ack, we have expanded on abbreviations. In this draft, it says E is globally unique, which makes E-C in that order unique. Can you please explain a bit more about the second unique? I suppose it's possible to have two different source nodes, E1 and E2, all reach destination E with color C, correct? DR# Uniqueness is for the destination (E)’s BGP route. The data model of E,C keeps the route NLRI unique end to end even though color in NLRI may map to another intent in a different color (administrative) domain during propagation, since E is globally unique in provider network and scopes the color. Section 12 discusses the operational/manageability considerations. DR# I assume by source you mean an ingress node. Both source nodes above E1 and E2 will receive the (E,C) route without any change in the NLRI, and can use it to send traffic to the destination node E. The draft has an informative reference to [I-D.hr-spring-intentaware-routing-using-color], which is an important problem statement for this solution. Will the problem statement draft progress as well? Even so, to improve the readability of the bgp-car draft, I'd suggest adding some text for a brief introduction of the problem. DR# Yes, the problem statement is awaiting adoption call in spring. DR# We have also expanded the Introduction section. IP Prefix NLRI was added in version -02. The use case is where a unique routable IP prefix is assigned a given intent or color. In other words, the IP is overloaded with a color. The same can be achieved using an IP with a color. I'm not totally convinced that this type 2 NLRI is needed. Please clearly specify when it should be used. DR# We have tried to clarify the usage of Type-2 for different cases in the updated versions, specifically in Section 8. DR# The expanded intro section also describes the use-case/motivation a bit more. Please consider adding a section for operation considerations. There are pieces of information about operation and deployment scattered in the document, please consider group them together. DR# We did have a Manageability Considerations section 12, renamed it. SRv6 specific operational considerations are in Section 8.3, since the SRv6 specific items are in Section 8. There are quite some sentences missing "." at the end. Please do an editorial pass and fix them. DR# Done, thanks. Detailed comments with line # from idnits: 478 The value set (or appropriately incremented) in the AIGP TLV 479 corresponds to the metric associated with the underlying intent of 480 the color. For example, when the color is associated with a low- 481 latency path, the metric value is set based on the delay metric. 483 Information regarding the metric type used by the underlying intra- 484 domain mechanism can also be set. comment: This statement lacks a clear definition how the metric should be set. DR# Updated to indicate it’s the metric value which is set based on the path/metric type. 486 If BGP CAR routes traverse across a discontinuity in the transport 487 path for a given intent, add a penalty in accumulated IGP metric 488 (value by user policy). For instance, when color C1 path is not 489 available, and route resolves via color C2 path (e.g., Appendix A.3). How about the case where encapsulations are different? For example, SR policy in one AS and IGP-FlexAlgo in the other AS vs. SR Policy in both ASes. DR# metric is independent of encapsulation type. For example delay metric can be provided by IGP FA or SR policy. DR# That said, the metric value/penalty can be updated differently by user depending on the path type. Section 2.7 504 The (E, C) route inherently provides availability of redundant paths 505 at every hop, identical to BGP-LU or BGP IP. "every hop" is a bit confusing here since it may mean an IGP hop within an AS. To my understanding, this section means ECMP or backup paths can provide protection in case of failure within an AS domain without impact other ASes. DR# Clarified to indicate it’s every BGP hop. And yes. "Path Availability" as the section title is not very clear. How about something like "Inherent Path Protection"? DR# Made it “Native Multipath Capability”, as path protection could be misinterpreted. 513 BGP ADD-PATH should be enabled for BGP CAR to signal multiple next 514 hops through a transport RR. I'd suggest to change to "SHOULD be enabled". DR# Done 526 The BGP CAR solution seamlessly supports this (rare) scenario while I'd suggest adding a small paragraph explaining why this is a rare but useful case. I would guess the tow domains used to belong to different administrators, now they're trying to merge under one admin domain. nits: personally I don't like how "(rare)" with parentheses is used here, but I'd leave this to the authors. DR#. Section 10 (manageability) describes some considerations. The use-case/requirement is described in the problem statement draft. DR# Removed parenthesis. 806 NLRI instead of the BGP Prefix SID attribute. The BGP Prefix SID 807 Attribute SHOULD be omitted from the labeled color-aware routes when 808 the attribute is being used to only convey the Label Index TLV. Add a reference to Appendix D? DR# Done. 848 BGP CAR SRv6 SID TLV definitions provide the following benefits: 850 * Native encoding of SIDs avoids robustness issue caused by 851 overloading of MPLS label fields. 853 * Simple encoding to signal Unique SIDs (non-transposition), 854 maintaining BGP update prefix packing 856 * Highly efficient transposition scheme (12-14 bytes saved per 857 NLRI), also maintaining BGP update prefix packing minor: I don't think the text belongs to the encoding section. Maybe part of "Operation Considerations"? DR# This text describes the reasoning for the CAR encoding design, and was added based on comments during adoption. Hence, we’ve kept it inline to provide context. 1019 * If multiple instances of same type are encountered, all but the 1020 first instance MUST be ignored. 1022 * If multiple instances of same type are encountered, all but the 1023 first instance MUST be ignored. nits: please remove the repetition. DR# Done, thanks. 1025 * A TLV is not considered malformed because of failing any semantic 1026 validation of its Value field. Q: When should a TLV be considered malformed? and how should it be handled? DR# TLV validation and its handling is already specified above in this section for type-specific Non-key TLVs. 1033 3. Service route Automated Steering on Color-Aware path nits: Service Route Automated Steering on Color-Aware Path Please check to make sure all section titles are consistent. DR# Ack, done. 1044 destination, per-flow, CO-only. For brevity, in this revision, we 1045 refer the reader to the [RFC9256] text. nits: maybe change to something like "For brevity, please refer to [RFC9256] section X for detail."? DR# Ack, done. 1047 Salient property: Seamless integration of BGP CAR and SR Policy. minor: personally I don't think this sentence belong to this section. DR# Removed. 1055 4. Intents The section title and content don't seem to match. I don't quite understand the purpose of this section. DR# It’s meant to include illustrations for various intent use-cases. We’ve removed this section as some cases are already included in Appendix. 1085 A separate document will analyze the BGP CAR supports for 3, 5 and 6. Any reference? DR# Not yet. 1097 5.1. (E, C) Subscription and Filtering Q: how is this subscription sent between routers? DR# It would be via a BGP route, but the specification/details are out of scope for this document. 1115 * If A does not have (E2, C1), it will advertise F (E2, C1) to its 1116 peer B I suppose it meant to be "If A does not have subscription of (E2, C1)" DR# It’s if A doesn’t have the route. 1124 On-demand filtering procedures are outside the scope of this 1125 document. what's "on-demand filtering"? DR# It’s on-demand subscription and filtering – fixed. 1138 Two key principles used to address the scaling requirements are a 1139 hierarchical network and routing design, and on-demand route 1140 subscription and filtering. Q: on-demand filtering is claimed to be out of the scope. (line #1124) DR# The hierarchical design is the primary technique which is described. The subscription is optional for control plane optimization. it’s included for completeness of the framework. 1342 Note: E1 does not need the BGP CAR (451, C1) route Q: what's the benefit? DR# The benefit is explained in Section 6.3 last bullet where it’s the case of “E1 needs BGP CAR (451, C1).” “the ingress PE needs an additional BGP transport level recursion and pushes a BGP VPN label and two BGP transport labels. It may also need to handle load-balancing for the egress ABRs. This is the most complex dataplane option for the ingress PE.” 1545 7. Routing Convergence comments: Maybe section 2.7 and 7 should be put together somehow, but I'll leave this to the authors. DR# We’ve kept it as is for now to avoid reorganizing the section. 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | NLRI Length | Key Length | NLRI Type |Prefix Length | 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Q: what's value of the NLRI Type here? DR# Same as for CAR SAFI. 1664 service route is advertised by the egress PE with a Color Ext-Comm C. nits: "Color Ext-Comm" is only used here once while "Color Extended-Community" elsewhere. DR# Done. Nits: this section 9.2.1 and 9.2.2 needs some editorial work. For example, each bullet point should be a sentence finished with a ".". DR# Done. 1796 CAR SAFI may also be used for best-effort routes in addition to 1797 intent-aware routes. Q: Should a color be specified here? or use the IP Prefix NLRI Type 2? DR# Its Type-2 without color. Clarified in Section 8. 2008 This extension defines a new SAFI within a BGP and therefore does not it should be two new SAFIs: BGP CAR/83 and BGP VPN CAR/84 2307 The examples use MPLS/SR for the transport data plane. Scenarios 2308 specific to other encapsulations will be added in subsequent 2309 versions. nits: this should be removed. DR# Ack, fixed. Regards, -Dhananjaya Thanks, Yingzhen
- [Idr] Opsdir early review of draft-ietf-idr-bgp-c… Yingzhen Qu via Datatracker
- Re: [Idr] Opsdir early review of draft-ietf-idr-b… Dhananjaya Rao (dhrao)
- Re: [Idr] Opsdir early review of draft-ietf-idr-b… Yingzhen Qu
- Re: [Idr] Opsdir early review of draft-ietf-idr-b… Yingzhen Qu
- Re: [Idr] Opsdir early review of draft-ietf-idr-b… Dhananjaya Rao (dhrao)