Re: [Dots] Telemetry draft: Vendor Specific data reduction

[Jon Shallow <[e-mail]>]

Hi All,

 

Any thoughts on this data reduction?

 

While it is possible for a Vendor to come up with their own augmented YANG
to cover their vendor specifics, it gets problematic when 2 or more Vendor
specifics need to be understood by a client or a server.

 

Having a "/vendor-mapping" operation path means that vendor mapping of
"attack-id" and "attack-name" can easily be exchanged.

 

If "attack-id" is an integer instead of a string, then "attack-id" could
become a Vendor specific set of enums (they do not need to start from 1)
based on "id".

 

Regards

 

Jon

 

From: Dots [mailto: [e-mail]] On Behalf Of Jon Shallow
Sent: 23 April 2020 10:49
To: [e-mail]
Subject: [Dots] Telemetry draft: Vendor Specific data reduction

 

Hi All,

 

When passing telemetry attack information back and forth, there are some
ways that we need to consider on data reduction, thus reducing the
likelihood of having to do Block transfers.

 

My understanding is that there is a one-to-one relationship between
"attack-id" and "attack-name".

 

My first suggestion is that the client is able to upload to a server, and
the server can download on request, a vendor's mapping of "attack-id" to
"attack-name" for the specific vendor "id".  Then, whenever there is
telemetry information "id" + "attack-id" need to be provided, but much space
can be saved by not having to also include "attack-name".

 

Second suggestion is that "attack-id" is an integer instead of a string to
again save on space in the telemetry data.

 

Regards

 

Jon