Jeff,
On 7/11/17, 5:20 PM, "GROW on behalf of Jeffrey Haas" <grow-boun...@ietf.org on
behalf of jh...@pfrc.org> 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 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.
[TE] IMO, limitations around transmission of X number of peers with *-rib-*
monitoring should be BMP
sender implementation specific. I do not believe anyone in their right mind
would configure a platform/sender
for *-rib-* on all peers, but you never know. This is why limits should exist,
a line in the sand,
for the platform. Limits that apply to one platform are not necessarily
required to be applied to another.
We want to enable the ability to monitor the five collection points of BGP
(Adj-RIB-In/pre, Adj-RIB-In/post,
Adj-RIB-Out/pre, Adj-RIB-Out/post, and Loc-RIB) but this doesn't mean the
platform can't restrict combinations.
I'm also open to alternative encodings that permit better clustering of the
messages to avoid redundant noise.
[TE] YES, PEER UP INFO "peer/update group" TLV with engineered deployment will
do. I can't imagine any sizable network
that has been configured without design/engineering. I do not believe or
suggest that is different with
BGP monitoring. BGP is big data, like IPFIX in that sense, and therefore
should get some engineering love,
not willy-nilly turn it on everywhere and hope for the best.
--Tim
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
