Internet DRAFT - draft-ietf-idr-aspath-orf
draft-ietf-idr-aspath-orf
IDR S. Hares
Internet-Draft Huawei
Intended status: Standards Track K. Patel
Expires: June 22, 2017 Cisco
December 19, 2016
AS Path Based Outbound Route Filter for BGP-4
draft-ietf-idr-aspath-orf-13.txt
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on June 22, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Hares & Patel Expires June 22, 2017 [Page 1]
Internet-Draft ASPATH ORF December 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
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
1. Introduction
The Cooperative Outbound Route Filtering Capability defined in
[RFC5292] 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 AS
Path based route filtering. The ASpath ORF supports AS path route
filtering as well as the regular expression based matching for
address groups.
2. ASpath ORF-Type
The ASpath ORF-Type allows one to express ORFs in terms of regular
expression and AS path numbers. That is, it provides AS path 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).
Hares & Patel Expires June 22, 2017 [Page 2]
Internet-Draft ASPATH ORF December 2016
The "Length" field indicates the length of AS path regular
expression string.
The "aspath" field contains an AS path 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 boundary. Note that the value of trailing bits is
irrelevant.
3. 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 [RFC5292],
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 the aspath is a variable length hexadecimal string whose length
is defined by Length field.
4. Capability Specification for Cooperative route filtering with ASpath
As specified in Cooperative Route Filter[RFC5292], 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 [RFC3392] defined as follows:
Capability code: 3
Capability length: variable
Capability value: one or more of the following entries:
Hares & Patel Expires June 22, 2017 [Page 3]
Internet-Draft ASPATH ORF December 2016
+--------------------------------------------------+
| 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 address family for the
Network Layer protocol associated with the Network Address that
follows.
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
Hares & Patel Expires June 22, 2017 [Page 4]
Internet-Draft ASPATH ORF December 2016
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
KKK = a 3 bit field reserved for future expansion of regular
expression differences in ORF.
FFF = 3 bits.
Bit 0 is the left most bit, and indicates anchoring
status.
Bit 0 = 0 - implies full length regular express
(regex), that is implicit anchoring of ASPath as in
"^ASPath$"
anchoring--non-anchoring
^X --------> X .*
^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]+"
Hares & Patel Expires June 22, 2017 [Page 5]
Internet-Draft ASPATH ORF December 2016
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,
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 AS path regular expressions to the its
(receiver's) interpretation of regular expressions as indicated in
the capability announcement.
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.
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. IANA Considerations
No IANA exist for this document.
Hares & Patel Expires June 22, 2017 [Page 6]
Internet-Draft ASPATH ORF December 2016
10. Security Considerations
No security considerations are involved with a gap analysis.
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement
with BGP-4", RFC 3392, DOI 10.17487/RFC3392, November
2002, <http://www.rfc-editor.org/info/rfc3392>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound
Route Filter for BGP-4", RFC 5292, DOI 10.17487/RFC5292,
August 2008, <http://www.rfc-editor.org/info/rfc5292>.
Authors' Addresses
Susan Hares
Huawei
7453 Hickory Hill
Saline, MI 48176
USA
Email: shares@ndzh.com
Keyur Patel
Cisco
Milipitas, CA 95035
Email: keyupate@cisco.com
Hares & Patel Expires June 22, 2017 [Page 7]
