Re: [tcpm] [Last-Call] Opsdir telechat review of draft-ietf-tcpm-yang-tcp-07
Gyan Mishra <hayabusagsm@gmail.com> Mon, 04 July 2022 21:02 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 287EDC14F749; Mon, 4 Jul 2022 14:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.594
X-Spam-Level:
X-Spam-Status: No, score=-1.594 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, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=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 Mx_CxM7EErPq; Mon, 4 Jul 2022 14:02:16 -0700 (PDT)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 6CD95C14F72C; Mon, 4 Jul 2022 14:02:16 -0700 (PDT)
Received: by mail-pf1-x435.google.com with SMTP id f12so60354pfk.10; Mon, 04 Jul 2022 14:02:16 -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=rS+9HYmlspxpQbYLACiQDTQO3fVY3NaMCjFkdUideJg=; b=Qtz+nmtHTf337AX+5WLeRBmrW66GwWfdgfqhtJxfOXBYowY+YznxU/NVtqrDhr2/pO zDuOjEmAAlqaAy/Vp16nj7TOr32GF5EpQLosXTizE8zOu668hqM/0zn2norv+8JEtutL MNZh0Q4vx8/lHGNstHkmghjp7Q/0+juepGCBr2UAfudYwlbwPZpx7b6rn2cgCn25Z7Yk i2iuca7LMY1k2QDxBOVpr36RAkFph/nVB+HTkq2ZbbVpWXd3k80LcOaSoTj6UhJ1waqD Wu0Ta8cuDaPliUCyjTLCIjIeWJRwFDqerqFxsn/rRMEHz1yPS5y2eWAf3H/KjgWJdHBr 7sVA==
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=rS+9HYmlspxpQbYLACiQDTQO3fVY3NaMCjFkdUideJg=; b=yZNNo/FZZe878SnOXfRGQmZuYfyadYZ0l+qC3Rs+RAZ1s6y60RzxVKesvtVR1DQj/j C1rmSB5TqPmHXtuSXyTQyyD+a1ChvCSZdZVgZoJ/KEyRNWqK91BtkWkZN/zhKdZOht7b F4gbOwLmpwLgnFLaUuiOWvtzsTARU1V+MZTAJEd1CyuglCi7Rs/TkGhcboMb+vaxdMvn Cc09gStkiqfdhycb9rtxVR+SkdKTDjpD2U4OfRBl6G1YMXZrqRbjGcqOyyZYYEkKxbJM bc3oRpdC4K2GDxPjT0eT3f8M1hba8hLDa4njslJ7plIIwC8WtFMIEL1KacjoJ0GcK98o FtGg==
X-Gm-Message-State: AJIora8DOjPhkatr53B+M30vFzw+ZJcyWVqga46172kLaY6ACgsU0Pqx 7wqPdWCk31i6KZU9RM5Yhrq+JqYzZ+BpXRqiYR8=
X-Google-Smtp-Source: AGRyM1uuk3BRhb7DioAUcTCWBT9JqhNc6qm3i2XvhFw9mBiRY9ajlZeob7fs5joqqDY3e3qGEcLxB7Ro56BggS6/jb4=
X-Received: by 2002:a63:1843:0:b0:412:6ea5:ac5c with SMTP id 3-20020a631843000000b004126ea5ac5cmr723829pgy.366.1656968535263; Mon, 04 Jul 2022 14:02:15 -0700 (PDT)
MIME-Version: 1.0
References: <165690747653.9313.6940379164951428048@ietfa.amsl.com> <DF6CF2BD-8418-4386-BB78-6E011A523FBA@strayalpha.com> <CABNhwV1SN+Ei_TScwUsg1scKhAAoxixfFTtXXghLXEPspU6gZA@mail.gmail.com> <893612ED-91B7-4492-8000-EF2D54AC49BC@strayalpha.com> <4688b79370e94df6b8af107a97be0a7f@hs-esslingen.de> <CAOj+MMGxUxqFko1R5yVkpc6Ujw6SJcOjB209YNKuGJo+MOZfvA@mail.gmail.com> <1c1e32001ce040268764783a5aa1e41f@hs-esslingen.de> <CAOj+MMFaFHPFSXseaAjGWwmDLkph96weufVKYmP-qYxrR+uyDw@mail.gmail.com> <CABNhwV2XJd=qF=vFr_f6ciEaNw-7UkocpYaW6dtAsTXk2tm9hA@mail.gmail.com> <c6c48ff6fa05454ebeb1f255fb0d1c1e@hs-esslingen.de>
In-Reply-To: <c6c48ff6fa05454ebeb1f255fb0d1c1e@hs-esslingen.de>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Mon, 04 Jul 2022 16:53:08 -0400
Message-ID: <CABNhwV3tWAstmBpn7Jgf16D4uQfxopjAYLJjUNKJVmAR6tsXGQ@mail.gmail.com>
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
Cc: Last Call <last-call@ietf.org>, Robert Raszuk <robert@raszuk.net>, "draft-ietf-tcpm-yang-tcp.all@ietf.org" <draft-ietf-tcpm-yang-tcp.all@ietf.org>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>, "touch@strayalpha.com" <touch@strayalpha.com>
Content-Type: multipart/alternative; boundary="000000000000f2d04905e3010cc0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/N2oB91nN9i5wNB5FRyhJclI0fnA>
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 <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: Mon, 04 Jul 2022 21:02:21 -0000
Hi Michael Understood. I understand the goal of the draft is to make a like for like equivalent of TCP MIB. To me that does seem like status quo bare minimum requirements scope of work. Responses in-line. On Mon, Jul 4, 2022 at 4:27 PM Scharf, Michael < Michael.Scharf@hs-esslingen.de> wrote: > Hi Gyan, > > > > These use cases may be very reasonable and important, but TCP is complex > and there are a lot of subtle issues once one looks behind the scenes. > > Gyan> Understood. In these particular use cases we do have to look in > detail behind the scenes. > > Before actually writing corresponding YANG models, the relevant players > would have to speak up, e.g., in TCPM, and come up with specific proposals. > As far as I can tell, this has not happened so far. > > Gyan> I think from the OPSDIR review POV as it relates to Routing area > operations we would like to have some concrete follow up from TCPM on this > topic. I understand the goal of this yang model however if we are able to > expand the goal beyond the TCP MIB to incorporate some requirements would > that be possible? We would have to get the relevant players in TCPM to > speak as you stated or would the authors of this draft be willing to take > on the new work? > > I have to emphasize once again that draft-ietf-tcpm-yang-tcp does not > prevent further YANG models. The document actually states that pretty > explicitly. > > Gyan> Understood. There is a chance do to priorities that the future > Yang model may not come to fruition. Also I think if we expand the scope > of this draft to encompass what myself and Robert are asking, I think it > would make the draft much much more useful to all. > > Michael > > > > > > > > *From:* Gyan Mishra <hayabusagsm@gmail.com> > *Sent:* Monday, July 4, 2022 10:11 PM > *To:* Robert Raszuk <robert@raszuk.net> > *Cc:* Last Call <last-call@ietf.org>; Scharf, Michael < > Michael.Scharf@hs-esslingen.de>; draft-ietf-tcpm-yang-tcp.all@ietf.org; > ops-dir@ietf.org; tcpm@ietf.org; touch@strayalpha.com > *Subject:* Re: [Last-Call] [tcpm] Opsdir telechat review of > draft-ietf-tcpm-yang-tcp-07 > > > > > > Hi Michael > > > > A possible good example of a use case by router vendors of use of the > detailed visibility into the TCP socket in the Yang model is an issue that > has caused outages across the internet related to BGP TCP O window where > the receive window was stuck state and could not write to the receive > buffer and so the BGP session remained in UP state resulting in a major > internet outage. > > > > Operators are now moving towards BGP based MSDC for massive scalability > and no IGP (OSPF or ISIS) for scalability and stability. As a result of > the motivation and change operationally towards BGP, TCP and all the socket > details is now that much more important to operators as well as now an > significant interest to most vendors. > > > > As well with micro services and Kubernetes with the data center fabric > being moved to compute nodes running hundreds of BGP sessions. > > > > That is the POV we are coming from related to the inner workings and > details of TCP Yang model now applies to router and switch vendors but as > well also compute nodes. > > > > > > Regards > > > > Gyan > > > > On Mon, Jul 4, 2022 at 3:52 PM Robert Raszuk <robert@raszuk.net> wrote: > > 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’t 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 stated > more than 10 years ago “new applications SHOULD NOT employ the TCP urgent > mechanism”). > > > > 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 model > 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 “elementary” parameters and implementation-specific 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 that > this is feasible and that relevant stacks would indeed implement that YANG > model. > > > > Michael > > > > > > > > *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>; 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 the > 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, > > > > „separate protocol specific YANG model” 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 protocol. > 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 <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-tcp-07 > > > > > > — > > Dr. Joe Touch, temporal epistemologist > > www.strayalpha.com > > > > On Jul 3, 2022, at 10:16 PM, Gyan Mishra <hayabusagsm@gmail.com> 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, so > the plan is that a separate protocol specific yang model would be a follow > 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 <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 FSM > 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’ll 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, > not states (i.e., the FSM is a Mealy machine, not a Moore machine). There > is no “flags set for each state”. > > > > http://tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF-2.htm > > That page has errors and is not consistent with RFC793 (or it’s pending > -bis update). E.g., FIN stands for “finis” (latin for “end”), not “finish”. > > > 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 > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email **gyan.s.mishra@verizon.com* <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 > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>* > > *M 301 502-1347* > > > -- <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] Opsdir telechat review of draft-ietf-tcpm-… Gyan Mishra via Datatracker
- Re: [tcpm] Opsdir telechat review of draft-ietf-t… touch@strayalpha.com
- Re: [tcpm] Opsdir telechat review of draft-ietf-t… Gyan Mishra
- Re: [tcpm] Opsdir telechat review of draft-ietf-t… touch@strayalpha.com
- Re: [tcpm] Opsdir telechat review of draft-ietf-t… Gyan Mishra
- Re: [tcpm] Opsdir telechat review of draft-ietf-t… Scharf, Michael
- Re: [tcpm] [Last-Call] Opsdir telechat review of … Robert Raszuk
- Re: [tcpm] [Last-Call] Opsdir telechat review of … touch@strayalpha.com
- Re: [tcpm] [Last-Call] Opsdir telechat review of … Robert Raszuk
- Re: [tcpm] [Last-Call] Opsdir telechat review of … Scharf, Michael
- Re: [tcpm] [Last-Call] Opsdir telechat review of … Scharf, Michael
- Re: [tcpm] [Last-Call] Opsdir telechat review of … Robert Raszuk
- Re: [tcpm] [Last-Call] Opsdir telechat review of … touch@strayalpha.com
- Re: [tcpm] [Last-Call] Opsdir telechat review of … Scharf, Michael
- Re: [tcpm] [Last-Call] Opsdir telechat review of … Gyan Mishra
- Re: [tcpm] [Last-Call] Opsdir telechat review of … Scharf, Michael
- Re: [tcpm] [Last-Call] Opsdir telechat review of … Robert Raszuk
- Re: [tcpm] [Last-Call] Opsdir telechat review of … Gyan Mishra
- Re: [tcpm] [Last-Call] Opsdir telechat review of … touch@strayalpha.com
- Re: [tcpm] [Last-Call] Opsdir telechat review of … Robert Raszuk
- Re: [tcpm] [Last-Call] Opsdir telechat review of … Scharf, Michael
- Re: [tcpm] [Last-Call] Opsdir telechat review of … Gyan Mishra
- Re: [tcpm] [Last-Call] Opsdir telechat review of … Scharf, Michael
- Re: [tcpm] [OPS-DIR] [Last-Call] Opsdir telechat … Susan Hares
- Re: [tcpm] [Last-Call] Opsdir telechat review of … Gyan Mishra
- Re: [tcpm] [OPS-DIR] [Last-Call] Opsdir telechat … Gyan Mishra
- Re: [tcpm] [OPS-DIR] [Last-Call] Opsdir telechat … tuexen
- Re: [tcpm] [OPS-DIR] [Last-Call] Opsdir telechat … Gyan Mishra
- Re: [tcpm] [OPS-DIR] [Last-Call] Opsdir telechat … Gyan Mishra