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 <[email protected]> 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 <[email protected]>: > > > 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 <[email protected]> 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 <[email protected]>: > > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/grow > >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
