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

From: Greg Mirsky <[email-masked]>
Date: Mon, 22 Jun 2020 16:17:21 -0700

Dear All,
the new version includes updates to address one comment from WG LC (thank
you, Yali Wang), and the comments from AD review (many thanks, Martin):

   - clarified the interoperation between a Session-Sender that uses SSID
   and a Session-Refletr that does not;
   - simplified allocation of the Type values by merging the Mandatory and
   optional ranges of values into one;
   - modified handling of unknown Type values to a "softer" approach. The
   Session-Reflector includes the Extra Padding TLV in the reflected packet in
   place of the unrecognized TLV. That keeps packets symmetrical, i.e., the
   same length;
   - improvements to the text - removed text duplication, added some
   clarifications.

I always welcome your questions and comments.

Regards,
Greg

---------- Forwarded message ---------
From: <[email-masked]>
Date: Mon, Jun 22, 2020 at 12:45 PM
Subject: New Version Notification for
draft-ietf-ippm-stamp-option-tlv-06.txt
To: Ernesto Ruffini <[email-masked]>, Richard Foote <
[email-masked]>, Greg Mirsky <[email-masked]>, Henrik Nydell
<[email-masked]>, Adi Masputra <[email-masked]>, Xiao Min <
[email-masked]>

A new version of I-D, draft-ietf-ippm-stamp-option-tlv-06.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:           draft-ietf-ippm-stamp-option-tlv
Revision:       06
Title:          Simple Two-way Active Measurement Protocol Optional
Extensions
Document date:  2020-06-22
Group:          ippm
Pages:          24
URL:
https://www.ietf.org/internet-drafts/draft-ietf-ippm-stamp-option-tlv-06.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-06
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-06

Abstract:
   This document describes optional extensions to Simple Two-way Active
   Measurement Protocol (STAMP) which enable measurement performance
   metrics in addition to ones supported by the STAMP base
   specification.  The document also defines a STAMP Test Session
   Identifier and thus updates RFC 8762.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 22 Jun 2020 19:41:25 -0400

Hi Greg,
One comment regarding handling of unknown Type values to a "softer"
approach. It is better than the ICMP message.
Why not define a new TLV Type called Unsupported TLV? The Value of that TLV
can return the whole unsupported TLV including its Type. This way there is
no ambiguity. The return packet size may be different but this would be the
case when the TLV is consumed by the reflector.

My 2c.

Thanks,
Rakesh

On Mon, Jun 22, 2020 at 7:17 PM Greg Mirsky <[email-masked]> wrote:

>    - simplified allocation of the Type values by merging the Mandatory
>    and optional ranges of values into one;
>    clarifications..
> [email-masked]>, Greg Mirsky <[email-masked]>, Henrik
> Nydell <[email-masked]>, Adi Masputra <[email-masked]>, Xiao Min <
> [email-masked]>
>
>
>
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 22 Jun 2020 16:45:03 -0700

Hi Rakesh,
I think that is a great idea, thank you! We have several ideas for new
TLVs, would you be interested to discuss and work together on this? I think
the Return Code TLV you've suggested can be added to a new document. What
do you think?

Regards,
Greg

On Mon, Jun 22, 2020 at 4:41 PM Rakesh Gandhi <[email-masked]>
wrote:

> Why not define a new TLV Type called Unsupported TLV? The Value of that
> TLV can return the whole unsupported TLV including its Type. This way there
> is no ambiguity. The return packet size may be different but this would be
> the case when the TLV is consumed by the reflector.
>
> My 2c.
>
> Thanks,
> Rakesh
>
>
>
>
>>    - clarified the interoperation between a Session-Sender that uses
>>    SSID and a Session-Refletr that does not;
>>    - modified handling of unknown Type values to a "softer" approach.
>>    The Session-Reflector includes the Extra Padding TLV in the reflected
>>    packet in place of the unrecognized TLV. That keeps packets symmetrical,
>>    i.e., the same length;

---

From: Martin Duke <[email-masked]>
Date: Mon, 22 Jun 2020 16:49:06 -0700

Why not in this document?

On Mon, Jun 22, 2020 at 4:45 PM Greg Mirsky <[email-masked]> wrote:

>>> the new version includes updates to address one comment from WG LC
>>> (thank you, Yali Wang), and the comments from AD review (many thanks,
>>> Martin):
>>>
>>>    i..e., the same length;

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 22 Jun 2020 17:07:20 -0700

If that is preferred by everyone, we can certainly roll it in. I can share
the new text by tomorrow.

Regards,
Greg

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 22 Jun 2020 21:46:15 -0400

Hi Greg,
I think this document should have some generic handling. There can be
generic return codes and also return of the unsupported TLVs. It could be
one combo tlv with sub-tlvs or two separate tlvs.
Thanks,
Rakesh

On Mon., Jun. 22, 2020, 8:07 p.m. Greg Mirsky, <[email-masked]>
wrote:

>>>>>    - simplified allocation of the Type values by merging the
>>>>>    Mandatory and optional ranges of values into one;
>>>>> Nydell <[email-masked]>, Adi Masputra <[email-masked]>, Xiao Min
>>>>> <[email-masked]>
>>>>>
>>>>>
>>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 22 Jun 2020 19:21:51 -0700

Hi Rakesh,
below is the new section where a new Error Code LTV defined:
NEW TEXT:
   An Error Code TLV is used by a STAMP Session-Reflector to inform a
   Session-Sender of a problem processing the received STAMP test
   packet.  The format of the Error Code TLV is shown in Figure 13.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Error Code Type        |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Code     |    Sub-Code   |          Reserved             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                        Received Packet                        ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 13: Error Code TLV

   where fields are defined as the following:

   o  Error Code Type - TBA9 allocated by IANA Section 5.1

   o  Length - two octets long field equals length on the Value field in
      octets.

   o  Code - one octet-long field.  It specifies the reason for an
      error.  Valid values are defined in Section 5.5.

   o  Sub-Code - one octet-long field.  It provides additional
      information to the Code field.  Valid values are defined in
      Section 5.5.

   o  Reserved - two octets-long field.  MUST be zeroed on transmission
      and ignored upon receipt.

   o  Received Packet - a copy of the problematic STAMP test packet,
      less four octets than the value in the Length field.

   A Session-Reflector that encountered a problem processing a TLV in
   the Extended STAMP test packet SHOULD include the Error Code TLV in
   the reflected test packet.  TThe Session-Reflector MUST set the
   Length field's value in the Error Code TLV equal to the Length field
   of the problematic TLV in the received test packet.  The Session-
   Reflector MUST use Code and Sub-Code values to characterize the
   encountered problem using the Error Code and Error Sub-Code sub-
   registries created by IANA (Section 5.5).  The Session-Reflector MUST
   copy the problematic TLV in the received test packet, starting from
   its Type field but less four octets, into the Received Packet field.

And here the text that specifies the handling of an unknown Type:
NEW TEXT:
      if an implementation does not recognize the value in the Type
      field it MUST include the Error Code TLV into the reflected STAMP
      packet setting the Code field to the value Unrecognized Type
      Table 10.  Processing of the Length and Received Packet fields
      described in Section 4.9.

Also, a new sub-section added into IANA Considerations:
NEW TEXT:
5.5.  Error Code and Error Sub-Code Sub-registries

   IANA is requested to create Error Code and Error Sub-Code sub-
   registries as part of the STAMP TLV Type registry.  All code points
   in the range 1 through 127 in these registries shall be allocated
   according to the "IETF Review" procedure as specified in [RFC8126].
   Code points in the range 128 through 239 in these registries shall be
   allocated according to the "First Come First Served" procedure as
   specified in [RFC8126].  Remaining code points are allocated
   according to Table 9:

          +-----------+--------------+-------------------------+
          | Value     | Description  | Reference               |
          +-----------+--------------+-------------------------+
          | 0         |   Reserved   | This document           |
          | 1- 127    |  Unassigned  | IETF Review             |
          | 128 - 239 |  Unassigned  | First Come First Served |
          | 240 - 249 | Experimental | This document           |
          | 250 - 254 | Private Use  | This document           |
          | 255       |   Reserved   | This document           |
          +-----------+--------------+-------------------------+

           Table 9: Error Code and Error Sub-Code Sub-registries

   This document defines the following new values in the Error Code sub-
   registry:

               +-------+-------------------+---------------+
               | Value |    Description    | Reference     |
               +-------+-------------------+---------------+
               | 1     | Unrecognized Type | This document |
               +-------+-------------------+---------------+

                           Table 10: Error Codes

I greatly appreciate your comments and suggestions.

Regards,
Greg

On Mon, Jun 22, 2020 at 6:46 PM Rakesh Gandhi <[email-masked]>
wrote:

>> If that is preferred by everyone, we can certainly roll it in. I can
>> share the new text by tomorrow.
>>
>> Regards,
>> Greg
>>
>>>>> Why not define a new TLV Type called Unsupported TLV? The Value of
>>>>> that TLV can return the whole unsupported TLV including its Type. This way
>>>>> there is no ambiguity. The return packet size may be different but this
>>>>> would be the case when the TLV is consumed by the reflector.
>>>>>
>>>>> My 2c.
>>>>>
>>>>> Thanks,
>>>>> Rakesh
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>    - modified handling of unknown Type values to a "softer"
>>>>>>    approach. The Session-Reflector includes the Extra Padding TLV in the
>>>>>>    reflected packet in place of the unrecognized TLV. That keeps packets
>>>>>>    symmetrical, i..e., the same length;
>>>>>> Nydell <[email-masked]>, Adi Masputra <[email-masked]>, Xiao
>>>>>> Min <[email-masked]>
>>>>>>
>>>>>>
>>>>>>

---

From: Henrik Nydell <[email-masked]>
Date: Tue, 23 Jun 2020 12:26:50 +0200

Hi, I sense a bit of ambiguity in what should be sent back to the sender.
The field is called "Received packet" and it is mentioned that the
reflector should place "a copy of the problematic STAMP test packet" in
this field. But later in the text you mention that only the problematic TLV
(less 4 bytes) should be sent back.

I also believe it should be written out that it is not recommended to make
use of the error TLV if the reflector doesnt recognize the TLV, it should
then just replace the unknown TLV with the Extra Padding TLV as described
in section 4.

On Tue, Jun 23, 2020 at 4:22 AM Greg Mirsky <[email-masked]> wrote:

>    according to the "IETF Review" procedure as specified in [RFC8126]..
>>>>>> approach.. It is better than the ICMP message.
>>>>>>>    - clarified the interoperation between a Session-Sender that
>>>>>>>    uses SSID and a Session-Refletr that does not;
>>>>>>>    - improvements to the text - removed text duplication, added
>>>>>>>    some clarifications..
>>>>>>>
>>>>>>> [email-masked]>, Greg Mirsky <[email-masked]>,
>>>>>>> Henrik Nydell <[email-masked]>, Adi Masputra <[email-masked]>,
>>>>>>> Xiao Min <[email-masked]>
>>>>>>>
>>>>>>>
>>>>>>>

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[email-masked]
<http://accedian.com>
<https://www.facebook.com/accedian/>  <https://twitter.com/Accedian>
<https://ca.linkedin.com/company/accedian>
<http://www.accedian.com>
*accedian.com <http://accedian.com>*

-- 

Avis de confidentialité

Les
 informations contenues dans le présent 
message et dans toute pièce qui 
lui est jointe sont confidentielles et 
peuvent être protégées par le 
secret professionnel. Ces informations sont 
à l’usage exclusif de son ou
 de ses destinataires. Si vous recevez ce 
message par erreur, veuillez 
s’il vous plait communiquer immédiatement 
avec l’expéditeur et en 
détruire tout exemplaire. De plus, il vous est 
strictement interdit de 
le divulguer, de le distribuer ou de le reproduire 
sans l’autorisation 
de l’expéditeur. Merci.

Confidentiality notice

This

 e-mail message and any attachment hereto contain confidential 
information 
which may be privileged and which is intended for the 
exclusive use of its 
addressee(s). If you receive this message in error,
 please inform sender 
immediately and destroy any copy thereof. 
Furthermore, any disclosure, 
distribution or copying of this message 
and/or any attachment hereto 
without the consent of the sender is 
strictly prohibited. Thank you.

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 23 Jun 2020 10:05:33 -0400

Thanks Greg for the proposal.
Perhaps reflector can copy the entire received unrecognized TLV including
Type, Length and Value "as is". The Error Code TLV will have Type -
Unrecognized TLV and Length will include the additional bytes in the Error
code TLV - i.e. it is just a wrapper around it. I am not clear if there is
a need to add Extra Padding TLV instead.

Thanks,
Rakesh

On Tue, Jun 23, 2020 at 6:27 AM Henrik Nydell <[email-masked]> wrote:

>>>>>> I think that is a great idea, thank you! We have several ideas for
>>>>>> new TLVs, would you be interested to discuss and work together on this? I
>>>>>> think the Return Code TLV you've suggested can be added to a new document.
>>>>>> What do you think?
>>>>>>
>>>>>> Regards,
>>>>>> Greg
>>>>>>
> Les informations contenues dans le présent message et dans toute pièce qui
> lui est jointe sont confidentielles et peuvent être protégées par le secret
> professionnel. Ces informations sont à l’usage exclusif de son ou de ses
> destinataires. Si vous recevez ce message par erreur, veuillez s’il vous
> plait communiquer immédiatement avec l’expéditeur et en détruire tout
> exemplaire. De plus, il vous est strictement interdit de le divulguer, de
> le distribuer ou de le reproduire sans l’autorisation de l’expéditeur.
> Merci.
>
> Confidentiality notice
>
> This e-mail message and any attachment hereto contain confidential
> information which may be privileged and which is intended for the exclusive
> use of its addressee(s). If you receive this message in error, please
> inform sender immediately and destroy any copy thereof. Furthermore, any
> disclosure, distribution or copying of this message and/or any attachment
> hereto without the consent of the sender is strictly prohibited. Thank you.
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 23 Jun 2020 07:45:43 -0700

Hi Henrik,
thank you for your comments. Please find my notes in-line below tagged
GIM>>.

Regards,
Greg

> (less 4 bytes) should be sent back.
GIM>> Agree. I've cleaned up the text to refer to the problematic TLV.
NEW TEXT:
4.9.  Error Code TLV

   An Error Code TLV is used by a STAMP Session-Reflector to inform a
   Session-Sender of a problem processing a TLV in the received STAMP
   test packet.  The format of the Error Code TLV is shown in Figure 13.

       0                   1                   2                   3
      ~                          Received TLV                         ~

   o  Received TLV - a copy of the problematic TLV, four octets fewer
      than the Length field value.

   A Session-Reflector that encountered a problem processing a TLV in
   the Extended STAMP test packet SHOULD include the Error Code TLV in
   the reflected test packet.  The Session-Reflector MUST set the Length
   field's value in the Error Code TLV equal to the Length field of the
   problematic TLV in the received test packet.  The Session-Reflector
   MUST use Code and Sub-Code values to characterize the encountered
   problem using the Error Code and Error Sub-Code sub-registries
   created by IANA (Section 5.5).  The Session-Reflector MUST copy the
   problematic TLV, starting from the Type field but less four octets,
   into the Received TLV field.

> then just replace the unknown TLV with the Extra Padding TLV as described
GIM>> There might be a situation when a Session-Reflector doesn't recognize
more than one TLV. I think that returning more information about that TLV
than could be available in the Extra Padding TLV is beneficial. Please note
that the proposal replaces the text in Section 4:
NEW TEXT:
      if an implementation does not recognize the value in the Type
      field it MUST include the Error Code TLV into the reflected STAMP
      packet setting the Code field to the value Unrecognized Type
      Table 10.  Processing of the Length and Received TLV fields
      described in Section 4.9.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 23 Jun 2020 07:56:14 -0700

Hi Rakesh,
thank you for your comments, suggestions. I had two objectives in mind when
proposing to copy Length- 4 octets:

   - return a sufficient amount of information about the problematic TLV to
   the Session-Sender;
   - keep test packets symmetric, i.e., the length of the reflected packet
   is the same as the length of the packet transmitted by the Session-Sender.

I can imagine how using the Extra Padding TLV as described in -06 allows
the Session-Sender to find which TLV(s) were not processed by the
Session-Reflector. But I like that the Error Code TLV explicitly provides
that information and may be used in error handling in other scenarios.

Regards,
Greg

On Tue, Jun 23, 2020 at 7:05 AM Rakesh Gandhi <[email-masked]>
wrote:

>> I also believe it should be written out that it is not recommended to
>> make use of the error TLV if the reflector doesnt recognize the TLV, it
>> should then just replace the unknown TLV with the Extra Padding TLV as
>> described in section 4.
>>
>>
>>>>>>> On Mon, Jun 22, 2020 at 4:41 PM Rakesh Gandhi <
>>>>>>> [email-masked]> wrote:
>>>>>>>
>>>>>>>> Hi Greg,
>>>>>>>>> Title:          Simple Two-way Active Measurement Protocol
>>>>>>>>> Optional Extensions
>> Les informations contenues dans le présent message et dans toute pièce
>> qui lui est jointe sont confidentielles et peuvent être protégées par le
>> secret professionnel. Ces informations sont à l’usage exclusif de son ou de
>> ses destinataires. Si vous recevez ce message par erreur, veuillez s’il
>> vous plait communiquer immédiatement avec l’expéditeur et en détruire tout

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 23 Jun 2020 11:06:42 -0400

Thanks Greg for the reply.
Some TLVs may be consumed by the reflector successfully. Is it expected in
the draft that reflectors always add Extra Padding TLV and return a
symmetric size packet in that case also? If that is not the case, then the
reflector can return the entire unrecognized TLV to avoid missing useful
data if the TLV was very small (e.g. just 4 byte size).

Thanks,
Rakesh

On Tue, Jun 23, 2020 at 10:56 AM Greg Mirsky <[email-masked]> wrote:

> Hi Rakesh,
> thank you for your comments, suggestions. I had two objectives in mind
> when proposing to copy Length- 4 octets:
>
>    - return a sufficient amount of information about the problematic TLV
>    to the Session-Sender;
>    - keep test packets symmetric, i.e., the length of the reflected
>    packet is the same as the length of the packet transmitted by the
>    Session-Sender.
>
>>> Hi, I sense a bit of ambiguity in what should be sent back to the
>>> sender. The field is called "Received packet" and it is mentioned that the
>>>>>>>>> One comment regarding handling of unknown Type values to a
>>>>>>>>> "softer" approach.. It is better than the ICMP message.
>>>>>>>>>> the new version includes updates to address one comment from WG
>>>>>>>>>> LC (thank you, Yali Wang), and the comments from AD review (many thanks,
>>>>>>>>>> Martin):
>>>>>>>>>>

---

From: Henrik Nydell <[email-masked]>
Date: Tue, 23 Jun 2020 17:27:44 +0200

Hi Greg, see below tagged HN>>

On Tue, Jun 23, 2020 at 4:45 PM Greg Mirsky <[email-masked]> wrote:

> GIM>> There might be a situation when a Session-Reflector doesn't
> recognize more than one TLV. I think that returning more information about
> that TLV than could be available in the Extra Padding TLV is beneficial.
> Please note that the proposal replaces the text in Section 4:
> NEW TEXT:

HN>> I propose not using error TLV if the session reflector is not familiar
with that TLV, but instead the currently proposed method in section 4 in
that case. This makes it easier for the session sender to determine if a
reflector supports the TLV or not, or if it is determined supported but
reflector deems it erroneous.

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[email-masked]
<http://accedian.com>

-- 

Avis de confidentialité

Les

Confidentiality notice

This

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 23 Jun 2020 08:31:47 -0700

Hi Rakesh,
I think that there could be a case, though it might be a corner case when
adding four octets per unrecognized TLV will make the reflected packet too
big for MTU at hand. On the other hand, another error handling might handle
the Received TLV field differently. I've updated the text to make it
specific to the Unrecognized Type error:
   A Session-Reflector that encountered a problem processing a TLV in
   the Extended STAMP test packet SHOULD include the Error Code TLV in
   the reflected test packet.  The Session-Reflector MUST set the Length
   field's value in the Error Code TLV equal to the Length field of the
   problematic TLV in the received test packet.  The handling of the
   Received TLV field in the reflected packet depends on the Error Code
   value.  This specification defines that if the Error Code is
   Unrecognized Type, then the Session-Reflector MUST use Code and Sub-
   Code values to characterize the encountered problem using the Error
   Code and Error Sub-Code sub-registries created by IANA (Section 5.5).
   The Session-Reflector MUST copy the problematic TLV, starting from
   the Type field but less four octets, into the Received TLV field.

The intention is to allow other methods of handling errors in other
scenarios.
What do you think?

Regards,
Greg

On Tue, Jun 23, 2020 at 8:06 AM Rakesh Gandhi <[email-masked]>
wrote:

>>> Perhaps reflector can copy the entire received unrecognized TLV
>>> including Type, Length and Value "as is". The Error Code TLV will have Type
>>> - Unrecognized TLV and Length will include the additional bytes in the
>>> Error code TLV - i.e. it is just a wrapper around it. I am not clear if
>>> there is a need to add Extra Padding TLV instead.
>>>
>>> Thanks,
>>> Rakesh
>>>
>>>
>>>
>>>
>>>
>>>
>>>>>>>>>> Why not define a new TLV Type called Unsupported TLV? The Value
>>>>>>>>>> of that TLV can return the whole unsupported TLV including its Type. This
>>>>>>>>>> way there is no ambiguity. The return packet size may be different but this
>>>>>>>>>>> Henrik Nydell <[email-masked]>, Adi Masputra <
>>>>>>>>>>> [email-masked]>, Xiao Min <[email-masked]>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 23 Jun 2020 08:59:09 -0700

Hi Henrik,
I agree, that the unrecognized TLV type can be handled as described in
section 4 of the version -06:
      if an implementation does not recognize the value in the Type
      field it MUST include the Extra Padding TLV into the reflected
      STAMP packet.  The Length field MUST be set equal to the value of
      the Length field of that TLV.  The size of the Value field MUST
      equal the value of the Length field.  Then proceed to process the
      next TLV if any present;
On the other hand, this scenario might be handled using the Error Code TLV.
Also, the Error TLV can be used to handle other cases when an
Session-Reflector needs to report an error to the Session-Sender. For
example, that might be a problem processing specific TLV we define in the
future specifications.

Regards,
Greg

On Tue, Jun 23, 2020 at 8:27 AM Henrik Nydell <[email-masked]> wrote:

> HN>> I propose not using error TLV if the session reflector is not
> familiar with that TLV, but instead the currently proposed method in
> section 4 in that case. This makes it easier for the session sender to
> determine if a reflector supports the TLV or not, or if it is determined
> supported but reflector deems it erroneous.
>
>
>
>
>>>

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 23 Jun 2020 13:19:21 -0400

Hi Greg,
If the reflector also returns the unrecognized TLV (just like unsupported
TLV), it will be easier to identify it at the sender without ambiguity, as
compared to sending the Extra padding TLV.
My 2c.
Thanks,
Rakesh

On Tue, Jun 23, 2020 at 11:59 AM Greg Mirsky <[email-masked]> wrote:

> On the other hand, this scenario might be handled using the Error Code
> TLV. Also, the Error TLV can be used to handle other cases when an

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 23 Jun 2020 13:36:10 -0400

Hi Greg,
The text could make it flexible to allow the return of the full or
truncated TLV.

Thanks,
Rakesh

On Tue, Jun 23, 2020 at 11:32 AM Greg Mirsky <[email-masked]> wrote:

>> Some TLVs may be consumed by the reflector successfully. Is it expected
>> in the draft that reflectors always add Extra Padding TLV and return a
>>>    - return a sufficient amount of information about the problematic
>>>    TLV to the Session-Sender;
>>>>>>       ~                        Received Packet
>>>>>>  ~
>>>>>>> I think this document should have some generic handling. There can
>>>>>>> be generic return codes and also return of the unsupported TLVs. It could
>>>>>>> be one combo tlv with sub-tlvs or two separate tlvs.
>>>>>>> Thanks,
>>>>>>> Rakesh
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon., Jun. 22, 2020, 8:07 p.m. Greg Mirsky, <
>>>>>>> [email-masked]> wrote:
>>>>>>>
>>>>>>>> If that is preferred by everyone, we can certainly roll it in. I
>>>>>>>> can share the new text by tomorrow.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Greg
>>>>>>>>
>>>>>>>>>> I think that is a great idea, thank you! We have several ideas
>>>>>>>>>> for new TLVs, would you be interested to discuss and work together on this?
>>>>>>>>>> I think the Return Code TLV you've suggested can be added to a new
>>>>>>>>>> document. What do you think?
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Greg
>>>>>>>>>>
>>>>>>>>>>>>    - clarified the interoperation between a Session-Sender
>>>>>>>>>>>>    that uses SSID and a Session-Refletr that does not;
>>>>>>>>>>>>    - improvements to the text - removed text duplication,
>>>>>>>>>>>>    added some clarifications..
>>>>>>>>>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 23 Jun 2020 11:59:36 -0700

Hi Rakesh,
I agree and I think that the latest version allows for such flexibility:
   A Session-Reflector that encountered a problem processing a TLV in
   the Extended STAMP test packet SHOULD include the Error Code TLV in
   the reflected test packet.  The Session-Reflector MUST set the Length
   field's value in the Error Code TLV equal to the Length field of the
   problematic TLV in the received test packet.  The handling of the
   Received TLV field in the reflected packet depends on the Error Code
   value.  This specification defines the Unrecognized Type as a new

   Error Code.  For the case of the Unrecognized Type, the Session-
   Reflector:

   o  MUST set the Length field's value in Error Code equal to the
      Length field's value in the received problematic TLV;

   o  MUST copy the problematic TLV, starting from the Type field but
      less four octets, into the Received TLV field.

As you see, handling of Length and Received TLV fields is defined based on
an Error Code. For the case of the Unrecognized Type error, returning only
the first four octets might be sufficient. To keep test packets
symmetrical, I've proposed to use the received TLV. For other cases, we
might define another mechanism to populate Length and Received TLV fields.
Attached, please find the new working version of the draft and the diff to
-06. Please review and share your comments.

I think that to continue moving this document, we need guidance from WG
Chairs and our AD.
Dear Ian, Tommy, and Martin,
please consider the discussion and share your thoughts on what should be
done next.

Regards,
Greg

On Tue, Jun 23, 2020 at 10:36 AM Rakesh Gandhi <[email-masked]>
wrote:

>>>> I can imagine how using the Extra Padding TLV as described in -06
>>>> allows the Session-Sender to find which TLV(s) were not processed by the
>>>>>>> On Mon, Jun 22, 2020 at 6:46 PM Rakesh Gandhi <
>>>>>>>>>>>>> the new version includes updates to address one comment from
>>>>>>>>>>>>> WG LC (thank you, Yali Wang), and the comments from AD review (many thanks,
>>>>>>>>>>>>> Martin):
>>>>>>>>>>>>>
>>>>>> Les informations contenues dans le présent message et dans toute
>>>>>> pièce qui lui est jointe sont confidentielles et peuvent être protégées par
>>>>>> le secret professionnel. Ces informations sont à l’usage exclusif de son ou
>>>>>> de ses destinataires. Si vous recevez ce message par erreur, veuillez s’il

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 23 Jun 2020 16:51:44 -0400

Thanks Greg.
I think I am missing something.
The Error code TLV adds 8 more bytes to the Unrecognized TLV (4 bytes for
the "Code/Subcode/Reserved" part and 4 bytes for the "Type/Length" part of
the Unrecognized TLV.

I also do not see the flexibility to return entire/truncated. TLV. It says
following with MUST:

The Session-Reflector MUST set the Length
   field's value in the Error Code TLV equal to the Length field of the
   problematic TLV in the received test packet.

Also, if there are more than one Unrecognized TLV, will the reflector add
an Error code TLV for each of them?

Thanks,
Rakesh

On Tue, Jun 23, 2020 at 2:59 PM Greg Mirsky <[email-masked]> wrote:

>>> I think that there could be a case, though it might be a corner case
>>> when adding four octets per unrecognized TLV will make the reflected packet
>>> too big for MTU at hand. On the other hand, another error handling might
>>> handle the Received TLV field differently. I've updated the text to make it
>>>>>>> I also believe it should be written out that it is not recommended
>>>>>>> to make use of the error TLV if the reflector doesnt recognize the TLV, it
>>>>>>>>>>>>> Why not define a new TLV Type called Unsupported TLV? The
>>>>>>>>>>>>> Value of that TLV can return the whole unsupported TLV including its Type.
>>>>>>>>>>>>> This way there is no ambiguity. The return packet size may be different but
>>>>>>>>>>>>> this would be the case when the TLV is consumed by the reflector.
>>>>>>>>>>>>>
>>>>>>>>>>>>> My 2c.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Rakesh
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 23 Jun 2020 14:08:37 -0700

Hi Rakesh,
you're right, to keep packets symmetrical we must leave not four but eight
octets out. Since several TLVs defined in the draft, e.g., Timestamp
Information, CoS, are only 8 octets long, that is a problem I've missed.
Thank you for pointing that out. One option, brute-force approach - make
TLVs at least 12 octets long. Any other suggestions?
The requirement is to ensure that test packets are symmetrical. If we
decide that is not required, then the text can be modified accordingly.
As for your second question, as defined in Section 4, a Session-Reflector
will continue parsing the received test packet and, as the result, multiple
Error Code TLVs might be added into the reflected packet.

Regards,
Greg

On Tue, Jun 23, 2020 at 1:51 PM Rakesh Gandhi <[email-masked]>
wrote:

>> As you see, handling of Length and Received TLV fields is defined based
>> on an Error Code. For the case of the Unrecognized Type error, returning
>> only the first four octets might be sufficient. To keep test packets
>> Attached, please find the new working version of the draft and the diff
>> to -06. Please review and share your comments.
>>
>>>>> Some TLVs may be consumed by the reflector successfully. Is it
>>>>> expected in the draft that reflectors always add Extra Padding TLV and
>>>>> return a symmetric size packet in that case also? If that is not the case,
>>>>> then the reflector can return the entire unrecognized TLV to avoid missing
>>>>> useful data if the TLV was very small (e.g. just 4 byte size).
>>>>>
>>>>> Thanks,
>>>>> Rakesh
>>>>>
>>>>>
>>>>>> thank you for your comments, suggestions. I had two objectives in
>>>>>> mind when proposing to copy Length- 4 octets:
>>>>>>
>>>>>>>>>        0                   1                   2
>>>>>>>>> 3
>>>>>>>>>> I think this document should have some generic handling. There
>>>>>>>>>> can be generic return codes and also return of the unsupported TLVs. It
>>>>>>>>>> could be one combo tlv with sub-tlvs or two separate tlvs.
>>>>>>>>>> Thanks,
>>>>>>>>>> Rakesh
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>>    - simplified allocation of the Type values by merging
>>>>>>>>>>>>>>>    the Mandatory and optional ranges of values into one;

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 23 Jun 2020 17:33:14 -0400

Hi Greg,
Not sure if the following option was considered, i.e. using the Reserved
field. Also, text could be flexible to say truncate it if a symmetrical
packet is required or there is MTU limitation else no need to truncate.

| Error Code Type               | Length = Unrecognized TLV Len |

| Code          |      Sub-Code | Unrecognized TLV Type         |

~ Value field from Received Unrecognized TLV Truncated by 4 Bytes ~

| Error Code Type               | Length = Unrecognized TLV Len+4 |

| Code          |      Sub-Code | Unrecognized TLV Type         |

~ Value field from Received Unrecognized TLV                    ~

Thanks,

Rakesh

On Tue, Jun 23, 2020 at 5:08 PM Greg Mirsky <[email-masked]> wrote:

>> I also do not see the flexibility to return entire/truncated. TLV. It
>> says following with MUST:
>>
>>>>>>>    - return a sufficient amount of information about the
>>>>>>>    problematic TLV to the Session-Sender;
>>>>>>> On Tue, Jun 23, 2020 at 7:05 AM Rakesh Gandhi <
>>>>>>>>>>>> If that is preferred by everyone, we can certainly roll it in.
>>>>>>>>>>>> I can share the new text by tomorrow.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Greg
>>>>>>>>>>>>
>>>>>>>>>>>>>> I think that is a great idea, thank you! We have several
>>>>>>>>>>>>>> ideas for new TLVs, would you be interested to discuss and work together on
>>>>>>>>>>>>>> this? I think the Return Code TLV you've suggested can be added to a new
>>>>>>>>>>>>>>>> the new version includes updates to address one comment
>>>>>>>>>>>>>>>> from WG LC (thank you, Yali Wang), and the comments from AD review (many
>>>>>>>>>>>>>>>> thanks, Martin):
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>    - modified handling of unknown Type values to a
>>>>>>>>>>>>>>>>    "softer" approach. The Session-Reflector includes the Extra Padding TLV in
>>>>>>>>>>>>>>>>    the reflected packet in place of the unrecognized TLV. That keeps packets

---

From: Martin Duke <[email-masked]>
Date: Tue, 23 Jun 2020 14:40:51 -0700

Speaking as an individual, another way to go would be to use only 15 bits
for the type and have the first bit be an error indicator.

On Tue, Jun 23, 2020 at 2:34 PM Rakesh Gandhi <[email-masked]>
wrote:

>> you're right, to keep packets symmetrical we must leave not four but
>> eight octets out. Since several TLVs defined in the draft, e.g., Timestamp
>>> The Error code TLV adds 8 more bytes to the Unrecognized TLV (4 bytes
>>> for the "Code/Subcode/Reserved" part and 4 bytes for the "Type/Length" part
>>> of the Unrecognized TLV.
>>>
>>> I also do not see the flexibility to return entire/truncated.. TLV. It
>>> Also, if there are more than one Unrecognized TLV, will the reflector
>>> add an Error code TLV for each of them?
>>>
>>> Thanks,
>>> Rakesh
>>>
>>>
>>>
>>>> please consider the discussion and share your thoughts on what should
>>>> be done next.
>>>>
>>>> Regards,
>>>> Greg
>>>>
>>>>
>>>>>>>>    - keep test packets symmetric, i.e., the length of the
>>>>>>>>    reflected packet is the same as the length of the packet transmitted by the
>>>>>>>>    Session-Sender.
>>>>>>>>
>>>>>>>>> On Tue, Jun 23, 2020 at 6:27 AM Henrik Nydell <
>>>>>>>>> [email-masked] <hnydell@accedian..com>> wrote:
>>>>>>>>>
>>>>>>>>>> I also believe it should be written out that it is not
>>>>>>>>>> recommended to make use of the error TLV if the reflector doesnt recognize
>>>>>>>>>> the TLV, it should then just replace the unknown TLV with the Extra Padding
>>>>>>>>>> TLV as described in section 4..
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>    packet.  The format of the Error Code TLV is shown in Figure
>>>>>>>>>>> 13..
>>>>>>>>>>>
>>>>>>>>>>>        0                   1                   2
>>>>>>>>>>>   3
>>>>>>>>>>>>>>>>>    - clarified the interoperation between a
>>>>>>>>>>>>>>>>>    Session-Sender that uses SSID and a Session-Refletr that does not;
>>>>>>>>>>>>>>>>> [email-masked]>, Greg Mirsky <
>>>>>>>>>>>>>>>>> [email-masked]>, Henrik Nydell <
>>>>>>>>>>>>>>>>> [email-masked]>, Adi Masputra <[email-masked]>, Xiao
>>>>>>>>>>>>>>>>> Min <[email-masked]..cn <[email-masked]>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> A new version of I-D,
>>>>>>>>>> This e-mail message and any attachment hereto contain
>>>>>>>>>> confidential information which may be privileged and which is intended for
>>>>>>>>>> the exclusive use of its addressee(s). If you receive this message in
>>>>>>>>>> error, please inform sender immediately and destroy any copy thereof.
>>>>>>>>>> Furthermore, any disclosure, distribution or copying of this message and/or
>>>>>>>>>> any attachment hereto without the consent of the sender is strictly
>>>>>>>>>> prohibited. Thank you.
>>>>>>>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 23 Jun 2020 15:09:01 -0700

Hi Martin,
very elegant mechanism, thank you. That definitely solves the problem of
the unrecognized type. Or, in general, this can be interpreted as Failed to
Process TLV though without specifying the reason for the failure. If more
information is needed from the Session-Reflector, then we may add a
mandatory four octets immediately following the Type and Length fields in
each TLV:

   - Error code - one octet
   - Error Sub-code - one octet
   - Pointer - two octets, offset in octets off the Type field pointing to
   the problematic field

What do you think?

Regards,
Greg

On Tue, Jun 23, 2020 at 2:41 PM Martin Duke <[email-masked]> wrote:

>>> As for your second question, as defined in Section 4, a
>>> Session-Reflector will continue parsing the received test packet and, as
>>> the result, multiple Error Code TLVs might be added into the reflected
>>> packet.
>>>
>>> Regards,
>>> Greg
>>>
>>>>> As you see, handling of Length and Received TLV fields is defined
>>>>> based on an Error Code. For the case of the Unrecognized Type error,
>>>>> returning only the first four octets might be sufficient. To keep test
>>>>> packets symmetrical, I've proposed to use the received TLV. For other
>>>>> cases, we might define another mechanism to populate Length and Received
>>>>> TLV fields.
>>>>> Attached, please find the new working version of the draft and the
>>>>> diff to -06. Please review and share your comments.
>>>>>
>>>>> I think that to continue moving this document, we need guidance from
>>>>> WG Chairs and our AD.
>>>>>>> On Tue, Jun 23, 2020 at 8:06 AM Rakesh Gandhi <
>>>>>>>>>>> Hi, I sense a bit of ambiguity in what should be sent back to
>>>>>>>>>>> the sender. The field is called "Received packet" and it is mentioned that
>>>>>>>>>>> the reflector should place "a copy of the problematic STAMP test packet" in
>>>>>>>>>>>>>> If that is preferred by everyone, we can certainly roll it
>>>>>>>>>>>>>> in. I can share the new text by tomorrow.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>    - improvements to the text - removed text
>>>>>>>>>>>>>>>>>>    duplication, added some clarifications..
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> To: Ernesto Ruffini <[email-masked]>, Richard Foote
>>>>>>>>>>>>>>>>>> <[email-masked]>, Greg Mirsky <
>>>>>>>>>>>>>>>>>> [email-masked]>, Adi Masputra <[email-masked]>,
>>>>>>>>>>>>>>>>>> Xiao Min <[email-masked]..cn <[email-masked]>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A new version of I-D,
>>>>>>>>>>>>>>>>>> Title:          Simple Two-way Active Measurement
>>>>>>>>>>>>>>>>>> Protocol Optional Extensions

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 23 Jun 2020 18:15:54 -0400

Hi Martin,
It would work for Unrecognized TLV Type Error Code. We may still need Error
Code TLV for the other generic error codes that we may define in future,
e.g. invalid SSID.

Thanks,
Rakesh

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 25 Jun 2020 14:10:28 -0700

Hi Martin, Rakesh, et al.,
I've taken Martin's idea and made changes in the working version of the
draft (attached along with the diff). I think that it provides the "soft"
handling for the Unrecognized TLV case we've been trying to put into the
protocol. I agree with Rakesh, that the Error Code TLV can be useful for
other cases. But  I think that that work might be deferred for the new
document.
Please share your comments, questions, and suggestions.

Regards,
Greg

On Tue, Jun 23, 2020 at 3:16 PM Rakesh Gandhi <[email-masked]>
wrote:

> Hi Martin,
> It would work for Unrecognized TLV Type Error Code. We may still need
> Error Code TLV for the other generic error codes that we may define in
> future, e.g. invalid SSID.
>
> Thanks,
> Rakesh
>
>
>>>>>> On Tue, Jun 23, 2020 at 10:36 AM Rakesh Gandhi <
>>>>>>>> I think that there could be a case, though it might be a corner
>>>>>>>> case when adding four octets per unrecognized TLV will make the reflected
>>>>>>>> packet too big for MTU at hand. On the other hand, another error handling
>>>>>>>> might handle the Received TLV field differently. I've updated the text to
>>>>>>>> make it specific to the Unrecognized Type error:
>>>>>>>>>>>>>    packet.  The format of the Error Code TLV is shown in
>>>>>>>>>>>>> Figure 13..
>>>>>>>>>>>>>
>>>>>>>>>>>>>        0                   1                   2
>>>>>>>>>>>>>     3
>>>>>>>>>>>>>> I think this document should have some generic handling.
>>>>>>>>>>>>>> There can be generic return codes and also return of the unsupported TLVs.
>>>>>>>>>>>>>> It could be one combo tlv with sub-tlvs or two separate tlvs.
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Rakesh
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> One comment regarding handling of unknown Type values to
>>>>>>>>>>>>>>>>>> a "softer" approach.. It is better than the ICMP message.
>>>>>>>>>>>>>>>>>>>    - simplified allocation of the Type values by
>>>>>>>>>>>>>>>>>>>    merging the Mandatory and optional ranges of values into one;
>>>>>>>>>>>>>>>>>>> To: Ernesto Ruffini <[email-masked]>, Richard
>>>>>>>>>>>>>>>>>>> Foote <[email-masked]>, Greg Mirsky <
>>>>>>>>>>>> Les informations contenues dans le présent message et dans
>>>>>>>>>>>> toute pièce qui lui est jointe sont confidentielles et peuvent être
>>>>>>>>>>>> protégées par le secret professionnel. Ces informations sont à l’usage
>>>>>>>>>>>> exclusif de son ou de ses destinataires. Si vous recevez ce message par
>>>>>>>>>>>> erreur, veuillez s’il vous plait communiquer immédiatement avec
>>>>>>>>>>>> l’expéditeur et en détruire tout exemplaire. De plus, il vous est
>>>>>>>>>>>> strictement interdit de le divulguer, de le distribuer ou de le reproduire
>>>>>>>>>>>> sans l’autorisation de l’expéditeur. Merci.
>>>>>>>>>>>>
>>>>>>>>>>>> Confidentiality notice
>>>>>>>>>>>>

---

From: Rakesh Gandhi <[email-masked]>
Date: Fri, 26 Jun 2020 12:40:56 -0400

Thanks Greg for the updates.
The update covers the case when the TLV is not recognized by the reflector.
The other cases, such as (1) TLV is recognized but not supported, (2) TLV
has an error such as wrong length or value, are not covered by the draft.
Wonder if a few bits can be reserved in the Type field to help with future
extensions. Maybe 1K-2K Types are plenty.

thanks,
Rakesh

On Thu, Jun 25, 2020 at 5:10 PM Greg Mirsky <[email-masked]> wrote:

>>> Speaking as an individual, another way to go would be to use only 15
>>> bits for the type and have the first bit be an error indicator.
>>>
>>>> Not sure if the following option was considered, i.e. using the
>>>> Reserved field. Also, text could be flexible to say truncate it if a
>>>> symmetrical packet is required or there is MTU limitation else no need to
>>>> truncate.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>> I also do not see the flexibility to return entire/truncated.. TLV.
>>>>>> It says following with MUST:
>>>>>>
>>>>>>> please consider the discussion and share your thoughts on what
>>>>>>> should be done next.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Greg
>>>>>>>
>>>>>>>
>>>>>>>>> The intention is to allow other methods of handling errors in
>>>>>>>>> other scenarios.
>>>>>>>>> What do you think?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Greg
>>>>>>>>>
>>>>>>>>>>> thank you for your comments, suggestions. I had two objectives
>>>>>>>>>>> in mind when proposing to copy Length- 4 octets:
>>>>>>>>>>>
>>>>>>>>>>> I can imagine how using the Extra Padding TLV as described in
>>>>>>>>>>> -06 allows the Session-Sender to find which TLV(s) were not processed by
>>>>>>>>>>> the Session-Reflector. But I like that the Error Code TLV explicitly
>>>>>>>>>>> provides that information and may be used in error handling in other
>>>>>>>>>>> scenarios.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Greg
>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Why not define a new TLV Type called Unsupported TLV?
>>>>>>>>>>>>>>>>>>> The Value of that TLV can return the whole unsupported TLV including its
>>>>>>>>>>>>>>>>>>> Type. This way there is no ambiguity. The return packet size may be
>>>>>>>>>>>>>>>>>>> different but this would be the case when the TLV is consumed by the
>>>>>>>>>>>>>>>>>>> reflector.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> My 2c.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>> Rakesh
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 26 Jun 2020 12:22:29 -0700

Hi Rakesh,
thank you for your helpful comments. Please find my answers, notes in-line
tagged GIM>>.

Regards,
Greg

On Fri, Jun 26, 2020 at 9:41 AM Rakesh Gandhi <[email-masked]>
wrote:

> The other cases, such as (1) TLV is recognized but not supported,
>
GIM>> Do you see this as a different case from the Not recognized? What
could be the difference between these two cases from the test operator's
point of view?
GIM>> I've compared how Type and Length error handling specified in Section
4. In the latter case processing of the extensions stopped. Should the same
be done in the former case? Or a system might try to process the next TLV?
And if the latter, what normative language to use - MAY, SHOULD or MUST? I
think that continuing processing is a good approach but that be left as
optional, i.e., use MAY. What do you think?

(2) TLV has an error such as wrong length or value, are not covered by the
> draft.
GIM>> I think that we have covered this case in the following part of
Section 4:
      fixed-size TLVs are verified that the Length field value equals
      the value defined for the particular type.  If the values are not
      equal, the processing of extension TLVs MUST be stopped.  Also, if
      the system is the Session-Reflector, it MUST send the ICMP
      Parameter Problem message with Code set to 0 and the Pointer
      referring to the Length field of the TLV.
This was part of the specification and, as I understand, the WG agreed to
the procedure.

>>>>>>> The Error code TLV adds 8 more bytes to the Unrecognized TLV (4
>>>>>>> bytes for the "Code/Subcode/Reserved" part and 4 bytes for the
>>>>>>> "Type/Length" part of the Unrecognized TLV.
>>>>>>>
>>>>>>> Also, if there are more than one Unrecognized TLV, will the
>>>>>>> reflector add an Error code TLV for each of them?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rakesh
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I think that to continue moving this document, we need guidance
>>>>>>>> from WG Chairs and our AD.
>>>>>>>>>>>>> Perhaps reflector can copy the entire received unrecognized
>>>>>>>>>>>>> TLV including Type, Length and Value "as is". The Error Code TLV will have
>>>>>>>>>>>>> Type - Unrecognized TLV and Length will include the additional bytes in the
>>>>>>>>>>>>>>>>>>>> One comment regarding handling of unknown Type values
>>>>>>>>>>>>>>>>>>>> to a "softer" approach.. It is better than the ICMP message.
>>>>>>>>>>>>>>>>>>>>> the new version includes updates to address one
>>>>>>>>>>>>>>>>>>>>> comment from WG LC (thank you, Yali Wang), and the comments from AD review
>>>>>>>>>>>>>>>>>>>>> (many thanks, Martin):
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Xiao Min <[email-masked]..cn <[email-masked]>
>>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> A new version of I-D,

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 29 Jun 2020 08:21:30 -0400

Hi Greg,

Many thanks for your reply. Please see comments inline with <RG>...

> could be the difference between these two cases from the test operator's

<RG> Unsupported means recognized but software doesn't support some or all
aspects of the TLV.

> GIM>> I've compared how Type and Length error handling specified in
> Section 4. In the latter case processing of the extensions stopped. Should
> the same be done in the former case? Or a system might try to process the
> next TLV? And if the latter, what normative language to use - MAY, SHOULD
> or MUST? I think that continuing processing is a good approach but that be
> left as optional, i.e., use MAY. What do you think?
>

<RG> Perhaps - SHOULD stop processing and return error? Not sure why
continue if there is a fatal error in length processing.

>       referring to the Length field of the TLV.

<RG> Why use a different protocol (ICMP) for error handling while it can be
done within the same protocol (STAMP)? Makes it easier to implement in the
same protocol.

>> Wonder if a few bits can be reserved in the Type field to help with
>> future extensions. Maybe 1K-2K Types are plenty.
>>
>
<RG> Any thoughts on this?

Thanks,
Rakesh

>>>>>>> The requirement is to ensure that test packets are symmetrical. If
>>>>>>> we decide that is not required, then the text can be modified accordingly.
>>>>>>> On Tue, Jun 23, 2020 at 1:51 PM Rakesh Gandhi <
>>>>>>>>>> The text could make it flexible to allow the return of the full
>>>>>>>>>> or truncated TLV.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Rakesh
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>> Hi, I sense a bit of ambiguity in what should be sent back
>>>>>>>>>>>>>>> to the sender. The field is called "Received packet" and it is
>>>>>>>>>>>>>>> mentioned that the reflector should place "a copy of the problematic STAMP
>>>>>>>>>>>>>>> test packet" in this field. But later in the text you mention that only the
>>>>>>>>>>>>>>> problematic TLV (less 4 bytes) should be sent back.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> If that is preferred by everyone, we can certainly roll
>>>>>>>>>>>>>>>>>> it in. I can share the new text by tomorrow.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I think that is a great idea, thank you! We have
>>>>>>>>>>>>>>>>>>>> several ideas for new TLVs, would you be interested to discuss and work
>>>>>>>>>>>>>>>>>>>> together on this? I think the Return Code TLV you've suggested can be added
>>>>>>>>>>>>>>>>>>>> to a new document. What do you think?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>> Greg
>>>>>>>>>>>>>>>>>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 29 Jun 2020 13:38:39 -0700

Hi Rakesh,
thank you for the great discussion. We've followed your suggestion to
extend the number of error flags in STAMP TLV. Attached is the updated
working version of the draft and its diff to -06 version.

Best regards,
Greg

On Mon, Jun 29, 2020 at 5:21 AM Rakesh Gandhi <[email-masked]>
wrote:

>> thank you for your helpful comments. Please find my answers, notes
>> in-line tagged GIM>>.
>>
>> Regards,
>> Greg
>>
>> (2) TLV has an error such as wrong length or value, are not covered by
>>> the draft.
>>>
> <RG> Why use a different protocol (ICMP) for error handling while it can
> be done within the same protocol (STAMP)? Makes it easier to implement in
> the same protocol.
>
>
>>>>>>>> you're right, to keep packets symmetrical we must leave not four
>>>>>>>> but eight octets out. Since several TLVs defined in the draft, e.g.,
>>>>>>>> Timestamp Information, CoS, are only 8 octets long, that is a problem I've
>>>>>>>> missed. Thank you for pointing that out. One option, brute-force approach -
>>>>>>>> make TLVs at least 12 octets long. Any other suggestions?
>>>>>>>>> I also do not see the flexibility to return entire/truncated..
>>>>>>>>> TLV. It says following with MUST:
>>>>>>>>>
>>>>>>>>>> Attached, please find the new working version of the draft and
>>>>>>>>>> the diff to -06. Please review and share your comments.
>>>>>>>>>>
>>>>>>>>>>>>>> thank you for your comments, suggestions. I had two
>>>>>>>>>>>>>> objectives in mind when proposing to copy Length- 4 octets:
>>>>>>>>>>>>>>

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 29 Jun 2020 17:56:17 -0400

Thank you Greg for considering my comments. The changes look good to me.
I have one additional comment. Wonder if the following ICMP error (only one
remained) can also be addressed with an error flag.
  "If HMAC
   verification by the Session-Reflector fails, then an ICMP Parameter
   Problem message MUST be generated (with consideration of limiting the
   rate of error messages).  The Code value MUST be set to 0 and the
   Pointer identifying HMAC Type.

Thanks,
Rakesh

On Mon, Jun 29, 2020 at 4:38 PM Greg Mirsky <[email-masked]> wrote:

>> <RG> Unsupported means recognized but software doesn't support some or
>> all aspects of the TLV.
>>
>>
>>> This was part of the specification and, as I understand, the WG agreed
>>> to the procedure.
>>>
>>>>> I've taken Martin's idea and made changes in the working version of
>>>>> the draft (attached along with the diff). I think that it provides the
>>>>> "soft" handling for the Unrecognized TLV case we've been trying to put into
>>>>> the protocol. I agree with Rakesh, that the Error Code TLV can be useful
>>>>> for other cases. But  I think that that work might be deferred for the new
>>>>> document.
>>>>>>> On Tue, Jun 23, 2020 at 2:34 PM Rakesh Gandhi <
>>>>>>>>>>> As you see, handling of Length and Received TLV fields is
>>>>>>>>>>> defined based on an Error Code. For the case of the Unrecognized Type
>>>>>>>>>>> error, returning only the first four octets might be sufficient. To keep
>>>>>>>>>>> test packets symmetrical, I've proposed to use the received TLV. For other
>>>>>>>>>>>>> I think that there could be a case, though it might be a
>>>>>>>>>>>>> corner case when adding four octets per unrecognized TLV will make the
>>>>>>>>>>>>> reflected packet too big for MTU at hand. On the other hand, another error
>>>>>>>>>>>>> handling might handle the Received TLV field differently. I've updated the
>>>>>>>>>>>>> text to make it specific to the Unrecognized Type error:
>>>>>>>>>>>>>> Some TLVs may be consumed by the reflector successfully. Is
>>>>>>>>>>>>>> it expected in the draft that reflectors always add Extra Padding TLV and
>>>>>>>>>>>>>>> I can imagine how using the Extra Padding TLV as described
>>>>>>>>>>>>>>> in -06 allows the Session-Sender to find which TLV(s) were not processed by
>>>>>>>>>>>>>>>>>>>>>>> One comment regarding handling of unknown Type
>>>>>>>>>>>>>>>>>>>>>>> values to a "softer" approach.. It is better than the ICMP message.
>>>>>>>>>>>>>>>>>>>>>>> Why not define a new TLV Type called Unsupported
>>>>>>>>>>>>>>>>>>>>>>> TLV? The Value of that TLV can return the whole unsupported TLV including
>>>>>>>>>>>>>>>>>>>>>>> its Type. This way there is no ambiguity. The return packet size may be