Hello Roberta, Thanks for information. For the scenario you described, I have following questions and comments. a) Where are destination address based ACL needed? Those filtering can be accomplished via the configuration on the end point, not necessarily placed intermediately. I am not convinced why design ACL like this. b) The transport layer information can be got via one more step check into the packets, that's not a big problem for new devices.
Thanks and regards, Zhen On Sun, Sep 9, 2012 at 4:08 PM, Maglione Roberta <[email protected]> wrote: > Hello Zhen, > thanks for your comments. The use cases I described in my email are just > some examples of types of ACL’s for IPv4 we have been using in our network > for many years. I don’t want to speak for other operators, but these are > real application for ACL’s in our current Broadband deployment. > I haven’t seen in your reply any explanation about how these scenarios > could be implemented with other solutions without changing the network > architecture. > In addition I’d like to mention that ACL’s are just one of the use cases > that could benefit from a MAP-T like solution, there are other examples, I > can describe them in more details, if you think it could be useful. > Thanks and best regards > Roberta > > > ________________________________________ > From: Zhen Cao [[email protected]] > Sent: Saturday, September 08, 2012 5:03 PM > To: Maglione Roberta > Cc: GangChen; softwires > Subject: Re: [Softwires] Is ACL really a point to drive MAP-T solution? > > 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. > > 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
