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

[Ahmad Muhanna <[e-mail]>]

Hi Sri,

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