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/