Subject: [GROW] I-D Action: draft-ietf-grow-bmp-07.txt

From: [email-masked]
Date: Mon, 22 Oct 2012 14:00:46 -0700

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/

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 22 Oct 2012 23:23:21 +0200

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-masked]> wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> 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

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 23 Oct 2012 13:36:17 -0400

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-masked]> wrote:

> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 23 Oct 2012 14:16:28 -0400

You can get all the gory details from the diff (http://tools.ietf.org/rfcdiff?url2=draft-ietf-grow-bmp-07.txt) but here's my summary of the major differences between -03 and -04:

- Bumped length field to 32-bit (was 16-bit, which isn't enough if draft-ietf-idr-bgp-extended-messages-03 is in use).
- Session establishment must be rate-controlled.
- More information in Initiation message.
- Added several new stat types.
- Permit multiplexing pre- and post-policy Adj-RIBs-In.
- Allow monitoring station to be active party in establishing TCP connection.
- Introduced Termination message.
- Restructuring and terminology changes for clarity and readability.

I believe the changes take in all the suggestions from the WG, with the following exceptions:

- "Raw inbound BGP TCP stream", just discussed in another message.
- Instrumenting next hops. While a promising idea this would introduce significant complexity and I think falls under the "best is the enemy of good" heading. Perhaps BMPbis?
- Instrumentation of treat-as-withdraw. I think to do this right is harder than it sounds. I'll plan to cover this when I report at the WG meeting.

If you made a suggestion other than the exceptions listed above and don't see it reflected in the new draft, please let me know.

I'm hoping we will be able to WGLC this draft soonish, say by the Orlando meeting.

--John

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 24 Oct 2012 00:08:27 +0200

Hi John,

Thank you for your perspective on this topic.

One thing to clarify ...

> 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.

Origin Validation is applied pre-inbound-policy - I think you agree with this.

Assume that during the origin validation prefix received from the peer
is found as INVALID and marked as such. Subsequent inbound policy is
configured by the operator to drop INVALID rather then just to
deprefer or not consider those in the best path.

I am afraid in the former policy configuration such prefix will never
go to Adj_RIB_In. In the latter case it will.

Are you saying that in your implementation you do not allow to drop
INVALID prefixes on EBGP inbound policy ?

Thx,
R.

---

From: Pedro Andres Aranda Gutierrez <[email-masked]>
Date: Wed, 24 Oct 2012 09:28:24 +0200

IMvHO, all this is quite conveniently covered by the MRT drafts. I get
snapshots of traffic as well as of routing tables without any
"screen-scraping approach"

Best,
/PA

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 25 Oct 2012 15:11:37 -0400

> INVALID prefixes on EBGP inbound policy ?

No, you can filter them out just like any other route. I'm saying that in our implementation, by default we retain filtered routes in our Adj-RIB-In but don't allow them to be selected for inclusion in the Loc-RIB.

Also, if an implementation doesn't do this, it's a general issue and not specific to Origin Validation. The BMP draft does talk about this issue a little bit.

--John