Re: [oam] One example of an updated approach

[Ronald Bonica <[e-mail]>]

Fred,

Comments inline.....

> 
> A tool that performs a keep-alive or make-dead function on a tunnel-or-
> whatever seems marginally functional without the ability to report its
> results to SOMETHING. I worry that you may find that this constraint
> declares out-of-scope most useful tools. I'm also concerned that
> describing what we have and constraining the discussion to that likely
> means that the result will be what we have.

I see your point. A forwarding plane diagnostic tool is *absolutely worthless* unless it can report its results to something (e.g., a cli, a management protocol, a routing protocol). It goes without saying the that any diagnostic tools that we build will have to report results to something. However, for the purposes of this design session, I would like to focus on the diagnostic tool, and not how or to whom it reports. Hopefully, we can build some kind of north/south interface so that that tools output will be accessible to many entities.



> 
> From my perspective, either we continue with the "you can't talk with
> the network, only over it" paradigm, or we look at a paradigm in which
> the network can itself respond to questions. I think the latter is
> required if we want to do anything that is recursive.
> 

This question is absolutely key, and I would be very interested in co-authoring a paper with you that poses this question to the design session. If you like, I will produce a first draft and send it to you.

                                                       Ron