draft-ietf-bess-orf-covering-prefixes-01.txt   draft-ietf-bess-orf-covering-prefixes-02.txt 
BESS Routing Working Group H. Jeng BESS Routing Working Group H. Jeng
Internet-Draft AT&T Internet-Draft AT&T
Intended status: Standards Track L. Jalil Intended status: Standards Track L. Jalil
Expires: July 24, 2015 Verizon Expires: August 7, 2015 Verizon
R. Bonica R. Bonica
Juniper Networks Juniper Networks
K. Patel K. Patel
Cisco Systems Cisco Systems
L. Yong L. Yong
Huawei Technologies Huawei Technologies
January 20, 2015 February 3, 2015
Covering Prefixes Outbound Route Filter for BGP-4 Covering Prefixes Outbound Route Filter for BGP-4
draft-ietf-bess-orf-covering-prefixes-01 draft-ietf-bess-orf-covering-prefixes-02
Abstract Abstract
This document defines a new Outbound Route Filter (ORF) type, called This document defines a new Outbound Route Filter (ORF) type, called
the "Covering Prefixes ORF (CP-ORF)". CP-ORF is applicable in the "Covering Prefixes ORF (CP-ORF)". CP-ORF is applicable in
Virtual Hub-and-Spoke VPNs. It also is applicable in BGP/MPLS Virtual Hub-and-Spoke VPNs. It also is applicable in BGP/MPLS
Ethernet VPN (EVPN) networks. Ethernet VPN (EVPN) networks.
Requirements Language Requirements Language
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on July 24, 2015. This Internet-Draft will expire on August 7, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 44 skipping to change at page 6, line 44
Adj-RIB-Out. Mechanisms such as RT-Contstrain [RFC4684] and ORF Adj-RIB-Out. Mechanisms such as RT-Contstrain [RFC4684] and ORF
[RFC5291] enable a router's peer to influence the Outbound Filter. [RFC5291] enable a router's peer to influence the Outbound Filter.
Therefore, the Outbound Filter for a given peer is constructed using Therefore, the Outbound Filter for a given peer is constructed using
a combination of the locally configured policy and the information a combination of the locally configured policy and the information
received via RT-Constrain and ORF from the peer. received via RT-Constrain and ORF from the peer.
Using this model we can describe the operations of CP-ORF as follows: Using this model we can describe the operations of CP-ORF as follows:
When a BGP speaker receives a ROUTE-REFRESH message that contains a When a BGP speaker receives a ROUTE-REFRESH message that contains a
CP-ORF, and that ROUTE-REFRESH message violates any of the encoding CP-ORF, and that ROUTE-REFRESH message violates any of the encoding
rules specified in Section 2, the BGP speaker MUST log the event and rules specified in Section 2, the BGP speaker MUST ignore the entire
ignore the entire ROUTE-REFRESH message. ROUTE-REFRESH message. It SHOULD also log the event. However, an
implementation MAY apply logging thresholds to avoid excessive
messaging or log file overflow.
Otherwise, the BGP speaker processes each CP-ORF entry as indicated Otherwise, the BGP speaker processes each CP-ORF entry as indicated
by the Action field. If the Action is equal to ADD, the BGP speaker by the Action field. If the Action is equal to ADD, the BGP speaker
adds the CP-ORF entry to the Outbound Filter associated with the peer adds the CP-ORF entry to the Outbound Filter associated with the peer
in the position specified by the Sequence field. If the Action is in the position specified by the Sequence field. If the Action is
equal to REMOVE, the BGP speaker removes the CP-ORF entry from the equal to REMOVE, the BGP speaker removes the CP-ORF entry from the
Outbound Filter. If the Action is equal to REMOVE-ALL, the BGP Outbound Filter. If the Action is equal to REMOVE-ALL, the BGP
speaker removes all CP-ORF entries from the Outbound Filter. speaker removes all CP-ORF entries from the Outbound Filter.
Whenever the BGP speaker applies an Outbound Filter to a route Whenever the BGP speaker applies an Outbound Filter to a route
skipping to change at page 16, line 38 skipping to change at page 16, line 38
Each CP-ORF consumes memory and compute resources on the device that Each CP-ORF consumes memory and compute resources on the device that
supports it. Therefore, in order to obtain optimal performance, BGP supports it. Therefore, in order to obtain optimal performance, BGP
speakers periodically evaluate all CP-ORFs that they have originated speakers periodically evaluate all CP-ORFs that they have originated
and remove unneeded CP-ORFs. The criteria by which a BGP speaker and remove unneeded CP-ORFs. The criteria by which a BGP speaker
identifies unneeded CP-ORF entries is a matter of local policy, and identifies unneeded CP-ORF entries is a matter of local policy, and
is beyond the scope of this document. is beyond the scope of this document.
7. IANA Considerations 7. IANA Considerations
This memo makes no IANA requests. This memo uses code points from the first-come-first-served range of
the following registries:
However, this memo uses code points that were reserved from the
first-come-first-served range of the following registries:
+-----------------------------------------------+---------------+ +-----------------------------------------------+---------------+
| Registry | Code Point | | Registry | Code Point |
+-----------------------------------------------+---------------+ +-----------------------------------------------+---------------+
| BGP Outbound Route Filtering (ORF) Types | CP-ORF (65) | | BGP Outbound Route Filtering (ORF) Types | CP-ORF (65) |
| Transitive Opaque Extended Community Sub-Type | CP-ORF (0x03) | | Transitive Opaque Extended Community Sub-Type | CP-ORF (0x03) |
+-----------------------------------------------+---------------+ +-----------------------------------------------+---------------+
IANA is requested to update the above mentioned registry entries so
that they include a stable reference to this memo.
8. Security Considerations 8. Security Considerations
Each CP-ORF consumes memory and compute resources on the device that Each CP-ORF consumes memory and compute resources on the device that
supports it. Therefore, a device supporting CP-ORF takes the supports it. Therefore, a device supporting CP-ORF takes the
following steps to protect itself from oversubscription: following steps to protect itself from oversubscription:
o When negotiating the ORF capability, advertise willingness to o When negotiating the ORF capability, advertise willingness to
receive the CP-ORF only to known, trusted iBGP peers receive the CP-ORF only to known, trusted iBGP peers
o Enforce a per-peer limit on the number of CP-ORFs that can be o Enforce a per-peer limit on the number of CP-ORFs that can be
installed at any given time. Ignore all requests to add CP-ORFs installed at any given time. Ignore all requests to add CP-ORFs
beyond that limit beyond that limit
Section 5 of RFC 5291 describes how BGP speakers use the Outbound
Route Filtering Capability to advertise their intention to send CP-
ORFs and their willingness to accept CP-ORFs.
9. Contributors 9. Contributors
The following individuals contributed to the development of this The following individuals contributed to the development of this
document: document:
o Yakov Rekhter o Yakov Rekhter
o Xiaohu Xu o Xiaohu Xu
10. Acknowledgements 10. Acknowledgements
 End of changes. 8 change blocks. 
10 lines changed or deleted 17 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/