Re: shim6 @ NANOG

["Christopher L. Morrow" <christopher.morrow () verizonbusiness com>]

(oh how I'm going to regret jumping into this conversation at point 'here'
not at the beginning :( )

On Sun, 5 Mar 2006, Iljitsch van Beijnum wrote:

> On 5-mrt-2006, at 5:48, Roland Dobbins wrote:
>
> > This fundamental misconception of the requirements of large
> > enterprise customers should be an indicator to proponents of shim6,
> > among others, that they do not have a good grasp of the day-to-day
> > operational and business realities faced by large enterprises.
> > This lack of understanding has led to such fundamental
> > misconceptions as a belief that large enterprises can accept
> > frequent renumbering within their organizations based upon changing
> > business relationships with their SPs (they cannot, see RFC 4192
> > for some of the reasons why not)
>
> The solution is routing based on geography: give every city of ~ 250k
> people a /32, and give people who multihome in or near that city a /
> 48 out of that /32. Since such a /48 will be easy to get, the global

can the v6 table/space work with 6B /48's? Assume that in the end-state
each 'person' is multi-homed: 802.11 + cell + cable + gprs. Also though a
/48 is quite large for a single person there will  be something (most
likely) to interconnect each family member in a household most likely as
well... or there might be :) who knows. Additionally, how many /32's are
there? Does scaling that to each municipality make sense? the arbitrary (I
suspect) 250k person limit will quickly devolve into 'any municipality'
with much less restriction on it.

> routing table will fill up with these /48s relatively quickly, and at
> some point it will start to look attractive to filter some of them
> out in part of an AS. This can be done without trouble by adding a
> few /32 aggregates that point towards the part of the AS where the /

For a single provider situation this might work, MIGHT. For a
multi-provider world, like the one we live in today, it seems doubtful
that this will scale... Unless we implement 'default to the left' or
something of that sort (pass default to the guy on your left, hope he
knows where west-kalamzoo's /32 is in the network)

> 48s that are filtered here are still known. Since every AS still has
> all the /48s somewhere within the AS, this works without strange
> requirements such as free transit or interconnection in every city.

I think I'm missing how this would work... if I don't have a route to you
you don't exist. I have to have a default to 'somewhere' or a route, it
seems fairly simple to me... see 'default to the left' above (also not a
good solution, but :) )

> So what do we need to get this off the ground? New allocation
> policies. As long as the number of geo PI prefixes is smaller than
> what comfortably fits inside routers that's all. If the global
> routing table continues to grow transit ASes will have to choose
> between buying more expensive routers or adding complexity by
> implementing geographic aggregation using BGP filters.

inside a single ASN aggregation may be workable. On the entire network
it's going to be much more complex :(

> Obviously strange ways of multihoming (towards ISPs on different
> continents, for instance) or strange ways of interconnecting (such as

ah, like pipex or vnsl or ... name your extra-us provider of choice. From
the 'non-NAnog' perspective, what about US carriers in ASPAC that
multihome to several pacific island nations at once?

> two European networks interconnecting in Chicago) aren't very
> compatible with geographic aggregation, but who cares about 10%
> exceptions as long as you can aggregate the other 90%. Enterprises

is it 10%? did you measure this? or did Geoff? or Randy? or KC?

> will have to choose between individual geo /48s in every location or
> becoming their own ISP with a /32 and backhaul traffic between
> locations themselves.