draft-ietf-mpls-seamless-mpls-04.txt		draft-ietf-mpls-seamless-mpls-05.txt
	MPLS Working Group N. Leymann, Ed.		MPLS Working Group N. Leymann, Ed.
	Internet-Draft Deutsche Telekom AG		Internet-Draft Deutsche Telekom AG
	Intended status: Informational B. Decraene		Intended status: Informational B. Decraene
	Expires: January 17, 2014 Orange		Expires: July 16, 2014 Orange
	C. Filsfils		C. Filsfils
	M. Konstantynowicz, Ed.		M. Konstantynowicz, Ed.
	Cisco Systems		Cisco Systems
	D. Steinberg		D. Steinberg
	Steinberg Consulting		Steinberg Consulting
	July 16, 2013		January 12, 2014
	Seamless MPLS Architecture		Seamless MPLS Architecture
	draft-ietf-mpls-seamless-mpls-04		draft-ietf-mpls-seamless-mpls-05
	Abstract		Abstract
	This documents describes an architecture which can be used to extend		This documents describes an architecture which can be used to extend
	MPLS networks to integrate access and aggregation networks into a		MPLS networks to integrate access and aggregation networks into a
	single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is		single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is
	based on existing and well known protocols. It provides a highly		based on existing and well known protocols. It provides a highly
	flexible and a scalable architecture and the possibility to integrate		flexible and a scalable architecture and the possibility to integrate
	100.000 of nodes. The separation of the service and transport plane		100.000 of nodes. The separation of the service and transport plane
	is one of the key elements; Seamless MPLS provides end to end service		is one of the key elements; Seamless MPLS provides end to end service
	skipping to change at page 1, line 49		skipping to change at page 1, line 49
	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 January 17, 2014.		This Internet-Draft will expire on July 16, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 29		skipping to change at page 2, line 29
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Why Seamless MPLS . . . . . . . . . . . . . . . . . . . . 6		2.1. Why Seamless MPLS . . . . . . . . . . . . . . . . . . . . 6
	2.2. Use Case #1 . . . . . . . . . . . . . . . . . . . . . . . 7		2.2. Use Case #1 . . . . . . . . . . . . . . . . . . . . . . . 7
	2.2.1. Description . . . . . . . . . . . . . . . . . . . . . 7		2.2.1. Description . . . . . . . . . . . . . . . . . . . . . 7
	2.2.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 9		2.2.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 10
	2.3. Use Case #2 . . . . . . . . . . . . . . . . . . . . . . . 10		2.3. Use Case #2 . . . . . . . . . . . . . . . . . . . . . . . 10
	2.3.1. Description . . . . . . . . . . . . . . . . . . . . . 10		2.3.1. Description . . . . . . . . . . . . . . . . . . . . . 10
	2.3.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 11		2.3.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 12
	3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12		3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 12		3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 13
	3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . 12		3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . 13
	3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 13		3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 13
	3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . 13		3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . 14
	3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 13		3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14
	3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 13		3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 14
	3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14		3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 15
	3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 14		3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 15
	4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 14		4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15
	4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 14		4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15
	4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . 15		4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . 15
	4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 15		4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 16
	4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 15		4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 16
	4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 16		4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 16
	4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 16		4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 17
	5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 16		5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 17
	5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 16		5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . 17
	5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 17		5.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 17
	5.1.2. General Network Topology . . . . . . . . . . . . . . 17		5.1.2. General Network Topology . . . . . . . . . . . . . . 17
	5.1.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . 18		5.1.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . 18
	5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 18		5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 19
	5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 18		5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 19
	5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 18		5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19
	5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 18		5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 19
	5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 19		5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 20
	5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 20		5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 20
	5.1.7. Labeled iBGP next-hop handling . . . . . . . . . . . 20		5.1.7. Labeled iBGP next-hop handling . . . . . . . . . . . 21
	5.1.8. Network Availability . . . . . . . . . . . . . . . . 21		5.1.8. Network Availability . . . . . . . . . . . . . . . . 22
	5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 21		5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 22
	5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 22		5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 23
	5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent		5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent
	Convergence . . . . . . . . . . . . . . . . . . . 22		Convergence . . . . . . . . . . . . . . . . . . . 23
	5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 23		5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 24
	5.1.8.5. Assessing loss of connectivity upon any failure . 24		5.1.8.5. Assessing loss of connectivity upon any failure . 24
	5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 28		5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 28
	5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 29		5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 29
	5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 29		5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 30
	5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 30		5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 30
	5.2.1. Control and Data Plane State for Deployment Scenario		5.2.1. Control and Data Plane State for Deployment Scenario
	#1 . . . . . . . . . . . . . . . . . . . . . . . . . 30		#1 . . . . . . . . . . . . . . . . . . . . . . . . . 30
	5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 30		5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 30
	5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 30		5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 31
	5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 32		5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 32
	5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 33		5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 33
	5.2.1.5. Numerical application for use case #1 . . . . . . 33		5.2.1.5. Numerical application for use case #1 . . . . . . 34
	5.2.1.6. Numerical application for use case #2 . . . . . . 34		5.2.1.6. Numerical application for use case #2 . . . . . . 35
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 35		8. Security Considerations . . . . . . . . . . . . . . . . . . . 36
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
	9.1. Normative References . . . . . . . . . . . . . . . . . . 35		9.1. Normative References . . . . . . . . . . . . . . . . . . 36
	9.2. Informative References . . . . . . . . . . . . . . . . . 36		9.2. Informative References . . . . . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	MPLS as a mature and well known technology is widely deployed in		MPLS as a mature and well known technology is widely deployed in
	today's core and aggregation/metro area networks. Many metro area		today's core and aggregation/metro area networks. Many metro area
	networks are already based on MPLS delivering Ethernet services to		networks are already based on MPLS delivering Ethernet services to
	residential and business customers. Until now those deployments are		residential and business customers. Until now those deployments are
	usually done in different domains; e.g. core and metro area networks		usually done in different domains; e.g. core and metro area networks
	are handled as separate MPLS domains.		are handled as separate MPLS domains.
	skipping to change at page 6, line 12		skipping to change at page 6, line 12
	points which can be virtually everywhere in the network. This		points which can be virtually everywhere in the network. This
	enables network and service providers with a flexible service and		enables network and service providers with a flexible service and
	service creation. Service creation can be done based on the existing		service creation. Service creation can be done based on the existing
	requirements without the needs for dedicated service creation areas		requirements without the needs for dedicated service creation areas
	on fixed locations. With the flexibility of Seamless MPLS the		on fixed locations. With the flexibility of Seamless MPLS the
	service creation can be done anywhere in the network and easily moved		service creation can be done anywhere in the network and easily moved
	between different locations.		between different locations.
	2.1. Why Seamless MPLS		2.1. Why Seamless MPLS
	Multiple SP plan to deploy networks with 10k to 100k MPLS nodes.		Multiple Service Providers plan to deploy networks with 10k to 100k
	This is typically at least one order of magnitude higher than typical		MPLS nodes, with varying levels of MPLS LSP connectivity between
	deployments and may require a new architecture. Multiple options are		those nodes - sparse-mesh in access, partial-mesh in aggregation and
	possible and it makes sense for the industry (both vendors and SP) to		full-mesh in core. This is typically at least one order of magnitude
	restrict the options in order to ease the first deployments (e.g.		higher than current deployments and may require a new architecture.
	restrict the number of options to implement and/or scales for		Multiple options are possible and it makes sense for the industry
	vendors, reduce interoperability and debugging issues for SP).		(both vendors and SP) to restrict the options in order to ease the
			first deployments (e.g. restrict the number of options to implement
			and/or scales for vendors, reduce interoperability and debugging
			issues for SP).
	Many aggregation networks are already deploying MPLS but are limited		Many aggregation networks are already deploying MPLS but are limited
	to the use of MPLS per aggregation area. Those MPLS based		to the use of MPLS per aggregation area. Those MPLS based
	aggregation domains are connected to a core network running MPLS as		aggregation domains are connected to a core network running MPLS as
	well. Nevertheless most of the services are not limited to an		well. Nevertheless most of the services are not limited to an
	aggregation domain but running between several aggregation domains		aggregation domain but running between several aggregation domains
	crossing the core network. In the past it was necessary to provide		crossing the core network. In the past it was necessary to provide
	connectivity between the different domains and the core on a per		connectivity between the different domains and the core on a per
	service level and not based on MPLS (e.g. by deploying native IP-		service level and not based on MPLS (e.g. by deploying native IP-
	Routing or Ethernet based technologies between aggregation and core).		Routing or Ethernet based technologies between aggregation and core).
	skipping to change at page 6, line 46		skipping to change at page 7, line 5
	scaling and manageability, and do not affect the service layer, since		scaling and manageability, and do not affect the service layer, since
	the Transport Pseudowire that carries packets from the AN to the SN		the Transport Pseudowire that carries packets from the AN to the SN
	doesn't care whether it takes two hops or twenty, nor how many region		doesn't care whether it takes two hops or twenty, nor how many region
	boundaries it needs to cross. The network architecture is about		boundaries it needs to cross. The network architecture is about
	network scaling, network resilience and network manageability; the		network scaling, network resilience and network manageability; the
	service architecture is about optimal delivery: service scaling,		service architecture is about optimal delivery: service scaling,
	service resilience (via replicated SNs) and service manageability.		service resilience (via replicated SNs) and service manageability.
	The two are decoupled: each can be managed separately and changed		The two are decoupled: each can be managed separately and changed
	independently.		independently.
	+--------------+ +--------------+ +--------------+		+--------------+ +--------------+ +--------------+
	| Aggregation | | Core | | Aggregation |		| Aggregation | | Core | | Aggregation |
	| Domain #1 +---------+ Domain +---------+ Domain #2 |		| Domain #1 +---------+ Domain +---------+ Domain #2 |
	| MPLS | ^ | MPLS | ^ | MPLS |		| MPLS | ^ | MPLS | ^ | MPLS |
	+--------------+ | +--------------+ | +--------------+		+--------------+ | +--------------+ | +--------------+
	| |		| |
	+------ service specific ------+		+------ service specific ------+
	configuration		configuration
	Figure 1: Service Specific Configurations		Figure 1: Service Specific Configurations
	One of the main motivations of Seamless MPLS is to get rid of		One of the main motivations of Seamless MPLS is to get rid of service
	services specific configurations between the different MPLS islands.		specific configurations between the different MPLS islands. Seamless
	Seamless MPLS connects all MPLS domains on the MPLS transport layer		MPLS connects all MPLS domains on the MPLS transport layer providing
	providing a single transport layer for all services - independent of		a single transport layer for all services - independent of the
	the service itself. The Seamless MPLS architecture therefore		service itself. The Seamless MPLS architecture therefore decuples
	decuples the service and transport layer and integrates access,		the service and transport layer and integrates access, aggregation
	aggregation and core into a single platform. One of the big		and core into a single platform. One of the big advantages is that
	advantages is that problems on the transport layer only need to be		problems on the transport layer only need to be solved once (and the
	solved once (and the solutions are available to all services). With		solutions are available to all services). With Seamless MPLS it is
	Seamless MPLS it is not necessary to use service specific		not necessary to use service specific configurations on intermediate
	configurations on intermediate nodes; all services can be deployed in		nodes; all services can be deployed in an end to end manner.
	an end to end manner.
	2.2. Use Case #1		2.2. Use Case #1
	2.2.1. Description		2.2.1. Description
	In most cases at least residential and business services need to be		In most cases at least residential and business services need to be
	supported by a network. This section describes a Seamless MPLS use		supported by a network. This section describes a Seamless MPLS use
	case which supports such a scenario. The use case includes point to		case which supports such a scenario. The use case includes point to
	point services for business customers as well as typical service		point services for business customers as well as typical service
	creation for residential customers.		creation for residential customers.
	+-------------+		+-------------+
	| Service |		| Service |
	| Creation |		| Creation |
	| Residential |		| Residential |
	| Customers |		| Customers |
	+------+------+		+------+------+
	|		|
	|		|
	|		|
	PW1 +-------+ +---+---+		PW1 +-------+ +---+---+
	######################### |		######################### |
	# +--+ AGN11 +---+ AGN21 + +------+		# +--+ AGN11 +---+ AGN21 + +------+
	# / | | /| |\ | | +--------+		# / | | /| |\ | | +--------+
	+--#-+/ +-------+\/ +-------+ \| | | remote |		+--#-+/ +-------+\/ +-------+ \| | | remote |
	| AN | /\ + CORE +---......--+ AN |		| AN | /\ + CORE +---......--+ AN |
	+--#-+\ +-------+ \+-------+ /| | ####### |		+--#-+\ +-------+ \+-------+ /| | ####### |
	# \ | | | |/################### +--------+		# \ | | | |/################### +--------+
	# +--+ AGN12 +---+ AGN22 +##+------+ P2P Business Service		# +--+ AGN12 +---+ AGN22 +##+------+ P2P Business Service
	##############################		##############################
	PW2 +-------+ +-------+		PW2 +-------+ +-------+
	Figure 2: Use Case #1: Service Creation		Figure 2: Use Case #1: Service Creation
	Figure 2 shows the different service creation points and the		Figure 2 shows the different service creation points and the
	corresponding pseudowires between the access nodes and the service		corresponding pseudowires between the access nodes and the service
	creation points. The use case does not show all PWs (e.g. not the		creation points. The use case does not show all PWs (e.g. not the
	PWs needed to support redundancy) in order to keep the figure simple.		PWs needed to support redundancy) in order to keep the figure simple.
	Node and link failures are handled by rerouting the PWs (based on		Node and link failures are handled by rerouting the PWs (based on
	standard mechanisms). End customers (either residential or business		standard mechanisms). End customers (either residential or business
	customers) are connected to the access nodes using a native		customers) are connected to the access nodes using a native
	technology like Ethernet. The access nodes terminates the PW(s)		technology like Ethernet. The access nodes terminates the PW(s)
	skipping to change at page 8, line 38		skipping to change at page 9, line 11
	Business Sercvices: For business services the use cases shows point		Business Sercvices: For business services the use cases shows point
	to point connections between two access nodes. PW2 originates at		to point connections between two access nodes. PW2 originates at
	the AN and terminates on the remote AN crossing two aggregation		the AN and terminates on the remote AN crossing two aggregation
	areas and the core network. If the access node needs connections		areas and the core network. If the access node needs connections
	to several remote ANs the corresponding number of PWs will be		to several remote ANs the corresponding number of PWs will be
	originated at the AN. Nevertheless taking the number of ports		originated at the AN. Nevertheless taking the number of ports
	available and the number of business customers on a typical access		available and the number of business customers on a typical access
	node the number of PWs will be relatively small.		node the number of PWs will be relatively small.
	+-------+ +-------+ +------+ +------+		+-------+ +-------+ +------+ +------+
	| | | | | | | |		| | | | | | | |
	+--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN		+--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN
	/ | | /| | | | | |		/ | | /| | | | | |
	+----+/ +-------+\/ +-------+ +------+ /+------+		+----+/ +-------+\/ +-------+ +------+ /+------+
	| AN | /\ \/		| AN | /\ \/
	+----+\ +-------+ \+-------+ +------+/\ +------+		+----+\ +-------+ \+-------+ +------+/\ +------+
	\ | | | | | | \| |		\ | | | | | | \| |
	+--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN		+--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN
	| | | | | | | |		| | | | | | | |
	+-------+ +-------+ +------+ +------+		+-------+ +-------+ +------+ +------+
	static route ISIS L1 LDP ISIS L2 LDP		static route ISIS L1 LDP ISIS L2 LDP
	<-Access-><--Aggregation Domain--><---------Core--------->
			<-Access-><--Aggregation Domain--><---------Core--------->
	Figure 3: Use Case #1: Redundancy		Figure 3: Use Case #1: Redundancy
	Figure 3 shows the redundancy at the access and aggregation network		Figure 3 shows the redundancy at the access and aggregation network
	deploying a two stage aggregation network (AGN1x/AGN2x).		deploying a two stage aggregation network (AGN1x/AGN2x).
	Nevertheless redundancy is not a must in this use case. It is also		Nevertheless redundancy is not a must in this use case. It is also
	possible to use non redundant connection between the ANs and AGN1		possible to use non redundant connection between the ANs and AGN1
	stage and/or between the AGN1 and AGN2 stages. The AGN2x stage is		stage and/or between the AGN1 and AGN2 stages. The AGN2x stage is
	used to aggregate traffic from several AGN1x pairs. In this use case		used to aggregate traffic from several AGN1x pairs. In this use case
	an aggregation domain is not limited to the use of a single pair of		an aggregation domain is not limited to the use of a single pair of
	skipping to change at page 10, line 19		skipping to change at page 11, line 5
	Table 1: Use Case #1: Typical Numbers for Access Node		Table 1: Use Case #1: Typical Numbers for Access Node
	2.3. Use Case #2		2.3. Use Case #2
	2.3.1. Description		2.3.1. Description
	In most cases, residential, wholesales and business services need to		In most cases, residential, wholesales and business services need to
	be supported by the network.		be supported by the network.
	+-------------+		+-------------+
	| Service |		| Service |
	| platforms |		| platforms |
	|(VoIP, VoD..)|		|(VoIP, VoD..)|
	| Residential |		| Residential |
	| Customers |		| Customers |
	+------+------+		+------+------+
	|		|
	|		|
	+---+ +-----+ +--+--+ +-----+		+---+ +-----+ +--+--+ +-----+
	|AN1|----+AGN11+--+AGN21+---+ ABR |		|AN1|----+AGN11+--+AGN21+---+ ABR |
	+---+ +--+--+ +--+--+ +--+--+		+---+ +--+--+ +--+--+ +--+--+
	| | |		| | |
	+---+ +--+--+ | | +----+		+---+ +--+--+ | | +----+
	|AN2|----+AGN12+ | | --+ PE |		|AN2|----+AGN12+ | | --+ PE |
	+---+ +--+--+ | | +----+		+---+ +--+--+ | | +----+
	| | |		| | |
	. | |		. | |
	. | |		. | |
	. | |		. | |
	| | |		| | |
	+---+ +---+ +--+--+ +--+--+ +--+--+		+---+ +---+ +--+--+ +--+--+ +--+--+
	|AN4+---+AN3|----+AGN1x+--+AGN22+---+ ABR |		|AN4+---+AN3|----+AGN1x+--+AGN22+---+ ABR |
	+---+ +---+ +-----+ +-----+ +-----+		+---+ +---+ +-----+ +-----+ +-----+
	<-Access-><--Aggregation Domain--><---------Core--------->		<-Access-><--Aggregation Domain--><---------Core--------->
	Figure 4: Use Case #2		Figure 4: Use Case #2
	The above topology (see Figure 4) is subject to evolutions, depending		The above topology (see Figure 4) is subject to evolutions, depending
	on AN types and capacities (in terms of number of customers and/or		on AN types and capacities (in terms of number of customers and/or
	aggregated bandwidth). For examples, AGN1x connection toward AGN2y		aggregated bandwidth). For examples, AGN1x connection toward AGN2y
	currently forms a ring but may latter evolve in a square or triangle		currently forms a ring but may latter evolve in a square or triangle
	topology; AGN2y nodes may not be present...		topology; AGN2y nodes may not be present...
	Most access nodes (AN) are single attached on one aggregation node		Most access nodes (AN) are single attached on one aggregation node
	skipping to change at page 17, line 20		skipping to change at page 18, line 5
	well as the details of the interworking of these protocols to achieve		well as the details of the interworking of these protocols to achieve
	the overall scalable hierarchical architecture.		the overall scalable hierarchical architecture.
	5.1.2. General Network Topology		5.1.2. General Network Topology
	There are multiple aggregation domains (in the order of up to 100)		There are multiple aggregation domains (in the order of up to 100)
	connected to the core in a star topology, i.e. aggregation domains		connected to the core in a star topology, i.e. aggregation domains
	are never connected among themselves, but only to the core. The core		are never connected among themselves, but only to the core. The core
	has its own domain.		has its own domain.
	+-------+ +-------+ +------+ +------+		+-------+ +-------+ +------+ +------+
	| | | | | | | |		| | | | | | | |
	+--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN		+--+ AGN11 +---+ AGN21 +---+ ABR1 +---+ LSR1 +--> to AGN
	/ | | /| | | | | |		/ | | /| | | | | |
	+----+/ +-------+\/ +-------+ +------+ /+------+		+----+/ +-------+\/ +-------+ +------+ /+------+
	| AN | /\ \/ |		| AN | /\ \/ |
	+----+\ +-------+ \+-------+ +------+/\ +------+		+----+\ +-------+ \+-------+ +------+/\ +------+
	\ | | | | | | \| |		\ | | | | | | \| |
	+--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN		+--+ AGN12 +---+ AGN22 +---+ ABR2 +---+ LSR2 +--> to AGN
	| | | | | | | |		| | | | | | | |
	+-------+ +-------+ +------+ +------+		+-------+ +-------+ +------+ +------+
	static route ISIS L1 LDP ISIS L2 LDP		static route ISIS L1 LDP ISIS L2 LDP
	<-Access-><--Aggregation Domain--><---------Core--------->		<-Access-><--Aggregation Domain--><---------Core--------->
	Figure 5: Deployment Scenario #1		Figure 5: Deployment Scenario #1
	As shown in Figure 5, the access nodes (AN) are connected to the		As shown in Figure 5, the access nodes (AN) are connected to the
	aggregation network via aggregation nodes called AGN1x, either to a		aggregation network via aggregation nodes called AGN1x, either to a
	single AGN1x or redundantly to two AGN1x. Each AGN1x has redundant		single AGN1x or redundantly to two AGN1x. Each AGN1x has redundant
	uplinks to a pair of second-level aggregation nodes called AGN2x.		uplinks to a pair of second-level aggregation nodes called AGN2x.
	Each aggregation domain is connected to the core via exactly two		Each aggregation domain is connected to the core via exactly two
	border routers (ABR) on the core side. There can be multiple AGN2		border routers (ABR) on the core side. There can be multiple AGN2
	skipping to change at page 23, line 17		skipping to change at page 24, line 6
	is encoded as a hierarchy of FIB entry B pointing to a FIB entry I		is encoded as a hierarchy of FIB entry B pointing to a FIB entry I
	pointing to a FIB entry 0.		pointing to a FIB entry 0.
	BGP Prefix Independent Convergence [BGP-PIC] extends the hierarchical		BGP Prefix Independent Convergence [BGP-PIC] extends the hierarchical
	dataplane with the concept of a BGP Path-List. A BGP path-list may		dataplane with the concept of a BGP Path-List. A BGP path-list may
	be abstracted as a set of primary multipath nhops and a backup nhop.		be abstracted as a set of primary multipath nhops and a backup nhop.
	When the primary set is empty, packets destined to the BGP		When the primary set is empty, packets destined to the BGP
	destinations are rerouted via the backup nhop.		destinations are rerouted via the backup nhop.
	For complete description of BGP-PIC technology and its applicability		For complete description of BGP-PIC technology and its applicability
	please refer to [BGP-PIC].		please refer to [BGP-PIC] and [ABR-FRR].
	Hierarchical data plane and BGP-PIC are very simple technologies to		Hierarchical data plane and BGP-PIC are very simple technologies to
	operate. Their applicability to any topology, any routing policy and		operate. Their applicability to any topology, any routing policy and
	any BGP unicast address family allows router vendors to enable this		any BGP unicast address family allows router vendors to enable this
	behavior by default.		behavior by default.
	5.1.8.4. BGP Egress Node FRR		5.1.8.4. BGP Egress Node FRR
	BGP egress node FRR is a Fast ReRoute solution and hence relies on		BGP egress node FRR is a Fast ReRoute solution and hence relies on
	local protection and the precomputation and preinstallation of the		local protection and the precomputation and preinstallation of the
	skipping to change at page 28, line 38		skipping to change at page 29, line 18
	More specifically, [RFC6571] plays a key role in the Seamless MPLS		More specifically, [RFC6571] plays a key role in the Seamless MPLS
	architecture as it describes simple design guidelines which		architecture as it describes simple design guidelines which
	determiniscally ensure LFA coverage for any link and node in the		determiniscally ensure LFA coverage for any link and node in the
	aggregation regions of the network. This is key as it provides for a		aggregation regions of the network. This is key as it provides for a
	simple <50msec protection for the vast majority of the node and link		simple <50msec protection for the vast majority of the node and link
	failures (>90% of the IGP/BGP3107 footprint at least).		failures (>90% of the IGP/BGP3107 footprint at least).
	If the guidelines cannot be met, then either the designer will rely		If the guidelines cannot be met, then either the designer will rely
	on (1) augmenting native LFA coverage with remote LFA		on (1) augmenting native LFA coverage with remote LFA
	[I-D.draft-ietf-rtgwg-remote-lfa], or (2) augmenting native LFA		[I-D.ietf-rtgwg-remote-lfa], or (2) augmenting native LFA coverage
	coverage with RSVP, or (3) a full-mesh TE FRR model, or (4) IGP		with RSVP, or (3) a full-mesh TE FRR model, or (4) IGP convergence.
	convergence. The first option provides an automatic and fairly		The first option provides an automatic and fairly simple sub-50msec
	simple sub-50msec protection as LFA without introducing any		protection as LFA without introducing any additional protocols. The
	additional protocols. The second option provides the same sub-50msec		second option provides the same sub-50msec protection as LFA, but
	protection as LFA, but introduces additional RSVP LSPs. The thrid		introduces additional RSVP LSPs. The thrid option optimizes for sub-
	option optimizes for sub-50msec protection, but implies a more		50msec protection, but implies a more complex operational model. The
	complex operational model. The fourth option optimizes for simple		fourth option optimizes for simple operation but only provides <1 sec
	operation but only provides <1 sec protection. Up to each designer		protection. Up to each designer to arbitrate between these three
	to arbitrate between these three options versus the possibility to		options versus the possibility to engineer the topology for native
	engineer the topology for native LFA protection.		LFA protection.
	A similar choice involves protection against ABR node failure and		A similar choice involves protection against ABR node failure and
	L3VPN PE node failure. The designer can either use BGP PIC or BGP		L3VPN PE node failure. The designer can either use BGP PIC or BGP
	egress node FRR. Up to each designer to asssess the trade-off		egress node FRR. Up to each designer to asssess the trade-off
	between the valuation of sub-50msec instead of sub-1sec versus		between the valuation of sub-50msec instead of sub-1sec versus
	additional operational considerations related to BGP egress node FRR.		additional operational considerations related to BGP egress node FRR.
	5.1.8.7. Conclusion		5.1.8.7. Conclusion
	The Seamless MPLS architecture illustrated in deployment case study 1		The Seamless MPLS architecture illustrated in deployment case study 1
	skipping to change at page 36, line 13		skipping to change at page 36, line 40
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	9.2. Informative References		9.2. Informative References
	[ABR-FRR] Rekhter, Y., "Local Protection for LSP tail-end node		[ABR-FRR] Rekhter, Y., "Local Protection for LSP tail-end node
	failure, MPLS World Congress 2009", .		failure, MPLS World Congress 2009", .
	[ACM01] , , , , "Archieving sub-second IGP convergence in large IP		[ACM01] , , , and , "Archieving sub-second IGP convergence in
	networks, ACM SIGCOMM Computer Communication Review, v.35		large IP networks, ACM SIGCOMM Computer Communication
	n.3", July 2005.		Review, v.35 n.3", July 2005.
	[BGP-PIC] , "BGP PIC, Technical Report", November 2007.		[BGP-PIC] "BGP PIC, Technical Report", November 2007.
	[I-D.bashandy-bgp-edge-node-frr]		[I-D.bashandy-bgp-edge-node-frr]
	Bashandy, A., Pithawala, B., and K. Patel, "Scalable BGP		Bashandy, A., Pithawala, B., and K. Patel, "Scalable BGP
	FRR Protection against Edge Node Failure", draft-bashandy-		FRR Protection against Edge Node Failure", draft-bashandy-
	bgp-edge-node-frr-03 (work in progress), July 2012.		bgp-edge-node-frr-03 (work in progress), July 2012.
	[I-D.bashandy-bgp-frr-mirror-table]		[I-D.bashandy-bgp-frr-mirror-table]
	Bashandy, A., Konstantynowicz, M., and N. Kumar, "BGP FRR		Bashandy, A., Konstantynowicz, M., and N. Kumar, "BGP FRR
	Protection against Edge Node Failure Using Table Mirroring		Protection against Edge Node Failure Using Table Mirroring
	with Context Labels", draft-bashandy-bgp-frr-mirror-		with Context Labels", draft-bashandy-bgp-frr-mirror-
	skipping to change at page 36, line 51		skipping to change at page 37, line 32
	[I-D.bashandy-isis-bgp-edge-node-frr]		[I-D.bashandy-isis-bgp-edge-node-frr]
	Bashandy, A., "IS-IS Extension for BGP FRR Protection		Bashandy, A., "IS-IS Extension for BGP FRR Protection
	against Edge Node Failure", draft-bashandy-isis-bgp-edge-		against Edge Node Failure", draft-bashandy-isis-bgp-edge-
	node-frr-01 (work in progress), September 2012.		node-frr-01 (work in progress), September 2012.
	[I-D.bashandy-mpls-ldp-bgp-frr]		[I-D.bashandy-mpls-ldp-bgp-frr]
	Bashandy, A. and K. Raza, "LDP Extension for FRR Edge Node		Bashandy, A. and K. Raza, "LDP Extension for FRR Edge Node
	Protection in BGP-Free LDP Core", draft-bashandy-mpls-ldp-		Protection in BGP-Free LDP Core", draft-bashandy-mpls-ldp-
	bgp-frr-00 (work in progress), March 2012.		bgp-frr-00 (work in progress), March 2012.
	[I-D.draft-ietf-rtgwg-remote-lfa]
	, .
	[I-D.ietf-karp-routing-tcp-analysis]		[I-D.ietf-karp-routing-tcp-analysis]
	, .		.
	[I-D.ietf-mpls-ldp-dod]		[I-D.ietf-mpls-ldp-dod]
	Beckhaus, T., Decraene, B., Tiruveedhula, K.,		Beckhaus, T., Decraene, B., Tiruveedhula, K.,
	Konstantynowicz, M., and L. Martini, "LDP Downstream-on-		Konstantynowicz, M., and L. Martini, "LDP Downstream-on-
	Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-09 (work		Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-09 (work
	in progress), July 2013.		in progress), July 2013.
			[I-D.ietf-rtgwg-bgp-pic]
			.
			[I-D.ietf-rtgwg-remote-lfa]
			.
	[I-D.minto-2547-egress-node-fast-protection]		[I-D.minto-2547-egress-node-fast-protection]
	Jeganathan, J. and H. Gredler, "2547 egress PE Fast		Jeganathan, J., Gredler, H., and B. Decraene, "2547 egress
	Failure Protection", draft-minto-2547-egress-node-fast-		PE Fast Failure Protection", draft-minto-2547-egress-node-
	protection-01 (work in progress), October 2012.		fast-protection-02 (work in progress), July 2013.
	[PE-FRR] Le Roux, J., Decraene, B., and Z. Ahmad, "Fast Reroute in		[PE-FRR] Le Roux, J., Decraene, B., and Z. Ahmad, "Fast Reroute in
	MPLS L3VPN Networks - Towards CE-to-CE Protection, MPLS		MPLS L3VPN Networks - Towards CE-to-CE Protection, MPLS
	2006 Conference", .		2006 Conference", .
	[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in		[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
	BGP-4", RFC 3107, May 2001.		BGP-4", RFC 3107, May 2001.
	[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.
	skipping to change at page 37, line 43		skipping to change at page 38, line 29
	for Inter-Area Label Switched Paths (LSPs)", RFC 5283,		for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
	July 2008.		July 2008.
	[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast		[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast
	Reroute: Loop-Free Alternates", RFC 5286, September 2008.		Reroute: Loop-Free Alternates", RFC 5286, September 2008.
	[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection		[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
	(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June		(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June
	2010.		2010.
	[RFC5920] , .		[RFC5920] .
	[RFC6571] , .		[RFC6571] .
			[RFC7032] .
	Authors' Addresses		Authors' Addresses
	Nicolai Leymann (editor)		Nicolai Leymann (editor)
	Deutsche Telekom AG		Deutsche Telekom AG
	Winterfeldtstrasse 21		Winterfeldtstrasse 21
	Berlin 10781		Berlin 10781
	DE		DE
	Phone: +49 30 8353-92761		Phone: +49 30 8353-92761
	Email: n.leymann@telekom.de		Email: n.leymann@telekom.de
	Bruno Decraene		Bruno Decraene
	Orange		Orange
	38-40 rue du General Leclerc		38-40 rue du General Leclerc
	Issy Moulineaux cedex 9 92794		Issy Moulineaux cedex 9 92794
	FR		FR
	Email: bruno.decraene@orange.com		Email: bruno.decraene@orange.com
	Clarence Filsfils		Clarence Filsfils
	Cisco Systems		Cisco Systems
End of changes. 42 change blocks.
	164 lines changed or deleted		173 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/