| IDR Working Group | W. Wang |
| Internet-Draft | A. Wang |
| Intended status: Standards Track | China Telecom |
| Expires: February 25, 2021 | H. Wang |
| Huawei Technologies | |
| G. Mishra | |
| Verizon Inc. | |
| S. Zhuang | |
| J. Dong | |
| Huawei Technologies | |
| August 24, 2020 |
Route Distinguisher Outbound Route Filter (RD-ORF) for BGP-4
draft-wang-idr-rd-orf-03
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 AB/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 February 25, 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 PE1 overflows, due to PE1 and other PEs are not iBGP neighbors, BGP Maximum Prefix Features cannot work, so the problem on PE2 cannot be known.
Now, there are several solutions can be used to alleviate this problem:
However, there are limitations to existing solutions:
1) Route Target Constraint
RTC can only filter the VPN routes from the uninterested VRFs, if the “trashing routes” come from the interested VRF, filter on RTs will erase all prefixes from this VRF.
2) Address Prefix ORF
Using Address Prefix ORF to filter VPN routes need to pre-configuration, but it is impossible to know which prefix may cause overflow in advance.
3) PE-CE edge peer Maximum Prefix
This mechanism can only protect the edge between PE-CE, it can’t be deployed within PE that peered via RR. Depending solely on the edge protection is dangerous, because if only one of the edge points being comprised/error-configured/attacked, then all of PEs within domain are under risk.
4) Configure the Maximum Prefix for each VRF on edge nodes
When a VRF overflows, PE will break down the BGP session with RR according to the Maximum Prefix mechanism. However, there may have several VRFs on PE rely on the PE-RR session, this mechanism will influence other VRFs.
This draft defines a new ORF-type, called the Route Distinguisher ORF (RD-ORF). Using RD-ORF mechanism, 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 AB/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:
The operation of RD-ORF mechanism on each device is independent, each of them makes a local judgement to determine whether it needs to send RD-ORF to its peers.
In general, every VRF on PE is configured a Maximum Prefix, the trigger of RD-ORF mechanism can be set as the number of VPN routes in VRF reach 80% of the Maximum Prefix. For RR, it doesn't have VRF and the machanism can be triggered by other conditions, such as the RR's memory/CPU utilization reaches 80%.
When the RD-ORF mechanism is triggered, the device must send an alarm information to network operators.
In scenario shown in Figure 1, when the VRF of VPN1 in PE1 overflows, PE1 will do analysis and calculation locally to find out the main source of VPN routes in this VRF, assuming it is PE3. Then, PE1 will resolve the host address and corresponding RD of VPN routes from BGP UPDATE message, and generate a BGP ROUTE-REFRESH message contains a RD-ORF entry, and send it to RR. The message contains the following fields:
It noted that the Sequence can uniquely identifies an RD-ORF entry. All VRFs share the sequence field, and the corresponding sequence of RD-ORF sent by each VRF will be recorded on the device.
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.
Before sending a VPN route toward PE1, RR will check its Adj-RIB-out and find there is a filter associated with <RD1, PE3’s host address>. Then, RR will stop sending that VPN route to PE1.
If the processing capacity of RR reaches the limit (e.g. RR's memory/CPU utilization reaches 80%), RR will find out the peer that sends the most routing entries to it, assuming it is PE3. Then, RR will generate a BGP ROUTE-REFRESH message contains a RD-ORF entry based on the result of calculation, and send it to PE3.
After receiving the ROUTE-REFRESH message that carries a RD-ORF entry, PE3 will 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 toward RR, 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.
The BGP Maximum Prefix Features can be configured to protect PE-CE peering at the edge. Therefore, in general, CEs will not cause the overflow of PEs. If the boundary protection measures fail and cause the overflow, the PE can calculate and find the CEs in corresponding VRF, and break down the associated BGP sessions.
When the RD-ORF mechanism is triggered, the alarm information will be generated and sent to the network operators. Operators should manually configure the network to resume normal operation. Due to devices can record the RD-ORF entries sent by each VRF, operators can find the entries needs to be withdrawn, and trigger the withdraw process as described in [RFC5291] manually to delete them on RR/ASBR/target PE after network recovery.
+--------------------------+ +--------------------------+
| | | |
| | | |
| +---------+ | | +---------+ |
| | PE1 | | | | PE3 | |
| +---------+ | | +---------+ |
| VPN1 \ | | / VPN1 |
| VPN2 \+---------+ EBGP +---------+/ VPN2 |
| | | | | |
| | ASBR1 |-----------| ASBR2 | |
| | | | | |
| +---------+ +---------+ |
| / | | \ |
| +---------+/ | | \+---------+ |
| | PE2 | | | | PE4 | |
| +---------+ | | +---------+ |
| VPN1 | | VPN2 |
| AS1 | | AS2 |
+--------------------------+ +--------------------------+
Figure 3: The Option B/Option AB cross-domain scenario
The Option B/Option AB cross-domain scenario is shown in Figure 3:
In Option B cross-domain 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, the RD-ORF mechanism will be implemented as follows:
1) PE1 will check and find out the main source of VPN routes in this VRF is PE3. Then, PE1 will resolve the host address and corresponding RD from BGP UPDATE message, and generate a BGP ROUTE-REFRESH message contains an RD-ORF entry, and send it to ASBR1.
2) When ASBR1 receives the ROUTE-REFRESH message, it checks 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.
Before sending a VPN route toward PE1, RR will check its Adj-RIB-out and find there is a filter associated with <RD1, PE3’s host address>. Then, ASBR1 will stop sending that VPN route.
Besides, ASBR1 will locally determine if it needs to send an RD-ORF entry to ASBR2. The judgment criteria refers to Section 5.1.2.
3) If ASBR2/PE3 receives the RD-ORF entry, it will repeat the above process.
When the RD-ORF mechanism is triggered, network operators need to manually configure the network to return to resume normal operation. The withdraw of RD-ORF entries refers to Section 5.2.
In Option AB cross-domain scenario, ASBRs maintain VRFs. However, due to VPN routes in all VRFs use the same BGP session, ASBRs cannot prevent the overflow of a certain VRF by breaking down a BGP session. The operation process of RD-ORF is similar to that in Option B scenario.
MP-EBGP
+----------------------------------------+
| |
+------------+------------+ +------------+------------+
| +----+----+ | | +----+----+ |
| | | | | | | |
| +----+ RR1 +----+ | | +----+ RR2 +----+ |
| | | | | | | | | | | |
| | +---------+ | | | | +---------+ | |
| | | | | | | |
| |IBGP IBGP| | | |IBGP IBGP| |
| | | | | | | |
+-+--+----+ +----+--+-+ +-+--+----+ +----+--+-+
| | | | | | | |
| PE1 | | ASBR1 |----------| ASBR2 | | PE2 |
| | | | | | | |
+-+-------+ 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 | Next hop Source Address sub-TLV | +----+-------------------------------------------------------------------+ | 2 | Route Origin Community Source Address sub-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:
Thanks Robert Raszuk, Jim Uttaro, Jakob Heitz, Jeff Tantsura, Rajiv Asati, John E Drake and Gert Doering for their valuable comments on this draft.