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 protected]> wrote: > > 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. > > >> -----Original Message----- >> From: Tim Evens (tievens) >> Sent: Tuesday, July 11, 2017 6:34 PM >> To: Jakob Heitz (jheitz) <[email protected]>; Jeffrey Haas <[email protected]> >> Cc: [email protected] >> Subject: Re: [GROW] Peer-groups in BMP adj-rib-out (was Re: I-D Action: >> draft-ietf-grow-bmp-adj-rib-out-00.txt) >> >> >> >> 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
