Re: [ippm] Robert Wilton's No Objection on draft-ietf-ippm-stamp-option-tlv-07: (with COMMENT)
Greg Mirsky <gregimirsky@gmail.com> Sun, 26 July 2020 02:34 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 B3B5A3A0912; Sat, 25 Jul 2020 19:34:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.596
X-Spam-Level:
X-Spam-Status: No, score=-0.596 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 1xTc5M7z_Raq; Sat, 25 Jul 2020 19:34:16 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 4C4463A090E; Sat, 25 Jul 2020 19:34:10 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id q6so13699792ljp.4; Sat, 25 Jul 2020 19:34:10 -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=2hy4orPXh7IyZ54n/zUHtMXmNty+NoMAgUTq/NlP714=; b=b8Q3pagUKGvS17aL+WRScnj21T4nbHrhjIfeik8SfCF9kBT5mzLLU50Ndatusub4lK 65uhHOdonPDT6Qjgs+mzXMk67T3lULMcjpYgJtXlx4ytvJB6FSmM1cevFjzVVg99Cjfi x8LaffJOMQgXeRxpl0ZPjFDOXO2RQvIvT5npn/GEYg6gsl0d2YJ3POGpo5Fmf07nFMgp WeMiiA5b+K20ERGGQJ39Qzy0Tz+BGhWDhj6Jp0YVv2W385XFVQGqyCj6I4r6dzV4lB15 LPk0YbpmRvG01Q7FhpzRXJLVAprGsKHF5fnWuaKdlOkl47k2HmkGMoDf0RpebBFSQDIl NDvw==
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=2hy4orPXh7IyZ54n/zUHtMXmNty+NoMAgUTq/NlP714=; b=KNZafyITwQZpdYZg/rdDfi8TuCsSZWBx+rL77tCrfOIKOj5apXGI9fMK0ArWs/uMEq /IfeTUrNEpoPpRiccQYpGXAEb+Z3XYtQVDRbiw5atS1B8IIDLgBugUw9gKxGnqIQmPTJ cj+CKj2SH1AISQLRfEr+D61JAmIyuRcDDspop4HBo4rtZkpZnJg1if3WUMCfAIXHrQP2 nMmjsU/TizwX4fc8KijDC6mGtNtGHEa2IZVtnWBCskyDSECgzhchl3Ac1gpZOpJ95tTa 0LmMuH25HOtFw8PJ5rr3qhqLwHWj8oZgDA9weATjkiCgs5BXTwndID6DvuhfhDi8KfOq 98qg==
X-Gm-Message-State: AOAM533TE8+VfbUHp/QgeI70911kCnvRLWyBZ3iLOtBCkZi23CkXA55U zcXDqQCjdGQGso5/lFF8nByNpjzlphePbjSaTxI=
X-Google-Smtp-Source: ABdhPJxQYaPAkqHVVxSBOj5bBwU9o7Czkx89cWTAI7UXM9Wlg6spvhasKfATJ/xsJ1p21vdoqXjjWaklcHeVneHRTUk=
X-Received: by 2002:a2e:9611:: with SMTP id v17mr7546330ljh.110.1595730848129; Sat, 25 Jul 2020 19:34:08 -0700 (PDT)
MIME-Version: 1.0
References: <159489254922.17209.7105685724653603337@ietfa.amsl.com>
In-Reply-To: <159489254922.17209.7105685724653603337@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sat, 25 Jul 2020 19:33:56 -0700
Message-ID: <CA+RyBmXM4LQu5Tt5gg4W9O84xqiV4Pg9syrYfBszp1zCFn6AYg@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ippm-stamp-option-tlv@ietf.org, IPPM Chairs <ippm-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>, Yali Wang <wangyali11@huawei.com>
Content-Type: multipart/mixed; boundary="0000000000005c488d05ab4f0ac9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/-l3c_myYvMU8NLRvmLgd1cnCEqE>
X-Mailman-Approved-At: Sun, 26 Jul 2020 14:47:01 -0700
Subject: Re: [ippm] Robert Wilton's No Objection on draft-ietf-ippm-stamp-option-tlv-07: (with COMMENT)
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: Sun, 26 Jul 2020 02:34:27 -0000
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 On Thu, Jul 16, 2020 at 2:42 AM Robert Wilton via Datatracker < noreply@ietf.org> wrote: > 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. > 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? > > 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. > 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. > > 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. > 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: If the U flag is set, the STAMP system MUST skip the processing of 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. > > 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? > 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. > 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. > 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. > > 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. > 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. > > Regards, > Rob > > > >
- [ippm] Robert Wilton's No Objection on draft-ietf… Robert Wilton via Datatracker
- Re: [ippm] Robert Wilton's No Objection on draft-… Greg Mirsky