<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.ietf-idr-rtc-no-rt" target="https://datatracker.ietf.org/doc/html/draft-ietf-idr-rtc-no-rt-12">
   <front>
      <title>Route Target Constrained Distribution of Routes with no Route Targets</title>
      <author initials="E. C." surname="Rosen" fullname="Eric C. Rosen">
         <organization>Unaffiliated</organization>
      </author>
      <author initials="K." surname="Patel" fullname="Keyur Patel">
         <organization>Arccus</organization>
      </author>
      <author initials="J." surname="Haas" fullname="Jeffrey Haas">
         <organization>Juniper Networks</organization>
      </author>
      <author initials="R." surname="Raszuk" fullname="Robert Raszuk">
         <organization>Bloomberg LP</organization>
      </author>
      <date month="October" day="1" year="2019" />
      <abstract>
	 <t>   There are a variety of BGP-enabled services in which the originator
   of a BGP route may attach one or more &quot;Route Targets&quot; to the route.
   By means of a procedure known as &quot;RT Constrained Distribution&quot; (RTC),
   a given BGP speaker (call it &quot;B&quot;) can announce the set of RTs in
   which it has interest.  The implication is that if a particular route
   (call it &quot;R&quot;) 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
   carried by R.  However, if route R does not carry any RTs at all,
   prior specifications do not make it clear whether B&#x27;s use of RTC
   implies that it does not want to receive route R.  This has caused
   interoperability problems in the field, as some implementations of
   RTC do not allow B to receive R, but some services presuppose that B
   will receive R.  This document updates RFC 4684 by clarifying the
   effect of the RTC mechanism on routes that do not have any RTs.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-idr-rtc-no-rt-12" />
   
</reference>
