IDR Working Group Praveen Muley Internet Draft Nortel Networks Document: draft-muley-hares-idr-orf-order-00.txt Susan Hares NextHop Technologies Keyur Patel Cisco Expires: December 2004 July 2004 Group Cooperative Route Filtering Capability for BGP-4 Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, or will be disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. 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. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Muley-Hares Expires - January 2005 [Page 1] draft-muley-hares-idr-orf-order-00.txt July 2004 Abstract Currently BGP-4 is capable of carrying multiple (Outbound Route Filters) ORFs entries sharing the AFI SAFI. Each ORF provides a filter that a route must pass through to be transmitted in the Route Refresh message. Efficient processing of filters for ORF may require ordering of ORFs filters in certain sequence. This group ORF provides an ORF type that specifies that ordering. The route set that passes set of ORFs running in a "Group ORF" will pass the same ORFs sent in normal ORFs. One possible application of this capability to apply multiple ORFs per VPN per peer as defined in 2547bis. 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 RFC-2119 [RFC2119]. Table of Contents 1. Introduction...................................................2 2. Group ORF type.................................................3 3. Group ORF encoding.............................................3 4. Group Cooperative route filtering capability...................4 5. Operation......................................................4 6. Security Considerations........................................5 7. Normative References...........................................5 8. Acknowledgments................................................6 9. Author's Addresses.............................................6 Intellectual Property Statement...................................7 Copyright Statement...............................................7 1. 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 Route Refresh message. Efficient processing of filters for ORF may require ordering of ORFs filters in certain sequence. Muley-Hares Expires - January 2005 [Page 2] draft-muley-hares-idr-orf-order-00.txt July 2004 This document defines GROUP ORF, new BGP-4 ORF type, that allows BGP to send to its peer a group of set of ordered ORF filters. Efficient processing of ORF filters will aid many BGP peer connections using Route Refresh. One example of this is the use of ORFs to efficiently handle complex ORF policies applied per VPN per peer. With the growing popularity of the BGP/MPLS VPNs, the use of ORFs to filter routes has increased. 2. Group ORF type The group ORF type allows carrying group of ORF entries of different types in the BGP ROUTE-REFRESH message [BGP-RR]. The Group ORF provides group cooperative route filtering. Conceptually the Group ORF value of Group type consists of multiple different types of ORF entries as defined in [BGP-ORF] and [AS- ORF]. 3. Group ORF encoding The value of the ORF-Type for Group ORF is . 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) | +--------------------------------------------------+ | Length of ORFs (2 octets) | +--------------------------------------------------+ | First ORF entry (variable) (Group) | +--------------------------------------------------+ | Second ORF entry (variable) (Group) | +--------------------------------------------------+ ......... +--------------------------------------------------+ | N-th ORF entry (variable) | +--------------------------------------------------+ where each Group ORF entry will be encoded as follows. Muley-Hares Expires - January 2005 [Page 3] draft-muley-hares-idr-orf-order-00.txt July 2004 | ORF Group id (1 octet) | +--------------------------------------------------+ | ORF Type (1 octet) [Group] | +--------------------------------------------------+ | 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) | +--------------------------------------------------+ ......... 4. 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] 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]. The use of ORF entry in Group ORF will depend upon the send/receive value of the ORF type in capability negotiation. 5. Operation In addition to operational procedures defined in [BGP-ORF] several few additional operational rules needs to be followed. When the Muley-Hares Expires - January 2005 [Page 4] draft-muley-hares-idr-orf-order-00.txt July 2004 BGP speaker receives different types of ORFs in a Group ORF entry, the order of the ORFs is preserved and applied as per first ORF entry match rule. If a BGP speaker maintains a Group ORF for multiple ORFs of different types, then the BGP speaker will advertise the route to peer by passing the route through each such ORF, and and-ing the results (and-ing of PERMIT and DENY results in DENY). This rule is not applied across multiple group ORF entries. To remove a group ORF then all the ORF entries in the Group ORF will have the action component as REMOVE. The GROUP ORF group id allows a tag for a GROUP of ORFs. If multiple instances of a Group ORF with the same ID exist within a Route Refresh Message, the additional group information is appended to the end of the list of ORFs. The full list (all instances combined or an ID) will be included in the "and-ing" process. When processing GROUP ORFs, the Group ORFS will be applied in ascending order of the Group ID. The Group ORF always have higher preference than the non-Group ORF, and will be processed first. Note: Group ORF are independent of ORF preference and will configuration to occur without concern for order of transmission. 6. Security Considerations This extension to BGP does not change the underlying security issues. 7. Normative References [2547bis] "BGP/MPLS VPN", Rosen, et. al., draft-ietf-l3vpn-rfc2547bis-01.txt, September 2003. [BGPCOMM] "BGP Communities Attribute", R. Chandra, P. Traina, T.Li, RFC 1997, August 1996 [BGP-DYNCAP] "Dynamic Capability for BGP-4", Enke Chen, Srihari R. Sangli, draft-ietf-idr-dynamic-cap-05.txt, July 2005 [BGPEXTCOMM], "BGP Extended Communities Attribute",Srihari R. Sangli,Daniel Tappan, Yakov Rekhter, draft-ietf-idr-bgp-ext-communities-06.txt, Muley-Hares Expires - January 2005 [Page 5] draft-muley-hares-idr-orf-order-00.txt July 2004 August 2003 [BGP-RR] "Route Refresh Capability for BGP-4", Chen E., RFC 2918, September 2000. [BGP-4] Rekhter, Y.,T. Li, and Hares, S. "A Border Gateway Protocol 4" (BGP-4)", draft-ietf-idr-bgp4-25.txt, May 2004 [BGP-ORF] Chen, E., and Rekhter, Y., "Cooperative Route Filtering Capability for BGP-4", draft-ietf-idr-route-filter-10.txt, March 2004 8. Acknowledgments 9. Author's Addresses Praveen Muley Nortel Networks 600 Technology Park Billerica, MA 01821 Phone: 978-288-3603 Email : pmuley@nortelnetworks.com Susan Hares NextHop Technologies. Inc. 517 W. Williams Ann Arbor, MI 48103-4943 Email: skh@nexthop.com Keyur Patel Cisco Systems Email: keyupate@cisco.com Muley-Hares Expires - January 2005 [Page 6] draft-muley-hares-idr-orf-order-00.txt July 2004 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Muley-Hares Expires - January 2005 [Page 7]