[Idr] One Admin Domain

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Wed, 07 April 2021 21:55 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 6FF1A3A2B20 for <idr@ietfa.amsl.com>; Wed, 7 Apr 2021 14:55:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.617
X-Spam-Level:
X-Spam-Status: No, score=-9.617 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_DNSWL_BLOCKED=0.001, 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=PVW6Y7cB; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QrIZBCiP
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 MH02rOEpQUOg for <idr@ietfa.amsl.com>; Wed, 7 Apr 2021 14:55:05 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D814C3A2B2C for <idr@ietf.org>; Wed, 7 Apr 2021 14:55:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5915; q=dns/txt; s=iport; t=1617832504; x=1619042104; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=1caOw2BzQ59ubxV4YWbkaWA8mRtAJjj/OfghAzrAyKM=; b=PVW6Y7cB4cESDqRhd8F7EpFkrB9TQXid1+pGCzEcdmW9ftGEkAlQ+xHr nBe62SYlylufNVBGhFMl7/M5/8XaZB/fnpKHLw6Gzrx/Ea6bQiJiYhKxb KjJazkCYgiUu1mX+Z6oHrnQ6smBXp3g0Ty6WaeBQgnNjfZb/ByD1M+1f5 4=;
X-IPAS-Result: =?us-ascii?q?A0A7AABIKW5gmJhdJa1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFSgVNRflo2MQOIBwOFOYhQA4EJmDKBQoERA1QLAQEBDQEBH?= =?us-ascii?q?QYPAgQBAYEWAYM5AoF3AiU4EwIDAQEBAwIDAQEBAQEFAQEBAgEGBBQBAQEBA?= =?us-ascii?q?QEBAWiFUA2GRAEBAQECAgE4BgEBKgIIAwEEBwYBGQQBAQEeNwsdCQEEDgUIg?= =?us-ascii?q?mkBglUDDiEBDqJVAoofdYE0gQGCBAEBBoUmGIITAwaBOQGCdYZjhBscgUlCg?= =?us-ascii?q?RNDgimDVAEBgUcbg0qCK4FaLERAIQdTWyAdLBUEChUIGhQEkT4GqUUKgwuJY?= =?us-ascii?q?5M8g02aVYZPlyWJWpJ2hEkCAgICBAUCDgEBBoFrIYFbcBU7gmlQFwIOjh8MB?= =?us-ascii?q?QgJg06FFIVFcwI2AgYKAQEDCXyLOF0BAQ?=
IronPort-PHdr: A9a23:DrD8Kxzod8boTwHXCzMxngc9DhMPsqjoPgMT9pssgq5PdaLm5Zn5I UjD/p1FhUPVG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHxkClY0NngMmDcLEbC+zLPPjYyEgW sgXUlhj8iKyLVQTE8H7NBXep3So5msUHRPyfQN+OuXyHNvUiMK6n+C/8pHeeUNGnj24NLhzN x6x6w7Ws5p+vA==
IronPort-HdrOrdr: A9a23:EqTsLK4ZpWwD2WffQQPXwZiFI+orLtY04lQ7vn1ZYSd+NuSFis Gjm+ka3xfoiDAXHEotg8yEJbPoexLh3LZPy800Ma25VAfr/FGpIoZr8Jf4z1TbdRHW3tV2kZ 1te60WMrLNJHBxh8ri/U2cG9Ev3NGI/MmT9Jrj5l1GJDsaDJ1IxQF/FwqdDwlSTA5JGZI2GP Onl7Z6jhCnfmkaadn+O2IMWPLNq8aOuJXtZxMHABBP0njAsRqD7rnmHx+EmioPSj8n+8ZvzU HpsSzcop+ivfay1wPG2wboj6h+tdP9xrJ4dbexo+cPLDGEsHfMWK1Ee5mv+A84u/uu7lFCqq iDnz4FM95o433cOkGZyCGdoTXI6zol53/8xVLwuxKKyqaVKENYeqh8rLhEeRjU4VdIhqAb7I t33nmUv5cSLRTMkDWV3amxazhWl1G5qXdnrOgLj3Y3a/pmVJZtq+UkjSdoOaZFOBi/xJEsEe FoAs2Zzu1Ra0mmY3fQuXQq6MCwX1wody32A3Qqi4iw6Xx7jXp5x0wXyIg0hXEb7q8wTJFC+q DtLrlorrdTVcUbBJgNRNspcI+SMCjgUBjMOGWdLRDMD6ccIU/ArJbx/fET6Py1focLiL8/go 7IXl8dlWNaQTOsNeS+mLlwtjzdSmS0WjrgjutE4YJih7H6TL33dSKZTlQjlNahvuUfDsXXV+ 3bAuMSP9bTaU/VXapZ1Qz3XJdfbVMEVtcOh9o9U1WS5sLHQ7ea8tDzQbL2Hv7AADwkUmTwDj 8oRz7oPvhN6UitRzv9iBjVUHX9Z1zn8ftLYe/n1tlW7LJIGpxHswATh1j8zNqMMyd+vqs/e1 Y7JqjmnKO9rWy/5n3J8G1tJxpYAi9ukffdekIPgTVPH1L/cL4FtdnaU3tVxmG7Khh2SN6TDB RSvE1t+aW8L4WZwCcrD97PCBPds1Ij4FaxC7sMkKyK4snoPq4iBpE9QaprCEHgDBpugztnr2 9FdS4JTkLSDSnVlK2glZAYbduvLuVUsUOOG4p0oWianViArcsvL0FrIAKGYIqyu0ISYBZ6wn d26LQShbKcny3HExpAvM0IdHtWaGqWB7paCh+if4s8oMGyRChACUGXmDedlxY/Pk3t+kl6vB 26EQSkPdfWH1FapndUlpzPzWoxXGCcc0VsA0oK6rFVHXjau3p1zO+Abrey1WzUcVcZ3uQBKl j+EEovCxIryNat2BGPnjGeUX0g25U1J+TYSK8uarfJxxqWWca1vLBDG/9f55B+Mt/y9ucNTO KEYgeQRQmIQt8BykiQpnw/PjNzp2RhmfT02Af95Gz92HIkG/LdLBBnQL4cSuvsp1TMVrKN0J 9ji8gysvb1OmLtasSewaWSdiVdMHro0BqLZvBtrYoRsbM5tbN1EZWeWTzU1Gtf1BF7KMvvjk sRTKly/bipAP4kQ+UCPyZCulY5ntWGK0Um9hb7BeIzZlkhhX7WNdHh2cu/lZM/Rkma4AfgM1 iW9CNQu+rfVyyYzLgAFuY+J39VZEVU0gUuwMqSM4nLTAOkeOFI8ADkbjuzcLpBRLOEHrtVpB Bg+N2Ml/KWcS292A24h0oIHotet2K8BcW1C0aQHOQN9dqwM1GFmLGr786+ly2fc0rNV20IwY leMVUNZcFCgCQ4hII50iKuWrX6y3hV4Gd28HVijBrxwYCo72fQAFFePQDYiptQWyNPMnLgt7 WxzcGIkHLn4DZE3pHfFEBfOtFWcuJgPrTKEw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.82,204,1613433600"; d="scan'208";a="693812133"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Apr 2021 21:55:03 +0000
Received: from mail.cisco.com (xbe-aln-002.cisco.com [173.36.7.17]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 137Lt3vb014171 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 7 Apr 2021 21:55:03 GMT
Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-aln-002.cisco.com (173.36.7.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Wed, 7 Apr 2021 16:55:03 -0500
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Wed, 7 Apr 2021 16:55:03 -0500
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 7 Apr 2021 17:55:02 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lz8Vk0igUvf9sVTz8D05TUJRPV45K85yc+fTSX8JGWlZsoO1yDaLtyM33Lfn2etcDvpZl6yTNcMFngS70/qpdp8O7yGIfiknMASvf2PA6JP5g8PLrFufSzzHPXFahZqdsMtD3b1q1BvaUTEKYSyWJLOPMx8e7cBltIXuL2FpIhBopoQbj5L82YdWY/tFIMBmaroXs4segBn7KG4Lr7JfTeLch3XJIBlmExZP+JjECp0s70iqhnBorm9DCmu9isvTQKdofsHADK005AKiVelKGOzkjVDEMLAidIjWt4S1NO67V0LVTW/3Bc8cpkqbZjlhfp43A45pGvHta1Uex5KIog==
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=5Bp8i7O6RjuHQacR5u6X1bbzzPA8BVLioj7UFKqqHXI=; b=OQheWM8bQBVMSlKSpOeQBZ44Zloa93uu/SjTbxaR9CnrCgQpeySwr8wRoQEKbYP7CEQWZU3aURpGscHkF/cAgyE2pljuFYEBbCUT+dc1H27Yz8huGlKbeSx/3HDI4WK+OCEoQE/OOwQ3rz7wi84ZrkP4s9OxgGKpWYdu5Dwdmju86ITdZ6NMttfxpL0U3Ayu5gtUrw4LYC9FFAxpUAj+pm+09bNJ4yvvSpduJ+Uq9vbVGLIYx9ieAmPEJCxE4JZ7pJpUfdwxvDNWjTsjO0FVr+lXXKEu3wOApTQCUn2rcnK+bdVxyariRl6izCR8h4awGYFs8GZFUjO0sFMvcie/bg==
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=5Bp8i7O6RjuHQacR5u6X1bbzzPA8BVLioj7UFKqqHXI=; b=QrIZBCiP5cy4htDztkhfpBBQCrYc1jsau2tg+Tqp4TWp0rvuICOm1hZZgyJnotMAFW1sp12U+mbMbqMdJa9vA9vGaRSYEUJBV5pS5YOObDaJKlrcOp2IsoVvH189Qxk52/AMUaJThE7qsQxPWnNlqu/TTCWqVcovqm/CtagjAPY=
Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BYAPR11MB2774.namprd11.prod.outlook.com (2603:10b6:a02:c1::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.32; Wed, 7 Apr 2021 21:55:01 +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.3999.033; Wed, 7 Apr 2021 21:55:01 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: "UTTARO, JAMES" <ju1738@att.com>
CC: "idr@ietf. org" <idr@ietf.org>
Thread-Topic: One Admin Domain
Thread-Index: Adcr9hZmlKm2YwrFRIW5ehKVUp4yTw==
Date: Wed, 7 Apr 2021 21:55:01 +0000
Message-ID: <BYAPR11MB32078DF8E3EE49F3248742C7C0759@BYAPR11MB3207.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: att.com; dkim=none (message not signed) header.d=none;att.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:647:5701:46e0:477:5f11:e97e:9b48]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e2548679-a407-4484-608d-08d8fa0fcb46
x-ms-traffictypediagnostic: BYAPR11MB2774:
x-microsoft-antispam-prvs: <BYAPR11MB27747785DC9ECF5843895E16C0759@BYAPR11MB2774.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: X5WGUNCxKl1C9cjGei6DPCQSoK7rROXU6yFr3NsGnA/R7Q3nUfQ5QuRPjQX2DjED94xmNtoX/fBU6GwS3iAHVEGEvmiRRx/54ORoOWJ3sQFOXa/ct4FPMezjYl619farDGeYe4hGEFVNKQptDBC+20OSEttQFE7x0lYenOk/iDZjlGOq+OEXcMtHP+FgDvwSQ20MtsFFFitCZ2wUJid97Z19oHmfKVd5uzKpbMkA4Xwidmt9EUhv+4Zs3lhKV5kPfY6Bphy+SwznpeOnc+hZmroXt89rDKctkZr2yIhrU7C6CNcH+/YxB1bAo4XV2CPLdQFVX9vtgX1dmzb4lII9Cjct6QTNeFx8nMjsqDKh8M6nhN/YKc27WH7YXgN0MHzjH1zCh3/1V1Pu1IVpVRNnfY3GRWHjipd3dOzvLnJ1oc+ePbPKvhTRk5LQYfo2SSBAzzSiqRGb+gNmyJJ6lRzp/sYFfOa58sJrrZIwtd5KQAb6tzeW63m/ercgR5Ea3SUrFjoH+J13zPQG5S4b7NrNEyXk+WiE2E4HOJmXQaWc/nw1tWisyiPH38go+J42Z/hcpXse/aGE8eW0SyLuWIwX28hlfoK7kLGCYPP3oLalAQ0uwT/cuo+MoOEyTkSfCsJFG8GQasmTCTIUEB7aq/oQRCVcUEP00+6ZEugD+vgtbDgz0Swa3J74FSo4bxM+Au45P5nqeSfgGG2gKNPVsDyOnO54AWJxVymQLXdNLhSLvEuCOPd+7F6SLA4cRMeRm9t5
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:(366004)(39860400002)(136003)(346002)(376002)(396003)(7116003)(6916009)(38100700001)(5660300002)(8676002)(4326008)(3480700007)(8936002)(7696005)(66556008)(478600001)(76116006)(52536014)(966005)(66446008)(66946007)(86362001)(66476007)(64756008)(2906002)(316002)(71200400001)(6506007)(55016002)(9686003)(53546011)(66574015)(83380400001)(33656002)(186003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?wQkoBzR5GyaQVxTx3CDii436Lk1klzPJtGTz6/xKjK8kSR0/LyyH2T0mFw9o?= =?us-ascii?Q?ailizEA+zNuuk/DWZLZ6HzQR3v3XwRC00B7fFlQJV/S+SXBDK/fnKkKz+vxg?= =?us-ascii?Q?q9iFR291/x0tWiMJZcvG88x3+jK+Tjphl6Xj+ulFc9DhBqWSCOl7GC3zHyCC?= =?us-ascii?Q?HwQr3z+crAcaeHznRYEtQJ9Pszer/tjBjnxX1xmTZVz4/+i9o2nrmjTyIVLR?= =?us-ascii?Q?Ey5SFYjUZC+CJQDWzMBdjNap5KTO+/LfcepPAcHQ17TbJsOdGA1EFPDFfhTx?= =?us-ascii?Q?3lbVxXBIqFDheyXzGhJ4iyYRZIGOF7pANaHVo0E+WrVVTwOcCT8L3h+sq2Dv?= =?us-ascii?Q?7ZsaTfJ40zeEjyVXXK5Uegi0JP/HOlKL18bjux+AsSBTPPHT4w/N6LPLN75Z?= =?us-ascii?Q?s4BNO8Xfa/B8lhs/Qwxm+XxEnN5a5CQO3tuaukym/UzvPlN8pElDba1KvH0O?= =?us-ascii?Q?EWtnrGrWWU9xQ4rDpI8FCT88NRpCcbjBQKYTXeYz9l8nvzwD9ayCqYUmJKcz?= =?us-ascii?Q?QeKvCPeYT81vE+6z7Ko6jBwNxrcOTRO8ooVxldAd5uJP6Fw62ssodLopWERd?= =?us-ascii?Q?+y3hdCL0W2oh8znGjmLAo+QHcQ+i9CfCImWm21NNUuMwE0lc/PeeCokHDSoO?= =?us-ascii?Q?SsuPy2SL5BtyHVvZ0TC6UUQXz2YVIiA1Krjzd1qSTy2zoWCfzPgQPtQ3ioDi?= =?us-ascii?Q?rl48d7Xa0JH48OpBkEk6HI7T8QzsJiyMWfdtbGhI9OrPoUm5uOqY7wpOlQmU?= =?us-ascii?Q?RvXBjGc+kyBemVEXVdjmt0Ast/5X0WjX6wq+8ay6vEtsJivQY2Ur6iAlnu2H?= =?us-ascii?Q?9CxdUJXYJLGt3lk0Cf0VNlHb3+wADIwxkruI7cCytp5c5w2QhyiLxf3wNidx?= =?us-ascii?Q?/SAZlIAMGOFt3aYiSNLpOjqhNfOibN+I4qIUvYeQBRbFLXrh2quWHG6lSJBe?= =?us-ascii?Q?gdH1OLKtNoB+YxmCw0NCrWXEz4OUT8h2OSofSZCdpsyrBUYcErvhkkZr0tJu?= =?us-ascii?Q?4XkNKsBziXkNg6Pw5KMESj7hJSdBgMh6r2bQ80khiVMeUZurUtCHwD498BME?= =?us-ascii?Q?j+CT1Xz2GTqfpVghTyevTe0e2QSZNSJl26e51WvoS9RI6QlanCIpJtVe9mgx?= =?us-ascii?Q?xSdrKO5CvmuBLzafokQzcTmMWAUNvXl+RUmd/LHd8t2SzAQ4kl8n3G5ND6hM?= =?us-ascii?Q?kVv1GwNNI+Sk0K66x+Fb4KbT9F4aHmbYc5hL6LZETaqlRwmcTF6UkJjvMK2z?= =?us-ascii?Q?KTLQAK9ML4iAMuVGwohivuZ79ANBnVFso1vjocCvY51xjmY+nUOm5cora27F?= =?us-ascii?Q?rYH9E3f5b3BgYwqaKAjfXscizQIrss4Sw/g0i2lvu3UIJUPwiyJQ2Kw20dDV?= =?us-ascii?Q?A/PF5PPsLEtvF42VRH8MY+j8pMEx?=
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: e2548679-a407-4484-608d-08d8fa0fcb46
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2021 21:55:01.3766 (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: 8smlKl6LnstSTXaahcvrunv9hy0WXDnQl8dN5OSSS+vuw3wZBE2SCUbqddFcqlMi7ANC1eIs9nw7cRObCtje+Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2774
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.17, xbe-aln-002.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/kUh3WxY-4dLFZur6D-7cm5Ao4EI>
Subject: [Idr] One Admin Domain
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, 07 Apr 2021 21:55:11 -0000

Jim,

That draft looks fine. Was it ever submitted? I can't find it in a search.

I would add a mechanism to reduce the AS_PATH length.
When sending out of the OAD, replace the sequence of ASNs in the
OAD by a single configured master ASN.
If a route is received by a speaker in any AS in the OAD from a speaker not in
the OAD, then the master ASN in the AS_PATH counts as a loop.

Regards,
Jakob.

-----Original Message-----
From: Idr <idr-bounces@ietf.org> On Behalf Of UTTARO, JAMES
Sent: Wednesday, April 7, 2021 6:43 AM
To: Jeffrey Haas <jhaas@pfrc.org>rg>; Robert Raszuk <robert@raszuk.net>
Cc: idr@ietf. org <idr@ietf.org>rg>; Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

" I don't believe we're likely to come up with a simple answer to BGP
capability domains soon.  That said, operators in a single administrative
domain at least can figure this out themselves because they're the ones
configuring it"

This discussion illustrates that a single administrative domain spanning multiple ASes should be addressed. Pradosh, John Scudder and I began identifying how an OAD ( One Administrative Domain ) should behave in terms of an eBGP and OAD-eBGP learned paths. ( See Attached ). 

As an example if we offering RFC 1998 feature to a customer whose VPN spans multiple AS domains requires that the operator preserve or reset ( default ) the LP. The customer may want to scope LP to a given AS or have it apply across an OAD.  As operators we have figured out how to create a somewhat seamless reachability/forwarding domain upon which services can be overlaid. That being said it maybe time to re-look at the scope of an AS vis-a-vis Admin domain including capabilities on a router, AS and OAD level..

Thanks,
	Jim Uttaro





-----Original Message-----
From: Idr <idr-bounces@ietf.org> On Behalf Of Jeffrey Haas
Sent: Wednesday, April 07, 2021 9:25 AM
To: Robert Raszuk <robert@raszuk.net>
Cc: idr@ietf. org <idr@ietf.org>rg>; Susan Hares <shares@ndzh.com>
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

Robert,

I think you're mixing some of the points together.

On Wed, Apr 07, 2021 at 12:29:21PM +0200, Robert Raszuk wrote:
> I have a question on how practical this proposal is.
> 
> Fundamental problem with today's BGP capabilities is that the information
> is only known to the peer.
> 
> So if I inject flowspec rule from behind the RR the RR will suppress some
> updates but:
> 
> * sender will have no clue about it
> * any other flow spec BGP speaker which supports request filtering down the
> BGP path will never get the chance to receive and apply the filter.

This is explicitly acknowledged in section 5.

It's also indistinguishable from policy.

> Both are IMHO bad. The latter is in fact directly against flowspec spirit
> to apply filtering as close to the src even if hops on the way are not
> capable of doing so.
> 
> So I am yet to be convinced this proposal is useful.
> 
> Today as a general rule if a router does not support an extension received
> via flowspec it just does not apply it but still can happily propagate the
> update down the road.

Not a single BGP flowspec implementation implemented the "opaque" property
in RFC 5575.  Not one.  And it was the strong motivation to remove that text
in RFC 8955.

This may change in flowspec v2 where we likely will make the NLRI proper
type-length-value rather than implied length as it is currently done.

How well the argument to filter unsupported components stands once we're to
something like flowspec v2 will be the longer question.  For such scenarios,
once we're no longer concerned about propagation characteristics of the
NLRI, it's quite reasoanble for a route reflector to carry NLRI with
filtering components it doesn't understand - but edge devices may not want
it.  But in that scenario, perhaps it's simply better for edge devices to
accept it and simply not install it.

> I think what we have here on the table is an illustration about the growing
> need for domain wide (or set of domains under the same admin) capability
> distribution such that all BGP speakers could advertise their
> capabilities to interested parties. A bit broader than flowspec, but could
> be useful here.

At the day job, we talk about the "flooding domain" of new features that are
gated on their capabilities.  BGP doesn't provide an explicit concept for
this, but it's become a protocol intrinsic behavior.  Unless you configure a
capability between two devices, it does't gain the ability to use the
feature.  A contiguous set of devices using those capabilities becomes that
domain.  That domain may, or may not, have strong overlap with one or more
ASes under the control of one or more parties.

For many BGP features, knowing what those domain boundaries are isn't much
of a problem.  Flowspec implementations with disjoint capabilities is a
place where it could be problematic.  (Again, see section 5.)

---

I don't believe we're likely to come up with a simple answer to BGP
capability domains soon.  That said, operators in a single administrative
domain at least can figure this out themselves because they're the ones
configuring it.

Right now, we are unable to safely deploy new flowspec features. Even when
you have disjoint flooding domains, if your flowspec rules are independent,
you can gain benefit.  So, short term for flowspec v1, I think there's
benefit for this feature.

-- Jeff

_______________________________________________
Idr mailing list
Idr@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!BhdT!zKnvUXaBTauH415pLQgguhjbJ69dkTpI04OgwY3aoSSiPV4IGBB2u-MqG68$