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

[Greg Mirsky <[e-mail]>]

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]> 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]]
> *Sent:* Wednesday, June 26, 2019 5:48 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,
>
> 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
>
>