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

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

Hi Robert,

Please see my answers to question 4&5 inline.


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.


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.

Best regards,
Xiaohu

Regards,
Robert


On Wed, Aug 9, 2023 at 3:12 PM Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:
Hi Xiaohu,

Thank you for submitting version -02 though it has some spelling errors.

Let's now focus on your document a bit instead of exploring alternative options :).

Question 1:

Can you please kindly elaborate how route brokers are going to handle Route Refresh messages coming from say one specific client ?

As you know we as IDR gave up on Enke's extended community ORF (https://datatracker.ietf.org/doc/html/draft-chen-bgp-ext-community-orf-00) when RTC got defined and progressed So here you need to make Route Refresh messages transitive via a stateless broker and moreover you need to send it to all upper level RRs**

That's quite inefficient if only a single client with single RT import is asking for refresh and instead you are going to get dump from all upper level RRs for all RTs given broker is serving.

Question 2:

When exactly brokers will drop routes ? As soon as it is sent to all peers ? Or is there some extra timer fired from the moment routes are declared as sent ?

And why brokers need to drop routes if in any case they need to be able to keep them at their peak for the purpose of forwarding to clients and upper level RRs (hence CPU and RAM on brokers must be sufficient to handle them).

I am just not seeing a reason why two levels of current RRs would not be a solution to the problem of the number of permanent IBGP connections spread.

Can you kindly elaborate what is exactly the advantage to drop/delete routes on the first level of RRs and rename them as brokers ?


** I think till this draft we have unwritten consensus that what we refer to Route Reflector is a BGP speaker serving IBGP clients and what we are referring to as Route Server is a BGP speaker serving EBGP clients. Your draft seems to be calling upper level Route Reflectors as Route Servers breaking that convention. Could we really refer to those upper level Route Reflectors in some other way then Route Server in next version ?

Many thx,
Robert


On Wed, Aug 9, 2023 at 1:18 PM <[e-mail]<mailto:[e-mail]>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

   Title           : BGP Route Broker for Hyperscale SDN
   Authors         : Xiaohu Xu
                     Shraddha Hegde
                     Srihari Sangli
   Filename        : draft-xu-idr-bgp-route-broker-02.txt
   Pages           : 7
   Date            : 2023-08-09

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 for hyperscale data center network
   virtualization environments, also known as Software-Defined Network
   (SDN) environments.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-xu-idr-bgp-route-broker/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-xu-idr-bgp-route-broker-02

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-xu-idr-bgp-route-broker-02

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


_______________________________________________
I-D-Announce mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt