feedback gezocht: maximum prefix limits (inbound / outbound) draft
Beste NLNOGers, Melchior en ik proberen te specifieren welke varianten van BGP maximum prefix limits er bestaan, en promoten een nieuw type limiet, de 'outbound maximum prefix limit' - met als doel het mogelijk te maken dat sessies automatisch uitgezet worden als je zelf een full table naar een peer leaked. We wouden de Internet-Draft hier circuleren voor feedback voordat we het naar IETF sturen. Het document is hier te lezen: https://raw.githubusercontent.com/bgp/draft-grow-maxprefix/master/draft-sa-g... Feedback qua terminologie, spelling, grammatica, zinsbouw - allemaal welkom! Met vriendelijke groeten, Job
prefix-limit outbound <> prefix-limit inbound <> Zoiets? On 18-12-18 17:01, Job Snijders wrote:
Beste NLNOGers,
Melchior en ik proberen te specifieren welke varianten van BGP maximum prefix limits er bestaan, en promoten een nieuw type limiet, de 'outbound maximum prefix limit' - met als doel het mogelijk te maken dat sessies automatisch uitgezet worden als je zelf een full table naar een peer leaked.
We wouden de Internet-Draft hier circuleren voor feedback voordat we het naar IETF sturen. Het document is hier te lezen:
https://raw.githubusercontent.com/bgp/draft-grow-maxprefix/master/draft-sa-g...
Feedback qua terminologie, spelling, grammatica, zinsbouw - allemaal welkom!
Met vriendelijke groeten,
Job _______________________________________________ NLNOG mailing list NLNOG@nlnog.net http://mailman.nlnog.net/listinfo/nlnog
Hi Dennis, On Tue, Dec 18, 2018 at 5:07 PM Dennis Ponne <dennis@ponne.nu> wrote:
prefix-limit outbound <> prefix-limit inbound <>
Zoiets?
Ja, maar de syntax zal natuurlijk van platform tot platform een beetje verschillen. Met vriendelijke groeten, Job
Job, Goed initiatief! een andere suggestie is om prefix-filter lists van je eigen IRR administratie te bouwen en die toe te passen op al je externe sessies. Jac On 18/12/2018 17:01, Job Snijders wrote:
Beste NLNOGers,
Melchior en ik proberen te specifieren welke varianten van BGP maximum prefix limits er bestaan, en promoten een nieuw type limiet, de 'outbound maximum prefix limit' - met als doel het mogelijk te maken dat sessies automatisch uitgezet worden als je zelf een full table naar een peer leaked.
We wouden de Internet-Draft hier circuleren voor feedback voordat we het naar IETF sturen. Het document is hier te lezen:
https://raw.githubusercontent.com/bgp/draft-grow-maxprefix/master/draft-sa-g...
Feedback qua terminologie, spelling, grammatica, zinsbouw - allemaal welkom!
Met vriendelijke groeten,
Job _______________________________________________ NLNOG mailing list NLNOG@nlnog.net http://mailman.nlnog.net/listinfo/nlnog
-- Jac Kloots Teamlead Network Services Network Department SURFnet
Goedemorgen Jac, Goede suggestie! Echter wat mij betreft out of scope voor deze draft. Het idee achter hetgeen Job en ik geschreven hebben is dat dit juist een fallback is waneer je vergeten bent om policies te maken of toe te passen. Dus een soort dodemansknop. Gr. Melchior On Wed, Dec 19, 2018 at 9:23 AM Jac Kloots <jac.kloots@surfnet.nl> wrote:
Job,
Goed initiatief! een andere suggestie is om prefix-filter lists van je eigen IRR administratie te bouwen en die toe te passen op al je externe sessies.
Jac
On 18/12/2018 17:01, Job Snijders wrote:
Beste NLNOGers,
Melchior en ik proberen te specifieren welke varianten van BGP maximum prefix limits er bestaan, en promoten een nieuw type limiet, de 'outbound maximum prefix limit' - met als doel het mogelijk te maken dat sessies automatisch uitgezet worden als je zelf een full table naar een peer leaked.
We wouden de Internet-Draft hier circuleren voor feedback voordat we het naar IETF sturen. Het document is hier te lezen:
https://raw.githubusercontent.com/bgp/draft-grow-maxprefix/master/draft-sa-g...
Feedback qua terminologie, spelling, grammatica, zinsbouw - allemaal welkom!
Met vriendelijke groeten,
Job _______________________________________________ NLNOG mailing list NLNOG@nlnog.net http://mailman.nlnog.net/listinfo/nlnog
-- Jac Kloots
Teamlead Network Services Network Department SURFnet
_______________________________________________ NLNOG mailing list NLNOG@nlnog.net http://mailman.nlnog.net/listinfo/nlnog
Hi, On Wed, Dec 19, 2018 at 09:22:55AM +0100, Jac Kloots wrote:
Goed initiatief! een andere suggestie is om prefix-filter lists van je eigen IRR administratie te bouwen en die toe te passen op al je externe sessies.
In dezelfde lijn - mensen zouden RPKI Origin Validation 'invalid == reject' niet alleen ingress moeten doen, maar ook egress! Met vriendelijke groeten, Job
Hi,
On 18 Dec 2018, at 17:01, Job Snijders <job@ntt.net> wrote:
[...]
https://raw.githubusercontent.com/bgp/draft-grow-maxprefix/master/draft-sa-g...
Feedback qua terminologie, spelling, grammatica, zinsbouw - allemaal welkom!
Klinkt als een mooie extra handrem om groote fuckups mee te voorkomen, ik zou zeker voor het gebruik hiervan zijn (zowel de voorgestelde inbound aanpassing als de outbound limit). Ik heb één kleine opmerking over paragraaf 4: "the BGP speaker MUST at a minimum be able to terminate the session and send its neighbor a NOTIFICATION message with the Error Code Cease and the Error Subcode "Threshold reached: Maximum Number of Prefixes Sent"" Ik zou overwegen deze error subcode duidelijker te maken zodat het verschil tussen de door de ontvanger gedefinieerde max prefix limit en door de zender gestelde max prefix limit raken zeer duidelijk is. Ik voorzie anders prachtige discussies tussen peers over waar de schuld van het niet op komen van sessies nou ligt. gr, Teun
On Wed, Dec 19, 2018 at 21:52 Teun Vink <teun@teun.tv> wrote:
Hi,
On 18 Dec 2018, at 17:01, Job Snijders <job@ntt.net> wrote:
[...]
https://raw.githubusercontent.com/bgp/draft-grow-maxprefix/master/draft-sa-g...
Feedback qua terminologie, spelling, grammatica, zinsbouw - allemaal welkom!
Klinkt als een mooie extra handrem om groote fuckups mee te voorkomen, ik zou zeker voor het gebruik hiervan zijn (zowel de voorgestelde inbound aanpassing als de outbound limit). Ik heb één kleine opmerking over paragraaf 4:
"the BGP speaker MUST at a minimum be able to terminate the session and send its neighbor a NOTIFICATION message with the Error Code Cease and the Error Subcode "Threshold reached: Maximum Number of Prefixes Sent""
Ik zou overwegen deze error subcode duidelijker te maken zodat het verschil tussen de door de ontvanger gedefinieerde max prefix limit en door de zender gestelde max prefix limit raken zeer duidelijk is. Ik voorzie anders prachtige discussies tussen peers over waar de schuld van het niet op komen van sessies nou ligt.
Heb je specifieke suggesties? We hebben dat stukje inderdaad geindentificeerd als “tricky” Met vriendelijke groeten, Job
On 19 Dec 2018, at 22:01, Job Snijders <job@ntt.net> wrote: [...] Heb je specifieke suggesties? We hebben dat stukje inderdaad geindentificeerd als “tricky”
"Number of prefixes received exceeds maximum advertised by peer" misschien? gr, Teun
Hoi, On 19/12/2018 22:04, Teun Vink wrote:
On 19 Dec 2018, at 22:01, Job Snijders <job@ntt.net> wrote: [...] Heb je specifieke suggesties? We hebben dat stukje inderdaad geindentificeerd als “tricky”
"Number of prefixes received exceeds maximum advertised by peer" misschien?
Dat geeft waarschijnlijk nog steeds verwarring over waar de prefixes vandaan komen (inbound/outbound), en dus waar het probleem ligt. Suggesties: - "Outbound prefix limit exceeded" - "Threshold reached: local outbound prefix limit exceeded" Dat zou voor beide kanten van de sessie duidelijker aangeven waar het probleem ligt, lijkt me. Groeten, Steven
Hi, Is het niet handiger om gewoon een stel grote klanten hierom te laten vragen? Deze draft is effectief gezien hetzelfde als "vendors, doe dit asjeblieft implementeren". En de meeste vendors gaan dat pas doen als er genoeg vraag naar is en er een business justification voor gevonden kan worden. Overigens kan ik me er prima in vinden hoor, erg handig als secondaire protection layer. Thanks, Sabri ----- On Dec 18, 2018, at 8:01 AM, Job Snijders job@ntt.net wrote:
Beste NLNOGers,
Melchior en ik proberen te specifieren welke varianten van BGP maximum prefix limits er bestaan, en promoten een nieuw type limiet, de 'outbound maximum prefix limit' - met als doel het mogelijk te maken dat sessies automatisch uitgezet worden als je zelf een full table naar een peer leaked.
We wouden de Internet-Draft hier circuleren voor feedback voordat we het naar IETF sturen. Het document is hier te lezen:
https://raw.githubusercontent.com/bgp/draft-grow-maxprefix/master/draft-sa-g...
Feedback qua terminologie, spelling, grammatica, zinsbouw - allemaal welkom!
Met vriendelijke groeten,
Job _______________________________________________ NLNOG mailing list NLNOG@nlnog.net http://mailman.nlnog.net/listinfo/nlnog
On 19 Dec 2018, at 22:38, Sabri Berisha <sabri@cluecentral.net> wrote:
Hi,
Is het niet handiger om gewoon een stel grote klanten hierom te laten vragen? Deze draft is effectief gezien hetzelfde als "vendors, doe dit asjeblieft implementeren". En de meeste vendors gaan dat pas doen als er genoeg vraag naar is en er een business justification voor gevonden kan worden.
Eerst formuleren wat je dan aan die vendors wilt vragen is wel handig dan. Dan gaan die vendors ook hopelijk hetzelfde doen. Daar lijkt me zo'n draft vanuit de community een prima startpunt voor. groetjes, Teun
On Wed, Dec 19, 2018 at 22:50 Teun Vink <teun@teun.tv> wrote:
On 19 Dec 2018, at 22:38, Sabri Berisha <sabri@cluecentral.net> wrote: Is het niet handiger om gewoon een stel grote klanten hierom te laten vragen? Deze draft is effectief gezien hetzelfde als "vendors, doe dit asjeblieft implementeren". En de meeste vendors gaan dat pas doen als er genoeg vraag naar is en er een business justification voor gevonden kan worden.
Eerst formuleren wat je dan aan die vendors wilt vragen is wel handig dan. Dan gaan die vendors ook hopelijk hetzelfde doen. Daar lijkt me zo'n draft vanuit de community een prima startpunt voor.
Teun, je slaat de spijker op de kop - het is goed als we eerst iets definiëren waar mensen naar kunnen verwijzen wanneer ze vragen stellen in RFPs. Het lijkt er op dat de ambiguïteit in de originele maximum prefix limit specificatie (onderdeel van RFC 4271) heeft geleid tot segmentatie in de markt waar een sterk voorbeeld het verschil tussen Cisco (enkel pre policy) en Junos (mogelijkheid voor zowel pre- als post policy) is. Groeten, Job
On 19 Dec 2018, at 22:49, Teun Vink <teun@teun.tv> wrote: [...] Eerst formuleren wat je dan aan die vendors wilt vragen is wel handig dan. Dan gaan die vendors ook hopelijk hetzelfde doen. Daar lijkt me zo'n draft vanuit de community een prima startpunt voor.
Nog wel even een aanvulling: Ik ben het wel met Sabri eens dat een paar grote klanten die hier wat gewicht achter gooien goed zijn om dingen daadwerkelijk geimplementeerd te krijgen bij vendors. Maar in mijn ogen is dat stap twee dan, en is formuleren wat je wil hebben de eerste stap. gr, Teun
Ha Sabri, Teun, Het is een tweetrapsraket; je hebt een specificatie nodig waar klanten om kunnen vragen en vervolgens heb je klanten nodig die daar om vragen.....of the other way around kan ook. De reden dat wij dit nu opschrijven is omdat wij het een goed idee vinden en klanten dan kunnen gaan vragen bij hun vendor wanneer ze di implementeren (zoals Teun ook al aangaf op IRC). Dus zeker eens met jullie punten maar first things first; nu opschrijven wat we willen, zorgen dat het RFC nummer krijgt en dan erom gaan vragen :) Thanks voor jullie support! Melchior On Wed, Dec 19, 2018 at 11:12 PM Teun Vink <teun@teun.tv> wrote:
On 19 Dec 2018, at 22:49, Teun Vink <teun@teun.tv> wrote: [...] Eerst formuleren wat je dan aan die vendors wilt vragen is wel handig dan. Dan gaan die vendors ook hopelijk hetzelfde doen. Daar lijkt me zo'n draft vanuit de community een prima startpunt voor.
Nog wel even een aanvulling:
Ik ben het wel met Sabri eens dat een paar grote klanten die hier wat gewicht achter gooien goed zijn om dingen daadwerkelijk geimplementeerd te krijgen bij vendors. Maar in mijn ogen is dat stap twee dan, en is formuleren wat je wil hebben de eerste stap.
gr, Teun _______________________________________________ NLNOG mailing list NLNOG@nlnog.net http://mailman.nlnog.net/listinfo/nlnog
Hi, Mooi werk! Hierbij mijn opmerkingen/suggesties: 3.1
Adj-RIB-In stores routing information learned from inbound UPDATE messages that were received from another BGP speaker Section 3.2 [RFC4271]
Adj-RIB-In stores routing information learned from inbound UPDATE messages that were received from another BGP speaker (see [RFC4271] Section 3.2).
As example [..]
As an example [..] 3.2 Je geeft een voorbeeld van wanneer de sessie niet down gebracht wordt, maar er ontbreekt een voorbeeld en RFC2119-tekst waarbij de sessie wel down gebracht wordt. Iets als de volgende tekst: "As an example, when an operator configures the Type B post-policy limit for IPv4 Unicast to be 50 on a given EBGP session, and the other BGP speaker announces a hundred IPv4 Unicast routes of which 75 are accepted due to local policy (and thus considered for the Loc-RIB by the local BGP speaker), the session MUST be torn down. On the other hand, if in the same example no prefixes are accepted due to local policy, the session is not torn down." Ik zou nog expliciet noemen dat de Type-B prefix limit voor een peer gelijk of lager dient te zijn dan de Type-A limit om effect te hebben. Dit zou ook afgedwongen kunnen worden in de configuratie. "In order to have effect, the Type-B prefix limit for a peer MUST be equal or lower than the Type-A limit for this peer. Implementations SHOULD/MAY(?) prevent configuration of a Type-B prefix limit that is higher than the configured Type-A limit. 4. De verwoording van de Error Subcode kan beter, zoals al eerder genoemd. Ik sluit me aan bij Steven's suggesties.
The routing information stored in the Adj-RIBs-Out will be carried in the local BGP speaker's UPDATE messages and advertised to its neighbors Section 3.2 [RFC4271]
The routing information stored in the Adj-RIBs-Out will be carried in the local BGP speaker's UPDATE messages and advertised to its neighbors (see [RFC4271] Section 3.2).
[..] the BGP session MUST be torn down and send the neighbor a NOTIFICATION message [..]
[..] the BGP session MUST be torn down and a NOTIFICATION message must be sent to the neighbor [..]
Outbound Maximum Prefix Limits can be thought of as Dead Man's Switches.
Outbound Maximum Prefix Limits can be thought of as "dead man's switches", preventing policy configuration accidents or malfunctioning from causing harm to other BGP speakers. Groet, Martin
participants (9)
-
Dennis Ponne -
Jac Kloots -
Job Snijders -
Job Snijders -
Martin Pels -
Melchior Aelmans -
Sabri Berisha -
Steven Bakker -
Teun Vink