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 >
- [ippm] WGLC for STAMP Extensions Ian Swett
- Re: [ippm] WGLC for STAMP Extensions Tommy Pauly
- Re: [ippm] WGLC for STAMP Extensions Adi Masputra
- Re: [ippm] WGLC for STAMP Extensions Greg Mirsky
- Re: [ippm] WGLC for STAMP Extensions Tianran Zhou
- Re: [ippm] WGLC for STAMP Extensions xiao.min2
- Re: [ippm] WGLC for STAMP Extensions Giuseppe Fioccola
- Re: [ippm] WGLC for STAMP Extensions Henrik Nydell
- Re: [ippm] WGLC for STAMP Extensions Ernesto Ruffini
- Re: [ippm] WGLC for STAMP Extensions Foote, Footer (Nokia - CA)
- [ippm] 答复: WGLC for STAMP Extensions Songyuezhong (songyuezhong, IP technology Research Dept)
- Re: [ippm] WGLC for STAMP Extensions wangyali
- Re: [ippm] 答复: WGLC for STAMP Extensions Henrik Nydell
- Re: [ippm] 答复: WGLC for STAMP Extensions Greg Mirsky
- [ippm] 答复: 答复: WGLC for STAMP Extensions Songyuezhong (songyuezhong, IP technology Research Dept)
- Re: [ippm] 答复: WGLC for STAMP Extensions Greg Mirsky
- [ippm] 答复: 答复: WGLC for STAMP Extensions Songyuezhong (songyuezhong, IP technology Research Dept)
- Re: [ippm] WGLC for STAMP Extensions Rakesh Gandhi
- Re: [ippm] 答复: WGLC for STAMP Extensions Greg Mirsky
- Re: [ippm] WGLC for STAMP Extensions MORTON, ALFRED C (AL)
- Re: [ippm] WGLC for STAMP Extensions Greg Mirsky
- Re: [ippm] WGLC for STAMP Extensions Ian Swett
- Re: [ippm] WGLC for STAMP Extensions Greg Mirsky
- Re: [ippm] WGLC for STAMP Extensions MORTON, ALFRED C (AL)
- Re: [ippm] WGLC for STAMP Extensions Greg Mirsky
- Re: [ippm] WGLC for STAMP Extensions Rakesh Gandhi
- Re: [ippm] WGLC for STAMP Extensions Greg Mirsky
- Re: [ippm] WGLC for STAMP Extensions Greg Mirsky
- Re: [ippm] WGLC for STAMP Extensions MORTON, ALFRED C (AL)
- Re: [ippm] WGLC for STAMP Extensions MORTON, ALFRED C (AL)
- Re: [ippm] WGLC for STAMP Extensions Rakesh Gandhi
- Re: [ippm] WGLC for STAMP Extensions Greg Mirsky
- Re: [ippm] WGLC for STAMP Extensions Rakesh Gandhi (rgandhi)
- Re: [ippm] WGLC for STAMP Extensions Greg Mirsky
- Re: [ippm] WGLC for STAMP Extensions Rakesh Gandhi
- Re: [ippm] WGLC for STAMP Extensions Greg Mirsky
- Re: [ippm] WGLC for STAMP Extensions Rakesh Gandhi
- Re: [ippm] WGLC for STAMP Extensions Greg Mirsky
- Re: [ippm] WGLC for STAMP Extensions wangyali
- Re: [ippm] WGLC for STAMP Extensions Greg Mirsky
- Re: [ippm] WGLC for STAMP Extensions Greg Mirsky
- [ippm] 答复: WGLC for STAMP Extensions wangyali
- Re: [ippm] WGLC for STAMP Extensions Greg Mirsky
- Re: [ippm] WGLC for STAMP Extensions wangyali
- Re: [ippm] WGLC for STAMP Extensions Greg Mirsky
- Re: [ippm] WGLC for STAMP Extensions wangyali