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 message actually gets to the peer: It could go down; it could leave the peer-group, ...
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. peer-groups will add significant confusion and complexity, especially when different vendors or even different versions from the same vendor do different things. Thanks, Jakob. > -----Original Message----- > From: GROW [mailto:[email protected]] On Behalf Of Gert Doering > Sent: Tuesday, July 11, 2017 1:55 AM > To: 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) > > 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 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. > > "per peer group" would actually match our use-case for rib-out much > better than "per individual peer". So, support for that idea. > > On the actual implementation, I abstain, as I haven't read up on the > technical details enough to make a qualified comment. > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
