Network Working Group Renhai Zhang
Internet Draft Mach Chen
Expires: April 2007 Huawei Technologies Co,LTD
October 12, 2006
Nexthop Based Outbound Route Filter for BGP-4
draft-chen-idr-bgp-nexthop-orf-00.txt
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 Internet-Draft will expire on April 12, 2007.
Abstract
This document defines a new Outbound Route Filter type for BGP,
termed "Nexthop Outbound Route Filter", which can be used to provide
Nexthop based route filtering.
Specification of requirements
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.
Mach Expires April 12, 2007 [Page 1]
Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt October 2006
Table of Contents
1. Introduction.................................................2
2. Motivation...................................................2
3. Nexthop ORF-type.............................................4
4. Nexthop ORF Encoding.........................................5
5. Capability Specification for Nexthop ORF.....................5
6. Nexthop ORF Matching.........................................5
7. Security Considerations......................................6
8. IANA Considerations..........................................6
9. References...................................................6
9.1. Normative References....................................6
9.2. Informative References..................................6
Author's Addresses..............................................6
Intellectual Property Statement.................................7
Copyright Statement.............................................7
Acknowledgment..................................................7
1. Introduction
The Outbound Route Filtering Capability defined in [BGP-ORF] provides
a mechanism for a BGP speaker to send its BGP peer a set of Outbound
Route Filters (ORFs) which can be used by its BGP peer to filter
outbound route updates to the speaker.
This document defines a new Outbound Route Filter type for BGP,
termed "Nexthop Outbound Route Filter", which can be used to perform
Nexthop based route filtering. The Nexthop ORF only supports exact
nexthop address matching.
2. Motivation
Advertisement of Multiple Paths (referred to as AMP) in BGP has been
defined in [ADD-PATH] and [MULTI-NEXTHOP]. So a BGP speaker,
especially route reflector and IX server, MAY advertise multiple
paths to its peer for a specific prefix. When we deploy AMP in our
network, multiple paths for each prefix MAY be advertised between a
BGP speaker and its BGP peer. But in some cases, a BGP router doesn't
want to receive those routes with a specific nexthop address from its
BGP peers. An alternative method for a BGP router to filter out those
routes is based on local routing policy when it received them, but
using Nexthop based ORF MAY be a better choice in such a scenario.
Consider the following scenarios:
Mach Expires April 12, 2007 [Page 2]
Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt October 2006
+------------------------+
| AS1 |
| +-----+ +-----+ |
| |ASBR1| |ASBR2| |
| +-----+ +-----+ |
+----|--------------|----+
| |
| |
+---------|--------------|--------+
| +-----+ +-----+ |
| |ASBR3| |ASBR4| |
| +-----+ +-----+ |
| \ / |
| +\-----/+ AS2 |
| | RR | |
| +--/-\--+ |
| / \ |
| +------+ +------+ |
| | R1 | | R2 | |
| +------+ +------+ |
+---------------------------------+
Figure 1: AMP scenario
As illustrated above in Figure 1, if we deploy AMP in AS2, that is
each router in AS2 has the AMP capability. So the RR MAY advertise
two paths to R1 and R2 respectively for each prefix. However, in some
cases, R1 or R2 doesn't want to receive those routes which are sent
from ASBR1 or ASBR2. In order to avoid unwanted routing updates, R1
or R2 MAY send a Nexthop based Outbound Route Filer to its peer (RR)
and the RR would apply this filter when it advertises routes to R1 or
R2. So, using Nexthop based ORF is a simple method which can satisfy
the above requirement in such scenario.
Mach Expires April 12, 2007 [Page 3]
Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt October 2006
+------------------------+
| +-----+ |
| |ASBR1| |
| +-----+ AS1 |
+----------|-------------+
|
+---------------|----------------+
| +-------+ AS2 |
| | ASBR21| |
| +-/---\-+ |
| / \ |
| +------+/ \+------+ |
| | R1 | | R2 | |
| +------+\ /+------+ |
| \ / |
| +-\---/-+ |
| | ASBR22| |
| +---|---+ |
+---------------|----------------+
|
+----------|-------------+
| +-----+ AS3 |
| |ASBR3| |
| +-----+ |
+------------------------+
Figure 2: Multi-homing scenario
Figure 2 is another scenario. As usual, in such a scenario R1 and R2
MAY receive two paths for each prefix, one with nexthop address of
ASBR1 is from ASBR21 and the other with nexthop address of ASBR3 is
from ASBR22. But for some reason, R1 prefers to choose ASBR21 as its
exit ASBR and R2 prefers to choose ASBR22 as its exit ASBR. So R1
doesn't need to receive those routes with nexthop address of ASBR1,
and R2 also doesn't need to receive those routes with nexthop address
of ASBR3. R1 or R2 can use the local policy to filter out those
unwanted routes when it received them. But in such a scenario, using
Nexthop based ORF is easier to do so.
3. Nexthop ORF-type
The Nexthop ORF allows one to express ORFs in terms of nexthop
address. That is, it provides nexthop address based route filtering,
including nexthop address based matching.
Conceptually a Nexthop ORF entry consists of the
fields<Sequence,Match,Length,Nexthop>.
Mach Expires April 12, 2007 [Page 4]
Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt October 2006
The "Sequence" field specifies the relative ordering of the entry,
this field is an unsigned 32-bit value.
The "Match" field specifies whether this entry is "PERMIT" (value 0)
or "DENY" (value 1).
The Length field specifies the length of Nexthop measured in octets,
this field is an unsigned 16-bit value.
The Nexthop filed contains the Network Address of the next router on
the path to the destination. This field MAY be an IPv4 address, IPv6
address or any other kinds of addresses.
4. Nexthop ORF Encoding
The value of the ORF-type for Nexthop ORF-type is <TBD>.
A Nexthop 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 as follows:
+--------------------------------+
| Sequence (4 octets) |
+--------------------------------+
| Length (2 octet) |
+--------------------------------+
| Nexthop ( variable length) |
+--------------------------------+
Figure 3: Nexthop ORF entry format
The "Nexthop" field is a variable length string whose length is
determined by "Length" field. This field contains the next hop
address which COULD be used by its peer to filter outbound route
updates to the speaker.
5. Capability Specification for Nexthop ORF
The Outbound Route Filter capability has been defined in [BGP-ORF].
In this document, in order to implement Nexthop based ORF, we just
need to add a new ORF-type for Nexthop based Outbound Route Filter.
The Nexthop ORF-type is <TBD.
6. Nexthop ORF Matching
In addition to the general matching rules defined in [BGP-ORF],
there are no more other specific matching rules for Nexthop based ORF.
Nexthop based ORF only supports exact nexthop address matching.
Mach Expires April 12, 2007 [Page 5]
Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt October 2006
7. Security Considerations
This extension to BGP does not change the underlying security issues.
8. IANA Considerations
This document specifies a new Outbound Route Filter (ORF) type:
Nexthop ORF type. The value of the ORF-type is <TBD>.
9. References
9.1. Normative References
[BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol
4 (BGP-4)", RFC 4271, January 2006.
[BGP-ORF] Chen, E., and Rekhter, Y., "Outbound Route Filtering
Capability for BGP-4", draft-ietf-idr-route-filter-15.txt,
July 2006.
[ASPATH-ORF] Keyur, P., and Susan, H., "Aspath Based Outbound Route
Filter for BGP-4", draft-ietf-idr-aspath-orf-08.txt,
January 2006.
[PREFIX-ORF] Chen, E., and Sangli S., " Address Prefix Based Outbound
Route Filter for BGP-4", draft-ietf-idr-bgp-prefix-orf-
04.txt, July 2006.
[ADD-PATH] Walton, D., and Chen, E., "Advertisement of Multiple Paths
in BGP", draft-walton-bgp-add-paths-05.txt, February 2006.
[MULTI-NEXTHOP] Bhatia, M., Joel, M., and Jakma, P., "Advertising
Multiple NextHop Routes in BGP", draft-bhatia-bgp-multiple-
next-hops-01.txt, August 2006.
9.2. Informative References
Author's Addresses
Mach Chen
Huawei Technologies CO,.LTD.
KuiKe Building, No.9 Xinxi Rd.,
Shang-Di Information Industry Base,
Hai-Dian District Beijing P.R. China 100085
Email: mach@huawei.com
Mach Expires April 12, 2007 [Page 6]
Internet-Draft draft-chen-idr-bgp-nexthop-orf-00.txt October 2006
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 (2006).
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Mach Expires April 12, 2007 [Page 7]