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

[Rakesh Gandhi <[e-mail]>]

Hi Rick,

One comment inline with <RG>..

On Wed, Aug 17, 2022 at 12:40 PM Ringel, Rick <[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-

"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] | www.spirent.com
> 5280 Corporate Drive, Suite A100, Frederick, MD 21703
>
> [image: Spirent]
> <https://www.linkedin.com/company/spirent-communications/> [image:
> Spirent] <https://twitter.com/intent/user?screen_name=Spirent> [image:
> Spirent] <https://www.youtube.com/user/spirentvideos> [image: Spirent]
> <https://www.facebook.com/spirent>
> [image: 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]
> https://www.ietf.org/mailman/listinfo/ippm
>