Subject: [oam] One example of an updated approach

From: Fred Baker <[email-masked]>
Date: Sun, 22 Aug 2010 18:05:42 -0700

On Aug 22, 2010, at 4:15 PM, Ronald Bonica wrote:

> The scope of this design session is limited to the forwarding plane. Proposals concerning control and management plane protocols will not be accepted. For example, a proposal that probes a tunnel for continuity would be acceptable, while a proposal for reporting tunnel continuity to a routing protocol or management station would be productive, but beyond the scope of this workshop.

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.

What we know how to do, and have done in the forwarding plane, is ICMP. I would argue that BFD is largely an extension to ICMP in concept, although it is implemented in UDP. It does the same functions - it sends keep-alive messages in the form of pings to a peer and observes the response. 

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.

An example of a paradigm in which the network might respond to questions asks a lower-layer device, such as a switch, to advise an upper-layer device, such as a host or router attached to the switch, for a specified indication of a specific kind of failure. For example, the router could advise the switch that it is interested in a given MAC address, one that perhaps happens to be in use by a peer router, and ask the switch to advise it if the switch loses connectivity to that MAC address. The switch would (somehow) put a watch on the port the MAC address is associated with, and if electrical connectivity is lost send a specified message to the router within some stated interval. Such electrical loss would protect against a hardware failure at the switch or in a connecting cable without routers needing to poll each other at all. It would not protect against forwarding plane failure in a peer, however; other kinds of failures would still be primarily detected at the same plane. There are obvious extensions for various inter-tube technologies, based on layering them on lower layer networks or relaying such requests to peer systems - if the switch in the example is connected to the MAC address via another switch, it could ask the neighboring switch for such a message and remember to forward it to the original requestor should it get one.

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 24 Aug 2010 16:14:41 -0400

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 24 Aug 2010 21:56:59 -0700

> 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 i…

Sure.

Fair warning - I will be out and about, with vacation and travel next week, a WIDE workshop after Labor Day, and an SGIP workshop the week of the 13th. But you know me. I'll find it and fit it in.

---

From: Ronald Bonica <[email-masked]>
Date: Wed, 25 Aug 2010 17:40:03 -0400

I will try to have a draft ready by this weekend.

                     Ron

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]]
> Sent: Wednesday, August 25, 2010 12:57 AM
> To: Ronald Bonica
> Cc: [email-masked]
> Subject: Re: [oam] One example of an updated approach
> 
> 
> > 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.
> 
> Sure.
> 
> Fair warning - I will be out and about, with vacation and travel next
> week, a WIDE workshop after Labor Day, and an SGIP workshop the week of
> the 13th. But you know me. I'll find it and fit it in.