ietf
[Top] [All Lists]

Re: Not Listening to the Ops Customer

2013-06-01 13:52:45
Brian,

I really need to stop posting to this thread -- I have other
things to do and I don't believe the conversation is leading to
anything actionable.  Second-guessing is fairly useless at this
point and there are at least a few things that we know in
retrospect that we couldn't have known in 1993-1995.  I continue
to believe that many of the IPv6 impediments have been economic
and deployment policy issues that we did understand in 1993 but
didn't pay enough attention to, but some of the technical stuff
was, and is, more complicated.  On the technical side, I believe
that there was a general belief in 1993 that we would be able to
map out a unified, clear, transition strategy for IPv6 and give
simple advice about it.  In retrospect, that was probably
naive... and I believe that confused messages about transition,
especially to people who won't make their deployment  decisions
based on complex and subtle technical issues, have been part of
the problem.

More inline.

--On Saturday, June 01, 2013 16:35 +1200 Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:

...
It was more complicated. I was actually running a team that
ran site network ops at the time, and (since DHCP was not yet
deployable), IPv4 was then a serious nuisance to manage,
compared say to Novell Netware and, even, Appletalk. There
were good reasons we wanted stateless auto-configuration and
unlimited subnet size, to mention two IPv6 bells and whistles.
If DHCP had already been deployed, our opinion might have been
different.

Yes, as I think Vint says, it is always more complicated.  But
translating the above into the perspective of a decision-maker
who has to decide if, when, and how to deploy IPv6, those
requirements weren't very compelling.  Some of the organizations
that had the need were already running some member of the family
of LAN protocols in which every node continually broadcast its
identity and location, or were getting by with BOOTP.  Others
just didn't perceive the problem as a need rather than, at most,
an inconvenience.  IPv6 would have made things better, but
almost no one actually was going to convert to it for that
reason given the other costs of conversion.   Then given your
explanation, IETF came along with an IPv6-killer in the form of
DHCP and reduced the motivation further.   

The standardization and deployment of DHCP was entirely
reasonable.  But we knew that DHCP was coming -- RFC 1531 was
published several months before even the IPng solicitation in
RFC 1550 and the DHC WG had been around, IIR, some time longer
-- so assuming that the configuration issues were going to be a
major driver to IPv6 doesn't speak well for the IETF's ability
to think about and understand complete systems and relationships
among protocols a decade ago (I have no reason to claim we have
gotten either better or worse -- so much for cross-area review
at the systems, rather than nits, details, and religion, levels).

It turns out that as soon as you envisage a network in which
some nodes only support 32 bit addresses and other nodes can't
get a globally unique 32 bit address, you are forced into a
world of hurt that requires some combination of NAT, tunnels
and dual-stack. That is completely independent of the design of
IPng, and we knew it 1994.

Sorry, Brian.  I may just be naive, but I see a difference
between the same protocol with an extended address format and a
different protocol that coexists more or less well.   They may
be formally no different, but the transition strategy
implications are, IMO, very different in part because the former
involves only a single address space with issues accessing part
of it while the latter implies everything we have seen played
out in recent years.   In particular, one protocol with an
extended address format doesn't ever require dual stack and, for
short-form addresses, it doesn't require address translation,
just packing and unpacking.

And yes, even with a different protocol, I think rejecting the
ideas Mike O'Dell and others pushed about embedding IPv4
addresses in IPv6 ones was a significant setback from a
deployment incentives and costs standpoint.

So while your criticism is valid that we collectively came up
with too many such combinations, that collective mistake was
(IMHO) not a result of the design of IPv6 as such. It was more
caused by the design of human beings.

What you see as "design of human beings" I see as either failure
to be able to get things right the first time or two or as a
different sort of failure to understand the whole system and act
on it.  In the first case, it would imply that we didn't
understand the implications of IPv6 nearly as well as we thought
we did when we started telling people to deploy it.  In the
second... well, we have extensive debates from time to time
about the problems associated with approving competing standards
to accomplish just about the same job.  Even when we do approve
competing protocols, we usually try to insist on good
explanations of applicability.  But, unless I've missed a series
of important conversations, IPv6 conversion/ transition methods
have been largely exempt from those discussions and
requirements.  

Whatever the causes, even if they are "design of humans", the
results don't do anything positive for either the deployment of
IPv6 or the credibility of the IETF.

...
Similarly, various applications folks within the IETF have
pointed out repeatedly that any approach that assigns multiple
addresses, associated with different networks and different
policies and properties, either requires the applications to
understand those policies, properties, and associated routing
(and blows up all of the historical application-layer APIs in
the process) or requires request/response negotiation that TCP
doesn't allow for (and blows up most of the historical
application-layer APIs).  

It's true, but to avoid that, I think we'd have to abolish
cellular telecommunications, Wi-Fi, and competition between
providers.

An interesting response.  I guess I'm still naive enough to
believe in hourglasses and IP-over-<whatever> models.  Today, my
applications absolutely do not need to know anything beyond IPv4
addresses and TCP (or UDP or RTP or...) in order to use those
physical environments today.  And, as long as there are routers
in the network --routers that can be fairly straightforward for
edge networks, even multihomed ones-- the applications don't
need to know about routing and route optimization either.

One of the original promises about
IPv6 was no need for changes to TCP and consequent
transparency to most applications.  Ha!

Right, but again - only part of that is due to the change of
address size and socket API details. Most of it is due to
multiple connectivity. That was going to happen anyway.

In the last decade or so, I've set up several multiply-connected
IPv4 LANs  with load-sharing and fall over provisions for
various people/ businesses.  I may not know much (and don't),
but I know a lot more than the SOHO-provider ISPs do and are
willing to supply.  The routing setup is simple enough that even
my rather small brain (I won't even play a routing expert on TV)
could handle it and none of these sites have PI space that they
can get routed.  They do have one-one NATs facing both LANs so
the applications don't know a thing about the connectivity
setup.  The setup isn't optimal and the routing decisions aren't
either, but it works and it would take a lot to convince me that
getting from there to optimal is worth the trouble.    For IPv6,
I've either got to replicate the setup (hence one less incentive
to convert) or I've got to deal with a significantly more
complex applications setup and teach the applications to be
routing-path-sensitive (some incentives in terms of performance,
but really high cost, especially when one includes the
observation that, if something goes wrong with the connectivity
setups that are in use now, it is possible to call the relevant
ISP and whine while the more optimized setups are ones they
don't want to support except, maybe, for large customers and
specific contractual agreements.

That problem actually does scale, at least to analogues, and
turns into another example in which we have made IPv6 and IPv6
transition a much more costly undertaking than would predict to
rapid deployment without our being able to show huge advantages
to the operators (even of small edge networks) rather than
advantages to the network (some tragedy of the commons elements
there, but we knew about that problem).

I have never been convinced that "longer addresses and nothing
else" was the only viable solution for IPng, 

Don't forget, BTW, that even "just" changing address size
from 32 to 64 would have blown up almost every app written to
BSD sockets (since Real Programmers Don't Use Structures and
almost everybody used to stick addresses into uint_32).
There never was a free lunch on the table.

Absolutely.  No change involves a free lunch and any change from
something  that is perceived as working satisfactorily (or even
nearly so) is going to require either an ability to make
commandments, a way to externalize the costs, or a fairly
serious incentive structure.   That was my key point, and
Warren's, and I think Randy's.    It may be worth noting that
those conditions were very clear when IPv4 was deployed: the
advantages of moving off the NCP environment were fairly well
understood and accepted in the community, the costs for many
installations were borne by the agencies who provided
connectivity and insisted on conversion, and it was very clear
that a flag day requirement could be imposed and enforced. 

Let me stress that, unlike some others, I'm not an IPv6-hater.
I'm painfully aware that almost any engineering design could be
made to come out differently if different design constraints
were assumed or different priorities were chosen for
optimization.  I continue to hope for IPv6 deployment and try to
think about ways to help even while I'm pessimistic about the
situation we find ourselves in and the stumbling blocks we have
allowed to rest in the path (those that we have caused and those
that come from other sources).  I don't think this is "IETF
versus the Ops" either although that may be the effect:  I think
what what Randy, Warren, and others have said about those
relationship are much more about symptoms of different
interests, criteria, and cultures then they are about
intentionally bad behavior, even though getting the assumptions
and practices about those relationships wrong may aggravate the
symptoms.  

The mistake I think we made was in not adequately considering
the transition and incentive issues as a fundamental and
critical part of the design and solution space rather than,
e.g., something that could be sorted out later as long as the
protocol was ok (or nearly so).   Sadly, I'm not at all sure we
have learned that lesson.

  best,
    john