[oam] One example of an updated approach

[Fred Baker <[e-mail]>]

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.