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

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

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

Hi, On Mon, Jul 10, 2017 at 05:15:09PM -0400, Jeffrey Haas wrote: > 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

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

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)

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

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

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

Jeff, On 7/11/17, 5:20 PM, "GROW on behalf of Jeffrey Haas" 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

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

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. > -Original Message- >

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)" 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

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

Jakob, Thanks for raising the logical discussion points. :-) On Tue, Jul 11, 2017 at 09:52:46PM +, Jakob Heitz (jheitz) wrote: > 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

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

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