An old cartoon I once saw, making fun of ISDN IIRC, showed a single
socket on the outside of the wall, connected to a rat's-nest of
connections on the inside. This seems apt for the present enterprise.
Tom Taylor
On 26/06/2012 9:48 PM, Maoke wrote:
dear Satoru,
2012/6/26 Satoru Matsushima <[email protected]>
On 2012/06/27, at 0:11, Qiong wrote:
Agree with Ian.
MAP is designed and optimized for algorithmatic address mapping, but not
for per-subscriber rule mapping. Actually, the more you would like to
solve, more complicated it will become.
I will certainly not buy MAP for per-subscriber case when MAP-T, MAP-E,
map-dhcp all becomes useless or not optimized. And I will not deploy
per-subscriber stateful and stateless solutions at the same.
So I encourage two seperated approaches optimized for different
scenarios. It will be good for both.
Do we really all forget about the "KISS" principle ?
Not quite.
I believe that the most motivate to start this work in the wg has destined
MAP to be 'multi-protocol socket v2.0' that's what the former wg chair
wished to. Do you remember that?
i like the philosophy of "multi-protocol socket". however, i moderately
doubt the "multi-protocol socket v2.0" is a perfect plan for every cases.
in a quite good hotel, we see typically one 'multi-protocol socket' while a
lot of local-standard sockets. i never think it will make me happy if i see
every socket in my room is *multi-protocol*, occupying much spaces and
quite noticeable on the walls. we need one to deploy somewhere not the only
one type to deploy anywhere. ;-)
therefore i understand the motivation of the wg is making a unified
solution covering both encapsulation and translation in the framework of
stateless, WITHOUT the exclusiveness against other solutions, more
specifically suitable for a certain use case.
cheers,
maoke
cheers,
--satoru
_______________________________________________
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
