Le 2012-04-10 à 11:21, Wojciech Dec a écrit : > > > On 10 April 2012 10:23, Rémi Després <[email protected]> wrote: > > Le 2012-04-10 à 09:59, Wojciech Dec a écrit : > >> >> >> On 10 April 2012 09:31, Rémi Després <[email protected]> wrote: >> Le 2012-04-10 à 07:35, GangChen a écrit : >> >> > Hello all, >> > >> > I have tried to work hard and technically contribute to all documents: >> > MAP-algorithm, MAP-T, MAP-E, MAP-Deployment, 4rd-U, and also cosigned >> > with all of them. Please allow me to share some points here. >> > >> > Basic idea of MAP algorithm were originally built on 4rd and DIVI >> > (draft-despres-softwire-4rd,draft-murakami-softwire-4rd, >> > draft-xli-behave-divi, ..). It was improved by design team members and >> > evolved into "polarized solutions"(as Jan mentioned), i.e. MAP-T and >> > MAP-E. Identical address format is used for -T and -E. Backing to the >> > earlier version of MAP document, it included all features (e.g. >> > Checksum-neutrality, Vbit etc.). Some people were in favor of it; some >> > thought it not key points. For example, CNP is desirable for >> > translation solution. But it's in some extent against current tunnel >> > implementation, because encapsulation requires fixed IPv6 address >> > representing an endpoint depending on tunnel code today. People have >> > to sacrifice this feature in order to keep the benefits of unified >> > address format. However, that obviously is of value to transparency. >> > (PS: CNP is also a feature in RFC6296, stateless IPv6-to-IPv6 Network >> > Prefix Translation). >> > >> > 4rd-U was trying to keep all merits together considering trade-off >> > points. It was targeted to be reversible process and full transparency >> > which I guess is important for a stateless design. Meanwhile, some >> > additional extensions have to be considered. It's maybe a point to >> > bring up "endless discussion" on the list. >> > >> > I agree with what Yiu said it's hard to simply answer YES or NO at >> > this time. Both solutions deserve spending more time, because these >> > solutions were born only for half a year. >> >> +1 >> >> > Implementation may need more >> > time and operation normally will also need to wait. >> > >> > OTOH, I'm still not fully convinced MAP-E and -T should be treated as >> > one solution. >> >> +1 >> (They were previously considered to be two distinct candidates for standard >> track.) >> >> > I like MAP-E or -T to be deployed as a separate >> > solution. However, coexistence means operators should have double >> > packages inspection toolkits, double operational rules delivery and >> > double provisioning costs. In some cases, translation solution is >> > exclusive to encapsulation (Please see more in >> > draft-dec-stateless-4v6). >> > Even you can implement in the same box, >> > that's very inconvenient for operation and subscriber. >> >> +1 >> With MAP-T+E, subscribers wouldn't have the same service depending on which >> specification their local operator has chosen, with subtle differences they >> shouldn't be concerned with. >> >> The service would be the same. Note: NAT64 based services are a reality >> today, and although you may think differently, no operator calls "checksum >> neutrality" a service (with this apparently being the main feature of >> 4rd-u). > > Please avoid inventing my thoughts to then criticize them. > The key service offered by 4rd-U is complete IPv4 transparency (a MAP-E > property) combined with compatibility with IPv6-only O&M-tools (a MAP-T > property). Checksum neutrality is just a tool. > > That is not a service as an operator would typically see it. In any case, > there is nothing preventing MAP from supporting the purported IPv4 > transparency, but so far there has been no consensus that this is actually > desirable, or worthwhile. > > >> What more, given that 4rd-U needs to be combined with BIH, the claim of it >> offering some "unified" solution, different operationally from MAP is bogus. >> If anything this combination and the fact that there is a IPv6.1 being >> created actually makes 4rd-u operations a major challenge in comparison to >> what we know of as IPinIP tunnelling or NAT64 with MAP. > > The need for an IPv6 6.1 is AFAIK an invention of yours, not something needed > by 4rd-U. > > 4rd-u does change the basic semantics of fields in IPv6,
??? (If you would have evidence that everything isn't backward compatible, please share this information.) > and that is not my invention. > > >> Remi, at one point you stated publicly that you would withdraw 4rd-u should >> it not gain WG consensus. > > (*) I said, and confirm, that my personal work is to achieve a single > standard, not to have 3. > My appreciation is that 4rd-U is more than ever the best candidate for this > since the idea of having only MAP-T OR MAP-E on standard track has ben > abandoned. > > 4rd-u requires coupling with BIH, so it's not a single standard by any means > (not to mention the changes to IPv6). 4rd-U is is a Softwire solution (IPv4 via IPv6). IPv4-only to IPv6-only communication is a different subject, already covered by a standard-track RFC. If there are criticisms of this existing RFC, they belong to a different forum. RD >> You also chose to quit the MAP design team, where your proposals failed to >> get consensus. > > Conditions in which the 4rd-U approach has been rejected, in an improvised > meeting in Taipei, has already been commented. > > The design team worked on the principles of common consensus and seeking > compromise in an effort to create a solution that addressed the core problems > and the agreement of the Beijing meeting in a timely manner. Concepts that > are apparently foreign to those who choose first to work on the design team > and then abandoned the team to seek the personal advancement of their own > solution. > As mentioned, forming a new WG for 4rd-X, if not actually an RD WG, is a > worthy idea that should be considered, allowing the rest of the world to > proceed with getting things done. > > -Woj. > > > There has been after that no alternative to a separate work, approved by the > chair. > result is the self contained and complete 4rd-U specification, which, despite > aggressive comments made on the list and in meetings, has already arisen > substantial interest in the WG. > > >> At this stage it appears that not only you are not intending to honour you >> public statement, > > See (*) above. > >> but also in general disputing the process of establishing consensus in the >> WG. One is tempted to see it that no consensus other than "consensus on your >> terms" is what you really want, and those terms change with each new draft >> revision. > > ??? > >> Perhaps its time for draft 4rd-X in a new WG... > > ??? > > RD > > >> >> -Woj. >> >> >> RD >> >> >> >> > According >> > RFC6180, it is fundamental two different solution. >> > >> > BRs >> > >> > Gang >> > _______________________________________________ >> > 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
