draft-ietf-opsawg-lsn-deployment-03.txt		draft-ietf-opsawg-lsn-deployment-04.txt
	OPSAWG V. Kuarsingh, Ed.		OPSAWG V. Kuarsingh, Ed.
	Internet-Draft J. Cianfarani		Internet-Draft J. Cianfarani
	Intended status: Informational Rogers Communications		Intended status: Informational Rogers Communications
	Expires: December 29, 2013 June 27, 2013		Expires: June 26, 2014 December 23, 2013
	CGN Deployment with BGP/MPLS IP VPNs		CGN Deployment with BGP/MPLS IP VPNs
	draft-ietf-opsawg-lsn-deployment-03		draft-ietf-opsawg-lsn-deployment-04
	Abstract		Abstract
	This document specifies a framework to integrate a Network Address		This document specifies a framework to integrate a Network Address
	Translation layer into an operator's network to function as a Carrier		Translation layer into an operator's network to function as a Carrier
	Grade NAT (also known as CGN or Large Scale NAT). The CGN		Grade NAT (also known as CGN or Large Scale NAT). The CGN
	infrastructure will often form a NAT444 environment as the subscriber		infrastructure will often form a NAT444 environment as the subscriber
	home network will likely also maintain a subscriber side NAT		home network will likely also maintain a subscriber side NAT
	function. Exhaustion of the IPv4 address pool is a major driver		function. Exhaustion of the IPv4 address pool is a major driver
	compelling some operators to implement CGN. Although operators may		compelling some operators to implement CGN. Although operators may
	wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near		wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near
	term needs may not be satisfied with an IPv6 deployment alone. This		term needs may not be satisfied with an IPv6 deployment alone. This
	document provides a practical integration model which allows the CGN		document provides a practical integration model which allows the CGN
	platform to be integrated into the network meeting the connectivity		platform to be integrated into the network, meeting the connectivity
	needs of the subscriber while being mindful of not disrupting		needs of the subscriber while being mindful of not disrupting
	existing services and meeting the technical challenges that CGN		existing services and meeting the technical challenges that CGN
	brings. The model included in this document utilizes BGP/MPLS IP		brings. The model included in this document utilizes BGP/MPLS IP
	VPNs which allow for virtual routing separation helping ease the CGNs		VPNs which allow for virtual routing separation helping ease the CGNs
	impact on the network. This document does not intend to defend the		impact on the network. This document does not intend to defend the
	merits of CGN.		merits of CGN.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 46		skipping to change at page 1, line 46
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 29, 2013.		This Internet-Draft will expire on June 26, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	skipping to change at page 2, line 20		skipping to change at page 2, line 23
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
			2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. CGN Network Deployment Requirements . . . . . . . . . . . . . 4		3. CGN Network Deployment Requirements . . . . . . . . . . . . . 4
	3.1. Centralized versus Distributed Deployment . . . . . . . . 5		3.1. Centralized versus Distributed Deployment . . . . . . . . 6
	3.2. CGN and Traditional IPv4 Service Co-existence . . . . . . 6		3.2. CGN and Traditional IPv4 Service Co-existence . . . . . . 6
	3.3. CGN By-Pass . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. CGN By-Pass . . . . . . . . . . . . . . . . . . . . . . . 7
	3.4. Routing Plane Separation . . . . . . . . . . . . . . . . 6		3.4. Routing Plane Separation . . . . . . . . . . . . . . . . 7
	3.5. Flexible Deployment Options . . . . . . . . . . . . . . . 7		3.5. Flexible Deployment Options . . . . . . . . . . . . . . . 7
	3.6. IPv4 Overlap Space . . . . . . . . . . . . . . . . . . . 7		3.6. IPv4 Overlap Space . . . . . . . . . . . . . . . . . . . 8
	3.7. Transactional Logging for LSN Systems . . . . . . . . . . 7		3.7. Transactional Logging for CGN Systems . . . . . . . . . . 8
	3.8. Additional CGN Requirements . . . . . . . . . . . . . . . 8		3.8. Base CGN Requirements . . . . . . . . . . . . . . . . . . 8
	4. BGP/MPLS IP VPN based CGN Framework . . . . . . . . . . . . . 8		4. BGP/MPLS IP VPN based CGN Framework . . . . . . . . . . . . . 9
	4.1. Service Separation . . . . . . . . . . . . . . . . . . . 10		4.1. Service Separation . . . . . . . . . . . . . . . . . . . 10
	4.2. Internal Service Delivery . . . . . . . . . . . . . . . . 10		4.2. Internal Service Delivery . . . . . . . . . . . . . . . . 11
	4.2.1. Dual Stack Operation . . . . . . . . . . . . . . . . 12		4.2.1. Dual Stack Operation . . . . . . . . . . . . . . . . 13
	4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . 14		4.3. Deployment Flexibility . . . . . . . . . . . . . . . . . 15
	4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN		4.4. Comparison of BGP/MPLS IP VPN Option versus other CGN
	Attachment Options . . . . . . . . . . . . . . . . . . . 14		Attachment Options . . . . . . . . . . . . . . . . . . . 15
	4.4.1. Policy Based Routing . . . . . . . . . . . . . . . . 14		4.4.1. Policy Based Routing . . . . . . . . . . . . . . . . 15
	4.4.2. Traffic Engineering . . . . . . . . . . . . . . . . . 15		4.4.2. Traffic Engineering . . . . . . . . . . . . . . . . . 16
	4.4.3. Multiple Routing Topologies . . . . . . . . . . . . . 15		4.4.3. Multiple Routing Topologies . . . . . . . . . . . . . 16
	4.5. Multicast Considerations . . . . . . . . . . . . . . . . 15		4.5. Multicast Considerations . . . . . . . . . . . . . . . . 16
	5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 15		5. Experiences . . . . . . . . . . . . . . . . . . . . . . . . . 16
	5.1. Basic Integration and Requirements Support . . . . . . . 15		5.1. Basic Integration and Requirements Support . . . . . . . 16
	5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 16		5.2. Performance . . . . . . . . . . . . . . . . . . . . . . . 17
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 16		7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	8. BGP/MPLS IP VPN CGN Framework Discussion . . . . . . . . . . 17		8. BGP/MPLS IP VPN CGN Framework Discussion . . . . . . . . . . 18
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	10.1. Normative References . . . . . . . . . . . . . . . . . . 17		10.1. Normative References . . . . . . . . . . . . . . . . . . 18
	10.2. Informative References . . . . . . . . . . . . . . . . . 17		10.2. Informative References . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	Operators are faced with near term IPv4 address exhaustion		Operators are faced with near term IPv4 address exhaustion
	challenges. Many operators may not have a sufficient amount of IPv4		challenges. Many operators may not have a sufficient amount of IPv4
	addresses in the future to satisfy the needs of their growing		addresses in the future to satisfy the needs of their growing
	subscriber base. This challenge may also be present before or during		subscriber base. This challenge may also be present before or during
	an active transition to IPv6 somewhat complicating the overall		an active transition to IPv6 somewhat complicating the overall
	problem space.		problem space.
	To face this challenge, operators may need to deploy CGN (Carrier		To face this challenge, operators may need to deploy CGN (Carrier
	Grade NAT) as described in [RFC6888] to help extend the connectivity		Grade NAT) as described in [RFC6888] to help extend the connectivity
	matrix once IPv4 addresses caches run out on the local local		matrix once IPv4 address caches run out on the local local operator.
	operator. CGN deployments will most often be added into operator		CGN deployments will most often be added into operator networks which
	networks which already have active IPv4 and/or IPv6 services.		already have active IPv4 and/or IPv6 services.
	The addition of the CGN introduces an operator controlled and		The addition of the CGN introduces an operator controlled and
	administered translation layer which should be added in a manner		administered translation layer which should be added in a manner
	which minimizes disruption to existing services. The CGN system		which minimizes disruption to existing services. The CGN system
	addition may also include interworking in a dual stack environment		addition may also include interworking in a dual stack environment
	where the IPv4 path requires translation.		where the IPv4 path requires translation.
	This document shows how BGP/MPLS IP VPNs as described in [RFC4364]		This document shows how BGP/MPLS IP VPNs as described in [RFC4364]
	can be used to integrate the CGN infrastructure solving key		can be used to integrate the CGN infrastructure solving key
	integration challenges faced by the operator. This model has also		integration challenges faced by the operator. This model has also
	been tested and validated in real production network models and		been tested and validated in real production network models and
	allows fluid operation with existing IPv4 and IPv6 services.		allows fluid operation with existing IPv4 and IPv6 services.
			1.1. Terms
			A list of acronyms used throughout this document are defined in list
			below.
			CGN - Carrier Grade NAT
			DOCSIS - Data Over Cable Service Interface Specification
			CMTS - Cable Modem Termination System
			DSL -Digital subscriber line
			BRAS - Broadband Remote Access Server
			GGSN - Gateway GPRS Support Node
			GPRS - General Packet Radio Service
			ASN-GW - Access Service Network Gateway
	2. Motivation		2. Motivation
	The selection of CGN may be made by an operator based on a number of		The selection of CGN may be made by an operator based on a number of
	factors. The overall driver may be the depletion of IPv4 address		factors. The overall driver may be the depletion of IPv4 address
	pools which leaves little to no addresses for IPv4 service or		pools which leaves little to no addresses for IPv4 service or
	connection demand growth. IPv6 is considered the strategic answer,		connection demand growth. IPv6 is considered the strategic answer,
	but it's applicability and usefulness in many networks is limited by		but it's applicability and usefulness in many networks is limited by
	the current access network and consumer home network. Customer		the current access network and consumer home network. Customer
	environments often are filled with IPv4-Only equipment which may not		environments often are filled with IPv4-only equipment which may not
	be upgradable to IPv6.		be upgradable to IPv6.
	The ability to replace IPv4-Only equipment may be out of the control		The ability to replace IPv4-only equipment may be out of the control
	of the operator, and even when it's in the administrative control; it		of the operator, and even when it's in the administrative control, it
	poses both cost and technical challenges as operators build out		poses both cost and technical challenges as operators build out
	massive programs for equipment retirement or upgrade. These issues		massive programs for equipment retirement or upgrade. These issues
	leave an operator in a precarious position which may lead to the		leave an operator in a precarious position which may lead to the
	decision to deploy CGN. Other address IPv4 sharing options do exist		decision to deploy CGN. Other address IPv4 sharing options do exist
	which are more architecturally desirable, but the practical and		which are more architecturally desirable, but the practical and
	workable approach in many cases is a CGN deployment using the NAT444		workable approach in many cases is a CGN deployment using the NAT444
	framework.		framework.
	If the operator has chosen to deploy CGN, they should do this in a		If the operator has chosen to deploy CGN, they should do this in a
	manner as not to negatively impact the existing IPv4 or IPv6		manner as not to negatively impact the existing IPv4 or IPv6
	subscriber base. This will include solving a number of challenges		subscriber base. This will include solving a number of challenges
	since subscribers who's connections require translation will have		since subscribers whose connections require translation will have
	network routing and flow needs which are different from legacy IPv4		network routing and flow needs which are different from legacy IPv4
	connections.		connections.
	The solution will also need to work in a dual stack environment where		The solution will also need to work in a dual stack environment where
	other options such as DS-Lite [RFC6333] are not yet viable. Even		other options such as DS-Lite [RFC6333] are not yet viable. Even
	technologies like 6RD [RFC5969] still require an IPv4 connectivity		technologies like 6RD [RFC5969] still require an IPv4 connectivity
	path to service the subscriber endpoint. The solution will need to		path to service the subscriber endpoint. The solution will need to
	address basic Internet connectivity, on-net service offerings, back		address basic Internet connectivity, on-net service offerings, back
	office management, billing, policy and security models already in		office management, billing, policy and security models already in
	place within the operator's network. CGN will often integrate quite		place within the operator's network. CGN will often integrate quite
	readily with the aforementioned requirements where as other		readily with the aforementioned requirements where as other
	transition mechanism may not due to the requirements to support IPv6		transition mechanism may not due to the requirements to support IPv6
	as the base protocol for IPv4 connectivity.		as the base protocol for IPv4 connectivity.
	3. CGN Network Deployment Requirements		3. CGN Network Deployment Requirements
	If a service provider is considering a CGN deployment with a provider		If a service provider is considering a CGN deployment with a provider
	NAT44 function, there are a number of basic architectural		NAT44 function, there are a number of basic architectural
	requirements which are of importance. Preliminary architectural		requirements which are of importance. Preliminary architectural
	requirements may require all or some of the following from the		requirements may require all or some of those captured in the list
	incoming CGN system:		below. Each of the architectural requirement items listed are
			expanded upon in the following subsections. It should be noted that
			architectural CGN requirements add additive to base CGN functional
			requirements in [RFC6888]. The assessed architectural requirements
			for deployment are:
	- Support distributed (sparse) and centralized (dense) deployment		- Support distributed (sparse) and centralized (dense) deployment
	models;		models;
	- Allow co-existence with traditional IPv4 based deployments,		- Allow co-existence with traditional IPv4 based deployments,
	which provide global scoped IPv4 addresses to CPEs;		which provide global scoped IPv4 addresses to CPEs;
	- Provide a framework for CGN by-pass supporting non-translated		- Provide a framework for CGN by-pass supporting non-translated
	flows between endpoints within a provider's network;		flows between endpoints within a provider's network;
	skipping to change at page 6, line 40		skipping to change at page 7, line 20
	3.3. CGN By-Pass		3.3. CGN By-Pass
	The CGN environment is only needed for flows with translation		The CGN environment is only needed for flows with translation
	requirements. Many flows which remain within the operator's network,		requirements. Many flows which remain within the operator's network,
	do not require translation. Such services include operator offered		do not require translation. Such services include operator offered
	DNS Services, DHCP Services, NTP Services, Web Caching, E-Mail, News		DNS Services, DHCP Services, NTP Services, Web Caching, E-Mail, News
	and other services which are local to the operator's network.		and other services which are local to the operator's network.
	The operator may want to leverage opportunities to offer third		The operator may want to leverage opportunities to offer third
	parties a platform to also provide services without translation. CGN		parties a platform to also provide services without translation. CGN
	By-pass can be accomplished in many ways, but a simplistic,		by-pass can be accomplished in many ways, but a simplistic,
	deterministic and scalable model is preferred.		deterministic and scalable model is preferred.
	3.4. Routing Plane Separation		3.4. Routing Plane Separation
	Many operators will want to engineer traffic separately for CGN flows		Many operators will want to engineer traffic separately for CGN flows
	versus flows which are part of the more traditional IPv4 environment.		versus flows which are part of the more traditional IPv4 environment.
	Many times the routing of these two major flow types differ,		Many times the routing of these two major flow types differ,
	therefore route separation may be required.		therefore route separation may be required.
	Routing plane separation also allows the operator to utilize other		Routing plane separation also allows the operator to utilize other
	skipping to change at page 7, line 25		skipping to change at page 8, line 6
	The CGN deployment should also be flexible enough to change over time		The CGN deployment should also be flexible enough to change over time
	as demand for translation services increase or change as noted in		as demand for translation services increase or change as noted in
	[RFC6264]. In turn, the deployment will need to then adapt as		[RFC6264]. In turn, the deployment will need to then adapt as
	translation demand decreases caused by the transition of flows to		translation demand decreases caused by the transition of flows to
	IPv6. Translation points should be able to be placed and moved with		IPv6. Translation points should be able to be placed and moved with
	as little re-engineering effort as possible minimizing the risks to		as little re-engineering effort as possible minimizing the risks to
	the subscriber base.		the subscriber base.
	Depending on hardware capabilities, security practices and IPv4		Depending on hardware capabilities, security practices and IPv4
	address availability, the translation environments my need to be		address availability, the translation environments may need to be
	segmented and/or scaled over time to meet organic IPv4 demand growth.		segmented and/or scaled over time to meet organic IPv4 demand growth.
	Operators may also want to choose models that support transition to		Operators may also want to choose models that support transition to
	other translation environments such as DS-Lite [RFC6333] and/or NAT64		other translation environments such as DS-Lite [RFC6333] and/or NAT64
	[RFC6146]. Operators will want to seek deployment models which are		[RFC6146]. Operators will want to seek deployment models which are
	conducive to meeting these goals as well.		conducive to meeting these goals as well.
	3.6. IPv4 Overlap Space		3.6. IPv4 Overlap Space
	IPv4 address overlap for CGN translation realms may be required if		IPv4 address overlap for CGN translation realms may be required if
	insufficient IPv4 addresses are available within the operator		insufficient IPv4 addresses are available within the operator
	environment to assign internally unique IPv4 addresses to the CGN		environment to assign internally unique IPv4 addresses to the CGN
	subscriber base . The CGN deployment should provide mechanisms to		subscriber base . The CGN deployment should provide mechanisms to
	manage IPv4 overlap if required.		manage IPv4 overlap if required.
	3.7. Transactional Logging for LSN Systems		3.7. Transactional Logging for CGN Systems
	CGNs may require transactional logging since the source IP and		CGNs may require transactional logging since the source IP and
	related transport protocol information is not easily visible to		related transport protocol information is not easily visible to
	external hosts and system.		external hosts and system.
	If needed, the CGN systems should be able to generate logs which		If needed, the CGN systems should be able to generate logs which
	identify 'internal' host parameters (i.e. IP/Port) and associated		identify 'internal' host parameters (i.e. IP/Port) and associated
	them to external translated parameters imposed by the translator.		them to external translated parameters imposed by the translator.
	The logged information should be stored on the CGN hardware and/or		The logged information should be stored on the CGN hardware and/or
	exported to an external system for processing. The operator may		exported to an external system for processing. The operator may
	choose to also enable mechanisms to help reduce logging such as block		choose to also enable mechanisms to help reduce logging such as block
	allocation of UDP and TCP ports or deterministic translation options		allocation of UDP and TCP ports or deterministic translation options
	such as [I-D.donley-behave-deterministic-cgn].		such as [I-D.donley-behave-deterministic-cgn].
	Operators may need to keep track of this information (securely) to		Operators may need to keep track of this information (securely) to
	meet regulatory and/or legal obligations. Further information can be		meet regulatory and/or legal obligations. Further information can be
	found in [RFC6888] with respect to CGN logging requirements (Logging		found in [RFC6888] with respect to CGN logging requirements (Logging
	Section).		Section).
	3.8. Additional CGN Requirements		3.8. Base CGN Requirements
	The CGN platform will also need to meet the needs of additional		Whereas the requirements above represent assessed architectural
	requirements such as Bulk Port Allocation and other CGN device		requirements, the CGN platform will also need to meet the need to
	specific functions. These additional requirements are captured		meet the base CGN requirements of a CGN function. Base requirements
	within [RFC6888].		include such functions as Bulk Port Allocation and other CGN device
			specific functions. These base CGN platform requirements are
			captured within [RFC6888].
	4. BGP/MPLS IP VPN based CGN Framework		4. BGP/MPLS IP VPN based CGN Framework
	The BGP/MPLS IP VPN [RFC4364] framework for CGN segregates the 'pre-		The BGP/MPLS IP VPN [RFC4364] framework for CGN segregates the 'pre-
	translated' realms within the service provider space into Layer-3		translated' realms within the service provider space into Layer-3
	MPLS based VPNs. The operator can deploy a single realm for all CGN		MPLS based VPNs. The operator can deploy a single realm for all CGN
	based flows, or can deploy multiple realms based on translation		based flows, or can deploy multiple realms based on translation
	demand and other factors such as geographical proximity. A realm in		demand and other factors such as geographical proximity. A realm in
	this model refers to a 'VPN' which shares a unique Route		this model refers to a 'VPN' which shares a unique Route
	Distinguisher/Route Target (RD/RT) combination, routing plane and		Distinguisher/Route Target (RD/RT) combination, routing plane and
	skipping to change at page 11, line 45		skipping to change at page 12, line 41
	| Local |		| Local |
	| Content |		| Content |
	+-----------+		+-----------+
	Figure 2: Internal Services and CGN By-Pass		Figure 2: Internal Services and CGN By-Pass
	An extension to the services delivery LSP is the ability to also		An extension to the services delivery LSP is the ability to also
	provide direct subscriber to subscriber traffic flows between CGN		provide direct subscriber to subscriber traffic flows between CGN
	zones. Each zone or realm may be fitted with separate CGN resources,		zones. Each zone or realm may be fitted with separate CGN resources,
	but the subtending subscribers don't necessarily need to be mediated		but the subtending subscribers don't necessarily need to be mediated
	(translated) by the CGN translators. This option, as shown in Figure		(translated) by the CGN translators. This option, as shown in
	3 below, is easy to implement and can only be enabled if no IPv4		Figure 3 below, is easy to implement and can only be enabled if no
	address overlap is used between communicating CGN zones.		IPv4 address overlap is used between communicating CGN zones.
	Access Node-1 VRF Termination CGN-1		Access Node-1 VRF Termination CGN-1
	+-------------+ +-----------+ +----------+		+-------------+ +-----------+ +----------+
	| | | | | |		| | | | | |
	CPE-1 | +---------+ | | +-------+ | | +------+ |		CPE-1 | +---------+ | | +-------+ | | +------+ |
	+-----+ | | | | | | | | | | | |		+-----+ | | | | | | | | | | | |
	| --+--+-+- VRF --+-+-+ | | VRF | | | | | |		| --+--+-+- VRF --+-+-+ | | VRF | | | | | |
	+-----+ | | | | | | | | | | | | |		+-----+ | | | | | | | | | | | | |
	| +---------+ | | | +-------+ | | | | |		| +---------+ | | | +-------+ | | | | |
	| | | | | | |XLATE | |		| | | | | | |XLATE | |
	| | | | | | | | |		| | | | | | | | |
	CPE-2 | +---------+ | | | +-------+ | | | | |		CPE-2 | +---------+ | | | +-------+ | | | | |
	+-----+ | | | | | | | | | | | | |		+-----+ | | | | | | | | | | | | |
	| --+--+-+- GRT | | | | | GRT | | | | | |		| --+--+-+- GRT | | | | | GRT | | | | | |
	+-----+ | | | | | | | | | | | | |		+-----+ | | | | | | | | | | | | |
	| +---------+ | | | +-------+ | | +------+ |		| +---------+ | | | +-------+ | | +------+ |
	+-------------+ | +-----------+ +----------+		+-------------+ | +-----------+ +----------+
	|		|
	LSP |		LSP |
	|		|
	Access Node-2 | VRF Termination CGN-2		Access Node-2 | VRF Termination CGN-2
	+-------------+ | +-----------+ +----------+		+-------------+ | +-----------+ +----------+
	| | | | | | |		| | | | | | |
	CPE-3 | +---------+ | | | +-------+ | | +------+ |		CPE-3 | +---------+ | | | +-------+ | | +------+ |
	+-----+ | | | | | | | | | | | | |		+-----+ | | | | | | | | | | | | |
	| --+--+-+-- VRF --+-+-+ | | VRF | | | | | |		| --+--+-+-- VRF --+-+-+ | | VRF | | | | | |
	+-----+ | | | | | | | | | | | |		+-----+ | | | | | | | | | | | |
	| +---------+ | | +-------+ | | | | |		| +---------+ | | +-------+ | | | | |
	| | | | | |XLATE | |		| | | | | |XLATE | |
	| | | | | | | |		| | | | | | | |
	CPE-4 | +---------+ | | +-------+ | | | | |		CPE-4 | +---------+ | | +-------+ | | | | |
	+-----+ | | | | | | | | | | | |		+-----+ | | | | | | | | | | | |
	| --+--+-+- GRT | | | | GRT | | | | | |		| --+--+-+- GRT | | | | GRT | | | | | |
	+-----+ | | | | | | | | | | | |		+-----+ | | | | | | | | | | | |
	| +---------+ | | +-------+ | | +------+ |		| +---------+ | | +-------+ | | +------+ |
	+-------------+ +-----------+ +----------+		+-------------+ +-----------+ +----------+
	The inherent capabilities of the BGP/MPLS IP VPN model demonstrates		The inherent capabilities of the BGP/MPLS IP VPN model demonstrates
	the ability to offer CGN By-Pass in a standard and deterministic		the ability to offer CGN By-Pass in a standard and deterministic
	manner without the need of policy based routing or traffic		manner without the need of policy based routing or traffic
	engineering.		engineering.
	4.2.1. Dual Stack Operation		4.2.1. Dual Stack Operation
	The BGP/MPLS IP VPN CGN model can also be used in conjunction with		The BGP/MPLS IP VPN CGN model can also be used in conjunction with
	IPv4/IPv6 dual stack service modes. Since many providers will use		IPv4/IPv6 dual stack service modes. Since many providers will use
	skipping to change at page 16, line 31		skipping to change at page 17, line 31
	between zones with some impact to extranet service model)		between zones with some impact to extranet service model)
	- Simple failover techniques can be implemented with redundant		- Simple failover techniques can be implemented with redundant
	translators, such as using a second default route		translators, such as using a second default route
	5.2. Performance		5.2. Performance
	The MPLS/VPN CGN model was observed to support basic functions which		The MPLS/VPN CGN model was observed to support basic functions which
	are typically used by subscribes within an operator environment. A		are typically used by subscribes within an operator environment. A
	full review of the observed impacts related to CGN (NAT444) are		full review of the observed impacts related to CGN (NAT444) are
	covered in [I-D.donley-nat444-impacts].		covered in [RFC7021].
	6. IANA Considerations		6. IANA Considerations
	There are not specific IANA considerations known at this time with		There are not specific IANA considerations known at this time with
	the architecture described herein. Should a provide choose to use		the architecture described herein. Should a provide choose to use
	non-assigned IP address space within their translation realms, then		non-assigned IP address space within their translation realms, then
	considerations may apply.		considerations may apply.
	7. Security Considerations		7. Security Considerations
	skipping to change at page 17, line 43		skipping to change at page 18, line 43
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, February 2006.		Networks (VPNs)", RFC 4364, February 2006.
	10.2. Informative References		10.2. Informative References
	[I-D.donley-behave-deterministic-cgn]		[I-D.donley-behave-deterministic-cgn]
	Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K.,		Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K.,
	and O. Vautrin, "Deterministic Address Mapping to Reduce		and O. Vautrin, "Deterministic Address Mapping to Reduce
	Logging in Carrier Grade NAT Deployments", draft-donley-		Logging in Carrier Grade NAT Deployments", draft-donley-
	behave-deterministic-cgn-05 (work in progress), January		behave-deterministic-cgn-06 (work in progress), July 2013.
	2013.
	[I-D.donley-nat444-impacts]
	Donley, C., Howard, L., Kuarsingh, V., Berg, J., and U.
	Colorado, "Assessing the Impact of Carrier-Grade NAT on
	Network Applications", draft-donley-nat444-impacts-06
	(work in progress), April 2013.
	[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and		[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
	E. Lear, "Address Allocation for Private Internets", BCP		E. Lear, "Address Allocation for Private Internets", BCP
	5, RFC 1918, February 1996.		5, RFC 1918, February 1996.
	[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol		[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
	Label Switching Architecture", RFC 3031, January 2001.		Label Switching Architecture", RFC 3031, January 2001.
	[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS		[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
	Multicast Encapsulations", RFC 5332, August 2008.		Multicast Encapsulations", RFC 5332, August 2008.
	skipping to change at page 18, line 46		skipping to change at page 19, line 39
	VPNs", RFC 6513, February 2012.		VPNs", RFC 6513, February 2012.
	[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and		[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
	M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address		M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
	Space", BCP 153, RFC 6598, April 2012.		Space", BCP 153, RFC 6598, April 2012.
	[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,		[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
	and H. Ashida, "Common Requirements for Carrier-Grade NATs		and H. Ashida, "Common Requirements for Carrier-Grade NATs
	(CGNs)", BCP 127, RFC 6888, April 2013.		(CGNs)", BCP 127, RFC 6888, April 2013.
			[RFC7021] Donley, C., Howard, L., Kuarsingh, V., Berg, J., and J.
			Doshi, "Assessing the Impact of Carrier-Grade NAT on
			Network Applications", RFC 7021, September 2013.
	Authors' Addresses		Authors' Addresses
	Victor Kuarsingh (editor)		Victor Kuarsingh (editor)
	Rogers Communications		Rogers Communications
	8200 Dixie Road		8200 Dixie Road
	Brampton, Ontario L6T 0C1		Brampton, Ontario L6T 0C1
	Canada		Canada
	Email: victor@jvknet.com		Email: victor@jvknet.com
	URI: http://www.rogers.com		URI: http://www.rogers.com
	John Cianfarani		John Cianfarani
	Rogers Communications		Rogers Communications
	8200 Dixie Road		8200 Dixie Road
	Brampton, Ontario L6T 0C1		Brampton, Ontario L6T 0C1
	Canada		Canada
	Email: john.cianfarani@rci.rogers.com		Email: john.cianfarani@rci.rogers.com
	URI: http://www.rogers.com		URI: http://www.rogers.com
End of changes. 29 change blocks.
	96 lines changed or deleted		121 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/