< draft-atlas-mpls-ldp-mrt-02.txt		draft-atlas-mpls-ldp-mrt-03.txt >
	MPLS Working Group A. Atlas		MPLS Working Group A. Atlas
	Internet-Draft K. Tiruveedhula		Internet-Draft K. Tiruveedhula
	Intended status: Standards Track C. Bowers		Intended status: Standards Track C. Bowers
	Expires: April 30, 2015 Juniper Networks		Expires: June 18, 2015 Juniper Networks
	J. Tantsura		J. Tantsura
	Ericsson		Ericsson
	IJ. Wijnands		IJ. Wijnands
	Cisco Systems, Inc.		Cisco Systems, Inc.
	October 27, 2014		December 15, 2014
	LDP Extensions to Support Maximally Redundant Trees		LDP Extensions to Support Maximally Redundant Trees
	draft-atlas-mpls-ldp-mrt-02		draft-atlas-mpls-ldp-mrt-03
	Abstract		Abstract
	This document specifies extensions to LDP to support the creation of		This document specifies extensions to the Label Distribution
	label-switched paths for Maximally Redundant Trees (MRT). A prime		Protocol(LDP) to support the creation of label-switched paths for
	use of MRTs is for unicast and multicast IP/LDP Fast-Reroute, which		Maximally Redundant Trees (MRT). A prime use of MRTs is for unicast
	we will refer to as MRT-FRR.		and multicast IP/LDP Fast-Reroute, which we will refer to as MRT-FRR.
	The sole protocol extension to LDP is simply the ability to advertise		The sole protocol extension to LDP is simply the ability to advertise
	an MRT Capability. This document describes that extension and the		an MRT Capability. This document describes that extension and the
	associated behavior expected for LSRs and LERs advertising the MRT		associated behavior expected for LSRs and LERs advertising the MRT
	Capability.		Capability.
	MRT-FRR uses LDP multi-topology extensions and requires three		MRT-FRR uses LDP multi-topology extensions and requires three
	different multi-topology IDs to be allocated from the LDP MT-ID		different multi-topology IDs to be allocated from the LDP MT-ID
	space.		space.
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	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 30, 2015.		This Internet-Draft will expire on June 18, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4		2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Overview of LDP Signaling Extensions for MRT . . . . . . . . 5		4. Overview of LDP Signaling Extensions for MRT . . . . . . . . 5
	4.1. MRT Capability Advertisement . . . . . . . . . . . . . . 5		4.1. MRT Capability Advertisement . . . . . . . . . . . . . . 5
	4.1.1. Interaction of LDP MRT Capability with IPv4 and IPv6 6		4.1.1. Interaction of MRT Capability and MT Capability . . . 6
			4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6 6
	4.2. Use of the Rainbow MRT MT-ID . . . . . . . . . . . . . . 7		4.2. Use of the Rainbow MRT MT-ID . . . . . . . . . . . . . . 7
	4.3. MRT-Blue and MRT-Red FECs . . . . . . . . . . . . . . . . 7		4.3. MRT-Blue and MRT-Red FECs . . . . . . . . . . . . . . . . 7
	5. LDP MRT FEC Advertisements . . . . . . . . . . . . . . . . . 7		5. LDP MRT FEC Advertisements . . . . . . . . . . . . . . . . . 7
	5.1. MRT-specific behavior . . . . . . . . . . . . . . . . . . 8		5.1. MRT-specific behavior . . . . . . . . . . . . . . . . . . 8
	5.1.1. ABR behavior and use of the Rainbow FEC . . . . . . . 8		5.1.1. ABR behavior and use of the Rainbow FEC . . . . . . . 8
	5.1.2. Proxy-node attachment router behavior . . . . . . . . 9		5.1.2. Proxy-node attachment router behavior . . . . . . . . 9
	5.2. LDP protocol procedures in the context of MRT label		5.2. LDP protocol procedures in the context of MRT label
	distribution . . . . . . . . . . . . . . . . . . . . . . 10		distribution . . . . . . . . . . . . . . . . . . . . . . 10
	5.2.1. LDP peer in RFC5036 . . . . . . . . . . . . . . . . . 10		5.2.1. LDP peer in RFC5036 . . . . . . . . . . . . . . . . . 10
	5.2.2. Next hop in RFC5036 . . . . . . . . . . . . . . . . . 10		5.2.2. Next hop in RFC5036 . . . . . . . . . . . . . . . . . 10
	skipping to change at page 2, line 50 ¶		skipping to change at page 2, line 51 ¶
	requirements in RFC5036 . . . . . . . . . . . . . . . 12		requirements in RFC5036 . . . . . . . . . . . . . . . 12
	5.2.5. Validating FECs in routing table . . . . . . . . . . 13		5.2.5. Validating FECs in routing table . . . . . . . . . . 13
	5.2.6. Recognizing new FECs . . . . . . . . . . . . . . . . 13		5.2.6. Recognizing new FECs . . . . . . . . . . . . . . . . 13
	5.2.7. Not propagating Rainbow FEC label mappings . . . . . 13		5.2.7. Not propagating Rainbow FEC label mappings . . . . . 13
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . 15		9.2. Informative References . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	This document describes the LDP signaling extension and associated		This document describes the LDP signaling extension and associated
	behavior necessary to support the architecture that defines how IP/		behavior necessary to support the architecture that defines how IP/
	LDP Fast-Reroute can use MRTs [I-D.ietf-rtgwg-mrt-frr-architecture].		LDP Fast-Reroute can use MRTs [I-D.ietf-rtgwg-mrt-frr-architecture].
	It is necessary to be familiar with the architecture in		It is necessary to be familiar with the architecture in
	[I-D.ietf-rtgwg-mrt-frr-architecture] to understand how and why the		[I-D.ietf-rtgwg-mrt-frr-architecture] to understand how and why the
	LDP extensions for behavior are needed.		LDP extensions for behavior are needed.
	skipping to change at page 3, line 46 ¶		skipping to change at page 3, line 46 ¶
	capability extension is needed for LDP. An LDP implementation		capability extension is needed for LDP. An LDP implementation
	supporting MRT MUST also follow the rules described here for		supporting MRT MUST also follow the rules described here for
	originating and managing FECs related to MRT, as indicated by their		originating and managing FECs related to MRT, as indicated by their
	multi-topology ID. Network reconvergence is described in		multi-topology ID. Network reconvergence is described in
	[I-D.ietf-rtgwg-mrt-frr-architecture] and the worst-case network		[I-D.ietf-rtgwg-mrt-frr-architecture] and the worst-case network
	convergence time can be flooded via the extension in Section 7 of		convergence time can be flooded via the extension in Section 7 of
	[I-D.atlas-ospf-mrt].		[I-D.atlas-ospf-mrt].
	IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and		IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and
	node failures in an arbitrary network topology where the failure		node failures in an arbitrary network topology where the failure
	doesn't split the network. It can also be deployed incrementally; an		doesn't partition the network. It can also be deployed
	MRT Island is formed of connected supporting routers and the MRTs are		incrementally; an MRT Island is formed of connected supporting
	computed inside that island.		routers and the MRTs are computed inside that island.
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119]		document are to be interpreted as described in [RFC2119]
	3. Terminology		3. Terminology
	For ease of reading, some of the terminology defined in		For ease of reading, some of the terminology defined in
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 14 ¶
	Island Border Router (IBR): A router in the MRT Island that is		Island Border Router (IBR): A router in the MRT Island that is
	connected to a router not in the MRT Island and both routers are		connected to a router not in the MRT Island and both routers are
	in a common area or level.		in a common area or level.
	Island Neighbor (IN): A router that is not in the MRT Island but is		Island Neighbor (IN): A router that is not in the MRT Island but is
	adjacent to an IBR and in the same area/level as the IBR..		adjacent to an IBR and in the same area/level as the IBR..
	4. Overview of LDP Signaling Extensions for MRT		4. Overview of LDP Signaling Extensions for MRT
	Routers need to know which of their neighbors support MRT.		Routers need to know which of their LDP neighbors support MRT. This
	Supporting MRT indicates several different aspects of behavior, as		is communicated using the MRT Capability Advertisement. Supporting
	listed below.		MRT indicates several different aspects of behavior, as listed below.
	1. Support for Multi-Topology (MT) - this MAY also be indicated via		1. Sending and receiving multi-topology FEC elements, as defined in
	the Multi-Topology LDP Capability [RFC7307].		[RFC7307].
	2. Understand the Rainbow MRT MT-ID and apply the associated labels		2. Understanding the Rainbow MRT MT-ID and applying the associated
	to all relevant MT-IDs.		labels to all relevant MT-IDs.
	3. Advertise the Rainbow MRT MT-ID to the appropriate neighbors for		3. Advertising the Rainbow MRT FEC to the appropriate neighbors for
	the associated prefix.		the appropriate prefix.
	4. If acting as LDP egress for a prefix in the default topology,		4. If acting as LDP egress for a prefix in the default topology,
	also advertise and act as egress for the same prefix in MRT-Red		also acting as egress for the same prefix in MRT-Red and MRT-
	and MRT-Blue.		Blue.
	5. For a FEC learned from a neighbor that does not support MRT,		5. For a FEC learned from a neighbor that does not support MRT,
	originate FECS for MRT-Red and MRT-Blue with the same prefix.		originating FECs for MRT-Red and MRT-Blue with the same prefix.
	This MRT Island egress behavior is to support an MRT Island that		This MRT Island egress behavior is to support an MRT Island that
	does not include all routers in the area/level.		does not include all routers in the area/level.
	4.1. MRT Capability Advertisement		4.1. MRT Capability Advertisement
	It is not possible to support MRT without supporting the LDP multi-
	topology extensions, but it is possible that the only use of the
	multi-topology extensions is for MRT. In that case, a router MAY not
	negotiate the multi-topology capability and only negotiate the MRT
	Capability with its LDP peers. Negotiation of the multi-topology
	capability is not required with negotiation of the MRT capability.
	A new MRT Capability Parameter TLV is defined in accordance with LDP		A new MRT Capability Parameter TLV is defined in accordance with LDP
	Capability definition guidelines[RFC5561].		Capability definition guidelines[RFC5561].
	The LDP MRT capability can be advertised during LDP session		The LDP MRT capability can be advertised during LDP session
	initialization or after the LDP session is established.		initialization or after the LDP session is established.
	Advertisement of the MRT capability indicates support of the		Advertisement of the MRT capability indicates support of the
	procedures for establishing the MRT-Blue and MRT-Red LSP paths		procedures for establishing the MRT-Blue and MRT-Red LSP paths
	detailed in this document. If the peer has not advertised the MRT		detailed in this document. If the peer has not advertised the MRT
	capability, then it indicates that LSR does not support MRT		capability, then it indicates that LSR does not support MRT
	procedures.		procedures.
	skipping to change at page 6, line 42 ¶		skipping to change at page 6, line 36 ¶
	MRT Capability: TBA-MRT-LDP-1 (To Be Allocated by IANA)		MRT Capability: TBA-MRT-LDP-1 (To Be Allocated by IANA)
	Length: The length (in octets) of TLV. Its value is 1.		Length: The length (in octets) of TLV. Its value is 1.
	S-bit: The State bit MUST be 1 if used in LDP "Initialization"		S-bit: The State bit MUST be 1 if used in LDP "Initialization"
	message. MAY be set to 0 or 1 in dynamic "Capability" message to		message. MAY be set to 0 or 1 in dynamic "Capability" message to
	advertise or withdraw the capability respectively, as described in		advertise or withdraw the capability respectively, as described in
	[RFC5561].		[RFC5561].
	4.1.1. Interaction of LDP MRT Capability with IPv4 and IPv6		4.1.1. Interaction of MRT Capability and MT Capability
	An LSR which advertises the MRT LDP capability is expected to		An LSR advertising the LDP MRT Capability MUST also advertise the LDP
	advertise MRT-related FEC-label bindings for both IPv4 and IPv6		Multi-topology (MT) capability. If an LSR negotiates LDP MRT
	address families, if the LSR originates shortest-path FEC-label		Capability with an LDP neighbor without also negotiating the LDP MT
	bindings for those address families.		Capability, the LSR MUST behave as if LDP MRT Capability has not been
			negotiated and respond with the "MRT Capability negotiated without MT
			Capability" status code in the LDP Notification message (defined in
			the document). The E-bit of this Notification should be set to 0 to
			indicate that this is an Advisory Notification. The LDP session
			SHOULD NOT be terminated.
			4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6
			The MRT LDP Capability Advertisement does not distinguish between
			IPv4 and IPv6 address families. An LSR which advertises the MRT LDP
			capability is expected to advertise MRT-related FEC-label bindings
			for the same address families for which it advertises shortest-path
			FEC-label bindings. Therefore, an LSR advertising MRT LDP capability
			and shortest path FEC-label bindings for IPv4 only (or IPv6 only)
			would be expected to advertise MRT-related FEC-label binding for IPv4
			only (or IPv6 only). An LSR advertising the MRT LDP capability and
			shortest-path FEC label bindings for BOTH IPv4 and IPv6 is expected
			to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6.
			In this scenario, advertising MRT-related FEC-label bindings only for
			IPv4 only (or only for IPv6) is not supported.
	4.2. Use of the Rainbow MRT MT-ID		4.2. Use of the Rainbow MRT MT-ID
	Section 10.1 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the		Section 10.1 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the
	need for an area border router (ABR) to have different neighbors use		need for an area border router (ABR) to have different neighbors use
	different MPLS labels when sending traffic to the ABR for the same		different MPLS labels when sending traffic to the ABR for the same
	FEC. More detailed discussion of the Rainbow MRT MT-ID is provided		FEC. More detailed discussion of the Rainbow MRT MT-ID is provided
	in Section 5.1.1.		in Section 5.1.1.
	Another use for the Rainbow MRT MT-ID is for an LSR to send the		Another use for the Rainbow MRT MT-ID is for an LSR to send the
	skipping to change at page 14, line 15 ¶		skipping to change at page 14, line 21 ¶
	7. IANA Considerations		7. IANA Considerations
	IANA is requested to allocate a value for the new LDP Capability TLV		IANA is requested to allocate a value for the new LDP Capability TLV
	(the first free value in the range 0x0500 to 0x05FF) from the LDP		(the first free value in the range 0x0500 to 0x05FF) from the LDP
	registry "TLV Type Name Space": MRT Capability TLV (TBA-MRT-LDP-1).		registry "TLV Type Name Space": MRT Capability TLV (TBA-MRT-LDP-1).
	Value Description Reference Notes / Reg. Date		Value Description Reference Notes / Reg. Date
	------------- ------------------ ------------ -----------------		------------- ------------------ ------------ -----------------
	TBA-MRT-LDP-1 MRT Capability TLV [This draft]		TBA-MRT-LDP-1 MRT Capability TLV [This draft]
			IANA is requested to allocate a value for the new LDP Status Code
			(the first free value in the range 0x00000032-0x00000036) from the
			LDP registry "Status Code Name Space": "MRT Capability negotiated
			without MT Capability" (TBA-MRT-LDP-3).
			Value E Description Reference Notes / Reg. Date
			------------- - ------------------------- --------- -----------------
			TBA-MRT-LDP-3 0 MRT Capability negotiated [This draft]
			without MT Capability
	IANA is requested to allocate a value from the MPLS Multi-Topology		IANA is requested to allocate a value from the MPLS Multi-Topology
	Identifiers Name Space [RFC7307]: Rainbow MRT MT-ID (TBA-MRT-LDP-2).		Identifiers Name Space [RFC7307]: Rainbow MRT MT-ID (TBA-MRT-LDP-2).
	Value Purpose Reference		Value Purpose Reference
	------------- ------------------ ------------		------------- ------------------ ------------
	TBA-MRT-LDP-2 Rainbow MRT MT-ID [This draft]		TBA-MRT-LDP-2 Rainbow MRT MT-ID [This draft]
	8. Acknowledgements		8. Acknowledgements
	The authors would like to thank Ross Callon and Loa Andersson for		The authors would like to thank Ross Callon, Loa Andersson, Stewart
	their suggestions.		Bryant, Mach Chen, and Greg Mirsky for their suggestions.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-rtgwg-mrt-frr-algorithm]		[I-D.ietf-rtgwg-mrt-frr-algorithm]
	Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.		Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
	Gopalan, "Algorithms for computing Maximally Redundant		Gopalan, "Algorithms for computing Maximally Redundant
	Trees for IP/LDP Fast-Reroute", draft-rtgwg-mrt-frr-		Trees for IP/LDP Fast-Reroute", draft-rtgwg-mrt-frr-
	algorithm-01 (work in progress), July 2014.		algorithm-01 (work in progress), July 2014.
End of changes. 19 change blocks.
	39 lines changed or deleted		63 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/