Subject: Re: [ippm] Comments, notes and questions regarding draft-cmzrjp-ippm-twamp-yang

From: Kostas Pentikousis <[email-masked]>
Date: Wed, 15 Jul 2015 18:02:09 +0200

Dear Greg,

Many thanks for the detailed comments. They certainly assisted us to improve the draft and were much appreciated.

| many thanks for starting this important work. Please kindly consider my notes,
| comments and questions to the document:
| * is the scope of the document exclusively RFC 5357 or data model includes other
|   TWAMP related RFCs, WG documents?

As per the YANG module revision description, draft-cmzrjp-ippm-twamp-yang-01 now covers RFC5357, RFC5618, RFC5938, RFC6038 and we took into consideration draft-ietf-ippm-metric-registry.

| * section 3.1: does test session identification set includes DSCP set by Session-Sender?

No, we concluded that it's sufficient to use the 4-tuple in Standards-Track TWAMP.

| * section 3.4: 4-tuple (Source/Destination IP addresses and UDP Ports) would not be unique,
| DSCP value required to uniquely identify test session.

Each Accepted Test Session is unique because it specifies a different port for the Session Sender. This is a limitation of the Request-TW-Session Message: there is only one dscp field and one source port field.

| * section 4.1:
|   o 5357 does not provision control of packet padding. What the 'paddingLength'
|     corresponds to in RFC 5357? Reference suggests it is to support RFC 6038.
|     Should RFC 6038 be is separate container as it is optional functionality?

Section 3.5 of RFC 4656 (OWAMP) describes the Padding Length field, and Section 3.4 of RFC 5357 references this through re-use of the OWAMP Request-Session fields. Further, Section 4.2.1 of RFC 5357 requires provisioning of packet padding content.

|   o pmIndex - should reference to Performance Metric Registry be in separate container?

Good point, we have updated accordingly (see pm-reg-list in draft-cmzrjp-ippm-twamp-yang-01)

| * section 4.2:
|   o dscp of Server is R/O as, per RFC 5357 "The Server SHOULD use the DSCP of the
|     Control-Client's TCP SYN in ALL subsequent packets on that connection (avoiding
|     any ambiguity in case of re-marking)."

This has also been updated, many thanks for bringing it up.

|* section 4.3:
|  o dot1dPriority - QoS mapping usually controlled on global scale, doesn't appear
|    in place in TWAMP data model;

Removed.

|  o packetDistribution - is it a container?

Do you think it makes more sense if it is?

|  o packetDistribution, fixedInterval and fixedIntervalUnits, lambda and lambdaUnits
|    - are not part of RFC 5357 and may be more appropriate in separate container,
|    e.g. with reference to Performance Metric Registry (pmIndex) and paddingLength;

Yes, this is covered by PM Index, could be in a proprietary extension, in a container.

|  o if lastRcvSeq included in the Session-Sender data model, adding RO for number
|    of duplicate and out-of-order may be useful.

lastRcvSeq (now last-rcv-seq) is intended as a de-bugging aid while a session is running.

| *         leaf paddingLength {
|             type uint32{
|               range "64..1500";
|             }
| I think that jumbo-frames must be allowed as well. Operator may use MTU Discovery protocol.

Updated accordingly, many thanks.

|         leaf dscp {
|           type inet:dscp;
|           description "The DSCP value used in the header of the TCP
|             control packets sent by the Server for this control
|             connection. This will usually be the same value as is
|             configured for twampServer:dscp under the twampServer.
|             However, in the event that the user re-configures
|             twampServer:dscp after this control connection is already
|             in progress, this read-only value will show the actual
|              dscp value in use by this control connection.";
|         }
| As noted, RFC 5357 requires (SHOULD) that Server copies DSCP from Control Client's
| TCP SYN, not that DSCP is configured.

See reply above.

| * section 6
| Although these are presented as only examples (in several places):
|               <senderUdpPort>4000</senderUdpPort>
| UDP port, AFAIK, must be from the dynamic or private ports range, i.e. 49152 to 65535.

Good catch, but  I somehow missed it in -01. Local copy of -02 (pending till the datatracker is on again) already updated. Thanks!

| * general: TWAMP Light is broadly supported by number of implementations. I believe it
| would beneficial to produce TWAMP Light YANG model or ensure that respective
| Session-Sender and Session-Reflector models support TWAMP-Light as characterized in
| Appendix I and relevant accepted Errata.

We aim this document towards Standards Track TWAMP and extensions.

Best regards,

Kostas (as editor, on behalf of the authors)