Subject: Questions on Configured Tunnel MTU and TOS Byte Settings

From: Roy Brabson <[email-masked]>
Date: Mon, 11 Nov 2002 09:44:27 -0500

I've got a few of questions on configured tunnels, as described in 
draft-ietf-ngtrans-mech-v2-01.txt. 

- Section 3.2 discusses how to set the tunnel MTU.  It covers the case 
  where the tunnel MTU size is manually configured, with a default of 
  1280.  While it discusses capping the tunnel MTU at 4400 when IPv4 
  path MTU discovery is used, it doesn't discuss a maximum configured
  value for the tunnel.  Does this mean there is no cap when manually 
  configuring the tunnel MTU (i.e., the configured tunnel MTU may be as 
  large as 65515, or even larger if jumbograms are used?)

- The same section does not discuss what a host should do if it receives a 

  Router Advertisement with an MTU option.  Should the MTU value received 
  be used?  If so, is there a cap associated with this MTU value?  In 
  other words, if it exceeds 4400 bytes should the value be used?

- In section 3.5, the TOS byte is defined as being set to 0 unless 
  otherwise specified.  What exactly does this mean?  That, if RFC 2893 is 

  followed the DSCP in the TOS byte may be set to a non-zero value?  Or 
  that RFC 2893 and RFC 3168 should explicitly NOT be implemented for 
  configured tunnels?  If the latter, I think some discussion on exactly
  WHY these two RFCs are not to be implemented would be helpful.

- In section 3.6, the TOS byte of the inner packet is left unmodified at 
  the tunnel egress.  This seems to contradict some of the referenced. 
  For instance, RFC 3168 defines both limited-functionality and 
  full-functionality support for ECN support over tunnels.  For 
  limited-functionality, which seems to most closely match what is 
  described in this draft, it discusses what to do at the tunnel egress if 

  the CE option is set in the outer packet header but not the inner packet 

  header.  This processing does not seem to match what is described in 
  this draft.  Is this intentional?

Roy

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Nov 2002 16:10:50 +0100

Roy,

> draft-ietf-ngtrans-mech-v2-01.txt.
...
>   WHY these two RFCs are not to be implemented would be helpful.

Firstl there is an important typo in the references. [20] should be
RFC 2983 and *not* 2893. 2983 is the diffserv/tunnels RFC. Although
it's only Informational, I would be very upset if the transition
draft was intended to mean "don't implement 2983". On the contrary,
it should mean "do implement 2983" and if the text isn't clear
on that, it needs fixing.

I don't claim expertise on ECN, but I expect the same applies.

>   this draft.  Is this intentional?

Surely the interpretation should be the same, i.e. do what [20] and [21]
say. If not, the text needs fixing.

By the way, RFC 2983 is Informational because at the time it was written,
we didn't feel certain enough to put it on standards track. But I've
seen nothing to suggest that what it recommends is wrong.

   Brian

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Nov 2002 13:17:53 +0100 (CET)

> RFC 2983 and *not* 2893. 2983 is the diffserv/tunnels RFC. 

Oops. Will fix.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 13 Nov 2002 13:16:31 +0100 (CET)

>   large as 65515, or even larger if jumbograms are used?)

It might be worth while to separate what the document currently says and
what folks want it to say. I saw some comments that for a configured
tunnel it makes sense to allow the encapsulator and decapsulator to
(out of band) agree on what mtu to use for the tunnel.
Thus as long as the decapsulator is capable of reassembling IPv4 packets
of size X for the tunnel, the encapsulator can be configured to use size X
for that tunnel's MTU.

But in the case when the tunnel MTU isn't explicitly configured, it must
have a default which all receivers are required to be able to reassemble.

Does that make sense to folks as the intent?

Does this mean that we should add some warnings that it doesn't make sense
to configure the tunnel MTU to be larger than the IPv4 path MTU
between the encapsulator and decapsulator?

>   other words, if it exceeds 4400 bytes should the value be used?

Good question. I assume the issue is confined to an RA with the MTU
option received on the tunnel interface.

In RFC 2461 is says that the advertised MTU should not be used when it
exceeds the default MTU specified in the link type specific document (e.g.
IPv6 over Ethernet).
Does that mean that it shouldn't be used when it exceeds 4400? 1280?

>   WHY these two RFCs are not to be implemented would be helpful.

The intent is that the setting of the TOS byte for tunnels is specified
in other documents, but we do not want to have a normative reference on
those documents since it would create an obstacle to moving this draft to
Draft Standard.
Any suggestions on how to make this more clear?

>   this draft.  Is this intentional?

Same isssue as above. If RFC 3168 was moved to draft standard status we could
have more prescriptive language.

  Erik