Subject: [Anima] FYI: Self-Driving Networks without Self-Crashing Networks

From: Brian E Carpenter <[email-masked]>
Date: Fri, 9 Jul 2021 14:52:48 +1200

I've just come across Jeff Mogul's keynote speech about self-driving (i.e. autonomic) networks from a couple of years ago. Well worth reading before designing your own autonomic network:
https://conferences.sigcomm.org/sigcomm/2018/files/slides/selfdn/keynote.pdf

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Jul 2021 13:11:03 -0400

Brian E Carpenter <[email-masked]> wrote:
    > I've just come across Jeff Mogul's keynote speech about self-driving
    > (i.e. autonomic) networks from a couple of years ago. Well worth
    > reading before designing your own autonomic network:

An interesting read.

1) the ACP is the fail-safe communication path.  (slide 43)
2) the ACP's RFC6550 provides a *map* of what links are actually working
(slide 48)
3) the ACP is the set of soft surfaces that prevent second collision and own
goals.

I like "Self-Driving-Network" as a new expansion of SDN :-)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Alan DeKok <[email-masked]>
Date: Sat, 10 Jul 2021 09:13:44 -0400

> On Jul 8, 2021, at 10:52 PM, Brian E Carpenter <[email-masked]> wrote:
> 

  A few things stood out for me.  Both from what he said, and from personal experience.  He says:

* It's really hard to get detailed/accurate/up-to-date network "maps" today

  IMHO it's essentially impossible to know what a system is doing, or control it, if you have no idea how it's put together.  The solution so far has been to add more protocols, more signalling, etc.  Which brings us to the next bit.

  Networks are generally organized by configuration, not by state.  i.e. the "state" of the network, such as it is, is buried inside a random grab-bag collection of configuration files and running data structures, on multiple systems, in multiple formats.  There is no way to say "move to state X", or even to query what state the network is currently in.

  States are not composable, so if one state fails, networks cannot fall back to using a parent state.  He alludes to this on slide 43: "if the centralized control plane fail-stops, local control continues to "fly straight and level""

  Add to that security issues, bugs in implementations, etc.

  The combination of those factors means that we are likely to get cascading chains of failure.  He mentions this on slide 39: "failures are the result of multiple faults". 

  Our networks are getting more fragile over time.  SDN simplified this somewhat for a bit, but is perhaps now approaching the peak of complexity, before there's yet another simplifying solution.

  Alan DeKokk.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 10 Jul 2021 12:44:33 -0400

Alan DeKok <[email-masked]> wrote:
    >   Networks are generally organized by configuration, not by state.
    > i.e. the "state" of the network, such as it is, is buried inside a
    > random grab-bag collection of configuration files and running data
    > structures, on multiple systems, in multiple formats.  There is no way
    > to say "move to state X", or even to query what state the network is
    > currently in.

That's an interesting and rather profound observation, I think.

90% of debugging (of both programs and networks) is about getting the right
set of observations.    A difficulty is that it's so hard to capture the
state.   (There were LISP debuggers which could step forward *AND*
backwards...)
The fact that ptrX is NULL at the point where it is dereferenced is not
interesting or useful information:  the point where it was supposed to first
not be NULL is the interesting point.

In debugging network configurations, one tries to get as many observation
points.  A key challenge in many systems (Linux, *BSD, and all hardware) is
that packets disappear between observation points, often without clearly
leaving a trace.
I've often had to debug Linux iptables filters by observing the counters
which increment and which don't.  (The replacement nftables' killer app is
perhaps that the counters are available in JSON, and so one should be able to
automate this much easier)

What does all of this mean to ANIMA?
We've had SNMP support in all sorts of things for ages.
I'm still amazed at how often it's not used.
So many interesting dotcoms that were going to do amazing things with it back
in 1999/2000, which then went bust, and we never saw things again.

We need basic data collection in a free to install module which goes into a
common database, and then we need AI/heuristic systems that people can send
their data to for "help" --- those things might cost $$$, but if you have a
problem, then maybe you are willing to pay at the time of disaster.

And, it's never the people who are at well-managed companies who have the
problems.  This is where I think the ACP wins: if it permits collection of
data from all sorts of systems simply and consistently. (Particularly, when
connectivity is poor)

Is there some way to support the analysis of the data in another fashion?

(Ad driven?  I doubt that would work.  While some IoT stuff can driven by
targetting marketing, like the person to gets diaper and baby formula ads
after they buy a pregnancy test...  I don't know how that would work for ISPs
and Enterprises with problems.   Maybe)

Maybe it will become some kind of welfare situation, recognizing that many
network anomalies are precusors to attacks?   If so, assuming that we can
even figure out what the network state is, do we have any chance of
anonymizing the data?

---

From: Alan DeKok <[email-masked]>
Date: Sat, 10 Jul 2021 13:06:22 -0400

> That's an interesting and rather profound observation, I think.

  Thanks.  As background, most of the networking code I've written in the last 25 years is wrong.  Not that it doesn't work, it does.

  But as time progresses, I find myself moving to a much more state oriented approach.  The code is easier to understand, and easier to debug

> state.

  Especially when the state is embodied in a collection of variables, and if/then/else procedural code which checks those variables.

  As compared to "the current state handler is function X.  So I know it's in state X".  How did it get there?  That's easy, instrument the state transitions, and print those out.

  Alan DeKok.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Jul 2021 10:22:40 +1200

>   As compared to "the current state handler is function X.  So I know it's in state X".  How did it get there?  That's easy, instrument the state transitions, and print those out.

However, that doesn't work at network scale. There's a peculiar form of special relativity in a network; because messages take finite time to propagate state changes between nodes, there can be no meaningful "state" for the network as a whole, only N partial states known to each of N nodes. Your view of your neighbour's state is always potentially out of date. That applies to each ASA in an ANIMA-style network, too. A GRASP negotiation is explicitly negotiating state with a peer ASA.

   Brian

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 12 Jul 2021 10:46:45 -0500

> I like "Self-Driving-Network" as a new expansion of SDN :-)

I thought self driving car/truck, etc. was an issue not self driving
network. That's why I was disappointed after reading Jeff Mogul's keynote
address especially considering that Google is a leading for in self driving
cars issue. Maybe that keynote was accidentally accepted :)

Behcet

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>