Subject: [RRG] Trying to find a path forwards

From: Randall Atkinson <[email-masked]>
Date: Wed, 26 Mar 2008 02:14:47 -0700

Earlier, Dino wrote:
% So if you are using my argument about routers,
% then it is even more so with hosts.

The main point was that if the RG lets itself wedge on contrived
examples, then the RG can't make any progress at all here
and might as well go home now.

It is highly unlikely that this RG will be able to cause any
architectural change to the deployed IPv4 Internet.  There are
too many of everything (routers, hosts, embedded systems of
various sorts), and too much entropy in the IPv4 routing allocations
(probably more PI than PA, though I haven't counted recently)
to really make a substantial architectural change.  Sundry hacks
might or might not be deployable, but the kinds of architectural
change indicated in the RG charter are unlikly to happen for the
IPv4 Internet (and are certainly very hard in absolute terms).

By contrast, the IPv6 Internet still has relatively limited deployment
and relatively little routing allocation entropy.  The overwhelming
majority of IPv6 hosts and routers are still young enough that
upgrading either or both is not impractical.  Further, it is still possible,
just, that if the RG were to focus and execute on its charter,
and the IETF then ran with the input in a focused way, that some
meaningful architectural change to the IPv6 world could happen
BEFORE most of the Internet starts using IPv6 in a production way
(mindful, for example, of the Comcast presentations about the need
for IPv4::IPv6 NAT so that IPv6 only users can access IPv4 only content).
I'm not sure, perhaps some consider the SHIM6 work to be sufficient
in this regard, but clearly many do not consider the SHIM6 work
to be a solution to these issues.  Presumably the powers that
wrote the current RG charter do not perceive SHIM6 as a solution
to the concerns listed in the charter.

Again, if we look at the charter, this is chartered as a research
group, not an engineering group, and definitely not to work on
standards (as IRTF is never permitted to develop standards;
IETF is the place for Internet standards).

Cheers,

Ran

--
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: Scott Brim <[email-masked]>
Date: Fri, 28 Mar 2008 10:11:23 -0400

Ran, are you assuming an architectural change will require host
changes?  If not, I don't see why this matters.  The "jack-up"
approach relieves the need for big changes to IP.

---

From: Randall Atkinson <[email-masked]>
Date: Fri, 28 Mar 2008 08:18:38 -0700

Scott,

  The distinction I would draw relative to my earlier note is
between an "architectural change" and something that is
an "engineering change" to work around limitations in the
architecture (without actually changing the architecture).

Cheers,

Ran

[1] Some engineering changes that could be imagined
     might well be cute and or interesting, but that doesn't
     transform an engineering change into an architectural
     change.

[2] Folks need not spin up to defend one concept or another;
     I'm deliberately not talking about any specific proposal
     as I make the comments. Instead, I'm talking about the
     difficulty in making any significant *architectural* change
     to the trillions of deployed IPv4 systems, applications,
     and what not.  The comparatively tiny deployed base of IPv6
     simply makes it easier (due to size if nothing else) to make
     meaningful *architectural* changes to IPv6, even at this date.