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