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. 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. 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. According RFC6180, it is fundamental two different solution. BRs Gang _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
