On Wed, Dec 15, 2010 at 3:26 PM, Robert Raszuk <ras...@cisco.com> wrote: > John at all, > >> Title : BGP Monitoring Protocol >> Author(s) : J. Scudder, et al. >> Filename : draft-ietf-grow-bmp-05.txt >> Pages : 16 >> Date : 2010-12-15 > > If I remember correctly the fundamental reason for bmp was to provide a very > simple mechanism for replaying content of received updates from the peers as > well as provide some form of signaling reg their state transition. That goal > was great. > > Unfortunately version -01 and above moved away from this and simplified the > requirement to reply/send content of Adj_RIB_In instead of those coming > updates from the peers.
It allowed an implementation to reconstruct updates, rather than replicate them. > So we are effectively loosing the most crucial part of the original proposal > as we no longer be able to pass to some observatory linux station those > prefixes which were dropped on inbound or worse any potential malformed > updates or attributes if they were not stored in the RIB_In. I disagree. The most crucial part of the proposal is to get the contents of Adj_RIB_In from the router to a monitoring station, without the filter of best path selection that occurs when you use BGP peering as a means to monitor what the router sees (and bgp-add-paths doesn't accomplish this, either). The corner cases of malformed updates and filtered updates simply aren't interesting for the application that this protocol was designed to enable - centralized analysis of the whole of an autonomous system's Adj_RIB_In. > I think it defeats a lot of use cases. Perhaps this subtle difference should > be discussed more before we proceed any further with this document. This was discussed before, if I recall correctly. BMP is proposed to do one job well, and that's to get the collected Adj_RIB_In out, globally, to where it can be processed by real computers. Stephen _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
