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:cb.li...@gmail.com] Envoyé : jeudi 6 mai 2010 19:00 À : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : Alain Durand; softwires@ietf.org; BINET David NCPI/NAD/TIP Objet : Re: [Softwires] GI-DS-lite as working group item? On Thu, May 6, 2010 at 1:27 AM, <mohamed.boucad...@orange-ftgroup.com> 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 : softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] De la > part de Alain Durand > Envoyé : mercredi 5 mai 2010 23:57 > À : softwires@ietf.org > 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 > Softwires@ietf.org > 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 > Softwires@ietf.org > 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 Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
