Subject: Re: [Softwires] Path to move forward with 4rd…

From: Guanghui Yu <[email-masked]>
Date: Thu, 22 Mar 2012 20:26:40 +0800

Hi all
    This mail raises a very important issue. MAP-T and MAP-E are not
competing technologies. They have different user scenarios. I read 4rd-u
draft and found it is flawed. I will not support the adoption of 4rd-u,
since there is no running code and there is no experimental evaluation. In
summary, 4rd-U is not in the same level of MAP series and it should not be
considered for adoption in coming Paris IETF meeting.

PS: I'am sorry if this mail sends more than one time, the mail system of
our university may have problems with this mail list today.

Yu Guanghui <ygh at dlut.edu.cn>
Network and Information Center
Dalian University of Technology, China
Tel: +86 411 84708117

在 2012-3-21，下午9:39， Xing Li 写道：

Hi, Alain, Yong and Ralph,

The newly posted agenda does not match the consensus as you mentioned on 6
Oct 2011, that “multiple address and port mapping technologies could and
should converge” and you formally announced “the creation of the MAP
(Mapping of Addresses and Ports) design team”, a design team which “is
tasked to formulate a unified format to be used either in an encapsulation
or double translation mode” (
http://www.ietf.org/mail-archive/web/softwires/current/msg03024.html). For
the past few months, the design team has produced a series of MAP
documents, including MAP, MAP-E, MAP-T, MAP-dhcp, etc. The mailing-list has
also showed positive feedback on the adoption of the MAP series as the
standard track of working group documents. Moreover, the dIVI (an earlier
version of MAP-T) has been running successfuly at CERNET2 for two years now.

4rd-U was submitted later, and the goal is to replace the MAP Series. There
have been discussions in the mailing list, but the discussions are mainly
questions concerning the 4rd-U proposal. Actually, 4rd-U is still in the
early design stage. Due to its proposed modification of the IPv6
architecture (V-Oct and the fragmentation header), the discussion should be
extended at least to 6man WG before the Softwire WG makes any decision of
adoption. Furthermore, experimental data should be presented to the WG to
show that these modifications are not harmful. In addition, the
fragmentation header modifications actually only deal with a very corner
case of double translation (10e-5% of the packets, not production traffic).

Therefore, I don’t think we have any reason to change the procedure and in
the coming meeting, we should discuss whether consensus can be reached for
the adoption of the MAP series. We should discuss whether 4rd-U can be
adopted in a later meeting when it gets proved by 6man and its
modifications are proved to be not harmful by experimental data.

Regards,

xing

于 2012/3/20 7:38, Alain Durand 写道:

Dear wg,

After a number of discussions with my co-chair, our AD and various
authors, here is how we would like to move forward wrt 4rd.

1) There  is an observation that all the solutions on the table E, T &
U actually solve the stateless  problem we started with.
    There are differences, but it is unclear if those differences are
really significant. E and T are the original Encapsulation and
Translation
    proposals, U is an hybrid unifying solution.

2) We have already agreed back in Beijing that we would publish all
necessary documents. The issue here is the 'label' or 'status' those
    documents have at IETF. In particular, do we want to publish them
as Experimental, Informational or Standard Track.

We are at the point now where we need to make progress. In Paris, we
would like to ask for presentations from the proponents of each
candidate solution (E, T & U).
Each presentation should cover an overview of the proposed solution,
explain how it compares to the others and make a case as why it should
be the one on the Standard Track. We will allocate 20 minutes for each
presentation.

Then, we, chairs, would like to ask a series of questions to the
working group. In order to make this process transparent, here is the
list of questions we want to ask
and their sequence.

Q1: Without pre-supposing which one will be selected, do you agree to
publish 1 of the 3 proposals on the Standard Track and publish the
other(s) as Informational if still asked to?

If the answer is NO, then the process stops and we will publish
everything as Experimental and come back in 12-24 months to see what
gets adopted by the market.
If the answer is YES, we move to the next question.

Q2: Do you believe that the WG should publish U as the one Standards
Track document?

If the answer is YES, the process stop, we put U on the Standard Track
and publish E & T as Informational.
If the answer is NO, we are left with E & T (U then might be abandoned
or published as Historical/Informational)

Q3: Which of E and T do you want to see moving on the standard track
(you can only express support for one)?

If there is a clear outcome from this question, we would publish that
proposal on the Standard Track and the other one as Informational.
If there is no clear consensus on this question, we will publish both
E & T as Experimental.

In the meantime, we would like to encourage discussion on the mailing
list to foster our common understanding of the various technologies
and how they relate to each other.

  Alain & Yong, wg co-chairs.
_______________________________________________
Softwires mailing
[email-masked]://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 23 Mar 2012 02:10:09 +0000

Hi Guanghui,

I agree that both MAP and 4rd-u are similar technology and solving the same
problem. From technical perspective, can you elaborate this a lithe bit?

Thanks,
Yiu

From:  Guanghui Yu <[email-masked]>
Date:  Thu, 22 Mar 2012 20:26:40 +0800
To:  Softwires WG <[email-masked]>
Subject:  Re: [Softwires] Path to move forward with 4rdŠ

I read 4rd-u draft and found it is flawed.

---

From: Guanghui Yu <[email-masked]>
Date: Fri, 23 Mar 2012 11:04:54 +0800

Hi Yiu

   4rd-u changes the IPv6 header architecture (redefine
fragmentation header extension) and IPv6 address architecture (different
meaning of u-bit when g-bit=1). These are the fundamental changes. If 4rd-u
becomes the standard, then there will be new defined “IPv6” packets on
the Internet, which are not compatible with existing IPv6 packets and
no existing devices can understand those packets.

On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu <[email-masked]>wrote:

> Hi Guanghui,
>
> I agree that both MAP and 4rd-u are similar technology and solving the
> same problem. From technical perspective, can you elaborate this a lithe
> bit?
>
> Thanks,
> Yiu
>
> Subject: Re: [Softwires] Path to move forward with 4rd…
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 23 Mar 2012 04:55:10 +0000

Hi Guanghui,

I have to admit that I am not IPv6 protocol expert. I guess Remi took the
fragmentation header and overload it  for his design. Say he defines a new
extension called "transition" extension, I would guess it would no longer
overload the fragmentation extension. I don't know enough the current
implementation of the FIB and how <u,g> in 4rd-u design would impact the
implementation. I have homework to do.

Apart from that, I found MAP and 4rd-u are similar technologies trying to
solve the same problem. So far I follow all the discussions in the mailing
list about this topics. Technically speaking, they have pros and cons. I
fail to see one is absolutely superior than the other. Both designs make
trade-offs.  
 
When we come to WG adoption, I am completely fine if the WG decides one over
the other. That said, the current discussion reminds me about OSPF vs IS-IS.
They are so similar but yet have subtle differences. Today, both protocols
are running in production. Best case scenario is the authors can balance the
trade-offs and merge two drafts. If not WG could potentially publish both
techs (e.g. one standard track and one informational/experimental) and let
the market force to decide.

B.R.,
Yiu

P.S. When I say MAP, I mean all 3 drafts (T/M/A+P). I see them one complete
series.

From:  Guanghui Yu <[email-masked]>
Date:  Fri, 23 Mar 2012 11:04:54 +0800
To:  "Yiu L. LEE" <[email-masked]>
Cc:  Softwires WG <[email-masked]>
Subject:  Re: [Softwires] Path to move forward with 4rdŠ

Hi Yiu

   4rd-u changes the IPv6 header architecture (redefine fragmentation header
extension) and IPv6 address architecture (different meaning of u-bit when
g-bit=1). These are the fundamental changes. If 4rd-u becomes the standard,
then there will be new defined "IPv6" packets on the Internet, which are not
compatible with existing IPv6 packets and no existing devices can understand
those packets.

Yu Guanghui <ygh at dlut.edu.cn <http://dlut.edu.cn> >
Network and Information Center
Dalian University of Technology, China

On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu <[email-masked]>
wrote:
> Subject:  Re: [Softwires] Path to move forward with 4rd...
>

---

From: Guanghui Yu <[email-masked]>
Date: Fri, 23 Mar 2012 13:43:07 +0800

Hi all
      To define the "transtion" extension has the same problem,  it still
is a "new" packet for existing devices.
      4rd-U cannot replace MAP-T, since it cannot support single
translation. 4rd-U cannot replace MAP-E, since it cannot support IPv4
option. Therefore, it is no way for 4rd-U to replace MAP series. BTW, we
need both encapsulation and translation, i.e. MAP-E and MAP-T.

On Fri, Mar 23, 2012 at 12:55 PM, Lee, Yiu <[email-masked]>wrote:

> When we come to WG adoption, I am completely fine if the WG decides one
> over the other. That said, the current discussion reminds me about OSPF vs
> IS-IS. They are so similar but yet have subtle differences. Today, both
> protocols are running in production. Best case scenario is the authors can
> balance the trade-offs and merge two drafts. If not WG could potentially
> publish both techs (e.g. one standard track and one
> informational/experimental) and let the market force to decide.
>
> B.R.,
> Yiu
>
> P.S. When I say MAP, I mean all 3 drafts (T/M/A+P). I see them one
> complete series.
>
>

--

---

From: "Zhang Huanjie" <[email-masked]>
Date: Fri, 23 Mar 2012 14:06:50 +0800 (CST)

4rd-U is in the very early design stage, there is no running code. In addition, it tries to modify the IPv6 address architecture. We need to see the experimental data before making any decision.

--
Zhang Huanjie
E-mail/msn: [email-masked]

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 22 Mar 2012 23:33:00 -0700

Is there experimental data for MAP running on production networks?
Certainly that is an important point to consider.

On 3/22/12 11:06 PM, "Zhang Huanjie" <[email-masked]> wrote:

>
>
>4rd-U is in the very early design stage, there is no running code. In
>addition, it tries to modify the IPv6 address architecture. We need to
>see the experimental data before making any decision.
>
>--
>Zhang Huanjie

---

From: GangChen <[email-masked]>
Date: Fri, 23 Mar 2012 15:49:09 +0800

Hello Guanghui,

2012/3/23, Guanghui Yu <[email-masked]>:
> translation.

I guess the concern of "single translation" has already been addressed
 in http://www.ietf.org/mail-archive/web/softwires/current/msg03724.html

BRs

Gang

>4rd-U cannot replace MAP-E, since it cannot support IPv4

---

From: Ole Trøan <[email-masked]>
Date: Fri, 23 Mar 2012 10:28:39 +0100

Yiu,

> I have to admit that I am not IPv6 protocol expert. I guess Remi took the fragmentation header and overload it  for his design. Say he defines a new extension called "transition" extension, I would guess it would no longer overload the fragmentation extension. I don't know enough the current implementation of the FIB and how <u,g> in 4rd-u design would impact the implementation. I have homework to do.

Type 3 Routing Header?
we've tried this type of tunneling before. ;-)

> Apart from that, I found MAP and 4rd-u are similar technologies trying to solve the same problem. So far I follow all the discussions in the mailing list about this topics. Technically speaking, they have pros and cons. I fail to see one is absolutely superior than the other. Both designs make trade-offs.  
>  
> When we come to WG adoption, I am completely fine if the WG decides one over the other. That said, the current discussion reminds me about OSPF vs IS-IS. They are so similar but yet have subtle differences. Today, both protocols are running in production. Best case scenario is the authors can balance the trade-offs and merge two drafts. If not WG could potentially publish both techs (e.g. one standard track and one informational/experimental) and let the market force to decide.

the authors did already do that. the dIVI and 4rd authors met 16th of November at the last IETF.
we collectively went through the complete feature list. the result is what you find in the MAP document series.

Remi, who was also at that meeting, later came up with a different solution and new features and decided to create a competing proposal. MAP is largely original 4rd and dIVI, considering its roots. there has been a continuing exchange of ideas and improvement of the proposals. Remi's latest 4rd-U proposal largely represents all the functions that there was no support for in the MAP design team. I do not think attempting yet another merger will be a good use of our time.

> P.S. When I say MAP, I mean all 3 drafts (T/M/A+P). I see them one complete series.

yes, that makes sense.
OK, what if we try this: MAP is a unified solution consisting of two transport modes (T/E), a provisioning (DHCP) and a deployment document.

then we can pick between MAP and 4rd-U. the winner gets published on standards track. the looser gets documented as informational for the purpose of historical reference.

cheers,
Ole

---

From: Congxiao Bao <[email-masked]>
Date: Fri, 23 Mar 2012 18:04:47 +0800

Hi Penno,

MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2
for two years and have been tested at China Telcom both in Beijing and
Hunan last year. In addition, the dIVI-PD was demonstrated successfully in
Softwire Interim Meeting in Beijing last September. BTW, the MAP-T code
will be available soon.

Congxiao

2012/3/23 Reinaldo Penno <[email-masked]>

---

From: "Zhang Huanjie" <[email-masked]>
Date: Fri, 23 Mar 2012 18:35:07 +0800 (CST)

I have been running single translation (IVI) for one year and have
tested divi in the same environment by cascading second translator
successfully.

> -----Original E-mail-----
> From: "Reinaldo Penno" <[email-masked]>
> Sent Time: 2012-3-23 14:33:00
> To: "Zhang Huanjie" <[email-masked]>, "Softwires WG" <[email-masked]>
> Cc: 
> Subject: Re: [Softwires] Path to move forward with 4rd
> 

--
张焕杰  E-mail/msn: [email-masked]   
安徽省合肥市金寨路96号  中国科学技术大学网络信息中心 (230026) 
Mobile: +86-13505693311   Tel: +86-551-3601897

---

From: Rémi Després <[email-masked]>
Date: Fri, 23 Mar 2012 11:35:24 +0100

Le 2012-03-22 à 13:26, Guanghui Yu a écrit :

> Hi all 
>     This mail raises a very important issue. MAP-T and MAP-E are not competing technologies. They have different user scenarios.

> I read 4rd-u draft and found it is flawed.

Please explain what, in your understanding, would be flawed. 

> I will not support the adoption of 4rd-u, since there is no running code and there is no experimental evaluation.

The theory of Reversible header mapping is so simple that, AFAIK, nobody with implementation experience would negate that it will work when tested. 
Other features of the U proposal may be debated, but they are not necessary to replace T and E by a solution that is suitable for use cases of these two.  

> In summary, 4rd-U is not in the same level of MAP series

Would you claim that there are no inconsistencies today in the MAP set of drafts?
Actually, the U draft is more complete and self consistent than the set of MAP documents.

Regard,
RD

> and it should not be considered for adoption in coming Paris IETF meeting.
> 
> PS: I'am sorry if this mail sends more than one time, the mail system of our university may have problems with this mail list today.
> 
>> The newly posted agenda does not match the consensus as you mentioned on 6 Oct 2011, that “multiple address and port mapping technologies could and should converge” and you formally announced “the creation of the MAP (Mapping of Addresses and Ports) design team”, a design team which “is tasked to formulate a unified format to be used either in an encapsulation or double translation mode” (http://www.ietf.org/mail-archive/web/softwires/current/msg03024.html). For the past few months, the design team has produced a series of MAP documents, including MAP, MAP-E, MAP-T, MAP-dhcp, etc. The mailing-list has also showed positive feedback on the adoption of the MAP series as the standard track of working group documents. Moreover, the dIVI (an earlier version of MAP-T) has been running successfuly at CERNET2 for two years now.
>> 
>> 4rd-U was submitted later, and the goal is to replace the MAP Series. There have been discussions in the mailing list, but the discussions are mainly questions concerning the 4rd-U proposal. Actually, 4rd-U is still in the early design stage. Due to its proposed modification of the IPv6 architecture (V-Oct and the fragmentation header), the discussion should be extended at least to 6man WG before the Softwire WG makes any decision of adoption. Furthermore, experimental data should be presented to the WG to show that these modifications are not harmful. In addition, the fragmentation header modifications actually only deal with a very corner case of double translation (10e-5% of the packets, not production traffic).
>> 
>> Therefore, I don’t think we have any reason to change the procedure and in the coming meeting, we should discuss whether consensus can be reached for the adoption of the MAP series. We should discuss whether 4rd-U can be adopted in a later meeting when it gets proved by 6man and its modifications are proved to be not harmful by experimental data.
>> 
>> Regards,
>> 
>> xing
>>  
>> 
>> 
>>> After a number of discussions with my co-chair, our AD and various authors, here is how we would like to move forward wrt 4rd.
>>> 
>>> 1) There  is an observation that all the solutions on the table E, T & U actually solve the stateless  problem we started with.
>>>     There are differences, but it is unclear if those differences are really significant. E and T are the original Encapsulation and Translation
>>> 2) We have already agreed back in Beijing that we would publish all necessary documents. The issue here is the 'label' or 'status' those
>>>     documents have at IETF. In particular, do we want to publish them as Experimental, Informational or Standard Track.
>>> 
>>> We are at the point now where we need to make progress. In Paris, we would like to ask for presentations from the proponents of each candidate solution (E, T & U).
>>> Each presentation should cover an overview of the proposed solution, explain how it compares to the others and make a case as why it should be the one on the Standard Track. We will allocate 20 minutes for each presentation.
>>> 
>>> Then, we, chairs, would like to ask a series of questions to the working group. In order to make this process transparent, here is the list of questions we want to ask
>>> and their sequence.
>>> 
>>> Q1: Without pre-supposing which one will be selected, do you agree to publish 1 of the 3 proposals on the Standard Track and publish the other(s) as Informational if still asked to?
>>> 
>>> If the answer is NO, then the process stops and we will publish everything as Experimental and come back in 12-24 months to see what gets adopted by the market.
>>> Q2: Do you believe that the WG should publish U as the one Standards Track document?
>>> 
>>> If the answer is YES, the process stop, we put U on the Standard Track and publish E & T as Informational.
>>> If the answer is NO, we are left with E & T (U then might be abandoned or published as Historical/Informational)
>>> 
>>> 
>>> Q3: Which of E and T do you want to see moving on the standard track (you can only express support for one)?
>>> 
>>> If there is a clear outcome from this question, we would publish that proposal on the Standard Track and the other one as Informational.
>>> If there is no clear consensus on this question, we will publish both E & T as Experimental.
>>> 
>>> In the meantime, we would like to encourage discussion on the mailing list to foster our common understanding of the various technologies and how they relate to each other.
>>>

---

From: Rémi Després <[email-masked]>
Date: Fri, 23 Mar 2012 12:21:20 +0100

> tested divi in the same environment by cascading second translator

1.
Draft U-03 (Dec 29) raised the issue of reassembly of packets from shared-address CEs, with a solution.
Draft E-01 (Jan 27) dealt with the issue. It described a simpler solution, also used in U-05 (March 12)
Draft T deals with the subject (although the issue is real and must be dealt with).

The current Draft T is therefore clearly incomplete, and tests were unable to show it.
Similarly, it has been acknowledged that MAP as is doesn't support hub&spoke (a DHCP parameter is missing). No experiment has found it.

2.
Understanding that reversible header mapping is more transparent than double translation needs no experiment.

RD

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 23 Mar 2012 05:10:28 -0700

Thank you.  I believe the answer to my question is  'no'.

Still, it is good to see that you are planning to deploy MAP-T.  It is
certainly an important data point.

Do you plan to substitute dIVI and dIVI-PD by MAP-T or run them in parallel?

From:  Congxiao Bao <[email-masked]>
Date:  Fri, 23 Mar 2012 18:04:47 +0800
To:  Cisco Employee <[email-masked]>
Cc:  Zhang Huanjie <[email-masked]>, Softwires WG <[email-masked]>
Subject:  Re: [Softwires] Path to move forward with 4rd

Hi Penno,
 
MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2
for two years and have been tested at China Telcom both in Beijing and Hunan
last year. In addition, the dIVI-PD was demonstrated successfully in
Softwire Interim Meeting in Beijing last September. BTW, the MAP-T code will
be available soon.
 
Congxiao

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 23 Mar 2012 13:26:48 +0100

Hi,

> Thank you.  I believe the answer to my question is  'no'.

divi and divi-pd and MAP-T are essentially the same, algorithmically, ie
with the MAP algorithm and certain paramaters set (eg M=1) they are the
same. The difference of "on-the-wire" encoding would not appear to have any
tangible effect on experimental data collected for divi.
Eg http://tools.ietf.org/html/draft-sunq-v6ops-ivi-sp-02

-Woj.

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 23 Mar 2012 05:40:09 -0700

From:  Wojciech Dec <[email-masked]>
Date:  Fri, 23 Mar 2012 13:26:48 +0100
To:  Cisco Employee <[email-masked]>
Cc:  Congxiao Bao <[email-masked]>, Softwires WG <[email-masked]>
Subject:  Re: [Softwires] Path to move forward with 4rd

Hi,

[RP] Interesting, thanks for the clarification. Can dIVI and MAP-T
hosts/CPEs interoperate given they are essentially the same?

[RP] I will read it and provide feedback. Thanks for the pointer.

-Woj.
> MAP-T was derived from dIVI and dIVI-PD, which has been running at CERNET2 for
> two years and have been tested at China Telcom both in Beijing and Hunan last
> year. In addition, the dIVI-PD was demonstrated successfully in Softwire
> Interim Meeting in Beijing last September. BTW, the MAP-T code will be
> available soon.
>  
> Congxiao
> 
>

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 23 Mar 2012 14:01:59 +0100

> hosts/CPEs interoperate given they are essentially the same?

Well, MAP-T and divi-pd in non-address-sharing mode (ie 1:1) should be
totally compatible. However, given that the "on-the-wire" encoding of the
PSID is different in the address sharing mode, interoperability in that
mode won't be there.

Cheers,
Woj.

>> MAP-T was derived from dIVI and dIVI-PD, which has been running at
>> CERNET2 for two years and have been tested at China Telcom both in Beijing
>> and Hunan last year. In addition, the dIVI-PD was demonstrated successfully
>> in Softwire Interim Meeting in Beijing last September. BTW, the MAP-T code
>> will be available soon.
>>
>> Congxiao
>>
>>

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 23 Mar 2012 14:24:22 +0000

Hi Guanghui,

Just curious, how common IPv4 option is used these days? I don't have any
data in-hand.

Thanks,
Yiu

Date:  Fri, 23 Mar 2012 13:43:07 +0800

it cannot support IPv4 option.

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 23 Mar 2012 14:28:56 +0000

Hi Guanghui,

Is the original use case for MAP is to deliver v4 over v6 in a stateless
fashion in the network? This is stated in the stateless-requirements draft.
If we can get v4-v6 (single translation) for free, I am all for it. But this
isn't the original requirements we are trying to solve. Right?

Thanks,
Yiu

 4rd-U cannot replace MAP-T, since it cannot support single translation.

---

From: Rémi Després <[email-masked]>
Date: Fri, 23 Mar 2012 18:13:33 +0100

Hi, Guanghui,

Le 2012-03-23 à 04:04, Guanghui Yu a écrit :

> Hi Yiu
> 
>    4rd-u changes the IPv6 header architecture (redefine fragmentation header extension)

4rd-U uses between CEs and BRs an IPv6 packet format that not only is completely authorized, but that is already 
used in double translation: RFC6145 also adds a fragmentation header to some unfragmented packets (sec 4.).

> and IPv6 address architecture (different meaning of u-bit when g-bit=1).

- U builds on the fact that all IPv6 unicast addresses are so far either universal scope (u=1 g=0) or local link scope (u=0 g=any value). This (fortunately) leaves an escape combination for new types of addresses (U is only one of these possible addresses, but the first one).
- A 4rd-U address happens to be partially universal scope (embedded public IPv4 addresses) and partially ISP-domain scope (dependent on ISP defined mapping rules). None of the existing formats is therefore mandatorily applicable.
- Impact on IPv6 address architecture is only a backward compatible extension: no interference is possible with anything that works in conformance with current IPv6 specifications.

> These are the fundamental changes. If 4rd-u becomes the standard, then there will be new defined “IPv6” packets on the Internet, which are not compatible with existing IPv6 packets and

Please see above.

> no existing devices can understand those packets.

Only BRs and CEs need to understand that these packets have IPv4 compatible payloads.

Regards,
RD

> On Fri, Mar 23, 2012 at 10:10 AM, Lee, Yiu <[email-masked]> wrote:
> Hi Guanghui,
> 
> I agree that both MAP and 4rd-u are similar technology and solving the same problem. From technical perspective, can you elaborate this a lithe bit? 
> 
> Thanks,
> Yiu
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 23 Mar 2012 18:28:39 +0000

Hi Wjociech,

So the only different between MAP-T and dIVI-PD is the new PSID calculation
in MAP. Otherwise, they are identical.

Thanks,
Yiu 

From:  Wojciech Dec <[email-masked]>
Date:  Fri, 23 Mar 2012 14:01:59 +0100
To:  Reinaldo Penno <[email-masked]>
Cc:  Softwires WG <[email-masked]>
Subject:  Re: [Softwires] Path to move forward with 4rd

Well, MAP-T and divi-pd in non-address-sharing mode (ie 1:1) should be
totally compatible. However, given that the "on-the-wire" encoding of the
PSID is different in the address sharing mode, interoperability in that mode
won't be there.

Cheers,
Woj.

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 23 Mar 2012 22:22:26 +0000

Hi Ole,

Technically, I think it now comes down to one question to debate between
MAP-T and 4rd-u. Btw reservable header and double-translation, what
technology better serves the requirements. Do you agree?

Thanks,
Yiu

On 3/23/12 5:28 AM, "Ole Trøan" <[email-masked]> wrote:

>Remi, who was also at that meeting, later came up with a different
>solution and new features and decided to create a competing proposal. MAP
>is largely original 4rd and dIVI, considering its roots. there has been a
>continuing exchange of ideas and improvement of the proposals. Remi's
>latest 4rd-U proposal largely represents all the functions that there was
>no support for in the MAP design team. I do not think attempting yet
>another merger will be a good use of our time.
>

---

From: Rémi Després <[email-masked]>
Date: Sat, 24 Mar 2012 09:23:01 +0100

> we collectively went through the complete feature list. the result is what you find in the MAP document series.

 This MAP meeting was immediately after the Taipei Softwire meeting. At this meeting, with an invalid technical argument, you had convinced most participants that -U couldn't work, so that a majority didn't believe the -U approach could be useful. 
 During this MAP meeting, a majority consequently expressed no interest in considering further, for MAP, new features that were part of the -U proposal (Reversible header mapping; Checksum neutrality, AKA CNP; Distinguishable address format, AKA V octet).
 
 After you had acknowledged on the WG list that, contrary to the technical argument made during the meeting, -U could work, the chair encouraged a separate work on -U. (On nov 29, Alain wrote to me, with copy on the WG ML, "I'd like to encourage you to keep working on 4rd-u and come back next meeting in Paris"). 
 Knowing that a majority expressed during an informal and unscheduled meeting of MAP contributors is in no way a full WG consensus, this was a fair decision.

> then we can pick between MAP and 4rd-U. the winner gets published on standards track. the looser gets documented as informational for the purpose of historical reference.

As already said, if MAP-T and/or MAP-E is standardized, I see no point in confusing people with, in addition, a -U RFC.
The ONLY purpose of -U is having simultaneously -E transparency and -T IPv6 compatibility.
It is NOT to multiply RFCs.

Chers,
RD

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Sat, 24 Mar 2012 17:29:43 +0100

On 3/23/12 4:04 AM, Guanghui Yu wrote:
> meaning of u-bit when g-bit=1). These are the fundamental changes. If
> 4rd-u becomes the standard, then there will be new defined “IPv6”
> packets on the Internet, which are not compatible with existing IPv6
> packets and no existing devices can understand those packets.

Exactly.

+1

Cheers, Jan Zorz

---

From: Rémi Després <[email-masked]>
Date: Sat, 24 Mar 2012 17:58:25 +0100

Hi, Jan,

Please see my answer to Guanghui.

Thanks,
RD

---

From: Ole Trøan <[email-masked]>
Date: Sun, 25 Mar 2012 07:31:37 +0200

Remi,

> This MAP meeting was immediately after the Taipei Softwire meeting. At this meeting, with an invalid technical argument, you had convinced most participants that -U couldn't work, so that a majorit…

that's not quite how I remember it. there were a number of issues discussed with 4rd-U.
 - destination spread, caused by Max PSID, CNP (I was wrong about CNP causing destination spread).
 - V-octet; implications
 - how -U achieves transparency by overloading information in the fragmentation header

> During this MAP meeting, a majority consequently expressed no interest in considering further, for MAP, new features that were part of the -U proposal (Reversible header mapping; Checksum neutralit…

the MAP effort has focused on the mandatory functionality and features only.

all the "features" between 4rd-U and MAP are interchangeable. in this instance I do believe "less is more" though.
the distinguishing part of 4rd-U is that is uses a different form of translation than what MAP does.

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Sun, 25 Mar 2012 09:43:12 +0200

> - how -U achieves transparency by overloading information in the fragmentation header

No contradiction.
- Destination spread was claimed to be caused by CNP. 
- Max PSID was unanimously abandoned during you meeting.
- Your (invalid) objection to CNP was maintained, with no time to argue about it, so that you got a majority vote for not considering CNP anymore in the MAP team. 

> the distinguishing part of 4rd-U is that is uses a different form of translation than what MAP does.

Whatever you call it, its virtue is that:
- it never modifies payloads
- it completely restores IPv4 headers (except for IPv4 options, but these are not needed for IPv4 applications).
Double RFC6145 translation, as you brilliantly explained yourself in Beijing, sometimes breaks e2e transparency. 

Cheers,
RD

---

From: Guanghui Yu <[email-masked]>
Date: Mon, 26 Mar 2012 07:52:24 +0800

Hi Yiu
   According to our experimental data, it is very small . But Please note
that the experimental data also shows that the ratio of packet labeled
"DF=1 and MF=1” among total packet is 1.1E-5. 4rd-U insists to claim to
have a better end-to-end behavior than MAP-T, but it just serves for a
corner case.

---

From: Guanghui Yu <[email-masked]>
Date: Mon, 26 Mar 2012 07:53:15 +0800

Hi Yiu

Please read MAP-Thttp://tools.ietf.org/html/draft-mdt-softwire-map-translation-01#section-8.3

On Fri, Mar 23, 2012 at 10:28 PM, Lee, Yiu <[email-masked]>wrote:

> If we can get v4-v6 (single translation) for free, I am all for it. But
> this isn't the original requirements we are trying to solve. Right?
>
> Thanks,
> Yiu
>

---

From: Kevin Y <[email-masked]>
Date: Mon, 26 Mar 2012 16:50:57 -0500

Hi, Remi,

This is beyond the charter of softwire WG, changing IPv6 address format
needs much broad discussion in IETF community to understand its impact
first, before we should even discuss if it is valid to design something
like this in softwire.   Have you done that ?

Best Regards,

Kevin Yin

---

From: GangChen <[email-masked]>
Date: Tue, 27 Mar 2012 15:53:29 +0800

Hello Kevin and all,

I actually see current multiple solution proposal from different
angle. Regarding the changes you mentioned, MAP-T/E is also doing
that, e.g. added fragmentation header to survive DF bit; change ICMP
ID filed to carry the port information.

4rd-U doesn't beat MAP-series. I prefer to understand the situation is
4rd-U raised some points(e.g. CNP, Fully IPv4 transparency) which is
desirable heading to a perfect protocol design.

BRs

Gang

2012/3/27, Kevin Y <[email-masked]>:
>> 4rd-u

---

From: "Jiang Dong" <[email-masked]>
Date: Tue, 27 Mar 2012 17:19:28 +0800

Hi Gang and all,

I think there are some points need to be considered between MAP series and 4rd-U.

4rd-U saids "IPv4 headers can be reversibly mapped into IPv6 headers so that 4rd tunnel packets can be designed to be valid IPv6 packets" in Section I. In my understanding, the difference between 4rd-u and MAP-E is "IPv6 fragment header vs IPv4 header". Both 4rd-U and MAP-E can keep the transparency, while 4rd-U reserves 12 bytes to improve the efficiency and MAT-E has some IPv4 redundancy octets but keep the original IP-IP encapsulation which is easy to be operated.

Comparing with MAP-E, 4rd-U keeps the DF bit, TOS and so on with an additional IPv6 fragment header, which incurs reusing IPv6 option 44.

If 4rd-U can be considered as a tunneling technique, the question is: does it deserve adding the IPv6 fragment header in order to save 12 bytes efficiency each packet?

If 4rd-U can be considered as a translation technique, the question is: does it deserve adding the IPv6 fragment header in order to keep transparency?

Regards!
Jiang Dong
Tsinghua University
2012-03-27

From: GangChen
Date: 2012-03-27 15:53
To: Kevin Y
CC: Softwires WG
Subject: Re: [Softwires]Path to move forward with 4rdŠ
Hello Kevin and all,

BRs

Gang

2012/3/27, Kevin Y <[email-masked]>:
>> becomes the standard, then there will be new defined 揑Pv6?packets on
>>> Subject: Re: [Softwires] Path to move forward with 4rd?
>>>

---

From: GangChen <[email-masked]>
Date: Wed, 28 Mar 2012 00:30:49 +0800

2012/3/27, Jiang Dong <[email-masked]>:
> 4rd-U saids "IPv4 headers can be reversibly mapped into IPv6 headers so that
> 4rd tunnel packets can be designed to be valid IPv6 packets" in Section I.
> In my understanding, the difference between 4rd-u and MAP-E is "IPv6
> fragment header vs IPv4 header". Both 4rd-U and MAP-E can keep the
> transparency, while 4rd-U reserves 12 bytes to improve the efficiency and
> MAT-E has some IPv4 redundancy octets but keep the original IP-IP
> encapsulation which is easy to be operated.
>
> Comparing with MAP-E, 4rd-U keeps the DF bit, TOS and so on with an
> additional IPv6 fragment header, which incurs reusing IPv6 option 44.
>
> If 4rd-U can be considered as a tunneling technique, the question is: does
> it deserve adding the IPv6 fragment header in order to save 12 bytes
> efficiency each packet?

Not just bits saving, but also capable of indentification with IPv6
address. Please see more detailed at
draft-despres-softwire-stateless-analysis-tool-01

> If 4rd-U can be considered as a translation technique, the question is: does
> it deserve adding the IPv6 fragment header in order to keep transparency?

See above draft to get more information on comparision. BTW,
fragmentation header is in common for MAP-T and 4rd-U.

BRs

Gang

---

From: "Jiang Dong" <[email-masked]>
Date: Wed, 28 Mar 2012 15:51:43 +0800

Hi Gang,

Thanks for your reply. Please see in lines.

Regards!
Jiang Dong
Tsinghua University
2012-03-28

From: GangChen
Date: 2012-03-28 00:30
To: jiangdong345
CC: Kevin Y; Softwires WG
Subject: Re: [Softwires]Path to move forward with 4rdŠ

[DJ] Thanks, I have read the comparison draft. With the fragmentation header 4rd-U can keep its transparency but MAP-T cannot,  so I think the use of fragmentation header are not the same for MAP-T and 4rd-U, and some compromises may have to be considered.

BRs

Gang