draft-ietf-idr-rtc-no-rt-02.txt | draft-ietf-idr-rtc-no-rt-03.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 R. Raszuk | Expires: May 14, 2016 J. Haas | |||
Juniper Networks, Inc. | ||||
R. Raszuk | ||||
Bloomberg LP | Bloomberg LP | |||
November 11, 2015 | November 11, 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-02.txt | draft-ietf-idr-rtc-no-rt-03.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 2, line 23 | skipping to change at page 2, line 23 | |||
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 . . . . . . . . . . . . . . . . . . 3 | 2. Some Deployment Scenarios . . . . . . . . . . . . . . . . . . 4 | |||
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 . . . . . . . . . . . . . . . . . 6 | 6.2. Informative References . . . . . . . . . . . . . . . . . 6 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
1. Introduction | 1. Introduction | |||
skipping to change at page 3, line 45 | skipping to change at page 3, line 45 | |||
existing AFI/SAFI. The default behavior may of course be overridden | existing AFI/SAFI. The default behavior may of course be overridden | |||
by 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" in this document are to be interpreted as described in | |||
[RFC2119]. | ||||
2. Some Deployment Scenarios | 2. Some Deployment Scenarios | |||
The lack of a clearly defined default behavior for applying RTC to | The lack of a clearly defined default behavior for applying RTC to | |||
routes that carry no RTs is problematic in at least three scenarios. | 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 SAFI known as "MDT-SAFI". Routes with this SAFI may | defines a BGP SAFI known as "MDT-SAFI". Routes with this SAFI may | |||
carry RTs, but are not required to do so. In order for the | carry RTs, but are not required to do so. In order for the | |||
procedures of [RFC6037] to work properly, if an MDT-SAFI route | procedures of [RFC6037] to work properly, if an MDT-SAFI route | |||
skipping to change at page 6, line 39 | skipping to change at page 7, line 4 | |||
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 | |||
United States | 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 | |||
United States | United States | |||
Email: keyupate@cisco.com | ||||
Jeffrey Haas | ||||
Juniper Networks, Inc. | ||||
1194 N. Mathilda Ave. | ||||
Sunnyvale, California 94089 | ||||
United States | ||||
Email: jhaas@juniper.net | Email: jhaas@juniper.net | |||
Robert Raszuk | Robert Raszuk | |||
Bloomberg LP | Bloomberg LP | |||
731 Lexington Ave | 731 Lexington Ave | |||
New York City, NY 10022 | New York City, NY 10022 | |||
United States | United States | |||
Email: robert@raszuk.net | Email: robert@raszuk.net | |||
End of changes. 7 change blocks. | ||||
5 lines changed or deleted | 16 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/ |