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

[Rakesh Gandhi <[e-mail]>]

Hi Greg,

Thanks for your reply to my comments. Please see additional comments below
with <RG1>....

On Thu, Oct 19, 2023 at 6:09 PM Greg Mirsky <[e-mail]> wrote:

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

<RG1> I wasn't sure why this is still union and not 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?
>>
>> 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.
>

<RG1> Ok. Hope we can discuss both VRF ID and EL/FL.




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

<RG1> Yes, sure.


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

<RG> Yes, it can change. But that's ok, it's current state information.


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


<RG1> Name can be added either as a key or in the data for the session.
Maybe keep it consistent with RFC8913??




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


<RG1> I think it is good to add 1024..49151 in the sender-udp-port range as
well.


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


<RG1> It is a stateful reflector, so it does have state information:) Good
to be able to see it.



> --------------------------------------------------------------------------
>>
>> 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";
>>
>>       }
>>
>>
>>
>

<RG1> Any thoughts on this?



> --------------------------------------------------------------------------
>>
>> 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";
>>
>>     }
>>
>

<RG1> Any thoughts on this?



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

<RG1> I checked some other yang models, they also do not have them. I am ok
to skip this.



> --------------------------------------------------------------------------
>>
>> 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.";
> }
>

<RG1> I meant, the TLVs defined (as feature) are not used (i.e.,
referenced) in the model.



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


<RG1> I wasn't sure if RFC8972 is included in the Yang model or if it is
planned for future work.

thanks,
Rakesh



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