Subject: Re: [ippm] WGLC for STAMP Extensions

From: wangyali <[email-masked]>
Date: Mon, 1 Jun 2020 08:40:30 +0000

Hi authors and IPPM,

I support its publication. But after reading, I have two questions and comments as follows:

1.       In the draft, I confused a sentence that said ‘The Session-Sender MUST NOT stop the session if it receives a zeroed  SSID field.’ If a STAMP Session-Reflector that does not support this specification and return the zeroed SSID field in the reflected STAMP test packet, the STAMP Session-Sender MUST stop the session. I assume there’s a edit error.

2.       Does the TLV field shown in figure 1 indicate that the STAMP Session-Sender test packet with TLV in unauthenticated mode can contains one or more TLVs defined in this draft? I suggest to give an illustration about the TLV field in the test packet and revise TLV field in figure 1 that is not very clear.

Best regards,
Yali

From: ippm [mailto:[email-masked]] On Behalf Of Ian Swett
Sent: Saturday, May 23, 2020 5:26 AM
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: [ippm] WGLC for STAMP Extensions

Hi IPPM,

At our virtual interim meeting, we decided draft-ietf-ippm-stamp-option-tlv was ready for last call. This email starts a two-week WGLC for this draft.

The latest version can be found here: https://tools.ietf.org/html/draft-ietf-ippm-stamp-option-tlv-04

This last call will end on Monday, June 8th. Please reply to [email-masked]<mailto:[email-masked]> with your reviews and comments.

Thanks,
Ian & Tommy

---

From: Henrik Nydell <[email-masked]>
Date: Mon, 1 Jun 2020 16:31:00 +0200

Hi Ian, see below

On Sat, May 30, 2020 at 1:56 PM Songyuezhong (songyuezhong, IP technology
Research Dept) <[email-masked]> wrote:

> Hi Ian，
>
>
>
> I have read the latest version of this draft，and have some small
> suggestions, hope it is helpful for you.
>
>
>
> For part 4,there list 8 new TLVs, but it seems not detailed enough for
> each TLV about the application scenario and some terms in it, we need guess
> to understand the whole plan.
>
>
>
> Especially for the people who have no background knowledge of each
> application scenario, maybe it is more hard for them to understand.
>
>
>
> So I suggest for each TLV, there should have some pictures and background
> content to help people understand the TLV’s meaning and using method，it
> will be better.
>
>
>
> By the way, I have some doubt about the Location TLV, which is the last-hop router, the reflector or the router before it? And how to indicate if the STAMP packets are send to the wrong Session-Reflector from this TLV?
>
> The STAMP packets are sent towards IP address A with UDP port X. A could
in this scenario be the network-facing IP address of a NAT router. The NAT
router is by some means configured to forward packets coming towards port X
to a client on its NAT:ed subnet, say host C. So the STAMP packet
eventually reaches C which is the reflector device. C shall now populate
the location TLV with information on the destination IP address of the
packet (C) and the destination port.

The STAMP-sender of course always sends packets only towards A, but can
with help of the location TLV see "behind" the firewall and record if the
NAT:ed address C changes for some reason.

>
> And another question is how to use Class of Service TLV to find the misconfigure problem, is it enough?
>
>
>
> Thanks,
> Yuezhong
>
>
>
> *发件人:* ippm [mailto:[email-masked]] *代表 *Ian Swett
> *发送时间:* 2020年5月23日 5:26
> *收件人:* IETF IPPM WG ([email-masked]) <[email-masked]>
> *主题:* [ippm] WGLC for STAMP Extensions
>
>
>
> Hi IPPM,
>
> At our virtual interim meeting, we decided
> draft-ietf-ippm-stamp-option-tlv was ready for last call. This email starts
> a two-week WGLC for this draft.
>
> The latest version can be found here:
> https://tools.ietf.org/html/draft-ietf-ippm-stamp-option-tlv-04
>
> This last call will end on *Monday, June 8th*. Please reply to
> [email-masked] with your reviews and comments.
>
> Thanks,
> Ian & Tommy
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

-- 

*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: Greg Mirsky <[email-masked]>
Date: Mon, 1 Jun 2020 09:03:03 -0700

Hi Yuezhong,
thank you for your comments and suggestions. Please find my notes and
answers in-line under the GIM>> tag.

Regards,
Greg

On Sat, May 30, 2020 at 4:56 AM Songyuezhong (songyuezhong, IP technology

> to understand the whole plan.
GIM>> We have tried to provide a clear technical description of extensions
to help implementers produce interoperable implementations. Describing
various scenarios an extension may be used in was not our main objective.
There are other SDOs that reference STAMP and STAMP TLVs in their
documents. I can mention BBF's WT-390.2 IP Performance Measurement from IP
Edge to Customer Equipment using STAMP, and MEF's MEF-w66 Service OAM for
IP Services. Both documents are in advanced phase and will be published
later this year.

> application scenario, maybe it is more hard for them to understand.
GIM>> Yes, you are correct. Standard documents require a certain level of
knowledge in the particular area of the technology.

> content to help people understand the TLV’s meaning and using method，it
GIM>> That is very helpful suggestion and I think that it can be a basis
for the Applicability of STAMP document. Would you be interested in working
on the new document together?

> GIM>> I hope that Henrik's response clarified one of the use case
scenarios.

> GIM>> One of the possible scenarios could be as follows:

   - STAMP Sender sets DSCP1 to value A
   - STAMP packet is transmitted with DSCP set to A
   - STAMP Reflector copies DSCP value into DSCP2 field
   - reflected STAMP packet is transmitted with DSCP set to A (as requested
   by the STAMP Sender)
   - STAMP Sender receives the STAMP packet with DSCP A but DSCP2 value is
   B not as expected.

I hope this little example helps. Obviously, there are many ways to use the
CoS TLV to test CoS mappings.

---

From: "Songyuezhong (songyuezhong, IP technology Research Dept)" <[email-masked]>
Date: Tue, 2 Jun 2020 03:59:00 +0000

Hi Greg,
thanks for the reply from you and Ian, some of my questions have been answered, and there are still a few problems I don't understand,
I will use the way you use with song>> tag for my reply

Regards,
Yuezhong

发件人: Greg Mirsky [mailto:[email-masked]]
发送时间: 2020年6月2日 0:03
收件人: Songyuezhong (songyuezhong, IP technology Research Dept) <[email-masked]>
抄送: Ian Swett <ianswett=[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>
主题: Re: [ippm] 答复: WGLC for STAMP Extensions

Hi Yuezhong,
thank you for your comments and suggestions. Please find my notes and answers in-line under the GIM>> tag.

Regards,
Greg

On Sat, May 30, 2020 at 4:56 AM Songyuezhong (songyuezhong, IP technology Research Dept) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ian，

I have read the latest version of this draft，and have some small suggestions, hope it is helpful for you.

For part 4,there list 8 new TLVs, but it seems not detailed enough for each TLV about the application scenario and some terms in it, we need guess to understand the whole plan.
GIM>> We have tried to provide a clear technical description of extensions to help implementers produce interoperable implementations. Describing various scenarios an extension may be used in was not our main objective. There are other SDOs that reference STAMP and STAMP TLVs in their documents. I can mention BBF's WT-390.2 IP Performance Measurement from IP Edge to Customer Equipment using STAMP, and MEF's MEF-w66 Service OAM for IP Services. Both documents are in advanced phase and will be published later this year.

Especially for the people who have no background knowledge of each application scenario, maybe it is more hard for them to understand.
GIM>> Yes, you are correct. Standard documents require a certain level of knowledge in the particular area of the technology.

So I suggest for each TLV, there should have some pictures and background content to help people understand the TLV’s meaning and using method，it will be better.
GIM>> That is very helpful suggestion and I think that it can be a basis for the Applicability of STAMP document. Would you be interested in working on the new document together?

song>>We would like to work on the new document you mentioned，if there have some plan，we can discuss together.

By the way, I have some doubt about the Location TLV, which is the last-hop router, the reflector or the router before it? And how to indicate if the STAMP packets are send to the wrong Session-Reflector from this TLV?
GIM>> I hope that Henrik's response clarified one of the use case scenarios.

  *   STAMP Sender sets DSCP1 to value A
  *   STAMP packet is transmitted with DSCP set to A
  *   STAMP Reflector copies DSCP value into DSCP2 field
  *   reflected STAMP packet is transmitted with DSCP set to A (as requested by the STAMP Sender)
  *   STAMP Sender receives the STAMP packet with DSCP A but DSCP2 value is B not as expected.
I hope this little example helps. Obviously, there are many ways to use the CoS TLV to test CoS mappings.
song>> the CoS mappings happened in Sender or other places, if DSCP value is not same with DSCP2 value, it means a error in which place?
song>> and for Access Report TLV, can you explain more, for example the location of sender and reflector both in user side, and how to find the reflector status changed, very thanks!

Thanks,
Yuezhong

发件人: ippm [mailto:[email-masked]<mailto:[email-masked]>] 代表 Ian Swett
发送时间: 2020年5月23日 5:26
收件人: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
主题: [ippm] WGLC for STAMP Extensions

Hi IPPM,

Thanks,
Ian & Tommy
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 2 Jun 2020 12:49:03 -0700

Hi Yuezhong,
great, let us connect off-list to share ideas about a new STAMP application
document.
On your other questions (I brought it to the front) I've added my notes
under GIM2>> tag below:

And another question is how to use Class of Service TLV to find the
misconfigure problem, is it enough?
GIM>> One of the possible scenarios could be as follows:

STAMP Sender sets DSCP1 to value A
STAMP packet is transmitted with DSCP set to A
STAMP Reflector copies DSCP value into DSCP2 field
reflected STAMP packet is transmitted with DSCP set to A (as requested by
the STAMP Sender)
STAMP Sender receives the STAMP packet with DSCP A but DSCP2 value is B not
as expected.
I hope this little example helps. Obviously, there are many ways to use the
CoS TLV to test CoS mappings.

song>> the CoS mappings happened in Sender or other places, if DSCP value
is not same with DSCP2 value, it means a error in which place?
GIM2>> Let us assume that no CoS re-mapping expected along a path between
the Sender and the Reflector. If the value in the DSCP2 field is different
from the value set in the DSCP field by the Sender at the transmission,
then the error is on the downstream leg of the path. If the value in the
DSCP1 field is different from the value in the DSCP field of the reflected
packet received by the Sender, then the error is on the upstream leg of the
path. I'll note that CoS re-mapping may be used and then the determination
of the error condition should be based on the expected behavior. I hope
that helps.

song>> and for Access Report TLV, can you explain more, for example the
location of sender and reflector both in user side, and how to find the
reflector status changed, very thanks!
GIM2>> As noted in the last paragraph in Section 4.6:
   The Access Report TLV is used by the Performance Measurement Function
   (PMF) components of the Access Steering, Switching and Splitting
   feature for 5G networks [TS23501].  The PMF component in the User
   Equipment acts as the STAMP Session-Sender, and the PMF component in
   the User Plane Function acts as the STAMP Session-Reflector.
UE acts as Session-Sender and UPF - Session-Reflector.

Regards,
Greg

On Mon, Jun 1, 2020 at 8:59 PM Songyuezhong (songyuezhong, IP technology
Research Dept) <[email-masked]> wrote:

> Hi Greg,
>
> thanks for the reply from you and Ian, some of my questions have been
> answered, and there are still a few problems I don't understand,
>
> *发件人:* Greg Mirsky [mailto:[email-masked]]
> *发送时间:* 2020年6月2日 0:03
> *收件人:* Songyuezhong (songyuezhong, IP technology Research Dept) <
> [email-masked]>
> *抄送:* Ian Swett <ianswett=[email-masked]>; IETF IPPM WG (
> [email-masked]) <[email-masked]>
> *主题:* Re: [ippm] 答复: WGLC for STAMP Extensions
>
>
>
> Hi Yuezhong,
>
>    - reflected STAMP packet is transmitted with DSCP set to A (as
>    requested by the STAMP Sender)
>    - STAMP Sender receives the STAMP packet with DSCP A but DSCP2 value
>    is B not as expected.
>
> song>> the CoS mappings happened in Sender or other places, if DSCP value
> is not same with DSCP2 value, it means a error in which place?
>
> song>> and for Access Report TLV, can you explain more, for example the
> location of sender and reflector both in user side, and how to find the
> reflector status changed, very thanks!
>
>
>
> Thanks,
> Yuezhong
>
>
>

---

From: "Songyuezhong (songyuezhong, IP technology Research Dept)" <[email-masked]>
Date: Thu, 4 Jun 2020 03:50:57 +0000

Hi Greg,

ok, for the new STAMP application document we can discuss off-list.
And for this draft, I still have some problem. such as the Follow-up Telemetry TLV, Follow-up Timestamp is record by egress when the packet Return to sender, And this timestamp will be carried next time?
And the last problem is why HMAC TLV is needed in authenticated mode, I think this mode has this function inherently.

Regards,
Yuezhong
发件人: Greg Mirsky [mailto:[email-masked]]
发送时间: 2020年6月3日 3:49
收件人: Songyuezhong (songyuezhong, IP technology Research Dept) <[email-masked]>
抄送: Ian Swett <ianswett=[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>; Tianran Zhou <[email-masked]>
主题: Re: [ippm] 答复: WGLC for STAMP Extensions

Hi Yuezhong,
great, let us connect off-list to share ideas about a new STAMP application document.
On your other questions (I brought it to the front) I've added my notes under GIM2>> tag below:

STAMP Sender sets DSCP1 to value A
STAMP packet is transmitted with DSCP set to A
STAMP Reflector copies DSCP value into DSCP2 field
reflected STAMP packet is transmitted with DSCP set to A (as requested by the STAMP Sender)
STAMP Sender receives the STAMP packet with DSCP A but DSCP2 value is B not as expected.
I hope this little example helps. Obviously, there are many ways to use the CoS TLV to test CoS mappings.

song>> the CoS mappings happened in Sender or other places, if DSCP value is not same with DSCP2 value, it means a error in which place?
GIM2>> Let us assume that no CoS re-mapping expected along a path between the Sender and the Reflector. If the value in the DSCP2 field is different from the value set in the DSCP field by the Sender at the transmission, then the error is on the downstream leg of the path. If the value in the DSCP1 field is different from the value in the DSCP field of the reflected packet received by the Sender, then the error is on the upstream leg of the path. I'll note that CoS re-mapping may be used and then the determination of the error condition should be based on the expected behavior. I hope that helps.

Regards,
Greg

On Mon, Jun 1, 2020 at 8:59 PM Songyuezhong (songyuezhong, IP technology Research Dept) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,
thanks for the reply from you and Ian, some of my questions have been answered, and there are still a few problems I don't understand,
I will use the way you use with song>> tag for my reply

Regards,
Yuezhong

发件人: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
发送时间: 2020年6月2日 0:03
收件人: Songyuezhong (songyuezhong, IP technology Research Dept) <[email-masked]<mailto:[email-masked]>>
抄送: Ian Swett <ianswett=[email-masked]<mailto:[email-masked]>>; IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
主题: Re: [ippm] 答复: WGLC for STAMP Extensions

Hi Yuezhong,

Regards,
Greg

Thanks,
Yuezhong

Hi IPPM,

Thanks,
Ian & Tommy

---

From: Rakesh Gandhi <[email-masked]>
Date: Sat, 6 Jun 2020 08:50:37 -0400

Hi WG, Chairs,
Support the publication of the draft.
I have a comment as follows:

Section 4

What error is returned if the mandatory TLV is not supported by the
reflector?

Section 5- Table 2

Are these all mandatory TLVs? Can we indicate it?

Thanks,

Rakesh

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 6 Jun 2020 10:33:02 -0700

Hi Yuezhong,
great questions, thank you! Please find my answers below in-line tagged
GIM3>>.

Regards,
Greg

On Wed, Jun 3, 2020 at 8:51 PM Songyuezhong (songyuezhong, IP technology
Research Dept) <[email-masked]> wrote:

> And for this draft, I still have some problem. such as the Follow-up
> Telemetry TLV, Follow-up Timestamp is record by egress when the packet
> Return to sender, And this timestamp will be carried next time?
>
GIM3>> You are absolutely correct. Obtaining a timestamp on the
transmission of a packet is challenging and various techniques have been
used to improve the consistency of this process, i.e., minimize the
variable delay between when the timestamp value is obtained and the
transmission of the packet actually begins. Separating the part of reading
the time value from the transporting it is what the Follow-up extension
provides to STAMP-based systems. As you've noted, the time value is read
and saved at the Session-Reflector very close to the physical transmission
of the reflected packet. And then that value may be included in the next
reflected STAMP packet in the Follow-up TLV.

> And the last problem is why HMAC TLV is needed in authenticated mode, I
> think this mode has this function inherently.
>
GIM3>> I'll note that only the base STAMP packet is protected by HMAC per
RFC 8762. The HMAC TLV is to protect STAMP extensions. I hope that makes it
clearer.

> *发送时间:* 2020年6月3日 3:49
> [email-masked]) <[email-masked]>; Tianran Zhou <[email-masked]>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sat, 6 Jun 2020 18:33:49 +0000

Hi IPPM,

At one of the author’s request, I reviewed draft-ietf-ippm-stamp-option-tlv-04.

TL;DR: I have a lot of small comments; no show-stoppers I think.

regards,
Al

   MBZ Must Be Zeroed   [acm] s/Zeroed/Zero/ ? that’s the way MBZ is usually used...

...
       Figure 1: STAMP Session-Sender test packet format with TLV in
                           unauthenticated mode

   An implementation of STAMP Session-Reflector that supports this
   specification SHOULD identify a STAMP Session using the SSID in
   combination with elements of the usual 4-tuple
[acm] <insert> for the session. If the Session-Reflector finds that
the SSID and 4-tuple combination changes during a test session, then
the Session-Reflector MUST discard the non-matching packet(s) and take
no further action on them.
   .  A conforming...

...

                        Figure 5: Extra Padding TLV

   where fields are defined as the following:

   o  Extra Padding Type - TBA1 allocated by IANA Section 5.1

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

   o  Extra Padding - a pseudo-random sequence of numbers.  The field
      MAY be filled with all zeroes.
[acm] 1,$ s/zeroes/zeros/g

   The Extra Padding TLV is similar to the Packet Padding field in
   TWAMP-Test packet [RFC5357].  The Extra Padding TLV MUST be used to
   create STAMP test packets of larger size
[acm] <insert> than the usual STAMP test packet, xxx octets for un-authenticated.

...
                 Figure 6: Session-Reflector Location TLV

   where fields are defined as the following:

   o  Location Type - TBA2 allocated by IANA Section 5.1

   o  Length - two octets long field equals length on
[acm] s/on/of/
      the Value field in
      octets.
[acm] <insert> The
       Length field value MUST be 20 octets for the IPv4 address
      family.  For the IPv6 address family
[acm] <insert> ", the "
       value of the Length field
      MUST be 44 octets.  All other values are invalid.
[acm] in two places above, s/MUST be/MUST equal/
(otherwise, there is some ambiguity about length and value)

   o  Source MAC - 6 octets 48 bits long field.  The session-reflector
      MUST copy Source MAC of received STAMP packet into this field.

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

   o  Destination IP Address - IPv4 or IPv6 destination address of the
[acm] ??? packet ???  if yes, delete packet at end of sentence...
      received by the session-reflector STAMP packet.
[acm] these fixes apply below to Source IP Address

   o  Source IP Address - IPv4 or IPv6 source address of the received by
      the session-reflector STAMP packet.
...

                    Figure 7: Timestamp Information TLV

   where fields are defined as the following:

   o  Timestamp Information Type - TBA3 allocated by IANA Section 5.1

   o  Length - two octets long field, equals four octets.
[acm] , set equal to the value 4 ?  (there seems to be a lot of this!)

   o  Sync Src In - one octet long field that characterizes the source
      of clock synchronization at the ingress of Session-Reflector.

      There are several of methods to synchronize the clock, e.g.,
      Network Time Protocol (NTP) [RFC5905], Precision Time Protocol
      (PTP) [IEEE.1588.2008], Synchronization Supply Unit (SSU) or
      Building Integrated Timing Supply (BITS), or Global Positioning
      System (GPS), Global Orbiting Navigation Satellite System
      (GLONASS) and Long Range Navigation System Version C (LORAN-C).
      The value is one of the listed in Table 4.
[acm] ... one of those listed ...  (more changes like this, too)

...

4.5.  Direct Measurement TLV

   The Direct Measurement TLV enables collection of "in profile" IP
   packets that had been transmitted and received by the Session-Sender
   and Session-Reflector respectfully.  The definition of "in-profile
   packet" is outside the scope of this document.
[acm]  and left to the test operators to determine.

...

   o  Reserved - the three octest-long field.  Its value MUST be zeroed
[acm] s/octest/octets/
      on transmission and ignored on receipt.

4.8.  HMAC TLV

...

             | TBA7  |  Follow-up Telemetry  | This document |
             | TBA8  |          HMAC         | This document |
             +-------+-----------------------+---------------+
[acm] You can suggest the values, if you want.
                           Table 2: STAMP Types

...

                  +-------+-------------+---------------+
                  | Value | Description | Reference     |
                  +-------+-------------+---------------+
                  | 1     |     3GPP    | This document |
                  | 2     |   Non-3GPP  | This document |
                  +-------+-------------+---------------+
[acm] these seem overly broad, and unlikely to be extended because they *cover everything*!!
                            Table 8: Access IDs

...

              +-------+---------------------+---------------+
              | Value |     Description     | Reference     |
              +-------+---------------------+---------------+
              | 1     |  Network available  | This document |
              | 2     | Network unavailable | This document |
              +-------+---------------------+---------------+
[acm] these seem overly broad, and imply knowledge where the STAMP end-point has limited insights!!
                          Table 10: Return Codes

...

6.  Security Considerations

   Use of HMAC in authenticated mode may be used to simultaneously
   verify both the data integrity and the authentication of the STAMP
   test packets.
[acm] That's it? At least add reference to STAMP 8762 Security Section?
[acm] I suspect there will be some challenges for "Location" in future

From: ippm [mailto:[email-masked]] On Behalf Of Ian Swett
Sent: Friday, May 22, 2020 5:26 PM
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: [ippm] WGLC for STAMP Extensions

Hi IPPM,

The latest version can be found here: https://tools.ietf.org/html/draft-ietf-ippm-stamp-option-tlv-04<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dstamp-2Doption-2Dtlv-2D04&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=-FQ_7VkardtUOemNdXjWGCdxDzw_8jcaV16Ots-GfRo&s=zadhVvE6IwVbJd0BcDUJdpX4xXqA4i60susVdbT5Pvg&e=>

Thanks,
Ian & Tommy

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 6 Jun 2020 12:44:09 -0700

Hi Al,
the most sincere thanks for your comments and thoughtful suggestions to
improve the document. I will carefully review your questions and reply with
clarifications by Monday.

Best regards,
Greg

On Sat, Jun 6, 2020 at 11:34 AM MORTON, ALFRED C (AL) <[email-masked]>
wrote:

> *From:* ippm [mailto:[email-masked]] *On Behalf Of *Ian Swett
> *Sent:* Friday, May 22, 2020 5:26 PM
> *To:* IETF IPPM WG ([email-masked]) <[email-masked]>
> *Subject:* [ippm] WGLC for STAMP Extensions
>
>
>
> Hi IPPM,
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dstamp-2Doption-2Dtlv-2D04&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=-FQ_7VkardtUOemNdXjWGCdxDzw_8jcaV16Ots-GfRo&s=zadhVvE6IwVbJd0BcDUJdpX4xXqA4i60susVdbT5Pvg&e=>
>

---

From: Ian Swett <[email-masked]>
Date: Tue, 9 Jun 2020 17:43:21 -0400

Dear IPPM WG,

Thank you all for your comments on
https://tools.ietf.org/html/draft-ietf-ippm-stamp-option-tlv-04.  There’s
strong support for publishing this document, but there were a number of
questions and comments during WGLC and the chairs would like to see some of
those addressed before sending an updated draft to the IESG.

Some examples below, though I may have missed some:

   -

   Section 4 - What error is returned if the mandatory TLV is not supported
   by the reflector?
   -

   Section 5 - Table 2 - Are these all mandatory TLVs? Can we indicate it?
   -

   Al Morton’s detailed comments (Thanks Al)

It also sounds like there’s interest in working on an applicability draft
to provide more detail on how these extensions are to be used; the authors
may want to note that applicability is out-of-scope for the extensions.

Authors, please publish a new version of the draft to incorporate this
feedback when ready, and we will progress the document after that.

Thanks, Ian and Tommy

On Sat, Jun 6, 2020 at 3:44 PM Greg Mirsky <[email-masked]> wrote:

> On Sat, Jun 6, 2020 at 11:34 AM MORTON, ALFRED C (AL) <
> acm@research..att.com <[email-masked]>> wrote:
>
>> Hi IPPM,
>>
>>
>>
>>       (PTP) [IEEE..1588.2008], Synchronization Supply Unit (SSU) or
>>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 9 Jun 2020 16:10:56 -0700

Hi Al,
the authors had discussed your comments and suggestions. I've updated the
working version (attached along with the diff). Please find my answers,
questions, and notes in-line under the tag GIM>>.

Regards,
Greg

>        Figure 1: STAMP Session-Sender test packet format with TLV in
GIM>> Accepted, thank you.

> no further action on them.
GIM>> We've discussed the scenario and couldn't define how a
Session-Reflector can distinguish between a new STAMP test session and the
event of a change in identifiers, i.e., SSID and 4-tuple of the ongoing
test session. Could you kindly help us here?

> [acm] 1,$ s/zeroes/zeros/g
GIM>> Done, thank you

> [acm] <insert> than the usual STAMP test packet, xxx octets for
GIM>> I've followed your suggestion and added a reference to the
authenticated base STAMP packet too. Hope the updated paragraph is
acceptable:
NEW TEXT:
   The Extra Padding TLV is similar to the Packet Padding field in
   TWAMP-Test packet [RFC5357].  The Extra Padding TLV MUST be used to
   create STAMP test packets of larger size that the base STAMP packet
   [RFC8762].  The length of the base STAMP is 44 octets in the
   unauthenticated mode or 112 octets in the authenticated mode.  The
   Extra Padding TLV MUST be the last TLV in a STAMP test packet.

> (otherwise, there is some ambiguity about length and value)
GIM>> Accepted and done all four. Thank you!

> [acm] these fixes apply below to Source IP Address
GIM>> Removed extra "packet" at the end of sentences in both cases.

> [acm] , set equal to the value 4 ?  (there seems to be a lot of this!)
GIM>> Thank you, Al. I believe I've captured them all.

> [acm] ... one of those listed ...  (more changes like this, too)
GIM>> Thank you, got them all fixed.

> [acm]  and left to the test operators to determine.
GIM>> Agreed and added to the text.

>    o  Reserved - the three octest-long field.  Its value MUST be zeroed
GIM>> Fixed.

>              | TBA8  |          HMAC         | This document |
GIM>> We've discussed and decided to leave the assignment to IANA.

>                            Table 2: STAMP Types
GIM>> Here we've turned to our 3GPP expert. The current (Rel-16)
specification of ATSSS defines only two access types - 3GPP and Non-3GPP.
Creating a sub-registry and leaving a space for new types might help to
accommodate potential changes in 5G specification and the development of
new specifications, e.g., 6G, in the future.

>                             Table 8: Access IDs
GIM>>  These are defined in ATSSS specification of Performance Measurement
Function. The value for the Return Code field is passed to STAMP system and
it only transports it. Would a new text clarify the role of a STAMP system:
OLD TEXT:
   o  Return Code - one octet long field that identifies the report
      signal, e.g., available, unavailable.  The value is one of those
      listed in Section 5.5.
NEW TEXT:
   o  Return Code - one octet long field that identifies the report
      signal, e.g., available, unavailable.  The value is passed,
      supplied to the STAMP end-point through some mechanism that is
      outside the scope of this document.  The value is one of those
      listed in Section 5.5.

> [acm] That's it? At least add reference to STAMP 8762 Security Section?
GIM>> Thank you for your suggestion. The new text is below:
NEW TEXT:
   This document defines extensions to STAMP [RFC8762] and inherits all
   the security considerations applicable to the base protocol.
   Additionally, the HMAC TLV is defined in this document to protect the
   integrity of optional STAMP extensions.  The use of HMAC TLV is
   discussed in detail in Section 4.8.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 10 Jun 2020 15:01:21 +0000

Hi Greg, Thanks for all replies.
Let’s concentrate on those needing some additional thought...
Al

GIM>> We've discussed the scenario and couldn't define how a Session-Reflector can distinguish between a new STAMP test session and the event of a change in identifiers, i.e., SSID and 4-tuple of the ongoing test session. Could you kindly help us here?

[acm] Thanks, I’m surprised that a new test session (with new SSID) can begin without any Session-Reflector agreement or communication from the Session-Reflector’s management interface. Since the Sending address and port could be spoofed, Session-Reflectors could receive lots of unexpected traffic, if you know what I mean...

...
 …                 | 2     |   Non-3GPP  | This document |
                  +-------+-------------+---------------+
[acm] these seem overly broad, and unlikely to be extended because they *cover everything*!!
GIM>> Here we've turned to our 3GPP expert. The current (Rel-16) specification of ATSSS defines only two access types - 3GPP and Non-3GPP. Creating a sub-registry and leaving a space for new types might help to accommodate potential changes in 5G specification and the development of new specifications, e.g., 6G, in the future.
[acm]
Yes, but your examples of 5G and 6G would fall under the general category of “3GPP” (which I accidentally delated above).
Maybe some additional detail would help, like “3GPP-LTE”, “3GPP-5G”, and make “Non-3GPP” the first entry so that expansion with new technologies starts at 2, 3, …
                            Table 8: Access IDs

...

GIM>>  These are defined in ATSSS specification of Performance Measurement Function. The value for the Return Code field is passed to STAMP system and it only transports it. Would a new text clarify the role of a STAMP system:
[acm]
OK
                          Table 10: Return Codes

...

[acm] OK

From: ippm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ian Swett
Sent: Friday, May 22, 2020 5:26 PM
To: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: [ippm] WGLC for STAMP Extensions

Hi IPPM,

Thanks,
Ian & Tommy
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=AJPt25JReJLCcKTac6bW207kN8j0F2v7N7paNXkrS0Y&s=9RnqOZ8tzteJbGK2PJMpE2Y8RqKl-bvq-QfiStX4ywc&e=>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 10 Jun 2020 16:20:31 -0700

Hi Al,
many thanks for your quick response, much appreciated. We'll need some more
time to discuss your suggestion related to the Access Report TLV. I've
front-copied the other open issue and added my notes under the tag GIM2>>
below.

   .  A conforming...

*[acm] Thanks, I’m surprised that a new test session (with new SSID) can
begin without any Session-Reflector agreement or communication from the
Session-Reflector’s management interface. Since the Sending address and
port could be spoofed, Session-Reflectors could receive lots of unexpected
traffic, if you know what I mean...*

GIM2>> Thank you for the clarification. I was not thinking out of a box.
Please review the proposed new text below. I hope it captures the scenario
you've pointed out.
OLD TEXT:
   An implementation of STAMP Session-Reflector that supports this
   specification SHOULD identify a STAMP Session using the SSID in
   combination with elements of the usual 4-tuple for the session.  A
   conforming implementation of STAMP Session-Reflector MUST copy the
   SSID value from the received test packet and put it into the
   reflected packet, as displayed in Figure 2.
NEW TEXT:
   An implementation of STAMP Session-Reflector that supports this
   specification SHOULD identify a STAMP Session using the SSID in
   combination with elements of the usual 4-tuple for the session.
   Before a test session commenced, a Session-Reflector MUST be
   provisioned with all the elements that identify the STAMP Session.  A
   STAMP Session-Reflector MUST discard the non-matching STAMP test
   packet(s).  The means of provisioning the STAMP Session
   identification is outside the scope of this specification.  A
   conforming implementation of STAMP Session-Reflector MUST copy the
   SSID value from the received test packet and put it into the
   reflected packet, as displayed in Figure 2.

Would the new text address your concern?

Regards,
Greg

On Wed, Jun 10, 2020 at 8:01 AM MORTON, ALFRED C (AL) <[email-masked]>
wrote:

> *[acm] Thanks, I’m surprised that a new test session (with new SSID) can
> begin without any Session-Reflector agreement or communication from the
> Session-Reflector’s management interface. Since the Sending address and
> port could be spoofed, Session-Reflectors could receive lots of unexpected
> traffic, if you know what I mean... *
>
>
>
>
>
> ...
>
> *[acm] *
> *Yes, but your examples of 5G and 6G would fall under the general category
> of “3GPP” (which I accidentally delated above).*
>
> *Maybe some additional detail would help, like “3GPP-LTE”, “3GPP-5G”, and
> make “Non-3GPP” the first entry so that expansion with new technologies
> starts at 2, 3, …*
>
>                             Table 8: Access IDs
>
>
>
> ...
>
>
>
> *[acm] *
> *OK*
> *[acm] OK*
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=AJPt25JReJLCcKTac6bW207kN8j0F2v7N7paNXkrS0Y&s=9RnqOZ8tzteJbGK2PJMpE2Y8RqKl-bvq-QfiStX4ywc&e=>
>
>

---

From: Rakesh Gandhi <[email-masked]>
Date: Wed, 10 Jun 2020 19:35:54 -0400

Hi Greg, Al,
I am not sure if I follow the scenario.
Between nodes A and B, there can be more than one STAMP sessions, e.g.
{Node-A, Node-B, Src-Port-1, Dst-Port-1, SSID1} and {Node-A, Node-B,
Src-Port-1, Dst-Port-1, SSID2}. I assume this is allowed? If yes, how do we
know when there is now a third session between them with SSID3 (with same 4
tuple), it is a change (from SSID1 or SSID2?) or a new third session?
Thanks,
Rakesh

On Wed, Jun 10, 2020 at 7:21 PM Greg Mirsky <[email-masked]> wrote:

> Hi Al,
> many thanks for your quick response, much appreciated. We'll need some
> more time to discuss your suggestion related to the Access Report TLV. I've
> traffic, if you know what I mean....*
>
> On Wed, Jun 10, 2020 at 8:01 AM MORTON, ALFRED C (AL) <
> [email-masked]> wrote:
>
>> traffic, if you know what I mean.... *
>>
>>
>>
>>
>>
>> ...
>>
>> GIM>> Here we've turned to our 3GPP expert.. The current (Rel-16)
>> *Yes, but your examples of 5G and 6G would fall under the general
>> category of “3GPP” (which I accidentally delated above).*
>>
>> GIM>>  These are defined in ATSSS specification of Performance
>> Measurement Function. The value for the Return Code field is passed to
>> STAMP system and it only transports it. Would a new text clarify the role
>> of a STAMP system:
>>
>> OLD TEXT:
>>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 10 Jun 2020 18:32:29 -0700

Hi Rakesh,
as Al clarified, and I agree with this scenario, a Session-Reflector must
be provisioned with a session identifier (some elements, I think, might be
specified as a wild card) before the session is commenced. All test packets
that do not match the provisioned identifier must be discarded without
processing. I've tried to capture that in the latest update sent earlier.
What do you think of this scenario?

Regards,
Greg

On Wed, Jun 10, 2020 at 4:36 PM Rakesh Gandhi <[email-masked]>
wrote:

>>> *Maybe some additional detail would help, like “3GPP-LTE”, “3GPP-5G”,
>>> and make “Non-3GPP” the first entry so that expansion with new technologies
>>> starts at 2, 3, …*
>>>
>>>                             Table 8: Access IDs
>>>
>>>
>>>
>>> ...
>>>
>>>
>>>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 10 Jun 2020 18:46:36 -0700

Hi Al,
we now have a proposal to address the open question related to the Access
ID in the Access Report TLV. I've front-copied it for the convenience.

[acm] these seem overly broad, and unlikely to be extended because they
*cover everything*!!

*[acm] *

                            Table 8: Access IDs

We propose the following updates:
- do not create the Access ID sub-registry
- define only two values - 3GPP Network and Non-3GPP Network with all
others being invalid
- change the length of the Access ID field from one octet to four bits
- make the remaining four bits a new Resv field (for optional use in the
future)

Attached are the new working version and the diff to -04 version of the
draft.
I much appreciate your consideration, comments, and questions.

Regards,
Greg

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 11 Jun 2020 13:45:43 +0000

Yes, the new text does it, thanks Greg.
Al

From: Greg Mirsky [mailto:[email-masked]]
Sent: Wednesday, June 10, 2020 7:21 PM
To: MORTON, ALFRED C (AL) <[email-masked]>
Cc: Ian Swett <ianswett=[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: Re: [ippm] WGLC for STAMP Extensions

Hi Al,
many thanks for your quick response, much appreciated. We'll need some more time to discuss your suggestion related to the Access Report TLV. I've front-copied the other open issue and added my notes under the tag GIM2>> below.

GIM2>> Thank you for the clarification. I was not thinking out of a box. Please review the proposed new text below. I hope it captures the scenario you've pointed out.

Regards,
Greg

On Wed, Jun 10, 2020 at 8:01 AM MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg, Thanks for all replies.
Let’s concentrate on those needing some additional thought...
Al

...

...

...

[acm] OK

Hi IPPM,

Thanks,
Ian & Tommy

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 11 Jun 2020 13:52:17 +0000

OK, works for me,
Al

Sent: Wednesday, June 10, 2020 9:47 PM

Hi Al,
we now have a proposal to address the open question related to the Access ID in the Access Report TLV. I've front-copied it for the convenience.
 …                 | 2     |   Non-3GPP  | This document |
                  +-------+-------------+---------------+
[acm] these seem overly broad, and unlikely to be extended because they *cover everything*!!
GIM>> Here we've turned to our 3GPP expert. The current (Rel-16) specification of ATSSS defines only two access types - 3GPP and Non-3GPP. Creating a sub-registry and leaving a space for new types might help to accommodate potential changes in 5G specification and the development of new specifications, e.g., 6G, in the future.
[acm]
Yes, but your examples of 5G and 6G would fall under the general category of “3GPP” (which I accidentally delated above).
Maybe some additional detail would help, like “3GPP-LTE”, “3GPP-5G”, and make “Non-3GPP” the first entry so that expansion with new technologies starts at 2, 3, …
                            Table 8: Access IDs
We propose the following updates:
- do not create the Access ID sub-registry
- define only two values - 3GPP Network and Non-3GPP Network with all others being invalid
- change the length of the Access ID field from one octet to four bits
- make the remaining four bits a new Resv field (for optional use in the future)

Attached are the new working version and the diff to -04 version of the draft.
I much appreciate your consideration, comments, and questions.

Regards,
Greg

...

...

...

[acm] OK

Hi IPPM,

Thanks,
Ian & Tommy

---

From: Rakesh Gandhi <[email-masked]>
Date: Thu, 11 Jun 2020 10:13:09 -0400

Thanks Greg.
SSID can be internally generated by the sender node. Expecting sender node
to communicate this to the controller and then to the reflector node for
*each* session may be overkill.

The destination UDP port to use on the reflector node is already
provisioned value and not any arbitrary port can be used anyways. So that
should help with such issues.

My 2c.

Thanks,
Rakesh

On Wed, Jun 10, 2020 at 9:32 PM Greg Mirsky <[email-masked]> wrote:

>>>> *[acm] Thanks, I’m surprised that a new test session (with new SSID)
>>>> can begin without any Session-Reflector agreement or communication from the

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 11 Jun 2020 07:20:18 -0700

Hi Rakesh,
I agree with your scenario. Do you feel that the document, including the
updated text, precludes it? Would you suggest text clarifications?

Regards,
Greg

On Thu, Jun 11, 2020 at 7:13 AM Rakesh Gandhi <[email-masked]>
wrote:

>>>> GIM2>> Thank you for the clarification. I was not thinking out of a
>>>> box. Please review the proposed new text below. I hope it captures the
>>>> scenario you've pointed out.
>>>> OLD TEXT:

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 11 Jun 2020 14:28:28 +0000

Hi Greg,
The current (OLD) text in the document looks good to me.
P.S. The goal for STAMP (with Simple) is to simplify such things when compared to TWAMP (RFC 5357).

Thanks,
Rakesh

From: ippm <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Thursday, June 11, 2020 at 10:21 AM
To: Rakesh Gandhi <[email-masked]>
Cc: "MORTON, ALFRED C (AL)" <[email-masked]>, Ian Swett <ianswett=[email-masked]>, "IETF IPPM WG ([email-masked])" <[email-masked]>
Subject: Re: [ippm] WGLC for STAMP Extensions

Hi Rakesh,
I agree with your scenario. Do you feel that the document, including the updated text, precludes it? Would you suggest text clarifications?

Regards,
Greg

On Thu, Jun 11, 2020 at 7:13 AM Rakesh Gandhi <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Greg.
SSID can be internally generated by the sender node. Expecting sender node to communicate this to the controller and then to the reflector node for *each* session may be overkill.

The destination UDP port to use on the reflector node is already provisioned value and not any arbitrary port can be used anyways. So that should help with such issues.

My 2c.

Thanks,
Rakesh

On Wed, Jun 10, 2020 at 9:32 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rakesh,
as Al clarified, and I agree with this scenario, a Session-Reflector must be provisioned with a session identifier (some elements, I think, might be specified as a wild card) before the session is commenced. All test packets that do not match the provisioned identifier must be discarded without processing. I've tried to capture that in the latest update sent earlier.
What do you think of this scenario?

Regards,
Greg

On Wed, Jun 10, 2020 at 4:36 PM Rakesh Gandhi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg, Al,
I am not sure if I follow the scenario.
Between nodes A and B, there can be more than one STAMP sessions, e.g. {Node-A, Node-B, Src-Port-1, Dst-Port-1, SSID1} and {Node-A, Node-B, Src-Port-1, Dst-Port-1, SSID2}. I assume this is allowed? If yes, how do we know when there is now a third session between them with SSID3 (with same 4 tuple), it is a change (from SSID1 or SSID2?) or a new third session?
Thanks,
Rakesh

On Wed, Jun 10, 2020 at 7:21 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Al,
many thanks for your quick response, much appreciated. We'll need some more time to discuss your suggestion related to the Access Report TLV. I've front-copied the other open issue and added my notes under the tag GIM2>> below.

[acm] Thanks, I’m surprised that a new test session (with new SSID) can begin without any Session-Reflector agreement or communication from the Session-Reflector’s management interface. Since the Sending address and port could be spoofed, Session-Reflectors could receive lots of unexpected traffic, if you know what I mean.....

Regards,
Greg

[acm] Thanks, I’m surprised that a new test session (with new SSID) can begin without any Session-Reflector agreement or communication from the Session-Reflector’s management interface. Since the Sending address and port could be spoofed, Session-Reflectors could receive lots of unexpected traffic, if you know what I mean.....

...
GIM>> Here we've turned to our 3GPP expert... The current (Rel-16) specification of ATSSS defines only two access types - 3GPP and Non-3GPP. Creating a sub-registry and leaving a space for new types might help to accommodate potential changes in 5G specification and the development of new specifications, e.g., 6G, in the future.

...

...

[acm] OK

Hi IPPM,

Thanks,
Ian & Tommy

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 11 Jun 2020 07:44:30 -0700

Hi Rakesh,
thank you for your quick response. Below is the text proposed in the update:
   Before a test session commenced, a Session-Reflector MUST be
   provisioned with all the elements that identify the STAMP Session.  A
   STAMP Session-Reflector MUST discard the non-matching STAMP test
   packet(s).  The means of provisioning the STAMP Session
   identification is outside the scope of this specification.
The intention of the update is to point to the need to use the management
or control plane to provision a STAMP session on the Session-Reflector. At
the same time, the text does not specify which of the informational
elements be provisioned to the explicit values and which may use a
wildcard. If you have concerns with the update, could you please suggest
modifications or propose an alternative?

Regards,
Greg

On Thu, Jun 11, 2020 at 7:28 AM Rakesh Gandhi (rgandhi) <[email-masked]>
wrote:

> *From: *ippm <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> *Date: *Thursday, June 11, 2020 at 10:21 AM
> *To: *Rakesh Gandhi <[email-masked]>
> *Cc: *"MORTON, ALFRED C (AL)" <[email-masked]>, Ian Swett <ianswett=
> [email-masked]>, "IETF IPPM WG ([email-masked])" <
> [email-masked]>
> *Subject: *Re: [ippm] WGLC for STAMP Extensions
>
>
>
> Hi Rakesh,
>
> traffic, if you know what I mean.....*
>
> traffic, if you know what I mean..... *
>
>
>
>
>
> ...
>
> GIM>> Here we've turned to our 3GPP expert... The current (Rel-16)

---

From: Rakesh Gandhi <[email-masked]>
Date: Thu, 11 Jun 2020 11:07:47 -0400

Hi Greg,
Basically removing the need to provision the SSID on the reflector node. So
new text may look like:

   provisioned with elements of the usual 4-tuple for the Session.  A

   A conforming implementation of STAMP Session-Reflector MUST copy the
   SSID value from the received test packet and put it into the
   reflected packet, as displayed in Figure 2.

Thanks,

Rakesh

On Thu, Jun 11, 2020 at 10:44 AM Greg Mirsky <[email-masked]> wrote:

>> *Cc: *"MORTON, ALFRED C (AL)" <[email-masked]>, Ian Swett
>> <ianswett=[email-masked]>, "IETF IPPM WG ([email-masked])" <
>> [email-masked]>
>> SSID can be internally generated by the sender node. Expecting sender
>> node to communicate this to the controller and then to the reflector node
>> for *each* session may be overkill.
>>
>>
>>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 11 Jun 2020 09:38:29 -0700

Hi Rakesh,
many thanks for the suggested text. I understand the intention of the
change but I think that the text proposed earlier, that Al has agreed to,
does not mandate that a Session-Reflector was provisioned with a specific
for the particular STAMP test session value of SSID. Provisioning, in my
view, could be as simple as leaving it a wildcard, i.e. Any. If we can
agree with this interpretation in this document, we'll decide on the
default values for all elements in the STAMP YANG data model. I hope you
can accept that.

Regards,
Greg

On Thu, Jun 11, 2020 at 8:07 AM Rakesh Gandhi <[email-masked]>
wrote:

> Hi Greg,
> Basically removing the need to provision the SSID on the reflector node.
> So new text may look like:
>
>> On Thu, Jun 11, 2020 at 7:28 AM Rakesh Gandhi (rgandhi) <
>> [email-masked]> wrote:
>>
>>> Hi Greg,
>>>
>>> as Al clarified, and I agree with this scenario, a Session-Reflector
>>> must be provisioned with a session identifier (some elements, I think,
>>> might be specified as a wild card) before the session is commenced. All
>>> test packets that do not match the provisioned identifier must be discarded
>>> without processing. I've tried to capture that in the latest update sent
>>> earlier.
>>>

---

From: Rakesh Gandhi <[email-masked]>
Date: Thu, 11 Jun 2020 14:30:46 -0400

Sure, thanks Greg.

On Thu, Jun 11, 2020 at 12:38 PM Greg Mirsky <[email-masked]> wrote:

>>> The intention of the update is to point to the need to use the
>>> management or control plane to provision a STAMP session on the
>>> Session-Reflector. At the same time, the text does not specify which of the
>>> informational elements be provisioned to the explicit values and which may
>>> use a wildcard. If you have concerns with the update, could you please
>>> suggest modifications or propose an alternative?
>>>
>>> Regards,
>>> Greg
>>>
>>>> <ianswett=[email-masked]>, "IETF IPPM WG ([email-masked])"
>>>> <[email-masked]>
>>>> I agree with your scenario. Do you feel that the document, including
>>>> the updated text, precludes it? Would you suggest text clarifications?
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Greg
>>>>
>>>>
>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 11 Jun 2020 14:41:34 -0700

Hi Yali,
my apologies for the delayed response. Please find my answers below tagged
GIM>>. Attached, please find the updated working version and the diff. I
hope that the proposed updates address your concerns.

Regards,
Greg

On Mon, Jun 1, 2020 at 1:40 AM wangyali <[email-masked]> wrote:

> 1.       In the draft, I confused a sentence that said ‘The
> Session-Sender MUST NOT stop the session if it receives a zeroed  SSID
> field.’ If a STAMP Session-Reflector that does not support this
> specification and return the zeroed SSID field in the reflected STAMP test
> packet, the STAMP Session-Sender MUST stop the session. I assume there’s a
> edit error.
>
GIM>> Great catch, thank you!

>
>
>
>
> 2.       Does the TLV field shown in figure 1 indicate that the STAMP
> Session-Sender test packet with TLV in unauthenticated mode can contains
> one or more TLVs defined in this draft? I suggest to give an illustration
> about the TLV field in the test packet and revise TLV field in figure 1
> that is not very clear.
>
GIM>> You are absolutely correct, multiple TLVs can be used in the same
test packet either sequentially or enclosed. I've added a new text in the
first paragraph of Section 4:
OLD TEXT:
   Type-Length-Value (TLV) encoding scheme provides flexible extension
   mechanism for optional informational elements.  TLV is an optional
   field in the STAMP test packet.
NEW TEXT:
   Type-Length-Value (TLV) encoding scheme provides a flexible extension
   mechanism for optional informational elements.  TLV is an optional
   field in the STAMP test packet.  Multiple TLVs MAY be placed in the
   STAMP test packet.  A TLV MAY be enclosed in a TLV.

Also, I've updated captions for Figure 1 and Figure 2 to indicate that they
present an example of an extended STAMP test packet.

> *Sent:* Saturday, May 23, 2020 5:26 AM

---

From: wangyali <[email-masked]>
Date: Fri, 12 Jun 2020 06:26:32 +0000

Hi Greg,

Glad to receive your reply. Just a minor question. Please see inline <Yali>.

From: Greg Mirsky [mailto:[email-masked]]
Sent: Friday, June 12, 2020 5:42 AM
To: wangyali <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [ippm] WGLC for STAMP Extensions

Hi Yali,
my apologies for the delayed response. Please find my answers below tagged GIM>>. Attached, please find the updated working version and the diff. I hope that the proposed updates address your concerns.

Regards,
Greg

On Mon, Jun 1, 2020 at 1:40 AM wangyali <[email-masked]<mailto:[email-masked]>> wrote:
Hi authors and IPPM,

1.       In the draft, I confused a sentence that said 'The Session-Sender MUST NOT stop the session if it receives a zeroed  SSID field.' If a STAMP Session-Reflector that does not support this specification and return the zeroed SSID field in the reflected STAMP test packet, the STAMP Session-Sender MUST stop the session. I assume there's a edit error.
GIM>> Great catch, thank you!

GIM>> You are absolutely correct, multiple TLVs can be used in the same test packet either sequentially or enclosed. I've added a new text in the first paragraph of Section 4:

<Yali> what do you mean 'A TLV MAY be enclosed in a TLV'?

Also, I've updated captions for Figure 1 and Figure 2 to indicate that they present an example of an extended STAMP test packet.

Best regards,
Yali

Hi IPPM,

Thanks,
Ian & Tommy

---

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

Hi Yali,
I wanted to point that TLVs may be enclosed, i.e., used as sub-,
sub-sub-TLV. If it came across in a confusing manner, I'm all open for
better wording.

Regards,
Greg

On Thu, Jun 11, 2020 at 11:26 PM wangyali <[email-masked]> wrote:

> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Friday, June 12, 2020 5:42 AM
> *To:* wangyali <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [ippm] WGLC for STAMP Extensions
>
>
>
> Hi Yali,
>
> <Yali> what do you mean ‘A TLV MAY be enclosed in a TLV’?
>
>
>
> Also, I've updated captions for Figure 1 and Figure 2 to indicate that
> they present an example of an extended STAMP test packet.
>
>
>
> Best regards,
>
> Yali
>
>
>
>
>
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 12 Jun 2020 12:23:27 -0700

Hi Ian,
thank you for the summary of the discussion, it was the most helpful as
I've almost missed some of them. I believe that the latest version
addresses all the comments received as part of the WGLC. I've added notes
below under GIM>> tag to answer two specific questions.
Please let the authors know if there are any comments we've missed or any
other questions.

Regards,
Greg

On Tue, Jun 9, 2020 at 2:43 PM Ian Swett <[email-masked]> wrote:

>    Section 4 - What error is returned if the mandatory TLV is not
>    supported by the reflector?
>
> GIM>>  Updated text in Section 4 requires to log an event and if the
system is a Session-Reflector, to send ICMP Parameter Problem message with
Code set to 0 and the Pointer referring to the Type field.

> GIM>> Updated text pointing that all the values are from the Mandatory TLV
range.

> GIM>> I believe that we've agreed on all the proposed updates that are
part of -05 version.

---

From: wangyali <[email-masked]>
Date: Mon, 15 Jun 2020 12:01:47 +0000

Hi Greg,

Thanks for your reply. This is also I am thinking. If I understand correctly, it means that any one of TLVs defined in this draft may be used as sub- or sub-sub-TLV in others.

Best regards,
Yali

发件人: Greg Mirsky [mailto:[email-masked]]
发送时间: 2020年6月12日 23:26
收件人: wangyali <[email-masked]>
抄送: [email-masked]; [email-masked]
主题: Re: [ippm] WGLC for STAMP Extensions

Hi Yali,
I wanted to point that TLVs may be enclosed, i.e., used as sub-, sub-sub-TLV. If it came across in a confusing manner, I'm all open for better wording.

Regards,
Greg

On Thu, Jun 11, 2020 at 11:26 PM wangyali <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, June 12, 2020 5:42 AM
To: wangyali <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ippm] WGLC for STAMP Extensions

Hi Yali,

Regards,
Greg

Best regards,
Yali

Hi IPPM,

Thanks,
Ian & Tommy

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 17 Jun 2020 15:49:56 -0700

Hi Yali,
firstly, many thanks from all the authors for volunteering as the Shepherd
for this document.
Secondly, I apologize for such a late proposal to refine the update to your
question. You've asked:

1.      In the draft, I confused a sentence that said ‘The Session-Sender
MUST NOT stop the session if it receives a zeroed  SSID field.’ If a STAMP
Session-Reflector that does not support this specification and return the
zeroed SSID field in the reflected STAMP test packet, the STAMP
Session-Sender MUST stop the session. I assume there’s a edit error.

We've agreed to change s/MUST NOT/MUST/.
After more thoughts and discussions among the authors, we would ask you and
the WG to consider the change that, in our view, will make the behavior of
a Session-Sender in this scenario more flexible:
OLD TEXT:
   The Session-Sender MUST stop the session if it receives a zeroed
   SSID field.
NEW TEXT:
   The Session-Sender MAY stop the session if it
   receives a zeroed SSID field.  An implementation of a Session-Sender
   MUST support control of its behavior in such a scenario.

I greatly appreciate your comments, questions.

Regards,
Greg

---

From: wangyali <[email-masked]>
Date: Thu, 18 Jun 2020 06:41:14 +0000

Hi Greg,

Glad to receive your response. Please see inline <Yali>.

Sent: Thursday, June 18, 2020 6:50 AM

Hi Yali,
firstly, many thanks from all the authors for volunteering as the Shepherd for this document.
Secondly, I apologize for such a late proposal to refine the update to your question. You've asked:
1.      In the draft, I confused a sentence that said ‘The Session-Sender MUST NOT stop the session if it receives a zeroed  SSID field.’ If a STAMP Session-Reflector that does not support this specification and return the zeroed SSID field in the reflected STAMP test packet, the STAMP Session-Sender MUST stop the session. I assume there’s a edit error.
We've agreed to change s/MUST NOT/MUST/.
After more thoughts and discussions among the authors, we would ask you and the WG to consider the change that, in our view, will make the behavior of a Session-Sender in this scenario more flexible:

<Yali> In deed, it becomes more flexible in this scenario. I’d suggest to explicitly point out all of actions the Session-Sender should take when it does not stop the session, such as sending a base STAMP-Test packet [RFC8762], etc. Please take following Text into consideration.

OLD TEXT:

<Yali> The Session-Sender MAY stop the session if it
   receives a zeroed SSID field. An implementation of a Session-Sender
   MUST support control of its behavior in such a scenario.
   If the session is not stopped, the Session-Sender MAY send a base STAMP-Test packet [RFC8762].

Regards,
Greg

Best regards,
Yali

Hi IPPM,

Thanks,
Ian & Tommy

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 18 Jun 2020 12:54:21 -0700

Hi Yali,
thank you for your quick response and thoughtful consideration of the
proposal. Please find my notes in-line tagged GIM>>.

Regards,
Greg

On Wed, Jun 17, 2020 at 11:41 PM wangyali <[email-masked]> wrote:

> *Sent:* Thursday, June 18, 2020 6:50 AM
> After more thoughts and discussions among the authors, we would ask you
> and the WG to consider the change that, in our view, will make the behavior
> of a Session-Sender in this scenario more flexible:
>
>
>
> <Yali> In deed, it becomes more flexible in this scenario. I’d suggest to
> explicitly point out all of actions the Session-Sender should take when it
> does not stop the session, such as sending a base STAMP-Test packet
> [RFC8762], etc. Please take following Text into consideration.
>
GIM>> Thank you for accepting the idea in general. I think that requiring
that implementation controls whether the Session-Sender stops or doesn't
stop the test session upon receipt of the zeroed SSID field in the
reflected packet is necessary and sufficient. As for the exact behavior of
the Session-Sender, if it was configured to continue running the test
session, I think that we can leave space for implementors to innovate
within bounds of RFC 8762 and this specification. I agree that sending the
base STAMP packet is one of the options. Perhaps it can be provided as an
example without the use of normative language. "If the test session is not
stopped, the Session-Sender, can, for example, send a base STAMP packet
[RFC8762]." What do you think?

---

From: wangyali <[email-masked]>
Date: Sat, 20 Jun 2020 02:32:14 +0000

Hi Greg,

Thanks for your consideration. I think this sentence is fine for me.

Best regards,
Yali

Sent: Friday, June 19, 2020 3:54 AM

Hi Yali,
thank you for your quick response and thoughtful consideration of the proposal. Please find my notes in-line tagged GIM>>.

Regards,
Greg

On Wed, Jun 17, 2020 at 11:41 PM wangyali <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Hi Yali,

<Yali> In deed, it becomes more flexible in this scenario. I’d suggest to explicitly point out all of actions the Session-Sender should take when it does not stop the session, such as sending a base STAMP-Test packet [RFC8762], etc. Please take following Text into consideration.
GIM>> Thank you for accepting the idea in general. I think that requiring that implementation controls whether the Session-Sender stops or doesn't stop the test session upon receipt of the zeroed SSID field in the reflected packet is necessary and sufficient. As for the exact behavior of the Session-Sender, if it was configured to continue running the test session, I think that we can leave space for implementors to innovate within bounds of RFC 8762 and this specification. I agree that sending the base STAMP packet is one of the options. Perhaps it can be provided as an example without the use of normative language. "If the test session is not stopped, the Session-Sender, can, for example, send a base STAMP packet [RFC8762]." What do you think?

OLD TEXT:

Regards,
Greg

Best regards,
Yali

Hi IPPM,

Thanks,
Ian & Tommy