Outbound Route Filtering Capability for BGP-4
RFC 5291
Document | Type | RFC - Proposed Standard (August 2008; No errata) | |
---|---|---|---|
Authors | Enke Chen , Yakov Rekhter | ||
Last updated | 2020-07-29 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5291 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | David Ward | ||
Send notices to | (None) |
Network Working Group E. Chen Request for Comments: 5291 Cisco Systems Category: Standards Track Y. Rekhter Juniper Networks August 2008 Outbound Route Filtering Capability for BGP-4 Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract 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) that the peer would use to constrain/filter its outbound routing updates to the speaker. 1. Introduction Currently, it is not uncommon for a BGP speaker [BGP-4] to receive, and then filter out some unwanted routes from its peers based on its local routing policy. Since the generation and transmission of routing updates by the sender, as well as the processing of routing updates by the receiver consume resources, it may be beneficial if the generation of such unwanted routing updates can be avoided in the first place. 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 peer would then apply these filters, in addition to its locally configured outbound filters (if any), to constrain/filter its outbound routing updates to the speaker. 2. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Chen & Rekhter Standards Track [Page 1] RFC 5291 ORF Capability for BGP-4 August 2008 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, 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 <AFI/SAFI, ORF-Type>. The "AFI/SAFI" component provides a coarse granularity control by limiting the ORF to only the routes whose Network Layer Reachability Information (NLRI) matches the "AFI/SAFI" component of the ORF. The "ORF-Type" component determines the content of the ORF-value. The "Action" component controls handling of the ORF Request by the remote peer. Action can be one of ADD, REMOVE, REMOVE-ALL. ADD adds an ORF entry to the ORF on the remote peer; REMOVE deletes a previously installed ORF entry on the remote peer; REMOVE-ALL deletes the previously installed entries in the specified ORF on the remote peer. The "Match" component is used to support matching granularity on a per ORF entry basis. It can be either PERMIT or DENY. The semantics of PERMIT is to ask the peer to pass updates for the set of routes that match the ORF entry. The semantics of DENY is to ask the peer not to pass updates for the set of routes that match the ORF entry. When an ORF is defined, an ORF-specific matching rule MUST be specified so that there is no ambiguity regarding which ORF entry is considered as the matching entry in the ORF when a route is passed through the ORF. Chen & Rekhter Standards Track [Page 2] RFC 5291 ORF Capability for BGP-4 August 2008 4. Carrying ORF Entries in BGP ORF entries are carried in the BGP ROUTE-REFRESH message [BGP-RR]. A BGP speaker can distinguish an incoming ROUTE-REFRESH message that carries one or more ORF entries from an incoming plain ROUTE-REFRESH message by using the Message Length field in the BGP message header. A single ROUTE-REFRESH message MAY carry multiple ORF entries in one or more ORFs, as long as all these entries share the same AFI/SAFI. From the encoding point of view, each ORF entry consists of a common part and type-specific part, as shown in Figures 1 and 2. The common part consists of <AFI/SAFI, ORF-Type, Action, Match>, and is encoded as follows: The AFI/SAFI component of an ORF entry is encoded in the AFI/SAFI field of the ROUTE-REFRESH message. Following the AFI/SAFI component is the one-octet When-to-refreshShow full document text