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

[wangyali <[e-mail]>]

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]<mailto:[e-mail]>> wrote:
Hi Greg,

Thanks for your reply. Please see inline [Yali].

Best regards,
Yali

From: Greg Mirsky [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Thursday, August 27, 2020 5:46 AM
To: wangyali <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; IETF IPPM WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[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]<mailto:[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]><mailto:&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]><mailto:&lt;[e-mail]&gt;>om>, Greg Mirsky <

[e-mail]><mailto:[e-mail]&gt;>gt;, Henrik Nydell <[e-mail]><mailto:&lt;[e-mail]&gt;>om>, Adi Masputra <

[e-mail]><mailto:[e-mail]&gt;>gt;, Ernesto Ruffini <[e-mail]><mailto:&lt;[e-mail]&gt;>rg>, Xiao Min <

[e-mail]><mailto:[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.