Search RPD Archives
[rpd] Factors affecting in-region utilization - way forward?
Owen DeLong
owen at delong.com
Mon Jul 21 19:47:09 UTC 2014
On Jul 21, 2014, at 01:42 , Stephen Wilcox <steve.wilcox at ixreach.com> wrote:
>
>
>
> On 21 July 2014 02:00, Owen DeLong <owen at delong.com> wrote:
>
> On Jul 20, 2014, at 13:45 , Stephen Wilcox <steve.wilcox at ixreach.com> wrote:
>
>>
>>
>>
>> On 20 July 2014 21:46, Owen DeLong <owen at delong.com> wrote:
>>> So if a service provider takes action against de-aggregates
>>> (either by blocking them off or charging for them), it puts
>>> them at a disadvantage with their competitors.
>>>
>>> This has always been the case, but so far its not made a difference…
>>
>> 1. You don’t actually know that.
>> 2. Are you certain it isn’t the primary reason nobody is doing this (yet)?
>>
>> I would argue that it is very likely the the primary reason and thus has, so far, made all the difference.
>>
>> I mean, that providers have always either refused to accept small address blocks (/24 has been the "limit" for many years, before that it was RIR allocation boundaries or classful addressing). Those that reluctantly accept blocks smaller than /24 usually caveat that it won't actually work on the global Internet. This seems to have held back routing of small blocks despite there always been a subset of demand, typically from corporates for routing small blocks.
>
> Route Views contradicts you:
>
> route-views>sh ip bgp | inc /2[56789]
> *> 1.9.56.0/25 202.249.2.86 0 7500 2516 4788 i
> *> 1.9.56.128/25 202.249.2.86 0 7500 2516 4788 i
> *> 1.209.11.240/28 194.85.102.33 0 3277 39710 9002 4766 38668 i
> *> 4.31.236.64/29 128.223.253.10 0 3582 4600 11537 1 i
> * 4.78.192.96/27 202.249.2.86 0 7500 2516 12989 26769 i
> * 5.44.72.0/25 193.0.0.56 0 3333 51088 i
> * 5.44.73.0/25 193.0.0.56 0 3333 51088 i
> * 5.45.254.0/25 129.250.0.11 386 0 2914 9002 13238 i
> *> 5.254.117.128/25 194.85.102.33 0 3277 39710 9002 39743 i
> *> 8.13.224.0/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.224.32/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.224.64/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.224.96/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.224.128/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.225.64/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.226.0/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.226.32/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.226.64/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.226.96/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.226.128/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.226.160/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.226.192/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.228.0/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.228.32/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.228.64/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.228.96/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.228.128/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.228.160/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.228.192/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.229.0/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.230.0/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.230.32/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.230.64/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.230.96/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.230.128/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.230.160/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.231.224/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.232.0/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.232.32/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.232.64/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.232.192/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.234.0/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.234.32/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.234.64/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.234.96/27 128.223.253.10 0 3582 4600 11537 1 i
> *> 8.13.234.128/27 128.223.253.10 0 3582 4600 11537 1 i
> * 12.219.55.0/26 202.249.2.86 0 7500 2516 3549 19015 ?
> *> 14.33.166.40/29 194.85.102.33 0 3277 39710 9002 4766 23564 i
> *> 14.34.221.72/29 194.85.102.33 0 3277 39710 9002 4766 i
> *> 14.48.1.128/27 202.249.2.86 0 7500 2516 4766 i
> *> 14.48.1.192/27 202.249.2.86 0 7500 2516 4766 i
> *> 14.48.11.128/27 202.249.2.86 0 7500 2516 4766 i
> *> 14.48.199.208/29 194.85.102.33 0 3277 39710 9002 4766 i
> *> 14.63.70.8/29 194.85.102.33 0 3277 39710 9002 4766 i
> * 14.129.224.0/25 203.181.248.168 0 7660 2516 4766 9457 38676 ?
> *> 14.137.188.0/27 203.62.252.186 0 1221 9482 i
> *> 14.137.188.32/28 203.62.252.186 0 1221 9482 i
> * 20.132.2.64/26 202.249.2.86 0 7500 2516 3549 21877 i
> * 23.61.246.0/25 202.249.2.86 0 7500 2516 3462 i
> * 24.229.95.0/25 128.223.253.10 0 3582 4600 11537 10466 32162 53913 i
> *> 27.124.36.32/28 194.85.102.33 0 3277 39710 9002 9498 ?
> *> 27.124.36.64/27 194.85.102.33 0 3277 39710 9002 9498 9730 ?
> *> 27.124.36.96/28 194.85.102.33 0 3277 39710 9002 9498 9730 ?
> *> 27.124.37.0/28 194.85.102.33 0 3277 39710 9002 9498 ?
> *> 27.124.37.16/28 194.85.102.33 0 3277 39710 9002 9498 i
> *> 27.124.37.40/29 194.85.102.33 0 3277 39710 9002 9498 ?
> *> 27.124.37.88/29 194.85.102.33 0 3277 39710 9002 9498 ?
> *> 27.124.37.104/29 194.85.102.33 0 3277 39710 9002 9498 ?
> *> 27.124.37.128/28 194.85.102.33 0 3277 39710 9002 9498 ?
> *> 27.124.37.160/27 194.85.102.33 0 3277 39710 9002 9498 ?
> *> 27.124.37.240/28 194.85.102.33 0 3277 39710 9002 9498 9730 ?
> * 27.125.159.128/26
> * 27.125.159.192/26
> *> 27.255.66.32/27 202.249.2.86 0 7500 2516 4766 i
> *> 27.255.66.64/28 194.85.102.33 0 3277 39710 9002 4766 i
> *> 27.255.66.80/28 194.85.102.33 0 3277 39710 9002 4766 i
> *> 27.255.66.96/28 194.85.102.33 0 3277 39710 9002 4766 i
> *> 27.255.66.128/28 194.85.102.33 0 3277 39710 9002 4766 i
> *> 27.255.77.128/25 202.249.2.86 0 7500 2516 4766 i
> *> 31.169.50.24/29 193.0.0.56 0 3333 1103 50304 60717 i
> *> 31.172.136.0/28 193.0.0.56 0 3333 1103 15772 24685 i
> *> 31.172.136.16/28 193.0.0.56 0 3333 1103 15772 24685 i
> *> 31.172.136.32/28 193.0.0.56 0 3333 1103 15772 24685 i
> *> 31.172.136.48/28 193.0.0.56 0 3333 1103 15772 24685 i
> *> 31.172.136.96/28 193.0.0.56 0 3333 1103 15772 24685 i
> *> 31.172.136.112/28
> *> 31.172.136.160/27
> *> 31.172.136.192/27
> *> 31.172.137.0/25 193.0.0.56 0 3333 1103 15772 24685 i
> *> 31.172.137.128/25
> *> 31.172.141.0/25 193.0.0.56 0 3333 1103 15772 24685 i
> *> 31.172.141.128/25
> * 31.186.234.0/26 202.249.2.86 0 7500 2516 3549 15570 i
> * 31.186.234.64/26 202.249.2.86 0 7500 2516 3549 15570 i
> --More--
>
> And that's just the first screen full, which gets us less than 1/5th of the way through the address space. It also doesn't
> include /30-/32 size prefixes as I wasn't that creative with my regex foo.
>
>> And I'd say that I do know it - there are no /25-32 addresses routable across a majority of the global internet.
>
> I lack adequate perspective to say for certain that these prefixes are our would be visible on enough routers to comprise "a majority of the global internet" (and so do you or anyone else, in actual fact).
>
> Seriously? Owen, I know you're better than that! Troll bait perhaps but I'll respond.
>
> There's 30-40 full BGP feeds sent to route-views often reflecting internal views from each ASN and not what they would necessarily propagate downstream, each of those prefixes in your screen grab are seen behind a single obscure path, there should be another 30-40 route entries *per prefix* .. there's not a single tier-1 in there, not even your employer AS6939!
Um, no. The | include regexp construct I used prevented the additional paths from being displayed, but, they are not, in fact, all single-paths.
At random:
route-views>sh ip bgp 27.125.159.128
BGP routing table entry for 27.125.159.128/26, version 2028363256
Paths: (3 available, best #2, table Default-IP-Routing-Table)
Flag: 0x820
Not advertised to any peer
7500 2516 3549 38861 55430
202.249.2.86 from 202.249.2.86 (202.249.2.86)
Origin IGP, localpref 100, valid, external
7660 2516 3549 38861 55430
203.181.248.168 from 203.181.248.168 (203.181.248.168)
Origin IGP, localpref 100, valid, external, best
Community: 2516:1030
3549 38861 55430
208.51.134.254 (inaccessible) from 208.51.134.254 (67.17.81.150)
Origin IGP, metric 2593, localpref 100, valid, external
Sure, this all ends at the same origin and even two of its upstreams are identical, but 2516 is also accepting it from 3549 and 7500 is taking it from them and passing it along.
I suppose you can argue that these are all cases of "unintended leakage", but whether intentional or through leakage, longer prefixes go farther than you would like to believe.
> You know full well these are not even remotely globally routable by themselves. Why assert they are or might be?!
That depends on your definition of "remotely globally routable".
>
> My point is that nobody is dropping /24s and I would be pretty surprised to see anyone start doing. I would argue that the primary reason that static situation has persisted is that doing so would put one at a competitive disadvantage. Otherwise, I know for a fact that there are a number of providers that would love to shrink their routing tables by dropping /21-/24 routes, for example. (Or at least several have expressed a desire to do so at one time or another).
>
> /24s have been acceptable since the late 1990s.
Yes.
> I'm sorry but prefixes longer than /24 simply will not work on the global Internet of 2014, you are welcome to sell transit to a customer with a small block but we all know unless you are holding the aggregate that its come from that its not going to work for what anyone would consider "global internet access".
They're definitely sub-optimal, to be sure, but "will not work" hasn't born out in my experience or in that of some of my clients who refused to listen to me.
> There is a possible place for longer prefixes which is for TE or connecting separate sites through a single upstream but neither of these is the scenario on the table.
On this we at least agree.
Don't get me wrong, I'm not advocating for longer than /24 IPv4 prefixes. I actually believe that the coming disaster in the IPv4 routing table is going to be the primary driver for IPv6 adoption well surpassing the IPv4 address shortage in the next few years. (Though I believe that the address shortage will be one of the primary drivers in the coming fragmentation
of the IPv4 routing table).
I'm just saying that what is coming will hit much harder than most people predict and that longer prefixes are out there, are being distributed, and when they start multiplying, it's going to get very interesting trying to keep the IPv4 internet running.
Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20140721/54ce09b7/attachment.html>
More information about the RPD
mailing list