Re: [netconf] Pullback tcp-client-server also?
Kent Watsen <kent@watsen.net> Fri, 22 March 2024 20:44 UTC
Return-Path: <0100018e67e83a0b-d315bdad-2b44-4f94-823e-b27e4d3f14b1-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863F8C14F71D for <netconf@ietfa.amsl.com>; Fri, 22 Mar 2024 13:44:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.011
X-Spam-Level:
X-Spam-Status: No, score=-1.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXcJAOpJ5shI for <netconf@ietfa.amsl.com>; Fri, 22 Mar 2024 13:44:17 -0700 (PDT)
Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 939AFC14F68A for <netconf@ietf.org>; Fri, 22 Mar 2024 13:44:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1711140256; h=Content-Type:Content-Transfer-Encoding:From:Mime-Version:Subject:Date:Message-Id:References:Cc:In-Reply-To:To:Feedback-ID; bh=21Lc423Do1R95r8G5xSDC9xyenywsiJGMchTsRuaDCQ=; b=IN3GjKCOe6e1tf3AA+ipkM4KrGx/uLBx3JXj/qRqiiEgSxCY86M6QLaL0quzuHBo wLMr5TSkxZO59IHsIothhcSdZeja1E2OHFuJBxFm5RNt+i3ok8HtCQ6omItTZWSTwHq bRHAH/5/m+yZ86d3D3++zErrtBZxQaPl2Y40lWTk=
Content-Type: multipart/alternative; boundary="Apple-Mail-904466EA-C95D-4424-A3F5-FCC74520A384"
Content-Transfer-Encoding: 7bit
From: Kent Watsen <kent@watsen.net>
Mime-Version: 1.0 (1.0)
Date: Fri, 22 Mar 2024 20:44:16 +0000
Message-ID: <0100018e67e83a0b-d315bdad-2b44-4f94-823e-b27e4d3f14b1-000000@email.amazonses.com>
References: <20eb59023fb7402588bbab80b4f01a51@hs-esslingen.de>
Cc: mohamed.boucadair@orange.com, "Joe Clarke (jclarke)" <jclarke=40cisco.com@dmarc.ietf.org>, Mahesh Jethanandani <mjethanandani@gmail.com>, Netconf <netconf@ietf.org>
In-Reply-To: <20eb59023fb7402588bbab80b4f01a51@hs-esslingen.de>
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
X-Mailer: iPhone Mail (21E219)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2024.03.22-54.240.48.90
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/c2kZ_SJ6Rnzq1B7h7vsJ9oXQkG8>
Subject: Re: [netconf] Pullback tcp-client-server also?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2024 20:44:22 -0000
On Mar 22, 2024, at 4:51 PM, Scharf, Michael <Michael.Scharf@hs-esslingen.de> 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 ::)
- 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: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
Sent: Thursday, March 21, 2024 10:52 PM
To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Joe Clarke (jclarke) <jclarke=40cisco.com@dmarc.ietf.org>; Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Netconf <netconf@ietf.org>
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 <Michael.Scharf@hs-esslingen.de>
Envoyé : vendredi 22 mars 2024 03:10
À : Joe Clarke (jclarke) <jclarke=40cisco.com@dmarc.ietf.org>; BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; Mahesh Jethanandani <mjethanandani@gmail.com>
Cc : Netconf <netconf@ietf.org>
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 <netconf-bounces@ietf.org> On Behalf Of Joe Clarke (jclarke)
Sent: Wednesday, March 20, 2024 3:34 AM
To: mohamed.boucadair@orange.com; Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Netconf <netconf@ietf.org>
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 <netconf-bounces@ietf.org> on behalf of mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
Date: Tuesday, March 19, 2024 at 21:31
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [netconf] Pullback tcp-client-server also?Re,
Yes.
Cheers,
Med
De : Mahesh Jethanandani <mjethanandani@gmail.com>
Envoyé : mercredi 20 mars 2024 11:27
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
Cc : Kent Watsen <kent+ietf@watsen.net>; Netconf <netconf@ietf.org>
Objet : Re: [netconf] Pullback tcp-client-server also?
Hi Med,
On Mar 20, 2024, at 11:04 AM, mohamed.boucadair@orange.com 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 <kent+ietf@watsen.net>
Envoyé : mercredi 20 mars 2024 10:48
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
Cc : Joe Clarke (jclarke) <jclarke@cisco.com>; Rob Wilton (rwilton) <rwilton@cisco.com>; netconf@ietf.org
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.
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 <kent+ietf@watsen.net>
Envoyé : mercredi 20 mars 2024 10:29
À : Joe Clarke (jclarke) <jclarke@cisco.com>
Cc : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; Rob Wilton (rwilton) <rwilton@cisco.com>; netconf@ietf.org
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) <jclarke@cisco.com> 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
____________________________________________________________________________________________________________
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
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf" rel="nofollow">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.
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
- Re: [netconf] Pullback tcp-client-server also? mohamed.boucadair
- [netconf] Pullback tcp-client-server also? Kent Watsen
- Re: [netconf] Pullback tcp-client-server also? Joe Clarke (jclarke)
- Re: [netconf] Pullback tcp-client-server also? Kent Watsen
- Re: [netconf] Pullback tcp-client-server also? Joe Clarke (jclarke)
- Re: [netconf] Pullback tcp-client-server also? mohamed.boucadair
- Re: [netconf] Pullback tcp-client-server also? Joe Clarke (jclarke)
- Re: [netconf] Pullback tcp-client-server also? mohamed.boucadair
- Re: [netconf] Pullback tcp-client-server also? Kent Watsen
- Re: [netconf] Pullback tcp-client-server also? mohamed.boucadair
- Re: [netconf] Pullback tcp-client-server also? Mahesh Jethanandani
- Re: [netconf] Pullback tcp-client-server also? mohamed.boucadair
- Re: [netconf] Pullback tcp-client-server also? Joe Clarke (jclarke)
- Re: [netconf] Pullback tcp-client-server also? mohamed.boucadair
- Re: [netconf] Pullback tcp-client-server also? Joe Clarke (jclarke)
- Re: [netconf] Pullback tcp-client-server also? mohamed.boucadair
- Re: [netconf] Pullback tcp-client-server also? Kent Watsen
- Re: [netconf] Pullback tcp-client-server also? Joe Clarke (jclarke)
- Re: [netconf] Pullback tcp-client-server also? mohamed.boucadair
- Re: [netconf] Pullback tcp-client-server also? Scharf, Michael
- Re: [netconf] Pullback tcp-client-server also? Wim Henderickx
- Re: [netconf] Pullback tcp-client-server also? mohamed.boucadair
- Re: [netconf] Pullback tcp-client-server also? Scharf, Michael
- Re: [netconf] Pullback tcp-client-server also? Kent Watsen
- Re: [netconf] Pullback tcp-client-server also? Kent Watsen
- Re: [netconf] Pullback tcp-client-server also? Kent Watsen
- Re: [netconf] Pullback tcp-client-server also? Joe Clarke (jclarke)
- Re: [netconf] Pullback tcp-client-server also? mohamed.boucadair