[Coin] Semantic Routing : Drawing the Lines

[Adrian Farrel <[e-mail]>]

Hi,

The next thread arising from the discussion at the interim is about where to
draw the lines for Semantic Routing.

Specifically, Marie-Jose observed, "It is not network programming - it is
dataplane programmability." Although she did qualify that with a smiley
face, it's an important question from a routing and forwarding perspective
because simply programming forwarding planes in the network needs careful
coordination in order to avoid forwarding loops and packet sinks. Anyone who
has attempted to install static routes across a large and complex network
will know the associated risks, and while some work in the IETF (such as,
draft- ietf-teas-pce-native-ip) has looked at ways of installing static
forwarding paths into the network, even that assumes the coordination of a
central controller and limits the extent of the paths to be installed.

So the point here is that the network has to be viewed as a whole and
programmed accordingly. That may (will) lead to programming of individual
forwarding hardware. And there will very probably be an intermediary step
where the network is partitioned into fragments that are each asked to
achieve specific results (intent), but left to work out how to program the
forwarding hardware within the network fragment.

Some of this plays into Joerg Ott's question, "This seems more about
'semantic' forwarding. Could you explain how you envision the routing part?"
and Dirk Kutscher's comment "I suggest 'Software-Defined Forwarding
Strategies' as an alternative name for this" (although Dirk also gave us a
smiley face - there's a lot of smiling in COIN :-).

The point is that (of course?) the ultimate objective of any routing
strategy is to program the forwarding elements in the network. So, in a
world of SDN and/or programmable devices, it is the forwarding elements that
get programmed. And, if the forwarding is acting based on information
carried in the packets (which is, in any case, how forwarding works today)
then, yes, this is semantic forwarding. 

But, as observed above, the programming of the forwarding elements cannot be
uncoordinated.  Indeed, even in networks that simply forward based on the
destination address, it is necessary to determine the correct forwarding
actions based on a coherent view of the network topology, an
objective/algorithm (usually SPF), and an understanding of the current state
of the network. That view and the coordination, combined with the
information and objectives, is the routing policy. 

So, when the forwarding decisions get more complicated (some packets to a
destination go one way in the network, some go another way), there is a need
for the routing policy to be more carefully thought-out. For example, a
policy to reduce end-to-end latency is only practical if it is aware of the
risk of causing congestion by sending all the traffic down the small set of
lowest-latency links.

So, semantic routing is about determining the right ways to program
forwarding devices across the whole network, and this is, in its way,
network programming. In an SDN sense, this is part of the orchestration
function.

But, please be aware that an SDN approach is only one way of achieving
semantic forwarding/routing. You could, for example (and I am neither
advocating for or against this), add lots of additional information to an
IGP and update the routing algorithms in the routers (allowing them to
construct their RIBs as they do today but using more information about the
network). The update of the algorithms (of course - again?) requires
coordination to achieve stability and avoid loops etc., and those algorithms
may need research. Further, these algorithms could be pushed to the network
nodes relatively dynamically (programming of compute resources in the
network), or could require full software updates.

And this may answer Dirk Kutscher's follow-up: "Isn't a collection of fields
to match against effectively a label?" Yes, it is. And so is an address. We
are talking about complex, potentially multi-field labels that convey
information that is used to determine forwarding actions. We are talking
about forwarding actions that may be simple look-ups or may be "micro
programs" acting on information about the network and information carried in
the packets. We are talking about the routing algorithms that are used to
generate those forwarding actions. We are talking about how to collect the
network state information necessary to derive and operate those routing
algorithms. And we are talking about how to install the algorithms and
forwarding instructions into the network. Above all, we are talking about
how to do this in a stable way within a complex system.

Best,
Adrian