Search RPD Archives
[rpd] Factors affecting in-region utilization - way forward?
Stephen Wilcox
steve.wilcox at ixreach.com
Mon Jul 21 21:30:19 UTC 2014
On 21 July 2014 23:47, Owen DeLong <owen at delong.com> wrote:
>
> 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.
>
Um you have just one single tier-1 propagating this.. there is no way int
he world this is globally routable..! Even you, 6939 does not propagate
it...
Anyway this argument feels tit-for-tat but my point remains, You cannot use
netblocks of prefixes greater than /24 in the internet of 2014.
Steve
>
> 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
>
>
>
--
Director / Founder
IX Reach Ltd
E: steve.wilcox at ixreach.com
M: +44 7966 048633
Tempus Court, Bellfield Road, High Wycombe, HP13 5HA, UK.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20140722/cf0c5803/attachment.html>
More information about the RPD
mailing list