Outbound Route Filtering Capability for BGP-4
RFC 5291

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 17

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