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.
> 
> 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 list
>>> Softwires@ietf.org
>>> https://www.ietf.org/mailman/listinfo/softwires
>>> 
>> 
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to