IDR                                                             S. Hares
Internet-Draft                                      Green Hills Software
Expires: August 27, 2008                                        P. Muley
                                                                 Alcatel
                                                                K. Patel
                                                           Cisco Systems
                                                           B. Schliesser
                                                   Saavis Communications
                                                       February 24, 2008


        Group Co-operative Route Filtering capability for BGP-4
                   draft-muley-hares-idr-orf-order-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

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

   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 Internet-Draft will expire on August 27, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).









Hares, et al.            Expires August 27, 2008                [Page 1]


Internet-Draft                  Group-ORF                  February 2008


Abstract

   Currently BGP-4 is capable of carrying multiple (Outbound Route
   Filters) ORFs entries for a given "AFI/SAFI".  Each ORF provides a
   filter that a route whose NLRI matches AFI/SAFI, must pass through to
   be transmitted in the BGP Update message.  Efficient processing of
   ORF filters may require ordering of individual ORFs in certain
   sequence and grouping of ORFs that should be applied together.  The
   grouping functionality also provides the support for logical OR
   operation between the grouped ORFs.

   This group ORF provides an ORF type that specifies that ordering and
   grouping.  The route set that passes set of ORFs running in a "Group
   ORF" will pass the same ORFs sent in normal ORFs.


Table of Contents

   1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions used in this document  . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Past Contriburos . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Group ORF Type . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Group ORF Encoding . . . . . . . . . . . . . . . . . . . . . .  7
   6.  ORF Entry Encoding . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Group Cooperative route filtering capability . . . . . . . . . 11
   8.  Operation  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 14
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 21


















Hares, et al.            Expires August 27, 2008                [Page 2]


Internet-Draft                  Group-ORF                  February 2008


1.  Definitions

1.1.  Conventions used in this document

   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 RFC2119 [1].












































Hares, et al.            Expires August 27, 2008                [Page 3]


Internet-Draft                  Group-ORF                  February 2008


2.  Introduction

   Currently it is not uncommon for a BGP speaker to receive set of ORFs
   from an ORF capable BGP peer.  Each ORF provides a filter that a
   route must pass through to be transmitted in the BGP update message.
   Today's operational procedure for cooperative route filtering
   provides the AFI/SAFI as the only context.  ORF by definition in its
   current form have logical OR within ORF entries and logical AND
   within the ORF types.  Efficient processing and expression of filters
   for ORF may require ordering of ORFs filters and ORF entries in
   certain sequence.  Efficient processing entails both BGP processing
   and quick processing of the ORF generated from User policies.

   This document defines GROUP ORF, a new BGP-4 ORF type that allows BGP
   to send to its peer a group of set of ordered ORF filters.  Group ORF
   provides a context for filtering rules that need to be interpreted
   together further within that context AFI/SAFI.  The grouping
   functionality also provides the support for logical OR operation
   between grouped ORFs.

   Today ORF entries of same ORF type have logical OR functionality
   only, which limits the flexibility of defining an efficient ORF with
   less grammar description.  Group ORF capability will help in defining
   the relational meaning within the ORF entries as well.

   One example of this is the use of ORFs to efficiently handle complex
   ORF policies applied per VPN per peer, in BGP/MPLS VPN deployment as
   defined in: RFC4364 [2].























Hares, et al.            Expires August 27, 2008                [Page 4]


Internet-Draft                  Group-ORF                  February 2008


3.  Past Contriburos

   The authors want to acknowledge the contributions of Luyuan Fang and
   Nabil Bitar.















































Hares, et al.            Expires August 27, 2008                [Page 5]


Internet-Draft                  Group-ORF                  February 2008


4.  Group ORF Type

   The group ORF type allows a set of ORF entries of different ORF types
   and ORF entries within the type, to be grouped, and ordered in the
   BGP ROUTE-REFRESH message RFC2918 [6].  The Group ORF provides group
   cooperative route filtering.

   Conceptually a Group ORF consist of multiple different types of ORF
   entries as defined in [BGP-ORF] [7], [ASPATH-ORF] [9] and [prefix-
   ORF] [8].  Each such ORF type, will have ordered ORF entries, with an
   operation of logical OR or logical AND defined with each other.








































Hares, et al.            Expires August 27, 2008                [Page 6]


Internet-Draft                  Group-ORF                  February 2008


5.   Group ORF Encoding

   The value of the ORF-Type for Group ORF is [TBD].

   Conceptually the Route Refresh message carrying Group ORF can be
   viewed as below.

         +--------------------------------------------------+
         | Address Family Identifier (2 octets)             |
         +--------------------------------------------------+
         | Reserved (1 octet)                               |
         +--------------------------------------------------+
         | Subsequent Address Family Identifier (1 octet)   |
         +--------------------------------------------------+
         | When-to-refresh (1 octet)                        |
         +--------------------------------------------------+
         |  ORF Type (1 octet) (Group)                      |
         +--------------------------------------------------+
         |  ORF Group Flags                                 |
         +--------------------------------------------------+
         | Length of ORFs (2 octets)                        |
         +--------------------------------------------------+
         | First ORF entry (variable) (Group)               |
         +--------------------------------------------------+
         | Second ORF entry (variable)  (Group)             |
         +--------------------------------------------------+
            .........
         +--------------------------------------------------+
         | N-th ORF entry (variable)                        |
         +--------------------------------------------------+

                              ORF byte layout



















Hares, et al.            Expires August 27, 2008                [Page 7]


Internet-Draft                  Group-ORF                  February 2008


         Each Group ORF entry will be encoded as follows.

         +--------------------------------------------------+
         | ORF Group id (1 octet)                           |
         +--------------------------------------------------+
         | ORF Type (1 octet)    [Group]                    |
         +--------------------------------------------------+
         | ORF Action (1 octet)                             |
         +--------------------------------------------------+
         | ORF FLags (1 octet)                              |
         | Length of ORFs (2 octets)                        |
         +--------------------------------------------------+
         | First ORF entry (variable)                       |
         +--------------------------------------------------+
         | Second ORF entry (variable)                      |
         +--------------------------------------------------+
            .........
         +--------------------------------------------------+
         | N-th ORF entry (variable)                        |
         +--------------------------------------------------+
         | ORF Type (1 octet)                               |
         +--------------------------------------------------+
         | Length of ORFs (2 octets)                        |
         +--------------------------------------------------+
         | First ORF entry (variable)                       |
         +--------------------------------------------------+
         | Second ORF entry (variable)                      |
         +--------------------------------------------------+
           .........

                           Group ORF byte layout

   ORF Action:

   Byte that indicates operation of "AND and OR" function within the
   full Group ORF.

   Value 000 Use AND or OR specified in Group ORF.  OR between GROUP
   IDs.

   Value 001 Always AND between attributes in Flag Byte

   Always ORed between same Route-map's different sequences.

   ORF FLAG:

   Value 0000 0001 Route-Map




Hares, et al.            Expires August 27, 2008                [Page 8]


Internet-Draft                  Group-ORF                  February 2008


   Value 0000 0002 Access Control List

   Value 1000 0000 Ignore ORF Action BIT
















































Hares, et al.            Expires August 27, 2008                [Page 9]


Internet-Draft                  Group-ORF                  February 2008


6.  ORF Entry Encoding

   As specified in the [BGP-ORF] [7] the ORF entry definition has common
   part and type specific part.  The encoding of common part of the ORF
   entries on Group ORF capability negotiation as defined below.


             +---------------------------------+
             |   Action (2 bit)                |
             +---------------------------------+
             |  Match (1 bit)                  |
             +---------------------------------+
             |  AND/OR (1 bit)                 |
             +---------------------------------+
             |   Reserved (4 bits)             |
             +---------------------------------+
             |   Type specific part (variable)  |
             +---------------------------------+

                           Group ORF Entry Byte

   The new AND/OR is a one bit field additional to the definition
   specified in [BGP-ORF] [7].  The value of this field is 0 for
   expression of logical OR and 1 for logical AND with the next ORF
   entry.  The ORF entries grammar expression for logical OR followed by
   logical AND ORF entries will be for the over all the group of such
   and-ed ORF entries.  This field in the last entry of the ORF type
   will be ignored.























Hares, et al.            Expires August 27, 2008               [Page 10]


Internet-Draft                  Group-ORF                  February 2008


7.  Group Cooperative route filtering capability

   A BGP speaker that is willing to receive Group 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, as described below.

   The Group ORF Capability is a new BGP capability

   [BGP-CAP] [3] defined as follows

      Capability code: X [IANA consideration]

      Capability length: variable

      Capability value: one or more of the entries as defined for ORF
      entries in the [BGP-ORF] [7].

   The use of ORF entry in Group ORF will depend upon the send/receive
   value of the ORF type in capability negotiation































Hares, et al.            Expires August 27, 2008               [Page 11]


Internet-Draft                  Group-ORF                  February 2008


8.   Operation

   In addition to operational procedures defined in [BGP-ORF] [7]
   several additional operational rules needs to be followed.

   The Group ORF Group-ID allows a tag for a group of ORFs.  If multiple
   instances of a Group ORF with the same Group-ID exist within a Route
   Refresh Message, the additional group information is appended to the
   set of previously received ORFs with the same Group-ID.  The complete
   list of ORFs within the Group will be included in the "and-ing"
   process for that Group.

   When processing multiple Group ORFs into a filter, the Group ORFs
   will be applied in ascending order of the Group ID.

   When the BGP speaker receives multiple ORFs within a Group ORF entry,
   the order of the ORFs is preserved and applied as per first ORF entry
   match rule.

   For each Group ORF, a BGP speaker will pass the set of candidate
   NLRIs (routes) through each ORF that is a member of the Group, and-
   ing the results (and-ing of PERMIT and DENY results in DENY).  If a
   Group ORF would result in a PERMIT for a given NLRI, it is advertised
   to the peer and it is removed from the list of candidate NLRIs.  If a
   Group ORF would result in a DENY for a given NLRI, it is not
   advertised to the peer and it is removed from the list of candidate
   NLRIs.  The remaining list of candidate NLRIs are then filtered
   through the next Group ORF.

   This process is repeated until the candidate NRLIs have been filtered
   through all Group ORFs.  The remaining candidate NLRIs are then
   filtered through any non-Group ORFs that might exist.  While
   processing the ORF entries in the ORF type the result of ORF entry
   match with AND/OR bit set will be and-ed with the subsequent ORF
   entry match.  The ORF entry with AND/OR bit is set to 0 will OR the
   match result with subsequent entry match result.  Rest of the
   procedure for treatment of NLRI remains same as described in the
   [BGP-ORF] [7].

   To remove a group ORF then all the ORF entries in the Group ORF will
   have the action component as REMOVE.

   The Group ORF MUST always have higher preference than non-Group ORFs,
   and will be processed first.

   Note: Group ORF are independent of ORF preference and configuration
   to occur without concern for order of transmission.  Individual ORF
   type preference within the Group ORF will occur based on



Hares, et al.            Expires August 27, 2008               [Page 12]


Internet-Draft                  Group-ORF                  February 2008


   configuration policy.


















































Hares, et al.            Expires August 27, 2008               [Page 13]


Internet-Draft                  Group-ORF                  February 2008


9.  Deployment Scenarios

   Following are few deployment examples where Group ORF helps in
   filtering and offering flexibility in ORF expression.

   Scenario 1

   An example of group ORF could be in the IPVPN case is where multiple
   BGP communities [BGP-COM} [4] and/or extended communities need to be
   considered together for a given VPN in the filtering rules although
   all IPVPN routes belong to the same AFI/SAFI.

   Consider the case where there are two VPNs, red and yellow, have
   routes belonging to sites tagged by community attributes that express
   city locations.  The Red VPN wants or needs to get routes from
   certain site locations but not others.  Similarly, the yellow VPN
   wants or needs to get sites from certain location not others.  For
   the purpose of ease in manageability, it would be desired to
   affiliate the community attribute value with the city location only.
   That is the red VPN and yellow VPN routes will carry the same city
   community value when these routes reside in same city.

   If cooperative route filtering is used without group ORF, it will not
   be possible to express the ORFs when the the two VPNs have different
   rules whereby different city routes need to be imported to another
   city for the two VPNs.  This is because of the ORing operation within
   the same ORF type and ANDing operation across ORF types.

   To illustrate further consider the following example where routers in
   the red VPN in city 4 needs to get the routes from city 1 only and
   not from city 2 and 3.  On the other hand, the routers in the yellow
   VPN in city 4 needs to get routes from city 2 but not city 3 and city
   1.  In current procedures for cooperative route filtering without
   group ORF, the only way to express that for ORF from the routers
   hosting VPN sites in city 4 is:

      AFI/SAFI = IPVPN

      Extended ORF Type = Target Extended Community

         Permit Red

         Permit Yellow

      ORF Type = Community

         Permit City1




Hares, et al.            Expires August 27, 2008               [Page 14]


Internet-Draft                  Group-ORF                  February 2008


         Permit City2

   Based on this ORF routes tagged with Red and City2 will be permitted
   and routes tagged with Yellow and City1 will be permitted although
   these are not deired routes and will need to be filtered out by a
   local policy on the routers in City4.

   If group ORF was available, the ORF policy can be more flexibly
   expressed in the following manner:

      AFI/SAFI = IPVPN

      Group 1 (implicitly Red VPN)

         Extended ORF Type = Target Extended Community

            Permit Red

         ORF Type = Community

            Permit City1

      Group 2 (implicitly Yellow VPN)

         Extended ORF Type = Target Extended Community

            Permit Yellow

         ORF Type = Community

            Permit City2

   Thus Group 1 provides a context for the red VPN and Group 2 provides
   a context for the yellow VPN.  Only routes that are tagged with Red
   target extended community attributes and City1 community or routes
   tagged with Yellow target community attributes and City2 community
   will be permitted to be advertised to the BGP client that sent this
   ORF, achieving the desired result.

   It may be argued that in this simple case, the problem could be
   addressed with existing ORF capabilities by simply tagging the Red
   and City 1 routes with a new extended community tag (Red_City1) and
   the routes with the Yellow and City2 tags with a new target extended
   community tag (Yellow_City2) and including these in the ORF.
   However, this can get complicated as the number of combinations of
   BGP extended communities RFC4360 [5] and communities increases.
   Having group ORF capability offers the needed flexibility.




Hares, et al.            Expires August 27, 2008               [Page 15]


Internet-Draft                  Group-ORF                  February 2008


   It is also true that the same result can be achieved by defining
   local policies on the routers but the tradeoff as in any ORF case is
   between the work done at a client and that done at the route
   reflector when used in topology.

   Scenario 2

   An example Group ORF in the global routing context can be where a BGP
   speaker wants to learn certain more specific NLRIs only if they
   traverse certain AS path.  Otherwise routes which are less specific
   than /25.  A Group ORF will look like as defined below where X,Y,Z
   are the more specific NLRIs to be learnt only if it learn it from
   AS1.

      AFI/SAFI = IPV4

      Group 1

         ORF Type = Prefix

            Permit X

            Permit Y

            Permit Z

         ORF Type = ASpath

            Permit AS1

      Group 2

         ORF Type = Prefix

            Deny prefix( */25) or longer

      Group 3

         ORF Type = Prefix

            Permit prefix(*)

   Although its possible to achieve the above mentioned application by
   making use of route policies, use of Group ORF helps in simplifying
   the configuration.






Hares, et al.            Expires August 27, 2008               [Page 16]


Internet-Draft                  Group-ORF                  February 2008


10.  Security Considerations

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
















































Hares, et al.            Expires August 27, 2008               [Page 17]


Internet-Draft                  Group-ORF                  February 2008


11.  IANA Considerations

   IANA will need to assign the value of the ORF-Type for Group ORF.
















































Hares, et al.            Expires August 27, 2008               [Page 18]


Internet-Draft                  Group-ORF                  February 2008


12.  References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", March 1997, <ftp://ftp.isi.edu/in-notes/rfc2119>.

   [2]  Cisco and Juniper, "BGP/MPLS VPN", February 2006,
        <http://www.ietf.org/rfc/rfc4364.txt>.

   [3]  Cisco and Cisco, "Capabilities Advertisement with BGP-4",
        November 2002, <http://www.ietf.org/rfc/rfc3392.txt>.

   [4]  Cisco, Cisco, and Cisco, "BGP/MPLS VPN", August 1996,
        <ftp://ftp.isi.edu/rfc/rfc-1997>.

   [5]  Cisco, Cisco, and Juniper, "BGP Extended Communities Attribute",
        July 2006, <http://www.ietf.org/rfc/rfc4360.txt>.

   [6]  Cisco, "Route Refresh Capability for BGP-4", Septebmer 2000,
        <http://www.ietf.org/rfc/rfc2918>.

   [7]  Sangli, S. and Cisco, ""Cooperative Router Filtering for
        BGP-4"", July 2005, <http://www.ietf.org/internet-drafts/
        draft-ietf-idr-route-filter-15.txt>.

   [8]  Sangli, S. and Cisco, ""Address Prefix Based Outbound Route
        Filter for BGP-4"", March 2005, <http://www.ietf.org/
        internet-drafts/draft-ietf-idr-bgp-prefix-orf-04.txt>.

   [9]  Hares, S. and K. Patel, ""Aspath Based Outbound Route Filter for
        BGP-4"", August 2007, <http://www.ietf.org/internet-drafts/
        draft-ietf-idr-aspath-orf-09.txt>.




















Hares, et al.            Expires August 27, 2008               [Page 19]


Internet-Draft                  Group-ORF                  February 2008


Authors' Addresses

   Susan Hares
   Green Hills Software
   825 Victors Way
   Ann Arbor, MI  48108

   Phone: +1-734-222-1610
   Email: shares@ghs.com


   Praveen Muley
   Alcatel
   701, E. Middle Field Rd
   Mountain View, CA  94043

   Phone: +1-650-623-2622
   Email: Praveen.Muley@alcatel.com


   Keyur Patel
   Cisco Systems

   Phone:
   Email: keyupate@cisco.com


   Benson Schliesser
   Saavis Communications
   1 Savvis Parkway
   Town and Country, MO  63017

   Phone: +1-314-628-7036
   Email: bensons@savvis.net

















Hares, et al.            Expires August 27, 2008               [Page 20]


Internet-Draft                  Group-ORF                  February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Hares, et al.            Expires August 27, 2008               [Page 21]