Subject: [netmod] draft-ietf-netmod-interfaces-cfg MTU value

From: David Lamparter <[email-masked]>
Date: Tue, 6 Nov 2012 18:00:19 -0500

Hi,

I just commented about some weirdness with the MTU field in the
interfaces draft.  Here's a quote for reference:
         leaf mtu {
           type uint32;
           description
             "The size, in octets, of the largest packet that the
              interface can send and receive.  This node might not be
              valid for all interface types.

              Media-specific modules must specify any restrictions on
              the mtu for their interface type.";
           reference
             "RFC 2863: The Interfaces Group MIB - ifMtu";
         }

The problem is quite simply that this doesn't say if it's referring to
L2 or L3 MTU.  I understand that there's some kind of consensus in usage
from history, but that's not useful in a specification if it's not
written down.

Aspects of the different values are:
 - L2:
   - it's the actual interface property
   - might make sense to have a max-mtu(ro) and mtu(rw) to support
     reducing allocated buffer sizes & such., but I believe that hosts
     can well handle that automatically
   - fits the location, we're below L3 in context
   - slightly confusing for subinterfaces.  Let's say I have ethernet
     with 2 stacked 1Q labels.  Is the mtu on the innermost still the
     same as on the parent ethernet, or is it reduced by 8?
     => specification needed
   - better name: mfs (maximum frame size)
 - L3:
   - actually useful value
   - makes more sense with stacked encapsulations since it's clearly
     defined that it's returning the usable value with all overhead
     applied

Relatedly, I see the need to add a MTU field on the IPv4/IPv6 levels.
(Which is going to be fun dealing with for example on Linux because it
only supports one value, but well... that's a Linux problem really.)

Cheers,

-David

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Nov 2012 13:22:23 +0100

> only supports one value, but well... that's a Linux problem really.)

Here is the definition of ifMtu in RFC 2863:

            "The size of the largest packet which can be sent/received
            on the interface, specified in octets.  For interfaces that
            are used for transmitting network datagrams, this is the
            size of the largest network datagram that can be sent on the
            interface."

This says its the largest overall frame size except if you run IP over
it (or some other protocol sending "network datagrams"), then it is
the largest payload size. What are our options?

1) drop the interface mtu leaf and instead add an IP config mtu leaf
   (since this is what we understand well)

2) like 1) but add a generic read-only leaf to report the maximum
   frame size actually used, (that means to configure it, you need
   interface type specific data model extensions)

3) like 2) but add another generic leaf to report the maximum frame
   size possible as a read-only leaf (e.g. useful to learn whether an
   ethernetCsmacd interface supports jumbo frames)

Anything else?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 7 Nov 2012 09:39:58 -0500

>  ethernetCsmacd interface supports jumbo frames)

I support #1 because some L2 technologies, such as ATM, don't have the notion of MTU. The future Ethernet module will define it and all should be fine.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: David Lamparter <[email-masked]>
Date: Wed, 7 Nov 2012 10:10:20 -0500

> >  (since this is what we understand well)

This could be either on the ipv4, or the ipv6, or the general interface
level.  I'd like to argue for keeping it on the interface level (which I
forgot as possibility when writing that rant about IPv4/IPv6 level
above - sorry).

See below for an adapted 1a) addressing a maximum value.

> I support #1 because some L2 technologies, such as ATM, don't have the
> notion of MTU. The future Ethernet module will define it and all
> should be fine.

These options aren't really excluding each other;  I suppose you're
simultaneously arguing for #1 and against #2/#3.  So far, we have a
consensus on #1 it seems.

I agree that 2) is not that useful;  it conveys only statistical /
debugging information that is of very limited use.

I do think 3) has some use, although I don't see an extreme need for it.
(i.e. I'd like to see other feedback, but not taking much of a stance on
it right now.)
However, to make 3) actually useful if added, IMHO it needs be:
 3a) adding an "encapsulationOverhead" field that indicates size of the
     L2 header including all overhead for additional encapsulations like
     802.1Q, GRE, or whatever floats your boat.

If we want to have some maximum value without going down the link-layer
path, there is:
 1a) add a maxMtu field on the IP level, explicitly defined as the
     maximum configurable _IP_ MTU.
(This is a separate option again, non-exclusive with 3/3a)

Note that for GRE with PMTU discovery, this topic gets another level of
complication.  If absolutely needed, I'd like to suggest using 0 for all
"special" cases, including ATM and tunnels with dynamic MTU.  This is
also an issue for the MTU value on the IP level, for tunnels at least.
An alternative option might be to have a defined meaning for the absence
of a MTU value.

-David

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 7 Nov 2012 11:40:16 -0500

> consensus on #1 it seems.

What I am saying is that the "mtu" leaf is present even for interfaces where it doesn't make sense, albeit it is optional.

> (This is a separate option again, non-exclusive with 3/3a)

I think all this belongs to media- or encapsulation-specific modules.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 07 Nov 2012 17:26:40 -0500 (EST)

Hi,

David Lamparter <[email-masked]> wrote:
> > On Nov 7, 2012, at 7:22 AM, Juergen Schoenwaelder

Are you suggesting that we add a single leaf ip-mtu (defined in the ip
module)?  And thus not have ipv4/mtu and ipv6/mtu?

/martin

---

From: David Lamparter <[email-masked]>
Date: Wed, 7 Nov 2012 17:30:20 -0500

> module)?  And thus not have ipv4/mtu and ipv6/mtu?

Yes, out of plain and simple reality acceptance.  But this is based on
my (limited) knowledge of existing device features.  If someone tells me
a large number of devices support separate MTUs here, I will instantly
change my opinion.

-David

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Nov 2012 00:21:19 +0100

> a large number of devices support separate MTUs here, I will instantly

Architecturally, I would argue they are not the same thing since they
face different constraints. Some widely used router documentation says
that they have commands such as 

     ipv6 mtu <bytes>

with a default of 1280 bytes and 

     ip mtu <bytes>

with a minimum of 128 bytes. Some other widely used router
documentation hints at this:

interface <name>
            unit 0
                family inet
                     mtu <bytes>
                family inet6
                     mtu <bytes>

If a Linux kernel only has one MTU value, then this might be a special
case. I am not sure what a *BSD kernel offers in this regard (too lazy
to check at the moment). So it seems appropriate to support IP version
specific MTUs, but it might be useful to have text somewhere that
details what should happen on boxes that only support a single per
link MTU value.

/js

---

From: Phil Shafer <[email-masked]>
Date: Thu, 8 Nov 2012 00:04:42 -0500

>that they have commands such as 

FWIW, googling yields some interesting stories about differing
views on MTU, like:

http://www.net-gyver.com/?p=1086
http://blog.ioshints.info/2011/07/all-mtus-are-not-same.html
http://books.google.com/books?id=PWVJUuLvw3oC&pg=PA147&lpg=PA147&dq=mtu+junos+ios&source=bl&ots=dNftFM8zQV&sig=p_tHHgHu4w93xXr2JAatpTVHGhQ&hl=en&sa=X&ei=CTubUP-jE-iviQLou4CABA&ved=0CDQQ6AEwAQ#v=onepage&q=mtu%20junos%20ios&f=false
http://www.gossamer-threads.com/lists/nsp/juniper/34633?do=post_view_threaded

In summary, JUNOS and IOS-XR view MTU as L2; IOS-classic views MTU
as L3.

The downside of using the L2 number is that the user needs to know
the L2 overhead.  The downside of using the L3 number is that the
user needs to know the L2 overhead. ;^)

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Nov 2012 09:02:22 -0500 (EST)

> In summary, JUNOS and IOS-XR view MTU as L2; IOS-classic views MTU

This would be the mtu on the interface.  All these implementations
treat the ip mtu the same way (which makes sense...).

It does seem weird that the mtu defined on the l2 level really is the
l3 mtu.  But RFC 2460 has this definition:

   packet      - an IPv6 header plus payload.

   link MTU    - the maximum transmission unit, i.e., maximum packet
                 size in octets, that can be conveyed over a link.

... which adds to the confusion.

Current consensus seems to be that we should not specify the mtu on
the interface layer at all.  We leave that up to the media-specific
modules.  So that they all can do it differently ;)

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 8 Nov 2012 11:08:25 -0500

> modules.  So that they all can do it differently ;)

+1. It also allows media-specific modules to specify their default MTU value.

Lada

---

From: t.petch <[email-masked]>
Date: Thu, 8 Nov 2012 18:19:09 +0000

----- Original Message -----
From: "Phil Shafer" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, November 08, 2012 5:04 AM

> http://blog.ioshints.info/2011/07/all-mtus-are-not-same.html
http://books.google.com/books?id=PWVJUuLvw3oC&pg=PA147&lpg=PA147&dq=mtu+
junos+ios&source=bl&ots=dNftFM8zQV&sig=p_tHHgHu4w93xXr2JAatpTVHGhQ&hl=en
&sa=X&ei=CTubUP-jE-iviQLou4CABA&ved=0CDQQ6AEwAQ#v=onepage&q=mtu%20junos%
20ios&f=false
http://www.gossamer-threads.com/lists/nsp/juniper/34633?do=post_view_thr
eaded
> In summary, JUNOS and IOS-XR view MTU as L2; IOS-classic views MTU

And we are the IETF and we speak with a single voice, namely

"
   MTU:  Maximum Transmission Unit, the size in bytes of the largest IP
      packet, including the IP header and payload, that can be
      transmitted on a link or path.  Note that this could more properly
      be called the IP MTU, to be consistent with how other standards
      organizations use the acronym MTU.

   Link MTU:  The Maximum Transmission Unit, i.e., maximum IP packet
      size in bytes, that can be conveyed in one piece over a link.  Be
      aware that this definition is different from the definition used
      by other standards organizations.

      For IETF documents, link MTU is uniformly defined as the IP MTU
      over the link.  This includes the IP header, but excludes link
      layer headers and other framing that is not part of IP or the IP
      payload.

      Be aware that other standards organizations generally define link
      MTU to include the link layer headers."

Doubtless Google will find you the RFC that this comes from:-)

I think you would be really wanting to create confusion if you depart
from the accepted, over several decades, IETF use of the terms.

Tom Petch