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

From: Gregory Mirsky <[email-masked]>
Date: Wed, 25 Mar 2015 18:20:48 +0000

Dear Authors, et. al,
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?

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

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

*         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?

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

*         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)."

*         section 4.3:

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

o   packetDistribution - is it a container?

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;

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

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

         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.

*         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.

*         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.

Regards,
        Greg