On Wed, Nov 19, 2008 at 8:28 AM, Erik Romijn <[EMAIL PROTECTED]> wrote: > Hi all, > > John G. Scudder wrote: >> >> Fast forward to present, there's been significant renewed interest so >> we've dusted off the draft and modified the mechanism to make it more >> implementor-friendly. I'm hoping that the WG would still, after the long >> hiatus, like to adopt the draft. > > Having been thinking myself about a similar custom system from time to time, > this looks very useful to me. > > Briefly reading through the draft, I do notice that there is no way to > detect the existence of a peer if it sends no prefixes (except when the > session goes down).
An implementation could send SR messages (section 2.2) to convey such information. > 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. Stephen _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
