Re: [ippm] Fwd: New Version Notification for draft-ietf-ippm-stamp-option-tlv-09.txt

[Greg Mirsky <[e-mail]>]

Hi Yali,
thank you for your comments and the question about the U flag's initial
setting. I think that there is a benefit in a Session-Sender setting the U
flag to 1. If the STAMP Session-Reflector does not support
draft-ietf-ippm-stamp-option-tlv, it will copy TLVs that follow the base
STAMP packet. The Session-Sender then can detect that none of the TLVs were
processed. What do you think?

Regards,
Greg

On Mon, Aug 31, 2020 at 6:52 PM wangyali <[e-mail]> wrote:

> Hi Greg,
>
>
>
> Thanks a lot for your feedbacks and follow-up notes. Please find my
> thoughts on the U flag inline [Yali2].
>
>
>
> Best regards,
>
> Yali
>
>
>
> *From:* Greg Mirsky [mailto:[e-mail]]
> *Sent:* Saturday, August 29, 2020 3:10 AM
> *To:* wangyali <[e-mail]>
> *Cc:* [e-mail]; IETF IPPM WG (
> [e-mail]) <[e-mail]>
> *Subject:* Re: [ippm] Fwd: New Version Notification for
> draft-ietf-ippm-stamp-option-tlv-09.txt
>
>
>
> Hi Yali,
>
> thank you for sharing your thoughts on how IANA allocation policies can be
> used for STAMP TLV and sub-TLV registries. Please find my follow-up notes
> in-lined tagged GIM2>>.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Thu, Aug 27, 2020 at 8:15 PM wangyali <[e-mail]> wrote:
>
> Hi Greg,
>
>
>
> Thanks for your reply. Please see inline [Yali].
>
>
>
> Best regards,
>
> Yali
>
>
>
> *From:* Greg Mirsky [mailto:[e-mail]]
> *Sent:* Thursday, August 27, 2020 5:46 AM
> *To:* wangyali <[e-mail]>
> *Cc:* [e-mail]; IETF IPPM WG (
> [e-mail]) <[e-mail]>
> *Subject:* Re: [ippm] Fwd: New Version Notification for
> draft-ietf-ippm-stamp-option-tlv-09.txt
>
>
>
> Hi Yali,
>
> thank you for your questions. Please find my answers and notes below under
> GIM>> tag.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Mon, Aug 24, 2020 at 7:51 PM wangyali <[e-mail]> wrote:
>
> Hi Greg and all,
>
>
>
> May I have some questions and comments about the STAMP TLV Type Registry?
>
>
>
> First, as shown in the Table 1, code points in the range 252-254 is
> allocated for Private Use. Does it mean each Vendor/Enterprise can just
> define three kinds of STAMP TLV? What’s your consideration about the three
> code points allocation for Vendor Private Use ?
>
> GIM>> My understanding of Section 4.1 RFC 8126
> <https://tools.ietf.org/html/rfc8126#section-4.1> is that Private code
> points MUST NOT be used ouside of an isolated local network domain, e.g.,
> lab network.
>
>  [Yali] True. This is the definition of the Private Use. So why is the
> range of Private Use just 3 code points? In addition, in the
> draft-ietf-mpls-lsp-ping-registries-update, the term "Vendor Private Use"
> is changed to "First Come First Served (FCFS)" in the principles of the LSP
> Ping TLV and sub-TLV registries. I suggest merging the range of Private Use
> into the FCFS. What do you think?
>
> GIM2>> In my understanding of RFC 8126, Private Use and FCFS are quite
> different. The former is only for isolated networks, while the latter may
> be used over the Internet. Also, I find that using FCFS registration we
> expose STAMP to the following warning provided in Section 4.4:
>
>    A working group or any other entity that is developing a protocol
>    based on a First Come First Served code point has to be extremely
>    careful that the protocol retains wire compatibility with current use
>    of the code point.  Once that is no longer true, the new work needs
>    to change to a different code point (and register that use at the
>    appropriate time).
>
> Hence, unless there's a strong technical reason for the proposed change of
> the registration, I'm hesitant to make the update at this time.
>
>
>
> Second, if the TLV Type or sub-TLV Type is Experimental, similarly to
> Private Use, does it need to fill the vendor’s SMI Private Enterprise Code
> in the first four octets of Value field? Please give some clarifications
> any expected restrictions on experimental scope. Such as said in [RFC8126],
> whether it’s acceptable to run experiments using those code points over the
> open Internet or whether such experiments should be confined to more closed
> environments.
>
> GIM>> True, the Experimental code points are similar to the ones
> designeted to Private Use, as explained in Section 4.2. I've followed the
> discussion on MPLS WG list
> <https://mailarchive.ietf.org/arch/browse/mpls/?gbt=1&index=ewEzqMkkwwOxdChj_NfF_G_CZKo>that
> dealt with the issues related to allocation of TLV and sub-TLV code points.
> I couldn't find the issue of the experimental scope being reflected in the
> latest version of the draft
> <https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-registries-update/?include_text=1>.
> Persnally, I don't think that we need to restrict the scope of using the
> experimental type. What do you think?
>
>  [Yali] Fine. If we want to follow the draft
> <https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-registries-update/?include_text=1>,
> I suggest merging the range of Private Use into the FCFS and revising the
> following sentence in section 4.
>
> Old:  If a Type value for TLV or sub-
>
>    TLV is in the range for Vendor Private Use, the Length MUST be at
>
>    least 4, and the first four octets MUST be that vendor's Structure of
>
>    Management Information (SMI) Private Enterprise Code, as recorded in
>
>    IANA's SMI Private Enterprise Codes sub-registry, in network octet order.
>
> New: If a Type value for TLV or sub-TLV is in the range for Experimental
> Use, the Length MUST be at least 4, and the first four octets MUST be that
> vendor's Structure of Management Information (SMI) Private Enterprise Code,
> as recorded in IANA's SMI Private Enterprise Codes sub-registry, in network
> octet order. In the standards compliant implementations, if the
> unrecognized TLV or sun-TLV is from the Experimental Use range, the TLVs
> should be silently ignored.
>
> GIM2>> Thank you for proposing the new text. I think that "silently
> ignored" for a TLV from the Experimental range is very different
> from how the handling of the unrecognized TLV defined in the specification.
> To support symmetrical packets in STAMP, the Session-Reflector must somehow
> compensate the length of the unrecognized TLV. Should it replace the
> unrecognized Experimental TLV with the Extra Padding TLV? Or copy the
> unrecognized Experimental TLV into the reflected packet as-is, i.e.,
> without setting the U flag? What do you think?
>
>
>
> [Yali2] first, I find there may be an editorial error that “the U flag
> MUST be set to 1 in an extended STAMP test packet which is transmitted by a
> Session-Sender”. Should it be that “the U flag MUST be set to 0 in an
> extended STAMP test packet which is transmitted by a Session-Sender”? And
> if the unrecognized TLV is not understood by the session-reflector, I
> suggest to copy the unrecognized TLV into the reflected packet as-is, and
> set the U flag to 1.
>
> Best regards,
>
> Yali
>
>
>
>
>
> ---------- Forwarded message ---------
>
> From: <[e-mail]> <&lt;[e-mail]&gt;>
>
> Date: Fri, Aug 21, 2020 at 1:01 PM
>
> Subject: New Version Notification for
>
> draft-ietf-ippm-stamp-option-tlv-09.txt
>
> To: Richard Foote <[e-mail]> <&lt;[e-mail]&gt;>om>, Greg Mirsky <
>
> [e-mail]> <[e-mail]&gt;>gt;, Henrik Nydell <[e-mail]> <&lt;[e-mail]&gt;>om>, Adi Masputra <
>
> [e-mail]> <[e-mail]&gt;>gt;, Ernesto Ruffini <[e-mail]> <&lt;[e-mail]&gt;>rg>, Xiao Min <
>
> [e-mail]> <[e-mail]&gt;>
>
>
>
>
>
>
>
> A new version of I-D, draft-ietf-ippm-stamp-option-tlv-09.txt
>
> has been successfully submitted by Greg Mirsky and posted to the
>
> IETF repository.
>
>
>
> Name:           draft-ietf-ippm-stamp-option-tlv
>
> Revision:       09
>
> Title:          Simple Two-way Active Measurement Protocol Optional
>
> Extensions
>
> Document date:  2020-08-21
>
> Group:          ippm
>
> Pages:          32
>
> URL:
>
> https://www.ietf.org/internet-drafts/draft-ietf-ippm-stamp-option-tlv-09.txt
>
> Status:
>
> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/
>
> Htmlized:
>
> https://tools.ietf.org/html/draft-ietf-ippm-stamp-option-tlv-09
>
> Htmlized:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-option-tlv
>
> Diff:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-option-tlv-09
>
>
>
> Abstract:
>
>    This document describes optional extensions to Simple Two-way Active
>
>    Measurement Protocol (STAMP) that enable measurement of performance
>
>    metrics.  The document also defines a STAMP Test Session Identifier
>
>    and thus updates RFC 8762.
>
>
>
>