Re: Outbound Route Filtering (ORF) vendor support

[Douglas Fischer]

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 purpose, the pros and cons
does not pay themselves.


But (there is always a but), I was imagining a different use
for ext-community-orf !

Considering scenarios like:
 -  Route-Servers of big IXPs, now days with almost 200K routes.
 - Transit providers sending its own point of view of DFZ with almos 900K
routes.
On both cases, informative communities are an excelente way to decide "what
is good for my ASN, and what is not".

Yes, I know that is possible to filter based on that after receiving those
routes.
But it takes computational effort on both sides to do that.
And I imagine that comparing to AS-Path Regex, the needed computational
effort and the complexity of the logics to do filtering based on
community-list are much smaller.


So, if I could say:
 "Hey Mr. Route-Server... how are you?
 Could you please not send-me the routes that are tagged with the
community ?
 And after that, send-me just the routes that are tagged with the
community ?"
In a Route-Server context, beyond reduce the number of BGP Messages that
would be great for the CPU/Memory consumption both, RS and RS-Client.

Or, in a Transit context...
1 - Customer opens a ticket with support team to set the export filter to
send only default-route.
2 - Customer, 5 days later, opens a ticket with support team re-adjust the
export filter, now sending full-routing.
3 - Customer, on next month, opens another ticket with support team to send
only the cone at right of the ASN of ITP.
With a good and public informative communities policy and
ext-community-orf, the transit customer could change what his router will
receive from the BGP transit Peer, depending only on himself.


Well... I don't really know how complex is to deal with that again on a WG.
But I would like to see that.



Em qua., 18 de ago. de 2021 às 20:11, Jeffrey Haas 
escreveu:

> ORFs are a challenging feature and haven't gotten a lot of deployment for
> a number of reasons.
>
> At a high level, they're a very coarse filter.  Since each new ORF type
> adds to the logical AND condition, you start having to be more and more
> permissive in what you permit in the policy.  Since a significant amount of
> common ISP policies require matching things in tuples, this doesn't
> translate super well into many types of automatically generated ORFs.
>
> The ext-community-orf feature was effectively supplanted by Rt-Constrain
> (RFC 4684).
>
> The as-path ORF was challenging because different vendors have different
> ideas about what "regex" means and what the input tokens are.  Consider for
> example Juniper vs. Cisco regex matching.  The abstract fix would have been
> to define a regex that is for the feature.  I half suspect if people pushed
> on this these days, they'd want PCRE. :-)
>
> The RD-ORF work is part of some ongoing discussion about how to deal with
> VRF overwhelm (prefix-limit exceed).
>
> -- Jeff (IDR co-chair)
>
> On Aug 18, 2021, at 1:10 PM, Douglas Fischer 
> wrote:
>
> 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 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 they were ever discussed at the WG and
>> if there was any outcome of the discussion (I suspect the authors are
>> no longer even working with the mentioned companies in the drafts):
>>
>> -
>> https://datatracker.ietf.org/doc/html/draft-chen-bgp-ext-community-orf-02
>> - https://datatracker.ietf.org/doc/html/draft-ietf-idr-aspath-orf-13
>>
>> Any info is very much appreciated.
>>
>> Thanks,
>>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>
>
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação

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

[Matthew Walster]

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
> source of truth for my bank balance?  how about i can learn your bank
> balance?
>
> < / >
>
> peeringdb has a mission, public exchange point documentation.  please
> don't get creepy.
>

Randy, your hyperbole helps no-one. Having been on Sabri's side of your
targeting before, I can attest it does little else than create veiled
anger. We are all friends here.

PeeringDB's mission, as stated on the front page, is:

PeeringDB is a freely available, user-maintained, database of networks, and
> the go-to location for interconnection data. The database facilitates the
> global interconnection of networks at Internet Exchange Points (IXPs), data
> centers, and other interconnection facilities, and is the first stop in
> making interconnection decisions.


The barrier to entry ought to be as low as possible, PeeringDB should
facilitate peering, not hinder it. Right now, I believe it is a force for
good. Where Sabri believes (based on a 6 year old email) a denial of
presence on the platform, it has degraded the utility of PeeringDB by not
allowing a network to advertise where it can be peered with -- something
that extensively happens between networks in LATAM outside of public IXPs
for example, which is why that statement above indicates it also
facilitates the interconnection of networks outside of IXPs. Whether that
is desirable or not is a topic for another day.

Matthew Walster

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

[Randy Bush]

> 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 your bank
balance?

< / >

peeringdb has a mission, public exchange point documentation.  please
don't get creepy.

randy

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

[Randy Bush]

> 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 database, but is the substrate on
which the next two mechanisms are based.  It is currently deployed
in all five administrative regions.

RPKI-based Origin Validation (ROV)

RPKI-based Origin Validation [RFC 6811] uses some of the RPKI data
to allow a router to verify that the autonomous system originating
an IP address prefix is in fact authorized to do so.  This is not
crypto checked so can be violated.  But it should prevent the vast
majority of accidental 'hijackings' on the internet today, e.g. the
famous Pakistani accidental announcement of YouTube's address space.
RPKI-based origin validation is in shipping code from AlcaLu, Cisco,
Juniper, and possibly others.

BGPsec

RPKI-based Path Validation, AKA BGPsec, a future technology still
being designed [draft-ietf-sidr-bgpsec-overview], uses the full
crypto information of the RPKI to make up for the embarrassing
mistake that, like much of the internet BGP was designed with no
thought to securing the BGP protocol itself from being
gamed/violated.  It allows a receiver of a BGP announcement to
cryptographically validate that the autonomous systems through which
the announcement passed were indeed those which the sender/forwarder
at each hop intended.

Sorry to drone on, but these three really need to be differentiated.

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

[Niels Bakker]

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 data you need.


But again, their database, their rules.


So you were planning to abuse, er, creatively implement their 
datamodel to declare yourself an IXP and list all your peers as 
members of said IXP, and then convince the world to build filter 
lists based on said participant list?


Creative, but indeed not what PeeringDB is about.


-- Niels.

Re: "Tactical" /24 announcements

[David Bass]

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 share your confusion Randy. It seems like perhaps Jakob answered a
> > slightly different question and his answer is roughly.
> >
> > a) Use this as-set feature to ensure valid set of ASNs from given peer
> > b) Validate prefix using RPKI (I'm assuming with rejecting unknowns
> > and invalids)
> > c) Don't punch in prefix-lists anywhere
> >
> > Which in theory works, but in practice it does not, as RPKI validity
> > cover is incomplete.
> >
> This, and (more fundamentally) RPKI-breakage gets translated into a
> dataplane
> outage.
>
> > Somewhat related, when JNPR implemented RTR the architecture was
> > planned so that the RTR implementation itself isn't tightly coupled to
> > RPKI validity. It was planned day1 that customers could have multiple
> > RTR setups feeding prefixes and the NOS side could use these for other
> > purposes too. So technically JNPR is mostly missing CLI work to allow
> > you to feed prefix-lists dynamically over RTR, instead of punching
> > them in vendor-specific way in config.
> >
> We already do essentially this on arista EOS using a custom agent.
>
> It runs under the EOS process supervisor and calls home to a REST-API
> wrapper around bgpq3. It looks for specific config lines to work out
> which prefix lists to build, and then fetches them on a configurable
> interval.
>
> This has been in production for a year or two, without major incident.
> It's all open source, available at
> https://github.com/wolcomm/eos-prefix-list-agent.
> Pull-requests
>  welcomed
> ;-)
>
> I'm in the middle of writing the equivalent tool for junos at the
> moment. Assuming that it works, we'll open source that too.
>
> HTH,
>
> Ben
>

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

[Sabri Berisha]

- 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 that B can use and/or forward A's announcements.

Yes, that would be a relatively easy thing to calculate. 

Niels has, of course, a fair point when he writes:

> When did PeeringDB turn into a routing (policy) registry?
> You should use an IRRdb if you want to write RPSL.

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.

But again, their database, their rules.

Thanks,

Sabri

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

[Rubens Kuhl]

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 PM Sabri Berisha  wrote:
>
> - 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 BGP peers. Your definition of BGP peering is different from mine, 
> at
> least in this context.
>
> > I guess you are right, the _Peering_DB does not register “certain” networks.
>
> Which was my point. I'm glad you agree. My little AS is not allowed to play 
> with
> the big kids.
>
> If you only want to register settlement-free peering, that's totally fine 
> with me.
> Your database, your rules.
>
> But, the fact stays that you can have an AS, advertise your prefixes to the 
> world,
> and not be permitted to register with peeringdb. Which means it can't be used 
> as
> a single source of truth. Which would have been a shame because with a little 
> bit
> of automation it would be feasible to "score" advertisements. That would help
> determine the likelihood of an advertisement to be erroneous (whether by 
> accident
> or malice).
>
> 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.
>
> But again, your database, your rules.
>
> Thanks,
>
> Sabri

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

[Niels Bakker]

* 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 (policy) registry?
You should use an IRRdb if you want to write RPSL.


-- Niels.

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

[Sabri Berisha]

- 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 BGP peers. Your definition of BGP peering is different from mine, at
least in this context.

> I guess you are right, the _Peering_DB does not register “certain” networks.

Which was my point. I'm glad you agree. My little AS is not allowed to play with
the big kids.

If you only want to register settlement-free peering, that's totally fine with 
me.
Your database, your rules.

But, the fact stays that you can have an AS, advertise your prefixes to the 
world,
and not be permitted to register with peeringdb. Which means it can't be used as
a single source of truth. Which would have been a shame because with a little 
bit
of automation it would be feasible to "score" advertisements. That would help 
determine the likelihood of an advertisement to be erroneous (whether by 
accident
or malice).

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. 

But again, your database, your rules.

Thanks,

Sabri

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

[Patrick W. Gilmore]

> 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 because nobody wants to peer 
> with them because they are not registered in peeringdb because nobody wants to
> peer with them? You get the idea.

First, most networks do not require a PDB record to peer. (Silly of them, I 
know, but still true.)

Second, you do not need to have a PDB record to get a link to an IXP. Even 
membership in a free IXP is sufficient for an account in PDB, as Grizz points 
out below.

Third, if you have an agreement, even just an email, saying a network will peer 
with you once you have a record, that may well suffice. Have you asked any 
network to peer? Private peering (because you are not on an IXP) is usually 
reserved for networks with more than a modicum of traffic. If your network is 
large enough to qualify for private peering, I have trouble believing you 
cannot get another network to agree to peer so you can get a record.

I guess you are right, the _Peering_DB does not register “certain” networks. 
Those networks would be ones that do not peer. Which seems pretty obvious to me 
- it is literally in the name.

-- 
TTFN,
patrick

> On Aug 18, 2021, at 5:50 PM, Sabri Berisha  wrote:
> 
> - 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 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.
 
>>> Would you care to expand on this?
>> 
>> I am extremely interested in hearing about this as well.
>> 
>> Specific examples would be useful.
> 
> 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 because nobody wants to peer 
> with them because they are not registered in peeringdb because nobody wants to
> peer with them? You get the idea.
> 
> Thanks,
> 
> Sabri
> AS31064
> 
> 
> Return-Path: gr...@peeringdb.com 
> Received: from mail.cluecentral.net  (LHLO 
> mail.cluecentral.net )
> (195.16.84.32) by mail.cluecentral.net  with 
> LMTP; Fri, 9 Oct 2015 01:47:22
> -0700 (PDT)
> Received: from localhost (localhost [127.0.0.1])
>   by mail.cluecentral.net  (Postfix) with 
> ESMTP id 4CED64001EF
>   for mailto:sa...@cluecentral.net>>; Fri,  9 Oct 
> 2015 01:47:22 -0700 (PDT)
> Received: from mail.cluecentral.net  
> ([127.0.0.1])
>   by localhost (mail.cluecentral.net  
> [127.0.0.1]) (amavisd-new, port 10024)
>   with ESMTP id 3TLvVaNdjHGA for  >;
>   Fri,  9 Oct 2015 01:47:21 -0700 (PDT)
> Received: from ubersmith.peeringdb.com  
> (ubersmith.peeringdb.com  [107.6.74.106])
>   by mail.cluecentral.net  (Postfix) with 
> ESMTP id C5B164001A9
>   for mailto:sa...@cluecentral.net>>; Fri,  9 Oct 
> 2015 01:47:01 -0700 (PDT)
> Received: by ubersmith.peeringdb.com  
> (Postfix, from userid 48)
>   id D8AF377C1A; Fri,  9 Oct 2015 04:46:29 -0400 (EDT)
> Date: Fri, 9 Oct 2015 04:46:29 -0400
> To: Sabri Berisha mailto:sa...@cluecentral.net>>
> From: supp...@peeringdb.com 
> Reply-To: supp...@peeringdb.com 
> Subject: Re: [#9192] [PeeringDB] User (sabri) Requesting Access (New Company 
> - Cluecentral Inc)
> Message-ID: <1bac170d74e5d3702d3a28b237c87...@ubersmith.peeringdb.com 
> >
> 
> Dear PeeringDB user,
> 
> Registering with peeringDB and peering negotiations are sort of egg and
> chicken problem. We only want to have networks registered that already
> do have settlement free peering.
> 
> After some basic checks it looks like you are only buying transit from 
> 6939/Hurricane Electric, but are not connected to any Internet Exchange (e.g. 
> AMS-IX/NL-ix) yet.
> 
> Having said this, is it acceptable to you to wait until you have your
> 1st settlement free peering setup? If you already have 

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

[Sabri Berisha]

- 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 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.
>>> 
>> Would you care to expand on this?
> 
> I am extremely interested in hearing about this as well.
> 
> Specific examples would be useful.

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 because nobody wants to peer 
with them because they are not registered in peeringdb because nobody wants to
peer with them? You get the idea.

Thanks,

Sabri
AS31064


Return-Path: gr...@peeringdb.com
Received: from mail.cluecentral.net (LHLO mail.cluecentral.net)
 (195.16.84.32) by mail.cluecentral.net with LMTP; Fri, 9 Oct 2015 01:47:22
 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by mail.cluecentral.net (Postfix) with ESMTP id 4CED64001EF
for ; Fri,  9 Oct 2015 01:47:22 -0700 (PDT)
Received: from mail.cluecentral.net ([127.0.0.1])
by localhost (mail.cluecentral.net [127.0.0.1]) (amavisd-new, port 
10024)
with ESMTP id 3TLvVaNdjHGA for ;
Fri,  9 Oct 2015 01:47:21 -0700 (PDT)
Received: from ubersmith.peeringdb.com (ubersmith.peeringdb.com [107.6.74.106])
by mail.cluecentral.net (Postfix) with ESMTP id C5B164001A9
for ; Fri,  9 Oct 2015 01:47:01 -0700 (PDT)
Received: by ubersmith.peeringdb.com (Postfix, from userid 48)
id D8AF377C1A; Fri,  9 Oct 2015 04:46:29 -0400 (EDT)
Date: Fri, 9 Oct 2015 04:46:29 -0400
To: Sabri Berisha 
From: supp...@peeringdb.com
Reply-To: supp...@peeringdb.com
Subject: Re: [#9192] [PeeringDB] User (sabri) Requesting Access (New Company - 
Cluecentral Inc)
Message-ID: <1bac170d74e5d3702d3a28b237c87...@ubersmith.peeringdb.com>

Dear PeeringDB user,

Registering with peeringDB and peering negotiations are sort of egg and
chicken problem. We only want to have networks registered that already
do have settlement free peering.

After some basic checks it looks like you are only buying transit from 
6939/Hurricane Electric, but are not connected to any Internet Exchange (e.g. 
AMS-IX/NL-ix) yet.

Having said this, is it acceptable to you to wait until you have your
1st settlement free peering setup? If you already have existing peering
sessions, please provide the following details to support your request for
peeringdb access:

Your AS number(s)
Which IXP / facilities you are peering at
Some of your peering partners (again AS numbers / name)

Please send your answers to supp...@peeringdb.com or reply to this ticket.


Best regards,
PeeringDB admin on Duty


PeeringDB Listserv information:

PeeringDB Announce: 
http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-announce

PeeringDB Governance:
http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-gov

PeeringDB Technical:
http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech

PeeringDB User Discuss:
http://lists.peeringdb.com/cgi-bin/mailman/listinfo/user-discuss

-- 
Florian Hibler 
PeeringDB Administrator

Re: Setting sensible max-prefix limits

[Jon Lewis]

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 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 breached, or often was the case when they were
and I wasn't ready for it. Not ideal.


We tackled this problem at $work recently after I wrote some code to audit 
configured prefix-limits and found how inconsistent we were.  My guess 
was, this was due to combination of each engineer "doing their own thing" 
with regard to how to set prefix-limits based on what was published in 
peeringdb and growth (peers increasing the suggested limits over time, 
after we'd configured [some of] their sessions).


The solution I implemented was:

In the script that builds peering config, fetch the peer's suggested 
limits from peeringdb via API (I still miss the open mysql access).


Multiply those values by 2.

If that's too close to the "full table size", try suggested limits * 1.5.

If that's still too close to the "full table size", just use the suggested 
limits.



I've never felt the automation of this setting however was worth the
effort.  Of course I am not usually responsible for hundreds of routers
and thousands of peering sessions.


Yeah...that changes things when you have thousands of peering sessions to 
maintain.



At the risk of advocating for more junk in BGP or the RPKI, a max prefix
setting might be something that could be set by the announcing peer in
a BGP message, or possibly as an RPKI object with an associated ASN.


It actually sounds like a cool feature, and could be implemented entirely 
on the sender's side.  i.e. You configure a peer with a self-imposed limit 
of 1000 routes.  If you screw up your routing policy facing that peer and 
leak the full table, once you hit 1001 advertised routes, your router's 
BGP process terminates the session.


Who hasn't had a new peer leak full routes to them at least once?

Who hasn't configured a new peer, only to have them immediately trip your 
prefix-limit because they haven't updated peeringdb for "some time" and 
advertise more routes than their suggested limits?


--
 Jon Lewis, MCP :)   |  I route
 StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

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

[Patrick W. Gilmore]

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 aware that PeerinDB refuses to register certain networks, right? It 
>> is most certainly not a single source of truth.
>> 
> Would you care to expand on this?

I am extremely interested in hearing about this as well.

Specific examples would be useful.

-- 
TTFN,
patrick

Re: Setting sensible max-prefix limits

[Matthew Walster]

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?
> It is most certainly not a single source of truth.
>

Would you care to expand on this?

Matthew Walster

>

Re: Setting sensible max-prefix limits

[Sabri Berisha]

- 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,

Sabri

Re: Outbound Route Filtering (ORF) vendor support

[Joel Halpern]

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) 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 
mailto:humbertogal...@gmail.com>> escreveu:


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 they were ever discussed at the WG and
if there was any outcome of the discussion (I suspect the authors are
no longer even working with the mentioned companies in the drafts):

-
https://datatracker.ietf.org/doc/html/draft-chen-bgp-ext-community-orf-02

- https://datatracker.ietf.org/doc/html/draft-ietf-idr-aspath-orf-13


Any info is very much appreciated.

Thanks,



--
Douglas Fernando Fischer
Engº de Controle e Automação

RE: Amazon Prime Video IP reputation

[Eric C. Miller]

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 Of Joshua 
Stump
Sent: Wednesday, August 18, 2021 1:40 PM
To: nanog@nanog.org
Subject: 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 
mailto:nanog-bounces+jstump=fourway@nanog.org>>
 On Behalf Of Eric C. Miller
Sent: Tuesday, August 17, 2021 7:31 PM
To: NANOG mailto:nanog@nanog.org>>
Subject: Amazon Prime Video IP reputation

Does anybody know which IP reputation service Amazon uses for Prime video? 
Within the last couple of hours several of our CGNAT publics are showing up as 
VPN or proxy when someone tries to watch Amazon video.

Any help would be appreciated!

Thank you!
Eric

RE: Amazon Prime Video IP reputation

[Joshua Stump]

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 17, 2021 7:31 PM
To: NANOG 
Subject: Amazon Prime Video IP reputation

 

Does anybody know which IP reputation service Amazon uses for Prime video?
Within the last couple of hours several of our CGNAT publics are showing up
as VPN or proxy when someone tries to watch Amazon video.

 

Any help would be appreciated!

 

Thank you!

Eric

Re: Outbound Route Filtering (ORF) vendor support

[Douglas Fischer]

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 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 they were ever discussed at the WG and
> if there was any outcome of the discussion (I suspect the authors are
> no longer even working with the mentioned companies in the drafts):
>
> -
> https://datatracker.ietf.org/doc/html/draft-chen-bgp-ext-community-orf-02
> - https://datatracker.ietf.org/doc/html/draft-ietf-idr-aspath-orf-13
>
> Any info is very much appreciated.
>
> Thanks,
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação

Re: Setting sensible max-prefix limits

[Tom Beecher]

>
> 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 I didn't say it clearly, that's exactly what we do. The described
'bucket' logic is only applied to the 'everyone else' pile ; our transit
stuff gets its own special care and feeding.

How often do folks see a failure case that's "deaggregated something and
> announced you 1000 /24s, rather than the expected/configured 100 max", vs
> "fat-fingered being a transit provider, and announced you the global table"?
>

I can count on one hand the number of times I can remember that a peer has
gone on a deagg party and ran over limits. Maybe twice in the last 8 years?
It's possible it's happened more that I'm not aware of.

We have additional protections in place for that second scenario. If a
generic peer tries to send us a route with a transit provider in the
as-path, we just toss the route on the floor. That protection has been much
more useful than prefix limits IMO.

On Wed, Aug 18, 2021 at 11:37 AM t...@pelican.org  wrote:

> 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 headroom to that bucket's max. If your ASN reaches 90% of your
> > limit, our ops folks just move you up to the next bucket. If you start to
> > get up there in the last bucket, then we'll take a manual look and decide
> > what is appropriate. This covers well over 95% of our non-transit
> sessions,
> > and has dramatically reduced the volume of tickets and changes our ops
> team
> > has had to sort through.
>
> 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.)
>
> How often do folks see a failure case that's "deaggregated something and
> announced you 1000 /24s, rather than the expected/configured 100 max", vs
> "fat-fingered being a transit provider, and announced you the global table"?
>
> My gut says it's the latter case that breaks things and you need to make
> damn sure doesn't happen.  Curious to hear others' experience.
>
> Thanks,
> Tim.
>
>
>

Re: Setting sensible max-prefix limits

[Dale W. Carder]

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, this is the state of the art.
 
> If you have automation in place. Another approach is to count the
> received prefix. Store the counted value in a database. Based on the
> avg prefix count over X (time period). Add e.g. 10 - 25 % headroom
> over the avg prefix count and use the calculated value as the
> max-prefix limit?
> 
> PeeringDB data (sometimes or often?) be somewhat misleading (in
> contrast to actual avg prefix count) in the sense 'some' networks will
> input a value with headroom percentages already included.
> 

Our code tries all 3:

a) using the max values in peeringdb
b) expand all the routes in the IRR record from peeringdb
b.1) if no object is specified, try to guess if it's named ASn
c) count the currently received prefixes

Many times the values in peeringdb can be off, or increasingly this is a good 
warning not to peer with a negligent operator.  For some peers 'b' can expand 
to a huge, unrealistic set (not always their fault), so if it's substantially 
larger than 'a' we throw it out.  (c) has proven the most reliable.

The count chosen then fits in the appropriate sized bin and given 30% headroom.
The code compares all this and gives the user a warning that in proactive gets 
ignored for option 'c'.  (For example we can override 'b' with a more 
appropriate 
object record in our provisioning db)

Dale

Re: Setting sensible max-prefix limits

[t...@pelican.org]

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 headroom to that bucket's max. If your ASN reaches 90% of your
> limit, our ops folks just move you up to the next bucket. If you start to
> get up there in the last bucket, then we'll take a manual look and decide
> what is appropriate. This covers well over 95% of our non-transit sessions,
> and has dramatically reduced the volume of tickets and changes our ops team
> has had to sort through.

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.)

How often do folks see a failure case that's "deaggregated something and 
announced you 1000 /24s, rather than the expected/configured 100 max", vs 
"fat-fingered being a transit provider, and announced you the global table"?

My gut says it's the latter case that breaks things and you need to make damn 
sure doesn't happen.  Curious to hear others' experience.

Thanks,
Tim.

Outbound Route Filtering (ORF) vendor support

[Humberto Galiza]

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 they were ever discussed at the WG and
if there was any outcome of the discussion (I suspect the authors are
no longer even working with the mentioned companies in the drafts):

- https://datatracker.ietf.org/doc/html/draft-chen-bgp-ext-community-orf-02
- https://datatracker.ietf.org/doc/html/draft-ietf-idr-aspath-orf-13

Any info is very much appreciated.

Thanks,

Re: Setting sensible max-prefix limits

[Jared Mauch]

> 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 breached, or often was the case when they were
> and I wasn't ready for it. Not ideal.
> 
> I've never felt the automation of this setting however was worth the
> effort.  Of course I am not usually responsible for hundreds of routers
> and thousands of peering sessions.

We did a variant of this at NTT, with certain baseline settings.  Sometimes 
networks would advertise more routes because they onboarded a large customer 
and it would cause manual updates to be necessary.

Polling daily and snapshotting these values is important to understand what is 
changing.  The reason I just posted a message about Akamai max-prefix is we 
have been giving some general guidance that is out of line/norm compared to 
what perhaps what we want.  This won’t cause a service outage per-se but will 
cause suboptimal routing as we continue to make improvements and upgrades to 
our network.

- Jared

Re: Setting sensible max-prefix limits

[Andrew Gallo]

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 
prefix count + some safety margin. How does that work for new peers? Do 
you negotiate/exchange sensible values whenever you establish a new 
session? Do you rely on PeeringDB (if available)? Do you apply default 
values to everyone except the big fishes?


Apart from your peers, do you also apply a limit to your transit sessions?

Best regards,

Lars





Our semi-automated process...
Check the peering routers for any peers that have a prefix limit set (we 
don't set limits on transit or iBGP, so we skip those groups)


Record what the current limit is.

Check peeringDB for what the network says the limit should be.

If configured max prefix < peeringDB, inform a config change is needed;
if configured max prefix > peeringDB, the network isn't keeping its 
record up to date.  no need for change


I've thought about adding additional headroom to what is advertised in 
peeringDB, but we haven't had the limits triggered in so long, it may 
not be worth it.




OpenPGP_0x1C61021F8B5942A2.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Setting sensible max-prefix limits

[John Kristoff]

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 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 breached, or often was the case when they were
and I wasn't ready for it. Not ideal.

I've never felt the automation of this setting however was worth the
effort.  Of course I am not usually responsible for hundreds of routers
and thousands of peering sessions.

At the risk of advocating for more junk in BGP or the RPKI, a max prefix
setting might be something that could be set by the announcing peer in
a BGP message, or possibly as an RPKI object with an associated ASN.
I'll let the masses debate how that would work and all the reasons that
isn't ideal, but I'm not sure there is a one-size-fit all solution for
this in the near term.

John

Re: Setting sensible max-prefix limits

[Tom Beecher]

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 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 headroom to that bucket's max. If your ASN reaches 90% of your
limit, our ops folks just move you up to the next bucket. If you start to
get up there in the last bucket, then we'll take a manual look and decide
what is appropriate. This covers well over 95% of our non-transit sessions,
and has dramatically reduced the volume of tickets and changes our ops team
has had to sort through.

Of course, we can also afford to be a little looser in limits based on the
capability of the equipment that these sessions land on, other environments
may require tighter restrictions.


On Wed, Aug 18, 2021 at 5:34 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
> prefix count + some safety margin. How does that work for new peers? Do
> you negotiate/exchange sensible values whenever you establish a new
> session? Do you rely on PeeringDB (if available)? Do you apply default
> values to everyone except the big fishes?
>
> Apart from your peers, do you also apply a limit to your transit sessions?
>
> Best regards,
>
> Lars
>
>
>

AS20940 Max Prefix and as-path filtering

[Jared Mauch]

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 to be updating PeeringDB to reflect this change as well.

An appropriate as-path access-list would look like:

20940_(21342|16625|33905|36183|24319|34164|35204|35994|43639|18680|39836|35993|23454|18717|31108|36183)

Feel free to reach out if you have any questions.

- Jared

Re: Setting sensible max-prefix limits

[Hank Nussbacher]

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 count the
received prefix. Store the counted value in a database. Based on the
avg prefix count over X (time period). Add e.g. 10 - 25 % headroom
over the avg prefix count and use the calculated value as the
max-prefix limit?


That works but all too often people forget to update it.  Set a 
quarterly reminder in your calendar to check max-prefix setting.


-Hank

Re: Setting sensible max-prefix limits

[Lars Prehn]

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, Denis Fondras wrote:

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

[Lars Prehn]

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 questions
a) should I apply it to before or after policy
b) what should I do when it triggers, should I reset or stop accepting new


When I read through [1] earlier today, I had the feeling that these 
question rather strictly translate to:


a) Do I keep rejected routes around?

b) Can I traffic-wise afford dropping the session to send a strong 
signal to my peer?


Hence, I didn't dig deeper.

Best regards,

Lars

[1] 
https://tools.ietf.org/id/draft-sa-grow-maxprefix-00.html#rfc.section.3.1

Re: Setting sensible max-prefix limits

[Saku Ytti]

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 before or after policy
b) what should I do when it triggers, should I reset or stop accepting new

--
  ++ytti

Re: Setting sensible max-prefix limits

[Denis Fondras]

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

[Lukas Tribus]

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 would be
wrong more often than not.

PeerginDB tool tips:
Recommended maximum number of IPv4 routes/prefixes to be configured on
peering sessions for this ASN
Recommended maximum number of IPv6 routes/prefixes to be configured on
peering sessions for this ASN



Lukas

Re: Setting sensible max-prefix limits

[Chriztoffer Hansen]

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 value in a database. Based on the
avg prefix count over X (time period). Add e.g. 10 - 25 % headroom
over the avg prefix count and use the calculated value as the
max-prefix limit?

PeeringDB data (sometimes or often?) be somewhat misleading (in
contrast to actual avg prefix count) in the sense 'some' networks will
input a value with headroom percentages already included.

Re: Setting sensible max-prefix limits

[Lukas Tribus]

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, e.g., current
> prefix count + some safety margin. How does that work for new peers? Do
> you negotiate/exchange sensible values whenever you establish a new
> session? Do you rely on PeeringDB (if available)? Do you apply default
> values to everyone except the big fishes?

- review max prefix suggestions from the peer itself, either from the
email or peeringdb
- check actual current prefix count (bgp.he.net et all)
- check whether the disparity between the two matches your expectation
of a safety margin, based on your own operational experience and
context
- defaults for low prefix count peers
- actually monitor warning/critical levels of max-prefix counts

Don't use too small a safety margin, you don't want to spend your days
adjusting max-prefix levels all the time.

I don't have strict rules for the safety margin itself; it depends
very much on the network (size, growing rate, trust, history).


lukas

Re: Setting sensible max-prefix limits

[Steve Lalonde]

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 peers one could just eyeball it, e.g., current 
> prefix count + some safety margin. How does that work for new peers? Do you 
> negotiate/exchange sensible values whenever you establish a new session? Do 
> you rely on PeeringDB (if available)? Do you apply default values to everyone 
> except the big fishes?
> 
> Apart from your peers, do you also apply a limit to your transit sessions?

We always use PeeringDB data and refuse to peer with networks not in PeeingDB ( 
I think there are only 2 exceptions ) Automation keeps the max_prefix numbers 
up to date. 

Our transits we use data from the weekly routing table reports and allow some 
expansion room.

So far this works for us

Regards

Steve

Setting sensible max-prefix limits

[Lars Prehn]

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 does that work for new peers? Do 
you negotiate/exchange sensible values whenever you establish a new 
session? Do you rely on PeeringDB (if available)? Do you apply default 
values to everyone except the big fishes?


Apart from your peers, do you also apply a limit to your transit sessions?

Best regards,

Lars