[ippm] Comments on draft-ietf-ippm-stamp-yang-11

[Rakesh Gandhi <[e-mail]>]

Hello authors,

I hope you find the following comments on this draft useful.

https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-yang-11.html

thanks,
Rakesh


--------------------------------------------------------------------------

   - Session id union or unit16?

 Sender

    |  |     +--rw stamp-session-id                union



Reflector

  +--rw stamp-session-id                    uint16

--------------------------------------------------------------------------

   - STAMP test packets may be used in a VRF.
   - vrf-id field in the config and state model

--------------------------------------------------------------------------

More so, to test processing of Class-of-Service along the same route in
Equal Cost Multi-Path environment Session-Sender may perform STAMP test
sessions concurrently using the same source IP address, source UDP port
number, destination IP address, and destination UDP port number. Thus the
only parameter that can be used to differentiate these test sessions would
be DSCP value.



   - IPv6 Flow-label is used for ECMP hash.
   - FL field in config and state model



    |  |  +--rw sender-test-session* [session-sender-ip

    |  |        session-sender-udp-port session-reflector-ip

    |  |        session-reflector-udp-port dscp-value]



   - >> Add IPv6 Flow-label in above?
   - >> Add VRF-ID in above?

--------------------------------------------------------------------------

   - Anomaly threshold for delay (micro-sec value) and loss (percentage
   loss). -> For example, it can be used to trigger telemetry events.
   - config model for threshold
   - Anomaly flag in state

--------------------------------------------------------------------------

   - Reflector state model - packet counts –> incoming interface identifier
   might be useful
   - interface identifier in state model

--------------------------------------------------------------------------

   - Session name in text. Could be internal name or user configured name.
   I see the TWAMP Yang model has this and I think it is useful.
   - session name in config and state model

--------------------------------------------------------------------------

Could we have the same range for UDP port for sender port (except 862)?



FYI, there was some discussions for TWAMP yang:

https://mailarchive.ietf.org/arch/msg/ippm/FdaEPf4Z4nczS4swJxPO0YhK6iE/



  leaf session-sender-udp-port {

    type inet:port-number {

      range "49152..65535";





      leaf reflector-udp-port {

        type inet:port-number{

          range "862 | 1024..49151 | 49152..65535";



--------------------------------------------------------------------------

Could current stats and history stats be available on “stateful” reflector?

       |     +--ro current-stats

--------------------------------------------------------------------------

RPC: Typo?

          +---w stamp-stamp-session-id    uint16



Could be stamp-session-id uint16

--------------------------------------------------------------------------

Does failed or error state make sense, for example, to indicate that
packets are sent but not received back?



      leaf sender-session-state {

        type enumeration {

          enum active {

            description "Test session is active";

          }

          enum ready {

            description "Test session is idle";

          }

        }

        description

          "State of the particular STAMP test

          session at the sender";

      }



--------------------------------------------------------------------------

It is not clear how the wait timer would be used in the STAMP protocol,
stop reflecting packets after timeout?

    leaf ref-wait {

      type uint32 {

        range 1..604800;

      }

      units seconds;

      default 900;

      description

        "REFWAIT(STAMP test session timeout in seconds),

        the default value is 900";

    }

--------------------------------------------------------------------------

I think security considerations from RFC8762 would apply to this document.

--------------------------------------------------------------------------

I do not see feature definitions for any tlv used in the model. E.g.,

feature hmac-tlv



Section 1 seems to indicate TLVs for the future. Is this in the scope of
this draft?

                    The defined STAMP data model can be augmented to
include STAMP extensions, for example, described in [RFC8972
<https://www.rfc-editor.org/info/rfc8972>].

--------------------------------------------------------------------------