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 ? Best wishes Qiong On Tue, Jun 26, 2012 at 3:55 PM, Wojciech Dec <[email protected]> wrote: > > Well, a couple of observations: > A) MAP allows you to optimize complexity in not having to deal with per > subscriber rules in cases where this is feasible. > B) You're referring to data representation as an operational problem, > which if so, actually applies to any solution incl LW46 that transmits > port-range info to a client. I.e. "Whatever support staff" needs to be > schooled to use some logic to glean useful port information from the data > sent to a client > C) It is very easy to represent MAP data as port range info on routers, > tools, etc. > > -Woj. > > >> >> 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 > > -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * ===============================================
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
