VPN Prefix Outbound Route Filter (VPN Prefix ORF) for BGP-4

Abstract

This draft defines a new Outbound Route Filter (ORF) type, called the VPN Prefix ORF. The described VPN Prefix ORF mechanism is applicable when the VPN routes from different VRFs are exchanged via one shared BGP session.¶

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:¶

• RD: Route Distinguisher, defined in [RFC4364]¶

• ORF: Outbound Route Filter, defined in [RFC5291]¶

• AFI: Address Family Identifier, defined in [RFC4760]¶

• SAFI: Subsequent Address Family Identifier, defined in [RFC4760]¶

• EVPN: BGP/MPLS Ethernet VPN, defined in [RFC7432]¶

• RR: Router Reflector, provides a simple solution to the problem of IBGP full mesh connection in large-scale IBGP implementation.¶

• VRF: Virtual Routing Forwarding, a virtual routing table based on VPN instance.¶

4. Operation process of VPN Prefix ORF mechanism on sender

The operation of VPN Prefix ORF mechanism on each device is independent, each of them makes a local judgement to determine whether it needs to send VPN Prefix ORF to its upstream peer. Operators can set the algorithms in the devices according to their own circumstances.¶

The general procedures of the VPN Prefix ORF mechanism on the sender are as follows:¶

This section describes the procedures for the BGP peer(the first BGP peer) receiving the VPN routes information from another BGP peer(the second BGP peer). The VPN information includes the updated VPN routes and their corresponding VPN instance identification information. Based on the VPN instance identification information, the first BGP peer determines the newly added VPN routes, and checks whether the number of the newly added VPN route has caused the number of total VPN routes exceeding the maximum route limit of the associated VPN instance.¶

If the route number of the VPN instance that identified by the VPN instance identification information is reached or excess its limit, it will send the instruction information to the second BGP peer, indicating that the second BGP peer stop sending the corresponding VPN routes that identified by the VPN instance identification information.¶

The first BGP peer and the second BGP peer are iBGP peers that are within one AS. The VPN instance identification information is RD and the instruction information is sent via the route-refresh message.¶

The instruction information that sends to the second BGP peer includes the followings information:¶

The ORF entries that are included in the route-refresh message.¶

Set the Action field in the ORF entries to the value that instructs to add the corresponding filter condition into outbound route filter of the second the BGP peer.¶

Set the Match field in the ORF entries to the value that instructs to deny the VPN routes updates that matches the corresponding ORF entries.¶

The RD value that identifies the above mentioned VPN instance is added at the type-specific part of the ORF entries.¶

When multiple VRFs on a PE are receiving VPN routes for a specific RD, if one VRF exceeds its limit upon receiving routes with that RD and the PE sends a VP-ORF message, it will prevent other VRFs that have not exceeded their limits from receiving VPN routes containing that RD, leading to communication disruptions between these VRFs and the rejected VPN routes. In order to more finely control VPN routing, when the above situation occurs, VRF should generate a filter when its route limit is exceeded, to selectively filter route entries based on RD before they enter the VRF from the RIB.¶

The PE which receives the offending VPN routes parses the received BGP update message to obtain routing information, and obtains VPN routing entries associated with the BGP path from the routing information. Then, PE should determine the target VRF based on the RT import information of the routing target entry, and configure filters for the target VRF. PE should first detect whether there is currently a filter associated with the target VRF. If yes, PE should use the filter to filter the VPN routing entries, so that VPN routing entries carrying the specified routing identifier RD are not introduced into the target VRF. If there is currently no filter associated with the target VRF, PE will directly introduce the VPN routing entry into the target VRF. The format of VPN Prefix ORF entry is shown in Section 6¶

When configuring a filter for the target VRF, the PE should detect whether there is currently a routing overflow issue with the target VRF. If the target VRF currently has a routing overflow issue and the reason for the routing overrun is caused by a VPN routing entry carrying the specified RD, a filter is generated for the target VRF, wherein the filter is used to filter VPN routing entries carrying the specified RD. If the target VRF currently does not have routing overflow issues, PE will delete the filter for the target VRF.¶

The detail procedures for further subdivisions are described below:¶

a) No quota value is set on PE¶

On PE, each VRF has a prefix limit. When the PE receives VPN routes from its BGP peer, due to the received VPN routes may belong to different VPN and carry the corresponding RDs, the PE should extract the VPN route information from BGP UPDATE message which contains VPN routes related to BGP optimal routing. PE can determine the target VRFs of the received VPN route based on the RT of the VPN route and the RT-import of VRFs. Then, the PE should sequentially determine whether each target VRF will exceed the limit after importing the received VPN routes. If a target VRF exceeds the limit which is caused by the VPN routes carrying a certain RD and the other target VRFs have not overflow, PE should not trigger the VPN Prefix ORF mechanism, and only performs VPN route filtering for the target VRF and stop importing VPN routes carrying the specific RD. If a target VRF exceeds the limit and there is no other VRFs need these VPN routes, the PE should trigger the VPN Prefix ORF mechanism and send a BGP ROUTE-REFRESH message contains the corresponding VPN Prefix ORF entry to its peer, which will generate a VPN routes filtering strategy for the VRF. And if the "Offending VPN routes process method" bit is 1, the receiver of VPN Prefix ORF entry should withdraw the extra VPN routes according to the value of VRF Prefix Limit, RD, RT and information in optional TLVs in the entry, and stop sending the corresponding VPN routes to the sender. If the target VRF no longer exceeds the limit, the relevant VPN routing filtering strategy needs to be deleted.¶

When importing VPN routes to a VRF, it is necessary to determine whether there is a VPN routes filtering strategy on the PE for that VRF. BGP peers supporting this functionality has VRFs that has maximum route limit reached should comply with the procedures defined in this document¶

b) Quota value is set on PE¶

On PE, each VRF has a prefix limit, and routes associated with each <RD, source PE> tuple has a pre-configured quota. Considering that the received VPN routes may belong to different VPNs and therefore carry different RDs, the PE should determine whether VRF will exceed the limit after adding the received VPN routes.¶

• when routes associated with <RD, source PE> tuple pass the quota but the prefix limit of VRF is not exceeded, PE should send warnings to the operator, and the VPN Prefix ORF mechanism should not be triggered.¶

• when routes associated with <RD, source PE> tuple pass the quota and the prefix limit is exceeded and there is no other VRFs on offended PE need VPN routes with this <RD, source PE> tuple, PE should trigger VPN Prefix ORF mechanism and send a BGP ROUTE-REFRESH message contains the corresponding VPN Prefix ORF entry to its peer.¶

When the VPN Prefix ORF mechanism is triggered, the device must send an alarm information to network operators.¶

 +------------------------------------------------------------------------+
 |                                                                        |
 |                                                                        |
 |        +-------+                                       +-------+       |
 |        |  PE1  +----------------+    +-----------------+  PE4  |       |
 |        +-------+                |    |                 +-------+       |
 |     VPN1(RD11,RT1)              |    |              VPN2(RD12,RT2)     |
 |     VPN2(RD12,RT2)              |    |                                 |
 |                               +-+----+-+                               |
 |                               |   RR   |                               |
 |                               +-+----+-+                               |
 |                                 |    |                                 |
 |                                 |    |                                 |
 |        +-------+                |    |                 +-------+       |
 |        |  PE2  +----------------+    +-----------------+  PE3  |       |
 |        +-------+                                       +-------+       |
 |     VPN1(RD21,RT1)                                  VPN1(RD31,RT1)     |
 |     VPN2(RD22,RT2,RT1)                              VPN2(RD32,RT2)     |
 |                                                                        |
 |                                 AS 100                                 |
 |                                                                        |
 +------------------------------------------------------------------------+
                 Figure 1 Network Topology of Scenario-1

 +------------------------------------------------------------------------+
 |                                                                        |
 |                                                                        |
 |        +-------+                                       +-------+       |
 |        |  PE1  +----------------+    +-----------------+  PE4  |       |
 |        +-------+                |    |                 +-------+       |
 |     VPN1(RD11,RT1)              |    |              VPN2(RD42,RT2)     |
 |     VPN2(RD12,RT2)              |    |                                 |
 |                               +-+----+-+                               |
 |                               |   RR   |                               |
 |                               +-+----+-+                               |
 |                                 |    |                                 |
 |                                 |    |                                 |
 |        +-------+                |    |                 +-------+       |
 |        |  PE2  +----------------+    +-----------------+  PE3  |       |
 |        +-------+                                       +-------+       |
 |     VPN1(RD21,RT1)                                  VPN1(RD31,RT1,RT2) |
 |                                                     VPN2(RD32,RT2)     |
 |                                                                        |
 |                                 AS 100                                 |
 |                                                                        |
 +------------------------------------------------------------------------+
                Figure 2 Network Topology of Scenario-2

 +------------------------------------------------------------------------+
 |                                                                        |
 |                                                                        |
 |        +-------+                                       +-------+       |
 |        |  PE1  +----------------+    +-----------------+  PE4  |       |
 |        +-------+                |    |                 +-------+       |
 |     VPN1(RD1,RT1)               |    |              VPN2(RD12,RT2)     |
 |     VPN2(RD12,RT2)              |    |                                 |
 |                               +-+----+-+                               |
 |                               |   RR   |                               |
 |                               +-+----+-+                               |
 |                                 |    |                                 |
 |                                 |    |                                 |
 |        +-------+                |    |                 +-------+       |
 |        |  PE2  +----------------+    +-----------------+  PE3  |       |
 |        +-------+                                       +-------+       |
 |     VPN1(RD1,RT1)                                   VPN1(RD1,RT1,RT2)  |
 |                                                     VPN2(RD32,RT2)     |
 |                                                                        |
 |                                 AS 100                                 |
 |                                                                        |
 +------------------------------------------------------------------------+
                  Figure 3 Network Topology of Scenario-3

5. Source PE Extended Community

We usually use NEXT_HOP to identify the source, but it may not useful in the following scenarios:¶

• a PE may have multiple addresses so that its BGP peer will receive several different NEXT_HOP from the same source.¶

• In Option B inter-domain scenario, the ASBR will change the NEXT_HOP.¶

ORIGINATOR_ID is a non-transitive attribute generated by RR to identify the source, but ORIGINATOR_ID cannot be advertised outside the local AS. To cover the above scenarios, we define a new Extended Community: Source PE Extended Community(SPE EC) to transmit the identifier of source. Its value can be set by source PE/RR/ASBR. Once set and attached with the BGP UPDATE message, its value should not be changed along the advertisement path.¶

The format of SPE EC is shown as Figure 4.¶

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               0x0d            |    Autonomous System Number   :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :     AS Number (cont.)         |         ORIGINATOR_ID         :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :     ORIGINATOR_ID (cont.)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 4 The format of SPE EC

For the RR/ASBR, it should perform as following:¶

• Check the existence of the SPE EC. If it exists, does not change it.¶

• If SPE EC does not exist, check the existence of ORIGINATOR_ID. If it exists, put it into SPE EC.¶

• If ORIGINATOR_ID does not exist, put the router-id of source PE into SPE EC.¶

7. Operation process of VPN Prefix ORF mechanism on receiver

The receiver of VPN Prefix ORF entries may be a RR or PE. As it receives the VPN Prefix ORF entries from the sender, it will check <AFI/SAFI, ORF-Type, Sequence, Route Distinguisher> to find if it already existed in its ORF-Policy table. If not, the receiver will add the VPN Prefix ORF entries into its ORF-Policy table; otherwise, the receiver will discard it.¶

The RR or PE should determine the sending device and next hop address of the stored VPN Prefix ORF entry corresponding to the source PE in the filtering condition by looking up in the FIB, including: 1) determining the port field corresponding to the stored VPN Prefix ORF entry in the export routing filter strategy table; 2) Determine the sending device of the stored VPN Prefix ORF entry based on the value of the port field corresponding to the stored VPN Prefix ORF entry.¶

The filtering conditions for the stored VPN Prefix ORF entries contain the RD and RT of the source PE.¶

If the sending device of the VPN Prefix ORF entry stored under the same filtering condition includes all IBGP neighbors of the RR or PE other than the device with the next hop address, the VPN Prefix ORF entry is generated, where the next hop address is the next hop address sent to the network device in the direction of the source PE in the same filtering condition. The filtering condition in the generated VPN Prefix ORF entry contain the address, RD and RT of the source PE; Then, the RR or PE should send the generated VPN Prefix ORF entry to the device at the next hop address via BGP ROUTE-REFRESH message, so that the device at the next hop address filters the VPN route sent by the source PE.¶

Before the route update is announced, the receiver should check its ORF-Policy table with <RD, Source PE> tuple of the VPN route. The Route Distinguisher information can be extracted directly from the BGP UPDATE message. The source PE information should be compared against the Source PE Extended Community if it is contained in BGP UPDATE message, or else the NEXT_HOP.¶

If there is not a related VPN Prefix ORF entry in ORF-Policy table, the receiver will send this VPN route; otherwise, the receiver will perform the following operations:¶

• If the "Offending VPN routes process method" bit is 0, the receiver should withdraw all the VPN routes identified by RD, RT and information in optional TLVs in the entry, and stop sending the corresponding VPN routes to the sender.¶

• If the "Offending VPN routes process method" bit is 1, the receiver withdraw the extra VPN routes according to the value of VRF Prefix Limit, RD, RT and information in optional TLVs in the entry, and stop sending the corresponding VPN routes to the sender.¶

8. Withdraw of VPN Prefix ORF entries

When the VPN Prefix 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 VPN Prefix 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. After returning to normal, the device sends withdraw ORF entries to its peer who have previously received ORF entries.¶

9. Applicability

We take the scenario in Section 4.1.1 as an example to illustrate how to determine each field when the sender generates a VPN Prefix ORF entry. We assume it is an IPv4 network. After PE1-PE4 and RR advertising the Outbound Route Filtering Capability, each of PE1-PE4 should send a VPN Prefix ORF entry that means "PERMIT-ALL" as follows:¶

• AFI is equal to IPv4¶

• SAFI is equal to MPLS-labeled VPN address¶

• When-to-refresh is equal to IMMEDIATE¶

• ORF Type is equal to VPN Prefix ORF¶

• Length of ORF entries is equal to 26¶

• Action is equal to ADD¶

• Match is equal to PERMIT¶

• Offending VPN routes process method is equal to 0¶

• Sequence is equal to 0xFFFFFFFF¶

• Length is equal to 12¶

• VRF Prefix Limit is equal to 0xFFFF¶

• Route Distinguisher is equal to 0¶

When the VPN Prefix ORF mechanism is triggered on PE1, PE1 will generate a VPN Prefix ORF contains the following information:¶

• AFI is equal to IPv4¶

• SAFI is equal to MPLS-labeled VPN address¶

• When-to-refresh is equal to IMMEDIATE¶

• ORF Type is equal to VPN Prefix ORF¶

• Length of ORF entries is equal to 44¶

• Action is equal to ADD¶

• Match is equal to DENY¶

• Offending VPN routes process method is equal to 0¶

• Sequence is equal to 1¶

• Length is equal to 30¶

• VRF Prefix Limit is equal to the prefix limit of VPN1 VRF¶

• Route Distinguisher is equal to RD31¶

• Optional TLV:¶

  • Type is equal to 1 (Source PE TLV)¶

  • Length is equal to 8¶

  • value is equal to PE3's IPv4 address¶

  • Type is equal to 4 (Route Target TLV)¶

  • Length is equal to 8¶

  • value is equal to RT1¶

10. Implementation Considerations

This draft is experimental in order to determine if the proposed mechanism could block the offending routes as expected or not, and whether it would cause other potential network failures. The first section below describes implementation considerations for the mechanism. The second section below provides a short summary of the experimental topology and the results.¶

11. Security Considerations

This draft does build upon [RFC5291]. A BGP speaker will maintain the VPN Prefix ORF entries in an ORF-Policy table, 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.¶

13. Contributor

Shunwan Zhuang¶

Huawei Technologies¶

Huawei Building, No.156 Beiqing Rd.¶

Beijing¶

Beijing, 100095 China¶

14. Acknowledgement

Thanks Robert Raszuk, Jim Uttaro, Jakob Heitz, Jeff Tantsura, Rajiv Asati, John E Drake, Gert Doering, Shuanglong Chen, Enke Chen, Srihari Sangli and Igor Malyushkin for their valuable comments on this draft.¶

15. Normative References

[I-D.ietf-bess-evpn-inter-subnet-forwarding]

Sajassi, A., Salam, S., Thoria, S., Drake, J., and J. Rabadan, "Integrated Routing and Bridging in Ethernet VPN (EVPN)", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-inter-subnet-forwarding-15, 26 July 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-inter-subnet-forwarding-15>.

[I-D.wang-idr-vpn-routes-control-analysis]

Wang, A., Wang, W., Mishra, G. S., Wang, H., Zhuang, S., and J. Dong, "Analysis of VPN Routes Control in Shared BGP Session", Work in Progress, Internet-Draft, draft-wang-idr-vpn-routes-control-analysis-04, 6 September 2021, <https://datatracker.ietf.org/doc/html/draft-wang-idr-vpn-routes-control-analysis-04>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4360]

Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <https://www.rfc-editor.org/info/rfc4360>.

[RFC4364]

Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.

[RFC4684]

Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, November 2006, <https://www.rfc-editor.org/info/rfc4684>.

[RFC4760]

Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.

[RFC5291]

Chen, E. and Y. Rekhter, "Outbound Route Filtering Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, August 2008, <https://www.rfc-editor.org/info/rfc5291>.

[RFC5292]

Chen, E. and S. Sangli, "Address-Prefix-Based Outbound Route Filter for BGP-4", RFC 5292, DOI 10.17487/RFC5292, August 2008, <https://www.rfc-editor.org/info/rfc5292>.

[RFC7024]

Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS VPNs", RFC 7024, DOI 10.17487/RFC7024, October 2013, <https://www.rfc-editor.org/info/rfc7024>.

[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, <https://www.rfc-editor.org/info/rfc7432>.

[RFC7543]

Jeng, H., Jalil, L., Bonica, R., Patel, K., and L. Yong, "Covering Prefixes Outbound Route Filter for BGP-4", RFC 7543, DOI 10.17487/RFC7543, May 2015, <https://www.rfc-editor.org/info/rfc7543>.