Re: [Coin] Semantic Routing : Drawing the Lines

[Marie-Jose Montpetit <[e-mail]>]

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 <[e-mail]> <[e-mail]>
Reply: Toerless Eckert <[e-mail]> <[e-mail]>
Date: March 1, 2022 at 12:55:16 PM
To: Adrian Farrel <[e-mail]> <[e-mail]>
Cc: [e-mail] <[e-mail]> <[e-mail]>, Marie-Jose Montpetit
<[e-mail]> <[e-mail]>, [e-mail]
<[e-mail]> <[e-mail]>, Dirk Kutscher <[e-mail]>
<[e-mail]>
Subject:  Re: [Coin] Semantic Routing : Drawing the Lines

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:
> 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
>
> --
> Coin mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/coin

-- 
---
[e-mail]