Re: [Softwires] GI-DS-lite as working group item?
Hi Med, See comments inline: Med: This is why I asked for a big picture view rather than a single solution. Please refer to my previous messages, I included links to http://tools.ietf.org/html/draft-miles-behave-l2nat-00 or http://tools.ietf.org/html/draft-arkko-dual-stack-extra-lite-00 for instance which are generic solutions. Should we define a generic table structure for all enhanced NAT tables? [YL] I think we disagree each other on this. DS-lite defines that a tunnel identifier (tid) should be added to the NAT table. In the classic ds-lite draft, the authors suggest the IPv6 address is the tid. In the gi-ds-lite draft, the tid is the CID, and in the extra-lite draft, the tid is the L2 header. From the specification point of view, they are all the same. However, we need drafts to describe how to apply this concept on different technologies. For example, gi-dslite describes how to make the tid to the CID in the mobile environment. So far we heard few mobile operators found it interesting. I think there is value to have different drafts to discuss how to define and use the dslite tunnel id in different technologies. Med: This is the main argument of the draft: unavailability of sufficient private IPv4 addresses to service all UEs behind a CGN. The valid scenario for GI-DS-Lite is case (c) below which is a centralised model IMHO: (a) Co-located model: the NAT is co-located in the PGW/GGSN. No issue with private IPv4 addresses. GTP TID can be used as 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 (centralised model) Does this make sense for you? [YL] Why (c) has to be N:1? I can argue this is N:M. smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
Hi Yiu, Please see inline. Cheers, Med -Message d'origine- De : Lee, Yiu [mailto:yiu_...@cable.comcast.com] Envoyé : mardi 18 mai 2010 21:58 À : BOUCADAIR Mohamed NCPI/NAD/TIP; Sri Gundavelli Cc : softwires@ietf.org Objet : Re: [Softwires] GI-DS-lite as working group item? Hi Med, I think we are on the same page. So your concern is the current draft didn't limit to the scale to 3gpp. IMHO, this draft suggests a way to use a tunnel-id to identify the client in AFTR. In this context, this doesn't limit the scale to 3gpp only. In theory any client using tunnel may use it (e.g. PPP). I don't now why IETF wants to limit it to 3gpp based deployment. Med: This is why I asked for a big picture view rather than a single solution. Please refer to my previous messages, I included links to http://tools.ietf.org/html/draft-miles-behave-l2nat-00 or http://tools.ietf.org/html/draft-arkko-dual-stack-extra-lite-00 for instance which are generic solutions. Should we define a generic table structure for all enhanced NAT tables? I don't see how this draft to suggest a centralized NAT. Can you show me any part in the draft may have suggested that? Med: This is the main argument of the draft: unavailability of sufficient private IPv4 addresses to service all UEs behind a CGN. The valid scenario for GI-DS-Lite is case (c) below which is a centralised model IMHO: (a) Co-located model: the NAT is co-located in the PGW/GGSN. No issue with private IPv4 addresses. GTP TID can be used as 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 (centralised model) Does this make sense for you? Yes, if an operator wants to use a giant NAT, this draft won't stop it. But this draft doesn't suggest it either. Like what you said, this is deployment issue, not the spec enforcing it. As far as proposing IPv6, I agree the draft can put more words on it. I will try to work with the authors off-line to suggest some text to them. Med: Hope to see there how Gi-DS-lite is a migration tool for IPv6. Cheers, Yiu On 5/18/10 3:48 AM, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com wrote: Hi Yiu, Yes, I understand that point. My comment was related to the claim that GI-DS-Lite allows to migrate to IPv6...which I still don't agree with. What you mentioned is valid for any NAT-based solution. My concerns are as follows: (1) Since it seems that 3GPP is interested in this proposal and the 3GPP recommends DS and IPv6-only, the scope of the document should be restricted to that context. (Need to check if the GI-ds-lite has been moved to the main document of the TR of the IPv6 SI) (2) No Fixed network considerations should be elaborated in the document (3) The problem statement should be clarified for IETF. Is there any issue with depletion of private IPv4 addresses? Clarify why this is a problem and for what deployment context? I still don't encourage centralise NAT approach. (4) Ensure that the proposed solution is not another showstopper for the deployment of IPv6. This is for consistency of the overall IETF work. This does not prevent any SP to do whatever it wants, but from a standardisation perspective alternative solutions to delay IPv6 should be avoided. Gi-Ds-lite for me is one of these category of solutions. It can even lead to NAT444 since the AD can embed a NAT function. I had other concerns with the procedure of the adoption of this document: - It seems to me that the current charter does not allow for adopting it. I asked the chair to clarify but with no answer. Cheers, Med -Message d'origine- De : Lee, Yiu [mailto:yiu_...@cable.comcast.com] Envoyé : mardi 18 mai 2010 03:07 À : BOUCADAIR Mohamed NCPI/NAD/TIP; Sri Gundavelli Cc : softwires@ietf.org Objet : Re: [Softwires] GI-DS-lite as working group item? Hi Med, 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? For some operators, NAT64 may make more sense; for others, GI-DS-lite may be more useful. In this end, GI-DS-lite just provides a simple way to address the IPv4 exhaustion issue w/o change in the MH. I think there is value for IETF to work on it. Cheers, Yiu * 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
Re: [Softwires] GI-DS-lite as working group item?
Hi Yiu, Hi Ahmad, I am not a MIP expert. Please forgive me if I am wrong. This draft merely specifies that the gateway is the B4 element and describes how a CID can be constructed to tunnel the packets to AFTR. That's it. The draft didn't alter the MH. If the MH decides to use CMIP, it can still create a tunnel to the HA. The ds-lite softwire could happen behind the B4 for DSMIPv6 is located at the mobile node, see http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemobility-01 HA which leaves the MH and HA stay untouched. For PMIP, the ds-lite gateway could possibly coexit with the MAG. Since Sri is one of the author of RFC5213, I will let him explain the details. So, I think this draft can be used independently with or without mobility. B4 for PMIPv6 is located at the MAG, see http://tools.ietf.org/html/draft-sarikaya-softwire-dslitemobility-01 Do you think that more than one B4 is needed/ allowed in DS-Lite? If yes, I think that would complicate things a lot. Regards, Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
Hi Yiu, Yes, I understand that point. My comment was related to the claim that GI-DS-Lite allows to migrate to IPv6...which I still don't agree with. What you mentioned is valid for any NAT-based solution. My concerns are as follows: (1) Since it seems that 3GPP is interested in this proposal and the 3GPP recommends DS and IPv6-only, the scope of the document should be restricted to that context. (Need to check if the GI-ds-lite has been moved to the main document of the TR of the IPv6 SI) (2) No Fixed network considerations should be elaborated in the document (3) The problem statement should be clarified for IETF. Is there any issue with depletion of private IPv4 addresses? Clarify why this is a problem and for what deployment context? I still don't encourage centralise NAT approach. (4) Ensure that the proposed solution is not another showstopper for the deployment of IPv6. This is for consistency of the overall IETF work. This does not prevent any SP to do whatever it wants, but from a standardisation perspective alternative solutions to delay IPv6 should be avoided. Gi-Ds-lite for me is one of these category of solutions. It can even lead to NAT444 since the AD can embed a NAT function. I had other concerns with the procedure of the adoption of this document: - It seems to me that the current charter does not allow for adopting it. I asked the chair to clarify but with no answer. Cheers, Med -Message d'origine- De : Lee, Yiu [mailto:yiu_...@cable.comcast.com] Envoyé : mardi 18 mai 2010 03:07 À : BOUCADAIR Mohamed NCPI/NAD/TIP; Sri Gundavelli Cc : softwires@ietf.org Objet : Re: [Softwires] GI-DS-lite as working group item? Hi Med, 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? For some operators, NAT64 may make more sense; for others, GI-DS-lite may be more useful. In this end, GI-DS-lite just provides a simple way to address the IPv4 exhaustion issue w/o change in the MH. I think there is value for IETF to work on it. Cheers, Yiu * 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
Re: [Softwires] GI-DS-lite as working group item?
Hi Yiu, -Original Message- Since Sri is one of the author of RFC5213, I will let him explain the details. [Ahmad] Good idea. Thanks! Cheers, Yiu ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
Hi folks, just a minor non-technical remark. We all know that there are lots of mobile operators out there, each with a special network infrastructure and a special IPv6 integration/migration strategy. From that perspective it seems logical that we will never find the global-galatctical all fitting migration mechanism and that we have to standardize and perhaps deploy a toolset of mechanisms. At the end the provider has to choose his poisson. As far as I understood, 3GPP has already a document where it describes what tools they need. GI DS-lite is one of the chosen tools and it fits very well to several operator networks and migration scenarios. That's why I'm, in favor for adopting it as WG document. And to be clear: A WG document still needs work and discussion inside the WG. But sometimes I have the feeling that today very often the requirements for a document to become a WG item are set equal to the requirements for a WG LC. But this may be my personal feeling only. Kind regards Olaf ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
Hi Ahmad, thanks for your answer. I've frankly to say that I've not totally understood your concerns regarding this I-D: - Is it to limited to only one scenario or is it to broad in its approach? - Should such a document in your understanding serve for several different network scenarios (if it could) or should it be specific and applicable only to a specific migration need? - Would it help you to sharpen the text regarding the intent/scope of this document? Thank you and kind regards Olaf -Ursprüngliche Nachricht- Von: Ahmad Muhanna [mailto:ahmad.muha...@ericsson.com] Gesendet: Freitag, 14. Mai 2010 14:45 An: Bonneß, Olaf; mohamed.boucad...@orange-ftgroup.com Cc: softwires@ietf.org Betreff: RE: [Softwires] GI-DS-lite as working group item? Hi Olaf, Please see inline. -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of olaf.bonn...@telekom.de Sent: Friday, May 14, 2010 3:18 AM To: mohamed.boucad...@orange-ftgroup.com Cc: softwires@ietf.org Subject: Re: [Softwires] GI-DS-lite as working group item? Hi folks, And to be clear: A WG document still needs work and discussion inside the WG. But sometimes I have the feeling that today very often the requirements for a document to become a WG item are set equal to the requirements for a WG LC. [Ahmad] Not exactly. I understand very well that some operators need certain specific tools to fit their own migration strategy. Additionally, I do not want to debate the best way for operators to achieve their specific migration strategy. But, the least acceptable common sense is: We can not accept a document that claim one-size-fits-all concept in order to satisfy the forth mentioned specific migration strategy. IMO, before accepting whatever document, that document needs to be specific and applicable only to that specific migration need. Regards, Ahmad But this may be my personal feeling only. Kind regards Olaf ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
Dear Sri, Thank you for answers. Please see inline. Cheers, Med -Message d'origine- De : Sri Gundavelli [mailto:sgund...@cisco.com] Envoyé : mardi 11 mai 2010 23:31 À : BOUCADAIR Mohamed NCPI/NAD/TIP; Cameron Byrne Cc : softwires@ietf.org; BINET David NCPI/NAD/TIP Objet : Re: [Softwires] GI-DS-lite as working group item? 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. 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. 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? 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 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 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. 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? 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? 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 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. On 5/7/10 2:24 AM, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com 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? (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
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. 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. UEPGWCGNinternet 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. 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. 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. 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. 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. 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. 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
Re: [Softwires] GI-DS-lite as working group item?
Re-, Please see inline. Cheers; Med -Message d'origine- De : Sri Gundavelli [mailto:sgund...@cisco.com] Envoyé : mercredi 12 mai 2010 09:12 À : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : softwires@ietf.org 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. UEPGWCGNinternet 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? 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. 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? 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. 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
Re: [Softwires] GI-DS-lite as working group item?
Hi Behcet, Please see inline. Regards, Ahmad - Original Message From: Ahmad Muhanna ahmad.muha...@ericsson.com To: Alain Durand adur...@juniper.net Cc: softwires@ietf.org softwires@ietf.org Sent: Tue, May 11, 2010 9:49:07 AM Subject: Re: [Softwires] GI-DS-lite as working group item? Hi Alain, Sorry that I was not at the last IETF meeting nor the IETF-3GPP meeting and I am some what ignorant of the amount of support this draft received and the arguments that have been used in these meetings . However, declaring the adoption of this draft as a WG document in 5 days without specifying a deadline seems to me a little fast! On the other hand, After reading this draft a couple of times. I failed to understand the value of this solution to MIP6 and PMIP6 as they quite clearly referenced in the draft. In other words, since mobility architecture seems to be a major beneficiary target for this solution, it is quite important for us to understand what this draft offers and how it fits or overlay this architecture? DS-Lite for mobility has been discussed in our draft: http://tools.ietf.org/id/draft-sarikaya-softwire-dslitemobility-01.txt this draft needs to be updated but we were lazy to do so :-). [Ahmad] So, you are saying that nothing new is needed. GI DS-Lite assumes an unmodified core so it works well with GTP like mobility protocols. There are other things but I don't know if it is worth discussing them. [Ahmad] Are you saying that this draft proposal is for GTP based mobility solution(s) only? Regards, --b ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
Hi Ahmad: On 5/11/10 9:38 PM, Ahmad Muhanna ahmad.muha...@ericsson.com wrote: Hi Sri, -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Sri Gundavelli Sent: Tuesday, May 11, 2010 6:26 PM To: Joel M. Halpern Cc: softwires@ietf.org; 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 j...@joelhalpern.com 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? I've explained the points in my earlier mail to Mohamed. This approach is independent of the protocol adopted on the access layer. The access layer can be running GTP, MIPv6 or PMIPv6. The approach allows the applicability of Dual-stack lite solution to the mobile architectures. The migration issue issue is not specific to a given mobility protocol and the solution is not specific to a given protocol either. 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. How does this solution defeat the adoption of IETF based mobility protocols ? May be I'm missing your point. This is a draft adoption call, if you disagree with the need for this, or on the outcome of the 3GPP/3GPP-IETF workshop, its perfectly fine. But, there are folks who support this approach. Regards Sri ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
Hi Sri, One more, Please see inline. Regards, Ahmad -Original Message- From: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] On Behalf Of Sri Gundavelli Sent: Tuesday, May 11, 2010 6:26 PM To: Joel M. Halpern Cc: softwires@ietf.org; 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 j...@joelhalpern.com 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, mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com 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
Re: [Softwires] GI-DS-lite as working group item?
Dear Alain, all, Please see inline. Cheers, Med -Message d'origine- De : Alain Durand [mailto:adur...@juniper.net] Envoyé : vendredi 7 mai 2010 18:19 À : Behcet Sarikaya Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; softwires@ietf.org Objet : Re: [Softwires] GI-DS-lite as working group item? On May 7, 2010, at 10:55 AM, Behcet Sarikaya wrote: (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. IMHO it is N:1 and that's why GI-DS lite is interesting to the operators. I agree with you that having 16M+ MNs NAT'ed by a single CGN is something I have not heard of, yes there there is a problem. co-chair hat off: This is the N:P aspect that I find interesting in GI-DS-lite. And it does not have to be limited to 16M+ address being concentrated... nor be limited to wireless. Med: I have several questions here: 1- What do you mean by N:P? (In my first e-mail N refers to the number of gws and 1 is number of CGNs). 2- If applied to fixed networks, (*) this would lead to NAT444 design model since nothing prevent to embed a NAT function in the AD. (*) IPv6 is not a MANDATORY building block of the solution. (*) What is then the recommendation of the WG: use DS-Lite? Or GI-DS-Lite? Etc. (*) A last comment, since GI-DS-Lite is a request from the 3GPP which recommends DS and IPv6-only models, this solution SHOULD be part of that package. Think about an ISP with a number of access router and a number of centralized NATs. Each customer connected to an access router is Med: Even if centralised, having several millions of customers behind the same stateful device is not a viable approach: this node needs to support logging, LI, NAT, ALG, etc. using his own version of RFC1918. Med: Yes, I agree with this point. What GI-DS-lite enable is to implement the NAT function in a different box that potentially has different scaling properties than the access router. Med: Yes but GI-DS-Lite is not the ONLY solution which allows this. You may rely on simple routing configuration from the gateway to its associated NAT(s), use DS-Lite ;-), or use A+P to avoid having any stateful device in the core network, etc. * 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
Re: [Softwires] GI-DS-lite as working group item?
Hi Med, As I understand, N:P means you don't need to have a single NAT box in the network, some network partitioning can be done possibly geographically to allow more than one NAT boxes and then it becomes a matter of configuration to connect them to the GWs. I agree with you on the applicability of GI DS-Lite in ISP networks. Regards, Behcet From: mohamed.boucad...@orange-ftgroup.com mohamed.boucad...@orange-ftgroup.com To: Alain Durand adur...@juniper.net; Behcet Sarikaya sarik...@ieee.org Cc: softwires@ietf.org softwires@ietf.org Sent: Mon, May 10, 2010 1:37:12 AM Subject: RE: [Softwires] GI-DS-lite as working group item? Dear Alain, all, Please see inline. Cheers, Med -Message d'origine- De : Alain Durand [mailto:adur...@juniper.net] Envoyé : vendredi 7 mai 2010 18:19 À : Behcet Sarikaya Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; softwires@ietf.org Objet : Re: [Softwires] GI-DS-lite as working group item? On May 7, 2010, at 10:55 AM, Behcet Sarikaya wrote: (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. IMHO it is N:1 and that's why GI-DS lite is interesting to the operators. I agree with you that having 16M+ MNs NAT'ed by a single CGN is something I have not heard of, yes there there is a problem. co-chair hat off: This is the N:P aspect that I find interesting in GI-DS-lite. And it does not have to be limited to 16M+ address being concentrated... nor be limited to wireless. Med: I have several questions here: 1- What do you mean by N:P? (In my first e-mail N refers to the number of gws and 1 is number of CGNs). 2- If applied to fixed networks, (*) this would lead to NAT444 design model since nothing prevent to embed a NAT function in the AD. (*) IPv6 is not a MANDATORY building block of the solution. (*) What is then the recommendation of the WG: use DS-Lite? Or GI-DS-Lite? Etc. (*) A last comment, since GI-DS-Lite is a request from the 3GPP which recommends DS and IPv6-only models, this solution SHOULD be part of that package. Think about an ISP with a number of access router and a number of centralized NATs. Each customer connected to an access router is Med: Even if centralised, having several millions of customers behind the same stateful device is not a viable approach: this node needs to support logging, LI, NAT, ALG, etc. using his own version of RFC1918. Med: Yes, I agree with this point. What GI-DS-lite enable is to implement the NAT function in a different box that potentially has different scaling properties than the access router. Med: Yes but GI-DS-Lite is not the ONLY solution which allows this. You may rely on simple routing configuration from the gateway to its associated NAT(s), use DS-Lite ;-), or use A+P to avoid having any stateful device in the core network, etc. * 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
Re: [Softwires] GI-DS-lite as working group item?
Hi Alain all, I support to adopt this a WG item. I believe 3GPP is also expecting to see it progress. Regards, -- Hidetoshi 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 at ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
On May 7, 2010, at 10:55 AM, Behcet Sarikaya wrote: (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. IMHO it is N:1 and that's why GI-DS lite is interesting to the operators. I agree with you that having 16M+ MNs NAT'ed by a single CGN is something I have not heard of, yes there there is a problem. co-chair hat off: This is the N:P aspect that I find interesting in GI-DS-lite. And it does not have to be limited to 16M+ address being concentrated... nor be limited to wireless. Think about an ISP with a number of access router and a number of centralized NATs. Each customer connected to an access router is using his own version of RFC1918. What GI-DS-lite enable is to implement the NAT function in a different box that potentially has different scaling properties than the access router. - Alain. ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
I support to adopt this as a WG item. This is also required for the IPv6 migration work currently underway in 3GPP. Thanks, Parviz ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
(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. IMHO it is N:1 and that's why GI-DS lite is interesting to the operators. I agree with you that having 16M+ MNs NAT'ed by a single CGN is something I have not heard of, yes there there is a problem. co-chair hat off: This is the N:P aspect that I find interesting in GI-DS-lite. And it does not have to be limited to 16M+ address being concentrated... nor be limited to wireless. Think about an ISP with a number of access router and a number of centralized NATs. Each customer connected to an access router is using his own version of RFC1918. What GI-DS-lite enable is to implement the NAT function in a different box that potentially has different scaling properties than the access router. This is good point, yes it could be N:P which could help in scaling. However I'd rather not see GI-DS Lite applicability in ISP networks because of missing things in CGN like PCP. At least currently we don't seem to need such things for mobile nodes. Regards, Behcet ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
I'm in favor of adopting it as WG item. It's a nice piece of work and fits very well to the deployment scenarios of mobile operators. Kind regards Olaf -Ursprüngliche Nachricht- Von: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] Im Auftrag von Alain Durand Gesendet: Mittwoch, 5. Mai 2010 23:57 An: softwires@ietf.org Betreff: [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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
Support with comments. There is only on tunnel between B4 and AFTR in GI-DS-lite. In the cases, which there are duplicated addresses for UEs, it needs to identify different user. For plain IP-in-IP tunnel, there is no mean to identify user. Perhaps it could be solved in the next version of GI-DS-lite draft. B. R. Tina http://tinatsou.weebly.com/contact.html - Original Message - From: olaf.bonn...@telekom.de To: adur...@juniper.net Cc: softwires@ietf.org Sent: Thursday, May 06, 2010 3:02 PM Subject: Re: [Softwires] GI-DS-lite as working group item? I'm in favor of adopting it as WG item. It's a nice piece of work and fits very well to the deployment scenarios of mobile operators. Kind regards Olaf -Ursprüngliche Nachricht- Von: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] Im Auftrag von Alain Durand Gesendet: Mittwoch, 5. Mai 2010 23:57 An: softwires@ietf.org Betreff: [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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
+1. I am going to provide my technical comments later. Regards, Behcet - Original Message From: olaf.bonn...@telekom.de olaf.bonn...@telekom.de To: adur...@juniper.net Cc: softwires@ietf.org Sent: Thu, May 6, 2010 2:02:50 AM Subject: Re: [Softwires] GI-DS-lite as working group item? I'm in favor of adopting it as WG item. It's a nice piece of work and fits very well to the deployment scenarios of mobile operators. Kind regards Olaf -Ursprüngliche Nachricht- Von: ymailto=mailto:softwires-boun...@ietf.org; href=mailto:softwires-boun...@ietf.org;softwires-boun...@ietf.org [mailto: href=mailto:softwires-boun...@ietf.org;softwires-boun...@ietf.org] Im Auftrag von Alain Durand Gesendet: Mittwoch, 5. Mai 2010 23:57 An: href=mailto:softwires@ietf.org;softwires@ietf.org Betreff: [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 href=mailto:Softwires@ietf.org;Softwires@ietf.org href=https://www.ietf.org/mailman/listinfo/softwires; target=_blank https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list href=mailto:Softwires@ietf.org;Softwires@ietf.org href=https://www.ietf.org/mailman/listinfo/softwires; target=_blank https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
I support to adopt this a WG item. On 5/5/10 5:57 PM, Alain Durand adur...@juniper.net wrote: 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 smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
Re: [Softwires] GI-DS-lite as working group item?
Hi Tina, Question for you. When you said to identify the user, did you mean to identify the user by IPv4 address or some other means like the GRE id? The basic DS-lite always assumes no duplicate IPv4 addresses managed by one B4. Can you elaborate the question? Thanks, Yiu On 5/6/10 3:49 AM, Tina TSOU t...@huawei.com wrote: Support with comments. There is only on tunnel between B4 and AFTR in GI-DS-lite. In the cases, which there are duplicated addresses for UEs, it needs to identify different user. For plain IP-in-IP tunnel, there is no mean to identify user. Perhaps it could be solved in the next version of GI-DS-lite draft. B. R. Tina http://tinatsou.weebly.com/contact.html - Original Message - From: olaf.bonn...@telekom.de To: adur...@juniper.net Cc: softwires@ietf.org Sent: Thursday, May 06, 2010 3:02 PM Subject: Re: [Softwires] GI-DS-lite as working group item? I'm in favor of adopting it as WG item. It's a nice piece of work and fits very well to the deployment scenarios of mobile operators. Kind regards Olaf -Ursprüngliche Nachricht- Von: softwires-boun...@ietf.org [mailto:softwires-boun...@ietf.org] Im Auftrag von Alain Durand Gesendet: Mittwoch, 5. Mai 2010 23:57 An: softwires@ietf.org Betreff: [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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires smime.p7s Description: S/MIME cryptographic signature ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
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 ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
[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
