Subject: Re: [tcpm] Open questions in draft-scharf-tcpm-yang-tcp-03

From: "Scharf, Michael" <[email-masked]>
Date: Mon, 2 Dec 2019 21:48:17 +0000

Hi Joe,

Thanks a lot for the feedback.

> -----Original Message-----
> From: Joe Touch <[email-masked]>
> Sent: Friday, November 29, 2019 6:09 PM
> To: Scharf, Michael <[email-masked]>
> Cc: tcpm IETF list <[email-masked]>; [email-masked]
> Subject: Re: [tcpm] Open questions in draft-scharf-tcpm-yang-tcp-03
> 
> Hi, Michael,
> 
> > On Nov 28, 2019, at 10:37 AM, Scharf, Michael <Michael.Scharf@hs-
> esslingen.de> wrote:
> >
> > [chair hat off]
> >
> > At IETF 106 there was not enough time left for Mahesh to present the latest
> update of the document "YANG Model for Transmission Control Protocol (TCP)
> Configuration".
> >
> > Mahesh, Vishal and me have significantly updated draft-scharf-tcpm-yang-
> tcp-03 since the last meeting. The changes are summarized in the slides that
> can be found at:
> >
> >   https://datatracker.ietf.org/meeting/106/materials/slides-106-tcpm-yang-
> model-for-transmission-control-protocol-tcp-configuration-01
> >
> > Our proposal to refine the scope of the document. This results in at least 4
> questions:
> >
> > 1. Should the model support statistics?
> 
> IMO, no - that should be a different, optional model (TCP-stats or something).

I guess using a separate module would be possible. We can try to come up with a proposal that keeps the stats separate.

> > 2. Should it model all TCP connections?
> 
> I don’t know what that means, even given the slides. I would expect there to be
> some common practice for this in YANG models, i.e., to describe how state is
> grouped by address.

The TCP-MIB had a TCP connection list, as explained in draft version -00. In YANG, the original TCP-MIB entries would look as follows (just listed here as illustration):

     +--rw tcpConnectionEntry* [tcpConnectionLocalAddressType tcpConnectionLocalAddress tcpConnectionLocalPort tcpConnectionRemAddressType tcpConnectionRemAddress tcpConnectionRemPort]
       |  +--ro tcpConnectionLocalAddressType    inet-address:InetAddressType
       |  +--ro tcpConnectionLocalAddress        inet-address:InetAddress
       |  +--ro tcpConnectionLocalPort           inet-address:InetPortNumber
       |  +--ro tcpConnectionRemAddressType      inet-address:InetAddressType
       |  +--ro tcpConnectionRemAddress          inet-address:InetAddress
       |  +--ro tcpConnectionRemPort             inet-address:InetPortNumber
       |  +--rw tcpConnectionState?              enumeration
       |  +--ro tcpConnectionProcess?            uint32

There seem to be use cases in which a TCP connection list could be useful, most notably since such a list matters for a number of application protocols. A benefit of having this in a model published by TCPM would be consistency; then other working groups would not have to reinvent the wheel when having to access a list of TCP connections.

Thus, it could make sense to add this to the YANG model. The exact modeling is TBD. It would be a list, but not identical to what is presented above.

> > 3. Add support for TCP-AO?
> 
> It should include all current standards-track options IMO.

Yep, I am working on that. Nonetheless, TCP-AO is particularly relevant for TCP stacks that can be configured by NETCONF/YANG. This is why we ask for feedback from the community.

> > 4. Add support for TCP-MD5?
> 
> For the reason above, this should not be included - it is deprecated by TCP-AO.
> If supported, it should be clearly identified as deprecated.

The question comes from implementers; apparently there is still some use of TCP-MD5 in legacy deployments. We would have to clearly flag this as deprecated and add a big warning sign in the YANG model in order to encourage TCP-AO instead. That seems doable to me. And I can hardly imagine how to pass a SEC-DIR review without big warning signs ;-)

Thanks

Michael

> Joe