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, [email protected] 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 <[email protected]>
Sent: Tuesday, November 5, 2024 6:55 PM
To: [email protected] [email protected] <[email protected]>
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: [email protected]
To: Camilo Cardona <[email protected]>, Luuk Hendriks <[email protected]>, Paolo Lucente 
<[email protected]>

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 -- [email protected]
To unsubscribe send an email to [email protected]

_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to