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

[Ahmad Muhanna <[e-mail]>]

Hi Sri,
One more, Please see inline.

Regards,
Ahmad

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Sri Gundavelli
> Sent: Tuesday, May 11, 2010 6:26 PM
> To: Joel M. Halpern
> Cc: [e-mail]; BINET David NCPI/NAD/TIP
> Subject: Re: [Softwires] GI-DS-lite as working group item?
>
> Hi Joel,
>
>
> On 5/11/10 3:25 PM, "Joel M. Halpern" <[e-mail]> wrote:
>
> > 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.
> >
>
> 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.
>
> > Usually, we make sure there is a problem before crafting a solution.
> > Was there a problem statement that I missed?
> >
>
> Agree. 3GPP TR 23.975 is a good starting point.
[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

>
> Regards
> Sri
>
>
>
> > 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
> >>
>
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires
>