[157918] 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 15 05:15:46 2012
From: "Ben S. Butler" <Ben.Butler@c2internet.net>
To: "'nanog@nanog.org'" <nanog@nanog.org>
Date: Thu, 15 Nov 2012 10:15:04 +0000
In-Reply-To: <416A23FC91E34449999D047BF540B46901689658E2FC@EXCHANGE.atlasbiz.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Hi,
I thought I would share an extract from an email I sent off list to a peer.=
My mail was a rather ramberly stream of consciousness exploring the issue=
, which worked its way to a potential solution... Hence why I am sharing an=
extract from it. I am not sure how practicably implementable it would be =
with the use of communities and some extra filtering logic implemented by t=
he router software to enable prefix matching on less specific. I include f=
or open discussion, I am sure there are things wrong with this idea, but ma=
ybe we can move towards a solution that works for everyone, rather than con=
tinuing in a straight line and having a bloated v6 route soup of indistingu=
ishable /48s all over the place. Maybe the below has some legs, I leave it=
for those clever than me to see if this can be incorporated into an emerge=
nt BCP that might address what we should be doing and give everyone clear g=
uidelines and keep everything on track.
<snip>
As I said its not the content networks I have issue with, it the rest of th=
e access networks and hosting networks that are going to abuse a relaxation=
policy of "you should only announce /32 and use communities and no export =
for TE to adjacent ASes, but because there are a lot of island networks tha=
t require /48 support yours will also get accepted but please don't do this=
for TE reasons."
What we need is a way to filter that says throw this prefix away if I can s=
ee it inside of another prefix. Ie discard this /48 if it is part of a /32=
(or bigger) that I also have in my RIB and then insert the /32 into FIB an=
d discard the /48". That would dump off all the TE nonsense, while keeping=
the island networks /48s. This new functionality could be used in a route=
map so it could be augmented with community matching or AS filter lists. =
That would solve the problem, all be it at the cost of the processing overh=
ead to examine each /48 in the table and recurse its route, versus simple a=
pplication of a filter list based on net block and minimum allocation size.=
I guess another thing that might work is if we all start passing communit=
ies and then we can tag some /48s as I am a TE prefix with a cover route an=
d use a different community to tag I am an island prefix with no cover rout=
e, and then we can filter or permit those in a route map as the recipient s=
ees fit and next the route map could filter everything left on RIR minimums=
for the block. That might work a lot better, if everyone passed communiti=
es.... At least people would be incentivised to tag the island routes which=
would be guaranteed to be permitted, we might have to worry about some peo=
ple tagging a TE route as an island route. So I guess the logic becomes...=
.
/48 Routes tagged with an island community permit as long as there is not a=
less specific covering route in the RIB.
/48 Routes tagged with a TE community can be permitted or denied as chosen =
by the recipient end AS but should be carried in the DFZ by transit provide=
rs.
/48 Routes that are not tagged should be assessed against RIR netblock mini=
mums as being valid or invalid.
Future RIR assignments should rigorously explore if the assignment is inten=
ded to be going to have an aggregate route or not, so for island networks t=
hat will not be aggregated are moved to a separate /12 with a /48 minimum a=
nd /40 maximum announced prefix size - rather than carried in the same bloc=
k as "PA (Aggregated)" / "ISP" blocks that have a /32 minimum.
If we do that, it keeps the existing problem the size it is currently and s=
olves it for future assignments, allows the island networks to work, preven=
ts people cheating by trying to sneak a TE route in as an island route when=
there is covering /32 route, dumps off the rubbish from spurious announcem=
ents and hijacking, while allowing PI end user /48s to continue to work... =
I think that would address the problem.
</snip>
Thoughts...?
Ben
-----Original Message-----
From: Ben S. Butler=20
Sent: 15 November 2012 00:05
To: 'Michael Smith'; William Herrin
Cc: nanog@nanog.org
Subject: RE: What is BCP re De-Aggregation: strict filtering /48s out of /3=
2 RIR minimums.
Hi,
" Again, I thought the discussion was about PI, not PA. I don't announce a=
ny PA."
My point, which I feel may be getting lost, and for which ARIN may already =
have policies in place for, is that an IP assignment is made out of a block=
with a defined minimum assignment size.
Now some people simply advertise the assignment that is made to them, some =
people chose to advertise more specifics with a covering route, I have no p=
roblem with any of this. What I am saying, is if people chose to deagregat=
e to create islands, for which I can completely understand the commercial a=
nd networking reason and why it is then by extension impossible for them to=
advertise the covering route. Then in these specific cases of "islands" th=
en these assignments should be made by the RIR from a block with a minimum =
prefix size of a /48. Then the application is submitted to the RIR it will=
justify as much space as it justifies, but at this point it should also be=
established - without any judgment positive or negative - if the intention=
is to advertise this unagregated or with a route for the aggregate. The R=
IR would then be empowered to assign the requested amount of address space =
from a block which can be labelled with a lower minimum prefix size.
I am not judging any of these design practices. What I am pointing out is =
that the designs are being implemented in assignment blocks that do not ref=
lect the recipients implementations intentions and this is neither helpful =
for them or other AS operators when it comes to filtering. If RIR policies=
establish this intention at the point of assignment then the "island" case=
will be catered for and we absolutely do not want to see an aggregate in t=
he route table for assignments from that block. IF it is TE then it can be=
made from a conventional block with a cover router and more specifics.
What I am seeing in the real world is island networks in address space with=
minimum /32 assigments. It is my choice if I filter your TE, it is a stup=
id choice if you don't advertise the cover route because you are doing TE. =
But what we need to facilitate are islands networks which for very sensibl=
e technical and commercial reasons are unable to advertise an aggregate. P=
olicies may be in place to provide for this, however, what I am seeing in t=
he route table is telling me that the policies are failing to identify peop=
le that want to implement their network in this fashion as they are coming =
from blocks with /32 min and they are advertising /48s. If these announcem=
ents came from and address block to which they were assigned with a minimum=
of a /48 because of their design intentions then everyone is happy and can=
announce and filer accordingly and end points are reachable.
There is a reason that different blocks have different minimum sizes, I am =
advocating ensuring that we get assignments aligned with the blocks that ar=
e suit the intended implementation.
It is not my place to judge your business, nor is it anyone elses to expect=
the rest of us to accept TE routes without a coverall and expect to be rea=
chable.
My 2c
Ben
-----Original Message-----
From: Michael Smith [mailto:mksmith@mac.com]=20
Sent: 14 November 2012 23:32
To: William Herrin
Cc: nanog@nanog.org; Michael Smith
Subject: Re: What is BCP re De-Aggregation: strict filtering /48s out of /3=
2 RIR minimums.
On Nov 14, 2012, at 1:50 PM, William Herrin <bill@herrin.us> wrote:
> On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith <mksmith@mac.com> wrote:
>> I guess I'm confused. I have a /32 that I have broken up into /47's=20
>> for my discrete POP locations. I don't have a network between them,=20
>> by design. And, I won't announce the /32 covering route because=20
>> there is no single POP that can take requests for the entire
>> /32 - think regionalized anycast.
>>=20
>> So, how is it "worse" to announce the deaggregated /47's versus=20
>> getting a /32 for every POP? In either case, I'm going to put the=20
>> same number of routes into the DFZ.
>=20
> Hi Michael,
>=20
> If you announce an ISP /32 from each POP (or an end-user /48, /47,
> etc) then I know that a neutral third party has vetted your proposed=20
> network configuration and confirmed that the routes are disaggregated=20
> because the network architecture requires it. If you announce a /47=20
> from your ISP space, for all I know you're trying to tweak utilization=20
> on your ISP uplinks.
>=20
Again, I thought the discussion was about PI, not PA. I don't announce any=
PA.
> In the former case, the protocols are capable of what they're capable=20
> of. Discrete multihomed network, discrete announcement. Like it or=20
> lump it.
>=20
> In the latter case, I don't particularly need to burn resources on my=20
> router half a world away to facilitate your traffic tweaking. Let the=20
> ISPs you're paying for the privilege carry your more-specifics.
>=20
You have great confidence in the immutability of design and the description=
thereof.
Mike
