hi zhen, 2012/9/9 Zhen Cao <[email protected]>
> Hello Roberta, > > For most operators, I haven't heard the issues existed. If those use > cases are just designed for this solution, this does not convince > anybody including me, and we do not need to discuss a scenario which > is to justify a solution. > IMHO, ACL visibility is one of the consequence/result/benefit rather than design goal of the MAP-T. we have the RFCs for translation -> translation for IPv4/IPv6 -> stateless translation -> double translation, where we can see a clear movitation of having the MAP-T. double translation is a naturally established use case (and an indispensible part of the architecture) of stateless translation and MAP-T is the application of MAP address/port mapping algorithm for it. debating on the significance of MAP-T, even after the WG has formally committed continueing the work on it, IMHO, is waste of time of the WG. but if you would like to discuss about the significance, motivation, and use cases of translation/double-translation, you are welcome to mail me offline. thanks! - maoke > > What's your unique network architecture compared with others, can you > show us your concrete network architecture? What's your deployment > plan for MAP-T and where? > > Thanks > Zhen > > On Fri, Sep 7, 2012 at 5:03 PM, Maglione Roberta > <[email protected]> wrote: > > Hello Gang, > > I do see some difference between MAP-E and MAP-T regarding the > application of ACL. > > Let's consider the following scenarios: > > - when a destination is outside of the MAP domain in case of MAP-E the > CE uses as IPv6 destination the IPv6 address of the MAP BR while for MAP-T > it uses the IPv4 address of the destination mapped in IPv6 by using the MAP > IPv6 rule. If I need to apply an ACL that matches a destination outside of > the map domain I can only do that by using MAP-T; > > - another example is how to apply an ACL that matches UDP or TCP packets > on the BNG. My understanding is that this cannot be achieved with MAP-E, as > the IPv4 packet is encapsulated in IPv6. > > > > These are just a couple of examples about ACL, there are use cases with > operational implications, that can be simply addressed by MAP-T. > > > > Thanks > > Best regards, > > Roberta > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > Behalf Of GangChen > > Sent: venerdì 7 settembre 2012 8.05 > > To: softwires > > Subject: [Softwires] Is ACL really a point to drive MAP-T solution? > > > > Hello all, > > > > As I identified, there is no issue to apply ACL either on fix networks > > or mobile networks. Why most operators don't have issue, why there is > > the issue for special operator. What is the issue? > > > > MAP-T and MAP-E have same address format. And, we have a good decision > > to standard the MAP-E solution. > > > > Even ACL is needed, MAP-E is sufficient. There is no need to create > > another flavor > > > > Considering above, MAP-T is superfluous. > > I don't think we need spend much energy on that. > > If there is something I missed, please kindly identify it before > > submitting the MAP-T document. > > > > Many thanks > > > > Gang > > _______________________________________________ > > Softwires mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/softwires > > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora > abbiate ricevuto questo documento per errore siete cortesemente pregati di > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > > > This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not > the intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks. > > > > _______________________________________________ > > 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
