From nobody Wed Oct 12 16:42:00 2022 Return-Path: X-Original-To: grow@ietfa.amsl.com Delivered-To: grow@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0152C14CE42; Wed, 12 Oct 2022 16:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.603 X-Spam-Level: X-Spam-Status: No, score=-9.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, 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 header.b=V3voQ5mR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=S/i0u19a 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 peSdZ5uqmUvD; Wed, 12 Oct 2022 16:41:54 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C0FC14CE3F; Wed, 12 Oct 2022 16:41:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19531; q=dns/txt; s=iport; t=1665618114; x=1666827714; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AYQ31Ja23Fqgl1o3hF9nxmUNoeLn5MLze2b8cDSLHZc=; b=V3voQ5mRxOwtuXcAe1EM8U7Mc1RE+trNO4tjrZD4LgC1zuATRrLkTLpJ Ao2ZuFqf/VcxFXVNPhoLEAH+MOpFbVFxnlVThl+85/XPPzKZvB+APwWIh n7+M7bloitpDhub/T7aMmhslMLt01swlRV3RA333Ep+ENlZ+Zsg8TjoLF w=; IronPort-PHdr: =?us-ascii?q?A9a23=3AW9OfMxCc4rkIMhZuf6bZUyQVaBdPi9zP1kY95?= =?us-ascii?q?pkmjudIdaKut9TnMVfE7PpgxFnOQc3A6v1ChuaX1sKoWWEJ7Zub9nxXdptKW?= =?us-ascii?q?kwJjMwMlFkmB8iIQUTwMP/taXk8G8JPHF9o9n22Kw5bAsH7MlbTuXa1qzUVH?= =?us-ascii?q?0aXCA=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3A5t5VJaJ0i89bNAgUFE+R+JclxSXFcZb7ZxGr2?= =?us-ascii?q?PjKsXjdYENS3mYOymoYXzuGb/uKYDT0eI9zOYW39RtV756AzYI2SAUd+CA2R?= =?us-ascii?q?RqmiyZq6fd1j6vI0qj7wvTrFCqL1O1DLIiZRCwIZiWE/E31b+G/9SAUOZygH?= =?us-ascii?q?9IQNsaVYkideic8IMsRoUoLd98R2uaEs/Dga+++kYuaT/nkBbOQ82Uc3lT4R?= =?us-ascii?q?E60gEgHUPza4Fv0t7GlDBxBlAe2e3I9VPrzKUwtRkYUTLW4HsbiLwrC5Li9+?= =?us-ascii?q?mWc9BA3B5b61L36aUYNBLXVOGBiiFIPBPPk2UYE/3d0i/pjXBYfQR8/ZzGhg?= =?us-ascii?q?9F81thLrrS7SBwiOevHn+F1vxxwQnAnYPYXouSYSZS4mYnJp6HcSFPthvkrB?= =?us-ascii?q?UcwOpAe8etfAGxS+7ofMj9lRh+ZgP2ewb+nRK9rnMtLESVBFOvzoVlpyTXfS?= =?us-ascii?q?P0hW52GHOPB5MRT23E7gcUmIBoXXOJBARIHUfgKS0Qn1o8rNa8D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AUDHKuKOxgR/qvcBcT3/155DYdb4zR+YMi2?= =?us-ascii?q?TDiHoedfUFSKOlfp6V8MjzjSWE9Ar4WBkb6LS90dq7MAzhHP9OkMQs1NKZPT?= =?us-ascii?q?UO11HYVL2KgbGSoQEIXheOi9K1tp0QP5SWaueAdmSS5PySiGLTfrZQo+Vvsp?= =?us-ascii?q?rY/9s2pE0dKj2CHpsQljuRfTzrdHGeKjM2YKYRJd653I5qtjCgcXMYYoCQHX?= =?us-ascii?q?8eRdXOoNXNidbPfQMGLwRP0njAsRqYrJrBVzSI1BYXVD1ChZ0493LergD/7q?= =?us-ascii?q?K/99mm1x7n0XPJ5Zg+oqqu9jIDPr3MtiEmEESutu+aXvUiZ1REhkFxnAib0i?= =?us-ascii?q?drrDALmWZlAy080QKXQoj/m2qS5+Cp6kde15al8y7fvZMmyvaJHA7TzKF69N?= =?us-ascii?q?tkm1LimjodlcA536RR022DsZ1LSRvGgSTm/tDNEwpnj0yuvBMZ4KYuZlFkIP?= =?us-ascii?q?0jgYVq3MUi1VIQFI1FEDPx6YghHuUrBMbA5OxOeVffa3zCpGFgzNGlQ3x2R3?= =?us-ascii?q?69MwI/k93Q1yITkGFyzkMeysBalnAc9IglQ50B4+jfKKxnmLxHU8dTZ6NgA+?= =?us-ascii?q?UKR9exFwX2MFnxGXPXJU6iGLAMOnrLpZKy6LIp5PuycJhN15c2kISpaiIuiY?= =?us-ascii?q?fzQTObNSSj5uw/zvmWehTPYd3E8LAt26RE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqBgDea4Ji/4wNJK1aHgEBCxIMQIF?= =?us-ascii?q?EC4EhMVIHdQJYOUOIGgOFMYUJgwKQSopxgSyBJQNUCwEBAQ0BASwBCgsEAQG?= =?us-ascii?q?FAgKFPgIlNAkOAQIEAQEBEgEBBQEBAQIBBwSBCROFaA2GQwIBAwEBCgYuAQE?= =?us-ascii?q?sCwEPAgEIRicLJQIEAQ0FCBqCXIIMVwMxAQ6fZwGBPgKKH3iBM4EBgggBAQY?= =?us-ascii?q?EBIE7AhBBgn8YgjgDBoE8gxSEJ4clJxyBSUSBFUOCZz6CYgEBAgEXgUgrg2C?= =?us-ascii?q?CLo8nhjoHOgNUgQUSgSFxAQgGBgcKBTIGAgwYFAQCExJNBh4CEwwKBhYOQhI?= =?us-ascii?q?ZDA8DEgMRAQcCCxIIFSwIAwIDCAMCAyMLAgMYCQcKAx0IChwSEBQCBBMfCwg?= =?us-ascii?q?DGh8tCQIEDgNDCAsKAxEEAxMYCxYIEAQGAwkvDSgLAwUPDwEGAwYCBQUBAyA?= =?us-ascii?q?DFAMFJwcDIQcLJg0NBBwHHQMDBSYDAgIbBwICAwIGFwYCAhlYCigNCAQIBBg?= =?us-ascii?q?EHiUTBQIHMQUEEB8CHgQFBhEJAhYCBgQFAgQEFgICEggCCCcbBxY2GQEFXQY?= =?us-ascii?q?LCSMWBhwBDwsGBQYWAyZSBQQfAZJZgx0IgQQJbEQmBC8DHwIUMhUgCgw0CA0?= =?us-ascii?q?pNwECOpISjVFDnxCBMAqDTIsalQwVh16geZZmII0HlE0mhGQCBAIEBQIOAQE?= =?us-ascii?q?GgWE8gVlwFRohgmhRGQ+OIINyhRSFSQF1OwIGCwEBAwmRGgEB?= X-IronPort-AV: E=Sophos;i="5.91,230,1647302400"; d="scan'208,217";a="991539237" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Oct 2022 23:41:52 +0000 Received: from mail.cisco.com (xfe-rcd-001.cisco.com [173.37.227.249]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 29CNfqRH011989 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 12 Oct 2022 23:41:53 GMT Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9; Wed, 12 Oct 2022 18:41:52 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9 via Frontend Transport; Wed, 12 Oct 2022 18:41:52 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q8mouFYLQ3z57M6gh6JwHSPxv4vXn0XA33ZHCub71AHVyc2h2rOIFCLsw64v/+xdb7s/E2pdEGVYxdkUlAEI/yHAVLGsNb8llaudCf9M/VNbngF7Ongo1Wu00FESJGN8I3io4V3qQ624NouW9yfM2PdSq7Jzmmexfw76KHq/6nBxWu2qYIdqGeHUNKwCrdP3Fq2hEbcG//Nu0NHmGoYG4vXXWOnbOaA/l/pDF8zUV1PY4JKbPeEMEb7k3xMoAHi5ZWkivSG0HDA9m2Dxu4wBtobzFRtUvZVcwphoU5GWS3rC0QehjamKVovggiLBbRJz8euKyxr3WlM0W3lbL+j9lQ== 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=f7bEIwNXGX4Fu/x5MOWqcBsGlpDyCZGE8my05jbm/hY=; b=M7whqABtlQ1p0as7fosnhtQyG+Z8vK4147v+te+bN5hP+36oVhsWtWgnjTcoOkKHEdTWi8aVAyGEt5hvmb69OVdve3IjTJYVa6zTpqwolyPlqrl0RbLYoijMA8UAZwkuSq62wz0owET+Umsbm30yaZBoFKzY3qrxZFvyx8Lex/0u/Q3ehqUQuMGNt/Funibk0vOGbc/8taGVay11go7nKQuChYjw9NOLIp5+RIZW2owBdbamYch8lxpQuNtuaTwMVNVy0XGV+Dy0DZPvVQtC30AjFRZptxPB9Tm5FpIe+XSrPeZjRaRqyxjp2ERJqaqal7yaZJ0w5B+oQMG4q110ZQ== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f7bEIwNXGX4Fu/x5MOWqcBsGlpDyCZGE8my05jbm/hY=; b=S/i0u19aitQ1WOtxDhnaaRkPcr75Xpf5XcfBICwojxpLduQrN6eBBTPh26tMXxWBywDxONkWwbdMPiZBJZZ/bycIoGFWx+Sb/sLeUGtNO1hryYRpIYDUvFyMQn/nFArTiKKzbajGteUWf2YoMdbUpfEXyjWL4F9/xmZ6Yy47kNk= Received: from MW3PR11MB4651.namprd11.prod.outlook.com (2603:10b6:303:2c::21) by PH0PR11MB4886.namprd11.prod.outlook.com (2603:10b6:510:33::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5709.15; Wed, 12 Oct 2022 23:41:50 +0000 Received: from MW3PR11MB4651.namprd11.prod.outlook.com ([fe80::3ce:16a8:57d8:6fea]) by MW3PR11MB4651.namprd11.prod.outlook.com ([fe80::3ce:16a8:57d8:6fea%8]) with mapi id 15.20.5676.040; Wed, 12 Oct 2022 23:41:50 +0000 From: "Tim Evens (tievens)" To: "grow@ietf.org" , "i-d-announce@ietf.org" CC: "grow@ietf.org" Thread-Topic: [GROW] I-D Action: draft-ietf-grow-bmp-tlv-09.txt Thread-Index: AQHY3jbqs8L1/Dxx0U6wfNaXxiWqsK4LWDSf Date: Wed, 12 Oct 2022 23:41:50 +0000 Message-ID: References: <166557802649.20435.9750985827482712643@ietfa.amsl.com> In-Reply-To: <166557802649.20435.9750985827482712643@ietfa.amsl.com> 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=cisco.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: MW3PR11MB4651:EE_|PH0PR11MB4886:EE_ x-ms-office365-filtering-correlation-id: 8416a49f-6317-41a7-54e0-08daacab558e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wQwv2fdTFyqUKzzPhLRBtVpadqtPAsLjEiGDZPv6nRZdY1L/RvQ45cO/vvFKaOGEcNoxXBgOMiP5F2IzK/jh1A3qgWNgHaIj23Oa+GNg3VyjJdaoev5U8LjM84YkPcM8xysVbL8sJZ5/JPyA/I+NeXF1fCGI9eiUPT+dJ5aQPh+VNE9ZB+ko3jbzUOiMGwg5hQuW/Qjd8p7mvdr+Q4OgqlcuWiBOITMbSbmG1uEkXMtaIuDLVby548hCRDrX1ZcRirmFT1IvBPnQ9RdIsZgIHZf50knIJfzV7W62b3JdHmmSa890ZKqMY4NE7wqF/HL9NpwoK4CIDjalDiMx/yRfGzq65NK2DzBXU9YLihf056qflgZdvGFe61OuT+rkVZ0RzNw6PFjQHL0EFTzw9wXDlTWAoM8RaRtIFsk0FiGVhOfpjP+O+3aQv/incL4WKC8NzLchGGT9T5jFSQHFW5bV/wQvR4SREAIIxKdBeddsCvNBVJzjLdhXMr31Xl4zIrRZ9GFsKmPcsue/wgpjFjB1QH+N9uOKlmQ+pwHqtRk6IBbdfTbZ+bW/kFbBK5kk+mDXveM2Tx/zeLF4fioJBdU8sN1KzBYGluFkexBo85gzze8wMDdC57VW95ztuljevolJV64PhaPZIDmrBzVjUSF0phdORrehhAVbAUA/pn3Vacf1LFWRYYqlJzjPAcLufFv3Jtt4cWTBNJr/PA/Qk5REKfz3d88K0TtoFKDgNfFj/1syiwevd6DTudmouufdH4qrw55Mh2EDGnkKXj3O9y7AIE762gfz0TZAGQ5fZLm6XYTMEHfpWlkSWyOFE9D5DKXySg6zOuA2im5Gk2Vw9asxiQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4651.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(366004)(136003)(396003)(346002)(376002)(39860400002)(451199015)(7696005)(71200400001)(9686003)(6506007)(966005)(86362001)(110136005)(55016003)(122000001)(33656002)(38070700005)(38100700002)(316002)(66574015)(53546011)(478600001)(166002)(186003)(83380400001)(4001150100001)(2906002)(5660300002)(8676002)(41300700001)(52536014)(64756008)(66946007)(66476007)(91956017)(66556008)(8936002)(450100002)(76116006)(4326008)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?iu2Ne0cQS3FONssKh6kE2wE1w7xQJes0nKlPkxXLVtTOIg2sh2FSJa4z?= =?Windows-1252?Q?/cuoVbVNkz41sJzDMDLfjfusOewPTlzK5OTCBi9pJNg8LN9v4atw6Xi3?= =?Windows-1252?Q?kKRz69Yk9rCgnEL3sOZFZDrXFMianAfuF2hStkURkwRhiNKFn8/RVBVK?= =?Windows-1252?Q?wB9Kv8ut8uFwW/aK6gXmusU4wJq+szUTHlT6e4b3V/fn9KkxWb5oBwVA?= =?Windows-1252?Q?1LhCEFQQrIuSgq/COO2+/G7c8Uze8ep3xVx4MycjOAsTAx0VC5tap5xC?= =?Windows-1252?Q?nWRzS17uHQ8/y389QLJIxP5cmxGqqIOh8eUcgyS/5rbv1fFKB1Eq0eHj?= =?Windows-1252?Q?65db9Up/8lJ/MEDG1Ao1uLoYCZI4Sc1VGqN/M4UlOGzG6cM1QEs+WeCe?= =?Windows-1252?Q?8F6BztxKEXIt6Re++irhRxXfbxaoNrlznAu4IjdxQVG6FLPsRZ0309KP?= =?Windows-1252?Q?L3U2xCjOjihRIzdCcsA2SGuJr/IdfhrbSNXsNxzgpLjbouGVXJTYAE6C?= =?Windows-1252?Q?ClGKTSyvlAcLXFISgschNJW08Klq8krJE5kc2j+o4jSXDo6eurflz5h6?= =?Windows-1252?Q?r+GctPtqrlBygIh/B6Tdp94nqAaU2uy7e3i5+TnTu7heXWIQlHNXLQDt?= =?Windows-1252?Q?rU9nNEwmyVofl/tCn2RCfrfyCCOS9SmGA8hgt39rjiLtQkL81+/X8TNo?= =?Windows-1252?Q?hgzFdmoKiskjuQZyVG2H7vL5Qqn/bapuZL97T4aWlaKnWEX5T870cBAR?= =?Windows-1252?Q?lkF3qT81hRL8tOZXVJkbSsLlOP8jROO8aDtztzdXYz0NDLYNBS+hP6EW?= =?Windows-1252?Q?Jle9Svn/xEs3GeZoGJzWqupG5OTAFJ45gglpsw7CdoToJoVMebUJNnZe?= =?Windows-1252?Q?n83Y/p4RDBU7z4UOa894Rk97HvYyxIweW9ZCYjuXqlt1lhAg9QErsz8T?= =?Windows-1252?Q?G5fcfUgHrB6Mu2S5SLUrCTgoJJ3rE2cPllDhOKTC2/XWhupLVDitvg1h?= =?Windows-1252?Q?pLkAvU+vZsuTj+d1HlotxZk2otNM7d81M9nuo94xBqyRYuuCO9xbMGg/?= =?Windows-1252?Q?Fq2P8FzHKv7S4cQ+k34/u4SLb7Zd45cVaYJVyJzoeYYdjtBHMOD9J4AP?= =?Windows-1252?Q?erlOtxoaVCzWC6OZoMy1jO8ycNEvFwPF9Vk0y2AkH8MM/W101rLIfdvY?= =?Windows-1252?Q?eNxhNEpuZPGjZpOpYtEnGA1fU/AW+CP7paWfJR+YCyhUyGH3/ryOyTJ1?= =?Windows-1252?Q?0IPDEWfqg4g8ZeQwx32Wzs22QTggfnfQoeDFYynn2V0F0QKkT45NcQBj?= =?Windows-1252?Q?HRuPR7He27MQSXHyf/MfmFVPabQbry9P4wkZJsF6RGFegfuHzIPI1fBx?= =?Windows-1252?Q?8vciAQlcUhdYaEhFj7kRXNdWKgnRRJw9pOFgQl2AWNgn5B21jwM1C9ck?= =?Windows-1252?Q?chMyekttKGiaLBrd4j+n+LnEA5YTLRW1SZszr8Ag5rAQti/pWPj2tGZm?= =?Windows-1252?Q?A+/34/Pg21znvvWj0ouFCFjXUVYTzP+UcgA7UmO71sDP53+/vEBYq5qQ?= =?Windows-1252?Q?1pQN1cuxSavjR47/DrisXIxwvFbnDz43TEyI+OoVc6I5IRM8WGcqlZ7v?= =?Windows-1252?Q?nwPqtMQFSxJcddFMcSseip/KMk6G+lQji0vfHdSV6jXT7ZbJocJgCISo?= =?Windows-1252?Q?KtyxjYcuqQ8+WGQ7vghhiaS3I+NmQDxhoa8nM0pnssiJjoEbjDKl5lk6?= =?Windows-1252?Q?Oji9Mp+RnYPpZ0Ttpug=3D?= Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4651B4FC4F2EC038C0ADBB5FB6229MW3PR11MB4651namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4651.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8416a49f-6317-41a7-54e0-08daacab558e X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2022 23:41:50.0810 (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: 4pBAMyrTa4cS9UAJ/N2fM4YCFcLdqmQgMmkA9bJRZhKo2hMHXIssncD0OU/jBKjmDoridv/y8PtugB64XWnjuA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4886 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.227.249, xfe-rcd-001.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [GROW] I-D Action: draft-ietf-grow-bmp-tlv-09.txt X-BeenThere: grow@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Grow Working Group Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2022 23:41:58 -0000 --_000_MW3PR11MB4651B4FC4F2EC038C0ADBB5FB6229MW3PR11MB4651namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Paolo, Yunan, >From section 1, intro: =93This means that both Route Monitoring and Peer Down messages have a non-= extensible format.=94 The above has been updated by section 5.3 RFC9069 where reason code 6 inclu= des TLVs. =93The proposal of this document is to bump the BMP version, for backward c= ompatibility, and allow all message types to make provision for trailing TL= V data.=94 Do all messages have to be version 4 for a session or can a BMP session use= both versions based on the need for additional TLVs or not? Some comments: * The main use-cases call out route-monitor and peer down messages that= didn=92t have optional TLVs. RFC9069 updates Peer Down with reason code 6,= that indicates TLVs to follow. Might make sense to use that instead of ch= anging it in version 4. * Instead of sorting TLVs by code point/type/=85 , wouldn=92t it be oka= y to process them in order as they are encoded? In other words, let the sen= der define the order by how the sender encodes them. Having to sort would r= equire buffering to process all TLVs so they can be sorted before processin= g/forwarding on. * To me, encoding per NLRI characteristics in TLVs with indexing is dup= licate of attributes. It also could get large when a handful of NLRIs (shar= ing the same BGP attributes, packed into the same message) have different o= r shared BMP TLV characteristics. For example, 10 NLRIs packed, 8 of them= share characteristic A and the other 2 share characteristic B. The TLV ca= nnot be indexed as 0 because all of them do not share the TLVs in common, r= esulting in 10 TLVs being needed. * The current TLV types suggest the primary use case is per BMP message= conveyance of BGP capabilities that effect how to parse the message itself= . Such as add-paths, multiple labels, =85 ASN encoding is already indicat= ed by the =93A=94 flag. Both RFC8277 and 3107 are the same in terms of deco= ding multiples of label 3 octets in length minus the prefix length. This ca= n be handled stateless still. RFC8277 does clarify what to expect in terms= of number of labels, but from a stateless standpoint can=92t we still proc= ess it as defined by 3107? This draft focuses on stateless processing, whe= re the Peer Up with the OPEN message was not seen and/or not considered. I= believe the only capability that is a problem is add-paths. Add-paths coul= d be handled with a new flag. I believe all the other BGP TLVs are defined = well enough to process the message without having to see the OPEN message e= xchange. Are there others that cannot be processed stateless? * A VRF name is conveyed via Peer Up and Peer Down and not included in = each route-monitor message. Strictly stateless, the receiver would not kno= w which VRF name the per-peer header correlates to without having some leve= l of state correlation of per-peer header values to Peer Up/Down. Maybe for= VRF name it doesn=92t matter, but at some point receivers are expected to = keep some level of state for peering sessions. This is needed with RIB stat= e tracking and route-refreshes, which may come in via route-mirror message = or another/repeated Peer Up message, but not in the form of a route-monitor= message. Thanks, Tim On 10/12/22, 5:34 AM, "GROW" wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Global Routing Operations WG of the IETF. Title : TLV support for BMP Route Monitoring and Peer Dow= n Messages Authors : Paolo Lucente Yunan Gu Filename : draft-ietf-grow-bmp-tlv-09.txt Pages : 7 Date : 2022-10-12 Abstract: Most of the message types defined by the BGP Monitoring Protocol (BMP) make provision for optional trailing data. However, Route Monitoring messages (which provide a snapshot of the monitored Routing Information Base) and Peer Down messages (which indicate that a peering session was terminated) do not. Supporting optional data in TLV format across all BMP message types allows for a homogeneous and extensible surface that would be useful for the most different use-cases that need to convey additional data to a BMP station. While it is not intended for this document to cover any specific utilization scenario, it defines a simple way to support optional TLV data in all message types. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-tlv/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-grow-bmp-tlv-09 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-dra= fts _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow --_000_MW3PR11MB4651B4FC4F2EC038C0ADBB5FB6229MW3PR11MB4651namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Paolo, Yunan,

 

From section 1, intro:

=93This means that both R= oute Monitoring and Peer Down messages have a non-extensible format.=94

 

The above has been update= d by section 5.3 RFC9069 where reason code 6 includes TLVs.

 

=93The proposal of this d= ocument is to bump the BMP version, for backward compatibility, and allow a= ll message types to make provision for trailing TLV data.=94

 

Do all messages have to b= e version 4 for a session or can a BMP session use both versions based on t= he need for additional TLVs or not?

 

Some comments:

  • The main use-cases call out route-monitor and peer down messages that= didn=92t have optional TLVs. RFC9069 updates Peer Down with reason code 6,= that indicates TLVs to follow.  Might make sense to use that instead of changing it in version 4.

 

  • Instead of sorting TLVs by code point/type/=85 , wouldn=92t it be oka= y to process them in order as they are encoded? In other words, let the sen= der define the order by how the sender encodes them. Having to sort would require buffering to process all TLVs so they c= an be sorted before processing/forwarding on.

 

  • To me, encoding per NLRI characteristics in TLVs with indexing is dup= licate of attributes. It also could get large when a handful of NLRIs (shar= ing the same BGP attributes, packed into the same message) have different or shared BMP TLV characteristics.&n= bsp;  For example, 10 NLRIs packed, 8 of them share characteristic A a= nd the other 2 share characteristic B.  The TLV cannot be indexed as 0= because all of them do not share the TLVs in common, resulting in 10 TLVs being needed.

 

  • The current TLV types suggest the primary use case is per BMP message= conveyance of BGP capabilities that effect how to parse the message itself= .  Such as add-paths, multiple labels, =85  ASN encoding is already indicated by the =93A=94 flag. Both RFC8= 277 and 3107 are the same in terms of decoding multiples of label 3 octets = in length minus the prefix length. This can be handled stateless still.&nbs= p; RFC8277 does clarify what to expect in terms of number of labels, but from a stateless standpoint can=92t we still proc= ess it as defined by 3107?  This draft focuses on stateless processing= , where the Peer Up with the OPEN message was not seen and/or not considere= d.  I believe the only capability that is a problem is add-paths. Add-paths could be handled with a new flag. I b= elieve all the other BGP TLVs are defined well enough to process the messag= e without having to see the OPEN message exchange. Are there others that ca= nnot be processed stateless?

 

  • A VRF name is conveyed via Peer Up and Peer Down and not included in = each route-monitor message.  Strictly stateless, the receiver would no= t know which VRF name the per-peer header correlates to without having some level of state correlation of per-peer h= eader values to Peer Up/Down. Maybe for VRF name it doesn=92t matter, but a= t some point receivers are expected to keep some level of state for peering= sessions. This is needed with RIB state tracking and route-refreshes, which may come in via route-mirror mes= sage or another/repeated Peer Up message, but not in the form of a route-mo= nitor message.

 

Thanks,

Tim

 

 

 

 

 

On 10/12/22, 5:34 AM, &qu= ot;GROW" <grow-bounces@ietf.org> wrote:

 


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Global Routing Operations WG of the IETF.<= br>
        Title    &nb= sp;      : TLV support for BMP Route Monitoring an= d Peer Down Messages
        Authors    &= nbsp;    : Paolo Lucente
            &nb= sp;            = Yunan Gu
  Filename        : draft-ietf-grow= -bmp-tlv-09.txt
  Pages           : = 7
  Date          &nbs= p; : 2022-10-12

Abstract:
   Most of the message types defined by the BGP Monitoring Protoc= ol
   (BMP) make provision for optional trailing data.  However= , Route
   Monitoring messages (which provide a snapshot of the monitored=
   Routing Information Base) and Peer Down messages (which indica= te that
   a peering session was terminated) do not.  Supporting opt= ional data
   in TLV format across all BMP message types allows for a homoge= neous
   and extensible surface that would be useful for the most diffe= rent
   use-cases that need to convey additional data to a BMP station= .
   While it is not intended for this document to cover any specif= ic
   utilization scenario, it defines a simple way to support optio= nal TLV
   data in all message types.


The IETF datatracker status page for this draft is:
https= ://datatracker.ietf.org/doc/draft-ietf-grow-bmp-tlv/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-09

A diff from the previous version is available at:
= https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-grow-bmp-tlv-09


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-dra= fts


_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org= /mailman/listinfo/grow

--_000_MW3PR11MB4651B4FC4F2EC038C0ADBB5FB6229MW3PR11MB4651namp_--