2012/3/25 Rémi Després despres.r...@laposte.net > > > 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. > >
you may argue that MAP is much more fuzzy. but as i said, nobody knows exactly what the "4rd-u tunnel" is. you said it is just a reversible header mapping that is not tunnel nor translation path section. then what does the "reversible header mapping" provides to the architecture of transition? you never clearly state this. > > > 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? > > i am not sure i know about the details of what you mean. do you mean the feature of R-2.C? if so, i happen to have following questions: 1) why hub&spoke topology should be announced to the CE? (IMHO, if a CE is informed with the FMR involving other CEs, it works as mesh; if only BMR and DMR is informed, surely it is hub&spoke. i think this has been clarified in MAP Section 5.) 2) to this parameter issue, what is the difference between T and E? look forward to your further clarification/discussions! if you mean not the hub&spoke mode indicator, please specify your question further. > > 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? > > execuse me. it is my fault. i read it but i didn't realize you mean the datagram identification here. it is a good point, and not only this but also the issue of how BR deals with fragments of the same datagram where only the first fragment has the port number. for this point, i think MAP-T also needs to consider this problem described in the MAP-E Section 7, last 2 paragraphs. thanks a lot! > > > > 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? > > well. this is why i said they are not conflict in logic. as a definition of the MAP rule, right, each MAP node in the domain SHOULD have the same set of rules. however, in practice of operation, it is possible that this MAY not strictly achieved due to some information losses (which is often happens in the Internet environment), MAP-T defines the CE working as it were in hub&spokes mode for an unknown destination CE. the text of Sec 8.2 of MAP-T and that of Sec 8.2 of MAP-E are clear enough to me. no one among MAP/MAP-T/MAP-E here needs to be changed. (i may partly agree with you that one could be further clarified). > 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 you mean the single mapping rule in IVI case, the answer is NONE, surely. IVI uses RFC6052 address format rather than the MAP, without the business of MAP. if you mean using the MAP for the single translation as we did in IVI (though actually we have IVI working for both single and double translations simultaneously), MAP-T Sec 8.3 has answered your question. > > If one, is it a DMR or a BMR? > If two, what are they? > > ... > > 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. > > ok. then may i conclude, for the major part of U, that 1) U, as a stated enhancement for double translation, gain the transparency for DF=MF=1 (the 10^-6 minor cases, commonly thought abnormal); 2) with introducing #1. uncommon definition of the fragment header of IPv6; #2 uncommon packet of IPv6 carrying ICMPv4 messages? > > > 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 mean "such an operator would know it uses 4rd-U" can approve nothing. i just try to understand what the 4rd-u reversible header mapping really is, in the term of architecture. this analogy is written as problem understanding rather than a reason of anything. > > > (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. > > well, i mostly argue that the ICMPv4 being carried by IPv6 and CNP are major flaws (as we discussed so much, i was not convinced at all). i don't think others who read the specification don't see them and other issues. > > Saying that E+T is better because its current inconsistencies are > "details" isn't enough either (IMHO). > > different problems. E + T is actually not only the MAP-E and MAP-T, but the utilization of existing, already mature E and T with the new MAP format. > 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. > > no. U has changed the layered model of Internet protocol stack. an operator definitely needs the encapsulation as a fully featured virtual link (underlay infrastructure) in real O&A for IPv4 communications over IPv6 infrastructure. U cannot replace E at all. on the other hand, an operator needs the translation to encourage transition and mutual communications between IPv4 and IPv6 and double translation is included in such an environment. T has specifications for this working but U needs still discussion and running code approval. it cannot replace T at least this moment. > - 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. > > MAP can work even without the V-octet and CNP, at least in significant cases. if we have the standard of MAP, we can immediately deploy it into practice through applying MAP rules into the already well understood, well approved, well standardized encapsulation and translation modules, without waiting for the approval of the new features in the address format, and the approval of the reversible header mapping tightly coupled with the address format. - maoke > > > 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 > >
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
