< draft-ietf-bier-mvpn-06.txt		draft-ietf-bier-mvpn-07.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: Experimental M. Sivakumar		Intended status: Experimental M. Sivakumar
	Expires: December 29, 2017 Cisco Systems, Inc.		Expires: January 27, 2018 Cisco Systems, Inc.
	S. Aldrin		S. Aldrin
	Google, Inc.		Google, Inc.
	A. Dolganow		A. Dolganow
	Nokia		Nokia
	T. Przygienda		T. Przygienda
	Juniper Networks, Inc.		Juniper Networks, Inc.
	June 27, 2017		July 26, 2017
	Multicast VPN Using BIER		Multicast VPN Using BIER
	draft-ietf-bier-mvpn-06		draft-ietf-bier-mvpn-07
	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 29, 2017.		This Internet-Draft will expire on January 27, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	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 in x-PMSI A-D Routes . . . . 5		2. Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes . . . . 5
	2.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 6		2.1. MPLS Label . . . . . . . . . . . . . . . . . . . . . . . 6
	2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 7		2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 8
	2.2.1. Using the LIR Flag . . . . . . . . . . . . . . . . . 8		2.2.1. Using the LIR Flag . . . . . . . . . . . . . . . . . 9
	2.2.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . 8		2.2.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . 9
	3. Use of the PMSI Tunnel Attribute in Leaf A-D routes . . . . . 9		3. Use of the PMSI Tunnel Attribute in Leaf A-D routes . . . . . 10
	4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 10		4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1. Encapsulation and Transmission . . . . . . . . . . . . . 10		4.1. Encapsulation and Transmission . . . . . . . . . . . . . 11
	4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 11		4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 12
	4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 12		4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 13
	4.2.2. At a BFER that is a P-tunnel Segmentation Boundary . 12		4.2.2. At a BFER that is a P-tunnel Segmentation Boundary . 13
	5. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 12		5. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 13
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 13		8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . 13		9.1. Normative References . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	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
	several different kinds of P-tunnel technology.		several different kinds of P-tunnel technology.
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 7 ¶
	root. In this case, it contains information that is needed in		root. In this case, it contains information that is needed in
	order for the originator of the route to join the specified		order for the originator of the route to join the specified
	P-tunnel.		P-tunnel.
	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 RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	2. Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes		2. Use of the PMSI Tunnel Attribute in x-PMSI A-D Routes
	As defined in [RFC6514], the PMSI Tunnel attribute (PTA) is used to		As defined in [RFC6514], the PMSI Tunnel attribute (PTA) carried by
	identify the P-tunnel that is used to instantiate a particular PMSI.		an x-PMSI A-D route identifies the P-tunnel that is used to
	If a PMSI is to be instantiated by BIER, the PTA is constructed as		instantiate a particular PMSI. If a PMSI is to be instantiated by
	follows.		BIER, the PTA is constructed by a BFIR.
			If segmented P-tunnels are not being used, the PTA attached to a
			given x-PMSI A-D route is constructed by the router that originated
			the route (typically by the ingress PE), and the PTA is not changed
			as the route is propagated.
			If segmented P-tunnels are being used, the PTA attached to a given
			x-PMSI A-D route by the route's originator may replaced, at a
			segmentation point (a BFER), by a PTA identifying the next segment of
			the P-tunnel. If the next segment of the P-tunnel is instantiated by
			BIER, the segmentation point serves as the BFIR for that next
			segment.
			In either case, a PTA is constructed by a BFIR as follows:
	The PTA contains the following fields:		The PTA contains the following fields:
	o "Tunnel Type". IANA is requested to assign a new tunnel type		o "Tunnel Type". IANA is requested to assign a new tunnel type
	codepoint for "BIER" from the "P-Multicast Service Interface		codepoint for "BIER" from the "P-Multicast Service Interface
	Tunnel (PMSI Tunnel) Tunnel Types" registry. This codepoint will		Tunnel (PMSI Tunnel) Tunnel Types" registry. This codepoint will
	be used to indicate that the PMSI is instantiated by BIER.		be used to indicate that the PMSI is instantiated by BIER.
	(Although BIER does not actually create tunnels, the MVPN
	procedures treat BIER as if it were a type of tunnel.)		Although BIER does not actually create tunnels, the MVPN
			procedures treat BIER as if it were a type of tunnel.
	o "Tunnel Identifier". When the "tunnel type" is "BIER", this field		o "Tunnel Identifier". When the "tunnel type" is "BIER", this field
	contains two subfields:		contains two subfields:
	1. The first subfield is a single octet, containing a BIER sub-		1. The first subfield is a single octet, containing a BIER
	domain-id. (See [BIER_ARCH].) This indicates that packets		sub-domain-id. (See [BIER_ARCH].) This indicates that
	sent on the PMSI will be sent on the specified BIER sub-		packets sent on the PMSI will be sent on the specified BIER
	domain. How that sub-domain is chosen is outside the scope of		sub-domain. How that sub-domain is chosen is outside the
	this document.		scope of this document.
	2. The second subfield is the BFR-Prefix (see [BIER_ARCH]) of the		2. The second subfield is the BFR-Prefix (see [BIER_ARCH]) of the
	originator of the route that is carrying this PTA. This must		router (a BFIR) that is constructing the PTA. This must be
	be the originator's BFR-prefix in the specified sub-domain.		the BFIR's BFR-prefix in the specified sub-domain. The
	The BFR-Prefix will either be a /32 IPv4 address or a /128		BFR-Prefix will either be a /32 IPv4 address or a /128 IPv6
	IPv6 address. Whether the address is IPv4 or IPv6 can be		address. Whether the address is IPv4 or IPv6 can be inferred
	inferred from the total length of the PMSI Tunnel attribute.		from the total length of the PTA.
	The BFR-Prefix need not be the same IP address that is carried		The BFR-Prefix need not be the same IP address that is carried
	in any other field of the x-PMSI A-D route.		in any other field of the x-PMSI A-D route, even if the BFIR
			is the originating router of the x-PMSI A-D route.
	Failure to properly set the Tunnel Identifier field cannot be		Failure to properly set the Tunnel Identifier field cannot be
	detected by the protocol, and will result in improper delivery of		detected by the protocol, and will result in improper delivery of
	the data packets sent on the PMSI.		the data packets sent on the PMSI.
	o "MPLS label". This field MUST contain an upstream-assigned MPLS		o "MPLS label". This field MUST contain an upstream-assigned non-
	label. It is assigned by the router that originates the BGP route		zero MPLS label. It is assigned by the router (a BFIR) that
	to which the PTA is attached. Constraints on the way in which the		constructs the PTA. Constraints on the way in which a BFIR
	originating router selects this label are discussed in		selects this label are discussed in Section 2.1.
	Section 2.1.
	Failure to follow the constraints on label assignment cannot be		Failure to follow the constraints on label assignment cannot be
	detected by the protocol, and may result in improper handling of		detected by the protocol, and may result in improper handling of
	data packets by the egress PE routers.		data packets by the egress PE routers.
	o "Flags". When the tunnel type is BIER, two of the flags in the		o "Flags". When the tunnel type is BIER, two of the flags in the
	PTA Flags field are meaningful. Details about the use of these		PTA Flags field are meaningful. Details about the use of these
	flags can be found in Section 2.2.		flags can be found in Section 2.2.
	* "Leaf Info Required per Flow (LIR-pF)". This flag is		* "Leaf Info Required per Flow (LIR-pF)". This flag is
	skipping to change at page 6, line 32 ¶		skipping to change at page 6, line 49 ¶
	the same BIER domain as the originator of the route. If the		the same BIER domain as the originator of the route. If the
	originator is in more than one BIER domain, the route must be		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. Thus the requirement expressed in this paragraph is		Route Targets. Thus the requirement expressed in this paragraph is
	really a requirement on the way the Route Targets are provisioned.		really a requirement on the way the Route Targets are provisioned.
	2.1. MPLS Label		2.1. MPLS Label
	Suppose an ingress PE originates two x-PMSI A-D routes. Suppose each		Suppose a BFIR attaches a PTA to each of two x-PMSI A-D routes, and
	route carries a PTA, and the PTA of each route specifies a tunnel		both PTAs specify a tunnel type of "BIER".
	type of "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 two routes do not have the same Address Family Identifier		o If the two routes do not have the same Address Family Identifier
	(AFI) value, then their respective PTAs MUST contain different		(AFI) value, then their respective PTAs MUST contain different
	MPLS label values. This ensures that when an egress PE receives a		MPLS label values. This ensures that when an egress PE receives a
	data packet with the given label, the egress PE can infer from the		data packet with the given label, the egress PE can infer from the
	label whether the payload is an IPv4 packet or an IPv6 packet.		label whether the payload is an IPv4 packet or an IPv6 packet.
	o If the ingress PE is supporting MVPN extranet ([RFC7900])		o If the BFIR is an ingress PE supporting MVPN extranet ([RFC7900])
	functionality, and if the two routes originate from different		functionality, and if the two routes originate from different VRFs
	VRFs, then the respective PTAs of the two routes MUST contain		on this ingress PE, then the respective PTAs of the two routes
	different MPLS label values.		MUST contain different MPLS label values.
	o If the ingress PE is supporting the "Extranet Separation" feature		o If the BFIR is an ingress PE supporting the "Extranet Separation"
	of MVPN extranet (see Section 7.3 of [RFC7900], section ), and if		feature of MVPN extranet (see Section 7.3 of [RFC7900]), 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 but 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 whenever
	as the NLRIs are not identical. In this case, the MPLS label can		the respective NLRIs of the two routes are not identical. The
	be used by the BFER to identify the particular C-flow to which a		MPLS label can then be used at the next segmentation point to
	data packet belongs, and this greatly simplifies the process of		switch packets from one P-tunnel segment directly to the next,
	forwarding a received packet to its next P-tunnel segment. This		without requiring the segmentation points to contain any other
	is explained further below. See also Section 4.		multicast forwarding state. This is explained further below. See
			also Section 4.
	When segmented P-tunnels are being used, an ABR or ASBR may receive,		When segmented P-tunnels are being used, a segmentation point, call
	from a BIER domain, an x-PMSI A-D route whose PTA specifies "BIER".		it "B1", may receive, from within a given BIER domain, an x-PMSI A-D
	This means that BIER is being used for one segment of a segmented		route whose PTA specifies "BIER". This means that BIER is being used
	P-tunnel. The ABR/ASBR may in turn need to originate an x-PMSI A-D		for the previous segment of a segmented P-tunnel. If the next
	route whose PTA identifies the next segment of the P-tunnel. The		segment is also of type "BIER", B1 will be the BFIR for the next
	next segment may also be "BIER". Suppose an ASBR receives x-PMSI A-D		segment. That is, B1 is a BFER of one BIER domain (corresponding to
	routes R1 and R2, and as a result originates x-PMSI A-D routes R3 and		the previous segment), and a BFIR of another BIER domain
	R4 respectively, where the PTAs of each of the four routes specify		(corresponding to the next segment). B1 needs to replace the PTA of
	BIER. Then the PTAs of R3 and R4 MUST NOT specify the same MPLS		the x-PMSI A-D route with a new PTA, specifying its own BFR-Prefix,
	label, UNLESS both of the following conditions hold:		and specifying an upstream-assigned label assigned by B1 itself.
	o R1 and R2 have the same "originating router" in their respective		Suppose B1 has received two x-PMSI A-D routes, R1 and R2, where:
	NLRIs.
	o R1 and R2 specify the same MPLS label in their respective PTAs.		o R1 and R2 each have a PTA specifying BIER,
	The ABR/ASBR MUST then program its dataplane such that a packet		o R1's PTA specifies BFR-Prefix B2 and Label L2.
	arriving with the upstream-assigned label specified in route R1 is
	transmitted with the upstream-assigned label specified in route R3,		o R2's PTA specifies BFR-Prefix B3 and Label L3.
	and a packet arriving with the upstream-assigned label specified in
	route R2 is transmitted with the label specified in route R4. Of		Suppose B1 decides to propagate both R1 and R2, replacing each PTA
	course, the data plane must also be programmed to encapsulate the		with a new PTA specifying BIER. Suppose these new PTAs specify
	transmitted packets with an appropriate BIER header, whose BitString		labels L4 and L5 respectively. Then L4 and L5 MUST be different
	is determined by the multicast flow overlay.		(upstream-assigned) label values, UNLESS both of the following
			conditions hold:
			o R1 and R2 have the same value in the "originating router" field of
			their respective NLRIs, and
			o B2 is equal to B3, and
			o L2 is equal to L3.
			The segmentation point (B1 in this example) MUST also program its
			dataplane appropriately. For example, when:
			o B1 receives a BIER packet for which it is a BFER, and
			o the BIER header specifies the BFIR-id that corresponds to B2,and
			o the BIER payload is an MPLS packet with upstream-assigned label,
			and
			o the top label value is L2,
			then the dataplane must be programmed to replace L2 with L4, and to
			reencapsulate the packet in a BIER header, with B1's BFIR-id in the
			BFIR-id field. The BitString of the new BIER header is determined by
			the MVPN explicit tracking procedures (see Section 2.2 in the BIER
			domain of the next segment.
	2.2. Explicit Tracking		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. Using the explicit tracking mechanism based on the "Leaf Info		1. Using the explicit tracking mechanism based on the "Leaf Info
	Required" flag specified in [RFC6513] and [RFC6514]. This method		Required" flag specified in [RFC6513] and [RFC6514]. This method
	is further described in Section 2.2.1.		is further described in Section 2.2.1.
	2. Using the OPTIONAL explicit tracking mechanism based on the LIR-		2. Using the OPTIONAL explicit tracking mechanism based on the
	pF flag specified in [EXPLICIT_TRACKING]. This method, further		LIR-pF flag specified in [EXPLICIT_TRACKING]. This method,
	described in Section 2.2.2, may be used if (and only if)		further described in Section 2.2.2, may be used if (and only if)
	segmented P-tunnels are not being used.		segmented P-tunnels are not being used.
	2.2.1. Using the LIR Flag		2.2.1. Using the LIR Flag
	To determine the set of BFERs to which the packets of a given C-flow		To determine the set of BFERs to which the packets of a given C-flow
	must be sent, a BFIR MUST originate a (C-S,C-G) S-PMSI A-D route for		must be sent, a BFIR MUST originate a (C-S,C-G) S-PMSI A-D route for
	the given C-flow. It MUST attach a PTA to that route, and MUST set		the given C-flow. It MUST attach a PTA to that route, and MUST set
	the LIR flag in the PTA. Per [RFC6514], the BFERs that need to		the LIR flag in the PTA. Per [RFC6514], the BFERs that need to
	receive that C-flow will respond with (C-S,C-G) Leaf A-D routes. By		receive that C-flow will respond with (C-S,C-G) Leaf A-D routes. By
	matching the received Leaf A-D routes to the originated S-PMSI A-D		matching the received Leaf A-D routes to the originated S-PMSI A-D
	skipping to change at page 9, line 13 ¶		skipping to change at page 10, line 8 ¶
	this document.		this document.
	This method 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 can now originate as few as one such		BFIR needs to originate; it can now originate as few as one such
	route (a (C-*,C-*) S-PMSI A-D route), rather than one for each		route (a (C-*,C-*) S-PMSI A-D route), rather than one for each
	C-flow. However, the method does not provide a way for the BFIR to		C-flow. However, the method does not provide a way for the BFIR to
	assign a distinct label to each C-flow. Therefore it cannot be used		assign a distinct label to each C-flow. Therefore it cannot be used
	when segmented P-tunnels are in use (see Section 4 for an		when segmented P-tunnels are in use (see Section 4 for an
	explanation).		explanation).
	Note: if a BFIR originates a (C-*,C-*) S-PMSI A-D route with the LIR-		Note: if a BFIR originates a (C-*,C-*) S-PMSI A-D route with the
	pF flag set, but also originates a more specific wildcard route that		LIR-pF flag set, but also originates a more specific wildcard route
	matches a particular (C-S,C-G), the BFERs will not originate Leaf A-D		that matches a particular (C-S,C-G), the BFERs will not originate
	routes for that (C-S,C-G) unless the LIR-pF flag is also set in the		Leaf A-D routes for that (C-S,C-G) unless the LIR-pF flag is also set
	more specific wildcard route. If the BFIR also originates a		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		(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		not originate Leaf A-D routes for that (C-S,C-G) unless the LIR flag
	is also set in that route.		is also set in that route.
	3. Use of the PMSI Tunnel Attribute in Leaf A-D routes		3. Use of the PMSI Tunnel Attribute in Leaf A-D routes
	Before an egress PE can receive a (C-S,C-G) flow from a given ingress		Before an egress PE can receive a (C-S,C-G) flow from a given ingress
	PE via BIER, the egress PE must have received one of the following		PE via BIER, the egress PE must have received one of the following
	x-PMSI A-D routes from the ingress PE:		x-PMSI A-D routes from the ingress PE:
	skipping to change at page 9, line 47 ¶		skipping to change at page 10, line 42 ¶
	The rules for determining which x-PMSI A-D route is the match for		The rules for determining which x-PMSI A-D route is the match for
	reception are given in [RFC6625]. However, these rules are		reception are given in [RFC6625]. However, these rules are
	modified here to exclude any x-PMSI A-D route that does not have a		modified here to exclude any x-PMSI A-D route that does not have a
	PTA, or whose PTA specifies "no tunnel type".		PTA, or whose PTA specifies "no tunnel type".
	If such a route is found, we refer to it as the "matching x-PMSI		If such a route is found, we refer to it as the "matching x-PMSI
	A-D route."		A-D route."
	If no matching x-PMSI A-D route for (C-S,C-G) is found, the egress PE		If no matching x-PMSI A-D route for (C-S,C-G) is found, the egress PE
	cannot receive the (C-S,C-G) flow from the ingress PE via BIER.		cannot receive the (C-S,C-G) flow from the ingress PE via BIER until
			such time as a matching route is received.
	When an egress PE determines that it needs to receive a (C-S,C-G)		When an egress PE determines that it needs to receive a (C-S,C-) flow
	flow from a particular ingress PE via BIER, it originates a Leaf A-D		from a particular ingress PE via BIER, it originates a Leaf A-D
	route. Construction of the Leaf A-D route generally follows the		route. Construction of the Leaf A-D route generally follows the
	procedures specified in [RFC6514], or optionally, the procedures		procedures specified in [RFC6514], or optionally, the procedures
	specified in [EXPLICIT_TRACKING]. However, when BIER is being used,		specified in [EXPLICIT_TRACKING]. However, when BIER is being used,
	the Leaf A-D route MUST carry a PTA that is constructed as follows:		the Leaf A-D route MUST carry a PTA that is constructed as follows:
	1. The tunnel type MUST be set to "BIER".		1. The tunnel type MUST be set to "BIER".
	2. The MPLS label field SHOULD be set to zero.		2. The MPLS label field SHOULD be set to zero.
	3. The sub-domain-id field of the Tunnel Identifier field (as		3. The sub-domain-id field of the Tunnel Identifier field (as
	skipping to change at page 10, line 23 ¶		skipping to change at page 11, line 21 ¶
	the PTA of the matching x-PMSI A-D route.		the PTA of the matching x-PMSI A-D route.
	4. The BFR-Prefix field of the Tunnel Identifier field (as defined		4. The BFR-Prefix field of the Tunnel Identifier field (as defined
	in Section 2) MUST be set to the egress PE's BFR-Prefix in the		in Section 2) MUST be set to the egress PE's BFR-Prefix in the
	sub-domain identifiers in the PTA of the matching x-PMSI A-D		sub-domain identifiers in the PTA of the matching x-PMSI A-D
	route.		route.
	The BFR-Prefix need not be the same IP address that is carried in		The BFR-Prefix need not be the same IP address that is carried in
	any other field of the Leaf A-D route.		any other field of the Leaf A-D route.
	When an ingress PE receives such a Leaf A-D route, it learns the BFR-		When an ingress PE receives such a Leaf A-D route, it learns the
	Prefix of the egress PE from the PTA. The ingress PE does not make		BFR-Prefix of the egress PE from the PTA. The ingress PE does not
	any use the value of the PTA's MPLS label field.		make any use the value of the PTA's MPLS label field.
	Failure to properly construct the PTA cannot always be detected by		Failure to properly construct the PTA cannot always be detected by
	the protocol, and will cause improper delivery of the data packets.		the protocol, and will cause improper delivery of the data packets.
	4. Data Plane		4. Data Plane
	The MVPN application plays the role of the "multicast flow overlay"		The MVPN application plays the role of the "multicast flow overlay"
	as described in [BIER_ARCH].		as described in [BIER_ARCH].
	4.1. Encapsulation and Transmission		4.1. Encapsulation and Transmission
End of changes. 25 change blocks.
	94 lines changed or deleted		135 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/