On 7/11/17, 6:03 PM, "Jakob Heitz (jheitz)" <[email protected]> wrote:
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.
[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.
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
