draft-ietf-idr-rtc-no-rt-01.txt		draft-ietf-idr-rtc-no-rt-02.txt
	IDR Working Group E. Rosen, Ed.		IDR Working Group E. Rosen, Ed.
	Internet-Draft Juniper Networks, Inc.		Internet-Draft Juniper Networks, Inc.
	Intended status: Standards Track K. Patel		Updates: 4684 (if approved) K. Patel
	Expires: December 31, 2015 Cisco Systems, Inc.		Intended status: Standards Track Cisco Systems, Inc.
	J. Haas		Expires: May 14, 2016 R. Raszuk
	Juniper Networks, Inc.		Bloomberg LP
	R. Raszuk		November 11, 2015
	Mirantis Inc.
	June 29, 2015
	Route Target Constrained Distribution of Routes with no Route Targets		Route Target Constrained Distribution of Routes with no Route Targets
	draft-ietf-idr-rtc-no-rt-01.txt		draft-ietf-idr-rtc-no-rt-02.txt
	Abstract		Abstract
	BGP routes sometimes carry an "Extended Communities" path attribute.		There are a variety of BGP-enabled services in which the originator
	An Extended Communities path attribute can contain one or more "Route		of a BGP route may attach one or more "Route Targets" to the route.
	Targets" (RTs). By means of a procedure known as "RT Constrained		By means of a procedure known as "RT Constrained Distribution" (RTC),
	Distribution" (RTC), a BGP speaker can send BGP UPDATE messages that		a given BGP speaker (call it "B") can announce the set of RTs in
	express its interest in a particular set of RTs. Generally, RTC has		which it has interest. The implication is that if a particular route
	been applied only to address families whose routes always carry RTs.		(call it "R") carries any RTs at all, BGP speaker B wants to receive
	When RTC is applied to such an address family, a BGP speaker		route R if and only if B has announced interest in one of the RTs
	expressing its interest in a particular set of RTs is indicating that		carried by R. However, if route R does not carry any RTs at all,
	it wants to receive all and only the routes of that address family		prior specifications do not make it clear whether B's use of RTC
	that have at least one of the RTs of interest. However, there are		implies that it does not want to receive route R. This has caused
	scenarios in which the originator of a route chooses not to include		interoperability problems in the field, as some implementations of
	any RTs at all, assuming that the distribution of a route with no RTs		RTC do not allow B to receive R, but some services presuppose that B
	at all will be unaffected by RTC. This has led to interoperability		will receive R. This document updates RFC 4684 by clarifying the
	problems in the field, where the originator of a route assumes that		effect of the RTC mechanism on routes that do not have any RTs.
	RTC will not affect the distribution of the route, but intermediate
	BGP speakers refuse to distribute that route because it does not
	carry any RT of interest. The purpose of this document is to clarify
	the effect of the RTC mechanism on routes that do not have any RTs.
	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 http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 31, 2015.		This Internet-Draft will expire on May 14, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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. Some Deployment Scenarios . . . . . . . . . . . . . . . . . . 4		2. Some Deployment Scenarios . . . . . . . . . . . . . . . . . . 3
	3. Default Behavior . . . . . . . . . . . . . . . . . . . . . . 4		3. Default Behavior . . . . . . . . . . . . . . . . . . . . . . 4
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 5		5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	6.1. Normative References . . . . . . . . . . . . . . . . . . 5		6.1. Normative References . . . . . . . . . . . . . . . . . . 5
	6.2. Informative References . . . . . . . . . . . . . . . . . 5		6.2. Informative References . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
	1. Introduction		1. Introduction
	A BGP route can carry a particular type of BGP path attribute known		A BGP route can carry a particular type of BGP path attribute known
	as an "Extended Communities Attribute" [RFC4360]. Each such		as an "Extended Communities Attribute" [RFC4360]. Each such
	attribute can contain a variable number of typed communities.		attribute can contain a variable number of typed communities.
	Certain typed communities are known as "Route Targets" (RTs)		Certain typed communities are known as "Route Targets" (RTs)
	([RFC4360], [RFC4364]).		([RFC4360], [RFC4364]).
	[RFC4684] defines a procedure, known as "RT Constrained Distribution"		[RFC4684] defines a procedure, known as "RT Constrained Distribution"
	(RTC) that allows a BGP speaker to advertise its interest in a		(RTC) that allows a BGP speaker to advertise its interest in a
	particular set of RTs. It does so by advertising "RT membership		particular set of RTs. It does so by advertising "RT membership
	information". (See [RFC4684] for details.) It may advertise RT		information". (See [RFC4684] for details.) It may advertise RT
	membership for any number of RTs. By advertising membership for a		membership for any number of RTs. By advertising membership for a
	particular RT, a BGP speaker declares that it is interested in		particular RT, a BGP speaker declares that it is interested in
	receiving BGP routes that carry that RT.		receiving BGP routes that carry that RT.
	If RTC is enabled on a particular BGP session, the session must be		If RTC is enabled on a particular BGP session, the session must be
	provisioned with the set of "address family" and "subsequent address		provisioned with the set of "address family" and "subsequent address
	family" (AFI/SAFIs) values to which RTC is to be applied. In		family" values (AFI/SAFIs) to which RTC is to be applied. In
	[RFC4684] it is implicitly assumed that RTC will only by applied to		[RFC4684] it is implicitly assumed that RTC will only be applied to
	AFI/SAFIs where all the routes carry RTs. When this assumption is		AFI/SAFIs for which all the routes carry RTs. When this assumption
	true, the RTC semantics are clear. A BGP speaker advertising its		is true, the RTC semantics are clear. A BGP speaker advertising its
	interest in RT1, RT2, ..., RTk is saying that, for the AFI/SAFIs to		interest in RT1, RT2, ..., RTk is saying that, for the AFI/SAFIs to
	which RTC is being applied, it is interested in any route that		which RTC is being applied, it is interested in any route that
	carries at least one of those RTs, and it is not interested in any		carries at least one of those RTs, and it is not interested in any
	route that does not carry at least one of those RTs.		route that does not carry at least one of those RTs.
	However, [RFC4684] does not specify how the RTC procedures are to be		However, [RFC4684] does not specify how the RTC procedures are to be
	applied to address families whose routes sometimes carry RTs and		applied to AFI/SAFIs whose routes sometimes carry RTs and sometimes
	sometimes do not. Consider a BGP session between routers R1 and R2,		do not. Consider a BGP session between routers R1 and R2, where R1
	where R1 has advertised its interest in RT1, RT2, ..., RTk, and RTC		has advertised its interest in RT1, RT2, ..., RTk, and RTC is being
	is being applied to a particular AFI/SAFI. Suppose R2 has a route of		applied to a particular AFI/SAFI. Suppose R2 has a route of that
	that AFI/SAFI, and that route carries no RTs. Should R2 advertise		AFI/SAFI, and that route carries no RTs. Should R2 advertise this
	this route to R1 or not?		route to R1 or not?
	There are two different answers to this question, each of which seems		There are two possible answers to this question, each of which seems
	prima facie reasonable:		prima facie reasonable:
	o No, R2 should not advertise the route, because it belongs to an		o No, R2 should not advertise the route, because it belongs to an
	AFI/SAFI to which RTC is being applied, and the route does carry		AFI/SAFI to which RTC is being applied, and the route does carry
	any of the RTs in which R1 is interested.		any of the RTs in which R1 is interested.
	o Yes, R2 should advertise the route; since the route carries no		o Yes, R2 should advertise the route; since the route carries no
	RTs, the intention of the route's originator is that the		RTs, the intention of the route's originator is that the
	distribution of the route not be constrained by the RTC mechanism.		distribution of the route not be constrained by the RTC mechanism.
	As might be expected, "one size does not fit all", and the best		As might be expected, "one size does not fit all". The best answer
	answer depends upon the particular deployment scenario, and upon the		depends upon the particular deployment scenario, and upon the
	particular AFI/SAFI to which RTC is being applied.		particular AFI/SAFI to which RTC is being applied.
	Section 3 defines a default behavior for each existing AFI/SAFI.		Section 3 defines a default behavior for existing AFI/SAFIs. This
	This default behavior will ensure proper operation of that AFI/SAFI		default behavior ensures proper operation when RTC is applied to an
	when RTC is applied. The default behavior may of course be		existing AFI/SAFI. The default behavior may of course be overridden
	overridden by a local policy.		by local policy.
	Section 3 also defines a default "default behavior" for new AFI/		Section 3 also defines a default "default behavior" for new AFI/
	SAFIs. When a new AFI/SAFI is defined, the specification defining it		SAFIs. When a new AFI/SAFI is defined, the specification defining it
	may specify a different default behavior; otherwise the default		may specify a different default behavior; otherwise the default
	default behavior will apply.		default behavior will apply.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" are to be interpreted as described in [RFC2119].		"OPTIONAL" are to be interpreted as described in [RFC2119].
	2. Some Deployment Scenarios		2. Some Deployment Scenarios
	There are at least three deployment scenarios where lack of a clearly		The lack of a clearly defined default behavior for applying RTC to
	defined default behavior for RTC is problematic.		routes that carry no RTs is problematic in at least three scenarios.
	o [RFC6037] describes a deployed Multicast VPN (MVPN) solution. It		o [RFC6037] describes a deployed Multicast VPN (MVPN) solution. It
	defines a BGP address family known as "MDT-SAFI". Routes of this		defines a BGP SAFI known as "MDT-SAFI". Routes with this SAFI may
	address family may carry RTs, but are not required to do so. In		carry RTs, but are not required to do so. In order for the
	order for the RFC6037 procedures to work properly, if an MDT-SAFI		procedures of [RFC6037] to work properly, if an MDT-SAFI route
	route does not carry any RTs, the distribution of that route must		does not carry any RTs, the distribution of that route MUST NOT be
	not be constrained by RTC. However, if an MDT-SAFI route does		constrained by RTC. However, if an MDT-SAFI route does carry one
	carry one or more RTs, its distribution may be constrained by RTC.		or more RTs, its distribution SHOULD be constrained by RTC.
	o [GTM] specifies a way to provide "global table" (as opposed to		o [GTM] specifies a way to provide "Global Table Multicast" (as
	VPN) multicast, using procedures that are very similar to those		opposed to VPN multicast), using procedures that are very similar
	described in [RFC6513] and [RFC6514] for MVPN. In particular, it		to those described in [RFC6513] and [RFC6514] for MVPN. In
	uses routes of the MCAST-VPN address family that is defined in		particular, it uses routes of the MCAST-VPN SAFI that is defined
	[RFC6514]. When used for MVPN, each MCAST-VPN route carries at		in [RFC6514]. When used for MVPN, each MCAST-VPN route carries at
	least one RT. However, when used for global table multicast, it		least one RT. However, when used for Global Table Multicast, it
	is optional for certain MCAST-VPN route types to carry RTs. In		is optional for certain MCAST-VPN routes to carry RTs. In order
	order for the procedures of [GTM] to work properly, if an MCAST-		for the procedures of [GTM] to work properly, if an MCAST-VPN
	VPN route does not carry any RTs, the distribution of that route		route does not carry any RTs, the distribution of that route MUST
	must not be constrained by RTC.		NOT be constrained by RTC.
	o Typically, Route Targets have been carried only by routes that are		o Typically, Route Targets have been carried only by routes that are
	distributed as part of a VPN service. However, it may be		distributed as part of a VPN service (or the Global
			Table Multicast service mentioned above). However, it may be
	desirable to be able to place RTs on non-VPN routes (e.g., on		desirable to be able to place RTs on non-VPN routes (e.g., on
	unicast IPv4 or IPv6 routes) and then to use RTC to constrain the		unicast IPv4 or IPv6 routes) and then to use RTC to constrain the
	delivery of the non-VPN routes. For example, if a BGP speaker		delivery of the non-VPN routes. For example, if a BGP speaker
	desires to receive only a small set of IPv4 unicast routes, and		desires to receive only a small set of IPv4 unicast routes, and
	the desired routes carry one or more RTs, the BGP speaker could		the desired routes carry one or more RTs, the BGP speaker could
	use RTC to advertise its interest in one or more of those RTs. In		use RTC to advertise its interest in one or more of those RTs. In
	this application, the intention would be that any IPv4 unicast		this application, the intention would be that any IPv4 unicast
	route not carrying an RT would be filtered. Note that this is the		route not carrying an RT would be filtered. Note that this is the
	opposite of the behavior needed for the other use cases discussed		opposite of the behavior needed for the other use cases discussed
	in this section.		in this section.
	3. Default Behavior		3. Default Behavior
	In order to handle the use cases discussed in Section 3, this		In order to handle the use cases discussed in Section 2, this
	document specifies a default behavior for the case where RTC is		document specifies a default behavior for the case where RTC is
	applied to a particular address family (AFI/SAFI), and some (or all)		applied to a particular AFI/SAFI, and some (or all) routes of that
	routes of that address family do not carry any RTs.		address family do not carry any RTs.
	When RTC is applied, on a particular BGP session, to routes of the		When RTC is applied, on a particular BGP session, to routes of the
	MDT-SAFI address family (SAFI=66), the default behavior is that		MDT-SAFI address family (SAFI=66, [RFC6037]), the default behavior
	routes that do not carry any RTs are distributed on that session.		MUST be that routes that do not carry any RTs are distributed on that
			session.
	When RTC is applied, on a particular BGP session, to routes of the		When RTC is applied, on a particular BGP session, to routes of the
	MCAST-VPN address family (SAFI=5), the default behavior is that		MCAST-VPN address family (SAFI=5, [RFC6514], [GTM]), the default
	routes that do not carry any RTs are distributed on that session.		behavior MUST be that routes that do not carry any RTs are
			distributed on that session.
	When RTC is applied, on a particular BGP session, to routes of other		When RTC is applied, on a particular BGP session, to routes of other
	address families, the default behavior is that routes without any RTs		address families, the default behavior MUST be that routes without
	are not distributed on that session. This default "default behavior"		any RTs are not distributed on that session. This default "default
	applies to all AFI/SAFIs for which a different default behavior has		behavior" applies to all AFI/SAFIs for which a different default
	not been defined.		behavior has not been defined.
	A BGP speaker may be provisioned to apply a non-default behavior to a		A BGP speaker MAY be provisioned to apply a non-default behavior to a
	given AFI/SAFI. This is a matter of local policy.		given AFI/SAFI. This is a matter of local policy.
	4. IANA Considerations		4. IANA Considerations
	This document contains no actions for IANA.		This document contains no actions for IANA.
	5. Security Considerations		5. Security Considerations
	No security considerations are raised by this document beyond those		The security considerations of [RFC4684] apply.
	already discussed in [RFC4684].
			The procedures of this document may allow the distribution of certain
			SAFI-5 and SAFI-66 routes, in situations where some implementations
			of RTC would previously have prevented their distribution. However,
			it is necessary to distribute such routes in order for the
			applications using them to operate properly. Allowing the
			distribution of such routes does not create any new security
			considerations beyond those of the applications that use the routes.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended		[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
	Communities Attribute", RFC 4360, February 2006.		Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
			February 2006, <http://www.rfc-editor.org/info/rfc4360>.
	[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,		[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
	R., Patel, K., and J. Guichard, "Constrained Route		R., Patel, K., and J. Guichard, "Constrained Route
	Distribution for Border Gateway Protocol/MultiProtocol		Distribution for Border Gateway Protocol/MultiProtocol
	Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual		Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
	Private Networks (VPNs)", RFC 4684, November 2006.		Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
			November 2006, <http://www.rfc-editor.org/info/rfc4684>.
	6.2. Informative References		6.2. Informative References
	[GTM] Zhang, J., Giulano, L., Rosen, E., Subramanian, K.,		[GTM] Zhang, J., Giulano, L., Rosen, E., Subramanian, K., and D.
	Pacella, D., and J. Schiller, "Global Table Multicast with		Pacella, "Global Table Multicast with BGP-MVPN
	BGP-MVPN Procedures", internet-draft draft-ietf-l3vpn-		Procedures", internet-draft draft-ietf-bess-mvpn-global-
	mvpn-global-table-mcast-01, May 2015.		table-mcast-03, September 2015.
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, February 2006.		Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
			2006, <http://www.rfc-editor.org/info/rfc4364>.
	[RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems'		[RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco
	Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037,		Systems' Solution for Multicast in BGP/MPLS IP VPNs",
	October 2010.		RFC 6037, DOI 10.17487/RFC6037, October 2010,
			<http://www.rfc-editor.org/info/rfc6037>.
	[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP		[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
	VPNs", RFC 6513, February 2012.		BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
			2012, <http://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, February 2012.		VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
			<http://www.rfc-editor.org/info/rfc6514>.
	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
	USA		United States
	Email: erosen@juniper.net		Email: erosen@juniper.net
	Keyur Patel		Keyur Patel
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 Tasman Drive		170 Tasman Drive
	San Jose, California 95134		San Jose, California 95134
	US		United States
	Email: keyupate@cisco.com
	Jeffrey Haas
	Juniper Networks, Inc.
	1194 N. Mathilda Ave.
	Sunnyvale, California 94089
	US
	Email: jhaas@juniper.net		Email: jhaas@juniper.net
	Robert Raszuk		Robert Raszuk
	Mirantis Inc.		Bloomberg LP
	615 National Ave. #100		731 Lexington Ave
	Mountain View, California 94043		New York City, NY 10022
	US		United States
	Email: robert@raszuk.net		Email: robert@raszuk.net
End of changes. 34 change blocks.
	108 lines changed or deleted		111 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/