IETF Logo Mail Archive

Re: [GROW] Prefix limit ORF

<Thomas.Graf@swisscom.com> Tue, 26 March 2019 18:36 UTC

Return-Path: <Thomas.Graf@swisscom.com>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDBC1202FA for <grow@ietfa.amsl.com>; Tue, 26 Mar 2019 11:36:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=swisscom.onmicrosoft.com
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 OltjPUPe9MQE for <grow@ietfa.amsl.com>; Tue, 26 Mar 2019 11:36:11 -0700 (PDT)
Received: from mail.swisscom.com (mailout110.swisscom.com [138.188.166.110]) (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 1C31D1208A9 for <grow@ietf.org>; Tue, 26 Mar 2019 11:36:10 -0700 (PDT)
Received: by mail.swisscom.com; Tue, 26 Mar 2019 19:36:05 +0100
Message-ID: <325942011.3388587.1553625365433@ss007564.tauri.ch>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="----=_Part_3388585_1222670094.1553625365432"
X-Mailer: Totemo_TrustMail_(Notification)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Swisscom.onmicrosoft.com; s=selector1-swisscom-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eE66/Z00pU/b5q88mOwQMshUvoC8jchvDYrlfwc2xNQ=; b=QNi43f3De4xoLtfDMgCku977EK8kZvtLbgnmKvgPQ5yr9b7gXzjYqfZ32I7TJxwtqUg9SWPPbk2EfHPMnOCgPo5+Sl01cr8dW7YRPxgrGrSGYNdgor40JuvevrZ60K+H3UrvVHZyCKUQIAH+1TdIczzRYGk6MR8z5OVFb9gEuB8=
From: Thomas.Graf@swisscom.com
To: robert@raszuk.net, jgs=40juniper.net@dmarc.ietf.org
CC: grow@ietf.org
Thread-Topic: [GROW] Prefix limit ORF
Thread-Index: AQHU4+zXMtz/BfIWWk2VIy1FkAWyD6YeEsGAgAAa4UA=
Date: Tue, 26 Mar 2019 18:35:46 +0000
References: <D8F9A493-D343-4AFD-96DF-3F702BF79597@juniper.net> <CAOj+MMHPMG92Z_vK-nxeFri-12cJZDXNUxX42bOsOX4rrzJ0YQ@mail.gmail.com>
In-Reply-To: <CAOj+MMHPMG92Z_vK-nxeFri-12cJZDXNUxX42bOsOX4rrzJ0YQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=True; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Owner=Thomas.Graf@swisscom.com; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2019-03-26T18:35:43.8113033Z; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 Internal; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Application=Microsoft Azure Information Protection; MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Extended_MSFT_Method=Automatic; Sensitivity=C2 Internal
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Graf@swisscom.com;
x-originating-ip: [178.197.224.157]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 885df451-b21b-4168-38b9-08d6b219dcfa
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR02MB4608;
x-ms-traffictypediagnostic: VI1PR02MB4608:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <VI1PR02MB4608CB71B39EC0C777585622895F0@VI1PR02MB4608.eurprd02.prod.outlook.com>
x-forefront-prvs: 09888BC01D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(39860400002)(136003)(396003)(199004)(189003)(51914003)(8936002)(486006)(26005)(316002)(9686003)(25786009)(72206003)(86362001)(606006)(11346002)(110136005)(54896002)(6306002)(236005)(81166006)(33656002)(55016002)(966005)(8676002)(478600001)(106356001)(68736007)(81156014)(446003)(74316002)(99286004)(6246003)(105586002)(476003)(4326008)(7736002)(14454004)(53936002)(102836004)(66066001)(10300500001)(2906002)(3846002)(6116002)(229853002)(10290500003)(790700001)(7696005)(256004)(5660300002)(76176011)(186003)(14444005)(6436002)(66574012)(97736004)(6506007)(71200400001)(71190400001)(53546011)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR02MB4608; H:VI1PR02MB4429.eurprd02.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: swisscom.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: ELF5wb0Hr9wftMX1YeFsy3O7pXqZNq6miSjYpBehX+CGTVboowIimRFXUpLL2WrwaLtdqZpnDkvS/ogsw1defnmc5g90jpd9Kz4UnqPgZ4g0UQZWrilyvdWb+ZjHP8E+kppxUMmJKREhGCCaNM4ciHh6OREdq46CmLcXwrm4ppVBgkWMOwbkpPbC2FTqOEmhAwcCLf2eDGJ2/UWBSf3urOFsYkeyxWQKr9p1DT4DmDu3L/WgPaGRvsXz2a3iiyZsLWKvQKIeVdYJFfG5mjbJhbsSO97qSaQKxjGxXQAHzDB9DTvqfF3KjHuZdH6gnuiUsPrlv29IfQaSvkQoVm76vMLXmBsVqXXJxDwGal2+1kGr0A/tk1XmqQD2h7nsTCXPcG78yuOPHz4cCzwqoTJvEtym0E0OqSwbCOfqM8rolr4=
X-MS-Exchange-CrossTenant-Network-Message-Id: 885df451-b21b-4168-38b9-08d6b219dcfa
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 18:35:46.8995 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 364e5b87-c1c7-420d-9bee-c35d19b557a1
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR02MB4608
X-OriginatorOrg: swisscom.com
X-CFilter-Loop: Reflected
X-Trustmail: processed
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/Wm9YOOEhYy1DuBKM3u_7gZsBZIs>
Subject: Re: [GROW] Prefix limit ORF
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Mar 2019 18:36:24 -0000

Hi Job,

Thanks for the input regarding draft-keyur-idr-bgp-prefix-limit-orf-03.

That’s what I meant. Incoming peer prefix limit needs to be advertised by BGP. I think it’s a bad idea to configure statically an outbound peer maximum prefix limit. The only reason why I want that is to align with my peer. Ideally, these parameters should be automatically exchanged between peers. John and Robert point out that both of them are in competition which should take precedence. This points usually to a bad design.

Let me go to the big picture and share my thoughts. The reason why we want inbound prefix limits is because we don't have endless resources in the BGP RIB's. Right? Thanks to

https://tools.ietf.org/html/rfc7854#section-4.8


we are able to monitor their usage. Great. But we don't have any IETF YANG model available giving us the maximum possible route count on each BGP RIB. Why? Therefore we don't know at which threshold we should alarm. Nor we don't know at which static threshold we should limit the amount of prefixes we receive from which peer. Nor thus this mechanism account for the BGP local RIB maximum capable routes. If my BGP local RIB supports 1'000'000 routes and I have 10 peers with an average of 70'000 routes each. How high should I set the inbound prefix limit? My answer: +10% more prefixes in BGP local RIB than alert, +20% more in BGP local RIB than limit the peer which caused the issue and alert. Should be monitored with BMP stats reports (https://tools.ietf.org/html/rfc7854#section-4.8) and orchestrated automatically within BGP YANG model (container prefix-limit). Monitored and orchestrated in a closed loop operation. Do we want' that logic to be built in routers? Does one router has the big picture of the network and their peerings? No. Therefore it needs to be solved outside the BGP router.



Kind regards
Thomas Graf
____________________________________________________________________________
Network Engineer
Datacenter Functions
Telefon +41-58-223 84 01
Mobile  +41-79-728 80 12
thomas.graf@swisscom.com<mailto:thomas.graf@swisscom.com>
____________________________________________________________________________
Swisscom (Schweiz) AG
IT, Network & Infrastructure
Datacenter Functions
Binzring 17
8045 Zürich
www.swisscom.com
Postadresse:
Binzring 17
8045 Zürich


From: GROW <grow-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Tuesday, March 26, 2019 5:02 PM
To: John Scudder <jgs=40juniper.net@dmarc.ietf.org>
Cc: grow@ietf.org
Subject: Re: [GROW] Prefix limit ORF

And with this in mind the draft needs to define expected behaviour when locally configured outbound prefix limit is different from ORF pushed one (someone's inbound).

Lowest wins, static wins, latest wins etc ... otherwise each implementation may choose differently ;)

thx
R.

On Tue, Mar 26, 2019, 16:59 John Scudder <jgs=40juniper.net@dmarc.ietf.org<mailto:40juniper.net@dmarc.ietf.org>> wrote:
Apropos Job’s talk just now —

draft-keyur-idr-bgp-prefix-limit-orf-03
https://tools.ietf.org/html/draft-keyur-idr-bgp-prefix-limit-orf-03

—John
_______________________________________________
GROW mailing list
GROW@ietf.org<mailto:GROW@ietf.org>
https://www.ietf.org/mailman/listinfo/grow

v2.23.0 | Report a Bug | By Email