Re: [lmap] Data type for Option/Value

[Juergen Schoenwaelder <[e-mail]>]

On Fri, Oct 07, 2016 at 08:13:09PM +0000, Ron Stana wrote:
> Juergen,
> 
> The reason we want to pass structured data is because we have tests that define hundreds of network paths, and each network path is defined by a group of parameters.  The example in appendix G is good for defining one network path but does not scale to multiple since it only supports the definition of one src/dest pair.

Ron,

I pointed you to the appendix not because the appendix solves your
problem but instead it shows how a model can augment model specific
parameters into the core LMAP data model. You can make this a list of
list of list if there is a need to do this.
 
> TWAMP is one example of a test that takes multiple network paths.  It has YANG models defined for it: 
> https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-01
> https://tools.ietf.org/html/draft-mirsky-ippm-twamp-light-yang-03
> 
> Which model is used depends on whether the network path requires special setup steps.  A single test could then consist of one or both of these models.
> 
> For these reasons we are using one LMAP id/value option for each of the TWAMP models above.

OK. Anyway, if your test requires complex parameters, one option is to
write a model augmentation to define the structure of the complex
parameters. The other option that you used is to serialize things and
put the result into an option. A third option is to have parameters
that are opaque anydata. All three options have their pros and cons.
If you have alreay TWAMP models, there might be a chance to reuse a
grouping if you were to augment the LMAP YANG model.

> The example in appendix G requires an extension of the LMAP model.  While I can see that it is a nice way of combining the two models, my understanding is LMAP was trying to prevent the need for customer extensions, especially in this situation where two well-known models are used.

There are trade-offs. If you serialize complex structures into string
option values, then any LMAP implementation will be able to move these
options around. Of course, this requires some additional serialization
and non-sense input will likely be detected only at test run-time. If
you augment the model, you of course require implementations to
support the augmentation but then you get the benefit of data
validation etc.

> The Appendix F example seems to define the new objects for use both within action/parameter and action/object.  If that understanding is correct, can you explain the difference between using them in the two places?  I didn't see anything in the information model document (version 11) that explained this.
>

The augmentation only adds something to parameters of an action
object. It is actually missing a second augmentation that is needed in
order to ship the parameters in reports back to the collector.

The information model is silent about this kind of extensibility,
which I think is OK, unless we want to make this a first class
property of the information model itself.

I added parameters essentially as a hook we might use when it turns
out to be needed. (And there should be a second matching hook for the
report model.)

/js

> Ron
> 
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[e-mail]] 
> Sent: Friday, October 07, 2016 2:24 PM
> To: Ron Stana
> Cc: [e-mail]; [e-mail]
> Subject: Re: [lmap] Data type for Option/Value
> 
> On Tue, Sep 27, 2016 at 09:24:34PM +0000, Ron Stana wrote:
> > LMAP Team,
> > 
> > The data type for the option/value in the LMAP YANG model is currently defined as a string.  Our tests use a structured set of input parameters, sometimes mandated by IETF YANG models such as TWAMP and TWAMP Light (see example below) so we currently have to stringify the data which makes it unnecessarily hard to read and requires an extra step before sending and parsing.
> > 
> > "action":[
> > 
> >    {
> > 
> >       "name":"Test-2016-09-27-16:54-action",
> > 
> >       "task":"twamp-initiator",
> > 
> >       "option":[
> > 
> >                  {
> > 
> >                     "id":"twamp-light",
> > 
> >                     "value":"{\"ietf-twamp-light:twamp-light\":{\"twamp-light-session-sender\":{\"sender-light-enable\":true,\"test-session\":[{\"session-id\":1,\"test-session-enable\":true,\"packet-padding-size\":425,\"session-authentication-mode\":\"unauthenticated\",\"interval\":10,\"sender-ip\":\"192.168.2.10\",\"sender-udp-port\":50000,\"reflector-ip\":\"192.168.2.20\",\"reflector-udp-port\":50000,\"dscp\":0},{\"session-id\":2,\"test-session-enable\":true,\"packet-padding-size\":41,\"session-authentication-mode\":\"unauthenticated\",\"interval\":20,\"sender-ip\":\"192.168.2.10\",\"sender-udp-port\":50000,\"reflector-ip\":\"192.168.2.20\",\"reflector-udp-port\":50000,\"dscp\":8}]}}}"
> > 
> >                 }
> > 
> >       ],
> 
> Why do you encode all twamp-light options in a single lmap task option?
> 
> > 
> >       "destination":[
> > 
> >                  "Test-2016-09-27-16:54-results-periodic-pm",
> > 
> >                 "Test-2016-09-27-16:54-results-periodic-rt"
> > 
> >       ]
> > 
> >    }
> > 
> > ]
> > 
> > 
> > 
> > Can the value object be changed in the LMAP YANG model so that it can contain another object (i.e. YANG's anyxml object type)?
> >
> 
> Please take a look at appendix G of draft-ietf-lmap-yang-05.txt for a possible way to do this if plain name/value pairs are not good enough.
> Using anydata makes the data really opaque. But the most important aspect, I think, is that LMAP YANG module provides the proper hooks to enable future extensions (via the parameters container).
> 
> /js
> 
> PS: Note that options are automatically submitted with result reports;
>     we should make sure that added structured parameters are also
>     contained in result reports (anydata may work generically here
>     since the format is implicitely defined).
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>