Hi Stephen,
Many thx for your offer to work on the receiving side if the sender
could replicate incoming TCP streams and encapsulate them into the BMP
wrapper rather then maintain and generate updates from Adj_RIB_In.
I will get to you offline after discussion with other members of IOS BGP
team when we could offer prototype/eft of such solution.
However for perhaps obvious reasons it is in everyone's interest to
avoid any proprietary solutions to surface. That is main reason why I
proposed to include a new option in the current bmp spec allowing for it
to be while not mandatory, but still a standards based BMP encapsulation
option.
Cheers,
R.
On Fri, Dec 17, 2010 at 1:02 AM, Robert Raszuk<[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/grow
