dear Alain, Yong, Ralph and all, in program, the effort of the MAP team should be respected. The formation of the MAP team was also the consensus of our meeting in beijing and we have seen the the team is working with clear progress. I don't think it is correct now to insert 4rd-u into a sort of exclusive decision of choice. And 4rd-u also has the address format elements abondoned by the MAP design team. I believe the MAP format reflects that the common understanding concludes the insignificance of those features. Sorry but the chair's questions a little confused me: if we need to go back to the stage before the works of the MAP design team?
The MAP series have reached running codes and the collective understanding of the community. From a view of a middle-sized ISP and cloud service provider, we do support to accept MAP series into standard track in order we can utilize it into business as soon as possible. in technology, first of all, MAP now has approached address mapping algorithm and that enough to make the series a unified solution. In our practice, we need to use either encapsulation or translation according to the actual needs and environment. The most important is, both the building blocks of transition architecture: virtual link (supported by encapsulation/tunneling) and participant of the delivery path (supported by translation), have their suitable use cases. And their advantages and limitations have been well investigated and understood by the community. second, i deeply discussed and explored 4rd-u, but i found its attempting of mixing the tunneling and translation, if accepted as standard, may trap the operators into a harsh situation of being unable to define what building block it really is. It is stated as tunneling but actually behaves like tunnel in some aspects while like translation in some other aspects. (I have pointed out in the 4rd-u discussion thread). We see it only a yet-another-translation that try to solve some corner problems but introduces new, possibly major flaws (also pointed out in the technical threads on 4rd.) In either the term of architectural philosophy or technical details, introducing 4rd-u into standards would be harmful. personally, i respect the exploration of the author(s), and the discussion between me and the author encouraged me to comprehensively review E and T, and the result is: i bacame much more confident of the correctness of the MAP track. We should move forward. regarding the chair's questions, my answer is: MAP, MAP-E/T, MAP-DHCP are of a whole suite needing to be put into standard track. Question is not about T, E or U. best regards, Maoke 在 2012年3月20日星期二，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 > [email protected] <javascript:;> > https://www.ietf.org/mailman/listinfo/softwires >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
