[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 04 05 06 07 08 09 10 11 12 13

Network Working Group                                       Keyur Patel
Internet Draft                                             AYR Networks
Expiration Date: October 2002                               Susan Hares
                                                   Nexthop Technologies

               Aspath Based Outbound Route Filter for BGP-4


1. Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

2. Abstract

   This document defines a new Outbound Router Filter type for BGP,
   termed "Aspath Outbound Route Filter", that can be used to perform
   aspath based route filtering. This ORF-type supports aspath based
   route filtering as well as regular expression based matching, for
   address groups.

Patel, Hares                                                    [Page 1]

Internet Draft      draft-ietf-idr-aspath-orf-03.txt         April  2002

3. Introduction

   The Cooperative Outbound Route Filtering Capability defined in [BGP-
   ORF] provides a mechanism for a BGP speaker to send to its BGP peer a
   set of Outbound Route Filters (ORFs) that can be used by its peer to
   filter its outbound routing updates to the speaker.

   This documents defines a new ORF-type for BGP, termed "Aspath
   Outbound Route Filter (Aspath ORF)", that can be used to
   perform Aspath based route filtering. The Aspath ORF supports Aspath
   route filtering as well as the regular expression based matching for
   address groups.

4. Aspath ORF-Type

   The Aspath ORF-Type allows one to express ORFs in terms of
   regular expression and aspath numbers. That is, it provides aspath
   based route filtering, including regular expression based matching.

   Conceptually an Aspath ORF entry consists of the fields
   <Sequence, Match, Length, Aspath>.

   The "Sequence" field is a number that specifies the relative ordering
   of the entry.

   The "Match" field specifies whether this entry is "PERMIT" (value 0),
   or "DENY" (value 1).

   The "Length" field indicates the length of aspath regular expression

   The "Aspath" field contains an aspath regular expression of an
   address group.

   The field "Sequence" is an unsigned 32 bit value. The field "Length"
   is an unsigned 16 bit value. The field "Aspath" is a variable length
   hexadecimal string. The field "Aspath" will be followed by enough
   trailing bits to make end of field fall on an octet boundry. Note
   that the value of trailing bits is irrelevant.

Patel, Hares                                                    [Page 2]

Internet Draft      draft-ietf-idr-aspath-orf-03.txt         April  2002

5. Aspath ORF Encoding

   The value of the ORF-Type for the Aspath ORF-Type is <TBD>.

   An Aspath ORF entry is encoded as follows. The "Match" field
   of the entry is encoded in the "Match" field of the common part
   [BGP-ORF], and the remaining fields of the entry is encoded in the
   "Type specific part" as follows.

               |   Sequence (4 octets)          |
               |   Length   (2 octet)           |
               |   Aspath   ( variable length)  |

   Note that the Aspath field is varibale length hexadecimal string
   whose length is defined by Length field.

Patel, Hares                                                    [Page 3]

Internet Draft      draft-ietf-idr-aspath-orf-03.txt         April  2002

6.) Capability Specification for Cooperative route filtering with ASpath

   As specified in the Coperative Router filtering draft
   [draft-ietf-idr-route-filter-05.txt], 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
   advertises this to the peer by using the Cooperative Route Filtering
   Capability uses a new BGP capability [BGP-CAP] defined as follows:

      Capability code: 3

      Capability length: variable
      Capability value: one or more of the following entries:

            | Address Family Identifier (2 octets)             |
            | Reserved (1 octet)                               |
            | Subsequent Address Family Identifier (1 octet)   |
            | Number of ORFs (1 octet)                         |
            | ORF Type (1 octet)                               |
            | Send/Receive (1 octet)                           |
            | ...                                              |
            | ORF Type (1 octet)                               |
            | Send/Receive (1 octet)                           |

            Fig 4. Capability encoding

   The use and meaning of these fields are as follows:

      Address Family Identifier (AFI):

         This field carries the identity of the Network Layer protocol
         associated with the Network Address that follows. Presently
         defined values for this field are specified in RFC1700 (see the
         Address Family Numbers section).

      Subsequent Address Family Identifier (SAFI):

         This field provides additional information about the type of
         the Network Layer Reachability Information carried in the

      Number of ORF Types:

         This field contains the number of Filter Types to be listed in
         the following fields.

      ORF Type:

         This field contains the value of an ORF Type.


         This field indicates whether the sender is (a) willing to
         receive ORF entries from its peer (value 1), (b) would like to
         send ORF entries to its peer (value 2), or (c) both (value 3)
         for the ORF Type that follows.

        In the upper bits of the Send/Receive byte the top three
        bits have the following encoding:  [FFFKKKSR]
        where bit 0 is the left most bit.

        Where - S = Send ORF for ASpath
                R = Receive ORF for ASpath

        Where KKK is a 3 bit field reserved for future expansion of
                  regular expression differences in ORF.

        Where FFF indicates 3 bits.  Bit 0 is the left most bit,
        Bit 1 is the middle bit and Bit 2 is the right most bit.

        bit 0 - anchors
          0 - full length regex, ie: implicit anchoring of AsPath as in
          1 - partial as-path regex with anchoring.  ie: the regex may
              or may not have anchors and thus may be a partial match.
               anchoring       non-anchoring
               ^X        ->      X .*
               ^X$       ->      X
               X         ->      .* X .*

       bit 1 - "." wildcard operator [Collating Element]
          0 - traditional application of "." as wildcard, ie: "." matches
              any single character of the set [0-9 ].
          1 - "." matches an AS-path token/term,
              regex "." == traditional regex "[0-9]+"

       bit 2 - "[]" operator
          0 - not supported.
          1 - supported, eg: [0-9]

7. Aspath ORF Matching

   In addition to the general matching rules defined in [BGP-ORF],
   several Aspath ORF specific matching rules are defined as follows.

   It is possible that the speaker would have more than one Aspath
   ORF entry that matches the route. In that case the "first-match" rule
   applies. That is, the ORF entry with the smallest sequence number
   among all the matching ORF entries) is considered as the sole match,
   and it would determine whether the route should be advertised.

   If any speaker does not support capabilities specified by the
   receiver but still decide to establish the connection, the
   receiver is expected to translate the Aspath regular
   expressions to the its (receiver's) interpretation of regular
   expressions as indicated in the capability announcement.

Patel, Hares                                                    [Page 4]

Internet Draft      draft-ietf-idr-aspath-orf-03.txt          April 2002

7. Security Considerations

   This extension to BGP does not change the underlying security issues.

8. Acknowledgements

   We express our thanks to Andrew Partan,Avneesh Sachdev, Alec Peterson,
   Enke Chen, John Heasley, Dorian Kim and Bruce Cole for their

9. References

   [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-
   4)", RFC 1771, March 1995.

   [BGP-ORF] Chen, E., and Rekhter, Y., "Cooperative Route Filtering
   Capability for BGP-4", draft-ietf-idr-route-filter-05.txt, January

10. Author Information

   Keyur Patel
   AYR Networks. Inc.
   3977 East Bayshore Road, suite 200
   Palo Alto, CA 94303
   email: keyur@ayrnetworks.com

   Susan Hares
   NextHop Technologies. Inc.
   517 W. Williams
   Ann Arbor, MI 48103-4943
   email: skh@nexthop.com

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/