draft-ietf-idr-aspath-orf-09.txt   draft-ietf-idr-aspath-orf-10.txt 
Network Working Group Keyur Patel IDR S. Hares
Internet Draft Cisco Systems Internet-Draft Huawei
Expiration Date: August 2007 Susan Hares Intended status: Standards Track K. Patel
Nexthop Technologies Expires: January 6, 2016 Cisco
July 5, 2015
Aspath Based Outbound Route Filter for BGP-4 Analysis of Existing work for I2NSF
draft-ietf-idr-aspath-orf-10.txt
draft-ietf-idr-aspath-orf-09.txt Abstract
1. Status of this Memo 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.
By submitting this Internet-Draft, each author represents Status of This Memo
that any applicable patent or other IPR claims of which he
or she is aware have been or will be disclosed, and any of This Internet-Draft is submitted in full conformance with the
which he or she becomes aware will be disclosed, in provisions of BCP 78 and BCP 79.
accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- 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 Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 6, 2016.
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 Notice
Copyright (C) The IETF Trust (2007). Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
2. Abstract This document is subject to 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 they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document defines a new Outbound Router Filter type for BGP, Table of Contents
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.
3. Introduction 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
The Cooperative Outbound Route Filtering Capability defined in [BGP- 1. Introduction
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 The Cooperative Outbound Route Filtering Capability defined in
Outbound Route Filter (Aspath ORF)", that can be used to [RFC5292] provides a mechanism for a BGP speaker to send to its BGP
perform Aspath based route filtering. The Aspath ORF supports Aspath peer a set of Outbound Route Filters (ORFs) that can be used by its
route filtering as well as the regular expression based matching for 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 AS
Path based route filtering. The ASpath ORF supports AS path route
filtering as well as the regular expression based matching for
address groups. address groups.
4. Aspath ORF-Type 2. ASpath ORF-Type
The Aspath ORF-Type allows one to express ORFs in terms of The ASpath ORF-Type allows one to express ORFs in terms of regular
regular expression and aspath numbers. That is, it provides aspath expression and AS path numbers. That is, it provides AS path based
based route filtering, including regular expression based matching. route filtering, including regular expression based matching.
Conceptually an Aspath ORF entry consists of the fields Conceptually an ASpath ORF entry consists of the fields <Sequence,
<Sequence, Match, Length, Aspath>. Match, Length, Aspath>.
The "Sequence" field is a number that specifies the relative ordering The "Sequence" field is a number that specifies the relative
of the entry. ordering of the entry.
The "Match" field specifies whether this entry is "PERMIT" (value 0), The "Match" field specifies whether this entry is "PERMIT" (value
or "DENY" (value 1). 0), or "DENY" (value 1).
The "Length" field indicates the length of aspath regular expression The "Length" field indicates the length of AS path regular
string. expression string.
The "Aspath" field contains an aspath regular expression of an The "aspath" field contains an AS path regular expression of an
address group. address group.
The field "Sequence" is an unsigned 32 bit value. The field "Length" The field "Sequence" is an unsigned 32 bit value. The field
is an unsigned 16 bit value. The field "Aspath" is a variable length "Length" is an unsigned 16 bit value. The field "aspath" is a
hexadecimal string. The field "Aspath" will be followed by enough variable length hexadecimal string. The field "aspath" will be
trailing bits to make end of field fall on an octet boundry. Note followed by enough trailing bits to make end of field fall on an
that the value of trailing bits is irrelevant. octet boundary. Note that the value of trailing bits is
irrelevant.
5. Aspath ORF Encoding 3. ASpath ORF encoding
The value of the ORF-Type for the Aspath ORF-Type is <TBD>. The value of the ORF-Type for the ASpath ORF-Type is <TBD>.
An Aspath ORF entry is encoded as follows. The "Match" field An ASpath ORF entry is encoded as follows. The "Match" field of the
of the entry is encoded in the "Match" field of the common part entry is encoded in the "Match" field of the common part [RFC5292],
[BGP-ORF], and the remaining fields of the entry is encoded in the and the remaining fields of the entry is encoded in the "Type
"Type specific part" as follows. specific part" as follows:
+--------------------------------+ +--------------------------------+
| Sequence (4 octets) | | Sequence (4 octets) |
+--------------------------------+ +--------------------------------+
| Length (2 octet) | | Length (2 octet) |
+--------------------------------+ +--------------------------------+
| Aspath ( variable length) | | Aspath ( variable length) |
+--------------------------------+ +--------------------------------+
Note that the Aspath field is varibale length hexadecimal string Note the aspath is a variable length hexadecimal string whose length
whose length is defined by Length field. is defined by Length field.
6. Capability Specification for Cooperative route filtering with ASpath 4. Capability Specification for Cooperative route filtering with ASpath
As specified in the Coperative Router filtering draft As specified in Cooperative Route Filter[RFC5292], a BGP speaker that
[draft-ietf-idr-route-filter-05.txt], a BGP speaker that is is willing to receive ORF entries from its peer, or a BGP speaker
willing to receive ORF entries from its peer, that would like to send ORF entries to its peer advertises this to
or a BGP speaker that would like to send ORF entries to its peer the peer by using the Cooperative Route Filtering Capability uses a
advertises this to the peer by using the Cooperative Route Filtering new BGP capability [RFC3392] defined as follows:
Capability uses a new BGP capability [BGP-CAP] defined as follows:
Capability code: 3 Capability code: 3
Capability length: variable Capability length: variable
Capability value: one or more of the following entries: Capability value: one or more of the following entries:
+--------------------------------------------------+ +--------------------------------------------------+
| Address Family Identifier (2 octets) | | Address Family Identifier (2 octets) |
+--------------------------------------------------+ +--------------------------------------------------+
| Reserved (1 octet) | | Reserved (1 octet) |
+--------------------------------------------------+ +--------------------------------------------------+
| Subsequent Address Family Identifier (1 octet) | | Subsequent Address Family Identifier (1 octet) |
+--------------------------------------------------+ +--------------------------------------------------+
| Number of ORFs (1 octet) | | Number of ORFs (1 octet) |
+--------------------------------------------------+ +--------------------------------------------------+
| ORF Type (1 octet) | | ORF Type (1 octet) |
+--------------------------------------------------+ +--------------------------------------------------+
| Send/Receive (1 octet) | | Send/Receive (1 octet) |
+--------------------------------------------------+ +--------------------------------------------------+
| ... | | ... |
+--------------------------------------------------+ +--------------------------------------------------+
| ORF Type (1 octet) | | ORF Type (1 octet) |
+--------------------------------------------------+ +--------------------------------------------------+
| Send/Receive (1 octet) | | Send/Receive (1 octet) |
+--------------------------------------------------+ +--------------------------------------------------+
Fig 4. Capability encoding Fig 4. Capability encoding
The use and meaning of these fields are as follows: The use and meaning of these fields are as follows:
Address Family Identifier (AFI): Address Family Identifier (AFI)
This field carries the identity of the Network Layer protocol This field carries the identity of the address family for the
associated with the Network Address that follows. Presently Network Layer protocol associated with the Network Address that
defined values for this field are specified in RFC1700 (see the follows.
Address Family Numbers section).
Subsequent Address Family Identifier (SAFI): Subsequent Address Family Identifier (SAFI):
This field provides additional information about the type of This field provides additional information about the type of
the Network Layer Reachability Information carried in the the Network Layer Reachability Information carried in the
attribute. attribute.
Number of ORF Types: Number of ORF Types
This field contains the number of Filter Types to be listed in This field contains the number of Filter Types to be listed in
the following fields. the following fields.
ORF Type: ORF Type
This field contains the value of an ORF Type. This field contains the value of an ORF Type.
Send/Receive: Send/Receive
This field indicates whether the sender is (a) willing to This field indicates whether the sender is (a) willing to
receive ORF entries from its peer (value 1), (b) would like 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) send ORF entries to its peer (value 2), or (c) both (value 3)
for the ORF Type that follows. for the ORF Type that follows.
In the upper bits of the Send/Receive byte the top three In the upper bits of the Send/Receive byte the top three bits
bits have the following encoding: [FFFKKKSR] have the following encoding: [FFFKKKSR] where bit 0 is the left
where bit 0 is the left most bit. most bit.
Where - S = Send ORF for ASpath where:
R = Receive ORF for ASpath
Where KKK is a 3 bit field reserved for future expansion of S = Send ORF for ASpath
regular expression differences in ORF.
Where FFF indicates 3 bits. Bit 0 is the left most bit, R = Receive ORF for ASpath
Bit 1 is the middle bit and Bit 2 is the right most bit.
bit 0 - anchors KKK = a 3 bit field reserved for future expansion of regular
0 - full length regex, ie: implicit anchoring of AsPath as in expression differences in ORF.
^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] FFF = 3 bits.
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 Bit 0 is the left most bit, and indicates anchoring
0 - not supported. status.
1 - supported, eg: [0-9]
7. Aspath ORF Matching Bit 0 = 0 - implies full length regular express
(regex), that is implicit anchoring of ASPath as in
"^ASPath$"
In addition to the general matching rules defined in [BGP-ORF], anchoring--non-anchoring
several Aspath ORF specific matching rules are defined as follows.
It is possible that the speaker would have more than one Aspath ^X --------> X .*
ORF entry that matches the route. In that case the "first-match" rule
applies. That is, the ORF entry with the smallest sequence number ^X$ --------> X
X -----------> .* X .*
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. [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, regex "." == traditional regex "[0-9]+"
Bit 2 is the right most bit, and indicates the "[]"
operator where:
Bit 2 = 0 - indicates not supported
Bit 2 = 1 - indicates support, e.g. [0-9]
5. ASpath ORF Matching
In addition to the general matching rules defined in [RFC5292],
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, among all the matching ORF entries) is considered as the sole match,
and it would determine whether the route should be advertised. and it would determine whether the route should be advertised.
If any speaker does not support capabilities specified by the If any speaker does not support capabilities specified by the
receiver but still decide to establish the connection, the receiver but still decide to establish the connection, the receiver
receiver is expected to translate the Aspath regular is expected to translate the AS path regular expressions to the its
expressions to the its (receiver's) interpretation of regular (receiver's) interpretation of regular expressions as indicated in
expressions as indicated in the capability announcement. the capability announcement.
7. Security Considerations 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. This extension to BGP does not change the underlying security issues.
8. Acknowledgements 8. Acknowledgements
We express our thanks to Andrew Partan, Avneesh Sachdev, Alec Peterson, We express our thanks to Andrew Partan, Avneesh Sachdev, Alec
Enke Chen, John Heasley, Dorian Kim and Bruce Cole for their Peterson, Enke Chen, John Heasley, Dorian Kim and Bruce Cole for
comments. their comments.
9. References 9. IANA Considerations
[BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP- No IANA exist for this document.
4)", RFC 1771, March 1995.
[BGP-ORF] Chen, E., and Rekhter, Y., "Cooperative Route Filtering 10. Security Considerations
Capability for BGP-4", draft-ietf-idr-route-filter-05.txt, January
2002.
10. Author Information No security considerations are involved with a gap analysis.
Keyur Patel 11. Normative References
Cisco Systems
510 McCarthy Blvd [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Milpitas, CA 95035 Requirement Levels", BCP 14, RFC 2119, March 1997.
email: keyupate@cisco.com
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement
with BGP-4", RFC 3392, November 2002.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound
Route Filter for BGP-4", RFC 5292, August 2008.
Authors' Addresses
Susan Hares Susan Hares
NextHop Technologies. Inc. Huawei
517 W. Williams 7453 Hickory Hill
Ann Arbor, MI 48103-4943 Saline, MI 48176
email: skh@nexthop.com USA
11. Full Copyright Notice Email: shares@ndzh.com
Copyright (C) The IETF Trust (2007). This document is subject Keyur Patel
to the rights, licenses and restrictions contained in BCP 78, and Cisco
except as set forth therein, the authors retain all their rights. Milipitas, CA 95035
This document and the information contained herein Email: keyupate@cisco.com
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.
 End of changes. 59 change blocks. 
171 lines changed or deleted 216 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/