< draft-li-mpls-mt-applicability-requirement-01.txt		draft-li-mpls-mt-applicability-requirement-02.txt >
	Internet Engineering Task Force Lianyuan. Li		Internet Engineering Task Force L. Li
	Internet-Draft Lu. Huang		Internet-Draft L. Huang
	Intended status: Standards Track China Mobile, Inc.		Intended status: Standards Track China Mobile
	Expires: September 15, 2011 N. So		Expires: January 9, 2012 N. So
	Verison Business		Verison Business
	A. Kvalbein		A. Kvalbein
	Resiliens Communication AS		Resiliens Communication AS
	March 14, 2011		B. zhang
			Telus Communications
			July 8, 2011
	MPLS Multiple Topology Applicability and Requirements		MPLS Multiple Topology Applicability and Requirements
	draft-li-mpls-mt-applicability-requirement-01.txt		draft-li-mpls-mt-applicability-requirement-02
	Abstract		Abstract
	This document describes the applicability and requirements for		This document describes the applicability and requirements for
	Multiprotocol Label Switching Multiple Topology (MPLS-MT). The		Multiprotocol Label Switching Multiple Topology (MPLS-MT). The
	applicability and requirements are presented from different angles.		applicability and requirements are presented from different angles.
	They are expressed from a customer's point of view, a service		They are expressed from a customer's point of view, a service
	provider's point of view and a vendor's point of view.		provider's point of view and a vendor's point of view.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 40 ¶
	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 September 15, 2011.		This Internet-Draft will expire on January 9, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 23 ¶
	1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Simplified Data-plane . . . . . . . . . . . . . . . . . . 6		3.1. Simplified Data-plane . . . . . . . . . . . . . . . . . . 6
	3.2. Automation of inter-layer interworking . . . . . . . . . . 7		3.2. Automation of inter-layer interworking . . . . . . . . . . 7
	3.3. Migration without service disruption . . . . . . . . . . . 7		3.3. Migration without service disruption . . . . . . . . . . . 7
	3.4. Protection using MT . . . . . . . . . . . . . . . . . . . 8		3.4. Protection using MT . . . . . . . . . . . . . . . . . . . 8
	3.5. Service Separation . . . . . . . . . . . . . . . . . . . . 8		3.5. Service Separation . . . . . . . . . . . . . . . . . . . . 8
	3.6. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 8		3.6. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 8
	3.7. Inter-domain MPLS-TE and MPLS VPN . . . . . . . . . . . . 9		3.7. Inter-domain MPLS-TE and MPLS VPN . . . . . . . . . . . . 9
			3.8. IPv6 deployment in IPv4 backbone . . . . . . . . . . . . . 9
	4. Service requirements . . . . . . . . . . . . . . . . . . . . . 9		4. Service requirements . . . . . . . . . . . . . . . . . . . . . 9
	4.1. Availability . . . . . . . . . . . . . . . . . . . . . . . 9		4.1. Availability . . . . . . . . . . . . . . . . . . . . . . . 10
	4.1.1. Physical Diversity and FRR . . . . . . . . . . . . . . 9		4.1.1. Physical Diversity and FRR . . . . . . . . . . . . . . 10
	4.2. Stability . . . . . . . . . . . . . . . . . . . . . . . . 10		4.2. Stability . . . . . . . . . . . . . . . . . . . . . . . . 10
	4.3. Traffic types . . . . . . . . . . . . . . . . . . . . . . 10		4.3. Traffic types . . . . . . . . . . . . . . . . . . . . . . 10
	4.4. Data isolation . . . . . . . . . . . . . . . . . . . . . . 10		4.4. Data isolation . . . . . . . . . . . . . . . . . . . . . . 11
	4.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 10		4.5. Security . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.5.1. User data security . . . . . . . . . . . . . . . . . . 11		4.5.1. User data security . . . . . . . . . . . . . . . . . . 11
	4.5.2. Access control . . . . . . . . . . . . . . . . . . . . 11		4.5.2. Access control . . . . . . . . . . . . . . . . . . . . 11
	4.5.3. MT router authentication and authorization . . . . . . 11		4.5.3. MT router authentication and authorization . . . . . . 12
	4.5.4. Inter domain security . . . . . . . . . . . . . . . . 11		4.5.4. Inter domain security . . . . . . . . . . . . . . . . 12
	4.6. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 12		4.6. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 12		4.7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.8. Quality of Service . . . . . . . . . . . . . . . . . . . . 12		4.8. Quality of Service . . . . . . . . . . . . . . . . . . . . 13
	4.9. Network Resource Partitioning and Sharing between		4.9. Network Resource Partitioning and Sharing between
	MPLS-MTs (REWRITE with emphasis/focus on partition) . . . 12		MPLS-MTs (REWRITE with emphasis/focus on partition) . . . 13
	5. Provider requirements . . . . . . . . . . . . . . . . . . . . 13		5. Provider requirements . . . . . . . . . . . . . . . . . . . . 13
	5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 13		5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 13
	5.1.1. Service Provider Capacity Sizing Projections . . . . . 13		5.1.1. Service Provider Capacity Sizing Projections . . . . . 14
	5.1.2. MPLS-MT Scalability aspects . . . . . . . . . . . . . 14		5.1.2. MPLS-MT Scalability aspects . . . . . . . . . . . . . 14
	5.1.3. Number of MPLS-MTs in the network . . . . . . . . . . 14		5.1.3. Number of MPLS-MTs in the network . . . . . . . . . . 14
	5.1.4. Number of MPLS-MTs per customer . . . . . . . . . . . 14		5.1.4. Number of MPLS-MTs per customer . . . . . . . . . . . 15
	5.1.5. Number of addresses and address prefixes per		5.1.5. Number of addresses and address prefixes per
	MPLS-MT . . . . . . . . . . . . . . . . . . . . . . . 14		MPLS-MT . . . . . . . . . . . . . . . . . . . . . . . 15
	5.1.6. Solution-Specific Metrics . . . . . . . . . . . . . . 15		5.1.6. Solution-Specific Metrics . . . . . . . . . . . . . . 15
	5.2. Management . . . . . . . . . . . . . . . . . . . . . . . . 15		5.2. Management . . . . . . . . . . . . . . . . . . . . . . . . 15
	5.3. Customer Management of a MPLS-MT . . . . . . . . . . . . . 15		5.3. Customer Management of a MPLS-MT . . . . . . . . . . . . . 16
	6. Engineering requirements . . . . . . . . . . . . . . . . . . . 16		6. Engineering requirements . . . . . . . . . . . . . . . . . . . 16
	6.1. Forwarding plane requirements . . . . . . . . . . . . . . 16		6.1. Forwarding plane requirements . . . . . . . . . . . . . . 16
	6.2. Control plane requirements . . . . . . . . . . . . . . . . 16		6.2. Control plane requirements . . . . . . . . . . . . . . . . 16
	6.3. Control Plane Containment . . . . . . . . . . . . . . . . 16		6.3. Control Plane Containment . . . . . . . . . . . . . . . . 17
	6.4. Requirements for commonality of MPLS-MT mechanisms . . . . 17		6.4. Requirements for commonality of MPLS-MT mechanisms . . . . 17
	6.5. Interoperability . . . . . . . . . . . . . . . . . . . . . 17		6.5. Interoperability . . . . . . . . . . . . . . . . . . . . . 17
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18		8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 18		9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	9.2. Informative References . . . . . . . . . . . . . . . . . . 18		9.2. Informative References . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Terminology		1. Terminology
	Terminology used in this document		Terminology used in this document
	Non-MT: router Routers that do not have the MT capability.		Non-MT: router Routers that do not have the MT capability.
	MT router: Routers that have MT capability as described in this		MT router: Routers that have MT capability as described in this
	document.		document.
	skipping to change at page 9, line 25 ¶		skipping to change at page 9, line 25 ¶
	multiple AS, PCE function has to be supported in each router in the		multiple AS, PCE function has to be supported in each router in the
	MPLS-TE tunnel. With MPLS MT, routers in different ASs can be		MPLS-TE tunnel. With MPLS MT, routers in different ASs can be
	included into a new AS. In this way, MPLS-TE tunnels can be easily		included into a new AS. In this way, MPLS-TE tunnels can be easily
	set up.		set up.
	MPLS VPNs can be constructed across differnet ASs. In some case,		MPLS VPNs can be constructed across differnet ASs. In some case,
	when there are multiple ASs, it is quite difficult to manage the		when there are multiple ASs, it is quite difficult to manage the
	inter-as MPLS VPN. With MPLS MT, all the PEs can be configured in a		inter-as MPLS VPN. With MPLS MT, all the PEs can be configured in a
	singe AS, so the MPLS VPN can be constructed and managed easily.		singe AS, so the MPLS VPN can be constructed and managed easily.
			3.8. IPv6 deployment in IPv4 backbone
			Without MPLS MT, the backbone is a sole topology to support IPv4 and
			IPv6 applications, IPv6 traffic is encoded into MPLS forwarding and
			mix with IPv4 traffic regardless using 6PE or 6VPN transition
			technology. As a result, service providers lose the visibility of
			traffic distribution breaking down to various protocols level which
			lead to impossible of accurately forecasting and planning of new IPv6
			applications.
			Besides, transition technology like 6PE or 6VPN request specific
			automatically generated IPv6 address to be used as next-hop and
			additional IPv6 routing and forwarding table to be maintained on
			gateway router,those tables coexist with IPv4 and consequentlly
			increase the amount of entire routes and bring challenge to enforce
			unified route and policy control. MPLS MT can help to de-couple the
			plane and simplify operation.
			Obtaining a logical isolated end to end IPv6 plane via MPLS MT boosts
			the intergation of IPv6 exclusive application simulation and SLA
			measurement. It helps to capture the data on each hop and get a
			thorough view by hop by hop analyzing.
	4. Service requirements		4. Service requirements
	These are the requirements that a customer can observe or measure for		These are the requirements that a customer can observe or measure for
	verifying whether the MPLS-MT service that the Service Provider (SP)		verifying whether the MPLS-MT service that the Service Provider (SP)
	provides is satisfactory. As mentioned before, each of these		provides is satisfactory. As mentioned before, each of these
	requirements apply equally across each of the three deployment		requirements apply equally across each of the three deployment
	scenarios unless stated otherwise.		scenarios unless stated otherwise.
	4.1. Availability		4.1. Availability
	skipping to change at page 12, line 24 ¶		skipping to change at page 12, line 46 ¶
	topology used by the service provider. The MPLS-MT services SHOULD		topology used by the service provider. The MPLS-MT services SHOULD
	be independent of MPLS-MT technology. To the extent possible, a		be independent of MPLS-MT technology. To the extent possible, a
	MPLS-MT service SHOULD be independent of the geographic extent of the		MPLS-MT service SHOULD be independent of the geographic extent of the
	deployment. Multiple MPLS-MTs per customer SHOULD be supported		deployment. Multiple MPLS-MTs per customer SHOULD be supported
	without requiring additional hardware resources.		without requiring additional hardware resources.
	4.7. Addressing		4.7. Addressing
	Each customer resource MUST be identified by an address that is		Each customer resource MUST be identified by an address that is
	unique within its MPLS-MT. It need not be identified by a globally		unique within its MPLS-MT. It need not be identified by a globally
	unique address. Support for private addresses as described in		unique address. Support for IPv4 private addresses as described in
	[RFC1918], as well as overlapping customer addresses SHALL be		[RFC1918] and unique local IPv6 addresses as described in [RFC 4193]
	supported. One or more MPLS-MTs for each customer can be built over		, as well as overlapping customer addresses SHALL be supported. One
	the same infrastructure without requiring any of them to renumber.		or more MPLS-MTs for each customer can be built over the same
	The solution MUST NOT use NAT on the customer traffic to achieve that		infrastructure without requiring any of them to renumber. The
			solution MUST NOT use NAT on the customer traffic to achieve that
	goal. Interconnection of two networks with overlapping IP addresses		goal. Interconnection of two networks with overlapping IP addresses
	is outside the scope of this document.		is outside the scope of this document.
	4.8. Quality of Service		4.8. Quality of Service
	A technical approach for supporting MPLS-MTs SHALL be able to support		A technical approach for supporting MPLS-MTs SHALL be able to support
	QoS via IETF standardized mechanisms such as Diffserv. Support for		QoS via IETF standardized mechanisms such as Diffserv. Support for
	best-effort traffic SHALL be mandatory for all MPLS-MT types. The		best-effort traffic SHALL be mandatory for all MPLS-MT types. The
	extent to which any specific MPLS-MT service will support QoS is up		extent to which any specific MPLS-MT service will support QoS is up
	to the service provider. In many cases single -provider single-AS		to the service provider. In many cases single -provider single-AS
	skipping to change at page 18, line 33 ¶		skipping to change at page 19, line 4 ¶
	[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi		[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
	Topology (MT) Routing in Intermediate System to		Topology (MT) Routing in Intermediate System to
	Intermediate Systems (IS-ISs)", RFC 5120, February 2008.		Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
	[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.
	[RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J., and A.		[RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J., and A.
	Ayyangar, "Encoding of Attributes for Multiprotocol Label		Ayyangar, "Encoding of Attributes for Multiprotocol Label
	Switching (MPLS) Label Switched Path (LSP) Establishment		Switching (MPLS) Label Switched Path (LSP) Establishment
	Using Resource ReserVation Protocol-Traffic Engineering		Using Resource ReserVation Protocol-Traffic Engineering
	(RSVP-TE)", RFC 4420, February 2006.		(RSVP-TE)", RFC 4420, February 2006.
	9.2. Informative References		9.2. Informative References
	Authors' Addresses		Authors' Addresses
	L Li		Lianyuan Li
	China Mobile, Inc.		China Mobile
	53A, Xibianmennei Ave.		53A, Xibianmennei Ave.
	Xunwu District, Beijing 01719		Xunwu District, Beijing 01719
	China		China
	Email: lilianyuan@chinamobile.com		Email: lilianyuan@chinamobile.com
	L Huang
	China Mobile, Inc.		Lu Huang
			China Mobile
	53A, Xibianmennei Ave.		53A, Xibianmennei Ave.
	Xunwu District, Beijing 01719		Xunwu District, Beijing 01719
	China		China
	Email: huanglu@chinamobile.com		Email: huanglu@chinamobile.com
	Ning So		Ning So
	Verison Business		Verison Business
	2400 North Glenville Drive		2400 North Glenville Drive
	Richardson, TX 78052		Richardson, TX 78052
	skipping to change at line 831 ¶		skipping to change at page 20, line 4 ¶
	Email: Ning.So@verizonbusiness.com		Email: Ning.So@verizonbusiness.com
	Amund Kvalbein		Amund Kvalbein
	Resiliens Communication AS		Resiliens Communication AS
	Martin Linges v 17, Fornebu		Martin Linges v 17, Fornebu
	Fornebu, Lysaker 1325		Fornebu, Lysaker 1325
	Norway		Norway
	Email: Amundk@simula.com		Email: Amundk@simula.com
			Boris Zhang
			Telus Communications
			200 Consilium Pl Floor 15
			Toronto, ON M1H 3J3
			Canada
			Email: Boris.Zhang@telus.com
End of changes. 23 change blocks.
	32 lines changed or deleted		62 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/