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

[Greg Mirsky <[e-mail]>]

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?

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