Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Tue, 07 November 2023 08:23 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD10C1E4E79 for <lsr@ietfa.amsl.com>; Tue, 7 Nov 2023 00:23:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.904
X-Spam-Level:
X-Spam-Status: No, score=-11.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b="N3VW3nP3"; dkim=pass (1024-bit key) header.d=cisco.com header.b="Fdr7crNQ"
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 FNDZnjhTcP6a for <lsr@ietfa.amsl.com>; Tue, 7 Nov 2023 00:23:12 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD023C1E4E63 for <lsr@ietf.org>; Tue, 7 Nov 2023 00:23:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=64712; q=dns/txt; s=iport; t=1699345391; x=1700554991; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UXCEi+KLMAR7XGYoyssQrC0LOSZDLdWn3A8jOtFBzBI=; b=N3VW3nP3I8gI3VM6mUJvqZ5hBclvK7/xoK4ivfcwOm68SOBaGOFI8D2a 0qPXEJx8m4Nhk3zPx0FlT0F6LennliAxteaf2w8RqNfo6dZrRS3B35Jnj jIi8uv/O67jdbRj9lVM42TFCoRy8d0O3lSB9OqOQ/+SXvg4dY/UlABUIe 4=;
X-CSE-ConnectionGUID: yN7XzZTbSx23+Va0PAfMrA==
X-CSE-MsgGUID: p4h6J13xRryLLjTHsMLZLA==
X-IPAS-Result: A0AZAACh80llmJBdJa1aHAEBAQEBAQcBARIBAQQEAQFlgRYHAQELAYE1MSooeAJZPEiEUoNMA4ROX4hiA4ETkCiMQxSBEQNCDwUHCAEBAQ0BAS4BDgcEAQGFBgIWhxACJjQJDgECAgIBAQEBAwIDAQEBAQEBAQIBAQUBAQECAQcEFAEBAQEBAQEBHhkFDhAnhWgNCIZEAQEBAQMBAQwEEQoTAQEjAgcLAQ8CAQYCEQQBASEBBgMCAgIlCxQJCAIECgQFCBMHggRYAYIWSAMBEI96j00BgUACiih6gTKBAYIJAQEGBAWBTkGwXQMGgUgBiAkBgU4BAYNphE0nG4FJRIEUAUKBZkoHMT6CYQEBAgGBKAELAQYBIxUPBwmDJTmCL4NygWSBD4IDFS4DBDKBCgwJgQODKimDD4FqiCSBAEdwGwMHA4EAECsHBDAbBwYJFC0jBlEEKCQJExI+BIFlgVEKgQI/Dw4Rgj8rNjYZSIJVCRUGOkp2ECoEFBeBCggEagUYFR43ERIXDQMIdh0CESM8AwUDBDMKEg0LIQUUQwNCBkkLAwIaBQMDBIE2BQ0eAhAaBg0nAwMTTQIQFAM7AwMGAwsxAzBVRAxQA2wfNgk8CwQMHwIbHg0nKAI1QwMRBRICFgM5A0QdQAMLbT01FBsFBGRZBZ0wDzxygUMRWgYuECYEFA4hDgIEEwstAQsgCkAaBQEGFwEGLgY6A4xuhS8FhAiLCEeNepRqCoQMjAGOD4NzgzwXhAGMc5goZJJwhU6CT4sWlSwYgliCJwIEAgQFAg4BAQaBYzprcHAVO4IzAQEyUhkPjiAMDQmDVoUUimV2AgE4AgEDAwEKAQEDCYhuAQEmB4FNYAEB
IronPort-PHdr: A9a23:Wj3Vih/E3Hn//v9uWO3oyV9kXcBvk7zwOghQ7YIolPcXNK+i5J/le kfY4KYlgFzIWNDD4ulfw6rNsq/mUHAd+5vJrn0YcZJNWhNEwcUblgAtGoiEXGXwLeXhaGoxG 8ERHER98SSDOFNOUN37e0WUp3Sz6TAIHRCqOgtzPe74AIH6hMWs3Of08JrWME1EgTOnauZqJ Q6t5UXJ49ALiJFrLLowzBaBrnpTLuJRw24pbV7GlBfn7cD295lmmxk=
IronPort-Data: A9a23:6AlpyK5OR+9/GaOyYX8xcgxRtCjHchMFZxGqfqrLsTDasY5as4F+v jYXCGDQaf+LZzTzLtl2Po3goR8AvcKEz9ZhGlBpqSpkZn8b8sCt6fZ1gavT04J+CuWZESqLO u1HMoGowPgcFyKa/lH1dOG58RGQ7InQLpLkEunIJyttcgFtTSYlmHpLlvUw6mJSqYDR7zil5 5Wq+KUzBHf/g2QvaztMtPrawP9SlK2aVA0w7wRWic9j5Dcyp1FNZLoDKKe4KWfPQ4U8NoZWk M6akdlVVkuAl/scIovNfoTTKyXmcZaOVeS6sUe6boD56vR0SoPe5Y5gXBYUQR8/ZzxkBLmdw v0V3XC7YV9B0qEhBI3xXjEAexySM5Gq95fWByePo/6vxXbWKSCv/fw2NGg4GJcxr7Mf7WFmr ZT0KRgXZRyFwumx2r/+Gq9nh98oK4/gO4Z3VnNIlG6CS615B8GYBfyWube03x9o7ixKNfnfY dETZCBgRB/BeBZIfFwQDfrSmc/x3SOmImEH8Q79Sawf+zTTki4oi6jXKsvxXt62Zd5wunS8j zeTl4j+KkhKaIPAodafyVqonfXnnC7nVsQVDrLQyxJxqEeYympWAxoMWB7r5/K4kUW5HdlYL iT45xbCs4Aj0hObXOvBVSao+iXHgBdEY/NeNvcTvVTlJrXv3y6VAW0NTzhkYdMgtdMrSTFC6 rNvt463bdCImODFIU9x5ot4vhvpZndIdT5qiTssCFpas4O68enfmzqWFo47eJNZmOEZDt0Z/ txnhDI1i7NWhskR2uDru1vGmDmr4JPOS2bZBzk7vEr7tGuVh6b8OuREDGQ3C94cdu51qXHa7 BA5dzC2trxmMH13qASDQf8WAJai7OufPTvXjDZHRsdwpm78piL/JdANuFmSwXuF1O5aIVcFh 2eN4WtsCGN7YBNGkIcuOdvqUpR2pUQePY69D668giVyjmhZLV/bo34Gib+41GH2m09kirAkJ Zqeaq6R4YUyV8xaIM6Nb75Fi9cDn3lmrUuKHMyT50r8i9K2OiXKIYrpxXPTNIgR9r2fmgzJ/ r53bo3So/mpeLegMnC/HE96BQ1iEEXX8rit9ZwPLbLeels/cIzjYteIqY4cl0Vet/09vs/D/ 2q2XQlTz1+XuJENAVzihqxLAF83YatCkA==
IronPort-HdrOrdr: A9a23:1Dj5M6qos3LR3k+0QZ2vgGIaV5tkLNV00zEX/kB9WHVpm5Oj5q OTdaUgtSMc1gxxZJh5o6HwBEDhex/hHZ4c2/hpAV7QZniXhILIFvAs0WKG+UyDJ8SQzJ8h6U 4NSdkYNDS0NykFsS+Y2nj3Lz9D+qj6zEnAv463pBkdKHAPV0gj1XYHNu/xKDwPeOAyP+tCKH Pq3Ls9m9PPQwVwUu2LQlM+c6zoodrNmJj6YRgAKSIGxWC15w+A2frRKTTd+g0RfQ9u7N4ZnF QtlTaX2oyT99WAjjPM3W7a6Jpb3PH7zMFYOcCKgs8Jbh3xlweBfu1aKv2/lQFwhNvqxEchkd HKrRtlFd908Wntcma8pgao8xX80Qwp92TpxTaj8DjeSI3CNXAH4vh69MZkmyjimg0dVRZHoe R2Nleixt9q5NX77X3ADpbzJklXfwGP0AkfeKYo/g5iuM0lGf5sRUh1xjIOLH/GdxiKs7wPAa 1gCtrR6+1Rdk7fZ3fFvnN3yNjpRXgrGAyaK3Jy8PB9/gIm1EyR9XFoj/A3jzMF7tYwWpNE7+ PLPuBhk6xPVNYfaeZ4CP0aScW6B2TRSVaUWVjibWjPBeUCITbAupT36LI66KWjf4EJ1oI7nN DEXElDvWA/dkryAYmF3YFN8BrKXGKhNA6dh/129tx8oPnxVbDrOSqMRBQnlNahuewWBonBV/ O6KPttcrbexKvVaPB0NiHFKu5vwCMlIbgoU/4AKiaznv4=
X-Talos-CUID: 9a23:ix2/nW1W+5rFvTVrtC6++LxfC+Z6Qm/v8H3rMxXjSlhgEIW8R3qK0fYx
X-Talos-MUID: 9a23:7XblfgiLhK+/MJxPwqLaa8MpLJtovYb3U1A3i4Qin8u4FTdVHwW5pWHi
X-IronPort-Anti-Spam-Filtered: true
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Nov 2023 08:23:10 +0000
Received: from alln-opgw-1.cisco.com (alln-opgw-1.cisco.com [173.37.147.229]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 3A78NA6Q032182 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <lsr@ietf.org>; Tue, 7 Nov 2023 08:23:10 GMT
X-CSE-ConnectionGUID: 5/0Up5EtRr+IkdyZVpYcrg==
X-CSE-MsgGUID: vCaeFmfRSAm4VVenf/QMUw==
Authentication-Results: alln-opgw-1.cisco.com; dkim=pass (signature verified) header.i=@cisco.com; spf=Pass smtp.mailfrom=ginsberg@cisco.com; dmarc=pass (p=quarantine dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="6.03,283,1694736000"; d="scan'208,217";a="7204116"
Received: from mail-co1nam11lp2168.outbound.protection.outlook.com (HELO NAM11-CO1-obe.outbound.protection.outlook.com) ([104.47.56.168]) by alln-opgw-1.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Nov 2023 08:23:09 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zr19JpCImGDjwnXHaGUKSJViMc+8Rk6IGxIQuY0i7fv12Hg2fvJFX8AdqWAKEK449wlyx3GPYBbw3m/GKML4WsM+XnvJHj0RUU5Nkksd0Bq9ELkwyaSnqoeIX0sbdCzdh95YbX7e+ijaaz5JtefZMVA2N8duJ9MDo3K7Cweco3+P/ORXB3RWYf5Wa0muD98iqZqm4E9EzW+b9oPvUGdgytXnC5/b9hNsQEMwUcQIlpmSWIV4SDV9l+h3paFE2bAjz0NsPy1AqE0i4/qQ6CKEzObAli/6aq7nX0aBiWTaw+pUeRmoFTFvYVfXntYzg7jpDgOXt23A68iEoKneoujBKQ==
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=UXCEi+KLMAR7XGYoyssQrC0LOSZDLdWn3A8jOtFBzBI=; b=JkcZSLnvBd9hdblr6oq01ZvKuDWZCIAeTNOMDKD46s/NOwKkhkpc2iKhif+M4JuS7/ySmdHO9feoVr4WqmLrlQWd9xV1SgqdV+93Ldkaa6/WQcYgWwRB/a7eCEbYr6jUqOaP7jb3DkNbJJV024ign0tW8EySARHsjAjBCOSS10+wVdc1kuIZrz8/GmVil3SCKA8ugcJl9uDOp9ip0oLrgMnFB7ORAdKcS3mcPh8/sTJLnFQY0RbCf9L3jB9a4g/ola47vNxDDR1chyzU+FIMtI4YSPQpPoGfBwfmJPJjt0KjcnTnWjmdRQlTfqSoolj7R8FseyhIRTKk+2yz+kv+Cw==
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.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=UXCEi+KLMAR7XGYoyssQrC0LOSZDLdWn3A8jOtFBzBI=; b=Fdr7crNQ5PYiuBZuVqctRhNaMF5GMOf+eGIarGyuxh5CaEKaf1d7AzcSl/sFv8bCZ+nL54YRo5gRCI95MOiriUR2GjI4DTXJPXtLhDQ6PUruKbnVufsR4hci16wofb9y3ogMqd0IlBzqd7+OZicKwnISnbprxmVZARdUPP5WzmY=
Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by MN0PR11MB6060.namprd11.prod.outlook.com (2603:10b6:208:378::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6954.29; Tue, 7 Nov 2023 08:23:06 +0000
Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::c7e5:7b05:fc78:6fb0]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::c7e5:7b05:fc78:6fb0%4]) with mapi id 15.20.6954.028; Tue, 7 Nov 2023 08:23:05 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Ketan Talaulikar <ketant.ietf@gmail.com>
CC: John Drake <je_drake=40yahoo.com@dmarc.ietf.org>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, Aijun Wang <wangaijun@tsinghua.org.cn>, "lsr@ietf.org" <lsr@ietf.org>
Thread-Topic: [Lsr] Technical questions for draft about unreachable prefixes announcement
Thread-Index: AQHaEKw6GC/9QnYTfkCBCHaCFizTPbBtT7OAgAAuyoCAAB7KgIAAS4GAgAAHZkCAAIzzAIAACHQA
Date: Tue, 07 Nov 2023 08:23:05 +0000
Message-ID: <BY5PR11MB43379993C0FCA66A6FDD76F4C1A9A@BY5PR11MB4337.namprd11.prod.outlook.com>
References: <f0811cfe-9a9e-4178-8c3c-f3071acffd74@cisco.com> <6123330A-2AC8-4E0D-9884-95E776B7FFAD@tsinghua.org.cn> <1784537198.758727.1699295427869@mail.yahoo.com> <CAH6gdPx_1WBhxX+y+xhY2oFE65HRqBrPYQkP_CTBbPCS5E0m7g@mail.gmail.com> <BY5PR11MB43379FA1CE43D6345884AFC0C1AAA@BY5PR11MB4337.namprd11.prod.outlook.com> <CAH6gdPzYwZK2vt50Eqo-oOSRJh8KqHp3m_-7my_2i7yDsNLpRA@mail.gmail.com>
In-Reply-To: <CAH6gdPzYwZK2vt50Eqo-oOSRJh8KqHp3m_-7my_2i7yDsNLpRA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: BY5PR11MB4337:EE_|MN0PR11MB6060:EE_
x-ms-office365-filtering-correlation-id: cb433a1d-a97f-452e-a049-08dbdf6ac43e
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1mHxjKVHUx9Q51gkfa/Ga0d2X30OFArVoRq7PDD4S6kGO5XCFbeu9ViTgs/0mWSS4OnPDGu7pxoIhkupnv7qmwDuwwUPXPQc/DODw6rNRgdcIQtg4pFcuOosgfIfnHSv3emTdIiACMKKl2x4uDL9gxGIQawcGvGjvRrrT8Na0xMMvNoFecx08arPLvgTmnkFKR30Vu5G/Ide7smSGBHpFHAjOdzxzD7K/oVqBNyVi8QJaBozu8jM6mFwP4mIqP5m+XK5asX7GHstzh2+XIFwj7IKHmywhiOa2BprQu16aNfqR45xT/XlHAnF30tHBvoWrB41+q5KaWqmoGf+onwHC/d1y4BOGiwy/lv1aTmfDtDiS+BMzcCYBXmXCGINk7737igr1PJIOrIGtMcfR5eNn6oTjvOp5eUQv5q30+8EFs+9SuH7gODLcg12P4+AgbURiqKwMwik9B6sGi6JLO0nLV4ZOx+pm6iH+ZF6HN2B+ObrmLMhYb3zBck7wbQwML+aWpoPbOu56Mfhe2LvUQjwLOtKeCm2i+1cnsQTvMQKuA6IetFbBvkGTMU6EnA+cF9ojtNEf4ROuO/KuDWpmNIe8QaaOQZpk2mogL6c2D8Eq8LtUK7ygh5ILgq8uyTUQEBAvpbzUpp3u/3OcEI52xMsyP9uAhwXZJPsdmgJShrQ7WI4WhpwlO24zwSZ4TQBvPs9
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:(13230031)(396003)(39860400002)(366004)(376002)(346002)(136003)(230273577357003)(230922051799003)(230173577357003)(1800799009)(451199024)(64100799003)(186009)(122000001)(38070700009)(66574015)(76116006)(66946007)(83380400001)(26005)(478600001)(6506007)(7696005)(71200400001)(966005)(53546011)(9686003)(66556008)(66476007)(2906002)(8936002)(8676002)(4326008)(55016003)(38100700002)(5660300002)(41300700001)(52536014)(166002)(86362001)(6916009)(64756008)(54906003)(66446008)(316002)(33656002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: iibGQorWfCxckkHX4UN5wmJ2AfGcHjxjuVEHh6pZxubCEV4sIqRa/ir+sxQp7fqTicshGP/TfgsLSCUkSWnC8m1KIyq2+nCYu+fgQNSt8meP00G/Sk26rCfH5Q2tda38v/hPYJjCu8tE1StEZ6oGva1urTqNvKGReWDjqpkU2M0RDlTxuVnLZulCasEHeXP6A0E/hpNBSrK7C16CblX8eSzGoqXWImjhnU0jx0oEnA+Oy1m1GvaF/sDQXPMmklMpEVZFVkdjmWs9yr4NqrEYUwp2lb6SCnLo82uBBRELGoOgxZmlv2YNh/ilDvz7bsBVGTSr38driGuWgNI2uIdMRFEvbPIgNHAaDP6vIJJ9jUE7GqPanL/UBnbzhD7VdzPCoqDSgYnmOGsXMJGAGbfHCO0KtSIgdqDGrS6f0zc6FqWxle/qo5VCQ2XCVQwmZtIGeHShSCBpY3NnrCoglkjJ5rthu1qxcnqG7jRvvErAeJNWK20NNS5dk7cUsUmf+TUY/z9vTAvFqSDPtZQ7Tio0DGcPuouTUfYcj/9wUNUzXP9kuoBpsWOS9FTYMJgryQJndypANYMKOz1xiGeU2NLHtYn2aT4x/GqsW+g9mhQ+Fos/whUYMNsNYIRBW10YeyXKaHk6vwf7YKu1M6UFIVM1Q7JCOS3z1w5UYNL3IEyqGOiyeS0FxEq96iHtSRU9Fovr5/NW+K092GBfcxawKBuvK9Wv7c7aMmOSFudY+ZxrTIWiVr23qT88itDo8MDqNKPsH3IWbJBBPNomWEj4GgwW1cecIv1DnNUKAMmBvURqh9wGWlFkUyrRhEX1opT3NnC1ExahT9utU8RMDcvEZxI7ZvqTpkldzR4h7+gACVDzOZZtF8hHu2/A8tozQ4zZglFIyEK9CxWU5SkzKX4Fpm9GX9C+mRZ20BlTgWl+15xGhR3nsmG5WldBAyhwX8jIcrvyWVTTV/U779tBFTThmKfC2hDFYydW2ZNDM1Z2xH1I4GlH3DBIMURx4fuFE9bf/5VEZ8rEl2TVKnFRPo39ZHvPAG8Kgs2v5fb2Wq5P5fdVmuqGnzJpOgWZdcqDfVQ6XV6WxOzl1Hh05s39M0mggt/C0A8ae3PWkot5TjxyaTJWxhn9lcC3wyxoVniRXq6L0r+HEcR05oJUvP94l8mTsAtSfsmozxEIWC0SLPwLi8MNCopeYjfOx+cJPFmXSvtDgSSK7Q+sf0WBOVyUi/31Su7k/yWAnYAMBw1D7lnG6hT8/7RtGzRI1Yug9c4Ch/xWoSqeNPO35vuu/ioBcG1/ExhsCX8e7687ldAH4/oXKkgNZAKBdiyu8i5JYY4Hv3w+CmamnYvpjKdOc9uZu0TqqI+7XYuiDpDROuXtM+Og107+gB1T8rDOhG9Gupx6TYvW5+oXhotevCjFxt2hXLVuE1EiSv1d/V4jixSZuL0qKTeJQBWF7TvlyuGCHcvcYGtXrYuAGClZDVhV+drZWbVKAIDxwRcQvHMyfOsoD1l0i+0sGv2ofmxeUwoc9GOHO9jzQwb6s9YqQSkgaga5SdV64m6ksEsfqC0uYWTncTamtISNC+l051ovzVMjxyFXc/6R5zdN
Content-Type: multipart/alternative; boundary="_000_BY5PR11MB43379993C0FCA66A6FDD76F4C1A9ABY5PR11MB4337namp_"
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4337.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: cb433a1d-a97f-452e-a049-08dbdf6ac43e
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2023 08:23:05.4538 (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: aAeijghkkew1sm3p++1Tp5CtceBYMhrZ6PV+8o3sNokUBif/aU5bmojuc0iTA0ndRkLbeMsiFGQa9IJ5BeN/MQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR11MB6060
X-Outbound-SMTP-Client: 173.37.147.229, alln-opgw-1.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/h_3O6ZPl_YSHr--9B2SiAUp5QPU>
Subject: Re: [Lsr] Technical questions for draft about unreachable prefixes announcement
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2023 08:23:17 -0000

Ketan –

I am very happy to be wrong in this case. 😊
We are in full agreement.

    Les


From: Lsr <lsr-bounces@ietf.org> On Behalf Of Ketan Talaulikar
Sent: Monday, November 6, 2023 11:52 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
Cc: John Drake <je_drake=40yahoo.com@dmarc.ietf.org>; Peter Psenak (ppsenak) <ppsenak@cisco.com>; Aijun Wang <wangaijun@tsinghua.org.cn>; lsr@ietf.org
Subject: Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

Hi Les,

I disagree with your reading of RFC9084 (OSPF Prefix Originator).

Sec 1
This document proposes extensions to the OSPF protocol for the inclusion of information associated with the router originating the prefix along with the prefix advertisement. These extensions do not change the core OSPF route computation functionality.

Sec 2.1

For intra-area prefix advertisements, the Prefix Source OSPF Router-ID Sub-TLV MUST be considered invalid and ignored if the OSPF Router ID field is not the same as the Advertising Router field in the containing LSA. Similar validation cannot be reliably performed for inter-area and external prefix advertisements.¶<https://www.rfc-editor.org/rfc/rfc9084.html#section-2.1-6>

A received Prefix Source OSPF Router-ID Sub-TLV with the OSPF Router ID field set to 0 MUST be considered invalid and ignored. Additionally, reception of such sub-TLVs SHOULD be logged as an error (subject to rate limiting).

As editor of this document, it is absolutely clear to me that we are referring to the sub-TLV and not the prefix advertisement. So, when the value is set to 0, the sub-TLV is invalid and ignored - the prefix reachability is not at all affected.
This is the reason why I am firmly opposed to using Prefix Originator value 0 for UPA or any other indication.

I hope I am able to convince you :-)

Thanks,
Ketan



On Tue, Nov 7, 2023 at 12:44 AM Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> wrote:
To add to what Ketan has stated…

draft-wang-lsr-prefix-unreachable-annoucement defines the same mechanism for both OSPF and IS-IS i.e., it proposes to use a prefix-originator sub-TLV with address set to 0.0.0.0 to indicate unreachability.
For OSPF, this might be considered compatible with RFC 9084 where it is stated that advertisements with “Router ID field set to 0 MUST be considered invalid and ignored” - though Ketan has indicated this usage is undesirable.
However, no equivalent statement was ever made for IS-IS in RFC 7794 – so this simply does not work in the case of IS-IS.
I (among others) pointed this out to the authors of draft-wang multiple times over the years, but my feedback was ignored.

Which is an example of why I would like to echo Ketan’s sentiments – let’s please put an end to this non-constructive discussion.

The authors of draft-wang have had many opportunities over the years to respond in a more constructive way to feedback. They were also – as Peter has indicated – given an opportunity to co-author draft-ietf-lsr-igp-ureach-prefix-announce out of respect for them bringing the problem space to the attention of the WG. They declined – which of course is their right. But they do not have the right to endlessly oppose the consensus of the WG.

Let’s please move on.

   Les


From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of Ketan Talaulikar
Sent: Monday, November 6, 2023 3:01 PM
To: John Drake <je_drake=40yahoo.com@dmarc.ietf.org<mailto:40yahoo.com@dmarc.ietf.org>>
Cc: Peter Psenak (ppsenak) <ppsenak@cisco.com<mailto:ppsenak@cisco.com>>; Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>; lsr@ietf.org<mailto:lsr@ietf.org>
Subject: Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

Hi Aijun,

As your co-author on the OSPF Prefix Originator RFC, I have stated many times (e.g. [1]) that overloading semantics of Prefix Originator is not a good or clean protocol encoding. Semantically, it is wrong and a very bad protocol design in my opinion. Going by this logic, tomorrow, someone would want to encode some different meaning for all 1's value in the originator address. We cannot be doing such (IMHO) HACKS in the protocol encodings.

It is better to signal the semantics/meaning explicitly using specific flags that are meaningful.

The authors of draft-ppsenak (now a WG document) agreed to this feedback from WG members and incorporated the U/UP flags in their draft. However, the authors of draft-wang seem to continue to refuse to accept feedback. It is perhaps one of the reasons why the WG adopted the draft-ppsenak and not draft-wang.

WG chairs, is there a way to put an end to this debate such that it does not continue endlessly?

Thanks,
Ketan

[1] thread https://mailarchive.ietf.org/arch/msg/lsr/FNbqHPhphY3GOfw-NWkLjmoRDVs/


On Mon, Nov 6, 2023 at 7:31 PM John Drake <je_drake=40yahoo.com@dmarc.ietf.org<mailto:40yahoo.com@dmarc.ietf.org>> wrote:
Aijun,

You castigated Peter for his lack of rigor in his reply to your email, however, I think that was completely unfounded.  Further, your reply to Peter seems to be argument by emphatic assertion, rather than "technical analysis/comparison".

Thanks,

John

On Monday, November 6, 2023 at 08:41:38 AM PST, Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>> wrote:


Hi, Peter:

Let’s focus on the technical analysis/comparison for the mentioned issues, and don’t repeat the subjective comments that without any solid analysis.

Detail replies inline below.
Aijun Wang
China Telecom

On Nov 6, 2023, at 14:53, Peter Psenak <ppsenak@cisco.com<mailto:ppsenak@cisco.com>> wrote:
Aijun,

please see inline:

On 06/11/2023 13:23, Aijun Wang wrote:
Hi, all:

Here are some technical questions for the hurry adopted draft about unreachable prefixes announcement:

1) There exists already “prefix originator” sub-TLV to indicate the associated prefix is unreachable, what’s the advantage of using other undefined, to-be-standardized, to-be-implemented sub-TLV?

many people have already commented on why overloading the “prefix originator” sub-TLV to signal unreachability is a bad idea. Please accept that feedback.

[WAJ] No one gives the technical analysis. Can you explain technically in detail?

You can set the prefix metric to LS-infinity to indicate the unreachability, why can’t we the prefix originator to NULL to indicate the unreachability?———The key idea for using “prefix originator” is here: if there is no router originate the associated prefix, then it is certainly unreachable. It is more straightforward than the LS_Infinity, and is also more easily implemented, deployed than the to-be-defined, to-be-standardized sub-TLV.



2) It is unnecessary to define the “UP” flag——if the operator know the unreachable event in advance, they can also schedule the switchover of the related services in advance. Why bother IGP to transfer such information?

looks like there are folks that see the value in it. I let them to comment more, but I don't necessarily see a problem in an extra bit. If you don't like it, don't use it.



3) There is very limited usage of LS_Infinity in current network. From the operator’s viewpoint, we will decrease its usage also in future. Then the solution should try their best to avoid their usages——Current solutions instead enhance its usage——It is unacceptable. Let’s keep the network simple.

the reasons for using the LSInfinity for unreachability has been discussed at great length a;ready. It's the backward compatibility for routers not supporting the new signalling - we need to avoid them interpreting the unreachability as reachability.

[WAJ] My emphasis is that we shouldn’t enhance the usage of LS-Infinity(you propose that the LS-Infinity metric must be carried) Instead, we should try to fade them out:
1) If all routers within one area/domain all support the new capabilities, we need not require the summary LSA to carry LS-infinity metric.

2) The Maxage of LSA can also be used to achieve the similar effects of legacy node bypassing.



4) We can’t ignore the partitions scenarios or let’s it go.

if you feel like the partition is the problem, you can write a separate draft and address it there. We are NOT trying to solve it with UPA draft. And for a reason.

[WAJ] They are coupled. If you don’t consider it now, you need to update your proposal later.




5) There should be some mechanisms to control the volume of advertised unreachable information, when compared with reachable information, as done in https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#section-6.


please look at the section 6 of the UPA draft.

[WAJ] I am referring to the balance advertisement of reachable information, as did in the above link, not the simple statement as the following: “It is also recommended that implementations limit the number of UPA advertisements which can be originated at a given time. “

Actually, even for your above statement, https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-12#name-deployment-considerations-4 gives more guidelines, I think you can refer to it again.


thanks,
Peter



Please consider the above technical issues carefully before evaluating and adopted any proposal.

If the above issues can’t be solved, we request the WG to adopt also the https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,which cover and solve all of the above issues.

Aijun Wang
China Telecom

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