Re: [ippm] RFC 8972, STAMP Optional Extensions Question, RFC 8762 stateless detection

["Ringel, Rick" <[e-mail]>]

Hey Rakesh,

That new verification flag looks like a good choice.
Perhaps the new wording could be more generic, such as “ the additional instruction or request for data in one of the TLVs was not followed.”

Regards,
Rick

From: Rakesh Gandhi <[e-mail]>
Sent: Tuesday, August 23, 2022 8:57 AM
To: Ringel, Rick <[e-mail]>
Cc: [e-mail]; Foote, Footer (Nokia - CA) <[e-mail]>
Subject: Re: [ippm] RFC 8972, STAMP Optional Extensions Question, RFC 8762 stateless detection

[Warning] This email comes from an external source. Be careful of any embedded links and attachments.
Hi Rick,

One comment inline with <RG>..

On Wed, Aug 17, 2022 at 12:40 PM Ringel, Rick <[e-mail]<mailto:[e-mail]>> wrote:


I’m working to implement the DirectMeasurement TLV as described in RFC 8972.  There is a scenario where the reflector cannot give a correct response, but the available TLV flags don’t allow the reflector to signal this to the sender.

A STAMP reflector can be started in stateless mode, in which case the reflector has no tx/rx counters to use in the DirectMeasurement TLV response.

I am currently setting the ‘Unrecognized’ flag so the sender doesn’t try to interpret the results, but this seems inconsistent with the intent of the flag.

<RG>
V Flag defined (at bit position 3) in the following draft may be useful in this case.
https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-srpm-05.html#name-verification-check-flag-in-<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-ippm-stamp-srpm-05.html*name-verification-check-flag-in-__;Iw!!FxRPhOnl!9XFEcdGsitYEko4K9oX9KVmEfbul8g0Y7X_CUSJeYspadQ2cz_o0v7FoM1mTC4b_X6IKXyZO73d01MjdJ4_klyk$>

"For example, Session-Reflector supports the TLV and it is well-formed, the STAMP test packet including all the TLVs was successfully processed but the additional instruction in one of the TLVs was not followed."

If it makes sense, the draft can add some text to cover the stateless reflector for the direct measurement tlv case.

Thanks,
Rakesh



What should the reflector’s response be in this situation?

I have played with algorithms on the sender side to determine if the reflector is stateful or stateless, as described in RFC 8762.  The best I have come up with is seeding the sender sequence number with a non-zero value on the first transmission.  If the reflector responds with a matching sequence number, it is stateless.  The sender can then inhibit transmission of the DirectMeasurement TLV.   Have I missed something in the RFC regarding the sender’s method for determining stateful/stateless reflectors?  The RFC says the sender sequence number should start at zero, so this is a bit of a hack.

I look forward to your response.

Rick Ringel
Senior Software Engineer

[e-mail]<mailto:[e-mail]> | www.spirent.com<http://www.spirent.com/>
5280 Corporate Drive, Suite A100, Frederick, MD 21703
[Spirent]<https://urldefense.com/v3/__https:/www.linkedin.com/company/spirent-communications/__;!!FxRPhOnl!9XFEcdGsitYEko4K9oX9KVmEfbul8g0Y7X_CUSJeYspadQ2cz_o0v7FoM1mTC4b_X6IKXyZO73d01MjdgJqkpOM$> [Spirent] <https://urldefense.com/v3/__https:/twitter.com/intent/user?screen_name=Spirent__;!!FxRPhOnl!9XFEcdGsitYEko4K9oX9KVmEfbul8g0Y7X_CUSJeYspadQ2cz_o0v7FoM1mTC4b_X6IKXyZO73d01MjdBvBkLbs$>  [Spirent] <https://urldefense.com/v3/__https:/www.youtube.com/user/spirentvideos__;!!FxRPhOnl!9XFEcdGsitYEko4K9oX9KVmEfbul8g0Y7X_CUSJeYspadQ2cz_o0v7FoM1mTC4b_X6IKXyZO73d01Mjdb1l7-N4$>  [Spirent] <https://urldefense.com/v3/__https:/www.facebook.com/spirent__;!!FxRPhOnl!9XFEcdGsitYEko4K9oX9KVmEfbul8g0Y7X_CUSJeYspadQ2cz_o0v7FoM1mTC4b_X6IKXyZO73d01MjdENRhdb0$>
[Spirent]<http://www.spirent.com/>
Spirent Communications e-mail confidentiality.
This email and the information contained therein may contain private, confidential or privileged material solely meant for the intended recipient. If you are not the intended recipient review, copying or distribution is forbidden. Further, if you are not the intended recipient, please contact the sender immediately and permanently delete this email and any copies or attachments.

_______________________________________________
ippm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ippm__;!!FxRPhOnl!9XFEcdGsitYEko4K9oX9KVmEfbul8g0Y7X_CUSJeYspadQ2cz_o0v7FoM1mTC4b_X6IKXyZO73d01MjdvfkMy_o$>