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

["Scharf, Michael" <[e-mail]>]

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

 

-        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

 

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.

 

MIchael

 

From: [e-mail] <[e-mail]> 
Sent: Thursday, March 21, 2024 10:52 PM
To: Scharf, Michael <[e-mail]>; Joe Clarke (jclarke) <jclarke=[e-mail]>; Mahesh Jethanandani <[e-mail]>
Cc: Netconf <[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 < <mailto:[e-mail]> [e-mail]> 
Envoyé : mercredi 20 mars 2024 10:48
À : BOUCADAIR Mohamed INNOV/NET < <mailto:[e-mail]> [e-mail]>
Cc : Joe Clarke (jclarke) < <mailto:[e-mail]> [e-mail]>; Rob Wilton (rwilton) < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [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,  <mailto:[e-mail]> [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 < <mailto:[e-mail]> [e-mail]> 
Envoyé : mercredi 20 mars 2024 10:29
À : Joe Clarke (jclarke) < <mailto:[e-mail]> [e-mail]>
Cc : BOUCADAIR Mohamed INNOV/NET < <mailto:[e-mail]> [e-mail]>; Rob Wilton (rwilton) < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [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) < <mailto:[e-mail]> [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 < <mailto:[e-mail]> [e-mail]> on behalf of <mailto:[e-mail]> [e-mail]< <mailto:[e-mail]> [e-mail]>
Date: Tuesday, March 19, 2024 at 18:23
To: Kent Watsen < <mailto:[e-mail]> [e-mail]>, Rob Wilton (rwilton) < <mailto:[e-mail]> [e-mail]>
Cc:  <mailto:[e-mail]> [e-mail] < <mailto:[e-mail]> [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 < <mailto:[e-mail]> [e-mail]> De la part deKent Watsen
Envoyé : mercredi 20 mars 2024 06:54
À : Rob Wilton < <mailto:[e-mail]> [e-mail]>
Cc :  <mailto:[e-mail]> [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
 <mailto:[e-mail]> [e-mail]
 <https://www.ietf.org/mailman/listinfo/netconf> 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.