On Thu, Oct 16, 2014 at 5:40 AM, Iljitsch van Beijnum <[email protected]> wrote: > On 16 Oct 2014, at 0:04, Christopher Morrow <[email protected]> > 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." _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
