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

[Greg Mirsky <[e-mail]>]

Hi Rakesh,
thank you for your thorough review and thoughtful comments. Please find my
notes below under the GIM>> tag. Attached, please find the new working
version (Google firmly believes that the diff I generated includes a virus
;)

Regards,
Greg

On Fri, Oct 13, 2023 at 8:55 AM Rakesh Gandhi <[e-mail]>
wrote:

> 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
>
GIM>> Thank you for catching it. Poor creativity in naming. Fixed to
    |  |     +--rw send-stamp-session-id       uint16

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

> --------------------------------------------------------------------------
>
>    - 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?
>
> GIM>> Great questions, thank you! As I understand, the applicability of
the FL is for IPv6. Other data planes we usually consider at IETF, e.g.,
MPLS, use other sources of the entropy information. Should the entropy
information be part of the data plane-specific configuration? Will bring
them up to the WG in the presentation at the IETF-118 and on the list.

>
>    -
>
> --------------------------------------------------------------------------
>
>    - 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
>
> GIM>> An interesting idea, thanks! Recently, we've started the work on the Precision
Availability Metric
<https://datatracker.ietf.org/doc/draft-ietf-ippm-pam/> (PAM).
The model of PAM that I imagine includes thresholds. A service monitored by
STAMP could have PAM-based thresholds defined that would trigger a variety
of actions. Would you be interested in joining in the work on the PAM YANG
data model?

--------------------------------------------------------------------------
>
>    - Reflector state model - packet counts –> incoming interface
>    identifier might be useful
>    - interface identifier in state model
>
> GIM>>  Interesting idea, thank you. Could the incoming interface change in
the course of the test session, e.g., if it is tied to a circuitless
address associated with the node that hosts the Session-Reflector?

> --------------------------------------------------------------------------
>
>    - 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
>
> GIM>> Thank you for the reference to RFC 8913. As I understood, the 'name'
is tying the Control-Client session with TWAMP-Test session and is used as
the key for both lists, e.g.,
         list test-session {
           key "name";
           description
             "List of TWAMP Session-Sender test sessions.";
           leaf name {
             type string;
             description
               "A unique name for this TWAMP-Test session to be used
                for identifying this test session by the
                Session-Sender logical entity.";
           }
Would you propose using 'name' as the key in the STAMP Session-Sender list?

> --------------------------------------------------------------------------
>
> Could we have the same range for UDP port for sender port (except 862)?
>
GIM>> range "49152..65535" for session-sender-udp-port defines range for
Source UDP port number for a STAMP test packet transmitted by a
Session-Sender.
range "862 | 1024..49151 | 49152..65535" for session-reflector-udp-port
defines the range for the Destination UDP port number  for a STAMP test
packet transmitted by a Session-Sender. The use of 1024..49151 is from the
experience of working on TR-390 Performance measurement from IP Edge to
Customer Equipment using TWAMP Lite. We've learned that some
implementations use this range on a Session-Reflector. As one of the
objectives of STAMP is its interworking with TWAMP Lite, it seems useful to
allow that range also in STAMP. WDYT?

>
>
> 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";
>
GIM>> Thank you for pointing out the discussion. Adding 1024..49151 range
was, as I recall, based on our experience with TR-390.

>
>
> --------------------------------------------------------------------------
>
> Could current stats and history stats be available on “stateful” reflector?
>
>        |     +--ro current-stats
>
> GIM>> What could be the benefit?

> --------------------------------------------------------------------------
>
> RPC: Typo?
>
>           +---w stamp-stamp-session-id    uint16
>
>
>
> Could be stamp-session-id uint16
>
GIM>> Thank you for a good catch, Fixed

> --------------------------------------------------------------------------
>
> 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.
>
GIM>> Thank you for the suggestion. I've looked at the Security
Considerations section in RFC 8913 TWAMP YANG data model. It references RFC
5357 TWAMP specification only in connection with usual use of TWAMP in a
single administrative domain. I couldn't find that YANG model inherits
security issues of the protocol. WDYT?

> --------------------------------------------------------------------------
>
> I do not see feature definitions for any tlv used in the model. E.g.,
>
> feature hmac-tlv
>
GIM>> Hmmm, p.p. 14 and 15 in TXT format
feature hmac-tlv {
  description
    "A TLV to provide the authentication protection
    for STAMP extensions.";
  reference
    "RFC 8972 STAMP
    Optional Extensions Section 4.8.";
}


>
>
> 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>].
>
GIM>> Good catch, thank you. Would you agree to changing the reference
to draft-ietf-ippm-stamp-srpm?

> --------------------------------------------------------------------------
>
>
>
>
>
>
>
>
>
>
>