Robert, I was going to point that out in a summary of the latest changes, but you've beaten me to it.
My reasoning (I'll let the other authors speak for themselves if they wish) in not picking up this proposal was that I don't see any likelihood of it being implemented. Although the suggestion was that it be optional, my view is that if it won't be implemented, having it in the document detracts from the quality of the spec. "Perfection is reached not when there is nothing left to add, but when there is nothing left to take away." That said, it's a WG doc, and as you say if the WG wants to direct the authors to spec that optional feature, OK. I was planning on presenting the changes in Atlanta, and that would be a good time to discuss the pros/cons. I'll plan to spend some time on it in my presentation. Finally, as to your comment that "replay of Adj_RIB_In would miss all of those prefixes which were subject to drop due to BGP Origin Validation", I don't know why you think this. In our implementation, it isn't true. --John On Oct 22, 2012, at 5:23 PM, Robert Raszuk <[email protected]> wrote: > Dear BMP authors, > > The new version of the document seems still missing IMHO a very > important addition of additional BMP message allowing for "Raw inbound > BGP TCP stream" send in the BMP envelope to the station. > > For the record I did proposed the small diff to add it to previous > version but apparently some authors are of the opinion that this > should go into separate BMP extension draft with which recommendation > I respectfully do disagree. > > For the record of the list I am attaching the former diff which > accomplishes said _optional_ spec extension proposed on 21 Nov 2011. > > Now this seems even more important as just replay of Adj_RIB_In would > miss all of those prefixes which were subject to drop due to BGP > Origin Validation on inbound. Of course I will leave to the GROW > members to decide on this optional spec extension and evaluate it's > applicability in their own BMP applications. In my view this is a > useful add-on yet as being optional not hurting any of the existing > shipping BMP implementations in any way. > > Quote from email to the authors: > > Finally I was able to find the proposed diff to draft ver -05 of BMP draft. > > 204a205,209 >> o TCP Stream Wrap (SW): This is an ongoing time shifted mirroring >> of all or selected received BGP TCP streams to the router. It >> could be very useful in verbatim/as-received BGP protocol > monitoring. The implementation of this capability is optional. >> >> > 265a271 >> * Type = 5: TCP Stream Wrap (optional) > 657c663,695 > < 5. Other Considerations > --- >> 5. TCP Stream Wrap >> >> As router is receiving BGP data over TCP connection after > completing all TCP processing the payload is normally passed to BGP I/O. > At this time such payload may be locally mirrored, timestamped and > placed into temporary local storage. >> >> At different time as well as possibly by different CPU such data >> may be wrapped in defined type 5 BMP header and replicated to BGP > receivers. >> >> Reception of such copy of date stream will allow for number of > very important analysis to be done off-line by BMP station. Such > analysis may include: >> >> * Monitoring of specific behaviour of given prefix or set of >> prefixes originated by any AS, >> >> * Monitoring reception of BGP withdraws, their patterns as well as >> their >> >> * Monitoring of update/withdraw frequencies >> >> * Analysis on all received BGP messages before any BGP I/O and BGP >> inbound processing >> >> * Removed the need to keep full BGP_RIB_In in cases where such > storage >> is not required from operational and functional perspective >> >> * Easy ability to receive and interpret any protocol encoding errors >> (for example malformed updates or malformed BGP attributes) >> >> * Provide ability to verify correct BGP MP_REACH and MP_UNREACH >> attribute ordering in BGP messages by sending peer >> >> The implementation of this message time is optional. >> >> >> 6. Other Considerations > 675c713 > < 6. Using BMP > --- >> 7. Using BMP > 694c732 > < 7. IANA Considerations > --- >> 8. IANA Considerations > 703a742 >> o Type 5: TCP Stream Wrap > 705c744 > < Type values 5 through 128 MUST be assigned using the "Standards > --- >> Type values 6 through 128 MUST be assigned using the "Standards > > Best regards, > R. > > > > On Mon, Oct 22, 2012 at 11:00 PM, <[email protected]> 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-07.txt >> Pages : 22 >> Date : 2012-10-22 >> >> Abstract: >> This document defines a 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. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-grow-bmp >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-grow-bmp-07 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-grow-bmp-07 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
