Hi Robert, Please see my reply inline ([RE2]).
Thanks, Zhen From: Robert Raszuk [mailto:rob...@raszuk.net] Sent: Friday, March 10, 2023 5:30 PM To: tanzhen (A) <tanzh...@huawei.com> Cc: rtgwg@ietf.org Subject: Re: Slot Request for RTGWG IETF 116 Hi, > 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. Do you mean by North-South management protocols, which usually needs a centralized controller? PASP is designed to transmit O&M information between devices. It is a non-centralized east-west protocol. Ok so let's take an ISIS L2 with 1000 nodes. Assume you will have a protocol to exchange some diagnostic information between nodes. That's cool - but I have a simple question - what is each node supposed to do with this data ? Would it not need to send it to centralized controller anyway ? [RE2]: There are 2 types of scenarios. 1. If the pre-configured condition is triggered, such as a RSVP-TE Set Up Failure, a node should send a notification message with some diagnostic information to the ingress node. 2. If receiving a PASP Request message, a node should send the requested type of information to the source of request. You can see that the major purpose of this document is to set up a protocol for a O&M personnel to fetch diagnostic information involving multiple nodes on one node, without a centralized controller. I hope that this is not going in the direction to allow one node to modify configuration or behaviour of another one or is it ? [RE2]: We are not trying to allow one node to modify configuration of another. This document and therefore the protocol focuses on troubleshooting. And I agree with you about the difference between venders and operating systems. That is actually part of the reason why we want an “assisting protocol” by which different route protocols could announce general O&M information in a uniform way. That could better assist the use of such management tools and will be great relief for O&M personnel. So you are defining a Request Message and there we find Request Data field defined as: o Request Data (Variable): Specifies information of the data that the local device is requesting. The specific format remains to be determined per each protocol, as well as each use case. The point is that this is a massive undertake to redefine again what protocols already expose. Leave alone redefine ... even collecting it seems impossible. For example you have today OpenConfig vs YANG camps. Then each have tons of vendors extensions. How do you envision to address interoperability and not when the new protocol envelope you are defining is shipped but on a daily basis ? See I have in the past written very similar document, much more narrow and targetted - to just focus on BGP - and with very few special selected fields. Original doc name was BGP Diagnostic Message then we merged it and got new new name BGP Operational Message. It was only point to point. Well it is still sitting on the shelf as folks said we can already query boxes from mgmt stations just fine. While perhaps nice to have there is no burning need (read $$$ to be spent) to have one box query its peer. [RE2]: As I claimed above, we are not trying to allow one node to modify configuration of another. This protocol focuses on troubleshooting. By clearly defining diagnostic information needed on each type of request, we could reuse the information that some protocols have already exposed without a re-definition. As to how to collect such information, this is not covered in this document. Each vender could have its own internal implementation as long as the PASP mechanism is handled correctly, just like most of other routing protocols. Kind regards, Robert Thanks, Zhen 发件人: Robert Raszuk [mailto:rob...@raszuk.net<mailto:rob...@raszuk.net>] 发送时间: 2023年3月9日 17:10 收件人: tanzhen (A) <tanzh...@huawei.com<mailto:tanzh...@huawei.com>> 抄送: rtgwg@ietf.org<mailto:rtgwg@ietf.org> 主题: 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<mailto:rtgwg@ietf.org> https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
