Re: [Idr] I-D Action: draft-xu-idr-bgp-route-broker-02.txt
Robert Raszuk <robert@raszuk.net> Wed, 09 August 2023 13:33 UTC
Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2872C15154E for <idr@ietfa.amsl.com>; Wed, 9 Aug 2023 06:33:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqYM6aYPgd1R for <idr@ietfa.amsl.com>; Wed, 9 Aug 2023 06:33:40 -0700 (PDT)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251FCC15108E for <idr@ietf.org>; Wed, 9 Aug 2023 06:33:40 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-51e2a6a3768so9435712a12.0 for <idr@ietf.org>; Wed, 09 Aug 2023 06:33:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1691588018; x=1692192818; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bRMp3oE3M2qyCPCUFwYFx0qxzQlUjQE937CV0PtzW4g=; b=Pgw/CT3Ot22RvyWH8SV3WAiWByV2U5zJZMbmE4kpsKUzbZANmnXDzWwQJkKnipxp+p RzbIxrNCGMbbq0LXQsSGVvRfZQGMCggQQqsYaFflDYTdQqb+X7aGqLzuPJX69d5QowWn yUukxo+onLApmhxa+kSnsW+TMvFGpzTo/UE7WFpsQRB0L9h6vSRShQoDuBvPqjOUz7vy 4vhWmm3R1yzW4JRpCK9+waHohE/tQspvg8k1sjezMrcfx3DjYy6uOa5/bYLBJgbQkgZY 6VglFLmso3ffKAkzaypnhfKrPRCrREuO3fvi+ek8w9s70mGKfWdl23VqJoss7U0NpH7j Sfjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691588018; x=1692192818; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bRMp3oE3M2qyCPCUFwYFx0qxzQlUjQE937CV0PtzW4g=; b=VDgr4h+eGvfnidpQ0ysR2451SkOrmzHqnKM7ymByaOXC9wI6GwLXn1vxUXlqM3SxVc O6Qj0TERAqFumTMGHbIPhT/uPUELOqH78iBdR7H/kxcaOmuB5ba6oJJ35jVfLykaWbt+ 1WGRdeY/fodKHQZGsNk6KjsSp5Brx+4WIr2oQA3m4JiWo0iN+QpXRwSk+DYWrCS4M4vQ nWFNNxW9Ztfq+hbhmtWszyQICUhgwpa+BBBfU1+gZutK73J5xnobm7Vh/VRTzoHHZm2i mBZBYilyFnDepgtae2WXbwJ2ywiKi210WU9ymg3PR+5vvzdJMPbExNhtJZcYQv4AN1Mm YxJA==
X-Gm-Message-State: AOJu0YyxtwlmxPPDOgLkjRpiLQwevlUL2bVx89dFBkAvooi5oj+6F4hc rZG9xwfB3rP1g8e3psqO4klCUH2aowsxOzQ0eI3g4Z3Gs0ilRw96
X-Google-Smtp-Source: AGHT+IHdW0Tq+xz0iXm0mHR54AWy7r4rGgz8/OAzngh3xSUuaGaWZsl85mVbiR81LTOk6LEWnFHeOXnu6XC6avddgAE=
X-Received: by 2002:a05:6402:1257:b0:523:1ea3:b9a6 with SMTP id l23-20020a056402125700b005231ea3b9a6mr2194778edw.39.1691588018357; Wed, 09 Aug 2023 06:33:38 -0700 (PDT)
MIME-Version: 1.0
References: <169157989186.10790.10412166011795082010@ietfa.amsl.com> <CAOj+MMGLTgnwT9gQ6Of7OdMkZQSsNmDuncO=hvmAZkmsJJ1JpA@mail.gmail.com>
In-Reply-To: <CAOj+MMGLTgnwT9gQ6Of7OdMkZQSsNmDuncO=hvmAZkmsJJ1JpA@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 09 Aug 2023 15:33:27 +0200
Message-ID: <CAOj+MMF3ARazhUUW0NqayX5FyPH24Qy5w=kuNUo_QH-f4yMOHg@mail.gmail.com>
To: xuxiaohu_ietf@hotmail.com
Cc: "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f0e14f06027d868e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ARxTfkpMR6oSeXmvOapFGCU_5nc>
Subject: Re: [Idr] I-D Action: draft-xu-idr-bgp-route-broker-02.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Aug 2023 13:33:43 -0000
*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 >> >
- Re: [Idr] I-D Action: draft-xu-idr-bgp-route-brok… Robert Raszuk
- Re: [Idr] I-D Action: draft-xu-idr-bgp-route-brok… Robert Raszuk
- [Idr] 答复: I-D Action: draft-xu-idr-bgp-route-brok… xuxiaohu_ietf@hotmail.com
- [Idr] 答复: I-D Action: draft-xu-idr-bgp-route-brok… xuxiaohu_ietf@hotmail.com
- Re: [Idr] I-D Action: draft-xu-idr-bgp-route-brok… Robert Raszuk
- [Idr] 答复: I-D Action: draft-xu-idr-bgp-route-brok… xuxiaohu_ietf@hotmail.com
- Re: [Idr] I-D Action: draft-xu-idr-bgp-route-brok… Robert Raszuk
- [Idr] 答复: I-D Action: draft-xu-idr-bgp-route-brok… xuxiaohu_ietf@hotmail.com
- Re: [Idr] I-D Action: draft-xu-idr-bgp-route-brok… Robert Raszuk
- [Idr] 答复: I-D Action: draft-xu-idr-bgp-route-brok… xuxiaohu_ietf@hotmail.com
- [Idr] 答复: I-D Action: draft-xu-idr-bgp-route-brok… xuxiaohu_ietf@hotmail.com
- Re: [Idr] I-D Action: draft-xu-idr-bgp-route-brok… Robert Raszuk
- Re: [Idr] I-D Action: draft-xu-idr-bgp-route-brok… Robert Raszuk
- [Idr] 答复: I-D Action: draft-xu-idr-bgp-route-brok… xuxiaohu_ietf@hotmail.com
- Re: [Idr] I-D Action: draft-xu-idr-bgp-route-brok… Robert Raszuk
- Re: [Idr] I-D Action: draft-xu-idr-bgp-route-brok… Nick Hilliard
- [Idr] 答复: I-D Action: draft-xu-idr-bgp-route-brok… xuxiaohu_ietf@hotmail.com
- Re: [Idr] I-D Action: draft-xu-idr-bgp-route-brok… Robert Raszuk
- [Idr] 答复: I-D Action: draft-xu-idr-bgp-route-brok… xuxiaohu_ietf@hotmail.com
- Re: [Idr] I-D Action: draft-xu-idr-bgp-route-brok… Robert Raszuk
- [Idr] 答复: I-D Action: draft-xu-idr-bgp-route-brok… xuxiaohu_ietf@hotmail.com
- Re: [Idr] I-D Action: draft-xu-idr-bgp-route-brok… Robert Raszuk
- [Idr] 答复: I-D Action: draft-xu-idr-bgp-route-brok… xuxiaohu_ietf@hotmail.com
- Re: [Idr] I-D Action: draft-xu-idr-bgp-route-brok… Robert Raszuk