draft-ietf-bess-orf-covering-prefixes-00.txt   draft-ietf-bess-orf-covering-prefixes-01.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: May 14, 2015 Verizon Expires: July 24, 2015 Verizon
R. Bonica R. Bonica
Y. Rekhter
Juniper Networks Juniper Networks
K. Patel K. Patel
Cisco Systems Cisco Systems
L. Yong L. Yong
X. Xu
Huawei Technologies Huawei Technologies
November 10, 2014 January 20, 2015
Covering Prefixes Outbound Route Filter for BGP-4 Covering Prefixes Outbound Route Filter for BGP-4
draft-ietf-bess-orf-covering-prefixes-00 draft-ietf-bess-orf-covering-prefixes-01
Abstract Abstract
This document defines a new ORF-type, called the "Covering Prefixes This document defines a new Outbound Route Filter (ORF) type, called
ORF (CP-ORF)". CP-ORF is applicable in Virtual Hub-and-Spoke VPNs. the "Covering Prefixes ORF (CP-ORF)". CP-ORF is applicable in
It also is applicable in BGP/MPLS Ethernet VPN (EVPN) Networks. Virtual Hub-and-Spoke VPNs. It also is applicable in BGP/MPLS
Ethernet VPN (EVPN) networks.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 47 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 May 14, 2015. This Internet-Draft will expire on July 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. CP-ORF Encoding . . . . . . . . . . . . . . . . . . . . . . . 3 2. CP-ORF Encoding . . . . . . . . . . . . . . . . . . . . . . . 3
3. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 6 3. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 6
4. Applicability In Virtual Hub-and-Spoke VPNs . . . . . . . . . 9 4. Applicability In Virtual Hub-and-Spoke VPNs . . . . . . . . . 9
4.1. Multicast Considerations . . . . . . . . . . . . . . . . 12 4.1. Multicast Considerations . . . . . . . . . . . . . . . . 12
5. Applicability In BGP/MPLS Ethernet VPN (EVPN) . . . . . . . . 12 5. Applicability In BGP/MPLS Ethernet VPN (EVPN) . . . . . . . . 12
6. Clean-up . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Clean-up . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
10. Normative References . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Problem Statement 1. Introduction
A BGP [RFC4271] speaker can send Outbound Route Filters (ORF) A BGP [RFC4271] speaker can send Outbound Route Filters (ORF)
[RFC5291] to a peer. The peer uses ORFs to filter routing updates [RFC5291] to a peer. The peer uses ORFs to filter routing updates
that it sends to the BGP speaker. Using ORF, a BGP speaker can that it sends to the BGP speaker. Using ORF, a BGP speaker can
realize a "route pull" paradigm, in which the BGP speaker, on demand, realize a "route pull" paradigm, in which the BGP speaker, on demand,
pulls certain routes from the peer. pulls certain routes from the peer.
This document defines a new ORF-type, called the "Covering Prefixes This document defines a new ORF-type, called the "Covering Prefixes
ORF (CP-ORF)". CP-ORF is applicable in Virtual Hub-and-Spoke VPNs ORF (CP-ORF)". CP-ORF is applicable in Virtual Hub-and-Spoke VPNs
[RFC7024] [RFC4364]. It also is applicable BGP/MPLS Ethernet VPN [RFC7024] [RFC4364]. It also is applicable BGP/MPLS Ethernet VPN
(EVPN) [I-D.ietf-l2vpn-evpn] Networks. (EVPN) [I-D.ietf-l2vpn-evpn] networks.
1.1. Terminology 1.1. Terminology
This document uses the following terms: This document uses the following terms:
o Address Family Indicator (AFI) - defined in [RFC4760] o Address Family Indicator (AFI) - defined in [RFC4760]
o Subsequent Address Family Indicator (SAFI) - defined in [RFC4760] o Subsequent Address Family Indicator (SAFI) - defined in [RFC4760]
o VPN IP Default Route - defined in [RFC7024]. o VPN IP Default Route - defined in [RFC7024].
skipping to change at page 3, line 31 skipping to change at page 3, line 31
o EVPN Instance (EVI) - defined in [I-D.ietf-l2vpn-evpn] o EVPN Instance (EVI) - defined in [I-D.ietf-l2vpn-evpn]
o Unknown MAC Route (UMR) - A regular EVPN MAC/IP Advertisement o Unknown MAC Route (UMR) - A regular EVPN MAC/IP Advertisement
route where the MAC Address Length is set to 48 and the MAC route where the MAC Address Length is set to 48 and the MAC
address to 00:00:00:00:00:00 address to 00:00:00:00:00:00
o Default MAC Gateway (DMG) - An EVPN PE that advertises a UMR o Default MAC Gateway (DMG) - An EVPN PE that advertises a UMR
2. CP-ORF Encoding 2. CP-ORF Encoding
[RFC5291] augments the BGP ROUTE-REFRESH message so that it can carry RFC 5291 augments the BGP ROUTE-REFRESH message so that it can carry
ORF entries. When the ROUTE-REFRESH message carries ORF entries, it ORF entries. When the ROUTE-REFRESH message carries ORF entries, it
includes the following fields: includes the following fields:
o AFI [IANA.AFI] o AFI [IANA.AFI]
o SAFI [IANA.SAFI] o SAFI [IANA.SAFI]
o When-to-refresh (IMMEDIATE or DEFERRED) o When-to-refresh (IMMEDIATE or DEFERRED)
o ORF Type o ORF Type
skipping to change at page 4, line 51 skipping to change at page 4, line 51
+--------------------------------+ +--------------------------------+
Figure 1: CP-ORF Type-specific Encoding Figure 1: CP-ORF Type-specific Encoding
The Sequence field specifies the relative ordering of the entry among The Sequence field specifies the relative ordering of the entry among
all CP-ORF entries. all CP-ORF entries.
The CP-ORF recipient uses the following fields to identify routes The CP-ORF recipient uses the following fields to identify routes
that match the CP-ORF: that match the CP-ORF:
o Minlen o Minlen (measured in bits)
o Maxlen o Maxlen (measured in bits)
o VPN Route Target o VPN Route Target
o Route Type o Route Type
o Host Address o Host Address
See Section 3 for details. See Section 3 for details.
The CP-ORF recipient marks routes that match CP-ORF with the Import The CP-ORF recipient marks routes that match CP-ORF with the Import
skipping to change at page 6, line 43 skipping to change at page 6, line 43
determines which Loc-RIB entries are processed into the corresponding determines which Loc-RIB entries are processed into the corresponding
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 that violates any of the CP-ORF, and that ROUTE-REFRESH message violates any of the encoding
encoding rules specified in Section 2, the BGP speaker MUST log the rules specified in Section 2, the BGP speaker MUST log the event and
event and ignore the entire ROUTE-REFRESH message. ignore the entire ROUTE-REFRESH message.
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 9, line 16 skipping to change at page 9, line 16
with subtype equal to CP-ORF (0x03). As a result of being placed in with subtype equal to CP-ORF (0x03). As a result of being placed in
Adj-RIB-Out, the route is advertised to the peer associated with the Adj-RIB-Out, the route is advertised to the peer associated with the
Adj-RIB-Out. Adj-RIB-Out.
Receiving CP-ORF entries with REMOVE or REMOVE-ALL Actions may cause Receiving CP-ORF entries with REMOVE or REMOVE-ALL Actions may cause
a route that has previously been installed in a particular Adj-RIB- a route that has previously been installed in a particular Adj-RIB-
Out be excluded from that Adj-RIB-Out. In this case, as specified in Out be excluded from that Adj-RIB-Out. In this case, as specified in
[RFC4271], "the previously advertised route in that Adj-RIB-Out MUST [RFC4271], "the previously advertised route in that Adj-RIB-Out MUST
be withdrawn from service by means of an UPDATE message". be withdrawn from service by means of an UPDATE message".
[RFC5291] states that a BGP speaker should respond to a ROUTE REFRESH RFC 5291 states that a BGP speaker should respond to a ROUTE REFRESH
message as follows: message as follows:
"If the When-to-refresh indicates IMMEDIATE, then after processing "If the When-to-refresh indicates IMMEDIATE, then after processing
all the ORF entries carried in the message the speaker re-advertises all the ORF entries carried in the message the speaker re-advertises
to the peer routes from the Adj-RIB-Out associated with the peer that to the peer routes from the Adj-RIB-Out associated with the peer that
have the same AFI/SAFI as what is carried in the message, and taking have the same AFI/SAFI as what is carried in the message, and taking
into account all the ORF entries for that AFI/SAFI received from the into account all the ORF entries for that AFI/SAFI received from the
peer. The speaker MUST re-advertise all the routes that have been peer. The speaker MUST re-advertise all the routes that have been
affected by the ORF entries carried in the message, but MAY also re- affected by the ORF entries carried in the message, but MAY also re-
advertise the routes that have not been affected by the ORF entries advertise the routes that have not been affected by the ORF entries
skipping to change at page 16, line 40 skipping to change at page 16, line 40
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 makes no IANA requests.
However, this memo uses code points that were reserved from the
first-come-first-served range of the following registries:
+-----------------------------------------------+---------------+
| Registry | Code Point |
+-----------------------------------------------+---------------+
| BGP Outbound Route Filtering (ORF) Types | CP-ORF (65) |
| Transitive Opaque Extended Community Sub-Type | CP-ORF (0x03) |
+-----------------------------------------------+---------------+
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 take 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
9. Acknowledgements 9. Contributors
The following individuals contributed to the development of this
document:
o Yakov Rekhter
o Xiaohu Xu
10. Acknowledgements
The authors wish to acknowledge Han Nguyen and James Uttaro for their The authors wish to acknowledge Han Nguyen and James Uttaro for their
comments and contributions. comments and contributions.
10. Normative References 11. References
11.1. Normative References
[I-D.ietf-l2vpn-evpn] [I-D.ietf-l2vpn-evpn]
Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J. Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., and J.
Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn- Uttaro, "BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn-
evpn-11 (work in progress), October 2014. evpn-11 (work in progress), October 2014.
[IANA.AFI]
IANA, "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers/
address-family-numbers.xhtml>.
[IANA.SAFI]
IANA, "Subsequent Address Family Identifiers (SAFI)
Parameters", <http://www.iana.org/assignments/safi-
namespace/safi-namespace.xhtml#safi-namespace-2>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006. Communities Attribute", RFC 4360, February 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
skipping to change at page 18, line 16 skipping to change at page 18, line 29
VPNs", RFC 6513, February 2012. VPNs", RFC 6513, February 2012.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012. VPNs", RFC 6514, February 2012.
[RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, [RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter,
Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS
VPNs", RFC 7024, October 2013. VPNs", RFC 7024, October 2013.
11.2. Informative References
[IANA.AFI]
IANA, "Address Family Numbers",
<http://www.iana.org/assignments/address-family-numbers/
address-family-numbers.xhtml>.
[IANA.SAFI]
IANA, "Subsequent Address Family Identifiers (SAFI)
Parameters", <http://www.iana.org/assignments/safi-
namespace/safi-namespace.xhtml#safi-namespace-2>.
Authors' Addresses Authors' Addresses
Huajin Jeng Huajin Jeng
AT&T AT&T
Email: hj2387@att.com Email: hj2387@att.com
Luay Jalil Luay Jalil
Verizon Verizon
skipping to change at page 18, line 27 skipping to change at page 19, line 4
Huajin Jeng Huajin Jeng
AT&T AT&T
Email: hj2387@att.com Email: hj2387@att.com
Luay Jalil Luay Jalil
Verizon Verizon
Email: luay.jalil@verizon.com Email: luay.jalil@verizon.com
Ron Bonica Ron Bonica
Juniper Networks Juniper Networks
2251 Corporate Park Drive 2251 Corporate Park Drive
Herndon, Virginia 20170 Herndon, Virginia 20170
USA USA
Email: rbonica@juniper.net Email: rbonica@juniper.net
Yakov Rekhter
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, California 94089
USA
Email: yakov@juniper.net
Keyur Patel Keyur Patel
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, California 95134 San Jose, California 95134
USA USA
Email: keyupate@cisco.com Email: keyupate@cisco.com
Lucy Yong Lucy Yong
Huawei Technologies Huawei Technologies
Austin, Texas Austin, Texas
USA USA
Email: lucy.yong@huawei.com Email: lucy.yong@huawei.com
Xiaohu Xu
Huawei Technologies
Beijing
China
Email: xuxiaohu@huawei.com
 End of changes. 25 change blocks. 
44 lines changed or deleted 61 lines changed or added

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