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

Reply via email to