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). 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. Remi, at one point you stated publicly that you would withdraw 4rd-u should it not gain WG consensus. You also chose to quit the MAP design team, where your proposals failed to get consensus. At this stage it appears that not only you are not intending to honour you public statement, 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... -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
