[Idr] 答复: draft-xu-idr-bgp-route-broker-01.txt

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

Hi Robert,

Thanks for your quick comments and suggestions. Please see my response inline.

发件人: Robert Raszuk <[e-mail]>
日期: 星期二, 2023年8月1日 22:09
收件人: Srihari Sangli <[e-mail]>, Shraddha Hegde <[e-mail]>, [e-mail] <[e-mail]>
抄送: idr@ietf. org <[e-mail]>
主题: draft-xu-idr-bgp-route-broker-01.txt
Dear authors,

Few observations.

#1 - Your draft talks a lot about exchanging VPN membership information without even once mentioning Route Target Constrained distribution. How are you going to dynamically propagate such membership information ?

[Xiaohu] It actually leverages the route target constrained distribution mechanism😊

#2 - You state:

"It’s no doubt that the route reflection mechanism should be considered in order to address the BGP scaling issues as mentioned above."

Actually I have a doubt. You are coming from the perspective of classic BGP and stretching it to fit the described scale. How about a clean slate approach and permanent session less distribution of reachability information end to end - not only on the brokers ?

[Xiaohu] If there was no permanent session between the publishers and subscribers, it seems that it’s hard to update the route tables on virtual PE routers in a real-time manner.

Even magnitude larger distributed systems are doing just fine when you do query/response model or pub/sub model. Why not overlay reachability ? And yes in a proactive way. And maybe TCP is not the right transport here. Maybe even BGP-4 is not ....

[Xiaohu] AFAIK, RobbitMQ (https://www.rabbitmq.com/connections.html), as one of the most popular large-scale pub/sub systems, are built on TCP😊 Hence, the root cause of the scaling issue as mentioned above should not be TCP.

#3 - You talk about overlay - but if there is overlay then usually there is also underlay. Dependency on underlay to detect nodes going down should be sufficient to trigger overlay invalidation.

[Xiaohu] Assume there are tens of thousands vPE routers, route aggregation on the underlay is a good practice. Furthermore, consider the VM migration operation or the frequent container creation/deletion operation, a proactive route distribution mechanism should be a must.

#4 - You talk about PEs. But in modern L3 fabric MSDCs it is compute nodes (or actually even smartNICs) which are acting as PEs to their local tenants.

[Xiaohu] Agree. That’s the reason why the virtual PE concept is mentioned in the draft.

So how about you think about DNS model or LISP mapping plane model instead here to distribuite overlay addresses to underlay next hop mappings ?

[Xiaohu] By using DNS or LISP, how could the virtual PE routers obtain the VPN route in a real-time maner?

So to summarize it is evident that you are really concerned about the number of TCP based BGP4 sessions.

Number of routes will still hit you as top level Route Reflectors (or Route Servers) will likely get requests to carry all VPN memberships.

[Xiaohu] there is no need to have any one top-level route reflector maintain all the VPN routes for all the VPNs supported by the data center. The scalability issue lies on the bottom-level route reflectors.

Your proposal does mitigate the former by introducing the notion of "BGP Broker" - but instead of making half step I would encourage you to think further and use other then BGP protocol distribution mechanism.

[Xiaohu] Since BGP has been used as an overlay routing protocol by some open-source or commercial SDN solutions, such as TungsenFabric, it seems worthwhile to consider how to further improve the scalability of the BGP-based IP VPN technology when deploying it in hyperscale data center network virtualization environments.

Or if you like, go for using either hierarchy of route brokers with session less overlay transport.

[Xiaohu] I have not got your point of using a hierarchy of route brokers. Could you please say more?


Last but not least I am really surprised that with such proposal you are also not suggesting to use notion of aggregate withdraws as defined in https://www.ietf.org/archive/id/draft-raszuk-aggr-withdraw-00.txt

[Xiaohu] I have not yet found how to use the notion of aggregation withdraws to address the scalability issues as mentioned above. Let’s me think it further. However, it does use some similar trick (see Section 6) as yours.

Thanks a lot for your comments and suggestions again😊

Kind regards,
Robert