Re: [Idr] I-D Action: draft-sas-idr-maxprefix-inbound-02.txt

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Wed, 12 May 2021 21:38 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 72C463A2A49 for <idr@ietfa.amsl.com>; Wed, 12 May 2021 14:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.585
X-Spam-Level:
X-Spam-Status: No, score=-9.585 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, 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=Wom5G/DG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=evoeF0Zi
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 xx927ABqCEMf for <idr@ietfa.amsl.com>; Wed, 12 May 2021 14:38:16 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042053A3478 for <idr@ietf.org>; Wed, 12 May 2021 14:26:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33510; q=dns/txt; s=iport; t=1620854804; x=1622064404; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lpowFfrDJF24ai1cSNBvvVx6PwZ3hkHacy43lK+wBIU=; b=Wom5G/DGnmyPYI8waouV4i8V25YFMQT2Q5v138CDgLwCdSB+a94ju/la mVWnSbk1F7HWygJc1I/nIxwPME4pqPuL1RcOGhaOdOCKrwfcoNdX3zPc2 dkC6BdwlAc2uetD/gPVMtUx2Xt84/WV3dABsDS1x275xrEr+L+Q9iAUKj o=;
X-IPAS-Result: =?us-ascii?q?A0B2AADDR5xgmJtdJa1XAxwBAQEBAQEHAQESAQEEBAEBg?= =?us-ascii?q?gYEAQELAYEiMCMGKH5aEiQxhEeDSAOFOYh9A5lcgUKBEQNUCwEBAQ0BASUBD?= =?us-ascii?q?AgCBAEBhE8CF4FdAiU3Bg4CBAEBAQEDAgMBAQEBBQEBBQEBAQIBBgQUAQEBA?= =?us-ascii?q?QEBAQFohVANhkQBAQEDAQEBIQoTAQEsBgUBBAsCAQgHBwMEAQEBIAcDAgICJ?= =?us-ascii?q?QsUCQgCBAENBQgTggtLAYF+VwMOIQEOnkECih96gTKBAYIGAQEGBASBNAEDA?= =?us-ascii?q?gKDdRiCEwmBIxcBgnqEDAEBhlonHIFJRIEVQ4JfPoIfICIBAQOBIwUBAQoBB?= =?us-ascii?q?gEjFQoMCQgJglAXH4ItgU8aQhkGIhAMAiQEA0APAQUPGyAMBQYVOSAJNScrk?= =?us-ascii?q?TiDBIgDjQyRcQqDFYoAh3uLXBCDWIsSlkqTOYF6jASTChgWhDsCAgICBAUCD?= =?us-ascii?q?gEBBoFqImtwcBU7gmkJRxcCDo4fDA0Jg06FFIVJcwI2AgYBCQEBAwl8iU0BJ?= =?us-ascii?q?4IfAQE?=
IronPort-PHdr: A9a23:MwINZRVHLWKIPeH2tKQcCK9upn7V8K3gAWYlg6HPw5pBd62i+9LpO 0mMrflujVqcW4Ld5roEjufNqKnvVCQG5orJq3ENdpFAFnpnwcUblgAtGoiJXEv8KvO5YCkzH cAEX1hgrDm3NEFPE5P4YFvf6nS58T8VHED5Mgx4buT4E4LflYK5zee3rpbSeA5PwjG6ZOAaE Q==
IronPort-HdrOrdr: A9a23:0ZnzzKvk5uw2MewBxR275bAh7skCqYMji2hC6mlwRA09TyXGra GTdaUguyMc1gx/ZJh5o6H+BEGBKUmskqKdkrNhQ4tKPTOW9ldASbsD0WKM+UyaJ8STzJ856U 4kSdkDNDSSNyk6sS+Z2njDLz9I+rDum8rE6Za8vhVQpENRGtxdBmxCe2Cm+zhNNXF77O0CZe OhD6R81l6dUEVSSv7+KmgOXuDFqdGOvonhewQ6Cxku7xTLpS+06ZbheiLonis2Yndq+/MP4G LFmwv26uGIqPeg0CLR0GfV8tB/hMbh8N1eH8aB4/JlaQkEyzzYJriJaYfy+Azdk9vfr2rCV+ O85SvICv4Drk85uFvF+CcFlTOQiArGoEWSuGNwyUGT0fARAghKUPaoQeliA0bkA41KhqAn7E sD5RPri7NHSRzHhyjz/N7OSlVjkVe1u2MrlaoJg2VYSpZ2Us4dkWUzxjIfLH47JlOx1GnnKp gZMCjW3ocbTbpbVQGQgoBL+q3iYp0eJGbzfqEygL3d79ENpgEN86Ix/r1pop4vzuNOd6V5
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.82,295,1613433600"; d="scan'208,217";a="685415095"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 May 2021 21:26:14 +0000
Received: from mail.cisco.com (xbe-aln-006.cisco.com [173.36.7.21]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 14CLQDNa027272 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 12 May 2021 21:26:13 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xbe-aln-006.cisco.com (173.36.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Wed, 12 May 2021 16:26:13 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 12 May 2021 17:26:12 -0400
Received: from NAM02-BN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 12 May 2021 17:26:12 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WBrFhBm3N7607lWFoB5ecJDYTSqDf75Wueg3bVm8gkaH1qctxuebWWyVo4zHq3+DARYGJZV21/vZHq91A02zEMWBVExqOT9rn7MwPaFi0QYiCIZlh7if5/eP7t37jJCTNhfIHUEgIJynX1K9rSL3/JT289X4RfNkU6Gf9ytVuoVtz4AZvqJlcFYcZeWX+tkyWuM3r1CeKNEyCEP8Iqwyyy1ru2uIh34tT6AEH7swGeDT9wNE8rjWc4BqA20JRV7T6O8v7pnzYWH49Oa8Wa7TXCBH//Th6YwSG6QJ9l5mE2aiGUrVZtMndFfmdDXxrJqUeVfzTGlx1Qwybz7Bwik0jw==
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=lpowFfrDJF24ai1cSNBvvVx6PwZ3hkHacy43lK+wBIU=; b=lOVtQglKz/Kd2Krez2lX9hQxsuHmjntA5tDBLXHAqEgTqychXGj8wEcyV2WJD6FmAWcigpC3fFEvFZS1oekPkY9OsQG2G06cs+99wdCDVgxaSBkVfsvurU1pDqj31fK6RkvrsrclDnkKO5m0FKHtEaNoFDMyg2nkr9InaVO61VDejWArKctpdAswxkvir3hDQa1aF107E4yPoGMlhMguIOkf9p2LOl9EIa6WMQY5XsbPCqv2ZY6RV1fLN5kKjwBTRzv4NsoefP0WMAmrDRSG72yujlmuTra8LiFJF8Bbu2jS2I8I7HBbIWOvIkwxyDWPPZltFpPC9j51MVfwE1CEnw==
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=lpowFfrDJF24ai1cSNBvvVx6PwZ3hkHacy43lK+wBIU=; b=evoeF0ZiETTMYJNlut1o/flzcYWPiut1IPiptlGll+Hdloi2qiiQwQJ+EP5Jmptwd3KCTy23r2vSoaZ2D3zcdsrdEthdwexPxXKfI4hPM2rYg5qDLjChIlCSYzb9AHn8pN8+0zTPTK/9F05JnS8ymvgf4UnKRukp6UGQTOfyDr8=
Received: from BYAPR11MB3207.namprd11.prod.outlook.com (2603:10b6:a03:7c::14) by BY5PR11MB4136.namprd11.prod.outlook.com (2603:10b6:a03:192::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.26; Wed, 12 May 2021 21:26:11 +0000
Received: from BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::106d:d229:f71b:b34f]) by BYAPR11MB3207.namprd11.prod.outlook.com ([fe80::106d:d229:f71b:b34f%4]) with mapi id 15.20.4108.031; Wed, 12 May 2021 21:26:11 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Gyan Mishra <hayabusagsm@gmail.com>, Melchior Aelmans <melchior@aelmans.eu>
CC: "idr@ietf. org" <idr@ietf.org>, Melchior Aelmans <maelmans@juniper.net>, Robert Raszuk <robert@raszuk.net>
Thread-Topic: [Idr] I-D Action: draft-sas-idr-maxprefix-inbound-02.txt
Thread-Index: AQHXMfFrTLXM9ljR7k6FaD+snnPsJKq1nkAAgAAGxoCAKMhgAIAACEcAgAAnUACAAP1xAIAA5a8w
Date: Wed, 12 May 2021 21:26:11 +0000
Message-ID: <BYAPR11MB3207A318E89779FDBE4F1EDFC0529@BYAPR11MB3207.namprd11.prod.outlook.com>
References: <161843563034.11054.13811966622190622752@ietfa.amsl.com> <CAOj+MMH=cCgtn7cL=HvOjQOMH1B9tmjOYOT04jXE9oky4SuevQ@mail.gmail.com> <YHhJTB51/joiz9Pg@snel> <CAOj+MMEFOGm=hCQcZNAUoN8vsPeVT3gqnjsQihUMJo4AOObZfw@mail.gmail.com> <CALxNLBhtQDDo9Dn7vBAZx+RbVwJ5BSbZfRS1wGStt_k7C2nPuQ@mail.gmail.com> <CAOj+MMHDPGt30deY6KtC+E-5eD9Q8cRtrL-xydLhsNic7KBdSw@mail.gmail.com> <CALxNLBi5Borzgr6ntRZHu0P6dnEcoZ8pk7=JKKfRhNcUbv873w@mail.gmail.com> <CABNhwV2mUP2f8sKdqOEde35U6a5idY+XGWNf0G2rzheRULhmmw@mail.gmail.com>
In-Reply-To: <CABNhwV2mUP2f8sKdqOEde35U6a5idY+XGWNf0G2rzheRULhmmw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2601:647:5701:46e0:e145:5b96:6241:b67a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 255ef063-26e2-4767-22cb-08d9158c906b
x-ms-traffictypediagnostic: BY5PR11MB4136:
x-microsoft-antispam-prvs: <BY5PR11MB4136EB8542F9C806F693699AC0529@BY5PR11MB4136.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: ZzhMPXoFuqDdsBozlwn/PSWCgpqxPP09YjYmWsoO3Ax0983dtCAYRPNmwXW9GaNgW423DFnNr0ed3w91N6HDSg0uj3nR9znCycx+lJCOY9FmXnLAl7ZQfR1pKKrMZsFLsXK9C1ldz+RAWbHCVgL5OU1Qfxl17SlRB6kMM5lWvm9rVfF2W5yzcHkPeWw/B1mG3OtkPTbTgLz2jkJpLVahs9tc+OK8AGj+qrk1MObDAcE5a8yQ1KXoWDCgEEssTDUVnDi88YkgpupIHXawT+UZwS5qls5xUVD0Gyuu0WICoMBQKuXxwk2jOfVWy6SynX40wDzk4kGcDFmCqpUMJcrpaPR/Iy8PQ6XfLhc5RRlj3cLtW1UQc87aPrxZjtNvvE3GUMLKG2JmUR0nSTQthDshokH21XbFnttZlWWuXgteF6GQLXrI5Vw/ABHty12egSLzRWvVN0Vr3/6oLWNY2mbhBztdfOLRZcDOP3gAC82wuBkmXYkXklvdHqqkKjxAShbeXeb9ZIZJvjvJDialQE8HsMbVOdFpofS88PRo2WgwIQYHcGD/rIODBqMhoM0QHx/lmRxmQBBKYBMjHQg/YzcgoPhqbOkxXbpBs9u3+Pbn24xDFgeWoxCEbI1zfDsD8PZ/wPKIXrlt9mjwrz+zsTrYXlG32GIbsoJOkLT8ASMiCrTcnsL1u2gAMxO2ESyvMRWXC00fXJ9eC7AYZ1KnZNG8K3qn94i3A5yRCEQg8WfAipI=
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:(376002)(396003)(39860400002)(366004)(136003)(346002)(6506007)(53546011)(966005)(52536014)(186003)(71200400001)(54906003)(83380400001)(76116006)(122000001)(316002)(8676002)(8936002)(66446008)(66556008)(66476007)(64756008)(7696005)(66946007)(9686003)(55016002)(33656002)(5660300002)(4326008)(110136005)(478600001)(86362001)(166002)(2906002)(66574015)(38100700002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?RlJPVXd4TWF1bFUreHRPRFBoenpqRm9NM0kySWtEdW5hUGpGT3Jaa1pDODFN?= =?utf-8?B?MHBBN09zM0EvSXA4THhQTmZrSnk2MTRac2xXYWtXcFllVEpQMWR1UTEvWm52?= =?utf-8?B?bldLZWlFZ1pUcFpYZStIbHBRVlRZb1JLeE1SeHFQcDF2L016bVdxM2RDbkl2?= =?utf-8?B?QmJYV0hiSGdvTDVLMTZ2di9FOTBOSW03LzNnYUdHSDE0OFNwUlNDQVY5OFJ0?= =?utf-8?B?NmtXeTBBZmJ5WTJ0YmtDT0xYQm8yNDA4WTBmMEUxN2RoZGRTMHdKaUNXOStM?= =?utf-8?B?S1YvM2dQeGlOaUFHeHNDYWlnbWJhZkVjbWdrbVdFT0FvYTFPNTgyYVlHeXgz?= =?utf-8?B?R2dqNWZtWktLbWFBS1A3UVFrVHA3U2Y4ZlhJZjJ6N2c2aVllTWRYWkZ6cEY5?= =?utf-8?B?bGJ5NmJtVFRIS0RJaDN2VGlwMUNqSE5xeFZSUnVzL2g5NThRdlcwcjRaUjdO?= =?utf-8?B?ek15RWxrMldkd3E1TU9LYlpzd1lHcFI5Q3RBWFM5RDQrYTV1MXdPQXpQWkJY?= =?utf-8?B?K2tJajlzLytuUnhsQ3RGOHBIVEhyUEhIeWpLTkpqb21ER2pKOHlPZTlCT1lN?= =?utf-8?B?MCsrRVJWWWV3b3Nhd3lSOWlGRzI4RFpyT2VYNHlqSmhQSFJ1VzdJcmR1T0VC?= =?utf-8?B?NGNHZjN4ZjMveWhWbmxnbms2bXlMVWtITW9YU21hU1orT3RZMVZBNVZFb01Q?= =?utf-8?B?cG1QeUNQNzBJT1R1b0lNR3AzejViUTBCZ1lOMS9FVFYzZ0ltVXBtMWs5TkRn?= =?utf-8?B?a2ZSM0J3VXhHdk50cGkzZTNDVGFxdUpFMWI1dFNXMzNMREdtcG1nQjdqa0sy?= =?utf-8?B?MDBrWjI4ZG0yeGxZbFJMeWdxNXFKamgyc3ZBekpjWHovRXp2dlRMS2srUEpz?= =?utf-8?B?MmFISXRldlJvamhpSlludll4UyswUjM2ZS9IeVdBMW4rUDE3djJ4OXRZYm4v?= =?utf-8?B?d01GdWptZjVvaXFUVW42STlWTWMyVE9RalpWajlDNHcydUp1M3VjSGNqeGQz?= =?utf-8?B?WmNnNTE5dHJzaDZJS2VNQ20zaDZ5ZURnQ25ObjJiRExFQUVPUWRmcTJ3bGlM?= =?utf-8?B?R3hNdlFuUkd1Y1krbG10MDAxcUFzWTdQUG92eFh3S3QxYjlOSUhhbHBySDZE?= =?utf-8?B?VG9ReENOZ1ovUGQ1WWcrbkNpb0ZoaU43UkpBSlo5d212LzN6eWl4WU5KU0lI?= =?utf-8?B?VFpubHB1SFZ1ZTlPMldpZXBBMXE0N283dzdqZTJKd1g1dTROd01EbThWU21n?= =?utf-8?B?aXlZUzY3RFoxQ0h1U0k2TkZsNk1CM2FLT3RtemRVWG9KYjJKc21lcjNOSGNR?= =?utf-8?B?Sy92ZXlRSjMrajNrUzhIZ0NWOGJTU1MrM0pzd3hZcXhZZWxjMTVSTW5PSlh6?= =?utf-8?B?TGk0NERySURyajBaeEVINUl6MTZZSzE4cE1ZZElxNEtldE44UXRodS96WkNV?= =?utf-8?B?OXQ2UE92YVhLcWk0QjY3c2pMRmtFNXAvdERvK1RhemtwTFhmbjhwcnNLMC94?= =?utf-8?B?MVhjNFBMak9GdGZHMzdZeGo3UmR2RWRLbkpOdGlsWEwxY3lhYjU2ZTVHNko0?= =?utf-8?B?QWV0d3h6YU5wL3VSNElJRFlJS1REdlFmazA2VXNadDAxWUY1K2lhZWh1ZlJD?= =?utf-8?B?TDU1SzlNdE5wbVQ2N2RROVRRQVQyZ09LMUFhQ2krcXVNdGhwWHRWVnVmSW1k?= =?utf-8?B?akJyMFpmeWVOODdDTHk2dnhCY0tMeUJQK1VpTDVFQWJWMzhXbnpNbFpsbno5?= =?utf-8?B?VGtEZk9VWkhrNENDRVdKZkhHemxBTXhtMUxLMy9KNUJHRURrcTRTUDRaakFo?= =?utf-8?B?Q25yNGJ2UVhFNEE2OWtXamxrWC92SnBMTGo1QlNvZGVMSFJuUDVYdUsyM01Z?= =?utf-8?Q?KfnEH3wdjVugQ?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB3207A318E89779FDBE4F1EDFC0529BYAPR11MB3207namp_"
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: 255ef063-26e2-4767-22cb-08d9158c906b
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2021 21:26:11.0182 (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: xs6t+YVNJQcLsYRFUpzExmYesqNm2aL/9618RVhN4K0g5W+wF/iIxtfa1bGHDCd59n8k9o9KXtHUPfQ1f+su/A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4136
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.21, xbe-aln-006.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/lMz499Cl8N-10b-PHXXNwj2VEAk>
Subject: Re: [Idr] I-D Action: draft-sas-idr-maxprefix-inbound-02.txt
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, 12 May 2021 21:38:31 -0000

The reason to terminate the session is illustrated in:
https://datatracker.ietf.org/meeting/104/materials/slides-104-grow-bgp-maximum-prefix-limits-00

Suppose you have a customer whose prefix advertisements vary somewhat,
so you give him a decent margin. Suppose you set max-prefix to 1000
and on a fateful day he advertises 200 prefixes.
You have some good inbound filters for him, but not perfect, again,
because the prefixes he advertises vary somewhat.
Now, on this day, he leaks the internet to you and you manage to filter most of it out,
but several routes sneak past your filter and leak.
Those that sneak past your filter are not enough to trip your max-prefix of 1000.
If you have a pre-policy max-prefix of, say, 10000, that will easily catch the leak
and you could terminate the session to stop the leak.

Regards,
Jakob.

From: Idr <idr-bounces@ietf.org> On Behalf Of Gyan Mishra
Sent: Wednesday, May 12, 2021 12:20 AM
To: Melchior Aelmans <melchior@aelmans.eu>
Cc: idr@ietf. org <idr@ietf.org>rg>; Melchior Aelmans <maelmans@juniper.net>et>; Robert Raszuk <robert@raszuk.net>
Subject: Re: [Idr] I-D Action: draft-sas-idr-maxprefix-inbound-02.txt


After thinking about it I agree that that the prefix pre and post can definitely be different.  The pre policy is a copy of the adj-rib-in stored separately in memory so the limit values can definitely be different. In such case as the pre policy is pre inbound filter so it can have a very high water mark for maximum prefix, and the post policy would have the maximum prefix exact value to trigger the neighbor being clamped down. In general the trigger event peer being clamped down would happen on the post policy adj-rib-in as that value would always be lower then the pre policy adj-rib-in.  In that respect thought I can’t see a scenario where the pre policy maximum prefix would take down the peer over the post policy maximum prefix.  That being said I am not sure we really need a pre policy maximum prefix.

I understand the reason behind it to save on memory copy of tbt ash-rib-in but I don’t think the action that the peer must be taken down if pre policy maximum is exceeded if the post policy is not exceeded.  The post policy the control plane rib is programmed into hardware for forwarding so there is more impact to resources both control and data plane for post policy as opposed to pre policy is control plane copy and also is not advertised to other peers as well as are pre policy prefixes.  Much less impact if pre policy is exceeded.

I think the case where a peer advertisement went from 100k to 2M and the pre policy was set to
1M and the post policy was set to 100k and 100k was received in this case if it was a Must to clamp down the peer due to pre policy being exceeded where post policy was not exceeded  I don’t think that’s a good idea as is impacting.  I think for pre policy maybe only a warning should be allowed but not clamping down the peer.

Gyan


On Tue, May 11, 2021 at 12:13 PM Melchior Aelmans <melchior@aelmans.eu<mailto:melchior@aelmans.eu>> wrote:
Ack Robert, thanks for confirming.

Cheers,
Melchior

On Tue, May 11, 2021 at 3:51 PM Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:
Hi Melchior,

After rethinking this I think the current text in the draft is ok.

It is after all optional cfg and if vendor supports both pre and post policy max-prefix limit inbound the configured numbers may not need to be identical.

Thx,
R.


On Tue, May 11, 2021 at 3:22 PM Melchior Aelmans <melchior@aelmans.eu<mailto:melchior@aelmans.eu>> wrote:
Hi Robert, all,

First of all thanks for your feedback!

The part we are confused about is that soft-reconfiguration inbound is a Cisco command to enable adj-RIB-In which then stores all the received routes. On Juniper and OpenBGPd (and possibly other implementations as well) adj-RIB-In is enabled by default and protected by a maximum-prefix limit inbound.
Could you please elaborate on what you are exactly trying to describe and as Job suggested make suggestions for text adjustments?

Thanks!
Melchior

On Thu, Apr 15, 2021 at 4:36 PM Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:
Hi Job,

The distinction between Per and Post policy is clear.

Inbound Prefix Limit may (depending on implementation) apply to either or both of those processing stages.

The observation I am trying to make is that IMHO soft in is not really a Pre Policy in a sense that you must not apply Prefix Limit to it. Otherwise the entire idea of soft-in becomes questionable.

To me perhaps the proper way to visualize it is actually to divide Pre Policy into two blocks - ALL Prefixes and Pre-Policy Prefix-Limited. All Prefixes block would occur only when soft in is enabled. Otherwise some may expect or request to apply Inbound Prefix Limit before routes are stored when soft reconfiguration inbound is enabled.

Or perhaps you actually want to do that sort of breaking that knob ?

Many thx,
R.






On Thu, Apr 15, 2021 at 4:10 PM Job Snijders <job@fastly.com<mailto:job@fastly.com>> wrote:
Dear Robert,

On Thu, Apr 15, 2021 at 02:16:12PM +0200, Robert Raszuk wrote:
> I think I have one question or suggestion.

Your review is appreciated!

> As you all know some implementations allow you to explicitly force BGP
> speaker to keep (pre-policy) all routes/paths received.
>
> Example:
>
> neighbor 192.168.1.1 soft-reconfiguration inbound
>
> The draft does not seem to comment on this case yet if implementation
> maintains the above behaviour at least some of the justifications for
> the document is gone.

Interesting, the draft's objective is to clarify that inbound limits can
be applied at multiple stages of the pipeline (pre and post policy), not
all Network Operating Systems appear to offer this (operationally
speaking much needed) granularity, and through this draft we hope to
clarify to implementers that it is something worth considering to add.

> I think that draft should at least mention such behaviour, not force to
> change it however put some light that if
> configured by the operator some of the benefits of inbound prefix limit
> will not be fully effective.

What you call 'soft-reconfiguration inbound' ends up storing into what
the draft refers to as 'Pre Policy'. (At least... that is the intention,
it is possible the text is readable to us but not easy to understand for
others)

Do you have specific text in mind to add to the draft to clarify this?

Kind regards,

Job
_______________________________________________
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
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email gyan.s.mishra@verizon.com<mailto:gyan.s.mishra@verizon.com>

M 301 502-1347