Hi Prasad,
Thanks very much for your comprehensive review and sharing of thoughts.
Replies inline:
On 8/11/24 06:34, Narasimha Prasad S N (snprasad) wrote:
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)
We are full in sync with this.
1. Do you maintain similar peer DBs on your BMP collectors ? if NOT, what is
challenge of keeping one please ?
So, yes, the online BMP collector in itself is not an issue. It builds
state and keeps it. Should the collector be re-started, the state will
re-build according to the practices of rfc7854.
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.
An offline collector (or consumer) would realistically be a piece of
stream processing software reading a data stream from files, a message
bus, ie. Kafka, or a time-series database.
In other words - and i believe this will clarify a lot - the online BMP
collector does not act as a BMP exporter to the offline BMP collector.
Hence Peer summary messages would be instrumental for this piece of
offline software to build state while parsing a saved stream of BMP data.
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
I think the second part of my answer to #2 does clarify this. And the
goal is to try not to have collectors "invent" a way to save the table
of peers and rather supply a standardized way to do it.
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.
Awesome, thanks for confirming!
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
All indeed good points, will add more text.
About b) let me say that, yes, we would be interested also in Emulated
Peers (for Loc-RIB case). Probably my previous elaborations in this
email would already go in this direction.
About c), yeah, this is what probably monopolized the attention of Luuk
and myself, see where this can go wrong especially if this - generating
summaries - gets a function of both the router and the online collector;
probably by now we are convinced that it should be function of either
one or the other but let's let us all reflect more.
About a), d) absolutely, point taken.
We can meet and discuss more offline.
Certainly, any time, it would be a pleasure!
Paolo
_______________________________________________
GROW mailing list -- grow@ietf.org
To unsubscribe send an email to grow-le...@ietf.org
