draft-ietf-idr-rtc-no-rt-03.txt		draft-ietf-idr-rtc-no-rt-04.txt
	IDR Working Group E. Rosen, Ed.		IDR Working Group E. Rosen, Ed.
	Internet-Draft Juniper Networks, Inc.		Internet-Draft Juniper Networks, Inc.
	Updates: 4684 (if approved) K. Patel		Updates: 4684 (if approved) K. Patel
	Intended status: Standards Track Cisco Systems, Inc.		Intended status: Standards Track Cisco Systems, Inc.
	Expires: May 14, 2016 J. Haas		Expires: May 16, 2016 J. Haas
	Juniper Networks, Inc.		Juniper Networks, Inc.
	R. Raszuk		R. Raszuk
	Bloomberg LP		Bloomberg LP
	November 11, 2015		November 13, 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-03.txt		draft-ietf-idr-rtc-no-rt-04.txt
	Abstract		Abstract
	There are a variety of BGP-enabled services in which the originator		There are a variety of BGP-enabled services in which the originator
	of a BGP route may attach one or more "Route Targets" to the route.		of a BGP route may attach one or more "Route Targets" to the route.
	By means of a procedure known as "RT Constrained Distribution" (RTC),		By means of a procedure known as "RT Constrained Distribution" (RTC),
	a given BGP speaker (call it "B") can announce the set of RTs in		a given BGP speaker (call it "B") can announce the set of RTs in
	which it has interest. The implication is that if a particular route		which it has interest. The implication is that if a particular route
	(call it "R") carries any RTs at all, BGP speaker B wants to receive		(call it "R") carries any RTs at all, BGP speaker B wants to receive
	route R if and only if B has announced interest in one of the RTs		route R if and only if B has announced interest in one of the RTs
	skipping to change at page 1, line 48		skipping to change at page 1, line 48
	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 May 14, 2016.		This Internet-Draft will expire on May 16, 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
	skipping to change at page 3, line 22		skipping to change at page 3, line 22
	do not. Consider a BGP session between routers R1 and R2, where R1		do not. Consider a BGP session between routers R1 and R2, where R1
	has advertised its interest in RT1, RT2, ..., RTk, and RTC is being		has advertised its interest in RT1, RT2, ..., RTk, and RTC is being
	applied to a particular AFI/SAFI. Suppose R2 has a route of that		applied to a particular AFI/SAFI. Suppose R2 has a route of that
	AFI/SAFI, and that route carries no RTs. Should R2 advertise this		AFI/SAFI, and that route carries no RTs. Should R2 advertise this
	route to R1 or not?		route to R1 or not?
	There are two possible 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 not
	any of the RTs in which R1 is interested.		carry 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". The best answer		As might be expected, "one size does not fit all". The best 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 existing AFI/SAFIs. This		Section 3 defines a default behavior for existing AFI/SAFIs. This
End of changes. 5 change blocks.
	6 lines changed or deleted		6 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/