Re: Questions on Configured Tunnel MTU and TOS Byte Settings

[Erik Nordmark <Erik.Nordmark@sun.com>]

> 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?)

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?

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

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?


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

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?

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

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

  Erik