draft-ietf-idr-route-filter-15.txt   draft-ietf-idr-route-filter-16.txt 
Network Working Group E. Chen Network Working Group E. Chen
Internet Draft Cisco Systems Internet Draft Cisco Systems
Expiration Date: January 2007 Y. Rekhter Expiration Date: March 2007 Y. Rekhter
Juniper Networks Juniper Networks
Outbound Route Filtering Capability for BGP-4 Outbound Route Filtering Capability for BGP-4
draft-ietf-idr-route-filter-15.txt draft-ietf-idr-route-filter-16.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
IPR Disclosure Acknowledgement
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Abstract Abstract
This document defines a BGP-based mechanism that allows a BGP speaker This document defines a BGP-based mechanism that allows a BGP speaker
to send to its BGP peer a set of route filters that the peer would to send to its BGP peer a set of route filters that the peer would
use to constrain/filter its outbound routing updates to the speaker. use to constrain/filter its outbound routing updates to the speaker.
1. Specification of Requirements 1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC-2119]. document are to be interpreted as described in RFC 2119 [RFC-2119].
2. Introduction 2. Introduction
Currently it is not uncommon for a BGP speaker to receive, and then Currently it is not uncommon for a BGP speaker [BGP-4] to receive,
filter out some unwanted routes from its peers based on its local and then filter out some unwanted routes from its peers based on its
routing policy. Since the generation and transmission of routing local routing policy. Since the generation and transmission of
updates by the sender, as well as the processing of routing updates routing updates by the sender, as well as the processing of routing
by the receiver consume resources, it may be beneficial if the updates by the receiver consume resources, it may be beneficial if
generation of such unwanted routing updates can be avoided in the the generation of such unwanted routing updates can be avoided in the
first place. first place.
This document defines a BGP-based mechanism that allows a BGP speaker This document defines a BGP-based mechanism that allows a BGP speaker
to send to its BGP peer a set of Outbound Route Filters (ORFs). The to send to its BGP peer a set of Outbound Route Filters (ORFs). The
peer would then apply these filters, in addition to its locally peer would then apply these filters, in addition to its locally
configured outbound filters (if any), to constrain/filter its configured outbound filters (if any), to constrain/filter its
outbound routing updates to the speaker. outbound routing updates to the speaker.
3. Outbound Route Filter (ORF) 3. Outbound Route Filter (ORF)
This document uses the terms "Address Family Identifier (AFI)" and
"Subsequent Address Family Identifier (SAFI)". In the context of this
document the meaning of these terms is the same as in [BGP-MP].
Conceptually an ORF entry is a tuple of the form <AFI/SAFI, ORF-Type, Conceptually an ORF entry is a tuple of the form <AFI/SAFI, ORF-Type,
Action, Match, ORF-value>; an ORF consists of one or more ORF entries Action, Match, ORF-value>; an ORF consists of one or more ORF entries
that have a common AFI/SAFI and ORF-Type. An ORF is identified by that have a common AFI/SAFI and ORF-Type. An ORF is identified by
<AFI/SAFI, ORF-Type>. <AFI/SAFI, ORF-Type>.
The "AFI/SAFI" component provides a coarse granularity control by The "AFI/SAFI" component provides a coarse granularity control by
limiting the ORF to only the routes whose NLRI matches the "AFI/SAFI" limiting the ORF to only the routes whose NLRI matches the "AFI/SAFI"
component of the ORF. component of the ORF.
The "ORF-Type" component determines the content of the ORF-value. The "ORF-Type" component determines the content of the ORF-value.
skipping to change at page 5, line 31 skipping to change at page 5, line 31
When the Action component of an ORF entry specifies REMOVE-ALL, When the Action component of an ORF entry specifies REMOVE-ALL,
the entry consists of only the common part. the entry consists of only the common part.
5. Outbound Route Filtering Capability 5. Outbound Route Filtering Capability
A BGP speaker that is willing to receive ORF entries from its peer, A BGP speaker that is willing to receive ORF entries from its peer,
or a BGP speaker that would like to send ORF entries to its peer or a BGP speaker that would like to send ORF entries to its peer
advertises this to the peer by using the Outbound Route Filtering advertises this to the peer by using the Outbound Route Filtering
Capability, as described below. Capability, as described below.
The Outbound Route Filtering Capability is a new BGP capability [BGP- The Outbound Route Filtering Capability is a new BGP capability
CAP] defined as follows: [BGP-CAP] defined as follows:
Capability code: 3 Capability code: 3
Capability length: variable Capability length: variable
Capability value: one or more of the entries as shown in Figure 3. Capability value: one or more of the entries as shown in Figure 3.
+--------------------------------------------------+ +--------------------------------------------------+
| Address Family Identifier (2 octets) | | Address Family Identifier (2 octets) |
+--------------------------------------------------+ +--------------------------------------------------+
skipping to change at page 6, line 31 skipping to change at page 6, line 31
+--------------------------------------------------+ +--------------------------------------------------+
| Send/Receive (1 octet) | | Send/Receive (1 octet) |
+--------------------------------------------------+ +--------------------------------------------------+
Figure 3: Outbound Route Filtering Capability Encoding Figure 3: Outbound Route Filtering Capability Encoding
The use and meaning of these fields are as follows: The use and meaning of these fields are as follows:
Address Family Identifier (AFI): Address Family Identifier (AFI):
This field carries the identity of the Network Layer protocol This field is the same as the one used in [BGP-MP].
associated with the Network Address that follows. Presently
defined values for this field are specified in RFC 1700 (see
the Address Family Numbers section).
Subsequent Address Family Identifier (SAFI): Subsequent Address Family Identifier (SAFI):
This field provides additional information about the type of This field is the same as the one used in [BGP-MP].
the Network Layer Reachability Information carried in the
attribute.
Number of ORF Types: Number of ORF Types:
This field contains the number of Filter Types to be listed in This field contains the number of Filter Types to be listed in
the following fields. the following fields.
ORF Type: ORF Type:
This field contains the value of an ORF Type. This field contains the value of an ORF Type.
skipping to change at page 9, line 4 skipping to change at page 8, line 46
to honor. to honor.
During a single BGP session the speaker MAY pass multiple ORF entries During a single BGP session the speaker MAY pass multiple ORF entries
to the peer. to the peer.
After a BGP speaker makes changes to the ORF entries previously sent After a BGP speaker makes changes to the ORF entries previously sent
to a peer, the speaker SHOULD send to the peer the updated ORF to a peer, the speaker SHOULD send to the peer the updated ORF
entries with either (a) When-to-refresh set to IMMEDIATE, or (b) entries with either (a) When-to-refresh set to IMMEDIATE, or (b)
When-to-refresh set to DEFER followed by a ROUTE-REFRESH message. The When-to-refresh set to DEFER followed by a ROUTE-REFRESH message. The
latter SHALL be used by the speaker when there are other policy latter SHALL be used by the speaker when there are other policy
changes (in addition to the ORF entries) that require the peer to re- changes (in addition to the ORF entries) that require the peer to
advertise all the routes. re-advertise all the routes.
The lifetime of an ORF is the duration of the BGP session during The lifetime of an ORF is the duration of the BGP session during
which the ORF is exchanged. which the ORF is exchanged.
An ORF is removed when the last ORF entry is removed (either via An ORF is removed when the last ORF entry is removed (either via
REMOVE-ALL, or via a sequence of REMOVE). REMOVE-ALL, or via a sequence of REMOVE).
If a particular route maintained by a BGP speaker does not match any If a particular route maintained by a BGP speaker does not match any
of the ORF entries of any of the (non-empty) ORFs associated with a of the ORF entries of any of the (non-empty) ORFs associated with a
particular peer, then this route SHOULD NOT be advertised to the particular peer, then this route SHOULD NOT be advertised to the
skipping to change at page 11, line 16 skipping to change at page 11, line 16
Some of the material in the document is adapted from a proposal for Some of the material in the document is adapted from a proposal for
selective updates by Yakov Rekhter, Kannan Varadhan, and Curtis selective updates by Yakov Rekhter, Kannan Varadhan, and Curtis
Villamizar. Villamizar.
12. Normative References 12. Normative References
[BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol [BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol
4 (BGP-4)", RFC 4271, January 2006. 4 (BGP-4)", RFC 4271, January 2006.
[BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, [BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y.,
"Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. "Multiprotocol Extensions for BGP-4", draft-ietf-idr-rfc1858bis-
10.txt.
[BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
BGP-4", RFC 3392, November 2002. BGP-4", RFC 3392, November 2002.
[BGP-RR] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918, [BGP-RR] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
September 2000. September 2000.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 11 change blocks. 
28 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/