Re: [ippm] On progressing draft-mirsky-ippm-stamp-option-tlv

[Tianran Zhou <[e-mail]>]

Hi Greg,

Very interesting discussion. I am clear about the CoS TLV.

Thanks,
Tianran

From: Greg Mirsky [mailto:[e-mail]]
Sent: Thursday, June 27, 2019 5:42 AM
To: Tianran Zhou <[e-mail]>
Cc: IETF IPPM WG <[e-mail]>; [e-mail]
Subject: Re: [ippm] On progressing draft-mirsky-ippm-stamp-option-tlv

Hi Tianran,
thank you for the great discussion. Please find my responses in-line tagged GIM3>>.

Regards,
Greg

On Tue, Jun 25, 2019 at 9:23 PM Tianran Zhou <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

Thank you very much for your clarification and taking my suggestions. Look forward to your revision.
Let’s work on this text:
NEW TEXT:
   A STAMP Session-Sender that includes the Class of Service TLV sets
   the value of the DSCP1 field and zeroes the value of the DSCP2 field.
   A STAMP Session-Reflector that received the test packet with the
   Class of Service TLV MUST include the Class of Service TLV in the
   reflected test packet.  Also, the Session-Sender MUST copy the value
   of the DSCP field of the IP header of the received STAMP test packet
   and copy it into the DSCP2 field of the reflected test packet.  And,
   at last, the Session-Reflector MUST set the value of the DSCP field
   in the IP header of the reflected test packet equal to the value of
   the DSCP1 field of the test packet it received.

1. “Also, the Session-Sender MUST copy the value of the DSCP field of the IP header of the received STAMP test packet and copy it into the DSCP2 field of the reflected test packet.”

Please make sure it’s session-reflector not session-sender. Correct?
GIM3>> Great catch, thank you!

2. My understanding dscp1 is used for the session-sender to notify the session-reflector to use the dscp1 for the reflect message transport. If so, why not just use the configuration(i.e., YANG)?
GIM3>> CoS re-mapping testing, in our view, does not require the use of many test packets in the session. In fact, to test CoS may require changing the DSCP value in the IP header and of DSCP1 in CoS TLV for each test packet transmitted by the Session-Sender.
Dscp2 is used for the session-reflector to notify the session-sender the receive packet dscp value. Why the sender need to know this, as the sender should have known this? To check if the path changed the DSCP?
GIM3>> You're right, DSCP2 returns the value of the DSCP field as received by the Session-Reflector. Re-mapping of CoS in some use cases, for example in mobile backhaul networks, is used technique to provide multiple services, i.e. 2G, 3G, LTE, over the same network. But if it is misconfigured, then it often difficult to diagnose the root cause of the problem that is viewed as an excessive packet drop of higher level service while packet drop for lower service packets is at a normal level.


Thanks,
Tianran

From: Greg Mirsky [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Wednesday, June 26, 2019 5:48 AM
To: Tianran Zhou <[e-mail]<mailto:[e-mail]>>
Cc: IETF IPPM WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [ippm] On progressing draft-mirsky-ippm-stamp-option-tlv

Hi Tianran,
many thanks for further clarifications. Please find my answers below in-lined tagged GIM2>>.

Regards,
Greg

On Mon, Jun 24, 2019 at 8:19 PM Tianran Zhou <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg，

Thanks for your reply. Please see inline.

Tianran

From: Greg Mirsky [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Monday, June 24, 2019 11:45 PM
To: Tianran Zhou <[e-mail]<mailto:[e-mail]>>
Cc: IETF IPPM WG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [ippm] On progressing draft-mirsky-ippm-stamp-option-tlv

Hi Tianran,
thank you for your interest in the proposal on the optional extensions of STAMP. Please find my answers in-line below tagged GIM>>.

Regards,
Greg

On Mon, Jun 24, 2019 at 1:59 AM Tianran Zhou <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg,

Several clarification questions after reading this draft.

1. Maybe wrt to section 4. Could you please explicitly describe the mechanism to detect the existence of TLVs, in addition to the fixed message part?
GIM>> Since the length of the base STAMP packet, and the mode, unauthenticated or authenticated, are known, the receiver of a STAMP packet can determine if there are any TLV by comparing the length of the base STAMP packet with the value of the Total length field of IP header.

[ztr]. OK. So，STAMP is IP based protocol? Or it’s udp based, so need to use the length in UDP header?
Anyway, it’s better to describe this information because from figure 1, people cannot deduce it.
GIM>> Yes, you're correct, thank you. STAMP uses UDP and thus the length of both IP and UDP headers must be included in the calculation. Hope the new text clarifies the process:
NEW TEXT:
   A STAMP node, whether Session-Sender or Session-Reflector, receiving
   a test packet MUST determine whether the packet is a base STAMP
   packet or includes one or more TLVs.  The node MUST compare the value
   in the Total Length field of the IP header and the length of the base
   STAMP test packet in the mode, unauthenticated or authenticated based
   on the configuration of the particular STAMP test session.  If the
   difference between the two values is larger than the length of IP and
   UDP headers, then the test packet includes one or more STAMP TLVs
   that immediately follow the base STAMP test packet.

2. Could you please describe the use case for each TLV you proposed? Especially the “Location TLV” and the “Class of Service TLV”. I can hardly understand why these two are useful, and how to use them to do measurement/collection.
GIM>> We'll expand the informational text for TLVs. For the Location TLV, the use is described in the draft as follows:

   The Location TLV MAY be used to determine the last-hop addressing for
   STAMP packets including source and destination IP addresses as well
   as the MAC address of the last-hop router.  Last-hop MAC address MAY
   be monitored by the Session-Sender whether there has been a path
   switch on the last hop, closest to the Session-Reflector.  The IP
   addresses and UDP port will indicate if there is a NAT router on the
   path, and allows the Session-Sender to identify the IP address of the
   Session-Reflector behind the NAT, detect changes in the NAT mapping
   that could cause sending the STAMP packets to the wrong Session-
   Reflector.

[ztr]: 1. My understanding on this paragraph is the location tlv actually includes two separate functions. One is to collect the last-hop MAC. The other is to collect the IP and port.
It seems they have very different use. Then why not split it into two TLVs? I cannot see the use case of the combination of the two parts.
GIM>> I agree that there could be practical reasons to have two TLVs. I hope other experts in the IPPM WG will share their opinions.
2. It’s still not clear to me why we need to know “whether there has been a path switch on the last hop”. How to know this based on the source MAC? Who’s source MAC? I cannot guess on the too simple description.
GIM>> Will add a use case into the future version.
3. ipv4 and ipv6 address have different length. How do I know it’s an ipv4 or ipv6 address?
GIM>> The value of the Length field may be used as the indicator of which address family being used.
4. I want to see more text on how to use IP+port to detect the NAT mapping. What’s the issue?
GIM>> Same as for the use of MAC. Will add a use case into the future version.


The use case of the Class of Service TLV is the same as of RFC 7750<https://datatracker.ietf.org/doc/rfc7750/> and draft-bailmir-ippm-twamp-dscp-ctrl-mon<https://www.ietf.org/archive/id/draft-bailmir-ippm-twamp-dscp-ctrl-mon-02.txt>.

[ztr]: Specifically, who generate the dscp1,dscp2 and ecn? based on what?
GIM2>> The explanation of the Class of Service TLV suggests that:
    o  DSCP1 - The Differentiated Services Code Point (DSCP) intended by
      the Session-Sender.  To be used as the return DSCP from the
      Session-Reflector.

   o  DSCP2 - The received value in the DSCP field at the Session-
      Reflector in the forward direction.
A new text to be added in the next update:
NEW TEXT:
   A STAMP Session-Sender that includes the Class of Service TLV sets
   the value of the DSCP1 field and zeroes the value of the DSCP2 field.
   A STAMP Session-Reflector that received the test packet with the
   Class of Service TLV MUST include the Class of Service TLV in the
   reflected test packet.  Also, the Session-Sender MUST copy the value
   of the DSCP field of the IP header of the received STAMP test packet
   and copy it into the DSCP2 field of the reflected test packet.  And,
   at last, the Session-Reflector MUST set the value of the DSCP field
   in the IP header of the reflected test packet equal to the value of
   the DSCP1 field of the test packet it received.

Does it make the intent and handling of the Class of Service TLV clearer?

Thanks,
Tianran

From: ippm [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Greg Mirsky
Sent: Thursday, June 20, 2019 3:06 PM
To: IPPM Chairs <[e-mail]<mailto:[e-mail]>>; IETF IPPM WG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [ippm] On progressing draft-mirsky-ippm-stamp-option-tlv

Dear Chairs, et al.,
authors of draft-mirsky-ippm-stamp-option-tlv believe that it is stable and detailed enough to ask for your consideration to start the WG Adoption Poll.

Regards,
Greg