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

[Greg Mirsky <[e-mail]>]

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]> wrote:

> 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]>
> 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]] *On Behalf Of *Greg Mirsky
> *Sent:* Thursday, June 20, 2019 3:06 PM
> *To:* IPPM Chairs <[e-mail]>; IETF IPPM WG <[e-mail]>
> *Cc:* [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
>
>