Re: [GROW] [v6ops] Deaggregation data
On 20/10/2014 23:41, Randy Bush wrote: > there seems to be a lot of deagg because of the perception that it > reduces the threat of mis-origination of one's routes. asia/pac is the > poster child for this but the competition is keen, see geoff's reports. this could be highly entertaining in the ipv6 world. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [v6ops] Deaggregation data
> The deaggregation pressure will be lower because the only deaggregation > pressure will be from TE funny, that was not the case with v4 four years ago Luca Cittadini, Wolfgang Mühlbauer, Steve Uhlig, Randy Bush, Pierre Francois, Olaf Maennel, Evolution of Internet Address Space Deaggregation: Myths and Reality, in IEEE Journal on Selected Areas in Communications, Vol. 28, No. 8, October 2010. there seems to be a lot of deagg because of the perception that it reduces the threat of mis-origination of one's routes. asia/pac is the poster child for this but the competition is keen, see geoff's reports. tl;dr (from the abstract): The impact of “bad guys” on routing table size growth and BGP churn has not changed for the worse in recent years. Rather, it increases at the same pace as the Internet itself. randy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [v6ops] Deaggregation data
On 20/10/2014 22:58, Christopher Morrow wrote: > NOTE: why don't v6 allocations in that file have 'ALLOCATED PA' in > their entries? because there are only two types of v6 blocks: ALLOCATED PA and ASSIGNED PA. The assignments aren't in that document and for v4, there are several types of status: ASSIGNED PA, ASSIGNED PI, ALLOCATED PA, ALLOCATED PI, EARLY REGISTRATION OR LIR-PARTITIONED. >> The baseline for starting to deaggregate will be much lower for ipv6 and >> there will be much less pressure in future to deaggregate. > > why is that? I thought geoff's numbers/reasons for deaggregation were > linked more to TE (perceived or supposed) than anything else? (maybe a > bunch of 'redistributed connected' as well) the baseline is lower because we're starting off with a situation where most LIRs have been allocated all the ipv6 address space they will ever need. The deaggregation pressure will be lower because the only deaggregation pressure will be from TE and there will be no need to slide-n-dice IPv6 address blocks in future asset sales, and no last /20 per RIR. IPv4 space has deaggregation pressure from last /8 assignments, from TE requirements and will have future pressure from asset sales. Once divided, the allocations will be impossible to reaggregate. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [v6ops] Deaggregation data
On Fri, Oct 17, 2014 at 4:45 PM, Nick Hilliard wrote: > On 17/10/2014 17:58, Randy Bush wrote: >> [ not pickin' on you, nick ] >> >> trying to find protein in this whole thread. > > thin pickings :-( > >> in the long run, why will v6 not suffer the > reasons goes here> same deaggregation which is about half of the v4 >> routing table? > > It might, but it won't matter as much because the number of baseline ipv6 > allocations will be a whole pile lower. Here's why. > > 1. retrospectively: the RIR policies of not handing out piecemeal > allocations based on 2Y policy means that most organisations will never > need a second allocation outside their /32. If you look at existing RIR > allocations, many of them are to the same organisations. Looking at: > > ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt > > There are: > > 7564 LIRs with ipv4 allocations outside 185/8 > 19856 ipv4 allocations outside 185/8 > > so the average # of allocations per LIR is ~2.62 for pre-last /8 addresses. wow, there are 4454 LIR allocations inside 185/8 :) with: 4568 distinct prefixes. (that's probably reasonably expected though) > Over all allocations, the numbers are 24416 allocations and 10134 LIRs. > I.e. the last /8 policy has dramatically increased the number of LIRs with > a single allocation. Possibly this is related to lack of PI space. is this also skewed because 'space is getting short, make sure to get your requests in NOW!' behavior? (or 'scarcity got people's attention') I guessed (so probably not the best judge for science) that 62/8 was being allocated for a longer bit of time, it seems: Apr 1997 -> Mar 2011 There are 671 allocations in this space though, across 457 LIRs or 1.49 prefixes/LIR... so it seems that the numbers oscillate a bit inside of the buckets, interesting I suppose. (perhaps not super germaine though) NOTE: why don't v6 allocations in that file have 'ALLOCATED PA' in their entries? 20121123185.11.8.0/22 ALLOCATED PA 201010232a02:2718::/29 despite: inet6num: 2a02:2718::/29 netname:YE-PTC-20101023 descr: Public Telecommunication Corporation country:ye org:ORG-PTC4-RIPE admin-c:YAA330-RIPE admin-c:IIA13-RIPE tech-c: MRA220-RIPE status: ALLOCATED-BY-RIR mnt-by: RIPE-NCC-HM-MNT > RIPE has allocated 8069 ipv6 prefixes to 7849 LIRs, i.e. an allocation rate > of 1.02. This includes last /8 assignments from RIPE's silly policy of > requiring an ipv6 allocation for a last /8 assignment. > > This indicates that virtually all LIRs are staying within the bounds of > their original allocations. This will reduce future pressure on the number > of prefixes in the dfz. I also wonder how much the spread of LIR/org really is? for MDN or other uses of 'oops, I need another /32'. > 2. in future: there are 10398 LIRs listed in alloclist. Of these, 7849 or > almost exactly 75% of LIRs already have IPv6 allocations. So assuming that > all RIPE LIRs will have an ipv6 allocation in future, that's growth from > 8069 to ~10700 + one for each new LIR. > > 3. further deaggregation of the ipv4 dfz will be driven by the market > economics of address holders splitting up their net blocks. > > 4. down the road, if we can get RIPE to stop its silly policy of requiring > an ipv6 allocation in order to get an ipv4 allocation from the last /8, > this will further reduce pressure on the overall number of allocations, > which leads to: > >> maybe if we start filtering now. but we know how well that went in ipv4 >> when their suits called our suits and said "we pay you to let us contact >> . > > The baseline for starting to deaggregate will be much lower for ipv6 and > there will be much less pressure in future to deaggregate. why is that? I thought geoff's numbers/reasons for deaggregation were linked more to TE (perceived or supposed) than anything else? (maybe a bunch of 'redistributed connected' as well) -chris > I haven't looked at the other RIR figures. No doubt they differ in > numbers, but my hunch is that they tell a similar story. > > Nick > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [v6ops] Deaggregation data
On 18/10/2014 10:06, Robert Raszuk wrote: > You can't *mandate* anything in BGP until you have a way to > effectively enforce it regardless if this is v4 or v6 or v9. it's a common misconception that bgp is a stick to beat people with, and that the RIRs are the routing police. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [v6ops] Deaggregation data (was: Deaggregation by large organizations)
> IPv6 BPs could mandate best aggregates only. You can't *mandate* anything in BGP until you have a way to effectively enforce it regardless if this is v4 or v6 or v9. It is not the problem of folks in shorts and sandals who type in BGP policies, but as Randy said those in suits who care about their respective businesses. Today at most we can have Geoff very nicely illustrating the picture at next RIPE or NANOG. But he does not have a way to issue fine tickets to offenders :) Best, r. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [v6ops] Deaggregation data (was: Deaggregation by large organizations)
Just my .002. Maybe it could help in the discussion to make a distinction between subnets of an AS and different ASes. Clearly there is no solution for the latter. And for the first, there will be lots of controversy ;-) IPv6 BPs could mandate best aggregates only. /PA El 17/10/2014 15:47, "Marc Binderberger" escribió: > Hello Nick and Iljitsch, > > fairly stable baseline of 20-30%, which may be acceptable if it stays > there. > Although peaks of 70% (is the 100% a graph problem?) seem to be a reason > _for_ filtering. > > Now what I'm wondering > > (1) is there a need to carry all the deaggregates? Because if you are far > enough away they may "look the same as the aggregate". To use Iljitsch' > example ... > > > I know this is controversial. "Topology ain't geography". Actually, most > of > > the time there is a significant correlation. If all German cities inject > a > > more specific, do you really need to hear those in Tokyo or Seattle? Just > > send the traffic to Europe as per the aggregate and let them figure it > out > > there. > > ... it's likely that for an US ISP X, peering with European ISPs Y and Z > who > carry the various deaggregate plus aggregate from Germany, all the European > prefixes have this peering router as next hop (let's say we have > next-hop-self). > > What about BGP on this peering router doing some auto-aggregation in such a > case? Has this been discussed? It would avoid geographic communities and > would simply follow the BGP topology: if the deaggregates result in the > same > forwarding information than the aggregate just keep the aggregate. Your > routing table would have deaggregates for your own region but only > aggregates > for the other, more distant regions. > > > (2) the problem of ever-growing routing tables and de-aggregation is not > new. > After so many years I'm wondering if the answer is that this cannot be > solved > with BGP/routing alone (?) Otherwise you would have found a solution > meanwhile :-) > And we have the - understandable and growing - needs of Enterprises, who > de-aggregate their PA addresses when they are LIR, or request PI addresses > per location. > > Combining this, should the de-aggregation step not be done with a different > technology? LISP comes to my mind (biased, as I'm working on it) or in > general a "de-aggregation overlay". The overlay would need gateways to the > BGP world and would announce one aggregate prefix only while the > de-aggregate > prefixes would be limited to the particular Enterprise overlay network and > would not show up in BGP. > > > > Regards, Marc > > > > > On Thu, 16 Oct 2014 22:16:09 +0100, Nick Hilliard wrote: > > On 16/10/2014 16:47, Iljitsch van Beijnum wrote: > >> Growth in IPv6 more specifics was 57% last year... > > > > Here's a graph which shows the percentage of more-specifics between 2003 > > and today from Geoff Huston's web site: > > > > http://goo.gl/QA0xud > > > > Eyeballing the graph, it's not clear where the figure of 57% came from. > In > > terms of trajectories, there doesn't seem to be a major problem either. > > > > Nick > > > > ___ > > v6ops mailing list > > v6...@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [v6ops] Deaggregation data
On 17/10/2014 17:58, Randy Bush wrote: > [ not pickin' on you, nick ] > > trying to find protein in this whole thread. thin pickings :-( > in the long run, why will v6 not suffer the reasons goes here> same deaggregation which is about half of the v4 > routing table? It might, but it won't matter as much because the number of baseline ipv6 allocations will be a whole pile lower. Here's why. 1. retrospectively: the RIR policies of not handing out piecemeal allocations based on 2Y policy means that most organisations will never need a second allocation outside their /32. If you look at existing RIR allocations, many of them are to the same organisations. Looking at: ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt There are: 7564 LIRs with ipv4 allocations outside 185/8 19856 ipv4 allocations outside 185/8 so the average # of allocations per LIR is ~2.62 for pre-last /8 addresses. Over all allocations, the numbers are 24416 allocations and 10134 LIRs. I.e. the last /8 policy has dramatically increased the number of LIRs with a single allocation. Possibly this is related to lack of PI space. RIPE has allocated 8069 ipv6 prefixes to 7849 LIRs, i.e. an allocation rate of 1.02. This includes last /8 assignments from RIPE's silly policy of requiring an ipv6 allocation for a last /8 assignment. This indicates that virtually all LIRs are staying within the bounds of their original allocations. This will reduce future pressure on the number of prefixes in the dfz. 2. in future: there are 10398 LIRs listed in alloclist. Of these, 7849 or almost exactly 75% of LIRs already have IPv6 allocations. So assuming that all RIPE LIRs will have an ipv6 allocation in future, that's growth from 8069 to ~10700 + one for each new LIR. 3. further deaggregation of the ipv4 dfz will be driven by the market economics of address holders splitting up their net blocks. 4. down the road, if we can get RIPE to stop its silly policy of requiring an ipv6 allocation in order to get an ipv4 allocation from the last /8, this will further reduce pressure on the overall number of allocations, which leads to: > maybe if we start filtering now. but we know how well that went in ipv4 > when their suits called our suits and said "we pay you to let us contact > . The baseline for starting to deaggregate will be much lower for ipv6 and there will be much less pressure in future to deaggregate. I haven't looked at the other RIR figures. No doubt they differ in numbers, but my hunch is that they tell a similar story. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [v6ops] Deaggregation data
>> in the long run, why will v6 not suffer the > reasons goes here> same deaggregation which is about half of the v4 >> routing table? > I see no reason why it will be fundamentally different unless sites > start using the multi-prefix model of addressing, which would change > the game by allowing a site to be in multiple aggregates > simultaneously. and deaggregate them all :( > Alternatively we could abolish capitalism. no, just capitalization randy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [v6ops] Deaggregation data
On 18/10/2014 05:58, Randy Bush wrote: > [ not pickin' on you, nick ] > > trying to find protein in this whole thread. > > in the long run, why will v6 not suffer the reasons goes here> same deaggregation which is about half of the v4 > routing table? I see no reason why it will be fundamentally different unless sites start using the multi-prefix model of addressing, which would change the game by allowing a site to be in multiple aggregates simultaneously. I don't know exactly what impact that would have, but it would change the game. Alternatively we could abolish capitalism. Brian > > maybe if we start filtering now. but we know how well that went in ipv4 > when their suits called our suits and said "we pay you to let us contact > . > > 96 more bits, no magic (and 64 of those bits are allocated to relative > vacuum) > > randy > > ___ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [v6ops] Deaggregation data (was: Deaggregation by large organizations)
[ not pickin' on you, nick ] trying to find protein in this whole thread. in the long run, why will v6 not suffer the same deaggregation which is about half of the v4 routing table? maybe if we start filtering now. but we know how well that went in ipv4 when their suits called our suits and said "we pay you to let us contact . 96 more bits, no magic (and 64 of those bits are allocated to relative vacuum) randy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [v6ops] Deaggregation data (was: Deaggregation by large organizations)
Hello Nick and Iljitsch, fairly stable baseline of 20-30%, which may be acceptable if it stays there. Although peaks of 70% (is the 100% a graph problem?) seem to be a reason _for_ filtering. Now what I'm wondering (1) is there a need to carry all the deaggregates? Because if you are far enough away they may "look the same as the aggregate". To use Iljitsch' example ... > I know this is controversial. "Topology ain't geography". Actually, most of > the time there is a significant correlation. If all German cities inject a > more specific, do you really need to hear those in Tokyo or Seattle? Just > send the traffic to Europe as per the aggregate and let them figure it out > there. ... it's likely that for an US ISP X, peering with European ISPs Y and Z who carry the various deaggregate plus aggregate from Germany, all the European prefixes have this peering router as next hop (let's say we have next-hop-self). What about BGP on this peering router doing some auto-aggregation in such a case? Has this been discussed? It would avoid geographic communities and would simply follow the BGP topology: if the deaggregates result in the same forwarding information than the aggregate just keep the aggregate. Your routing table would have deaggregates for your own region but only aggregates for the other, more distant regions. (2) the problem of ever-growing routing tables and de-aggregation is not new. After so many years I'm wondering if the answer is that this cannot be solved with BGP/routing alone (?) Otherwise you would have found a solution meanwhile :-) And we have the - understandable and growing - needs of Enterprises, who de-aggregate their PA addresses when they are LIR, or request PI addresses per location. Combining this, should the de-aggregation step not be done with a different technology? LISP comes to my mind (biased, as I'm working on it) or in general a "de-aggregation overlay". The overlay would need gateways to the BGP world and would announce one aggregate prefix only while the de-aggregate prefixes would be limited to the particular Enterprise overlay network and would not show up in BGP. Regards, Marc On Thu, 16 Oct 2014 22:16:09 +0100, Nick Hilliard wrote: > On 16/10/2014 16:47, Iljitsch van Beijnum wrote: >> Growth in IPv6 more specifics was 57% last year... > > Here's a graph which shows the percentage of more-specifics between 2003 > and today from Geoff Huston's web site: > > http://goo.gl/QA0xud > > Eyeballing the graph, it's not clear where the figure of 57% came from. In > terms of trajectories, there doesn't seem to be a major problem either. > > Nick > > ___ > v6ops mailing list > v6...@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [v6ops] Deaggregation data (was: Deaggregation by large organizations)
On 17 Oct 2014, at 11:11, Marc Binderberger wrote: >> If all German cities inject a >> more specific, do you really need to hear those in Tokyo or Seattle? Just >> send the traffic to Europe as per the aggregate and let them figure it out >> there. > ... it's likely that for an US ISP X, peering with European ISPs Y and Z who > carry the various deaggregate plus aggregate from Germany, all the European > prefixes have this peering router as next hop (let's say we have > next-hop-self). > What about BGP on this peering router doing some auto-aggregation in such a > case? Has this been discussed? It would avoid geographic communities and > would simply follow the BGP topology: if the deaggregates result in the same > forwarding information than the aggregate just keep the aggregate. Yes, this would be another way to address the issue. However, this introduces a new complication: the presence of prefix Y in the table depends on the presence of prefix X. Currently, that's taboo in BGP. Note that filtering according to geographic communities could be done within an AS, removing the need for inter-AS coordination (beyond propagating the communities). So for instance a network that spans the US could carry European more specifics on the east coast and Asian more specifics on the west coast, if they feel that having both sets of more specifics everywhere would inflate their routing tables too much. > (2) the problem of ever-growing routing tables and de-aggregation is not new. > After so many years I'm wondering if the answer is that this cannot be solved > with BGP/routing alone Look at the work in the IRTF routing research group. There are possibilities to address this, but so far there's always been significant resistance against the tradeoffs such solutions would require. Iljitsch ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [v6ops] Deaggregation data (was: Deaggregation by large organizations)
On 16/10/2014 16:47, Iljitsch van Beijnum wrote: > Growth in IPv6 more specifics was 57% last year... Here's a graph which shows the percentage of more-specifics between 2003 and today from Geoff Huston's web site: http://goo.gl/QA0xud Eyeballing the graph, it's not clear where the figure of 57% came from. In terms of trajectories, there doesn't seem to be a major problem either. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
