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

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Fri, 19 March 2021 20:40 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 666D83A0EDF for <idr@ietfa.amsl.com>; Fri, 19 Mar 2021 13:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.62
X-Spam-Level:
X-Spam-Status: No, score=-9.62 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=YVZiWNwS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Hbp9l+tX
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 gdOcroshRSSV for <idr@ietfa.amsl.com>; Fri, 19 Mar 2021 13:40:19 -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 933073A0EDB for <idr@ietf.org>; Fri, 19 Mar 2021 13:40:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5240; q=dns/txt; s=iport; t=1616186419; x=1617396019; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=JaOsiy5zBis36Q9A+n85DXDC0O/LQAXQ2+gjDlVNwCM=; b=YVZiWNwSXS0Zh6wsulkxIICvehGkrcwTy0TfCyrxK9DH4nYQ3PAivSQN 3Ev+kjafdJ13Shsv+OX45dUGp9Jk7jfii7u/ovLSzvlsiwAs5iAfyUBUw JyIQEwfwNLCBRkT9Nt1myKzqhKU35NlM4UVXwFFEOx7qRVM/VRFK+CnkG M=;
X-IPAS-Result: =?us-ascii?q?A0DlCQB1C1Vg/4wNJK1aHgEBCxIMQIMjIy4Hdlo2MYgKA?= =?us-ascii?q?4U5iD0DgQmYKoJTA1QLAQEBDQEBHQsKAgQBAYEWAYM5AoF7AiU4EwIDAQEBA?= =?us-ascii?q?wIDAQEBAQUBAQECAQYEcYVhDYZEAQEBBAEBGx0GAQEsDAsEAgEIDgMEAQEBH?= =?us-ascii?q?gULJwsdCAIEARIIDAqCU4JVAy8BDp96AooedYE0gwQBAQaFDRiCEwMGgTmCd?= =?us-ascii?q?opNJhyBSUKBEUOCJDU+gmABAYFgg0mCK4I9BwZkBDESECACLgsYJYEhO7oTC?= =?us-ascii?q?oMGnHikOpQJdZ4WhFoCBAIEBQIOAQEGgWsjgVlwFTuCaVAXAg2OHwwWFIM5h?= =?us-ascii?q?RSFRXM4AgYKAQEDCXyOWQEB?=
IronPort-PHdr: A9a23:oeF5fR9EaCrnxP9uWNPoyV9lXQAupqn0MwgJ65Eul7NJdOG58o//O FDEjd11gkXCG4LB5KEMh+nXtvXmXmoNqdaEvWsZeZNBHxkClY0NngMmDcLEbC+zLPPjYyEgW sgXUlhj8iKjP1JeXsHkaA6arni79zVHHBL5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5L Q69qkPascxF6bY=
IronPort-HdrOrdr: A9a23:0ykCh6EboYFxVd5ypLqFkZXXdLJzesId70hD6mlYcjYQWtCEls yogfQQ3QL1jjFUY307hdWcIsC7IE/03aVepa0cJ62rUgWjgmunK4l+8ZDvqgePJwTXzcQY76 tpdsFFZ+HYJVJxgd/mpCyxFNg9yNeKmZrY+dv25XFrUA1sduVE5wB2Fg6UHiRNNXZ7LLA+E4 eR4dcCmiGpfm4ZYt/+Kn4OWeXCoNOjruOpXTctARk75A6SyQ658bKSKWnW4j4ycRNqhY0j/2 /MjhDj6syY082T5xfA2wbonuxrsfT7zN8rPr3otuE0LXHWhh+sdMBdXdS5zU0IicWOzHpvr9 XWuRcnOK1ImjLsV0W4uwHk1QWl8BtG0Q6Y9XaijXHuodP0SVsBYqIr7+80A3ipiXYIh91y3L lG2GiUrfNsfGn9tR7g7NvFXQwCrDvSnVMekPUeh3EacYwSZK45l/1nwGppEYwNFC+/1YY/EO MGNrC72N9qdzqhHhTkl1gq5ObpcmU4Hx+ATERHkNeSySJqkHdwyFZd7NADn18bnahNC6Vs1q DhCOBFhbtORsgZYeZWH+EaW/a6DWTLXFblLH+SG1L6D6sKUki96KLf0fEQ3qWHaZYIxJw9lN DqS1VDr1M/fEroFImo0IBU9AvOBEGwRy7kxM0bx5URgMy/eJPbdQm4DHw+mcqppPsSRufBXe yoBZ5QC/j/aWT0H4JE2BD/RolSJXESXNZ9gKd+Z3u+5ubwbqH6vO3Sd/jeYJD3Fyw/Z2/5Cn wfGDj/Tf8wqXyDazvdulz8Snntckvw8dZbC67B5dUez4ALK8lJuggRglKp+9GTJVR5w+oLVX o7BImivrKwpGGw82qNxX5uIABhAkFc56ilVWhLqw8MO0b9aq0CpN2bZGBX0BK8V1pCZvKTND Qai0V8+KqxIZDV7zslEcibPmWTiGZWuGiHVI4GmqqI5d7sf5QxCppOYt0pKSz7UzhO3Sp6om ZKbwEJAnLFHjT1kKO/kdg/H+fEbeRxhw+tPO9ZoX/Srl+nuMkqX3cXNgTeCfK/sEILfX50jk c027IDiLCA8AzfV1cXsaAdChlwT0i5RJhBFx+IYY1InKuDQnAAcU66wRqAix8yfWL28V41nW KJF1zORdj7RnxAp3tfzqHmtHRze2n1RTMsVllK9atgCG/BpnF/ldWuW5P2+W6QZlweq9ttag 3taScOIw9o2tC83AOUnjHHDnk92pAyJIXmfcQeWqCW1XW3JIKSk6YaW/dS4ZZ+Ldjr9vQGSO SFZmauXXnFIvJs3wyevXA+PiZo7HEijPPzwRXghVLIlEIXEL7XIF58QascLMzZ52/4R+yQ2J E8id4up+O/PiHwbdGBoJunJAJrO1fWoWSsSfsvpo0RtaUutKFrF52eSCDWzhh8rWIDBdaxkF lbTLVw4bjHNIMqd8sOezhB9l5skNiUNkMkvgH/H+dWRyBhs1bLe9eSp7bYo7smBUOM4BH9Pl SS6CVR9fbIVSnr789SN4sgZWBNLEQs4nVr++2PM5DKAAKxbudZ4R60NGS+fLI1ctnIJZwA6h Jhp9eGkO+ce3CmhETevT5nLrlP9GjiS8WoGw6IEfNJ9dv/OVnkuNre3OejyDPsDT28YAAEgI cAc0oaZMFKkCMjg406yTLacN2Anms1119FpSh6nVvs0JW86GjVHUtaIRTU668mLwV7IzyNl4 DZ6uCW23T2/Shd1ZTCHElWeMtSG9J4dPmCEw5+bc4KvLCp+KIzgiNMJBc2ZlRM+wzA4w==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,262,1610409600"; d="scan'208";a="665856759"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Mar 2021 20:40:18 +0000
Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 12JKeI3G023444 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 19 Mar 2021 20:40:18 GMT
Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 19 Mar 2021 15:40:18 -0500
Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 19 Mar 2021 15:40:18 -0500
Received: from NAM10-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; Fri, 19 Mar 2021 15:40:18 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HFqdPDn0b5S8eBlqQX21sn8CUqAktLDeXB0exElJHS+ngCHnr0JG8LEZHae18ej9HcpxPMf/sg8OvdbxHA8Ylsb3RreXblSuYM9z6AOyejiSLKjuKtoxn5Pc+UfPdQQSNT4m10+85G8BAh5vzSVR6R92Hj8hEXBSYgiRgsfdT/uWjpi4l0uUiX7m8sYE4uqFnOE37sqkQLgf5N0VkX1+9nvB92Pc4C/hqC2pLbJxp2lmLd0boj3pJAK776OVUgHeIJbwwQqnSVEHdjVAO85FC7V07iHvQZYSjzC5257NG0p4wLV4sFNu7g32kCjQeS6jnmLjTyQOuYG/6aYeN3EOTw==
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=CzQCtAPA3PE8tpyRJ5OdNfJ24wWYd5mWaKbwnOzkkN8=; b=KdgwoWx+HrJcq8FbPI5Am73XKX/Fvu8NAsy+J2ZpjXEOLlBF3mJtFhmXhUCMzDW2jZ17K0aTOTaPfAxG09hJjkd4njPto0VYWDVJOrPmmKQrrFs1lNojHIQxpZBnahcxd3htJv4rLJuGsZwvO2qhy+Jmnc17BqaSv4hqjlG96ahGhzxJl0A+CxsHU8h2Z4QnVRmFUHz8ONAl5XSJPnh+VesfSaE0KYzyRVVSUYhNhfWrUSgfM1GKvnI2sKMFvowApbUBwMM1P91oBun0KGSIeOaShPwBVuinA4Mqm/gdBMa6sgy6bmXaYdcclVr73qx7QQgwktLuT/lTp4/IPmfZJA==
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=CzQCtAPA3PE8tpyRJ5OdNfJ24wWYd5mWaKbwnOzkkN8=; b=Hbp9l+tXJ9ZIV/aNgh6Jg3YxaGJEq1Yg+9TR7GgdR72N9KcxX/ZujKD/gKZdZUHX8BWYSbfaxgoEyelSEWMhcxRGN7RLpjmUjfSiN7sbyCvt5jbOv1iLkzfpVJzWVZtlUD9mEsIu8umbNJ5u8mo6SR++ZjfowGEjjEab+aC11/4=
Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BYAPR11MB2968.namprd11.prod.outlook.com (2603:10b6:a03:90::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.32; Fri, 19 Mar 2021 20:40:15 +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.3912.031; Fri, 19 Mar 2021 20:40:15 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] WKLC transitivity considerations (was Re: Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23))
Thread-Index: AQHXHNouRxAqhLs6vUmhS+JHcB6o1KqLwO4g
Date: Fri, 19 Mar 2021 20:40:15 +0000
Message-ID: <BYAPR11MB3207F7BC05E7F10C09373E6EC0689@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> <20210319162953.GR29692@pfrc.org>
In-Reply-To: <20210319162953.GR29692@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: pfrc.org; dkim=none (message not signed) header.d=none;pfrc.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:647:5701:46e0:65b6:eeee:b2ff:8898]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1a922777-bd29-4daa-cc9c-08d8eb1733cf
x-ms-traffictypediagnostic: BYAPR11MB2968:
x-microsoft-antispam-prvs: <BYAPR11MB2968C3E28ABE42871B19CC10C0689@BYAPR11MB2968.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: KSRa0iIlSLDBeGICty4ULaUVBlObjkeJr1l04S5Ctxu+E1izFd5mBGLrYRaAM6UVuQXLGUesTOjGD1Sw36HfoZdHlRRmxurXjUHmD99VaA6YtBC/Df+16ii48arpnyaw5eg6n3Jfk37pDSnJdIomKoKzYuD3W3mhu12SeamK1dDymVP6O0JMZxrEC1u4i5DyXYUggW1955FrWQ+U9GjvgByioXm6DQeMdb8XIo4dsf0eAuk9SJXIXyytWsBrGjrxrK6rwDdqUgf6d/3W6KOlgyzq7qligyqyrvfhGEIf7ml7GEw7O1TBjecWpOjdK+6lmbFXLy0/0m/9xF57SGq7Qx3P1BrntHfI+WUCMUcyirbk984UzBPOgLWeM3Z4mAsTHldK2KqnrSi8sPBH1WAvs0kpyPju78+GeGtjK5v6NJz9YaiQ4t7lT9zpY5rTgv55Vvn6aqS7UAGfY5Ebv+9r0AMq7ihflxoi//XjTJ3gzjhLBseBb8L9z9+LTopc8s6qRMSAovf06sCmNVTsZUK8inq2mYCkNiLOSFTqUCWEYrpsO5B6Xw9r1UdN2crR3HaUjaLBe+AaHALhBcjxqhBXGiP/dlGAdHVaEMpT63jXWj9Hqev9FaMBJeZ4qH6dqf9pe7a45KBdvoQR//roJ3reW9NI8EqP8Dt5MM6mOynMF4F6iDk6syEKpoe39XYFKg52XQ3TCdiuk2alHqaz9nuxZQCqe5bxlmLSmg3dv06vIEszjBbCKFmSRjq9bsHtxEj8
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:(136003)(366004)(346002)(376002)(396003)(39860400002)(53546011)(966005)(6506007)(76116006)(66446008)(110136005)(66556008)(33656002)(52536014)(5660300002)(316002)(8676002)(83380400001)(8936002)(66574015)(66946007)(66476007)(2906002)(71200400001)(186003)(478600001)(86362001)(38100700001)(55016002)(7696005)(64756008)(9686003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?3Dd5hXn0Ey+bBDsNivK6aEeD9w+DbFRIBgQrRlLYy2zn+boHezIuxZlk2Icr?= =?us-ascii?Q?b4cdNi/8cmN+MzPLpmqpywnuVVsdMK/pPNVMWXmIKXId4YyOrmSuro1rMUCy?= =?us-ascii?Q?U0Z3GKdrjnDCv7Q42RkUS70fOOFr+B3hJ92GtnvGH2fzUbcN9DJGreoBpJio?= =?us-ascii?Q?fs38up7uMaDZQqanOSVoOlxs9zQiJuHqTtjs62Y88g/MWOp5FsbK8REsGfkL?= =?us-ascii?Q?dcIQWLYL+FD36zCCDLiaGOfg8Qovtb3ucj89nkp6uDD0rKl3O2E7VI9ghRC+?= =?us-ascii?Q?HgLRS2Fnm3y6EePHPOqLXVwE5GpYwwdny1CNODT0FFmmISxDvXkwdpKetTo3?= =?us-ascii?Q?BiJjC6ncdTRGNqqDyIE2OqKoZVaxVyPIeT6KKCSc8n8ZUnLBUvCJ2akGAi/4?= =?us-ascii?Q?JIyDYVPlLZ5Ryaff0yk6e42rzCQQ4ITiiuxdfd8v5rqcZN1yfZxcjbXO3DpS?= =?us-ascii?Q?XPgrfhruLrXo3C1Duuv7+BQhub8LASCEuox9SYiUNqtV39J6xhte2jBFBjhO?= =?us-ascii?Q?RoXxuC/hcquYQvCcll44utAIKE2Az0a8hrAPXOrCfB58TYSCWXhCue52mTtr?= =?us-ascii?Q?rauNJWxz/TNJcfoA8Nh2SaXR0kpod6bThdZgBx7EoSkQXSWv62tcpA7dAF2v?= =?us-ascii?Q?FqzHSuO0cNYLx8vjr4CR0Z1xJ6Olx1e+t6rouWh7LzQ1FHXiaY4yrHTlkb22?= =?us-ascii?Q?Dm6+Q5PK2mQrJoBDkI712MkQCBneHVYcKGVsN7fwmEoO2/5iF6hD5p9eKFFb?= =?us-ascii?Q?8rU+EU/skkxEboit3F3920H53VC6h1U4V0wDAqd0McnCXjQ7ixqjRyONAnz1?= =?us-ascii?Q?32WerJal7exZtqHRYMN9/l6Q2wxsvM+toAQ2vL9MB6UlfacS7cAmSCXLVrKU?= =?us-ascii?Q?w5J9qApJjkAO6NW7Sys8lkJze1Ji1bN5RdLSsK/zqaVBQ4L4nP8tMRsczBAK?= =?us-ascii?Q?12u70GM/Cko3XuS14QZdCIgzpmqBdDw1sMvr79EGj+v+i83nd4rkWO3j8IRl?= =?us-ascii?Q?Q2BJ559Q999EjFAx160XwlYMoxgJj55kCDBMAZ+XJmnmMDCcN5QofoUupClG?= =?us-ascii?Q?t5MD/UjYdQqqLKZ/fU/55RPRnvMNlWFvA+bUuwA0NRG06aBqCkWfHZZ0YQzw?= =?us-ascii?Q?BDSfOQ5dM4JuMjIInuH8KjLXeKA8GDXqBQLuot+N//HCUabACx+j4x9xPTqE?= =?us-ascii?Q?WyZsYYK8mAkOiUw8eNUYmCmB4zYIBVVA/hGYCjOq+Rf6wI1oZA8efMrYcO5G?= =?us-ascii?Q?2D2ycbG5SD0s5qcJrtg/qyIn5ZUdHrUA3WPDnUot5Xocllw4aLwdfGgFYn8p?= =?us-ascii?Q?S+mDLVeIzqSI9qzGyFSTKqrUAzpGEz+4/XaoqNz3tx2vcDRl2gC438c36G4D?= =?us-ascii?Q?1GGQ1GqbV3jRkHRi2W46xlQwzRlD?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: 1a922777-bd29-4daa-cc9c-08d8eb1733cf
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2021 20:40:15.7547 (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: H03hyIC2zHWi4+8rHGFYjj0+CUTzkNcrVsw7dDtjT+kNVCDniyIprk9kqTo6DIkU7rYs8LfVAgzjxGjEot1KVw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2968
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Gb2dHNepYd5fxrAmQeDzlXHKptg>
Subject: Re: [Idr] WKLC transitivity considerations (was Re: 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: Fri, 19 Mar 2021 20:40:21 -0000

Jeff,

I'm glad you brought that up.
IMO, it's "don't care".

It matters in duplicate detection.
If the LC attribute contains a particular WKLC and the same WKLC
were to be added, say by a route-policy statement, but with a
different transitivity, do you add both of them or just one of
them and if so, which one do you keep?

I'm just going to stick my neck out and say:
keep the value with the longest transitivity.
So, in the draft, the highest numerical transitivity.

The reasoning:
Suppose you keep both. What is the behavior?
Assume that the decision taken by a BGP speaker at a WKLC match
does not depend on the transitivity, but only on the other bits.
If two identical community values exist in a community attribute,
then the decision is exactly the same as if there were only one.
Therefore discarding the value with the shorter transitivity
does not change routing behavior.

The transitivity should matter only in the decision to propagate
and no other decision. If that's a good assumption, then it should work.

I just made this up on the spot, so I might have missed something.
Shoot.

Regards,
Jakob.

-----Original Message-----
From: Idr <idr-bounces@ietf.org> On Behalf Of Jeffrey Haas
Sent: Friday, March 19, 2021 9:30 AM
To: idr@ietf.org
Subject: [Idr] WKLC transitivity considerations (was Re: Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23))

WKLC authors,

Let me use Brian's text here as a starting point to raise issues about
interpreting WKLC with regard to their transitivity bits.  I don't believe
the issue here is irreconcilable, but it does play to a point Brian was
illustrating and that it somewhat dilutes the deployed feeature argument.

On Fri, Mar 12, 2021 at 10:13:31AM -0800, Brian Dickson wrote:
> 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.

For reference, the layout of a WKLC from the draft is:

:       0                   1                   2                   3
:       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
:      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:      |1 1 1 1 0 1| T |    WKLC ID    |          Data 1               |
:      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:      |                             Data 2                            |
:      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:      |                             Data 3                            |
:      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A property that extended communities had as a result of how the authors
designed the feature, and later firmed up by Eric Rosen as part of registry
work was that a given extended community did NOT have a guarantee of the
same semantics when you had a transitive vs. a non-transitive version.

If it did, using link-bandwidth as an example, one's code would treat the
transitivity bit as a "don't care" for purposes of comparison.  I'm not
aware of any implementation that does this.[1]

The behavior of the transitivity bits for WKLC isn't directly discussed in
the document in terms of whether they have "don't care" semantics or not.

WKLC in particular discusses changing transitivity flags:

:         3 - One-time Transitive: The WKLC is transitive across ASes
:             under the same administration and into an AS under the
:             neighboring administration, but not into an AS under a
:             further administration.  A BGP speaker that receives a WKLC
:             with transitivity 3 on an external BGP session on an
:             administrative boundary SHOULD change the transitivity to 2.

The implication here leans toward this meaning they're "don't care", but
that may be my interpretation.

This primarily is an issue for "singleton" communities, like link-bandwidth.
While that may not be the target for the first use cases of the draft, it
should be part of the considerations for the feature's definition.

Related nit: Define your transitivity behavior for BGP confederations.

-- Jeff

[1] In the early 2000's when the extended community feature was being
disussed in IDR and I was a junior BGP dev, I did try to push the authors
toward treating transitivity as a don't care, and the sub-type field as a
"format field" for generic parsing.  Clearly my opinion didn't win out.
This results in extended community parsing being a snake's nest of special
cases with some generic patterns in use.

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