Re: [GROW] [Idr] RFC7854: EoR

[Robert Raszuk <[e-mail]>]

Hi Henk,

Ok we are on the same page.

As you can see in this message I exactly described that in monitoring mode
we send the "latest" not all messages:
https://mailarchive.ietf.org/arch/msg/grow/I83kOjy63OCg34e4a9ygdU8XkfI/

I did not even know we call it "compression" :)

But then there is mirroring mode of operation where I think by the spec it
is bit by bit replay. Perhaps as Jeff and later I noted with some vendor
secret sauce filtering.

I agree with Jeff that sending all counters which I suggested would mean
sending all RIB (or rather Adj_Rib_In). But that was not really what I
meant by asking if extension to BMP to carry such churn counters is
something folks would like to see happening.

I was more thinking that we specify such counters + add b_net info and send
it periodically only when it increases above a wise threshold. Not sending
a full table at all.

Sure here we come to really ask if such counters should be sent by BMP or
MGMT/YANG channels. I am a bit split on this. Input welcome !

Best,
Robert





On Fri, Sep 23, 2022 at 5:41 PM Henk Smit <[e-mail]> wrote:

> Hi Robert,
>
> > I do not agree that exposing churn is hard.
>
> Maybe not. But not by reporting every incoming BGP packet bit-for-bit to
> the collector.
> You want to keep the "compression". I wouldn't call it compression, I
> would call it "reporting only the latest state".
>
> If you want to look at problems, you have your periodic counters. Those
> should help.
>
> > just keep local churn counter per NLRI
>
> If you want to look at per-NLRI granularity, indeed we could use some more
> information in the message-format.
> If people had been interested in my BMPv4-draft from 2018, we would have
> had proper TLVs for all packet-types.
> And adding a "churn-counter TLV" to monitoring messages would have been
> trivial. And backwards compatible.
> Has:
> https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv
> been implemented yet? Do we have TLVs for Route Monitoring messages?
>
> In any case, I would advocate for keeping the "compression" mechanism in
> BMP. Only report the lastest state.
>
> henk.
>
>
> Op 21-09-2022 22:55 schreef Robert Raszuk <[e-mail]>:
>
>
> Hey Henk,
>
> The point is that what matters in BGP is reachability and stability //
> Leave aside all the opaque junk BGP carries today //. Reachability you can
> pretty much monitor by vanilla IBGP session say with Add-Paths if you want
> to be fancy. Stability or more importantly filtering the "bad" routes is a
> bit harder.
>
> So I do not agree that exposing churn is hard. You perhaps think about it
> in the atomic model where you have to mirror all received messages. Well
> BMP original idea was about just that. But here we need to decouple
> discussion about sharing Adj_RIB_In from global bRIB.
>
> But here you can just keep local churn counter per NLRI to periodically
> send it in BMP indicating how many paths for a given b_net was received or
> withdrawn since your last BMP update. And it does not need to take much
> space on the sender nor BMP receiver.
>
> I would call it smart-compression where you significantly reduce make the
> bits on the wire or in the ram/ssd yet you do not drop useful information.
>
> Many thx,
> R.
>
> On Wed, Sep 21, 2022 at 3:45 PM Henk Smit <[e-mail]> wrote:
>
> Hi Robert,
>
> > But this will hide BGP churn for a given NET to be detectable by BMP
> receiver. Is this a good thing ?
>
> The question is: how expensive is it to report everything bit-for-bit to
> the BMP collector?
> If you want to report everything, you have to store everything.
> Which will require bufferspace. How much? You don't know in advance. Might
> be a lot.
>
> The current way of doing things allows the BMP implementation on a router
> to be pretty efficient.
> When BGP receives routes, you store them in the BRIB. You don't store
> anything special for BMP (expect maybe timestamps, or other meta-data).
> When BMP on a router is going to send BMP updates, it just walks the BRIB,
> and sees which NLRI/routes have not been sent to the collector yet.
> BGP needs only 1 bit of information for that (to be precise: 1 bit per BMP
> session per NLRI/route).
>
> If you want to see all churn, you need loads of buffers.
> And BMP stops being an easy and efficient protocol.
> So yeah, I am greatly in favor of allowing "compression" (aka skipping
> reporting outdated info).
>
> henk.
>
>
> Op 21-09-2022 07:52 schreef Robert Raszuk <[e-mail]>:
>
>
> Hi Paolo,
>
> A-la: there is multiple updates related to a certain NLRI by when a BMP
> message is to be sent out, let's state-compress (ie. not send out) those
> that were already obsoleted by a subsequent update.
>
>
> But this will hide BGP churn for a given NET to be detectable by BMP
> receiver. Is this a good thing ? I am not sure. It is a loss of information
> to me.
>
> Thx,
> R.
> _______________________________________________
> GROW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/grow
>
>