Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Wed, 31 March 2021 17:39 UTC

Return-Path: <jheitz@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 90D043A2F79 for <idr@ietfa.amsl.com>; Wed, 31 Mar 2021 10:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.917
X-Spam-Level:
X-Spam-Status: No, score=-11.917 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_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=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=mj2ZOgWy; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=UfUdQPDh
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsc0uYaoLAoe for <idr@ietfa.amsl.com>; Wed, 31 Mar 2021 10:38:55 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 294E93A2F78 for <idr@ietf.org>; Wed, 31 Mar 2021 10:38:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=78362; q=dns/txt; s=iport; t=1617212335; x=1618421935; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BOCPPBChDo9RuNJTJb/Gsd4ZlBO/cag2OXlipstZYf0=; b=mj2ZOgWyKXkqseHHkAPNlyQO6QH7papED2h916Sz7o0z/8qjcjXrENsk Jx6UgW6QFzRfNe59tOMN6OzFLDujVMi3Vajyz3W11Cpn4fmXKsUdAJJ7T w8lnW3Yuu2bUAXOMAypQD1ujRBZLNMOPUWS4DYTtA4QuN7IqWg+Ix8Qgg o=;
X-IPAS-Result: =?us-ascii?q?A0BoBgDEsmRg/5NdJa1QChwBAQEBAQEHAQESAQEEBAEBg?= =?us-ascii?q?hCBIzAjBigHdlo2MYRBg0gDhTmITgOBCY4bihGCUwNPBQsBAQENAQEdAQwIA?= =?us-ascii?q?gQBAYRQAheBZAIlOBMCAwEBAQMCAwEBAQEBBQEBAQIBBgRxhTQBLA2GRAEBA?= =?us-ascii?q?QMBAQEYAwYKEwEBLAsBBAsCAQgRBAEBIQEGAwICAiULFAkIAgQOBQgMgl6Bf?= =?us-ascii?q?lcDDiEBDqBOAooed4EygwQBAQaBNwIOQYMGGIITAwaBOYJ2hAcBAYZLJhyBS?= =?us-ascii?q?UKBEkOCJDU+gmABAQIBgS4PIAwJFgmCYDWCK4FYAQJiBwg8HQ0NBwQZIAJbA?= =?us-ascii?q?hYBBwoTKgIZASQBAQIrQwOQJwQPGyyCf4dfjHORXwqDB4ldhxmIfYMapFigb?= =?us-ascii?q?JJQFASERwICAgIEBQIOAQEGgWsjgVlwFTuCaVAXAg2Hf4IdhAMHAgMWgQIBD?= =?us-ascii?q?oI9hRSFRXMCNgIGAQkBAQMJfI4NAQE?=
IronPort-PHdr: A9a23:MrL5bBZ6o2JWI9dx7c/Mrlf/LTDbhN3EVjU944c7i79IbqWo9ojjO 0qa//h2kVvVRu3z8ftfmffV9abtRT9I7ZWAtSUEd5pBH18AhN4NlgMtSMiCFQXgLfHsYiB7e aYKVFJs83yhd0QAHsH4ag7Iq2ag8D1UHBjjZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/J Rm7t0PfrM4T1IBjMa02jBDOpyggRg==
IronPort-HdrOrdr: A9a23:YjxVUqtRNk46uSDOoXK+v0nu7skCJIcji2hD6mlwRA09T+WxrO rrtOgH1BPylTYaUGwhn9fFA6WbXXbA7/dOgLU5FYyJGC3ronGhIo0n14vtxDX8Bzbzn9Qy6Y 5JSII7MtH5CDFB4vrSyAOzH888hPyO9661jenTpk0dMj1CQYsI1XYfNi+wFEpqSA5aQb8wE5 SB7sRKzgDQB0g/RMK9G3UDQqz/t8TG/aiWLyIuKjwGzE21jT2u4KPnCBTw5Hcjeh5G3LtKyx m/ryXX/aOm2svLryP092iW1JhOncuk990rPr3xtuEwChHBzjmlf55gXbrqhkF1nMiK5EwxmN fB5zcMVv4DkU/5RW2+rRvz1wSI6l9HgBWOpS768BneiPf0Sz4gB81KiZgxSGql12MboNp+3K hXtljp0aZ/MBLakCzxo/jOWh16/3DE2UYKrO8Jg3RTFbYZcb9axLZvhX99LZFoJlOf1KkXVM 1VSO3M7vdfdl2XK1rDuHN0/dCqVnMvWj+bX0kroKWuonhrtUE863Fd6N0Un38G+p54YYJD/f 74PqNhk6wLZtMKbJh6GPwKTaKMey/waCOJFFjXDUXsFakBNX6IgYXw+q8J6Oajf4FN65cuhp LbUhd9uXQpc0zjTe2Ctac7sCzlcSGYZ3DA28te7592tvnXX7zwKxCOT1gojo+uuPMaDsrHW+ uiOZ5fDvP5RFGeXbph7knbYd1/OHMeWMoatpIQQFSVuP/GLYXsq6jafZ/oVf3QOAdhflm6Lm oIXTD1KskFxFusQGXEjB/YXG6ofkT++Jl3AbXL5uR78vlKCqR89iwuzXip7MCCLjNP9oYsel FlHb/hmqSn4W+s/WjJ6G1tMgFHDllc5ajhV38in35OD2rENZI4//mPc2Fb23WKYjVlSdnNLQ JZr1Nrvb6sI4eI3iAkAdK/Omech38ezUj6Fqs0q+mm34PIa5k4BpEpVOhNDg3NDQVyghsvgn xEchU4SkjWES7Oha2pgIcPPvzWc8BxjW6QUJZpgEOakX/ZhMk0AlMHQjalUKes8HcTbgsRom c0zogyr/6rny21JW42neIiWWc8GFi/MfZhFwSKZIJdh7bxXhp/JF363gCyulUUZnfg8VkUiy jHKyCZEMu7X2Z1izR/zrvg9k9yeyGmW39ILlp+sYF7CA39yyxO+OeWe6u+1HaQYFMewucbdC rIeycWPxkG/aHF6DeF3DmFDnko3ZMoI6jUC6kiaaja3je3JJSPjrxuJY4YwL91cNTvuPQMS+ SRZkucKy75Efog32Wu1z0YETgxrHkvivXz3hL5qGC+wX4kGPLXZFBrXasSLd3Z72/qQZ+zod 9EpMNwueu7KWPqbNGajanRcj5YMxvW5XesUPtAk+EjgYsi8L9oW5XLWzrB039KmB04McfvjU sbBKB2+qrININjd9EbEhgpsmYBhZCKNg8mowb2CugxcRU2g3jXM8iA7rDIpbAsa3fx7DfYKB 2a6WlQ7v3FVyyM2foGEKo2O31Rc1V553J4/u+OHregRzmCZqVG5h69PXC8erMGF/TAFrUUsx pg49aH2+WQbDH13QjMvT19ZqJCmlzXNf+aEUaJA6pP9df/JFGHxq2t68S3hC3sSTS6Z18D7L c1PHA4f4BGkH06kIYz0iKuUaT5rUIujktG7Vhc5yvQ85nj5H2eAFpPPgLYiIhHRDVfMnCHis Le7OiTvU6NlwRtyN3ED0dfftZHBtgWQMz2Nk5VWLotgII=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,293,1610409600"; d="scan'208,217";a="672714679"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Mar 2021 17:38:53 +0000
Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 12VHcrPQ000922 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 31 Mar 2021 17:38:53 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xbe-aln-007.cisco.com (173.36.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Wed, 31 Mar 2021 12:38:52 -0500
Received: from xfe-aln-003.cisco.com (173.37.135.123) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 31 Mar 2021 13:38:51 -0400
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Wed, 31 Mar 2021 12:38:51 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N+FvZRPx24XdevqcLDTHeR53YcYvr2voKe1ZloqrLEuK5hEhVTwYfVzFZEsHjYaIQoLngEMZyMNjXjd/Il6YpZag9FF0Jvs40588cpbU16L5Dgk7r9UZcGA+ekEEGMW3gh19cAcSsOcuqSxulzinBt9s7LfACj3gDu8Rit6iB7qkJuHaqQ6svkHaBaZgTuWhydHS8iPRJC1k9J8hsTA81xmGfn64ZKRnIu5pNDbLf710V41PkJe8nVIJb5mMIhnKbejjc9C7636fsg/Y5+kn5rqxKRoEFmov0Pay3iBBjyaNdLdi5Olq7yV7vwUSSVvUPfs6RtPFf/9AQl/qGCLvQQ==
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-SenderADCheck; bh=BOCPPBChDo9RuNJTJb/Gsd4ZlBO/cag2OXlipstZYf0=; b=JE37JInpfEkGbOesUpaxutqoB7W71n99SQ0b7StiifUaQTgZtGj2AtfguQTwF0QQtC0/ZBvb/K6xBTUpWk63Fq/XaHcG3RRIXxIowdnR4IoFEy2PgzWlbz+V1WN263T+g/JYkjdA6La/4gMOQBz72Vf262ghUpBQMFq9W2O/qoHWrCkcxgMZ2xId4b4c0vpejCKydaU/WGyHkci6Cs0LZveueFfYia6GUUN/AAOKIh6gifid7ZQ+KG42MEletzMrfsBu9Ex1dcKo5Yq4dIAujfKDoEEhqW/H/YK0XVnaeLOnuiBWzueozpXEnc5GjnZcuEwYlT75reNE3oFq/1vG3g==
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=BOCPPBChDo9RuNJTJb/Gsd4ZlBO/cag2OXlipstZYf0=; b=UfUdQPDhbQkTFnG6LJVMeuGaUKe8coOMDKz7N7m6ypfTreZ4Njwnh2qMzHDrqObEqRtFmYJCQcbmbalNldM5ERWNT9rjUPkd7YsJtzXBleRHZ1nQyQkCplk6P5NdBxozUmFXbuLZ/LMi+J7FsQRyFYOHaktzvd4LuyaY24Xc2G8=
Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by SJ0PR11MB5166.namprd11.prod.outlook.com (2603:10b6:a03:2d8::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3999.28; Wed, 31 Mar 2021 17:38:47 +0000
Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::e084:727e:9608:11c7]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::e084:727e:9608:11c7%7]) with mapi id 15.20.3977.033; Wed, 31 Mar 2021 17:38:47 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Robert Raszuk <robert@raszuk.net>
CC: IETF IDR <idr@ietf.org>
Thread-Topic: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)
Thread-Index: AdcUzCK9cOxVNXxlSTaYTgm0ztYk+QAlchOAAARMGvAAAPLwAAAARvIwAAM2YYAACa7m0AABveeAAFc7oAAAAOjLwAABuHEAABRZTIACwlQUAAAA1uAAANFFkSAAHYosgAAIBRGg
Date: Wed, 31 Mar 2021 17:38:46 +0000
Message-ID: <BYAPR11MB3207534EBAB5B85B83BB5FFDC07C9@BYAPR11MB3207.namprd11.prod.outlook.com>
References: <BYAPR11MB3207CF86CF2FBD56CA3EAD66C0919@BYAPR11MB3207.namprd11.prod.outlook.com> <CBFDE565-E501-4344-BF6C-53A541D50391@tsinghua.org.cn> <012b01d7170f$7ec90310$7c5b0930$@tsinghua.org.cn> <BYAPR11MB3207D4E973EE9ED170687E1EC06F9@BYAPR11MB3207.namprd11.prod.outlook.com> <015601d7171a$036be470$0a43ad50$@tsinghua.org.cn> <CAH1iCiqy3uu0SF2i9TyTRwCdt2d2Ud9+nUCtRG+vc2E-gwfLPQ@mail.gmail.com> <018a01d72274$bdeb63b0$39c22b10$@ndzh.com> <CAH1iCiqycXf7QJ7PuYQ7E8nJjdXpjcta_z39xOfdLsar3cAOJA@mail.gmail.com> <BYAPR11MB3207FF17C2AA82960EEFDC43C07D9@BYAPR11MB3207.namprd11.prod.outlook.com> <CAOj+MMGQnesamiuDFWYMWLxdt-EbceW3tCgt+gFS7m0svNKJJQ@mail.gmail.com>
In-Reply-To: <CAOj+MMGQnesamiuDFWYMWLxdt-EbceW3tCgt+gFS7m0svNKJJQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:647:5701:46e0:8518:f5d8:94a1:e028]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3ab0663d-fe5c-4534-12ba-08d8f46bd68f
x-ms-traffictypediagnostic: SJ0PR11MB5166:
x-microsoft-antispam-prvs: <SJ0PR11MB51666E904AFA8B19BDEBF0FFC07C9@SJ0PR11MB5166.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: NfOKrDQ7i1f03XgqPemf3SojwRusHrJdkeskDODlfiWY0L8t9KhKbIFi11GJgGYCL3n6zkU6SMxF+hmKQ1vqlvFL99u5qSRwavOa89rdN9Vy0BIWEE3WxC4o+XaBQsszTbhYlpSyDbpYKbe9PsdRELqiLhf26KHkqwXleLSfLra5KAaCLjDIIAn14V6knTZvy6fbb7CiG4jsMNT0nBFvRmccZ9jzzmC4kvMNoWOMmabuMqwV5PcDhDSjgcQQA8Js2IlBUczmHfC0aXTrkSLxSa3s8d4GKeNthOuqsG7To8bucGVlzxUxAbMNWm+dOJpOm5GfmA2LZt2asHhz2IJxGCSmB7e3p8pYYTG8ZCCh7EeXMHgNZuCufRhSkmxQt/O010oDZMm+ZD4jiiKdzeWxMe5hn2M4q3iXRIQCFmGDwsqgqPiecJ1/20KQ3yE2PfEjcqxE29flaIjV7Ob3CaowFUN6EnJGJib9keg8xTT+e5MsjspfD/fxlV2aJbvVCC31IMxxZRfQ15NbsVHrg/hF8ZF+XTsfB45t8hBU8gR6mUQuQfbJY+/A6mb8JKMewMcUR0vFeRO7C5KW6I3HDdvoy/9QDhnS2sKvwyT2kk49F6Ff6qS6vDo8YYP0Qb6pZ5LA/2GrPTFXEQiiv+6DqsMcNkqcG2GFuWknBXgPh3skeYfTpJJx/O2y2ke/pH8EGKztWqpSZ/LiKMiaN2iE6AhH0bZQnj/QR6540uD/H9dCw/c=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3207.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(346002)(39860400002)(136003)(376002)(366004)(186003)(76116006)(166002)(66446008)(64756008)(66556008)(66946007)(66476007)(9686003)(71200400001)(55016002)(4326008)(8936002)(8676002)(2906002)(52536014)(316002)(6916009)(30864003)(7696005)(966005)(478600001)(33656002)(5660300002)(66574015)(83380400001)(6506007)(53546011)(86362001)(38100700001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?RzArV1hsS3BzWlZDd3ViRzlKVmVMVksvenA3SFJ3MlZFMHBnSWJEem82U3BF?= =?utf-8?B?WWkrVUhUQjI0S0IxYUZ5VFV1ZHhJRUEyZ2g0NmJnNGNySG8xSll5UnJpdVdC?= =?utf-8?B?NVAwSFM3UWV6OWxOMmI3eTlCc1R2Uml0eVRVeWY3M01LOHBESitrYnY2bU5C?= =?utf-8?B?OXh2VjhBUnRrSGtjM2hMcUtQNStuMzNueEcwNXQ2c3pyUTYrN29Wc1NIQ1Ix?= =?utf-8?B?eldJaWlpWUh3cXQ2L2xBNzZheFRJc05kMDA5MXhMRWU3ZnhBbS93ZTN1b1JB?= =?utf-8?B?Z1IvTXRucCtWOC9aajFPem9kMXNHQnRtSGZxaE96L3ZaYW0vWk1xaFZEcCt5?= =?utf-8?B?dEl6dHJiVVpPSzYyTDRMRmJ4VmdVQ0tURThHNFk2UGp4NWtnVTl6ZUdXMlBj?= =?utf-8?B?a25xUGFiOWZmTkVoRGdFRzRUemNFazU3QzhQbVlienZYN3Y3RzhGb3UwOXR3?= =?utf-8?B?bzZNOSs2R3ZlK1ltYkQ1KzdUTXZNUTVsa21IMmhWTm5LWnhkelJ6Q2ZUNFNh?= =?utf-8?B?bUs1TG0ySWNOQzR5VUxkZ25JajUyZlJiT1A3L21zSUdaZ2ZlMXJBSmdLMkpr?= =?utf-8?B?bW4xUkZZNDRRNThPa3E1QkF4cG9xZUJXNHlUOFQ4RnNOWGxLeDNEdC9ZQ3lI?= =?utf-8?B?TEhMNGtWeHIxMUpJeEhSSTl1SCttZXVXNDZHdENZSVIzajVCUW5VMkJYWkhR?= =?utf-8?B?L0w5V2Iyekk1d2ZnbmtXdE93eUZpQ3J4SkJQNGVWNktMTnpvQ2VmWE9FZzZQ?= =?utf-8?B?MkZoSWFNTi80bythN21JVGRMNUtBQVZpR0dVL2RpMlltY050WmdIS0lEK3RU?= =?utf-8?B?MXRsTlNTcjZPZzNMZlgvcUJSNnA1RmhFWitKSHNJWEV2UkVKaGRJVUlnTENX?= =?utf-8?B?T0xVT2xMT1ZlR1R1ajBsK1F5QVZlK29VWDFLREhiTHRFR1NMeXQ1Z3VOQ2tn?= =?utf-8?B?ZkRRdlE0VjladGdUM0I4R015VyswK0M2cnpkYzJ5RlY4TzdXTjB4T0o4U0lE?= =?utf-8?B?MkhwZHFKcllGMlduQUFZS3EyUEExNVdqYW5GTWFUeEt3M0c3K3VFaThXQUd6?= =?utf-8?B?aG9CK3hCWk5NMjRyRlQrbUlUQ0RieWVUWVFHQUZmM0VoMzdYOWRzUFZvL0hC?= =?utf-8?B?bkhRek9pS3ZwNEJ4bkx3UW5qNDljV3hjcUxpQkJxdlA2VVBzSUdyd2RrZW5u?= =?utf-8?B?ZTdyZjZCR2VIbENmeHNPWEVGOVAzN1hoUXdZNEpwaGcyYi9pUWdYdUREYUMr?= =?utf-8?B?ZFgwVWhpbXZ0NWcvd1NNbUZCdFR4OUtSb3lFeHZqWUNTcTZuOHorSC9GSlZ4?= =?utf-8?B?aEt5TzFDcjluYUVjbVB6Q2NaM2JGUWxramM4TE5TWENYaWFPTS9pNzRrWjNC?= =?utf-8?B?TGNNblNpTzZBS0ErS1VqRHJMaXg4a01PdWVwMG93VDl4a2lReVh0MkhNL2ZW?= =?utf-8?B?ZVZDZzZhMVZMSTVmdzhrMzNqU090Z2VRbWFWaXdnVkN6Z1o2c3RMWFkvZG1j?= =?utf-8?B?aHNsZmY1VXh1NnZRZFRwVjhrM09Ub0tjby9ONDZva0lENFFkck5nTWJ3V3J1?= =?utf-8?B?STFrQXVIZldOcVErN2pFZzdtMGt3Q2xid0pqSnpraWNlRlBOSlJGR0Erd3RQ?= =?utf-8?B?R1UvWHFtTnVZL3dsaXpreXNIZlM0YXVIYXJSalBnUlErSjhpUzVTT0c1a1FH?= =?utf-8?B?SGZWb2phaE4wR0V6bng1dUlhcWZqNTQrTzRMbVZNRklFcTlDMlRqN29JQ2RR?= =?utf-8?B?UExWYVNPTXMxb3FXYUR0VWpkaFZLdWFWNThzUm8rQU80emxyUVl0VEZhUUJ4?= =?utf-8?B?d3hoWW53UjNZazE0Mnd5a0Nzb2swWFB1dlZWQjk3d0tjNkoxbEJuSlV4YnJR?= =?utf-8?Q?1SMD8L/UCyE2h?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB3207534EBAB5B85B83BB5FFDC07C9BYAPR11MB3207namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3207.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3ab0663d-fe5c-4534-12ba-08d8f46bd68f
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2021 17:38:46.9315 (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: N/daKuCnwXWhTkkKTMZuCxv8Mout8DwR0X8bT6bBfZH3oX4zSP9EUFw1dI08N2AcbKo8Z4OqGiPYTTNLLS8ovA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5166
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/qwQmsSpepqV_wDCQq4wbrOA8TUs>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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, 31 Mar 2021 17:39:01 -0000

My opinion is based on the fact that I write router code
and I wrote all the code and tests, including the route-policy code
(by far the biggest part) of the large-community code in IOS-XR.

I also know that too many people want too many different things
out of communities.

My key opposition to wide communities is that I realize how massive
a job it would be to implement. Coding it on the wire is trivial.
It's all the route-policy stuff, checking the myriad of tiny details
to ensure no conflicts, error detection and recovery that is the
nightmare that will never be right. It will be a cesspool of bugs.

I'm happy to fix any bugs in large community code. If you can just find one.

Regards,
Jakob.

From: Idr <idr-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Wednesday, March 31, 2021 6:40 AM
To: Jakob Heitz (jheitz) <jheitz=40cisco.com@dmarc.ietf.org>
Cc: IETF IDR <idr@ietf.org>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hey Jakob,

>   They belong in operator code, which is route-policy/route-map.

We clearly have different opinions on this part.

You keep stating that all route-policy must be typed by operator.

I am saying route-policy can be typed by operators from atomic match and set primitives or route-policy can be smart enough to understand some predefined policies. Especially if those are predefined in the RFCs. Think of it in terms of pre-made policy templates like objects. They can be enabled by default or disabled and enabled on a per needed/expected basis.

That way you do not need to write your policy each time from scratch :) Let the router's vendor help you ...

I bring it here as that is also I think your key opposition to implementing wide communities which can easily accommodate by design all requests mentioned in this thread so far.

Best,
Robert.


On Wed, Mar 31, 2021 at 1:36 AM Jakob Heitz (jheitz) <jheitz=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:
Best chance for Sriram is to do it with a new attribute.

Community fields semantics do not belong in router code.
They belong in operator code, which is route-policy/route-map.
As soon as you define any structure into the community,
then the semantics must be interpreted in router code.

Regards,
Jakob.

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Brian Dickson
Sent: Friday, March 26, 2021 12:42 PM
To: Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>>
Cc: IETF IDR <idr@ietf.org<mailto:idr@ietf.org>>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)



On Fri, Mar 26, 2021 at 12:18 PM Susan Hares <shares@ndzh.com<mailto:shares@ndzh.com>> wrote:
Brian:

<WG chair hat on>
This brief justification for the ASN space even for 4-byte AS is not sufficient.   A separate draft will need to specify why so much ASN space that is managed by IANA.

In the original work with route-leaks, John Scudder and I agreed to help the route-leaks folks obtain 2-8 ASNs specifically for the route leaks.  Modifying your grow draft will obtain approval for a small amount of special ASNs.   I have discussed your need with IANA so that we had a sense of whether it would be approved.

Asking for 1/64 of the address space requires substantial justification as it significantly limits the future uses of 4 byte-AS.

The IDR WG allotted private ASN space for uses within an AS (or a Confederation AS) that spans multiple uses.   If you can make use of this space + 2-8 AS, your proposal can go forward.  If not, a separate proposal will be needed to justify that amount of address space.


Would a request for reserving 255 ASNs for WKLC and establishing an WKLC registry (which would maintain parity with the original WKC reservation) be a reasonable compromise?
Our GROW draft would then request something on the order of 2-4 of those values for the needs of the route-leaks draft.

Thanks for your consideration.

Brian
(The only hats I wear are the ones to keep the sun out of my eyes and off my head. :-) )

Thank you for being clear in this discussion with Aijun.

Sue
<WG Chair hat off>


From: Idr [mailto:idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>] On Behalf Of Brian Dickson
Sent: Friday, March 12, 2021 1:14 PM
To: Aijun Wang
Cc: IETF IDR
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)



On Fri, Mar 12, 2021 at 12:31 AM Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>> wrote:
Hi, Jakob:

From: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>
Sent: Friday, March 12, 2021 3:45 PM
To: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Cc: idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)


1.      It is small, not huge as explained in the draft.
[WAJ] When compared to the 22 well-known community, “67,108,864 AS numbers” is too large.  I am worrying the unnecessary reservation may prevent the allocation of the unallocated AS-number for other purposes.

The range of reserved ASNs occupies two bits of the upper 8 bits, plus the entirety of the the next 24 bits in its range.
This represents a single value from the 6-bit portion of the ASN space, or exactly 1/64 of the 32-bit ASN space.
Given that the current usage for ASNs is 2^16 for the 16-bit ASNs, plus less than 7 bits out of the upper 16 bit range, that is roughly 64/65536 or about 1/1000.
This still leaves well over 31/32 of the potential ASN space, so I believe your worry is unjustified.

2. It got updated and I missed it when I updated my draft. Thanks for catching it.
3. I don't understand your question. Can you expand?
[WAJ] why not take the approach directly as that descried in  https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-04. ?
That is to say, for each potential well-known large community, reserve one value for the “Global Administrator” part of the large community, and defined the associated data for the other two local parts. Transitive or non-transitive can be defined accordingly.
Currently, you define “WKLC ID” as the large community type. From the definition of large community(RFC8092), the “Global Administrator” part will be divided into 256 groups, each group will have 2^16 number, that is 2^16 well-known large communities?
I know you want to leave some field to the data part, but this arises some confusion when your proposed encoding is different from the original definition of RFC8092.

The logic for this is as follows:
The initial use case is to establish a structured value of TBD1:TBD2:ASN for the route-leak-detection-mitigation (as that draft explains).
The TBD2 is a single value out of a 32-bit range which will be in its own (new) registry. Having a registry allows for future uses in the context of TBD1, allowing new kinds of LC's in this bigger registered range.

However, the router implementations, for the most part, permit filtering of LCs on the basis of 3 32-bit values, where either literal values or wildcards can be used.
Having the elements be aligned on the 32-bit boundary, and having TBD1 and TBD2 be fixed values, permits LC matching using a patterns of either TBD1:TBD2:* (wild-card), or TBD1:TBD2:ASN (explicit ASN match).
In other words, this structure choice is forced by router implementations, and really not appropriate to second-guess. It isn't up for negotiation, as this is a necessary requirement for the first use case.

BTW: Both of these patterns (fixed single value and wild-card of lower 32-bit value) are required to implement the GROW draft you referenced.

Having said that, this is the first out of up to 255 WKLCs, and the maximum benefit to other potential uses for WKLC is achieved by making the maximum (reasonable) number of octets available for those other WKLCs, specifically 10 octets of undefined structure.

In particular, it is possible that other WKLCs require two ASN data values in their encoding (such as a source ASN and a destination ASN), and additional values (single bits or ranges of values) beyond that. Limiting the WKLC to having only single Global Administrator values and 8 octets of data, would be insufficient in that case.

This would require re-design of WKLCs at a later date, and it may not be possible due to existing usage or reservations of WKLCs.

By providing more octets to EACH WKLC, this problem is prevented. Making data allocations on power-of-two boundaries at the highest order is necessary up front. Attempting to expand ranges after allocations is possible, but may not be compatible with the power-of-two alignment required by future use cases of WKLC.

You cannot aggregate that which was not initially allocated in a fashion suitable for aggregation. This was one major outcome of the IP allocation strategies prior to CIDR addressing for IPv4 address space. We would do well to learn from the mistakes of others, particularly when those mistakes were effectively repeated in the ASN space already (16 bits to 32 bits, because the initial assumption was 16 bits would be sufficient).

So, in summary, the reservation of the range of ASNs is specifically to permit applying structure to the LC values within that range.
The original LC definition is only applicable to "actual" ASNs as Global Administrator. RFC8092 says only "intended", and that the value "SHOULD" be an ASN.
This is a new use case, and is the reason RFCs use "SHOULD" instead of "MUST".
(What RFC8092 really says is, LCs where the Global Administrator value corresponds to an actual assigned ASN, are reserved exclusively for the operator of that ASN.)
Since this proposal sets aside a range of ASNs as a group, the structure of LCs covering that range can be redefined accordingly, as long as that redefinition is scoped to that range of ASNs.
This is EXACTLY what this WKLC proposal is doing, and nothing more.
The other draft is for the use of the first assigned WKLC values (single ID plus the Transitive Bit values).

Hope this clarifies the usage and compatibility with other RFCs.

Brian


Regards,
Jakob.

From: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Sent: Thursday, March 11, 2021 11:16 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>
Cc: idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Hi, Jakob:

More questions for your draft:

1.     Do we need to reserve such huge range(4093640704 (0xF4000000) to 4160749567 (0xF7FFFFFF) as you described in https://datatracker.ietf.org/doc/html/draft-heitz-idr-wklc-02#section-6 for the countable well-known large communities?

2.     There is some inaccurate description for the current reserved AS number space in https://datatracker.ietf.org/doc/html/draft-heitz-idr-wklc-02#section-4.  You can check it at https://www.iana.org/assignments/as-numbers/as-numbers.xhtml. The unallocated AS range is 401309-4199999999, not at described in your draft “The range of AS numbers currently unallocated by IANA is 399,261 to 4,199,999,999.”

3.     What’s the necessary to group such WKLC via the WKLC ID?

Best Regards

Aijun Wang
China Telecom

From: idr-bounces@ietf.org<mailto:idr-bounces@ietf.org> <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Aijun Wang
Sent: Wednesday, March 10, 2021 9:38 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>
Cc: idr@ietf.org<mailto:idr@ietf.org>
Subject: Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

Yes, if we reserve some 4-bytes AS range, then your concerns will not happen.
The well-known large community need just be allocated from this reserved range. That’s all.
Do we need other definitions in your draft then?
Aijun Wang
China Telecom

On Mar 10, 2021, at 21:18, Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>> wrote:

Consider if there is a real AS that uses 4,093,640,704 as its ASN.
And if this AS were to send a large community of its own.
It would put its ASN into the Global Administrator field of the LC.
This ASN is 11110100000000000000000000000000 in binary.
Then another AS sends a WKLC with WKLC ID 0, Transitivity 0 and Data 1 = 0.
This has the same bit pattern.
To avoid the clash, we need to reserve the ASNs that would clash.

Regards,
Jakob.

From: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>
Sent: Wednesday, March 10, 2021 12:11 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com<mailto:jheitz@cisco.com>>; 'Susan Hares' <shares@ndzh.com<mailto:shares@ndzh.com>>; idr@ietf.org<mailto:idr@ietf.org>
Subject: RE: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

And, what the reason to assign the “111101”value in the first 6bit your encoding? It is not conformed to general definition of large community, in which the first 4-bytes is to identify the Global Administrator.

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