Re: [netconf] Pullback tcp-client-server also?

[Kent Watsen <[e-mail]>]

Dear WG (especially Joe, Med, and Wim).

Michael and I discussed offline.   We discussed 1) a possibility of aligning the model/text with draft-ietf-tcpm-yang-tcp, 2) how best to support keep-alives, and 3) better wording for the “list local-bind” description statement.

1) Regarding aligning the model/text with draft-ietf-tcpm-yang-tcp, there are two considerations: 

    A) the tcpm model uses a “union” for the “local-address” node, in represent values
        from the TCP MIB.   However, since the netconf model doesn’t need to support 
        the TCP MIB values, this union in unnecessary.

    b) the tcpm description text for the “local-address” and “local-port” nodes are written
        In context of a list containing three keys.  However, since the netconf model has
        only two keys (and rightly so), this text would have to be adjusted to suit.  This
        being the case, keeping what we have seems better.

2) Regarding how to best support keep-alives.   There was some discussion earlier in this thread about moving it to be per list-entry (for maximum flexibility).  However Michael says that this may be unsupported in some TCP-stacks.  Furthermore, as a general observation, the IETF is trying to NOT promote the use to TCP-level keepalives, and hence adding complexity for them isn’t worth it.

3) Regarding the “list local-bind” description statement, where it says “¸as well as the case where a single service family may use different local-ports for different address families”, Michael says that this should be s/address families/addresses/.  That said, after looking more carefully, I found that the description could be simplified in a way that eliminated the problematic sentence altogether (see below).

In addition to the above, I found the proposal for the “local-bind” list to be keyed by both the “local-address” and “local-port” problematic.  The issue is that YANG doesn’t allow “default” values for keys (https://github.com/netmod-wg/yang-next/issues/62), and forcing well-known port values to always have to be specified seems overkill to support what appears to be an edge-case (listening to two different ports for the same "local-address” value.  Thus, I simplified the key to be just the “local-address” node.

The net-net follows:

  Tree Diagram:

        grouping tcp-server-grouping:
          +-- local-bind* [local-address]
          |  +-- local-address?   inet:ip-address
          |  +-- local-port?      inet:port-number
          +-- keepalives! {keepalives-supported,tcp-server-keepalives}?
             +-- idle-time?        uint16
             +-- max-probes?       uint16
             +-- probe-interval?   uint16

  YANG:

      grouping tcp-server-grouping {
        description
          "A reusable grouping for configuring a TCP server.

           Note that this grouping uses fairly typical descendant
           node names such that a stack of 'uses' statements will
           have name conflicts.  It is intended that the consuming
           data model will resolve the issue (e.g., by wrapping
           the 'uses' statement in a container called
           'tcp-server-parameters').  This model purposely does
           not do this itself so as to provide maximum flexibility
           to consuming models.";
        list local-bind {
          key local-address;
          description
            "A list of bind (listen) points for this server
             instance.  A server instance may have multiple
             bind points to support, e.g., the same port in
             different address families or different ports
             in the same address family.";
          leaf local-address {
            type inet:ip-address;
            description
              "The local IP address to listen on for incoming
               TCP client connections.  To configure listening
               on all IPv4 addresses the value must be '0.0.0.0'
               (INADDR_ANY).  To configure listening on all IPv6
               addresses the value must be '::' (INADDR6_ANY).";
          }
          leaf local-port {
            type inet:port-number;
            default "0";
            description
              "The local port number to listen on for incoming TCP
               client connections.  An invalid default value (0)
               is used (instead of 'mandatory true') so that an
               application level data model may 'refine' it with
               an application specific default port number value.";
          }
        }
        uses tcpcmn:tcp-common-grouping {
          refine "keepalives" {
            if-feature "tcp-server-keepalives";
            description
              "An if-feature statement so that implementations
               can choose to support TCP server keepalives.";
          }
        }
      }

Please review/bless the above - thank you!

Kent // author


> On Mar 22, 2024, at 4:44 PM, Kent Watsen <[e-mail]> wrote:
> 
> Thank you Michael and Med for carrying thing conversation forward. 
> 
>> On Mar 22, 2024, at 4:51 PM, Scharf, Michael <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> Hi Med,
>>  
>> I agree that reusable structures make sense. 
>>  
>> This is why I try to understand whether draft-ietf-netconf-tcp-client-server could use the same structure like draft-ietf-tcpm-yang-tcp.
>>  
>> As far as I understand so far, there may be two challenges in this discussion:
>>  
>> -        A TCP listener (server) that supports dual-stack (i.e., 0.0.0.0 and ::)
> 
> This is for sure the primary goal, to support v4 to v6 transition…
> 
> I almost wonder if the YANG model shouldn’t have “max-elements 2” and “key type”, as opposed to key "type address port". 
> 
> 
>> -        A server application that listens on multiple different IP addresses (other than 0.0.0.0 and ::, possibly with different AF), which might require separate sockets when the sockets API is used
> 
> This may be a goal.  For instance, having ‘sshd’ listen to both a public and private V4 address [1]. 
> 
> But this is rather app-specific.  Just because SSHD can do this doesn’t mean every TCP-based app can. 
> 
> [1] https://www.cyberciti.biz/tips/howto-openssh-sshd-listen-multiple-ip-address.html
> 
> 
>>  Please let me know if this is a misunderstanding.
>>  
>> The latter may be relevant for a service model, but AFAIK the network stack considers this as separate TCP listeners.
> 
> 
> For max flexibility, the model can allow lists with no “max-elements” and overlapping AFs.   But, since the max-flex case isn’t universal, I’d hope that consuming models could restrict it as needed (e.g., to the simple dual-stack case)
> 
>>  MIchael
> 
> Kent
> 
> 
>> From: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>> 
>> Sent: Thursday, March 21, 2024 10:52 PM
>> To: Scharf, Michael <[e-mail] <mailto:[e-mail]>>; Joe Clarke (jclarke) <jclarke=[e-mail] <mailto:jclarke=[e-mail]>>; Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>>
>> Cc: Netconf <[e-mail] <mailto:[e-mail]>>
>> Subject: RE: [netconf] Pullback tcp-client-server also?
>>  
>> Hi Michael, 
>>  
>> > At first sight, this leaf can model the example below. Or do I miss something?
>>  
>> It can be modeled in draft-ietf-tcpm-yang-tcp because you have a list indexed per AF:
>>  
>> ==
>>        list tcp-listeners {
>>          key "type address port";
>>          config false;
>>  
>>          description
>>            "A table containing information about a particular
>>             TCP listener.";
>>  
>>          leaf type {
>>            type inet:ip-version;
>>            description
>>              "The address type of address.  The value
>>               should be unspecified (0) if connection initiations
>>               to all local IP addresses are accepted.";
>>          }
>> ==
>>  
>> The common model does not have that. The point was to have a reusable structure that would capture typical combinations, including when the structure is used in upper layers (service and network models).
>>  
>> Cheers,
>> Med
>>  
>> De : Scharf, Michael <[e-mail] <mailto:[e-mail]>> 
>> Envoyé : vendredi 22 mars 2024 03:10
>> À : Joe Clarke (jclarke) <jclarke=[e-mail] <mailto:jclarke=[e-mail]>>; BOUCADAIR Mohamed INNOV/NET <[e-mail] <mailto:[e-mail]>>; Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>>
>> Cc : Netconf <[e-mail] <mailto:[e-mail]>>
>> Objet : RE: [netconf] Pullback tcp-client-server also?
>>  
>> Hi all,
>>  
>> Sorry for chiming in late. This week I am very busy in my day job.
>>  
>> I still try to fully understand the problem while catching up. I apologize if I miss something.
>>  
>> To start with, I’d like to highlight that at first sight draft-ietf-tcpm-yang-tcp has to solve a similar problem.
>>  
>> Well, draft-ietf-netconf-tcp-client-server is more about the application view, whereas draft-ietf-tcpm-yang-tcp is about the stack-internal view. But they are related, and draft-ietf-tcpm-yang-tcp waits in the RFC editor queue…
>>  
>> In draft-ietf-tcpm-yang-tcp, the solution for a TCP listener (i.e., server) is:
>>  
>>      leaf address {
>>         type union {
>>           type inet:ip-address;
>>           type string {
>>             length 0;
>>           }
>>         }
>>         description
>>           "The local IP address for this TCP connection.
>>  
>>            The value of this node can be represented in three
>>            possible ways, depending on the characteristics of the
>>            listening application:
>>  
>>            1. For an application willing to accept both IPv4 and
>>               IPv6 datagrams, the value of this node must be
>>               ''h (a zero-length octet-string), with the value
>>               of the corresponding 'type' object being
>>               unspecified (0).
>>  
>>            2. For an application willing to accept only IPv4 or
>>               IPv6 datagrams, the value of this node must be
>>               '0.0.0.0' or '::' respectively, with
>>               'type' representing the appropriate address type.
>>  
>>            3. For an application which is listening for data
>>               destined only to a specific IP address, the value
>>               of this node is the specific local address, with
>>               'type' representing the appropriate address type.";
>>       }
>>  
>> This solution also supports dual-stack. As far as I recall, there was some discussion on how to model dual-stack, and this is what we ended up with.
>>  
>> At first sight, this leaf can model the example below. Or do I miss something?
>>  
>> Thanks
>>  
>> Michael
>>  
>>  
>>  
>> From: netconf <[e-mail] <mailto:[e-mail]>> On Behalf Of Joe Clarke (jclarke)
>> Sent: Wednesday, March 20, 2024 3:34 AM
>> To: [e-mail] <mailto:[e-mail]>; Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>>
>> Cc: Netconf <[e-mail] <mailto:[e-mail]>>
>> Subject: Re: [netconf] Pullback tcp-client-server also?
>>  
>> As I thought about this more and consider Med’s DHC example, I kept coming back to how services are defined in a UNIX /etc/services file.  In Med’s example, DHCPv4 and DHCPv6 each have different services for client and server.  If I were implementing the “tcp-server-grouping” for a given service on a host, a leaf-list would be sufficient (as I’d have two different daemons or at least two different config blocks for v4 and v6).
>>  
>> However, Med is making the point that if this was to be implemented at a controller or higher abstraction level he wants to offer a “DHC” service as a single entity.  In this case, he’d like to have all DHC-capabilities under one service config (albeit that is more of an example for UDP server).
>>  
>> Concretely, I think he is proposing something like the attached snippet (Med, correct me if I’m wrong).  In this case, if I had an SSH server as an example that used different ports for different address families I would have (in XML):
>>  
>> <tcp-server xmlns="urn:ietf:params:xml:ns:yang:ietf-tcp-server">
>>   <local-bind>
>>     <local-address>0.0.0.0</local-address>
>>     <local-port>22</local-port>
>>     <keepalives>
>>       <idle-time>7200</idle-time>
>>       <max-probes>9</max-probes>
>>       <probe-interval>75</probe-interval>
>>     </keepalives>
>>   </local-bind>
>>   <local-bind>
>>     <local-address>::</local-address>
>>     <local-port>22022</local-port>
>>     <keepalives>
>>       <idle-time>7200</idle-time>
>>       <max-probes>9</max-probes>
>>       <probe-interval>75</probe-interval>
>>     </keepalives>
>>   </local-bind>
>> </tcp-server>
>>  
>> Yes, this adds complexity in order to get more flexibility, but you can still do the same ports for a given server such as:
>>  
>> <tcp-server xmlns="urn:ietf:params:xml:ns:yang:ietf-tcp-server">
>>   <local-bind>
>>     <local-address>0.0.0.0</local-address>
>>     <local-port>22</local-port>
>>     <keepalives>
>>       <idle-time>7200</idle-time>
>>       <max-probes>9</max-probes>
>>       <probe-interval>75</probe-interval>
>>     </keepalives>
>>   </local-bind>
>>   <local-bind>
>>     <local-address>::</local-address>
>>     <local-port>22</local-port>
>>     <keepalives>
>>       <idle-time>7200</idle-time>
>>       <max-probes>9</max-probes>
>>       <probe-interval>75</probe-interval>
>>     </keepalives>
>>   </local-bind>
>> </tcp-server>
>>  
>>  
>>   Joe
>>  
>> From: netconf <[e-mail] <mailto:[e-mail]>> on behalf of [e-mail] <mailto:[e-mail]><[e-mail] <mailto:[e-mail]>>
>> Date: Tuesday, March 19, 2024 at 21:31
>> To: Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>>
>> Cc: Netconf <[e-mail] <mailto:[e-mail]>>
>> Subject: Re: [netconf] Pullback tcp-client-server also?
>> 
>> Re, 
>>  
>> Yes.
>>  
>> Cheers,
>> Med
>>  
>> De : Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>> 
>> Envoyé : mercredi 20 mars 2024 11:27
>> À : BOUCADAIR Mohamed INNOV/NET <[e-mail] <mailto:[e-mail]>>
>> Cc : Kent Watsen <[e-mail] <mailto:[e-mail]>>; Netconf <[e-mail] <mailto:[e-mail]>>
>> Objet : Re: [netconf] Pullback tcp-client-server also?
>>  
>> Hi Med,
>>  
>>  
>> 
>> On Mar 20, 2024, at 11:04 AM, [e-mail] <mailto:[e-mail]> wrote:
>>  
>> Re-,
>>  
>> As Joe rightfully mentioned, running different instances is likely to happen at the device level. For that case, the leaf-list approach is just fine. 
>>  
>> Now, when the model is reused in upper layers (network or service models), that would not be sufficient. Think about a DHC service model which hides the internal of the service (whether this is dhcp or dhcpv6) but simply needs to expose where the dhc service is enabled: distinct ports are required for that case.
>>  
>> [mj] So a list of local-address and local-port?
>>  
>> Cheers.
>>  
>> 
>>  
>> Cheers,
>> Med
>>  
>> De : Kent Watsen <[e-mail] <mailto:[e-mail]>> 
>> Envoyé : mercredi 20 mars 2024 10:48
>> À : BOUCADAIR Mohamed INNOV/NET <[e-mail] <mailto:[e-mail]>>
>> Cc : Joe Clarke (jclarke) <[e-mail] <mailto:[e-mail]>>; Rob Wilton (rwilton) <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>> Objet : Re: [netconf] Pullback tcp-client-server also?
>>  
>> Hi Med,
>>  
>> Do you mean a list of “local-address + local-port” tuples?
>>  
>> Can you post a concrete proposal?
>>  
>> K. 
>>  
>>  
>> On Mar 20, 2024, at 10:36 AM, [e-mail] <mailto:[e-mail]> wrote:
>> 
>>  
>> Re-,
>>  
>> This would address the first cases I mentioned, but not the third one.
>>  
>> At least some narrative text is needed to explain the intended use of distinct port per AF. A cleaner approach would to model this is as a list keyed per AF.
>>  
>> Cheers,
>> Med
>>  
>> De : Kent Watsen <[e-mail] <mailto:[e-mail]>> 
>> Envoyé : mercredi 20 mars 2024 10:29
>> À : Joe Clarke (jclarke) <[e-mail] <mailto:[e-mail]>>
>> Cc : BOUCADAIR Mohamed INNOV/NET <[e-mail] <mailto:[e-mail]>>; Rob Wilton (rwilton) <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>> Objet : Re: [netconf] Pullback tcp-client-server also?
>>  
>> Thanks Med and Joe.  I had a sidebar with Rob and Mahesh, and we’re going to do this update in Auth48.  
>>  
>> Let us (the WG) agree on the exact change.  
>>   1) change ‘leaf’ to ‘leaf-list’
>>   2) tweak the ‘description’ to say that it’s a list
>>   
>> Anything else?  Do we need to disallow shadows?  (e.g., two wildcards)
>>  
>> K. 
>>  
>>  
>> On Mar 20, 2024, at 9:02 AM, Joe Clarke (jclarke) <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>>  
>> I agree with Med.  Your description is an either/or, but one server might do something like:
>>  
>> tcp46      0      0 *.9100                 *.*                    LISTEN ç Listen on all v4 and v6 addresses
>>  
>> Or:
>>  
>> tcp4       0      0 127.0.0.1.25           *.*                    LISTEN çListen on just v4 on an explicit address
>>  
>> Or:
>>  
>> tcp6       0      0 ::1.25   *.*                              LISTEN ç Listen on just v6 on an explicit address
>>  
>> In the first case, I’d think you’d at least need a leaf-list to hold both 0.0.0.0 and ::.  In the second two cases, you’d want this service to have a leaf list for 127.0.0.1 and ::1.
>>  
>> Joe
>>  
>> From: netconf <[e-mail] <mailto:[e-mail]>> on behalf [e-mail] <mailto:[e-mail]><[e-mail] <mailto:[e-mail]>>
>> Date: Tuesday, March 19, 2024 at 18:23
>> To: Kent Watsen <[e-mail] <mailto:[e-mail]>>, Rob Wilton (rwilton) <[e-mail] <mailto:[e-mail]>>
>> Cc: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
>> Subject: Re: [netconf] Pullback tcp-client-server also?
>> 
>> Hi Kent, all,
>>  
>> When I initially raised the issue for the UDP grouping, I had in mind any, IPv4/IPv6 explicit address bindings, and eventually listening on distinct port numbers per AF. Given this is a reusable model, these cases should be all covered.
>>  
>> Cheers,
>> Med
>>  
>> De : netconf <[e-mail] <mailto:[e-mail]>> De la part deKent Watsen
>> Envoyé : mercredi 20 mars 2024 06:54
>> À : Rob Wilton <[e-mail] <mailto:[e-mail]>>
>> Cc : [e-mail] <mailto:[e-mail]>
>> Objet : [netconf] Pullback tcp-client-server also?
>>  
>> Rob, Netconf, 
>>  
>> Regarding support for “dual-stack”, do we need to convert from a “leaf” to a “leaf-list”?
>>  
>> Please note that the existing text says that a wildcard card may be used to bind to all addresses:
>>  
>> leaf local-address {
>>       type inet:ip-address;
>>       mandatory true;
>>       description
>>         "The local IP address to listen on for incoming
>>          TCP client connections.  INADDR_ANY (0.0.0.0) or
>>          INADDR6_ANY (0:0:0:0:0:0:0:0 a.k.a. ::) MUST be
>>          used when the server is to listen on all IPv4 or
>>          IPv6 address.";
>>     }
>>  
>> Good enough?
>>  
>> Kent 
>>  
>> ____________________________________________________________________________________________________________
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>  
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>> ____________________________________________________________________________________________________________
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>  
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>> ____________________________________________________________________________________________________________
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>  
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>> _______________________________________________
>> netconf mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/netconf
>>  
>> 
>> Mahesh Jethanandani
>> [e-mail] <mailto:[e-mail]>
>>  
>>  
>>  
>>  
>> 
>>  
>> ____________________________________________________________________________________________________________
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>  
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>> _______________________________________________
>> netconf mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/netconf
> _______________________________________________
> netconf mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netconf