| IDR Working Group | W. Wang |
| Internet-Draft | A. Wang |
| Intended status: Standards Track | China Telecom |
| Expires: January 29, 2021 | S. Zhuang |
| J. Dong | |
| H. Wang | |
| Huawei Technologies | |
| July 28, 2020 |
Route Distinguisher Outbound Route Filter (RD-ORF) for BGP-4
draft-wang-idr-rd-orf-02
This draft defines a new Outbound Route Filter (ORF) type, called the Route Distinguisher ORF (RD-ORF). RD-ORF is applicable when the routers do not exchange VPN routing information directly (e.g. routers in single-domain connect via Route Reflector, or routers in Option B/Option C cross-domain scenario).
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 January 29, 2021.
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.
With the rapid growth of network scale, Route Reflector is introduced in order to reduce the network complexity. Routers in the same Autonomous System only need to establish iBGP session with RR to transmit routes.
+----------------------------------------------+
| |
| |
| +---------+ +---------+ |
| | PE1 | | PE4 | |
| +---------+ +---------+ |
| VPN1 \ / VPN2 |
| VPN2 \+---------+ / |
| | | |
| | RR | |
| | | |
| +---------+ \ |
| / \ |
| +---------+/ +---------+ |
| | PE2 | | PE3 | |
| +---------+ +---------+ |
| VPN1 VPN1 |
| AS 100 VPN2 |
+----------------------------------------------+
Figure 1: Single-domain scenario
In VPN scenario shown in Figure 1, PE1 – PE4 establish IBGP sessions with RR to ensure the routes can be transmitted within AS100, where PE1 and PE3 maintain VRFs of VPN1 and VPN2, PE2 maintains VPN1's VRF and PE4 maintains VPN2's VRF. RR don not maintain any VRFs.
When the VRF of VPN1 in PE2 overflows, due to PE2 and other PEs are not iBGP neighbors, BGP Maximum Prefix Features cannot work, so the problem on PE2 cannot be known.
Now, there are two solutions can be used to alleviate this problem:
However, RTC can only specify the VPN routes it want, it cannot control the route limit within one specific VRF. Using Address Prefix ORF to filter VPN routes need to pre-configuration, but it is impossible to know which device may overflow in advance.
This draft defines a new ORF-type, called the Route Distinguisher ORF (RD-ORF). Based on RD-ORF, VPN routes of a VPN can be controlled based on source RD and originator. This mechanism is event-driven and does not need to be pre-configured. When a VRF of a router overflows, the router will find out the main source address and RD of VPN routes in this VRF, and send a RD-ORF to its BGP peer that carrys the RD and the source address. 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 when the routers do not exchange VPN routing information directly (e.g. routers in single-domain connect via Route Reflector, or routers in Option B/Option C cross-domain scenario).
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] .
The following terms are defined in this draft:
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, and MUST be regenerated when it is tended to be sent to other BGP peers. The ROUTE-REFRESH message which carries ORF entries contains the following fields:
A RD-ORF entry contains a common part and type-specific part. The common part is encoded as follows:
RD-ORF also contains type-specific part. The encoding of the type-specific part is shown in Figure 2.
+-----------------------------------------+
| |
| Sequence (4 octets) |
| |
+-----------------------------------------+
| |
| Route Distinguisher (8 octets) |
| |
+-----------------------------------------+
| |
|Source Address sub-TLV (4,6 or 16 octets)|
| |
+-----------------------------------------+
Figure 2: RD-ORF type-specific encoding
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:
In scenario shown in Figure 1, When the VRF of VPN1 in PE1 overflows, it will find out the main source of VPN routes in this VRF, assuming it is PE3. Then, PE1 will extract PE3’s host address and source RD from BGP UPDATE message and generate a BGP ROUTE-REFRESH message contains a RD-ORF entry, and send it to RR. The entry consists of the following fields:
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 RR receives the ROUTE-REFRESH message, it checks <AFI/SAFI, ORF-Type, Sequence, Route Distinguisher, Source Address sub-TLV> to find whether it received the latest entry or not. If not, RR will discard the entry; otherwise, RR will add the RD-ORF entry into its Adj-RIB-out, and regenerate a BGP ROUTE-REFRESH message to send this RD-ORF entry to PE3.
After receiving this ROUTE-REFRESH message that carries a RD-ORF entry, PE3 will repeat the above process to check if it receives the latest entry. If not, PE3 will discard it; otherwise, PE3 will add the RD-ORF entry into its Adj-RIB-out.
Before sending a VPN route (the RD is equal to RD1) toward PE1, PE3 will check its Adj-RIB-out and find the RD-ORF entry prevent it from sending VPN route which carries RD1 to RR. Then, PE3 will stop sending that VPN route.
When the VRF of VPN1 in PE1 no longer overflows, it will send RR a BGP ROUTE-REFRESH message encoded as following:
After receiving the BGP ROUTE-REFRESH message, RR will check whether it receives the latest entry. If not, RR will discard it; otherwise, RR will remove the associated RD-ORF entry from its Adj-RIB-out, and regenerate a BGP ROUTE-REFRESH message to send this RD-ORF entry to PE3.
After receiving this ROUTE-REFRESH message that carries a RD-ORF entry, PE3 will repeat the above process to check if it receives the latest entry. If not, PE3 will discard it; otherwise, PE3 will remove the associated RD-ORF entry from its Adj-RIB-out.
Before sending a VPN route (the RD is equal to RD1) toward PE1, PE3 will check its Adj-RIB-out and find there is no filter associated with RD1. Then, it will send that VPN route.
+--------------------------+ +--------------------------+
| | | |
| | | |
| +---------+ | | +---------+ |
| | PE1 | | | | PE3 | |
| +---------+ | | +---------+ |
| VPN1 \ | | / VPN1 |
| VPN2 \+---------+ EBGP +---------+/ VPN2 |
| | | | | |
| | ASBR1 |-----------| ASBR2 | |
| | | | | |
| +---------+ +---------+ |
| / | | \ |
| +---------+/ | | \+---------+ |
| | PE2 | | | | PE4 | |
| +---------+ | | +---------+ |
| VPN1 | | VPN2 |
| AS1 | | AS2 |
+--------------------------+ +--------------------------+
Figure 3: The Option B cross-domain scenario
The Option B cross-domain scenario is shown in Figure 3:
In this scenario, PE1 - PE4 are responsible for maintaining VPN routing information in AS1 and AS2. There is a direct link between ASBR1 and ASBR2 via EBGP. In AS1, PE1 and PE2 establish IBGP sessions with ASBR1 to ensure the routes can be transmitted in AS1. In AS2, PE3 and PE4 establish IBGP session with ASBR2.
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 - PE4 can transmit VPN routes through the network architecture shown in Figure 3. When the VRF of VPN1 in PE1 overflows, it will check and find out the main source of VPN routes in this VRF is PE3. Then, PE1 will extract PE3's host address and source RD from BGP UPDATE message and generate a BGP ROUTE-REFRESH message contains a RD-ORF entry, and send it to ASBR1. The entry consists of the following fields:
When ASBR1 receives the ROUTE-REFRESH message, it checks the <AFI/SAFI, ORF-Type, Sequence, Route Distinguisher, Source Address sub-TLV> to determine whether it receives the latest RD-ORF entry. If not, ASBR1 will discard the entry; Otherwise, ASBR1 will add the RD-ORF entry into its Adj-RIB-out and regenerate a ROUTE-REFRESH message carries the RD-ORF entry to send it to ASBR2.
After receiving the RD-ORF entry, ASBR2 will repeat the above process to check if it receives the latest entry. If not, ASBR2 will discard it; otherwise, ASBR2 will add the RD-ORF entry into its Adj-RIB-out and send the entry to PE3. PE3 will check it and add the associated entry into its Adj-RIB-out.
Before sending a VPN route (the RD is equal to RD1) toward PE1, PE3 will check its Adj-RIB-out and find the RD-ORF entry prevent it from sending VPN route which carries RD1 to ASBR2. Then, it will stop sending that VPN route.
If PE1 can re-receive the route entries, it will send a ROUTE-REFRESH message to ASBR1, carrying a RD-ORF entry consists of the following fields:
When ASBR1 receives the ROUTE-REFRESH message, it checks the <AFI/SAFI, ORF-Type, Sequence, Route Distinguisher, Source Address sub-TLV> to determine whether it receives the latest RD-ORF entry. If not, ASBR1 will discard the entry; otherwise, ASBR1 will remove the associated RD-ORF entry from its Adj-RIB-out and regenerate a ROUTE-REFRESH message carries the RD-ORF entry to send it to ASBR2.
After receiving the RD-ORF entry, ASBR2 will repeat the above process. ASBR2 will repeat the above process to check if it receives the latest entry. If not, ASBR2 will discard it; otherwise, ASBR2 will remove the associated RD-ORF entry from its Adj-RIB-out and send the entry to PE3. PE3 will check it and remove the associated entry from its Adj-RIB-out.
Before sending a VPN route (the RD is equal to RD1) toward PE1, PE3 will check its Adj-RIB-out and find there is no filter associated with RD1. Then, it will send that VPN route.
+--------------------------+ +--------------------------+
| | | |
| +---------+ | MP-EBGP | +---------+ |
| | RR1 |-------+-------------+-------| RR2 | |
| +---------+ | | +---------+ |
| / \ | | / \ |
| / \ | | / \ |
| / +---------+ +---------+ \ |
| +---------+ | | | | +---------+ |
| | PE1 | | ASBR1 | | ASBR2 | | PE2 | |
| +---------+ | | | | +---------+ |
| VPN1 +---------+ +---------+ VPN1 |
| VPN2 | | VPN2 |
| AS1 | | AS2 |
+--------------------------+ +--------------------------+
Figure 4: The Option C cross-domain scenario
The Option C cross-domain scenario is shown in Figure 4:
In this scenario, PE1 and PE2 are responsible for maintaining VPN routing information in AS1 and AS2. In order to reduce the complexity that full-mesh brings to the network, RR1 and RR2 establish MP-EBGP session to transmit labeled routes. In AS1, PE1 and ASBR1 establish IBGP session with RR1 to ensure the routes can be transmitted in AS1. In AS2, PE2 and ASBR2 establish IBGP session with RR2.
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.
The operating mechanism of RD-ORF is similar to the description in Section 6.1.
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.
This document defines a new Outbound Route Filter type - Route Distinguisher Outbound Route Filter (RD-ORF). 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.
IANA is requested to allocate one code point for Source Address sub-TLV for RD-ORF.
+----+------------------------------------------------------------------+ |Type| Description | +----+------------------------------------------------------------------+ | 1 | IPv4 L3EVPN Source Address TLV | +----+------------------------------------------------------------------+ | 2 | IPv6 L3EVPN Source Address TLV | +----+------------------------------------------------------------------+ | 3 | L2EVPN Source Address TLV | +----+------------------------------------------------------------------+ | 4 | MPLS VPN Source Address TLV | +----+------------------------------------------------------------------+
This document defines the following new RD-ORF sub-TLV types, which should be reflected in the Source Address sub-TLV for RD-ORF Code Point registry: