Re: [ippm] WGLC for STAMP Extensions

Greg Mirsky <gregimirsky@gmail.com> Sat, 06 June 2020 19:44 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234313A0B13 for <ippm@ietfa.amsl.com>; Sat, 6 Jun 2020 12:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jtoy5ACoXVUr for <ippm@ietfa.amsl.com>; Sat, 6 Jun 2020 12:44:24 -0700 (PDT)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967DB3A0B12 for <ippm@ietf.org>; Sat, 6 Jun 2020 12:44:23 -0700 (PDT)
Received: by mail-lj1-x230.google.com with SMTP id n24so15767500lji.10 for <ippm@ietf.org>; Sat, 06 Jun 2020 12:44:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qGGZzhCfwYdoTIMqqnsFzR4uozfAu/C+7Vw4nGxpZ+g=; b=M2/O691Nhi8ebyEqlxuyv97DKypfqbNu3qj+jqaeHL2UYwBqIyDIFVZgfaSdPuFhM9 ySByXJl/pIRdjP8jbO9nEVyP88l5d5bXR8UMPt+oB43NWjmutA1KfF+IWJrNeroPE1Ei AaBQQZYZHAzklsFHUEi67cW/LsK1wY/Acj4FNz5ugb4yweNHML8od5YGa2mg4bwSVbWE bsCxvveXE5RWW43jIrNPp3q3U3JZup4EI7uQJbQnhHv/EH5otec0PYUvUspn0gvH+mch tKRk+U7eKvcJEKoDoMpzi1w0bidIZ84D9ITjAKjYfdEDY+qBizTmFuXZ98hYD+fIO/LW tAmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qGGZzhCfwYdoTIMqqnsFzR4uozfAu/C+7Vw4nGxpZ+g=; b=UXk7lkANSvfP1IJEk798OZV8etljRxXYOM8xE+1OlFalqfy1lXMLmhekXKuTUcMwgb htrEdqzYxExJWNz9IZBSR4qSCtJBmiCSFXTIsz3OGRwmbSBflAuKs2xwpinh4/WMZtW7 5tlZKJ4bhxSwJF5e0UI3TuXtoenWws/2k6v9AYXHLHFOWFiQZtF6EIj9FuGpno1RDSV9 qf7WfKfDnAS2RaF1+bNSbLNsFpJallvct7ZV93dRt646kvQT1TxDB+Le6tkNeuRgYfE8 VFwg7OfNViN829bvpqh1d9GPnaZ4VpORjfMvtx85+tlSelqQ4Gj/9F2zAXXcwwMRih6U 4OLQ==
X-Gm-Message-State: AOAM5329VVkSeFezyqRyN9KxcRyasZjSI10SufRvchwbKKylHAHDhF0i Xq6LOSLqR+aS3GSmxL5g+ggpxs/DwC0npQdz+cc=
X-Google-Smtp-Source: ABdhPJylJusTSXpMl2X3v/4LA9vVeWAs2CFN92F9Oe46vuQrQkvDJ2rMDfCF73B26HX7Y0osF6v/iejQFzCq3Eg9IbU=
X-Received: by 2002:a2e:9009:: with SMTP id h9mr7416480ljg.266.1591472660360; Sat, 06 Jun 2020 12:44:20 -0700 (PDT)
MIME-Version: 1.0
References: <CAKcm_gMVc88xpkOMmV7L-ybVCBzw+LhNS6Jw3=iB2gutR0ZhxA@mail.gmail.com> <4D7F4AD313D3FC43A053B309F97543CF0108A608DC@njmtexg5.research.att.com>
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF0108A608DC@njmtexg5.research.att.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sat, 06 Jun 2020 12:44:09 -0700
Message-ID: <CA+RyBmWaqk2J1=FOU1cUt92cUzuE9-htWBBd-W=itvLOOh8beg@mail.gmail.com>
To: "MORTON, ALFRED C (AL)" <acm@research.att.com>
Cc: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, "IETF IPPM WG (ippm@ietf.org)" <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000097313505a76f9a2b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/BXMwTuegT6BBCYbLjP2i0Ls4bF0>
Subject: Re: [ippm] WGLC for STAMP Extensions
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Jun 2020 19:44:26 -0000

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>
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:ippm-bounces@ietf.org] *On Behalf Of *Ian Swett
> *Sent:* Friday, May 22, 2020 5:26 PM
> *To:* IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
> *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
> ippm@ietf.org with your reviews and comments.
>
> Thanks,
> Ian & Tommy
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>