On Fri, Dec 17, 2010 at 1:02 AM, Robert Raszuk <ras...@cisco.com> wrote: > Hi Stephen, > > Many thx for your reply. > >>> 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. > > Update "reconstruction" to me means to take what is already in Adj_RIB_In, > place it into the bmp wrapper and send over bmp session. In fact spec is > pretty clear to say this is normal, local, update generation essentially per > peer. > > Few points: > > * What is in Adj_RIB_In is already the product or result past the BGP IO > processing therefor any issues there will not be visible, > > * The information about update format received from the peer is lost - > example you will not be able to say if MP_(UN)REACH_NLRI were first in the > update msg nor what was for example the packing ratio
That level of protocol debugging was not a requirement for BMP, and isn't of interest for the family of applications that I'm trying to enable. Note that an implementation of BMP is free to replicate updates as received rather than generate them, and (arguably) it would bad from a software complexity standpoint to implement both. If you'd like to explore this further in, say, IOS, I would be happy to do the work on the receiver to bring it up to draft -04 and test with you. > * Many address families (example VPNv4) drop uninteresting routes when non > intersecting RT is found hence they will not be in Adj_RIB_In .. I would not > expect that for BMP reasons routers now will store all VPN routes > permanently > > * You loose information about update frequency, inter-update gaps, churn > > * You report only accumulated number of invalidate routes without listing > those NLRIs .. > > I think those are enough of reasons to consider adding a new option to bmp > to actually allow to wrap received TCP strems from each peer like Tony has > proposed in a bmp header and send it to the observatory linux station. In > this case non of the above drawback would occur. > > Moreover such wrapping and sending does not need to happen inline .. it is > very easy to buffer in RAM or in HDD copy of incoming streams for their push > to linux box when CPU has spare cycles to do so. > > Also it needs to be noticed that such option would not require to increase > amount of permanent resource use by the bgp speaker. While Adj_RIB_In would > need to be kept, keeping above described TCP streams is only a transient > resource usage. > > The timestamp in BMP header in this case may actually reflect the true > reception of such stream to the router allowing for much broader use case. > > And again I am not saying that current message types should be removed from > the spec. I am just proposing to add one more and let the implementer and > operator choose which one makes most sense for them. As above, that's orthogonal to the type of application that I need to enable, but if you want to prototype something I'm happy to help on the receiver side. How soon do you think you can have an implementation ready? Thanks, Stephen >>> 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
