Subject: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)

From: Jeffrey Haas <[email-masked]>
Date: Mon, 10 Jul 2017 17:15:09 -0400

Authors,

We briefly discussed this during the bar BoF for BMP last IETF.  My
apologies for not presenting text before this point.

While there are use cases where an end-user may want per-peer rib-out state,
some applications may not quite that level of granularity of information.
In many cases, it is sufficient to know what route will be sent to the peers
that belong to the BGP's peer-group/update-group.  (I'll be using peer-group
for the remainder of this e-mail.)

In such cases, the adj-rib-out in its current form can be quite noisy.  It
effectively can turn the BMP feed into trying to squeeze the entire firehose
of BGP traffic through the straw of a single session.

I'd offer the following proposal for per-group BMP rib-out:

The Per-Peer BMP header (RFC 7854, section 4.2) gets a new "peer-type" of
"Rib-Out Group" (value TBD).

For this new value, the Peer Distinguisher is set to a system-wide group-ID.
The Peer-Address, Peer AS and Peer BGP ID is zero-filled.  The group-ID is
sufficient to determine the contents of the BGP data sent to the peer-group.

A new message is allocated, called "BGP Rib-Out Groups".
Its contents are:

Flags (1 byte), a Delete flag is specified.
Group-Id (8 bytes)
Group-Name Length (1 byte)
Group-Name A UTF-8 string of up to 255 bytes representing the group name.
Number of Peers (2 bytes)
Peer-List Section: (for each peer)
  Peer Type (1 byte)
  Peer Flags (1 byte)
  Peer Distinguisher (8 bytes)
  Peer Address (16 bytes)
  Peer AS (4 bytes)
  Peer BGP ID (4 bytes)

The peer-list section is filled as per RFC 7854, section 4.2.

The BGP Rib-Out Groups message should be sent prior to sending Route
Monitoring or Route  Mirroring messages.  However, the application should be
prepared to receive such messages without the group mapping.

A group mapping by ID may be updated by sending a replacement with the same
Group Id.

A group mapping may be deleted by sending a truncated message containing
only the flags with the delete bit set and the Group-Id.

---

The contents above are missing some finer points, such as V and A flags and
the O flag from the base bmp-adj-rib-out spec.  However, this should serve
as a coarse proposal.

-- Jeff

On Wed, Jun 21, 2017 at 12:08:17PM -0700, [email-masked] wrote:
> Abstract:
>    The BGP Monitoring Protocol (BMP) defines access to only the Adj-RIB-
>    In Routing Information Bases (RIBs).  This document updates the BGP
>    Monitoring Protocol (BMP) RFC 7854 by adding access to the Adj-RIB-
>    Out RIBs.  It adds a new flag to the peer header to distinguish Adj-
>    RIB-In and Adj-RIB-Out.

---

From: Gert Doering <[email-masked]>
Date: Tue, 11 Jul 2017 10:54:50 +0200

Hi,

> of BGP traffic through the straw of a single session.

"per peer group" would actually match our use-case for rib-out much
better than "per individual peer".  So, support for that idea.

On the actual implementation, I abstain, as I haven't read up on the
technical details enough to make a qualified comment.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 11 Jul 2017 21:52:46 +0000

The message sent to a peer group is not always the same as what's
sent to the peer.
Some fields are rewritten at the io-write stage. Nexthop is common.
When it's written to the peer-group, it is not yet written to the peer.
If there is a slow peer in the group, anything could happen before the
message actually gets to the peer: It could go down; it could leave the
peer-group, ...

Some vendors (eg. IOS-XR) have several types of peer grouping.
There are a number of ways to group configurations.
In addition, the peers are automatically grouped into update groups such that
each member gets (mostly) the same update message.

peer-groups will add significant confusion and complexity, especially
when different vendors or even different versions from the same vendor
do different things.

Thanks,
Jakob.

> -----Original Message-----
> From: GROW [mailto:[email-masked]] On Behalf Of Gert Doering
> Sent: Tuesday, July 11, 2017 1:55 AM
> To: Jeffrey Haas <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: draft-ietf-grow-bmp-adj-rib-out-00.txt)
> 
> Hi,
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 11 Jul 2017 20:20:04 -0400

Jakob,

Thanks for raising the logical discussion points. :-)

> When it's written to the peer-group, it is not yet written to the peer.

That's absolutely true.  You give the example of nexthop.  My employer's
implementation also may do AS-substitution for prepending, insertion of
communities for things like LLGR, etc.

In such cases, it's not possible to get exactly what is sent out to a given
peer.

> message actually gets to the peer: It could go down; it could leave the

This is potentially a problem in the BMP architecture anyway.  There's no
guarantee that the BMP messaging is in sync with BGP, including potential
state compression.  The same is true for mirroring since  it'd imply
infinite buffering which is not feasible.

> each member gets (mostly) the same update message.

In cases where peers are fully dynamically grouped rather than clustered in
a way that is mostly static, my proposal wouldn't be terribly helpful.

> when different vendors or even different versions from the same vendor

In such cases - use the per peer rib-out.  I do believe it has good use
cases.  However, discussions with our customers have suggested that in most
cases it's excessively chatty and threatens to swamp the rib-in portion of
the control channel they're actually interested in.  For them, a general
indication of rib-out content is sufficient, even when there's some minor
variations with specifications they may be comfortable with.

I'm also open to alternative encodings that permit better clustering of the
messages to avoid redundant noise.

-- Jeff

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Wed, 12 Jul 2017 00:28:55 +0000

The use-case to monitor Adj-RIB-Out for a peer-group is definitely something this draft
addresses but appears to need more clarification. 

Noisy and likely duplicate/wasteful, yes… if one configures every peer to send Adj-RIB-Out
for peers that convey the same data, to which is likely not what folks will do or what I would
recommend doing.  I believe this can be addressed by adding "Other Considerations" section to
explain how one should go about using adj-rib-out.  For example, in the use-case of monitoring
peer-group egress policy advertisements, which is what I believe you are addressing with your
comment, the operator should configure at least two reliable peers in a group
to be monitored. This provides redundancy should one peer fail. This would easily provide peer-group
level conveyance of the egress policy. What's missing is the peer-group name so that on
the receiving side we can correlate (group) the peers that represent the same peer-group. 
Providing we have the group name for the peer, the receiver can group the peers that have the same
group name.  If the use-case is only to monitor the peer-group policy, not specific overrides per peer,
then the receiver can easily de-dup the X (redundant) peers for a single representation of the peer-group.

This is use-case specific as there are use-cases where we need to still monitor each peer even if they are 
part of the same peer/update group.  

In either case, this is really a receiver knob to correlate based
on intended operator configuration/deployment.  Although we do need the peer-group advertised as part
of the PEER INFO TLV, which we talked about at the BoF.  This was meant to be added, but I forgot to
add that.

Based on your proposal statements, it seems that this is only a method to correlate/map peers, 
peers that still need PEER_UP/per-peer RM messages, into a group. IMO, this complicates 
both the implementation (router/sender) and the receiver unnecessarily considering we can accommodate
this with a simple PEER_UP INFO TLV. RFC7854 doesn't include any info TLV's
for PEER_UP, but we do introduce them in draft-ietf-grow-bmp-loc-rib.   By adding
a PEER_UP info TLV to convey peer/update group name enables the receiver to easily correlate
peers that belong to the same group.  How we treat and understand those peers is very much specific to the 
operator configuration/deployment/implementation on the receiver side.   The operator can
decide if they just need one peer per peer-group or if they want fault tolerance by including more peers.
This allows both the peer-group monitoring as well as the cases where an operator needs
to monitor each individual peer within a peer group or otherwise. 

Thanks,
Tim

On 7/10/17, 2:15 PM, "GROW on behalf of Jeffrey Haas" <[email-masked] on behalf of [email-masked]> wrote:

    Authors,

    

    

    

    
    
    ---

    -- Jeff

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Wed, 12 Jul 2017 00:57:31 +0000

Jeff,

On 7/11/17, 5:20 PM, "GROW on behalf of Jeffrey Haas" <[email-masked] on behalf of [email-masked]> wrote:

[TE] IMO, limitations around transmission of X number of peers with *-rib-* monitoring should be BMP
 sender implementation specific.  I do not believe anyone in their right mind would configure a platform/sender
for *-rib-* on all peers, but you never know. This is why limits should exist, a line in the sand,
for the platform.   Limits that apply to one platform are not necessarily required to be applied to another.
We want to enable the ability to monitor the five collection points of BGP (Adj-RIB-In/pre, Adj-RIB-In/post,
Adj-RIB-Out/pre, Adj-RIB-Out/post, and Loc-RIB) but this doesn't mean the platform can't restrict combinations.

[TE] YES, PEER UP INFO "peer/update group" TLV with engineered deployment will do.  I can't imagine any sizable network
that has been configured without design/engineering.  I do not believe or suggest that is different with
BGP monitoring.  BGP is big data, like IPFIX in that sense, and therefore should get some engineering love, 
not willy-nilly turn it on everywhere and hope for the best. 

--Tim

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 12 Jul 2017 01:03:52 +0000

How about some compression, like run-length-encoding instead of peer groups to reduce the firehose?
A bunch of peers being sent nearly the same updates should compress very nicely
and you wouldn't get all the confusion that comes with peer-groups.

Thanks,
Jakob.

> From: Tim Evens (tievens)
> Sent: Tuesday, July 11, 2017 5:58 PM
> To: Jeffrey Haas <[email-masked]>; Jakob Heitz (jheitz) <[email-masked]>
> Cc: [email-masked]

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Wed, 12 Jul 2017 01:34:29 +0000

On 7/11/17, 6:03 PM, "Jakob Heitz (jheitz)" <[email-masked]> wrote:

[TE] This is reasonable and per RFC78564 Route-monitoring is state compressed.  Adj-RIB-Out follows that
and supports both route-mirroring and route-monitoring.  The interval/throttle used for the state-compression
should be platform specific, but it should be documented so that we know the granularity to expect.  
State-compression should help reduce the number of updates but monitoring 100 peers that belong to the
same update/peer group will likely be wasteful as there will be a lot of duplication.  In this case, 
I go back to needing some engineering love.  

IMO, it does not make sense to monitor all of those peers if they in fact are conveying the identical advertisements.   In either case, we need that peer group name in the PEER UP so that we can correlate the peers to groups for proper de-duplication. Unless we are monitoring for software bugs, the engineering team/operators know which peers should be monitored in order to get a proper group representation based on egress/export policies. Although, this does put a bit of a burden on engineering deployment. 

To address the engineering deployment use-case of monitoring only the peer-group (export policy), it would be nice to ease the monitoring configuration with the ability on the router to dynamic select the peer to be monitored.  For instance, under the peer-group configuration for BMP monitoring, enable "adj-rib-out best 2".  The router then would select the best 2 peers that represent the peer-group advertisements. This can change over time as peers are added, removed, or experience stability issues.  In terms of BMP, normal PEER_UP/PEER_DOWN with INFO TLV's would be used so that the receiving system can easily correlate and de-dup as needed by peer-group.  If the doing peer-group monitoring, the peer itself wouldn't matter as much. 

Peer group (including template) monitoring is not limited to Adj-RIB-Out.  The same use-case for monitoring the peer-group for export policy can be said for Adj-RIB-In as well.   The same engineering/deployment configuration of which peer is to be monitored for the peer-group name can be used for Adj-RIB-In as well. Easing this configuration for groups is beneficial.

BTW… we absolutely need the OPEN message to convey the capabilities.  This is required to correctly parse the NRLI's and attributes.  

    Thanks,
    Jakob.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 12 Jul 2017 01:41:28 +0000

I said run-length-encoding.
That's data compression, not state compression.
The peers in a peer-group do not always get exactly the same updates.

Thanks,
Jakob.

> Sent: Tuesday, July 11, 2017 6:34 PM
> To: Jakob Heitz (jheitz) <[email-masked]>; Jeffrey Haas <[email-masked]>
> Cc: [email-masked]
> IMO, it does not make sense to monitor all of those peers if they in fact are conveying the identical advertisements.
> In either case, we need that peer group name in the PEER UP so that we can correlate the peers to groups for proper
> de-duplication. Unless we are monitoring for software bugs, the engineering team/operators know which peers should
> be monitored in order to get a proper group representation based on egress/export policies. Although, this does put
> a bit of a burden on engineering deployment.
> 
> To address the engineering deployment use-case of monitoring only the peer-group (export policy), it would be nice
> to ease the monitoring configuration with the ability on the router to dynamic select the peer to be monitored.  For
> instance, under the peer-group configuration for BMP monitoring, enable "adj-rib-out best 2".  The router then would
> select the best 2 peers that represent the peer-group advertisements. This can change over time as peers are added,
> removed, or experience stability issues.  In terms of BMP, normal PEER_UP/PEER_DOWN with INFO TLV's would be used so
> that the receiving system can easily correlate and de-dup as needed by peer-group.  If the doing peer-group
> monitoring, the peer itself wouldn't matter as much.
> 
> Peer group (including template) monitoring is not limited to Adj-RIB-Out.  The same use-case for monitoring the
> peer-group for export policy can be said for Adj-RIB-In as well.   The same engineering/deployment configuration of
> which peer is to be monitored for the peer-group name can be used for Adj-RIB-In as well. Easing this configuration
> for groups is beneficial.
>

---

From: "Tim Evens (tievens)" <[email-masked]>
Date: Wed, 12 Jul 2017 02:48:37 +0000

Sorry, I jumped to state compression since that would reduce the repeats even if they aren't the same in terms of attributes.

I completely agree that peer group is not always the same.  Hence we need the protocol to not limit what can be exported.

> On Jul 11, 2017, at 6:41 PM, Jakob Heitz (jheitz) <[email-masked]> wrote:
>

---

From: Job Snijders <[email-masked]>
Date: Wed, 12 Jul 2017 10:14:57 +0200

On Wed, Jul 12, 2017 at 12:57:31AM +0000, Tim Evens (tievens) wrote:
> > In such cases - use the per peer rib-out.  I do believe it has good
> > use cases.  However, discussions with our customers have suggested
> > that in most cases it's excessively chatty and threatens to swamp
> > the rib-in portion of the control channel they're actually
> > interested in.  For them, a general indication of rib-out content is
> > sufficient, even when there's some minor variations with
> > specifications they may be comfortable with.
> > 
> [TE] IMO, limitations around transmission of X number of peers with
> *-rib-* monitoring should be BMP sender implementation specific.  I do
> not believe anyone in their right mind would configure a
> platform/sender for *-rib-* on all peers, but you never know.

I wouldn't be so quick to dismiss that from happening, nor frown upon
it. It actually might be one of the first things I'd do when debugging
an issue. And since quite some debugging is 'after the fact', it makes
sense to permanently monitor at least Adj-RIB-In and Adj-RIB-Out for
each peer.

> BGP is big data, like IPFIX in that sense, and therefore should get
> some engineering love, not willy-nilly turn it on everywhere and hope
> for the best. 

I agree with you that BGP might be 'a lot of data' but storage space is
cheap, so if the edge routers can send it I'll store it and keep it. I'm
tired of flying blind. Also, I am not sure how I can select up front
what BGP data I will keep, aggregate or throw away. To do proper triage
on BGP hijacks we'll need per-prefix per-update granularity.

Kind regards,

Job

---

From: Paolo Lucente <[email-masked]>
Date: Wed, 12 Jul 2017 12:46:41 +0200

> On 12 Jul 2017, at 02:57, Tim Evens (tievens) <[email-masked]> wrote:
> 

I indeed support this. We should de-couple standardisation, which should take into account the different possibilities (which appear to be on the low numbered side anyways), from implementation, where things will hit platform-specific limits, constraints and caveats (.. and, well, customer demand). Connecting all of this to the ongoing per-peer vs peer-group discussion, i’d say there should not be a “vs” but provision for both alternatives in the draft - then implementors will figure out the specific bits to their platform(s). Why choose upfront and make this one yet another nice effort but with “some limits"? It seems to me we are precisely coming from that and trying to fix it.

Paolo

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Jul 2017 11:14:22 -0400

Tim,

On Wed, Jul 12, 2017 at 12:28:55AM +0000, Tim Evens (tievens) wrote:
> to be monitored. This provides redundancy should one peer fail.

I had considered this as one of the possibilities.  However, if the actual
use case is to simply see what's sent to the group, why not simply get rid
of the per-peer need in the first place?  This avoids the somewhat hack of
"picking reliable peers".

> This would easily provide peer-group

This potentially gets to one of the case Jakob had mentioned wherein
something might be part of a peer group, but may have radically different
"per peer" behavior in some implementations.  By comparison, Junos does only
minor alterations per-peer outside of the high level export policy.

If we consider two group cases: Pure group, some per-peer, then we have two
possible ways of handling this as part of wire encoding:
1. Emit only per-group RM messages
2. If there's per-peer variance of sufficient interest, emit peer specific
   RM messages.

> of the PEER INFO TLV, which we talked about at the BoF.  This was meant to be added, but I forgot to

Thanks. Since I wans't able to attend the full BoF, I don't recall if this
had been part of the disucssion.

> peers that still need PEER_UP/per-peer RM messages, into a group.

Largely correct.  Although I think you've made a good argument that a
simpler way of providing the group mapping is to simply put it into the
information message as part of the peer-up message.

>  IMO, this complicates 
> peers that belong to the same group.

I'd find that a reasonable mapping mechanism.

>  How we treat and understand those peers is very much specific to the 

I disagree with this case for the reasoning above.  I think if the per-peer
case was kept as the per-group monitoring mechanism, it'd eventually
degenerate down to the "fake peer" case that is always up.  Such a hack
could easily be done today but is clumsy for operators to analyze since
they'd have to track that said "fake peer" is in fact not real.
(E.g. use a class E address.)

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Jul 2017 11:19:15 -0400

Tim,

> Adj-RIB-Out/pre, Adj-RIB-Out/post, and Loc-RIB) but this doesn't mean the platform can't restrict combinations.

As I already noted, I'm perfectly fine with the existing rib-out encoding.
I simply believe that the per-group encoding offers flexibility to remove
noise from BMP feeds for some of the same use cases.

In particular, it avoids de-duping needs for operators in many scenarios.

I find this less a matter of limits and more a matter of simple BGP
procedure.  A single update learned on one feed will usually result in
multiple advertisements.  Even with peer-group grouping, the fan out is
often significantly higher.  Given this, a mechanism to reduce information,
where appropriate, seems reasonable.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Jul 2017 11:20:41 -0400

> and you wouldn't get all the confusion that comes with peer-groups.

I believe it's the redundant updates in the per-peer feed that is the
consideration rather than strictly the data.  I.e. it's a matter of RM
messages not bps.

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 12 Jul 2017 22:48:28 +0000

Here are some more factors that cause different updates to peers in the same peer-group:
 - RT Constraint: This filters different updates from different peers.
 - Refresh requests: Only the peer that sent the request receives the updates.
 - Nexthop SAFI (future).

IMO, the point of BMP is to take the guess work out of figuring out what was sent.
Peer-groups will add more guess work.

Thanks,
Jakob.

> From: GROW [mailto:[email-masked]] On Behalf Of Jeffrey Haas
> Sent: Wednesday, July 12, 2017 8:14 AM
> To: Tim Evens (tievens) <[email-masked]>
> Cc: [email-masked]

---

From: Gert Doering <[email-masked]>
Date: Thu, 13 Jul 2017 10:02:04 +0200

Hi,

On Wed, Jul 12, 2017 at 12:28:55AM +0000, Tim Evens (tievens) wrote:
> Noisy and likely duplicate/wasteful, yes??? if one configures every peer to send Adj-RIB-Out
> recommend doing.  

The use case I have is "I want to see how routes from customer <x> end
up being sent to DECIX" - which technically is a peer-group with 100+
peers in.

Monitoring a given peer is not really useful here (that peer could be 
down) - monitoring *all* peers will give way more data than I want (I can
collapse it again afterwards, but why eat up CPU etc. for no benefit).

So "peer group" is exactly matching my use case.

Gert Doering
        -- NetMaster

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Jul 2017 07:01:02 -0400

Jakob,

>  - Refresh requests: Only the peer that sent the request receives the updates.

You missed simple BGP loop detection such as RRs with cluster list or
originator ID suppression for iBGP or AS_PATH for eBGP.

> Peer-groups will add more guess work.

Much of my point is that even without complicated features, if you care
about per-peer state, you have to monitor *ALL* of the peers.  Otherwise,
you're going to miss things.  There's no "monitor one or two sample peers".  

You either care about the approximate state of the peers in the group or you
care about the exact state.  The use cases are different.

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 13 Jul 2017 13:27:38 +0000

What is this "approximate state"?
Why does a sample peer not give you approximate state?
Why does loc-rib not give you approximate state?

Thanks,
Jakob.

> On Jul 13, 2017, at 3:51 AM, Jeffrey Haas <[email-masked]> wrote:
> 
> Jakob,
>

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Jul 2017 11:31:33 -0400

> Why does a sample peer not give you approximate state?

You just gave multiple examples of when the peer might not be good enough.
I'm unclear why you're asking the question.

Simple examples:
Basic ibgp, no policy.  Monitoring the rib-out per group is likely good
enough.  Same for reflection.  Likely the same for ebgp confederation peer.

Basic ibgp for L3VPN.  Monitoring the rib-out per group is probably good
enough, even with rt-constrain.  Can you tell which peers got the update or
not?  Not with the encoding discussed.  But you can tell what the state
advertised is.  But in such cases you're really better off looking at rib-in
state on the receiver anyway.

For ebgp in the same peer group?  Possibly good enough as long as you don't
care about the per-nexthop or potentially community changes.  If the ebgp
peers are also yours to monitor, the rib-in is sufficient.  If they're not,
then go per-peer.

> Why does loc-rib not give you approximate state?

Because it doesn't give you the results of export policy on your peer group?
(Otherwise we wouldn't be discussing a rib-out feature...)

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 13 Jul 2017 16:57:46 +0000

The problem with peer-groups is that today's high end routers
don't generate updates to peer-groups.
Peer-groups are only a convenience for configuration.
High end routers group peers automatically into update groups
and generate updates to the update group.
Even update groups have sub divisions to which the generated updates
may or may not be copied to.
This is done for efficient update generation with thousands of peers.

Thanks,
Jakob.

> Sent: Thursday, July 13, 2017 1:02 AM

---

From: Gert Doering <[email-masked]>
Date: Thu, 13 Jul 2017 19:06:15 +0200

Hi,

> This is done for efficient update generation with thousands of peers.

Which is an implementation detail, really.

If I configure 100 neighbours and one BMP exporter to be in "the same
peer-group" (with the same export policy), I expect them to see the same 
prefixes, in general - except for those that are down, slow, and what
other per-peer things might happen that shoves one of them into a different
update groups.

If they have different export policies, I might want one "BMP exporter" per
export policy - or inheritance group, or neighbour-group, or whatever.

("100" is not an arbitrarily high number, it might actually be low, when
talking about peers at major IXPs, that - with a few exceptions - all 
have the same export policy today, namely "our customer cone, except if
the no-export-to-IXP community is set, prepend if prepend-to-IXP community
is set")

Gert Doering
        -- NetMaster

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 13 Jul 2017 20:43:27 +0000

That will certainly be the case most of the time.
However, the time when you really want to know will
invariably be the time when a peer did not get exactly what the rest
of the peer group got.
That's when the hurt starts and the standard vendor answer will be:
peer-groups are purely a configuration convenience.
"that's probably what was sent" doesn't cut it in troubleshooting.

Thanks,
Jakob.

> From: Gert Doering [mailto:[email-masked]]
> Sent: Thursday, July 13, 2017 10:06 AM
> To: Jakob Heitz (jheitz) <[email-masked]>
> Cc: Gert Doering <[email-masked]>; Tim Evens (tievens) <[email-masked]>; [email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Jul 2017 22:13:14 -0400

> and generate updates to the update group.

I did note potential distinctions in implementations when I kicked off this
mail chain. :-)

By direct comparison in Junos, peers A, B and C may be part of the same
configured group, but may be split into distinct groups if they don't share
policy.  Thus, in our implementation, they're report those distinct
mappings.  In our case, distinct group IDs sharing the same group name.

Whether this is applicable for your implementation is unclear.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Jul 2017 22:15:39 -0400

> invariably be the time when a peer did not get exactly what the rest

Two observations:
- This argument eventually degenerates into "you need to monitor the rib-out
  of every single peer".
- Due to state compression of the BMP feed vs. the BGP feed, you're going to
  lose stuff anyway.

I believe anyone expecting *any* implementation of BMP for rib-out to be a
perfectly stateful match for their announced BGP has unrealistic
expectations.

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 14 Jul 2017 02:11:14 +0000

Then the same is true for RIB-in.
Since every RIB-out matches a RIB-in somewhere else,
the input must equal the output in the aggregate.
Unless BGP leaks... :)

Thanks,
Jakob.

> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Thursday, July 13, 2017 7:16 PM
> Cc: Gert Doering <[email-masked]>; [email-masked]