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
* 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.
Many thx,
R.
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
[email protected]
https://www.ietf.org/mailman/listinfo/grow
