[RRG] Re: PI as a non-requirement

[RJ Atkinson <rja@extremenetworks.com>]

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
rja@extremenetworks.com




--
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