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

From: "Russ White" <[email-masked]>
Date: Sat, 1 Apr 2017 07:26:09 -0400

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

The eventual status seems to be a useful discussion to have at some point... I'm pretty ambivalent about it; the other co-authors may have a stronger opinion. 

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

So -- returning to your earlier comment:

>> I see no valid reason to require TELNET vs. any other service over 
>> which configuration can be achieved.

I note that 1812 spends a good deal of time on O&M, including MIBs, dumping router memory, out-of-band access, TFTP, memory dumps, audit trails, etc., none of which seem (to me) to be IPv4 specific, and it is standards track. I do not know if this bit of information applies, however (?). 

😊 /r

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 2 Apr 2017 02:11:50 +1300

> I note that 1812 spends a good deal of time on O&M, including MIBs, dumping router memory, out-of-band access, TFTP, memory dumps, audit trails, etc., none of which seem (to me) to be IPv4 specific…

I think 1812 was written a long time ago and both solutions and practices for
configuring & monitoring routers have changed more than somewhat since then.
I also think that they will continue to change, but the draft allows for that
by saying "not limited to":

   To support automated network device configuration, IPv6 routers and
   network devices SHOULD support YANG and SNMP configuration, including
   (but not limited to):

The only quibble with that sentence is that it seems to recommend SNMP SET.
I understood that SNMP was only use for monitoring in practice,
as mentioned later under 'Telemetry'.

    Brian

---

From: Ross Chandler <[email-masked]>
Date: Sat, 1 Apr 2017 14:35:25 +0100

> On 1 Apr 2017, at 14:11, Brian E Carpenter <[email-masked]> wrote:
> 

If you are talking about the present situation, SNMP is used for configuration. 
At least one widely used router vendor’s element manager is dependent on it.

Ross

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 2 Apr 2017 02:18:34 +1200

> At least one widely used router vendor’s element manager is dependent on it.

Interesting. But given that SNMP SET is generally not recommended these days,
shouldn't the draft indicate that this is a legacy solution rather than a SHOULD?

    Brian

---

From: Ross Chandler <[email-masked]>
Date: Sat, 1 Apr 2017 15:38:45 +0100

On 1 Apr 2017, at 15:18, Brian E Carpenter <[email-masked]> wrote:

Interesting. But given that SNMP SET is generally not recommended these days,
shouldn’t the draft indicate that this is a legacy solution rather than a SHOULD?

In the case of this manager all the SNMP configuration is done either from manual changes in the gui or via an XML based API into it.
So I don’t see a problem with SNMP only being a MAY.  As I understand it the roadmap for the vendor is to support YANG in router and manager.

Ross

---

From: Tim Chown <[email-masked]>
Date: Sat, 1 Apr 2017 23:55:43 +0000

Hi Russ,

> On 1 Apr 2017, at 02:54, Russ White <[email-masked]> wrote:
> 
> 
>> 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.
> 
> 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.

I think capturing the spirit of what you say above in the draft would be useful, esp. what you say in the first paragraph.

Tim

> 
> 😊 /r 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 21 Apr 2017 15:54:19 +0200 (CEST)

On Wed, 22 Mar 2017, Ron Bonica wrote:

> 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 am strongly in favour of support of jumbo frames.

I would like to see the document specify an L3 MTU of 9180 as its SHOULD 
requirement. All major core router vendor supports this today. The reason 
for 9180 is that this is what RFC2225, RFC2492, RFC1209 mention.

Other comments:

3.3 It would be good if the draft referenced for instance RFC8071 for 
Netconf-call-home and draft-ietf-netconf-zerotouch-13 for zerotouch 
plug'n'play provisioning.

5.4. The ICMP ECHO/REPLY requirement here opposes what's in RFC4890. I 
prefer what RFC4890 says.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ron Bonica <[email-masked]>
Date: Fri, 21 Apr 2017 15:20:56 +0000

Hi Mikael,

When I made the comment that you quote, I was confusing Jumbo Frames with Jumbograms.

                                                                                Sorry,
                                                                                    Ron

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Mikael
> Abrahamsson
> Sent: Friday, April 21, 2017 9:54 AM
> To: IPv6 Ops WG <[email-masked]>
> Subject: Re: [v6ops] Comments on draft-ali-ipv6rtr-reqs-02
> 
> > Frames". However, there is no further mention of Jumbo Frames. Could
> > we explore Jumbo's possibly with an eye towards deprecation.
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 21 Apr 2017 12:00:17 -0700

> On Apr 21, 2017, at 6:54 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
>> 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 would like to see the document specify an L3 MTU of 9180 as its SHOULD requirement. All major core router vendor supports this today. The reason for 9180 is that this is what RFC2225, RFC2492, RFC1209 mention.

We may need to clarify the meaning of the term. RFC 2460 removed references to Jumbograms (from the RFC 1883 text), moving it to a separate document. That document is RFC 2675, which says:

   The IPv6 header [IPv6] has a 16-bit Payload Length field and,
   therefore, supports payloads up to 65,535 octets long.  This document
   specifies an IPv6 hop-by-hop option, called the Jumbo Payload option,
   that carries a 32-bit length field in order to allow transmission of
   IPv6 packets with payloads between 65,536 and 4,294,967,295 octets in
   length.  Packets with such long payloads are referred to as
   "jumbograms".

From that perspective, a 9K byte message is a "normal" IPv6 message - the payload length fits in the provided 16 bit field.

Yes, I'm in favor of 9K byte messages too. But they are not "jumbo" from this perspective.

> Other comments:
> 
> 3.3 It would be good if the draft referenced for instance RFC8071 for Netconf-call-home and draft-ietf-netconf-zerotouch-13 for zerotouch plug'n'play provisioning.
> 
> 5.4. The ICMP ECHO/REPLY requirement here opposes what's in RFC4890. I prefer what RFC4890 says.
> 
> --