From nobody Mon Jul 4 12:53:04 2022 Return-Path: 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 A1D0DC15791D for ; Mon, 4 Jul 2022 12:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 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, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, 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, 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 (2048-bit key) header.d=raszuk.net 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 ocRa2fBjDaJW for ; Mon, 4 Jul 2022 12:52:58 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 4BE3EC157908 for ; Mon, 4 Jul 2022 12:52:58 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id j21so17313921lfe.1 for ; Mon, 04 Jul 2022 12:52:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VvNudMeNtheHCFcws0R9N1y0EiZl1u7CHkRZevdYFDM=; b=Y4DQIq5GPk/lIwDvz+BfktmJedmVkpS1K4NT34Mr332W+PFLqqIhtgc68yK50dsumS iNaY75DBhuP28Sfkzs9+LkJtakkHK7YEC9933TSBx4eZyFPFidPmuRDRNGzuq6iGtbbn f1PsiApjDsmZPd6p9WITbJnbVLPnu2WVfAPSqCEVKmSYXyknfyFzIDovS72PTP+4iWbh Pivl/S6T3r3f4txhsVUX2+dCVfXOfHbIxFgJxByIrqQ+L0r0c+igYpQxAF+kK4Pa76CO NfwC0/6aMyoJGdP89Fy+2Ma0VWqSKIdtROuFgaxJ5OZzAQyXF7pyVQyrft2DXq1Fkh0g 81tg== 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=VvNudMeNtheHCFcws0R9N1y0EiZl1u7CHkRZevdYFDM=; b=s0PTm8YQAnA/RHrfCaUZ0YC4jKzP6UvO3Lbb3EmfGzwSXksHTT2XRbp5wbqoR7c4J7 ccy67ao6n2ZbsGJNvPEAQR9p7Y9zGEgI28+FGJS3ThBDkjRyhM4Si450QSoRZpe+su8f xWuNT3W9mRhX2v35Og/Q/unW1Cuf0noegKrDQN/tk3sCmuze+3gZHqYrRWfInMpKWUAP U2IqZjGBrmNCrum59VCBe9xXHZ+P4WBgXLwJbCBKbPoXWk6PyvG3j/L6O6WfVhXUWtYp uOOhKKHQsp9Db27FrkWrUP4/p3UYlPMYwMhhS3bCn8W+/s+YkjTShf38jDOi52K0wjfW 3TsQ== X-Gm-Message-State: AJIora8SMfmnUMpEyO8mdS1BKOgl3f3GuWGSHGmLConCt47etTfXYPXK SCrfIBFcOnbag7XTCMuoShayKHLH5o1zj2iz7Q18Sg== X-Google-Smtp-Source: AGRyM1sX2cIcJpg+e08BmAZCYl4eto7pF0Rp2zhPx30u69d83TBK2lt1lnADI/RvM32NtVcFq+iedxwmW5BaAPb8DB8= X-Received: by 2002:ac2:4e4e:0:b0:47f:b3c0:2f3d with SMTP id f14-20020ac24e4e000000b0047fb3c02f3dmr19301445lfr.15.1656964376140; Mon, 04 Jul 2022 12:52:56 -0700 (PDT) MIME-Version: 1.0 References: <165690747653.9313.6940379164951428048@ietfa.amsl.com> <893612ED-91B7-4492-8000-EF2D54AC49BC@strayalpha.com> <4688b79370e94df6b8af107a97be0a7f@hs-esslingen.de> <1c1e32001ce040268764783a5aa1e41f@hs-esslingen.de> In-Reply-To: <1c1e32001ce040268764783a5aa1e41f@hs-esslingen.de> From: Robert Raszuk Date: Mon, 4 Jul 2022 21:52:54 +0200 Message-ID: To: "Scharf, Michael" Cc: "touch@strayalpha.com" , Gyan Mishra , Last Call , "draft-ietf-tcpm-yang-tcp.all@ietf.org" , "ops-dir@ietf.org" , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000bb12c05e3001569" Archived-At: Subject: Re: [tcpm] [Last-Call] Opsdir telechat review of draft-ietf-tcpm-yang-tcp-07 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2022 19:53:02 -0000 --0000000000000bb12c05e3001569 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Michael, Actually I used the URG flag example as this is used by one of the key features in one of the major vendor's OS. Ability to see this flag to be reported is IMO useful in this very application. > on-path middleboxes. That is not my concern at all. My focus is to use YANG on the endpoints to avoid need to recreate TCP state via TAP captures. Like some of the good analyzers allow you to do. > many OS kernels don=E2=80=99t use YANG at all. True - but is this the right argument ? Those will not benefit irrespective of how small or big YANG model will be shipped. > One could write a lot in a YANG model, but who would actually implement that? I would count on network vendors to implement it. And that is my personal area of interest. Otherwise I would not care to comment :) Thx, R. On Mon, Jul 4, 2022 at 9:39 PM Scharf, Michael < Michael.Scharf@hs-esslingen.de> wrote: > Hi Robert, > > > > the TCP Urgent Flag is discussed in RFC 6093 and probably not a good > example for a TCP-feature relevant for modern applications (RFC 6093 stat= ed > more than 10 years ago =E2=80=9Cnew applications SHOULD NOT employ the TC= P urgent > mechanism=E2=80=9D). > > > > A modern TCP implementation actually has several windows and running TCP > code either measures them in bytes or in segments. That results in quite > some differences. So, even for TCP windows there is no simple way to mode= l > the actual behavior of widely deployed running code. > > > > And the algorithms of a modern TCP stack can imply more than 100 > parameters. Due to the complexity it is basically impossible to draw the > line between =E2=80=9Celementary=E2=80=9D parameters and implementation-s= pecific ones. > > > > All that was discussed in TCPM, and the WG consensus was not to boil the > ocean. The very narrow scope of draft-ietf-tcpm-yang-tcp is a result of > that discussion in TCPM. I have tried my best to explain the rationale > inside the document. > > > > It may be possible to publish a more comprehensive TCP YANG model as a > follow-up specification. But the first step would be to convince TCPM tha= t > this is feasible and that relevant stacks would indeed implement that YAN= G > model. > > > > Michael > > > > > > > > *From:* Robert Raszuk > *Sent:* Monday, July 4, 2022 9:15 PM > *To:* Scharf, Michael > *Cc:* touch@strayalpha.com; Gyan Mishra ; Last > Call ; draft-ietf-tcpm-yang-tcp.all@ietf.org; > ops-dir@ietf.org; tcpm@ietf.org > *Subject:* Re: [Last-Call] [tcpm] Opsdir telechat review of > draft-ietf-tcpm-yang-tcp-07 > > > > Hi, > > > > > Any application can decide to configure TCP parameters as far as > possible in the given operation > > > system, e.g., via the sockets API. That is orthogonal to the internals > of the TCP implementation and the TCP protocol. > > > > While clients running on top of TCP can configure its parameters I would > at least expect to be able to report such values (local and remote) when > using the TCP YANG model. For example I can not find the Urgent Flag in t= he > current YANG model. Same for elementary window size of any given > connection, same for connection duration, . > > > > Inability to do so to me sounds like a half baked model. IMHO it is not > ready to be even declared as MVP. > > > > Many thx, > > Robert > > > > > > On Mon, Jul 4, 2022 at 6:06 PM Scharf, Michael < > Michael.Scharf@hs-esslingen.de> wrote: > > Joe, all, > > > > =E2=80=9Eseparate protocol specific YANG model=E2=80=9D could be the YANG= model for BGP, > or for any other TCP-based application. > > > > Any application can decide to configure TCP parameters as far as possible > in the given operation system, e.g., via the sockets API. That is > orthogonal to the internals of the TCP implementation and the TCP protoco= l. > The app configuration can be done in YANG or by other means. For the TCP > stack, that does not matter. > > > > As far as I understand Gyan, the concerns regarding > draft-ietf-tcpm-yang-tcp are sorted out already. > > > > @all: Please speak up if specific changes are needed in > draft-ietf-tcpm-yang-tcp. The authors will have to focus on the IESG > feedback. > > > > Thanks > > > > Michael > > > > > > > > *From:* touch@strayalpha.com > *Sent:* Monday, July 4, 2022 4:38 PM > *To:* Gyan Mishra > *Cc:* Last Call ; > draft-ietf-tcpm-yang-tcp.all@ietf.org; ops-dir@ietf.org; tcpm@ietf.org > *Subject:* Re: [tcpm] Opsdir telechat review of > draft-ietf-tcpm-yang-tcp-07 > > > > > > =E2=80=94 > > Dr. Joe Touch, temporal epistemologist > > www.strayalpha.com > > > > On Jul 3, 2022, at 10:16 PM, Gyan Mishra wrote: > > > > Hi Joe, authors et all > > > > I reviewed the feedback from my earlier review in March and as this model > is geared towards BGP primary. > > > > To address all of my concerns would be complicated for this Yang model, s= o > the plan is that a separate protocol specific yang model would be a follo= w > on to address all of my concerns. > > > > First, there should NEVER be two different YANG models for BGP routers vs= . > other routers or hosts. TCP is TCP is TCP. If that is an assumption for > moving this document forward, TCPM should have a longer discussion about > that point specifically. > > > > Second, my observations about your requests below stand, regardless of > when/where current or future authors might be considering them. > > > > Joe > > > > > > On Mon, Jul 4, 2022 at 12:44 AM touch@strayalpha.com > wrote: > > FWIW: > > > On Jul 3, 2022, at 9:04 PM, Gyan Mishra via Datatracker < > noreply@ietf.org> wrote: > > > > Reviewer: Gyan Mishra > > Review result: Not Ready > > > > This draft provides the Yang data mode for TCP. > > > > The draft is well written and is almost ready publication. I verified > the FSM > > state machine and all states are listed. > > > > Minor issues: > > None > > > > Major issues: > > None > > > > Nits: > > I reviewed the TCP Yang data model and has a question related to the FS= M > state > > machine. > > > > Would it be possible to specify the TCP Header flags SYN, FIN, ACK, RST > of BFD > > FSM finite state machine Events and Transition. I think this would be > very > > helpful for the TCP Yang model FSM state machine. For each state you > could > > specify the flags set. > > These issues appear to have been raised by you in March during last call > review. Some have been addressed by others before; I=E2=80=99ll add my in= put. > > The YANG model represents information about the current TCP connection. I= t > is not (and should not be confused with) a specification of the protocol. > > Further, flags are associated with messages that cause state transitions, > not states (i.e., the FSM is a Mealy machine, not a Moore machine). There > is no =E2=80=9Cflags set for each state=E2=80=9D. > > > > http://tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMa= chineF-2.htm > > That page has errors and is not consistent with RFC793 (or it=E2=80=99s p= ending > -bis update). E.g., FIN stands for =E2=80=9Cfinis=E2=80=9D (latin for =E2= =80=9Cend=E2=80=9D), not =E2=80=9Cfinish=E2=80=9D. > > > I think the TCP TCB (TCP Control Block) is missing in the Yang model. > This is > > important for troubleshooting TCP connection state. > > RFC793 (and -bis) indicate that the STATUS command, which might return > similar information, is optional. > > If there is connection information returned, I do not think it should be > the TCB; that is an implementation-dependent parameter, not a universal > property of TCP connections. As others have stated in previous responses = to > you review, the common subset of the TCB is already contained. > > I.e., I think the YANG model represents TCP information. It is not - and > should not be confused with - a troubleshooting tool. > > Joe > > -- > > > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email **gyan.s.mishra@verizon.com* > > *M 301 502-1347* > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call > > --0000000000000bb12c05e3001569 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Michael,

Actually I used the U= RG flag example as this is used by one of the key features in one of the ma= jor vendor's OS. Ability to see this flag to be reported is IMO useful = in this very application.

> on-path middleboxes.

<= span lang=3D"EN-US">

That is not my concern at all. My focus is to use YANG on the endpoints= to avoid need to recreate TCP state via TAP captures. Like some of the goo= d analyzers allow you to do.=C2=A0

=C2=A0=C2=A0

> many OS kernels don=E2=80=99t use YANG at all.

=


True - but is this the right argument ? Those will not benefit=C2=A0= irrespective of how small or big YANG model will be shipped.=C2=A0


> One could write a lot in a YANG model, but who would actually implem= ent that?


I wo= uld count on network vendors to implement=C2=A0it. And that is my personal = area of interest. Otherwise I would not care to comment :)=C2=A0

<= div>
Thx,
R.

On Mon, Jul 4, 2022 at 9:39 PM Sch= arf, Michael <Michael.= Scharf@hs-esslingen.de> wrote:

Hi Robert,=

=C2=A0

the TCP Urgent Flag is discusse= d in RFC 6093 and probably not a good example for a TCP-feature relevant fo= r modern applications (RFC 6093 stated more than 10 years ago =E2=80=9Cnew = applications SHOULD NOT employ the TCP urgent mechanism=E2=80=9D).=

=C2=A0

A modern TCP implementation act= ually has several windows and running TCP code either measures them in byte= s or in segments. That results in quite some differences. So, even for TCP = windows there is no simple way to model the actual behavior of widely deployed run= ning code.

=C2=A0

And the algorithms of a modern = TCP stack can imply more than 100 parameters. Due to the complexity it is b= asically impossible to draw the line between =E2=80=9Celementary=E2=80=9D p= arameters and implementation-specific ones.

=C2=A0

All that was discussed in TCPM,= and the WG consensus was not to boil the ocean. The very narrow scope of d= raft-ietf-tcpm-yang-tcp is a result of that discussion in TCPM. I have trie= d my best to explain the rationale inside the document.=

=C2=A0

It may be possible to publish a= more comprehensive TCP YANG model as a follow-up specification. But the fi= rst step would be to convince TCPM that this is feasible and that relevant = stacks would indeed implement that YANG model.

=C2=A0

Michael

=C2=A0

=C2=A0

=C2=A0

From: Robert Raszuk <robert@raszuk.net>
Sent: Monday, July 4, 2022 9:15 PM
To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>
Cc: touch@= strayalpha.com; Gyan Mishra <hayabusagsm@gmail.com>; Last Call <last-call@ietf.org>; <= a href=3D"mailto:draft-ietf-tcpm-yang-tcp.all@ietf.org" target=3D"_blank">d= raft-ietf-tcpm-yang-tcp.all@ietf.org; ops-dir@ietf.org; tcpm@ietf.org
Subject: Re: [Last-Call] [tcpm] Opsdir telechat review of draft-ietf= -tcpm-yang-tcp-07

=C2=A0

Hi,

=C2=A0

> Any application can decide= to configure TCP parameters as far as possible in the given operation=C2= =A0

> system, e.g., via the sock= ets API. That is orthogonal to the internals of the TCP implementation and = the TCP protocol.

=C2=A0

While clients running on top of= TCP can configure its parameters I would at least expect to be able to rep= ort such values (local and remote) when using the TCP YANG model. For examp= le=C2=A0I can not find the Urgent Flag in the current YANG model. Same for elementary window size of any given conne= ction, same for connection duration, .=C2=A0

=C2=A0

Inability to do so to me sounds= like a half baked model. IMHO it is not ready to be even declared as MVP.= =C2=A0

=C2=A0

Many thx,<= /p>

Robert

=C2=A0

=C2=A0

On Mon, Jul 4, 2022 at 6:06 PM = Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:

Joe, all,<= /p>

=C2=A0

=E2=80=9Eseparate protocol spec= ific YANG model=E2=80=9D could be the YANG model for BGP, or for any other = TCP-based application.

=C2=A0

Any application can decide to c= onfigure TCP parameters as far as possible in the given operation system, e= .g., via the sockets API. That is orthogonal to the internals of the TCP implementation and the TCP protocol. The app configur= ation can be done in YANG or by other means. For the TCP stack, that does n= ot matter.

=C2=A0

As far as I understand Gyan, th= e concerns regarding draft-ietf-tcpm-yang-tcp are sorted out already.

=C2=A0

@all: Please speak up if specif= ic changes are needed in draft-ietf-tcpm-yang-tcp. The authors will have to= focus on the IESG feedback.

=C2=A0

Thanks

=C2=A0

Michael

=C2=A0

=C2=A0

=C2=A0

From: touch@strayalpha.com <= touch@strayalpha.com>
Sent: Monday, July 4, 2022 4:38 PM
To: Gyan Mishra <hayabusagsm@gmail.com>
Cc: Last Call <last-call@ietf.org>; draft-ietf-tcpm-yang-tcp.all@ietf.org; ops-dir@ietf.org; tcpm@ietf.org
Subject: Re: [tcpm] Opsdir telechat review of draft-ietf-tcpm-yang-t= cp-07

=C2=A0

=C2=A0

=E2=80=94=

Dr. Joe T= ouch, temporal epistemologist

=C2=A0

On Jul 3, 2022, at 10:16 PM, Gy= an Mishra <hayabusagsm@gmail.com> wrote:

=C2=A0

Hi Joe, authors =C2=A0et all=C2= =A0

=C2=A0

I reviewed the feedback from my= earlier review in March and as this model is geared towards BGP primary.= =C2=A0

=C2=A0

To address all of my concerns w= ould be complicated for this Yang model, so the plan is that a separate pro= tocol specific yang model would be a follow on to address all of my concerns.

=C2=A0

First, there should NEVER be tw= o different YANG models for BGP routers vs. other routers or hosts. TCP is = TCP is TCP. If that is an assumption for moving this document forward, TCPM should have a longer discussion about that point sp= ecifically.

=C2=A0

Second, my observations about y= our requests below stand, regardless of when/where current or future author= s might be considering them.

=C2=A0

Joe

=C2=A0

=C2=A0

On Mon, Jul 4, 2022 at 12:44 AM touch@strayalpha.com <= touch@strayalpha.com> wrote:

FW= IW:

> On Jul 3, 2022, at 9:04 PM, Gyan Mishra via Datatracker <nor= eply@ietf.org> wrote:
>
> Reviewer: Gyan Mishra
> Review result: Not Ready
>
> This draft provides the Yang data mode for TCP.
>
> The draft is well written and is almost ready publication.=C2=A0 I ver= ified the FSM
> state machine and all states are listed.
>
> Minor issues:
> None
>
> Major issues:
> None
>
> Nits:
> I reviewed the TCP Yang data model and has a question related to the F= SM state
> machine.
>
> Would it be possible to specify the TCP Header flags SYN, FIN, ACK, RS= T of BFD
> FSM finite state machine Events and Transition.=C2=A0 I think this wou= ld be very
> helpful for the TCP Yang model FSM state machine.=C2=A0 For each state= you could
> specify the flags set.

These issues appear to have been raised by you in March during last call re= view. Some have been addressed by others before; I=E2=80=99ll add my input.=

The YANG model represents information about the current TCP connection. It = is not (and should not be confused with) a specification of the protocol.
Further, flags are associated with messages that cause state transitions, n= ot states (i.e., the FSM is a Mealy machine, not a Moore machine). There is= no =E2=80=9Cflags set for each state=E2=80=9D.

> h= ttp://tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachi= neF-2.htm

That page has errors and is not consistent with RFC793 (or it=E2=80=99s pen= ding -bis update). E.g., FIN stands for =E2=80=9Cfinis=E2=80=9D (latin for = =E2=80=9Cend=E2=80=9D), not =E2=80=9Cfinish=E2=80=9D.

> I think the TCP TCB (TCP Control Block) is missing in the Yang model. = This is
> important for troubleshooting TCP connection state.

RFC793 (and -bis) indicate that the STATUS command, which might return simi= lar information, is optional.

If there is connection information returned, I do not think it should be th= e TCB; that is an implementation-dependent parameter, not a universal prope= rty of TCP connections. As others have stated in previous responses to you = review, the common subset of the TCB is already contained.

I.e., I think the YANG model represents TCP information. It is not - and sh= ould not be confused with - a troubleshooting tool.

Joe

--

Gyan Mishra=

Network Solutions Architect=C2=A0

M 301 502-1347

=C2=A0

_______________________________= ________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm=

=C2=A0

--
last-call mailing list
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last= -call

--0000000000000bb12c05e3001569--