draft-ietf-bess-orf-covering-prefixes-04.txt   draft-ietf-bess-orf-covering-prefixes-05.txt 
BESS Routing Working Group H. Jeng BESS 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: August 24, 2015 Verizon Expires: September 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
February 20, 2015 March 6, 2015
Covering Prefixes Outbound Route Filter for BGP-4 Covering Prefixes Outbound Route Filter for BGP-4
draft-ietf-bess-orf-covering-prefixes-04 draft-ietf-bess-orf-covering-prefixes-05
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 August 24, 2015. This Internet-Draft will expire on September 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 2, line 48 skipping to change at page 2, line 48
1. Introduction 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)". A BGP speaker sends a CP-ORF to a peer in order to
[RFC7024] [RFC4364]. It also is applicable BGP/MPLS Ethernet VPN pull routes that cover a specified host address. A prefix covers a
(EVPN) [I-D.ietf-l2vpn-evpn] networks. host address if it can be used to forward traffic towards that host
address. Section 3 provides a more complete description of covering
prefix selection criteria.
CP-ORF is applicable in Virtual Hub-and-Spoke VPNs [RFC7024]
[RFC4364]. It also is applicable BGP/MPLS Ethernet VPN (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 Identifier (AFI) - defined in [RFC4760] o Address Family Identifier (AFI) - defined in [RFC4760]
o Subsequent Address Family Identifier (SAFI) - defined in [RFC4760] o Subsequent Address Family Identifier (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 4, line 45 skipping to change at page 4, line 47
+--------------------------------+ +--------------------------------+
| Route Type (8 bits) | | Route Type (8 bits) |
+--------------------------------+ +--------------------------------+
| Host Address | | Host Address |
| (0, 32, 48 or 128 bits) | | (0, 32, 48 or 128 bits) |
| .... | ....
+--------------------------------+ +--------------------------------+
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 CP-ORF recipient uses the following fields to select routes
all CP-ORF entries. matching the CP-ORF:
The CP-ORF recipient uses the following fields to identify routes o Sequence: Relative position of CP-ORF entry among other CP-ORF
that match the CP-ORF: entries
o Minlen (measured in bits) o Minlen: Minimum length of selected route (measured in bits)
o Maxlen (measured in bits)
o VPN Route Target o Maxlen: Maximum length of selected route (measured in bits)
o Route Type o VPN Route Target : VPN Route Target carried by selected route
o Host Address o Route Type: Type of selected route
o Host Address: Address covered by selected route
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
Route Target before advertising those routes to the CP-ORF Route Target before advertising those routes to the CP-ORF
originator. See Section 3 for details. originator. See Section 3 for details.
If the ROUTE-REFRESH AFI is equal to IPv4: If the ROUTE-REFRESH AFI is equal to IPv4:
o The value of Minlen MUST be less than or equal to 32 o The value of Minlen MUST be less than or equal to 32
skipping to change at page 9, line 35 skipping to change at page 9, line 35
"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
carried in the message." carried in the message."
When the ROUTE-REFRESH message includes one or more CP-ORF entries, When the ROUTE-REFRESH message includes only CP-ORF entries, the BGP
the BGP speaker MUST re-advertise routes that have been affected by speaker MUST re-advertise routes that have been affected by these CP-
ORF entries carried by the message. While the speaker MAY also re- ORF entries. It is RECOMMENDED not to re-advertise the routes that
advertise the routes that have not been affected by the ORF entries have not been affected by the CP-ORF entries.
carried in the message, this memo RECOMMENDS not to re-advertise the
routes that have not been affected. The behavior when the ROUTE-REFRESH message includes one or more CP-
ORF entries and one or more ORF entries of a different type remains
unchanged from that described in RFC 5291.
4. Applicability In Virtual Hub-and-Spoke VPNs 4. Applicability In Virtual Hub-and-Spoke VPNs
In a Virtual Hub-and-Spoke environment, VPN sites are attached to In a Virtual Hub-and-Spoke environment, VPN sites are attached to
Provider Edge (PE) routers. For a given VPN, a PE router acts in Provider Edge (PE) routers. For a given VPN, a PE router acts in
exactly one of the following roles: exactly one of the following roles:
o As neither a V-hub nor a V-Spoke o As neither a V-hub nor a V-Spoke
o As a V-hub o As a V-hub
skipping to change at page 17, line 12 skipping to change at page 17, line 22
IANA is requested to update the above mentioned registry entries so IANA is requested to update the above mentioned registry entries so
that they include a stable reference to this memo. 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. See
Section 5 of RFC 5291 for negotiation details.
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.
Security considerations for BGP are presented in RFC4271 while Security considerations for BGP are presented in RFC4271 while
further security analysis of BGP is found in [RFC6952]. further security analysis of BGP is found in [RFC6952].
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
The authors wish to acknowledge Han Nguyen and James Uttaro for their The authors wish to acknowledge Han Nguyen, James Uttaro and Alvaro
comments and contributions. Retana for their comments and contributions.
11. References 11. References
11.1. Normative 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.
[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
Networks (VPNs)", RFC 4364, February 2006.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, November 2006. Private Networks (VPNs)", RFC 4684, November 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January "Multiprotocol Extensions for BGP-4", RFC 4760, January
2007. 2007.
skipping to change at page 19, line 5 skipping to change at page 19, line 10
[IANA.EVPN] [IANA.EVPN]
IANA, "Ethernet VPN (EVPN)", IANA, "Ethernet VPN (EVPN)",
<http://www.iana.org/assignments/evpn/evpn.xhtml>. <http://www.iana.org/assignments/evpn/evpn.xhtml>.
[IANA.SAFI] [IANA.SAFI]
IANA, "Subsequent Address Family Identifiers (SAFI) IANA, "Subsequent Address Family Identifiers (SAFI)
Parameters", <http://www.iana.org/assignments/safi- Parameters", <http://www.iana.org/assignments/safi-
namespace/safi-namespace.xhtml#safi-namespace-2>. namespace/safi-namespace.xhtml#safi-namespace-2>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, May 2013. Guide", RFC 6952, May 2013.
Authors' Addresses Authors' Addresses
Huajin Jeng Huajin Jeng
AT&T AT&T
 End of changes. 18 change blocks. 
33 lines changed or deleted 39 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/