> On 10. Jul 2022, at 02:00, Gyan Mishra <hayabusagsm@xxxxxxxxx> 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 <shares@xxxxxxxx> 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 <ops-dir-bounces@xxxxxxxx> *On Behalf Of *Gyan Mishra >> *Sent:* Friday, July 8, 2022 2:05 PM >> *To:* Scharf, Michael <Michael.Scharf@xxxxxxxxxxxxxxx> >> *Cc:* Last Call <last-call@xxxxxxxx>; Robert Raszuk <robert@xxxxxxxxxx>; >> draft-ietf-tcpm-yang-tcp.all@xxxxxxxx; ops-dir@xxxxxxxx; tcpm@xxxxxxxx; >> touch@xxxxxxxxxxxxxx >> *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 < >> Michael.Scharf@xxxxxxxxxxxxxxx> 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 <hayabusagsm@xxxxxxxxx> >> *Sent:* Monday, July 4, 2022 10:53 PM >> *To:* Scharf, Michael <Michael.Scharf@xxxxxxxxxxxxxxx> >> *Cc:* Last Call <last-call@xxxxxxxx>; Robert Raszuk <robert@xxxxxxxxxx>; >> draft-ietf-tcpm-yang-tcp.all@xxxxxxxx; ops-dir@xxxxxxxx; tcpm@xxxxxxxx; >> touch@xxxxxxxxxxxxxx >> *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 < >> Michael.Scharf@xxxxxxxxxxxxxxx> 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@xxxxxxxxx> >> *Sent:* Monday, July 4, 2022 10:11 PM >> *To:* Robert Raszuk <robert@xxxxxxxxxx> >> *Cc:* Last Call <last-call@xxxxxxxx>; Scharf, Michael < >> Michael.Scharf@xxxxxxxxxxxxxxx>; draft-ietf-tcpm-yang-tcp.all@xxxxxxxx; >> ops-dir@xxxxxxxx; tcpm@xxxxxxxx; touch@xxxxxxxxxxxxxx >> *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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxx> >> *Sent:* Monday, July 4, 2022 9:15 PM >> *To:* Scharf, Michael <Michael.Scharf@xxxxxxxxxxxxxxx> >> *Cc:* touch@xxxxxxxxxxxxxx; Gyan Mishra <hayabusagsm@xxxxxxxxx>; Last >> Call <last-call@xxxxxxxx>; draft-ietf-tcpm-yang-tcp.all@xxxxxxxx; >> ops-dir@xxxxxxxx; tcpm@xxxxxxxx >> *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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx <touch@xxxxxxxxxxxxxx> >> *Sent:* Monday, July 4, 2022 4:38 PM >> *To:* Gyan Mishra <hayabusagsm@xxxxxxxxx> >> *Cc:* Last Call <last-call@xxxxxxxx>; >> draft-ietf-tcpm-yang-tcp.all@xxxxxxxx; ops-dir@xxxxxxxx; tcpm@xxxxxxxx >> *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@xxxxxxxxx> 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
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
