Subject: [Coin] Semantic Routing : Drawing the Lines

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 1 Mar 2022 16:55:09 -0000

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

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 1 Mar 2022 18:55:12 +0100

I'd broadly look at "what (semantics)" as one vertical of work,
where worst case we get only completely proprietary secret
implementation sauce of vendors - like what pretty much most of
IETF protocol implementations are.

The other work vertical is the "how (to implement)",
where we have (IMHO) done rather little work in IETF/IRTF.
And worst-case this vertical just improves how IPv4 unicast
gets implemented in future networks, aka: no new "what" semantic routing.

The "how (to implement)" vertical would be quite well-serving for the
research community, because it could help bring back experimentation/research
into the "what (semantics)", which IMHO we lost in the process of
research-programmable platforms becoming more and more irrelevant for
wide-area networks, leaving researcher to focus on inventing new
protocols/semantic only where the industry would already use software
forwarding.

The whole discussion about how to couple forwarding and control plane
that Adrian recites below is hopefully not at the core of future research
because i think it's been explored more than enough and we know for
every possible solution one candidate deployment sweet spot.

The extend to which we need programmability of forwarding planes to
introduce the routing semantics of interest on the other hand consists IMHO only
of a lot of historic, common wisdoms that can be challenged or fortified, and
a lot of gaps.

I think it may be useful to start with scenarios and then explore whats
needed for them. For example:

- regional L3 network in 2030, 1Tbps links in core, 10Gbps in access,
  think smaller country or larger urban area in large country -
  (200 miles diameter, 20++ million people, 2++ billions things).
- Future virtual private network operator wants to get a programmable
  slice across the network, where he can provide for every router the
  P5 program to process its packets.
- In one case, this could be one out of few big content aggregators,
  maybe wanting to use ICN and/or BIER forwarding plane semantics
- In another case it is criticial infrastructure services such as remote
  driving or car2curb operations wanting highly resilient / deterministic
  (and better) semantics. 
- In  hird case its the regions reseaerch community wanting to run some
  new research packet semantics.

Of course, this is a vision, and any instance in reality would have to
be darn good before anyone would trust critical infrastructure services
to such a network, but: We do have data-centers mixing critical
infrastucture services with "entertainment" so we know from other
domains whats required, and we had the same concerns back 20 years when
we started to multiplex voice and video into data networks. 

And if thats not a useful reference scenario to build out research
aspects for the "how (to implement)" for new semantic routing, then
please suggest what you think useful scenarios to build from would be.
  
Cheers
    Toerless

On Tue, Mar 01, 2022 at 04:55:09PM -0000, Adrian Farrel wrote:
> -- 
> Coin mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/coin

-- 
---
[email-masked]

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 1 Mar 2022 13:28:33 -0500

Dear all:

The COIN chairs are late for the interim minutes but please wait for our
specific recommendations on how to move forward with the semantic routing
research in COIN before continuing this thread.

We will post the minutes and recommendations later today.

Thanks

J/E/M

From: Toerless Eckert <[email-masked]> <[email-masked]>
Reply: Toerless Eckert <[email-masked]> <[email-masked]>
Date: March 1, 2022 at 12:55:16 PM
To: Adrian Farrel <[email-masked]> <[email-masked]>
Cc: [email-masked] <[email-masked]> <[email-masked]>, Marie-Jose Montpetit
<[email-masked]> <[email-masked]>, [email-masked]
<[email-masked]> <[email-masked]>, Dirk Kutscher <[email-masked]>
<[email-masked]>
Subject:  Re: [Coin] Semantic Routing : Drawing the Lines

research community, because it could help bring back
experimentation/research

The extend to which we need programmability of forwarding planes to
introduce the routing semantics of interest on the other hand consists IMHO
only
of a lot of historic, common wisdoms that can be challenged or fortified,
and
a lot of gaps.

Cheers
Toerless

-- 
---
[email-masked]