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

[Rakesh Gandhi <[e-mail]>]

Thanks Rick for your comments.
I will add the suggested text in the draft.

Regards,
Rakesh


On Mon, Aug 29, 2022 at 9:07 AM Ringel, Rick <[e-mail]>
wrote:

> 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]>
> 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] | www.spirent.com
> 5280 Corporate Drive, Suite A100, Frederick, MD 21703
>
> [image: Spirent]
> <https://urldefense.com/v3/__https:/www.linkedin.com/company/spirent-communications/__;!!FxRPhOnl!9XFEcdGsitYEko4K9oX9KVmEfbul8g0Y7X_CUSJeYspadQ2cz_o0v7FoM1mTC4b_X6IKXyZO73d01MjdgJqkpOM$>
>  [image: Spirent]
> <https://urldefense.com/v3/__https:/twitter.com/intent/user?screen_name=Spirent__;!!FxRPhOnl!9XFEcdGsitYEko4K9oX9KVmEfbul8g0Y7X_CUSJeYspadQ2cz_o0v7FoM1mTC4b_X6IKXyZO73d01MjdBvBkLbs$>
>  [image: Spirent]
> <https://urldefense.com/v3/__https:/www.youtube.com/user/spirentvideos__;!!FxRPhOnl!9XFEcdGsitYEko4K9oX9KVmEfbul8g0Y7X_CUSJeYspadQ2cz_o0v7FoM1mTC4b_X6IKXyZO73d01Mjdb1l7-N4$>
>  [image: Spirent]
> <https://urldefense.com/v3/__https:/www.facebook.com/spirent__;!!FxRPhOnl!9XFEcdGsitYEko4K9oX9KVmEfbul8g0Y7X_CUSJeYspadQ2cz_o0v7FoM1mTC4b_X6IKXyZO73d01MjdENRhdb0$>
> [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
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ippm__;!!FxRPhOnl!9XFEcdGsitYEko4K9oX9KVmEfbul8g0Y7X_CUSJeYspadQ2cz_o0v7FoM1mTC4b_X6IKXyZO73d01MjdvfkMy_o$>
>
>