Here are some more factors that cause different updates to peers in the same peer-group: - RT Constraint: This filters different updates from different peers. - Refresh requests: Only the peer that sent the request receives the updates. - Nexthop SAFI (future).
IMO, the point of BMP is to take the guess work out of figuring out what was sent. Peer-groups will add more guess work. Thanks, Jakob. > -----Original Message----- > From: GROW [mailto:[email protected]] On Behalf Of Jeffrey Haas > Sent: Wednesday, July 12, 2017 8:14 AM > To: Tim Evens (tievens) <[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) > > Tim, > > On Wed, Jul 12, 2017 at 12:28:55AM +0000, Tim Evens (tievens) wrote: > > 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 folks will > > do or what I would > > recommend doing. I believe this can be addressed by adding "Other > > Considerations" section to > > explain how one should go about using adj-rib-out. For example, in the > > use-case of monitoring > > peer-group egress policy advertisements, which is what I believe you are > > addressing with your > > comment, the operator should configure at least two reliable peers in a > > group > > to be monitored. This provides redundancy should one peer fail. > > I had considered this as one of the possibilities. However, if the actual > use case is to simply see what's sent to the group, why not simply get rid > of the per-peer need in the first place? This avoids the somewhat hack of > "picking reliable peers". > > > This would easily provide peer-group > > level conveyance of the egress policy. What's missing is the peer-group > > name so that on > > the receiving side we can correlate (group) the peers that represent the > > same peer-group. > > Providing we have the group name for the peer, the receiver can group the > > peers that have the same > > group name. If the use-case is only to monitor the peer-group policy, not > > specific overrides per peer, > > then the receiver can easily de-dup the X (redundant) peers for a single > > representation of the peer-group. > > This potentially gets to one of the case Jakob had mentioned wherein > something might be part of a peer group, but may have radically different > "per peer" behavior in some implementations. By comparison, Junos does only > minor alterations per-peer outside of the high level export policy. > > If we consider two group cases: Pure group, some per-peer, then we have two > possible ways of handling this as part of wire encoding: > 1. Emit only per-group RM messages > 2. If there's per-peer variance of sufficient interest, emit peer specific > RM messages. > > > This is use-case specific as there are use-cases where we need to still > > monitor each peer even if they are > > part of the same peer/update group. > > > > In either case, this is really a receiver knob to correlate based > > on intended operator configuration/deployment. Although we do need the > > peer-group advertised as part > > of the PEER INFO TLV, which we talked about at the BoF. This was meant to > > be added, but I forgot to > > add that. > > Thanks. Since I wans't able to attend the full BoF, I don't recall if this > had been part of the disucssion. > > > Based on your proposal statements, it seems that this is only a method to > > correlate/map peers, > > peers that still need PEER_UP/per-peer RM messages, into a group. > > Largely correct. Although I think you've made a good argument that a > simpler way of providing the group mapping is to simply put it into the > information message as part of the peer-up message. > > > IMO, this complicates > > both the implementation (router/sender) and the receiver unnecessarily > > considering we can accommodate > > this with a simple PEER_UP INFO TLV. RFC7854 doesn't include any info TLV's > > for PEER_UP, but we do introduce them in draft-ietf-grow-bmp-loc-rib. By > > adding > > a PEER_UP info TLV to convey peer/update group name enables the receiver to > > easily correlate > > peers that belong to the same group. > > I'd find that a reasonable mapping mechanism. > > > How we treat and understand those peers is very much specific to the > > operator configuration/deployment/implementation on the receiver side. > > The operator can > > decide if they just need one peer per peer-group or if they want fault > > tolerance by including more peers. > > I disagree with this case for the reasoning above. I think if the per-peer > case was kept as the per-group monitoring mechanism, it'd eventually > degenerate down to the "fake peer" case that is always up. Such a hack > could easily be done today but is clumsy for operators to analyze since > they'd have to track that said "fake peer" is in fact not real. > (E.g. use a class E address.) > > -- Jeff > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
