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. > unfortunately, so while it may be in the MIB that does not mean that a BMP > client has a prayer of ever access that mib! > > So, yes, it would be useful to have this data inband within the BMP feed. As noted previously, SR messages can signal the existence of a peer, and the monitoring application can use that information to determine that a peer exists which has not supplied updates. Stephen _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
