Re: [v6ops] Discussion focus: draft-ietf-v6ops-ipv6rtr-reqs

[<[e-mail]>]

> That's for them to say what their motivation is. But Comcast and LinkedIn are
> both known to be at the forefront of IPv6 deployment. I wouldn't classify
> LinkedIn as an ISP of any sort or a core/transit network provider or an IXC. If

I would classify LinkedIn as a content provider -- it's a different sort of network, but it's not "enterprise" (although, honestly, I really dislike the entire "enterprise/provider" divide -- it generally just muddies the water, and I find it adds almost no useful information in any conversation I've been involved in for the last 3-4 years). 

> LinkedIn or Comcast thinks there is a need for requirements for data center
> network routers, that would be interesting to know. Most major data center
> operators I know have gone to using SDN (with open source router software
> on commodity hardware). 

There is some confusion between "SDN" and "disaggregated" in the air around the networking world. We need to clarify these somewhat. SDN has a specific meaning: centralizing the discovery of reachable destinations and topology, and centralizing the calculation of loop free paths through the network, in whole or in part. White box + some mixture of sourced and open source are not SDN. Most large scale data center fabrics are disaggregated, and most have some sort of SDN component (openfabric, which is what LinkedIn is working on, is no exception here). But none of this seems to have anything to with IPv6. 

> have no impact on use of 6rd in legacy DSL access). I have not yet noticed IPv6
> in the corporate (enterprise) network that I attach to for work. I've also heard
> from some people who work with enterprise customers that adoption among
> those customers is a painfully slow crawl.

This brings me to two points...

First, folks who run their network primarily on vendor driven gear and architectures are struggling to consume IPv6. This document might be helpful for them.

Second, the point was not to address any specific segment of any market, but rather to provide a helpful review of how the architecture has changed, put some "lessons learned" out there, and provide a helpful list of "if you are a vendor, and you are building software that purports to route IPv6 packets, these are the things you should really think about including."

Essentially, there are two schools of thought I'm seeing in discussing this document:

The first school of thought says "every IPv6 deployment, and every piece of software designed for IPv6, is a unique snowflake; there are no common features or requirements we can agree on; people just need to get with the program and know what they are doing -- and if they don't, too bad for them (they need to rethink their business strategy)." 

The second school of thought says, "when I buy a router that claims to run IPv6, I want to be fairly certain it has a base set of features. I don't expect them to be turned on for me, but I don't want to find that I need them in a couple of years, and discover they are not there. It would be nice to have a list of what the community thinks this base useful feature set is, because I’m not perfect, and I can't think of everything, nor does my experience rise to the level of the entire community's experience."

It could be that we are, in fact, seeing slower adoption of IPv6 because we seem to have adopted the first school of thought, rather than the second.

😊 /r