Re: [tcpm] [OPS-DIR] [Last-Call] Opsdir telechat review of draft-ietf-tcpm-yang-tcp-07

[Gyan Mishra <[e-mail]>]

+ TCPM Chairs

Hi Sue

That would be excellent!

Thank you for following and chiming in on this thread!

I think if we could get a 15 minute time slot for an open  discussion or I
could put together a slide deck of use cases that we would like to
translate into the NG TCP Yang model.

I think this would be an excellent first step.

Looks like TCPM meets on Friday 10-12.  LSR is at the same time but I
should be able to flip flop between the two sessions.  Transport has an
open meeting 1:30-2:30pm as well.

Dear TCPM chairs

Is it possible to get a time slot for Friday?

Kind Regards

Gyan

On Sat, Jul 9, 2022 at 6:37 PM Susan Hares <[e-mail]> wrote:

> Gyan, Robert, Michael, Tom, Jeff Haas, Mahesh, and TCPM WG.
>
>
>
> Thank you for hard work to try to get a useful TCP Yang module.  It’s a
> tough module because of the interactions.
>
>
>
> I am glad to help and create the next generation of TCPM Yang module.
>
>
>
> Would it be possible to clearly note when TCPM is discussion this topic at
> IETF meeting schedule?
>
> I think the email threads are clear in the WG.
>
>
>
> Sue
>
>
>
> *From:* OPS-DIR <[e-mail]> *On Behalf Of *Gyan Mishra
> *Sent:* Friday, July 8, 2022 2:05 PM
> *To:* Scharf, Michael <[e-mail]>
> *Cc:* Last Call <[e-mail]>; Robert Raszuk <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: [OPS-DIR] [Last-Call] [tcpm] Opsdir telechat review of
> draft-ietf-tcpm-yang-tcp-07
>
>
>
>
>
>
>
> Hi Michael
>
>
>
> Responses in-line
>
>
>
> On Tue, Jul 5, 2022 at 4:39 AM Scharf, Michael <
> [e-mail]> wrote:
>
> Hi Gyan,
>
>
>
> If something is needed beyond the current scope of
> draft-ietf-tcpm-yang-tcp, interested contributors and in particular also
> owner of running code have to speak up in TCPM.
>
>  Gyan> Understood
>
> Multiple implementations of the TCP MIB (RFC 4022) exist, and thus it is
> reasonable to assume that a similar YANG model as proposed in
>  draft-ietf-tcpm-yang-tcp will also be implemented and not be a theoretical
> exercise only.
>
>     Gyan> Agreed
>
> But TCPM contributors were quite concerned about the lack of success of
> other, more advanced TCP-related MIBs, e.g. the extended statistics in RFC
> 4898.
>
>     Gyan> That would be all the more reason and justification to have a
> complete TCP Yang model that covers not just the TCP MIB which TCPM
> contributors see as lacking such as advanced statistics.  Also these very
> statistics is what myself, Robert and others in Routing Area feel is a MUST
> for tracking telemetry TCP state and windowing etc for any app such as BGP
> using TCP as well as compute node transactional tracking and zero window
> frozen window issues.
>
> As a result, there is no TCPM consensus to work on YANG without a
> crystal-clear use case.
>
>    Gyan> I can provide more detail into the use cases for routing area
> which are concrete real word use cases
>
> TCP-AO is such an example and therefore included in
> draft-ietf-tcpm-yang-tcp - and in this case the configuration is relatively
> similar in different OS, i.e., modeling is doable.
>
> Gyan> Understood
>
> A separate question is whether further use cases would have to be handled
> by draft-ietf-tcpm-yang-tcp or in an new I-D. Any significant change of the
> scope would first have to reach consensus in TCPM.
>
>     Gyan> I think it makes sense to put further use case TCPM to make the
> yang model useful to all.  As it stands today it is not.
>
>
>
> BTW, in my opinion we are here discussing cross-area work. As far as I can
> tell, cross-area work is not a low-hanging fruit in the IETF; at least it
> will require some time. That alone may be one reason to solve further use
> cases separately.
>
>  Gyan> Understood.  I think this discussion is worthwhile setting a a
> meeting to review next steps with this draft and have contributors and all
> interested parties involved
>
> Michael
>
>
>
>
>
> *From:* Gyan Mishra <[e-mail]>
> *Sent:* Monday, July 4, 2022 10:53 PM
> *To:* Scharf, Michael <[e-mail]>
> *Cc:* Last Call <[e-mail]>; Robert Raszuk <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: [Last-Call] [tcpm] Opsdir telechat review of
> draft-ietf-tcpm-yang-tcp-07
>
>
>
>
>
> 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 <
> [e-mail]> 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 <[e-mail]>
> *Sent:* Monday, July 4, 2022 10:11 PM
> *To:* Robert Raszuk <[e-mail]>
> *Cc:* Last Call <[e-mail]>; Scharf, Michael <
> [e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> *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 <[e-mail]> 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 <
> [e-mail]> 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 <[e-mail]>
> *Sent:* Monday, July 4, 2022 9:15 PM
> *To:* Scharf, Michael <[e-mail]>
> *Cc:* [e-mail]; Gyan Mishra <[e-mail]>; Last
> Call <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> *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 <
> [e-mail]> 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:* [e-mail] <[e-mail]>
> *Sent:* Monday, July 4, 2022 4:38 PM
> *To:* Gyan Mishra <[e-mail]>
> *Cc:* Last Call <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail]
> *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 <[e-mail]> 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 [e-mail] <[e-mail]>
> wrote:
>
> FWIW:
>
> > On Jul 3, 2022, at 9:04 PM, Gyan Mishra via Datatracker <
> [e-mail]> 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 **[e-mail]* <[e-mail]>
>
> *M 301 502-1347*
>
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>
>
>
> --
> last-call mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*