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

[[e-mail]]

Hi Joe, all,

Keepalive can be distinct per AF as NATs may be present for IPv4 (see rfc5382):

   TCP connections can stay in established phase indefinitely without
   exchanging any packets.  Some end-hosts can be configured to send
   keep-alive packets on such idle connections; by default, such keep-
   alive packets are sent every 2 hours if enabled [RFC1122].

Cheers,
Med

De : Joe Clarke (jclarke) <[e-mail]>
Envoyé : jeudi 21 mars 2024 08:23
À : Kent Watsen <[e-mail]>; BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : Mahesh Jethanandani <[e-mail]>; [e-mail]
Objet : Re: [netconf] Pullback tcp-client-server also?

I could go either way here.  I went for maximum granularity, but debated with myself as to whether that would actually be needed.  In Med’s case where the top-level abstraction may hide lower, device/host-level implementation, perhaps those different service points would have different options.

That said, I’m not opposed to keeping the options outside the list as I couldn’t come up with a specific implementation off the top of my head that would need this granularity.

Joe

From: Kent Watsen <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, March 20, 2024 at 17:32
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: Joe Clarke (jclarke) <[e-mail]<mailto:[e-mail]>>, Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [netconf] Pullback tcp-client-server also?
Thank you Joe for the concrete proposal, and Med for guidance!

Question:

Why is "uses tcpcmn:tcp-common-grouping” under “local-bind” list?
    - wouldn’t the keepalive config be independent of the AF?
    - plus, many other “common” TCP nodes may be added in the future
- i.e., though only “keep alive” now, that may not be forever…

K.




On Mar 20, 2024, at 2:03 PM, [e-mail]<mailto:[e-mail]> wrote:

Re-,

Deal!

Thanks, Joe.

Cheers,
Med



Orange Restricted
De : Joe Clarke (jclarke) <[e-mail]<mailto:[e-mail]>>
Envoyé : mercredi 20 mars 2024 12:59
À : 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?



One minor comment: ‘mandatory true;’ should be removed as this is a key.

Of course.

Otherwise, we might get this part defined outside the list, but the structure shared by Joe provides more flexibility to control the connection parameters per AF:

I considered this and thought if we’re doing the list, might as well add max flexibility.

Joe

==
          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.";
            }
==


Cheer,
Med



Orange Restricted
De : Joe Clarke (jclarke) <[e-mail]<mailto:[e-mail]>>
Envoyé : mercredi 20 mars 2024 12:34
À : 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?

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 [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.
Orange Restricted



____________________________________________________________________________________________________________

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.
Orange Restricted



____________________________________________________________________________________________________________

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

____________________________________________________________________________________________________________
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.