Tim, Thanks for your comments. Your suggestions for the Initiation Message look like good stuff. I would like to encourage the WG to brainstorm whether there are any other items to add to the laundry list (without boiling the ocean, please). I'd also like to encourage any interested party including you to Send Text if you've a mind to.
The next hop thing is interesting, but I have to ask: can't you pull it out of the IGP already? The reason we built BMP was because you just couldn't get the info you need by BGP peering with the router, so we had to come up with another way to externalize it. This is not the case with the next hop stuff, is it? I would prefer not to reinvent wheels if we can avoid it. Regards, --John On Dec 1, 2011, at 2:01 PM, Evens, Tim wrote: > Hi John et al., > > Below are some comments. > > Initiation Message: > > I like having Type-0 (free form text) but I think that some common > information about the router/config should be consistently conveyed. > My top of mind items are: > 1) Router product vendor ID, such as the enterprise OID > 2) Router hostname > 3) Software version > 4) Per Peer administrative configuration, such as: > 4a) Description of peer > 4b) peer-group name, if in peer-group > 4c) flag to indicate if peer is IBGP-RR client or not > 4d) aggregated list of filter names applied in/out (route-maps, > import/export, prefix-lists, > filter-list) - vendor specific, but would allow management > system to lookup the filters > applied or to validate correct filters are applied without > having to query the router directly > via other means. > > New BMP Message Type (IGP next-hops) : > > We have developed a BMP server that collects the BMP messages, but without > the IGP next hop metrics we are not able to do predictive calculations on > the learnt prefixes. The Loc-RIB sheds light into what the router has > selected/installed, but it doesn't give the BMP server the ability to > identify why those prefixes were preferred over another peer on the same > router in terms of the next-hops. Since the IGP next hops are not tied > with BGP updates, it seems to make most sense to add a new message type > "IGP next hop" that would convey the admin preferences/distance/metrics > for BGP next hops. No sense in advertising everything, just the next hops > are needed. Providing we have the IGP next hop information from the > perspective of the router, we will be able to do predictive analysis on > policy changes based on the Adj-RIB-In information. > > The Loc-RIB information is still greatly needed since it provides details > on which prefixes were actually installed, which helps confirm policy > filters are working correctly. > > > Thanks, > > Tim > > On 12/1/11 7:20 AM, "John Scudder" <j...@juniper.net> wrote: > >> Folks, >> >> Changes between -05 and -06 are: >> >> - Added "Lifecycle of a BMP Session" section. It seemed as though people >> really needed a little more context as to the expected sequence. >> >> - Changed Message Length to 4 bytes. (See >> draft-ietf-idr-bgp-extended-messages-01 for some context as to why this >> seemed like a good idea.) >> >> - Changed Initiation Message string encoding from ASCII to UTF-8. >> >> - Specified that Version 0 is reserved. >> >> Regards, >> >> --John >> >> On Dec 1, 2011, at 10:14 AM, <internet-dra...@ietf.org> wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the Global Routing Operations >>> Working Group of the IETF. >>> >>> Title : BGP Monitoring Protocol >>> Author(s) : John Scudder >>> Rex Fernando >>> Stephen Stuart >>> Filename : draft-ietf-grow-bmp-06.txt >>> Pages : 17 >>> Date : 2011-12-01 >>> >>> This document proposes a simple protocol, BMP, which can be used to >>> monitor BGP sessions. 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. The design goals are >>> to keep BMP simple, useful, easily implemented, and minimally >>> service-affecting. BMP is not suitable for use as a routing >>> protocol. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-grow-bmp-06.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-grow-bmp-06.txt >>> >>> _______________________________________________ >>> GROW mailing list >>> GROW@ietf.org >>> https://www.ietf.org/mailman/listinfo/grow >> >> _______________________________________________ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow > _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
