►
From YouTube: IETF111-DETNET-20210730-2130
Description
DETNET meeting session at IETF111
2021/07/30 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
Okay,
it's
time
to
get
started,
welcome
everyone.
This
is
a
meeting
a
session
of
the
death
networking
group
as
part
of
the
online
ietf
111.
lou,
berger
and
myself.
Janusz
farkas
are
co-chairing
the
working
group
and
we
have
our
secretary
here
ethan
grossman,
who
takes
the
lead
on
immediate
taking
and
does
a
really
good
job,
many
thanksgiving
for
that
we
have
the
all
the
material
at
the
usual
place.
You
can
see
it
on
on
the
screen
and
also
the
working
group
information
as
a
part
of
an
ietf
meeting.
A
We
follow
itf
rules
and
procedures
and
by
participating,
you
accept
to
agree
to
follow
these
process
and
policies
and
just
to
remind
you
that
this
session
will
become
the
part
of
the
permanent
record
of
itf
and
by
participating.
A
A
Lou
has
already
provided
the
link
in
the
chat
window
as
well,
so
please
join
the
mini,
taking
and
and
help
the
joint
effort,
and
this
is
the
the
death
net
session
friday,
where
we
are,
and
we
already
had
a
joint
session
with
the
pass
and
the
mpls
working
group
on
tuesday,
where
the
main
scope
is,
is
the
evolution
of
mpls
and
does
not
leverage
the
amperas
data
plane
as
well.
So
we
are
taking
part
in
that
effort
as
well.
A
So
this
is
our
agenda
for
today.
I
know
it's
an
eye
chart.
It
is
available
in
the
usual
place,
as
I
mentioned,
so
you
can
check
it
and
read
it
more
in
detail
there.
A
A
So
I
would
like
to
ask
each
presenter
to
stick
the
to
that
time
plan
which
was
provided
in
advance.
I
would
like
to
thank
to
the
great
presentations
and
then
very
nice
charts
in
in
many
of
those
it's
really
good
to
have
them
available,
but
given
the
short
time,
I
suggest
to
to
make
your
points
and
and
and
the
gist
of
your
your
presentation,
given
the
situation
where
we
are,
I
will
come
back
to
a
potential
interim
in
a
later
slide.
A
We
have
a
couple
of
rfcs
published
since
the
previous
itf.
This
is
really
good
news
with
that.
This
is
the
security
rfc
and
and
the
rest
of
the
data
plane
rfcs,
except
for
one
when
it
comes
to
the
data
plane.
The
ipo
mprs
is,
with
with
the
rfc
editor
to
be
published
very
soon,
and
the
one
following
it
is
the
bounded
latency,
which
is
heading
up
for
isg
review,
iot
telechat.
A
We
have
the
yang
in
a
status
that
is
a
post
working
group.
Last
call
the
contributors.
Authors
are
making
a
really
great
effort
in
addressing
the
comments
received
during
the
last
call,
and
we
expect
to
have
a
new
revision
uploaded
soon.
One
of
the
working
group
documents
is
not
on
the
agenda:
the
control
airplane.
A
There
was
no
request
for
that.
This
time
we
just
got
an
incoming
liaison
like
a
few
days
ago
from
itu-t
study
group
13.,
the
title
is
work
items
related
to
deterministic
communication.
A
A
Some
part
from
the
liaison
letter
is
is
copied
here.
This
incoming
liaison
is
for
information.
That
is
no
specific
response
is
requested,
but
I
would
suggest
to
to
review
and
check
offline.
I
mean
it
looks
really
interesting
and
it's
up
to
the
working
group
to
decide
whether
or
not
to
respond.
We
can
send
an
unsolitary
response
and
we
can
develop
such
a
response
if
the
group
decides
to
do
so
on
the
list.
A
I
would
like
to
remind
people
of
the
ipr
procedures
here.
Early
notifications
on
ipr
is
encouraged
and
welcome.
We
have
two
checks:
checkpoints
for
ipr
call
when
a
document
gets
adopted
by
the
working
group
and
actually
during
working
group,
last
call
as
well
as
for
this
working
group.
We
introduced
another
step
that
we
ask
an
author
to
to
make
a
declaration
then
joins
becomes
a
new
author
in
an
already
working
group
document.
A
We
have
been
working
remote,
as
all
of
us
know.
We
would
like
to
to
mention
and
keep
mentioning
to
use
the
mailing
list.
That's
that's
half,
for
let's
put
it
this
way
and
when
it
comes
to
virtual
meetings,
we
can
schedule
meetings
as
needed.
A
We
can
schedule
interim
meetings
and
inform
our
working
meetings
as
well.
We
have
been
using
that
format
for
a
while
for
data
plane
for
yang
and,
most
recently,
for
oem.
You
will
hear
about
that.
I
expect
to
continue
the
oem
dc
for
my
working
meetings
and
potentially
the
control
airplane
as
well.
A
There
is
a
highlighted
item
here,
as
I
already
mentioned,
that
reviewing
the
agenda
that
we
think
we
do
and
then
see
it
from
other
people's
thoughts
as
well,
that
the
group
could
benefit
an
interim
meeting,
for
example,
on
the
queuing
topics
to
be
discussed
and
checking
the
vacation
plans
and
stuff
like
that
september
would
be
a
good
month.
The
week
of
6th
of
september
could
be
a
candidate
because
after
that
conferences
and
other
standards,
meetings
gets
started.
A
So
that's
sort
of
an
early
september
6th
of
september
is
a
bank
holiday
in
the
us.
My
friday
is
not
good,
so
our
proposal
is
the
9th
of
september
starting
at
noon.
Utc,
which
is
translates
to
9am
us,
is
turned
to
epm
europe,
which
is
a
hotspot
sweet
spot.
We
know
all
of
us
have
standing
meetings
myself
too
speaking
as
an
individual,
but
I
would
give
a
priority
to
the
single
occurrence.net
interim.
I
see
tallest
in
the
queue
so
tell
us.
Please.
B
That
makes
my
presentation
already
one
slide
shorter:
how
about
a
doodle
for
that
week,
just
to.
A
Yeah,
so
let's
discuss
it
on
the
list
any
further,
just
to
give
people
time
to
meet
my
presentations
and
let's
conclude
this
chairs
intro
with
some
information
or
related
work
on
going.
This
is
just
an
updated
summary
on
the
I
t,
plato,
2.20
centers
group,
some
some
new
works.
Some
works
have
been
finished
since
the
last
update.
A
Some
new
works
have
been
started,
including
base
standards
like
synchronization
and
new
profiles
like
aerospace,
and
another
important
item
is
that
the
tsn
topics
and
other
i8
or
two
topics,
including
all
kinds
of
violin
and
wireless,
like
dot
11.15,
are
coordinated
by
the
ieb
id
plato
to
coordination
team.
There
are
regular
meetings
like
open
meetings
and
documented
here
as
usual,
and
one
more
recent
item
related
to
very
very
closely
to
that
net
is
that
the
avenue
alliance
has
started.
The
study
group,
like
the
group,
has
been
approved.
A
That's
where
we
are,
and
with
that
I
suggest
to
move
on
to
the
next
or
the
third
presenter.
Actually.
A
Let
me
share
which
is
greg.
Yes,
I
will
navigate.
D
A
D
D
Okay,
so
we
had
great
discussions
and
comments
and
much
appreciated
from
balash
and
pascal
and
that
helped
us
to
move
the
document
further
and
thanks
to
janis
for
cheering
out
bi-weekly
calls,
and
that
is
definitely
very
good
and
helpful
to
to
progress
this
work
and,
I
believe,
any
work.
So
so
what
updated?
We
updated
the
terminology
to
do
clarification
of
what
would
be
interpretation
of
that
net.
D
Oem
instance
a
map
in
oem
documents,
and
then
we
paid
the
special
attention
to
the
terms
that
often
used
like
in-band,
oem
and
out-of-band
oem
and
they're,
specifically
for
active
oem,
so
active,
oem,
ads
and
oem
methods
that
you
specifically
constructed
test
packets
that
are
injected
in
the
network.
D
We
cannot
accurately
properly
interpret
their
results.
The
observed
behavior
of
the
test
packet
and
correlated
with
their
behavior
and
treatment
by
the
network
of
the
data
packets
that
flow
being
monitored.
D
But
at
the
same
time
there
are
some
cases
where
out
of
band
oem
packets
can
be
used
to
do
the
measurement
and
collection,
so
the
out
of
band.
I
am
characterized
by
either
not
following
exactly
the
same
path
as
being
traversed
by
the
data
packets
or
not
being
treated
by
the
network
as
a
qis
or
a
packet
replication
duplicate,
elimination
ordering
function
the
same
way
as
their
data
packets,
so
all
both
could
be
so,
for
example,.
D
We
have
a
proposal
under
consideration
in
ippm
working
group
on
collecting
telemetry,
which
may
use
out
of
band
traversing
the
same
packets,
but
using
a
different
qis,
not
a
deathnet
qos,
and
then
the
clarification
for
their
own
path,
telemetry,
because
these
are
methods
that
are
very
useful
and
that's
complementary
to
active
oem
by
all
means,
and
we
have
a
discussion
of
methods
of
collecting
the
telemetry
information
in
the
death
net
and
possible
impacts
of
different
options
on
next
slide.
Please.
D
So
there
are
other
aspects
that
we
paid
attention
and
resulting
from
our
discussions.
Addressing
comments
from
velash
and
pascal
is
map
selection
and
placement,
depending
on
which
sub-layer
of
that
net,
whether
it's
a
forwarding
or
service
what
we
want
to
reuse
and
obviously
by
all
means.
We
want
to
reuse
all
available
tools,
especially
echo
request
reply
like
icmp
or
lspt
for
that
net,
with
mpls
data
plane,
and
then
we
identified
that
for
the
pre-op.
We
need
to
work
on
some
extensions
next
slide.
D
So
again
we
worked
and
discussed
and
did
some
work
on
that
net
oem
requirements.
So
you
can
check
that
in
a
current
version
of
the
document.
D
So
what
we
are
planning
to
do-
and
next
will
be
balash-
will
present
his
work
and
we
already
discussed
it
and
we
agreed
and
want
the
working
group
to
consider
that
part
of
this
document,
individual
document
on
a
service
sub
layer
oem
to
be
integrated
with
the
devnet
oem
framework
document,
which
is
a
working
group
document,
because
it's
a
very
valuable
work
and
it
makes
sense
to
have
it
in
a
single
document.
D
We'll
continue
bi-weekly
discussion.
So
it's
an
open
discussions.
Everybody
is
welcome
and
looking
forward
for
your
comments,
suggestions
and
once
the
document
is
stable,
probably
before
the
next
ietf
meeting
we'll
come
to
the
working
group
for
consideration
of
the
last
call.
Thank
you.
C
Well,
the
next
person
comes
up.
Is
there
any
questions,
janusz
you
want
to
switch
to
the
next
step.
A
Maybe
just
one
point
we
could
make
that,
and
there
are
the
two
other
oem
documents
very
good
documents:
mpls
and
ip,
and
if
we
go
for
working
group
class
call
with
the
framework,
maybe
we
can
hold
it
in
working
past
call
until
the
other
ones
progress
major
enough.
E
E
This
draft
has
been
submitted
as
a
individual
contribution
to
oem
discussion
and,
in
particular,
the
the
main
target
for
that
was
to
kick
off
the
work
group
discussion
on
introducing
oem
for
the
deafness
service,
sub
layer
and,
as
greg
already
mentioned,
this
is
this
was
discussed
and
it
is
planned
that
some
part
of
this
this
draft
can
go
to
other
drafts
and
and
if
the
verb
intends
to
do
so
next
slide,
please.
E
So
the
current
content
of
this
draft
is
about
two
major
topic.
One
is
the
requirements
on
oem
for
the
net
service
sub
player,
discovery
of
that
net
relay
nodes
in
the
net
network,
collecting
that
net
service
sub
layer,
specific
information
from
the
deathnet
relay
nodes,
like
configuration,
operation
status,
information,
and
this
is
also
something
that
should
work
both
for
both
data
place,
both
for
mpls
and
ip.
E
This
is
something
that
we
intend
to
to
update
and
and
put
to
the
oem
framework.
As
like
already
mentioned,
the
other
major
group
of
information
are
related
to
a
so-called
net
ping
functionality.
E
The
main
challenge
for
end-to-end
oem
is
that
the
forwarding
sub
linear
segments
they
are
that
the
death
net
relay
nodes
which
are
providing
the
service
sub.
They
are
functionalities.
E
So
this
this
functionality
is
providing
via
two
type
of
oem
packets,
that
that
echo
request
and
that
net
reply,
packets.
E
The
draft
deals
with
the
various
relay
node
roads,
whether
they
are
originating
or
targeting
or
or
they
are
targeted,
node
from
oem
perspective,
or
they
are
just
simply
intermediate.net
service
sub
layer
nodes
how
they
should
behave,
what
processes
they
should
do
and
the
oem
processing
are
defined
depending
on
the
that
net
relay
node
functionality
from
service
sub
layer
perspective
and
packet
elimination
function
is
highlighted,
because
that
is
the
most
challenging
functionality
from
that
net
service
sub
layer
perspective
next
slide,
please
or
look.
E
Next
slide
yeah,
so
this
is
just
about
a
summary.
We
have
already
discussed
it
on
the
biblically
oem
course,
and
the
next
step
is
that
we
are
looking
for
further
comments
discussions.
E
E
A
Seems
to
be
that
lou
lost
audio.
Maybe
let's
go
to
the
next
one
and
can
come
back.
E
Okay,
this
draft
is
about
to
provide
prior
functionality
for
the
that
net
ip
data
plane
for
many
people.
Looking
to
that
net
data
planes,
the
major
difference
between
the
deathnet
mpls
and
the
netnet
ip
data
plane
is
that
the
type
data
plane
does
not
provide
pre-off
as
it
is
defined.
With
this
simplified
ip
data
plane
and
together
with
the
co-authors,
andrew
mallis
and
and
janos
and
myself,
we
intended
to
show
how
to
provide
prior
functionality
for
the
deafness
ip
data
plane.
Next
slide,
please.
E
So
this
draft
is
a
informational
draft
and
it
is
providing
based
on
rfc
1925,
which
is
the
deathnet
mpls
over
udpip
rfc
had
to
have
to
ensure
prior
functionality
for
ip
next
slide.
Please,
the
goal
of
this
draft
was
to
to
add
the
prior
functionality
with
the
reuse
of
existing
death.
Net
data
plane
functions,
so
we
wanted
to
provide
the
net
service
sub
layer
with
with
minimal
f4,
both
from
standardization
and
also
from
implementation
perspective.
E
This
is
fully
in
line
with
the
death
note
architecture
and
it
is
maintaining
the
net
service
sub
layer
and
that
that
forwarding
sub
layer,
characteristics
and
sequencing
is
provided
in
the
service
sub
layer
and
the
forwarding
sub
layer
can
be
any
routing
function,
so
it
enables
seamless
use
of
existing
routing
techniques
like
segment
routing
like
native
ipv6
and
so
on
next
slide,
please,
the
draft
content
is
described
in
the
basic
concept,
which
is
practically
udp
tunneling
between
the
that
net
relay
nodes
on
the
intermediate
nodes
on
the
net
transit
nodes,
it
is
maintaining
the
type
data
plane
characteristic
with
six
double
bass.net
flow
identification.
E
There
are
also
details
in
the
draft
regarding
encapsulation
packet
processing
how
to
do
flow
aggregation.
What
are
the
pre
of
procedures
in
case
of
ip
and
control
and
management
parameters
are
also
defined
next
slide,
please.
So
this
draft
really
leverage
the
existing
netnet
data
plane
building
blocks.
There
are
no
new
header
fields
specified.
E
It
is
a
generic
ip
solution,
verse
for
both
ipv6
and
ipv4.
It
is
defining
prayeroff
at
the
deathnet
sub
layer
and
any
routing
techniques
can
be
applied.
Underneath
of
of
that
service
sub
layer-
and
it
does
not
require
any
additional
processing
on
the
transit
node,
so
it
is
really
focusing
on
the
net
relay
nodes.
All
the
other
nodes
practically
can
work
as
as
defined
previously.
E
So
we
are
looking
for
comments
and
if
people
are
happy,
we
we
can
also
ask
for
per
group
adoption,
because
this
is
really
based
on
existing
building.
F
Yeah,
so
I
I
made
my
first
series
of
comments
on
this
document.
There
were
a
number
of
questions
which
were
naturally
answered,
and
one
of
them
was
aggregation.
What
happens
is
if,
in
the
middle
of
the
network,
we
want
to
aggregate
the
flows?
E
No,
no,
I
I
will
answer
that
more
detail
with
more
detail
on
the
list,
but
this
is
not
the
case
so
of
the
udp
tunnels.
They
are
terminated
on
the
that
net
relay
nodes
and
that
that
relay
nodes
can
do
aggregation.
G
This
is
aimed
at
informational
rfc
is
that
what's
wanted,
is
an
example
of
how
it
could
be
done,
or
should
this
be
head
of
some
something
like
standards
track
as
a
spec
for
how
for
how
it
should
be
done
for
interoperability.
E
I
I
think
this
is
something
to
up
to
discussion
inside
the
world
group.
We
have
said
this
for
informational,
because
it
is
really
based
on
existing
building
blocks
and
we
put
those
building
blocks
together.
That
is
why
the
first
attempt
was
to
to
define
it
as
informational,
but,
as
you
have
mentioned
interoperability,
I
think
it
is
up
to
the
discussion
up
to
the
group
to
discuss
on
the
list
whether
it
should
be
a
standard
track
or
informational.
G
The
discussion
having
a
discussion
during
work,
adoption
during
adoption
call
will
be
just
fine.
C
Thank
you.
I
think
I'd
like
to
see
a
little
more
discussion
on
this
on
possible
paths
and
whether
we
want
to
take
multiple.
For
example,
another
building
block
is
ipover
mpls
over
ip
over
udpip,
which
actually
sounds
like
a
mouthful,
but
only
adds
four
more
bytes
actually
may
not
even
add
four
more
bytes.
I
have
to
think
about
that,
but
we
should
talk
about
that
on
the
list,
a
little
bit
about
the
options
and
gauge
the
working
groups
opinion
on
those
different
options.
F
Pascal
yes,
so
this
is.
This
is
a
probably
an
alternate
proposal
to
what
was
just
discussed.
It
aims
specifically
at
the
ipv6
data
plate
and
proposes
to
place
the
net
information
at
the
layer,
3
so
below
udp
and
I'm
sorry,
I'm
getting
ugco.
So
that's
very
hard
to
speak
next
slide,
please.
F
F
That's
how
you
recognize
package
duplication
and
if
you
have
a
puff,
then
that's
also
how
you
can
check
the
order
of
the
packets
and
for
this
we'll
note
that
usually
people
think
of
a
sequence
information,
but
that's
not
necessarily
all
that
you
can
use
in
particular,
it's
possible
to
to
provide
to
use
any
information
that
that
would
be
unique
within
the
upper
bound
of
out
of
order
packets
to
duplicate
the
packets.
F
Also,
there
is
the
the
prime
of
network
cutting
if
you
use
the
classical
function
of
splitting
the
packet
into
fragments
and
then
network
coding,
the
fragments,
all
the
fragments
are
basically
the
same
quote-unquote
sequence
and
can
be
received
in
any
order
and
reassembled,
but
we
should
not
eliminate
different
fragments,
so
the
the
ordering
would
not
apply
to
those
fragments,
but
they
each
flag,
each
different
fragment
could
be
eliminated,
but
there's
not
two
different
fragments.
F
That's
what
I'm
getting
at
the
other
piece
of
information
that
that
we
need
is
information
that
indicates
which
path
we're
going
to
follow
and
for
this
the
contribution
that
we
make
in
the
draft
is
to
to
indicate
that
basically,
we
should
not
confuse
the
the
path
and
the
flow
like
the
water
and
the
pipe
analogy,
and
what
we
do
is
we.
We
tag
the
packet
with
layers
of
information
that
indicates
the
path
and
that's,
regardless
of
the
flows
that
are
being
transported.
F
So
this
way
we
can
transport
multiple
applications,
layer
flows
without
having
to
look
at
the
six
double
or
anything,
and
we
can
also
merge
in
border
am
with
the
flows
inside
the
same
path
and
we
can
easily
as
well
aggregate
multiple
paths
into
bigger
path.
F
F
So
for
that
we
propose
to
use
ipv6
by
hub
option
and
the
the
cool
thing
with
the
bio
option.
It's
it's
available
right
after
the
ipv6
header,
so
it's
very
early
in
the
packet.
It's
very
hard
to
find
this
fits
the
v6
architecture,
because
now
we
can
coexist
with
other
extensions
like
srv6.
F
If
we
want
to
have
a
loose
path
signal
by
a
service
6.,
and
it
fits
that
architecture
which
says
basically
that
the
flows
are
assigned
to
to
path,
and
so
basically
you
do
some
classification
at
ingress
and
then
you
just
follow
a
path,
and
so
we
tag
the
path
in
the
packet
and
we
can
just
follow
it
next
slide.
Please.
F
So
can
we
there
is
this
question
of
whether
we
can
use
it
by
harp.
I
can't
spend
much
time,
but
basically
the
answer
is
yes.
F
Rabbi
hop
and
extension
general
are
getting
more
traction
in
v6
these
years
and
since
8200
now
the
hub
by
hub
can
be
ignored
when
it's
not
being
used,
so
it
makes
it
makes
much
easier
to
use
our
bear
headers
in
ipv6,
and
they
just
showed
in
this
illustration
that
the
hotbar
app
is
right
before
the
srh,
and
so
that
makes
it
very
early,
very
easy
to
pass
with
hardware
before
isaac
processing
next
line.
F
So
right
now
we
propose
three
information.
One
of
them
is,
is
the
redundancy
which
may
contain
sequence
but
may
contain
another
type
of
information
and
and
precise
time
would
be
a
typical
information
that
we
could
place
there.
Also
the
option
editor
could
be
placed
not
only
in
by
hub,
but
also
just
before,
an
srh.
F
That's
if,
if
we
signal
the
service
sub-layer
using
srh,
and
then
we
have
this
streak
path
option
that
is
typical
for
that
net.
We
also
have
a
loose
path:
option,
which
is
not
reused
right
now
and
could
be
replaced
by
a
s
and
that's
it
yeah,
I'm
sorry.
I
will
have
to
boost
the
volume
again
because,
like
I
said,
I
got
everything
as
equal
and
that
was
unpleasant.
You.
C
I
don't
think
you
left
much
time.
I
will
send
some
questions
to
the
list.
In
particular,
it
seems
that
this
is
a
raw
focus
rather
than
generic
and
it'd
be
good
to
understand
that
that
again,
we'll
discuss
it
on
the
list
and
with
that,
okay,
the
internet.
E
Okay,
this
draft
is
about
that
net
service,
sub
layer,
functionality,
the
pocket
ordering
function,
and
this
draft
intends
to
provide
support
for
people
who
intend
to
implement
this
functionality.
E
This
is
a
a
contribution
together
with
colleagues
from
hirschmann,
stefan
carrer,
tobias,
herrer,
janusz
farkas,
from
arizona
and
myself
is
the
authors
of
of
these
drafts.
The
next
slide
please.
E
This
is
intended
to
provide
algorithms
for
the
pocket
ordering
functionality
which
are
needed
in
order
to
restore
the
correct
order
when
replication
and
elimination
function
functions
are
used
in
a
net
network
next
slide,
please.
E
So
the
the
goal
of
this
draft
was
to
to
define
the
algorithm
that
can
be
implemented.
In
the
previous
discussions,
we
have
discussed
the
old
out
of
box
visibility
of
this
functionality.
What
is
the
result
if
it
is
working
but
how
to
implement?
E
E
We
also
intended
to
keep
these
algorithms
as
simple
as
possible,
also
both
from
implementation
from
number
of
states
from
configuration
parameters
perspective,
and
it
was
also
aimed
not
to
have
any
time
synchronization
related
requirement
between
the
that
net
relay
nodes.
The
the
draft
is
containing
two
algorithms.
The
basic
algorithm
is
described
in
more
in
in
detail.
There
is
a
special
parameter
that
is
used
by
this
argument.
It
is
called
the
puff
max
delay.
This
is
the
maximum
increment
packet
delay.
E
It
is
an
important
characteristic
that,
in
order
packets
are
not
delayed,
and
this
basic
algorithm
can
be
used
in
scenarios
where
the
delay
budget
of
a
flow
at
the
point
where
you
are
doing
pov
allows
that
both
max
delay
time
for
all
the
packets
received
there.
E
The
advanced
algorithm
is
a
extension
of
the
basic
algorithm
it
is.
It
can
be
used
for
any
scenarios.
It
is
identifying
the
the
path
of
the
received
packet
at
the
puff
location
and
making
this
puff
marks
delay
parameter
dependent
on
the
path
practically
next
slide.
Please.
E
So
there
were
all
the
discussion
on
the
list.
We
have
received
good
comments
and
and
clarification
questions
based
on
that.
We
have
also
updated
the
draft.
E
E
B
Yeah,
I'm
not
even
sure
why
we
don't
even
want
to
have
a
standardized
externally
observable
per
hop
behavior
for
that
ordering
function
like,
for
example,
this
especially
important
case
when
you're
switching
over
between
the
a
and
b
stream-
and
you
don't
want
to
increase
the
jitter,
but
you
already
delay
the
shorter
path
latency,
a
stream.
These
type
of
things
are
externally
observable
and
would
be
good
to.
You
know
at
least
have
standardized
ways
to
characterize
the
behavior,
the
algorithm
itself,
and
you
know
how
good
it
will
become,
may
not
be
standard.
Thank
you.
C
C
H
Yes,
thanks
hi
yeah:
this
is
the
rsvp
for
tsm
network
drive
this.
This
replaces
the
atlanta
previously
presented
at
the
the
itf-110.
Can
you
go
to
the
next
slide?
Please
we
we,
we
changed
the
the
premise
of
the
trough
to
focus
on
the
the
the
teaser
networks,
which
I
show
in
the
in
the
next
couple
of
slides.
H
The
the
the
the
the
key
aspect
is
the
rcp
changes
for
better
dsn
integration
that
followed
the
discussion
that
we
had
at
the
itf
110,
that's
the
the
main
change
and
if
you
go
to
the
next
slide,
which
outlines
the
main
changes
from
last
version.
As
I
mentioned,
we
focus
on
rfb
tsn,
as
we
call
it
in
the
draft
and
the
interaction
with
the
lower
layer
technologies.
That's
the
main
part
we
for
that.
We
mapped
the
dns
that
the
the
end
flows
onto
the
lower
layer
technologies.
H
We
don't
limit
it
only
to
the
motor
to
one
q
approaches.
We
simplified
the
use
cases
with
that
where
we
provided
a
single
deterministic
network
with
tns
tsn
enabled
end
system.
We
described
three
different
use
cases
with
the
service
proxy
and
we
use
rsvptsn
across
those
use
cases.
So
that's.
What
is
the
one
change?
H
We
changed
section
three
on
the
design
rationale
outlining
changes
to
the
data
model,
the
reservation
styles,
the
object
definition
flow
specifications
that
are
flowing
then
into
section
4,
which
is
the
the
first
description
of
the
rsvp
tsn
itself,
where
we
describe
the
layer
directions
revised
from
the
previous
version
of
the
draft,
and
we
also
changed
the
api
descriptions
to
align
with
the
revised
focused
that
we
that
we
provided
in
the
structure.
H
That's
that's,
you
know
fairly
straightforward
use
cases
that
revise
the
design
ratio
around
the
four
different
aspects
that
I
mentioned
before
and
they
revised
the
line
terminology
in
section
four
for
the
for,
for
you
know,
for
the
layer
interactions
and
the
and
the
api
descriptions
and
and
that
the
security
consideration
we
haven't
started
yet
become
the
next
version.
H
How
have
we
addressed
the
feedback?
Well,
the
discussion
we
had
at
the
in
in
110
was
mainly
what
the
focus
of
the
document
would
be.
We
created
a
new
document,
hence
the
change
in
file
name
to
narrow
the
document
to
a
proposal
for
rsvp
tsn
for
tsn
enabled
lower
layer
technologies.
H
That's
mainly
because
of
the
author's
said
that
we
had
when
we
discussed
we
weren't
entirely
willing
to
take
on
the
task
to
discuss
the
the
the
wider
scope
of
rsvp
in
general,
so
hence
the
r3pts
and
narrowing
down
in
this
particular
craft
that
had
the
impact
on
the
use
case,
design
rational
that
I
described
before.
H
H
The
next
steps.
If
you
go
to
the
next
slide,
please
is
to
fill
in
more
infos
on
the
message
formats
and
protocol
info.
We
haven't
done
that
yet,
but
obviously,
most
importantly,
we
are
interested
in
more
input
from
the
list.
We've
sent
the
draft
to
the
list.
We
haven't
had
discussion
on
the
list
yet
and
and
and
we
would
be
highly
interested
in
feedback
and
comments,
including
co-authors
and
and
contributors
as
you'll,
see
on
the
last
on
the
last
slide.
Thank
you.
C
Question
so
one
one
comment
that
I
put
into
jabber:
is
that
we'll
need
to
figure
out
which
working
group
will
handle
this?
If
this
proceeds
we
have
a
couple
of
other
working
groups
that
handle
rsvp
and
adaption
to
specific
technologies.
C
I
will
also
comment
that
there
really
hasn't
been
a
lot
of
interest
in
the
itf
on
working
on
two
two
rfc
2205
based
rsvp
solutions.
So
you
know
that
that
we'll
have
to
demonstrate
that
I
think
for
this
work
to
proceed.
Thank
you
and
with
that
thanks
moving.
C
On
whoever
is
presenting
will
need
to
unmute.
C
I
As
defined
in
rfc,
8655.net
may
provide
the
details,
take
a
service
for
the
tsn
and
assist
n
system
and
the
deathless
ip
and
mps
flows
may
be
carried
over
tsn
sub
networks
and
the
related
standards
of
deadplay
with
tsn
and
the
led
has
been
released
to
rc
as
this
night
show
last
night,
please
so
as
discussed
in
these
drafts,
the
common
requirement
is
to
provide
statlet
flow
mapping
in
control
play
the
mapping
between
tsm
streams
and
the
data
flows
is
required
within
the
service
proxy
function
at
deselect
engine
nodes,
the
end
mapping
table
can
be
configured
and
maintained
in
control,
plane
and
default
mapping
from
a
desolate
flow
to
a
tsn
string.
I
It
is,
it
is
achieved
by
the
compilation
of
a
passive
and
an
active
string
and
notification
function
that
operates
as
the
free
level
and
for
the
testing
strings.
Mapping
to
a
data
flow
implementations
should
use
management
and
the
control
information
to
map
a
tester
string
to
a
desktop
flow
and
and
with
one
mapping
aggregation
multiplier.
Tsm
strings
in
a
single
jet
flat
flow
should
also
be
supported
so
based
on
their
background.
This
grant.
I
This
document
proposed
extensions
to
php
flow
specification
for
the
mapping
of
data
flows
and
the
tss
strings
by
exist,
extending
the
traffic
filtering
rules
dividing
rfc8955
to
identify
the
package
and
using
the
associated
action
to
map
their
packet
to
the
related
service.
Next,
please
so
this
is
the
detailed
extensions
for
bhp
fs
and
the
string
id
is
used
to
uniquely
identify
and
identify
a
string
and
the
string
identification
functions
are
defined
in
azure,
802.1,
cb
and
cbdb.
I
I
For
a
deadlock
flow
mapping
to
tsn
string,
this
document
also
define
filtering
rules
for
deadline
flows.
We
proposed
a
d
c
w
types
in
l,
l,
three
components,
flows
back
for
that
mps
flow.
This
document
divide
also
define
the
traffic
action
for
desolate
flows
and
propose
a
tsm
action
and
the
extended
action
for
and
that
traffic
filtering
is
to
accept
accepted
investment
flow
matches.
I
C
Very
much
you
have
comments.
We
really
like
to
see
them
on
the
list.
We
think
that
this
one
definitely
needs
more
discussion
on
the
list
and
typically
and
how
it's
going
to
be
used
and
then,
if
there's
support
for
the
use
case
with
that,
the
next
presenter
please.
J
J
J
So
a
network
administrator
can
must
master
skill
how
to
introduce
the
the
detonate
service
into
the
internet
network
and
related
maintenance.
So
the
precise
of
that
night
networks,
service
deployment
consists
deployment,
preparation,
department,
deployment
planning
and
the
network
service
deployment.
Next,
please.
J
Before
deployment
network
administrator
must
for
understand
what
is
what
is
the
net?
That
night
service
does
not
flow
explicit
and
the
relationship
among
them,
so
the
administrator
must
provide
the
necessary
input
to
evaluate
solution.
Visibility.
The
following
table
lists
the
definite
information
described
in
rfc
9016
and
the
detonator
young
model,
and
next
please.
J
The
asking
controller
is
recommended
in
the
deployment
deployment
scenario,
so
the
administrator
should
specify
net
net
service
information
on
the
interface
of
accident
controller,
for,
for
example,
the
data
service
deliver
profile
is
about
the
assured
bandwidth,
the
bond
analytics,
depending
on
the
variation
and
the
assured
punctual,
the
pancreatic
loss
rate
and
next
piece.
J
J
Okay,
a
network
administrator
should
also
specify
explicit
information
information,
for
example,
the
service
protection
is
for
eliminate,
eliminating
the
pancreatic
loss
and
the
keto
magnesium
is
chosen
by
the
administrator.
For
example.
Cyclical
forwarding
is
easy
to
evaluate
the
fundamental
literacy
next,
please.
J
Okay,
after
the
information
by
the
net
administrator,
the
controller
will
convert
the
information
into
that
net
and
the
network
configuration
by
the
netcast
young,
for
example,
mps
segment,
routing
enable
data
capability
service,
configuration
flow
configuration
and
so
on.
Next,
please,
after
the
configuration,
the
synchronous
node
will
perform
the
function.
For
example,
the
english
node
identifies
the
detonator
service
maps.
The
data
service
to
the
netflow
establish
the
explicit
paths.
C
B
You
my
best
friend,
is
next
the
mute
button.
Next
we
talked
about
an
interim
that's
great
next,
okay,
so
I
just
wanted
to
talk
about
two
of
the
high
level
problems
that
I've
written
in
the
document.
It's
a
lot
more
comprehensive!
Please
read
it
and
comment
on
it.
The
main
issue
is
that
I
really
worry
about
that
net
being
possible
to
implement
in
high
speed,
100,
gigabit
and
faster
low
cost
wide
area
network
equipment
in
a
mutual
space
hop
by
hop,
and
that
is
because
of
the
per
hop
perflow
queuing
model
that
we
have.
B
It
is
very
expensive
to
implement
in
hardware.
It
basically
creates
a
lot
of
churn
when
it
needs
to
be
updated
because
user,
you
know
created
flows
require
signaling
to
every
hop
service
providers.
Typically,
as
my
experience
from
from
tees
has
been
don't
like
that,
they
only
want
to
have
signaling
to
the
edge
and
there
there
are
more
issues
next
slide
so
effectively.
B
Unfortunately,
there
is
text
error
in
here
right,
so
what
we
would
like
to
have
is
really
just
the
signaling
to
maybe
an
ingress
router
to
to
to
shape
or
gate
the
flow
is.
It
called
in
tsn
and
then
and
that's
the
text
issue
on
every
hub,
just
having
diffserv
class
based
queuing
for
the
that
net
flows
and
not
per
flow
state.
That
needs
to
be
updated,
and
this
also
would
make
that
net
compatible
with
you
know,
traffic
steering
that
stateless
specifically
sr
mpls
or
srv6
and
for
multicast
beer.
B
So
that's
the
one
big
point
next
slide,
that's
what
the
tech
next!
That
is
just
the
textual
explanation.
So
this
the
second
one
is
about
actually
bounding
jitter,
more
than
not
bounding
it
at
all,
and
so
there
have
been
two
terms
been
phrased
in
the
industry
in
time
is
basically
when
the
jitter
is
is
really
maximum
and
that's
what
we
have
with
ts
and
ats
or
for
the
most
part,
insert
guaranteed
services
and
they're
queuing
mechanisms
where
the
network
takes
care
of
the
buffering
of
the
packets.
B
We
call
them
on
time,
so
it's
close
to
synchronous,
delivery
and
I've
tried
to
have
a
picture
here
which
I
could
explain
more
in
the
interim,
which
basically
shows
especially
for
tight
control
loops
like
we
see
in
industrial
or
remote
driving,
many
of
the
interesting
new
money
making
applications
the
problems
that
we
have
when
we
don't
have
on-time
delivery
right.
One
of
them
is
obviously
a
lot
more.
You
know,
timing
requirements
for
the
end
points
next
slide.
B
So
here
is
basically
the
proposal.
There
was
already
a
posted
last.
It
have
not
brought
up
this
time
that
we
had
an
example
of
how
this
can
be
solved
right,
because
just
raising
problems
isn't
really
useful.
If
you
don't
show
that
there
can
be
solutions,
so
this
cyclic
cueing
with
packet
tagging,
I
think
there
is
some
rendering
issue
here.
It's
too
small
in
our
proposal
that
solves
all
these
issues.
It's
also
reducing
the
amount
of
clock,
synchronization
required
and
is
quite
flexible
because
of
the
number
of
cycles
possible.
So
yeah,
that's
it.
B
I
think
next
slide
that
should
have
been
it.
Oh
yeah,
I've
started
to
build
a
comparison
slide
of
the
different
algorithms
based
on
the
different.
You
know
factors
of
interest,
and
I
think
that
should
be
one
of
the
work
we
can
expand
on
to
actually
come
to
judgements,
and
that's,
I
think,
should
be
as
yes.
C
Okay,
thank
you,
and
so
we
we
are
planning
an
interim
on
this
broader
topic.
I
do
ask
that
you
remove
the
history
lesson
and
also
you
know,
subjective
material
from
the
draft
and
stick
to
the
technical
issues.
Please
there's
quite
a
bit
in
the
beginning
that
is
not
relevant
to
what
you
presented
here.
Can
you
can.
B
C
Okay
and
let's
move
on
to
junk
pay.
B
Okay,
kyo
hear
me:
yes,
you
sound
good.
Okay,
thank
you
and
jung
punto
from
china
mobile
and
this
slide
is
about
the
draft
of
microburst
under
the
version
three
and
next
slides,
please,
okay,
this
side,
it
will
deal
some
modifications
about
the
version
three.
We
first
make
some
clarification
about
the
purpose
of
the
draft
and
add
some
clarifications
about
what
is
the
large
scale
mean
in
the
in
our
draft,
and
we
also
add
some
text
into
this
analysis
or
the
proposed
method.
B
Next
science
piece
and
this
step
will
introduce
the
purpose
of
the
graph
we.
Firstly,
we
point
out
the
problem
in
our
opinion
that
we
think
that
in
large
scale,
sp
networks,
we
need
a
simple
and
scalable
deterministic
mechanism
and
the
large-scale
network.
We
mean
that
this,
that
network
is
relatively
large
and
so
for
a
lot
of
users,
and
thus
there
are
many
dynamic
flows
in
the
network.
In
this
large
network.
It
is
hard
to
do
for
flow
shipping
for
the
intermediate
nodes
because
they
have
a
high
pressure
forwarding
forwarding
date.
B
Secondly,
we
propose
a
potential
direction
for
the
problem.
For
example,
we
we
do
this
for
flow
scheduling.
On
the
edge
and
do
the
first
interface
scattering
on
the
intermediate
nodes,
we
have
a
larger
aggregation
granularity
to
ensure
the
scalability
and
next
slide.
Please,
and
in
our
opinion,
we
think
that
we
need
different
level
disseminated
deterministic
for
the
industrial
networks.
We
think
we
have.
B
We
need
a
high
and
our
own,
disseminating
and
the
tiers
and
gradually
makes
them
marked
as
this
solution
one
and
is
very
acceptable,
and
but
we
think
that
they
are
more
complex
and
have
a
relatively
lower
scalability
and
not
likely
to
be
adopted
in
a
relatively
near
future.
B
For
this
large-scale
network
and
for
the
consumer
network.
We
think
that
a
reality
with
lower
level
of
disabilities
are
required.
For
example,
we
have
this
solution
too.
This
is
just
the
ip
forwarding
based
on
this
study,
statistical
multiplexing
in
a
relative
light
load
network,
and
we
also
have
a
solution:
three
based
on
the
method
of
the
document,
which
thinks
that
it
can
do
a
better
job
than
a
solution
too
in
the
aspect
of
the
higher
dissemination.
B
Thank
you.
We
have
a
comparison
for
these
two
three
kind
of
mechanism.
The
solution,
one
is
a
tsm
mechanism
such
as
ats,
and
they
have
a
high
level
of
determination,
and
but
we
think
that
it's
not
not
very
good
at
the
scalability
and
the
elite
were
not
very
easy
to
be
adopted
and
for
the
slightly
statistical
multiplexing
exam.
We
think
they
have
a
low
germany,
no
level
of
dismantling
and
have
a
good,
scalability
and
easy
to
be
adopted.
B
In
conclusion,
we
think
the
solution
three
we
proposed
how
first
matter
have
a
better
survivability
than
the
traditional
tsm
mechanism
and
a
better
reliability
than
the
statistical
multiplexing
based
method.
C
Thank
you
so
much
for
bringing
this
work.
It's
definitely
of
interest
to
the
working
group.
We
certainly
have
had
a
pack
session.
We
were
asked
to
stick
to
one
hour.
I
think
next
time
we
will
ignore
the
request
and
and
go
for
a
longer
session
and
it'll
it'll
make
for
a
much
more
useful
session.
So
apologies
to
everyone
for
how
compact
it
is.
Thank
you
to
all
who
contributed.