Subject: Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt

From: Margaret Wasserman <[email-masked]>
Date: Wed, 14 May 2003 19:56:11 -0400

Hi All,

Erik's message (below) and the current Transition Mechanisms draft
match the agreement of the WG, as of the last time this issue was
discussed.

The chairs have discussed this issue, and we don't believe that the
recent discussion on this topic has demonstrated a consensus to
change the previous decision.  So, we don't think that there is a
need to modify what the document currently says about MTU values
or Path MTU discovery.

If anyone believes that there is a blocking technical issue with
the current document wording, please let us know.  Otherwise, the
document should remain as-is.

Thanks,
Margaret

At 09:24 AM 3/11/2003 +0100, Erik Nordmark wrote:
> > I notice that in the latest draft version, you are no longer requiring an
> > MRU of 4420 bytes in decapsulators and seem to be taking a less
> > aggressive approach in the dynamic MTU discovery in the encapsulator.
> > Can you say more as to the reasons for the change?
>
>This change (the non-need for the 4420 limit) was presented in
>Atlanta even though it was not in the previous version of the draft.
>
>The basic results (which I think were on the slides, or perhaps only
>in the discussion in Atlanta) is that the decapsulator needs to
>support reassembly of up to the max (of its interface MTUs) and 1280+20.
>(There is a note in the spec about it really being its neighbors MTU
>that matter when the MTU != MRU).
>
>Then the encapsulator can choose between the static approach of
>a fixed tunnel MTU of 1280 and DF not set in the IPv4 header, or a dynamic
>tunnel MTU detection using IPv4 path MTU discovery. The latter will never
>result in IPv4 packets at the decapsulator larger than the max of the
>decapsualtor's interface MTUs.
>
>Finally the spec allows for manual configuration to override the 1280 number
>in the static/fixed MTU case, but only if the receiver can handle reassembly
>of the larger IPv4 packets. Thus it requires manual coordination between
>the encapsulator and decapsulator to do this manual override.
>
>   Erik

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 15 May 2003 09:49:38 -0700

Margaret,

The message from Erik you are quoting is out-dated. In his most recent
message to the list, Erik said:

At 02:33PM 04/26/2003 Erik Nordmark wrote:
 > I don't personally have a problem with raising the tunnel MTU in mech-v2
 > from 1280 to 1380.
 > What do others in the WG think?

We were in the middle of a discussion on this subject on the list, and
I had addressed the technical points raised by itojun and Vlad Yasevich.
I find it irregular and indeed unfair that the chairs would go off and
make a private decision while the technical discussion was still taking
place. In short, I object to this action by the chairs.

Fred Templin
[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Thu, 15 May 2003 10:42:38 -0700

> place. In short, I object to this action by the chairs.

Fred,

Let me respectfully disagree with you.
The current discussion does not seem to converge
and I'd like to see this document moving forward.
As this is, with all due respect, not a major issue,
I welcome leadership from the chairs and I say,
let's move on, if not, we'll be here again next year.

	- Alain.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 15 May 2003 18:15:15 -0400

Hi Fred,

>place. In short, I object to this action by the chairs.

I am sorry that you interpreted my message this way.

I have read the discussion, and it appears to me that this is
a situation where one person has made a suggestion to raise the
MTU to 1380, and several people have written back indicating
that there is no reason to make this change.

The current wording in the document was the result of a
much more extensive earlier discussion, and we would need
some new information or technical justifications to warrant
revisiting that decision.

IMO, it is not necessary that the people who would like
the document to remain as-is provide technical justification
for a default MTU of 1280, it is up to you to provide
technical justifications for why a change is necessary.

If there is some new information available that warrants
reconsidering this decision, please let me know what it
is.  Or, if there is a serious technical flaw with the
current wording, please explain.

Also, if there are other people who think that we should
change the default MTU in this document to 1380, please
feel free to speak up and explain why.

Margaret