Subject: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02

From: Ron Bonica <[email-masked]>
Date: Wed, 22 Mar 2017 16:24:08 +0000

Folks,

The following are a few comments on draft-ali-ipv6rtr-reqs-02:

1) Consider adding an appendix that summarizes requirements. An entry in this appendix might look like the following:

REQ 1 : To support automated router configuration, IPv6 routers and routers SHOULD support YANG and SNMP configuration, including (but not
   limited to)...... (From Section 3.1 of this document)

2) Some of the requirements put forth in this document are IPv6 specific. For example, "SLAAC SHOULD be enabled by default on all router interfaces". Others requirements are applicable to IPv6 and IPv6. For example,  "TELNET SHOULD be disabled by default, but should be available for operational purposes as required or as configured by the operator". I wonder whether generic requirements belong in an document on requirements for IPv6 routers?

3) The title of Section 5.3 is "Maximum Transmission Unit and Jumbo Frames". However, there is no further mention of Jumbo Frames. Could we explore Jumbo's possibly with an eye towards deprecation.

4) A few sections (e.g. 5.1) don't contain any requirements. Will they contain a requirement in a later revision? Do they support requirements in another section? If not, I wonder if they contribute to the document.

                                   /hatless
                                    Ron Bonica

---

From: "Russ White" <[email-masked]>
Date: Thu, 30 Mar 2017 10:41:08 -0500

> 1) Consider adding an appendix that summarizes requirements. An entry in
> this appendix might look like the following:

I'll add this to the next version.

> 2) Some of the requirements put forth in this document are IPv6 specific. For
> example, "SLAAC SHOULD be enabled by default on all router interfaces".
> Others requirements are applicable to IPv6 and IPv6. For example,  "TELNET
> SHOULD be disabled by default, but should be available for operational
> purposes as required or as configured by the operator". I wonder whether
> generic requirements belong in an document on requirements for IPv6
> routers?

This is a hard question. While the document says "IPv6 requirements for routers," we really threw out ideas that cover anything in a "router" -- I don't know if this is the right "mix" however. I'd really like some guidance from the WG here. 

> 3) The title of Section 5.3 is "Maximum Transmission Unit and Jumbo
> Frames". However, there is no further mention of Jumbo Frames. Could we
> explore Jumbo's possibly with an eye towards deprecation.

I think this is one of those sections where I wasn't certain what to say. I did not realize there was an effort afoot to deprecate jumbo frames? 

> 4) A few sections (e.g. 5.1) don't contain any requirements. Will they contain
> a requirement in a later revision? Do they support requirements in another
> section? If not, I wonder if they contribute to the document.

These are place holders for "I don't know what stuff to say here, or if it's helpful to include this." If anyone has ideas, I'm happy to add text. If I don't have suggestions in a couple of revisions, I'll remove them.

😊 /r

---

From: Ron Bonica <[email-masked]>
Date: Fri, 31 Mar 2017 14:52:19 +0000

Hi Russ,

Inline......

> > 2) Some of the requirements put forth in this document are IPv6
> > specific. For example, "SLAAC SHOULD be enabled by default on all router
> interfaces".
> > Others requirements are applicable to IPv6 and IPv6. For example,
> > "TELNET SHOULD be disabled by default, but should be available for
> > operational purposes as required or as configured by the operator". I
> > wonder whether generic requirements belong in an document on
> > requirements for IPv6 routers?
> 
> This is a hard question. While the document says "IPv6 requirements for
> routers," we really threw out ideas that cover anything in a "router" -- I don't
> know if this is the right "mix" however. I'd really like some guidance from the
> WG here.
> 
[RB ] 
One way to tackle this problem is to review previous documents that enumerated router requirements (e.g., RFC 1812). Then add a table to draft-ali-ipv6rtr-req that says "this document inherits requirements A, B and C from RFCs X, Y, and Z.

That way you can leverage previous work without replicating the effort.

> > Frames". However, there is no further mention of Jumbo Frames. Could
> > we explore Jumbo's possibly with an eye towards deprecation.
> 
> I think this is one of those sections where I wasn't certain what to say. I did
> not realize there was an effort afoot to deprecate jumbo frames?
[RB ] 

My bad. I was confusing Jumbo Frames (  > 1500 bytes  ) with Jumbograms  ( > 65,767 bytes ).  IMHO, all IPv6 routers should support jumbo frames while jumbograms  aren't really required by anybody.

> 
> > 4) A few sections (e.g. 5.1) don't contain any requirements. Will they
> > contain a requirement in a later revision? Do they support
> > requirements in another section? If not, I wonder if they contribute to the
> document.
> 
> These are place holders for "I don't know what stuff to say here, or if it's
> helpful to include this." If anyone has ideas, I'm happy to add text. If I don't
> have suggestions in a couple of revisions, I'll remove them.
[RB ] 
Understood. Work in progress....

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 1 Apr 2017 05:26:04 +1300

> My bad. I was confusing Jumbo Frames (  > 1500 bytes  ) with Jumbograms  ( > 65,767 bytes ).  IMHO, all IPv6 routers should support jumbo frames while jumbograms  aren't really required by anybody.

1. Jumbograms were intended for very high speed point to point links like HIPPI**.
So nobody ever expected routers to handle them. Let them sleep quietly; no need
to send them to the jumbogram graveyard.

2. Jumboframes aren't really an IETF problem, are they? I've nothing against
them, but why would they be a router *requirement*?

**RFC2675:
   Jumbograms are relevant only to IPv6 nodes that may be attached to
   links with a link MTU greater than 65,575 octets, and need not be
   implemented or understood by IPv6 nodes that do not support
   attachment to links with such large MTUs.

Regards
   Brian

---

From: Joe Touch <[email-masked]>
Date: Fri, 31 Mar 2017 09:44:23 -0700

> One way to tackle this problem is to review previous documents that enumerated router requirements (e.g., RFC 1812). Then add a table to draft-ali-ipv6rtr-req that says "this document inherits requ…
FWIW, that's what I've been asking for.

IMO, the related requirement might be "configurable", but indicating how
is out of scope unless you demand support for a particular protocol. I
see no valid reason to require TELNET vs. any other service over which
configuration can be achieved.

Joe

---

From: "Russ White" <[email-masked]>
Date: Fri, 31 Mar 2017 21:54:46 -0400

> IMO, the related requirement might be "configurable", but indicating how is
> out of scope unless you demand support for a particular protocol.
> I see no valid reason to require TELNET vs. any other service over which

Let me put this another way: some sets of features make a network easier to operate. Others make a network more difficult to operate. What I've heard from operators (including my operational folks) is what is in the draft. This is not a document that says, "this is what is technically best," or "this is what is the most advanced." Instead, this document was designed just to give operators a chance to say, "this is what I expect to see in a router on which I deploy IPv6." 

If we are going to move away from what operators argue implementations SHOULD/MUST/MAY implement, then we are moving away from the original intent of the document--which means it becomes a different document entirely, and we are going to need to find different ground rules for determining what to include or not. If someone would like to make a suggestion of what those ground rules might be (please do not suggest "the best technical solution," as that idea will simply result in an endless fight), please suggest it.

I'm perfectly happy to do whatever editing is needed... But I need to know what the new ground rules are going to be if the intent of the draft is going to be changed, in order to effectively evaluate what should in (or out) of the draft -- and if the ground rules do change, then a draft with the original intent is going to reappear anyway, as many operators I've spoken to believe such a document is useful and necessary.

😊 /r

---

From: Joe Touch <[email-masked]>
Date: Fri, 31 Mar 2017 19:48:27 -0700

Hi, Russ,

> Let me put this another way: some sets of features make a network easier to operate. Others make a network more difficult to operate. What I've heard from operators (including my operational folks)…

I see BCPs as a place where operator advice goes. IMO, requirements are
a different thing, esp. when we're defining what it means to "be" something.

That's why I saw this as the IPv6 corollary to RFC1812 and why I found
it lacking in that regard.

Joe