Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model
Gyan Mishra <hayabusagsm@gmail.com> Fri, 29 July 2022 15:19 UTC
Return-Path: <hayabusagsm@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF28C157B52 for <tcpm@ietfa.amsl.com>; Fri, 29 Jul 2022 08:19:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xmyNOh2cISqA for <tcpm@ietfa.amsl.com>; Fri, 29 Jul 2022 08:19:50 -0700 (PDT)
Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE325C157B36 for <tcpm@ietf.org>; Fri, 29 Jul 2022 08:19:50 -0700 (PDT)
Received: by mail-pf1-x432.google.com with SMTP id g12so4912622pfb.3 for <tcpm@ietf.org>; Fri, 29 Jul 2022 08:19:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hyL+HGklZ9VUoNh6EfnGOrI28WMfB6qe9D3EV2H1x3I=; b=XVMZ83TmGTFfYhpQT64t1D5+x46XzizZSM45c349CQi+c2lUKr1o5/mzxP+jKHHCvg 3t5y3IqL08tlTnkY+7FJnoWFfElQnpyGr/TDFKmBgxlv8JD8qfHEfXW/C1P0HnwmfT2P MMWKzpscxcWbZeTI7MFDpQvo8n8Ox6J3t9Q/UktQ/vQJ7OzRN42CN5hPp7il+iWwUHyi KF914UCNJSRJBWw+vL0k0+y/MF+b9CmZStzJexToPRgoKSwA8VZFkyJWl39LbFdHq+1l BugM5fYjYq1tKNaPF9ZDt1ZzbdKOdHs6tOLiwXI4GkekkypUlO7jfLuULHN+O6azNiSo hLOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hyL+HGklZ9VUoNh6EfnGOrI28WMfB6qe9D3EV2H1x3I=; b=eIZWuYap4BKpjIkZRAzZq0O2t1+wSPdCOY23xO9xeqvW4Kon8+d8wux2thWf6fsQet nTqgJ/Z2THy1KEv7CpvZXRyfUQj2BGjH6fiNfl5PlU4UtRMr8FnE/bPP+CJ/euHVUEog cwJcBOLqNaqX4KmXM/XSaOkCEo534BvDbFfR9xsyzMMNBEyf8bteaK7TYh7u8trnNsTn 7cJreQD+U+n7Z6wwZQUF/aza0+48brivk6EyYV5lYoMta2F0z1phmHe86hxZ45Mji+Uy eVhmSrdG6A3t14bDSbR0iAYh2e0BGyjcFA5DCOR9959r6gZyc22DDG2PTETxyqvrxVb1 KC8g==
X-Gm-Message-State: AJIora/qpK5VztHvMQ4zEKeHjd45SeLSpscBAknxCsSMGjouEgTgMwfZ tJDm3kG9LKztj0rZpptyi8sLXNZzIPzgJGbPlKE=
X-Google-Smtp-Source: AGRyM1sVpOPVNUrSwUrB3Z4pcd4YYxhHe76S5WyLyAlHMjVu4NJDRUw1fvSifKvRPyCowsuS0fThXqe8p4hy0lR9trw=
X-Received: by 2002:a05:6a00:428e:b0:52b:7e40:56cf with SMTP id bx14-20020a056a00428e00b0052b7e4056cfmr3934448pfb.72.1659107989820; Fri, 29 Jul 2022 08:19:49 -0700 (PDT)
MIME-Version: 1.0
References: <CAJhXr9-zcJg99ML3MSNMTvRFiT_BLzJihQucAdX8MZGDZ84dWw@mail.gmail.com> <CABNhwV1wz2Uhx+DWjabzVz8GAhQD78NFKhq2az=E7dhnxTC-Ww@mail.gmail.com> <A8851A57-748D-4504-97B6-677807EE0DB6@lurchi.franken.de> <EF72E595-0B1E-4AD9-BDFE-603B9B200F0D@strayalpha.com> <aea35a2d93c544a8affe6b0b75d69eca@hs-esslingen.de>
In-Reply-To: <aea35a2d93c544a8affe6b0b75d69eca@hs-esslingen.de>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 29 Jul 2022 11:19:38 -0400
Message-ID: <CABNhwV3Jsv99qMbO=a=EynTNzC9hUgciTaYscddLnmoU+VzD=g@mail.gmail.com>
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
Cc: Jeffrey Haas <jhaas@pfrc.org>, Michael Tuexen <michael.tuexen@lurchi.franken.de>, Robert Raszuk <robert@raszuk.net>, Susan Hares <shares@ndzh.com>, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>, tcpm IETF list <tcpm@ietf.org>, "touch@strayalpha.com" <touch@strayalpha.com>
Content-Type: multipart/alternative; boundary="000000000000609a4d05e4f32e36"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/m9DA9AldKrvF8hEHve9MnNyd4xA>
Subject: Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2022 15:19:55 -0000
Hi Michael See in-line Thanks Gyan On Wed, Jul 27, 2022 at 10:13 AM Scharf, Michael < Michael.Scharf@hs-esslingen.de> wrote: > Hi all, > > See below... > > > -----Original Message----- > > From: tcpm <tcpm-bounces@ietf.org> On Behalf Of touch@strayalpha.com > > Sent: Wednesday, July 27, 2022 4:13 AM > > To: Michael Tuexen <michael.tuexen@lurchi.franken.de> > > Cc: Gyan Mishra <hayabusagsm@gmail.com>; tcpm IETF list > > <tcpm@ietf.org>; Robert Raszuk <robert@raszuk.net>; Van De Velde, > > Gunter (Nokia - BE/Antwerp) <gunter.van_de_velde@nokia.com>; Jeffrey > > Haas <jhaas@pfrc.org>; Susan Hares <shares@ndzh.com> > > Subject: Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model > > > > Notes below. > > > > > On Jul 26, 2022, at 6:19 PM, Michael Tuexen > > <michael.tuexen@lurchi.franken.de> wrote: > > > > > >> > > >> > > >> Dear TCPM > > >> > > >> Attached is the slide deck for the NG TCP Yang model discussion. > > >> > > >> Sue, Robert, Jeff, Gunter > > >> > > >> Please review and let me know if I missed any talking points for the > NG > > TCP Yang model. > > > A couple of clarifying questions related to slide "What to add to NG > TCP > > Yang Model?", > > > especially since I know almost nothing about YANG: > > > > > > • All TCP states part of the FSM state machine. > > > Understood. > > These make sense. > > Indeed. > > draft-ietf-tcpm-yang-tcp-07 already models the states of a TCP connection, > using the definitions from 793bis: > > <snip> > leaf state { > type enumeration { > enum closed { > value 1; > description > "Connection is closed. Connections in this state > may not appear in this list."; > } > enum listen { > value 2; > description > "Represents waiting for a connection request from any > remote TCP peer and port."; > } > enum syn-sent { > value 3; > description > "Represents waiting for a matching connection request > after having sent a connection request."; > } > enum syn-received { > value 4; > description > "Represents waiting for a confirming connection > request acknowledgment after having both received > and sent a connection request."; > } > enum established { > value 5; > description > "Represents an open connection, data received can be > delivered to the user. The normal state for the data > transfer phase of the connection."; > } > enum fin-wait-1 { > value 6; > description > "Represents waiting for a connection termination > request from the remote TCP peer, or an > acknowledgment of the connection termination request > previously sent."; > } > enum fin-wait-2 { > value 7; > description > "Represents waiting for a connection termination > request from the remote TCP peer."; > } > enum close-wait { > value 8; > description > "Represents waiting for a connection termination > request from the local user."; > } > enum last-ack { > value 9; > description > "Represents waiting for an acknowledgment of the > connection termination request previously sent to > the remote TCP peer (this termination request sent > to the remote TCP peer already included an > acknowledgment of the termination request sent from > the remote TCP peer)"; > } > enum closing { > value 10; > description > "Represents waiting for a connection termination > request acknowledgment from the remote TCP peer."; > } > enum time-wait { > value 11; > description > "Represents waiting for enough time to pass to be > sure the remote TCP peer received the acknowledgment > of its connection termination request, and to avoid > new connections being impacted by delayed segments > from previous connections."; > } > } > description > "The state of this TCP connection."; > } > description > "List of TCP connections with their parameters. The list > is modeled as writeable, but implementations may not > allow creation of new TCP connections by adding entries to > the list. Furthermore, the behavior upon removal is > implementation-specific. Implementations may support > closing or resetting a TCP connection upon an operation > that removes the entry from the list."; > } > </snip> > > This creates feature parity with the TCP MIB regarding state. > > All: Please have a look at this model, which was added to address the IETF > LC feedback, and let us know if anything is missing. > > > > • All TCP flags and respective states. > > > Do you mean the TCP flags SYN, FIN, PSH, ... Does a YANG module all to > > describe > > > packets sent and received? > > > > I can’t see how this can model the TCP flags; all it should be modeling > is the > > states of the connection. The model is for TCP, not TCP packets. > > I am very confused here, too. > > > > • All TCP parameters that would be accessible with a local OS kernel > hook. > > > Doesn't that mean the complete set of state variable the kernel has and > > isn't that implementation dependent? > > > • All windowing parameters including window scaling as well as any > > windowing related optimizations. > > > You mean the receiver window including the window scaling. > > > • All TCP options and optimizations set such as Selective ACK. > > > I guess you mean the set of TCP extensions which have been negotiated. > > > • All TCP slow start congestion control parameters CWIN etc. > > > There are a multiple Congestion Controls, even ones not being > specified by > > the IETF. > > > So this might get very hard to do. Or do you require a specific CC when > > using TCP for BGP? > > > > This is where things get confusing to me; it seems that there is either > a model > > for TCP or a model for TCP implementations. The two should not be > confused > > with each other > > Yep, and a lot of details are very implementation specific and differ a > lot in the long tail of existing TCP implementations. Gyan> Understood. Maybe if we focused on router vendor TCP implementations. Also maybe commonality across compute node TCP implementations > > > In the first discussions regarding draft-scharf-tcpm-yang-tcp, I have > shown some examples for TCP parameters that are implemented relatively > similarly across major TCP stacks and that a more comprehensive TCP YANG > model could possibly include. Gyan> Thank you This includes for instance enabling/disabling ECN, Window Scaling, > Timestamps, etc. Gyan> Perfect But even in that case different stacks differ *a lot* and I am not aware of > a simple way to work around that. Gyan> Understood Details can be found in the IETF proceedings for previous TCPM meetings. Gyan> Ok > > > If there is interest in modeling TCP beyond draft-ietf-tcpm-yang-tcp-07, > the discussion needs to ensure that the model roughly corresponds to > running code. Gyan> Understood > > > Unfortunately, I probably cannot attend this TCPM session because of my > day job, but I obviously follow the mailing list. > > Thanks > > Michael > > > > > > Joe > > > > > > > > Best regards > > > Michael > > >> > > >> Thanks > > >> > > >> Gyan > > >> > > >> ---------- Forwarded message --------- > > >> From: Mishra, Gyan S <gyan.s.mishra@verizon.com> > > >> Date: Mon, Jul 25, 2022 at 11:36 PM > > >> Subject: IETF 114 TCPM WG - NG TCPM Yang Model > > >> To: Hayabusanew <hayabusagsm@gmail.com> > > >> > > >> > > >> -- > > >> > > >> > > >> Gyan Mishra > > >> Network Solutions Architect > > >> Email gyan.s.mishra@verizon.com > > >> M 301 502-1347 > > >> > > >> > > >> <IETF-114 TCPM TCP Yang > > Model.pdf>_______________________________________________ > > >> tcpm mailing list > > >> tcpm@ietf.org > > >> https://www.ietf.org/mailman/listinfo/tcpm > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* *M 301 502-1347*
- [tcpm] Fwd: IETF 114 TCPM WG - NG TCPM Yang Model Gyan Mishra
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model Michael Tuexen
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model Gyan Mishra
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model Susan Hares
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model Gyan Mishra
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model touch@strayalpha.com
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model Gyan Mishra
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model Michael Tuexen
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model Scharf, Michael
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model Gyan Mishra
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model Gyan Mishra
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model touch@strayalpha.com
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model Gyan Mishra
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model touch@strayalpha.com
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model Gyan Mishra
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model Robert Raszuk
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model Gyan Mishra
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model touch@strayalpha.com
- Re: [tcpm] IETF 114 TCPM WG - NG TCPM Yang Model Gyan Mishra