Hi Paolo, Thomas, Few early qs/thoughts on the draft -
On the Router side and in our internal test BMP collector as well, we maintain a Peer DB with its capabilities cached. - The trigger to add a peer to this DB would be peer config on Router side and Peer-Up on the BMP collector side - The trigger to delete a peer from this DB would be Peer unconfig on the Router side and a Peer-down on the test BMP collector. - The peer capabilities get updated across few other triggers (across peer flaps) (Note: ignoring the LRIB Emulated peer case & couple of other cases to keep above explanation simple for now) 1. Do you maintain similar peer DBs on your BMP collectors ? if NOT, what is challenge of keeping one please ? 2. I am wondering, if we follow above, the update to offline collector could be trigger based (Peer-Up or Peer-Down). And we could avoid the need for periodic refreshes. And for cases when the connection to offline collector is lost, it would be a full-refresh of the Peer-DB. 3. Does the connection between online and offline BMP collectors already exist ? - If not, thoughts on operational aspects/complexity of introducing and maintaining connection between them. - If yes, could you please share more context on that - this would be a consideration 4. It should be simple to generate periodic updates from the Router side, if required. - As a best practice we should try and limit BMP collectors talking to Router to a couple when possible & do the mirroring outside of it. So even if we did this on Router side, the Router would talk to Online BMP collector which could then talk to other offline BMP collectors. 5. In the draft, it will be helpful to include following for clarity a. Diagram(s) that show the flow defined is between BMP collectors, as this part is covered in the last section of the draft, so one may almost miss this point b. If this is for real BGP peers or if we are interested in Emulated Peers (for LRIB case) c. Error Handling scenarios d. Location / connection mgmt. aspects between BMP collectors We can meet and discuss more offline. Thanks, /snnp (Prasad) -----Original Message----- From: Paolo Lucente <pa...@ntt.net> Sent: 06 November 2024 16:43 To: thomas.g...@swisscom.com; grow@ietf.org Subject: [GROW] Re: Fwd: New Version Notification for draft-lucente-grow-bmp-offline-00.txt Hi Thomas, Thanks for your review. You hit the nail on the head! We had an extended conversation yesterday with Luuk precisely on this point -- the draft of the -00 did include this possibility, the final -00 does not; we went for considerations for simplicity and today it is one point on which i'd have asked for feedback during the WG. So, yeah, if there is interest in this direction, we can open that door and review how summaries at the exporter and at the station can interplay. Paolo On 6/11/24 10:40, thomas.g...@swisscom.com wrote: > Dear Paolo and authors, > > Thanks a lot. I just reviewed the document and find it for a network > operators, operating network analytics stacks, very useful. > > The document abstract describes the aim of the document. Targeting the use > case of offline BMP data processing and in section 3 describing that the new > BMP message type is originated at the BMP monitoring station, data collection. > > I believe another very common use case can be covered as well. As stated, it > is very common that BGP peerings are very stable and peering state > informations might not persisted in a time series databases with limited data > retention. Have regular refreshes on BGP peering states is therefore very > helpful. Avoiding that the BGP peering state expires in the time series > database due to retention policy. In my opinion, these regular BGP peering > state refreshes could not only be originated from the BMP monitoring station, > but also from the router. This avoids that the BMP monitoring station needs > to cache, store the BMP message type peer_up in order to track the state of > the BGP peering as described in > https://datatracker.ietf.org/doc/html/draft-lucente-grow-bmp-offline-00#name-operational-considerations. > > If you agree that Peer Summary messages can be originated from the router as > well, we want to consider the enablement and frequency to be configurable > through https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-yang and > update draft-lucente-grow-bmp-offline with the use case an possibility to > originate Peer Summary messages from the router. > > Best wishes > Thomas > > -----Original Message----- > From: Paolo Lucente <pa...@ntt.net> > Sent: Tuesday, November 5, 2024 6:55 PM > To: grow@ietf.org grow@ietf.org <grow@ietf.org> > Subject: [GROW] Fwd: New Version Notification for > draft-lucente-grow-bmp-offline-00.txt > > > Be aware: This is an external email. > > > > Dears, > > A brief email to say about this initial effort we have just posted to make > BMP more off-wire friendly. I will briefly present around this at the Grow > session tomorrow. Appreciate as always thoughts, reviews and tomatoes. > > Paolo > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-lucente-grow-bmp-offline-00.txt > Date: Tue, 05 Nov 2024 10:48:38 -0800 > From: internet-dra...@ietf.org > To: Camilo Cardona <cam...@ntt.net>, Luuk Hendriks > <l...@nlnetlabs.nl>, Paolo Lucente <pa...@ntt.net> > > A new version of Internet-Draft draft-lucente-grow-bmp-offline-00.txt > has been > successfully submitted by Paolo Lucente and posted to the IETF repository. > > Name: draft-lucente-grow-bmp-offline > Revision: 00 > Title: Making BMP fruible offline > Date: 2024-11-05 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/archive/id/draft-lucente-grow-bmp-offline-00.txt > Status: https://datatracker.ietf.org/doc/draft-lucente-grow-bmp-offline/ > HTMLized: > https://datatracker.ietf.org/doc/html/draft-lucente-grow-bmp-offline > > > Abstract: > > BMP (BGP Monitoring Protocol) [RFC7854] is perfectly suited for real- > time consumption but less ideal for off-wire historical purposes. > The main issue is the dependence that parsing BGP Update PDUs has on > knowing which capabilities have been agreed when establishing the BGP > session with the peers, which could have happened long time ago > (days, weeks, months). > > This document defines a new optional BMP message type, called Peer > Summary, that carries a summary of the established BGP sessions along > with their capabilities and that is intended to be injected in the > BMP feed at configurable time intervals and/or ad-hoc whenever it is > felt necessary to improve fruition of BMP data offline. > > > > The IETF Secretariat > > > _______________________________________________ > GROW mailing list -- grow@ietf.org > To unsubscribe send an email to grow-le...@ietf.org _______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org _______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
