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, 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). > > > 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
