[ppml] 2005-1 status

Scott Leibrand sleibrand at internap.com
Tue Jan 24 18:13:54 EST 2006


Bill,

I think we do need to consider alternate routing methods and network
technologies, but I think that they need to developed in the appropriate
forum (IETF)  and implemented by the appropriate folks (network
operators).  I think we need to make sure that ARIN policy supports the
existing network technologies, without inhibiting future innovation.  To
that end, I think that IPv6 PI space is necessary for the same folks that
need IPv4 PI space (so they can migrate from IPv4 to IPv6 with minimal
changes to their network), but that non-PI multihoming techniques
(advertising PA space into BGP, using shim6, or any other new multihoming
method) should be preferred for folks without a compelling need for
provider independent addresses.  IMO that compelling need is directly
related to the difficulty of renumbering when changing providers, which is
large for the types of organizations that currently get IPv4 PI space, and
small for most of the folks who don't.

-Scott

On 01/24/06 at 5:18pm -0600, Bill Darte <billd at cait.wustl.edu> wrote:

>
>
> We should at least learn some lessons from previous routing scalability
> problems.  Personally, I do not believe the routing table growth problem
> will ever be solved until we separate the routing identifier from the
> end
> system identifier.  However, until that is done, we have to look at IPv6
> as it stands.
>
>
> Owen, so OK the conversation continues to be about changing address policy
> and shim6 and deagregations and .....
>
> Why is GBP sacrosanct?  Is there no better method of routing large scale
> networks?  You mention a technique above.  Is this a legitimate pursuit?
> Are there others?  Does the problem we keep arguing about need to be solved
> with tweaks? Seems everything  is about preserving the BGP routing
> tables....isn't there a routing fix?
>
> bd
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml
>



More information about the ARIN-PPML mailing list