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

[Kent Watsen <[e-mail]>]

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] 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