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

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

Hi Robert,

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

Question 3:

When route broker receives two or more identical NLRIs from upper level RRs it likely needs to run best path on them. That best path information is lost when we delete the routes after sending them to clients.

[Xiaohu] Those top-level RRs corresponding for a given VPN should have exactly the same VPN routes for that VPN.  In other word, they are within the same redundancy cluster. Hence, there is no difference in the routes for a given NLRI advertised by different RRs from the viewpoint of the route brokers and route broker clients.

Imagine one of the upper level RRs goes down ... How does broker know that the path which he selected as best and propagated to the client(s) came from the upper level RR which went down or which is still up ?

[Xiaohu] As mentioned above, there is no need for route brokers to take any action.

If the path came from the one which is down how would it remove it from the clients ? Note that the RR which continues to work did not pushed a new routes.

[Xiaohu] Until all RRs belonging to a given cluster are down, there is no need to withdraw any VPN route advertised from the dead RR of that cluster. For more details, see section 7.

Best regards,
Xiaohu


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.


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.

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