IDR S. Hares
Internet-Draft Huawei
Intended status: Standards Track K. Patel
Expires: January 7, 2016 Cisco
July 6, 2015

Analysis of Existing work for I2NSF
draft-ietf-idr-aspath-orf-10.txt

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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."

This Internet-Draft will expire on January 7, 2016.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

The Cooperative Outbound Route Filtering Capability defined in [RFC5292] 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 AS Path based route filtering. The ASpath ORF supports AS path route filtering as well as the regular expression based matching for address groups.

2. ASpath ORF-Type

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

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

3. ASpath ORF encoding

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


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

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

Note the aspath is a variable length hexadecimal string whose length is defined by Length field.

4. Capability Specification for Cooperative route filtering with ASpath

As specified in Cooperative Route Filter[RFC5292], 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 [RFC3392] defined as follows:

   +--------------------------------------------------+
   | 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:

5. ASpath ORF Matching

In addition to the general matching rules defined in [RFC5292], 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 AS path regular expressions to the its (receiver's) interpretation of regular expressions as indicated in the capability announcement.

6. Error handling

ORFs provide information that guides future sending, but any malformed ORF is simply missed filtering information. If ASpath ORF is malformed, the attribute shall simply be discarded.

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 comments.

9. IANA Considerations

No IANA exist for this document.

10. Security Considerations

No security considerations are involved with a gap analysis.

11. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
[RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound Route Filter for BGP-4", RFC 5292, August 2008.

Authors' Addresses

Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA EMail: shares@ndzh.com
Keyur Patel Cisco Milipitas, CA 95035 EMail: keyupate@cisco.com