Subject: [v6ops] Outstanding edits for draft-ali-ipv6rtr-reqs

From: "Russ White" <[email-masked]>
Date: Sat, 18 Feb 2017 11:26:17 -0500

Y'all --

These are the outstanding comments and areas where work is needed for
draft-ali-ipv6rtr-reqs. 

:-)

Russ

==
There has been some discussion around changing the name of the draft. It
would be good to discuss this to see if there is something better here.

==
There are still some sections that either need to be filled in or deleted.
If anyone has opinions on which to do, it would be good to hear them.

==
The bullet "The desired optimization" isn't clear to me. Do you mean
efficiency? Something else?

It's hard to describe, because "it depends." It can mean "higher utilization
along all links, so we don't need to deploy more bandwidth." It can also
mean "lower ovoerall jitter, to better support application x." Or, perhaps,
"improving utilization while also decreasing jitter for application x." The
problem with describing this particular third of the triangle is the goal
can vary depending on what you consider "optimal use of resources" -- which
is actually as it should be, because every network is supporting a different
application mix in support of different business requirements. "Efficiency"
has the same problem -- "efficiency of what?" The efficiency of supporting a
particular application, efficiency in terms of making the most use of
available bandwidth, efficiency in terms of... 

==
"Network devices should place a priority on supporting machine readable
APIs." Do you mean device maufacturers should focus on writing code to do
that, or do you mean the devices should prioritize API config bits somehow?
I think you mean "Router manufacturers should focus on developing
machine-readable APIs." But I'm not sure I agree, since to prioritize
something means to implicitly deprioritize something else (if everything's a
priority, nothing is), and I don't want to encourage vendors to prioritize
APIs over CLI.

Just about everyone else wants implementations to focus on APIs rather than
CLIs, I think -- at least most of the folks I've talked to. We should
discuss this some, and see what the list says, as well. I have changed the
text a bit here, however, to make the concept "more clear."

==
The bullet "Configuring an prefix length longer than a /64.should require
additional configuration steps."  Hmm. I'm not sure about this one. More
discussion required.

I'm ambivalent about this; I'll leave this for discussion amongst the
contributors to decide. 

==
5.6 I wish you luck!

I actually don't know what to put here; is there a specific set that should
be supported? Is it "fair" to ask for hardware support for specific
extension headers?

==
3.1 
citations needed for SNMP and MIB definitions.

I couldn't figure out "one" citation, and I didn't want to list them all.
:-) I suppose we could just list the one for IPv6 (?). Thoughts?

==
This section should make reference to ANIMA and SUPA WG efforts, even if
just for awareness. Maybe HNCP (Homenet), too. All of those efforts could
make a difference in this area.

I'm not certain ANIMA, SUPA, and HNCP fit into this section.

---

From: Fred Baker <[email-masked]>
Date: Sat, 18 Feb 2017 13:19:27 -0800

On Feb 18, 2017, at 8:26 AM, Russ White <[email-masked]> wrote:
> I don't want to encourage vendors to prioritize
> APIs over CLI.
> 
> CLIs, I think -- at least most of the folks I've talked to.

All hats off.

Personally, I think CLI is to be deprioritized. SNMPv1 was pretty much handed to the IETF, and the IETF developed it, including writing a lot of MIBs. The operators essentially came back and wanted something they could read - ASCII. The outcome of that discussion was NetConf. Then they wanted a list of improvements, and the outcome was/is being YANG. I know some vendors that want CLI, and perhaps even a standardized CLI variant. The one thing that the operators have not really asked for, at least in my hearing, is CLI.

At least part of that is Cisco's fault; CLI on one OS is not necessarily portable to another even within Cisco's product line, and the companies that use the acronym to mean a "Cisco-like Interface" aren't interoperable either. If there is one thing that I have heard from the operators, it's that they want something that is interoperable across the machines they use, which means multi-vendor interoperability. YANG gives them that in the sense that there is a described outcome, and the vendors supply whatever it takes to implement that outcome on their equipment.

In your list, I didn't see James' comment from the other day, regarding discussion of routing. I'd suggest you add it to the list. You might also be interested in my reply - I asked a number of open-ended questions. They come down to - first, for what market, and making what assumptions? Second (from a different email), should there be a list of target markets (and, reading my email again, let's add mobile wireless) with differing requirements?

I also didn't see a reference to Joe's comment regarding RFC 1812. If you like, Joe and I can put our heads together on that one - I have some history in it. What he asked for, and what I think might be a reasonable first step, is some description of the use cases the document targets. I *think* there might be real value in a description somewhere of the Internet in 2017, which is quite a bit different than what it was before 1996.

---

From: Fred Baker <[email-masked]>
Date: Sat, 18 Feb 2017 18:11:30 -0800

On Feb 18, 2017, at 1:19 PM, Fred Baker <[email-masked]> wrote:
> In your list, I didn't see 

I also didn't see Lee's response...

---

From: "Russ White" <[email-masked]>
Date: Sat, 18 Feb 2017 22:06:58 -0500

> In your list, I didn't see James' comment from the other day, regarding
> discussion of routing. I'd suggest you add it to the list. You might also
be
> interested in my reply - I asked a number of open-ended questions. They
> come down to - first, for what market, and making what assumptions?
> Second (from a different email), should there be a list of target markets
(and,
> reading my email again, let's add mobile wireless) with differing
> requirements?

I saw that exchange -- I don't know that I want to say "should implement
routing protocol x and y" -- because I don't know that we'd agree until we
said, "BGP, OSPF, IS-IS, BABEL, LISP, etc., etc..." And then someone would
say "sure, but what specific elements of each protocol need to be
implemented," in order to "narrow the list," and then... I can see where
this is going before I turn down that particular rabbit trail, I think. :-)
Because, as you said, everyone has different requirements here.

> I also didn't see a reference to Joe's comment regarding RFC 1812. If you
like,
> Joe and I can put our heads together on that one - I have some history in
it.

Sure -- I didn't really understand the question... I don't know how I'd
write a "state of the Internet in 2017," other than something like --

- very dense interconnectivity
- largely deploying dual stack
- might be seeing a shift in architecture away from "real" transit in many
ways, and a focus on the "edges"
- definitely confused about SDNs and things in that neighborhood (largely a
definitional problem)

Maybe a few other things -- but I wouldn't mind having some ideas in this
space, if folks think it's useful.

On Lee's comments -- I addressed most of them in the rev (or at least I hope
I did). The ones I put on the list are the remainder. I might have missed
another round of comments, though... I wasn't trying to make a list of
issues, which is what I probably need to do now, so I can keep track of
folks' comments.

:-)

Russ