Le 2012-03-25 à 05:34, Maoke a écrit : > dear Remi, > 2012/3/24 Rémi Després <[email protected]> > > 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.
Not more fuzzy than MAP (actually less fuzzy IMHO). Debate on details is possible for U as wall as for T+E. > 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? Is a DHCPv6 parameter needed, yes or no? > 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! Sec 4.5.3. is "Packet Identifications from Shared-Address CEs". Did you read the complete draft? > 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. This is not the point. Separate documents can be consistent, but they aren't on this point. One of the two assertions must be changed. Remaining question: which one? > 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. How many MAP mapping rules do you see for the equivalent of the IVI use case in a MAP domain? None? If one, is it a DMR or a BMR? If two, what are they? > 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. OK, could have been clearer. Yet, I think you understand that with U, one has SIMULTANEOUSLY, transparency to DF=MF=1 and applicability of IPv6-only middle boxes that look at TCP ports. >> 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. Comparison is not reason (French proverb). > >> (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. I have still to understand where you see "major flaws". Just asserting they exist, without explanation although others who read the specification don't see them isn't enough. Saying that E+T is better because its current inconsistencies are "details" isn't enough either (IMHO). > 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. You can call it as you wish, but the point remains that, with U, one doesn't need both E and T. > - 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. I made the point many times that the right to analyze problems didn't stop after a majority decision obtained during an improvised meeting. Many MAP contributors were absents, and no time was given to correct invalid objections that had been made just before during a WG meeting. Note that several co-authors of the U proposal have been MAP contributors. > - 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. Your stand is clear, but comparison isn't reason. RD > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
