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