> On 12 Jul 2017, at 02:57, Tim Evens (tievens) <tiev...@cisco.com> wrote: > > [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 indeed support this. We should de-couple standardisation, which should take into account the different possibilities (which appear to be on the low numbered side anyways), from implementation, where things will hit platform-specific limits, constraints and caveats (.. and, well, customer demand). Connecting all of this to the ongoing per-peer vs peer-group discussion, i’d say there should not be a “vs” but provision for both alternatives in the draft - then implementors will figure out the specific bits to their platform(s). Why choose upfront and make this one yet another nice effort but with “some limits"? It seems to me we are precisely coming from that and trying to fix it. Paolo _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
