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

Reply via email to