Subject: [ippm] Benoit Claise's No Objection on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Mon, 19 Oct 2015 15:40:46 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-ippm-type-p-monitor-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-type-p-monitor/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

As mentioned by Al Morton, part of his OPS DIR review:

Summary: Almost ready, comments and editorial suggestions follow.

The draft header should indicate that this draft updates RFC 5357.

Section 2.2.1

Figure 1 has a number of canonical references that should 
be cited to ensure IPv4 and IPv6 applicability, including 
RFC 2474, RFC 3168, and other relevant updates (of which 
there are many).

<later>
   o  if the negotiated/provisioned DSCP value is not known (e.g.  TWAMP
      Light), the choice of the DSCP is implementation specific.  For
      instance, Session-Reflector MAY copy the DSCP value from the
      received test packet and set it as DSCP in a reflected packet.
Question:
What about the ECN value?   From 3168:
      +-----+-----+
      | ECN FIELD |
      +-----+-----+
        ECT   CE         [Obsolete] RFC 2481 names for the ECN bits.
         0     0         Not-ECT
         0     1         ECT(1)
         1     0         ECT(0)
         1     1         CE
It makes little sense to copy a "11" == CE into the reflected packet,
and it may affect the measured performance if "11" were copied.
The draft needs more guidance here (there is a general problem
when the negotiated values are "not known"; this does not apply 
to the Standards Track TWAMP protocol or its extensions).

-=-=-=-=-=-=-=-=-=-=-=-=-

Editorial comments/suggestions:

OLD
2.2.  TWAMP-Test Extension

   Monitoring of DSCP and ECN requires support by the Session-Reflector
   and changes the format of its test packet format both in
   unauthenticated, authenticated and encrypted modes. 
Suggest:
   Monitoring of DSCP and ECN requires support by the Session-Reflector
   and changes the test packet format in all the original
   (unauthenticated, authenticated and encrypted) modes. 

2.2.1

OLD
   o  the first six bits of the Differentiated Service field MUST be
      copied from received Session-Sender test packet into Sender DSCP
      (S-DSCP) field;

   o  the following two bits of the ECN field MUST be copied from
      received Session-Sender test packet into Sender ECN (S-ECN) field.
Suggest:
   o  the six (least-significant) bits of the Differentiated Service
field MUST be
      copied from received Session-Sender test packet into Sender DSCP
      (S-DSCP) field;

   o  the two bits of the ECN field MUST be copied from
      received Session-Sender test packet into Sender ECN (S-ECN) field.

because RFC 3168 defines:
         0     1     2     3     4     5     6     7
      +-----+-----+-----+-----+-----+-----+-----+-----+
      |          DS FIELD, DSCP           | ECN FIELD |
      +-----+-----+-----+-----+-----+-----+-----+-----+

        DSCP: differentiated services codepoint
        ECN:  Explicit Congestion Notification

      Figure 2: The Differentiated Services and ECN Fields in IP.
-=-=-=-=-=-=-=-

OLD
    0     1     2     3     4     5     6     7     8
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               S-DSCP              |   S-ECN   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: Sender DSCP and ECN field format

Suggest:
The extra "+" within bit positions are distracting,
and don't conform to the conventions of these diagrams.
Also, there's no "8" when numbering from 0.

Some attempt should be made to put Figure 3 on a single page in the 
final version. There's one line taken up by "+" that is unnecessary
in the modified field:

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Sender TTL  |  S-DSCP-ECN   |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                             |
 >> +                                                             + <<
    |                       MBZ (14 octets)                       |
    |                                                             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 20 Oct 2015 20:24:13 +0000

Dear Benoit,
thank you for your review and the comments. We're working on addressing them and will send the proposed updates shortly.

	Regards,
		Greg

-----Original Message-----
From: Benoit Claise [mailto:[email-masked]] 
Sent: Monday, October 19, 2015 3:41 PM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Benoit Claise's No Objection on draft-ietf-ippm-type-p-monitor-02: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Section 2.2.1

Figure 1 has a number of canonical references that should be cited to ensure IPv4 and IPv6 applicability, including RFC 2474, RFC 3168, and other relevant updates (of which there are many).

<later>
   o  if the negotiated/provisioned DSCP value is not known (e.g.  TWAMP
      Light), the choice of the DSCP is implementation specific.  For
      instance, Session-Reflector MAY copy the DSCP value from the
      received test packet and set it as DSCP in a reflected packet.
Question:
What about the ECN value?   From 3168:
      +-----+-----+
      | ECN FIELD |
      +-----+-----+
        ECT   CE         [Obsolete] RFC 2481 names for the ECN bits.
         0     0         Not-ECT
         0     1         ECT(1)
         1     0         ECT(0)
         1     1         CE
It makes little sense to copy a "11" == CE into the reflected packet, and it may affect the measured performance if "11" were copied.
The draft needs more guidance here (there is a general problem when the negotiated values are "not known"; this does not apply to the Standards Track TWAMP protocol or its extensions).

OLD

2.2.1

OLD

   o  the following two bits of the ECN field MUST be copied from
      received Session-Sender test packet into Sender ECN (S-ECN) field.
Suggest:
   o  the six (least-significant) bits of the Differentiated Service field MUST be
      copied from received Session-Sender test packet into Sender DSCP
      (S-DSCP) field;

OLD
    0     1     2     3     4     5     6     7     8

Suggest:
The extra "+" within bit positions are distracting, and don't conform to the conventions of these diagrams.
Also, there's no "8" when numbering from 0.

Some attempt should be made to put Figure 3 on a single page in the final version. There's one line taken up by "+" that is unnecessary in the modified field:

    |                       MBZ (14 octets)                       |
    |                                                             |