ietf
[Top] [All Lists]

Re: [IETF] Not Listening to the Ops Customer (was Re: Issues in wider geographic participation)

2013-05-31 20:14:06

On May 31, 2013, at 8:23 PM, Randy Bush <randy(_at_)psg(_dot_)com> 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.  
Unfortunatly
Yup, the "issue" with v4 was simply a lack of addresses -- more address bits 
was what ops wanted, this probably needed a new protocol number, but that's 
about all.

Unfortunately the was a bad case of creeping featuritis and we got:
A new, and unfortunately very complex way of resolving L2 addresses.
Magic IPSec, which then went away again.
Extension headers that make it so you cannot actually forward packets in modern 
hardware ( http://tools.ietf.org/html/draft-wkumari-long-headers-00)
SLAAC, which then required privacy addressing and then fun that that entails / 
the DHCP debacle.
RA instead of VRRP
Countless transition strategies.
The list goes on and on, but gets depressing really fast.

Operators learnt a number of lessons (the hard way) while operating IPv4 
networks that reoccured in new ways in IPv6. 
For example, operators learnt that having a large subnet behind a router makes 
the router fall over (doing all the ARP processing) during an IP scan. This is 
almost identical to the issue described in RFC 6583 ("Operational Neighbor 
Discovery Problems")

Operators learnt (a long time back) that allowing source-routing is a really 
bad idea, and so a: devices disable it by default and / or b: the standard 
templates all have "no ip source-route" (or equivalent). This is almost 
identical to the Routing Header issues in V6 (see RFC 5095 - "Deprecation of 
Type 0 Routing Headers in IPv6" )

Most operators address ptp Ethernet links with a /30 or /31 in V4. Took a long 
time to get this in V6 (RFC 6164 - "Using 127-Bit IPv6 Prefixes on Inter-Router 
Link") and it is still controversial.

We ended up in a space where perceived elegance and shiny features overshadowed 
what folk actually wanted -- 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.

Yup


at ripe/dublin, olaf gave a really nice but somewhat glib talk about
technology adoption, using dnssec and ipv6 as the positive examples.

Yes, this was a great talk -- I think that it was somewhat glib for the 
audience, but having a longer, more in depth version of it at an IETF would 
(IMO) be valuable. I think that Olaf has a few versions of that talk…. For folk 
who'd like to see the RIPE version - https://ripe66.ripe.net/archives/video/7/ 
- Innovation at the Waist


 as
some curmudgeonly schmuck pointed out at the mic, dnssec is forward
compatible and there are no alternatives, so it is being adopted despite
its complexity and warts.  ipv6 is not forward compatible, we put
unnecessary obstacles in the deployment path, and there are
alternatives.  d o o m.

if we had wanted ipng deployed, we would have done everything we could
to make it simple and easy for net-ops and end users to turn it on.
instead, we made it complex and hard and then blame everyone else for
not instantly adopting it en masse.
 the ietf did not listen to or
consider the customer.  this is fatal.  and the arrogance is taking what
is left of the e2e internet down the drain with it.


+1.
w

randy


--
Don't be impressed with unintelligible stuff said condescendingly.
    -- Radia Perlman.






<Prev in Thread] Current Thread [Next in Thread>