< draft-ietf-bier-mvpn-07.txt		draft-ietf-bier-mvpn-08.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: January 27, 2018 Cisco Systems, Inc.		Expires: April 19, 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.
	July 26, 2017		October 16, 2017
	Multicast VPN Using BIER		Multicast VPN Using BIER
	draft-ietf-bier-mvpn-07		draft-ietf-bier-mvpn-08
	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 40 ¶		skipping to change at page 1, line 40 ¶
	over an SP backbone network.		over an SP backbone network.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 https://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 January 27, 2018.		This Internet-Draft will expire on April 19, 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		(https://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 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 . . . . . . . . . . . . . . . . . . . . . . . 7
	2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 8		2.2. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 9
	2.2.1. Using the LIR Flag . . . . . . . . . . . . . . . . . 9		2.2.1. Using the LIR Flag . . . . . . . . . . . . . . . . . 9
	2.2.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . 9		2.2.2. Using the LIR-pF Flag . . . . . . . . . . . . . . . . 10
	3. Use of the PMSI Tunnel Attribute in Leaf A-D routes . . . . . 10		3. Use of the PMSI Tunnel Attribute in Leaf A-D routes . . . . . 11
	4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 11		4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.1. Encapsulation and Transmission . . . . . . . . . . . . . 11		4.1. Encapsulation and Transmission . . . . . . . . . . . . . 12
	4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 12		4.2. Disposition . . . . . . . . . . . . . . . . . . . . . . . 13
	4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 13		4.2.1. At a BFER that is an Egress PE . . . . . . . . . . . 14
	4.2.2. At a BFER that is a P-tunnel Segmentation Boundary . 13		4.2.2. At a BFER that is a P-tunnel Segmentation Boundary . 14
	5. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 13		5. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 14
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 14		8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 15
	9.2. Informative References . . . . . . . . . . . . . . . . . 15		9.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	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 24 ¶		skipping to change at page 5, line 24 ¶
	the route (typically by the ingress PE), and the PTA is not changed		the route (typically by the ingress PE), and the PTA is not changed
	as the route is propagated.		as the route is propagated.
	If segmented P-tunnels are being used, the PTA attached to a given		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		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		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		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		BIER, the segmentation point serves as the BFIR for that next
	segment.		segment.
	In either case, a PTA is constructed by a BFIR as follows:		In either case, a PTA is constructed by a BFIR as follows (see
			Figure 1):
	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 has assigned 0x0B as the tunnel type
	codepoint for "BIER" from the "P-Multicast Service Interface		codepoint for "BIER" in the "P-Multicast Service Interface Tunnel
	Tunnel (PMSI Tunnel) Tunnel Types" registry. This codepoint will		(PMSI Tunnel) Tunnel Types" registry. This codepoint is used to
	be used to indicate that the PMSI is instantiated by BIER.		indicate that the PMSI is instantiated by BIER.
	Although BIER does not actually create tunnels, the MVPN		Although BIER does not actually create tunnels, the MVPN
	procedures treat BIER as if it were a type of tunnel.		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 three subfields:
	1. The first subfield is a single octet, containing a BIER		1. The first subfield is a single octet, containing a BIER
	sub-domain-id. (See [BIER_ARCH].) This indicates that		sub-domain-id. (See [BIER_ARCH].) This indicates that
	packets sent on the PMSI will be sent on the specified BIER		packets sent on the PMSI will be sent on the specified BIER
	sub-domain. How that sub-domain is chosen is outside the		sub-domain. How that sub-domain is chosen is outside the
	scope of this document.		scope of this document.
	2. The second subfield is the BFR-Prefix (see [BIER_ARCH]) of the		2. The second subfield is a two-octet field containing the
	router (a BFIR) that is constructing the PTA. This must be		BFR-id, in the sub-domain identified in the first subfield, of
	the BFIR's BFR-prefix in the specified sub-domain. The		the router that is constructing the PTA.
	BFR-Prefix will either be a /32 IPv4 address or a /128 IPv6
	address. Whether the address is IPv4 or IPv6 can be inferred		3. The third subfield is the BFR-Prefix (see [BIER_ARCH]) of the
	from the total length of the PTA.		router (a BFIR) that is constructing the PTA. The BFR-Prefix
			will either be a /32 IPv4 address or a /128 IPv6 address.
			Whether the address is IPv4 or IPv6 can be inferred 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, even if the BFIR		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.		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 non-		o "MPLS Label". This field MUST contain an upstream-assigned non-
	zero MPLS label. It is assigned by the router (a BFIR) that		zero MPLS label. It is assigned by the router (a BFIR) that
	constructs the PTA. Constraints on the way in which a BFIR		constructs the PTA. Constraints on the way in which a BFIR
	selects this label are discussed in Section 2.1.		selects this label are discussed in 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
	skipping to change at page 6, line 36 ¶		skipping to change at page 7, line 5 ¶
	* "Leaf Info Required per Flow (LIR-pF)". This flag is		* "Leaf Info Required per Flow (LIR-pF)". This flag is
	introduced in [EXPLICIT_TRACKING]. A BFIR SHOULD NOT set this		introduced in [EXPLICIT_TRACKING]. A BFIR SHOULD NOT set this
	flag UNLESS it knows that all the BFERs in the BIER domain (or		flag UNLESS it knows that all the BFERs in the BIER domain (or
	at least all the BFERs to which it needs to transmit) support		at least all the BFERs to which it needs to transmit) support
	this flag. (How this is known is outside the scope of this		this flag. (How this is known is outside the scope of this
	document.) Procedures for the use of this flag are given in		document.) Procedures for the use of this flag are given in
	Section 2.2.2. Support for this flag is OPTIONAL.		Section 2.2.2. Support for this flag is OPTIONAL.
	* "Leaf Info Required Bit". See Section 2.2.1.		* "Leaf Info Required Bit". See Section 2.2.1.
			+---------------------------------+
			| Flags (1 octet) |
			+---------------------------------+
			| Tunnel Type = 0x0B (1 octet) |
			+---------------------------------+
			| MPLS Label (3 octets) |
			+---------------------------------+
			| Sub-domain-id (1 octet) | <---
			+---------------------------------+ |
			| BFIR-id (2 octets) | |-- Tunnel
			+---------------------------------+ | Identifier
			| BFIR-Prefix (4 or 16 octets) | <---
			+---------------------------------+
			Figure 1: PMSI Tunnel Attribute for BIER
	If a PTA specifying tunnel type "BIER" is attached to an x-PMSI A-D		If a PTA specifying tunnel type "BIER" is attached to an x-PMSI A-D
	route, the route MUST NOT be distributed beyond the boundaries of a		route, the route MUST NOT be distributed beyond the boundaries of a
	BIER domain. That is, any routers that receive the route must be in		BIER domain. That is, any routers that receive the route must be in
	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
			The MPLS Label carried in the PTA is an upstream-assigned label.
			If two PTAs contain the same BFR-prefix in their respective Tunnel
			Identifier fields, then the labels carried in those PTAs MUST come
			from the same label space. (See section 7 of [RFC5331].) An
			implementation may choose to use this fact when setting up the tables
			it uses to interpret the upstream-assigned labels.
	Suppose a BFIR attaches a PTA to each of two x-PMSI A-D routes, and		Suppose a BFIR attaches a PTA to each of two x-PMSI A-D routes, and
	both PTAs specify a tunnel type of "BIER".		both PTAs specify a tunnel 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
	skipping to change at page 8, line 11 ¶		skipping to change at page 9, line 5 ¶
	o R1's PTA specifies BFR-Prefix B2 and Label L2.		o R1's PTA specifies BFR-Prefix B2 and Label L2.
	o R2's PTA specifies BFR-Prefix B3 and Label L3.		o R2's PTA specifies BFR-Prefix B3 and Label L3.
	Suppose B1 decides to propagate both R1 and R2, replacing each PTA		Suppose B1 decides to propagate both R1 and R2, replacing each PTA
	with a new PTA specifying BIER. Suppose these new PTAs specify		with a new PTA specifying BIER. Suppose these new PTAs specify
	labels L4 and L5 respectively. Then L4 and L5 MUST be different		labels L4 and L5 respectively. Then L4 and L5 MUST be different
	(upstream-assigned) label values, UNLESS both of the following		(upstream-assigned) label values, UNLESS both of the following
	conditions hold:		conditions hold:
	o R1 and R2 have the same value in the "originating router" field of		o R1 and R2 have the same value in the Originating Router field of
	their respective NLRIs, and		their respective NLRIs, and
	o B2 is equal to B3, and		o B2 is equal to B3, and
	o L2 is equal to L3.		o L2 is equal to L3.
	The segmentation point (B1 in this example) MUST also program its		The segmentation point (B1 in this example) MUST also program its
	dataplane appropriately. For example, when:		dataplane appropriately. For example, when:
	o B1 receives a BIER packet for which it is a BFER, and		o B1 receives a BIER packet for which it is a BFER, and
	skipping to change at page 10, line 45 ¶		skipping to change at page 11, line 38 ¶
	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 until		cannot receive the (C-S,C-G) flow from the ingress PE via BIER until
	such time as a matching route is received.		such time as a matching route is received.
	When an egress PE determines that it needs to receive a (C-S,C-) flow		When an egress PE determines that it needs to receive a (C-S,C-G)
	from a particular ingress PE via BIER, it originates a Leaf A-D		flow 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 subfield of the Tunnel Identifier field (as
	defined in Section 2) MUST be set to the corresponding value from		defined in Section 2) MUST be set to the corresponding value from
	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-id subfield of the Tunnel Identifier field MUST be set to
	in Section 2) MUST be set to the egress PE's BFR-Prefix in the		the BFR-id, in the sub-domain identified by the sub-domain-id
	sub-domain identifiers in the PTA of the matching x-PMSI A-D		subfield, of the egress PE.
	route.
			5. The BFR-Prefix field of the Tunnel Identifier field (as defined
			in Section 2) MUST be set to the egress PE's BFR-Prefix.
	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		When an ingress PE receives such a Leaf A-D route, it learns the
	BFR-Prefix of the egress PE from the PTA. The ingress PE does not		BFR-Prefix of the egress PE from the PTA. The ingress PE does not
	make 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.
	skipping to change at page 12, line 41 ¶		skipping to change at page 13, line 33 ¶
	procedures of [BIER_ARCH] and [BIER_ENCAPS]. (See especially		procedures of [BIER_ARCH] and [BIER_ENCAPS]. (See especially
	Section 4, "Imposing and Processing the BIER Encapsulation", of		Section 4, "Imposing and Processing the BIER Encapsulation", of
	[BIER_ENCAPS].)		[BIER_ENCAPS].)
	4.2. Disposition		4.2. Disposition
	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, the BIER layer passes the following information to		BIER-encapsulated, the BIER layer passes the following information to
	the multicast flow overlay:		the multicast flow overlay:
	o The BFR-prefix corresponding to the sub-domain-id and BFIR-id in		o The sub-domain-id and the BFIR-id from the BIER header. (As the
	the BIER header.		sub-domain-id is inferred from the BIFT-id field of the BIER
			header, an implementation might choose to pass the BIFT-id rather
			than the sub-domain-id; this is an implementation matter.)
	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. In the dataplane, the BFIR-id and the
	which the upstream-assigned label is interpreted.		sub-domain-id provide the context in which the upstream-assigned
			label is interpreted.
	Note that per [RFC5331], the context for an upstream-assigned
	label is the IP address of the label assigner, which in this case
	is the BFR-prefix of the BFIR.
	By looking up the upstream-assigned label in the appropriate context,		By looking up the upstream-assigned label in the appropriate context,
	the multicast flow overlay determines whether the BFER is an egress		the multicast flow overlay determines whether the BFER is an egress
	PE for the packet.		PE for the packet.
	Note that if segmented P-tunnels are in use, a BFER might be a		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		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		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		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		need to follow the procedures of Section 4.2.1, the procedures of
	skipping to change at page 14, line 13 ¶		skipping to change at page 14, line 47 ¶
	Email: ice@cisco.com		Email: ice@cisco.com
	6. Acknowledgments		6. 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. We also thank Stig Venaas for his review		contributions to this work. We also thank Stig Venaas for his review
	and comments.		and comments.
	7. IANA Considerations		7. IANA Considerations
	IANA is requested to assign a value for "BIER" from the "P-Multicast		IANA has assigned the codepoint 0x0B to "BIER" in the "P-Multicast
	Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry. The		Service Interface Tunnel (PMSI Tunnel) Tunnel Types" registry.
	reference should be this document.
	8. Security Considerations		8. 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		9. References
	9.1. Normative References		9.1. Normative References
	skipping to change at page 14, line 41 ¶		skipping to change at page 15, line 29 ¶
	[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
	Replication in MPLS Networks", internet-draft draft-ietf-		Replication in MPLS Networks", internet-draft draft-ietf-
	bier-mpls-encapsulation-07.txt, June 2017.		bier-mpls-encapsulation-07.txt, June 2017.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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, DOI 10.17487/RFC4364, February		Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
	2006, <http://www.rfc-editor.org/info/rfc4364>.		2006, <https://www.rfc-editor.org/info/rfc4364>.
	[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream		[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
	Label Assignment and Context-Specific Label Space",		Label Assignment and Context-Specific Label Space",
	RFC 5331, DOI 10.17487/RFC5331, August 2008,		RFC 5331, DOI 10.17487/RFC5331, August 2008,
	<http://www.rfc-editor.org/info/rfc5331>.		<https://www.rfc-editor.org/info/rfc5331>.
	[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/		[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
	BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February		BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
	2012, <http://www.rfc-editor.org/info/rfc6513>.		2012, <https://www.rfc-editor.org/info/rfc6513>.
	[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>.		<https://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>.		<https://www.rfc-editor.org/info/rfc6625>.
	9.2. Informative References		9.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-02,		VPN", internet-draft draft-ietf-bess-mvpn-expl-track-02,
	June 2017.		June 2017.
	[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>.		<https://www.rfc-editor.org/info/rfc7524>.
	[RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y.,		[RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y.,
	and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs",		and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs",
	RFC 7900, DOI 10.17487/RFC7900, June 2016,		RFC 7900, DOI 10.17487/RFC7900, June 2016,
	<http://www.rfc-editor.org/info/rfc7900>.		<https://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 16, line 19 ¶		skipping to change at page 17, 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
	Nokia		Nokia
	600 March Rd.		438B Alexandra Rd #08-07/10
	Ottawa, Ontario K2K 2E6		Alexandra Technopark
	Canada		Singapore 119968
	Email: andrew.dolganow@nokia.com		Email: andrew.dolganow@nokia.com
	Tony Przygienda		Tony Przygienda
	Juniper Networks, Inc.		Juniper Networks, Inc.
	1137 Innovation Way		1137 Innovation Way
	San Jose, California 94089		San Jose, California 94089
	United States		United States
	Email: prz@juniper.net		Email: prz@juniper.net
End of changes. 34 change blocks.
	66 lines changed or deleted		94 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/