[158141] in North American Network Operators' Group
RE: What is BCP re De-Aggregation: strict filtering /48s out of /32
daemon@ATHENA.MIT.EDU (Ben S. Butler)
Thu Nov 22 06:29:43 2012
From: "Ben S. Butler" <Ben.Butler@c2internet.net>
To: "nanog@nanog.org" <nanog@nanog.org>
Date: Thu, 22 Nov 2012 11:28:31 +0000
In-Reply-To: <416A23FC91E34449999D047BF540B46901689658E308@EXCHANGE.atlasbiz.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Hi,
I have been thinking some more. Could we not solve the problem of legacy a=
ssignments of /32s that have been split to /48 with no covering route out o=
f a RIR block with a /32 minimum with relative ease. AS operators that cho=
ose to filter these RIR blocks on /48 minimum have no problems, ISPs that c=
hoose to filter on /32 minimum do as they loose visibility of these "island=
networks" aka no covering route.
If we were to extend peeringDB to add a field to indicate with there is a c=
overing route or not, this could then be used to assign a peer to a peer-gr=
oup with the associated filter as appropriate either permitting 48s or deny=
ing them. This enables the people that have deigned their networks in this=
fashion to indicate as such, and those who choose to use the information c=
an accept their prefixes without having to accept any old 48.
Peering DB could then also publish a RegExp string from their database of a=
ll the ASes that have indicated no covering route. This could then be used=
, if desired, by an AS operator to filter his BGP sessions which are not di=
rectly with the end AS, transit or peering, enabling the deployment of a ro=
ute-map that would match the RegExp and prefix length of 48 and permit thes=
e, then match the Regexp with a prefix length <>48 and deny all of that (be=
cause there shouldn't be any), and then match what is left on a filter list=
that selected on RIR minimums.
The island networks would be incentivised to register, those that choose to=
filter can, those that don't want to can accept all 48s. Filters can be u=
sed on RIR minimums and new assignments made out of the new non-contiguous =
address blocks with a 48 minimum size, and the legacy problem is handled. =
Everyone is happy. No technology needs to change and all that is needed is=
for someone such as peeringDB to keep a record of the ASes that indicate t=
hey don't have a covering route and this can be readily used when setting u=
p direct peerings or used to construct a generic filter for all ASes in thi=
s category to be applied to other BGP sessions.
Thoughts.... RIPE seems to be saying its upto the community to decide polic=
y, ours is a /32 minimum and we strongly recommend you don't de-agregate bu=
t we are not going to tell you you can't. The legacy of island networks is=
the only thing that forces this issue to be dealt with one way or the othe=
r as it is not possible for them as they currently have things setup to ann=
ounce the covering route.
I think a BCP would be good that considered alternatives to the polarized d=
ebate of do or don't do minimum filters vs TE routes vs why should I carry =
your TE. I think something like the above could be simply implemented as a=
n opt in system that could be used if operators choose to that would keep a=
ll three groups of AS operators happy.
Ben
-----Original Message-----
From: Ben S. Butler=20
Sent: 16 November 2012 00:54
To: 'Matthew Petach'; Ben S. Butler
Cc: nanog@nanog.org
Subject: RE: What is BCP re De-Aggregation: strict filtering /48s out of /3=
2 RIR minimums.
