< draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-00.txt		draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01.txt >
	Network Working Group IJ. Wijnands, Ed.		Network Working Group IJ. Wijnands, Ed.
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems
	Intended status: Standards Track P. Hitchen		Intended status: Standards Track P. Hitchen
	Expires: December 31, 2012 BT		Expires: April 20, 2013 BT
	N. Leymann		N. Leymann
	Deutsche Telekom		Deutsche Telekom
	W. Henderickx		W. Henderickx
	Alcatel-Lucent		Alcatel-Lucent
	June 29, 2012		A. Gulko
			Thomson Reuters
			October 17, 2012
	Multipoint Label Distribution Protocol		Multipoint Label Distribution Protocol
	In-Band Signaling in a VRF Context		In-Band Signaling in a VRF Context
	draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-00		draft-wijnands-l3vpn-mldp-vrf-in-band-signaling-01
	Abstract		Abstract
	Sometimes an IP multicast distribution tree (MDT) traverses both		Sometimes an IP multicast distribution tree (MDT) traverses both
	MPLS-enabled and non-MPLS-enabled regions of a network. Typically		MPLS-enabled and non-MPLS-enabled regions of a network. Typically
	the MDT begins and ends in non-MPLS regions, but travels through an		the MDT begins and ends in non-MPLS regions, but travels through an
	MPLS region. In such cases, it can be useful to begin building the		MPLS region. In such cases, it can be useful to begin building the
	MDT as a pure IP MDT, then convert it to an MPLS Multipoint LSP		MDT as a pure IP MDT, then convert it to an MPLS Multipoint LSP
	(Label Switched Path) when it enters an MPLS-enabled region, and then		(Label Switched Path) when it enters an MPLS-enabled region, and then
	convert it back to a pure IP MDT when it enters a non-MPLS-enabled		convert it back to a pure IP MDT when it enters a non-MPLS-enabled
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 6 ¶
	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 December 31, 2012.
			This Internet-Draft will expire on April 20, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 7, line 8 ¶		skipping to change at page 7, line 8 ¶
	to the IP address of the Upstream PE. If, in the context of this		to the IP address of the Upstream PE. If, in the context of this
	VPN, (S,G) refers to a source-specific MDT, then the values of S, G,		VPN, (S,G) refers to a source-specific MDT, then the values of S, G,
	and the upstream RD are encoded into the opaque value. If, in the		and the upstream RD are encoded into the opaque value. If, in the
	context of this VPN, G is a bidirectional group address, then S is		context of this VPN, G is a bidirectional group address, then S is
	replaced with the value of the RPA associated with G. The coding		replaced with the value of the RPA associated with G. The coding
	details are specified in Section 3. Conceptually, the Multipoint FEC		details are specified in Section 3. Conceptually, the Multipoint FEC
	can be thought of as an ordered pair: <root=Upstream-PE,		can be thought of as an ordered pair: <root=Upstream-PE,
	opaque_value=<S or RPA ,G ,Upstream-RD>. The mLDP Label Mapping		opaque_value=<S or RPA ,G ,Upstream-RD>. The mLDP Label Mapping
	Message is then sent by PE1 on its LDP session to the "next hop" on		Message is then sent by PE1 on its LDP session to the "next hop" on
	its path to the upstream PE. The "next hop" is usually the IGP next		its path to the upstream PE. The "next hop" is usually the IGP next
	hop, but see [I-D.napierala-mpls-targeted-mldp] for cases in which		hop, but see [I-D.ietf-mpls-targeted-mldp] for cases in which the
	the next hop is not the IGP next hop.		next hop is not the IGP next hop.
	If the UMH and the upstream PE do not have the same IP address, the		If the UMH and the upstream PE do not have the same IP address, the
	procedures of section 2 of [RFC6512] should be applied. The root		procedures of section 2 of [RFC6512] should be applied. The root
	node of the multipoint FEC is set to the UMH. The recursive opaque		node of the multipoint FEC is set to the UMH. The recursive opaque
	value is then set as follows: the root node is set to the upstream		value is then set as follows: the root node is set to the upstream
	PE, and the opaque value is set to the multipoint FEC described in		PE, and the opaque value is set to the multipoint FEC described in
	the previous paragraph. That is, the multipoint FEC can be thought		the previous paragraph. That is, the multipoint FEC can be thought
	of as the following recursive ordered pair: <root=UMH,		of as the following recursive ordered pair: <root=UMH,
	opaque_value=<root=Upstream-PE, opaque_value =<S or RPA, G,		opaque_value=<root=Upstream-PE, opaque_value =<S or RPA, G,
	Upstream-RD>>.		Upstream-RD>>.
	skipping to change at page 11, line 41 ¶		skipping to change at page 11, line 41 ¶
	Thanks to Eric Rosen, Andy Green and Yakov Rekhter for their comments		Thanks to Eric Rosen, Andy Green and Yakov Rekhter for their comments
	on the draft.		on the draft.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, February 2006.		Networks (VPNs)", RFC 4364, February 2006.
	[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
	"Protocol Independent Multicast - Sparse Mode (PIM-SM):
	Protocol Specification (Revised)", RFC 4601, August 2006.
	[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,		[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
	"Bidirectional Protocol Independent Multicast (BIDIR-		"Bidirectional Protocol Independent Multicast (BIDIR-
	PIM)", RFC 5015, October 2007.		PIM)", RFC 5015, October 2007.
	[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP		[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
	Specification", RFC 5036, October 2007.		Specification", RFC 5036, October 2007.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	skipping to change at page 12, line 29 ¶		skipping to change at page 12, line 26 ¶
	[I-D.ietf-mpls-mldp-in-band-signaling]		[I-D.ietf-mpls-mldp-in-band-signaling]
	Wijnands, I., Eckert, T., Leymann, N., and M. Napierala,		Wijnands, I., Eckert, T., Leymann, N., and M. Napierala,
	"Multipoint LDP in-band signaling for Point-to-Multipoint		"Multipoint LDP in-band signaling for Point-to-Multipoint
	and Multipoint- to-Multipoint Label Switched Paths",		and Multipoint- to-Multipoint Label Switched Paths",
	draft-ietf-mpls-mldp-in-band-signaling-06 (work in		draft-ietf-mpls-mldp-in-band-signaling-06 (work in
	progress), June 2012.		progress), June 2012.
	7.2. Informative References		7.2. Informative References
	[I-D.napierala-mpls-targeted-mldp]		[I-D.ietf-mpls-targeted-mldp]
	Napierala, M. and E. Rosen, "Using LDP Multipoint		Napierala, M. and E. Rosen, "Using LDP Multipoint
	Extensions on Targeted LDP Sessions",		Extensions on Targeted LDP Sessions",
	draft-napierala-mpls-targeted-mldp-03 (work in progress),		draft-ietf-mpls-targeted-mldp-00 (work in progress),
	April 2012.		August 2012.
	[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP		[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
	VPNs", RFC 6513, February 2012.		VPNs", RFC 6513, February 2012.
	[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP		[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
	Encodings and Procedures for Multicast in MPLS/BGP IP		Encodings and Procedures for Multicast in MPLS/BGP IP
	VPNs", RFC 6514, February 2012.		VPNs", RFC 6514, February 2012.
	[RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3
	Provider-Provisioned Virtual Private Networks (PPVPNs)",
	RFC 4834, April 2007.
	Authors' Addresses		Authors' Addresses
	IJsbrand Wijnands (editor)		IJsbrand Wijnands (editor)
	Cisco Systems, Inc.		Cisco Systems
	De kleetlaan 6a		De kleetlaan 6a
	Diegem 1831		Diegem 1831
	Belgium		Belgium
	Email: ice@cisco.com		Email: ice@cisco.com
	Paul Hitchen		Paul Hitchen
	BT		BT
	BT Adastral Park		BT Adastral Park
	Ipswich IP53RE		Ipswich IP53RE
	UK		UK
	Email: paul.hitchen@bt.com		Email: paul.hitchen@bt.com
	Nicolai Leymann		Nicolai Leymann
	Deutsche Telekom		Deutsche Telekom
	skipping to change at line 491 ¶		skipping to change at page 13, line 27 ¶
	Email: n.leymann@telekom.de		Email: n.leymann@telekom.de
	Wim Henderickx		Wim Henderickx
	Alcatel-Lucent		Alcatel-Lucent
	Copernicuslaan 50		Copernicuslaan 50
	Antwerp 2018		Antwerp 2018
	Belgium		Belgium
	Email: wim.henderickx@alcatel-lucent.com		Email: wim.henderickx@alcatel-lucent.com
			Arkadiy Gulko
			Thomson Reuters
			195 Broadway
			New York NY 10007
			USA
			Email: arkadiy.gulko@thomsonreuters.com
End of changes. 13 change blocks.
	20 lines changed or deleted		14 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/