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

["Joel M. Halpern" <[e-mail]>]

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

Sri Gundavelli wrote:
> 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, "[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.
> 
>  
>> (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
>> (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. 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 ?
> 
> 
>> 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.
> 
>  
>> * 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
>>    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.
> 
> 
> 
>> (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
> 
> 
>> 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
> 
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>