Network Working Group                                       Keyur
IDR                                                             S. Hares
Internet-Draft                                                    Huawei
Intended status: Standards Track                                K. Patel
Internet Draft
Expires: January 6, 2016                                           Cisco Systems
Expiration Date: August 2007                                Susan Hares
                                                   Nexthop Technologies

               Aspath Based
                                                            July 5, 2015

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

Abstract

   This document defines a new Outbound Route Router Filter type for BGP-4

                    draft-ietf-idr-aspath-orf-09.txt

1. 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 This Memo

   By submitting this Internet-Draft, each author represents
   that any applicable patent or other IPR claims of which he
   or she

   This Internet-Draft is aware have been or will be disclosed, and any of
   which he or she becomes aware will be disclosed, submitted in
   accordance full conformance with Section 6 the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts.
   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This document is an individual submission. Comments are solicited and
   should be addressed to the author(s). Internet-Draft will expire on January 6, 2016.

Copyright Notice

   Copyright (C) The (c) 2015 IETF Trust (2007).

2. Abstract and the persons identified as the
   document authors.  All rights reserved.

   This document defines a new Outbound Router Filter type for BGP,
   termed "Aspath Outbound Route Filter", that can be used is subject to perform
   aspath based route filtering. This ORF-type supports aspath based
   route filtering 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 well they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as regular expression based matching, for
   address groups. 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  ASpath ORF-Type . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  ASpath ORF encoding . . . . . . . . . . . . . . . . . . . . .   3
   4.  Capability Specification for Cooperative route filtering with
       ASpath  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  ASpath ORF Matching . . . . . . . . . . . . . . . . . . . . .   6
   6.  Error handling  . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   7
   11. Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   The Cooperative Outbound Route Filtering Capability defined in [BGP-
   ORF]
   [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 "ASpath
   Outbound Route Filter (Aspath (ASpath ORF)", that can be used to perform Aspath AS
   Path based route filtering.  The Aspath ASpath ORF supports Aspath AS path route
   filtering as well as the regular expression based matching for
   address groups.

4. Aspath

2.  ASpath ORF-Type

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

   Conceptually an Aspath 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 AS path regular
      expression string.

      The "Aspath" "aspath" field contains an aspath AS path 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" "aspath" is a
      variable length hexadecimal string.  The field "Aspath" "aspath" will be
      followed by enough trailing bits to make end of field fall on an
      octet boundry. boundary.  Note that the value of trailing bits is
      irrelevant.

5. Aspath

3.  ASpath ORF Encoding encoding

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

   An Aspath 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], [RFC5292],
   and the remaining fields of the entry is encoded in the "Type
   specific part" as follows. follows:

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

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

6.

4.  Capability Specification for Cooperative route filtering with ASpath

   As specified in the Coperative Router filtering draft
   [draft-ietf-idr-route-filter-05.txt], 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 [BGP-CAP] [RFC3392] 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): (AFI)

         This field carries the identity of the address family for 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
         attribute.

      Number of ORF Types: Types

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

      ORF Type: Type

         This field contains the value of an ORF Type.

      Send/Receive:

      Send/Receive
         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 -

         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 indicates anchoring
               status.

                  Bit 2 is the right most bit.

	bit 0 - anchors = 0 - implies full length regex, ie: regular express
                  (regex), that is implicit anchoring of AsPath ASPath as in
               ^AsPath$
          1 - partial as-path regex with anchoring.  ie: the regex may
              or may not have anchors and thus may be a partial match.
              eg:
               anchoring       non-anchoring
                  "^ASPath$"

                     anchoring--non-anchoring

                     ^X        -> --------> X .*

                     ^X$       -> --------> X

                     X         -> -----------> .* X .*

       bit

                  Bit 0 = 1 - implies partial aspath regex, regex may or
                  may not have anchors

               Bit 1 is the middle bit, and it is the "." wildcard operator
               operator.  [Collating Element]

                  Bit 1 = 0 - -- indicates traditional application of "."
                  as wildcard, ie: "." matches any single character of
                  the set [0-9 ].

                  Bit 1 - = 1 -- indicates "." matches an AS-path token/term, token/
                  term, regex "." == traditional regex "[0-9]+"

       bit

               Bit 2 - is the right most bit, and indicates the "[]"
               operator where:

                  Bit 2 = 0 - indicates not supported. supported

                  Bit 2 = 1 - supported, eg: indicates support, e.g. [0-9]

7. Aspath

5.  ASpath ORF Matching

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

   It is possible that the speaker would have more than one Aspath 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 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

   [BGP-4]

   [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., and T. Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-
   4)", (BGP-4)", RFC 1771, March 1995.

   [BGP-ORF] 4271, January 2006.

   [RFC5292]  Chen, E., E. and Rekhter, Y., "Cooperative S. Sangli, "Address-Prefix-Based Outbound
              Route Filtering
   Capability Filter for BGP-4", draft-ietf-idr-route-filter-05.txt, January
   2002.

10. Author Information RFC 5292, August 2008.

Authors' Addresses

   Susan Hares
   Huawei
   7453 Hickory Hill
   Saline, MI  48176
   USA

   Email: shares@ndzh.com

   Keyur Patel
   Cisco Systems
   510 McCarthy Blvd
   Milpitas,
   Milipitas, CA  95035
   email:

   Email: keyupate@cisco.com

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

11. Full Copyright Notice

   Copyright (C) The IETF Trust (2007). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein
   are provided on an "AS IS" basis and THE CONTRIBUTOR, THE
   ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE
   INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE
   DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
   ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
   INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
   OR FITNESS FOR A PARTICULAR PURPOSE.