[ppml] 2005-1 status

[Scott Leibrand]

Owen,

Do you attend IETF?  It seems to me that's the place to push for an
improved routing paradigm and a redesign of the routing system.

I'll be at my first IETF in Dallas in March.  If you'll be attending, let
me know.  I'd love to meet up with folks with good ideas on how to improve
the Internet, and start actively participating in some working groups.

Until someone finishes paving the road ahead and builds a bridge across
the ravine in the distance, I don't think it's wise to take our foot off
the brakes.  We needn't stop yet, and I'd love to be able to speed up, but
I don't think it's safe to do so just yet.

-Scott

On 02/01/06 at 10:34pm -0800, Owen DeLong <owen at delong.com> wrote:

>
>
> --On February 1, 2006 9:35:16 PM -0500 Scott Leibrand
> <sleibrand at internap.com> wrote:
>
> > George,
> >
> > I think we all agree that enterprises need to be able to multihome, switch
> > ISPs, and traffic engineer.  But the devil is in the details, i.e. how.
> > It sounds like you represent a large network that would qualify for IPv4
> > PI space, and for whom PA space is unreasonable because of the renumbering
> > difficulty.  So I wanted to get your opinion on the point I've been trying
> > to introduce into the discussion: at what point along the spectrum from a
> > home user to a large multinational corporation does PI space become the
> > best (or only) option for effective multihoming?
> >
> Scott,
>
> With all due respect, I think you are asking the wrong question.  That
> question boils down to how can we optimize who we give full citizenship
> in the internet to and who we treat as second class citizens.  I think
> instead, we should be asking "How do we accommodate everyone who needs
> PA space?"  Todays routing paradigm will not do it.  We know that.
> As such, I think the question then shifts to "How long should we continue
> to accept a routing paradigm which is known not to meet the needs
> of all of the constituents of the internet?  How hard should we work
> and how many entities are we willing to penalize in order to preserve
> the status quo?"
>
> > I know a home user doesn't need PI space: an IPv6 prefix from each of his
> > ISPs (or his and his neighbors) would suffice.  But does a small business
> > with a single location need PI space to multihome?  What about about a
> > larger business with a hundred employees and a branch office or two?
> >
> How do you know this?  Granted, I agree that the home user that needs
> this today is few and far between.  However, as more and more people
> and families become generators and not just consumers of content, I
> believe this will change in the long run.
>
> Certainly there are many small businesses with single locations that may
> need PI space to multihome effectively.  Some may need it even if they
> are not multihomed in order to accommodate the ability to switch providers
> without having to address configurations an a vast number of devices they
> do not control.  However, most such businesses are multihomed today,
> so, I can live with multihoming as a base threshold for now.
>
> Certainly, the larger the organization gets, the higher the percentage
> you will find needing PI space today.
>
> > As I've stated before, I really think we need to set up the policy such
> > that only the people for whom PI space is the only reasonable option will
> > go that route.  If we give PI space out to anyone with two ISPs, I'm
> > pretty sure we're cause a marked increase in routing table growth over
> > what we've seen with IPv4.
> >
> That may be true.  My question is: "Should we continue to penalize the
> end users in order to prevent this, or, should we instead start insisting
> on an improved routing paradigm that takes this need into account."
>
> I realize ARIN can't redesign the routing system, but, we can decide
> whether we want to base policy on preservation of the status quo, or,
> instead on the needs of all of our constituencies.
>
> Owen
>
> --
> If this message was not signed with gpg key 0FE2AA3D, it's probably
> a forgery.
>