[Softwires] MAP-E&T vs 4rd-U

[GangChen <[e-mail]>]

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