IDR Working Group W. Wang Internet-Draft A. Wang Intended status: Standards Track China Telecom Expires: December 3, 2020 June 1, 2020 Route Distinguisher Outbound Route Filter for BGP-4 draft-wang-idr-rd-orf-00 Abstract This draft defines a new Outbound Route Filter (ORF) type, called the Route Distinguisher ORF (RD-ORF). RD-ORF is applicable in BGP/MPLS IP Virtual Private Networks and Ethernet VPN, in which the Route Reflector (RR) and Autonomous System border router (ASBR) do not maintain the VPN routes. 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 https://datatracker.ietf.org/drafts/current/. 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 December 3, 2020. Copyright Notice Copyright (c) 2020 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 (https://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. Wang & Wang Expires December 3, 2020 [Page 1] Internet-Draft RD-ORF June 2020 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. RD-ORF Encoding . . . . . . . . . . . . . . . . . . . . . . . 3 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Application in Option B cross-domain scenario . . . . . . 5 5.2. Application in Option C cross-domain scenario . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction According to the description in [RFC4364], MPLS VPN can cross-domain networking in three ways, we usually called them Option A, B and C. In Option A, an Autonomous System border router (ASBR) is attached directly to an ASBR in another AS, they act as CE/PE of each other and exchange VPN route, so they SHOULD maintain VPN route information in Virtual Routing Forwarding (VRF). So, the route control mechanism based on Prefix Limit can be used in Option A scenario, to prevent the number of routes transmitted by one of them from exceeding the maximum number of another's routing tables. In Option B, a ASBR is connected to another via EBGP. ASBRs only perform VPN routing forwarding, the maintenance of VRF is done by PEs. In Option C, RRs are connected each other via MP-EBGP and are responsible for VPN routing forwarding, without maintaining VRFs. Due to ASBRs and RRs do not maintain VRFs in Option B and C, the route control mechanism based on Prefix Limit does not work. [RFC5291] defines a BGP-based mechanism called Outbound Route Filter (ORF), which allows a BGP speaker to send a set of ORFs to its BGP peers, the peers will constrain the routing information that they decide to transmit to the speaker. This draft defines a new ORF-type, called the Route Distinguisher ORF (RD-ORF). When the route table of a BGP speaker reaches its maximum, the BGP speaker will send a RD-ORF to its BGP peers that carry a RD. If a BGP speaker receives a RD-ORF from its BGP peer, it will filter the VPN routes it tends to send according to the RD-ORF entry. RD-ORF is applicable in BGP/MPLS IP Virtual Private Networks [RFC4364], and BGP/MPLS Ethernet VPN (EVPN) networks [RFC7432]. Wang & Wang Expires December 3, 2020 [Page 2] Internet-Draft RD-ORF June 2020 2. Conventions used in this document 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 [RFC2119] . 3. Terminology The following terms are defined in this draft: o RD: Route Distinguisher, defined in [RFC4364] o ORF: Outbound Route Filter, defined in [RFC5291] o AFI: Address Family Identifier, defined in [RFC4760] o SAFI: Subsequent Address Family Identifier, defined in [RFC4760] o EVPN: BGP/MPLS Ethernet VPN, defined in [RFC7432] o RR: Router Reflector, provides a simple solution to the problem of IBGP full mesh connection in large-scale IBGP implementation. o VRF: Virtual Routing Forwarding, a virtual routing table based on VPN instance. 4. RD-ORF Encoding In this draft, we defined a new ORF type called Route Distinguisher Outbound Route Filter (RD-ORF). The ORF entries are carried in the BGP ROUTE-REFRESH message as defined in [RFC5291]. A BGP ROUTE- REFRESH message can carry one or more ORF entries. The ROUTE-REFRESH message which carries ORF entries contains the following fields: o AFI (2 octets) o SAFI (1 octet) o When-to-refresh (1 octet): the value is IMMEDIATE or DEFER o ORF Type (1 octet) o Length of ORF entries (2 octets) A RD-ORF entry contains a common part and type-specific part. The common part is encoded as follows: o Action (2 bits): the value is ADD, REMOVE or REMOVE-ALL Wang & Wang Expires December 3, 2020 [Page 3] Internet-Draft RD-ORF June 2020 o Match (1 bit): the value is PERMIT or DENY o Reserved (5 bits) RD-ORF also contains type-specific part. The encoding of the type- specific part is shown in Figure 1. +---------------------------------------+ | | | Sequence (4 octets) | | | +---------------------------------------+ | | | Route Distinguisher (8 octets) | | | +---------------------------------------+ | | | Reserved (4 octets) | | | +---------------------------------------+ Figure 1: RD-ORF type-specific encoding o Sequence: identifying the order in which RD-ORF is generated o Route Distinguisher: distinguish the different user routes. The RD-ORF filters the VPN routes it tends to send based on Route Distinguisher. Note that if the Action component of an ORF entry specifies REMOVE- ALL, the ORF entry does not include the type-specific part. When the BGP ROUTE-REFRESH message carries RD-ORF entries, it must be set as follows: o The ORF-Type MUST be set to RD-ORF. o The AFI MUST be set to IPv4, IPv6, or Layer 2 VPN (L2VPN). o If the AFI is set to IPv4 or IPv6, the SAFI MUST be set to MPLS- labeled VPN address. o If the AFI is set to L2VPN, the SAFI MUST be set to BGP EVPN. o The Match field MUST be equal to DENY. Wang & Wang Expires December 3, 2020 [Page 4] Internet-Draft RD-ORF June 2020 5. Operation In VPN/EVPN, RD is used to distinguish different user routes. When a BGP speaker's route table reaches its maximum, it will generate a BGP ROUTE-REFRESH message contains a RD-ORF entry, and send it to its BGP peers, reminding them not to send it routes whose Type field in the BGP header is set to UPDATE (BGP UPDATE message). In the RD-ORF entry, the RD field must be set to the Route Distinguisher of the BGP speaker. When a BGP speaker receives a ROUTE-REFRESH message that carries a RD-ORF entry, it will check whether the message violates the encoding rules or not. If the ROUTE-REFRESH message violates the rules, the BGP speaker MUST ignore it and log the event. Otherwise, the BGP speaker checks the Action field of the RD-ORF entry. If the Action field is set to ADD, the BGP speaker adds this entry to the Adj-RIB- out. The location is specified by the Sequence field. If the Action field is set to REMOVE, the BGP speaker removes the CP-ORF entry specified by the Sequence field from the Adj-RIB-out. If the Action field is set to REMOVE-ALL, the BGP speaker removes all entries in the Adj-RIB-out. For a BGP speaker, before sending BGP routes to its peers, it checks the Adj-RIB-out to find the related strategies. If it finds a RD-ORF associated with a BGP peer in the Adj-RIB-out, it will not send any BGP UPDATE message to that peer. 5.1. Application in Option B cross-domain scenario The Option B cross-domain scenario is shown in Figure 2: +------------+------------+ +------------+------------+ | +----+----+ | | +----+----+ | | | | | | | | | | +----+ RR1 +----+ | | +----+ RR2 +----+ | | | | | | | | | | | | | | | +---------+ | | | | +---------+ | | | | | | | | | | | |IBGP IBGP| | | |IBGP IBGP| | | | | | | | | | +-+--+----+ +----+--+-+ +-+--+----+ +----+--+-+ | | | | EBGP | | | | | PE1 | | ASBR1 +----------+ ASBR2 | | PE2 | | | | | | | | | +-+-------+ AS1 +-------+-+ +-+-------+ AS2 +-------+-+ +-------------------------+ +-------------------------+ Figure 2: The Option B cross-domain scenario Wang & Wang Expires December 3, 2020 [Page 5] Internet-Draft RD-ORF June 2020 In this scenario, PE1 and PE2 are responsible for maintaining VPN routing of devices in AS1 and AS2, respectively. There is a direct link between ASBR1 and ASBR2 via EBGP. In AS1, PE1 and ASBR1 establish IBGP session with RR1 to ensure the routes can be transmitted in AS1, same in AS2. Due to the maintenance of VPN routes is only done by PEs. ASBRs cannot know whether the PEs' ability to handle VPN routes has reached the upper limit or not, so it needs the RD-ORF to control the number of routes. Assume that PE1 and PE2 can transmit VPN routes through the network architecture shown in Figure 2. When PE1 thinks it cannot handle more VPN routes, it will send ROUTE-REFRESH message that carries a RD-ORF entry to RR1. The entry consists of the following fields: o AFI is set to IPv4 or IPv6 o SAFI is set to "MPLS-labeled VPN address" o When-to-refresh is set to IMMEDIATE o Action is set to ADD o Match is set to DENY o ORF Type is set to RD-ORF o RD-ORF Sequence is set to 1 o RD-ORF Route Distinguisher is set to RD1 It noted that for a RD, the sequence of the first RD-ORF is equal to 1. When a PE needs to send a second RD-ORF entry associated with the same RD, the RD-ORF sequence SHOULD increment. When RR1 receives the ROUTE-REFRESH message, it checks the to determine whether it is interested in the entry. Then RR1 will check the RD-ORF Route Distinguisher and sequence, find the Route Distinguisher is equal to RD1 and the sequence is equal to 1, indicating that it received the latest entry. If the above conditions are not all met, RR1 will discard the entry; otherwise, RR1 will add the RD-ORF entry into its Adj-RIB-out and stop sending VPN routes containing that RD to PE1, and transmitting this RD-ORF entry to ASBR1. Wang & Wang Expires December 3, 2020 [Page 6] Internet-Draft RD-ORF June 2020 After receiving the RD-ORF entry, ASBR1 will repeat the above process and send the entry to ASBR2. The RD-ORF entry will be transmitted toward PE2, until PE2 receives it and add it into the Adj-RIB-out. Before sending a VPN route (the RD is equal to RD1) toward PE1, PE2 will check its Adj-RIB-out and find the RD-ORF entry prevent it from sending VPN route which carries RD1 to RR2. Then, PE2 will stop sending that VPN route. If PE1 can re-receive the route entries, it will send a ROUTE-REFRESH message to RR1, carrying a RD-ORF entry consists of the following fields: o AFI is set to IPv4 or IPv6 o SAFI is set to "MPLS-labeled VPN address" o When-to-refresh is set to IMMEDIATE o Action is set to REMOVE o Match is set to DENY o ORF Type is set to RD-ORF o RD-ORF Sequence is set to 2 o RD-ORF Route Distinguisher is set to RD1 When RR1 receives the ROUTE-REFRESH message, it checks the to determine whether it is interested in the entry. Then RR1 will check the RD-ORF Route Distinguisher and sequence, find the Route Distinguisher is equal to RD1 and the sequence is equal to 2, indicating that it received the latest entry. If the above conditions are not all met, RR1 will discard the entry; otherwise, RR1 will remove the RD-ORF entry from its Adj-RIB-out and send this entry to ASBR1. After receiving the RD-ORF entry, ASBR1 will repeat the above process and send the entry to ASBR2. The RD-ORF entry will be transmitted toward PE2, until PE2 receives it and remove the entry from the Adj- RIB-out. Before sending a VPN route (the RD is equal to RD1) toward PE1, PE2 will check its Adj-RIB-out and find there is no filter associated with RD1. Then, PE2 will send that VPN route. Wang & Wang Expires December 3, 2020 [Page 7] Internet-Draft RD-ORF June 2020 5.2. Application in Option C cross-domain scenario The Option C cross-domain scenario is shown in Figure 3: Please view in a fixed-width font such as Courier. MP-EBGP +----------------------------------------+ | | +------------+------------+ +------------+------------+ | +----+----+ | | +----+----+ | | | | | | | | | | +----+ RR1 +----+ | | +----+ RR2 +----+ | | | | | | | | | | | | | | | +---------+ | | | | +---------+ | | | | | | | | | | | |IBGP IBGP| | | |IBGP IBGP| | | | | | | | | | +-+--+----+ +----+--+-+ +-+--+----+ +----+--+-+ | | | | | | | | | PE1 | | ASBR1 + + ASBR2 | | PE2 | | | | | | | | | +-+-------+ AS1 +-------+-+ +-+-------+ AS2 +-------+-+ +-------------------------+ +-------------------------+ Figure 3: The Option C cross-domain scenario In this scenario, PE1 and PE2 are responsible for maintaining VPN routing of devices in AS1 and AS2, respectively. In order to reduce the complexity that full-mesh brings to the network, RR1 and RR2 establish MP-BGP session to transmit labeled routes. In AS1, PE1 and ASBR1 establish IBGP session with RR1 to ensure the routes can be transmitted in AS1, same in AS2. Due to the maintenance of VPN routes is only done by PEs. RRs cannot know whether the PEs' ability to handle VPN routes has reached the upper limit or not, so it needs the RD-ORF to control the number of routes. Assume that PE1 and PE2 can transmit VPN routes through the network architecture shown in Figure 3. When PE1 thinks it cannot handle more VPN routes, it will send ROUTE-REFRESH message that carries a RD-ORF entry to RR1. The entry consists of the following fields: o AFI is set to IPv4 or IPv6 o SAFI is set to "BGP EVPN" Wang & Wang Expires December 3, 2020 [Page 8] Internet-Draft RD-ORF June 2020 o When-to-refresh is set to IMMEDIATE o Action is set to ADD o Match is set to DENY o ORF Type is set to RD-ORF o RD-ORF Sequence is set to 1 o RD-ORF Route Distinguisher is set to RD1 When RR1 receives the ROUTE-REFRESH message, it checks the to determine whether it is interested in the entry. Then RR1 will check the RD-ORF Route Distinguisher and sequence, find the Route Distinguisher is equal to RD1 and the sequence is equal to 1, indicating that it received the latest entry. If the above conditions are not all met, RR1 will discard the entry; otherwise, RR1 will remove the RD-ORF entry from its Adj-RIB-out and send this entry to ASBR1 and RR2. After receiving the RD-ORF entry, RR2 and ASBR1 will repeat the above process, then send the entry to ASBR2 and PE2. Before sending a VPN route (the RD is equal to RD1) toward PE1, PE2 will check its Adj-RIB-out and find the RD-ORF entry prevent it from sending VPN route which carries RD1 to RR2. Then, PE2 will stop sending that VPN route. If PE1 can re-receive the VPN routes, it will send a ROUTE-REFRESH message to RR1, carrying RD-ORF entries consist of the following fields: o AFI is set to IPv4 or IPv6 o SAFI is set to "BGP EVPN" o When-to-refresh is set to IMMEDIATE o Action is set to REMOVE o Match is set to DENY o ORF Type is set to RD-ORF o RD-ORF Sequence is set to 2 o RD-ORF Route Distinguisher is set to RD1 Wang & Wang Expires December 3, 2020 [Page 9] Internet-Draft RD-ORF June 2020 When RR1 receives the ROUTE-REFRESH message, it checks the to determine whether it is interested in the entry. Then RR1 will check the RD-ORF Route Distinguisher and sequence, find the Route Distinguisher is equal to RD1 and the sequence is equal to 2, indicating that it received the latest entry. If the above conditions are not all met, RR1 will discard the entry; otherwise, RR1 will remove the RD-ORF entry from its Adj-RIB-out and send this entry to ASBR1 and RR2. After receiving the RD-ORF entry, RR2 and ASBR1 will repeat the above process, then send the entry to ASBR2 and PE2. Before sending a VPN route (the RD is equal to RD1) toward PE1, PE2 will check its Adj-RIB-out and find there is no filter associated with RD1. Then, PE2 will send that VPN route. 6. Security Considerations A BGP speaker will maintain the RD-ORF entries in Adj-RIB-out, this behavior consumes its memory and compute resources. To avoid the excessive consumption of resources, [RFC5291] specifies that a BGP speaker can only accept ORF entries transmitted by its interested peers. 7. IANA Considerations This document defines a new Outbound Route Filter type - Route Distinguisher Outbound Route Filter. The code point is from the "BGP Outbound Route Filtering (ORF) Types". It is recommended to set the code point of RD-ORF to 66. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, . Wang & Wang Expires December 3, 2020 [Page 10] Internet-Draft RD-ORF June 2020 [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, August 2008, . [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, . Authors' Addresses Wei Wang China Telecom Beiqijia Town, Changping District Beijing, Beijing 102209 China Email: wangw36@chinatelecom.cn Aijun Wang China Telecom Beiqijia Town, Changping District Beijing, Beijing 102209 China Email: wangaj3@chinatelecom.cn Wang & Wang Expires December 3, 2020 [Page 11]