Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 08 June 2022 01:39 UTC

Return-Path: <ginsberg@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 92CFBC14CF01 for <idr@ietfa.amsl.com>; Tue, 7 Jun 2022 18:39:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.624
X-Spam-Level:
X-Spam-Status: No, score=-9.624 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.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, 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=an0q5BcG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ooVuwSYa
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 RPcHjpK3Z-tu for <idr@ietfa.amsl.com>; Tue, 7 Jun 2022 18:39:26 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEEE6C14F72B for <idr@ietf.org>; Tue, 7 Jun 2022 18:39:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43464; q=dns/txt; s=iport; t=1654652365; x=1655861965; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HMybGt05cui85lXm+w3YYbalL4ZKwm3Jx5bepS2nxCc=; b=an0q5BcGULuLVg/FJnCmrb04J96tXJJykGwNXz9x1q5jTsbDvL9D3VrH c8V+OGPIjC2lWTgU7nLJOaDL1/SBXuqOh6NQG4IFWnlg8MpPk+g6MLI8l B3N/ZbFoO0NOu+G+iULUdfM0RjidupXdsNba8qVVsul16qqBjw9FyzgAl E=;
IronPort-PHdr: A9a23:dgY9fxxdsQIls5zXCzPZngc9DxPP8534PQ8Qv5wgjb8GMqGu5I/rM0GX4/JxxETIUoPW57Mh6aLWvqnsVHZG7cOHt3YPI5BJXgUO3MMRmQFoCcWZCEr9efjtaSFyHMlLWFJ/uX+hNk0AE8flbFqUqXq3vlYv
IronPort-Data: A9a23:GdvJqaudOBX7v0ZPeNXocEBqSufnVJFcMUV32f8akzHdYApBsoF/qtZmKT/Vb6veNmDyfdl+aYvjoBsP757Rm95gHVY4/CgyF38SgMeUXt7xwmUckM+xwmwvdK/shiknQoGowPscEzmN/39BDpC79SMmjfzRGOKlYAL5EnkZqTFMGX9JZS1Lw4bVsqYw6TSIK1vlVeHa+qUzC3f9s9JACV/43orYwP9ZUFsejxtD1rA2TagjUFYzDBD5BrpHTU26ByOQroW5goeHq+j/ILGRpgs1/j83Ad+j1738aEBPHfjZPBOFjTxdXK3Kbhpq/3NplP1kcqtHLx4L0F1lnPgpoDlJnZOxTxwjM7fDsO8cSBJfVSp5OMWq/ZeeeSPu75DNlhKcG5fr67A0ZK0sBqUZ9vxfAGxS+7ofMj9lRg+Kge2/wbCmTMFwncUlI8n2NcUYoH4mxjexJe0mSIrOWI3M6c1Ymjw3g6hz8Vz2DyYCQSBkYBKFaBpVNxJITpk/h+yvwHL4dlVlRJuujfJfywDuIMZZidAB6OboR+E=
IronPort-HdrOrdr: A9a23:O7LM4a5VMlkmKQ73WQPXwYaCI+orL9Y04lQ7vn2ZFiY6TiXIra+TdaoguSMc0AxhJE3Jmbi7Sc29qADnhOFICOgqTPiftWzd2VdAQ7sSlbcKrweQeREWs9QtqJuIEJIORuEYb2IK9voSiTPQe71Lrbn3k5xAx92utUuFJjsaDJ2Imj0JczpzZXcGIjWua6BJcaa0145inX6NaH4XZsO0Cj0uRO7YveDGk5rgfFovGwMnwBPmt0Lo1JfKVzyjmjsOWTJGxrkvtULflRbi26mlu/anjjfBym7o6YhMkteJ8KoCOCXMsLlXFtzfsHfsWG1TYczHgNnzmpDp1L8eqqiPn/7nBbU015qeRBDtnfKn4Xif7N9n0Q6S9bbfuwq6nSQ8LwhKUfaoQuliA0DkAgMbzaFB+bMO0GSDu5VNCxTc2Cz7+tjTThlv0lG5uHw4jIco/jdiuKYlGfZsRLYkjQto+VY7bVbHwZFiFPMrANDX5f5Qf1/fZ3fFvnN3yNjpWngoBB+JTkULp8TQilFt7T1E5lpdwNZakmYL9Zo7RZUB7+PYMr5wnLULSsMNd6pyCOoIXMPyUgX2MF7xGXPXJU6iGLAMOnrLpZKy6LIp5PuycJhNyJcpgpzOXF5RqGZ3cUPzDs+F2oFN73n2MS+AdCWoztsb64lyu7X6SrauOSqfSEo2m8/luPkbCt2zYYfEBHuXOY6VEYLDI/c64+SlYeggFZA3arxhhuoG
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BtAAB2bIJi/49dJa1aHQEBAQEJARIBBQUBgXsIAQsBgSAxUgd1Alg5Q4ROg0wDhFJfhQmDAgOBE480inGBLIElA08FCwEBAQ0BASwBCgsEAQGFAgIWhSgCJTQJDgECBAEBARIBAQUBAQECAQcEgQkThWgNhkIBAQEBAwEBEAsGChMBASwLAQ8CAQYCDgMEAQEhAQYDAgICJQsUCQgCBAENBQgXA4JcggxXAzEBDkOPbY83AYE+AoofeoExgQGCCAEBBgQEgU1Bgn8YgjgDBoE8AYMThCcBAYMIhBsnHIFJRGYuAUOCMDc+gmIBAQOBXyQHCYMgN4IuY5Iggl4HOgNUgQUSgSFxAQgGBgcKBTIGAgwYFAQCExJTHgITDAocDlQZDA8DEgMRAQcCCxIIFSwIAwIDCAMCAyMLAgMYCQcKAx0IChwSEBQCBBMfCwgDGh8tCQIEDgNDCAsKAxEEAxMYCxYIEAQGAwkvDSgLAwUPDwEGAwYCBQUBAyADFAMFJwcDIQcLJg0NBBwHHQMDBSYDAgIbBwICAwIGFwYCAnEKKA0IBAgEHB4lEwUCBzEFBC8CHgQFBhEJAhYCBgQFAgQEFgICEggCCCcbBxY2GQEFXQYLCSMcHAEPCwYFBhYDJlIFBCCSWYMdCIF5DiM5AQMvARsIIAImCAsYDUsCEQYGKQEBKDqRbQUfg1mJeY0IgQCSewqDTIsahweGaYNmgzYVg3VIi3aNQopihx6PSCCNB5RJEgoBgWKDDwIEAgQFAg4BAQaBMDE8gVlwFTuCaFEZD44gDBaDUIUUhUp1OwIGAQoBAQMJkRoBAQ
X-IronPort-AV: E=Sophos;i="5.91,230,1647302400"; d="scan'208,217";a="1039646172"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jun 2022 01:39:24 +0000
Received: from mail.cisco.com (xfe-rcd-001.cisco.com [173.37.227.249]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 2581dOAW001000 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 8 Jun 2022 01:39:24 GMT
Received: from xfe-rcd-002.cisco.com (173.37.227.250) 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.986.14; Tue, 7 Jun 2022 20:39:23 -0500
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Tue, 7 Jun 2022 20:39:23 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V5RIbSTF4TIJERXL/hfn5RvdgfMY5QKdx7hARLZwSWBRSrwC/OxOYpz6OiUCm82etx57GBpq0lZzFRBhX2ybFlhIMlfgTz14E5y6bWjxLQC8oc08wSShQcTofg7eS8ZySuIsKoW4L+fsdjmgaOeOIdsovdgkpNTSaBSYUDbk2xU2lHYaSZCytoe5bFL82a3tsrnpdB5sTkuQuR5tByEmrSN38UO2B/PNQq2b7QpzBTzWusZwBhc8D8ci0mjgaLLil/NZJIUMTevu61vKYFDpSZ2uMbgdo3d9lkPAGrwTxaYjllMd/eiS9kUsX5R70A1xOEqcT2rD2Qf3admj2xtcIA==
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=HMybGt05cui85lXm+w3YYbalL4ZKwm3Jx5bepS2nxCc=; b=A1lrlKdq6sdFZbLy6te5akGQUyYHQ7opyecw5RvY/AsmQXeiSTVTuyXfbs52N9cUCr30pXt7cyToZLt2fklUCm9rHtRz0pQXjM21rdJI5IcG2BkqJvYkiZ+J8SmXeEKNFOXltAaCyZCfVHUG0nwoM0MLTTgYfeZbCzg+nR5vtfydReDgsdB0W7WFIx2I+qtwKdqcMWqT0DHYI53IsdFNKILPe8p54NtZRz8a3jZoJm/51KGUsMFlfa+8S/O7eODAMo38SJSmeftC/Oi6lmeLpBRdqLU9IMYaDBU3dGcwBBLvIpYvIk1gRcONR0wA7fSzG0P3+BEvYnGJKugJFD5jEg==
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=HMybGt05cui85lXm+w3YYbalL4ZKwm3Jx5bepS2nxCc=; b=ooVuwSYaMID4GgTNplN+/MzPmKWOJjUTEv16kI9YBvVhaoe8FuzWxN1pSeyM/HkMTTHrDSQOuzlvthRP7sUoFYDJ/mgS95Kb6Pu0M3qQuQkT2ECaKTrrYfu8z/Xkj3uNU3vIjWqgxT3g3sipVdhPKtpcKAOqblni66zP4/Qm5yA=
Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by MN0PR11MB6033.namprd11.prod.outlook.com (2603:10b6:208:374::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.19; Wed, 8 Jun 2022 01:39:22 +0000
Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::8464:28ca:3a3d:cf5f]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::8464:28ca:3a3d:cf5f%7]) with mapi id 15.20.5314.019; Wed, 8 Jun 2022 01:39:22 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Susan Hares <shares@ndzh.com>, Aijun Wang <wangaijun@tsinghua.org.cn>
CC: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)
Thread-Index: AQHYen4UlVQY9V86IE6lXfnEzYj2Va1EbIgAgAAe/GCAAA2sAIAAA5nwgAAT5ACAAAjCkA==
Date: Wed, 08 Jun 2022 01:39:22 +0000
Message-ID: <BY5PR11MB4337E9C8F39A7512FC8808DEC1A49@BY5PR11MB4337.namprd11.prod.outlook.com>
References: <D2506157-B374-4C95-93F9-C992F2BC7BAE@tsinghua.org.cn> <BYAPR08MB48723BC505CEC00DDA9870B2B3A59@BYAPR08MB4872.namprd08.prod.outlook.com> <BY5PR11MB4337153D1D387C125A822F12C1A59@BY5PR11MB4337.namprd11.prod.outlook.com> <BYAPR08MB487281C781BB66A00803B9ECB3A59@BYAPR08MB4872.namprd08.prod.outlook.com> <BY5PR11MB43370655CE2A2406B394C901C1A49@BY5PR11MB4337.namprd11.prod.outlook.com> <BYAPR08MB4872AB7D94218FFD4FF236D5B3A49@BYAPR08MB4872.namprd08.prod.outlook.com>
In-Reply-To: <BYAPR08MB4872AB7D94218FFD4FF236D5B3A49@BYAPR08MB4872.namprd08.prod.outlook.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-office365-filtering-correlation-id: 95a1980d-7110-4b17-4d3a-08da48efb663
x-ms-traffictypediagnostic: MN0PR11MB6033:EE_
x-microsoft-antispam-prvs: <MN0PR11MB603312D6787BAEB5CE8AC136C1A49@MN0PR11MB6033.namprd11.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: z0BEzvCjiI6JFD15zvztp3aa71XAOorUjF7wm16ZOIiqKvI+2nL5N+lvnSpq8X9H/hobHJP+89vKK3TIdysilVMiQzMeW4AQbOBTZGHngC1AvHWYWN2k7rWwbXX8GVNnBd9/0Ykol1aIAU71mo8+1ConyH88AjrqH91hGVe6C4q8khCiT1aLzc/taXxcR6Vcz9vJ4VhWOR4a5IjBpQWyMrWxS7qW/68NdNQESkGPFhF/Omc/PH5b3hKNeoCrCmxJGJl5oqBppEvlJbLwWWaXIJoqdkuMQiuoqELDjQ9Ds1VXbEUjDKNxhKegjMxod6xtZK7Qj/lYtyReCqOLgnVkqgG/bqo9M8LE5LoUyEOA6VFqXu2GlWaU3NvPZvawhMHgtlvuDrQlZXUFqA2khWPTNDHKdSpewqn0oLTSVVLiRGM5zR2lEd4/1htk93h1swIW1rY+H/Jux87caVy3YORnT1kO/ebTs8T503v79vmLBPN62z73CUdyi9Ya3Zcg61BDbIAyWx+Pxd83LwdOlDrbwVsLM3TreBdVSQ1+OdyyL5D0PzdFFw/fIynkIygwTVlDOp05tyMNipmDyytct1KdDYv2+fKOWJ+D3Lo5EruJJgxwSs8yVtaIt40I6b3emXThY+6pAV+NpMj+9D0nOieu3bz6kiWHznUDClb2VOZc16lSD9pScTofcB3JIYc7wgO7hUarZmPUPHhqObFiXXgrkEbfg+YRUxpItzjmeexCsbIukU1ljTQ9k0Cbib2z25kcoRZequ08mTXzEv2ZRU8ew9OVy4iwH3YELgt8rWUh6WTJXE6xNACjA4sfXDgB7s81KT8ol1PZnhb1KTx9Vbfnvw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4337.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(6506007)(53546011)(55016003)(186003)(86362001)(52536014)(38070700005)(110136005)(8936002)(508600001)(66946007)(76116006)(66446008)(64756008)(8676002)(66476007)(66556008)(4326008)(316002)(7696005)(33656002)(2906002)(9686003)(966005)(71200400001)(5660300002)(38100700002)(83380400001)(166002)(122000001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 2
x-ms-exchange-antispam-messagedata-0: keaZn9bZ3N7xCe4hjuRvndncmvFfZedf4mgIlBkKdqbwXEII+Kyvr+MuaccKCHmyy7A+/NDyyIe1PoGv1dUNCC7Y0F2S/wAgxCHKxOGI5GWdmqGLzw1qjNkpXWQMU2QxW3Whp4MCITEC838IbVNkUBGFQuk5YBjMRZF1tFNirHybx7DYPmSSBKDJleAhZLYmAO+jxIMY9+nertYeu3kIVSvTZKKcBV4mHIOJHjf/mHVfysOZO/xdR8xvASWgF4t4qYGwEPZCi7Vgf0lty8wsT7Djy5DZByhfWA/cBq0bmLpz7fL1OjjD4ctYqIP8rtXiLQ/GlSXllixnmKFulX31rQtsb+G1yCnDNkOD/nOeP2m2BRF8YhVpOy2RjxB3GCyuGt+D3r2TFGewTcEUNI2jA3ChfRjmVDrZ1mH3o1JmzTGyBHQq9mjmNz0CNbqzQTDBMTYh9Jd54QJ2L5bScXrDokTbWYvsp3yrWwxni0yPi6DvWeCICphfZSwMyQ/eVTMI+U8RmxgdNTMl4rEoWEZnUTEMl2Iox0rwKyxJ0dryc7kj95Zdo5iQ756bniJ3KyQd+lE6qxQ35zAhDhPRnr77GAZfAMeP2Ug9le/RBtP8ZAd6VzDjVpA8stvMyBvt9qunPhd/578xB6t/gQawwakb/MDfCxXd/NfXmYIJM2MIPM8Dm2BXckFcq70HclR3V0pfU/XPJRTk3tzQTNnsToErj6qlom/a8vQtRJ/n4vdYFQNJP/B6MMsy/WMAPdw0FjKsMp2t8gmtpTZUWxw6Y9m/xg4HgditVxFU1DqYiRpB+PnnW3O5gZjLLVArP3BDQYcvjjxU+giAbN/SgaVLMJ1c/OjhCfFgb7YiQzw6MQ6GguVLBNhOR/f8C8QrmnovG5MPfZe+Ccq5OmPuqqwiKw0agbff8XpgUhhcgT3o4e5cnmq1ibwBf68ORolTfK9/4JxAbn1Dyw5qOKBkGlOIn68lvAZWWsTJSIFohY7RJwcUp2RVbddVLkhxxo1nAvEaLRY0DPJluuUomhqOAJYmgGsEv8voRv4dTPMML6vPsLKlT+mhuVFOxpbN5MXlV8iQ9O0Zp37vO+P5pyxkVrMeHvpar4FRe5tqoVWSQ8cj3RG9yVQVdVriPQCHiQmRePwz/y3afXydyepm6xEy7L78F48VdXA4BxF1a+BdIx48S6TO/ViH1+0IctlGRuaik47xXFTMssqgm3yoJoh5uPCYlEaNosD8fZQZkcgoiKHW6PrC9R+IAy+jr4Num+BEjzQ/Hraj5wePSTDZ6Oqy+k9nd3yK9V8/vZT68C1PtQcjuywHTb1JFcoxU38cmt9FTNH6G7O7gJoOOrhz/6t0nX/2ALEKiaW5JgIzUHS2gZLy6+ZVIotcaVsGHjTW1xtjYSEz+0hc6N5TGkj9gpBvzuvwri7/cyyqByDVSIXkX70YntupsA33FIrCufDgwXle4ptMg52ilek5W6fwrex09ccQfXIHcBRUhSm6lT4bcjAV7XUe6NCg7xhpZ/mntPh9h8lw8BWs7fZMYffh0dILT/WsnsP9J8h5pzD98oUTQT6755kSY0+fIhJeVejRXsWOZ+VUKrxnxpkHqljIAjcv2EUCUsqFTd/MSRYPg0hCjiilZ6wyf6gKrBCBzkQ/sx6ueAXFVbTjyn4EDCZCW2PcJFFdH1QOi7UPZhs0J+STfTv9ECkhZywCf6lvGsC+V60v6TtEx70NPBkWJfB/gxj2Ze/z6DHnXhDR0MhE1xaSxKwzCMtQiZPaIfc19jQcVbeSnABimNIjXNnMbw++
x-ms-exchange-antispam-messagedata-1: /GLWmncR1dII0g==
Content-Type: multipart/alternative; boundary="_000_BY5PR11MB4337E9C8F39A7512FC8808DEC1A49BY5PR11MB4337namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4337.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 95a1980d-7110-4b17-4d3a-08da48efb663
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2022 01:39:22.0535 (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: uzfBhmZ6Nk/5LvaMPMAkVACR1Rm3T6H/XywdYwjz1/xotRCkQZ7jlVt7Il/dAJqH4yOANDJ9k0grlOdoXl0S/A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR11MB6033
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.227.249, xfe-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Q02BWplHsEC6d3SpN3OXLZVgeqE>
Subject: Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)
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, 08 Jun 2022 01:39:30 -0000

Sue –

Thanx for the followup.
I started this sub-thread in response to your statement:

“…It is important to know if an operator feels this option will not be deployed.
I  will contact other operators to ask them to comment on this adoption call.”

I interpreted this to mean that you felt it was IDR’s place to decide whether a given IGP extension should be supported or not.
I believe this is not within the charter of the IDR WG. The LSR WG gets to decide what IGP extensions will be approved – and the WG has already made that call in regards to draft-ietf-lsr-isis-flood-reflection.
For IDR to say “we won’t allow the BGP-LS extensions draft for this (already approved) IGP extension to become a WG item” indicates that the IDR charter now allows it to make IGP extensions non-deployable (due to lack of BGP-LS support).
I don’t believe this is within the charter of IDR.

IDR certainly has the responsibility/right to review proposed BGP-LS extensions for correctness.

As to whether the IGP extensions will ever get deployed, I consider that a moot question at this point.

Maybe the lesson to be learned here is that it is better to avoid this discussion entirely by incorporating the BGP-LS extensions directly in the LSR draft whenever feasible.

Thanx  for the discussion.

    Les



From: Susan Hares <shares@ndzh.com>
Sent: Tuesday, June 7, 2022 5:58 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: idr@ietf.org
Subject: RE: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

Les:

I’m glad to take this offline if you wish.   I’m sorry I misunderstood your question.

Let me be specific about the two drafts (draft-ietf-lsr-isis-flood-reflection-07.txt and draft-head-idr-bgp-ls-isis-fr-01.txt).

LSR is the key working group reviewing the TLVS in the OSPF/ISIS protocols.  The IDR WG is responsible for BGP basic functions (BGP-LS, SR-BGP, etc.).  If LSR WG agrees to additions to OSPF/ISIS, IDR does not cross review these features.  IDR only cross reviews any LSR draft that includes of the TLVS in BGP-LS for BGP.

Is this a clear response?

Since the draft-ietf-lsr-isis-flood-reflection-07.txt has past LSR WG LC AND does not have any BGP-LS TLVS – IDR has no reason to comment on this draft.   If IDR WG members wish to comment on the draft, then the appropriate place is the LSR WG, Routing AD (John Scudder) or IETF LC.

I doubt the IDR WG will say “no more BGP-LS” as I have a pile of IDR drafts that specify more BGP-LS.  However, like Tony Li raises concerns about what goes in ISIS or OSPF, it is reasonable for people to ask “why” about additions to IDR.

I hope this is clear answer.  You are welcome to tell me I missed the mark again..

Cheers, Sue


From: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>
Sent: Tuesday, June 7, 2022 8:01 PM
To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Cc: idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)


Sue –

(I am already starting to be sorry I waded into this thread…)

Sorry, but I find your response off topic.

It is quite legitimate for the IDR WG to consider alternatives to BGP-LS – and even consider deprecation of BGP-LS.
(By saying that I am not expressing support or opposition to the idea.)

But it is NOT legitimate for that topic to be used as a blocker for a particular BGP-LS draft.
BGP-LS is what we have – and it is widely deployed. If/when the IDR WG decides “no more BGP-LS” then clearly such drafts should no longer be written. But that state does not currently exist.

In the real world we live in, as I see it:

LSR WG decides what IGP protocol extensions will be approved.
Once those extensions are approved it is NOT the place of the IDR WG to say “BGP-LS will not be allowed for this IGP protocol extension”.
IDR WG could say “we would rather you incorporated the BGP-LS extensions directly into the corresponding LSR draft”.
But, I don’t hear you saying that. I hear you saying the IDR WG may decide to forbid BGP-LS extensions for this particular IGP extension.
Which is why I ask – where is the definition of how such a decision is made?

I deliberately am not commenting inline to your response because (no offense intended) nothing in your response is applicable to my question.

   Les


From: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>
Sent: Tuesday, June 7, 2022 4:34 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>; Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Cc: idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

Les:

The IDR and LSR WG chairs have agreed that LSR/BGP BGP-LS specifications often specify the same TLVs.   In this case, if the authors desire, the LSR specification can specify both ISIS TLVs, OSPF TLVs, and BGP-LS TLVS.

As part of the WG LC process for such a combination document, the IDR WG reviews BGP-LS portion of the LSR Specification.  If there is an objection to the LSR work going into BGP, then the LSR and IDR chairs handle the issue.  You may have noticed this happening in the past.  Or it may have been part of the LSR chairs back-end process you did not see.

For this draft, the authors requested a separate draft would be adopted and WG LC in IDR. Given the author’s request, I must follow the normal procedure for any IDR draft.   As you have notice from Aijun and Robert, there is growing concern the continued addition of BGP-LS TLVs.  This growing concern for this draft may have been expressed even if this was a cross-reviewed draft.

Consensus decision-making does take time and cross reviews.

I hope this helps you understand the administrative process.  The LSR and IDR chairs are trying to minimize needless drafts while providing opportunities for the two WGs to review the documents.

Cheers, Sue

From: Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>>
Sent: Tuesday, June 7, 2022 6:57 PM
To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>; Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Cc: idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)


Sue –

Color me confused.

We have here a protocol extension to IS-IS that the LSR WG has approved (passed last call). Which there was sufficient belief in the WG that this protocol extension was useful for it to be approved.
But you claim there is some secondary process, managed by the IDR chairs (or perhaps IDR and LSR chairs?), that determines whether the BGP-LS extensions in support of the approved IGP extensions will be allowed?
This is completely new to me – please explain how that process works.

NOTE: I am not debating Aijun’s remark as to the “enthusiasm” showed in the LSR WG for the draft – nor was I a vocal supporter of the LSR draft in question.
But, if LSR WG approval is not sufficient to justify the corresponding BGP-LS support, please explain what is the defined process and where it is documented and describe how it has been used in the past.

Thanx.

    Les

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Susan Hares
Sent: Tuesday, June 7, 2022 1:54 PM
To: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Cc: idr@ietf.org<mailto:idr@ietf.org>
Subject: Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)

Aijun:

Thank you for your feedback on deployment issues.   It is important to know if an operator feels this option will not be deployed.

I  will contact other operators to ask them to comment on this adoption call.

Sue

From: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Sent: Tuesday, June 7, 2022 10:51 AM
To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>
Cc: idr@ietf.org<mailto:idr@ietf.org>
Subject: Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20)


Hi, all:

I don’t support its adoption.
The corresponding IS-IS document past just the LSR WG unconvincingly and I cannot foresee which operator will deploy the flood reflection mechanism in IS-IS deployment.
Then it is doubtful also the corresponding BGP-LS extension.
There is no any description for the necessary in the document.

If the authors insist to do so, I recommend to incorporate the trivia contents into the corresponding IS-IS document.


Aijun Wang
China Telecom

On Jun 7, 2022, at 05:28, Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>> wrote:

This begins a 2 week WG adoption call for draft-head-idr-bgp-ls-isis-fr-01.txt

https://datatracker.ietf.org/doc/draft-head-idr-bgp-ls-isis-fr/

  This document defines one new BGP-LS (BGP Link-State) TLV for
   Flood Reflection to match the ISIS TLV for flood reduction.

   The draft is short (5 total pages).

Since this BGP-LS feature has been adopted by IS-IS,
Please consider


  1.  Is there any technical difficulty with adding this to the BGP-LS code points?
2.   Is this draft ready for publication?
3.   Does this addition help operational networks.

Cheers, Sue Hares



_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr