On Wed, Nov 19, 2008 at 11:58 AM, Geoff Huston <[EMAIL PROTECTED]> wrote: > > 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.
Agreed. Do SR messages suffice? Would you prefer to see some of the information from the bgpPeerTable replicated in SR messages? _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
