Subject: [GROW] draft-scudder-bmp-01

From: "John G. Scudder" <[email-masked]>
Date: Wed, 12 Nov 2008 19:16:52 -0500

GROW folks,

I'll be presenting draft-scudder-bmp-01 ("BGP Monitoring Protocol") at  
the meeting in Minneapolis.  Long-time GROW fans may remember that the  
WG requested to make the -00 version a WG document way back in 2005.   
It turned out that there were some major implementation hurdles with  
the draft as written and it became moribund and never did get issued  
as draft-ietf-grow.

Fast forward to present, there's been significant renewed interest so  
we've dusted off the draft and modified the mechanism to make it more  
implementor-friendly.  I'm hoping that the WG would still, after the  
long hiatus, like to adopt the draft.

Since I missed the submission cutoff, a copy of the draft is attached  
for those who'd like to (please!) look at it before the meeting.  Your  
comments are welcome before, during or after the meeting.

--John

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

---

From: Geoff Huston <[email-masked]>
Date: Fri, 14 Nov 2008 04:23:37 +1100

On 13/11/2008, at 11:16 AM, John G. Scudder wrote:

> GROW folks,
>
> I'll be presenting draft-scudder-bmp-01 ("BGP Monitoring Protocol")  
> at the meeting in Minneapolis.  Long-time GROW fans may remember  
> that the WG requested to make the -00 version a WG document way back  
> in 2005.  It turned out that there were some major implementation  
> hurdles with the draft as written and it became moribund and never  
> did get issued as draft-ietf-grow.
>
> Fast forward to present, there's been significant renewed interest  
> so we've dusted off the draft and modified the mechanism to make it  
> more implementor-friendly.  I'm hoping that the WG would still,  
> after the long hiatus, like to adopt the draft.
>
> Since I missed the submission cutoff, a copy of the draft is  
> attached for those who'd like to (please!) look at it before the  
> meeting.  Your comments are welcome before, during or after the  
> meeting.

AS the then-chair of the GROW WG that was requesting submission of  
this draft as a WG document way back then, I'm really glad to see that  
its finally seeing the light of day once more as its a potentially  
very useful BGP monitoring tool. So I support this draft being adopted  
as a WG document - its a potentially very useful mechanism.

I'm a little confused however by some of the details. It appears that  
BMP is a method to tap into a peer session and the local BGP speaker  
can be configured to send a copy of all received updates from a BGP  
peer to a monitor point using BMP, including the time when these  
updates were received by the local BGP speaker.

However in section 3 the text states: "If there are state changes in  
the interim for that prefix, it is acceptable that the router generate  
the final state of that prefix to the monitoring station. "

What I'm confused about is: what timestamp should be used in such a  
case? And does this "final state" reflect the final state in the  
logical Adj-RIB-In for this BGP peer, or the final state according to  
the local Loc-RIB?

thanks,

     Geoff

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 13 Nov 2008 13:51:38 -0500

Geoff,

On Nov 13, 2008, at 12:23 PM, Geoff Huston wrote:
> I'm a little confused however by some of the details. It appears  
> that BMP is a method to tap into a peer session and the local BGP  
> speaker can be configured to send a copy of all received updates  
> from a BGP peer to a monitor point using BMP, including the time  
> when these updates were received by the local BGP speaker.
>
> the interim for that prefix, it is acceptable that the router  
> generate the final state of that prefix to the monitoring station. "
>
> case?

The timestamp should reflect the time the final state transition  
occurred.  So for example if the router saw:

time = 1, state = 10/8 via 1.1.1.1
time = 2, state = 10/8 withdrawn
time = 3, state = 10/8 via 2.2.2.2

And generated the BMP message 10/8 via 2.2.2.2, it would be  
timestamped with time = 3.

> And does this "final state" reflect the final state in the logical  
> Adj-RIB-In for this BGP peer, or the final state according to the  
> local Loc-RIB?

The former (Adj-RIB-In) unless the implementation is unable to support  
Adj-RIB-In and uses Loc-RIB instead as discussed in Section 3  
paragraph 2.

--John

---

From: Ricardo Oliveira <[email-masked]>
Date: Thu, 13 Nov 2008 16:52:44 -0800

BMP would be a great tool for BGP monitoring since it virtually  
multiplies the number of feeds received in a single session; i.e. not  
only we get to know the updates of the direct peer but also those of  
its neighbors (minus delta of policy filters);   wondering if there's  
running code for BMP already..
Cheers,

--Ricardo

On Nov 12, 2008, at 4:16 PM, John G. Scudder wrote:

> that the WG requested to make the -00 version a WG document way  
> back in 2005.  It turned out that there were some major  
> implementation hurdles with the draft as written and it became  
> moribund and never did get issued as draft-ietf-grow.
>
> <draft-scudder- 
> bmp-01.txt>_______________________________________________
> GROW mailing list
> [email-masked]

---

From: Danny McPherson <[email-masked]>
Date: Thu, 13 Nov 2008 18:03:54 -0700

On Nov 13, 2008, at 5:52 PM, Ricardo Oliveira wrote:

> multiplies the number of feeds received in a single session; i.e.  
> not only we get to know the updates of the direct peer but also  
> those of its neighbors (minus delta of policy filters);   wondering  
> if there's running code for BMP already..

Indeed..  I support this work as well...

-danny

---

From: Shane Amante <[email-masked]>
Date: Tue, 18 Nov 2008 22:09:04 -0700

Hi John,

> after the long hiatus, like to adopt the draft.

I'm glad to see this draft has been resuscitated and I do support its  
adoption.

A few questions:
1)  The draft says the following in Section 2:
---snip---
If the peer is a "Global Instance Peer", this field is zero filled. If  
the peer is a "L3VPN Instance Peer", it is set to the route  
distinguisher of the particular L3VPN instance that the peer belongs to.
---snip---
I'm a little confused by the second sentence.  Is that referring to  
the case where a router is doing RFC 4364 "Option A" style eBGP with a  
remote peer, or something else?

2)  In Section 3, the draft talks about sources of routing information  
(Adj-RIB-In or Loc-RIB) sent in Route Monitoring messages.  Would it  
be useful to have a bit in the BMP "Peer Flags" that indicates if the  
path being sent in a RM message was retrieved pre- (Adj-RIB-In) or  
post- (Loc-RIB) policies, so the receiver knows which he/she is  
looking at?

3)  How will BMP cope with BGP flap dampening being enabled on a BMP  
source router?  In other words, a router (configured as a BMP source)  
receives a series of WITHDRAW's & UPDATE's that it is configured to  
apply flap dampening on, suppressing re-advertisement of these updates  
further into an AS.  If the BMP source is forwarding messages from Adj- 
RIB-In, would a BMP receiver see all incoming WITHDRAW's & UPDATE's  
associated with a "flap" event, (even though these updates would have  
been suppressed from further re-advertisement after flap dampening is  
applied)?  How would, or should, a BMP receiver know that flap  
dampening is enabled and/or would be applied?
     The reason I ask is perhaps this is more a question of the  
'authenticity' of "monitoring data" at a BMP receiver with respect to  
formulating what did (or could) have happened with a series of Updates  
being propagated further within an AS?  Or, perhaps there's another  
answer?

-shane

---

From: Erik Romijn <[email-masked]>
Date: Wed, 19 Nov 2008 17:28:50 +0100

Hi all,

> long hiatus, like to adopt the draft.

Having been thinking myself about a similar custom system from time to 
time, this looks very useful to me.

Briefly reading through the draft, I do notice that there is no way to 
detect the existence of a peer if it sends no prefixes (except when the 
session goes down).

This should probably not be a common case, but we do see it from time to 
time. It would be useful for us to be able to have this data.

cheers,
Erik Romijn
RIPE NCC RIS

---

From: Stephen Stuart <[email-masked]>
Date: Wed, 19 Nov 2008 10:16:54 -0800

On Wed, Nov 19, 2008 at 8:28 AM, Erik Romijn <[email-masked]> wrote:
>> implementor-friendly.  I'm hoping that the WG would still, after the long
>> hiatus, like to adopt the draft.
>
> Having been thinking myself about a similar custom system from time to time,
> this looks very useful to me.
>

An implementation could send SR messages (section 2.2) to convey such
information.

> time. It would be useful for us to be able to have this data.

Data regarding the state of configured peers are already available by
other means (the BGP 4 MIB described in RFC1657); correlating with
that data tells us that a peer has supplied no updates
(BGP4-MIB::bgpPeerInUpdates.A.B.C.D). If the update count is non-zero
and there are still no BMP messages indicating that the peer supplied
a prefix, then it's likely attributable to "state changes in the
interim" for that prefix.

Stephen

---

From: Stephen Stuart <[email-masked]>
Date: Wed, 19 Nov 2008 10:19:27 -0800

On Tue, Nov 18, 2008 at 9:09 PM, Shane Amante <[email-masked]> wrote:
>> I'll be presenting draft-scudder-bmp-01 ("BGP Monitoring Protocol") at the
>> meeting in Minneapolis.  Long-time GROW fans may remember that the WG
>> requested to make the -00 version a WG document way back in 2005.  It turned
>> out that there were some major implementation hurdles with the draft as
>> written and it became moribund and never did get issued as draft-ietf-grow.
>>
> If the peer is a "Global Instance Peer", this field is zero filled. If the
> peer is a "L3VPN Instance Peer", it is set to the route distinguisher of the
> particular L3VPN instance that the peer belongs to.
> ---snip---
> I'm a little confused by the second sentence.  Is that referring to the case
> where a router is doing RFC 4364 "Option A" style eBGP with a remote peer,
> or something else?
>
> (Adj-RIB-In or Loc-RIB) sent in Route Monitoring messages.  Would it be
> useful to have a bit in the BMP "Peer Flags" that indicates if the path
> being sent in a RM message was retrieved pre- (Adj-RIB-In) or post-
> (Loc-RIB) policies, so the receiver knows which he/she is looking at?

The "L" flag described in section 2.1 conveys that information?

Stephen

> 3)  How will BMP cope with BGP flap dampening being enabled on a BMP source
> router?  In other words, a router (configured as a BMP source) receives a
> series of WITHDRAW's & UPDATE's that it is configured to apply flap
> dampening on, suppressing re-advertisement of these updates further into an
> AS.  If the BMP source is forwarding messages from Adj-RIB-In, would a BMP
> receiver see all incoming WITHDRAW's & UPDATE's associated with a "flap"
> event, (even though these updates would have been suppressed from further
> re-advertisement after flap dampening is applied)?  How would, or should, a
> BMP receiver know that flap dampening is enabled and/or would be applied?
>    The reason I ask is perhaps this is more a question of the 'authenticity'
> of "monitoring data" at a BMP receiver with respect to formulating what did
> (or could) have happened with a series of Updates being propagated further
> within an AS?  Or, perhaps there's another answer?
>
> -shane
>

---

From: Stephen Stuart <[email-masked]>
Date: Wed, 19 Nov 2008 10:37:00 -0800

> The "L" flag described in section 2.1 conveys that information?

Sorry, I forgot that we took that out.

Stephen

---

From: Geoff Huston <[email-masked]>
Date: Thu, 20 Nov 2008 06:37:58 +1100

While we are on the topic of suggestions from the great unwashed  
masses about this draft, you might also want to consider the  
suggestion that the BGP speaker should sequentially number the BMP  
messages to the BMP client so that if the sender was forced to discard  
msgs because of a broken or stalled TCP connection that caused local  
backlog overflow of to-be-sent messages, then the receiver could at  
least be aware that these was an interruption in the feed of msgs by a  
jump in the sequence number space.

Geoff

On 20/11/2008, at 3:28 AM, Erik Romijn wrote:

>> we've dusted off the draft and modified the mechanism to make it  
> Having been thinking myself about a similar custom system from time  
> to time, this looks very useful to me.
>
> Briefly reading through the draft, I do notice that there is no way  
> to detect the existence of a peer if it sends no prefixes (except  
> when the session goes down).
>
> This should probably not be a common case, but we do see it from  
> time to time. It would be useful for us to be able to have this data.
>
> cheers,
> Erik Romijn
> RIPE NCC RIS

---

From: Geoff Huston <[email-masked]>
Date: Thu, 20 Nov 2008 06:40:48 +1100

On 20/11/2008, at 5:16 AM, Stephen Stuart wrote:
>> time to

having access to a feed of BGP data for research purposes and SNMP  
access to the bgp speaker's MIB are invariably two entirely different  
concepts, unfortunately, so while it may be in the MIB that does not  
mean that a BMP client has a prayer of ever access that mib!

So, yes, it would be useful to have this data inband within the BMP  
feed.

   Geoff

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 19 Nov 2008 13:48:11 -0600

In -01 there's no such thing as discarded messages -- if the  
monitoring station backpressures the BGP speaker, the BGP speaker  
simply stops generating messages until the monitoring station is ready  
to consume more messages.  This was the most important change between  
-00 and -01.

--John

On Nov 19, 2008, at 1:37 PM, Geoff Huston wrote:

> messages to the BMP client so that if the sender was forced to  
> discard msgs because of a broken or stalled TCP connection that  
> caused local backlog overflow of to-be-sent messages, then the  
> receiver could at least be aware that these was an interruption in  
> the feed of msgs by a jump in the sequence number space.
>
> Geoff
>
>
>
>>> so

---

From: Stephen Stuart <[email-masked]>
Date: Wed, 19 Nov 2008 11:51:26 -0800

On Wed, Nov 19, 2008 at 11:40 AM, Geoff Huston <[email-masked]> wrote:
> having access to a feed of BGP data for research purposes and SNMP access to
> the bgp speaker's MIB are invariably two entirely different concepts,

On the other hand, an application built to use a feed of BGP data for
decision support almost certainly has other sources of operational
data, such as BGP MIB data, readily available. At least that's the
case for me.

> unfortunately, so while it may be in the MIB that does not mean that a BMP
> client has a prayer of ever access that mib!
>
> So, yes, it would be useful to have this data inband within the BMP feed.

As noted previously, SR messages can signal the existence of a peer,
and the monitoring application can use that information to determine
that a peer exists which has not supplied updates.

Stephen

---

From: Geoff Huston <[email-masked]>
Date: Thu, 20 Nov 2008 06:54:29 +1100

but form the client's perspective it still looks the same as a  
discarded message - i.e. there is a gap in the data stream

i.e. the client sees a withdraw and then a little later see another  
withdraw with no intervening announcement, for example

with sequencing of messages from the source the gap in the information  
flow is then a little more obvious

geoff

     (who could well be a card carrying member of the Bad Idea  
Department in this case - I dunno! ;-) )

On 20/11/2008, at 6:48 AM, John G. Scudder wrote:

> simply stops generating messages until the monitoring station is  
> ready to consume more messages.  This was the most important change  
> between -00 and -01.
>
> --John
>
>>> Having been thinking myself about a similar custom system from  
>>> time to time, this looks very useful to me.
>>>
>>> Briefly reading through the draft, I do notice that there is no  
>>> way to detect the existence of a peer if it sends no prefixes  
>>> (except when the session goes down).
>>>

---

From: Geoff Huston <[email-masked]>
Date: Thu, 20 Nov 2008 06:58:29 +1100

On 20/11/2008, at 6:51 AM, Stephen Stuart wrote:

>> access to

true, but my comment is motivated by the text in the draft's abstract  
which states:

"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".
And if the intent is to serve the BPG feed leeches (such as myself!)  
then SNMP access is not a given.

geoff

---

From: Stephen Stuart <[email-masked]>
Date: Wed, 19 Nov 2008 12:04:12 -0800

On Wed, Nov 19, 2008 at 11:58 AM, Geoff Huston <[email-masked]> wrote:
> true, but my comment is motivated by the text in the draft's abstract which
> states:
>
> "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".
> And if the intent is to serve the BPG feed leeches (such as myself!) then
> SNMP access is not a given.

Agreed.

Do SR messages suffice? Would you prefer to see some of the
information from the bgpPeerTable replicated in SR messages?
_______________________________________________
GROW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grow

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 19 Nov 2008 15:06:00 -0600

Geoff,

If I've got it straight now, you're saying that you really wish you  
could have the bit-for-bit (or at least update-for-update) property of  
the -00 version of the draft, because you're interested in the fine- 
grained dynamics of the BGP update stream.  But if you can't have that  
(and you can't :-), you'd at least like some hints in that direction.   
Correct?

This seems like a reasonable desire and one can imagine providing a SR  
message with information about the update stream as received from the  
peer (for example).  My caveat is the same as I told Ruediger this  
morning -- that implementability and minimal intrusiveness is of  
paramount importance.

--John

On Nov 19, 2008, at 1:54 PM, Geoff Huston wrote:

> with sequencing of messages from the source the gap in the  
> information flow is then a little more obvious
>
> geoff
>

---

From: Geoff Huston <[email-masked]>
Date: Thu, 20 Nov 2008 08:14:21 +1100

On 20/11/2008, at 8:06 AM, John G. Scudder wrote:

> could have the bit-for-bit (or at least update-for-update) property  
> of the -00 version of the draft, because you're interested in the  
> fine-grained dynamics of the BGP update stream.  But if you can't  
> have that (and you can't :-), you'd at least like some hints in that  
> direction.  Correct?

Yes, that is correct!

>
>
> This seems like a reasonable desire and one can imagine providing a  
> SR message with information about the update stream as received from  
> the peer (for example).  My caveat is the same as I told Ruediger  
> this morning -- that implementability and minimal intrusiveness is  
> of paramount importance.
>

of course, and I appreciate that caveat.

Thanks for your efforts in this work - I for one am very interested in  
this. From a very selfish perspective I have high expectations of its  
utility in my work on BGP dynamics.

   Geoff

>>> ready to consume more messages.  This was the most important  
>>> change between -00 and -01.
>>>
>>> --John
>>>
>>>> suggestion that the BGP speaker should sequentially number the  
>>>> BMP messages to the BMP client so that if the sender was forced  
>>>> to discard msgs because of a broken or stalled TCP connection  
>>>> that caused local backlog overflow of to-be-sent messages, then  
>>>> the receiver could at least be aware that these was an  
>>>> interruption in the feed of msgs by a jump in the sequence number  
>>>> space.
>>>>
>>>> Geoff
>>>>
>>>>
>>>>
>>>>>> we've dusted off the draft and modified the mechanism to make  
>>>>>> it more implementor-friendly.  I'm hoping that the WG would  
>>>>>> still, after the long hiatus, like to adopt the draft.
>>>>>

---

From: "Pedro Torres" <[email-masked]>
Date: Wed, 19 Nov 2008 22:11:01 -0200

I would like too see some information, commonly obtained through
"show bgp summary" in SR messages:
MsgRcvd/MsgSent: useful to find verbose neighbours.
PfxRcd: useful to produce an alarm reaching some threshold
InQ/OutQ: useful to...

--
Pedro

---

From: "Pedro Torres" <[email-masked]>
Date: Wed, 19 Nov 2008 23:30:34 -0200

--
Pedro