[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Consensus? End-user networks need their own portable address space
- To: "Routing Research Group" <rrg@psg.com>
- Subject: Re: [RRG] Consensus? End-user networks need their own portable address space
- From: "William Herrin" <bill@herrin.us>
- Date: Mon, 26 May 2008 21:07:50 -0400
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ZZa3lqd2hHnd0V41GsxAhG/2sLIuCX1HmEpwQsZHvoV+78Oq4B5x+1iQMHubZmTuo/GbRZYt6WiomqSAo4w85DrZc3KccneJNLNQlhjikq08Ppg/nTwz3xq7SBMPLT7vfujpoQ/jVHj8G8Ifmi3R6dDnrNWCuH2Jpp3GrVhl0D8=
- In-reply-to: <483932D3.6040203@firstpr.com.au>
- References: <483932D3.6040203@firstpr.com.au>
On Sun, May 25, 2008 at 5:35 AM, Robin Whittle <rw@firstpr.com.au> wrote:
> Can we form rough consensus on this?
>
> Short version:
>
> End-user networks need their own portable address space.
Concur but I want to explicitly state the assumption:
[In any complex internet in which the host network address is not
strictly ephemeral,] end-user networks need their own portable address
space.
In theory, we could redesign IP from the ground up so that the
hostname was king and the network addresses assigned to a particular
machine could change at any time without disrupting communications. In
practice, we're not going to and if we were going to it would be far
beyond the scope of this working group. This leaves us at your
conclusion.
On Sun, May 25, 2008 at 7:55 AM, Randall Atkinson
<rja@extremenetworks.com> wrote:
> Users care greatly about capabilities (e.g. ability to multi-home
> for improved resilience/availability, ability to change the set of
> contracted upstream providers to reduce communications costs,
> traffic engineering, mobility).
>
> Users do NOT generally believe they want or need "portable
> address space" -- except as an engineering mechanism to
> achieve the other higher-level capabilities.
Users care about capabilities. The only engineering mechanism which
has ever been found that implements the capabilities you listed to the
consistent satisfaction of the users is providing them with their own
portable address space.
If A=B and B=C then A=C.
I'm dealing with this at work now, getting ready to dump yet another
/24 into the core because it's not practical for the one-way
transmitters sending the system data packets to determine where the
listener currently is.
I'll tell you straight up: if you build a new system that can't scale
to deliver portable addresses to all the end users that want them,
you're just wasting everybody's time. Do yourself a favor and treat it
as a requirement, whether you believe it will turn out to be or not.
On Sun, May 25, 2008 at 10:12 PM, Brian E Carpenter
<brian.e.carpenter@gmail.com> wrote:
> On 2008-05-26 07:56, Tony Li wrote:
>> If we provide solutions that give end-users the functionality without that
>> particular mechanism, I can't rationally say that there is a _need_.
>
> Exactly. IPv6 was designed to remove the _need_, although there's no
> doubt that most IT departments around the world haven't understood
> this.
Yes, it was indeed an IPv6 design goal. As discussed on essentially
all of the RIR policy lists, that missed goal has been one of IPv6's
more egregious failures. It's not that the IT departments don't
understand, its that regardless of its goals, IPv6 just doesn't
accomplish that job, not even in an ideal world.
This is not the proper forum, so I'll leave it there but if you really
want to hear the litany of why IPv6 makes the demand for PI space
worse instead of better, feel free to contact me offlist.
Regards,
Bill Herrin
--
William D. Herrin ................ herrin@dirtside.com bill@herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg