Subject: [v6ops] Vetting draft-ali-ipv6rtr-reqs

From: Fred Baker <[email-masked]>
Date: Tue, 14 Feb 2017 09:32:41 -0800

A few months ago, several authors submitted draft-ali-ipv6rtr-reqs. We are considering bringing it into v6ops, as it is primarily operational. To do so, we need support from the working group.

Is this a draft folks would like to discuss in Chicago?

---

From: james woodyatt <[email-masked]>
Date: Wed, 15 Feb 2017 12:28:52 -0800

> A few months ago, several authors submitted draft-ali-ipv6rtr-reqs. We are considering bringing it into v6ops, as it is primarily operational. To do so, we need support from the working group.

I recently had cause to give this draft a cursory review, because I was searching for any IETF discussion relevant to a question about how IPv6 nodes must operate when they have interfaces where they must function as both a host and a router. I was rather surprised not to see any discussion in this draft about the question of whether an IPv6 router necessarily implements any dynamic routing protocol.

The only mentions of dynamic routing protocols I can find are as follows:

- In Section 2.1, Robustness Principle: which recommends that software shouldn’t fail in way that causes adjacent routers to fail or generate traffic engineering problems.

- In Section 2.4, Routers: an overview of the functional requirements of a router are listed in a table, with no mention of a dynamic routing protocol function. On the other hand, Figure 2 contains a diagram with boxes labeled “IS-IS”, “BGP”, “OSPF” and “Other” with arrows pointing to labels reading “Adjacent Routers” and “Peers.”

When I noticed this, my first thought was “this needs a lot of work.” And I haven’t really given it much thought since. Shouldn’t there be a lot more here about dynamic routing protocols? Shouldn’t there, at least, be something about whether implementing one or more dynamic routing protocols is even required?

Also, I note that the draft contains a normative citation to RFC 2119, but a) it doesn’t include the boilerplate from RFC 2119, and b) it’s classified as Information, where RFC 2119 language is usually not used unless there is an explicit notification that IETF is providing guidance to other standards bodies, which is also not present here. The draft uses RFC 2119 requirements keywords very sparsely and inconsistently. So, it’s hard to know what the purpose of this document is intended to serve.

Shorter james: maybe this draft needs another revision before a call for adoption.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Fred Baker <[email-masked]>
Date: Wed, 15 Feb 2017 12:57:30 -0800

Maybe I should clarify. We are not, at this point, calling for adoption, but wondering whether folks want to discuss it at the coming IETF meeting. And for the record, there is another revision in the works, intended to be posted for this meeting.

You'll note that I am listed as an author (although "contributor" might be more appropriate). From that perspective, I would agree that some comment on dynamic routing is appropriate. The obvious next question is "which protocols" and "what should be said". I suspect that this leads to the weeds somewhere. Do we want to say that every router in the world SHOULD support BGP4+, IS-IS with both IPv4 and IPv6 support, OSPFv2, OSPFv3, RPL, and Babel, for example? Some subset of those, and if so, which subset and why? With BGP, there are a number of optional or updating RFCs; do we want to list the ones we think are important? In general, a product today SHOULD support both IPv4 and IPv6, but is that true tomorrow? At what point would a recommendation of that sort expire?

Thinking out loud, several of the authors are from a well known data center service, so the initial thinking obviously targets data centers. If we were to put something in, it's probably about BGP4+, IS-IS, and OSPFv3. I could imagine discussing how one configures a contention-free switching fabric (often called a "Clos" network). That said, I could imagine service providers having their own set of requirements, residential networks having their own set of requirements, and IoT networks having their own requirement. Thread, for example, only discusses RPL, and Homenet only discusses Babel or static routing.

> On Feb 15, 2017, at 12:28 PM, james woodyatt <[email-masked]> wrote:
> 
> --james woodyatt <[email-masked]>
> 
> 
>