Hi Paolo, all, Thanks for writing down this idea in. Being on the consumer / BMP station side of things, I'd welcome REL as I agree with the motivation in the Introduction section. But I also realise that the exporting side might be far more challenging to implement. Curious to hear what people from that side think.
Having said that, some thoughts on the -00: Sec 3.2: Do we need to reuse the entire BGP UPDATE PDU, or can we only reuse NLRI encoding? The overhead of especially the 16 byte marker, but also the message type, (perhaps the message length), the Withdrawn Routes Length, that all seems a bit excessive and unnecessary. I do agree we should not reinvent the wheel when it comes to the NLRI encodings and their existing support in BGP. We'll need the AFI/SAFI for that, so the MP_REACH_NLRI attribute format seems like a good choice, though perhaps without the Next Hop and the Reserved byte? (I think in MRT something similar happens, but I'd have to double check.) Re point 2 in your mail, you mention that we perhaps want to be able to export other message types besides the UPDATE PDU. Whichever way this goes, I think we need to minimise possible confusion between what is exported verbatim (i.e. an exact copy of a PDU that has been observed on the wire), vs a synthesized/constructed message, mimicking a BGP PDU that looks like it could have been sent over the wire but actually never was. Thanks, luuk On Thu 10 Nov 2022, 13:43, Paolo Lucente wrote: > > Dear Growers, > > I wanted to draw your attention on this new document that i just submitted - > and that i hope the venerable Chairs would allow me to briefly present > tomorrow. > > Basic idea: in BMP we have State Synchronization (Route Monitoring), > Debugging (Route Mirroring), Statistics, etc. but we miss the Event Logging > complement to the existing messages, or anyway some sort of event-driven > message type. > > There has been conversation in the past - and even a draft proposal! - and > where this work would like to go is towards a more simple / stream-lined > approach and broader applicability. > > I reckon myself the current document has several limits: > > 1) it was worked out in rush, > > 2) it is a very humbled down proposal which can potentially grow (haha!) in > several directions, like why limiting it to routes only? Also what if one > wants to log specific BGP message types, then the BGP Message TLV should be > able to contain a BGP message different than an Update (which is the current > proposal). > > I would like to take this -00 version as a showcase for the idea / problem > domain and would love to receive feedback: do you see it valid? is there > interest? Thanks for any attention you can give to it & here ready for the > tomatoes. > > Paolo > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-lucente-grow-bmp-rel-00.txt > Date: Thu, 10 Nov 2022 05:30:06 -0800 > From: [email protected] > To: Paolo Lucente <[email protected]> > > > A new version of I-D, draft-lucente-grow-bmp-rel-00.txt > has been successfully submitted by Paolo Lucente and posted to the > IETF repository. > > Name: draft-lucente-grow-bmp-rel > Revision: 00 > Title: Logging of routing events in BGP Monitoring Protocol > (BMP) > Document date: 2022-11-10 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/archive/id/draft-lucente-grow-bmp-rel-00.txt > Status: https://datatracker.ietf.org/doc/draft-lucente-grow-bmp-rel/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-lucente-grow-bmp-rel > > > Abstract: > The BGP Monitoring Protocol (BMP) does provision for BGP session > event logging (Peer Up, Peer Down), state synchronization (Route > Monitoring), debugging (Route Mirroring) and Statistics messages, > among the others. This document defines a new Route Event Logging > (REL) message type for BMP with the aim of covering use-cases with > affinity to alerting, reporting and on-change analysis. > > > > > The IETF Secretariat > > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
