Hi Gyan,
Inline [MS]…
From: Gyan Mishra <hayabusagsm@xxxxxxxxx>
Sent: Friday, July 8, 2022 8: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: [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.
[MS] I suggest to precisely describe these use cases and what would be required in a corresponding YANG model. Details about existing solutions (e.g., in router operating systems) may also help.
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
[MS] Often, a presentation in a TCPM meeting is a good first step to trigger a technical discussion. Also, keep in mind that the protocol stacks in router operating systems may have characteristics different to client and server operating systems. So, a careful technical analysis may be needed.
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.
[MS] Nothing prevents TCPM from extending the model defined in draft-ietf-tcpm-yang-tcp in follow-up steps (e.g., by augmentation). Unless I miss something, I am not aware of anything inside draft-ietf-tcpm-yang-tcp that *prevents* further modeling, e.g., to address other use cases. Thus, at least to me, it would be a quite reasonable strategy to address further use cases in a separate document.
Gyan> Understood. So I agree now that we have a path forward. We can proceed to sign off OPSDIR review for draft-ietf-tcpm-yang-tcp ready for publication. We can start on the follow up steps for augmentation in a new yang model that addresses further use cases. We can kick this discussion off with presentation in TCPM on routing area use cases.
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
[MS] It clearly makes sense for interested parties to speak up and engage in TCPM. Yet, I’d like to emphasize once again that addressing further use cases may not necessarily require changing the (relatively well-defined) scope of draft-ietf-tcpm-yang-tcp. IMHO, not all problems need to be solved in a single document.
Michael
Michael
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
