[157912] 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)
Wed Nov 14 19:05:50 2012
From: "Ben S. Butler" <Ben.Butler@c2internet.net>
To: 'Michael Smith' <mksmith@mac.com>, William Herrin <bill@herrin.us>
Date: Thu, 15 Nov 2012 00:05:08 +0000
In-Reply-To: <19C3960E-2E90-4965-BF16-8A5B40B5B923@mac.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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
