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