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/