dear Remi, 2012/3/24 Rémi Després <despres.r...@laposte.net> > > 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": > >
some issues remaining not yet reaching collective undertanding is not a reason of making things over. the collective understanding has been reached for the major part of the 1) MAP address format and the corresponding algorithms 2) encapsulation and translation modes being supported by MAP format and the existing header processing standards 3) DHCP extensions as a way of distributing rules. the above big picture are what i call "collective understanding". the correct way is: making these already gained approaches as bases, continuing discussion or even dabate on the details. i don't think it is a correct way of action to disrespect a team's work. 4rd-u's problem is even its big picture is still fuzzy. > > a) T operation in hub&spoke (hasn't been so far answered in an > understandable way). > i doubt i understand what you mean. may you please specify the question in details? > > b) IDs from shared-address CEs. T currently has so far no solution while > both U and E include one. > > what do you mean with the IDs? or do you mean interface IDs? i don't see "IDs from shared-address CEs" in U too. please teach! > > 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 ..." > > first of all, they are not conflicting logically. second, if you mean one doc is superior than multiple with better consistency in writing, i could agree. but it doesn't mean one doc is definitely reflecting "collective understanding" better than multiple. > > 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. > > single mapping rule for a domain != single mapping rule for the IPv4 world. the IVI (RFC6052/6145/6219) practice does the latter. the latter doesn't need DHCP to distribute the mapping rule. in the MAP, i don't think DMR and BMR being exclusive is a problem. > > 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? ). > > well, "collective understanding" was mentioned by Sally Floyd to the community of Internet researchers, and i borrowed her term. but i understand: no matter it is research or engineering, collective understanding is the understanding on the problems and the architecture rather than the detailed technical solutions. the MAP architecture has been reflected in the works of the draft suite. on the other hand, the community is not the softwires wg but the whole Internet engineering circle. > > > 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? > > i cannot follow your "full IPv4 transparency" with "some" IPv6-only middle boxes. what does the "transparency" mean for the middle boxes? i understand, when we talk about the Internet transparency, we refer to the "end-to-end transparency". please specify your question concretely. > > > 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. > > well, this is what i mean the uncertainty of 4rd-U in the architecture to the common understanding. as a analogy, one of Mr. E and Mr. T said, "i give you a horse", while the other said "i give you a donkey". then people well understand when they need a horse when they need a donkey. now Mr. U said "wow, i give you a fantastic donkorse!". there would be 2 possible results, not certain right now: A. donkorse is just another sort of donkey, somehow good but somehow flawed. B. donkorse is just donkorse, and people, taking a long time to understand it, and finally find it either a flawed or a quite good hybrid, like mule, useful in some cases. no matter if the future result is A or B, now Mr. O understand what he needs for his business is either a horse and a donkey, with their well-known characteristics. Mr. MAP provides a wheeled car as the common instrument, while Mr. O needs a standard suite for the wheeled-car, the horse-driving and donkey-driving methods and the way of feeding the horse and donkey. this is the task of our wg, right now. Mr. U said you must have another type of wheel and drive it with my donkorse --- and when Mr. O asked him, what your donkorse is, he answered: you will know it is donkorse, having both the advantages of the horse and the advantages of the donkey. however, Mr. O doubts donkorse hasn't also the disadvantages of horse and the disadvantages of donkey and some flaws not yet documented. why not? > > 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 don't think those who made out mule expected the mule could replace horse and donkey and achieving a better world without horse and donkey but only mule. surely mule-only world is simpler. > (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). > > i believe they are major flaws but i was gently argued with the "possibly" because i respected that maybe others didn't think so critically like me. > > > IMPORTANT: > - The essential characterization of U (vs T and E) is its Reversible > header mapping (as replacement of both Double RFC6145 translation and > Encapsulation). > > yet-another-translation, with some issues still in debates. > > - 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. > > MAP team has concluded V-octet and CNP are not necessary. do we need to debate again? i doubt people have unlimited time. > > - For this, community acceptance to listen to explanations, would be the > normal process. I will be available this week for this. > > i think we are all open to listen to and to discuss on any explorations but it doesn't mean we should stop standardization of our wheeled-car/horse-driving/donkey-driving/feeding suite with an expectation of a "better world" with only donkorse and the donkorse-specific wheeled car. regards, maoke > > > 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
