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

From: [email-masked]
Date: Thu, 01 Dec 2011 07:14:19 -0800

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

---

From: John Scudder <[email-masked]>
Date: Thu, 1 Dec 2011 07:20:43 -0800

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

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 01 Dec 2011 16:55:04 +0100

Hello John,

As we have previously discussed on and off list the current BMP draft 
does not meet customer's requirements in the space of BMP monitoring.

It almost adds no value in comparison with sending full BGP table 
without any outbound policy by add-paths option ALL so in that light it 
is just a duplication of different ways to accomplish the same.

In particular it regenerates updated as stored in Adj_RIB_In which 
automatically means that any errors or even order of attributes your 
peer is sending will not be seen at the management station.

I asked to add new optional type called "Session Monitoring" which would 
allow to encapsulate and reply to management station raw PDUs however it 
seems from the below -05 to -06 delta that my suggestion has been ignored.

I think we have a chance to deliver something much more useful and 
meaningful to customers without compromising or putting at risk existing 
implementations.

Please kindly reconsider.

Best regards,
R.

> On Dec 1, 2011, at 10:14 AM,<[email-masked]>  wrote:
>
>>

---

From: "Evens, Tim" <[email-masked]>
Date: Thu, 1 Dec 2011 11:01:12 -0800

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

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

---

From: Stephen Stuart <[email-masked]>
Date: Fri, 2 Dec 2011 18:38:57 -0800

On Thu, Dec 1, 2011 at 7:55 AM, Robert Raszuk <[email-masked]> wrote:
> Hello John,
>
> As we have previously discussed on and off list the current BMP draft does
> not meet customer's requirements in the space of BMP monitoring.

As discussed, it does not meet some customers' requirements. It does
meet others, such as mine.

> It almost adds no value in comparison with sending full BGP table without
> any outbound policy by add-paths option ALL so in that light it is just a
> duplication of different ways to accomplish the same.

I feel that it does add value in that my receiver application in the
BMP case does not need to be a BGP protocol speaker with risk of
impact to the control plane.

> automatically means that any errors or even order of attributes your peer is
> sending will not be seen at the management station.

This is not relevant in my case.

> seems from the below -05 to -06 delta that my suggestion has been ignored.

It wasn't ignored. It was discussed, and as the proposal grew to try
to encompass error cases and include timestamps, and the lack of
clarity around potential for duplication of the same information
between the proposed optional type and existing required types, I
preferred to recognize the progress we have made and address new
requirements - which I recognize are reasonable for *some* use cases
beyond mine - in a new draft.

Stephen

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 03 Dec 2011 14:05:42 +0100

Hello Stephen,

 > which I recognize are reasonable for *some* use cases
 > beyond mine

Different networks have different requirements - that is true. However 
IETF usually attempts to address broader requirements pool.

Few comments ...

> impact to the control plane.

I wasn't proposing one. Today to parse BMP as is you need to understand 
attribute formats already. Adding ability to to be able to recognize BGP 
messages seems like an afternoon project. Same for sending the BGP OPEN 
with add-path capability.

If you are really concern there are hooks already which can safely drop 
anything what such essentially passive peer would attempt to send you.

> between the proposed optional type and existing required types,

The existing "required" types are required by the BMP draft. Clearly it 
should be up to the operator to specify which types he is interesting in 
receiving on his monitoring station. If particular implementation does 
not offer such selection on what to send such implementation would need 
to be fixed. (And it is a very minor fix).

> I

My suggestion does not put at risk the progress made so far. It only 
allows operator to choose if he wants to rebuild the Adj_RIB_In and send 
it towards monitoring station or if he would rather select to get all 
information received from his peers as original BGP PDUs.

Yes we have talked about the new draft - but I completely do not see 
this as good idea if we are just about adding new type to entire 
existing BMP mechanism. Based on my IETF experience and guidelines such 
draft would be subject to be merged with existing BMP draft.

Best regards,
R.

---

From: Danny McPherson <[email-masked]>
Date: Sat, 3 Dec 2011 08:26:12 -0500

A few comments on the current draft.

Thanks Stephen, 

-danny

---
Regarding this section:

   BMP operates over TCP.  All options are controlled by configuration
   on the monitored router.  No message is ever sent from the monitoring
   station to the monitored router.  The monitored router MAY take steps
   to prevent the monitoring station from sending data (e.g. by half-
   closing the TCP session or setting its window size to zero) or it MAY
   silently discard any data erroneously sent by the monitoring station.

   "... If the router is unable to connect to the monitoring station, it periodically 
    retries the connection. .."

I'm not sure what this all means?  When I first read it I had assumed that 
you were referring to "No BMP message is ever sent from the monitoring 
station .." but upon reading further it seems to suggest that you are 
changing basic TCP behaviors here as well; the current recommendation
concerns me, as it creates non-deterministic failure conditions.  Am I 
missing something?

---
In S 3.5 how would an operator use the SR and Stat Data to determine, for
example, a particular prefix that was resulting in a large number of duplicate
advertisements?  I'm inclined to think we should go ahead and specify that
"more complex TLV-type" stat data now, such that implementations that wish 
to convey which prefixes are of interest can do so.   Thoughts on this?

Also, it would allow us to discriminate in cases where, e.g., a cluster_list loop 
is actually a legitimate withdraw?

---
I wonder if S 3.5 or S 3.6 should have some additional text to accommodate 
the new bgp error handling procedures being defined in IDR - e.g., flag these
updates as "special", and you could even address issues by others here with 
TLV capabilities in S 3.5 that would allow inclusion of additional data, if need
be?

---
In S 9 I think if confidentiality is not the requirement but integrity is then 
perhaps TCP-AO should be recommended?

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 05 Dec 2011 12:07:16 +0000

>    service-affecting.  BMP is not suitable for use as a routing

John,

Would it be possible to modify the peer flags?  In the context of route
servers, we operators have separate requirements to be able to view:
adj-rib-in, per-peer loc-rib and adj-rib-out, with the possibility of a
primary loc-rib (depending on implementation).  This would break your
suggested peer flags mechanism - or at least it would create a non-atomic
signalling mechanism which would take up 50% of your proposed flag space to
implement.  Why not create a separate "RIB Type" flag and define a set of
values associated with it?

Nick

---

From: John Scudder <[email-masked]>
Date: Thu, 8 Dec 2011 12:21:04 -0800

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 08 Dec 2011 21:31:09 +0100

Hi John,

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

Has anyone proposed BMP extension which would fall into "boiling the 
ocean" category ?

> I'd also like to encourage
> any interested party including you to Send Text if you've a mind to.

I hope you still have the diff for my proposal ...

> The next hop thing is interesting, but I have to ask: can't you pull
> it out of the IGP already?

Not possible across IGP areas/levels.

However perhaps it would be interesting to discuss pros/cons of using 
either:

http://tools.ietf.org/html/draft-gredler-bgp-te-01
http://tools.ietf.org/html/draft-varlashkin-bgp-nh-cost-02

Tim - do you think using any of those would not be feasible for you ? If 
not I am personally fine to extend BMP to carry next hop metrics.

Of course Stephen will say that it requires to run BGP on the linux host 
and is a dangerous thing, but is that really an issue ?

Best regards,
R.