Subject: [Softwires] Chair input on 6rd/MTU discussion

From: "Durand, Alain" <[email-masked]>
Date: Mon, 15 Mar 2010 21:40:47 -0400

Wg,
> 
> As chairs, We¹ve been looking at the MTU thread on 6rd. There has been many
> good points made and we have had an healthy discussion. It is now time to move
> on with the base spec. MTU is one of the many operational issues with 6rd. The
> chairs and the authors discussed a while back to have a companion document to
> 6rd that will focus on exactly those operational considerations. We do believe
> that the 6rd MTU discussion belongs there.
> In order to not tie the hands of that new document, it will be better if the
> base spec were to remain silent on the MTU issue.
> This future operational document should be focused on 6rd and not try to solve
> the generic tunneling MTU discussion.
> The generic work is important too, and certainly need to find a home. However
> this is a different topic, for future discussions with our ADs.
> 
   - Alain & David.

---

From: Mark Townsley <[email-masked]>
Date: Tue, 16 Mar 2010 03:06:02 +0100

I agree that the Tunnel-MTU derived method is not perfect by any means, 
but it does represent the most agreed-upon compromise in terms of 
implementation and running code at this time. It's a shame to have lost 
that fact from the RFC today, as I doubt that we are going to finish 
solving the generic issue in time for 6rd deployments to begin. C'est la 
vie.

- Mark

On 3/16/10 2:40 AM, Durand, Alain wrote:
> Wg,
>
>
>     As chairs, We’ve been looking at the MTU thread on 6rd. There has
>     been many good points made and we have had an healthy discussion.
>     It is now time to move on with the base spec. MTU is one of the
>     many operational issues with 6rd. The chairs and the authors
>     discussed a while back to have a companion document to 6rd that
>     will focus on exactly those operational considerations. We do
>     believe that the 6rd MTU discussion belongs there.
>     In order to not tie the hands of that new document, it will be
>     better if the base spec were to remain silent on the MTU issue.
>     This future operational document should be focused on 6rd and not
>     try to solve the generic tunneling MTU discussion.
>     The generic work is important too, and certainly need to find a
>     home. However this is a different topic, for future discussions
>     with our ADs.
>
> - Alain & David.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 16 Mar 2010 10:42:54 -0700

Alain and David,

I agree that 6rd has many operational limitations. I pointed out several that
have not yet been fully addressed:

  http://www.ietf.org/mail-archive/web/softwires/current/msg01263.html

That means that 6rd needs to have an applicability statement as part of
its base document, as was required for transition mechanisms developed
in the ngtrans and early phases of v6ops days.

Fred
[email-masked]

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Durand, Alain
Sent: Monday, March 15, 2010 6:41 PM
To: softwires
Cc: Ole Troan
Subject: [Softwires] Chair input on 6rd/MTU discussion

Wg,

As chairs, We've been looking at the MTU thread on 6rd. There has been many good points made and we have had an healthy discussion. It is now time to move on with the base spec. MTU is one of the many operational issues with 6rd. The chairs and the authors discussed a while back to have a companion document to 6rd that will focus on exactly those operational considerations. We do believe that the 6rd MTU discussion belongs there.
In order to not tie the hands of that new document, it will be better if the base spec were to remain silent on the MTU issue.
This future operational document should be focused on 6rd and not try to solve the generic tunneling MTU discussion.
The generic work is important too, and certainly need to find a home. However this is a different topic, for future discussions with our ADs.
  - Alain & David.