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

[Greg Mirsky <[e-mail]>]

Hi Rick,
thank you for your work on implementing RFC 8972 (I guess that also means
you have implemented RFC 8762). Please find my notes in-lined below under
the tag GIM>>.

Please keep the IPPM WG updated about the state of STAMP implementation and
share your questions and experiences.

Regards,
Greg


On Wed, Aug 17, 2022 at 9:40 AM 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.
>
GIM>> The role of the Direct Measurement TLV is to collect "in-profile" Tx
and Rx counters. The definition of "in-profile" is outside the scope of RFC
8972. I can imagine that in some scenarios, STAMP test packets will be
accounted for as in-profile. But, as Tx and Rx counters are expected to be
outside the STAMP module and are per monitored flow, it seems like a STAMP
Session-Reflector that supports this extension will have access to those
values.

>
>
> 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.
>
GIM>> I think your idea of setting the Unrecognized flag is good.

>
>
> What should the reflector’s response be in this situation?
>
GIM>> Our expectation was that Tx and Rx counters are outside STAMP
application and are per monitored flow (as noted earlier). If that is the
case, we didn't expect that a STAMP Session-Reflector that supports the
extension will be unable to copy counter values in the reflected packet.

>
>
> 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.
>
GIM>> I need to think about that. Our intention was that a management
system would control/know the mode of each Session-Reflector system through
the use of the management plane derived based on the STAMP YANG data model
<https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-yang/>.

>
>
> 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
>