(Changed the subject to differentiate from all the other “slot requests”)
+1 to what Robert has said. We already have multiple ways to provide information to any entity that is interested – adding yet another transport doesn’t really help. Just burdens implementations with even more transports to support. What we need is better usage of the information already available. Les From: rtgwg <rtgwg-boun...@ietf.org> On Behalf Of Robert Raszuk Sent: Thursday, March 9, 2023 1:10 AM To: tanzhen (A) <tanzh...@huawei.com> Cc: rtgwg@ietf.org Subject: Re: Slot Request for RTGWG IETF 116 Hi, > O&M personal could actively request more information of other devices But this is what every decently operating NOC is already doing today. They have bunch of tools external or home grown which go and query the network for specific information. I am not clear why do we need a new protocol for this. Note this is massive undertaking to keep track of what can be received across zoo of vendors and even within each vendor variants of operating systems. Best, R. On Thu, Mar 9, 2023 at 3:38 AM tanzhen (A) <tanzh...@huawei.com<mailto:tanzh...@huawei.com>> wrote: Hi Robert, Please see my reply inline. 发件人: Robert Raszuk [mailto:rob...@raszuk.net<mailto:rob...@raszuk.net>] 发送时间: 2023年3月8日 21:38 收件人: tanzhen (A) <tanzh...@huawei.com<mailto:tanzh...@huawei.com>> 抄送: yingzhen.i...@gmail.com<mailto:yingzhen.i...@gmail.com>; rtgwg-cha...@ietf.org<mailto:rtgwg-cha...@ietf.org>; rtgwg@ietf.org<mailto:rtgwg@ietf.org> 主题: Re: Slot Request for RTGWG IETF 116 Hi, I have two questions: 1. Draft says that triggering the action is an event which in defined by configuration: "configured troubleshooting triggering condition." If so that only covers very small subset of possible anomalies. Moreover this would only cover anomalies which are known apriori. [T.Z.]: The initial purpose of this protocol is to obtain network-wide O&M information when a network failure occurs, which helps locate the failure. Besides the pre-configured condition, which triggers automatically, O&M personal could actively request more information of other devices, with PASP. More use-cases will be updated to the draft later this week. 2. The draft focuses on control plane troubleshooting. Well most protocols have build in mechanisms for that. Instead most interesting failures are happening not in control plane but in data plane. So do you plan to refocus or add ability to self trigger actions based on various data plane events ? [T.Z.]: Thank you for your advice. For now, we're focused on troubleshooting of control plane. The data plane scenario is a good direction for future expansion. Many thx, Robert On Wed, Mar 8, 2023 at 7:25 AM tanzhen (A) <tanzhen6=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org>> wrote: Hi Yingzhen, I would like to request a 10 minute slot for Protocol Assisted Protocol (PASP) draft： https://datatracker.ietf.org/doc/draft-li-rtgwg-protocol-assisted-protocol/ An updated version of this draft will be uploaded later this week. Presenter: Zhen Tan Thanks. Zhen _______________________________________________ rtgwg mailing list rtgwg@ietf.org<mailto:rtgwg@ietf.org> https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
