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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On May 31, 2013, at 8:23 PM, Randy Bush <randy@xxxxxxx> 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.










[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]