Subject: [Softwires] Is ACL really a point to drive MAP-T solution?

From: GangChen <[email-masked]>
Date: Fri, 7 Sep 2012 14:04:31 +0800

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

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 10:11:48 +0200

Gang,

I think you are on a wrong track here.
1. In Vancouver it was decided that MAP-E would be standard track, and both MAP-T and 4rd experimental. There is no longer any way to prevent those who want experimental MAP-T to have it.
2. The argument against ACLs is also an argument against 4rd. 

If you agree, we can discuss how to best stop this thread.

RD

Le 2012-09-07 à 08:04, GangChen a écrit :

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Maoke <[email-masked]>
Date: Fri, 7 Sep 2012 17:19:59 +0900

i share the same view with Remi. and ACL is not the only reason that MAP-T
is needed. - maoke
2012/9/7 Rémi Després <[email-masked]>

> 1. In Vancouver it was decided that MAP-E would be standard track, and
> both MAP-T and 4rd experimental. There is no longer any way to prevent
> those who want experimental MAP-T to have it.

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Sep 2012 10:49:54 +0200

2012-09-07 à 10:19, Maoke:

> 
> i share the same view with Remi. and ACL is not the only reason that MAP-T is needed. - maoke

Yes, we do agree that work on experimental MAP-T can continue in Softwire (as decided in Vancouver)
But lets avoid confusion concerning my position: I am not personally one of those who believe MAP-T is needed.

Regards,
RD

---

From: Maglione Roberta <[email-masked]>
Date: Fri, 7 Sep 2012 11:03:47 +0200

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-masked] [mailto:[email-masked]] 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,

Many thanks

Gang

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.

---

From: Zhen Cao <[email-masked]>
Date: Sat, 8 Sep 2012 23:03:04 +0800

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

---

From: Maglione Roberta <[email-masked]>
Date: Sun, 9 Sep 2012 10:08:08 +0200

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-masked]]
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,

Thanks
Zhen

---

From: Maoke <[email-masked]>
Date: Mon, 10 Sep 2012 10:07:43 +0900

hi zhen,

2012/9/9 Zhen Cao <[email-masked]>

> 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

> > - 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
> >
> > 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.
> >

---

From: Zhen Cao <[email-masked]>
Date: Mon, 10 Sep 2012 10:12:08 +0800

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

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 10 Sep 2012 15:54:49 +0200

Zhen,

you perhaps may be missing out on the last 1+ years of discussions in this
WG regarding the role/purpose of NAT464 technology and all relevant
architectures, including the softwire Beijing interim with map-t use-cases,
the WG adoption vote/status, discussion on xlat464, as well as 4rd-u
(although the need for this technology variant remains questionable).
While we can re-hash many of those, in the interest of moving forward it
would be helpful if you revisited the archives to find the answers.

Regards,
W. Dec

---

From: Zhen Cao <[email-masked]>
Date: Tue, 11 Sep 2012 16:01:16 +0800

Woj,

I did attend the softwire Beijing interim meeting. What I heard then
were two conflicting arguments a) the  ACL should be accomplished via
IPv6 plane.
b) full IPv4 address should be encoded in the IPv6 address, so that
data filtering could be achieved.

Although these have been discussed on the mailing list for long, I
only witness one operator stating this is an issue since then.

Best regards,
Zhen

On Mon, Sep 10, 2012 at 9:54 PM, Wojciech Dec <[email-masked]> wrote:
>> > copying, printing or use by anybody else is unauthorised. If you are not the
>> > intended recipient, please delete this message and any attachments and