On 4/3/12 3:53 AM, Satoru Matsushima wrote:
FYI, choosing MAP doesn't mean that committing to a 'single'. But
choosing 4rd-u means that committing to a 'single'.

There're just transport variants, which are encapsulation,
translation and new one we've never seen before. Proponents of the
new one claim to unify transport only to the new one, which means
that eliminating both encapsulation and translation variants of MAP
because they say two choice of transport type would make confusion
for operators. The new one is transparent than translation, but less
than encapsulation. I couldn't decide transport type to be unified
with the new one. No evidence, no expertise, no experience for that.
Do we need them to be sure in spite of we already have existing
mature transport variants?

cheers, --satoru

+1

Given the situation with IPv4 exhaustion we have to hurry and go with what we know and what is proven to work today with no funky new features.

I agree that 4RD-U brings some good new features, but as it changes the IPv6 current usage I suggest to redirect 4RD-U to BoF and to go through revision of also other working groups that needs to say their understanding of changed IPv6 transport behavior. I also believe that when 4RD-U goes through the whole proper procedure it might be widely adopted later as MAP replacement.

Meantime - let's fix the problem with what we know and understand.

Speaking as A+P (RFC6346) co-author, we got many questions about A+P progress from operators and we learned that the time-frame for decision between CGN and something else is already nearly expired. If we want anything-A+P to still reach the operators, then the time for decision is now. We already missed the majority of that train, but last seats in last wagon are still reachable.

We need to act and not just to push the endless discussion (that is not that uncommon for any IETF WG :) ).

Cheers, Jan Zorz
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to