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

[Gyan Mishra <[e-mail]>]

Hi Michael

Yes I will be on site.

Thanks

Gyan

On Sun, Jul 10, 2022 at 5:47 AM <[e-mail]> wrote:

> > On 10. Jul 2022, at 02:00, Gyan Mishra <[e-mail]> wrote:
> >
> > + 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?
> Hi Gyan,
>
> I think that should work. Some slides indicating what you want in
> addition to what is in draft-ietf-tcpm-yang-tcp-07 might be a good
> starting point for discussion. When initially discussing the
> the adoption of the WG item, the WG was very clear on keeping it
> as small as possible. So having this input is important.
>
> I think you will be onsite, right?
>
> Best regards
> Michael
> >
> > 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
>
> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*