draft-ietf-mpls-mldp-recurs-fec-01.txt		draft-ietf-mpls-mldp-recurs-fec-02.txt
	Network Working Group IJsbrand Wijnands		MPLS Working Group IJsbrand Wijnands
	Internet Draft Eric C. Rosen		Internet Draft Eric C. Rosen
	Intended Status: Proposed Standard Cisco Systems, Inc.		Intended Status: Proposed Standard Cisco Systems, Inc.
	Expires: October 4, 2011		Expires: November 9, 2011
	Maria Napierala		Maria Napierala
	AT&T		AT&T
	Nicolai Leymann		Nicolai Leymann
	Deutsche Telekom		Deutsche Telekom
	April 4, 2011		May 9, 2011
	Using mLDP through a Backbone where there is no Route to the Root		Using Multipoint LDP when the Backbone has no Route to the Root
	draft-ietf-mpls-mldp-recurs-fec-01.txt		draft-ietf-mpls-mldp-recurs-fec-02.txt
	Abstract		Abstract
	The control protocol used for constructing Point-to-Multipoint and		The control protocol used for constructing Point-to-Multipoint and
	Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a		Multipoint-to-Multipoint Label Switched Paths ("MP LSPs") contains a
	field that identifies the address of a "root node". Intermediate		field that identifies the address of a "root node". Intermediate
	nodes are expected to be able to look up that address in their		nodes are expected to be able to look up that address in their
	routing tables. However, if the route to the root node is a BGP		routing tables. However, if the route to the root node is a BGP
	route, and the intermediate nodes are part of a BGP-free core, this		route, and the intermediate nodes are part of a BGP-free core, this
	is not possible. This document specifies procedures which enable a		is not possible. This document specifies procedures which enable a
	MP LSP to be constructed through a BGP-free core. In these		MP LSP to be constructed through a BGP-free core. In these
	procedures, the root node address is temporarily replaced by an		procedures, the root node address is temporarily replaced by an
	address which is known to the intermediate nodes.		address that is known to the intermediate nodes and is on the path to
			the true root node.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 2, line 28		skipping to change at page 2, line 28
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1 Introduction .......................................... 3		1 Introduction .......................................... 3
	2 The Recursive Opaque Value Type ....................... 5		2 The Recursive Opaque Value ............................ 5
	2.1 Encoding .............................................. 5		2.1 Encoding .............................................. 5
	2.2 Procedures ............................................ 5		2.2 Procedures ............................................ 5
	3 The VPN-Recursive MP FEC Element ...................... 6		3 The VPN-Recursive Opaque Value ........................ 6
	3.1 Encoding .............................................. 6		3.1 Encoding .............................................. 6
	3.2 Procedures ............................................ 7		3.2 Procedures ............................................ 7
	3.2.1 Unsegmented Inter-AS P-tunnels ........................ 7		3.2.1 Unsegmented Inter-AS P-tunnels ........................ 7
	3.2.2 Limited Carrier's Carrier Function .................... 9		3.2.2 Limited Carrier's Carrier Function .................... 9
	4 IANA Considerations ................................... 10		4 IANA Considerations ................................... 10
	5 Security Considerations ............................... 11		5 Security Considerations ............................... 11
	6 Acknowledgments ....................................... 11		6 Acknowledgments ....................................... 11
	7 Authors' Addresses .................................... 11		7 Authors' Addresses .................................... 11
	8 Normative References .................................. 12		8 Normative References .................................. 12
	1. Introduction		1. Introduction
	[MLDP] defines several LDP FEC element encodings: P2MP, MP2MP		[mLDP] defines several LDP "Forwarding Equivalence Class" (FEC)
	Upstream, and MP2MP Downstream.		element encodings: Point-to-Multipoint (P2MP), Multipoint-to-
			Multipoint (MP2MP) Upstream, and MP2MP Downstream.
	The encoding for these three FEC elements is shown in Figure 1.		The encoding for these three FEC elements is shown in Figure 1.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Address Family | Address Length|		| Type | Address Family | Address Length|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	~ Root Node Address ~		~ Root Node Address ~
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Opaque Length | . |		| Opaque Length | . |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
	~ ~		~ ~
	| Opaque Value |		| Opaque Value |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	MLDP FEC Element Encoding		mLDP FEC Element Encoding
	Figure 1		Figure 1
	Note that a P2MP or MP2MP label switched path ("MP LSP") is		Note that a P2MP or MP2MP label switched path ("MP LSP") is
	identified by the combination of a "root node" and a variable length		identified by the combination of a "root node" and a variable length
	"opaque value". The root node also plays a special role in the MLDP		"opaque value". The root node also plays a special role in the mLDP
	procedures - MLDP messages that are "about" a particular MP LSP are		procedures - mLDP messages that are "about" a particular MP LSP are
	forwarded to the LDP adjacency that is the next hop on the route to		forwarded to the LDP adjacency that is the next hop on the route to
	the root node.		the root node.
	Sometimes it is desirable for a MP LSP to pass through a part of the		Sometimes it is desirable for a MP LSP to pass through a part of the
	network in which there is no route to the root node. For instance,		network in which there is no route to the root node. For instance,
	consider the topology of Figure 2:		consider the topology of Figure 2:
	CE1----PE1---P1---- ...----P2 ----PE2----CE2----R		CE1----PE1---P1---- ...----P2 ----PE2----CE2----R
	Figure 2		Figure 2
	skipping to change at page 4, line 12		skipping to change at page 4, line 13
	hop. However, the provider's interior routers (such as P1 and P2) do		hop. However, the provider's interior routers (such as P1 and P2) do
	not have any BGP-learned routes, and in particular do not have any		not have any BGP-learned routes, and in particular do not have any
	routes to R.		routes to R.
	In such an environment, data packets from CE1 address to R would get		In such an environment, data packets from CE1 address to R would get
	encapsulated by PE1, tunneled to PE2, decapsulated by PE2, and		encapsulated by PE1, tunneled to PE2, decapsulated by PE2, and
	forwarded to CE2.		forwarded to CE2.
	Suppose now that CE1 is trying to set up a MP LSP whose root is R,		Suppose now that CE1 is trying to set up a MP LSP whose root is R,
	and the intention is that the provider's network will participate in		and the intention is that the provider's network will participate in
	the construction of the LSP. Then the MLDP messages identifying the		the construction of the LSP. Then the mLDP messages identifying the
	LSP must be passed from CE1 to PE1, from PE1 to P1, ..., from P2 to		LSP must be passed from CE1 to PE1, from PE1 to P1, ..., from P2 to
	PE2, from PE2 to CE2, and from CE2 to R.		PE2, from PE2 to CE2, and from CE2 to R.
	To begin the process, CE1 creates a MP FEC element with the address		To begin the process, CE1 creates a MP FEC element with the address
	of R as the root node address, and passes that FEC element via MLDP		of R as the root node address, and passes that FEC element via mLDP
	to PE1. However, PE1 cannot use this same FEC element to identify		to PE1. However, PE1 cannot use this same FEC element to identify
	the LSP in the LDP messages it sends to P1, because P1 does not have		the LSP in the LDP messages it sends to P1, because P1 does not have
	a route to R.		a route to R.
	However, PE1 does know that PE2 is the "BGP next hop" on the path to		However, PE1 does know that PE2 is the "BGP next hop" on the path to
	R. What is needed is a method whereby:		R. What is needed is a method whereby:
	- PE1 can tell P1 to set up an LSP as if the root node were PE2,		- PE1 can tell P1 to set up an LSP as if the root node were PE2,
	and		and
	- PE2 can determine that the LSP in question is really rooted at R,		- PE2 can determine that the LSP in question is really rooted at R,
	not at PE2 itself,		not at PE2 itself,
	- PE2 can determine the original FEC element that CE1 passed to		- PE2 can determine the original FEC element that CE1 passed to
	PE1, so that PE2 can pass it on to CE2.		PE1, so that PE2 can pass it on to CE2.
	This document defines the procedures that allow CE1 to create an LSP		This document defines the procedures that allow CE1 to create an LSP
	rooted at R. These procedures require PE1 to modify the MP FEC		rooted at R. These procedures require PE1 to modify the MP FEC
	element before sending an MLDP message to P1. The modified FEC		element before sending an mLDP message to P1. The modified FEC
	element has PE2 as the root, and the original FEC element as the		element has PE2 as the root, and the original FEC element as the
	opaque value. This requires a new type of opaque value. Since the		opaque value. This requires a new type of opaque value. Since the
	opaque value contains a FEC element, we call this a "Recursive Opaque		opaque value contains a FEC element, we call this a "Recursive Opaque
	Value". When PE2 sends an mLDP message to CE2, it replaces the FEC		Value". When PE2 sends an mLDP message to CE2, it replaces the FEC
	element with the opaque value, thus undoing the recursion. Details		element with the opaque value, thus undoing the recursion. Details
	are in section 2.		are in section 2.
	Section 3 defines a "VPN Recursive Opaque Value". Whereas the		Section 3 defines a "Virtual Private Network (VPN) Recursive Opaque
	"Recursive Opaque Value" carries the original FEC, the "VPN Recursive		Value". Whereas the "Recursive Opaque Value" carries the original
	Opaque Value" carries the original FEC plus a Route Distinguisher		FEC, the "VPN Recursive Opaque Value" carries the original FEC plus a
	(RD). This has several possible uses in an L3VPN context. Details		Route Distinguisher (RD). This is applicable when MP LSPs are being
	are in section 3.		used to carry the multicast traffic of a VPN [MVPN]. Details are in
			section 3.
	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].
	2. The Recursive Opaque Value Type		2. The Recursive Opaque Value
	2.1. Encoding		2.1. Encoding
	We define a new Opaque Value Type, the Recursive Opaque Value Type.		We define a new type of Opaque Value, the Recursive Opaque Value.
			This is a "basic type", identified by a one-octet type field.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 6 | Length | |		| Type = TBD | Length | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	~ ~		~ ~
	| P2MP or MP2MP FEC Element |		| P2MP or MP2MP FEC Element |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Recursive Opaque Value Type		Recursive Opaque Value
	Figure 3		Figure 3
	The "opaque value" itself is a P2MP or MP2MP FEC element, encoded		The value field of the "Recursive Opaque Value" is itself is a P2MP
	exactly as specified in [MLDP], with a type field, a length field,		or MP2MP FEC element, encoded exactly as specified in [mLDP], with a
	and value field of is own. The length field of the Recursive Opaque		type field, a length field, and value field of its own. The length
	Value Type thus includes the type and length fields of the FEC		of the Recursive Opaque Value thus includes the lengths of the type,
	element that is the value field.		length, and value fields of the contained FEC element.
	2.2. Procedures		2.2. Procedures
	In the topology of Figure 2, let us suppose that CE1 sends PE1 an MP		In the topology of Figure 2, let us suppose that CE1 sends PE1 an MP
	FEC element whose root node is R, and whose opaque value is Q. We		FEC element whose root node is R, and whose opaque value is Q. We
	will refer to this FEC element as "CE1-FEC". We may think of CE1-FEC		will refer to this FEC element as "CE1-FEC". We may think of CE1-FEC
	as an ordered pair, as follows:		as an ordered pair, as follows:
	CE1-FEC = <root=R, opaque_value=Q>.		CE1-FEC = <root=R, opaque_value=Q>.
	PE1 determines that the root node R matches a BGP route, with a BGP		PE1 determines that the root node R matches a BGP route, with a BGP
	next hop of PE2. PE1 also knows by its configuration that the		next hop of PE2. PE1 also knows by its configuration that the
	interior routers on the path to PE2 are "BGP-free", and thus have no		interior routers on the path to PE2 are "BGP-free", and thus have no
	route to R.		route to R.
	PE1 therefore MUST create a new MP FEC element, whose root node		PE1 therefore MUST create a new MP FEC element, whose root node
	address is the address of PE2, and whose opaque value is a Recursive		address is the address of PE2, and whose opaque value is a Recursive
	(type 6) Opaque Value whose value field contains CE1-FEC. We refer		Opaque Value whose value field contains CE1-FEC. We refer to this
	to this FEC element as PE2-FEC. PE1 then MUST send this FEC element		FEC element as PE2-FEC. PE1 then MUST send this FEC element to P1.
	to P1.
	PE2-FEC = <root=PE2, opaque_value=CE1-FEC>, or		PE2-FEC = <root=PE2, opaque_value=CE1-FEC>, or
	PE2-FEC = <root=PE2, opaque_value=<root=R,		PE2-FEC = <root=PE2, opaque_value=<root=R,
	opaque_value=Q>>		opaque_value=Q>>
	As far as the interior routers are concerned, they are being		As far as the interior routers are concerned, they are being
	requested to build a MP LSP whose root node is PE2. They MUST NOT		requested to build a MP LSP whose root node is PE2. They MUST NOT
	interpret the opaque value at all.		interpret the opaque value at all.
	When PE2-FEC arrives at PE2, PE2 notes that it is the identified root		When PE2-FEC arrives at PE2, PE2 notes that it (PE2) is the
	node, and that the opaque value is a Recursive (type 6) opaque value.		identified root node, and that the opaque value is a Recursive Opaque
	Therefore it MUST replace PE2-FEC with the contents of the type 6		Value. Therefore PE2 MUST replace PE2-FEC with the contents of the
	opaque value (i.e., with CE1-FEC) before doing any further		Recursive Opaque Value (i.e., with CE1-FEC) before doing any further
	processing. This will result in CE1-FEC being sent on to CE2, and		processing. This will result in CE1-FEC being sent on to CE2, and
	presumably further from CE2 to R. Note that CE1-FEC will contain the		presumably further from CE2 to R. Note that CE1-FEC will contain the
	LSP root node specified by CE1; the presumption is that PE2 has a		LSP root node specified by CE1; the presumption is that PE2 has a
	route to this root node.		route to this root node.
	3. The VPN-Recursive MP FEC Element		3. The VPN-Recursive Opaque Value
	3.1. Encoding		3.1. Encoding
	We define a new Opaque Value Type, the VPN-Recursive Opaque Value		We define a new type of Opaque Value, the VPN-Recursive Opaque Value.
	Type.		This is a "basic type", identified by a one-octet type field.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type = 7 | Length | |		| Type = TBD | Length | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	| |		| |
	| Route Distinguisher (8 octets) +-+-+-+-+-+-+-+-+		| Route Distinguisher (8 octets) +-+-+-+-+-+-+-+-+
	| | |		| | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	~ ~		~ ~
	| P2MP or MP2MP FEC Element |		| P2MP or MP2MP FEC Element |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	VPN-Recursive Opaque Value Type		VPN-Recursive Opaque Value
	Figure 3		Figure 3
	The "opaque value" consists of an eight-octet Route Distinguisher		The value field of the "VPN-Recursive Opaque Value" consists of an
	(RD), followed by a P2MP or MP2MP FEC element, encoded exactly as		eight-octet Route Distinguisher (RD), followed by a P2MP or MP2MP FEC
	specified in [MLDP], with a type field, a length field, and value		element, encoded exactly as specified in [mLDP], with a type field, a
	field of is own. The length field of the Recursive Opaque Value Type		length field, and value field of is own. The length of the VPN-
	thus includes the 8 octets of RD plus the type and length fields of		Recursive Opaque Value thus includes the 8 octets of RD plus the
	the FEC element that is the value field.		lengths of the type, length, and values fields of the contained FEC
			element.
	3.2. Procedures		3.2. Procedures
	3.2.1. Unsegmented Inter-AS P-tunnels		3.2.1. Unsegmented Inter-AS P-tunnels
	Consider the Inter-AS VPN scenario depicted in Figure 4.		Consider the Inter-AS VPN scenario depicted in Figure 4.
	PE1 --- P1 ---- ASBR1 ... ASBR2 ---- P2 ---- PE2		PE1 --- P1 ---- ASBR1 ... ASBR2 ---- P2 ---- PE2
	Figure 4		Figure 4
	skipping to change at page 8, line 27		skipping to change at page 8, line 27
	Intra-AS I-PMSI A-D routes. Therefore one must use a Recursive FEC		Intra-AS I-PMSI A-D routes. Therefore one must use a Recursive FEC
	element that contains the RD as well as the as well as the address of		element that contains the RD as well as the as well as the address of
	PE2. The "VPN-Recursive FEC Element" defined herein is used for this		PE2. The "VPN-Recursive FEC Element" defined herein is used for this
	purpose.		purpose.
	This enables us to provide the same functionality, for mLDP P-tunnels		This enables us to provide the same functionality, for mLDP P-tunnels
	that is provided for PIM P-tunnels in section 8.1.3.2 of [MVPN]		that is provided for PIM P-tunnels in section 8.1.3.2 of [MVPN]
	though the use of the MVPN Join Attribute.		though the use of the MVPN Join Attribute.
	At PE1 in Figure 4, the LSP to be created is associated with a		At PE1 in Figure 4, the LSP to be created is associated with a
	particular VRF. PE1 looks up in that VRF the Intra-AS I-PMSI A-D		particular VPN Routing/Forwarding Table (VRF). PE1 looks up in that
	route originated by PE2. It finds that the BGP next hop of that		VRF the Intra-AS I-PMSI A-D route originated by PE2. It finds that
	route is ASBR1. So it creates a P2MP or MP2MP FEC element whose root		the BGP next hop of that route is ASBR1. So it creates a P2MP or
	is ASBR1, and whose opaque value is a VPN-Recursive FEC element. The		MP2MP FEC element whose root is ASBR1, and whose opaque value is a
	VPN-Recursive FEC element itself consists of a root, an RD, and an		VPN-Recursive FEC element. The VPN-Recursive FEC element itself
	opaque value, set as follows:		consists of a root, an RD, and an opaque value, set as follows:
	- The root is PE2		- The root is PE2
	- The RD is the RD from the NLRI of the Intra-AS A-D route		- The RD is the RD from the NLRI of the Intra-AS A-D route
	originated by PE2.		originated by PE2.
	- The opaque value is chosen (by some method outside the scope of		- The opaque value is chosen (by some method outside the scope of
	this document) so as to be unique in the context of PE2. (E.g.,		this document) so as to be unique in the context of PE2. (E.g.,
	it may have been specified in a PMSI tunnel attribute originated		it may have been specified in a PMSI tunnel attribute originated
	by PE2.) We will refer to this opaque value as "Q".		by PE2.) We will refer to this opaque value as "Q".
	The resulting FEC element can be informally represented as		The resulting FEC element can be informally represented as
	<root=ASBR1, opaque_value=<root=PE2, RD, opaque_value=Q>>.		<root=ASBR1, opaque_value=<root=PE2, RD, opaque_value=Q>>.
	PE1 can now begin setting up the LSP by using this FEC element in an		PE1 can now begin setting up the LSP by using this FEC element in an
	LDP label mapping message sent towards ASBR1.		LDP label mapping message sent towards ASBR1.
	When ASBR1 receives, over a non-VRF interface, an mLDP label mapping		When ASBR1 receives, over a non-VRF interface, an mLDP label mapping
	message containing this FEC element, it sees that it is the root, and		message containing this FEC element, it sees that it is the root, and
	that the opaque value is a VPN-Recursive (type 7) FEC element. It		that the opaque value is a VPN-Recursive Opaque Value. It parses the
	parses the VPN-Recursive FEC element and extracts the root value,		VPN-Recursive Opaque value and extracts the root value, PE2.
	PE2.
	If ASBR1 has a route to PE2, it continues setting up the LSP by using		If ASBR1 has a route to PE2, it continues setting up the LSP by using
	the following FEC element:		the following FEC element:
	<root=PE2, opaque_value=Q>		<root=PE2, opaque_value=Q>
	However, if ASBR1 does not have a route to PE2, it looks for an		However, if ASBR1 does not have a route to PE2, it looks for an
	Intra-AS I-PMSI A-D route whose NLRI contains PE2's address along		Intra-AS I-PMSI A-D route whose NLRI contains PE2's address along
	with the specified RD value. Say the BGP next hop of that route is		with the specified RD value. Say the BGP next hop of that route is
	ASBR2. Then ASBR1 continues setting up the LSP by using the		ASBR2. Then ASBR1 continues setting up the LSP by using the
	skipping to change at page 9, line 41		skipping to change at page 9, line 40
	refer to this FEC element as "CE1-FEC". However, PE1's route to R		refer to this FEC element as "CE1-FEC". However, PE1's route to R
	will be in a VRF ("Virtual Routing and Forwarding Table"). Therefore		will be in a VRF ("Virtual Routing and Forwarding Table"). Therefore
	the FEC-element created by PE1 must contain some identifier that PE2		the FEC-element created by PE1 must contain some identifier that PE2
	can use to find the proper VRF in which to look up the address of R.		can use to find the proper VRF in which to look up the address of R.
	When PE1 looks up the address of R in a VRF, it will find a route in		When PE1 looks up the address of R in a VRF, it will find a route in
	the VPN-IP address family. The next hop will be PE2, but there will		the VPN-IP address family. The next hop will be PE2, but there will
	also be a Route Distinguisher (RD) as part of that NLRI of the		also be a Route Distinguisher (RD) as part of that NLRI of the
	matching route. In this case, the new FEC element created by PE1		matching route. In this case, the new FEC element created by PE1
	MUST have the address of PE2 as the root node address, and MUST have		MUST have the address of PE2 as the root node address, and MUST have
	a VPN-Recursive (type 7) opaque value. The value field of the type 7		a VPN-Recursive Opaque Value. The value field of the VPN-Recursive
	opaque value MUST consist of the 8-octet RD followed by CE1-FEC.		Opaque Value MUST consist of the 8-octet RD followed by CE1-FEC.
	As far as the interior routers are concerned, they are being		As far as the interior routers are concerned, they are being
	requested to build a MP LSP whose root node is PE2. They MUST NOT		requested to build a MP LSP whose root node is PE2. They MUST NOT
	interpret the opaque value at all.		interpret the opaque value at all.
	When an mLDP label mapping message containing PE2-FEC arrives at PE2		When an mLDP label mapping message containing PE2-FEC arrives at PE2
	over a VRF interface, PE2 notes that it is the identified root node,		over a VRF interface, PE2 notes that it is the identified root node,
	and that the opaque value is a VPN-recursive (type 7) opaque value.		and that the opaque value is a VPN-Recursive Opaque Value. Therefore
	Therefore it MUST replace PE2-FEC with the contents of the VPN-		it MUST replace PE2-FEC with the contents of the VPN-Recursive Opaque
	recursive opaque value (i.e., with CE1-FEC) before doing any further		Value (i.e., with CE1-FEC) before doing any further processing. It
	processing. It uses the VRF to lookup up the path to R. This will		uses the VRF to lookup up the path to R. This will result in CE1-FEC
	result in CE1-FEC being sent on to CE2, and presumably further from		being sent on to CE2, and presumably further from CE2 to R.
	CE2 to R.
	In this scenario, the RD in the VPN-Recursive Opaque Value also		In this scenario, the RD in the VPN-Recursive Opaque Value also
	ensures uniqueness of the FEC Element within the inner carrier's		ensures uniqueness of the FEC Element within the inner carrier's
	network.		network.
	This way of providing Carrier's Carrier service has limited		This way of providing Carrier's Carrier service has limited
	applicability, as it only works under the following conditions:		applicability, as it only works under the following conditions:
	- Both the inner carrier and the outer carrier are using		- Both the inner carrier and the outer carrier are using
	unsegmented mLDP P-tunnels		unsegmented mLDP P-tunnels
	skipping to change at page 10, line 31		skipping to change at page 10, line 29
	- The inner carrier is not aggregating the P-tunnels of the outer		- The inner carrier is not aggregating the P-tunnels of the outer
	carrier, but is content to carry each such P-tunnel in a single		carrier, but is content to carry each such P-tunnel in a single
	P-tunnel of its own.		P-tunnel of its own.
	The carrier's carrier scenario can be distinguished from the inter-AS		The carrier's carrier scenario can be distinguished from the inter-AS
	scenario by the fact that in the former, the mLDP messages are being		scenario by the fact that in the former, the mLDP messages are being
	exchanged on VRF interfaces.		exchanged on VRF interfaces.
	4. IANA Considerations		4. IANA Considerations
	[MLDP] defines a registry for "The LDP MP Opaque Value Element Type".		[mLDP] defines a registry for "The LDP MP Opaque Value Element Basic
	This document requires the assignment of two new code points in this		Type". This document requires the assignment of two new code points
	registry:		in this registry:
	- Type 6.		- Recursive Opaque Value: Type TBD (requested value: 6)
	An opaque value of this type is itself a TLV that encodes an mLDP		An opaque value of this type is itself a TLV that encodes an mLDP
	FEC type, as defined in [MLDP].		FEC type, as defined in [mLDP].
	- Type 7		- VPN-Recursive Opaque Value: Type TBD (requested value: 7)
	An opaque value of this type consists of an eight-octet Route		An opaque value of this type consists of an eight-octet Route
	Distinguisher as defined in [VPN], followed by a TLV that encodes		Distinguisher as defined in [VPN], followed by a TLV that encodes
	an mLDP FEC type, as defined in [MLDP].		an mLDP FEC type, as defined in [mLDP].
	5. Security Considerations		5. Security Considerations
	TBD		The security considerations of [LDP] and [mLDP] apply.
			Unauthorized modification of the FEC elements defined in this
			document can disrupt the creation of the multipoint LSPs, or can
			cause he multipoint LSPs to pass through parts of the network where
			they are not supposed to go. This could potentially be used as part
			of an attack to illegitimately insert or intercept multicast traffic.
			However, since the FEC elements defined in this document are not
			inherently more vulnerable to this form of attack than are the
			previously defined FEC elements, this document does not add new
			security vulnerabilities.
	6. Acknowledgments		6. Acknowledgments
	The authors wish to thank Toerless Eckert for his contribution to		The authors wish to thank Toerless Eckert for his contribution to
	this work.		this work.
	7. Authors' Addresses		7. Authors' Addresses
	IJsbrand Wijnands		IJsbrand Wijnands
	Cisco Systems, Inc.		Cisco Systems, Inc.
	skipping to change at page 11, line 32		skipping to change at page 12, line 4
	Eric C. Rosen		Eric C. Rosen
	Cisco Systems, Inc.		Cisco Systems, Inc.
	1414 Massachusetts Avenue		1414 Massachusetts Avenue
	Boxborough, MA, 01719		Boxborough, MA, 01719
	E-mail: erosen@cisco.com		E-mail: erosen@cisco.com
	Maria Napierala		Maria Napierala
	AT&T Labs		AT&T Labs
	200 Laurel Avenue, Middletown, NJ 07748		200 Laurel Avenue, Middletown, NJ 07748
	E-mail: mnapierala@att.com		E-mail: mnapierala@att.com
	Nicolai Leymann		Nicolai Leymann
	Deutsche Telekom		Deutsche Telekom
	Winterfeldtstrasse 21		Winterfeldtstrasse 21
	Berlin 10781		Berlin 10781
	Germany		Germany
	E-mail: n.leymann@telekom.de		E-mail: n.leymann@telekom.de
	8. Normative References		8. Normative References
	[MLDP] "Label Distribution Protocol Extensions for Point-to-		[LDP] "LDP Specification", RFC 5036, Andersson, Minei, Thomas,
			October 2007
			[mLDP] "Label Distribution Protocol Extensions for Point-to-
	Multipoint and Multipoint-to-Multipoint Label Switched Paths", Minei,		Multipoint and Multipoint-to-Multipoint Label Switched Paths", Minei,
	Kompella, Wijnands, Thomas, draft-ietf-mpls-ldp-p2mp-12.txt, February		Kompella, Wijnands, Thomas, draft-ietf-mpls-ldp-p2mp-12.txt, February
	2011		2011
	[MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al.,		[MVPN] "Multicast in MPLS/BGP IP VPNs", Rosen, Aggarwal, et. al.,
	draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2009		draft-ietf-l3vpn-2547bis-mcast-10.txt, January 2009
	[RFC2119] "Key words for use in RFCs to Indicate Requirement		[RFC2119] "Key words for use in RFCs to Indicate Requirement
	Levels.", Bradner, March 1997		Levels.", Bradner, March 1997
End of changes. 39 change blocks.
	75 lines changed or deleted		89 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/