Re: [Idr] 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.

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 ?

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.

*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 <robert@raszuk.net> 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 <internet-drafts@ietf.org> 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
>> I-D-Announce@ietf.org
>> 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
>>
>