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

[Tianran Zhou <[e-mail]>]

Hi Greg，

Thanks for your reply. Please see inline.

Tianran

From: Greg Mirsky [mailto:[e-mail]]
Sent: Monday, June 24, 2019 11:45 PM
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 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.

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.
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.
3. ipv4 and ipv6 address have different length. How do I know it’s an ipv4 or ipv6 address?
4. I want to see more text on how to use IP+port to detect the NAT mapping. What’s the issue?


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?

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