On 20/11/2008, at 6:51 AM, Stephen Stuart wrote:
On Wed, Nov 19, 2008 at 11:40 AM, Geoff Huston <[EMAIL PROTECTED]> wrote:
On 20/11/2008, at 5:16 AM, Stephen Stuart wrote:
This should probably not be a common case, but we do see it from
time to
time. It would be useful for us to be able to have this data.
Data regarding the state of configured peers are already available
by
other means (the BGP 4 MIB described in RFC1657); correlating with
that data tells us that a peer has supplied no updates
(BGP4-MIB::bgpPeerInUpdates.A.B.C.D). If the update count is non-
zero
and there are still no BMP messages indicating that the peer
supplied
a prefix, then it's likely attributable to "state changes in the
interim" for that prefix.
having access to a feed of BGP data for research purposes and SNMP
access to
the bgp speaker's MIB are invariably two entirely different concepts,
On the other hand, an application built to use a feed of BGP data for
decision support almost certainly has other sources of operational
data, such as BGP MIB data, readily available. At least that's the
case for me.
true, but my comment is motivated by the text in the draft's abstract
which states:
"BMP is intended to provide a more convenient interface for obtaining
route views for research purpose than the screen-scraping approach in
common use today".
And if the intent is to serve the BPG feed leeches (such as myself!)
then SNMP access is not a given.
geoff
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
