[j-nsp] Publish API data over SNMP

[Saku Ytti]

On 8 March 2018 at 22:43, Phil Shafer <phil at juniper.net> wrote:

> Unfortunately not, since MIBs use numeric identifier for fields,
> so if a developer inserts "leaf foxtrot" between "leaf echo" and
> "leaf geronimo" (where it really belongs) then the MIB ordering has
> changed and the numbers and all off.  The MIB generator would need
> the numbers from the previous release to generate useful numbers.

To me it seems like you'd need three OID levels, one for key=>value,
one for key's depth and one for key's position. Even though position
changes, the original key=>value stays same. The position isn't
relevant for SNMP consumer, but important if you want to map it back.

I see no reason why arbitrary JSON couldn't be machine translated to
SNMP and, crucially, back.

ASN.1 <-> XML/JSON probably is solved problem.

> The XML content is generated by the component, so the "show route"
> is forwarded to RPD, who emits the XML response.  MGD forwards that
> to the API client or to the CLI, who turns it into text.  The JSON
> generation (and the "format='text'") is done as a "filter" (in the
> unix sense of the word) to the output stream coming back to the API
> client.

This is all quite beautiful, to have single source of truth. Unlike C
(not dishing on them, every vendor has high points and low points)
where they need to write programmatic presentation support
individually for every thing, which will never work, it has to be
guaranteed 100% coverage or it's useless.
I think exactly because of this infrastructure that you (and NOK) have
in place, adding new ways to emit data, JSON or SNMP, is rather cheap
proposal.

And in context of SNMP, who hasn't found themselves wanting to have
this and that CLI counter in SNMP, this would be one-off work, which
would pay dividends continuously. And strong marketing message, if you
can see it on CLI, you can poll it on your NMS. Compared how much
ad-hoc work have already been spent adding OIDs customers requests.

> Well, if this is a "one off", we have two potential solutions.  First
> is the utility MIB, which holds simple name/value pairs, with the name
> being the key.  An intermittent event script can record a value into
> the utility mib and an SNMP client can retrieve it.  More info is at:

Thank you for the proposals, but certainly this isn't first OID I've
found missing nor last. And these proposed solutions don't contribute
well towards reducing work. With guaranteed CLI counter in SNMP OID
people can ship more turn-key NMS packages to Juniper users.

> My concern was with ensuring that a PDU containing requests for the
> value of "foxtrot" and "geronimo" get these values from the same
> RPC output, instead of issuing the RPC twice, which makes more work
> and my give inconsistent results.  Sorry if my previous explanation
> (and perhaps this one as well ;^) wasn't clear.

Aah yes, I got it now. Implication is, either SNMP is potentially
costly proposal if you walk say fabric statistics, and for each time
you ask for value, it executes RPC. Or another solution is that it's
stateful or at least caching, increasing complexity and bug surface.

-- 
  ++ytti