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

From: <[email-masked]>
Date: Fri, 2 Feb 2018 10:41:15 -0500

> b) If you can provide scoping text that defines which routers are covered,
> rather than a generalisation like "pretty much all", we could stop arguing.

I can't think of any scoping text that cannot have holes punched in it, and hence won't end up being a separate document itself. If folks could provide scoping that will hold up against various objections and corner cases, whether for the entire document or individual requirements, I'd be happy to include it.

IMHO, such text is a null set -- there are too many corner cases, etc. For instance, you cannot say "routers designed for home use do not need to follow these recommendations" -- whose home, and under what conditions (managed by a provider, by the user, etc.)? Or "routers designed to operate at the Internet core" -- too ambiguous, and it's not always true... It _might_ be possible to find some _specific_, individual, requirements on which we can get _everyone_ to agree to a scope -- but I don't see any evidence of this yet.

😊 /r

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 3 Feb 2018 00:44:23 +0900

On Sat, Feb 3, 2018 at 12:41 AM, <[email-masked]> wrote:

> I can't think of any scoping text that cannot have holes punched in it,
> and hence won't end up being a separate document itself. If folks could
> provide scoping that will hold up against various objections and corner
> cases, whether for the entire document or individual requirements, I'd be
> happy to include it.
>

But if we do not include scoping text, this document might not achieve
consensus, in which case none of the text would get published at all.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 3 Feb 2018 08:29:59 +1300

> consensus, in which case none of the text would get published at all.

Unless you reduce it to a "here are some things you might like to think
about" list.

I agree with Lorenzo. If you can't state the scope of your document,
it's pretty close to useless.

    Brian

---

From: David Farmer <[email-masked]>
Date: Fri, 2 Feb 2018 13:59:45 -0600

On Fri, Feb 2, 2018 at 9:41 AM, <[email-masked]> wrote:

> IMHO, such text is a null set -- there are too many corner cases, etc. For
> instance, you cannot say "routers designed for home use do not need to
> follow these recommendations" -- whose home, and under what conditions
> (managed by a provider, by the user, etc.)? Or "routers designed to operate
> at the Internet core" -- too ambiguous, and it's not always true... It
> _might_ be possible to find some _specific_, individual, requirements on
> which we can get _everyone_ to agree to a scope -- but I don't see any
> evidence of this yet.
>
> 😊 /r
>

What about someting like this;

The primary focus is routers for enterprise or carrier use, however most of
the features also have broad applicability to all routers.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Bob Hinden <[email-masked]>
Date: Fri, 2 Feb 2018 13:15:27 -0800

David,

> On Feb 2, 2018, at 11:59 AM, David Farmer <[email-masked]> wrote:
> 
> 
> 
> The primary focus is routers for enterprise or carrier use, however most of the features also have broad applicability to all routers.
> 

The current draft seems to me to be both very broad and specific at the same time.  For example, it doesn’t say anything about routing protocols, but then gets into lots of detail about which type of DHCPv6 and RA options to send.  Then doesn’t mention DHCPv6 prefix delegation.

It would be good to decide what the focus is, I am having difficulty telling from reading the draft.

Bob

---

From: <[email-masked]>
Date: Fri, 2 Feb 2018 18:02:05 -0500

> The primary focus is routers for enterprise or carrier use, however most of the
> features also have broad applicability to all routers.

Anyone else on list have an opinion on this wording? I'm happy enough to include whatever... I also sent out a possible text snippet before that would ask developers/manufacturers to explain which things they don't support from this. This might be useful in providing something you could look at to help you see what might be "missing," etc., when evaluating equipment.

😊 /r

---

From: <[email-masked]>
Date: Sat, 3 Feb 2018 07:30:25 -0500

> > The primary focus is routers for enterprise or carrier use, however
> > most of the features also have broad applicability to all routers.

But, having said I'm happy to include whatever -- I will point out there are lots of exceptions in this scoping. Just to name a few --

- I'm not really crazy about the "enterprise/service provider" divide, as it doesn't really describe a lot of network operators

- Given a WISP is a "service provider," and a WISP (by definition) runs a large wireless network, and there have been a lot of objections on the list about applying these requirements to edge wireless devices, I don't think this scoping will work

- Would this also cover, say, a route server at an IX? It seems it would, and yet route servers do not forward traffic, so this is another exception

- Would the routing component of a "firewall" or "load balancer," running in an "enterprise network" be considered a "router?" If so, there a number of requirements in this document do not apply

- Would a virtual router sitting in any network service be considered a "router?" If so, I can imagine a number of situations where many of the requirements here might not be necessary

I could probably give tens of more examples of exceptions to the above scoping.

IMHO, it is much safer to include "if there are exceptions, please tell me what they are" -- something like this:

==
This document describes a minimal set of features any device designed to run a control plane capable of computing loop free paths for IPv6, and forwarding IPv6 packets, is expected to support. In some cases, it might be that a device designed for a specific situation will not need a particular feature listed in this document as a SHOULD or a MUST. In these situations, the manufacturer or developer SHOULD provide a list of features described either as SHOULD SUPPORT or MUST SUPPORT to operators and consumers of the device. This will aid the operator by providing a clear list of what is, and is not, supported by the device.
==

😊 /r

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 04 Feb 2018 21:41:58 +0000

On Sat, 3 Feb 2018, 04:30 , <[email-masked]> wrote:

> This document describes a minimal set of features any device designed to
> run a control plane capable of computing loop free paths for IPv6, and
> forwarding IPv6 packets, is expected to support.
>

Sounds like that text excludes home routers and mobile hotspots, so you
likely won't get strong complaints from vendors of those devices.

It seems to me that the text also excludes devices that are primarily
intended to be MPLS routers. LSRs aren't "designed to run a control plane
capable of computing loop free paths", they're designed to switch labels. I
assume this is not what you want.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 5 Feb 2018 15:34:33 +0000

> > most of the features also have broad applicability to all routers.

I see a real need for recommendations for enterprise routers. I also believe that any attempts to broaden the scope beyond that will both slow down producing such recommendations and force the recommendations to be watered down to the point whether they are significantly less useful to enterprise networks.
Here is why I think most other router types either don't need or will ignore these recommendations:
 - CE routers are covered by RFC 7084
 - telco ISPs aren't asking for this (for their own ISP networks) and tend to use BBF documents; any who are waiting until IETF produces router requirements for them need to reconsider their strategy
 - cable ISPs aren't asking for this (for their own ISP networks) and tend to use CableLabs docs; any who are waiting until IETF produces router requirements for them need to reconsider their strategy
 - wireless ISPs aren't asking for this and tend to use 3GPP docs; any who are waiting until IETF produces router requirements for them need to reconsider their strategy
 - transit/core network providers aren't asking for this and have already got IPv6 running (and if they haven't, there's no excuse, because the equipment is there); they also don't tend to do address assignment (no hosts on those networks) so requirements for DHCPv6 and SLAAC aren't needed; a lot of this equipment is done with SDN now; this is also true of a lot of the "regional network" part of ISP networks
 - IXCs don't tend to do address assignment and seem to have IPv6 in place; any that don't have IPv6 -- it's not for lack of requirements; a lot of them have gone to SDN

As for SDN: If you think an open source project doing SDN code is missing some IPv6 functionality, it might be easier to contribute the code, rather than write an RFC and see if some random person says "OMG, the IETF is saying do this; no-one else is writing this code so I guess I better do it".

We need to get enterprises transitioning. Whatever IETF can do to help that specific audience would be appreciated.
Barbara

---

From: Fred Baker <[email-masked]>
Date: Mon, 5 Feb 2018 08:02:31 -0800

Thanks for this. It's cogent and to the point.

I do have a question. The authors are from LinkedIn and Comcast. How would you interpret that fact in the context of the facts you point out?

> On Feb 5, 2018, at 7:34 AM, STARK, BARBARA H <[email-masked]> wrote:
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 5 Feb 2018 17:10:59 +0000

> I do have a question. The authors are from LinkedIn and Comcast. How
> would you interpret that fact in the context of the facts you point out?

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 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). I don't recall having heard Comcast say they need a router requirements document to help with their access/regional network IPv6 deployment (which seems to be doing quite well). I don't know about any internal corporate networks they may have -- which I would classify as "enterprise networks".

Personally, I haven't heard any of the people working on any of my employer's access/regional/core networks asking for a new IETF router requirements document (the IPv6 metrics for wireline and wireless access are looking pretty good with non-IPv6 traffic due to hosts/wireless UEs/retail CE routers and not the network routers, and no issues in the core; router requirements would 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.

Clearly, there is a population with a need. If we focus on helping that population, it might be possible to drive results.
Barbara

> > I see a real need for recommendations for enterprise routers. I also believe
> that any attempts to broaden the scope beyond that will both slow down
> producing such recommendations and force the recommendations to be
> watered down to the point whether they are significantly less useful to
> enterprise networks.
> > - telco ISPs aren't asking for this (for their own ISP networks) and
> > tend to use BBF documents; any who are waiting until IETF produces
> > router requirements for them need to reconsider their strategy
> > - cable ISPs aren't asking for this (for their own ISP networks) and
> > tend to use CableLabs docs; any who are waiting until IETF produces
> > router requirements for them need to reconsider their strategy
> > - wireless ISPs aren't asking for this and tend to use 3GPP docs; any
> > who are waiting until IETF produces router requirements for them need
> > to reconsider their strategy
> > - transit/core network providers aren't asking for this and have
> > already got IPv6 running (and if they haven't, there's no excuse,
> > because the equipment is there); they also don't tend to do address
> > assignment (no hosts on those networks) so requirements for DHCPv6 and
> > SLAAC aren't needed; a lot of this equipment is done with SDN now;
> > this is also true of a lot of the "regional network" part of ISP
> > networks
> > - IXCs don't tend to do address assignment and seem to have IPv6 in
> > place; any that don't have IPv6 -- it's not for lack of requirements;
> > a lot of them have gone to SDN
> >
> > As for SDN: If you think an open source project doing SDN code is missing
> some IPv6 functionality, it might be easier to contribute the code, rather than
> write an RFC and see if some random person says "OMG, the IETF is saying
> do this; no-one else is writing this code so I guess I better do it".
> >
> > We need to get enterprises transitioning. Whatever IETF can do to help
> that specific audience would be appreciated.
> > Barbara
> >

---

From: Bob Hinden <[email-masked]>
Date: Mon, 5 Feb 2018 13:52:31 -0800

Barbara,

> On Feb 5, 2018, at 9:10 AM, STARK, BARBARA H <[email-masked]> wrote:
> 

I agree with what you have written.  It’s not clear to me what the need is here.  Regarding enterprise deployment, I would be surprised if the reason for slow IPv6 adoption has anything to do with the IETF writing a document describing what an IPv6 enterprise router should implement.  If someone has evidence to show it is needed, I would like to see it too.

Thanks,
Bob

---

From: <[email-masked]>
Date: Mon, 5 Feb 2018 17:45:17 -0500

> 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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 6 Feb 2018 06:34:38 +0100 (CET)

On Mon, 5 Feb 2018, [email-masked] wrote:

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

SDN means anything and nothing in todays world. So while I agree with your 
definition, that's not how it's widely accepted to be defined. There are 
multiple of the biggest network equipment vendors who also includes 
orchestration (of both network and applications) into the SDN concept.

I have seen people use the term SDN for exactly the thing you mentioned in 
the last paragraph.

So whenever you use SDN in a text, you need to define it, because it's 
been marketed to hell and back, and it now means different things to 
different people.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Tue, 6 Feb 2018 09:41:46 +0000

> On 5 Feb 2018, at 21:52, Bob Hinden <[email-masked]> wrote:
> 
> Barbara,
> 

I certainly hear questions from campus network admins about IPv6 requirements for tenders. There are documents like RIPE-554 which are helpful in that regard (though it needs an update), but being able to point at an RFC has some value, and any update of 554 would likely draw on the consensus expressed therein, along with 6434-bis.

I really like the writing style of draft-ietf-v6ops-ipv6rtr-reqs; there's a lot of very good and very useful discussion and advice in there aside from specific MUSTs and SHOULDs.

Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Feb 2018 10:49:19 +1300

On 06/02/2018 18:34, Mikael Abrahamsson wrote:
> definition, 

To me that sounds like a precise definition of IBM's SNA sysgen process
twenty years ago.

> that's not how it's widely accepted to be defined. There are 

Not to mention that "centralized" is a bad word in many contexts, and
robust SDN control needs to be distributed in some way.

> been marketed to hell and back, and it now means different things to 

Agreed. I think we should remove "SDN" from our vocabulary if we want
to avoid constant confusion.

     Brian

---

From: Bob Hinden <[email-masked]>
Date: Tue, 6 Feb 2018 14:01:12 -0800

Tim,

> On Feb 6, 2018, at 1:41 AM, Tim Chown <[email-masked]> wrote:
> 

I agree.  I was thinking that the draft would be better if it went through a list of features relevant for routers, discussed scenarios where they are useful, but didn’t try to get into MUST or SHOULDs because there are too many different types of routers.  For example, DHCPv6 prefix delegation is useful for ISP facing home/SHO routers.

Bob