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-refresh
Show full document text