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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
