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

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

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

Question 4:

The questionable advantage of deleting the routes after they are sent from the brokers has huge drawback - that withdraws need to be now sent using extended communities marking (namely RT).

But as we know many routes may be advertised with the same export RT - so it is impossible to withdraw only subset of routes based on the RT membership.

[Xiaohu1] It works well when each VRF to be configured with a unique export RT in the data center SDN environment. Of course, you can configure multiple import RTs for a VRF so as to realize inter-VRF route leaking for special services, e.g., cloud WAN.


Configuring unique export RT for each VRF of the VPN is an insane recommendation. Sorry.

The core principle of L3VPN architecture (and EVPN as well) is that addition or deletion of a VRF in the network DOES NOT REQUIRE TO ADJUST ANY OTHER NODE's CONFIGURATION IN THE NETWORK.

[Xiaohu2] Let me correct my statement. For a given VPN, it should be assigned with a unique export RT. In other words, one export RT per VPN.

Question 5:

When sending withdraws due to lost sessions to upper level RRs now need to be based on VPN membership (modulo issue #4) the biggest problem seems to be that the proposed brokers are not backwards compatible with existing deployed PEs.

Each PE now would need to understand the new format of withdraw messages (yet to be defined) and support such new extension(s). That makes a deployment a nightmare and does at least require new BGP capability message between the client and the broker and the broker and upper level RRs.

[Xiaohu1] I agree that there are many details which need to be specified further. As for incremental deployment and backwards compatibility, the proposed solution is intended for large-scale data center SDN environments which are greenfield environments. To connect to the outside world (e.g., other data centers or on-premises sites), hardware PE routers which peers with the top-level RRs via the classical BGP would be used instead.


Even in new deployments there is usually more then one OS vendor involved especially as you are talking about virtual PEs.

So understanding if my peer will support new format of the withdraw messages seems a critical piece and a MUST have for this to even be POC tested.  Moreover even if OS supports it you are still likely talking here about new IBGP peer type as clearly route broker will not properly work with current IBGP mechanism (current means today's BGP-4 SAFI 128 peer).

[Xiaohu3] As I had mentioned before, this proposed solution is intended for a green-field data center environments.

Best regards,
Xiaohu


Rgs,
R.