I would like too see some information, commonly obtained through "show bgp summary" in SR messages: MsgRcvd/MsgSent: useful to find verbose neighbours. PfxRcd: useful to produce an alarm reaching some threshold InQ/OutQ: useful to...
-- Pedro On Wed, Nov 19, 2008 at 6:04 PM, Stephen Stuart <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
