[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GLOBAL-V6]IPv6 Allocation Policy
"Craig A. Huegen" wrote:
>
> On Thu, 15 May 2003, Brian E Carpenter wrote:
>
> > "Craig A. Huegen" wrote:
> > ...
> > > The challenge: how to define a "large multi-national end-user" such that
> > > it would embody the spirit of what we're trying to accomplish.
> >
> > What we're trying to accomplish, presumably, is keeping the size of
> > the default BGP4+ table under control while allowing large multinationals
> > to be connected at many points to multiple ISPs using today's technology.
> >
> > However, I suspect that any attempt to define "large multinational"
> > precisely is going to be hard. It would be a brave person who
> > defines N and M in "has physical sites in at least N countries,
> > and is connected worldwide to at least M different ISPs."
>
> That's precisely why I was a coward. However, I'm not sure that N
> countries is a real factor that should be considered; really, I think the
> factors are a) number of segments/subnets, and b) number of ISP's
> contributing a prefix to the end user.
>
> I think the cleanest solution is finding some way to use the existing
> policy but slightly amended for end-user. Let me throw what I would
> consider reasonable: end-user networks with more than, say, 1000 segments
> and 2 discrete ISP's?
I can live with that, but if my employer's network had, say, 999
segments I might be objecting violently :-)
>
> On top of that, I do have one other concern... how does an end-user
> network obtain address space that would be routable when divided into the
> separate geographic regions? For example, if I want address space that I
> can divide into chunks, each announced from a different Internet access
> point, do I need to ask for a /32 for each of the routing points or should
> the RIR's be advising ISP's that they should do filtering, if necessary,
> at minimum_allocation + 4 bits, or something like that? I realize the
> RIR's don't want to guarantee routability, but they really should take it
> into consideration.
I think that is something we can't fix at the allocation policy level.
Megacorps will do what they do today, until the IETF offers a viable
multihoming solution. And that is being vigorously debated on the
relevant IETF list.
Briam