Le 2012-03-22 à 15:40, Maoke a écrit : > 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. Here are some issues among those remaining before reaching "collective understanding": a) T operation in hub&spoke (hasn't been so far answered in an understandable way). b) IDs from shared-address CEs. T currently has so far no solution while both U and E include one. c) MAP-A+P says "Each MAP node in the domain has the same set of rules" while MAP-T says "if a CE knows only a subset of the mapping rules ..." d) Whether T can work with a single mapping rule (as was, I think, the case for IVI). So far DMR and BMR seem exclusive, and there is no way to distinguish them in MAP-dhcp. The fact that no-one involved in the MAP design raised any of these issues is AFAIK sign that MAP has NOT reached "collective understanding of the community". (Note that, concerning stateless v4/v6 solutions, I think I should be considered part of this community. Right? ). Maoke, clarifications on these points will be welcome. > 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. Note: This excludes ISPs that would like to offer full IPv4 transparency with some IPv6-only middles boxes. Right? > 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. Such an operator would know it uses 4rd-U. This doesn't seem to justify any FUD from co-authors from broadband and mobile operators (or from product vendors). > It is stated as tunneling but actually behaves like tunnel in some aspects > while like translation in some other aspects. Yes indeed, thus achieving the best of both worlds without making it more complex. Actually making it clearly less complex than supporting both T and E. > (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.) "Possibly major flaws" isn't an identified point on which U would do less than what it has been designed to do (unified replacement of T + E). IMPORTANT: - The essential characterization of U (vs T and E) is its Reversible header mapping (as replacement of both Double RFC6145 translation and Encapsulation). - Other features of U that differ from MAP (V-octet, CNP), or are complementary to it (Rule IPv6 suffix, NAT64+), are secondary in this respect. Each of these features could be abandoned in U, or, if the WG appreciates what they offer, added to MAP. - For this, community acceptance to listen to explanations, would be the normal process. I will be available this week for this. Cheers, RD > 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 > 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
