RE: draft-ietf-l3vpn-mpls-vpn-mib drop counter

["Ash, Gerald R \(Jerry\), ALABS" <gash at att.com>]

Bert,
Tom,

> I just want to understand. Tom states:
> > > mplsL3VpnVrfRouteDroppedCounter OBJECT-TYPE
> > >    SYNTAX        Unsigned32
> > >    MAX-ACCESS    read-only
> > >    STATUS        current
> > >    DESCRIPTION
> > >              This counter should be incremented when the number of routes
> > >         contained by the specified VRF exceeds or attempts to exceed
> > >         the maximum allowed value as indicated by
> > >         mplsL3VpnVrfMaxRouteThreshold.
> > 
> > 
> > TOM:	Yes, a simple definition is indeed simple. However, consider
> > 	the implementation both in the device and in the NMS:
> > 
> > 	Device:	Device's code needs to be modified in a number of
> > 		places to accurately count this.  Then the device
> > 		needs to be constantly asked what the status of
> > 		the variable is.
> > 
> > 	NMS:	NMS needs to poll constantly to stay accurate,
> > 		so it needs to be modified.

JERRY: The NMS does *not* need "to poll constantly to stay accurate", it only needs to read the counter periodically (and relatively infrequently) to read the count.  This is not an issue for the operator.

> > 	Consider that a typical PE services on the order of several
> > 	hundred VRFs. That is a lot of polling to do, just for that
> > 	device.  What I am suggesting is that it is more efficient
> > 	for everyone involved to simply let the device tell the NMS
> > 	when its pre-configured threshold for routes exceeded has been
> > 	reached and simply tell it.
> 
> Can you explain what the difference in code is for the device.
> It seems to me that it is as follows:
> 
> - for the "let device tell the NMS"
> 
>     keep an eye on a count and if it exceeds the threshold,
>     send a notification.
> 
> - for the above counter it seems
> 
>     keep an eye on a count and if it exceeds the threshold,
>     increment above counter by 1.
> 
> Or am I still not understanding?

JERRY: The above 2 approaches (notification or counter) don't produce the same result.  Only the counter gives the count needed to meet the requirement.  The notification only gives an indication that the threshold has been exceeded, but not the count, it does *not* satisfy the requirement.  This has also been pointed out by Richard Spencer and by Tom.

> The fact if the counter gets polled many times or how many notifications
> get send is a separate issue and is something that one may want to 
> write some text about, but (to me) seems to have nothing to do with 
> the complexity of supporting the notifications and/or the counter.
> 
> I am not an operator myself, so I am note voicing my support one way
> or the other, but I do want to understand the technical details.

JERRY: Only the counter meets the operator requirement.  Tom asserts that the notification is good enough for the operator, but the operators don't agree.