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

[<[e-mail]>]

Dear Sri,

Thank you for answers.

Please see inline.

Cheers,
Med


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

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.

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.

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.

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?

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.

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

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

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

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?

4.) Allows the operator to migrate various parts of the mobile network to
IPv6, in parts, EPC core, or the network Sgi.

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

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.

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.


On 5/7/10 2:24 AM, "[e-mail]"
<[e-mail]> 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?
>
> (1) The behaviour of the gateway?
>

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.

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


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

Med: But this still an operational consideration.


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

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

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.


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

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


> (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 ?

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


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

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.

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.


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

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?


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

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.

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)


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

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


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

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

Regards
Sri


> Cheers,
> Med
>
>
> -----Message d'origine-----
> De : Cameron Byrne [mailto:[e-mail]]
> Envoyé : jeudi 6 mai 2010 19:00
> À : BOUCADAIR Mohamed NCPI/NAD/TIP
> Cc : Alain Durand; [e-mail]; BINET David NCPI/NAD/TIP
> Objet : Re: [Softwires] GI-DS-lite as working group item?
>
> On Thu, May 6, 2010 at 1:27 AM,  <[e-mail]> wrote:
>> 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.
>>
>
> 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
>
>
>> 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 : [e-mail] [mailto:[e-mail]] De la
>> part de Alain Durand
>> Envoyé : mercredi 5 mai 2010 23:57
>> À : [e-mail]
>> 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.
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>> *********************************
>> 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.
>> ********************************
>>
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>
> *********************************
> 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.
> ********************************
>
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires


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