< draft-ietf-bier-mvpn-03.txt		draft-ietf-bier-mvpn-04.txt >
	Internet Engineering Task Force E. Rosen, Ed.		Internet Engineering Task Force E. Rosen, Ed.
	Internet-Draft Juniper Networks, Inc.		Internet-Draft Juniper Networks, Inc.
	Intended status: Standards Track M. Sivakumar		Intended status: Standards Track M. Sivakumar
	Expires: December 22, 2016 Cisco Systems, Inc.		Expires: January 19, 2017 Cisco Systems, Inc.
	S. Aldrin		S. Aldrin
	Google, Inc.		Google, Inc.
	A. Dolganow		A. Dolganow
	Alcatel-Lucent		Nokia
	T. Przygienda		T. Przygienda
	Ericsson		Juniper Networks, Inc.
	June 20, 2016		July 18, 2016
	Multicast VPN Using BIER		Multicast VPN Using BIER
	draft-ietf-bier-mvpn-03		draft-ietf-bier-mvpn-04
	Abstract		Abstract
	The Multicast Virtual Private Network (MVPN) specifications require		The Multicast Virtual Private Network (MVPN) specifications require
	the use of multicast tunnels ("P-tunnels") that traverse a Service		the use of multicast tunnels ("P-tunnels") that traverse a Service
	Provider's backbone network. The P-tunnels are used for carrying		Provider's backbone network. The P-tunnels are used for carrying
	multicast traffic across the backbone. A variety of P-tunnel types		multicast traffic across the backbone. A variety of P-tunnel types
	are supported. Bit Index Explicit Replication (BIER) is a new		are supported. Bit Index Explicit Replication (BIER) is a new
	architecture that provides optimal multicast forwarding through a		architecture that provides optimal multicast forwarding through a
	"multicast domain", without requiring intermediate routers to		"multicast domain", without requiring intermediate routers to
	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 December 22, 2016.		This Internet-Draft will expire on January 19, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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
	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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Use of the PMSI Tunnel Attribute . . . . . . . . . . . . . . 4		2. Use of the PMSI Tunnel Attribute . . . . . . . . . . . . . . 4
	3. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 6		2.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Using the LIR Flag . . . . . . . . . . . . . . . . . . . 7		2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 7
	3.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . . . 7		2.2.1. Using the LIR Flag . . . . . . . . . . . . . . . . . 7
	4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 8		2.2.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . 7
	4.1. Encapsulation and Transmission . . . . . . . . . . . . . 8		3. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 9		3.1. Encapsulation and Transmission . . . . . . . . . . . . . 8
	4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 9		3.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 9
	4.2.2. At a BFER that is a P-tunnel Segmentation Boundary . 9		3.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 10
	5. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 10		3.2.2. At a BFER that is a P-tunnel Segmentation Boundary . 10
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		4. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	9.1. Normative References . . . . . . . . . . . . . . . . . . 10		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.2. Informative References . . . . . . . . . . . . . . . . . 11		8.1. Normative References . . . . . . . . . . . . . . . . . . 11
			8.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	[RFC6513] and [RFC6514] specify the protocols and procedures that a		[RFC6513] and [RFC6514] specify the protocols and procedures that a
	Service Provider (SP) can use to provide Multicast Virtual Private		Service Provider (SP) can use to provide Multicast Virtual Private
	Network (MVPN) service to its customers. Multicast tunnels are		Network (MVPN) service to its customers. Multicast tunnels are
	created through an SP's backbone network; these are known as		created through an SP's backbone network; these are known as
	"P-tunnels". The P-tunnels are used for carrying multicast traffic		"P-tunnels". The P-tunnels are used for carrying multicast traffic
	across the backbone. The MVPN specifications allow the use of		across the backbone. The MVPN specifications allow the use of
	skipping to change at page 5, line 20 ¶		skipping to change at page 5, line 23 ¶
	originator of the route that is carrying this PTA. This will		originator of the route that is carrying this PTA. This will
	either be a /32 IPv4 address or a /128 IPv6 address. Whether		either be a /32 IPv4 address or a /128 IPv6 address. Whether
	the address is IPv4 or IPv6 can be inferred from the total		the address is IPv4 or IPv6 can be inferred from the total
	length of the PMSI Tunnel attribute.		length of the PMSI Tunnel attribute.
	o "MPLS label". This field contains an upstream-assigned MPLS		o "MPLS label". This field contains an upstream-assigned MPLS
	label. It is assigned by the router that originates the BGP route		label. It is assigned by the router that originates the BGP route
	to which the PTA is attached. Constraints on the way in which the		to which the PTA is attached. Constraints on the way in which the
	originating router selects this label are discussed below.		originating router selects this label are discussed below.
	o "Flags". When the tunnel type is BIER, two of the bits in the PTA		o "Flags". When the tunnel type is BIER, two of the flags in the
	Flags field are meaningful. Details about the use of these bits		PTA Flags field are meaningful. Details about the use of these
	can be found in Section 3.		flags can be found in Section 2.2.
	* "Leaf Info Required per Flow (LIR-pF)". This bit is introduced
	in [EXPLICIT_TRACKING]. A BFIR SHOULD NOT set this bit UNLESS
	it knows that all the BFERs in the BIER domain (or at least all
	the BFERs to which it needs to transmit) support this bit.
	(How this is known is outside the scope of this document.)
	This bit MAY be set in a (C-*,C-*) S-PMSI A-D route, but MUST
	NOT be set in I-PMSI A-D routes or in other S-PMSI A-D routes.
	* "Leaf Info Required Bit". The setting of this bit depends upon
	the type of route and the NLRI of the route that carries the
	PTA.
	+ In an I-PMSI A-D route or a (C-*,C-*) S-PMSI A-D route, the		* "Leaf Info Required per Flow (LIR-pF)". This flag is
	bit SHOULD be clear, unless the LIR-pF bit has also been set		introduced in [EXPLICIT_TRACKING]. A BFIR SHOULD NOT set this
	(see above). This bit SHOULD also be clear in a (C-S,C-*)		flag UNLESS it knows that all the BFERs in the BIER domain (or
	or (C-*,C-G) S-PMSI A-D route.		at least all the BFERs to which it needs to transmit) support
			this flag. (How this is known is outside the scope of this
			document.) Procedures for the use of this flag are given in
			Section 2.2.2
	+ In other S-PMSI A-D routes, the bit SHOULD be set.		* "Leaf Info Required Bit". See Section 2.2.1.
	Note that if a PTA specifying "BIER" is attached to an I-PMSI or		Note that if a PTA specifying "BIER" is attached to an I-PMSI or
	S-PMSI A-D route, the route MUST NOT be distributed beyond the		S-PMSI A-D route, the route MUST NOT be distributed beyond the
	boundaries of a BIER domain. That is, any routers that receive the		boundaries of a BIER domain. That is, any routers that receive the
	route must be in the same BIER domain as the originator of the route.		route must be in the same BIER domain as the originator of the route.
	If the originator is in more than one BIER domain, the route must be		If the originator is in more than one BIER domain, the route must be
	distributed only within the BIER domain in which the BFR-Prefix in		distributed only within the BIER domain in which the BFR-Prefix in
	the PTA uniquely identifies the originator. As with all MVPN routes,		the PTA uniquely identifies the originator. As with all MVPN routes,
	distribution of these routes is controlled by the provisioning of		distribution of these routes is controlled by the provisioning of
	Route Targets.		Route Targets.
			2.1. MPLS Label
	Suppose an ingress PE originates two x-PMSI A-D routes, where we use		Suppose an ingress PE originates two x-PMSI A-D routes, where we use
	the term "x-PMSI" to mean "I-PMSI or S-PMSI". Suppose both routes		the term "x-PMSI" to mean "I-PMSI or S-PMSI". Suppose both routes
	carry a PTA, and the PTA of each route specifies"BIER".		carry a PTA, and the PTA of each route specifies"BIER".
	o If the two routes do not carry the same set of Route Targets		o If the two routes do not carry the same set of Route Targets
	(RTs), then their respective PTAs MUST contain different MPLS		(RTs), then their respective PTAs MUST contain different MPLS
	label values.		label values.
	o If the ingress PE is supporting MVPN extranet ([EXTRANET])		o If the ingress PE is supporting MVPN extranet ([RFC7900])
	functionality, and if the two routes originate from different		functionality, and if the two routes originate from different
	VRFs, then the respective PTAs of the two routes MUST contain		VRFs, then the respective PTAs of the two routes MUST contain
	different MPLS label values.		different MPLS label values.
	o If the ingress PE is supporting the "Extranet Separation" feature		o If the ingress PE is supporting the "Extranet Separation" feature
	of MVPN extranet (see Section 7.3 of [EXTRANET], section ), and if		of MVPN extranet (see Section 7.3 of [RFC7900], section ), and if
	one of the routes carries the "Extranet Separation" extended		one of the routes carries the "Extranet Separation" extended
	community and the other does not, then the respective PTAs of the		community and the other does not, then the respective PTAs of the
	two routes MUST contain different MPLS label values.		two routes MUST contain different MPLS label values.
	o If segmented P-tunnels are being used, then the respective PTAs of		o If segmented P-tunnels are being used, then the respective PTAs of
	the two routes MUST contain different MPLS label values, as long		the two routes MUST contain different MPLS label values, as long
	as the NLRIs are not identical. In this case, the MPLS label can		as the NLRIs are not identical. In this case, the MPLS label can
	be used by the BFER to identify the particular C-flow to which a		be used by the BFER to identify the particular C-flow to which a
	data packet belongs, and this greatly simplifies the process of		data packet belongs, and this greatly simplifies the process of
	forwarding a received packet to its next P-tunnel segment. This		forwarding a received packet to its next P-tunnel segment. This
	is explained further in Section 4.		is explained further below. See also Section 3.
	When segmented P-tunnels are being used, an ABR or ASBR may receive,		When segmented P-tunnels are being used, an ABR or ASBR may receive,
	from a BIER domain, an x-PMSI A-D route whose PTA specifies "BIER".		from a BIER domain, an x-PMSI A-D route whose PTA specifies "BIER".
	This means that BIER is being used for one segment of a segmented		This means that BIER is being used for one segment of a segmented
	P-tunnel. The ABR/ASBR may in turn need to originate an x-PMSI A-D		P-tunnel. The ABR/ASBR may in turn need to originate an x-PMSI A-D
	route whose PTA identifies the next segment of the P-tunnel. The		route whose PTA identifies the next segment of the P-tunnel. The
	next segment may also be "BIER". Suppose an ASBR receives x-PMSI A-D		next segment may also be "BIER". Suppose an ASBR receives x-PMSI A-D
	routes R1 and R2, and as a result originates x-PMSI A-D routes R3 and		routes R1 and R2, and as a result originates x-PMSI A-D routes R3 and
	R4 respectively, where the PTAs of each of the four routes specify a		R4 respectively, where the PTAs of each of the four routes specify
	BIER. Then the PTAs of R3 and R4 MUST NOT specify the same MPLS		BIER. Then the PTAs of R3 and R4 MUST NOT specify the same MPLS
	label, UNLESS both of the following conditions hold:		label, UNLESS both of the following conditions hold:
	o R1 and R2 have the same "originating router" in their respective		o R1 and R2 have the same "originating router" in their respective
	NLRIs.		NLRIs.
	o R1 and R2 specify the same MPLS label in their respective PTAs.		o R1 and R2 specify the same MPLS label in their respective PTAs.
	3. Explicit Tracking		The ABR/ASBR MUST then program its dataplane such that a packet
			arriving with the upstream-assigned label specified in route R1 is
			transmitted with the upstream-assigned label specified in route R3,
			and a packet arriving with the upstream-assigned label specified in
			route R2 is transmitted with the label specified in route R4. Of
			course, the data plane must also be programmed to encapsulate the
			transmitted packets with an appropriate BIER header, whose BitString
			is determined by the multicast flow overlay.
			2.2. Explicit Tracking
	When using BIER to transport an MVPN data packet through a BIER		When using BIER to transport an MVPN data packet through a BIER
	domain, an ingress PE functions as a BFIR (see [BIER_ARCH]). The		domain, an ingress PE functions as a BFIR (see [BIER_ARCH]). The
	BFIR must determine the set of BFERs to which the packet needs to be		BFIR must determine the set of BFERs to which the packet needs to be
	delivered. This can be done in either of two ways:		delivered. This can be done in either of two ways:
	1. By using the explicit tracking mechanism based on the "Leaf Info		1. Using the explicit tracking mechanism based on the "Leaf Info
	Required" flag, as specified in [RFC6513] and [RFC6514], or		Required" flag specified in [RFC6513] and [RFC6514]. This method
			is further described in Section 2.2.1.
	2. By using the explicit tracking mechanism based on the LIR-pF flag		2. Using the explicit tracking mechanism based on the LIR-pF flag
	as specified in [EXPLICIT_TRACKING]. This mechanism MAY be used		specified in [EXPLICIT_TRACKING]. This method, further described
	if (and only if) segmented P-tunnels are not being used.		in Section 2.2.2, may be used if (and only if) segmented
			P-tunnels are not being used.
	3.1. Using the LIR Flag		2.2.1. Using the LIR Flag
	To determine the set of BFERs to which a given MVPN data packet needs		To determine the set of BFERs to which the packets of a given C-flow
	to be delivered, the BFIR originating an S-PMSI A-D route sets the		must be sent, a BFIR MUST originate a (C-S,C-G) S-PMSI A-D route for
	LIR bit in the route's PTA. Per [RFC6514], the BFERs will respond		the given C-flow. It MUST attach a PTA to that route, and MUST set
	with Leaf A-D routes. By matching the received Leaf A-D routes to		the LIR flag in the PTA. Per [RFC6514], the BFERs that need to
	the originated S-PMSI A-D routes, the originator of the S-PMSI A-D		receive that C-flow will respond with (C-S,C-G) Leaf A-D routes. By
	route determines the set of BFERs that need to receive the multicast		matching the received Leaf A-D routes to the originated S-PMSI A-D
	data flow (or flows) that is (are) identified in the NLRI of the of		routes, the originator of the S-PMSI A-D route determines the set of
	the S-PMSI A-D route.		BFERs that need to receive the multicast data flow that is identified
			in the NLRI of S-PMSI A-D route.
	This requires that each BFIR originate an S-PMSI A-D route for each		The PTA MAY specify a tunnel type ("BIER") and a non-zero MPLS label.
	C-flow for which it serves as BFIR. The BFIR MAY include, in each		(If it specifies one of these it MUST also specify the other.)
	such route, a PTA as described in Section 2. However, if the BFIR		Alternatively, the PTA MAY specify "no tunnel type" and a zero MPLS
	has originated an I-PMSI A-D route or a wildcard S-PMSI A-D route		label. In this case, the tunnel type ("BIER") and non-zero MPLS
	that "matches" (according to the rules of [RFC6625]) a particular		label MUST be specified in an I-PMSI A-D route or in a wildcard
	C-flow, then it may do explicit tracking for that C-flow by		S-PMSI A-D route that "matches" (according to the rules of [RFC6625])
	originating an S-PMSI A-D route for that C-flow, but including a PTA		the C-flow in question.
	that specifies "no tunnel type".
	3.2. Using the LIR-pF Flag		2.2.2. Using the LIR-pF Flag
	If segmented P-tunnels are not being used, the BFIR can determine the		If segmented P-tunnels are not being used, the BFIR can determine the
	set of BFERs to which a given MVPN data packet needs to be delivered		set of BFERs that need to receive the packets of a given (C-S,C-G)
	by originating a (C-*,C-*) S-PMSI A-D route, and by setting the LIR-		C-flow as follows. The BFIR MUST originate a wildcard S-PMSI A-D
	pF flag in the PTA of that route. Per [EXPLICIT_TRACKING], each BFER		route (either (C-*,C-*), (C-*,C-G), or (C-S,C-G) and the PTA of that
	will respond with one or more Leaf A-D routes, identifying the flows		route MUST the following settings:
	that it is expecting to receive from the BFIR that originated the
	(C-*,C-*) S-PMSI A-D route.		o The LIR-pF flag MUST be set;
			o The tunnel type MUST be set to "BIER;
			o A non-zero MPLS label MUST be specified.
			Per [EXPLICIT_TRACKING], a BFER that needs to receive (C-S,C-G)
			traffic from the BFIR will respond with a Leaf A-D route.
	A BFIR MUST NOT use this method of finding the set of BFERs needing		A BFIR MUST NOT use this method of finding the set of BFERs needing
	to receive a given C-flow unless it knows that all those BFERs		to receive a given C-flow unless it knows that all those BFERs
	support the LIR-pF flag. How this is known is outside the scope of		support the LIR-pF flag. How this is known is outside the scope of
	this document.		this document.
	This option greatly reduces the number of S-PMSI A-D routes that a		This method greatly reduces the number of S-PMSI A-D routes that a
	BFIR needs to originate; it now needs to originate only one such		BFIR needs to originate; it can now originate as few as one such
	route, rather than one for each C-flow. However, it does not provide		route (a (C-*,C-*) S-PMSI A-D route), rather than one for each
	a way for the BFIR to assign a distinct label to each C-flow.		C-flow. However, the method does not provide a way for the BFIR to
	Therefore it cannot be used when segmented P-tunnels are in use (see		assign a distinct label to each C-flow. Therefore it cannot be used
	Section 4 for an explanation).		when segmented P-tunnels are in use (see Section 3 for an
			explanation).
	4. Data Plane		Note: if a BFIR originates a (C-*,C-*) S-PMSI A-D route with the LIR-
			pF flag set, but also originates a more specific wildcard route that
			matches a particular (C-S,C-G), the BFERs will not originate Leaf A-D
			routes for that (C-S,C-G) unless the LIR-pF flag is also set in the
			more specific wildcard route. If the BFIR also originates a
			(C-S,C-G) S-PMSI A-D route without the LIR flag set, the BFERs will
			not originate Leaf A-D routes for that (C-S,C-G) unless the LIR flag
			is also set in that route.
	The MVPN application plays the role of the "multicast flow layer" as		3. Data Plane
	described in [BIER_ARCH].
	4.1. Encapsulation and Transmission		The MVPN application plays the role of the "multicast flow overlay"
			as described in [BIER_ARCH].
			3.1. Encapsulation and Transmission
	To transmit an MVPN data packet, an ingress PE follows the rules of		To transmit an MVPN data packet, an ingress PE follows the rules of
	[RFC6625] to find the S-PMSI A-D route or I-PMSI A-D route that is a		[RFC6625] to find the S-PMSI A-D route or I-PMSI A-D route that is a
	"match for transmission" for that packet. (In applying the rules of		"match for transmission" for that packet. (In applying the rules of
	[RFC6625], any S-PMSI A-D route with a PTA specifying "no tunnel		[RFC6625], any S-PMSI A-D route with a PTA specifying "no tunnel
	information" is ignored.) If the matching route has a PTA specifying		information" is ignored.) If the matching route has a PTA specifying
	a "BIER", the (upstream-assigned) MPLS label from that PTA is pushed		"BIER", the (upstream-assigned) MPLS label from that PTA is pushed on
	on the packet's label stack. Then the packet is encapsulated in a		the packet's label stack. Then the packet is encapsulated in a BIER
	BIER header and forwarded, according to the procedures of [BIER_ARCH]		header and forwarded, according to the procedures of [BIER_ARCH] and
	and [BIER_ENCAPS]. (See especially Section 4, "Imposing and		[BIER_ENCAPS]. (See especially Section 4, "Imposing and Processing
	Processing the BIER Encapsulation", of [BIER_ENCAPS].)		the BIER Encapsulation", of [BIER_ENCAPS].)
	In order to create the proper BIER header for a given packet, the		In order to create the proper BIER header for a given packet, the
	BFIR must know all the BFERs that need to receive that packet. It		BFIR must know all the BFERs that need to receive that packet. It
	determines this by finding all the Leaf A-D routes that correspond to		determines this by finding all the Leaf A-D routes that correspond to
	the S-PMSI A-D route that is the packet's match for transmission.		the S-PMSI A-D route that is the packet's match for transmission.
	There are two different cases to consider:		There are two different cases to consider:
	1. The S-PMSI A-D route that is the match for transmission carries a		1. The S-PMSI A-D route that is the match for transmission carries a
	PTA that has the LIR flag set but does not have the LIR-pF flag		PTA that has the LIR flag set but does not have the LIR-pF flag
	set.		set.
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 23 ¶
	route.		route.
	2. The S-PMSI A-D route that is the match for transmission carries a		2. The S-PMSI A-D route that is the match for transmission carries a
	PTA that has the LIR-pF flag.		PTA that has the LIR-pF flag.
	In this case, the corresponding Leaf A-D routes are those whose		In this case, the corresponding Leaf A-D routes are those whose
	"route key" field is derived from the NLRI of the S-PMSI A-D		"route key" field is derived from the NLRI of the S-PMSI A-D
	route according to the procedures described in Section 5.2 of		route according to the procedures described in Section 5.2 of
	[EXPLICIT_TRACKING].		[EXPLICIT_TRACKING].
	4.2. Disposition		3.2. Disposition
	The procedures for handling a received BIER packet at BFER depend on
	whether the BFER is an egress PE for the packet. A BFER can tell
	whether it is an egress PE for a given BIER packet by examining the
	MPLS label that the packet is carrying immediately after the BIER
	header. This will be an upstream-assigned label (from the BFIR) that
	has been advertised in the PTA of an S-PMSI A-D route.
	Note that if segmented P-tunnels are in use, a BFER might be a
	P-tunnel segmentation border router rather than an egress PE, or a
	BFER might be both an egress PE and a P-tunnel segmentation border
	router.
	Depending upon the role of the BFER for given packet, it may need to
	follow the procedures of Section 4.2.1, the procedures of
	Section 4.2.2, or both.
	4.2.1. At a BFER that is an Egress PE
	When a BFER receives an MVPN multicast data packet that has been		When a BFER receives an MVPN multicast data packet that has been
	BIER-encapsulated, it determines from the MPLS label at the top of		BIER-encapsulated, the BIER layer passes the following information to
	the packet's label stack whether it is an egress PE for the packet or		the multicast flow overlay:
	not. If it is an egress PE, the BIER layer passes the following
	information to the multicast flow layer:
	o The BFR-prefix corresponding to the sub-domain-id and BFIR-id in		o The BFR-prefix corresponding to the sub-domain-id and BFIR-id in
	the BIER header.		the BIER header.
	o The "payload", which is an MPLS packet whose top label is an		o The "payload", which is an MPLS packet whose top label is an
	upstream-assigned label. The BFR-prefix provides the "context" in		upstream-assigned label. The BFR-prefix provides the "context" in
	which the upstream-assigned label is interpreted.		which the upstream-assigned label is interpreted.
	Note that per [RFC5331], the context for an upstream-assigned		Note that per [RFC5331], the context for an upstream-assigned
	label is the IP address of the label assigner, which in this case		label is the IP address of the label assigner, which in this case
	is the BFR-prefix of the BFIR.		is the BFR-prefix of the BFIR.
	4.2.2. At a BFER that is a P-tunnel Segmentation Boundary		By looking up the upstream-assigned label in the appropriate context,
			the multicast flow overlay determines whether the BFER is an egress
			PE for the packet.
			Note that if segmented P-tunnels are in use, a BFER might be a
			P-tunnel segmentation border router rather than an egress PE, or a
			BFER might be both an egress PE and a P-tunnel segmentation border
			router. Depending upon the role of the BFER for given packet, it may
			need to follow the procedures of Section 3.2.1, the procedures of
			Section 3.2.2, or both.
			3.2.1. At a BFER that is an Egress PE
			From looking up the packet's upstream-assigned label in the context
			of the packet's BFIR-prefix, the egress PE determines the egress VRF
			for the packet. From the IP header of the payload, the multicast
			states of the VRF, the upstream-assigned label, and the BFR-prefix,
			the egress PE can determine whether the packet needs to be forwarded
			out one or more VRF interfaces.
			3.2.2. At a BFER that is a P-tunnel Segmentation Boundary
	When segmented P-tunnels are being used, a BFER that receives a BIER-		When segmented P-tunnels are being used, a BFER that receives a BIER-
	encapsulated MVPN multicast data packet may need to be forwarded on		encapsulated MVPN multicast data packet may need to be forwarded on
	its next P-tunnel segment. The choice of the next P-tunnel segment		its next P-tunnel segment. The choice of the next P-tunnel segment
	for the packet depends upon the C-flow to which the packet belongs.		for the packet depends upon the C-flow to which the packet belongs.
	Since the BFIR assigns a distinct upstream-assigned MPLS label for		As long as the BFIR has assigned the MPLS label according to the
	each C-flow, the BFER can select the proper "next P-tunnel segment"		constraints specified in Section 2.1, the BFIR will have assigned
	for a given packet simply by looking up the upstream-assigned label		distinct upstream-assigned MPLS labels to distinct C-flows. The BFER
	that immediately follows the BIER header. (If the BFIR had not		can thus select the proper "next P-tunnel segment" for a given packet
	assigned a distinct label to each C-flow, the BFER would need to		simply by looking up the upstream-assigned label that immediately
	maintain all the state from the Multicast Flow Overlay in order to		follows the BIER header.
	select the next P-tunnel segment.)
	5. Contributor Addresses		4. Contributor Addresses
	Below is a list of other contributing authors in alphabetical order:		Below is a list of other contributing authors in alphabetical order:
	IJsbrand Wijnands		IJsbrand Wijnands
	Cisco Systems, Inc.		Cisco Systems, Inc.
	De Kleetlaan 6a		De Kleetlaan 6a
	Diegem 1831		Diegem 1831
	Belgium		Belgium
	Email: ice@cisco.com		Email: ice@cisco.com
	6. Acknowledgments		5. Acknowledgments
	The authors wish to thank Jeffrey Zhang for his ideas and		The authors wish to thank Jeffrey Zhang for his ideas and
	contributions to this work.		contributions to this work.
	7. IANA Considerations		6. IANA Considerations
	IANA is requested to assign a value for "BIER" from the "P-Multicast		IANA is requested to assign a value for "BIER" from the "P-Multicast
	Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. The		Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. The
	reference should be this document.		reference should be this document.
	8. Security Considerations		7. Security Considerations
	The security considerations of [BIER_ARCH], [BIER_ENCAPS], [RFC6513]		The security considerations of [BIER_ARCH], [BIER_ENCAPS], [RFC6513]
	and [RFC6514] are applicable.		and [RFC6514] are applicable.
	9. References		8. References
	9.1. Normative References		8.1. Normative References
	[BIER_ARCH]		[BIER_ARCH]
	Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T.,		Wijnands, IJ., Rosen, E., Dolganow, A., Przygienda, T.,
	and S. Aldrin, "Multicast using Bit Index Explicit		and S. Aldrin, "Multicast using Bit Index Explicit
	Replication", internet-draft draft-ietf-bier-architecture-		Replication", internet-draft draft-ietf-bier-architecture-
	03, January 2016.		03, January 2016.
	[BIER_ENCAPS]		[BIER_ENCAPS]
	Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J., and		Wijnands, IJ., Rosen, E., Dolganow, A., Tantsura, J., and
	S. Aldrin, "Encapsulation for Bit Index Explicit		S. Aldrin, "Encapsulation for Bit Index Explicit
	skipping to change at page 11, line 33 ¶		skipping to change at page 12, line 5 ¶
	[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, DOI 10.17487/RFC6514, February 2012,		VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
	<http://www.rfc-editor.org/info/rfc6514>.		<http://www.rfc-editor.org/info/rfc6514>.
	[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.		[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R.
	Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",		Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes",
	RFC 6625, DOI 10.17487/RFC6625, May 2012,		RFC 6625, DOI 10.17487/RFC6625, May 2012,
	<http://www.rfc-editor.org/info/rfc6625>.		<http://www.rfc-editor.org/info/rfc6625>.
	9.2. Informative References		8.2. Informative References
	[EXPLICIT_TRACKING]		[EXPLICIT_TRACKING]
	Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang,		Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang,
	"Explicit Tracking with Wild Card Routes in Multicast		"Explicit Tracking with Wild Card Routes in Multicast
	VPN", internet-draft draft-ietf-bess-mvpn-expl-track-00,		VPN", internet-draft draft-ietf-bess-mvpn-expl-track-00,
	June 2016.		June 2016.
	[EXTRANET]
	Rekhter, Y., Rosen, E., Aggarwal, R., Cai, Y., and T.
	Morin, "Extranet Multicast in BGP/IP MPLS VPNs", internet-
	draft draft-ietf-bess-mvpn-extranet-07, April 2016.
	[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,		[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T.,
	Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area		Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area
	Point-to-Multipoint (P2MP) Segmented Label Switched Paths		Point-to-Multipoint (P2MP) Segmented Label Switched Paths
	(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,		(LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015,
	<http://www.rfc-editor.org/info/rfc7524>.		<http://www.rfc-editor.org/info/rfc7524>.
			[RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y.,
			and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs",
			RFC 7900, DOI 10.17487/RFC7900, June 2016,
			<http://www.rfc-editor.org/info/rfc7900>.
	Authors' Addresses		Authors' Addresses
	Eric C. Rosen (editor)		Eric C. Rosen (editor)
	Juniper Networks, Inc.		Juniper Networks, Inc.
	10 Technology Park Drive		10 Technology Park Drive
	Westford, Massachusetts 01886		Westford, Massachusetts 01886
	United States		United States
	Email: erosen@juniper.net		Email: erosen@juniper.net
	skipping to change at page 12, line 30 ¶		skipping to change at page 13, line 4 ¶
	Email: masivaku@cisco.com		Email: masivaku@cisco.com
	Sam K Aldrin		Sam K Aldrin
	Google, Inc.		Google, Inc.
	1600 Amphitheatre Parkway		1600 Amphitheatre Parkway
	Mountain View, California		Mountain View, California
	United States		United States
	Email: aldrin.ietf@gmail.com		Email: aldrin.ietf@gmail.com
	Andrew Dolganow		Andrew Dolganow
	Alcatel-Lucent		Nokia
	600 March Rd.		600 March Rd.
	Ottawa, Ontario K2K 2E6		Ottawa, Ontario K2K 2E6
	Canada		Canada
	Email: andrew.dolganow@alcatel-lucent.com		Email: andrew.dolganow@nokia.com
	Tony Przygienda		Tony Przygienda
	Ericsson		Juniper Networks, Inc.
	300 Holger Way		1137 Innovation Way
	San Jose, California 95134		San Jose, California 94089
	United States		United States
	Email: antoni.przygienda@ericsson.com		Email: prz@juniper.net
End of changes. 45 change blocks.
	139 lines changed or deleted		158 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/