►
From YouTube: IETF-RTGWG-20220621-1500
Description
RTGWG meeting session at IETF
2022/06/21 1500
https://datatracker.ietf.org/meeting//proceedings/
B
B
C
C
C
C
Please
stay
milled
during
the
meeting
and
when
you
are
invited
to
talk,
please
make
sure
identify
yourself
and
speak
join
the
meet.
I
call
queue
for
questions
and
feel
free
to
use
the
chat
window
during
the
meeting,
but
please
make
your
important
point
available
at
the
mic.
So
people
can
everybody
can
know
about
it.
C
D
E
A
E
It's
not
attempting
to
push
solutions
out
there
at
the
moment,
but
more
discuss
the
approaches
that
could
be
made
and
see
whether
we
can
burn
those
straw,
men
and
and
move
forward.
So
I
think
we
should
leap
straight
in
and
daniel
should
go
ahead.
I
guess
dan.
If
you
ask
to
share
slides,
then
the
chairs
will
say
yes
and
we'll
get
the
right
slide
set.
F
So
what
we
wanted
to
do
at
the
start
of
our
session
here
was
just
provide
a
refresher
on
semantic
routing
and
give
you
some
background
on
why
we've
been
sort
of
investigating
the
topic,
some
of
the
use
cases
and
a
couple
of
links
to
existing
documents
that
you
may
find
relevant
and
then
we'll
build
on
the
architecture,
discussion,
potential,
sort
of
complementary
ancillary
technologies,
and
then
you
know
where
to
which
direction?
Should
we
be
heading
after
that
cool.
F
F
We
are
very
much
mindful
that
there
are
applicability,
slash
use
cases
for
semantic
routing
already
in
commercial
environments
or
or
near-term
commercial
environments.
Now
I
could
spend
a
few
minutes
talking
about
the
tens
or
hundreds
of
potential
use
cases
for
this
type
of
technology,
but
that's
really
not
necessary,
because
we've
all
been
drinking
the
kool-aid
as
the
sort
of
what
future
internet
will
look
like
and
enable
us
to
do.
But
really
my
main
use
case
is
on
the
next
slide
and
it's
specifically
around.
F
We
know
that
the
cloud
is
sort
of
dominant
now
and
essentially
the
internet,
to
a
certain
degree,
is
providing
internet
interconnectivity
between
cloud
resources,
whether
sort
of
hyperscale
cloud
or
highly
distributed
sort
of
fog
architecture,
and
yes,
we're
going
to
be
talking
about
capacity
in
qos.
So
essentially,
we
have
a
fairly
ubiquitous
connectivity
with
with
high
bandwidth
available
across
those
links.
F
So
the
use
case
that
that
I'm
kind
of
interested
in,
in
fact,
I
in
full,
in
the
spirit
of
full
disclosure,
there's
two
use
cases,
but
this
is
the
one
that
I'm
going
to
talk
about
today
and
that's
sort
of
the
health
network
and
certainly
in
europe,
we're
seeing
significant
activity
for
this
particular
use
case.
There's
a
several
european
commission
funded
projects
and
epsrc
funded
projects.
That's
the
uk
research
council
that
are
bringing
together
telecommunication
experts.
F
Researchers,
clinical
and
hospital
sites,
as
well
as
sme
type
stakeholders,
and
that's
to
provide
connectivity
sort
of
network
infrastructure
that
can
connect
several
emerging
devices
that
are
going
to
be
used
for
patient
care
and
also
well.
This
is
not
just
kind
of
proactive
patient
care,
that's
maybe
monitoring
your
your
blood
pressure,
cholesterol
or
fat
content
or
glucose,
etc,
but
also
reactive
devices
that
in
some
situation
you
have
a
particular
problem
with
your
health.
F
It
would
sort
of
trigger
a
critical
alarm
and
various
sort
of
remedial
actions
would
be
taken,
and
these
devices
have
numerous
requirements.
So
maybe,
in
terms
of
networking
requirements,
there'll
be
devices
that
that
have
to
be
always
on
connected
low
latency,
minimal
bandwidth.
There
will
be
other
devices,
maybe
connected
to
mri
type
devices
that
are
are
used
sparingly,
but
actually
very
high.
Bandwidth,
super
high
resolution,
photos
and
graphics,
spectrometers,
etc,
and
everything
in
between
some
of
these
devices
will
have
various
stacks
running
directly
on
top
of
them.
Others
are
fairly
dumb.
F
They
have
sort
of
one
task
in
mind
and
essentially
will
have
to
be
interconnected
through
various
gateways
that
that
will
have
an
ip
stack,
but
it
has
very
limited
capabilities,
so
it
can't
participate
in
various
overlay
technologies,
and
you
know
why.
Why
is
this
an
interesting
use
case?
Well,
you
know
clearly
it's
for
our
benefit,
it's
massive
in
terms
of
sort
of
growth,
and
I
think
it's
just
underlined
by
the
revenue
opportunity
as
well,
which
generally
money
sort
of
talks
and
that
funds
a
lot
of
our
research
and
technology
development.
F
Now
we
could
just
look
at
historic
methods
of
meeting
some
of
these
requirements
when
we
define
our
problem
statements
and
define
the
use
case,
but
actually
we're
we're
we're
going
to.
Oh
I've
got
a
request
to
go
into
slide
deck
mode.
Okay,
I'll
try
that
problem
is
I've,
got
multiple
monitors.
So
now
I
have
to
stop
sharing
and
resharing
my
screen,
but
while
I
do
that,
I
will
try
to
multitask.
F
Essentially
we
need
to
sort
of
take
an
a
slightly
different
approach
with
solving
some
of
these
problems.
I
think
adrian,
you
have
to
give
me
us.
The
screen
share
again
thanks:
okay,
there
we
go
should
have
a
happy
customer
now
we
we
can't
just
build
up
new
infrastructure
and
expect
to
throw
unlimited
bandwidth
at
it,
and
that's
that's
a
debate,
a
discussion
that
we're
going
to
have
later.
F
We
could
jack
up
our
qrs
capabilities,
provide
more
memory
and
cpu,
I.e
more
state
to
devices
more
logic
more
capability,
but
that
just
increases
the
cost
of
the
physical
element
as
well,
and
maybe
requires
some
essentially
overhead
for
packet
processing
and
forwarding.
Maybe
we
should
sort
of
reconfigure
our
topology.
F
F
Well,
essentially,
every
one
of
you
is
an
expert
and
will
understand
the
the
architecture
here
in
terms
of
routing
it's,
it's
tried
and
tested
for
many
decades
already,
and
what
we're
advocating
is
semantic
routing
which
will
augment
existing
sort
of
ip
architecture
in
order
to
meet
some
of
the
emerging
requirements
and
solve
these
future
use
cases.
Now
maybe
semantic
routing
is.
It
is
not
necessarily
a
clear
term,
considering
the
the
scope
of
the
work
that
we're
having
to
investigate
here
in
the
problem
space
and
the
potential
solutions.
F
F
Oops,
sorry
so,
historically,
yes,
we've
got
dijkstra
and
various
other
techniques,
event
driven
algorithms
for
forwarding
traffic
and
deciding
what
to
do
with
traffic.
Yes,
we've
got
control,
plane
technology
that
can
be
either
distributed
or
centralized
or
or
or
some
kind
of
hybrid.
The
these
will
still
be
used.
F
F
Catastrophic
failure.
In
some
cases,
one
of
the
sort
of
sub
use
cases
that
we
had
for
the
medical
domain
was
field
hospitals
that
might
be
set
up
in
the
event
of
of
some
sort
of
natural
occurring
disaster,
where
you
essentially
have
sites
coming
on
and
off
line
and
joining
the
network
where
you've
got
patients
being
treated
with
with
different
injuries
and
then
devices
that
are
providing
patient
data
having
to
store
that
information
at
central
locations.
F
That
data
needs
to
be
clearly
differentiated
and
in
that
kind
of
environment,
where
it's
ad
hoc
actually
sets
everything
up.
Traffic
engineering
rules
and
using
some
overlay
technology
would
be
extremely
problematic
and
it's
likely
the
devices
deployed,
wouldn't
support
that
either
and
then
the
second
part
of
semantic
routing
or
semantic
networking,
if
you
like,
is
the
marking.
F
Now
we've
got
some
pretty
cool
tools
already
in
our
tool
kit,
so
we
can
use
really
anything
in
the
ip
header
or
the
length
of
the
packet
or
you
know,
maybe
some
meta
information
as
well.
Oh
slide
has
not
moved.
It's
moved
on
my
screen,
maybe
it's
being
updated
I'll,
just
bounce
that,
hopefully
you
should
see
packet
marking
part
of
semantic
routing,
but
maybe
actually
we
will
use
new
bits.
F
F
I
suppose
one
of
the
the
design
goals
of
semantic
routing
or
semantic
networking
is
not
to
constrain
the
solution
that
you
might
use
in
order
to
achieve
the
objectives.
What
we
want
to
do
is
essentially
say
well
for
some
situations
you
might
use
foo
technology
and
for
other
situations
you
might
use
an
entirely
different,
encapsulation
or
or
packet
header
information.
F
Okay,
if
it,
if
any
of
my
previous
slides,
haven't
been
contentious.
Maybe
this
is
the
first
contentious
issues.
The
bold
statement
here
is
semantic
routing
or
semantic
networking
architecturally
speaking
at
least
is
not
a
big
deal,
and
I
know
that
some
people
might
disagree.
This
is
the
itf
and
not
really
what
makes
it
so
cool,
but
what
we're
not
doing
is
redesigning
ip
routing
we're
not
breaking
the
internet.
We're
not
saying
this
specifically
applies
to
a
greenfield
network
and
you
must
rip
out
and
replace
all
of
your
existing
equipment.
F
What
we're
saying
is
this
is
a
set
of
objectives
with
capability
and
architecture
that
augments
existing
technology.
So
in
terms
of
traditional
sort
of
identification
and
endpoint
information,
the
ip
address
great,
we
will
continue
to
use
the
ip
address.
It's
just
that
now
we're
going
to
have
a
semantic
element,
that's
applied
to
it
and,
if
you're
a
device
that
supports
semantic
networking
great,
you
might
understand
it
and
do
something
with
it.
F
F
Then
we
kind
of
highlighted
the
work
a
couple
of
itfs
ago
in
the
routing
working
group,
and
there
was
your
strong
response
to
that
positive.
I
believe,
because
there
are
clearly
a
lot
of
routing
experts
who
are
kind
of
interested
in
this.
Even
if
that
interest
is
simply
saying
we
don't
need
to
do
it.
You
know
that's
great,
you
know,
let's
hear
that
there
are
numerous
documents
that
we've
tried
to
write
in
order
to
document
the
requirements
and
some
of
the
use
cases
some
of
the
objectives.
E
G
Thank
you
very
much
for
the
nice
presentation.
Just
have
a
couple
of
questions,
so
you
focus
on
the
medical
device.
So
today
most
medical
devices
like
I
know
lots
of
people
wear
those
continuous
molecular
glucose
monitoring.
It
just
go
to
their
phone
and
then
the
phone
reported
directly
to
the
server
or
whatever
in
the
cloud.
So
I'm
just
curious,
like,
in
that
case
the
medical
device
environment,
the
semantics.
G
F
So
you
would
have
a
patch
that
sits
on
your
arm
for
two
weeks.
It's
essentially
providing
glucose
information
reading,
that's
pretty
cool
and
unless
it
drops
below
a
particular
point
and
you
slip
into
a
coma
that
would
be
bad
or
exceeds
a
particular
threshold.
And
then
you
need
to
pump
some
insulin
into
you.
F
F
F
H
H
F
We
would
ideally
be
able
to
kind
of
mark
traffic
and
then
set
up
connectivity
based
on
where
that
traffic
needs
to
go
and
what
maybe
network
requirements
it
has
in
terms
of
latency
and
bandwidth
and
jitter
etcetera.
The
payload
inspection
you
know.
Potentially
there
is
sort
of
hardware.
Now
you
know
low-cost
white
white
box
hardware,
that's
capable
of
of
looking
at
the
payload,
but
then
you
know
it.
It
there's
a
whole
set
of
other
issues
that
that
potentially
opens
up
in
terms
of
encryption
and
privacy
as
well.
F
I
I
I
How
do
you
make
sure
that
once
you
standardize
it
that
people
are
being
truthful
because
everybody's
gonna,
you
know
somebody
everybody's
gonna,
want
whether
it
be
you
know
somebody
who's
gaming
they'll
come
up
with
some
way
to
to
get
the
gate
the
same
priority
that
these
life
critical
applications
are,
and
it's
in
unless
it's
under
this
a
single
administrative
control.
Once
it
goes
over
the
public
network,
you
know
all
bets
are
off
and
also
you
know,
this
is
going
to
cost
more
money
to
get
this
treatment.
How
are
you
going
to
you
know?
F
Questions
ac
and
I
I
like
the
way
you
think
I
will
in
the
interest
of
time
I
will
defer
somewhat
some
of
these
responses,
because
I
think
we
will
cover
them
in
more
detail
as
we
go
through
the
session
in
terms
of
things
like
you
know,
stopping
people
maliciously
attacking
the
system
or
trying
to
game
the
system.
You
then
it
would
be
a
sort
of
what's
the
expression,
trust
but
verify
I've
heard
before.
F
E
Yes,
thanks
dan
and
ac,
I
think
ac
is
asking
the
right
questions
with
regard
to
apn.
I
I
bounced
all
this
off
the
apn
people,
because
you're
right
it
it
looks
very
similar
and
the
apn
guys
said
that
they
were
principally
interested
in
per
hot
behaviors
and
not
in
influencing
the
forwarding
or
even
the
the
routing
part
that
determines
what
the
forwarding
paths
are
now
I
I
think
this
is
all
open
for
discussion,
but
that's
that's
how
we
got
where
we
are,
so
we
should.
E
D
C
J
D
J
J
I
think
it
was
a
nice
nice
phrase
so
to
give
you
some
of
my
views
on
on
quality
service,
so
I
think
the
first
thing
to
say
about
cross
is
it's
really
trying
to
buy
you
a
time
advantage,
so
the
schematic
at
the
bottom
is
supposed
to
indicate
that
you
know.
We've
got
a
whole
whole
range
of
applications
that
we
can
do
now
and
we
might
want
to
do
in
the
future.
J
We
have
some.
You
know
like
voip,
now
very
easy
to
do.
We
have
got
some
like
remote
surgery
which
are
not
yet
possible,
and
then
we've
got
some
which
are
kind
of
on
the
edge
of
being
possible.
So
it's
really
those
kind
of
ones
in
that
amber
zone,
so
the
ones
which
are
sort
of
almost
possible,
but
not
quite
those,
are
really
the
ones
where
cross
mechanisms
are
buying
an
advantage.
Because
you
can,
you
know
they
they,
maybe
they
become
feasible,
but
of
course
this
is
all
in
time.
J
J
You
know
so
in
a
world
of
growing
bandwidth,
especially
where
bandwidth
is
growing
quite
fast,
and
this
sort
of
this
edge
or
critical
edge
is
moving
to
the
right
quality
of
service
is
really
giving
you
a
time
advantage.
It's
not
doing
anything.
You
know
beyond
that.
Things
will
become
feasible,
so
to
point
out
something
obvious.
That
means
that
the
quality
of
service
mechanism
you
introduce
you've
got
to
introduce
it
quickly
enough
that
you're
not
losing
that
time
advantage
that
you've,
you
just
think
you're
gaining.
J
And
you
know
also
in
this
perspective,
you
know
cross
matters
more
where
bandwidth
is
constrained,
so
that
would
you
know
would
have
been
true
in
the
in
edge
networks
in
the
past
is
probably
much
less
true
today,
with
sort
of
fiber
and
5g
and
in
situations
where
capacity
is
hard
to
deploy.
You
know,
there'll
be
some
environments
where
it's
actually
difficult
to
go
and
put
in
new
new
capacity.
E
J
B
J
J
J
It's
re-sharing
capacity,
you
know
so
sort
of
an
analogy
I'm
drawn
here
is
with
the
with
the
first
and
second
laws
of
thermodynamics.
You
know
so
thermodynamics
has
sort
of
first
sources
that
you
can.
You
can
change
energy
from
from
one
form
to
another,
but
you're
not
creating
it
or
destroying
it,
and
then
entropy
in
the
system
will
either
stay
the
same
or
increase.
J
But
on
the
you
know,
on
the
positive
side,
there
are
lots
of
things
that
you
can
improve,
which
are
kind
of
in
the
sort
of
the
quality
field.
So
things
like
you,
know,
latency
with
aqm
measures
and
buffer
management,
and
you
know
ecn
and
l4s
kind
of
things.
There's
lots
of
things
you
can
do
there
that
are
really
good
on
reliability.
J
Energy
is
becoming
more
and
more
critical,
partly
because
of
energy
costs
going
up
and
us
wanting
to
be
greener,
partly
because
power
efficiency
is
not
not
increasing
the
same
rate
as
as
bandwidth
and
network
growth
is
so
that
the
fraction
of
cost
for
energy
is
going
up
in
your
network
lifetime.
Energy
costs
are
now
expected
to
be
kind
of
comparable
to
capex.
J
So
it's
really
important
that
you
work
on
it.
You
know
and
forwarding
takes
energy.
You
know,
so
it's
you've
got
to
make
sure
that
you
try
and
think
about
how
often
you
hit
forwarding
hardware
and
those
sorts
of
things
on
the
security
front.
I
think
security
is
very
closely
tied
into
quality
service,
so
you
know
like
mpls
and
vpns.
The
two
things
are
very
much
tied
closely
together.
J
J
You
know
3869
rfc
and
the
sort
of
difficulties
of
deploying
costs
at
the
beam
that
you
know
you've
got
to
try
and
align
to
a
commercial
model.
If
you
want
to
be
successful
in
this,
I
know
you
know
there
are
examples
where
it
does
align
with
the
commercials.
So
you
know
that
wholesale
costs,
for
instance
you
wear
a
global
operator
or
an
over-the-top
buyer's
capacity
or
quality
service
from
a
local
operator.
So
those
things
are
quite
are
well.
B
J
You
know
how
come
you've
got
to
make
sure
that
you
don't
just
have
everybody
using
the
the
top
priority.
We've
got
to
think
of
about
complexity
that
it
adds
to
the
system.
It's
complexity
makes
it
more
expensive
to
to
operate
and
manage
and
more
expensive,
probably
to
forward
packets
and
to
do
the
routing
and
we've
got
to
think
about
incremental
deployability,
and
you
know,
if
receive
foreign
to
18,
it
talks
about
aligning
incentives
and
aligning
the
pain
and
gain.
J
If
you
want
the
protocol
to
be
successful
or
an
approach
to
be
successful
and
just
finally
sort
of
sort
of
some
conclusions
relating
that
that
quality
service
stuff
back
to
semantic
routing
which
I'll
pose
as
some
questions
on,
I
think
need
to
be
thought
about
for
semantic
routing.
So
the
you
know
the
first
one
off
that
that
first
slide.
J
J
E
E
But
that
seems
to
be
a
bit
of
a
ph
b,
sorry
yeah,
perhaps
behavior
kind
of
view
of
of
quas,
rather
than
a
routing
view
where
you
might
be
putting
packets
onto
paths
that
are
more
appropriate
for
the
service
that
they
want,
and
that
sort
of
leads
me
to
your
your
commercial
point,
which
ac
made
as
well,
which
is
you
know
how?
How
do
you
stop
everybody
asking
for
the
best
quality
of
service?
J
J
People
just
buy
bandwidth
or
they
just
buy
a
connection.
That's
good
enough.
I
think
in
for
businesses
you've
got,
you
know,
there's
more
of
a
chance
and
people
I
mean
there
are
successes
in
that.
Aren't
there,
because
mpls
is
awkwardly
doing
that
that
the
businesses
are
prepared
to
find
different
different
services
and
you
manage
into
them.
J
I
guess
I'm
not
sure
I'll
see
what
the
real
difference
will
be
between
the
routing
paths,
except
possibly,
if
you're
doing
doing
some
additional
processing
on
route.
You
know
sort
of
computing
stuff
on
route
and
then
maybe
there's
any
you
know
some
routers
will
have
some
types
of
processing
there,
which
others
don't
or
a
particular
server
that
you
need
to
get
to
because
that's
got
the
data
needed
or
something.
J
G
G
J
I
don't
think
I'm
the
best
person
to
answer
that
because
I
I
can't
say
I've
got
a
detailed
understanding
of
semantic
routing
but
yeah.
It's
definitely
something,
and
I
think
it's
part
because
my
impressionists
are
still
you
know
lots
of
different
options
for
how
people
think
it
might
be
done.
But
it
was.
J
E
D
M
M
A
E
Yeah,
I
think
greg
has
you've
raised
another
point
that
needs
consideration
and
whether
deterministic
networking
covers
all
of
the
bases
for
semantic
routing
or
some
of
them,
and
and
therefore
falls
into
one
of
the
bullets
in
my
presentation
that
I'm
gonna
have
to
rush
through,
which
says
that
we're
seeing
a
lot
of
stovepipe
solutions-
and
maybe
deterministic
networking
is
is-
is
exactly
that.
It's
a
slice
of
the
problem
space.
E
So
that
that
really
applies
to
both
the
routing
and
the
forwarding,
some
encapsulation
techniques
for
extensibility
can
actually
grow
quite
large,
and
if
you
have
too
much
data
in
the
in
the
packet
header
you're
effectively
paying
a
sell
tax
and
for
some
applications,
maybe
that's
not
a
big
deal.
But
but
it
looks
like
the
applications
that
we're
talking
about
are
probably
sending
smaller
packets,
and
then
this
does
become
an
issue.
E
E
I
think
semantic
routing
makes
the
whole
behavior
of
the
network
much
more
complicated
and
harder
to
predict,
so
we
might
need
more
and
better
oam,
but
if
semantic
routing
is
dynamic
and
adapting
to
changes
in
the
network,
the
packet
tracing
may
not
be
particularly
good
at
telling
us
where
our
next
package
is
going
to
go.
Given
how
the
last
packet
went.
E
E
Semantic
routing
may
well
be
increasing
the
attack
surface,
so
that
needs
to
be
looked
at
and
obviously
a
fragile
network
is
a
more
easily
attacked
network,
but
privacy
has
had
a
lot
of
attention
and
linda
asked
in
in
one
of
her
questions
about
what
information
goes
in
the
packet.
Does
it
identify
the
user
and
the
application
they're
running
and
and
so
on,
and
I
think
this
is
essential.
It
must
not
be
possible
to
determine
a
user's
identity
through
semantic
routing.
E
So
to
do
this,
there
must
be
no
trade-off
between
the
information
needed
to
root
and
forward
and
the
achieving
of
privacy.
So
so
we
have
to
do
both
and
finally,
my
question
is
what
to
do
with
this
I'd
like
to
take
these
questions
forward
into
the
discussion
of
what
semantic
routing
is
and
and
what
it
might
achieve.
A
M
E
E
So
it's
it's!
It's
forwarding,
based
on
information.
That's
in
the
packet
as
dad
and
dan
had
in
on
on
his
slides
are
all
forwarding
is
semantic
forwarding,
but
the
proposal
is
that
additional
information
can
be
put
in
there
as
well
to
accompany
the
fields
that
are
there
at
the
moment,
which
includes
the
destination
and
routing
can
program
the
forwarding
plane
to
achieve
forwarding
based
on
lookups
on
that
information.
E
B
Sorry
now
I
see
the
controls
down
there
of
the
for
for
semantic
readiness.
Daniel
pointed
out,
you
know,
maybe
calling
the
semantic
networking
would
have
been
a
better
thing
to
start
with.
What
are
the
questions
from
a
architecture
perspective
that
that
I
think
we
should
be
asking?
Well,
one
is
what
are
the
communication
semantics
that
we're
aiming
at?
What's
the
type
of
communication,
we
want
to
see
the
network
to
be
doing
that
semantic
routing
automatic
networking
could
really
realize
what
are
the
from
an
architecture
perspective?
B
What
are
the
abstractions
that
we're
looking
at
that?
You
know
this
this,
this
spotting
work
should
have
and
how
could
an
architecture
look
like?
What
are
you
know,
components
involved
how
what
are
the
main
interactions,
but
also,
how
does
it
connect
to
other
aspects
that
we
already
know
are
ongoing,
and
I
would
show
this
in
a
slide
later,
which
is
the
now
unanimous
unanimated
slide
that
I
was
talking
about
a
couple
of
words
on
deployment.
What
to
consider
when
we
want
to
deploy
ideas?
B
B
Okay,
so
if
you
look
at
the
original
purpose
of
the
routing
system,
we
was
originally
designed
to
you
know:
forward
ip
packets
toward
towards
destination
addresses
in
the
best
of
the
manner
worked
really
well.
We
used
location,
locator
semantic
of
ip
addresses
as
a
fundamental
piece
to
achieve
that
ip
addresses
are
signed
in
the
context
of
network
topologies.
That
allows
you
to
build
a
from
a
particular
scalability
perspective,
tractable
system
to
achieve
that
functionality.
B
It's
a
distributed
decision
making
and
intermediary
routers
and
key
here
are
the
methods
to
select
the
path
and
the
criteria
for
doing
so.
Traffic
engineering
may
improve
on
just
best
effort.
I
mean
you
may
introduce
policy
based
path,
steering
you
know,
resource
reservation
and
other
thing
you
know
to
that.
We've
discussed
already
in
the
previous
slides
that
hasn't
evolved
that
that
system
has
evolved
to
a
system
that
actually
supports
a
very
rich
communication
set
of
communication.
Semantics.
B
Not
just
one
beyond
the
best
effort
which
ability
that
I
outlined
before
and
and
I'm
not
trying
to
categorize
them
this
this.
This
is
our
first
attempt
that
we've
done
in
in
some
joint
work,
unicast
communication,
various
semantics
for
multicast
and
group-based
diffusion-based
multicast,
which
you
find
very
often
in,
for
instance,
consensus
systems
where
we're
not
the
entire
group,
but
a
subset
in
a
diffusional
being
addressed.
B
The
actual
endpoint
out
of
your
end
cast
group
and
and
on
the
left
side,
you
see
who's,
making
the
selection
either
the
source
or
the
network,
and
we
also
included
chain
cast
here
as
a
as
a
programmed
forwarding
of
packets
to
the
network,
either
pop
or
in
a
programmed
manner
again,
either
the
selection
being
done
at
the
source
of
the
network.
You
can
see
the
communication
symmetry,
so
you
can
find
examples
of
those.
B
I
presented
a
draft
in
the
routing
working
group
in
the
last
itf
on
routing
beyond
reachability,
which
lists
rfcs
ongoing
trials,
a
bit
of
research
work,
but
mainly
engineering
work
that
supports
these
various
semantics
in
a
a
very
wide
set
of
solutions.
So
this
is
not
something.
That's
that's
being
entirely
drawn
up
new.
So
if
you
go,
what
are
the
abstractions
that
we
then
maybe
want
here
from
an
architecture?
B
In
the
meantime,
we
had
an
interjection
back
in
1996.
He
he
listed
this
in
a
recent
exercise
as
a
historical
hawking
back
into
active
networking,
where
the
attempt
was
to
change
the
abstraction
from,
in
addition
to
the
ip
address,
to
provide
a
programmable
unit,
the
so-called
capsule
and
those
of
you
who
may
remember
the
original
paper
of
1996.
Well,
it
would
come
like
nowhere.
Also,
the
initiative
in
the
end
went
to
the
capsule,
unfortunately
never
took
off
as
a
as
an
abstraction
module.
B
What
we
look
at
here
is
a
semantic
header
in
addition
to
the
packet
header,
that
explicitly
describes
and
evolves
from
the
current
ip
evolved
ip
routing
by
by
grouping
the
suitable
input
into
the
programming
programmatic,
forwarding
actions
in
a
dedicated
semantic
header.
The
the
forwarding
actions
are
deployed
at
the
traversing
notes
and
it's
a
defined
place
for
the
forwarding
information
to
be
placed
instead
of
opening
the
entire
packet
header
blindly
it
is,
it
is
explicitly
captured
in
a
semantic
header.
B
So
how
could
an
architecture
look
like
and
again?
This
is
the
non-animated
slide,
which
is
why
it
looks
a
little
bit
a
lot
to
take
in
when
you
stare
at
it
at
once.
In
the
animated
note,
it
would
have
built
up
really
nicely,
but
for
that
I
needed
a
screen
share,
which
I
didn't
there
after
the
previous
attempts.
So
let
me
walk
this,
maybe
through
on
on
on
the
top
left,
so
this
connects.
B
Events
to
provide
both
constraints
and
matrix
to
the
routing
to
the
semantic
routing
part
and
forwarding
action
suitable
forwarding
actions
to
the
semantic
forwarding
part.
As
daniel
mentioned
before.
These
two
things
have
to
be
seen
in
conjunction
somatic
routing,
provides
potential
additional
path,
information
to
the
semantic
forwarding,
which
can
then
use
the
instructions
to
install
and
configure
forwarding
actions
in
the
underlying
switches
and
routers
of
the
network
nodes
network,
topology
capabilities
states.
B
They
are
being
obtained
in
the
process
for
the
routing
as
well,
and
the
orchestration
and
the
information
is
being
disseminated
too,
but
also
being
accessed
through
the
infrastructure
links
from
the
from
the
netherlands
capabilities
and
state
component
down
to
the
network
parts.
This
is
a
very
high
level
way
of
how
you
could
look
at
the
interaction
of
the
various
components
and
a
lot
of
more
is
required
to
dive
down
into
what
the
individual
bits
and
pieces
are
doing,
but
at
a
very
high
level.
B
You
may
use
extension
headers
instead
of
messing
with
ip
addresses,
so
that
kicks
you
towards
a
shim
overlay,
a
layer
3.5,
as
it's
very
often
called
you
may
work
with
an
underlay
which
then
pushes
you
towards
segregating
the
existing
address
space
with
the
new
semantics.
There
are
examples
that
have
done
that
in
in
the
past.
It
may
have
a
routing
protocol
impact,
and
I
know
there
are
a
lot
of
people
that
are
very,
very,
very,
very
conscious
about
impacts
on
the
routing
protocol.
B
B
Is
it
a
limited
domain
technology
or
the
mighty
domain?
Then
also
example
talked
a
lot
about
solutions
that
have
been
for
a
very
long
time
being
entirely
isolated.
That's
okay!
But
how
do
you
ensure,
if
you
come
to
the
point
not
only
to
wanting
to
use
the
the
multiplexing
of
the
technology
choices,
maybe
namely
introducing,
for
instance,
ip
technologies
in
your
limited
domain,
because
it's
a
well-established
technology,
but
you
want
to
interconnect.
How
do
you
ensure
the
interconnection
now
that
the
interconnection
has
been
brought
on
the
table?
B
The
number
of
industries
that
are
industries
that
are
currently
struggling
with
that
this
industrial
networking
or
vehicular
communication,
where
interconnection
has
come
increasingly
into
into
into
focus
from
the
previously
very,
very
isolated,
limited
domains?
How
do
you
avoid
spilling
your
potential
domain,
limited
semantics
into
other
domains?
B
I
can
tell
you
and
either
anecdote
in
the
chat,
maybe
later
on
how
somebody
at
siemens
tried
to
solve
service
multiplexing
and
has
apparently
never
heard
of
ip
addresses
and
ports,
and
that's
that's
one
way
of
how
you
should
not
do
that,
because
it
will
not
look
very
nice
if
that
packet
comes
out
on
the
other
side
of
the
network,
but
that's
an
actual
proposed
solution
of
vehicular
communication.
Unfortunately,
how
do
you
deliver
new
services?
B
Is
there
any
programmatic
way
of
doing
this?
The
idea
of
the
architecture
than
before
is
that
programmability
is
a
very,
very
key
part
of
making
semantic
networking
really
work
in
the
future
that
allows
to
roll
out
a
lot
of
these
semantic
enhancements
programmatically
through
the
interaction
with
a
higher
level,
intent
based
systems
how
to
manage
networks
and
the
increasing
complexity.
B
Is
it
possible
to
move
towards
this
programmatic
execution,
and
the
answer
to
those
questions
may
also
be
trivial.
Economic
incentives
again,
roll
out,
speed
and
scope
could
be
one
aspect
that
again
may
kick
you
to
an
offering
on
top
of
ipv6,
because
it's
faster
to
roll
out
removing
the
burden
to
change
the
underlay.
That's
a
very
strong
economic
incentive
for
many
service
providers
and
the
stability
of
course,
of
not
only
services.
B
B
What
is
it?
What
are
possible
aspects
personalization?
Why
should
we
care
about
this?
An
architectural
framework?
I
believe
the
in
particular
an
extensible
architectural
framework
on
components
were
the
interfaces
inter
interaction,
diving
deeper
than
the
previous
slide,
that
I
showed
these
interactions
need
to
be
interoperable.
B
I
need
to
know
how
the
communication,
how
the
protocols,
how
they
look,
what
are
the
semantics,
not
use
cases
but
the
purpose
of
communication
right
and
we
can
map
them
quite
easily
on
a
variety
of
use
cases
later
on,
possibly
captured
as
a
service
description
to
enable
programmatic,
realization,
there's
a
lot.
We
could
potentially
learn
from
fields
like
the
semantic
web
that
has
done
a
lot
of
this
type
of
service
description
onto
service
mapping,
type
of
approaches.
B
What
are
the
abstractions
so
involving
addressing
as
the
main
input
into
actions
and
com,
and
you
find
the
encodings
and
encapsulations
and
the
actions
the
state
distributions.
That's
you
know
also
known
as
routing
protocols
and
the
primitives
that
we
need.
Thank
you
very
much.
That
was
it
for
my
excitement.
E
E
So
first
up
is
suresh.
I
wanna
thank
suresh.
He
he
got
landed
with
this
in
in
a
bit
less
than
24
hours
notice
and
owing
to
some
confusion,
he
didn't
realize
that
he
was
actually
expected
to
present
anything
until
about
two
hours
ago,
but
he
has
come
up
trump's
and
got
a
set
of
slides
here,
and
I
will
I'm
sure,
talk
brilliantly
thanks.
Suresh.
O
So
I
just
like
we'll
go
through
pretty
quickly
with
the
srv
central.
You
know
we
are
running
over
time,
so
I'll
try
to
make
this
extremely
quick.
Just
to
like
you
know,
go
back
to
what
daniel
said
and
and
adrian
said
in
the
presentations
right
so
like
what
we're
trying
to
do
with
srv6
is
to
augment
the
packet
with
additional
information
on
how
the
packet
is
going
to
get
processed
in
the
network
right.
O
So
I'm
just
going
to
skip
through
quite
a
bit
of
the
background,
slides
on
what
srs
right,
but
to
just
talk
about
two
data
plane
instantiations,
like
one
of
them,
is
like
srm
pls
right,
which
is
like
a
regular
encapsulation
of
the
segment
ordering
concept
over
the
mpls
networks
and
the
other
one
is
the.
What
we
call
srv6,
which
is
the
instantiation
of
sr
over
ipv6,
and
the
specific
thing
I
wanted
to
talk
about
today
is
srv6
network
programming
which
uses
like
ipv6.
O
O
So
so
the
network
program
is
pretty
much
like
a
set
of
srv6
sets
and
it's
got
like
you
know,
list
of
like
locators
and
functions
right.
The
packet
needs
to
pass
through.
So
what
you
do
is
you
augment
the
ipv6
packet
with
this
information
when
the
packet
enters
like
an
sr
domain,
and
that
provides
what
would
you
call
like
a
network
program
for
the
network
to
treat
that
package,
so
you
put
in
like
a
whole
bunch
of
things
in
a
list
that
needs
to
get
done
and
the
packet
goes
through.
The
network.
O
Take
the
next
address
sitting
in
here
or
the
next
sitting
in
here
and
put
it
in
the
destination
address
field
of
the
packet
right
and
and
so
pretty
much
the
you
just
run
through
the
program
like
every
node
that
gets
the
back.
It
runs
through
the
program
and
at
the
end
of
it,
the
the
packet
can
leave
the
sr
domain
and
and
the
nodes
outside
the
domain
are
non-divisor.
O
And
we
also
have
a
tag
field
in
the
sr
which
allows
you
to
kind
of
group
packets
right.
So
if
you
have
a
set
of
packets
which
have
to
receive
a
similar
kind
of,
I
would
say
like
like
quas,
for
lack
of
a
better
term.
Right,
like
you
know,
like
phil,
was
talking
about
before.
So
what
you
do
is
you
tag
them
in
a
similar
way?
O
So
if
you
have
the
same
tag,
the
packets
can
get
treated
like
similarly
going
forward
so
think
of
it
as
some
kind
of
metadata
field,
and
so
we
also
have
like
a
metadata
tlb
that
can
like
kind
of
be
augmented,
and
this
is
really
intended
for
kind
of
a
software-based
solution.
Right,
like
that,
we
have
like
nfe
and
all
those
things
use
stuff
like
in
a
very
extensible
way.
O
O
So
if
you
look
at
the
sr
itself
right
like
so
the
the
I
would
say
the
earlier
bits
right,
like
you
know,
the
the
higher
order
bits
in
the
sr
header
are
optimized
for
hardware
processing.
So
we
here
there's
like
a
cisco
silicon.
One
chip
that's
shown
here
but,
like
you
know,
we
have
implementations
on
like
you
know,
for
example,
the
intel
barefoot
to
phenoches
and
so
on
and
and
other
fpgas
as
well.
So
you
can.
O
It
stays
unmodified
when
it
leaves
the
domain.
So
this
is
really
something
that
the
behaviors
are
specified
inside
an
sr
domain,
and-
and
that's
like
that's,
why
we
add
an
additional
header
put
in
the
additional
stuff,
like
it's
really
about
handling
information
in
a
domain
that
understands
these
behaviors
and,
like
so
there's
like
a
set
of
behaviors
that
defined
by
the
srv6
network
programming.
There's
like
an
ioni
registry
that
talks
about.
O
Like
you
know
what,
like
you
know,
numerical
value
is
like
assigned
to
each
of
these
behaviors,
but
some
of
the
behaviors
are,
like
you
know
the
the
defaulting
point
behavior,
which
is
like
you
know,
assign
the
value
zero
it
just
like
takes
the
shutter's
path
to
the
sets
endpoint
right.
It's
just
like
updates
it
just
like
processes
the
packet
and
puts
the
next
set
into
the
destination
address
and
just
forwards.
O
The
packet
right
like
using
regular
forwarding
mechanisms
and
the
cross
connect,
is
pretty
much
using
like
an
igb
adjacency
to
send
a
packet
to
like
a
different
node,
that's
connected
to
the
node
that
is
sitting
in
the
the
sid
itself.
So
if
you
have,
I
just
have
a
picture
here.
So
if
you
look
at
it
right
like
so,
if
you
look
at
the
green
path
right,
it
takes
the
shortest
path.
O
To
like
you
know
the
set
of
things
that
we
need
to
do
right.
So
so
I
I
like
quote
from
memory
right.
It's
really
about
you
know
determining
the
next
offer.
Each
packet,
given
the
network
setting
capability,
that's
coming
from
really
from
the
igp,
and
we
do
the
packet
marking
like
you
know.
We
can
talk
about
like
you
know
how
the
packet
is
going
to
get
treated
and
like
also
the
following
information.
O
E
O
So
the
tag
is
really
about
like
group
policy
right
like
so
what
you're
trying
to
say
is
like
hey
this
packet,
like
kind
of
wants
to
get
treated
like
other
packets
right,
that's
kind
of
what
the
tag
is
really
specifying
right.
The
function
is
separate
like
exactly
like
you
said,
but
the
tag
is
really
about
like
specifying
similar
groups
of
packets
to
get
treated.
So,
let's
think
of
it
as
a
shotgun.
L
Yeah
thanks
forest
for
presenting
this,
like,
I
have
a
kind
of
a
quick
understanding
questions
like
what
you
just
presented
like
it
felt
like
a
pretty
much
towards
the
srv6,
which
you
know
about
that:
a
service
segment
routing,
I'm
just
curious
like
where
the
key
difference
maker
or
the
how
the
semantic
routing
is
coming
like.
Is
there
any
slide?
O
Yeah
you're
right
so
this
is
this
is
really
like
a
tool
kit
right
like
so.
The
the
semantic
routing
is
something
we
can
build
using
this.
So
I
think,
like
adrian
talked
about,
like
you
know
not
like
you
know,
doing
like
something
revolutionary
and
and
work
on
evolutionary
things
right,
so
we're
talking
about
like
some
kind
of
tools
that
we
can
use
to
leverage
to
build
semantic
routing.
So
this
is
like
one
such
tool
right
like,
and
I
think
like
stefano
is
going
to
present
another
one.
O
So
what
you're
talking
about
is,
like
you
know,
taking
existing
networks
and
how
can
we
build
things
on
top
to
enable
semantic
routing
so
like
just
like
a
bunch
of,
as
I
said,
there's
a
bunch
of
behaviors
that
defined
in
srv6
and
in
np?
So
if
there's
like
stuff,
that's
missing,
we
can
certainly
go
ahead
and
define
them,
but
I
think
it's
like
a
fairly
feature
rich
solution
today.
So
if
there's
like,
we
realize
there's
something
that's
missing.
We
can
certainly
go
and
add
like
additional
behaviors
on
there.
L
E
K
I
think,
like
I
look
at
the
srv6
you're
using
example
here,
what's
the
first
presentation
by
by
daniel
about
some
requirement
for
a
second
writing,
one
thing
is
like
not
for
overlay
guys,
because
not
not
by
hop
so
there's
one
thing
in
that
slide
here.
I
look
at
your
thing
since
you
use
some
domain
and
then
use
ingress
egress
with
something
between
to
me
like
you
are
using
some
counter
examples
say:
oh
yeah,
this
is
yeah,
something
like
this.
This
is
like
overly.
K
E
N
N
So
referring
to
previous
presentation,
where
I
think
adrian
mentioned
that
we
should
try
to
find
some
solution
which
is
general
and
extensible,
so
we
are
trying
to
to
do
something
in
this
in
this
line.
So
the
the
idea
is
that
ipv6
and
system
and
network
nodes
can
read
and
write
these
extensible
information
in
in
packet,
headers
and,
of
course,
nodes
can
take
a
packet
processing
decision
depending
on
this
eip
information.
N
So
as
shown
here
that
there
are
different
use
cases
that
can
be
supported,
so
semantic
routing
is
one
of
these
another
one
which
we
are
already
trying
to
make.
Some
experiments
is
a
advanced
monitoring.
So
a
mechanism
to
to
capture
molecular
information
in
in
networks
and
distribute
it
in
putting
information
in
packet
headers
also
deterministic.
Networking
is
another
use
case
that
may
benefit
from
this
eip
network
slicing
and
so
on.
So
the
idea
we
will
define
an
eip
header
and
in
turn
we
want
to
carry
this
ip
header
in
into
the
ipv6
header.
N
Where
do
we
carry
in
the
ipv6
center
either
we
can
carry
it
in
a
hop
biop
option
or
we
can
also
carry
it
in
segments
rooting
either
tlb.
So
I
can
also
refer
to
previous
presentation
by
by
suresh.
So
also,
this
mechanism
is
compatible
with
segment
routing
and
it
can
also
be
used
to
to
extend
segment
routing
to
add
some
missing
bits
because,
as
should
have
mentioned,
also
segment
routing
for
ipv6
is
meant
to
be
extendable,
and
so
we
can
put
the
extension
in
the
in
the
srv.
H
N
N
N
N
But
I
think
that
if
we
go
for
a
different
hold
by
up
option
for
every
use
case,
I
mean
the
solution
does
not
scale.
So
we
are
trying
to
make
a
more
general
approach
to
have
a
a
a
single
hop
by
your
option.
That
then,
can
be
extended
farther
with
different
use
cases,
and
so
we
believe
that
there
are
good
reason
for
having
a
single
eip
header
that
can
be,
as
I
discussed,
either
a
notebook
option
or
a
tlb
inside
the
srh
header.
N
If
you
want
to
extend
the
segment
rooting
for
s7c
for
ipv6,
and
but
it
is
good
to
have
this
common
erp
header
and
inside
this,
we
can
put
the
eip
information
elements
that
can
support
different
use
cases.
Okay,
this
is
one
reason
is
that
the
number
of
option
types
in
all
biopedal
is
very
limited,
so
there
are
eight
bits,
but
then
three
of
them
are
used
for
defining.
They
have
a
specific
semantic.
N
So,
basically,
for
in
some
cases
you
have
only
32
options
to
to
define,
while
with
the
with
our
eap
information
element,
we
have
a
code
point
space
of
up
to
24
bits,
so
we
have
millions
60
millions
of
different
information
elements
that
we
can
define,
and
so
there
is
no
pressure.
Let's
say
on
the
under
standardization,
and
also
another
interesting
thing
is
that
common
information
elements
can
be
reused
across
use
cases,
so
it
makes
sense
to
have
one
single
header,
then
different
information
elements,
and
some
of
them
are
reused
across
different
use
cases.
N
So,
of
course,
we
will
need
to
define
a
different
information
element
depending
on
the
specific
use
case
that
we
want
to
support.
But
some
of
them
like
time,
stamping
or
authentication
they
will
be
sharing.
So
we
will.
We
can
create
a
library
of
common
protocol
components
or
common
information
elements
that
can
support
multiple
use
cases,
and
we
have
started
to
do
this
in
in
the
in
the
document
that
I
mentioned
before
a
quick
discussion
on
applicability
and
scope.
A
N
So
here
I
repeat
the
the
draft:
no,
this
is
not
the
aitf
draft.
This
is
still
a
public
document
not
not
published
as
a
draft
in
which
you
will
find
the
definition
of
this
aip
header
and
a
definition
of
a
set
of
information
elements
that
are
carried
inside
this
ap
information
element
and
so
coming
to
the
specific
topic
of
semantic
routing.
N
Of
the
communication,
so,
of
course
the
source
can
use
it
to
advertise
his
geographic
position
and
other
nodes
can
use
the,
for
example,
the
advertised
location
to
to
use
it
in
a
routing
things,
for
example,
to
the
the
situation
in
which
you
have
leo
satellites
that
are
covering
the
the
world.
So
in
that
case,
maybe
you
need
to,
if
you
know
the
the
the
the
geographical
coordinates
you
can
use
this
information
to
root
an
ipv6
targets
in
your
network
of
leo
satellites.
N
No,
so
here
we
have
the
details
on
how
we
can
encode
the
information
in
our
information
elements.
So
we
have
a
solution
where
we
encode
the
coordinates
in
32
bits
and
we
have
a
precision
in
the
order
of
millimeters
or
you
can
use
16
bits
for
latitude
and
longitude
and
you
have
precision
in
the
order
of
hundreds
of
meters.
So
these
are
all
interesting
things
that
you
can
do
when
you
have
a
platform
for
doing
experiments.
N
It's
a
prototype
that
is
built
for
for
linux
and
we
have
two
main
components:
we
have
a
packet
generator
and
the
detector,
so
we
can
write
our
eip
header
and
we
can
put
this
erp
editor
in
inside
the
hop
biop
header
or
segment
root
in
tlb,
and
then
we
have
an
eip,
our
router,
that
is
based
on
ebpf
and
can
take
these
information
elements
and
can
take
a
processing
decision
rooting
decision
based
on
on
the
information.
So
we
are
implementing
this
semantic
routing,
in
particular
the
geoducking
use
case.
N
With
this
prototypes
and
also
we
are
implementing
advanced
monitoring.
So
we
have
a
solution
for
end-to-end
delay,
monitoring
in
band,
so
adding
information
in
ap
packets
to
monitor
end-to-end
delay
and
another
solution
for
path
tracing,
so
taking
recording
the
path
that
a
packet
is
is
taking
putting
this
information
in
our
eip
header.
N
N
Generating
your
packets
and
then
processing
in
a
couple
of
intermediate
routers,
we
have
set
up
an
informal
interest
group
on
on
this
topic,
so
here
you
can
find
the
link
and
you're
welcome
to
to
join,
and
you
will
find
all
the
information
about
the
the
prototype.
Also
in
this
link
here,
you
find
some
reference,
so
we
have
recently
we
will
have
a
paper
in
the
in
the
workshop
that
also
daniel
mentioned.
N
M
N
N
M
N
M
N
Yeah
yeah,
I
think
that
in
in
the
case
of
monitoring,
I
think
that
there
are
advantages
in
some
cases
in
collecting
the
information
and
sharing
the
information
directly
on
the
data
plane.
So
if
you
are
building
a
new
router
which
is
optimized
for
doing
this
information,
I
have
the
feeling
that
is
more
efficient
to
do
to
do
some
operation
in
the
data
plane,
rather
than
exporting
information
in
the
management
plane
and
processing
this
in
the
management
plane.
N
So
if
you
need,
for
example,
make
that's
good
to
do
and
also
you
you,
there
are
some
situations
in
which
you
can,
for
example,
calculate
some
sketches
some
reduced
information
in
your
data
plane
and
inserting
this
information
directly
in
the
packet
can
be
more
efficient.
But,
of
course
this
is,
I
think,
an
open
research
topic
at
the
moment.
Yeah.
N
So
I'm
also
putting
the
question
if
it
is,
I
think
it's
the
right
time
also
to
make
something
which
is
a
little
bit
more
general,
because
with
t2
oim
you
can
do
just
the
monitoring
okay,
but
there
are
different
other
use
cases
in
which
you
can
also
read.
You
can
also
write.
You
can
also
take
decision
based
on
the
information
that
is
inside.
N
N
M
M
And
you
don't
have
to
create
a
new
header
for
that
another
advantage
of
iam
is
it
supports
out
of
band
collection
of
telemetry
information
and
it
could
be
either
iem
direct
expert
or,
for
example,
hybrid,
two
step
and
hybrid
two-step
advantage?
Is
that
it's
not
only
keeps
the
overhead
of
the
data
packet
limited
by
not
adding
data
in
the
packet,
but
it
simplifies
the
correlation
of
data,
because
data
are
collected
on
the
same
path
as
the
trigger
packet
in
one
in
a
train
of
packets.
So.
M
M
E
E
E
E
K
Yes
checking
here
well,
I
want
to
volunteer
some
information
regarding
the
first
presentation
on
the
what
is
driving
the
secondary
the
slide.
It
used
some
examples,
especially
emphasize
the
5g
related
semi
video
streaming,
the
5g
health
healthcare
vr
ar
holographic
those
type
of
things.
But
the
thing
is
like
for
these
things:
it's
normally
comprised
of
multi-modality
communications
like
a
video,
audio,
haptic
or
all
kind
of
information
that
requires
synchronization
among
different
strips,
so
one
information
that
has
been
discussed
just
in
the
finish
the
3gpp
discussion
for
the
xrm.
P
P
My
current
understanding
of
semantic
routing
is
to
still
utilize
ap
addresses,
but
putting
some
so-called
semantic,
meaning
into
it.
What
whose
semantic
is
that
that's
a
question?
It's
it's
the
semantic
of
the
applications,
the
semantic
of
the
contents,
and
I
think
it
is
really
getting
to
a
change
of
architecture
if
your
semantic
departs
from
ip
address
semantics.
P
That's
is
not
about
the
details,
whether
you
do
point
solution,
you
do
some
something
else.
It's
not
about.
You
can't
make
an
implementation
that
works
in
small
scale.
This
is
really
about
what
semantics
we
are
talking
here
and
if
that
semantics
is
not
topological
semantics,
then
then
it
really
represents
architectural
change.
E
Yeah,
I
think
I
think
you
nail
it
there
and
and
to
take
this
forward,
does
require
identifying,
what's
trying
to
be
achieved
and
therefore,
what
needs
to
be
expressed
in
the
packet
as
a
semantic
and
then
whether
that
goes
by
overloading
the
address
field
or
by
being
placed
somewhere
else
to.
If
you
like,
enhance
the
address
field.
P
Q
It
is
very
quickly
only
to
comment
that
the
yeah
actually
the
the
interest
on
this
that
could
help
help
the
applications
to
I
mean,
have
the
deliberate
information
to
have
some
contextual
information
that
could
help
to
optimize
the
deliberation
information
from
applications.
So
I
think
the
interest
on
that-
and
I
would
like
just
to
to
remark
that,
because
one
of
the
balance
that
you
put
there
is,
if
the
are
there,
applications
imminent
to
use
this,
probably
those
that
could
require
context
will
be
the
ones
requiring
this
kind
of
information.
D
D
We
know
it
doesn't
always
work.
Doing
everything
in
data
plane
has
huge
cost
associated
with
it
from
forklift
upgrades
to
very
low
success
rate,
as
said
rightly
so,
finding
way
in
between
probably
would
be
right
place
to
use,
and
I
can
tell
you
from
actual
implementation
perspective,
there's
a
lot
of
work
going
on.
It's
not
published
in
atf,
where
the
semantics
are
flattened,
otherwise,
there's
no
way
to
put
reasonable,
simple
device.
D
E
D
So
now,
with
a
chair
head
on,
we
are
going
to
work
with
engine
and
our
ids
on
trying
to
assess
what
has
been
presented
and
what
could
potentially
be
the
next
steps
adrian
and
supporters.
On
your
side,
please
work
on
coherent
proposal
of
how
you
perceive
the
presentation,
the
interest
and
the
potential
next
steps.
Please
talk
to
us.