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:mksm...@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 <b...@herrin.us> wrote: > On Wed, Nov 14, 2012 at 3:10 PM, Michael Smith <mksm...@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
