[Idr] 答复: I-D Action: draft-xu-idr-bgp-route-broker-02.txt

["[e-mail]" <[e-mail]>]

Hi Robert，

发件人: Robert Raszuk <[e-mail]>
日期: 星期四, 2023年8月10日 22:46
收件人: [e-mail] <[e-mail]>
抄送: idr@ietf. org <[e-mail]>
主题: Re: I-D Action: draft-xu-idr-bgp-route-broker-02.txt
Hi Xiaohu,

Really ? Do you want to alter BGP-4 RFC4271 and FSM to support the concept of "BGP Route Broker" ?

[Xiaohu2] If the scalability issue associated with the BGP-based VPN solution when being deployed in real large-scale SDN environments could not be addressed by using the current BGP mechanism, why not try to make any necessary change?

For the benefit of IDR WG participants could you clearly state by email or in the draft what is the problem with addressing your deployment needs by using hierarchical VPNv4/v6 route reflection (as is - no single line of code change needed) + RTC along with it ?

【Xiaohu3】Assume there are 100K vPEs/servers, 100k VRFs/tenants, 100M VPN routes (most of them are host routes) in a large-scale data center SDN environment, you deploy a two-layer hierarchical RR architecture where there are 10 top-level RRs and 10 bottom-level RRs. As mentioned in the draft, there is no scaling pressure on top-level RRs since each just needs to store about 10 percent of the 100M VPN routes and peers with 10 bottom-level RRs. However, each bottom-level RR needs to peer with about 10K vPEs, in the worst case where the collection of VRFs attached to the 10K vPEs cover all VPNs within the data center, therefore each RR would have to store the 100M VPN routes. Furthermore, it’s almost impossible to use the peer-group attribute for the 10K vPE peers since the VRFs attached to one vPE are different from that of another vPE. As a result, each bottom-level RR would have to hold a local-RIB containing 100M VPN route entries and 10K RIB-out tables with each consists of about 20K VPN routes (assume each vPE is attached with about 20 VRFs). Besides, the route update frequency would be very high due to the widely adoption of containers.

BTW, there is no need to introduce the headache issue associated with RTC in the hierarchical RR architecture as mentioned in https://www.ietf.org/archive/id/draft-mohanty-idr-rtc-hierarchical-rr-00.html. For an example, there is no need for the top-level RRs to reflect the RT membership advertisement received from the route brokers.

You can scale a large number of peers (vPEs) easily with that model which seems to be the most critical requirement you put on the table. In fact today you can deploy virtual RRs (from a number of vendors) and co-locate them in the same compute clusters as your compute nodes. No need to purchase, mount and install hardware RRs any more.

[Xiaohu3] It’s true that Virtual RRs are widely used in the data center SDN environment. However, it’s not that easy to scale the well-known BGP-based SDN solution to support more than 5K vPEs.

Note that I do not buy the argument of timing out routes on the first line of RRs (in your draft called route brokers) as they still need to be able to handle all of those routes at peak times. So if they must be built to handle all of the routes they may as well as store them.

[Xiaohu3] Route brokers don’t need to be capable of handling all VPN routes at any given period of time. There are many ways to achieve that goal. BTW, it’s acceptable to cost a relatively long period of time for VPN route convergence when restarting all vPEs within a data center due to some unexpected reasons (e.g.，power interruption in the scope of a data center）.

Best regards,
Xiaohu

Please kindly observe that in modern BGP stacks operation on large BGP tables is atomic and targeted - only required elements are processed when needed. So the fact that you store 10M routes and only 1% of them changes does not in any way result in any CPU work which would be associated with 99% of remaining routes.

[Xiaohu] There should be a limit on the maximum number of BGP sessions that could be established within a given period of time.

Oh that is an interesting approach to scale ...

[Xiaohu2] There is a more interesting approach on the way…

That's what I am afraid of :)

Cheers,
Robert