One document matched: draft-muley-hares-idr-orf-order-00.txt
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 <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) |
+--------------------------------------------------+
| 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]
| PAFTECH AB 2003-2026 | 2026-04-23 09:57:27 |