Subject: [ippm] Robert Wilton's No Objection on draft-ietf-ippm-stamp-option-tlv-07: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 16 Jul 2020 02:42:29 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-ippm-stamp-option-tlv-07: 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-stamp-option-tlv/

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

I support Ben's discuss regarding check the length of the STAMP packet to
determine whether it is a base or extended STAMP packet.

Comments:
Thank you for this document.  By and large I found this document fairly easy to
read and understand, but have comments on a few areas:

I found the document slightly confusing in that the extended stamp packets are
defined under the "STAMP Test Session Identifier" section.  I would have found
the document to be more coherent if the new extended packet structure was
pulled into its own section, perhaps with "STAMP Test Session Identifier" as a
sub-section.

Perhaps it might be helpful to explain why the MBZ sections are where they are
- I presume to still conform with the structure of the base STAMP packet
formats for session-reflectors that do not understand the new format.

In section 4:  TLV Extensions to STAMP

   A system that has received a STAMP test packet with extension TLVs
   MUST validate each TLV:

      If the U flag is set, the STAMP system MUST skip the processing of
      the TLV.  The implementation MUST try to process the next TLV if
      present in the extended STAMP packet.

      If the L flag is set, the STAMP system MUST stop processing the
      remainder of the extended STAMP packet.

      If the A flag is set, the STAMP system MUST discard all TLVs and
      MUST stop processing the remainder of the extended STAMP packet.

I was initially surprised that different behavior was specified for the
handling for the U, L and A flags given that the sender sets these to zero.  I
presume that the aim here is just to have commonality between the Session
Sender and Session Reflectors?  It might help clarify whether this section
applies to both sender and reflector.

In section 4.4:

   o  DSCP2 - The received value in the DSCP field at the Session-
      Reflector in the forward direction.

   o  ECN - The received value in the ECN field at the Session-Reflector
      in the forward direction.

These are the only two cases of forward direction.  Would it be better to
describe this as "ingress of the Session-Reflector", e.g. similar to the
description in the previous section?

4.5.  Direct Measurement TLV

   o  Session-Reflector Rx counter (R_RxC) is a four-octet-long field.
      MUST be zeroed by the Session-Sender on transmit and ignored by
      the Session-Reflector on receipt.  The Session-Reflector MUST fill
      it with the value of in-profile packets received.

"in-profile packets received" is unclear to me.

   o  Session-Reflector Tx counter (R_TxC) is a four-octet-long field.
      MUST be zeroed by the Session-Sender and ignored by the Session-
      Reflector on receipt.  The Session-Reflector MUST fill it with the
      value of the transmitted in-profile packets.

Presumably the Session-Reflector needs to be configured via an out of band
mechanism to specify how many in-profile packets are transmitted, and what
those packets are.  Further text in the beginning of section 4.5 may be helpful
here.

4.6.  Access Report TLV

This section seems to describe more than just a TLV given that it seems to put
additional constraints on the implementation (e.g. use of a retransmission
timer).  Possibly the document would have been more clear to split the
definition of the access report handling separately (e.g. as a separate section
earlier in the document) from the Access Report TLV definition.

Regards,
Rob

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 25 Jul 2020 19:33:56 -0700

Hi Rob,
thank you for your comments and my apologies for the belated response.
Please find my answers and notes below under the tag GIM>>. The published
version of the draft has been through a lot of updates. I've attached the
working version of the document (includes the proposed below update) and
its diff to -07.

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/
GIM>> Section 3 that defines the SSID references and encompasses figures
that display the SSID field and TLVs (only as generic construct). But the
definition of STAMP TLV, a detailed discussion of its format, TLVs, and
sub-TLVs is in Section 4. We've tried to use the same figures for SSID and
extensions to reduce the amount of space taken by ASCII-art. Would you
agree with the current structure of the document?

> formats for session-reflectors that do not understand the new format.
GIM>> Four leading figures that display the format of a STAMP packet in all
combinations are from RFC 8762. This specification introduces the SSID
field into the base STAMP packet (i.e., non-extended) and documents the
STAMP extensions. RFC 8762 is referenced throughout the document, starting
with the Introduction section. The use and location of MBZ fields in the
STAMP base packet is to provide compatibility with devices that support
TWAMP-Test in unauthenticated mode.

> applies to both sender and reflector.
GIM>> As the result of discussions with IESG reviewers this text has been
considerably changed, e.g., the U flag is set to 1 by a Session-Sender. I
hope that the updated text is improved in regard to how the STAMP actors
process flags:
   o  U (Unrecognized) is a one-bit flag.  A Session-Sender MUST set the
      U flag to 1 before transmitting an extended STAMP test packet.  A
      Session-Reflector MUST set the U flag to 1 if the Session-
      Reflector has not understood the TLV.  Otherwise, the Session-
      Reflector MUST set the U flag in the reflected packet to 0.

   o  M (Malformed) is a one-bit flag.  A Session-Sender MUST set the M
      flag to 0 before transmitting an extended STAMP test packet.  A
      Session-Reflector MUST set the M flag to 1 if the Session-
      Reflector determined the TLV is malformed, i.e., the Length field
      value is not valid for the particular type, or the remaining
      length of the extended STAMP packet is less than the size of the
      TLV.  Otherwise, the Session-Reflector MUST set the M flag in the
      reflected packet to 0.

   o  I (Integrity) is a one-bit flag.  A Session-Sender MUST set the I
      flag to 0 before transmitting an extended STAMP test packet.  A
      Session-Reflector MUST set the I flag to 1 if the STAMP extensions
      have failed HMAC verification (Section 4.8).  Otherwise, the
      Session-Reflector MUST set the I flag in the reflected packet to
      0.

   o  R - reserved flags for future use.  These flags MUST be zeroed on
      transmit and ignored on receipt.

   A STAMP node, whether Session-Sender or Session-Reflector, receiving
   a test packet MUST determine whether the packet is a base STAMP
   packet or includes one or more TLVs.  The node MUST compare the value
   in the Length field of the UDP header and the length of the base
   STAMP test packet in the mode, unauthenticated or authenticated based
   on the configuration of the particular STAMP test session.  If the
   difference between the two values is larger than the length of the
   UDP header, then the test packet includes one or more STAMP TLVs that
   immediately follow the base STAMP test packet.  A Session-Reflector
   that does not support STAMP extensions will not process but copy them
   into the reflected packet, as defined in Section 4.3 [RFC8762].  A
   Session-Reflector that supports TLVs will indicate specific TLVs that
   it did not process by setting the U flag to 1 in those TLVs.

   A STAMP system, i.e., either a Session-Sender or a Session-Reflector,
   that has received a STAMP test packet with extension TLVs MUST
   validate each TLV:

      the TLV.

      If the M flag is set, the STAMP system MUST stop processing the
      remainder of the extended STAMP packet.

      If the I flag is set, the STAMP system MUST discard all TLVs and
      MUST stop processing the remainder of the extended STAMP packet.
      If an implementation of a Session-Reflector does not recognize the
      Type field value, it MUST include a copy of the TLV into the
      reflected STAMP packet.  The Session-Reflector MUST set the U flag
      to 1.  The Session-Reflector MUST skip the processing of the
      unrecognized TLV.

      If a TLV is malformed, the processing of extension TLVs MUST be
      stopped.  The Session-Reflector MUST copy the remainder of the
      received extended STAMP packet into the reflected STAMP packet.
      The Session-Reflector MUST set the M flag to 1.

> description in the previous section?
GIM>> Thank you for the suggestion. Agree and below is the update I propose:
NEW TEXT:
    o  DSCP2 - The received value in the DSCP field at the ingress of the
      Session-Reflector.

   o  ECN - The received value in the ECN field at the ingress of the
      Session-Reflector.

> those packets are.  Further text in the beginning of section 4.5 may be
GIM>> Direct loss measurement uses a data flow to calculate the packet loss
between two systems. Because of using real-life data flow, there's no
expectation of receiving any specific number of packets within a fixed time
interval. An OAM message that collects counters from the local and remote
systems helps to synchronize the reading of in-profile packet counters.
Direct loss measurements supported in CFM/Y.1731 and RFC 6374.

> earlier in the document) from the Access Report TLV definition.
GIM>> In the specification of the Acces Report TLV we've followed the
current definition of the PMF in 3GPP's TS23501. Thus, an implementation
that supports the Access Report TLV might be compliant with TS23501.