draft-ietf-mpls-mldp-recurs-fec-02.txt		draft-ietf-mpls-mldp-recurs-fec-03.txt
	MPLS 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: November 9, 2011		Expires: December 23, 2011
	Maria Napierala		Maria Napierala
	AT&T		AT&T
	Nicolai Leymann		Nicolai Leymann
	Deutsche Telekom		Deutsche Telekom
	May 9, 2011		June 23, 2011
	Using Multipoint LDP when the Backbone has no Route to the Root		Using Multipoint LDP when the Backbone has no Route to the Root
	draft-ietf-mpls-mldp-recurs-fec-02.txt		draft-ietf-mpls-mldp-recurs-fec-03.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
	skipping to change at page 3, line 4		skipping to change at page 2, line 41
	3 The VPN-Recursive Opaque Value ........................ 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
			9 Informative References ................................ 12
	1. Introduction		1. Introduction
	[mLDP] defines several LDP "Forwarding Equivalence Class" (FEC)		The document [mLDP] extends LDP ("Label Distribution Protocol",
	element encodings: Point-to-Multipoint (P2MP), Multipoint-to-		[LDP]) to support multipoint label-switched paths. These extensions
	Multipoint (MP2MP) Upstream, and MP2MP Downstream.		are known as "Multipoint LDP", or more simply as "mLDP". [mLDP]
			defines several LDP "Forwarding Equivalence Class" (FEC) 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, as defined in [mLDP], 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 | . |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
	skipping to change at page 3, line 40		skipping to change at page 3, line 44
	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
	where CE1 and CE2 are "customer edge routers", PE1 and PE2 are		In Figure 2, CE1 and CE2 are "customer edge routers", R is a customer
	"provider edge routers", but the provider's core is "BGP-free". That		router at the same VPN site as CE2, PE1 and PE2 are "provider edge
	is, PE1 has a BGP-learned route for R, in which PE2 is the BGP next		routers". Suppose that the provider's core is "BGP-free". That is,
	hop. However, the provider's interior routers (such as P1 and P2) do		PE1 has a BGP-learned route for R, in which PE2 is the BGP next hop.
	not have any BGP-learned routes, and in particular do not have any		However, the provider's interior routers (such as P1 and P2) do not
	routes to R.		have any BGP-learned routes, and in particular do not have any routes
			to R.
	In such an environment, data packets from CE1 address to R would get		In such an environment, unicast data packets from CE1 addressed to R
	encapsulated by PE1, tunneled to PE2, decapsulated by PE2, and		would get encapsulated by PE1, tunneled to PE2, decapsulated by PE2,
	forwarded to CE2.		and 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
	skipping to change at page 6, line 5		skipping to change at page 6, line 10
	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 creates a new MP FEC element, whose root node address
	address is the address of PE2, and whose opaque value is a Recursive		is the address of PE2, and whose opaque value is a Recursive Opaque
	Opaque Value whose value field contains CE1-FEC. We refer to this		Value whose value field contains CE1-FEC. We refer to this FEC
	FEC element as PE2-FEC. PE1 then MUST send this FEC element to P1.		element as PE2-FEC:
	PE2-FEC = <root=PE2, opaque_value=CE1-FEC>, or		PE2-FEC = <root=PE2, opaque_value=CE1-FEC>, i.e.,
	PE2-FEC = <root=PE2, opaque_value=<root=R,		PE2-FEC = <root=PE2, opaque_value=<root=R,
	opaque_value=Q>>		opaque_value=Q>>
			PE1 then sends this FEC element to P1.
	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 (PE2) is the		When PE2-FEC arrives at PE2, PE2 notes that it (PE2) is the
	identified root node, and that the opaque value is a Recursive Opaque		identified root node, and that the opaque value is a Recursive Opaque
	Value. Therefore PE2 MUST replace PE2-FEC with the contents of the		Value. Therefore PE2 MUST replace PE2-FEC with the contents of the
	Recursive 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		further from CE2 to R. Note that CE1-FEC will contain the LSP root
	LSP root node specified by CE1; the presumption is that PE2 has a		node specified by CE1; the presumption is that PE2 has a route to
	route to this root node.		this root node.
	3. The VPN-Recursive Opaque Value		3. The VPN-Recursive Opaque Value
	3.1. Encoding		3.1. Encoding
	We define a new type of Opaque Value, the VPN-Recursive Opaque Value.		We define a new type of Opaque Value, the VPN-Recursive Opaque Value.
	This is a "basic type", identified by a one-octet type field.		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
	skipping to change at page 7, line 21		skipping to change at page 7, line 21
	| Route Distinguisher (8 octets) +-+-+-+-+-+-+-+-+		| Route Distinguisher (8 octets) +-+-+-+-+-+-+-+-+
	| | |		| | |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
	~ ~		~ ~
	| P2MP or MP2MP FEC Element |		| P2MP or MP2MP FEC Element |
	| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	VPN-Recursive Opaque Value		VPN-Recursive Opaque Value
	Figure 3		Figure 4
	The value field of the "VPN-Recursive Opaque Value" consists of an		The value field of the "VPN-Recursive Opaque Value" consists of an
	eight-octet Route Distinguisher (RD), followed by a P2MP or MP2MP FEC		eight-octet Route Distinguisher (RD), followed by a P2MP or MP2MP FEC
	element, encoded exactly as specified in [mLDP], with a type field, a		element, encoded exactly as specified in [mLDP], with a type field, a
	length field, and value field of is own. The length of the VPN-		length field, and value field of is own. The length of the VPN-
	Recursive Opaque Value thus includes the 8 octets of RD plus the		Recursive Opaque Value thus includes the 8 octets of RD plus the
	lengths of the type, length, and values fields of the contained FEC		lengths of the type, length, and values fields of the contained FEC
	element.		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 5.
	PE1 --- P1 ---- ASBR1 ... ASBR2 ---- P2 ---- PE2		PE1 --- P1 ---- ASBR1 ... ASBR2 ---- P2 ---- PE2
	Figure 4		Figure 5
	Suppose this is an "option B" VPN interconnect ([VPN] section 10).		Suppose this is an "option B" VPN interconnect ([VPN] section 10).
	This means that the Autonomous System Border Router (ASBR) in the		This means that the Autonomous System Border Router (ASBR) in the
	first Autonomous System (i.e., ASBR1) does not have a route to PE		first Autonomous System (i.e., ASBR1) does not have a route to PE
	routers in other ASes (such as PE2). Suppose also that the MVPN		routers in other ASes (such as PE2). Suppose also that the MVPN
	policy is to instantiate PMSIs [MVPN] using mLDP, and that		policy is to instantiate PMSIs [MVPN] using mLDP, and that
	"unsegmented inter-AS P-tunnels" [MVPN] are being used.		"unsegmented inter-AS P-tunnels" [MVPN] are being used.
	In this scenario, PE1 may need to join a P2MP or MP2MP LSP whose root		In this scenario, PE1 may need to join a P2MP or MP2MP LSP whose root
	is PE2. P1 has no route to PE2, and all PE1 knows about the route to		is PE2. P1 has no route to PE2, and all PE1 knows about the route to
	skipping to change at page 9, line 38		skipping to change at page 9, line 38
	Carrier VPN Service" [VPN] to CE1/CE2. CE1 sends PE1 an MP FEC		Carrier VPN Service" [VPN] to CE1/CE2. CE1 sends PE1 an MP FEC
	element whose root node is R, and whose opaque value is Q. We will		element whose root node is R, and whose opaque value is Q. We will
	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 has
	MUST have the address of PE2 as the root node address, and MUST have		the address of PE2 as the root node address, and has a VPN-Recursive
	a VPN-Recursive Opaque Value. The value field of the VPN-Recursive		Opaque Value. The value field of the VPN-Recursive Opaque Value
	Opaque Value MUST consist of the 8-octet RD followed by CE1-FEC.		consists 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 Opaque Value. Therefore		and that the opaque value is a VPN-Recursive Opaque Value. Therefore
	it MUST replace PE2-FEC with the contents of the VPN-Recursive Opaque		it MUST replace PE2-FEC with the contents of the VPN-Recursive Opaque
	Value (i.e., with CE1-FEC) before doing any further processing. It		Value (i.e., with CE1-FEC) before doing any further processing. It
	skipping to change at page 11, line 19		skipping to change at page 11, line 19
	Unauthorized modification of the FEC elements defined in this		Unauthorized modification of the FEC elements defined in this
	document can disrupt the creation of the multipoint LSPs, or can		document can disrupt the creation of the multipoint LSPs, or can
	cause he multipoint LSPs to pass through parts of the network where		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		they are not supposed to go. This could potentially be used as part
	of an attack to illegitimately insert or intercept multicast traffic.		of an attack to illegitimately insert or intercept multicast traffic.
	However, since the FEC elements defined in this document are not		However, since the FEC elements defined in this document are not
	inherently more vulnerable to this form of attack than are the		inherently more vulnerable to this form of attack than are the
	previously defined FEC elements, this document does not add new		previously defined FEC elements, this document does not add new
	security vulnerabilities.		security vulnerabilities.
			A description of general security issues for MPLS can be found in
			[RFC5920].
	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.
	De kleetlaan 6a Diegem 1831		De kleetlaan 6a Diegem 1831
	skipping to change at page 12, line 18		skipping to change at page 12, line 18
	Germany		Germany
	E-mail: n.leymann@telekom.de		E-mail: n.leymann@telekom.de
	8. Normative References		8. Normative References
	[LDP] "LDP Specification", RFC 5036, Andersson, Minei, Thomas,		[LDP] "LDP Specification", RFC 5036, Andersson, Minei, Thomas,
	October 2007		October 2007
	[mLDP] "Label Distribution Protocol Extensions for Point-to-		[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-13.txt, April
	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
	[VPN] "BGP/MPLS IP Virtual Private Networks (VPNs)", Rosen, Rekhter,		[VPN] "BGP/MPLS IP Virtual Private Networks (VPNs)", Rosen, Rekhter,
	RFC 4364, February 2006		RFC 4364, February 2006
			9. Informative References
			[RFC5920] "Security Framework for MPLS and GMPLS Networks", L. Fang,
			RFC 5920, July 2010
End of changes. 20 change blocks.
	33 lines changed or deleted		44 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/