Re: Outbound Route Filtering (ORF) vendor support

Thanks Jeffrey! Well, I invested 15 minutes passing my eyes on the IDR list archive Joel mentioned(scary!). You were very concise describing ll that discussion in such polide way. I agree that without combining prefix-list and as-path, the effectiveness of ORF, considering its initial

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

On Thu, 19 Aug 2021 at 02:03, Randy Bush wrote: > > The difference is, if you are able to use PeeringDB as a single > > source of truth, it is a lot easier to grab the data you need. > > < pushing the analogy to the absurd > > > great idea! please tell me when i can use peeringdb as the single

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

> The difference is, if you are able to use PeeringDB as a single > source of truth, it is a lot easier to grab the data you need. < pushing the analogy to the absurd > great idea! please tell me when i can use peeringdb as the single source of truth for my bank balance? how about i can learn

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

> Currently RPKI can only validate origin, not paths. not exactly you ar speaking of route origin validation RPKI The RPKI is an X.509 based hierarchy [RFC 6481] which is congruent with the internet IP address allocation administration, the IANA, RIRs, ISPs, ... It is just a

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

When did PeeringDB turn into a routing (policy) registry? You should use an IRRdb if you want to write RPSL. * sa...@cluecentral.net (Sabri Berisha) [Thu 19 Aug 2021, 01:59 CEST]: The difference is, if you are able to use PeeringDB as a single source of truth, it is a lot easier to grab the

Re: "Tactical" /24 announcements

I'm also in the externally managed space...very cool tool though. I love the idea of distributing some of this functionality. Are you also exporting and managing this data outside? On Tue, Aug 17, 2021 at 12:23 PM Ben Maddison via NANOG wrote: > Hi Saku, > > On 08/17, Saku Ytti wrote: > > I

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

- On Aug 18, 2021, at 4:03 PM, Rubens Kuhl rube...@gmail.com wrote: Hi, > Currently RPKI can only validate origin, not paths. If/when a path > validation solution is available, then one easy way to know that > network A really means to peer with network B is to publish a path > validation

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

Currently RPKI can only validate origin, not paths. If/when a path validation solution is available, then one easy way to know that network A really means to peer with network B is to publish a path validation that B can use and/or forward A's announcements. Rubens On Wed, Aug 18, 2021 at 7:53

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

* sa...@cluecentral.net (Sabri Berisha) [Thu 19 Aug 2021, 00:55 CEST]: For example, if I were to register my peers (53356 and 136620) and AS5524 would all of a sudden start to advertise my AS as behind it, you'd be able to flag that. I'm confused. When did PeeringDB turn into a routing

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

- On Aug 18, 2021, at 3:02 PM, Patrick W. Gilmore patr...@ianai.net wrote: Hi, > Those networks would be ones that do not peer. Which seems pretty obvious to > me > - it is literally in the name. I have an AS, I advertise IP space to the world. I want to be a Good Netizen and register my

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

> Of course! Including headers to show authenticity. I was very amused by the > explanation of the "chicken and egg" problem. Who's creating that? The > networks > who refuse to peer with non-peeringdb registered ASNs, or peeringdb who won't > recognize ASNs that are not peering with anyone

Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

- On Aug 18, 2021, at 2:21 PM, Patrick W. Gilmore patr...@ianai.net wrote: Hi, > On Aug 18, 2021, at 5:00 PM, Matthew Walster wrote: >> On Wed, 18 Aug 2021, 21:37 Sabri Berisha, wrote: >> - On Aug 18, 2021, at 2:46 AM, Steve Lalonde st...@enta.net wrote: >> >> Hi, >> >>> > We always

Re: Setting sensible max-prefix limits

On Wed, 18 Aug 2021, John Kristoff wrote: On Wed, 18 Aug 2021 11:33:09 +0200 Lars Prehn wrote: As I understand by now, it is highly recommended to set a max-prefix limit for peering sessions. Yet, I can hardly find any recommendations on how to arrive at a sensible limit. Maybe because

PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]

On Aug 18, 2021, at 5:00 PM, Matthew Walster wrote: > On Wed, 18 Aug 2021, 21:37 Sabri Berisha, wrote: > - On Aug 18, 2021, at 2:46 AM, Steve Lalonde st...@enta.net wrote: > > Hi, > >> > We always use PeeringDB data and refuse to peer with networks not in >> > PeeingDB >> >> You are

Re: Setting sensible max-prefix limits

On Wed, 18 Aug 2021, 21:37 Sabri Berisha, wrote: > - On Aug 18, 2021, at 2:46 AM, Steve Lalonde st...@enta.net wrote: > > Hi, > > > We always use PeeringDB data and refuse to peer with networks not in > PeeingDB > > You are aware that PeerinDB refuses to register certain networks, right? >

Re: Setting sensible max-prefix limits

- On Aug 18, 2021, at 2:46 AM, Steve Lalonde st...@enta.net wrote: Hi, > We always use PeeringDB data and refuse to peer with networks not in PeeingDB You are aware that PeerinDB refuses to register certain networks, right? It is most certainly not a single source of truth. Thanks,

Re: Outbound Route Filtering (ORF) vendor support

You may want to examine the IDR lsit archive https://mailarchive.ietf.org/arch/browse/idr/?q=orf for discussion of the orf proposal and the difficulties people have with it. Yours, Joel On 8/18/2021 1:10 PM, Douglas Fischer wrote: Hello! I also found a recent draft(expires Novembre 2021)

RE: Amazon Prime Video IP reputation

We found that ipqualityscore.com seems to match up with the CGNATs that we are having the most trouble with. They indicated a 1-3 day turnaround in responding to mis-classifications. We might have to make a habit of calling them every 30 minutes until they do something. From: NANOG On Behalf

RE: Amazon Prime Video IP reputation

I'm having the same with one of my valid IPv4 /21 right now. Amazon Prime, HBO Max, and Hulu confirmed. Just started within the last couple days. Joshua Stump Network Admin Fourway.NET 800-733-0062 From: NANOG On Behalf Of Eric C. Miller Sent: Tuesday, August

Re: Outbound Route Filtering (ORF) vendor support

Hello! I also found a recent draft(expires Novembre 2021) about using Route Distinguisher as a Value on ORF. https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/ Em qua., 18 de ago. de 2021 às 11:41, Humberto Galiza < humbertogal...@gmail.com> escreveu: > Hi, > > Is anyone aware of any

Re: Setting sensible max-prefix limits

> > Depending on what failure cases you actually see from your peers in the > wild, I can see (at least as a thought experiment), a two-bucket solution - > "transit" and "everyone else". (Excluding downstream customers, who you > obviously hold some responsibility for the hygiene of.) > Although

Re: Setting sensible max-prefix limits

Thus spake Chriztoffer Hansen (c...@ntrv.dk) on Wed, Aug 18, 2021 at 12:03:51PM +0200: > On Wed, 18 Aug 2021 at 11:33, Lars Prehn wrote: > > I guess for long standing peers one could just eyeball it, e.g., current > > prefix count + some safety margin. How does that work for new peers? sadly,

Re: Setting sensible max-prefix limits

On Wednesday, 18 August, 2021 14:21, "Tom Beecher" said: > We created 5 or 6 different buckets of limit values (for v4 and v6 of > course.) Depending on what you have published in PeeringDB (or told us > directly what to expect), you're placed in a bucket that gives you a decent > amount of

Outbound Route Filtering (ORF) vendor support

Hi, Is anyone aware of any vendor that supports Outbound Route Filtering (ORF) based on anything other than prefix-lists? I found these two old IETF drafts (both expired :-/) which supported the idea of filtering based on community and as-path respectively, but I wasn't able to understand if

Re: Setting sensible max-prefix limits

> On Aug 18, 2021, at 9:38 AM, John Kristoff wrote: > > Maybe because there isn't a simple, universal approach to setting it. > Probably like a lot of people, historically I'd set it to > some % over the current stable count and then manually adjust when the > limits were about to be

Re: Setting sensible max-prefix limits

On 8/18/2021 5:33 AM, Lars Prehn wrote: As I understand by now, it is highly recommended to set a max-prefix limit for peering sessions. Yet, I can hardly find any recommendations on how to arrive at a sensible limit. I guess for long standing peers one could just eyeball it, e.g., current

Re: Setting sensible max-prefix limits

On Wed, 18 Aug 2021 11:33:09 +0200 Lars Prehn wrote: > As I understand by now, it is highly recommended to set a max-prefix > limit for peering sessions. Yet, I can hardly find any recommendations > on how to arrive at a sensible limit. Maybe because there isn't a simple, universal approach

Re: Setting sensible max-prefix limits

While there are good solutions in this thread, some of them have scaling issues with operator overhead. We recently implemented a strategy that I proposed a couple years ago that uses a bucket system. We created 5 or 6 different buckets of limit values (for v4 and v6 of course.) Depending on

AS20940 Max Prefix and as-path filtering

Hello, Akamai has been increasing the routes we are advertising in various locations as part of ongoing network changes. If you have a max-prefix set for Akamai can you please increase v4 to 1k and ensure you are accepting our additional ASNs that may live behind the clusters. We are going

Re: Setting sensible max-prefix limits

On 18/08/2021 13:03, Chriztoffer Hansen wrote: On Wed, 18 Aug 2021 at 11:33, Lars Prehn wrote: I guess for long standing peers one could just eyeball it, e.g., current prefix count + some safety margin. How does that work for new peers? If you have automation in place. Another approach is to

Re: Setting sensible max-prefix limits

Okay, so some automated PeeringDB-based approach seems to be the preferred road. ~30% and ~40% of IPv4 and IPv6 PeeringDB prefix count recommendations are 0. How do you treat those cases? Does it also boils down to a simple "we don't peer with them" ? Best regards, Lars On 18.08.21 12:31,

Re: Setting sensible max-prefix limits

On 18.08.21 12:36, Saku Ytti wrote: On Wed, 18 Aug 2021 at 12:36, Lars Prehn wrote: As I understand by now, it is highly recommended to set a max-prefix limit for peering sessions. Yet, I can hardly find any recommendations on how to arrive at a sensible limit. You are missing two important

Re: Setting sensible max-prefix limits

On Wed, 18 Aug 2021 at 12:36, Lars Prehn wrote: > As I understand by now, it is highly recommended to set a max-prefix > limit for peering sessions. Yet, I can hardly find any recommendations > on how to arrive at a sensible limit. You are missing two important questions a) should I apply it to

Re: Setting sensible max-prefix limits

Le Wed, Aug 18, 2021 at 10:46:34AM +0100, Steve Lalonde a écrit : > > We always use PeeringDB data and refuse to peer with networks not in PeeingDB > That !

Re: Setting sensible max-prefix limits

On Wed, 18 Aug 2021 at 12:03, Chriztoffer Hansen wrote: > 'some' networks will input a value with headroom percentages already > included. That's what it's for. There is no point in periodically copying the actual prefix-count into peeringdb records, that would just be redundant data which

Re: Setting sensible max-prefix limits

On Wed, 18 Aug 2021 at 11:33, Lars Prehn wrote: > I guess for long standing peers one could just eyeball it, e.g., current > prefix count + some safety margin. How does that work for new peers? If you have automation in place. Another approach is to count the received prefix. Store the counted

Re: Setting sensible max-prefix limits

On Wed, 18 Aug 2021 at 11:33, Lars Prehn wrote: > > As I understand by now, it is highly recommended to set a max-prefix > limit for peering sessions. Yet, I can hardly find any recommendations > on how to arrive at a sensible limit. > > I guess for long standing peers one could just eyeball it,

Re: Setting sensible max-prefix limits

On 18 Aug 2021, at 10:33, Lars Prehn mailto:lpr...@mpi-inf.mpg.de>> wrote: > > As I understand by now, it is highly recommended to set a max-prefix limit > for peering sessions. Yet, I can hardly find any recommendations on how to > arrive at a sensible limit. > > I guess for long standing

Setting sensible max-prefix limits

As I understand by now, it is highly recommended to set a max-prefix limit for peering sessions. Yet, I can hardly find any recommendations on how to arrive at a sensible limit. I guess for long standing peers one could just eyeball it, e.g., current prefix count + some safety margin. How