Re: transmech MTU comments

[Fred Templin <osprey67@yahoo.com>]

Erik,

--- Erik Nordmark <Erik.Nordmark@Sun.COM> wrote:
> > My understanding of RFC 3168 is that when the tunnel interface
> > forwards an IPv6 packet to an IPv4 interface with an ECT(0) or ECT(1)
> > codepoint in the traffic class field, it MAY set the codepoint to CE if
> > congestion is experienced. I interpret the MAY to mean that the other
> > option is to drop the packet. If the packet is to be dropped, should it
> > be dropped silently? Also, could a link restriction be considered as
> > congestion? If so, does drop silent also entail NOT sending an
> > ICMPv6 "packet too big" message back to the source?
> 
> My understanding is that larger than MTU is not congestion, that
> packets would not be dropped as an alternative to setting CE, and
> that congestion for tunnels isn't any different than congestion in general.
> 
> What tunnel adds is the question of what the encasulator puts in the ECT
> bits in the outer header (where copying them from the inner header
> makes sense in many cases) and whether the decapulator does anything with
> the received ECT bits in the outer header (and I think that 3168 says
> that unless there are security concerns, copying them from the outer
> to the inner header makes sense).

My only concern in this case is what happens at the decapsulator
if an ECT/CE codepoint is set in the inner header but the outer
header contains Not-ECT. Which one do we trust, in that case,
and should the behavior be documented?
 
> Thus I think the text in the mech document about ECN are sufficient.

Agreed on other fronts except the above.

Fred
osprey67@yahoo.com