Re: [GROW] [Idr] RFC7854: EoR
Robert Raszuk <robert@raszuk.net> Fri, 23 September 2022 07:53 UTC
Return-Path: <robert@raszuk.net>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CFCC1524B1 for <grow@ietfa.amsl.com>; Fri, 23 Sep 2022 00:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_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 fE_V1loHGa1i for <grow@ietfa.amsl.com>; Fri, 23 Sep 2022 00:53:25 -0700 (PDT)
Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 94100C14CF01 for <grow@ietf.org>; Fri, 23 Sep 2022 00:53:25 -0700 (PDT)
Received: by mail-wm1-x336.google.com with SMTP id i203-20020a1c3bd4000000b003b3df9a5ecbso2764304wma.1 for <grow@ietf.org>; Fri, 23 Sep 2022 00:53:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=yFVVtZME57ctDTkQbatgKaxUdL7+TdcVeETVdwznVpo=; b=KnbriwOOyeoZ9VBZ8ryQB/q4fRWTVx5uW0o1UQWSgxADehOGBlLWNZJkoJ1kFhJ+5w zd89RItz1F9A2TsmXdBfDJ524Mm9d1cgSS8TZ28XqIJoGa5TdYSFY0L9XzNnCii2Ky9F IV06MnY6NsKpBaM14SsjxIe9P5hF+JZs9vCCrZUeTLl3vwa2lukLO7r3ublonqyj17W4 PH3hUZaQ1vMysVvKZ9hW1iN/Su9ZUZXjRbcyFqfx+1vIWXpNU6/8mNwfc3T3Y1NP/Q3W SBqkpgnSCbEYNMjs1f36gneHP71fk8rBYMVDRx7rYdweZBf5B2XW0Gt4zJcPuA4pSgXo Z4aQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=yFVVtZME57ctDTkQbatgKaxUdL7+TdcVeETVdwznVpo=; b=LlZfiW1D5eKwGRcAOQicoEiP8RA2SwK+3xyoqwpPYZtseCscIsAl8sg3CCb/Kr7/H3 pE9HgMX2q7ALSCSV8vHTUIgzT9fwz7ur28zzG18HWD8nmlrjIeROnocUv2gxBo+K7trC BQzvAXWmEFPz1I7B0oMg4AZwTWX34xwQ1cASy05m7AN15MycFXtDMD1c5Kj697Rs5zY2 JWHz9P9OtyzXdCmQanMANY11dMUp0a3oNUO1gdDIWn5hQC+qXE0THxKpjNVtvDuP+eY/ 5qgp80aQh+T3Yxm9nhvvQS+SEgqcz8kEWPz7fz2us4IvVtS25QyOAxKcqUch/Psip1m1 ivZg==
X-Gm-Message-State: ACrzQf1vHfr+1I5+tVJcytvAbZZttaWwM3EGqSgCsgo9su92dtFOr3tj hQof2obP0XQtUfrylyfjNGCQ9VFtNgrY1r7NQsOgBdsQ4f4=
X-Google-Smtp-Source: AMsMyM5aMKelGWDNEQy8LvsyfFoWFgK/C4yIfZyCFoFwFDZX8AVlp4EB6WsUgj1c0X3rEl8aldPyCh9xV40TtUPcArM=
X-Received: by 2002:a7b:c047:0:b0:3b4:adc7:1ecb with SMTP id u7-20020a7bc047000000b003b4adc71ecbmr4834900wmc.144.1663919603193; Fri, 23 Sep 2022 00:53:23 -0700 (PDT)
MIME-Version: 1.0
References: <bd7c5fb4-b398-c979-6f6b-0de82fd2ee12@bernat.ch> <dba40193-138e-5981-a4c2-6fc44fadde51@bernat.ch> <20220912203612.GA18968@pfrc.org> <6CB8C0EB-DC6E-48A8-993A-C98DEBD0D04A@juniper.net> <463DBA4E-3136-4A0F-A298-D081FEB123EB@pfrc.org> <20220914230819.GD27304@principal.rfc2324.org> <20220916101510.GA1365691@corley.shackle.nl> <MW3PR11MB4651FA81C4FC0E6C0F488DB4B64D9@MW3PR11MB4651.namprd11.prod.outlook.com> <058bcd84a50a4f3fa3fee62d0cf74da6@huawei.com> <0496725C-927F-4E62-9542-2C35874C8FDE@pfrc.org> <MW3PR11MB4651FED3E4009777B8F94FBDB6519@MW3PR11MB4651.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB4651FED3E4009777B8F94FBDB6519@MW3PR11MB4651.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 23 Sep 2022 09:53:45 +0200
Message-ID: <CAOj+MMGZSO=ZkMfh=k=UEmRcr2JvxdhL3WG8h63P5U1ph792Jg@mail.gmail.com>
To: "Tim Evens (tievens)" <tievens=40cisco.com@dmarc.ietf.org>
Cc: Jeffrey Haas <jhaas@pfrc.org>, Zhuangshunwan <zhuangshunwan@huawei.com>, "grow@ietf.org" <grow@ietf.org>, Maximilian Wilhelm <max@rfc2324.org>
Content-Type: multipart/alternative; boundary="000000000000e22db205e953784f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/XoA38RZNpULbvrIvYZTr5Vfj8RQ>
Subject: Re: [GROW] [Idr] RFC7854: EoR
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Sep 2022 07:53:29 -0000
Tim, Why not just send BGP Message Type 5 verbatim ? Are you saying that BMP is not sending this message to BMP receivers when arriving from BGP peers of the router ? If so why ? Thx, R. On Fri, Sep 23, 2022 at 2:03 AM Tim Evens (tievens) <tievens= 40cisco.com@dmarc.ietf.org> wrote: > When I wrote route-refresh, that was from the router/sender side, not BMP > receiver sending a route-refresh. BMP is still write-only. > > > > There are use-cases for re-syncing the RIB to the BMP receiver. Some of > the methods today are to clear the peer, request a route-refresh in, or to > reset the BMP feed. This is a bit intrusive to the router (sender) and BMP > receiver. Having to go to the router to request a refresh to the BMP > server, IMO, is still okay. The problem is that control knobs for refresh > are at the BGP peer level, not BMP. For Adj-RIB-In Pre-Policy, it makes > sense to do that on the peer, but for Post-Policy, Adj-RIB-Out and > Local-RIB, it doesn’t really make sense. Having a knob to initiate BMP > side refresh would be very nice and hopefully less intrusive. > > > > Regardless of the BMP server needing a refresh, a BMP server does not know > when someone has requested route-refresh IN at the peer level (maybe it was > requested for policy change, …) Instead, the BMP receiver, blindly, > receives a boat load of updates with no awareness that it was a new RIB > dump or controlled refresh. In this case, it would appear to be churn. > IMO, there is value in having a message to signal the receiver that a > refresh is coming, followed by an EoR. A PEER_UP could be used for this, > but that is intrusive and misuse of PEER_UP. > > > > --Tim > > > > On 9/22/22, 11:03 AM, "Jeffrey Haas" <jhaas@pfrc.org> wrote: > > > > > > > On Sep 21, 2022, at 7:42 AM, Zhuangshunwan <zhuangshunwan= > 40huawei.com@dmarc.ietf.org> wrote: > > > > Hi Tim and All, > > > > I think the idea of a "BMP route refresh" would be appreciated, it will > helps keep the information synchronized between the BMP Server and the BMP > Client. > > Would someone clarify what they mean by a bmp route refresh? > > The BMP protocol was intentionally designed as write-only. > > -- Jeff > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow >
- Re: [GROW] [Idr] RFC7854: EoR Jeffrey Haas
- Re: [GROW] [Idr] RFC7854: EoR Jeff Tantsura
- Re: [GROW] [Idr] RFC7854: EoR John Scudder
- Re: [GROW] [Idr] RFC7854: EoR Jeffrey Haas
- Re: [GROW] [Idr] RFC7854: EoR John Scudder
- Re: [GROW] [Idr] RFC7854: EoR Maximilian Wilhelm
- Re: [GROW] [Idr] RFC7854: EoR Luuk Hendriks
- Re: [GROW] [Idr] RFC7854: EoR Tim Evens (tievens)
- Re: [GROW] [Idr] RFC7854: EoR Robert Raszuk
- Re: [GROW] [Idr] RFC7854: EoR Tim Evens (tievens)
- Re: [GROW] [Idr] RFC7854: EoR Robert Raszuk
- Re: [GROW] [Idr] RFC7854: EoR Paolo Lucente
- Re: [GROW] [Idr] RFC7854: EoR Paolo Lucente
- Re: [GROW] [Idr] RFC7854: EoR Paolo Lucente
- Re: [GROW] [Idr] RFC7854: EoR Robert Raszuk
- Re: [GROW] [Idr] RFC7854: EoR Zhuangshunwan
- Re: [GROW] [Idr] RFC7854: EoR Zhuangshunwan
- Re: [GROW] [Idr] RFC7854: EoR Tim Evens (tievens)
- Re: [GROW] [Idr] RFC7854: EoR Henk Smit
- Re: [GROW] [Idr] RFC7854: EoR Tim Evens (tievens)
- Re: [GROW] [Idr] RFC7854: EoR Maximilian Wilhelm
- Re: [GROW] [Idr] RFC7854: EoR Tim Evens (tievens)
- Re: [GROW] [Idr] RFC7854: EoR Robert Raszuk
- Re: [GROW] [Idr] RFC7854: EoR Jeffrey Haas
- Re: [GROW] [Idr] RFC7854: EoR Jeffrey Haas
- Re: [GROW] [Idr] RFC7854: EoR Jeffrey Haas
- Re: [GROW] [Idr] RFC7854: EoR Jeffrey Haas
- Re: [GROW] [Idr] RFC7854: EoR Robert Raszuk
- Re: [GROW] [Idr] RFC7854: EoR Jeffrey Haas
- Re: [GROW] [Idr] RFC7854: EoR Robert Raszuk
- Re: [GROW] [Idr] RFC7854: EoR Tim Evens (tievens)
- Re: [GROW] [Idr] RFC7854: EoR Tim Evens (tievens)
- Re: [GROW] [Idr] RFC7854: EoR Robert Raszuk
- Re: [GROW] [Idr] RFC7854: EoR Zhuangshunwan
- Re: [GROW] [Idr] RFC7854: EoR Robert Raszuk
- Re: [GROW] [Idr] RFC7854: EoR Zhuangshunwan
- Re: [GROW] [Idr] RFC7854: EoR Zhuangshunwan
- Re: [GROW] [Idr] RFC7854: EoR Robert Raszuk
- Re: [GROW] [Idr] RFC7854: EoR Jeffrey Haas
- Re: [GROW] [Idr] RFC7854: EoR Jeffrey Haas
- Re: [GROW] [Idr] RFC7854: EoR Jeffrey Haas
- Re: [GROW] [Idr] RFC7854: EoR Henk Smit
- Re: [GROW] [Idr] RFC7854: EoR Robert Raszuk