Network Working Group Q. Zeng
Internet-Draft J. Dong
Intended status: Standards Track Huawei Technologies
Expires: May 3, 2012 J. Heitz
Ericsson Inc.
K. Patel
Cisco Systems
R. Shakir
Cable&Wireless Worldwide
Z. Huang
China Telecom
October 31, 2011
One-time Address-Prefix Based Outbound Route Filter for BGP-4
draft-zeng-idr-one-time-prefix-orf-01
Abstract
This document defines a new Outbound Router Filter (ORF) type for
BGP, termed "One-time Address Prefix Outbound Route Filter", which
would allow a BGP speaker to send to its BGP peer a route refresh
request with a set of address-prefix-based filters to make the peer
re-advertise only the specific routes matching the filters to the
speaker. This ORF-type enables a BGP speaker to replay or recover
some specific "problematic" routes without requiring its peer to re-
advertise the whole Adj-RIB-Out of a specific address family, which
makes the trouble shooting operation (such as packets tracking) more
efficient and reduces the impact on network stability. This filter
does not change the outbound route filters on BGP peers and should
only be used for one-time filtering.
Requirements Language
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].
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/.
Zeng, et al. Expires May 3, 2012 [Page 1]
Internet-Draft One-time Address-Prefix Based ORF October 2011
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 May 3, 2012.
Copyright Notice
Copyright (c) 2011 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Zeng, et al. Expires May 3, 2012 [Page 2]
Internet-Draft One-time Address-Prefix Based ORF October 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. One-time Address Prefix ORF-Type . . . . . . . . . . . . . . . 4
3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Zeng, et al. Expires May 3, 2012 [Page 3]
Internet-Draft One-time Address-Prefix Based ORF October 2011
1. Introduction
The Outbound Route Filtering Capability defined in [RFC5291] 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.
During some network maintenance, BGP speaker only needs to retrieve
some specific "problematic" routes from its peer if the routes are
possibly lost or contain some problematic attributes for some reason,
but send ROUTE-REFRESH will lead to the peer re-advertising its whole
Adj-RIB-Out. Such large numbers of updates include a lot of
unnecessary routes which would make trouble shooting operation (such
as packets tracking) more difficult, and is a waste of processing
resources and bandwidth. With the increase of IPV6 deployment, this
problem could be more significant. Even configured with ORF
mechanism as defined in [RFC5291], on receipt of a ROUTE-REFRESH
message, the peer will re-advertise all the routes matching current
outbound route filters, i.e., the whole Adj-Rib-Out for this BGP
speaker. Since in this case the BGP speaker does not want to change
the outbound route filters on its peer, this problem cannot be solved
by current ORF mechanism.
This document defines a new Outbound Router Filter (ORF) type for
BGP, termed "One-time Address Prefix Outbound Route Filter", which
would allow a BGP speaker to send to its BGP peer a route refresh
request with a set of address-prefix-based filters to make the peer
re-advertise only the specific routes matching the filters to the
speaker. This ORF-type enables a BGP speaker to replay or recover
some specific "problematic" routes without requiring its peer to re-
advertise the whole Adj-RIB-Out of specific address family, which
makes the trouble shooting operation (such as packets tracking) more
efficient and reduces the impact on network stability. This filter
does not change the outbound route filters on BGP peers and should
only be used for one-time filtering.
Consider the following scenario: In an Inter-AS environment, if
ASBR-A received a malformed UPDATE from ASBR-B and treated it as
withdraw. For Operator-A, the log on the ASBR-A was not enough to
judge whether the UPDATE was incorrectly sent by ASBR-B or
incorrectly processed by ASBR-A. A good method is to replay and
debug the packets. One-time Prefix ORF is a low impact way to
refresh the UPDATE.
2. One-time Address Prefix ORF-Type
This document defines a new ORF type: One-time Address Prefix ORF.
Zeng, et al. Expires May 3, 2012 [Page 4]
Internet-Draft One-time Address-Prefix Based ORF October 2011
In the following description, the sending speaker sends a one-time
ORF request and the receiving speaker receives it and sends back the
routes to satisfy the request.
As specified in the [RFC5291], an ORF entry is a tuple of the form
<AFI/SAFI, ORF-Type, Action, Match, ORF-value> an ORF consists of one
or more ORF entries that have a common AFI/SAFI and ORF-Type. An ORF
is identified by <AFI/SAFI, ORF-Type>.
The format of One-time Address Prefix ORF-Type entry is the same as
the encoding of Address Prefix ORF in [RFC5292], the specific fields
are defined as follows:
Since the semantics of this new ORF-Type is always "one-time
filtering" and has no impact on existing ORFs, the Action field MUST
be ignored.
The matching rules of the One-time Address Prefix ORF are the same as
defined in Address-Prefix-Based ORF [RFC5292].
The ORF entries of this type are used as one-time filters that MUST
not change any previously installed ORF entry on the receiving
speaker.
3. Operation
The capability negotiation of <AFI/SAFI, One-time Address Prefix ORF>
MUST NOT delay the advertisement of routes with this AFI/SAFI.
The received One-time Address Prefix ORF entries SHOULD only be used
for one-time route filtering and MUST NOT be saved locally. The
received One-time Address Prefix ORF entries MUST NOT modify the
outbound route filters on the receiving speaker (either locally
configured or received from the sending speaker through ORF).
On receipt of ROUTE-REFRESH message with One-time Address Prefix ORF
entries, the receiving speaker SHOULD re-advertise to the sending
speaker the routes from the Adj-RIB-Out associated with the sending
speaker which pass the entries carried in the One-time Address Prefix
ORF as well as the locally saved ORFs (if any) received from the
sending speaker.
Since different processing orders may lead to different results, the
One-time ORFs and the regular ORFs SHOULD not be encoded in one
route-refresh message.
During the period when the receiving speaker is sending updates to
Zeng, et al. Expires May 3, 2012 [Page 5]
Internet-Draft One-time Address-Prefix Based ORF October 2011
satisfy the One-time ORF request, it may experience other routing
activity that will require it to send updates unrelated to the One-
time ORF request. It is permitted to send these updates before it
has completed sending the One-time ORF related updates.
Similarly, if a route that passes the One-time ORF has already been
sent and the receiving speaker experiences routing activity that
changes this route and the receiving speaker has not yet sent all
routes to satisfy the One-time ORF request, it is permitted to send
the changed route immediately.
Details about how to interoperate when both One-time ORF Capability
and the Enhanced Route Refresh Capability as described in
[I-D.keyur-bgp-enhanced-route-refresh] are enabled will be discussed
in the next version.
4. IANA Considerations
This document specifies a new Outbound Route Filtering (ORF) type,
One-time Address-Prefix ORF. The value of the ORF-type needs to be
assigned by the IANA.
5. Security Considerations
This extension to BGP does not change the underlying security issues
in [RFC4271].
6. Acknowledgements
The authors would like to thank Enke Chen, Susan Hares, Haibo Wang,
Jiawei Dong, Yaqun Xiao and Mach Chen for their valuable suggestions
and comments to this document.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2918] Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
September 2000.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Zeng, et al. Expires May 3, 2012 [Page 6]
Internet-Draft One-time Address-Prefix Based ORF October 2011
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering
Capability for BGP-4", RFC 5291, August 2008.
[RFC5292] Chen, E. and S. Sangli, "Address-Prefix-Based Outbound
Route Filter for BGP-4", RFC 5292, August 2008.
7.2. Informative References
[I-D.keyur-bgp-enhanced-route-refresh]
Patel, K., Chen, E., and B. Venkatachalapathy, "Enhanced
Route Refresh Capability for BGP-4",
draft-keyur-bgp-enhanced-route-refresh-02 (work in
progress), March 2011.
Authors' Addresses
Qing Zeng
Huawei Technologies
Huawei Building, No.156 Beiqing Rd
Beijing 100095
China
Email: zengqing@huawei.com
Jie Dong
Huawei Technologies
Huawei Building, No.156 Beiqing Rd
Beijing 100095
China
Email: jie.dong@huawei.com
Jakob Heitz
Ericsson Inc.
100 Headquarters Drive
San Jose, CA 95134
USA
Email: jakob.heitz@ericsson.com
Zeng, et al. Expires May 3, 2012 [Page 7]
Internet-Draft One-time Address-Prefix Based ORF October 2011
Keyur Patel
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: keyupate@cisco.com
Rob Shakir
Cable&Wireless Worldwide
London
UK
Email: rjs@cw.net
ZhiLan Huang
China Telecom
109 West Zhongshan Ave
Guangzhou 510630
China
Email: huangzl@gsta.com
Zeng, et al. Expires May 3, 2012 [Page 8]