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 by
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 for
Re: [Softwires] I-D Action:draft-despres-softwire-sam-00.txt
Hello, Let me confirm about 2 description. 1) Section 2.5, Fragmentation Considerations For If the exterior locator family of a SAM domain is IPv4 case, you mentioned as having the Don't Fragment bit set to 1 may either be discarded (with appropriate ICMPv6 error message returned to the source). Is this(ICMPv6 error) correct way? I suppose this might be ICMP error message and not ICMPv6. 2) Section 3.2.2, Multiple IPv4 Prefixes In this section, you described as Since there are 3 domain exterior prefixes Dn, we have to choose 3 customer interior prefixes P, the lengths of each Cn must be such that k + cn + xn = 48, i.e. cn = 20 But I suppose P = K[.H] is used here and the Cn is replaced for Hn. Am I missed something? Regards, On 2010/03/02, at 3:30, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Stateless Address Mapping (SAM) for Softwire-Lite Solutions Author(s) : R. Despres Filename: draft-despres-softwire-sam-00.txt Pages : 33 Date: 2010-03-01 Stateless Address Mapping (SAM) is a generic mechanism which permits, in a number of new scenarios, to easily establish tunnels for packets of some address family to traverse domains where this family is not directly routed (softwires). It generalizes address mapping principles of already deployed technologies such as 6to4, ISATAP, and 6rd, where encapsulations of IP over IP are used for point-to- multipoint tunnels (mesh softwires). Identified use cases of SAM include native IPv6 across IPv4 NATs, IPv6 multihoming with provider-aggregatable prefixes, public IPv4 across IPv6-only domains and, to mitigate consequences of the IPv4 address shortage, extended IPv4 prefixes for statically shared IPv4 public addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-despres-softwire-sam-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. メールの添付ファイル___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --- Ruri Hiromi INTEC Systems Institute, Inc. / Keio university hir...@inetcore.com hiromi_r...@intec-si.co.jp ___ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
