Re: [v6ops] [GROW] Deaggregation by large organizations

[Christopher Morrow <[e-mail]>]

On Thu, Oct 16, 2014 at 5:40 AM, Iljitsch van Beijnum
<[e-mail]> wrote:
> On 16 Oct 2014, at 0:04, Christopher Morrow <[e-mail]> wrote:
>
>>> This practice, especially if/when it becomes more common, presents two challenges:
>
>>> 1. Large numbers of prefixes may show up in the global routing table. For instance, there is a number plan for all of the German government, which could potentially inject more than 5000 municipality prefixes into the global IPv6 routing table.
>
>> ok <1% growth.
>
> What do you mean?

5000 is less than 1% of 540k... (I think, math is hard and all that business)
for the (since someone else shot me a note behind the scenes about
this as well) forseable future we'll have v4 + v6 to deal with in a
DFZ device, so call it even at 540k routes today in the table, your 5k
extra is less than 1% of that.

>>> Ideally, a set of best practices would be developed that strike a good balance between the needs of large organizations and the needs of the global routing system, and allow everyone to predict the consequences of different kinds of behavior and thus avoid unpleasant surprises.
>
>> i feel like we sort of have that already, or we know how the global
>> table works and people live within those constraints.
>
> I've only heard from a few people who do this / want to do this so far, but from what I hear they really want some clarity in this area. Spending a lot of time and money to set all of this up and then discovering your prefixes are filtered is rather suboptimal.
>

So, some folk thought: "Hey, not announcing my aggregate and not
providing connectivity between the aggregate announcement and the
little islands I created is a grand plan!" and were surprised when
things went badly...

Do you want a document that says:
  "Sure, announce your aggregate as a bunch of de-aggs, and be sure
there's a fall back ASIDE FROM ::/0 which has reachability to your
islands, if you want to be sure to not run afoul of random isp route
filtering."