draft-ietf-mpls-seamless-mpls-02.txt		draft-ietf-mpls-seamless-mpls-03.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: April 25, 2013 France Telecom		Expires: November 14, 2013 France Telecom
	C. Filsfils		C. Filsfils
	M. Konstantynowicz		M. Konstantynowicz, Ed.
	Cisco Systems		Cisco Systems
	D. Steinberg		D. Steinberg
	Steinberg Consulting		Steinberg Consulting
	October 22, 2012		May 13, 2013
	Seamless MPLS Architecture		Seamless MPLS Architecture
	draft-ietf-mpls-seamless-mpls-02		draft-ietf-mpls-seamless-mpls-03
	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
	independent transport. Therefore it removes the need for service		independent transport. Therefore it removes the need for service
	specific configurations in network transport nodes (without end to		specific configurations in network transport nodes (without end to
	end transport MPLS, some additional services nodes/configurations		end transport MPLS, some additional services nodes/configurations
	would be required to glue each transport domain). This draft defines		would be required to glue each transport domain). This draft defines
	a routing architecture using existing standardized protocols. It		a routing architecture using existing standardized protocols. It
	does not invent any new protocols or defines extensions to existing		does not invent any new protocols or defines extensions to existing
	protocols.		protocols.
	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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 April 25, 2013.		This Internet-Draft will expire on November 14, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		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 . . . . . . . . . . . . . . . . . . . 10		2.2.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 9
	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 . . . . . . . . . . . . . . . . . . . 12		2.3.2. Typical Numbers . . . . . . . . . . . . . . . . . . . 11
	3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 12		3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 13		3.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . . 13		3.1.1. Access . . . . . . . . . . . . . . . . . . . . . . . 12
	3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 13		3.1.2. Aggregation . . . . . . . . . . . . . . . . . . . . . 13
	3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . . 14		3.1.3. Core . . . . . . . . . . . . . . . . . . . . . . . . 13
	3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 14		3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 13
	3.3. Availability . . . . . . . . . . . . . . . . . . . . . . . 14		3.3. Availability . . . . . . . . . . . . . . . . . . . . . . 14
	3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 15		3.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . 14
	3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 15		3.5. Stability . . . . . . . . . . . . . . . . . . . . . . . . 14
	4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 15		4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 15
	4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15		4.1. Overall . . . . . . . . . . . . . . . . . . . . . . . . . 15
	4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . . 15		4.2. Multi-Domain MPLS networks . . . . . . . . . . . . . . . 15
	4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 16		4.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 15
	4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . . 16		4.4. Intra-Domain Routing . . . . . . . . . . . . . . . . . . 15
	4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . . 16		4.5. Inter-Domain Routing . . . . . . . . . . . . . . . . . . 16
	4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . . 17		4.6. Access . . . . . . . . . . . . . . . . . . . . . . . . . 16
	5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 17		5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 17
	5.1. Deployment Scenario #1 . . . . . . . . . . . . . . . . . . 17		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 . . . . . . . . . . . . . . . . . . 19		5.1.4. Intra-Area Routing . . . . . . . . . . . . . . . . . 18
	5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . . 19		5.1.4.1. Core . . . . . . . . . . . . . . . . . . . . . . 18
	5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19		5.1.4.2. Aggregation . . . . . . . . . . . . . . . . . . . 19
	5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . . 19		5.1.5. Access . . . . . . . . . . . . . . . . . . . . . . . 19
	5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . . 20		5.1.5.1. LDP Downstream-on-Demand (DoD) . . . . . . . . . 20
	5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . . 21		5.1.6. Inter-Area Routing . . . . . . . . . . . . . . . . . 21
	5.1.7. Labled iBGP next-hop handling . . . . . . . . . . . . 22		5.1.7. Labled iBGP next-hop handling . . . . . . . . . . . . 22
	5.1.8. Network Availability . . . . . . . . . . . . . . . . . 23		5.1.8. Network Availability . . . . . . . . . . . . . . . . 22
	5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 23		5.1.8.1. IGP Convergence . . . . . . . . . . . . . . . . . 23
	5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . . 24		5.1.8.2. Per-Prefix LFA FRR . . . . . . . . . . . . . . . 23
	5.1.8.3. Hierarchical Dataplane and BGP Prefix		5.1.8.3. Hierarchical Dataplane and BGP Prefix Independent
	Independent Convergence . . . . . . . . . . . . . 24		Convergence . . . . . . . . . . . . . . . . . . . 24
	5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 25		5.1.8.4. BGP Egress Node FRR . . . . . . . . . . . . . . . 24
	5.1.8.5. Assessing loss of connectivity upon any failure . 25		5.1.8.5. Assessing loss of connectivity upon any failure . 25
	5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 29		5.1.8.6. Network Resiliency and Simplicity . . . . . . . . 29
	5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . . 30		5.1.8.7. Conclusion . . . . . . . . . . . . . . . . . . . 30
	5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 30		5.1.9. BGP Next-Hop Redundancy . . . . . . . . . . . . . . . 30
	5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . . 31		5.2. Scalability Analysis . . . . . . . . . . . . . . . . . . 31
	5.2.1. Control and Data Plane State for Deployment		5.2.1. Control and Data Plane State for Deployment Scenario
	Scenario #1 . . . . . . . . . . . . . . . . . . . . . 31		#1 . . . . . . . . . . . . . . . . . . . . . . . . . 31
	5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . . 31		5.2.1.1. Introduction . . . . . . . . . . . . . . . . . . 31
	5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 32		5.2.1.2. Core Domain . . . . . . . . . . . . . . . . . . . 31
	5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . . 33		5.2.1.3. Aggregation Domain . . . . . . . . . . . . . . . 33
	5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 34		5.2.1.4. Summary . . . . . . . . . . . . . . . . . . . . . 34
	5.2.1.5. Numerical application for use case #1 . . . . . . 35		5.2.1.5. Numerical application for use case #1 . . . . . . 34
	5.2.1.6. Numerical application for use case #2 . . . . . . 35		5.2.1.6. Numerical application for use case #2 . . . . . . 35
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 37		8. Security Considerations . . . . . . . . . . . . . . . . . . . 36
	8.1. Access Network Security . . . . . . . . . . . . . . . . . 37		8.1. Access Network Security . . . . . . . . . . . . . . . . . 37
	8.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 37		8.2. Data Plane Security . . . . . . . . . . . . . . . . . . . 37
	8.3. Control Plane Security . . . . . . . . . . . . . . . . . . 38		8.3. Control Plane Security . . . . . . . . . . . . . . . . . 38
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 39		9.1. Normative References . . . . . . . . . . . . . . . . . . 38
	9.2. Informative References . . . . . . . . . . . . . . . . . . 39		9.2. Informative References . . . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
	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.
	Seamless MPLS extends the core domain and integrates aggregation and		Seamless MPLS extends the core domain and integrates aggregation and
	access domains into a single MPLS domain ("Seamless MPLS"). This		access domains into a single MPLS domain ("Seamless MPLS"). This
	enables a very flexible deployment of an end to end service delivery.		enables a very flexible deployment of an end to end service delivery.
	In order to obtain a highly scalable architecture Seamless MPLS takes		In order to obtain a highly scalable architecture Seamless MPLS takes
	into account that typical access devices (DSLAMs, MSAN) are lacking		into account that typical access devices (DSLAMs, MSAN) are lacking
	some advanced MPLS features, and may have more scalability		some advanced MPLS features, and may have more scalability
	limitations. Hence access devices are kept as simple as possible.		limitations. Hence access devices are kept as simple as possible.
	skipping to change at page 5, line 39		skipping to change at page 5, line 32
	o Use Case: Describes a typical network including service creation		o Use Case: Describes a typical network including service creation
	points in order to describe the requirments, typical numbers etc.		points in order to describe the requirments, typical numbers etc.
	which need to be taken into account when applying the Seamless		which need to be taken into account when applying the Seamless
	MPLS architecture.		MPLS architecture.
	2. Motivation		2. Motivation
	MPLS is deployed in core and aggregation network for several years		MPLS is deployed in core and aggregation network for several years
	and provides a mature and stable basis for large networks. In		and provides a mature and stable basis for large networks. In
	addition MPLS is already used in access networks, e.g. such as mobile		addition MPLS is already used in access networks, e.g. such as
	or DSL backhaul. Today MPLS as technology is being used on two		mobile or DSL backhaul. Today MPLS as technology is being used on
	different layers:		two different layers:
	o the Transport Layer and		o the Transport Layer and
	o the Service Layer (e.g. for MPLS VPNs)		o the Service Layer (e.g. for MPLS VPNs)
	In both cases the protocols and the encapsulation are identical but		In both cases the protocols and the encapsulation are identical but
	the use of MPLS is different especially concerning the signalling,		the use of MPLS is different especially concerning the signalling,
	the control plane, the provisioning, the scalability and the		the control plane, the provisioning, the scalability and the
	frequency of updates. On the service layer only service specific		frequency of updates. On the service layer only service specific
	information is exchanged; every service can potentially deploy it's		information is exchanged; every service can potentially deploy it's
	own architecture and individual protocols. The services are running		own architecture and individual protocols. The services are running
	on top of the transport layer. Nevertheless those deployments are		on top of the transport layer. Nevertheless those deployments are
	usually isolated, focussed on a single use case and not integrated		usually isolated, focussed on a single use case and not integrated
	into an end-to-end manner.		into an end-to-end manner.
	skipping to change at page 6, line 40		skipping to change at page 6, line 32
	restrict the number of options to implement and/or scales for		restrict the number of options to implement and/or scales for
	vendors, reduce interoperability and debugging issues for SP).		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).
	In most cases service specific configurations on the border nodes		In most cases service specific configurations on the border nodes
	between core and aggregation were required. New services led to		between core and aggregation were required. New services led to
	additional configurations and changes in the provisioning tools (see		additional configurations and changes in the provisioning tools (see
	Figure 1).		Figure 1).
	With Seamless MPLS there are no technology boundaries and no topology		With Seamless MPLS there are no technology boundaries and no topology
	boundaries for the services. Network (or region) boundaries are for		boundaries for the services. Network (or region) boundaries are for
	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
	services specific configurations between the different MPLS islands.		services specific configurations between the different MPLS islands.
	Seamless MPLS connects all MPLS domains on the MPLS transport layer		Seamless MPLS connects all MPLS domains on the MPLS transport layer
	providing a single transport layer for all services - independent of		providing a single transport layer for all services - independent of
	the service itself. The Seamless MPLS architecture therefore		the service itself. The Seamless MPLS architecture therefore
	decuples the service and transport layer and integrates access,		decuples the service and transport layer and integrates access,
	aggregation and core into a single platform. One of the big		aggregation and core into a single platform. One of the big
	skipping to change at page 8, line 5		skipping to change at page 7, line 39
	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)
	carrying the traffic for the end customers. The link between the		carrying the traffic for the end customers. The link between the
	access node (AN) and the aggregation node (AGN) is the first MPLS		access node (AN) and the aggregation node (AGN) is the first MPLS
	enabled link.		enabled link.
	Residential Services: The service creation for all residential		Residential Services: The service creation for all residential
	customers connected to the Access Nodes in an aggregation domain		customers connected to the Access Nodes in an aggregation domain
	is located on an Service Node connected to the AGN2x. The PW		is located on an Service Node connected to the AGN2x. The PW
	(PW1) originated at the AN and terminates at the AGN2. A second		(PW1) originated at the AN and terminates at the AGN2. A second
	PW is deployed in the case where redundancy is needed on the AN		PW is deployed in the case where redundancy is needed on the AN
	(the figure shows redundancy but this might not be the case for		(the figure shows redundancy but this might not be the case for
	all ANs in this Use Case). Additonal PWs can be deployed as well		all ANs in this Use Case). Additonal PWs can be deployed as well
	in case more than a single service creation is needed for the		in case more than a single service creation is needed for the
	residential service (e.g. one service creation point for Internet		residential service (e.g. one service creation point for Internet
	access and a second service creation point for IPTV services).		access and a second service creation point for IPTV services).
	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 12, line 24		skipping to change at page 11, line 47
	o Number of Backbone Nodes: 150		o Number of Backbone Nodes: 150
	o Number of Aggregation Nodes: 1.500		o Number of Aggregation Nodes: 1.500
	o Number of Access Nodes: 40.000		o Number of Access Nodes: 40.000
	2.3.2. Typical Numbers		2.3.2. Typical Numbers
	Table 2 shows typical numbers which are expected for Use Case #2 for		Table 2 shows typical numbers which are expected for Use Case #2 for
	the purpose of establishing the transport LSPs. They do not take		the purpose of establishing the transport LSPs. They do not take
	into account the services built in addition. (e.g. 6PE will require		into account the services built in addition. (e.g. 6PE will require
	additional IPv6 routes).		additional IPv6 routes).
	+-------------------+---------------+		+-------------------+---------------+
	| Parameter | Typical Value |		| Parameter | Typical Value |
	+-------------------+---------------+		+-------------------+---------------+
	| IGP Control Plane | 2 |		| IGP Control Plane | 2 |
	| IP FIB | 2 |		| IP FIB | 2 |
	| LDP Control Plane | 1000 |		| LDP Control Plane | 1000 |
	| LDP FIB | 1000 |		| LDP FIB | 1000 |
	+-------------------+---------------+		+-------------------+---------------+
	skipping to change at page 13, line 14		skipping to change at page 12, line 34
	o Scalability: The network SHALL be scalable to the minimum of		o Scalability: The network SHALL be scalable to the minimum of
	100.000 nodes.		100.000 nodes.
	o Fast convergence (sub second resilience) SHALL be supported. Fast		o Fast convergence (sub second resilience) SHALL be supported. Fast
	reroute (LFA) SHOULD be supported.		reroute (LFA) SHOULD be supported.
	o Flexibility: The Seamless MPLS architecture SHALL be applied to a		o Flexibility: The Seamless MPLS architecture SHALL be applied to a
	wide variety of existing MPLS deployments. It SHALL use a		wide variety of existing MPLS deployments. It SHALL use a
	flexible approach deploying building blocks with the possiblity to		flexible approach deploying building blocks with the possiblity to
	use certain features only if those features are needed (e.g. dual		use certain features only if those features are needed (e.g. dual
	homing ANs or fast reroute mechanisms).		homing ANs or fast reroute mechanisms).
	o Service independence: Service and transport layer SHALL be		o Service independence: Service and transport layer SHALL be
	decoupled. The architecture SHALL remove the need for service		decoupled. The architecture SHALL remove the need for service
	specific configurations on intermediate nodes.		specific configurations on intermediate nodes.
	o Native Multicast support: P2MP MPLS LSPs SHOULD be supported by		o Native Multicast support: P2MP MPLS LSPs SHOULD be supported by
	the Seamless MPLS architecture.		the Seamless MPLS architecture.
	o Interoperable end to end OAM mechanisms SHALL be implemented		o Interoperable end to end OAM mechanisms SHALL be implemented
	skipping to change at page 17, line 15		skipping to change at page 16, line 38
	4.6. Access		4.6. Access
	Compared to the aggregation and core parts of the Seamless MPLS		Compared to the aggregation and core parts of the Seamless MPLS
	network the access part is special in two respects:		network the access part is special in two respects:
	o The number of ndes in the access is at least one order of		o The number of ndes in the access is at least one order of
	magnitude higher than in any other part of the network.		magnitude higher than in any other part of the network.
	o Because of the large quantity of access nodes, the cost of these		o Because of the large quantity of access nodes, the cost of these
	nodes is extremly relevant for the overall costs of the entire		nodes is extremly relevant for the overall costs of the entire
	network, i.e. acess nodes are very cost sensitive.		network, i.e. acess nodes are very cost sensitive.
	This makes it desirable to design the architecture such that the AN		This makes it desirable to design the architecture such that the AN
	functionality can be kept as simple as possible. This should always		functionality can be kept as simple as possible. This should always
	be kept in mind when evalulating different seamless MPLS		be kept in mind when evalulating different seamless MPLS
	architectures. The goal is to limit both the number of different		architectures. The goal is to limit both the number of different
	protocols needed on the AN as well as the scale to which each		protocols needed on the AN as well as the scale to which each
	protocol must perform to the absolute minimum.		protocol must perform to the absolute minimum.
	5. Deployment Scenarios		5. Deployment Scenarios
	skipping to change at page 17, line 45		skipping to change at page 17, line 26
	This deployment scenario describes one way to implement a seamless		This deployment scenario describes one way to implement a seamless
	MPLS architecture. Specific to this implementation is the choice of		MPLS architecture. Specific to this implementation is the choice of
	intra- and inter-domain routing and label distribution protocols, as		intra- and inter-domain routing and label distribution protocols, as
	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 21, line 29		skipping to change at page 21, line 13
	necessary on the AN.		necessary on the AN.
	o The following are the triggers for ANs to request a label:		o The following are the triggers for ANs to request a label:
	o		o
	* When a control session (targeted LDP) to a target has to be		* When a control session (targeted LDP) to a target has to be
	established		established
	* When a service label has been received by a control session		* When a service label has been received by a control session
	(e.g. pseudo wire label)		(e.g. pseudo wire label)
	5.1.6. Inter-Area Routing		5.1.6. Inter-Area Routing
	The inter-domain MPLS connectivity from the aggregation domains to		The inter-domain MPLS connectivity from the aggregation domains to
	and across the core domain is realized primarily using BGP with MPLS		and across the core domain is realized primarily using BGP with MPLS
	labels ("labled BGP/SAFI4" [RFC3107]). A very limited amount of		labels ("labled BGP/SAFI4" [RFC3107]). A very limited amount of
	route leaking from ISIS L2 into L1 is also used.		route leaking from ISIS L2 into L1 is also used.
	All ABR and PE nodes in the core are part of the labeled iBGP mesh,		All ABR and PE nodes in the core are part of the labeled iBGP mesh,
	which can be either full mesh or based on route reflectors. These		which can be either full mesh or based on route reflectors. These
	skipping to change at page 23, line 38		skipping to change at page 23, line 22
	delay and a linear FIB update [ACM01].		delay and a linear FIB update [ACM01].
	The initial delay could conservatively be assumed to be 260msec:		The initial delay could conservatively be assumed to be 260msec:
	50msec to detect failures with BFD (most failures would be detected		50msec to detect failures with BFD (most failures would be detected
	faster with loss of light for example or with faster BFD timers),		faster with loss of light for example or with faster BFD timers),
	50msec to throttle the LSP generation, 150msec to throttle the SPF		50msec to throttle the LSP generation, 150msec to throttle the SPF
	computation (making sure than all the required LSP's are received		computation (making sure than all the required LSP's are received
	even in case of SRLG failures) and 10msec for shortest-path-first		even in case of SRLG failures) and 10msec for shortest-path-first
	tree computation.		tree computation.
	Assuming 250usec per update (conservative), this allows for (1000-		Assuming 250usec per update (conservative), this allows for
	260)/0.250= 2960 prefixes update within a second following the		(1000-260)/0.250= 2960 prefixes update within a second following the
	outage. More precisely, this allows for 2960 important IGP prefixes		outage. More precisely, this allows for 2960 important IGP prefixes
	updates. Important prefixes are automatically classified by the		updates. Important prefixes are automatically classified by the
	router implementation through simple heuristic (/32 is more important		router implementation through simple heuristic (/32 is more important
	than non-/32).		than non-/32).
	The number of IGP important routes (loopbacks) in deployment case		The number of IGP important routes (loopbacks) in deployment case
	study 1 is much smaller than 2960, and hence sub-second IGP		study 1 is much smaller than 2960, and hence sub-second IGP
	convergence is conservative.		convergence is conservative.
	IGP convergence is a simple technology for the operator provided that		IGP convergence is a simple technology for the operator provided that
	skipping to change at page 32, line 5		skipping to change at page 31, line 37
	Let's take the following assumptions:		Let's take the following assumptions:
	o Aggregation equipments are equally spread across aggregation		o Aggregation equipments are equally spread across aggregation
	routing domains		routing domains
	o the number of IGP links is three times the number of IGP nodes		o the number of IGP links is three times the number of IGP nodes
	o the number of IGP prefixes is five times the number of IGP nodes		o the number of IGP prefixes is five times the number of IGP nodes
	(links prefixes + 2 loopbacks)		(links prefixes + 2 loopbacks)
	o Access Nodes need to set up 1000 (1k) LSPs. 10% (100) are FEC		o Access Nodes need to set up 1000 (1k) LSPs. 10% (100) are FEC
	which are outside of their routing domain. Those 100 remote FEC		which are outside of their routing domain. Those 100 remote FEC
	are the same for all Access Nodes of a given AGN.		are the same for all Access Nodes of a given AGN.
	The following sections roughly evaluate the scalability, both in		The following sections roughly evaluate the scalability, both in
	absolute numbers and relatively with the number of Access Node which		absolute numbers and relatively with the number of Access Node which
	is the biggest scalability factor.		is the biggest scalability factor.
	5.2.1.2. Core Domain		5.2.1.2. Core Domain
	The IGP & LDP core domain are not affected by the number of access		The IGP & LDP core domain are not affected by the number of access
	skipping to change at page 33, line 33		skipping to change at page 33, line 17
	In the aggregation domain, IGP & LDP are not affected by the number		In the aggregation domain, IGP & LDP are not affected by the number
	of access nodes outside of their domain. They are not affected by		of access nodes outside of their domain. They are not affected by
	the total number of AN nodes:		the total number of AN nodes:
	IGP:		IGP:
	node : #AGN / #Area ~ o(1)		node : #AGN / #Area ~ o(1)
	links : 3*#AGN / #Area ~ o(1)		links : 3*#AGN / #Area ~ o(1)
	IP prefixes : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN		IP prefixes : #Core + #Area + (5*#AGN + #AN) / #Area ~ o(#AN *5
	*5/ #Area)		/ #Area)
	+ + 1 loopback per core node + one aggregate per area + 5		+ + 1 loopback per core node + one aggregate per area + 5
	prefixes per AGN in the area + 1 prefix per AN in the area.		prefixes per AGN in the area + 1 prefix per AN in the area.
	LDP FEC:		LDP FEC:
	Core + (#AGN + #AN) / #Area ~ o(#AN / #Area)		Core + (#AGN + #AN) / #Area ~ o(#AN / #Area)
	+ + 1 loopback per core node + 1 loopback per AGN & AN node in		+ + 1 loopback per core node + 1 loopback per AGN & AN node in
	the area.		the area.
	skipping to change at page 34, line 45		skipping to change at page 34, line 28
	In the aggregation areas, IGP and LDP are affected by the number of		In the aggregation areas, IGP and LDP are affected by the number of
	core nodes and the number of AGN and AN in their area. They are not		core nodes and the number of AGN and AN in their area. They are not
	affected by the total number of AGN or AN in the seamless MPLS		affected by the total number of AGN or AN in the seamless MPLS
	domain.		domain.
	No FIB of any node is required to handle the total number of AGN or		No FIB of any node is required to handle the total number of AGN or
	AN in the seamless MPLS domain. In other word, the number of AGN and		AN in the seamless MPLS domain. In other word, the number of AGN and
	AN in the seamless MPLS domain is not limited, if the number of areas		AN in the seamless MPLS domain is not limited, if the number of areas
	can grow accordingly. The main limitation is the MPLS connectivity		can grow accordingly. The main limitation is the MPLS connectivity
	requirements on the AN, i.e. mainly the number of LSP needed on the		requirements on the AN, i.e. mainly the number of LSP needed on the
	AN. Another limitation may be the number of different LSP needed by		AN. Another limitation may be the number of different LSP needed by
	AN attached or behind an AGN. However, given foreseen deployments		AN attached or behind an AGN. However, given foreseen deployments
	and current AGN capabilities, this is not expected to be a		and current AGN capabilities, this is not expected to be a
	limitation.		limitation.
	In the control plane, BGP will typically handle all AN routes. This		In the control plane, BGP will typically handle all AN routes. This
	is significant but target deployments are well under current		is significant but target deployments are well under current
	equipments capacities. In addition, if required, additional		equipments capacities. In addition, if required, additional
	techniques could be used to improve this scalability, based on the		techniques could be used to improve this scalability, based on the
	experience gained with scaling BGP/MPLS VPN (e.g. route partitioning		experience gained with scaling BGP/MPLS VPN (e.g. route partitioning
	between RR planes, route filtering (static or dynamic with ORF or		between RR planes, route filtering (static or dynamic with ORF or
	route refresh) between AN and on AGN to improve AGN scalability.		route refresh) between AN and on AGN to improve AGN scalability.
	5.2.1.5. Numerical application for use case #1		5.2.1.5. Numerical application for use case #1
	As a recap, targets for deployment scenario 1 are:		As a recap, targets for deployment scenario 1 are:
	o Number of Aggregation Domains 100		o Number of Aggregation Domains 100
	o Number of Backbone Nodes 1.000		o Number of Backbone Nodes 1.000
	skipping to change at page 37, line 14		skipping to change at page 36, line 41
	8. Security Considerations		8. Security Considerations
	The Seamless MPLS Architecture is subject to similar security threats		The Seamless MPLS Architecture is subject to similar security threats
	as any MPLS LDP deployment. It is recommended that baseline security		as any MPLS LDP deployment. It is recommended that baseline security
	measures are considered as described in the LDP specification RFC5036		measures are considered as described in the LDP specification RFC5036
	[RFC5036] including ensuring authenticity and integrity of LDP		[RFC5036] including ensuring authenticity and integrity of LDP
	messages, as well as protection against spoofing and Denial of		messages, as well as protection against spoofing and Denial of
	Service attacks. Some deployments may require increased measures of		Service attacks. Some deployments may require increased measures of
	network security if a subset of Access Nodes are placed in locations		network security if a subset of Access Nodes are placed in locations
	with lower levels of physical security e.g. street cabinets ( common		with lower levels of physical security e.g. street cabinets ( common
	practice for VDSL access ). In such cases it is the responsibility		practice for VDSL access ). In such cases it is the responsibility
	of the system designer to take into account the physical security		of the system designer to take into account the physical security
	measures ( environmental design, mechanical or electronic access		measures ( environmental design, mechanical or electronic access
	control, intrusion detection ), as well as monitoring and auditing		control, intrusion detection ), as well as monitoring and auditing
	measures (configuration and Operating System changes, reloads, routes		measures (configuration and Operating System changes, reloads, routes
	advertisements ). But even with all this in mind, the designer still		advertisements ). But even with all this in mind, the designer still
	should consider network security risks and adequate measures arising		should consider network security risks and adequate measures arising
	from the lower level of physical security of those locations.		from the lower level of physical security of those locations.
	8.1. Access Network Security		8.1. Access Network Security
	skipping to change at page 39, line 4		skipping to change at page 38, line 32
	access locations with lower physical security, designer could also		access locations with lower physical security, designer could also
	consider using:		consider using:
	o different crypto keys for use in authentication procedures for		o different crypto keys for use in authentication procedures for
	these locations.		these locations.
	o stricter network protection mechanisms including DoS protection,		o stricter network protection mechanisms including DoS protection,
	interface and session flap dampening.		interface and session flap dampening.
	9. References		9. References
	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] , , , , "Archieving sub-second IGP convergence in large IP
	networks, ACM SIGCOMM Computer Communication Review, v.35		networks, ACM SIGCOMM Computer Communication Review, v.35
	n.3", July 2005.		n.3", July 2005.
	[BGP-PIC] "BGP PIC, Technical Report", November 2007.		[BGP-PIC] , "BGP PIC, Technical Report", November 2007.
	[I-D.draft-bashandy-bgp-edge-node-frr-03]		[I-D.draft-bashandy-bgp-edge-node-frr-03]
	"".		, .
	[I-D.draft-bashandy-bgp-frr-mirror-table-00]		[I-D.draft-bashandy-bgp-frr-mirror-table-00]
	"".		, .
	[I-D.draft-ietf-rtgwg-remote-lfa-00]		[I-D.draft-ietf-rtgwg-remote-lfa-00]
	"".		, .
	[I-D.draft-minto-2547-egress-node-fast-protection-00]		[I-D.draft-minto-2547-egress-node-fast-protection-00]
	"".		, .
	[I-D.filsfils-rtgwg-lfa-applicability]		[I-D.filsfils-rtgwg-lfa-applicability]
	Filsfils, C., Francois, P., Shand, M., Decraene, B.,		Filsfils, C., Francois, P., Shand, M., Decraene, B.,
	Uttaro, J., Leymann, N., and M. Horneffer, "LFA		Uttaro, J., Leymann, N., and M. Horneffer, "LFA
	applicability in SP networks",		applicability in SP networks", draft-filsfils-rtgwg-lfa-
	draft-filsfils-rtgwg-lfa-applicability-00 (work in		applicability-00 (work in progress), March 2010.
	progress), March 2010.
	[I-D.ietf-bfd-v4v6-1hop]		[I-D.ietf-bfd-v4v6-1hop]
	Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single		Katz, D. and D. Ward, "BFD for IPv4 and IPv6 (Single
	Hop)", draft-ietf-bfd-v4v6-1hop-11 (work in progress),		Hop)", draft-ietf-bfd-v4v6-1hop-11 (work in progress),
	January 2010.		January 2010.
	[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-03 (work		Demand in Seamless MPLS", draft-ietf-mpls-ldp-dod-06 (work
	in progress), August 2012.		in progress), May 2013.
	[I-D.kothari-henderickx-l2vpn-vpls-multihoming]		[I-D.kothari-henderickx-l2vpn-vpls-multihoming]
	Kothari, B., Kompella, K., Henderickx, W., and F. Balus,		Kothari, B., Kompella, K., Henderickx, W., and F. Balus,
	"BGP based Multi-homing in Virtual Private LAN Service",		"BGP based Multi-homing in Virtual Private LAN Service",
	draft-kothari-henderickx-l2vpn-vpls-multihoming-01 (work		draft-kothari-henderickx-l2vpn-vpls-multihoming-01 (work
	in progress), July 2009.		in progress), July 2009.
	[I-D.narten-iana-considerations-rfc2434bis]		[I-D.narten-iana-considerations-rfc2434bis]
	Narten, T. and H. Alvestrand, "Guidelines for Writing an		Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs",		IANA Considerations Section in RFCs", draft-narten-iana-
	draft-narten-iana-considerations-rfc2434bis-09 (work in		considerations-rfc2434bis-09 (work in progress), March
	progress), March 2008.		2008.
	[I-D.raggarwa-mac-vpn]		[I-D.raggarwa-mac-vpn]
	Aggarwal, R., Isaac, A., Uttaro, J., Henderickx, W., and		Aggarwal, R., Isaac, A., Uttaro, J., Henderickx, W., and
	F. Balus, "BGP MPLS Based MAC VPN",		F. Balus, "BGP MPLS Based MAC VPN", draft-raggarwa-mac-
	draft-raggarwa-mac-vpn-01 (work in progress), June 2010.		vpn-01 (work in progress), June 2010.
	[I-D.sajassi-l2vpn-rvpls-bgp]		[I-D.sajassi-l2vpn-rvpls-bgp]
	Sajassi, A., Patel, K., Mohapatra, P., Filsfils, C., and		Sajassi, A., Patel, K., Mohapatra, P., Filsfils, C., and
	S. Boutros, "Routed VPLS using BGP",		S. Boutros, "Routed VPLS using BGP", draft-sajassi-l2vpn-
	draft-sajassi-l2vpn-rvpls-bgp-01 (work in progress),		rvpls-bgp-01 (work in progress), July 2010.
	July 2010.
	[PE-FRR] Le Roux, J., Decraene, B., and Z. Ahmad, "Fast Reroute in		[PE-FRR] Le Roux, J.L., Decraene, B., and Z. Ahmad, "Fast Reroute
	MPLS L3VPN Networks - Towards CE-to-CE Protection, MPLS		in MPLS L3VPN Networks - Towards CE-to-CE Protection, MPLS
	2006 Conference".		2006 Conference", .
	[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,		[RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629,
	June 1999.		June 1999.
	[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.
	[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.
	[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,		[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
	and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP		and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
	Tunnels", RFC 3209, December 2001.		Tunnels", RFC 3209, December 2001.
	[RFC3353] Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul,		[RFC3353] Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul,
	F., and F. Ansari, "Overview of IP Multicast in a Multi-		F., and F. Ansari, "Overview of IP Multicast in a Multi-
	Protocol Label Switching (MPLS) Environment", RFC 3353,		Protocol Label Switching (MPLS) Environment", RFC 3353,
	August 2002.		August 2002.
	[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC		[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Text on Security Considerations", BCP 72, RFC 3552,		Text on Security Considerations", BCP 72, RFC 3552, July
	July 2003.		2003.
	[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute		[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
	Extensions to RSVP-TE for LSP Tunnels", RFC 4090,		Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
	May 2005.		2005.
	[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.
	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP		[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
	Specification", RFC 5036, October 2007.		Specification", RFC 5036, October 2007.
	[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension		[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension
	for Inter-Area Label Switched Paths (LSPs)", RFC 5283,		for Inter-Area Label Switched Paths (LSPs)", RFC 5283,
	July 2008.		July 2008.
	skipping to change at page 41, line 40		skipping to change at page 41, line 19
	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
	France Telecom		France Telecom
	38-40 rue du General Leclerc		38-40 rue du General Leclerc
	Issy Moulineaux cedex 9, 92794		Issy Moulineaux cedex 9 92794
	FR		FR
	Phone:		Email: bruno.decraene@orange.com
	Fax:
	Email: bruno.decraene@orange-ftgroup.com
	URI:
	Clarence Filsfils		Clarence Filsfils
	Cisco Systems		Cisco Systems
	Brussels,		Brussels
	Belgium		Belgium
	Phone:
	Fax:
	Email: cfilsfil@cisco.com		Email: cfilsfil@cisco.com
	URI:
	Maciek Konstantynowicz		Maciek Konstantynowicz (editor)
	Cisco Systems		Cisco Systems
	London,		London
	United Kingdom		United Kingdom
	Phone:
	Fax:
	Email: maciek@cisco.com		Email: maciek@cisco.com
	URI:
	Dirk Steinberg		Dirk Steinberg
	Steinberg Consulting		Steinberg Consulting
	Ringstrasse 2		Ringstrasse 2
	Buchholz 53567		Buchholz 53567
	DE		DE
	Email: dws@steinbergnet.net		Email: dws@steinbergnet.net
End of changes. 59 change blocks.
	192 lines changed or deleted		182 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/