[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 04 05 06 07 08 09 10 11 12
13
Network Working Group Keyur Patel
Internet Draft Cisco Systems
Expiration Date: August 2007 Susan Hares
Nexthop Technologies
Aspath Based Outbound Route Filter for BGP-4
draft-ietf-idr-aspath-orf-09.txt
1. 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 document is an individual submission. Comments are solicited and
should be addressed to the author(s).
Copyright Notice
Copyright (C) The IETF Trust (2007).
2. 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.
Patel, Hares [Page 1]
Internet Draft draft-ietf-idr-aspath-orf-09.txt Febuary 2007
3. Introduction
The Cooperative Outbound Route Filtering Capability defined in [BGP-
ORF] 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 Aspath based route filtering. The Aspath ORF supports Aspath
route filtering as well as the regular expression based matching for
address groups.
4. Aspath ORF-Type
The Aspath ORF-Type allows one to express ORFs in terms of
regular expression and aspath numbers. That is, it provides aspath
based route filtering, including regular expression based matching.
Conceptually an 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 regular expression
string.
The "Aspath" field contains an aspath 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" is a variable length
hexadecimal string. The field "Aspath" will be followed by enough
trailing bits to make end of field fall on an octet boundry. Note
that the value of trailing bits is irrelevant.
Patel, Hares [Page 2]
Internet Draft draft-ietf-idr-aspath-orf-09.txt Febuary 2007
5. Aspath ORF Encoding
The value of the ORF-Type for the Aspath ORF-Type is <TBD>.
An 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], and the remaining fields of the entry is encoded in the
"Type specific part" as follows.
+--------------------------------+
| Sequence (4 octets) |
+--------------------------------+
| Length (2 octet) |
+--------------------------------+
| Aspath ( variable length) |
+--------------------------------+
Note that the Aspath field is varibale length hexadecimal string
whose length is defined by Length field.
Patel, Hares [Page 3]
Internet Draft draft-ietf-idr-aspath-orf-09.txt Febuary 2007
6. Capability Specification for Cooperative route filtering with ASpath
As specified in the Coperative Router filtering draft
[draft-ietf-idr-route-filter-05.txt], 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] 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):
This field carries the identity of 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:
This field contains the number of Filter Types to be listed in
the following fields.
ORF Type:
This field contains the value of an ORF Type.
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 - 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 Bit 2 is the right most bit.
bit 0 - anchors
0 - full length regex, ie: implicit anchoring of 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
^X -> X .*
^X$ -> X
X -> .* X .*
bit 1 - "." wildcard operator [Collating Element]
0 - traditional application of "." as wildcard, ie: "." matches
any single character of the set [0-9 ].
1 - "." matches an AS-path token/term,
regex "." == traditional regex "[0-9]+"
bit 2 - "[]" operator
0 - not supported.
1 - supported, eg: [0-9]
7. Aspath ORF Matching
In addition to the general matching rules defined in [BGP-ORF],
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 Aspath regular
expressions to the its (receiver's) interpretation of regular
expressions as indicated in the capability announcement.
Patel, Hares [Page 4]
Internet Draft draft-ietf-idr-aspath-orf-09.txt Febuary 2007
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. References
[BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-
4)", RFC 1771, March 1995.
[BGP-ORF] Chen, E., and Rekhter, Y., "Cooperative Route Filtering
Capability for BGP-4", draft-ietf-idr-route-filter-05.txt, January
2002.
10. Author Information
Keyur Patel
Cisco Systems
510 McCarthy Blvd
Milpitas, CA 95035
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.
Html markup produced by rfcmarkup 1.129c, available from
https://tools.ietf.org/tools/rfcmarkup/