Subject: [ippm] TWAMP Data Model updated: draft-cmzrjp-ippm-twamp-yang-01

From: Kostas Pentikousis <[email-masked]>
Date: Fri, 3 Jul 2015 18:31:53 +0200

Dear all,

We have updated the TWAMP data model draft which in now available at https://datatracker.ietf.org/doc/draft-cmzrjp-ippm-twamp-yang/.

We would like to thank all those who have provided comments and in particular Greg, Kevin and Robert: All of your suggestions have been taken into consideration in this revision.

We will come back to you right after the IETF cut-off on Monday with detailed answers to your emails sent earlier on the list. Sincere apologies for the delay!

Best regards,

Kostas (on behalf of the authors)

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 14 Jul 2015 05:40:13 -0400

> -----Original Message-----
> From: Kostas Pentikousis [mailto:[email-masked]]
...
> 
> We have updated the TWAMP data model draft which in now available at
> https://datatracker.ietf.org/doc/draft-cmzrjp-ippm-twamp-yang/.
> 
> We would like to thank all those who have provided comments and in
> particular Greg, Kevin and Robert: All of your suggestions have been
> taken into consideration in this revision.
> 
[ACM] 
Thanks for your comments, Kevin, and for permission to 
post the response to the list.  See below.

regards,
Al (for the co-authors)

[reply] as of June 25, where almost all replies have been executed in 01,
and any remaining in next 02 to be published soon.

Comments/Questions from Kevin D'Souza
As we discussed, here is a list of comments/questions I had on the latest TWAMP draft.

1.      should the maintenance statistics parameters be uint64 size? Or are these expected to not grow beyond a uint32?

[reply]
TWAMP Sequence numbers cannot exceed the uint32 limit.
It's arguable that packet counts could exceed this value,
due to more duplicates than losses.

>>we'll investigate counter 32/64, although the decrement feature may not be needed.

2.      Recommend moving all camelCase elements to use lower case words separated by "-" e.g., sessionSender->session-sender

[reply]
Agreed to do this in next rev.

3.      Recommend moving all ENUMS to typedefs (e.g., mode) or even better use identity to ensure less of a module revision impact.  In either case these definitions should be moved to the front of the module, so they are all in one place.

[reply]
We'll look at all ENUMS and convert where it makes sense, probably not all cases.

4.      Recommend that the module be compiled with ietf-strict, which will require comments to be included in each element

[reply]
Yes on ietf-strict, probably move ~all descriptions to module at end of development.

5.      Recommend moving all common definitions (which are reused in the module) to typedefs (or identity) such as keyId

[reply]
typedef makes sense for keyId, don't need identity...
>>> need to search for other common definitions.

6.      Just want to ensure that the model supports TWAMP deployments with no Control-Client/Server implementation.  Perhaps you could add a clarification in there.

[reply]
Implicit in the design of the module as features, so implementation can say
which features it supports. Also, each TWAMP entity will have admin state in 
the second release, allowing enable/disable function.

7.      Wanted to ensure that there is no restriction with supporting a mixed environment in relation to the YANG support.  For example, the server supports a YANG interface but the control-client does not ---- same flexibility needed for session sender/reflector.  If not already stated in the RFC, please add this in somewhere.

[reply]
Implicit in the design of the module as features, so implementation can say
which features it supports.

8.      For backward compatibility, may want to state that implementation of a YANG interface should not result in the prior interface not being supported (or is this left to implementation?).  I don't want to be in a position where we have to do a hard cut of our systems to a YANG interface once that is first supported in a product

[reply]
This is a implementation detail, it's an question for everyone doing new YANG 
implementation what to support. 

9.      Can I assume that the values retrieved via YANG (i.e., the "ro" data elements) would be identical to the values that would be retrieved via the alternate method (e.g., CLI) - or is this an implementation specific consideration? Perhaps this can be clarified in implementation guidance?

[reply]
CLI of the past has been proprietary, so the YANG module data elements
may not map one-to-one with an equivalent CLI data element. Example,
packet counters may be differently defined in YANG module and the CLI,
or some attribute may not exist in the CLI. The YANG module is intended
to avoid restricting standards track protocol implementation.

---

From: Srivathsa Sarangapani <[email-masked]>
Date: Tue, 21 Jul 2015 16:13:00 +0000

Hi Kostas,

Good document which covers most of the things.
I just had some thoughts on some of fields below:

Section 5.1:
|        +--rw repeat?               boolean

How about making this a uint32 instead of boolean.
Currently true means it will run forever and false means it will run for
one full iteration.
If we make it uint32 and give it a value, the user can decide how many
iterations it can run right?
Say 0 can indicate infinite iterations(as 0 iterations makes no sense).
1-4294967295 can indicate the number of iterations.

Section 5.1:

In case of both twamp-session-sender and twamp-session-reflector, can we
even store the timestamp of the last-sent-seq and last-rcv-seq packets?
Say along with the below fields:
|     +--ro last-sent-seq?             uint32
         |     +--ro last-rcv-seq?              uint32

have 2 more fields

| +--ro last-sent-seq-time? uint64
| +--ro last-rcv-seq-time? uint64
This might give more insight on when the last packet was sent and when the
last packet was received. Just to understand
As anyways TWAMP deals with RTT, storing the time might make sense.

How about storing the below values(ro) for UDP Test packets in case of
twamp-session-sender:
Current Test packet results:
   Rtt: 57 usec, Egress jitter: -6 usec, Ingress jitter: 5 usec, Round
trip jitter: -1 usec, Egress interarrival jitter: 1 usec,
   Ingress interarrival jitter: 1 usec, Round trip interarrival jitter: 0
usec
    Results over current test:
   Packets sent: 5, Packets received: 5, Loss percentage: 0.000000
      Measurement: Round trip time
   Samples: 5, Minimum: 57 usec, Maximum: 58 usec, Average: 58 usec, Peak
to peak: 1 usec, Stddev: 0 usec
      Measurement: Negative egress jitter
   Samples: 4, Minimum: 6 usec, Maximum: 6 usec, Average: 6 usec, Peak to
peak: 0 usec, Stddev: 0 usec
      Measurement: Positive ingress jitter
   Samples: 4, Minimum: 5 usec, Maximum: 7 usec, Average: 6 usec, Peak to
peak: 2 usec, Stddev: 1 usec
      Measurement: Positive round trip jitter
   Samples: 3, Minimum: 0 usec, Maximum: 1 usec, Average: 0 usec, Peak to
peak: 1 usec, Stddev: 0 usec
      Measurement: Negative round trip jitter
   Samples: 1, Minimum: 1 usec, Maximum: 1 usec, Average: 1 usec, Peak to
peak: 0 usec, Stddev: 0 usec

    Results over all tests:
   Packets sent: 15, Packets received: 15, Loss percentage: 0.000000
      Measurement: Round trip time
   Samples: 15, Minimum: 57 usec, Maximum: 58 usec, Average: 58 usec, Peak
to peak: 1 usec, Stddev: 0 usec
      Measurement: Negative egress jitter
   Samples: 14, Minimum: 6 usec, Maximum: 6 usec, Average: 6 usec, Peak to
peak: 0 usec, Stddev: 0 usec
      Measurement: Positive ingress jitter
   Samples: 14, Minimum: 5 usec, Maximum: 7 usec, Average: 6 usec, Peak to
peak: 2 usec, Stddev: 1 usec
      Measurement: Positive round trip jitter
   Samples: 10, Minimum: 0 usec, Maximum: 1 usec, Average: 0 usec, Peak to
peak: 1 usec, Stddev: 0 usec
      Measurement: Negative round trip jitter
   Samples: 04, Minimum: 1 usec, Maximum: 1 usec, Average: 1 usec, Peak to
peak: 0 usec, Stddev: 0 usec

If you feel it makes sense, then we can work on the type for each of these
variables. 
We can take some of the values and leave the rest. But having some of
these values really makes sense in my opinion.

-- 
Regards,
Vathsa

-----Original Message-----
From: Kostas Pentikousis <[email-masked]>
Date: Friday, July 3, 2015 at 10:01 PM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]"
<[email-masked]>
Subject: [ippm] TWAMP Data Model updated: draft-cmzrjp-ippm-twamp-yang-01

Dear all,

We would like to thank all those who have provided comments and in
particular Greg, Kevin and Robert: All of your suggestions have been taken
into consideration in this revision.

We will come back to you right after the IETF cut-off on Monday with
detailed answers to your emails sent earlier on the list. Sincere
apologies for the delay!

Best regards,