Re: [tcpm] [Idr] Last Call: <draft-ietf-tcpm-yang-tcp-06.txt> (A YANG Model for Transmission Control Protocol (TCP) Configuration) to Proposed Standard

[Jeffrey Haas <[e-mail]>]

Michael,

On Wed, Mar 02, 2022 at 10:53:54AM +0000, Scharf, Michael wrote:
> Thanks a lot for these good comments. As suggested below, I have put the TCPM list in CC in order to ensure that TCPM is in the loop.

Thanks.  Please note that I don't otherwise participate in tcpm and wouldn't
see additional threads spawned from this one unless explicitly copied.

I do want to front load one particular comment: Especially for operational
state, standards are sometimes the motivator for network components to
provide implementations to access that state.  I realize there is a tension
to try to limit work to things that exist in the field, but I also believe
we're at an inflection state similar to where we were when MIBs started to
become popular.  You will thus find me advocating in many cases for useful
operational state in the model even if it may not be commonly deployed at
the moment.

That said, this isn't my model and I am just one person who has spent too much
time in netstat variants.  These are just my opinions.


> > > From: Jeffrey Haas <[e-mail]>
> > On Feb 25, 2022, at 7:41 PM, Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>> wrote:
> 
> > I think what is meant here is RNextKeyId. This is part of TCP-AO (Section 2.2 of RFC 5925). We seem to agree that the client, e.g. BGP, should maintain a reference to the keychain it is using. Does the client need to do more than providing that reference to TCP, i.e. provide the RNextKeyId?
> 
> > > Note that I'm not arguing that this state is config state at all.  I think this one is likely operational-only state.
> > > But that rather argues what the glue is for the configuration.  And that's where the conversation below gets interesting.
> 
> [ms] We never discussed whether additional operational state is needed for TCP-AO. It is a good question, though. Whether we go down that road probably depends also on how we further proceed with TCP-AO configuration.

Agreed, in general.  The specific bit of state cited here, RNextKeyId, is
ideally short-lived operational state for when a key rollover in TCP-AO
happens.  It is primarily useful for "stuck" key roll overs.

> > > - The states exposed in the model are incomplete.  While they cover much
> > >  that is from the TCP-MIB (as noted by the discussion text), some things
> > >  like FIN_WAIT* are very helpful for troubleshooting stuck TCP sessions or
> > >  socket exhaustion.

> [ms] There was some discussion in TCPM on whether to focus on the base statistics from the TCP MIB (RFC 4022), or whether to include more stats. Note that there is a TCP Extended Statistics MIB (RFC 4898), but at least I am not aware of any implementation of that MIB.

Understood.  See near top of message my opinion on such things.

That said, tcp state for things like FIN_WAIT* are well deployed in my
experience.  (And sadly, to my operational experience in trying to
troubleshoot network and stack issues.)

> [ms] The stats defined by the TCP MIB are supported not only on several router operating systems, but e.g. also on Linux (/proc/net/snmp on a Debian Buster system). Also, there have been a report that Windows uses global stats along the lines of the MIB definitions (see  https://mailarchive.ietf.org/arch/msg/tcpm/3oMQdIrz9prgE1smt-aFTEFpqGs/ for details). Of course, operating systems may have useful stats beyond the TCP MIB. For instance, in Linux the “netstat -s” command reports also counters beyond the TCP MIB, including a counter related to FIN_WAIT, but at least some of these counters reported by “netstat -s” are Linux-specific, as they refer to Linux-internal heuristics. So, sure, we can add further stats to the YANG model, but then we need a very careful analysis whether these stats are indeed reasonably similar implemented. I have done such an analysis for some other TCP configuration parameters and even for pretty trivial parameters the existing running TCP code differs significantly. There is a significant risk that whatever we would write in a YANG model deviates from running code. TCP-AO may be partly an exception because the implementations are all fairly new.

In some of my prior kernel browsing for various operational state, I've seen
that the stats are literally named after the old MIB variables.  So, there's
examples of providing stats because standards work motivated it.

I don't advocate trying to cover everything.  For IETF work, what I
generally advocate for is things that the protocol specifications lead to.
Session state should be an easy answer.

For other things that are less supportable by common reference to RFCs but
may be widely but not pervasively deployed, YANG module authors have a
choice: Don't put it in, and permit implementors to augment the feature into
the model.  Put it in, and require implementors to deviate features they
don't support.

YANG, at least, gives us the easy option for such augmentations and
deviations.  It'll be up to the wisdom of the contributors to the Working
Group as to what makes sense in such circumstances.

> [ms] Finally, the past discussions in TCPM have quite clearly shown that TCP implementers focusing on client and server operating systems hardly care about YANG models at all. YANG may not play an important role in that space. This is also one of the reasons why draft-ietf-tcpm-yang-tcp explicitly focuses on what is needed on a router.

The network industry is currently in a management tooling interregnum.  IETF
no longer creates MIBs.  SNMP and MIBs were the only tools that were being
provided for general purpose network management.  IETF shifted its work to
YANG and protocols in the netconf suite.  Many industries are waiting for us
to finish our various bits of work so they can get on with the boring task
of satisfying network monitoring needs.

I haven't done larger scale sysadmin work in years.  But for my friends who
do it, SNMP is still used in their environments because that's what's
available.

I'm not advocating any specific IETF Working Group try to own the task of
shifting the industry to use modern tooling.  The best we can do is supply
good models so that when tooling catches up the models are available.

> [ms] The TCP connection table is *not* intended for configuration state.

Then you have an example that needs work. :-)

>  I have been told that this list has to be read-write because of YANG semantics, albeit a large part of the content is read-only.

I would be curious to see the YANG doctor analysis that lead to this
decision.  Do you have a pointer?

>  The document already explains this as follows: “TCP connection table: Access to status information for all TCP connections.  Note, the connection table is modeled as a list that is read-writeable, even though a connection cannot be created by adding entries to the table.  Similarly, deletion of connections from this list is implementation-specific.” I agree that if a TCP connection were to be established by that table, wildcards would be needed 

Asking a simple "netstat" question: How do you model sockets in the LISTEN
state?  For such sockets, how do you model listening on one address or a
wildcard address?

> – but in reality TCP connections are established by the application or service, e.g. by the sockets API. One doesn’t use a YANG model for that, at least as far as I know. If the list only includes established TCP connections, every single TCP connection has a well-defined src/dst IP address and a well-defined  src/dst port (5-tuple); on the connection initiator side, src address and src port may be selected by the stack. The current model in draft-ietf-tcpm-yang-tcp-06 also does not model a list of listeners.

My point is made for listeners.  I believe this is a model gap.

> [ms] In a nutshell, if connections cannot be created by adding entries to the list, I don’t understand why wildcards would be needed.

For operational state for listeners.  That said, I'm less advocating for
"create a connection in this table" and more about "how does a TCP client
wanting to use TCP-AO get its job done?"

> > >  + The binding between a send-id and receive-id likely belong in the
> > >    keychain.  This likely requires augmenting the keychain model.
> 
> > Did you mean binding between tcp-ao and the keychain model it is using?
> 
> I mean that send-id/receive-id state likely belongs in an individual keychain entry.  That means the keychain model needs augmenting.  The augmentation can be sourced from the tcpm RFC.
> 
> [ms] That solution (used by all known router implementations) is already explicitly explained in draft-ietf-tcpm-yang-tcp-06 as follows: “The keychain for TCP-AO can be modeled by the YANG Data Model for Key Chains [RFC8177].  The groupings defined in this document can be imported and used as part of such a preconfiguration.”

I don't find the example clear.  As noted above, configuration state in
existing implementations requires a binding of a send-id and a receive-id
(TCP-AO configuration state) to the keychain entry.

> [ms] Now, the challenge is that this solution would require an update to RFC8177, and I don’t know if and when this would happen. One option would just to define the grouping in draft-ietf-tcpm-yang-tcp and do not define its use in the keychain, i.e., to leave that open until a 8177bis document is done. We tried to find an alternative that can work with the existing RFC8177 model instead. That does not prevent use of the grouping in a future key-chain standard.

I will, perhaps unpopularly, argue that its dereliction of duty to throw
your hands up and say "we can't get our responsible component to work
because of someone else's work".

If you own the YANG model for TCP-AO, you're responsible for figuring out
how it should work.

If you can do it solely within your module, this is easy and done.

What is far more likely is that TCP-AO state needs to be coupled in with the
keychain.  If this can be done in a way that lets you satisfy providing a
useful model for TCP-AO by augmenting the keychain model, that's a
reasonable path forward.  Simply defining a grouping isn't the full extent
of the work, defining the augmentation would be.

If your analysis (because you're the group with the expertise) is that
configuration of TCP-AO does require binding of configuration state from
TCP-AO into the keychain, but the keychain has structural issues that
prevent this from being current viable, IETF as a whole has a problem: The
modules don't inter-work.

What should IETF do when such inter-work issues are identified?  Fix them.

What should tcpm or other Working Groups do about configuration state if
such inter-work issues are identified?  Perhaps hold up publishing your
model until it can be fixed - the process for fixing YANG models is painful
even for trivial things much less things that will require restructuring.
Alternatively, if operational state is fine, perhaps configuration state is
deferred to a later model while working through the issue with the other
dependent Working Groups.

> [ms] I agree that a TCP connection will typically *not* be set up by configuration state but instead by the socket APO. Thus the connection list is most likely operational state only. The unknown is how TCP-AO configuration would be provisioned in that case. If it is indeed done by the key-chain, we may not require corresponding configuration state in draft-ietf-tcpm-yang-tcp.

That's a possible way this goes.

But if the answer is that it belongs in the keychain model and the
configuration state is motivated by TCP-AO, it's reasoanble this Working
Group supplies that model.  Alternatively, this Working Group initiates the
inter-working group discussion to solve the broader problem.

Such inter-work discussions are effectively why I'm here wearing my BGP YANG
hat. :-)

> [ms] I’d also like to note that there is a related problem for TCP keep-alives (which matter more for NETCONF than for BGP, as far as I understand). The actual configuration of TCP keep-alives on a new TCP connection would most likely be done by the corresponding (NETCONF) client or server application (e.g., draft-ietf-netconf-tcp-client-server). Yet, for an established TCP connection these keep-alive parameters could also be changed, and this could be done by a TCP connection list entirely independent of the client or server application. If we want to allow that change, the TCP keep-alive configuration in the list has to be configuration state, and this is what draft-ietf-tcpm-yang-tcp-06 assumes. Well, we could decide not to allow such changes in existing connections via draft-ietf-tcpm-yang-tcp. Then the entire connection list would probably have operational state only. That could possibly simplify some things. But I really wonder if that is the only solution?

I did find the structure of the keepalives a bit peculiar.  This felt less
like a general TCP mechanism and more about supporting netconf.

For things that are related to "system tuning", you're left with an
interesting set of modeling problems.  If you're in need of letting the system
tune individual sessions, you could permit the objects in an otherwise
operational state model to be read-write.  However, I suspect your YANG
doctors would suggest that doing so leads people to the peculiar observation
that they should be able to create configuration state for such sessions.

Far more likely is you include action statements in the relevant portion of
the operational tree:
https://datatracker.ietf.org/doc/html/rfc7950#section-7.15

Or alternatively, you create an RPC for the module:
https://datatracker.ietf.org/doc/html/rfc7950#section-7.14

-- Jeff