Jakob, Thanks for raising the logical discussion points. :-)
On Tue, Jul 11, 2017 at 09:52:46PM +0000, 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 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. > 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, ... 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. > 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. 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. That said: > peer-groups will add significant confusion and complexity, especially > when different vendors or even different versions from the same vendor > do different things. 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 _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
