Maoke, (Retransmission after deleting unnecessary old text. Message was too big for the mailing list)
2012-03-25 14:08, Maoke : > 2012/3/25 Rémi Després <despres.r...@laposte.net> ... > 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 I rather say that reversible header mapping implements a "tunnel" variant. > nor translation path section. > then what does the "reversible header mapping" provides to the architecture > of transition? you never clearly state this. The draft is AFAIK not ambiguous. I tried to answer all your questions on this point I barely understand (neither an implementation nor an operation issue) End of this point for me, if there is nothing significantly new. >> 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. Today, there is no DHCPv6 parameter to require H&S, right? My question is then: "is it sufficient to have none, or is it needed to add a new parameter". Looking at more details would be premature for me until you have answered this question. > 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? None AFAIK. > 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! (*) End of this subject. >> 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. I am not aware that a CE might receive some of the MAP DHCPv6 parameters but not all due to lost packets. Clarification on this will be welcome. > 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). ... > >> How many MAP mapping rules do you see for the equivalent of the IVI use case >> in a MAP domain? > 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. OK (In this respect at least, IVI significantly differs from a running version of MAP-T). > 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. Saying that there is no mapping rule in IVI is sufficient an answer. ... > ... 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); 1) A statistic at a given time, and in a given place, isn't a proof that the same ratio will be found later and somewhere else. 2) Those that happen to be in the sacrificed minority, be it small, may not like their situation. Solving the problem, be it only for them, is progress. > 2) with introducing #1. weird definition of the fragment header of IPv6; #2 > weird packet of IPv6 carrying ICMPv4 messages? AFAIK, not weird to those who are open to accept that it is very simple. >> 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 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 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. ICMPv4 payloads in IPv6 packets appear only during domain traversal, where they don't hurt anyone. If a host is IPv6 only, it isn't a 4rd-U host. For communication between IPv4-only applications of DS hosts and IPv6-only hosts, there are already workable RFCs. BIH in DS hosts is AFAIK particularly powerful, and IMHO sufficient. A new solution for this isn't needed. ... > ... 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. Different understanding. A detailed E use case that cannot be supported by U (if it exists) would give substance to this claim. Open to look at it. > 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 BIH does the job with single translation. Where U applies, both ends are IPv4, T has AFAIK no operational superiority while U is more transparent. > but U needs still discussion T too. See, for example, (*) above. > and running code approval. it cannot replace T at least this moment. Understanding how U's header mapping works doesn't need great expertise. Co-autors readily understood it, with origins as varied as router-and-host vendor, software vendor, broadband operator, mobile operator. Running code as soon couldn't be done yet, but isn't a big deal at all (see (**) below) ... > MAP can work even without the V-octet and CNP, at least in significant cases. Not a valid reason to stop progress, especially if easy to understand. At least Med suggested to look at V octet even in the context of MAP (if chosen for standard track). > 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. (**) When we discussed in Taipei, you first said you might code 4rd-U so that it could be tested for real. You didn't do it for reasons that I perfectly respect. Yet, modifying T code to support header mapping remains quite simple (you even call it a translation variant). Starting from E code, it's simple too. When this is done, all verifications can be easily done that what analysis says is right is also right with running code. Regards, RD > > - 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 > > > > >> 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
