Subject: [RRG] PI as a non-requirement

From: RJ Atkinson <[email-masked]>
Date: Wed, 20 Aug 2008 06:53:07 -0400

(CAUTION:  Please read this very closely before having
an emotional meltdown, for the point of this note might
be too subtle to catch at first glance. :-)

- I really don't think that PI allocations are a requirement.

- PI allocations are one possible mechanism to meet a
   different requirement.

The underlying requirement is:

	The 'pain and cost of renumbering' when multiplied
  	by the likely frequency of renumbering needs to be
	tolerable.

PI space is one mechanism to get that pain and cost down to
levels acceptable to many sites, but it might not be the only
way to get pain and cost down to those levels.  We ought not
be closing the door on alternative approaches.  Instead, we
ought to be encouraging folks to study and investigate ideas
that might lead to other alternative approaches.

Indeed, I can imagine that some of those alternatives might be
*lower* cost and *lower* pain than PI space -- particularly
given the annual "address leasing" costs associated with
getting PI space from a registry.[1]

So PI is one possible mechanism, and maybe the only one that
some folks can imagine.

However, the *requirement* is to have a sufficiently low
cost and pain associated with renumbering at whatever
renumbering frequency is needed.

Cheers,

Ran
[email-masked]

[1] There is an opportunity for the IPv6 community to step
up to the batter's box here.  So far, IPv6 renumbering,
particularly for routers within a given site, can be pretty
painful.  Renumbering for hosts is a whole lot less painful
than in IPv4, given both DHCP and Stateless Autoconfiguration.

--
to unsubscribe send a message to [email-masked] 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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Aug 2008 13:43:52 +0200

Ran,

I like how you did not separate service providers from large 
enterprises.  That can be taken further.  I would characterize our 
preferences differently.  All other things being equal, we all 
(enterprise, SP, etc) have the following preferences:

   1. Don't renumber at all, and incur no costs.
   2. Renumber exactly one more time, and incur a one time charge.
   3. Invest in tools and processes that make renumbering easier, and
      incur those charges and whatever associated with the recurring event.

Let's talk about (2) for just a minute more.  Many organizational IT 
managers believe that there is just such a renumbering in their future 
and it is IPv6.  Hence any solution that *requires* a site to renumber 
may well bind itself to that event. *Worse* (but far less likely), if IT 
managers as a whole do believe that there is some new routing 
architecture down the road that will solve problems relevant to their 
business and require renumbering, they may further delay their own 
migration to IPv6.

Your email was more about (3), only we haven't really discussed who pays 
for it.  In the end the end user will pay, and the costs are not small, 
and neither the tools are processes are simple.[1]  The question is 
simply which will cost more, and will those costs be visible in some 
fashion to those people.  CIDR was implemented and deployed with the 
tacit approval of end user organizations because nobody saw an 
alternative, even though we (at the time) understood that there would be 
costs associated with renumbering (PIER, et. al).  If there is an 
alternative and it is visible, and the costs are clear, then the end 
users will have more of a say this time around.

This is not to say that one should oppose (3).  Renumbering occurs for 
many different reasons, not all of which have to do with this argument 
(I'd argue in fact that most don't).  Rather we should all probably 
pursue (1), (2), and (3).

Finally, as I have mentioned previously, quite a lot of work has already 
gone into looking at the renumbering problem for IPv6.  Again, please 
see RFC 4192.  Beyond that perhaps it would be useful for people to 
carefully listen to what Tim Chown has to say, because he did EU-funded 
work on this very subject.[2]

Eliot

[1]  A nod to Bill Manning, who desired a world whereby one could 
renumber large swathes of network in five minutes.  It's a great ideal 
we should STILL continue to pursue.
[2] See http://www.6net.org/publications/deliverables/D3.6.1.pdf and 
http://www.6net.org/publications/deliverables/D3.6.2.pdf.  This work was 
jointly funded by the EU and Cisco.  See also 
http://www.mail-archive.com/[email-masked]/msg07648.html and related 
messages.

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 20 Aug 2008 08:22:37 -0400

Eliot,

   I disagree with some of the words you used and the way
some things were expressed.  I suspect that the differences
in actual viewpoint might be smaller than they seem at first
glance. :-)

% 1) Don't renumber at all, and incur no costs.

There are always costs.  It is important that one
understand what costs one is already incurring,
so that one can fully understand the economic tradeoffs
that are being made (whether consciously or not).

For IPv6, any form of address space is leased from the
registries.  That is a recurring cost, not a one-time cost,
to whichever organisation leased the address space.

For IPv4, many many chunks of address space are on the same
lease model.  For IPv4, as "not yet allocated global unicast"
space diminishes, the opportunity cost of all forms of IPv4
global unicast address space rises.

Moreover, IP networks of any non-trivial size have renumbering
events on a regular basis.  For example, universities renumber
chunks of their internal network regularly as academic
departments or other offices are shuffled from one building
to another, or because of changes to the university's internal
backbone.  Site-wide renumbering events are more painful than
smaller events, but the pain increase is proportional to the
size of the renumbering.

% 2) Renumber exactly one more time, and incur a one time charge.

This is also a fallacy, for the same reasons as (1) above.

Your other text suggested some view this as the "add IPv6
support" or "migrate to IPv6" scenario -- however IPv6 address
space is leased -- with a recurring charge, not a one time
charge.  So anyone thinking that adding IPv6 PI space is a
"one time charge" hasn't fully investigated the full costs
(including membership fees et alia) that are associated
with leasing IPv6 (PA or PI) address space.

In the case of PA space, the cost is incurred by an upstream
and that upstream can spread those costs across a number of
customers (lowering the effective cost for a given customer).
Generally, that cost is implicit in the existing service
pricing.  That same kind of cost spreading doesn't work for
PI space.

% 3) Invest in tools and processes that make renumbering easier,
%    and incur those charges associated...

and later on you said this:

% In the end the end user will pay, and the costs are not small,
% and neither the tools are processes are simple.

My postulate is that the commercial world (and separately the IETF
standards world) can do a lot to build-in support for renumbering
that is wildly less costly/painful than today.  Some might be
sceptical, but the community ought not close the door and totally
preclude someone from inventing some useful automation here.

That renumbering technology would be useful not just for site-wide
renumbering events, but would also be useful (probably even more
useful) for the smaller partial renumbering events that occur
regularly today (and in the past) for in IP networks of any size.

We don't know that the "costs are not small" for all time in the
future.  That is not knowable.  Similarly, we cannot know that
"neither the tools or processes are simple".  What we know is
that some folks think that the currently widely known approaches
are too expensive/painful.

My note was pretty carefully phrased.  My point is that we
ought to persue new/innovative approaches to renumbering
precisely because clever folks are likely to invent or discover
new (possibly radically new) approaches that could well be
MUCH lower pain and also lower cost than anything widely
known about today.

Bottom line is that I stand by the conclusion of my previous
note:

	The pain and cost of renumbering, when multiplied
	by the likely frequency of renumbering, needs to be
	tolerable.

PI is a mechanism that folks see right now for dealing with
the above requirement, but PI is not itself the requirement.

One hopes the community can do better now or in future.  We
ought not close the door by confusing a mechanism to meet
a requirement with the requirement itself.

Yours,

Ran
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Aug 2008 16:36:48 +0200

Ran,

I guess what it boils down to is this:  I don't think this group should 
count on innovations in renumbering unless we ourselves are willing to 
roll up our sleeves and do some of the work in provisioning systems and 
standards.  Quite frankly I think that's a tall order and some of that 
work needs to be done by others (like the Tucows of the world).

Perhaps one good outcome would be some outreach to those folks.

Eliot

---

From: Stephen Sprunk <[email-masked]>
Date: Sun, 31 Aug 2008 11:45:53 -0500

RJ Atkinson wrote:
> PI space is one mechanism to get that pain and cost down to levels 
> acceptable to many sites, but it might not be the only way to get pain 
> and cost down to those levels.  We ought not be closing the door on 
> alternative approaches.  Instead, we ought to be encouraging folks to 
> study and investigate ideas that might lead to other alternative 
> approaches.

I agree that PI is not an actual requirement, but so far it is the only 
model which has been shown to meet the true requirements.  I'm open to 
other ideas, if they present themselves in a timely fashion.

> Indeed, I can imagine that some of those alternatives might be *lower* 
> cost and *lower* pain than PI space -- particularly given the annual 
> "address leasing" costs associated with getting PI space from a 
> registry.[1]

I don't see how any renumbering system, unless it was 100% automated, 
could beat PI space on cost.  In the ARIN region, the annual "leasing" 
costs are currently $100 for all direct IPv4, IPv6, and ASN assignments 
to end user orgs -- one flat fee, regardless of the number or type of 
assignments.  That means a renumbering solution needs to eliminate the 
need for _all_ of those things _and_ require no more than 1-2 man-hours 
of labor per year for it to be an economic win.

I'm not saying it's impossible, but it is infeasible with the technology 
currently available or on the horizon, and IMHO by the time the IETF 
could develop something and vendors got it to market, PI in IPv6 will be 
as deeply entrenched as PI in IPv4 already is and few will have reason 
to switch.  Then again, I'm a cynic.

S

(I put "leasing" in quotes because numbers cannot be property and thus 
cannot be leased out; the fees are legally payment for the services of 
being listed in the RIR's WHOIS and rDNS.)