Subject: Re: Not Listening to the Ops Customer

From: Masataka Ohta <[email-masked]>
Date: Sat, 01 Jun 2013 18:51:10 +0900

Doug Barton wrote:

> Not picking on you here, in fact I'm agreeing with you regarding the 
> early days. In '94 SLAAC/RA was a good idea, and remains a good idea for 
> "dumb" devices that only need to know their network and gateway to be 
> happy.

Wrong.

Even at that time and even on small end user LANs, it is
better to let the gateway manage the address configuration
state in centralized fashion than to have, so called, SLAAC,
which is full of address configuration state, which is
maintained in fully distributed manner involving all the nodes.

						Masataka Ohta

---

From: Warren Kumari <[email-masked]>
Date: Sat, 1 Jun 2013 06:39:42 -0400

Warren Kumari
------
Please excuse typing, etc -- This was sent from a device with a tiny keyboard.

>> "dumb" devices that only need to know their network and gateway to be 

Thank you for so eloquently proving Doug's point.

W

---

From: Arturo Servin <[email-masked]>
Date: Sat, 01 Jun 2013 10:28:54 -0300

Masataka,
	
> maintained in fully distributed manner involving all the nodes.

YMMV.

	I was working on TCP/IP, Novell and AppleTalk nets in the mid 90s and
as network engineers we hated to maintain a database of static IP
addresses for users, and we loved how AT for example was totally
automatic (IPX was in the middle because we also hated the long addresses).

	But any how, I agree with Brian that it was a good idea at that time. I
was very young and naive (I am still naive) then but I remember that I
thought that it was a plus compared to v4, but probably I would the same
applauded an automatic centric IP address management (i.e. dhcp).

	In fact, as an operator I wanted a mechanism to handle IP address
easily, not to use the mac address and avoid ARP. I guess this backs
Randy's point too.

Best regards,
as

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 01 Jun 2013 23:25:25 +0900

> addresses for users,

I think you mean "a database of static IP addresses" DNS, not HOSTS.TXT.
Then, neither Novell nor AppleTalk enables it.

Today, with DNS dynamic update, you don't have to maintain the database
manually.

The difference is that DHCP with centralized state is a lot more
good at automatic maintenance of the database than so stateful
SLAAC with fully distributed state.

> and we loved how AT for example was totally

So is most NAT boxes behaving as a DHCP server.

> 	But any how, I agree with Brian that it was a good idea at that time.

Not at all.

It was merely that those who had little operational insight had
thought so.

Rest of the people developed DHCP and, now, you can see which is
better.

						Masataka Ohta

---

From: Arturo Servin <[email-masked]>
Date: Sat, 01 Jun 2013 11:57:48 -0300

No, I meant a table of static ip addresses (possibly it was in excel,
db2, or any other old database) for each host so we do not configured
the same IP to two or three different hosts. It was a nightmare.

	With IPX, AT address assignment was automatic. No DHCP in those old times.

.as

---

From: Arturo Servin <[email-masked]>
Date: Sat, 01 Jun 2013 12:02:26 -0300

Kind of.

	Those were different times. At least us we were not so preoccupied by
tracking users, accounting, etc. So a central point to record IP address
was not as important as a central port to give IP address. So both
solutions would seem useful to me at that time (as I said I was young
and naive).

	Now, it is different. DHCP it is better solution to our current needs.

Regards
as

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 02 Jun 2013 00:08:16 +0900

Arturo Servin wrote:

> the same IP to two or three different hosts.

So, it's like HOSTS.TXT.

> It was a nightmare.

Yes, it was.

> 	With IPX, AT address assignment was automatic. No DHCP in those old times.

That something was automatic only to produce useless (to me) results
does not mean it was a good idea.

						Masataka Ohta

---

From: Randy Bush <[email-masked]>
Date: Sat, 01 Jun 2013 08:09:29 -0700

> easily, not to use the mac address and avoid ARP. I guess this backs

i do not disagree with you, but ...

actually, i was taking no position on slaac vs dhcp.  my point was that
customers did take a position for historic reasons, dhcp in enterprise
and fixed on the wan, and having a religious argument with the customer
is not a smart business or design plan.

if we cared about success and the customer, we might have followed the
principle of least astonishment (pola) and given them dhcp and also have
pointed to the availability of the new wonderful washes your car
alternative which they might like to try.

randy

---

From: Warren Kumari <[email-masked]>
Date: Sat, 1 Jun 2013 11:28:31 -0400

On Jun 1, 2013, at 12:35 AM, Brian E Carpenter <[email-masked]> wrote:

> On 01/06/2013 15:00, John C Klensin wrote:
>> 
>> --On Friday, May 31, 2013 17:23 -0700 Randy Bush <[email-masked]>
>> wrote:
>> 
>>> < rant >
>>> 
>>> the sad fact is that the ietf culture is often not very good at
>>> listening to the (ops) customer.  look at the cf we have made
>>> out of ipv6.  the end user, and the op, want the absolute
>>> minimal change and cost, let me get an ipv6 allocation from
>>> the integer rental monopoly, flip a switch or two, and get 96
>>> more bits no magic.  15 years later, dhcp is still a cf, i
>>> have to run a second server (why the hell does isc not merge
>>> them?), i can not use it for finding my gateway or vrrp exit,
>>> ...  at least we got rid of the tla/nla classful insanity.  but
>>> u/g?  puhleeze.
>> 
>> Randy,
>> 
>> I suggest that characterizing that set of issues as IETF versus
>> Ops is probably not completely right either.  

> 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, it was more complicated, but the sad part is that DHCP was widely deployed in V4 long before V6 was a viable transport for real work on the Internet. Operators kept asking for DHCP and kept being slapped down by zealots who refused to listen to / consider why the Ops were asking for this.

I *really* want to make sure that my CEO always gets the same address, and want him to be assigned specific DNS servers and use a certain gateway. The folk who manage the DHCP are the "Internal Services Infrastructure Group"  (aka "The windows monkeys") and I'm sure as heck not giving them access to my router to twiddle knobs on it.  

>> For example, with
>> IPv6, the IETF has proposed multiple transition solutions with
>> no roadmap as to which one to apply under what circumstances and
>> growing evidence that some of those solutions are unworkable in
>> practice and others are incompatible with what are claimed to be
>> fundamental and important features of the Internet.  
> 
> 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.
> 

Yes, hindsight always makes things *much* clearer. It also provides a nice sandbox to stand on….

Anyway, I think that going down the path of "There are warts in V6, I want a refund!" is not helpful. What I hope we can try and focus on is how we can improve understanding of what the customer (operators, users) actually wants, how and where the protocols of the future will be used, how we can incorporate changes as we get feedback and understand new requirements, etc.

I was not intending to point fingers (although I realize I did), but rather to try show places where the protocol could have improved with a better understanding of what folk were looking for / with more operator input...

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

I'd go further -- some of the issue is (IMO) caused by the consensus driven nature of how we do things. We all have different sets of interests and different priorities. Because of a need to achieve consensus, we end in something kind of like horse-trading. We add features to appease some set of folk, and compromise on other bits to appease others. I suspect that if one or two folk had designed this, soup-to-nuts, we'd have ended up with something cleaner.
> 
>> It doesn't
>> take a skilled operations person to understand that is a
>> problem; someone with a pointy head and barely enough clue to
>> figure out what a "bit" is much less how many of them are in
>> various addresses can derive a "don't be the first person on the
>> block" or "don't migrate if you can figure out an alternative"
>> lesson from that.  
>> 
>> 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.

Not sure I agree.
Most apps on my iPhone seem to work just fine while I wander in and out of my house and move from WiFi to cellular.

As for competition between providers -- folk have been doing this with e.g BGP for years. Most CPE lets you easily swap between providers (by moving a wire :-)) and some let you share multiple by NATing (yes, I know, I know) some sessions to one and others to the other provider...

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

Yes, IP is fundamental plumbing, and folk make assumptions about how the plumbing works / take shortcuts. 
Changing fundamental plumbing is hard, and requires changes to all the fittings, valves, etc.

W

> 
>   Brian
> 
>> but I don't think
>> it requires an advanced degree in economics to understand that,
>> if the incentives to do something don't exceed the costs and
>> risks of doing it, one shouldn't expect a lot of rational folks
>> to charge off and do it.  A complex system with high deployment
>> costs and risks and a dubious set of advantages is not a story
>> that is going to sell itself.  And, again, it doesn't require a
>> sophisticated operator to figure that out.
>> 
>> None of this takes away from your rant (or Warren's).  But I
>> suggest that, on several of the dimensions you identify, the
>> operators are not being singled out for abusive treatment
>> because we don't listen to each other or elementary
>> decision-making or economic realities either... at least where
>> broad issues, rather than fine-tuning of a spec are concerned.
>> 
>>   john
>> 
>> 
>> 
>> 
> 

--
There were such things as dwarf gods. Dwarfs were not a naturally religious species, but in a world where pit props could crack without warning and pockets of fire damp could suddenly explode they'd seen the need for gods as the sort of supernatural equivalent of a hard hat. Besides, when you hit your thumb with an eight-pound hammer it's nice to be able to blaspheme. It takes a very special and straong-minded kind of atheist to jump up and down with their hand clasped under their other armpit and shout, "Oh, random-fluctuations-in-the-space-time-continuum!" or "Aaargh, primitive-and-outmoded-concept on a crutch!"
  -- Terry Pratchett

---

From: John C Klensin <[email-masked]>
Date: Sat, 01 Jun 2013 14:52:04 -0400

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
<[email-masked]> 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

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.

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

>...

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.

>> IPv6 was no need for changes to TCP and consequent
>> transparency to most applications.  Ha!
> 

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

> 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

---

From: "cb.list6" <[email-masked]>
Date: Sat, 1 Jun 2013 13:44:49 -0700

> based on complex and subtle technical issues, have been part of

I think there is something here that is interesting, and that is the
interplay between paper design, evolution, and ultimately the emergent
complex dynamical system we call the internet ... which is almost
completely zero compliant to the e2e principle.  Not that e2e is the wrong
principle, but ipv4 could not support it as of 10+ years ago. Hence, nearly
every internet node is behind a stateful device (cpe or cgn nat) or server
load balancer. There is also widespread disbelief in how dns operates in
the real world (not everyone gets the same answer).

Yet, corners of the ietf call this real world internet of middleboxes as
broken. As some of it is broken, so you have things like SPDY and
ICE/STUN/TURN/464XLAT/MAP/6RD to bust through it.  Mutation happens.

That said, the teaching moment here is look back and realize the internet
was not engineered, if was emerged.

Given that the internet is not engineered and that it is a greedy
collection of self optimizing nodes that mutate, how do we make it go fast,
bigger, better given the few levers we have.

CB

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 02 Jun 2013 06:41:19 +0900

Arturo Servin wrote:

> was not as important as a central port to give IP address.

A merit to have the central server is that you don't have to
waste time and packets to have DAD, with additional overehead
of IGMP, to confirm all the distributed nodes maintaining the
state of SLAAC consistently, that is, a new configured address
is unique.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 02 Jun 2013 07:05:58 +0900

cb.list6 wrote:

> principle, but ipv4 could not support it as of 10+ years ago.

As long as a NAT box is directly connected to the Internet
and is UPnP capable, which is the case at my home, hosts
behind it can enjoy full end to end transparency (PORT
command of FTP works), if hosts' IP and transport stack is
modified a little.

> Hence, nearly
> every internet node is behind a stateful device (cpe or cgn nat)

That is not a problem if state of the device is known to
the end, because IP and transport stack of the end
can reverse the translation.

See draft-ohta-e2e-nat-00.txt for details.

> or server

It has nothing to do with the end to end transparency.

If operators of the servers think any server is fine, it is not
a problem.

						Masataka Ohta

---

From: John Curran <[email-masked]>
Date: Sun, 2 Jun 2013 02:41:49 -0400

On Jun 1, 2013, at 2:52 PM, John C Klensin <[email-masked]> wrote:
> 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.  

John is correct in terms of belief (but perhaps a bit early on date), as 
the IPng decision was specifically predicated upon us being able to explain 
shortly thereafter "what mechanisms will be employed in the transition, how 
the transition will work, the assumptions about infrastructure deployment 
inherent in the operation of these mechanisms, and the types of functionality 
that applications developers will be able to assume as the protocol mix 
changes over time." (RFC 1752 "The Recommendation for the IP Next Generation 
Protocol", January 1995)

The fact that the fundamental architecture of IPng could be selected before
the transition strategy was settled is clear proof of the very point Randy 
was making with respect to the IETF not listening to the operations customer, 
as no one running production Internet service could have agreed to proceed 
with a new _incompatible_ version of the Internet protocol absent a well-
documented transition/interoperability strategy.  This disconnect is not 
solely the fault of the IETF, it is definitely shared with the operator 
community who have more pressing and immediate demands on their time than 
trying to cover IETF activities as risk mitigation against new developments 
which aren't likely to impact their business for years to come.  (In fact, 
it should probably be more surprising that there are any service providers 
who attempt to stay informed about IETF efforts, given the difficulty of 
covering the range of IETF activities and the very long-term timeline for 
any potential benefit from the investment.)

The reality is that there are not a lot of places where _one_ architecture
is needed; i.e. in general, it's fine to "let a hundred flowers blossom"
with a myriad of alternative working groups with vendors promoting various
competing drafts to solve a given problem. However, we can't lose sight of
the fact that there are also areas that are fundamentally architectural in
nature, with far-reaching and long-lasting impact on the Internet (e.g. the
IP protocol itself, TCP, DNS, etc.) where there truly needs to be just one
solution for any given problem space.  When dealing with such cases of the
fundamental architecture of the Internet, the IETF needs to go above and 
beyond in making sure its reaching out to the actual operator community 
and dealing with the actual problems that they face with these protocols.
I'd suggest seeking out operators with significant "skin in the game" and 
interest in joining the effort before spinning up new working groups for 
protocols in these key architectural areas.  If you can't find a service 
provider interested enough to participate, then that is likely sign that 
the work may not actually be needed...

It would also help if there was a general acceptance that the IETF should
be far more rigorous when dealing with these core protocols, and set very 
high standards before deciding to making any changes.  In the case of IPng, 
we jumped on a solution that was neither fully defined nor focused on what
operational networks actually needed; the result has been quite painful 
but hopefully will not prove fatal for the Internet in the coming years.

FYI,
/John

Disclaimers:  My views alone.  As a member of the IPng directorate at the
time, I do share in responsibility for the recommendation of IPng as the 
new Internet Protocol despite its lack of focus on actual service provider
functionality and the transition/interoperability mechanism left as an open 
work item. I believe that critical examination of the past is essential to 
improvement, and in this particular case the pain involved in reflection 
is well worth it if the IETF gains as a result.

---

From: John C Klensin <[email-masked]>
Date: Sun, 02 Jun 2013 10:15:56 -0400

--On Saturday, June 01, 2013 11:28 -0400 Warren Kumari
<[email-masked]> wrote:

>...
> I *really* want to make sure that my CEO always gets the same
> address, and want him to be assigned specific DNS servers and
> use a certain gateway. The folk who manage the DHCP are the
> "Internal Services Infrastructure Group"  (aka "The windows
> monkeys") and I'm sure as heck not giving them access to my
> router to twiddle knobs on it.  

Warren, I sympathize.   But I also note that your comment above
can be read, in more general form, as "the folks in IT are
turkeys and therefore we need to export the issues they can't be
trusted to handle well to the Internet".  That isn't a good
model, if only because it involves moving the intelligence to
the middle of the net.  

Assuming that you still work where I think you work, you've got
a significant advantage over most of the people in similar
circumstances: you have an Executive Chairman and a bunch of VPs
who actually do understand the problem with incompetent internal
IT departments and maybe even why they come out that way and
many of them are pretty accessible.  Identify the problem and
suggest a workable solution.

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

But the "knew it in 1994" part means that this is _not_
hindsight.  Several of the other comments we have made aren't
either -- they were well-understood in the community in 1994 and
then rejected or ignored for one reason or another.  One can
complain about the rejection in hindsight, but not about lack of
information.

> I'd go further -- some of the issue is (IMO) caused by the
> consensus driven nature of how we do things. We all have
> different sets of interests and different priorities. Because
> of a need to achieve consensus, we end in something kind of
> like horse-trading. We add features to appease some set of
> folk, and compromise on other bits to appease others. I
> suspect that if one or two folk had designed this,
> soup-to-nuts, we'd have ended up with something cleaner.

See my note about the nature of standards.  

    john

---

From: John Curran <[email-masked]>
Date: Sun, 2 Jun 2013 12:34:49 -0400

On Jun 2, 2013, at 10:15 AM, John C Klensin <[email-masked]> wrote:
> --On Saturday, June 01, 2013 11:28 -0400 Warren Kumari <[email-masked]> wrote:
>> ...

Indeed, it was well-understood that there needed to be some solution 
involving NAT to provide for basic interoperability (even if no one 
liked standardizing that aspect); specifically, "The IPng transition 
plan must define the procedures required to successfully implement 
the functions which vendors will be likely to include in their devices.  
This is the case even if there are good arguments to recommend against 
a particular function, header translation for example.  If products 
will exist it is better to have them interoperate than not." [RFC 1752,
Section 16.1]

The problem was that the IETF felt enormous pressure _for its own
efficiency_ to come to a decision about IPng; i.e. we did not have 
operators clamoring that they needed IPng to be decided ASAP (I'd
wager that most commercial service providers were far too busy trying 
to keep up with the epic customer demand in the early 90's to pay 
much attention to the IPv4 depletion problem which was many, many
years away...)  As you know, there were real concerns about transition
expressed by operators at the IPdecide BoF ('93 Amsterdam IETF) - 
  
 "It was stated frequently and forcibly that the transition costs 
  should be a significant factor in the selection criteria. Concerns 
  were expressed by several service providers that the developers 
  had little appreciation of the real-world networking complexities 
  that transition would force people to cope with.  If the cost of 
  transition outweighed the pain of other solutions (application 
  gateways or address translators) customers would not deploy IPng."

[ftp://ftp.ietf.org/ietf/93jul/ipdecide-minutes-93jul.txt]
(Highly recommended reading for folks who are interested in 
the history of IPv6)

In the end, the IETF decided it should take active steps toward making 
the technical decision on IPng (rather than waiting for the "marketplace" 
to decide) and that IESG would form the IPng Directorate [RFC 1719] which 
was to evaluate how long we had to IPv4 runout and develop the technical 
requirements and criteria for IPng.  Once this was completed at the end 
of 1994, there was enormous pressure to select a single IPng candidate 
protocol to work on (despite the unresolved issues regarding transition) 
so that the work of the IETF could be focused in a single effort going 
forward.  This approach might have worked out fine, but once the actual
IPng candidate decision was made, all of the prioritization on transition 
requirements dissipated as the work was shuffled off to various working 
groups in the years that followed, with the result being that the once
mandatory IPng requirement for a straightforward transition plan from 
IPv4 was never fulfilled.  

I was asked to be more specific on how to avoid such issues the future, 
so here goes:

  If multiple solutions can readily coexist, let the market decide.

  If not, define the problem from the perspective of those who must
  deploy the solution, including their inherent need for a clear and
  functional transition mechanism.

In retrospect, it's fairly obvious that there's a huge difference between
problem spaces which allow for multiple solutions (e.g. interior routing 
protocols) versus problem spaces which the IETF is aiming for only _one_ 
protocol in the final solution (e.g. IP, DNS); the process making that
type of architectural decision should probably be quite visible and rather
explicit because it comes with a huge responsibility for addressing all 
necessary transition aspects.  This responsibility for the transition 
aspects should not be set aside by the IETF for convenience or due to the 
level of effort that results, as it is the price to be paid when making
an architectural decision to have a single protocol solution for a given
problem space.

FYI,
/John

p.s. John - you made a comparison to electrical power standards with 
     respect to operator & end-user participation: I guess the parallel
     would be that the electrical equipment manufacturers (along with
     engineers from electrical production and distribution companies who 
     have the right background) may indeed make new standards without  
     end-user input, but when they do so, it is done such that end-users 
     plugging in old equipment never results in explosion and fire...  
     We now have service providers running into real challenges trying 
     to accomplish the same logical result with IPv6, which implies that
     the electrical distribution folks pay more attention to transition 
     aspects of their new standards than we do, and is actually why end-
     users and even property developers in general don't worry about 
     changes in power distribution standards. (You may have to learn 
     about them if you want take advantage of new features, but if you 
     don't care, existing practices won't blow up in your face.)

Disclaimers:  My views alone.  Your mileage may vary; feel free to use, 
              abuse, or discard these views as you desire.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 3 Jun 2013 12:32:17 +0300

Randy, Warren,

>> One (IMO) good idea that was mentioned recently (sorry, I cannot
>> remember by whom, may have been Jim Martin) was for someone from the
>> IETF to present a short summary of interesting work at NOG meetings.
> 
> this has been done many times.  imiho, it has not stirred up much useful
> interaction unless the ietfer says something really st00pid.  then it
> gets amusing.

I have found that generic "this is happening" informational is usually not so interesting. Whereas discussion on specific topics has been far more interesting… sessions that talk about some IETF WG technology, operator's problems in that area, and someone's experience in deploying the stuff are very interesting IMO.

Jari