The DFZ and supernetting
Hi, We have had a fair amount of discussions lately on and off this list about the explosion of routes in the DFZ as a result of people wanting PI space and the likes. Others are ofcourse if there is no NAT66 how do you handle multihoming of a small site - but that is besides the point here. I have been wondering - since BGP is all about reachability as a goal and not so much optimal routing/best path/etc. is the easy solution for growth in the DFZ not overly simple? The way I see it you will end up with three sets of routes that you will need to carry on your routers: 1) Own customer routes - these can be any prefix length between /48 and /64 2) Other LIRs aggregates in same RIR region - these are /32 and bigger 3) Supernets for other RIR regions - these are /12 or larger So it seems like the explosion of the DFZ can be managed by supernetting certain routes. Having come up with this idea my next was - ok what am I missing here since it seems a simple and easy fix that would work without breaking much if anything. Can anyone enlighten me why we should not want to head in this direction? Met vriendelijke groet, Jasper Jans Team Leader Network Operations Sr. Network Engineer T: 088 - 00 68 152 F: 088 - 00 68 001 M: 06 - 218 26 380 E: jasper.jans@espritxb.nl EspritXB Monitorweg 1, 1322 BJ Almere Postbus 60043, 1320 AA Almere T: 088 00 68 000 KvK: 1717 7850 F: 088 00 68 001 W: http://www.espritxb.nl http://www.linkedin.com/companies/espritxb http://twitter.com/EspritXB EspritXB levert traditionele spraakdiensten en IP-gebaseerde diensten zoals VoIP, internettoegang, VPN, pinnen, alarm en managed hosting aan MKB Nederland. Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer
On man, september 19, 2011 11:38, Jasper Jans wrote: <snip>
I have been wondering - since BGP is all about reachability as a goal and not so much optimal routing/best path/etc. is the easy solution for growth in the DFZ not overly simple? The way I see it you will end up with three sets of routes that you will need to carry on your routers:
1) Own customer routes - these can be any prefix length between /48 and /64 2) Other LIRs aggregates in same RIR region - these are /32 and bigger 3) Supernets for other RIR regions - these are /12 or larger
... geo adressing? :-) anyway, about #3, how should be it implemented in practice? Who should carry others route in DFZ between regions, and who should distribute it to others? Should RIPE/ARIN/APNIC etc "pay" someone to make region<>region communication possible? and yeah, the idea is sound and I agree but can't really see an easy way to implement it today... -- --- ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - The Future is IPv6 ------------------------------------------------------- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
1) Own customer routes - these can be any prefix length between /48 and /64 2) Other LIRs aggregates in same RIR region - these are /32 and bigger 3) Supernets for other RIR regions - these are /12 or larger
... geo adressing? :-)
In a way yea. We have known reservations per RIR region.
anyway, about #3, how should be it implemented in practice? Who should carry others route in DFZ between regions, and who should distribute it to others? Should RIPE/ARIN/APNIC etc "pay" someone to make region<>region communication possible?
For the local LIRs I believe they already pay for this - they pay someone for IP transit. So this model seems to work for smaller LIRs - exactly the group of which many have stated they do not have the funding to continiously upgrade their equipment - especially not at the expense of someone else wanting PI space. Apart from picking one transit party over another unless I'm mistaken LIRs already default out to a bigger party these days already. The big boys - the parties that sell IP transit and hence connect in multiple regions - they would not to carry several more routes. I wonder if carrying /12s per region there would be sufficient - probably not. But on the other hand these are usually the parties that already have the bigger routers anyways.
and yeah, the idea is sound and I agree but can't really see an easy way to implement it today...
It is probably far from ideal - just came to me as a means to fix or at least bypass a hurdle for at least the LIRs that can otherwise not keep up with a growing routing table. Jasper Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer
On Mon, 2011-09-19 at 12:02 +0200, Roger Jørgensen wrote:
On man, september 19, 2011 11:38, Jasper Jans wrote: <snip>
I have been wondering - since BGP is all about reachability as a goal and not so much optimal routing/best path/etc. is the easy solution for growth in the DFZ not overly simple? The way I see it you will end up with three sets of routes that you will need to carry on your routers:
1) Own customer routes - these can be any prefix length between /48 and /64 2) Other LIRs aggregates in same RIR region - these are /32 and bigger 3) Supernets for other RIR regions - these are /12 or larger
... geo adressing? :-)
anyway, about #3, how should be it implemented in practice?
Good question.
Who should carry others route in DFZ between regions, and who should distribute it to others?
Anyone who so pleases.
Should RIPE/ARIN/APNIC etc "pay" someone to make region<>region communication possible?
Oh dear TCAMs, please no.
and yeah, the idea is sound and I agree but can't really see an easy way to implement it today...
It sounds suspiciously like ITU for me (ie, bad). It imposes previously non-existent architectural limits and constraints on Internet routing (given there is some form of routing police, of course :-)): How would you multi-home across region boundaries? What will happen with other inter-region connectivity? All AS:es who peer over a region-boundary, they will have to stop? (Who can enforce that?) Or will they have to get space from each regions RIR and do prefix translation in their routers? (This will amplify space usage by number of regions, roughly, for operators with presence in more than one region.) Jasper, how did you conclude that RIR region boundaries is a good place to draw the line in the sand by the way? Why, for example, didn't you suggest nation state borders? (Ie, Denmark could have 0045::, Sweden 0046:: and so on) Cheers, Martin
It sounds suspiciously like ITU for me (ie, bad). It imposes previously non-existent architectural limits and constraints on Internet routing (given there is some form of routing police, of course :-)): How would you multi-home across region boundaries?
Good point. Only way is ending up with a kludge I guess where for those parties that connect over multiple summarization boundries you do not only carry a summary but also the more specific. Hence you loose effect towards less routes in the table for these parties.
What will happen with other inter-region connectivity? All AS:es who peer over a region-boundary, they will have to stop? (Who can enforce that?) Or will they have to get space from each regions RIR and do prefix translation in their routers? (This will amplify space usage by number of regions, roughly, for operators with presence in more than one region.)
That can hardly be a correct way to go down. Sounds like this is for sure one of those items coming in the way of simple aggregation.
Jasper, how did you conclude that RIR region boundaries is a good place to draw the line in the sand by the way? Why, for example, didn't you suggest nation state borders? (Ie, Denmark could have 0045::, Sweden 0046:: and so on)
Just picked a boundry - I guess there are multiple boundries where aggregation can take place. For the moment I kinda stuck by the delegations known to me already (RIR/LIR/etc). Depending on how RIRs assign prefixes today you could implement summaries in between the RIR and LIR level. But in light of your point made above - it does seem to me that the more summaries are made on a smaller scale the more exceptions are required. In a way I also felt that it aligns well with what we for instance do - we do IP transit and peering. All peerings are mainly with parties inside Europe. Transit carries all the other traffic which is mainly US/Asia/etc. Jasper Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer
2011/9/19 Jasper Jans <Jasper.Jans@espritxb.nl>:
It sounds suspiciously like ITU for me (ie, bad). It imposes previously non-existent architectural limits and constraints on Internet routing That's exactly what I thought.
Why, for example, didn't you suggest nation state borders? If, and only if, anyone really would suggest practically borders, then please no nation state borders. Peering-Regions could be an idea, e.g. AMSIX-region, DECIX-region and at all places where LIRs use to peer.
How do LIRs handle the issue at the moment? I guess I would just add a default route to my routing table for one (or more) transit providers. Or buy a better(tm) router if I could afford it. Sorry for being barefaced, but although I appreciate the idea, I just don't think it is doable yet. One cannot aggegrate routes when it is not reflected on the corresponding infrastructure, can one? regards, danrl -- danrl / Dan Luedtke http://www.danrl.de
Hi The same problem (http://tools.ietf.org/html/rfc4984) has been discussed in the Routing Research Group for a couple years. Their discussion has been summarized in: http://tools.ietf.org/html/rfc6115 AFAIR there is a section talking about aggregating prefixes. Luigi On Sep 19, 2011, at 14:19 , Dan Luedtke wrote:
2011/9/19 Jasper Jans <Jasper.Jans@espritxb.nl>:
It sounds suspiciously like ITU for me (ie, bad). It imposes previously non-existent architectural limits and constraints on Internet routing That's exactly what I thought.
Why, for example, didn't you suggest nation state borders? If, and only if, anyone really would suggest practically borders, then please no nation state borders. Peering-Regions could be an idea, e.g. AMSIX-region, DECIX-region and at all places where LIRs use to peer.
How do LIRs handle the issue at the moment? I guess I would just add a default route to my routing table for one (or more) transit providers. Or buy a better(tm) router if I could afford it. Sorry for being barefaced, but although I appreciate the idea, I just don't think it is doable yet.
One cannot aggegrate routes when it is not reflected on the corresponding infrastructure, can one?
regards, danrl
-- danrl / Dan Luedtke http://www.danrl.de
participants (5)
-
Dan Luedtke -
Jasper Jans -
Luigi Iannone -
Martin Millnert -
Roger Jørgensen