draft-ietf-mpls-seamless-mcast-13.txt		draft-ietf-mpls-seamless-mcast-14.txt
	skipping to change at page 1, line 21		skipping to change at page 1, line 21
	I. Grosclaude		I. Grosclaude
	France Telecom		France Telecom
	N. Leymann		N. Leymann
	Deutsche Telekom AG		Deutsche Telekom AG
	S. Saad		S. Saad
	AT&T		AT&T
	June 10 2014		June 30 2014
	Inter-Area P2MP Segmented LSPs		Inter-Area P2MP Segmented LSPs
	draft-ietf-mpls-seamless-mcast-13.txt		draft-ietf-mpls-seamless-mcast-14.txt
	Abstract		Abstract
	This document describes procedures for building inter-area point-to-		This document describes procedures for building inter-area point-to-
	multipoint (P2MP) segmented service LSPs by partitioning such LSPs		multipoint (P2MP) segmented service LSPs by partitioning such LSPs
	into intra-area segments and using BGP as the inter-area routing and		into intra-area segments and using BGP as the inter-area routing and
	label distribution protocol. Within each IGP area the intra-area		label distribution protocol. Within each IGP area the intra-area
	segments are either carried over intra-area P2MP LSPs, using P2MP LSP		segments are either carried over intra-area P2MP LSPs, using P2MP LSP
	hierarchy, or instantiated using ingress replication. The intra-area		hierarchy, or instantiated using ingress replication. The intra-area
	P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress		P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress
	skipping to change at page 6, line 52		skipping to change at page 6, line 52
	achieved using downstream-assigned labels alone.		achieved using downstream-assigned labels alone.
	The ingress area segment of a P2MP service LSP is rooted at a PE (or		The ingress area segment of a P2MP service LSP is rooted at a PE (or
	at an ASBR in the case where the P2MP service LSP spans multiple		at an ASBR in the case where the P2MP service LSP spans multiple
	ASes). The leaves of this segment are other PEs/ASBRs and ABRs in the		ASes). The leaves of this segment are other PEs/ASBRs and ABRs in the
	same area as the root PE.		same area as the root PE.
	The backbone area segment is rooted at an ABR that is connected to		The backbone area segment is rooted at an ABR that is connected to
	the ingress area (ingress ABR), or at an ASBR if the ASBR is present		the ingress area (ingress ABR), or at an ASBR if the ASBR is present
	in the backbone area, or at a PE if the PE is present in the backbone		in the backbone area, or at a PE if the PE is present in the backbone
	area. The backbone area segment has as its leaves ABRs that are		area. The backbone area segment has its leaves ABRs that are
	connected to the egress area(s) or PEs in the backbone area, or ASBRs		connected to the egress area(s) or PEs in the backbone area, or ASBRs
	in the backbone area.		in the backbone area.
	The egress area segment is rooted at an ABR in the egress area		The egress area segment is rooted at an ABR in the egress area
	(egress ABR), and has as its leaves PEs and ASBR in that egress area		(egress ABR), and has its leaves PEs and ASBR in that egress area
	(the latter covers the case where the P2MP service LSP spans multiple		(the latter covers the case where the P2MP service LSP spans multiple
	ASes). Note that for a given P2MP service LSP there may be more than		ASes). Note that for a given P2MP service LSP there may be more than
	one backbone segment, each rooted at its own ingress ABR, and more		one backbone segment, each rooted at its own ingress ABR, and more
	than one egress area segment, each rooted at its own egress ABR.		than one egress area segment, each rooted at its own egress ABR.
	This document uses the term "A-D routes" for "auto-discovery routes".		This document uses the term "A-D routes" for "auto-discovery routes".
	An implementation that supports this document MUST implement the		An implementation that supports this document MUST implement the
	procedures described in the following sections to support inter-area		procedures described in the following sections to support inter-area
	point-to-multipoint (P2MP) segmented service LSPs.		point-to-multipoint (P2MP) segmented service LSPs.
	skipping to change at page 17, line 26		skipping to change at page 17, line 26
	segment then the Leaf A-D route MUST carry a downstream assigned		segment then the Leaf A-D route MUST carry a downstream assigned
	label in the P-Tunnel Attribute where the P-Tunnel type is set to		label in the P-Tunnel Attribute where the P-Tunnel type is set to
	Ingress Replication. A PE MUST assign a distinct MPLS label for each		Ingress Replication. A PE MUST assign a distinct MPLS label for each
	Leaf A-D route originated by the PE.		Leaf A-D route originated by the PE.
	To constrain distribution of this route, the originating PE		To constrain distribution of this route, the originating PE
	constructs an IP-based Route Target community by placing the IP		constructs an IP-based Route Target community by placing the IP
	address of the upstream node in the Global Administrator field of the		address of the upstream node in the Global Administrator field of the
	community, with the Local Administrator field of this community set		community, with the Local Administrator field of this community set
	to 0. The originating PE then adds this Route Target Extended		to 0. The originating PE then adds this Route Target Extended
	Community to this Leaf A-D route. The upstream node's address is as		Community to this Leaf A-D route. The upstream node's address is
	determined in section 6.1 ("Determining the Upstream ABR/PE/ASBR		determined as specified in section 6.1 ("Determining the Upstream
	(Upstream Node)").		ABR/PE/ASBR (Upstream Node)").
	The PE then advertises this route to the upstream node.		The PE then advertises this route to the upstream node.
	6.3. PIM-SM in ASM mode for Global Table Multicast		6.3. PIM-SM in ASM mode for Global Table Multicast
	This specification allows two options for supporting global table		This specification allows two options for supporting global table
	multicast with PIM-SM in ASM mode. The first option does not transit		multicast with PIM-SM in ASM mode. The first option does not transit
	IP multicast shared trees over the MPLS network. The second option		IP multicast shared trees over the MPLS network. The second option
	does transit shared trees over the MPLS network and relies on shared		does transit shared trees over the MPLS network and relies on shared
	tree to source tree switchover.		tree to source tree switchover.
	skipping to change at page 18, line 10		skipping to change at page 18, line 10
	network. Therefore, when an (egress) PE creates (*, G) state (as a		network. Therefore, when an (egress) PE creates (*, G) state (as a
	result of receiving PIM or IGMP messages on one of its IP multicast		result of receiving PIM or IGMP messages on one of its IP multicast
	interfaces), the PE does not propagate this state using Leaf A-D		interfaces), the PE does not propagate this state using Leaf A-D
	routes.		routes.
	6.3.1.1. Originating Source Active A-D Routes		6.3.1.1. Originating Source Active A-D Routes
	Whenever as a result of receiving PIM Register or MSDP messages an RP		Whenever as a result of receiving PIM Register or MSDP messages an RP
	that is co-located with a PE discovers a new multicast source, the		that is co-located with a PE discovers a new multicast source, the
	RP/PE SHOULD originate a BGP Source Active A-D route. Similarly		RP/PE SHOULD originate a BGP Source Active A-D route. Similarly
	whenever as a result of receiving MSDP messages a PE, that is not		whenever as a result of receiving MSDP messages, a PE that is not
	configured as a RP, discovers a new multicast source the PE SHOULD		configured as a RP, discovers a new multicast source the PE SHOULD
	originate a BGP Source Active A-D route. The BGP Source Active A-D		originate a BGP Source Active A-D route. The BGP Source Active A-D
	route carries a single MCAST-VPN NLRI constructed as follows:		route carries a single MCAST-VPN NLRI constructed as follows:
	+ The RD in this NLRI is set to 0.		+ The RD in this NLRI is set to 0.
	+ The Multicast Source field MUST be set to S. The Multicast		+ The Multicast Source field MUST be set to S. The Multicast
	Source Length field is set appropriately to reflect this.		Source Length field is set appropriately to reflect this.
	+ The Multicast Group field MUST be set to G. The Multicast		+ The Multicast Group field MUST be set to G. The Multicast
	skipping to change at page 18, line 42		skipping to change at page 18, line 42
	Using the normal BGP procedures the Source Active A-D route is		Using the normal BGP procedures the Source Active A-D route is
	propagated to all other PEs within the AS.		propagated to all other PEs within the AS.
	Whenever the RP/PE discovers that the source is no longer active, the		Whenever the RP/PE discovers that the source is no longer active, the
	RP MUST withdraw the Source Active A-D route, if such a route was		RP MUST withdraw the Source Active A-D route, if such a route was
	previously advertised by the RP.		previously advertised by the RP.
	6.3.1.2. Receiving BGP Source Active A-D Route by PE		6.3.1.2. Receiving BGP Source Active A-D Route by PE
	When as a result of receiving PIM or IGMP messages on one of its IP		When as a result of receiving PIM or IGMP messages on one of its IP
	multicast interfaces an (egress) PE creates in its Tree Information		multicast interfaces an egress PE creates in its Tree Information
	Base (TIB) a new (*, G) entry with a non-empty outgoing interface		Base (TIB) a new (*, G) entry with a non-empty outgoing interface
	list that contains one or more IP multicast interfaces, the PE MUST		list that contains one or more IP multicast interfaces, the PE MUST
	check if it has any Source Active A-D routes for that G. If there is		check if it has any Source Active A-D routes for that G. If there is
	such a route, S of that route is reachable via an MPLS interface, and		such a route, S of that route is reachable via an MPLS interface, and
	the PE does not have (S, G) state in its TIB for (S, G) carried in		the PE does not have (S, G) state in its TIB for (S, G) carried in
	the route, then the PE originates a Leaf A-D route carrying that (S,		the route, then the PE originates a Leaf A-D route carrying that (S,
	G), as specified in section 6.2.2 ("Leaf A-D Route for Global Table		G), as specified in section 6.2.2 ("Leaf A-D Route for Global Table
	Multicast").		Multicast").
	When an (egress) PE receives a new Source Active A-D route, the PE		When an egress PE receives a new Source Active A-D route, the PE MUST
	MUST check if its TIB contains an (*, G) entry with the same G as		check if its TIB contains an (*, G) entry with the same G as carried
	carried in the Source Active A-D route. If such an entry is found, S		in the Source Active A-D route. If such an entry is found, S is
	is reachable via an MPLS interface, and the PE does not have (S, G)		reachable via an MPLS interface, and the PE does not have (S, G)
	state in its TIB for (S, G) carried in the route, then the PE		state in its TIB for (S, G) carried in the route, then the PE
	originates a Leaf A-D route carrying that (S, G), as specified in		originates a Leaf A-D route carrying that (S, G), as specified in
	section 6.2.2 ("Leaf A-D Route for Global Table Multicast").		section 6.2.2 ("Leaf A-D Route for Global Table Multicast").
	6.3.1.3. Handling (S, G, rpt) state		6.3.1.3. Handling (S, G, rpt) state
	Creation and deletion of (S, G, rpt) state on a PE that resulted from		Creation and deletion of (S, G, rpt) state on a PE that resulted from
	receiving PIM messages on one of its IP multicast interfaces does not		receiving PIM messages on one of its IP multicast interfaces does not
	result in any BGP actions by the PE.		result in any BGP actions by the PE.
	6.3.2. Option 2		6.3.2. Option 2
	This option does transit IP multicast shared trees over the MPLS		This option does transit IP multicast shared trees over the MPLS
	network. Therefore, when an (egress) PE creates (*, G) state (as a		network. Therefore, when an egress PE creates (*, G) state (as a
	result of receiving PIM or IGMP messages on one of its IP multicast		result of receiving PIM or IGMP messages on one of its IP multicast
	interfaces), the PE does propagate this state using Leaf A-D routes.		interfaces), the PE does propagate this state using Leaf A-D routes.
	6.3.2.1. Originating Source Active A-D Routes		6.3.2.1. Originating Source Active A-D Routes
	Whenever a PE creates an (S, G) state as a result of receiving Leaf		Whenever a PE creates an (S, G) state as a result of receiving Leaf
	A-D routes associated with the global table multicast service, if S		A-D routes associated with the global table multicast service, if S
	is reachable via one of the IP multicast capable interfaces, and the		is reachable via one of the IP multicast capable interfaces, and the
	PE determines that G is in the PIM-SM in ASM mode range, the PE MUST		PE determines that G is in the PIM-SM in ASM mode range, the PE MUST
	originate a BGP Source Active A-D route. The route carries a single		originate a BGP Source Active A-D route. The route carries a single
	skipping to change at page 25, line 32		skipping to change at page 25, line 32
	advertising ABR, and the Local Administrator field set to 0. PEs in		advertising ABR, and the Local Administrator field set to 0. PEs in
	the egress area that participate in the global table multicast will		the egress area that participate in the global table multicast will
	import this route.		import this route.
	A PE in the egress area SHOULD join the P2MP LSP advertised in the		A PE in the egress area SHOULD join the P2MP LSP advertised in the
	PMSI Tunnel attribute of the wildcard S-PMSI A-D route if (a) the		PMSI Tunnel attribute of the wildcard S-PMSI A-D route if (a) the
	Originating Router's IP Address field in the S-PMSI A-D route has the		Originating Router's IP Address field in the S-PMSI A-D route has the
	same value as the Ingress PE's IP address in at least one of the Leaf		same value as the Ingress PE's IP address in at least one of the Leaf
	A-D routes for global table multicast originated by the PE, and (b)		A-D routes for global table multicast originated by the PE, and (b)
	the upstream ABR for the Ingress PE's IP address in that Leaf A-D		the upstream ABR for the Ingress PE's IP address in that Leaf A-D
	route is the (egress) ABR that advertises the wildcard S-PMSI A-D		route is the egress ABR that advertises the wildcard S-PMSI A-D
	route.		route.
	7.2.3. Global Table Multicast and the Expected Upstream Node		7.2.3. Global Table Multicast and the Expected Upstream Node
	If the mapping between the inter-area P2MP service LSP for global		If the mapping between the inter-area P2MP service LSP for global
	table multicast service and the intra-area P2MP LSP is many-to-one		table multicast service and the intra-area P2MP LSP is many-to-one
	then an egress PE must be able to determine whether a given multicast		then an egress PE must be able to determine whether a given multicast
	packet for a particular (S, G) is received from the "expected"		packet for a particular (S, G) is received from the "expected"
	upstream node. The expected node is the node towards which the Leaf		upstream node. The expected node is the node towards which the Leaf
	A-D route is sent by the egress PE. Packets received from another		A-D route is sent by the egress PE. Packets received from another
	skipping to change at page 33, line 10		skipping to change at page 33, line 10
	the label stack to include identification of the sender upstream		the label stack to include identification of the sender upstream
	node. When P2MP LSPs are used this requires that PHP MUST be turned		node. When P2MP LSPs are used this requires that PHP MUST be turned
	off. When Ingress Replication is used the egress PE knows the		off. When Ingress Replication is used the egress PE knows the
	incoming downstream assigned label to which it has bound a particular		incoming downstream assigned label to which it has bound a particular
	(S/*, G) and must accept packets with only that label for that (S/*,		(S/*, G) and must accept packets with only that label for that (S/*,
	G).		G).
	13.3. Data Plane Procedures on Ingress PEs		13.3. Data Plane Procedures on Ingress PEs
	An Ingress PE must perform application specific forwarding procedures		An Ingress PE must perform application specific forwarding procedures
	to identify the outgoing inta-area segment of an incoming packet.		to identify the outgoing intra-area segment of an incoming packet.
	If the outgoing intra-area segment is instantiated using a P2MP LSP,		If the outgoing intra-area segment is instantiated using a P2MP LSP,
	and if there is a one-to-one mapping between the outgoing intra-area		and if there is a one-to-one mapping between the outgoing intra-area
	segment and the P2MP LSP, then the ingress PE MUST encapsulate the		segment and the P2MP LSP, then the ingress PE MUST encapsulate the
	packet in the label stack of the outgoing P2MP LSP. If there is a		packet in the label stack of the outgoing P2MP LSP. If there is a
	many-to-one mapping between outgoing intra-area segments and the P2MP		many-to-one mapping between outgoing intra-area segments and the P2MP
	LSP then the PE MUST first push the upstream assigned label		LSP then the PE MUST first push the upstream assigned label
	corresponding to the outgoing intra-area segment, if such a label has		corresponding to the outgoing intra-area segment, if such a label has
	been assigned, and then push the label stack of the outgoing P2MP		been assigned, and then push the label stack of the outgoing P2MP
	LSP.		LSP.
	skipping to change at page 39, line 9		skipping to change at page 39, line 9
	state on ABRs, it would also result in bandwidth inefficiency, as (C-		state on ABRs, it would also result in bandwidth inefficiency, as (C-
	S1, C-G1) will be delivered not just to PE2, PE3, and PE4, but also		S1, C-G1) will be delivered not just to PE2, PE3, and PE4, but also
	to PE5, which has no receivers for this stream. Likewise, (C-S2, C-		to PE5, which has no receivers for this stream. Likewise, (C-S2, C-
	G2) will be delivered not just to PE3, PE4, and PE5, but also to PE2,		G2) will be delivered not just to PE3, PE4, and PE5, but also to PE2,
	which has no receivers for this stream.		which has no receivers for this stream.
	15. IANA Considerations		15. IANA Considerations
	This document defines a new BGP Extended Community called "Inter-area		This document defines a new BGP Extended Community called "Inter-area
	P2MP Segmented Next-Hop" (see section "Inter-area P2MP Segmented		P2MP Segmented Next-Hop" (see section "Inter-area P2MP Segmented
	Next-Hop Extended Community"). This community is IP Address Specific,		Next-Hop Extended Community"). This may be either a Transitive
	of an extended type, and is transitive. A codepoint for this		IPv4-Address-Specific Extended Community or a Transitive
	community has been assigned both from the IPv4 Address Specific		IPv6-Address-Specific Extended Community. IANA has assigned the
	Extended Community registry, and from the IPv6 Address Specific		value 0x12 in the Transitive IPv4-Address-Specific Extended Community
	Extended Community registry. IANA is requested to change in these		Sub-Types registry, and IANA has assigned the value 0x0012 in the
	registries the reference to the RFC number as soon as this document		Transitive IPv6-Address-Specific Extended Community Types registry.
	is published as an RFC.		This document is the reference for both codepoints. IANA is
			requested to change in these registries the reference to the RFC
			number as soon as this document is published as an RFC.
	This document also assigns a new Tunnel Type in the PMSI Tunnel		IANA is requested to assign a value from the PMSI Tunnel Types
	Attribute, called the "Transport Tunnel" (see section "Transport		registry [pmsi-registry] for "Transport Tunnel" (see section
	Tunnel Type"). This Tunnel Type is assigned a value of 8.		"Transport Tunnel Type"). The value 0x08 is requested.
	16. Security Considerations		16. Security Considerations
	Procedures described in this document are subject to similar security		Procedures described in this document are subject to similar security
	threats as any MPLS deployment. It is recommended that baseline		threats as any MPLS deployment. It is recommended that baseline
	security measures are considered as described in Security Framework		security measures are considered as described in Security Framework
	for MPLS and GMPLS networks [RFC5920], in the mLDP specification		for MPLS and GMPLS networks [RFC5920], in the mLDP specification
	[RFC6388] and in P2MP RSVP-TE specification [RFC3209].		[RFC6388] and in P2MP RSVP-TE specification [RFC3209].
	17. Acknowledgements		17. Acknowledgements
	We would like to thank Eric Rosen for his comments. We also would		We would like to thank Eric Rosen for his comments. We also would
	like to thank Loa Andersson for his review and comments.		like to thank Loa Andersson and Qin Wu for their review and comments.
	18. References		18. References
	18.1. Normative References		18.1. Normative References
	[RFC1997] "BGP Communities Attribute", Ravi Chandra, et al., RFC		[RFC1997] "BGP Communities Attribute", Ravi Chandra, et al., RFC
	1997, August 1996		1997, August 1996
	[RFC2119] "Key words for use in RFCs to Indicate Requirement		[RFC2119] "Key words for use in RFCs to Indicate Requirement
	Levels.", Bradner, RFC 2119, March 1997		Levels.", Bradner, RFC 2119, March 1997
	skipping to change at page 41, line 11		skipping to change at page 41, line 13
	Multipoint and Multipoint-to-Multipoint Label Switched Paths",		Multipoint and Multipoint-to-Multipoint Label Switched Paths",
	Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, RFC		Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, RFC
	6388, November 2011		6388, November 2011
	[RFC6625] "Wildcards in Multicast VPN Auto-Discovery Routes", Eric		[RFC6625] "Wildcards in Multicast VPN Auto-Discovery Routes", Eric
	Rosen, et al., RFC 6625, May 2012		Rosen, et al., RFC 6625, May 2012
	[RFC7117] "Multicast in VPLS", R. Aggarwal, Y. Kamite, L. Fang, RFC		[RFC7117] "Multicast in VPLS", R. Aggarwal, Y. Kamite, L. Fang, RFC
	7117, February 2014		7117, February 2014
			[pmsi-registry] L. Andersson, et al., "IANA registry for PMSI Tunnel
			Type code points", draft-ietf-l3vpn-pmsi-registry, work in progress
	18.2. Informative References		18.2. Informative References
	[SEAMLESS-MPLS] "Seamless MPLS Architecture", N. Leymann et. al.,		[SEAMLESS-MPLS] "Seamless MPLS Architecture", N. Leymann et. al.,
	draft-ietf-mpls-seamless-mpls, work in progress		draft-ietf-mpls-seamless-mpls, work in progress
	[RFC5920] "Security Framework for MPLS and GMPLS Networks", L. Fang,		[RFC5920] "Security Framework for MPLS and GMPLS Networks", L. Fang,
	et al., RFC 5920, July 2010		et al., RFC 5920, July 2010
	[RFC7024] "Virtual Hub-and-Spoke in BGP/MPLS VPNs", Huajin Jeng et.		[RFC7024] "Virtual Hub-and-Spoke in BGP/MPLS VPNs", Huajin Jeng et.
	al., RFC 7024, October 2013		al., RFC 7024, October 2013
End of changes. 15 change blocks.
	27 lines changed or deleted		32 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/