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" <grow-boun...@ietf.org on
behalf of jh...@pfrc.org> wrote:
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, internet-dra...@ietf.org 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.
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
