Alain, Yong, Ralph,

 First, a little bit of history is IMHO useful to understand where we are:
 1.  At the Beijing meeting, end of September, I started, with Professor Xing 
Li, Wojciech Dec, and Congxiao Bao, a convergence effort based on requirements 
expressed by double-translation and encapsulation proponents respectively (ref 
www.ietf.org/mail-archive/web/softwires/current/msg02994). 
 2. In early October, Alain then entrusted Ole with the task to lead a team  
having "to formulate a unified format to be used either in an encapsulation or 
double translation mode, for both hub & spokes and mesh models" 
(www.ietf.org/mail-archive/web/softwires/current/msg03024)
 3. Working on my own, looking for a stateless solution that would be more 
completely unified than just the address mapping, I found an approach for that, 
called 4rd-U. (Its reversible "header mapping" uses systematic IPv6 fragment 
headers, and TCP-checksum neutrality of mapped addresses. Ref 
draft-despres-softwire-4rd-u-00)
 4. During the Softwire meeting in Taipei, in his report as MAP-team leader, 
Ole had a slide stating that checksum neutrality would result into "destination 
spray" (i.e. would break TCP!). Time lacking for a technical challenge of such 
a claim, this prevented the WG from finding interest in pursuing the 4rd-U 
approach.  
 5. In the MAP-team meeting that immediately followed that of the WG, Ole 
obtained a rough consensus that features of the 4rd-U proposal (checksum 
neutrality and the V octet) would no longer be considered by the MAP team. 
 6. After that, Ole and I having discussed privately, Ole acknowledged on the 
WG list that his statement against checksum neutrality was technically invalid. 
 7. Some interest for looking more at the 4rd-U solution was then reported to 
the chairs, and Alain encouraged me to work on a revised 4rd-U draft for the 
next meeting (ref www.ietf.org/mail-archive/web/softwires/current/msg03296).
 8. On December 29, I then posted 
tools.ietf.org/html/draft-despres-softwire-4rd-u-02. Following comments I had 
received, and accepting that some needs weren't satisfied in draft-02, I posted 
on January 28 draft-03 which has two tunnel variants close to one another 
(4rd-E for encapsulation, 4rd-H for header mapping).
 9. On January 30, Ole announced to the WG that the 4 related MAP documents 
were available (ref www.ietf.org/mail-archive/web/softwires/current/msg03328).

 Thus, people involved in the two approaches have clearly done what they were 
asked to.

 Trying to converge between the two approaches is worth attempting because, as 
Ole recently wrote: "let us make it clear that these two solutions are solving 
exactly the same problem, and they solve it in the same fundamental way (A+P). 
the differences we're talking about here are what whistles, bells (and dongs) 
we want to add on to the base specification. consider it a buffet, any feature 
from one of them can be applied to the other."
 Now, the 4rd-U draft is IMHO the best starting point for a specification that 
suits implementors that didn't participate in the work, because it is 
self-consistent and avoids redundancy. It is also AFAIK much clearer than the 
current set of posted MAP document.

 An example of already achieved convergence is a proposal made by Ole.
 (It concerns the "BR rewrite fragmentation" item of his table of 
www.ietf.org/mail-archive/web/softwires/current/msg03364, i.e. disambiguation 
of datagram identifications in packets that go from shared-address CEs to the 
Internet.)   
 - The need to do something has been identified for the first time in the 
4rd-U-03 draft.
 - Ole's proposed solution is simpler than that of the draft. (The need is 
satisfied directly in CEs, rather than left for BRs to satisfy it.)
 Unless a problem would be identified in the mean time, I will adopt Ole's 
solution in the next 4rd-U version. 

 Naturally, if Ole would agree to it, he would be most welcome as co-author of 
the upgraded unified specification. 


Best regards,
RD



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

Reply via email to