Re: [ippm] WGLC for STAMP Extensions

[Greg Mirsky <[e-mail]>]

Hi Ian,
thank you for the summary of the discussion, it was the most helpful as
I've almost missed some of them. I believe that the latest version
addresses all the comments received as part of the WGLC. I've added notes
below under GIM>> tag to answer two specific questions.
Please let the authors know if there are any comments we've missed or any
other questions.

Regards,
Greg

On Tue, Jun 9, 2020 at 2:43 PM Ian Swett <[e-mail]> wrote:

> Dear IPPM WG,
>
> Thank you all for your comments on
> https://tools.ietf.org/html/draft-ietf-ippm-stamp-option-tlv-04.  There’s
> strong support for publishing this document, but there were a number of
> questions and comments during WGLC and the chairs would like to see some of
> those addressed before sending an updated draft to the IESG.
>
> Some examples below, though I may have missed some:
>
>    -
>
>    Section 4 - What error is returned if the mandatory TLV is not
>    supported by the reflector?
>
> GIM>>  Updated text in Section 4 requires to log an event and if the
system is a Session-Reflector, to send ICMP Parameter Problem message with
Code set to 0 and the Pointer referring to the Type field.

>
>    -
>
>    Section 5 - Table 2 - Are these all mandatory TLVs? Can we indicate it?
>
> GIM>> Updated text pointing that all the values are from the Mandatory TLV
range.

>
>    -
>
>    Al Morton’s detailed comments (Thanks Al)
>
> GIM>> I believe that we've agreed on all the proposed updates that are
part of -05 version.

>
> It also sounds like there’s interest in working on an applicability draft
> to provide more detail on how these extensions are to be used; the authors
> may want to note that applicability is out-of-scope for the extensions.
>
> Authors, please publish a new version of the draft to incorporate this
> feedback when ready, and we will progress the document after that.
>
> Thanks, Ian and Tommy
>
> On Sat, Jun 6, 2020 at 3:44 PM Greg Mirsky <[e-mail]> wrote:
>
>> Hi Al,
>> the most sincere thanks for your comments and thoughtful suggestions to
>> improve the document. I will carefully review your questions and reply with
>> clarifications by Monday.
>>
>> Best regards,
>> Greg
>>
>> On Sat, Jun 6, 2020 at 11:34 AM MORTON, ALFRED C (AL) <
>> acm@research..att.com <[e-mail]>> wrote:
>>
>>> Hi IPPM,
>>>
>>>
>>>
>>> At one of the author’s request, I reviewed
>>> draft-ietf-ippm-stamp-option-tlv-04.
>>>
>>>
>>>
>>> TL;DR: I have a lot of small comments; no show-stoppers I think.
>>>
>>>
>>>
>>> regards,
>>>
>>> Al
>>>
>>>
>>>
>>>
>>>
>>>    MBZ Must Be Zeroed   [acm] s/Zeroed/Zero/ ? that’s the way MBZ is
>>> usually used...
>>>
>>>
>>>
>>> ...
>>>
>>>        Figure 1: STAMP Session-Sender test packet format with TLV in
>>>
>>>                            unauthenticated mode
>>>
>>>
>>>
>>>    An implementation of STAMP Session-Reflector that supports this
>>>
>>>    specification SHOULD identify a STAMP Session using the SSID in
>>>
>>>    combination with elements of the usual 4-tuple
>>>
>>> [acm] <insert> for the session. If the Session-Reflector finds that
>>>
>>> the SSID and 4-tuple combination changes during a test session, then
>>>
>>> the Session-Reflector MUST discard the non-matching packet(s) and take
>>>
>>> no further action on them.
>>>
>>>    .  A conforming...
>>>
>>>
>>>
>>>
>>>
>>> ...
>>>
>>>
>>>
>>>                         Figure 5: Extra Padding TLV
>>>
>>>
>>>
>>>    where fields are defined as the following:
>>>
>>>
>>>
>>>    o  Extra Padding Type - TBA1 allocated by IANA Section 5.1
>>>
>>>
>>>
>>>    o  Length - two octets long field equals length on the Extra Padding
>>>
>>>       field in octets.
>>>
>>>
>>>
>>>    o  Extra Padding - a pseudo-random sequence of numbers.  The field
>>>
>>>       MAY be filled with all zeroes.
>>>
>>> [acm] 1,$ s/zeroes/zeros/g
>>>
>>>
>>>
>>>    The Extra Padding TLV is similar to the Packet Padding field in
>>>
>>>    TWAMP-Test packet [RFC5357].  The Extra Padding TLV MUST be used to
>>>
>>>    create STAMP test packets of larger size
>>>
>>> [acm] <insert> than the usual STAMP test packet, xxx octets for
>>> un-authenticated.
>>>
>>>
>>>
>>>
>>>
>>> ...
>>>
>>>                  Figure 6: Session-Reflector Location TLV
>>>
>>>
>>>
>>>    where fields are defined as the following:
>>>
>>>
>>>
>>>    o  Location Type - TBA2 allocated by IANA Section 5.1
>>>
>>>
>>>
>>>    o  Length - two octets long field equals length on
>>>
>>> [acm] s/on/of/
>>>
>>>       the Value field in
>>>
>>>       octets.
>>>
>>> [acm] <insert> The
>>>
>>>        Length field value MUST be 20 octets for the IPv4 address
>>>
>>>       family.  For the IPv6 address family
>>>
>>> [acm] <insert> ", the "
>>>
>>>        value of the Length field
>>>
>>>       MUST be 44 octets.  All other values are invalid.
>>>
>>> [acm] in two places above, s/MUST be/MUST equal/
>>>
>>> (otherwise, there is some ambiguity about length and value)
>>>
>>>
>>>
>>>    o  Source MAC - 6 octets 48 bits long field.  The session-reflector
>>>
>>>       MUST copy Source MAC of received STAMP packet into this field.
>>>
>>>
>>>
>>>    o  Reserved - two octets long field.  MUST be zeroed on transmission
>>>
>>>       and ignored on reception.
>>>
>>>
>>>
>>>    o  Destination IP Address - IPv4 or IPv6 destination address of the
>>>
>>> [acm] ??? packet ???  if yes, delete packet at end of sentence...
>>>
>>>       received by the session-reflector STAMP packet.
>>>
>>> [acm] these fixes apply below to Source IP Address
>>>
>>>
>>>
>>>    o  Source IP Address - IPv4 or IPv6 source address of the received by
>>>
>>>       the session-reflector STAMP packet.
>>>
>>> ...
>>>
>>>
>>>
>>>                     Figure 7: Timestamp Information TLV
>>>
>>>
>>>
>>>    where fields are defined as the following:
>>>
>>>
>>>
>>>    o  Timestamp Information Type - TBA3 allocated by IANA Section 5.1
>>>
>>>
>>>
>>>    o  Length - two octets long field, equals four octets.
>>>
>>> [acm] , set equal to the value 4 ?  (there seems to be a lot of this!)
>>>
>>>
>>>
>>>    o  Sync Src In - one octet long field that characterizes the source
>>>
>>>       of clock synchronization at the ingress of Session-Reflector.
>>>
>>>
>>>
>>>       There are several of methods to synchronize the clock, e.g.,
>>>
>>>       Network Time Protocol (NTP) [RFC5905], Precision Time Protocol
>>>
>>>       (PTP) [IEEE..1588.2008], Synchronization Supply Unit (SSU) or
>>>
>>>       Building Integrated Timing Supply (BITS), or Global Positioning
>>>
>>>       System (GPS), Global Orbiting Navigation Satellite System
>>>
>>>       (GLONASS) and Long Range Navigation System Version C (LORAN-C).
>>>
>>>       The value is one of the listed in Table 4.
>>>
>>> [acm] ... one of those listed ...  (more changes like this, too)
>>>
>>>
>>>
>>> ...
>>>
>>>
>>>
>>> 4.5.  Direct Measurement TLV
>>>
>>>
>>>
>>>    The Direct Measurement TLV enables collection of "in profile" IP
>>>
>>>    packets that had been transmitted and received by the Session-Sender
>>>
>>>    and Session-Reflector respectfully.  The definition of "in-profile
>>>
>>>    packet" is outside the scope of this document.
>>>
>>> [acm]  and left to the test operators to determine.
>>>
>>>
>>>
>>> ...
>>>
>>>
>>>
>>>    o  Reserved - the three octest-long field.  Its value MUST be zeroed
>>>
>>> [acm] s/octest/octets/
>>>
>>>       on transmission and ignored on receipt.
>>>
>>>
>>>
>>> 4.8.  HMAC TLV
>>>
>>>
>>>
>>> ...
>>>
>>>
>>>
>>>              | TBA7  |  Follow-up Telemetry  | This document |
>>>
>>>              | TBA8  |          HMAC         | This document |
>>>
>>>              +-------+-----------------------+---------------+
>>>
>>> [acm] You can suggest the values, if you want.
>>>
>>>                            Table 2: STAMP Types
>>>
>>>
>>>
>>> ...
>>>
>>>
>>>
>>>                   +-------+-------------+---------------+
>>>
>>>                   | Value | Description | Reference     |
>>>
>>>                   +-------+-------------+---------------+
>>>
>>>                   | 1     |     3GPP    | This document |
>>>
>>>                   | 2     |   Non-3GPP  | This document |
>>>
>>>                   +-------+-------------+---------------+
>>>
>>> [acm] these seem overly broad, and unlikely to be extended because they
>>> *cover everything*!!
>>>
>>>                             Table 8: Access IDs
>>>
>>>
>>>
>>> ...
>>>
>>>
>>>
>>>               +-------+---------------------+---------------+
>>>
>>>               | Value |     Description     | Reference     |
>>>
>>>               +-------+---------------------+---------------+
>>>
>>>               | 1     |  Network available  | This document |
>>>
>>>               | 2     | Network unavailable | This document |
>>>
>>>               +-------+---------------------+---------------+
>>>
>>> [acm] these seem overly broad, and imply knowledge where the STAMP
>>> end-point has limited insights!!
>>>
>>>                           Table 10: Return Codes
>>>
>>>
>>>
>>> ...
>>>
>>>
>>>
>>> 6.  Security Considerations
>>>
>>>
>>>
>>>    Use of HMAC in authenticated mode may be used to simultaneously
>>>
>>>    verify both the data integrity and the authentication of the STAMP
>>>
>>>    test packets.
>>>
>>> [acm] That's it? At least add reference to STAMP 8762 Security Section?
>>>
>>> [acm] I suspect there will be some challenges for "Location" in future
>>>
>>>
>>>
>>>
>>>
>>> *From:* ippm [mailto:[e-mail]] *On Behalf Of *Ian Swett
>>> *Sent:* Friday, May 22, 2020 5:26 PM
>>> *To:* IETF IPPM WG ([e-mail]) <[e-mail]>
>>> *Subject:* [ippm] WGLC for STAMP Extensions
>>>
>>>
>>>
>>> Hi IPPM,
>>>
>>> At our virtual interim meeting, we decided
>>> draft-ietf-ippm-stamp-option-tlv was ready for last call. This email starts
>>> a two-week WGLC for this draft.
>>>
>>> The latest version can be found here:
>>> https://tools.ietf.org/html/draft-ietf-ippm-stamp-option-tlv-04
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dstamp-2Doption-2Dtlv-2D04&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=-FQ_7VkardtUOemNdXjWGCdxDzw_8jcaV16Ots-GfRo&s=zadhVvE6IwVbJd0BcDUJdpX4xXqA4i60susVdbT5Pvg&e=>
>>>
>>> This last call will end on *Monday, June 8th*. Please reply to
>>> [e-mail] with your reviews and comments.
>>>
>>> Thanks,
>>> Ian & Tommy
>>> _______________________________________________
>>> ippm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ippm
>>>
>>