Subject: [Softwires] GI-DS-lite as working group item?

From: Alain Durand <[email-masked]>
Date: Wed, 5 May 2010 14:57:04 -0700

Dear WG,

At the 3GPP-IETF interim meeting, there was strong interest in GI DS-lite, and the recommendation was the IETF should take on its standardization. There was similar interest shown during the last IETF meeting and an informal show of hands demonstrated large support to take GI DS-lite as a working group item.
This of course need to be confirmed on the list, and unless we hear otherwise, we, Softwires chairs, will work with our ADs to add GI-DS-lite on our charter.

  - Alain, softwires co-chair.

---

From: <[email-masked]>
Date: Thu, 6 May 2010 09:02:50 +0200

I'm in favor of adopting it as WG item. It's a nice piece of work and fits very well to the deployment scenarios of mobile operators.

Kind regards
Olaf 

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von Alain Durand
> Gesendet: Mittwoch, 5. Mai 2010 23:57
> An: [email-masked]
> Betreff: [Softwires] GI-DS-lite as working group item?
> 
> Dear WG,
> 
> At the 3GPP-IETF interim meeting, there was strong interest 
> in GI DS-lite, and the recommendation was the IETF should 
> take on its standardization. There was similar interest shown 
> during the last IETF meeting and an informal show of hands 
> demonstrated large support to take GI DS-lite as a working group item.
> This of course need to be confirmed on the list, and unless 
> we hear otherwise, we, Softwires chairs, will work with our 
> ADs to add GI-DS-lite on our charter.
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Tina TSOU <[email-masked]>
Date: Thu, 06 May 2010 15:49:03 +0800

Support with comments.

There is only on tunnel between B4 and AFTR in GI-DS-lite. In the cases, 
which there are duplicated addresses for UEs, it needs to identify different 
user. For plain IP-in-IP tunnel, there is no mean to identify user. Perhaps 
it could be solved in the next version of GI-DS-lite draft.

B. R.
Tina
http://tinatsou.weebly.com/contact.html
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 06, 2010 3:02 PM
Subject: Re: [Softwires] GI-DS-lite as working group item?

I'm in favor of adopting it as WG item. It's a nice piece of work and fits 
very well to the deployment scenarios of mobile operators.

Kind regards
Olaf

---

From: <[email-masked]>
Date: Thu, 6 May 2010 10:27:44 +0200

Dear Alain, all,

GI-DS-Lite is one option among others to limit the effect the of the IPv4 address depletion. It introduces a tunnel between a PGW/GGSN and a CGN, this has some impacts on the gateway. This tunnel can be of any nature, IPv6 is only an option. 

Other solutions such as enabling a NAT44 (or even a NAT64 to prepare for an IPv6-only mode) in the GGSN/PGW or enforce routing policies to redirect the traffic to a CGN which is used to service a set of PGWs/GGSNs is also a valid scenario which solves the problem addressed by GI-DS-Lite. The pressure on the private IPv4 addresses if any can be solved by adopting a per-interface (TID of GTP can be sued for de-multiplexing purposes, and the same private IPv4 address can be assigned to requesting UEs).

Note that both solutions may be deployed in a standalone scheme: i.e., without any plan to enable IPv6...

To sum up, my proposal is: instead of adopting a document which describes one possible solution, document other "viable" options too for fairness. 

I don't know if the IETF is the right place for this, but the impact of GI-DS-Lite on existing 3GPP architectures should be assessed.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Alain Durand
Envoyé : mercredi 5 mai 2010 23:57
À : [email-masked]
Objet : [Softwires] GI-DS-lite as working group item?

Dear WG,

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 6 May 2010 08:09:52 -0700 (PDT)

+1.

I am going to provide my technical comments later.

Regards,

Behcet

----- Original Message ----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Thu, May 6, 2010 2:02:50 AM
> I'm in favor of adopting it as WG item. It's a nice piece of work and fits very 
> well to the deployment scenarios of mobile operators.

Kind 
> regards
Olaf 

> Von: > ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked] 
> 
> [mailto:> href="mailto:[email-masked]">[email-masked]] Im 
> Auftrag von Alain Durand
> An: > href="mailto:[email-masked]">[email-masked]
> Betreff: 
> [Softwires] GI-DS-lite as working group item?
> 
> Dear WG,
> 
> 
> in 
> GI DS-lite, and the recommendation was the IETF should 
> take on its 
> standardization. There was similar interest shown 
> during the last IETF 
> Softwires mailing 
> list
> > href="mailto:[email-masked]">[email-masked]
> > href="https://www.ietf.org/mailman/listinfo/softwires" target=_blank 
Softwires mailing 
> list
> href="mailto:[email-masked]">[email-masked]
> href="https://www.ietf.org/mailman/listinfo/softwires" target=_blank

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 6 May 2010 11:52:09 -0400

I support to adopt this a WG item.

On 5/5/10 5:57 PM, "Alain Durand" <[email-masked]> wrote:

> Dear WG,
> 
> At the 3GPP-IETF interim meeting, there was strong interest in GI DS-lite, and
> the recommendation was the IETF should take on its standardization. There was
> similar interest shown during the last IETF meeting and an informal show of
> hands demonstrated large support to take GI DS-lite as a working group item.
> This of course need to be confirmed on the list, and unless we hear otherwise,
> we, Softwires chairs, will work with our ADs to add GI-DS-lite on our charter.
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 6 May 2010 11:55:44 -0400

Hi Tina,

Question for you. When you said to identify the user, did you mean to
identify the user by IPv4 address or some other means like the GRE id?

The basic DS-lite always assumes no duplicate IPv4 addresses managed by one
B4. Can you elaborate the question?

Thanks,
Yiu

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 6 May 2010 09:59:43 -0700

> To sum up, my proposal is: instead of adopting a document which describes one possible solution, document other "viable" options too for fairness.

Med, I believe GI-DS-Lite is a unique protocol that the IETF must
define.  IMHO, it would be confusing to have one document that both
defines and evaluates solutions.  It is better to have standards track
documents to uniquely define a protocol, and then a separate
informational document (IETF, 3GPP, both ...) that that compares the
deployment options.

Cameron

---

From: <[email-masked]>
Date: Fri, 7 May 2010 11:24:33 +0200

Dear Cameron, all,

GI-DSLite does not define any protocol but an architecture where a tunnel is used together with a new enhanced NAT44 table (because more de-multiplexing information than for basic NAT44 table is required). So, what should be standardised there?

(1) The behaviour of the gateway?

(2) The tunnel establishment "procedure"? This is an operational consideration as a matter of fact. In addition, the tunnel is not required in the majority of the scenarios. Normal routing actions can be done in the gateway to redirect the traffic to the appropriate CGN. I don't see a deployment context where more that +16M UEs (or Access Devices) will be serviced by the same CGN device. 

(3) The structure of the enhanced NAT table?: Other proposals are on the table such as Layer-2 Aware NAT (http://tools.ietf.org/html/draft-miles-behave-l2nat-00) or Per-interface NAT (http://tools.ietf.org/html/draft-arkko-dual-stack-extra-lite-00). Should we define a generic table structure for all enhanced NAT? 

The document does not define the problem to be solved and neither why a new solution is required. Is the targeted problem a valid problem to be solved? Please find below my analysis on the mobile use case. Several scenarios can be envisaged as listed below:

(a) Co-located model: the NAT is co-located in the PGW/GGSN. No issue with private IPv4 addresses. GTP TID can even be used a de-multiplexing factor if required.

(b) 1:1 model: the CGN and the PGW/GGSN are not embedded in the same device. Each PGW/GGSN is configured how to reach its attached CGN. There is no private IPv4 @ depletion problem.

(c) N:1 model: a single CGN serve a group of PGW/GGSN. Indeed, having +16M of customers is a valid case. **BUT** which Service Provider will accept to service this huge amount of UEs with the same node (if we suppose that a mega centralised CGN implementation is found in the market)? This is single point of failure design which SHOULD NOT BE RECOMMENDED.

Below additional comments on the proposal:

* As currently documented, GI-DS-Lite can be deployed in fixed networks too. I thought (since I heard this argument several times, especially in the context of A+P effort) that IETF does not need any new tool for solving the IPv4 address depletion, and DS and DS-Lite are sufficient enough in fixed networks. Why GI-DS-Lite should be an exception?

* Nothing prevent the AD (Access Device) to embed a NAT function. This leads to NAT444 model. Do we want to go in that direction?

* The support of IPv6 tunnels IS NOT mandatory in GI-DS-Lite. GI-DS-Lite is a misleading terminology. The solution can be deployed in IPv4-only networks.

* Does this solution allows for an "IPv6 introduction"-friendly path? The draft says "...it allows the network between the
   access gateway and the NAT to be either IPv4 or IPv6 and provides the
   operator to migrate to IPv6 in incremental steps." 

(i) What does that "migrate" really mean? For me, "migrate" means that actions are undertaken to move to an IPv6-only scheme. I could understand the rationale behind this sentence if a procedure to offload the traffic from NAT44 to NAT64 is elaborated for instance. This is not the case of GI-DS-Lite current spec.
 
(ii) 3GPP seems to recommend DS and IPv6-only approaches. This solution SHOULD part of that package and not defined as a standalone solution.

Technically the proposed architecture works. My concern is more about the validity of the deployment scenarios. This is why I re-iterate my proposal to adopt a big-picture approach rather than specifying one piece of the puzzle.

Please correct me if I missed something.

Cheers,
Med

-----Message d'origine-----
De : Cameron Byrne [mailto:[email-masked]] 
Envoyé : jeudi 6 mai 2010 19:00
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Alain Durand; [email-masked]; BINET David NCPI/NAD/TIP
Objet : Re: [Softwires] GI-DS-lite as working group item?

Cameron

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 7 May 2010 07:55:24 -0700 (PDT)

Hi Med,

> Dear Cameron, all,

GI-DSLite does not define any protocol but an 
> architecture where a tunnel is used together with a new enhanced NAT44 table 
> (because more de-multiplexing information than for basic NAT44 table is 
> required). So, what should be standardised there?

(1) The behaviour of 
> the gateway?

(2) The tunnel establishment "procedure"? This is an 
> operational consideration as a matter of fact. In addition, the tunnel is not 
> required in the majority of the scenarios. Normal routing actions can be done in 
> the gateway to redirect the traffic to the appropriate CGN. I don't see a 
> deployment context where more that +16M UEs (or Access Devices) will be serviced 
> by the same CGN device. 

(3) The structure of the enhanced NAT table?: 
> Other proposals are on the table such as Layer-2 Aware NAT 
> (http://tools.ietf.org/html/draft-miles-behave-l2nat-00) or Per-interface NAT 
> (http://tools.ietf.org/html/draft-arkko-dual-stack-extra-lite-00). Should we 
> define a generic table structure for all enhanced NAT? 

The document does 
> not define the problem to be solved and neither why a new solution is required. 
> Is the targeted problem a valid problem to be solved? Please find below my 
> analysis on the mobile use case. Several scenarios can be envisaged as listed 
> below:

> (a) Co-located model: the NAT is co-located in the PGW/GGSN. No 
> issue with private IPv4 addresses. GTP TID can even be used a de-multiplexing 
> factor if required.

> (b) 1:1 model: the CGN and the PGW/GGSN are not 
> embedded in the same device. Each PGW/GGSN is configured how to reach its 
> attached CGN. There is no private IPv4 @ depletion problem.

> (c) N:1 
> model: a single CGN serve a group of PGW/GGSN. Indeed, having +16M of customers 
> is a valid case. **BUT** which Service Provider will accept to service this huge 
> amount of UEs with the same node (if we suppose that a mega centralised CGN 
> implementation is found in the market)? This is single point of failure design 
> which SHOULD NOT BE RECOMMENDED.

IMHO it is N:1 and that's why GI-DS lite is interesting to the operators. I agree with you that having 16M+ MNs NAT'ed by a single CGN is something I have not heard of, yes there there is a problem.

Let's hope that we are not going to have that problem. If IPv6 migration progresses fast we may not.

Regards,

Behcet

---

From: Alain Durand <[email-masked]>
Date: Fri, 7 May 2010 09:19:05 -0700

> IMHO it is N:1 and that's why GI-DS lite is interesting to the operators. I agree with you that having 16M+ MNs NAT'ed by a single CGN is something I have not heard of, yes there there is a problem.

co-chair hat off:

This is the N:P aspect that I find interesting in GI-DS-lite. And it does not have to be limited to 16M+ address being concentrated... nor be limited to wireless.
Think about an ISP with a number of access router and a number of centralized NATs. Each customer connected to an access router is using his own version of RFC1918.
What GI-DS-lite enable is to implement the NAT function in a different box that potentially has different scaling properties than the access router.

  - Alain.

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 7 May 2010 13:42:33 -0700 (PDT)

>> is a valid case. **BUT** which Service 
> Provider will accept to service this huge 
>> amount of UEs with the 
> same node (if we suppose that a mega centralised CGN 
>> implementation 
> is found in the market)? This is single point of failure design 
>> 
> IMHO it is N:1 and that's why 
> GI-DS lite is interesting to the operators. I agree with you that having 16M+ 
> MNs NAT'ed by a single CGN is something I have not heard of, yes there there is 
> a problem.

co-chair hat off:

This is the N:P aspect that I 
> find interesting in GI-DS-lite. And it does not have to be limited to 16M+ 
> address being concentrated... nor be limited to wireless.
Think about an ISP 
> with a number of access router and a number of centralized NATs. Each customer 
> connected to an access router is using his own version of RFC1918.
What 
> GI-DS-lite enable is to implement the NAT function in a different box that 
> potentially has different scaling properties than the access 
> router.

This is good point, yes it could be N:P which could help in scaling. However I'd rather not see GI-DS Lite applicability in ISP networks because of missing things in CGN like PCP. At least currently we don't seem to need such things for mobile nodes.

Regards,

Behcet

---

From: Alain Durand <[email-masked]>
Date: Fri, 7 May 2010 14:39:31 -0700

On May 7, 2010, at 4:42 PM, Behcet Sarikaya wrote:

I tend to believe that PCP would be of great utility for mobiles... If you are guaranteed that the mapping is in place for a contracted period of time, you do not need to send those keep alive messages...

   - Alain.

---

From: <[email-masked]>
Date: Mon, 10 May 2010 08:37:12 +0200

Dear Alain, all,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Alain Durand [mailto:[email-masked]] 
Envoyé : vendredi 7 mai 2010 18:19
À : Behcet Sarikaya
Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : Re: [Softwires] GI-DS-lite as working group item?

co-chair hat off:

Med: I have several questions here:

1- What do you mean by N:P? (In my first e-mail N refers to the number of gws and 1 is number of CGNs). 

2- If applied to fixed networks,  

(*) this would lead to NAT444 design model since nothing prevent to embed a NAT function in the AD.
(*) IPv6 is not a MANDATORY building block of the solution.   
(*) What is then the recommendation of the WG: use DS-Lite? Or GI-DS-Lite? Etc.
(*) A last comment, since GI-DS-Lite is a request from the 3GPP which recommends DS and IPv6-only models, this solution SHOULD be part of that package.

Think about an ISP with a number of access router and a number of centralized NATs. Each customer connected to an access router is 

Med: Even if centralised, having several millions of customers behind the same "stateful" device is not a viable approach: this node needs to support logging, LI, NAT, ALG, etc.    

using his own version of RFC1918.

Med: Yes, I agree with this point.

Med: Yes but GI-DS-Lite is not the ONLY solution which allows this.  You may rely on simple routing configuration from the gateway to its associated NAT(s), use DS-Lite ;-), or use A+P to avoid having any stateful device in the core network, etc.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 10 May 2010 08:49:46 -0700 (PDT)

Hi Med,
As I understand, N:P means you don't need to have a single NAT box in the network, some network partitioning can be done possibly geographically to allow more than one NAT boxes and then it becomes a matter of configuration to connect them to the GWs.

I agree with you on the applicability of GI DS-Lite in ISP networks.

Regards,

Behcet

________________________________
From: "[email-masked]" <[email-masked]>
To: Alain Durand <[email-masked]>; Behcet Sarikaya <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Mon, May 10, 2010 1:37:12 AM
Subject: RE: [Softwires] GI-DS-lite as working group item?

Dear Alain, all,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Alain Durand [mailto:[email-masked]] 
Envoyé : vendredi 7 mai 2010 18:19
À : Behcet Sarikaya
Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : Re: [Softwires] GI-DS-lite as working group item?

co-chair hat off:

---

From: <[email-masked]>
Date: Mon, 10 May 2010 18:03:46 +0200

Hi Behcet,

Please see inline.

Cheers,
Med

________________________________
De : Behcet Sarikaya [mailto:[email-masked]]
Envoyé : lundi 10 mai 2010 17:50
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]
Objet : Re: [Softwires] GI-DS-lite as working group item?

Hi Med,
As I understand, N:P means you don't need to have a single NAT box in the network, some network partitioning can be done possibly geographically to allow more than one NAT boxes and then it becomes a matter of configuration to connect them to the GWs.
[Med] Ok thanks, I got it now. BTW, this is the (c) case  "(c) N:1 model: a single CGN serve a group of PGW/GGSN."

Regards,

Behcet

Dear Alain, all,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Alain Durand [mailto:[email-masked]<mailto:[email-masked]>]
Envoyé : vendredi 7 mai 2010 18:19
À : Behcet Sarikaya
Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]<mailto:[email-masked]>
Objet : Re: [Softwires] GI-DS-lite as working group item?

co-chair hat off:

---

From: Alain Durand <[email-masked]>
Date: Tue, 11 May 2010 05:24:41 -0700

Dear working group,

Thank you for the comments received on GI-DS-lite

So, far, we have heard 10 shows of support from 10 different people (and different companies), excluding the authors, and 1 voice against.
As wg chair, I declare WG consensus to adopt this document as working group item. I'd like to direct the authors to re-submit GI-DS-lite as draft-softwire-gateway-init-ds-lite-00.txt

   - Alain, wg co-chair.

---

From: Ahmad Muhanna <[email-masked]>
Date: Tue, 11 May 2010 10:49:07 -0400

Hi Alain,
 
Sorry that I was not at the last IETF meeting nor the IETF-3GPP meeting and I am some what ignorant of the amount of support this draft received and the arguments that have been used in these meetings . However, declaring the adoption of this draft as a WG document in 5 days without specifying a deadline seems to me a little fast!
 
On the other hand, After reading this draft a couple of times. I failed to understand the value of this solution to MIP6 and PMIP6 as they quite clearly referenced in the draft.

In other words, since mobility architecture seems to be a major beneficiary target for this solution, it is quite important for us to understand what this draft offers and how it fits or overlay this architecture?
 
Thanks for your considerations.

Regards,
Ahmad 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alain Durand
> Sent: Tuesday, May 11, 2010 7:25 AM
> To: Alain Durand
> Cc: [email-masked]
> So, far, we have heard 10 shows of support from 10 different 
> people (and different companies), excluding the authors, and 
> 1 voice against.
> As wg chair, I declare WG consensus to adopt this document as 
> working group item. I'd like to direct the authors to 
> re-submit GI-DS-lite as draft-softwire-gateway-init-ds-lite-00.txt
> 
>    - Alain, wg co-chair.
> 
> 
>

---

From: <[email-masked]>
Date: Tue, 11 May 2010 16:56:36 +0200

Dear Alain, all,

I don't understand why it is so that urgent to close this call for opinion after less than one week!

Another "logistic" comment is that the current charter of the working group seems to not allow to accept this document. 

I have sent several questions that I would appreciate to have answers from the authors. These questions can be found at:
- http://www.ietf.org/mail-archive/web/softwires/current/msg01396.html
- http://www.ietf.org/mail-archive/web/softwires/current/msg01410.html

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Alain Durand
Envoyé : mardi 11 mai 2010 14:25
À : Alain Durand
Cc : [email-masked]
Objet : Re: [Softwires] GI-DS-lite as working group item?

Dear working group,

   - Alain, wg co-chair.

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 11 May 2010 09:06:45 -0700 (PDT)

Hi Ahmad,

----- Original Message ----
> From: Ahmad Muhanna <[email-masked]>
> To: Alain Durand <[email-masked]>
> Sent: Tue, May 11, 2010 9:49:07 AM

Sorry that I was not at the last IETF meeting nor the 
> IETF-3GPP meeting and I am some what ignorant of the amount of support this 
> draft received and the arguments that have been used in these meetings . 
> However, declaring the adoption of this draft as a WG document in 5 days without 
> specifying a deadline seems to me a little fast!

On the other hand, 
> After reading this draft a couple of times. I failed to understand the value of 
> this solution to MIP6 and PMIP6 as they quite clearly referenced in the 
> draft.

>In other words, since mobility architecture seems to be a major 
> beneficiary target for this solution, it is quite important for us to understand 
> what this draft offers and how it fits or overlay this architecture?

DS-Lite for mobility has been discussed in our draft:
http://tools.ietf.org/id/draft-sarikaya-softwire-dslitemobility-01.txt
this draft needs to be updated but we were lazy to do so :-).

GI DS-Lite assumes an unmodified core so it works well with GTP like mobility protocols. There are other things but I don't know if it is worth discussing them.

Regards,

--b

---

From: Ahmad Muhanna <[email-masked]>
Date: Tue, 11 May 2010 12:44:58 -0400

Hi Behcet,
Please see inline.

Regards,
Ahmad
> > IETF-3GPP meeting and I am some what ignorant of the amount 
> of support 
> > this draft received and the arguments that have been used 
> in these meetings .
> > However, declaring the adoption of this draft as a WG document in 5 
> > days without specifying a deadline seems to me a little fast!
> 
> On the other hand, 
> > After reading this draft a couple of times. I failed to 
> understand the 
> > value of this solution to MIP6 and PMIP6 as they quite clearly 
> > referenced in the draft.
> 
> >beneficiary target for this solution, it is quite important 
> for us to 
> >understand  what this draft offers and how it fits or 
> overlay this architecture?
> 
[Ahmad]
So, you are saying that nothing new is needed.

> 
> GI DS-Lite assumes an unmodified core so it works well with 
> GTP like mobility protocols. There are other things but I 
> don't know if it is worth discussing them.
[Ahmad]
Are you saying that this draft proposal is for GTP based mobility solution(s) only?

---

From: Ahmad Muhanna <[email-masked]>
Date: Tue, 11 May 2010 12:47:19 -0400

Hi Behcet,
Just a clarification

Regards,
Ahmad
> So, you are saying that nothing new is needed.

[Ahmad]
Meant to add: on top of existing IETF mobility protocols.

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 11 May 2010 14:31:18 -0700

Hi Mohamed:

Sorry for the late response. We were not inclined to take the draft adoption
call to a discussion thread and hence the silence. Please see below.

You asked number of questions and all of those points were analyzed during
the IPv6 migration discussions and surely not in isolation, this was
attended by practically all the vendors and mobile operators. Two major
workshops were conducted to discuss the IPv6 migration issues in mobile
architectures. Its unfortunate, we missed you there.

Please also see the report from the 3GPP-IETF workshop. The workshop
identified GI-DS-lite as a useful tool in some configurations. Its not the
only tool, but it is one of the tools along with NAT64, useful in the IPv6
migration toolkit.

Now to this draft. The mechanism defined in GI-DS-lite draft allows us to
apply dual-stack lite approach to mobile architectures, resulting in the
following benefits.

1.) Solves the IPv4 address exhaust issue in mobile networks.
2.) Contains IPv4 to a state only in the end-point and in the CGN function.
Still allowing the end-points to access IPv4 services
3.) Provides the deployment option to move the CGN function from the gateway
and move it to the edge of the SP network. Removing traces of IPv4 and
allowing the gateway to perform packet forwarding without using IPv4 routing
state. The side affect of this is that the operator is not required to
segment IPv4 public address space across gateways and that is a key benefit
with respect to provisioning and for efficient address space management.
4.) Allows the operator to migrate various parts of the mobile network to
IPv6, in parts, EPC core, or the network Sgi.
5.) There are no changes to the end-point, unlike the other proposals that
were discussed which provide the solution for the same problem set. No
tunnel setup from the UE, no software grade and no additional overhead.

Please see below.

On 5/7/10 2:24 AM, "[email-masked]"
<[email-masked]> wrote:

> Dear Cameron, all,
> 
> GI-DSLite does not define any protocol but an architecture where a tunnel is
> used together with a new enhanced NAT44 table (because more de-multiplexing
> information than for basic NAT44 table is required). So, what should be
> standardised there?
> 

Yes. The gateway is responsible for forwarding UE's IPv4 packets. It needs
to ensure proper UE specific context identifiers are carried in the tunnel
headers. The specifics on how the gateway handles this function, how it
makes the forwarding decision needs to be standardized.

> (2) The tunnel establishment "procedure"? This is an operational consideration
> as a matter of fact. In addition, the tunnel is not required in the majority
> of the scenarios. Normal routing actions can be done in the gateway to
> redirect the traffic to the appropriate CGN. I don't see a deployment context
> where more that +16M UEs (or Access Devices) will be serviced by the same CGN
> device. 
> 

The overlay tunnel is needed.  The tunnel hides the IPv4 topology from the
network and allows a  deployment with an IPv6-only EPC core and IPv6 only
network on the Sgi interface, to allow UE's to access IPv4 services. Normal
routing actions are not sufficient in all configuration and in all
deployment models.

There is no restriction that the gateway should not handle more 16M
subscribers. Its about the platform scaling.

> (3) The structure of the enhanced NAT table?: Other proposals are on the table
> such as Layer-2 Aware NAT
> The document does not define the problem to be solved and neither why a new
> solution is required. Is the targeted problem a valid problem to be solved?
> Please find below my analysis on the mobile use case. Several scenarios can be
> envisaged as listed below:
> 
> (a) Co-located model: the NAT is co-located in the PGW/GGSN. No issue with
> private IPv4 addresses. GTP TID can even be used a de-multiplexing factor if
> required.
> 

Sure, collocated model is fine. If it works for a deployment, that is fine.
You don't need additional tools. However, in deployments where the operator
prefers to keep IPv6-only in the core network (SGi) and in the EPC core, the
gateway is not running IPv4, in that case the CGN tunnel in the GI-DS-lite's
allows the gateway to forward UE's IPv4 packets. The side affect being,
there is no need to partition the public address space across gateways, and
solves the IPv4 exhaust problem. Is that not a benefit ?

> (b) 1:1 model: the CGN and the PGW/GGSN are not embedded in the same device.
> Each PGW/GGSN is configured how to reach its attached CGN. There is no private
> IPv4 @ depletion problem.
> 

Many assumption here. You would require a tunnel, if the CGN and the gateway
are separated by an IP network beyond one hop and that network can be
IPv6-only.

> (c) N:1 model: a single CGN serve a group of PGW/GGSN. Indeed, having +16M of
> customers is a valid case. **BUT** which Service Provider will accept to
> service this huge amount of UEs with the same node (if we suppose that a mega
> centralised CGN implementation is found in the market)? This is single point
> of failure design which SHOULD NOT BE RECOMMENDED.
> 

Ignoring the 16M subscriber scaling, the solution removes the operator from
the burden of public IPv4 address space partitioning across gateways, allows
IPv6 only network (EPC + Sgi) to be deployed. Is that not a goal of IPv6
migration ? An all IPv6 network, still allowing access to IPv4 services ?

> * As currently documented, GI-DS-Lite can be deployed in fixed networks too. I
> thought (since I heard this argument several times, especially in the context
> of A+P effort) that IETF does not need any new tool for solving the IPv4
> address depletion, and DS and DS-Lite are sufficient enough in fixed networks.
> Why GI-DS-Lite should be an exception?
>

I'm not sure, how A+P competes with this. That approach was validated and
the resulting consensus. Its not fair to bring that battle to this
discussion.

> * Nothing prevent the AD (Access Device) to embed a NAT function. This leads
> to NAT444 model. Do we want to go in that direction?
>

No operator is willing to perform firmware upgrade on all handsets. That's a
cost. The solution based on this approach does not require changes to the
handset.

> * The support of IPv6 tunnels IS NOT mandatory in GI-DS-Lite. GI-DS-Lite is a
> misleading terminology. The solution can be deployed in IPv4-only networks.
> 
> * Does this solution allows for an "IPv6 introduction"-friendly path? The
> draft says "...it allows the network between the
> (i) What does that "migrate" really mean? For me, "migrate" means that actions
> are undertaken to move to an IPv6-only scheme. I could understand the
> rationale behind this sentence if a procedure to offload the traffic from
> NAT44 to NAT64 is elaborated for instance. This is not the case of GI-DS-Lite
> current spec.
>  

The tunnel specified in GI-DS-lite can use IPv4 or IPv6 transport. That
allows a deployment to remove IPv4 support in phases. It clearly allows the
operator to turn on IPv6 in steps. Migration to IPv6 is not a overnight
action, phased approach is always a better approach.

> (ii) 3GPP seems to recommend DS and IPv6-only approaches. This solution SHOULD
> part of that package and not defined as a standalone solution.
>

3GPP has adopted NAT64 approach for deployments with IPv6-only UE's. This is
additional tool for supporting a deployment with dual-stack devices.

> Technically the proposed architecture works. My concern is more about the
> validity of the deployment scenarios. This is why I re-iterate my proposal to
> adopt a big-picture approach rather than specifying one piece of the puzzle.
> 

Agree. Sure, there is a big picture view. There is no one magic transition
tool that can be a solution for all deployment variants. GI-DS-lite, NAT64
or just one of the tools in that toolkit.

> Please correct me if I missed something.

Hope this clarifies.

Regards
Sri

>> GI-DS-Lite is one option among others to limit the effect the of the IPv4
>> address depletion. It introduces a tunnel between a PGW/GGSN and a CGN, this
>> has some impacts on the gateway. This tunnel can be of any nature, IPv6 is
>> only an option.
>> 
>> Other solutions such as enabling a NAT44 (or even a NAT64 to prepare for an
>> IPv6-only mode) in the GGSN/PGW or enforce routing policies to redirect the
>> traffic to a CGN which is used to service a set of PGWs/GGSNs is also a valid
>> scenario which solves the problem addressed by GI-DS-Lite. The pressure on
>> the private IPv4 addresses if any can be solved by adopting a per-interface
>> (TID of GTP can be sued for de-multiplexing purposes, and the same private
>> IPv4 address can be assigned to requesting UEs).
>> 
>> To sum up, my proposal is: instead of adopting a document which describes one
>> possible solution, document other "viable" options too for fairness.
>> 
> 
>> I don't know if the IETF is the right place for this, but the impact of
>> GI-DS-Lite on existing 3GPP architectures should be assessed.
>> 
>> Cheers,
>> Med
>> 
>> 
>> At the 3GPP-IETF interim meeting, there was strong interest in GI DS-lite,
>> and the recommendation was the IETF should take on its standardization. There
>> was similar interest shown during the last IETF meeting and an informal show
>> of hands demonstrated large support to take GI DS-lite as a working group
>> item.
>> This of course need to be confirmed on the list, and unless we hear
>> otherwise, we, Softwires chairs, will work with our ADs to add GI-DS-lite on
>> our charter.
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 11 May 2010 18:25:57 -0400

I am somewhat confused by this description.
You seem to be saying that the primary need for gi-ds-lite is mobile. 
But the MIP related working groups don't seem to be asking for it.  And 
while 3GPP expressed interest in DS-Lite, from what I can gather they 
have not expressed particular interest in gi-ds-lite.

Usually, we make sure there is a problem before crafting a solution. 
Was there a problem statement that I missed?

Yours,
Joel

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 11 May 2010 16:26:24 -0700

Hi Joel,

> have not expressed particular interest in gi-ds-lite.

The primary consumer for Mobile IP protocols is 3GPP. There are various
interfaces that 3GPP architecture supports, that includes GTP, MIPv6 and
Proxy Mobile IPv6 based protocol interfaces. The IPv6 migration issues for
mobile architectures are generic across these protocols. The 3GPP had a
study item that identified the issues for IPv6 migration and that is
specified in 3GPP TR 23.975. The solution documented in GI-DS-lite are other
approaches that were considered are also listed in that document.
 
> Was there a problem statement that I missed?

Agree. 3GPP TR 23.975 is a good starting point.

Regards
Sri

>>>> France Telecom Group shall not be liable for the message if altered,
>>>> changed
>>>> or falsified.
>>> This message and any attachments (the "message") are confidential and
>>> intended
>>> solely for the addressees.

---

From: Ahmad Muhanna <[email-masked]>
Date: Wed, 12 May 2010 00:38:21 -0400

Hi Sri,

> [mailto:[email-masked]] On Behalf Of Sri Gundavelli
> Sent: Tuesday, May 11, 2010 6:26 PM
> To: Joel M. Halpern
> Cc: [email-masked]; BINET David NCPI/NAD/TIP
> > But the MIP related working groups don't seem to be asking for it.
> > And while 3GPP expressed interest in DS-Lite, from what I
> can gather
> > they have not expressed particular interest in gi-ds-lite.
> >
>
> The primary consumer for Mobile IP protocols is 3GPP. There
> are various interfaces that 3GPP architecture supports, that
> includes GTP, MIPv6 and Proxy Mobile IPv6 based protocol
> interfaces.
[Ahmad]
Not to question the future of MIP6 and PMIP6 in 3GPP, but may be you can explain what value add this draft has that is not currently addressed by IETF MIP6/PMIP6 suite protocols?

It seems to me that on one hand, we complain why some SDO's do not adopt IETF mobility protocols. While on the other hand, we come with solutions that basically defeat that same purpose.

Regards,
Ahmad

> The IPv6 migration issues for mobile
> architectures are generic across these protocols. The 3GPP
> had a study item that identified the issues for IPv6
> migration and that is specified in 3GPP TR 23.975. The
> solution documented in GI-DS-lite are other approaches that
> were considered are also listed in that document.
>
> >> Sorry for the late response. We were not inclined to take
> the draft
> >> adoption call to a discussion thread and hence the
> silence. Please see below.
> >>
> >> You asked number of questions and all of those points were
> analyzed
> >> during the IPv6 migration discussions and surely not in isolation,
> >> this was attended by practically all the vendors and mobile
> >> operators. Two major workshops were conducted to discuss the IPv6
> >> migration issues in mobile architectures. Its unfortunate,
> we missed you there.
> >>
> >> identified GI-DS-lite as a useful tool in some configurations. Its
> >> not the only tool, but it is one of the tools along with NAT64,
> >> useful in the IPv6 migration toolkit.
> >>
> >> Now to this draft. The mechanism defined in GI-DS-lite
> draft allows
> >> us to apply dual-stack lite approach to mobile architectures,
> >> resulting in the following benefits.
> >>
> >> 3.) Provides the deployment option to move the CGN
> function from the
> >> gateway and move it to the edge of the SP network.
> Removing traces of
> >> IPv4 and allowing the gateway to perform packet forwarding without
> >> using IPv4 routing state. The side affect of this is that the
> >> operator is not required to segment IPv4 public address
> space across
> >> gateways and that is a key benefit with respect to
> provisioning and for efficient address space management.
> >> 4.) Allows the operator to migrate various parts of the mobile
> >> network to IPv6, in parts, EPC core, or the network Sgi.
> >> 5.) There are no changes to the end-point, unlike the
> other proposals
> >> that were discussed which provide the solution for the
> same problem
> >> set. No tunnel setup from the UE, no software grade and no
> additional overhead.
> >>
> >> Please see below.
> >>
> >>
> architecture where a
> >>> tunnel is used together with a new enhanced NAT44 table (because
> >>> more de-multiplexing information than for basic NAT44 table is
> >> Yes. The gateway is responsible for forwarding UE's IPv4
> packets. It
> >> needs to ensure proper UE specific context identifiers are
> carried in
> >> the tunnel headers. The specifics on how the gateway handles this
> >> function, how it makes the forwarding decision needs to be
> standardized.
> >>
> >>
> >>> (2) The tunnel establishment "procedure"? This is an operational
> >>> consideration as a matter of fact. In addition, the tunnel is not
> >>> required in the majority of the scenarios. Normal routing actions
> >>> can be done in the gateway to redirect the traffic to the
> >>> appropriate CGN. I don't see a deployment context where more that
> >>> +16M UEs (or Access Devices) will be serviced by the same CGN
> >>> device.
> >>>
> >>
> >> The overlay tunnel is needed.  The tunnel hides the IPv4 topology
> >> from the network and allows a  deployment with an
> IPv6-only EPC core
> >> and IPv6 only network on the Sgi interface, to allow UE's
> to access
> >> IPv4 services. Normal routing actions are not sufficient in all
> >> configuration and in all deployment models.
> >>
> >>> (3) The structure of the enhanced NAT table?: Other
> proposals are on
> >>> the table such as Layer-2 Aware NAT
> (http://tools.ietf.org/html/draft-arkko-dual-stack-extra-lite-00).
> >>> Should we define a generic table structure for all enhanced NAT?
> >>>
> >>> The document does not define the problem to be solved and neither
> >>> why a new solution is required. Is the targeted problem a
> valid problem to be solved?
> >>> Please find below my analysis on the mobile use case. Several
> >>> scenarios can be envisaged as listed below:
> >>>
> >>> issue with private IPv4 addresses. GTP TID can even be used a
> >>> de-multiplexing factor if required.
> >>>
> >>
> >> You don't need additional tools. However, in deployments where the
> >> operator prefers to keep IPv6-only in the core network
> (SGi) and in
> >> the EPC core, the gateway is not running IPv4, in that
> case the CGN
> >> tunnel in the GI-DS-lite's allows the gateway to forward UE's IPv4
> >> packets. The side affect being, there is no need to partition the
> >> public address space across gateways, and solves the IPv4
> exhaust problem. Is that not a benefit ?
> >>
> >>
> >>
> >>> Each PGW/GGSN is configured how to reach its attached
> CGN. There is
> >>> no private
> >> Many assumption here. You would require a tunnel, if the
> CGN and the
> >> gateway are separated by an IP network beyond one hop and that
> >> network can be IPv6-only.
> >>
> >>
> >>> (c) N:1 model: a single CGN serve a group of PGW/GGSN. Indeed,
> >>> having +16M of customers is a valid case. **BUT** which Service
> >>> Provider will accept to service this huge amount of UEs with the
> >> Ignoring the 16M subscriber scaling, the solution removes the
> >> operator from the burden of public IPv4 address space partitioning
> >> across gateways, allows
> >> IPv6 only network (EPC + Sgi) to be deployed. Is that not
> a goal of
> >> IPv6 migration ? An all IPv6 network, still allowing
> access to IPv4 services ?
> >>
> >>
> >>> * As currently documented, GI-DS-Lite can be deployed in
> fixed networks too.
> >>> I
> >>> thought (since I heard this argument several times, especially in
> >>> the context of A+P effort) that IETF does not need any
> new tool for
> >>> solving the IPv4 address depletion, and DS and DS-Lite are
> >>> sufficient enough in fixed networks.
> >> I'm not sure, how A+P competes with this. That approach
> was validated
> >> and the resulting consensus. Its not fair to bring that battle to
> >> this discussion.
> >>
> >>
> >>> * Nothing prevent the AD (Access Device) to embed a NAT function.
> >>> This leads to NAT444 model. Do we want to go in that direction?
> >>>
> >>
> >> No operator is willing to perform firmware upgrade on all
> handsets.
> >> That's a cost. The solution based on this approach does
> not require
> >> changes to the handset.
> >>
> >>
> >>> * The support of IPv6 tunnels IS NOT mandatory in GI-DS-Lite.
> >>> GI-DS-Lite is a misleading terminology. The solution can
> be deployed
> >>> in IPv4-only networks.
> >>>
> >>> * Does this solution allows for an "IPv6 introduction"-friendly
> >>> path? The draft says "...it allows the network between the
> >>> (i) What does that "migrate" really mean? For me, "migrate" means
> >>> that actions are undertaken to move to an IPv6-only
> scheme. I could
> >>> understand the rationale behind this sentence if a procedure to
> >>> offload the traffic from
> >>> NAT44 to NAT64 is elaborated for instance. This is not
> the case of
> >>> GI-DS-Lite current spec.
> >>>
> >>
> >> The tunnel specified in GI-DS-lite can use IPv4 or IPv6 transport.
> >> That allows a deployment to remove IPv4 support in phases.
> It clearly
> >> allows the operator to turn on IPv6 in steps. Migration to IPv6 is
> >> not a overnight action, phased approach is always a better
> approach.
> >>
> >>
> >>
> >>> (ii) 3GPP seems to recommend DS and IPv6-only approaches. This
> >>> solution SHOULD part of that package and not defined as a
> standalone
> >>> solution.
> >>>
> >>
> >> 3GPP has adopted NAT64 approach for deployments with
> IPv6-only UE's.
> >> This is additional tool for supporting a deployment with
> dual-stack devices.
> >>
> >>
> >>> Technically the proposed architecture works. My concern is more
> >>> about the validity of the deployment scenarios. This is why I
> >>> re-iterate my proposal to adopt a big-picture approach
> rather than
> >>> specifying one piece of the puzzle.
> >>>
> >>
> >> Agree. Sure, there is a big picture view. There is no one magic
> >> transition tool that can be a solution for all deployment
> variants.
> >> GI-DS-lite, NAT64 or just one of the tools in that toolkit.
> >>
> >>
> >>> De : Cameron Byrne [mailto:[email-masked]] Envoyé :
> jeudi 6 mai
> >>> 2010 19:00 À : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : Alain Durand;
> >>> [email-masked]; BINET David NCPI/NAD/TIP Objet : Re:
> [Softwires]
> >>> On Thu, May 6, 2010 at 1:27 AM,
> >>>> GI-DS-Lite is one option among others to limit the effect the of
> >>>> the IPv4 address depletion. It introduces a tunnel between a
> >>>> PGW/GGSN and a CGN, this has some impacts on the gateway. This
> >>>> tunnel can be of any nature, IPv6 is only an option.
> >>>>
> >>>> Other solutions such as enabling a NAT44 (or even a NAT64 to
> >>>> prepare for an IPv6-only mode) in the GGSN/PGW or
> enforce routing
> >>>> policies to redirect the traffic to a CGN which is used
> to service
> >>>> a set of PGWs/GGSNs is also a valid scenario which solves the
> >>>> problem addressed by GI-DS-Lite. The pressure on the
> private IPv4
> >>>> addresses if any can be solved by adopting a
> per-interface (TID of
> >>>> GTP can be sued for de-multiplexing purposes, and the
> same private
> >>>> To sum up, my proposal is: instead of adopting a document which
> >>>> describes one possible solution, document other "viable" options
> >>>> too for fairness.
> >>>>
> >>> defines and evaluates solutions.  It is better to have standards
> >>> track documents to uniquely define a protocol, and then a
> separate
> >>>> I don't know if the IETF is the right place for this, but the
> >>>> impact of GI-DS-Lite on existing 3GPP architectures
> should be assessed.
> >>>>
> >>>> Cheers,
> >>>> Med
> >>>>
> >>>>
> >>>> De : [email-masked]
> [mailto:[email-masked]]
> >>>> De la part de Alain Durand Envoyé : mercredi 5 mai 2010
> 23:57 À :
> >>>> [email-masked] Objet : [Softwires] GI-DS-lite as
> working group
> >>>> item?
> >>>>
> >>>> Dear WG,
> >>>>
> >>>> At the 3GPP-IETF interim meeting, there was strong
> interest in GI
> >>>> DS-lite, and the recommendation was the IETF should take
> on its standardization.
> >>>> There
> >>>> was similar interest shown during the last IETF meeting and an
> >>>> informal show of hands demonstrated large support to take GI
> >>>> DS-lite as a working group item.
> >>>> otherwise, we, Softwires chairs, will work with our ADs to add
> >>>> GI-DS-lite on our charter.
> >>>>
> >>>> This message and any attachments (the "message") are
> confidential
> >>>> and intended solely for the addressees.
> >>>> If you are not the intended addressee of this message, please
> >>>> cancel it immediately and inform the sender.
> >>> changed or falsified.
> >>> If you are not the intended addressee of this message,
> please cancel
> >>> it immediately and inform the sender.

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 11 May 2010 22:11:07 -0700

Hi Ahmad:

On 5/11/10 9:38 PM, "Ahmad Muhanna" <[email-masked]> wrote:

> Not to question the future of MIP6 and PMIP6 in 3GPP, but may be you can
> explain what value add this draft has that is not currently addressed by IETF
> MIP6/PMIP6 suite protocols?
> 

I've explained the points in my earlier mail to Mohamed. This approach is
independent of the protocol adopted on the access layer. The access layer
can be running GTP, MIPv6 or PMIPv6. The approach allows the applicability
of Dual-stack lite solution to the mobile architectures. The migration issue
issue is not specific to a given mobility protocol and the solution is not
specific to a given protocol either.

> It seems to me that on one hand, we complain why some SDO's do not adopt IETF
> mobility protocols. While on the other hand, we come with solutions that
> basically defeat that same purpose.
>

How does this solution defeat the adoption of IETF based mobility protocols
? May be I'm missing your point.

This is a draft adoption call, if you disagree with the need for this, or on
the outcome of the 3GPP/3GPP-IETF workshop, its perfectly fine. But, there
are folks who support this approach.

Regards
Sri

---

From: Ahmad Muhanna <[email-masked]>
Date: Wed, 12 May 2010 01:15:54 -0400

Hi Sri,
One more, Please see inline.

Regards,
Ahmad

> interfaces. The IPv6 migration issues for mobile
[Ahmad]
It good to know that you are up to speed with 3GPP specifications:)

I would like to mention that GI-DS Lite is listed with a bunch (I guess 8) of other approaches in an Informative Annex in the mentioned  Technical Report. Does that constitue endorsement to GI-DS Lite approach?

Regards,
Ahmad

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 11 May 2010 22:27:56 -0700

Hi Ahmad,

Please see inline.

On 5/11/10 10:15 PM, "Ahmad Muhanna" <[email-masked]> wrote:

> I would like to mention that GI-DS Lite is listed with a bunch (I guess 8) of
> other approaches in an Informative Annex in the mentioned  Technical Report.
> Does that constitue endorsement to GI-DS Lite approach?
> 

Sure, all those 8 approaches were considered. See the report from the 3GPP
IETF workshop. 

http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Report/IP
W100060.zip

And, surely you can ignore that recommendation and we are only asking for
consensus in this group, and not base it on that recommendation. That can
only be considered as an input.

Regards
Sri

---

From: Ahmad Muhanna <[email-masked]>
Date: Wed, 12 May 2010 01:28:39 -0400

Hi Sri.

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Wednesday, May 12, 2010 12:11 AM
> To: Ahmad Muhanna; Joel M. Halpern
> >> The primary consumer for Mobile IP protocols is 3GPP. There are 
> >> various interfaces that 3GPP architecture supports, that includes 
> >> GTP, MIPv6 and Proxy Mobile IPv6 based protocol interfaces.
> > [Ahmad]
> > Not to question the future of MIP6 and PMIP6 in 3GPP, but 
> may be you 
> > can explain what value add this draft has that is not currently 
> > addressed by IETF
> I've explained the points in my earlier mail to Mohamed. This 
> approach is independent of the protocol adopted on the access 
> layer. The access layer can be running GTP, MIPv6 or PMIPv6. 
> The approach allows the applicability of Dual-stack lite 
> solution to the mobile architectures. The migration issue 
> issue is not specific to a given mobility protocol and the 
> solution is not specific to a given protocol either.
[Ahmad]
Thanks for the pointer Sri.

I understand a 3000 feet high view always is rosy:) As you know, I am actually interested in the details.
Assuming that we have all the assumptions and preconditions as documented in GI DS-Lite, why, for example, PMIP6 suite of protocols NEED this proposal.

I appreciate your detailed views.

Regards,
Ahmad 
> 
> 
> > It seems to me that on one hand, we complain why some SDO's do not 
> > adopt IETF mobility protocols. While on the other hand, we 
> come with 
> > solutions that basically defeat that same purpose.
> >
> 
> How does this solution defeat the adoption of IETF based 
> mobility protocols ? May be I'm missing your point.
> 
> This is a draft adoption call, if you disagree with the need 
> for this, or on the outcome of the 3GPP/3GPP-IETF workshop, 
> its perfectly fine. But, there are folks who support this approach.
> 
> 
> Regards
> Sri
> 
> 
>

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 11 May 2010 22:46:07 -0700

Hi Ahmad,

> Assuming that we have all the assumptions and preconditions as documented in
> GI DS-Lite, why, for example, PMIP6 suite of protocols NEED this proposal.
>

I'm not sure, why this is being tied to PMIPv6, or to one specific protocol.
As stated above, This approach is independent of the protocol adopted on the
access layer. The access layer can be running GTP, MIPv6 or PMIPv6. The
approach allows the applicability of Dual-stack lite solution to the mobile
architectures. I've already listed the benefits of this approach in my
earlier mail to Mohamed.

You can forget about the 3000 feet view, which is rosy, you can surely
ignore the 3GPP-IETF recommendation. We are asking the WG to measure the
approach on the basis of this draft alone and consider that recommendation
only as an input.

Regards
Sri

---

From: Ahmad Muhanna <[email-masked]>
Date: Wed, 12 May 2010 02:16:17 -0400

Hello Sri,

I understand what you are saying. However, I have sincere doubts on this approach being overlayed on top of current IETF mobility protocols without any impact nor interactions, in specific MIP6/PMIP6 suite of protocols. If the draft is trying to offer a solution for networks that deploy mobility architecture (IETF mobility architecture), I strongly believe that we are obligated to understand how this works and solves the issue if there is one before we adopt the draft.

I may be missing something here, but from IETF prospective, I strongly believe that the mobility groups need to look into the claim that this proposal can be overlayed on top of IETF mobility protocols without any negative impact or interaction. On the other hand, for example, if PMIP6 is deployed in a network with the assumptions and pre-conditions that GI DS-Lite highlighted and assumed, do we need this proposal?

These questions need answers! Otherwise, we are not putting the cart in front of the horse, we are putting a train:-)

Regards,
Ahmad 

> Sent: Wednesday, May 12, 2010 12:46 AM
> To: Ahmad Muhanna
> Cc: [email-masked]
> >> approach is independent of the protocol adopted on the 
> access layer. 
> >> The access layer can be running GTP, MIPv6 or PMIPv6.
> solution to 
> >> the mobile architectures. The migration issue issue is not 
> specific 
> >> to a given mobility protocol and the solution is not specific to a 
> >> given protocol either.
> > [Ahmad]
> > I understand a 3000 feet high view always is rosy:) As you 
> know, I am 
> > actually interested in the details.
> > Assuming that we have all the assumptions and preconditions as 
> > documented in GI DS-Lite, why, for example, PMIP6 suite of 
> protocols NEED this proposal.
> >
> 
> As stated above, This approach is independent of the protocol 
> adopted on the access layer. The access layer can be running 
> GTP, MIPv6 or PMIPv6. The approach allows the applicability 
> of Dual-stack lite solution to the mobile architectures. I've 
> already listed the benefits of this approach in my earlier 
> mail to Mohamed.
> 
> You can forget about the 3000 feet view, which is rosy, you 
> can surely ignore the 3GPP-IETF recommendation. We are asking 
> the WG to measure the approach on the basis of this draft 
> alone and consider that recommendation only as an input.
> 
> 
> Regards
> Sri
> 
> 
>  
> 
> 
> 
> >> How does this solution defeat the adoption of IETF based mobility 
> >> protocols ? May be I'm missing your point.
> >> 
> >> This is a draft adoption call, if you disagree with the need for 
> >> this, or on the outcome of the 3GPP/3GPP-IETF workshop, 
> its perfectly 
> >> fine. But, there are folks who support this approach.
> >> 
> >> 
> >> Regards
> >> Sri
> >> 
> >> 
> >> 
> 
>

---

From: <[email-masked]>
Date: Wed, 12 May 2010 08:25:09 +0200

Dear Sri,

Thank you for answers.

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Sri Gundavelli [mailto:[email-masked]]
Envoyé : mardi 11 mai 2010 23:31
À : BOUCADAIR Mohamed NCPI/NAD/TIP; Cameron Byrne
Cc : [email-masked]; BINET David NCPI/NAD/TIP
Objet : Re: [Softwires] GI-DS-lite as working group item?

Hi Mohamed:

Med: Since the request come from 3GPP, the applicability of the solution SHOULD NOT be beyond that scope. Furthermore, the draft should at least provide a background on the main recommendations of 3GPP SI: DS and IPv6-only and that the proposal can be used in that context. GI-DS-LITE is not mentioned anywhere that it is a MANDATORY functional block.

Med: Again, I would like to understand how this is a migration tool to IPv6. "Migrate" means moving to "IPv6-only" scheme? How this is supported in GI-DS-Lite? How you allow to offload NAT44 nodes and use IPv6?

Med: The context SHOULD be mentioned clearly in the document: Mobile+DS. All fixed use case should be removed.

1.) Solves the IPv4 address exhaust issue in mobile networks.
Med: Not specific to GI-DS-Lite

Med: Not specific to GI-DS-Lite

3.) Provides the deployment option to move the CGN function from the gateway
and move it to the edge of the SP network.

Med: In some deployments, the NAT function is already provided in the edge of the PLMN not in the gateway. Usually, it is hosted together with a firewall device.

 Removing traces of IPv4 and

Med: This is an engineering option and not a STANDARD-in-the-stone issue. IPv4 address pools can be re-used per ggsn/pgw also and therefore, there is no modification required to the gateway, right?

Med: How Gi-ds-lite allows for this?

Med: Again, this is not specific to GI-DS-Lite. Other ***configuration**** allows for this:
* co-located NAT in the gw
* dedicated NAT with routing/forwarding configuration in the gateway to reach its CGN
* NAT in the boundary of the PLMN

I don't have any issue with mentioning that gi-ds-lite is an option but I admit I'm not comfortable with seeing the IETF prefers a solution against other without any analysis of the alternative solutions.

Please see below.

Med: These modifs belong to 3GPP Specs and not the IETF. What is needed from the IETF?

Med: But this still an operational consideration.

Sure, collocated model is fine. If it works for a deployment, that is fine.
You don't need additional tools.

Med: Fine.

 However, in deployments where the operator

Med: The gateway needs to run IPv4 anyway at least to do encapsulation in IPv6 in your case. As for the partitioning of the public Ipv4 address, you will avoid it if you adopt a centralized CGN approach. It has other drawbacks such as presenting a single point of failure, etc.

Med: Yes, you are right. In the context of IPv6-only core networks, a tunnel is required but **not** an enhanced NAT44 table. A classical NAT44 table is sufficient since the NAT is aware of its gw (1:1, model).

Med: I don't see how your comment is related to my initial comment.

Med: A+P is only an example in a big list as mentioned in the annex of the current TR prepared by the IPv6 SI.

Med: Ok, for the mobile. But if the solution is deployed in fixed networks as listed in your ID (Section 7.2), what prevents the AD to embed a NAT?

Med: By introducing this IPv4 tunnel phase, you are adding another delay for IPv6. If the IPv4 address depletion issue is solved with the IPv4-flavour of GI-Ds-Lite, why should I move to IPv6? How the solution allow to move to an IPv6-only scheme (means also that only IPv6 pref are allocated to UEs, legacy UEs can continue to be allocated with IPv4 addresses, etc)

Med: You agree with what I said, gi-ds-lite should be positioned in the overall package as seems to be recommended by 3gpp and not a standalone
* Please add these elements to the ID

Hope this clarifies.

Med: Thanks for your effort. I still have some concerns.

Regards
Sri

>> intended solely for the addressees.

---

From: <[email-masked]>
Date: Wed, 12 May 2010 08:59:33 +0200

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Ahmad Muhanna
Envoyé : mercredi 12 mai 2010 08:16
À : Sri Gundavelli
Cc : [email-masked]
Objet : Re: [Softwires] GI-DS-lite as working group item?

Hello Sri,

Med: +1.

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 12 May 2010 00:11:53 -0700

Hi Mohamed,

Please see inline.

> 
> Med: Since the request come from 3GPP, the applicability of the solution
> SHOULD NOT be beyond that scope. Furthermore, the draft should at least
> provide a background on the main recommendations of 3GPP SI: DS and IPv6-only
> and that the proposal can be used in that context. GI-DS-LITE is not mentioned
> anywhere that it is a MANDATORY functional block.
> 

This can be a compromise. Surely, the primary motivation is mobile
architectures. We can discuss on the applicability note.

> Med: Again, I would like to understand how this is a migration tool to IPv6.
> "Migrate" means moving to "IPv6-only" scheme? How this is supported in
> GI-DS-Lite? How you allow to offload NAT44 nodes and use IPv6?
> 

I think I've answered this question.

UE----PGW----CGN----<internet>

For a mobile operator to transition to IPv6-only core (both EPC and Sgi),
there are three migration points. The 3GPP EPC architecture allows the
UE-PGW to have IPv6-only support, the GI-DS-lite tunnel between the PGW and
the CGN (IPv6-GRE encap) will allow IPv6-only transport network, still
enabling access to IPv4 services. This will result in an operator network
that is entire IPv6-only. So, this is the "Migrate" option that this
mechanism allows, which leads to an IPv6 only operator network.

> Med: Not specific to GI-DS-Lite

It is GI-DS-lite that is allowing this configuration. Sure, the approach is
based on DS-lite. GI-DS-lite is an extension to DS-lite applicable to
tunnel-based access architectures. So, it is specific to GI-DS-lite in this
context. Applying DS-lite as it is will result in additional tunnel, that is
the optimization.

> Med: Not specific to GI-DS-Lite

Same response as above.

> Med: In some deployments, the NAT function is already provided in the edge of
> the PLMN not in the gateway. Usually, it is hosted together with a firewall
> device.
>

That is going with the assumption that we are running IPv4 between the edge
of the PLMN and the gateway. The GI-DS-lite tunnel allows an IPv6 only
network between those points.

> Med: This is an engineering option and not a STANDARD-in-the-stone issue. IPv4
> address pools can be re-used per ggsn/pgw also and therefore, there is no
> modification required to the gateway, right?
>

The same private address space can be used across gateways. But, that
requires static provisioning of public address space. When you dont want to
do that segmentation of public pools across gateways, this solution can be
useful. Both the options are fine, based on the deployment choice.

> Med: How Gi-ds-lite allows for this?

Explained earlier with an illustration.

> * NAT in the boundary of the PLMN

Sure, that one approach with some assumptions on either the placement of the
gateway, about running IPv4 between CGN and gateway, about partitioning of
public address pools across gateways. Cannot support IPv4 endpoints, unless
the operator runs IPv4 routing protocols in the network.

> I don't have any issue with mentioning that gi-ds-lite is an option but I
> admit I'm not comfortable with seeing the IETF prefers a solution against
> other without any analysis of the alternative solutions.
> 
> Please see below.
> 

I do not think we are asking that this solution be the only option. Its just
one tool in the migration tool kit.

> Med: These modifs belong to 3GPP Specs and not the IETF. What is needed from

The approach that is standardized DS-lite, GI-DS-lite, is the generic
aspect. Not the changes in 3GPP EPC architecture. Only the generic semantics
of using softwire tunnel that can carry additional semantics.

>> consideration

Address exhaust is only one aspect. The other aspects of public pool
partitioning, or the migration to IPv6 only network is also an operational
consideration.

> Med: The gateway needs to run IPv4 anyway at least to do encapsulation in IPv6
> in your case. As for the partitioning of the public Ipv4 address, you will
> avoid it if you adopt a centralized CGN approach. It has other drawbacks such
> as presenting a single point of failure, etc.
> 

Fair enough. Its a deployment choice on how an operator prefers to place a
CGN. I do not believe we can force the operator to go with a specific
deployment configuration. Number of parameters drive that decision.

> Med: Yes, you are right. In the context of IPv6-only core networks, a tunnel
> is required but **not** an enhanced NAT44 table. A classical NAT44 table is
> sufficient since the NAT is aware of its gw (1:1, model).
>

It has to be an enhanced NAT44 table, if overlapping IPv4 address space is
in use within the same gateway scope.

> Med: I don't see how your comment is related to my initial comment.

May be I missed your point. The operator may have only 100K subscribers, but
still may want to use a common CGN for wired and wireless subscribers. So,
my point is that there are multiple reasons that will make the NAT placement
decision.

> current TR prepared by the IPv6 SI.

Ok.

> Med: Ok, for the mobile. But if the solution is deployed in fixed networks as
> listed in your ID (Section 7.2), what prevents the AD to embed a NAT?
> 

I will not argue for the support in fixed networks. So, if one can change
the end-point is fixed networks so easily, that's fine.

> Med: By introducing this IPv4 tunnel phase, you are adding another delay for
> IPv6. If the IPv4 address depletion issue is solved with the IPv4-flavour of
> GI-Ds-Lite, why should I move to IPv6? How the solution allow to move to an
> IPv6-only scheme (means also that only IPv6 pref are allocated to UEs, legacy
> UEs can continue to be allocated with IPv4 addresses, etc)
> 

We can mandate on an IPv6-only tunnel, that's a minor change But, that will
not provide a proper migration phase. The solution is providing the
semantics for an operator to depend only on IPv6. Now, to force the operator
to use IPv6-only is another consideration. But, its about normative text in
the draft.

> Med: You agree with what I said, gi-ds-lite should be positioned in the
> overall package as seems to be recommended by 3gpp and not a standalone

The spec is standardizing a specific approach, not a suite of approaches.
Surely, the NAT64 is the only option for IPv6-only UE's and that is based on
IETF specs. But, there can be separate document that can additionally make
that recommendation. I'm just not sure, how that can structured into this
draft.

> Med: Thanks for your effort. I still have some concerns.

Thanks for your discussion.

Regards
Sri

---

From: <[email-masked]>
Date: Wed, 12 May 2010 16:17:56 +0200

Re-,

Please see inline.

Cheers;
Med

-----Message d'origine-----
De : Sri Gundavelli [mailto:[email-masked]]
Envoyé : mercredi 12 mai 2010 09:12
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : [email-masked]
Objet : Re: [Softwires] GI-DS-lite as working group item?

Hi Mohamed,

Please see inline.

Med: Ok.

Med: If the network is IPv6-only (likely the major base of UEs would be IPv6-enabled, right?), the use of NAT64 would be more appropriate (hence avoiding tunnelling) that crossing a NAT44 device. No?

Med: My point was that any NAT-based solution allows to mitigate the address shortage.

> Med: Not specific to GI-DS-Lite

Same response as above.
Med: See my answers above ;-)

Med: I understand that you are claiming that gi-ds-lite benefit is only when it is deployed with IPv6 tunnelling scheme. Right?

Med: You agree that this is an operational consideration. Why then this document is in the standard track? Information would be enough.

Med: Your answer does not address this. Not sure I got how you can offload the traffic from NAT44 to a NAT64 for instance. What you are proposing can apply with the co-located model for instance.

Med: And my comment was: instead of adopting a single piece of the puzzle an overall picture should be adopted. The side effects of the proposal need to be identified, the problem to be solved needs to be sketched, alternative solutions are to be described also.

Med: Yes, and so?

Med: This is a false problem. I don't see why a single gw would have a problem of shortage of private IPv4 address. The whole pool can be used since all is hidden behind the same NAT.

Med: Again this is an operational issue, nothing to do with a standard!

Ok.

Med: BTW, for my own records, is the gi-ds-lite text still in the annex of the TR?

Med: So, please remove that text from the draft.

Med: This is why I'm asking for a big picture approach rather than atomised one.

Regards
Sri

---

From: "Nick Heatley" <[email-masked]>
Date: Thu, 13 May 2010 16:49:41 +0100

Dear All,
I would support the adoption of GI DS Lite into the Softwires WG.
It seems a good tool for use within the period from now to when
IPv6-only (services; internet; bearer network) becomes optimal. I see it
used as protection against IPv4 private address exhaustion in this
interim period.
I would expect 3GPP to do the analysis of best fit for the Mobile
architecture, using the menu of tools available from the IETF.
All the best,
Nick Heatley

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alain Durand
Sent: 05 May 2010 22:57
To: [email-masked]
Subject: [Softwires] GI-DS-lite as working group item?

Dear WG,

At the 3GPP-IETF interim meeting, there was strong interest in GI
DS-lite, and the recommendation was the IETF should take on its
standardization. There was similar interest shown during the last IETF
meeting and an informal show of hands demonstrated large support to take
GI DS-lite as a working group item.
This of course need to be confirmed on the list, and unless we hear
otherwise, we, Softwires chairs, will work with our ADs to add
GI-DS-lite on our charter.

  - Alain, softwires co-chair.
_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires
T-Mobile (UK) Limited
Company Registered Number: 02382161
Registered Office Address: Hatfield Business Park, Hatfield, Hertfordshire, AL10 9BW
Registered in England and Wales
 
NOTICE AND DISCLAIMER
 
This email (including attachments) is confidential. If you are not the intended recipient, notify the sender immediately, delete this email from your system and do not disclose or use for any purpose.

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 13 May 2010 18:19:58 -0700

Hi Mohamed,

Please see inline.

Regards
Sri

On 5/12/10 7:17 AM, "[email-masked]"
<[email-masked]> wrote:

> Med: If the network is IPv6-only (likely the major base of UEs would be
> IPv6-enabled, right?), the use of NAT64 would be more appropriate (hence
> avoiding tunnelling) that crossing a NAT44 device. No?
>

This is one debate that will never converge. Ideally, I'd like to see as
well, IPv6-only handsets with NAT64 as the mechanism for access to IPv4
content. However, industry needs experience with the NAT64 and DNS64
mechanisms and products before they turn off IPv4. During this period,
mechanisms like Dual-stack lite are critical. But, if a deployment chooses
to go that route, we should ensure we have the needed support. The final
incentive of migrating to IPv6 is possible by allowing the operator turn off
IPv4 in segments in planned timeline, not require by an overnight action,
that won't be real.

> Med: My point was that any NAT-based solution allows to mitigate the address

It does. That's one deployment model with some assumptions. There is a
motivation for other deployment models of a centralized CGN with no need for
public IPv4 address space segmentation. Both the models have merits.

> Med: See my answers above ;-)

:)

> Med: I understand that you are claiming that gi-ds-lite benefit is only when
> it is deployed with IPv6 tunnelling scheme. Right?
>

Yes. IPv6 deployment is the final goal.

> Med: You agree that this is an operational consideration. Why then this
> document is in the standard track? Information would be enough.
>

The mechanism needs to be standardized for vendor interoperability.

> Med: Your answer does not address this. Not sure I got how you can offload the
> traffic from NAT44 to a NAT64 for instance. What you are proposing can apply
> with the co-located model for instance.
>

May be I still don't follow the question. If the network has IPv6-only
transport support, but by virtue of Dual-stack lite type approaches in
place, we can support end-terminals which are dual-stack enabled, and NAT64
mechanisms for supporting terminals which are IPv6-only enabled, and so the
respective NAT44 and NAT64 usage.

To my comment that we can migrate various segments of the network to IPv6 in
steps, that is about IPv6-only EPC core and on SGi interface (Gateway - CGN)
link.

> Med: And my comment was: instead of adopting a single piece of the puzzle an
> overall picture should be adopted. The side effects of the proposal need to be
> identified, the problem to be solved needs to be sketched, alternative
> solutions are to be described also.
> 

We are not standardizing an architecture. Its a mechanism we are
standardizing. We have many tools in transitioning tool kit, there is no one
magic bullet. You can surely put all the pieces in puzzle by building the
right tools. Imagine, we work on DS-Lite, NAT64 in one document, it would
have taken few more years and with no convergence.

> partitioning, or the migration to IPv6 only network is also an operational

So, the relevance for the approach.

> Med: This is a false problem. I don't see why a single gw would have a problem
> of shortage of private IPv4 address. The whole pool can be used since all is
> hidden behind the same NAT.
> 

You are entitled to your opinion. But, this has implication on the
operator's network topology, cost and on how they want to manage the
network. I don't believe we can force them to go with one specific approach.

> Med: Again this is an operational issue, nothing to do with a standard!

Operational considerations do drive standards.

> Med: BTW, for my own records, is the gi-ds-lite text still in the annex of the

This is agreed upon in this SA2 to be to the main body of the document It CR
S2-102525. An updated CR (S2-102930) of this will make it to the main
portion of the doc.

> Med: So, please remove that text from the draft.

Like I said, we will work on the applicability note.

> Med: This is why I'm asking for a big picture approach rather than atomised

Not sure, how this changes the big picture, or removes the need for other
valid tools. We are talking about a specific mechanism needed for IPv6
migration, which is relevant in some scenarios.

---

From: <[email-masked]>
Date: Fri, 14 May 2010 10:17:46 +0200

Hi folks,

just a minor non-technical remark.

We all know that there are lots of mobile operators out there, each with a special network infrastructure and a special IPv6 integration/migration strategy. From that perspective it seems logical that we will never find the global-galatctical all fitting migration mechanism and that we have to standardize and perhaps deploy a toolset of mechanisms. At the end the provider has to choose his poisson.

As far as I understood, 3GPP has already a document where it describes what tools they need. GI DS-lite is one of the chosen tools and it fits very well to several operator networks and migration scenarios.
That's why I'm, in favor for adopting it as WG document.

And to be clear: A WG document still needs work and discussion inside the WG.
But sometimes I have the feeling that today very often the requirements for a document to become a WG item are set equal to the requirements for a WG LC.
But this may be my personal feeling only.

Kind regards
Olaf

---

From: Ahmad Muhanna <[email-masked]>
Date: Fri, 14 May 2010 08:44:45 -0400

Hi Olaf,
Please see inline.

> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Friday, May 14, 2010 3:18 AM
> To: [email-masked]
> Cc: [email-masked]

> But sometimes I have the feeling that today very often the 
> requirements for a document to become a WG item are set equal 
> to the requirements for a WG LC.
[Ahmad]
Not exactly.

I understand very well that some operators need certain specific tools to fit their own migration strategy. Additionally, I do not want to debate the best way for operators to achieve their specific migration strategy. But, the least acceptable common sense is: We can not accept a document that claim one-size-fits-all concept in order to satisfy the forth mentioned specific migration strategy. IMO, before accepting whatever document, that document needs to be specific and applicable only to that specific migration need.

Regards,
Ahmad

---

From: <[email-masked]>
Date: Fri, 14 May 2010 16:28:09 +0200

Hi Ahmad,

thanks for your answer. I've frankly to say that I've not totally understood your concerns regarding this I-D:
- Is it to limited to only one scenario or is it to broad in its approach?
- Should such a document in your understanding serve for several different network scenarios (if it could) or should it be specific and applicable only to a specific migration need?
- Would it help you to sharpen the text regarding the intent/scope of this document?

Thank you and kind regards
Olaf 

> Von: Ahmad Muhanna [mailto:[email-masked]] 
> Gesendet: Freitag, 14. Mai 2010 14:45
> An: Bonneß, Olaf; [email-masked]
> Cc: [email-masked]
> Betreff: RE: [Softwires] GI-DS-lite as working group item?
> 
> Hi Olaf,
> Please see inline.
> 
> I understand very well that some operators need certain 
> specific tools to fit their own migration strategy. 
> Additionally, I do not want to debate the best way for 
> operators to achieve their specific migration strategy. But, 
> the least acceptable common sense is: We can not accept a 
> document that claim one-size-fits-all concept in order to 
> satisfy the forth mentioned specific migration strategy. IMO, 
> before accepting whatever document, that document needs to be 
> specific and applicable only to that specific migration need.
> 
> Regards,
> Ahmad
>

---

From: Ahmad Muhanna <[email-masked]>
Date: Fri, 14 May 2010 12:11:47 -0400

Hi Olaf,

I thought that your comment was not a technical one:) so, I wanted to comment on the procedural aspect of it.
But anyhow, the draft claims applicability to network mobility with RFC3775 and RFC5213 being referenced. Having that claim in the draft is not justified and there is a need for IETF mobility group to evaluate if the current IETF mobility suite of protocols need this solution to start with. 

On the other hand, following the discussion, it is quite clear that this tool is needed when 3GPP GTP network based mobility is used. If that the case, then the draft need to reflect that specifically. Also, not to mention that although this approach moves the NAT to a single network element, but it also concentrates IPv4 traffic through a single network element creating a single point of failure.

Regards,
Ahmad 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, May 14, 2010 9:28 AM
> To: Ahmad Muhanna
> Cc: [email-masked]
> Subject: AW: [Softwires] GI-DS-lite as working group item?
> 
> Hi Ahmad,
> 
> thanks for your answer. I've frankly to say that I've not 
> totally understood your concerns regarding this I-D:
> - Should such a document in your understanding serve for 
> several different network scenarios (if it could) or should 
> it be specific and applicable only to a specific migration need?
> > > requirements for a document to become a WG item are set 
> equal to the 
> > > requirements for a WG LC.
> > [Ahmad]
> > Not exactly.
> > 
> > Additionally, I do not want to debate the best way for operators to 
> > achieve their specific migration strategy. But, the least 
> acceptable 
> > common sense is: We can not accept a document that claim 
> > one-size-fits-all concept in order to satisfy the forth mentioned 
> > specific migration strategy. IMO, before accepting whatever 
> document, 
> > that document needs to be specific and applicable only to that 
> > specific migration need.
> > 
> > Regards,
> > Ahmad
> >

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 17 May 2010 21:07:20 -0400

Hi Med,

> avoiding tunnelling) that crossing a NAT44 device. No?
For some operators, NAT64 may make more sense; for others, GI-DS-lite may be
more useful. In this end, GI-DS-lite just provides a simple way to address
the IPv4 exhaustion issue w/o change in the MH. I think there is value for
IETF to work on it.

Cheers,
Yiu

---

From: "Lee, Yiu" <[email-masked]>
Date: Mon, 17 May 2010 21:07:50 -0400

Hi Ahmad,

I am not a MIP expert. Please forgive me if I am wrong.

This draft merely specifies that the gateway is the B4 element and describes
how a CID can be constructed to tunnel the packets to AFTR. That's it. The
draft didn't alter the MH. If the MH decides to use CMIP, it can still
create a tunnel to the HA. The ds-lite softwire could happen behind the HA
which leaves the MH and HA stay untouched. For PMIP, the ds-lite gateway
"could possibly coexit" with the MAG. Since Sri is one of the author of
RFC5213, I will let him explain the details. So, I think this draft can be
used independently with or without mobility.

Cheers,
Yiu

On 5/14/10 12:11 PM, "Ahmad Muhanna" <[email-masked]> wrote:

> But anyhow, the draft claims applicability to network mobility with RFC3775
> and RFC5213 being referenced. Having that claim in the draft is not justified
> and there is a need for IETF mobility group to evaluate if the current IETF
> mobility suite of protocols need this solution to start with.
> 
> On the other hand, following the discussion, it is quite clear that this tool
> is needed when 3GPP GTP network based mobility is used. If that the case, then
> the draft need to reflect that specifically. Also, not to mention that
> although this approach moves the NAT to a single network element, but it also
> concentrates IPv4 traffic through a single network element creating a single
> point of failure.
> 
> Regards,
> Ahmad 
>

---

From: <[email-masked]>
Date: Tue, 18 May 2010 09:48:02 +0200

Hi Yiu,

Yes, I understand that point. My comment was related to the claim that GI-DS-Lite allows to "migrate" to IPv6...which I still don't agree with. 

What you mentioned is valid for any NAT-based solution. My concerns are as follows: 

(1) Since it seems that 3GPP is interested in this proposal and the 3GPP recommends DS and IPv6-only, the scope of the document should be restricted to that context. (Need to check if the GI-ds-lite has been moved to the main document of the TR of the IPv6 SI) 
(2) No Fixed network considerations should be elaborated in the document
(3) The problem statement should be clarified for IETF. Is there any issue with depletion of private IPv4 addresses? Clarify why this is a problem and for what deployment context? I still don't encourage centralise NAT approach.
(4) Ensure that the proposed solution is not another showstopper for the deployment of IPv6. This is for consistency of the overall IETF work. This does not prevent any SP to do whatever it wants, but from a standardisation perspective alternative solutions to delay IPv6 should be avoided. Gi-Ds-lite for me is one of these category of solutions. It can even lead to NAT444 since the AD can embed a NAT function.

I had other concerns with the procedure of the adoption of this document:
- It seems to me that the current charter does not allow for adopting it. I asked the chair to clarify but with no answer. 

Cheers,
Med 

-----Message d'origine-----
De : Lee, Yiu [mailto:[email-masked]] 
Envoyé : mardi 18 mai 2010 03:07
À : BOUCADAIR Mohamed NCPI/NAD/TIP; Sri Gundavelli
Cc : [email-masked]
Objet : Re: [Softwires] GI-DS-lite as working group item?

Hi Med,

Cheers,
Yiu

---

From: Ahmad Muhanna <[email-masked]>
Date: Tue, 18 May 2010 08:46:52 -0400

Hi Mohamed,

> [email-masked]
> Sent: Tuesday, May 18, 2010 2:48 AM
> To: Lee, Yiu; Sri Gundavelli
> Cc: [email-masked]
> Yes, I understand that point. My comment was related to the 
> claim that GI-DS-Lite allows to "migrate" to IPv6...which I 
> still don't agree with. 
[Ahmad]
I am sure it is clear in the minds of the authors, but at least has not been communicated with that clarity.
Only the details will reveal the capabilities of this solution and its applicability to IETF.

> (1) Since it seems that 3GPP is interested in this proposal 
> and the 3GPP recommends DS and IPv6-only, the scope of the 
> document should be restricted to that context. 
[Ahmad]
+1
To be more specific, when GTP is being used.

> (3) The problem statement should be clarified for IETF. Is 
> there any issue with depletion of private IPv4 addresses? 
> Clarify why this is a problem and for what deployment 
> context? 
[Ahmad]
+1

> I still don't encourage centralise NAT approach.
[Ahmad]
Yes. IMO, It is not a good idea.

> (4) Ensure that the proposed solution is not another 
> showstopper for the deployment of IPv6. This is for 
> consistency of the overall IETF work. This does not prevent 
> any SP to do whatever it wants, but from a standardisation 
> perspective alternative solutions to delay IPv6 should be 
> avoided. Gi-Ds-lite for me is one of these category of 
> solutions. It can even lead to NAT444 since the AD can embed 
> a NAT function.
> 
> 
> - It seems to me that the current charter does not allow for 
> adopting it. I asked the chair to clarify but with no answer. 
> 
> Cheers,
> Med 
> 
> confidential and intended solely for the addressees.

---

From: Ahmad Muhanna <[email-masked]>
Date: Tue, 18 May 2010 08:13:08 -0400

Hi Tiu,

> Since Sri is one of the author of RFC5213, I will let him 
> explain the details.
[Ahmad]
Good idea. Thanks!

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 18 May 2010 15:58:07 -0400

Hi Med,

I think we are on the same page. So your concern is the current draft didn't
limit to the scale to 3gpp. IMHO, this draft suggests a way to use a
tunnel-id to identify the client in AFTR. In this context, this doesn't
limit the scale to 3gpp only. In theory any client using tunnel may use it
(e.g. PPP). I don't now why IETF wants to limit it to 3gpp based deployment.

I don't see how this draft to suggest a centralized NAT. Can you show me any
part in the draft may have suggested that? Yes, if an operator wants to use
a giant NAT, this draft won't stop it. But this draft doesn't suggest it
either. Like what you said, this is deployment issue, not the spec enforcing
it.  

As far as proposing IPv6, I agree the draft can put more words on it. I will
try to work with the authors off-line to suggest some text to them.

Cheers,
Yiu

On 5/18/10 3:48 AM, "[email-masked]"
<[email-masked]> wrote:

> Hi Yiu,
> 
> Yes, I understand that point. My comment was related to the claim that
> GI-DS-Lite allows to "migrate" to IPv6...which I still don't agree with.
> 
> (1) Since it seems that 3GPP is interested in this proposal and the 3GPP
> recommends DS and IPv6-only, the scope of the document should be restricted to
> that context. (Need to check if the GI-ds-lite has been moved to the main
> document of the TR of the IPv6 SI)
> (3) The problem statement should be clarified for IETF. Is there any issue
> with depletion of private IPv4 addresses? Clarify why this is a problem and
> for what deployment context? I still don't encourage centralise NAT approach.
> (4) Ensure that the proposed solution is not another showstopper for the
> deployment of IPv6. This is for consistency of the overall IETF work. This
> does not prevent any SP to do whatever it wants, but from a standardisation
> perspective alternative solutions to delay IPv6 should be avoided. Gi-Ds-lite
> for me is one of these category of solutions. It can even lead to NAT444 since
> the AD can embed a NAT function.
> 
> 
> - It seems to me that the current charter does not allow for adopting it. I
> asked the chair to clarify but with no answer.
> 
> Cheers,
> Med 
>

---

From: <[email-masked]>
Date: Wed, 19 May 2010 09:48:16 +0200

Hi Yiu, 

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Lee, Yiu [mailto:[email-masked]] 
Envoyé : mardi 18 mai 2010 21:58
À : BOUCADAIR Mohamed NCPI/NAD/TIP; Sri Gundavelli
Cc : [email-masked]
Objet : Re: [Softwires] GI-DS-lite as working group item?

Hi Med,

Med: This is why I asked for a big picture view rather than a single solution. Please refer to my previous messages, I included links to http://tools.ietf.org/html/draft-miles-behave-l2nat-00 or http://tools.ietf.org/html/draft-arkko-dual-stack-extra-lite-00 for instance which are generic solutions. Should we define a generic table structure for all enhanced NAT tables? 

I don't see how this draft to suggest a centralized NAT. Can you show me any
part in the draft may have suggested that? 

Med: This is the main argument of the draft: unavailability of sufficient private IPv4 addresses to service all UEs behind a CGN. The valid scenario for GI-DS-Lite is case (c) below which is a centralised model IMHO:
(a) Co-located model: the NAT is co-located in the PGW/GGSN. No issue with private IPv4 addresses. GTP TID can be used as de-multiplexing factor if required.
(b) 1:1 model: the CGN and the PGW/GGSN are not embedded in the same device. Each PGW/GGSN is configured how to reach its attached CGN. There is no private IPv4 @ depletion problem. 
(c) N:1 model: a single CGN serve a group of PGW/GGSN. Indeed, having +16M of customers is a valid case (centralised model)

Does this make sense for you?

Yes, if an operator wants to use
a giant NAT, this draft won't stop it. But this draft doesn't suggest it
either. Like what you said, this is deployment issue, not the spec enforcing
it.

Med: Hope to see there how Gi-DS-lite is a "migration" tool for IPv6. 

Cheers,
Yiu

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 May 2010 15:49:32 -0700 (PDT)

Hi Yiu,

> This draft merely specifies that the gateway is the B4 element and 
how a CID can be constructed to tunnel the packets to AFTR. That's 
> it. The
draft didn't alter the MH. If the MH decides to use CMIP, it can 
> still
>create a tunnel to the HA. The ds-lite softwire could happen behind the 

B4 for DSMIPv6 is located at the mobile node, see http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemobility-01

> HA
which leaves the MH and HA stay untouched. For PMIP, the ds-lite 
> gateway
"could possibly coexit" with the MAG. Since Sri is one of the author 
> of
RFC5213, I will let him explain the details. So, I think this draft can 
> be

B4 for PMIPv6 is located at the MAG, see http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemobility-01

Do you think that more than one B4 is needed in DS-Lite?

Regards,

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 May 2010 15:50:06 -0700 (PDT)

Hi Yiu,

Do you think that more than one B4 is needed/ allowed in DS-Lite? If yes, I think that would complicate things a lot.

Regards,

Behcet

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 21 May 2010 16:47:10 -0400

Hi Behcet,

> B4 for DSMIPv6 is located at the mobile node, see
> http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemobility-01
>
[YL] I heard strong objection to modify the MH. Putting B4 function in the
mobile node will be a tough battle.

>  B4 for PMIPv6 is located at the MAG, see
> http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemobility-01
> 
[YL] Putting in the MAG makes sense to me.

> Do you think that more than one B4 is needed/ allowed in DS-Lite? If yes, I
> think that would complicate things a lot.
> 
[YL] Why limit to one B4? As long as each B4 has its own unique tunnel to
the AFTR, you can have as many B4 as you like.

Regards,
Yiu

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 21 May 2010 16:43:28 -0400

Hi Med,

See comments inline:

> Med: This is why I asked for a big picture view rather than a single solution.
> Please refer to my previous messages, I included links to
> http://tools.ietf.org/html/draft-miles-behave-l2nat-00 or
> http://tools.ietf.org/html/draft-arkko-dual-stack-extra-lite-00 for instance
> which are generic solutions. Should we define a generic table structure for
> all enhanced NAT tables?
> 
[YL] I think we disagree each other on this. DS-lite defines that a tunnel
identifier (tid) should be added to the NAT table. In the classic ds-lite
draft, the authors suggest the IPv6 address is the tid. In the gi-ds-lite
draft, the tid is the CID, and in the extra-lite draft, the tid is the L2
header. From the specification point of view, they are all the same.
However, we need drafts to describe how to apply this concept on different
technologies. For example, gi-dslite describes how to make the tid to the
CID in the mobile environment. So far we heard few mobile operators found it
interesting. I think there is value to have different drafts to discuss how
to define and use the dslite tunnel id in different technologies.

> Med: This is the main argument of the draft: unavailability of sufficient
> private IPv4 addresses to service all UEs behind a CGN. The valid scenario for
> GI-DS-Lite is case (c) below which is a centralised model IMHO:
> private IPv4 addresses. GTP TID can be used as de-multiplexing factor if
> required.
> customers is a valid case (centralised model)
> 
[YL] Why (c) has to be N:1? I can argue this is N:M.