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

[Sri Gundavelli <[e-mail]>]

Hi Mohamed,

Please see inline.

Regards
Sri


On 5/12/10 7:17 AM, "[e-mail]"
<[e-mail]> wrote:

> 
> Re-,
> 
> Please see inline.
> 
> Cheers;
> Med
> 
> -----Message d'origine-----
> De : Sri Gundavelli [mailto:[e-mail]]
> Envoyé : mercredi 12 mai 2010 09:12
> À : BOUCADAIR Mohamed NCPI/NAD/TIP
> Cc : [e-mail]
> Objet : Re: [Softwires] GI-DS-lite as working group item?
> 
> Hi Mohamed,
> 
> Please see inline.
> 
> 
>> 
>> 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.
>> 
> 
> This can be a compromise. Surely, the primary motivation is mobile
> architectures. We can discuss on the applicability note.
> 
> Med: Ok.
> 
> 
>> 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?
>> 
> 
> I think I've answered this question.
> 
> UE----PGW----CGN----<internet>
> 
> For a mobile operator to transition to IPv6-only core (both EPC and Sgi),
> there are three migration points. The 3GPP EPC architecture allows the
> UE-PGW to have IPv6-only support, the GI-DS-lite tunnel between the PGW and
> the CGN (IPv6-GRE encap) will allow IPv6-only transport network, still
> enabling access to IPv4 services. This will result in an operator network
> that is entire IPv6-only. So, this is the "Migrate" option that this
> mechanism allows, which leads to an IPv6 only operator network.
> 
> Med: If the network is IPv6-only (likely the major base of UEs would be
> IPv6-enabled, right?), the use of NAT64 would be more appropriate (hence
> avoiding tunnelling) that crossing a NAT44 device. No?
>

This is one debate that will never converge. Ideally, I'd like to see as
well, IPv6-only handsets with NAT64 as the mechanism for access to IPv4
content. However, industry needs experience with the NAT64 and DNS64
mechanisms and products before they turn off IPv4. During this period,
mechanisms like Dual-stack lite are critical. But, if a deployment chooses
to go that route, we should ensure we have the needed support. The final
incentive of migrating to IPv6 is possible by allowing the operator turn off
IPv4 in segments in planned timeline, not require by an overnight action,
that won't be real.


 
> 
>> 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
>> 
> 
> It is GI-DS-lite that is allowing this configuration. Sure, the approach is
> based on DS-lite. GI-DS-lite is an extension to DS-lite applicable to
> tunnel-based access architectures. So, it is specific to GI-DS-lite in this
> context. Applying DS-lite as it is will result in additional tunnel, that is
> the optimization.
> 
> Med: My point was that any NAT-based solution allows to mitigate the address
> shortage.
> 

It does. That's one deployment model with some assumptions. There is a
motivation for other deployment models of a centralized CGN with no need for
public IPv4 address space segmentation. Both the models have merits.


>> 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
>> 
> 
> Same response as above.
> Med: See my answers above ;-)
> 

:)


> 
> 
>> 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.
>> 
> 
> That is going with the assumption that we are running IPv4 between the edge
> of the PLMN and the gateway. The GI-DS-lite tunnel allows an IPv6 only
> network between those points.
> 
> Med: I understand that you are claiming that gi-ds-lite benefit is only when
> it is deployed with IPv6 tunnelling scheme. Right?
>

Yes. IPv6 deployment is the final goal.


 
> 
>>  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?
>> 
> 
> The same private address space can be used across gateways. But, that
> requires static provisioning of public address space. When you dont want to
> do that segmentation of public pools across gateways, this solution can be
> useful. Both the options are fine, based on the deployment choice.
> 
> Med: You agree that this is an operational consideration. Why then this
> document is in the standard track? Information would be enough.
>

The mechanism needs to be standardized for vendor interoperability.

 
>> 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?
>> 
> 
> Explained earlier with an illustration.
> 
> Med: Your answer does not address this. Not sure I got how you can offload the
> traffic from NAT44 to a NAT64 for instance. What you are proposing can apply
> with the co-located model for instance.
>


May be I still don't follow the question. If the network has IPv6-only
transport support, but by virtue of Dual-stack lite type approaches in
place, we can support end-terminals which are dual-stack enabled, and NAT64
mechanisms for supporting terminals which are IPv6-only enabled, and so the
respective NAT44 and NAT64 usage.

To my comment that we can migrate various segments of the network to IPv6 in
steps, that is about IPv6-only EPC core and on SGi interface (Gateway - CGN)
link.


 
>> 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
>> 
> 
> Sure, that one approach with some assumptions on either the placement of the
> gateway, about running IPv4 between CGN and gateway, about partitioning of
> public address pools across gateways. Cannot support IPv4 endpoints, unless
> the operator runs IPv4 routing protocols in the network.
> 
> 
> 
>> 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.
>> 
> 
> I do not think we are asking that this solution be the only option. Its just
> one tool in the migration tool kit.
> 
> Med: And my comment was: instead of adopting a single piece of the puzzle an
> overall picture should be adopted. The side effects of the proposal need to be
> identified, the problem to be solved needs to be sketched, alternative
> solutions are to be described also.
> 

We are not standardizing an architecture. Its a mechanism we are
standardizing. We have many tools in transitioning tool kit, there is no one
magic bullet. You can surely put all the pieces in puzzle by building the
right tools. Imagine, we work on DS-Lite, NAT64 in one document, it would
have taken few more years and with no convergence.
 


>> 
>> 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?
>> 
> 
> The approach that is standardized DS-lite, GI-DS-lite, is the generic
> aspect. Not the changes in 3GPP EPC architecture. Only the generic semantics
> of using softwire tunnel that can carry additional semantics.
> 
> 
>> 
>>> (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.
>> 
> 
> Address exhaust is only one aspect. The other aspects of public pool
> partitioning, or the migration to IPv6 only network is also an operational
> consideration.
> 
> Med: Yes, and so?
> 

So, the relevance for the approach.

>> 
>>> (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.
>> 
> 
> 
> Fair enough. Its a deployment choice on how an operator prefers to place a
> CGN. I do not believe we can force the operator to go with a specific
> deployment configuration. Number of parameters drive that decision.
> 
> 
>> 
>>> (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).
>> 
> 
> It has to be an enhanced NAT44 table, if overlapping IPv4 address space is
> in use within the same gateway scope.
> 
> Med: This is a false problem. I don't see why a single gw would have a problem
> of shortage of private IPv4 address. The whole pool can be used since all is
> hidden behind the same NAT.
> 

You are entitled to your opinion. But, this has implication on the
operator's network topology, cost and on how they want to manage the
network. I don't believe we can force them to go with one specific approach.



>> 
>>> (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.
>> 
> 
> May be I missed your point. The operator may have only 100K subscribers, but
> still may want to use a common CGN for wired and wireless subscribers. So,
> my point is that there are multiple reasons that will make the NAT placement
> decision.
> 
> Med: Again this is an operational issue, nothing to do with a standard!
> 

Operational considerations do drive standards.


> 
>> 
>>> 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.
>> 
> 
> Ok.
> 
> Med: BTW, for my own records, is the gi-ds-lite text still in the annex of the
> TR?
>

This is agreed upon in this SA2 to be to the main body of the document It CR
S2-102525. An updated CR (S2-102930) of this will make it to the main
portion of the doc.


 
> 
>> 
>>> * 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?
>> 
> 
> I will not argue for the support in fixed networks. So, if one can change
> the end-point is fixed networks so easily, that's fine.
> 
> Med: So, please remove that text from the draft.
>

Like I said, we will work on the applicability note.
 

>> 
>>> * 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)
>> 
> 
> We can mandate on an IPv6-only tunnel, that's a minor change But, that will
> not provide a proper migration phase. The solution is providing the
> semantics for an operator to depend only on IPv6. Now, to force the operator
> to use IPv6-only is another consideration. But, its about normative text in
> the draft.
> 
> Med: This is why I'm asking for a big picture approach rather than atomised
> one.
>

Not sure, how this changes the big picture, or removes the need for other
valid tools. We are talking about a specific mechanism needed for IPv6
migration, which is relevant in some scenarios.


 
> 
>> 
>>> (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
>> 
> 
> The spec is standardizing a specific approach, not a suite of approaches.
> Surely, the NAT64 is the only option for IPv6-only UE's and that is based on
> IETF specs. But, there can be separate document that can additionally make
> that recommendation. I'm just not sure, how that can structured into this
> draft.
> 
> 
> 
>> 
>>> 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.
>> 
> 
> Thanks for your discussion.
> 
> Regards
> Sri
> 
> 
> *********************************
> 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.
> ********************************
>