RE: What is BCP re De-Aggregation: strict filtering /48s out of /32 RIR minimums.

["Ben S. Butler" <Ben.Butler () c2internet net>]

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 the router software to enable prefix matching on less specific.  I include for open discussion, I 
am sure there are things wrong with this idea, but maybe we can move towards a solution that works for everyone, rather 
than continuing in a straight line and having a bloated v6 route soup of indistinguishable /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 emergent 
BCP that might address what we should be doing and give everyone clear guidelines and keep everything on track.

<snip>

As I said its not the content networks I have issue with, it the rest of the 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 that 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 see 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 and 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 overhead to examine each /48 in the table and recurse its route, 
versus simple application 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 communities and then we can tag some /48s as I am a TE prefix with a cover route 
and use a different community to tag I am an island prefix with no cover route, and then we can filter or permit those 
in a route map as the recipient sees 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 communities.... 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 people 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 providers.

/48 Routes that are not tagged should be assessed against RIR netblock minimums as being valid or invalid.

Future RIR assignments should rigorously explore if the assignment is intended to be going to have an aggregate route 
or not, so for island networks that will not be aggregated are moved to a separate /12 with a /48 minimum and /40 
maximum announced prefix size - rather than carried in the same block 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 solves it for future assignments, allows the 
island networks to work, prevents 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 announcements 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 
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 /32 RIR minimums.

Hi,

" Again, I thought the discussion was about PI, not PA.  I don't announce any 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 problem with any of this.  What I am saying, is if people chose to deagregate to 
create islands, for which I can completely understand the commercial and networking reason and why it is then by 
extension impossible for them to advertise the covering route. Then in these specific cases of "islands" then 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 RIR 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 reflect 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 the 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 stupid 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 sensible technical and commercial reasons are unable to 
advertise an aggregate.  Policies may be in place to provide for this, however, what I am seeing in the route table is 
telling me that the policies are failing to identify people 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 announcements 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 are 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 reachable.

My 2c

Ben

-----Original Message-----
From: Michael Smith [mailto:mksmith () mac com] 
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 /32 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 
> > for my discrete POP locations.  I don't have a network between them, 
> > by design.  And, I won't announce the /32 covering route because 
> > there is no single POP that can take requests for the entire
> > /32 - think regionalized anycast.
> >
> > So, how is it "worse" to announce the deaggregated /47's versus 
> > getting a /32 for every POP?  In either case, I'm going to put the 
> > same number of routes into the DFZ.
>
> Hi Michael,
>
> 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 
> network configuration and confirmed that the routes are disaggregated 
> because the network architecture requires it. If you announce a /47 
> from your ISP space, for all I know you're trying to tweak utilization 
> on your ISP uplinks.
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 
> of. Discrete multihomed network, discrete announcement. Like it or 
> lump it.
>
> In the latter case, I don't particularly need to burn resources on my 
> router half a world away to facilitate your traffic tweaking. Let the 
> ISPs you're paying for the privilege carry your more-specifics.

You have great confidence in the immutability of design and the description thereof.

Mike