BGP Route Broker for Hyperscale SDN
draft-xu-idr-bgp-route-broker-04

Network Working Group                                              X. Xu
Internet-Draft                                              China Mobile
Intended status: Standards Track                                S. Hegde
Expires: 27 October 2024                                       S. Sangli
                                                                 Juniper
                                                                S. Zhang
                                                                 J. Dong
                                                                  Huawei
                                                           25 April 2024

                  BGP Route Broker for Hyperscale SDN
                    draft-xu-idr-bgp-route-broker-04

Abstract

   This document describes an optimized BGP route reflector mechanism,
   referred to as a BGP route broker, so as to use BGP-based IP VPN as
   an overlay routing protocol in a scalable way for hyperscale data
   center network virtualization environments, also known as Software-
   Defined Network (SDN) environments.

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 27 October 2024.

Copyright Notice

   Copyright (c) 2024 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

Xu, et al.               Expires 27 October 2024                [Page 1]
Internet-Draft              BGP Route Broker                  April 2024

   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Solution Overview . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Route Target Membership Advertisement Process . . . . . . . .   4
   4.  Route Distribution Process  . . . . . . . . . . . . . . . . .   4
   5.  Deployment Considerations . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Problem Statement

   BGP/MPLS IP VPN has been successfully deployed in world-wide service
   provider networks for two decades and therefore it has been proved to
   be scalable enough in large-scale networks.  Here, the BGP/MPLS IP
   VPN means both BGP/MPLS IPv4 VPN [RFC4364] and BGP/MPLS IPv6 VPN
   [RFC4659] . In addition, BGP/MPLS IP VPN-based data center network
   virtualization approaches as described in [RFC7814], especially in
   the virtual PE model as described in [I-D.ietf-bess-virtual-pe] have
   been widely deployed in small to medium-sized data centers for
   network virtualization purpose, also known as Software Defined
   Network (SDN).  Examples include but not limited to OpenContrail.

   Hyperscale cloud data centers usually have tens of thousands of
   servers, which are virtualized as Virtual Machines (VMs) or
   containers.  This means that there are at least tens of thousands of
   virtual PEs, millions of VPNs, and tens of millions of VPN routes
   from the network virtualization perspective, assuming the virtual PE
   model is used.  However, this poses a significant challenge on the
   BGP session capacity and the VPN routing table capacity of any given
   BGP router.

   The route reflection (RR) mechanism is crucial to address BGP scaling
   issues.  If a one-level route reflector architecture is used, all the
   VPN routes supported by a data center could be divided among multiple
   route reflectors by preconfiguring each route reflector with a block
   of route targets associated with partial VPNs.  This means that any

Xu, et al.               Expires 27 October 2024                [Page 2]
Internet-Draft              BGP Route Broker                  April 2024

   single route reflector does not need to maintain all the VPN routes
   supported by the data center.  For redundancy, more than one route
   reflectors should be preconfigured with the same block of route
   targets to form a RR cluster.

   If each virtual PE is attached to at least one VPN corresponding to a
   given route reflector, that route reflector would have to establish
   BGP sessions with all virtual PEs, which can create a huge BGP
   session pressure on route reflectors.  To solve this scaling issue,
   another level （i.e, bottom-level) of route reflectors can be
   introduced between the existing level (i.e., top-level) route
   reflectors and the virtual PEs.  Each top-level route reflector would
   establish BGP sessions with all bottom-level route reflectors, rather
   than all virtual PE routers.  Additionally, bottom-level route
   reflectors would only need to establish BGP sessions with a subset of
   all virtual PEs respectively.  Therefore, the above partition
   mechanism solves the scaling issue of the BGP session capacity as
   mentioned above.

   In a two-level RR hierarchy within hyperscale data centers, using the
   Route Target Constrain (RTC) mechanism [RFC4684] may have two
   drawbacks.  Firstly, it can be difficult to partition all the VPN
   routes supported by the data center among multiple top-level RRs.
   Secondly, virtual PEs may have to receive RT membership NLRIs
   corresponding to all route targets supported by the data center,
   which would unnecessarily consume the CPU and RAM resources of
   virtual PEs.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Solution Overview

   The bottom-level route reflectors, also known as route brokers, are
   designed based on the high-performance message queuing mechanisms
   such as RabbitMQ.  These route brokers maintain the route target
   membership information of their IBGP peers and reflect VPN routes
   among them on demand.  Essentially, route brokers function as the
   message brokers or exchanges of the message queuing system.  On the
   other hand, top-level route reflectors, known as route collection
   servers, and virtual PEs, known as route broker clients, act as both
   message publishers or producers and subscribers or consumers of the
   message queuing system.

Xu, et al.               Expires 27 October 2024                [Page 3]
Internet-Draft              BGP Route Broker                  April 2024

3.  Route Target Membership Advertisement Process

   Route collection servers advertise route target membership
   information according to the preconfigured block of route targets on
   each of them.  As a result, route brokers know which VPNs are
   partitioned to each of them.

   Route brokers advertise default route target membership information
   to their own route broker client so as to collect VPN routes from
   their clients and then reflect them to route collection servers.

   Route broker clients advertise route target membership information
   according to the block of route targets which are dynamically
   configured on each of them.  Upon receiving the above advertisement,
   route brokers would dispatch the received route target memembership
   information towards the corresponding route collection servers whose
   preconfigured block of route target cover the advertised route
   targets.

   The advertisement of route target membership information is based on
   Route Target Outbound Route Filtering (ORF) as defined in
   [I-D.xu-idr-route-target-orf] .

4.  Route Distribution Process

   Upon receiving a route update message from a route collection server
   which contains VPN routes for a given VPN, if those VPN routes
   contained in the route update message are selected as best routes,
   route brokers would store those VPN routes in their local RIBs and
   then reflect them to their route broker clients which are associated
   with that VPN.  Meanwhile, the cluster ID of route brokers SHOULD be
   prepended when reflecting the above VPN routes.

   Upon receiving a route update message from a route broker client
   which contains VPN routes for a given VPN, if those VPN routes are
   selected as best routes, route brokers would store those routes in
   their local RIBs and then reflect them to the other iBGP peers
   (including route collection servers and other route broker clients)
   which are associated with that VPN.  Meanwhile, the cluster ID of
   route brokers SHOULD be prepended when reflecting the above VPN
   routes.

   Upon receiving an implicit route request for all the VPN routes for
   one or more VPNs (via the route target membership information
   advertisement) from a route broker client, route brokers SHOULD
   respond with the corresponding VPN routes stored in its local RIBs to
   that route broker.

Xu, et al.               Expires 27 October 2024                [Page 4]
Internet-Draft              BGP Route Broker                  April 2024

   Upon receiving an implicit route request for all the VPN routes for
   one or more VPNs (via the route target membership information
   advertisement) from a route collection server, route brokers SHOULD
   respond with the corresponding VPN routes stored in its local RIBs
   which are learnt from their own route broker clients to that route
   collection server.

5.  Deployment Considerations

   To simplify the VPN route distribution control, each VPN SHOULD be
   assigned with a globally unique export route target value.

   Since the advertisement of multiple paths for a given VPN prefix is
   needed in the data center SDN environments, virtual PEs SHOULD be
   assigned with different RDs.

   Virtual PEs SHOULD NOT establish BGP session with more than one
   cluster of route brokers which are configured with the same cluster
   ID.

6.  IANA Considerations

   There is no need for IANA to do any action.

7.  Security Considerations

   TBD

8.  Acknowledgements

   The authors would like to thank Robert Raszuk for their valuable
   comments and suggestions on this document.

9.  References

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

   [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>.

Xu, et al.               Expires 27 October 2024                [Page 5]
Internet-Draft              BGP Route Broker                  April 2024

   [RFC4659]  De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
              "BGP-MPLS IP Virtual Private Network (VPN) Extension for
              IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006,
              <https://www.rfc-editor.org/info/rfc4659>.

   [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>.

   [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>.

   [RFC7814]  Xu, X., Jacquenet, C., Raszuk, R., Boyes, T., and B. Fee,
              "Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension
              Solution", RFC 7814, DOI 10.17487/RFC7814, March 2016,
              <https://www.rfc-editor.org/info/rfc7814>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2.  Informative References

   [I-D.ietf-bess-virtual-pe]
              Fang, L., Fernando, R., Napierala, M., Bitar, N. N., and
              B. Rijsman, "BGP/MPLS VPN Virtual PE", Work in Progress,
              Internet-Draft, draft-ietf-bess-virtual-pe-00, 12 November
              2014, <https://datatracker.ietf.org/doc/html/draft-ietf-
              bess-virtual-pe-00>.

   [I-D.xu-idr-route-target-orf]
              Xu, X., Hegde, S., Sangli, S. R., Zhuang, S., and J. Dong,
              "Route Target ORF", Work in Progress, Internet-Draft,
              draft-xu-idr-route-target-orf-00, 17 August 2023,
              <https://datatracker.ietf.org/doc/html/draft-xu-idr-route-
              target-orf-00>.

Authors' Addresses

   Xiaohu Xu
   China Mobile
   Email: xuxiaohu_ietf@hotmail.com

Xu, et al.               Expires 27 October 2024                [Page 6]
Internet-Draft              BGP Route Broker                  April 2024

   Shraddha Hegde
   Juniper
   Email: shraddha@juniper.net

   Srihari Sangli
   Juniper
   Email: ssangli@juniper.net

   Shunwan
   Huawei
   Email: zhuangshunwan@huawei.com

   Jie
   Huawei
   Email: jie.dong@huawei.com

Xu, et al.               Expires 27 October 2024                [Page 7]