Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04

Hi Joe,

Regarding stats, this is a YANG „feature“ in draft -04. That explicitly specifies that a NETCONF server compliant to the YANG model does not have to provide the stats. We added this because of your past comment on that.

For the stats, -04 relatively closely follows the TCP-MIB (and the WG explicitly ask not to try a 1:1 mapping).

Given the pushback, here is a copy the current spec from -04:

    container statistics {
        if-feature statistics;
        config false;

        leaf active-opens {
          type yang:counter32;
          description
            "The number of times that TCP connections have made a direct
             transition to the SYN-SENT state from the CLOSED state.";
        }

        leaf passive-opens {
          type yang:counter32;
          description
            "The number of times TCP connections have made a direct
             transition to the SYN-RCVD state from the LISTEN state.";
        }

        leaf attempt-fails {
          type yang:counter32;
          description
            "The number of times that TCP connections have made a direct
             transition to the CLOSED state from either the SYN-SENT
             state or the SYN-RCVD state, plus the number of times that
             TCP connections have made a direct transition to the
             LISTEN state from the SYN-RCVD state.";
        }

        leaf establish-resets {
          type yang:counter32;
          description
            "The number of times that TCP connections have made a direct
             transition to the CLOSED state from either the ESTABLISHED
             state or the CLOSE-WAIT state.";
        }

        leaf currently-established {
          type yang:gauge32;
          description
            "The number of TCP connections for which the current state
             is either ESTABLISHED or CLOSE-WAIT.";
        }

        leaf in-segments {
          type yang:counter32;
          description
            "The total number of segments received, including those
             received in error.  This count includes segments received
             on currently established connections.";
        }

        leaf out-segments {
          type yang:counter32;
          description
            "The total number of segments sent, including those on
             current connections but excluding those containing only
             retransmitted octets.";
        }

        leaf retransmitted-segments {
          type yang:counter32;
          description
            "The total number of segments retransmitted; that is, the
             number of TCP segments transmitted containing one or more
             previously transmitted octets.";
        }

        leaf in-errors {
          type yang:counter32;
          description
            "The total number of segments received in error (e.g., bad
             TCP checksums).";
        }

        leaf out-resets {
          type yang:counter32;
          description
            "The number of TCP segments sent containing the RST flag.";
        }
…

I fully agree that we can discuss every single entry. But, at least for the stats, I don’t think this is really a lot of work. It is a fairly short list quite similar to the deployed TCP-MIB. The assumption here is that the TCP-MIB is a reasonable baseline. Is it really hard to agree on a list of counters in TCPM and publish this?

In addition, there is one difference between a YANG model (and in fact also a MIB) and a TCP API: The TCP API is tightly coupled with the TCP protocol implementation typically in the kernel. Network management apps using YANG can run outside the kernel. There are certain dependencies to configure and to retrieve operational state. Nonetheless, the implementer of a YANG model may not be the implementer of a TCP stack. That may limit the burden to the latter.

Stats, TCP-AO and MD5 (with appropriate flagging) actually look like pretty low-hanging fruits to me. Of course, we need to discuss the modeling details,  but it is a fairly narrow and well-defined scope. Is this part really the most challenging part of the document that prevents us from adopting a YANG model in TCPM?

Michael

Von: Joseph Touch<mailto:touch@strayalpha.com>
Gesendet: Freitag, 27. März 2020 16:03
An: Scharf, Michael<mailto:Michael.Scharf@hs-esslingen.de>
Cc: Lars Eggert<mailto:lars@eggert.org>; draft-scharf-tcpm-yang-tcp@ietf.org<mailto:draft-scharf-tcpm-yang-tcp@ietf.org>; tcpm IETF list<mailto:tcpm@ietf.org>; Michael Tuexen<mailto:tuexen@fh-muenster.de>
Betreff: Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04

Hi, all,

I agree with Lars that, in effect, encoding certain stats in the YANG model runs the risk of making them “expected” in an implementation; if that’s desired, the process should be inverted (decide what we think is necessary THEN add it; don’t let the model drive the requirements).

That would be a LOT of work, equivalent to extending the API for TCP. If that happens, we need to be VERY careful to not burden implementers with implementation details or requirements.

As to MD5, agreed that it’s important to include, but I would even go so far as to put it under a subtree of “Deprecated” components to make it very clear to everyone who uses them.

Joe

On Mar 27, 2020, at 7:49 AM, Scharf, Michael <Michael.Scharf@hs-esslingen.de<mailto:Michael.Scharf@hs-esslingen.de>> wrote:

I am not an expert for SNMP under Linux. But, at first sight, /proc/net/snmp provides basically all scalars from the TCP-MIB. The connection table seems missing. But those objects I would only expect when actually managing a Linux system by the SNMP protocol, not in the proc file system.

Search engines find quite a number of implementer questions on „/proc/net/snmp“. So, it seems relatively likely that there is some use. And in the area of SNMP network management, there is often not much public documentation, so a professor may not be able to figure out any details of deployed systems.

Regarding MD5, I get told that there is still running code and operational deployment, even if TCP-AO is getting traction. As users seem to ask for it, my proposal would be to add big warning signs that it is deprecated, i.e., TCP-AO should be used instead. On that aspect, the other authors could maybe also chime in.

Michael

Von: Lars Eggert<mailto:lars@eggert.org>
Gesendet: Freitag, 27. März 2020 15:15
An: Scharf, Michael<mailto:Michael.Scharf@hs-esslingen.de>
Cc: Michael Tuexen<mailto:tuexen@fh-muenster.de>; tcpm IETF list<mailto:tcpm@ietf.org>; draft-scharf-tcpm-yang-tcp@ietf.org<mailto:draft-scharf-tcpm-yang-tcp@ietf.org>
Betreff: Re: [tcpm] Request for feedback on WG adoption of draft-scharf-tcpm-yang-tcp-04

Hi,

On 2020-3-27, at 15:52, Scharf, Michael <Michael.Scharf@hs-esslingen.de<mailto:Michael.Scharf@hs-esslingen.de>> wrote:
> But, wait a second: I recommend to have a look at the output of „cat /proc/net/snmp“ under Linux (just tested on Debian Buster)…
>
> As far as I can see, these are the object definitions from the TCP-MIB. If implemented on Linux, why does the TCP-MIB not matter?

/proc/net/snmp provides the scalars (a small subset of 4022), and obviously just in text form. Are you aware of any uses?

> However, we have learnt from that: We have explicitly decided not to include extended statistics in draft-scharf-tcpm-yang-tcp. The draft currently only includes basic stats.

Well, basic stats and AO detail. (And why still MD5? We obsoleted 2385 ten years ago.)

> It is well understood that there *are* challenges with coming up for a YANG model for TCP. But if RFC 4898 got it wrong, we could learn from that, IMHO.

You are much more optimistic than I am.

Lars

_______________________________________________
tcpm mailing list
tcpm@ietf.org<mailto:tcpm@ietf.org>
https://www.ietf.org/mailman/listinfo/tcpm