Subject: [GROW] Prefix limit ORF

From: John Scudder <[email-masked]>
Date: Tue, 26 Mar 2019 15:59:07 +0000

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

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 26 Mar 2019 17:02:25 +0100

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=[email-masked]>
wrote:

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: "Aliaksei Sheshka" <[email-masked]>
Date: Tue, 26 Mar 2019 14:26:56 -0400

On Tue, 26 Mar 2019 15:59:07 +0000

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

 I fail to see how such approach solves anything.
According the draft max-pref is send through the same channel
as prefixes themselves. Why should one trust that? On other side,
if there was kind of RPKI object which ties ASN+AS-SET+maxpref
what would be a different story, since that would out-of-band
verification.

---

From: <[email-masked]>
Date: Tue, 26 Mar 2019 18:35:46 +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
[email-masked]<mailto:[email-masked]>
____________________________________________________________________________
Swisscom (Schweiz) AG
IT, Network & Infrastructure
Datacenter Functions
Binzring 17
8045 Zürich
www.swisscom.com
Postadresse:
Binzring 17
8045 Zürich

From: GROW <[email-masked]> On Behalf Of Robert Raszuk
Sent: Tuesday, March 26, 2019 5:02 PM
To: John Scudder <jgs=[email-masked]>
Cc: [email-masked]
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=[email-masked]<mailto:[email-masked]>> wrote:
Apropos Job’s talk just now —

—John
_______________________________________________
GROW mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/grow