Re: [ippm] WGLC for STAMP Extensions

[Ian Swett <[e-mail]>]

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

   Section 5 - Table 2 - Are these all mandatory TLVs? Can we indicate it?
   -

   Al Morton’s detailed comments (Thanks Al)


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