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 ?
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 ?
> 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.
Kind regards,
Robert
>
>
> Thanks,
>
> Zhen
>
>
>
> *发件人:* Robert Raszuk [mailto:rob...@raszuk.net]
> *发送时间:* 2023年3月9日 17:10
> *收件人:* tanzhen (A) <tanzh...@huawei.com>
> *抄送:* 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> wrote:
>
> Hi Robert,
>
> Please see my reply inline.
>
>
>
> *发件人:* Robert Raszuk [mailto:rob...@raszuk.net]
> *发送时间:* 2023年3月8日 21:38
> *收件人:* tanzhen (A) <tanzh...@huawei.com>
> *抄送:* yingzhen.i...@gmail.com; rtgwg-cha...@ietf.org; 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> 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
> https://www.ietf.org/mailman/listinfo/rtgwg
>
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
