►
From YouTube: DETNET WG Interim Meeting, 2020-12-09
Description
DETNET WG Interim Meeting, 2020-12-09
B
B
C
C
C
This
is
our
usual
note.
Well,
it
covers
everything
that
we
discuss
here.
Basically,
all
discussion
becomes
an
ietf
contribution.
If
you're
unfamiliar
with
these
rules,
I
suggest
you
go
take
a
look
at
the
about
no
well
on
the
iepf
page,
that's
on
the
bottom
and
fill
yourself
with
our
rules
of
conduct
and
contribution.
C
The
agenda
has
been
updated
from
the
original
agenda.
That's
highlighted
on
the
bottom
and
in
particular
that
the
fourth
item
has
been
added.
We
have
an
hour
and
a
half.
We
think
we
have
enough
time
to
cover
all
topics
and
maybe
have
a
little
time
left
over,
but
we
also
really
want
to
have
good
discussion.
So
we're
going
to
try
to
let
discussions
run
as
much
as
possible
with
allowing
some
time
for
the
for
the
later
presentations.
C
This
is
just
a
reminder
of
our
ipr
process.
We
do
a
formal
request
for
disclosure
both
that
time
of
adoption
and
prior
to
last
call.
We
are
all
familiar
with
working
remote
at
this
point.
If
you
would
like
to
have
your
an
informal
meeting,
the
webex
is
available.
I'd
also
like
to
point
out
that
the
ietf
gather
is
also
available.
C
We
would
like
to
suggest,
although
not
require
that
for
your
informal
meetings,
that
you
advertise
it
to
the
list
and
to
invite
contribution
from
all
working
group,
members
or
participants
and
just
a
reminder.
The
next
ietf
has
already
been
announced
as
being
online.
If
you'd
like
to
have
a
webex
session.
C
Just
let
us
know
we
I
do
expect
we'll
come
back
and
say:
hey:
can
you
try
using
gather
and
announce
it
and
we'll
I'll
still
announce
that
on
the
list,
and
that's
it
so
next
up
on
the
agenda,
it
oops
sorry
about
that
is
the
control
plane
framework,
I'm
not
sure
which
author
is
going
to
present.
I
note
that
we
have
multiple
on
so
that's
great.
D
Thank
you,
okay.
I
will
start
actually.
These
slides
are
almost
very
similar
to
our
pre
previous
presentation
in
itm108
and
this
time
just
to
maintain
these
contents
to
give
a
very
quick
review
of
what
we
have
done
in
this
document
and
what
has
been
updated,
and
we
also
want
to
collect
feedback
from
the
working
group
to
move
this
work
forward
next
slide.
Please.
D
This
is
the
background
and
what
we
are
trying
to
propose.
The
the
background
of
this
document
is
that
there
are
some
existing
work
in
the
working
group
that
mentioned
about
the
controller
plan,
including
control
plan
management
plan
for
that
net.
One
of
them
is
intended
architecture
document
and
another
one
is
that
net
data
plan
framework
and
our
purpose
for
this
document
is
to
compile
all
the
requirements
together
and
also
provide
an
overview
of
the
architecture
and
the
considerations
and
also
try
to
give
guidance
for
following
control
plan
work.
D
D
D
This
is
the
management
plan
requirement.
Actually,
the
the
comments
coming
from
itf
108
is
about
the
manage
plan
requirement,
especially
about
the
relationship
between
the
oem
document
and
what
should
be
defined
in
this
document,
and
I
think
we
have
make
this
part
clear,
because
the
oem
part
is
not
the
main
purpose
of
this
document.
D
What
we
should
include
it
is
just
some
reference
to
the
existing
working
itf
and
what
should
be
contained
in
many
management
plan,
or
maybe
will
request
more
discussions,
including
the
comments
from
palace,
for
example,
the
administration
collection
of
the
net
service
request
and
also
some
very
great
comments
from
lou,
or
maybe
the
controller
plan
doesn't
include
the
oem
part,
which
should
be
the
input
of
the
controller
plan,
and
I
think
in
the
following
work.
We
should
consider
all
these
comments
from
the
working
group
and
try
to
end
more
contents.
For
this
part
next
slide.
D
D
D
And
this
is
the
management
plan
overview,
as
I
have
mentioned
in
the
existing
work.
We
only
contain
some
very
brief
descriptions
about
oem
and
some
and
and
ending
some
reference
to
the
existing
oem
work
and
in
the
following
version.
We
should
try
to
add
more
contents
in
management
plan
next
slide.
Please.
D
Yes,
maybe
I
have
a
misleading
what
what
I
want
to
express
here.
Actually,
what
I'm
ending
here
is
just
the
reference
to
the
existing
oem
documents
and
what
I'm
going
to
work
on
after
this
in
terrorism
is
about
to
add
more
other
part
of
management
plan
functions,
for
example,
collecting
input
from
oem
or
some
other
kind
of
management.
C
D
Actually,
I'm
also
a
little
confused
about
about
the
scope
of
the
management
plan
because
for
the
control
plan
it
is
clear
either.
It
is
for
architecture
of
the
controller
plan,
a
control
plan.
Sorry,
it
can
be
some
signaling
protocol
extension
or
it
can
be
some-
maybe
centralized
configuration
by
your
model
or
other
matters,
but
for
management
plan.
What
should
be
included
in
the
document?
I
think
that
is
the
core
point
that
I
want
to
bring
this
topic
to
the
the
discussion
of
in
terrorism.
C
Fair
enough-
and
I
I
do
agree
that
it
is
controller
plane-
can
be
a
little
confusing
because
it's
both
distributed
control,
plane
and
centralized
control,
plane,
support
and,
of
course,
centralized
control.
Plane
support.
The
interface
looks
a
lot
like
a
management
interface,
so
you
know
I
can
I
can
understand.
The
statement
of
this
is
a
little
confusing,
so
look
forward
to
your
future
text
to
clarify
that.
D
D
And
also,
if
there
is
anyone
who
want
to
contribute
to
this
part,
this
will
be
very
welcome,
and
this
is
the
last
page
of
the
of
this
presentation,
because
in
idea
108,
we
think
the
the
work
is
is
solid
and
is
ready
for
move
forward.
And
then
there
are
some
comments
in
in
the
in
the
meeting
and
mentioned
that
the
the
relationship
between
this
document
and
the
existing
oam
work
should
be
clarified.
D
C
I
I
think
it
would
be
really
useful
to
hear
about
anyone
who
has
concerns
about
adopting
the
the
version
of
the
document
I
mean
personally,
I
would
like
to
see
the
plan
changes
done.
First,
particularly
the
clarification
on
the
oam
section,
but
it's
also
okay
with
me.
If
the
working
group
decides
to
adopt
first
and
then
then
fix
that,
because
I
could
just
make
that
as
an
adoption
comment,
does
anyone
else
have
any
concerns?
C
D
C
E
C
E
That
net
realization
over
over
tsn
that
we're
using
as
a
use
case
and
the
l3
signaling,
is
based
on
at
least
the
first
proposal
that
we're
having
for
something
that
we
call
as
a
spell
in
their
one
e
too
much
to
what
we
call
rsvp.net
and
that's
the
main
part
of
the
contribution
we
want
to
focus
on
the
structure
are
all
represented.
Of
the
last
time
is
the
main
meat.
E
We
tried
to
structure
this
a
little
bit
initially
at
least
and
I'll,
come
to
the
changes
in
a
bit
then
we're
looking
into
the
for
the
next
version
around
the
the
the
control
plane
framework
draft
that
we
just
heard,
and
so
that's
why
we
have
the
three
main
sections,
even
though
section
three
and
four
were
mainly
for
future
revisions,
and
you
know
the
main
contribution
being
I'm
sorry.
I
just
have
to
move
a
window
out
of
the
way
the
main
focus
really
on
these
subsections.
E
Now,
what's
the
feedback
we've
received
so
far
and
and
there
were
clarification
source
on
the
on
the
mailing
list-
to
respond
to
the
feedback?
What's
the
scenario
here
is
a
tsn
over.net
that
with
tsn
and
we
we
also
try
to
trust
it
better
in
a
new
use
case
section
that
we
propose
for
the
next
revision.
I
come
to
that.
The
current
draft
talks
about
that
net
over
tsn
that
was
clarified
in
the
response,
clarify
the
relationships
and
specific
data
plane
drafts.
E
E
Also,
we
clarify
the
use
of
the
flow
information
model
also
that
will
be
done
in
revised
api
descriptions
and
there
were
indeed
inconsistencies
that
we
had,
and
they
were
pointed
out
correctly
in
the
in
the
list
feedback
same
terminology,
so
apologies
that
we
haven't
stuck
entirely
to
the
terminology
there
and
again,
that's
obviously
on
our
list
to
address
the
next
version
of
contribution.
This
is
a
very,
very
first
version,
zero
draft.
E
So
what
are
the
next
step?
Really
that
we
have
in
mind
for
this,
and,
and
that
is
to
move
from
the
type
of
bridge,
to
either
scenario
that
is
in
version
zero
to
more
broadly
introducing
the
rsvp.net
proposal
and
how
that
integrates
into
the
controller
framework.
That
means
the
main
contribution
would
be
on
the
on
the
on
the
protocol.
E
Showing
the
design
rationale,
outline
example,
interactions
and
present
clearer
use
cases
beyond
the
one
that
we
had
initially
in
version
zero,
and
also
align
that
with
the
draft
that
we
just
heard
which
which
at
the
moment
is
still
individual
traffic
may
at
that
point,
be
a
working,
quick
draft.
Then,
once
we
update
our
drafts,
more
aligned
is
in
terms
of
the
supported
control,
plane
architectures.
E
Could
that
look
in
a
revised
structure?
So
we
we
wanted
to
introduce
a
much
clearer
use
case.
Section
tsn
has
a
layer,
2
technology
with
approached
sorry
tsn.
I
don't
know
why
I
put
usb
there
ethernet
is
is
one
of
the
use
cases,
but
we
will
introduce
clearer
use
cases
there.
Also
addressing
the
terminology
commons
already
in
the
use
cases
itself.
E
What
are
the
supported,
control,
plane,
architectures
and
that's
mainly
a
summary
and
references
to
the
to
the
current
another
draft
on
the
controller
plane
framework.
So
there
will
be
strong
linkages,
but
a
very
brief
section:
the
design,
rationale
or
rsvp.net,
which
is
a
combination
of
the
current
sections.
Two
four,
two
four
sr22
to
four
and
two
five
in
the
current
draft.
E
That's
where
the,
where
the
address
and
the
feedback
will
go
in,
and
the
protocol
specification
itself
example
interactions
in
a
new
section,
six,
which
is
based
on
the
current
section
2.3,
which
has
the
interactions
based
on
the
figure
we
provided
and
also
linking
that
to
the
use
cases
in
section
two
and
then
you
know
the
remaining
sections
as
per
usual
structure.
So
it's
restructuring
it
very
very.
E
B
E
A
E
Yes,
that's
that
you
know
that's
correct,
that's
that's
one
of
the
use
cases
we
we
will
outline
so
they
indeed
the
interaction
between
the
layer
three
seconds
later
to
the
signaling,
and
I
do
agree
that
I
should
have
mentioned
that
as
well.
We're
also
re-thinking
of
how
to
title
it
better.
The
title
is
too
generic
and-
and
it's
not
helping.
B
B
I
I
think
that
would
be
also
word
for
a
discussion
in
the
world
group
too,
like
we
did
with
the
data
plane
that
we
have
split.
The
data
plan
related
discussion
in
separate
drafts,
focusing
on
special
scenarios.
So
maybe
this
is
something,
but
we
should
also
discuss
and
find
a
good
structure
for
the
control
plane
related
signaling
drafts,
because
I
assume
that
there
will
be
more
such
signaling
related
graphs
during
the
different
network
scenarios.
E
B
A
Yeah,
thank
you
thank
you
for
the
update
and
and
and
the
opportunity
for
discussion.
So
I
have
a
question
on
this
slide
on
under
item
5
rsvp.net.
There
is
a
sublet
protocol
specification
and
I'm
not
sure
if
I
heard
it
to
write
that
you
want
to
do
some
protocol
specification
work
like
extensions
to
rsvp
or.
C
C
The
definition
of
tease
traffic
engineering
architecture
and
signaling
working
group-
it's
actually
rsvp
now,
oh
okay,
good
good,
because,
basically
I
don't
want
it
yeah,
so
sorry
to
interrupt
but
okay.
This
is
this
is
this:
this
is
traffic
engineering
rsvp.
This
is
not
the
that
this
is
not
not
not
the
general
flow
one.
Okay,
you're
right,
but
even
the
general
flow
one.
My
understanding
is
owned
by
t's.
If
it's
certainly
just
one
addition,
but
but
that's
like
an
isg
discussion,
we
shouldn't
go
down
that
rat
hole.
C
Okay,
no
problem
to
address
the
well.
If
you
want
to
just
that,
that's
fine,
but
to
address
the
comment
from
yanosh
about
which
working
group
teas
would
be
the
right
place
for
it.
If
we
decide
to
split
it
out,
I
would
say
for
now,
while
it's
maturing
just
keep
it
all
together
and
then
before
adoption
is.
When
we'll
we
can
address
whether
we
split
the
document
into
two,
and
I
note
that
we
have
debra
or
brungaard
our
a.d
online.
C
C
Thank
you.
I
do
have
one
comment
as
a
with
any
hat:
no
hat
doesn't
really
matter.
I
think
our
the
term
rsvp.net
is
a
little
confusing.
You
know
to
echo
what
others
have
said
and
you're
already
taking
action
to
clarify.
I
think
that'll
be
really
helpful,
but
to
me
rsvp.net
is
extensions
to
rsvp
to
support
core
that
net,
not
extension
rsvp
to
support
tsm,
so
that
name
is
a
little
misleading
too.
I
do
think
it
would
be
interesting
to
make
sure
you
cover
both
any
rsvp
extensions.
E
C
E
C
A
A
It?
May
it's
not
easy
for
me
to
see
the
next
step
so
so
actually,
in
other
words,
we
have
been
working
on
on
the
control
airplane
framework
draft
as
it
was
presented
just
so
long
ago,
and
then
we
are
about
to
call
for
adoption,
and
I
guess
it
would
be
good
to
see
what
what
is
needed
overall
for
that.
But
this
is
just
some.
A
E
E
E
C
C
F
A
Sorry
I
mean
I
just
don't
know
that
and
that's
a
nice
picture
in
two
slides
before,
and
we
wanted
to
mention
that.
Actually,
the
death
net
use
cases
rfc
has
a
section
about
cellular
networks,
so
kind
of
what
a
point
I'm
making
is
that
it
was
among
the
goals
to
to
address
the
problem
of
of
cellular
network.
F
F
We
have
a
lot
of
jobs
to
enable
this
deterministic
service,
both
in
layer
two
and
earlier
three,
and
I
changed
some
words
here,
trying
some
sentence
here,
but
with
using
that
we
have
some
steps
for
this
very,
very
network,
because,
of
course,
the
present
mechanism
can
achieve
the
target.
But
we
think
it's
a
closer
target
with
a
relative
higher
cost.
F
This
is
the
gaps
using
in
this
layer,
three
deterministic
network.
We
are
short
of
a
common
major
mechanism
and
since
the
main
aspect
is
the
simplicity
and
the
scalability
and
the
speed
about
why.
We
think
that
a
primary
death
maximum
cannot
be
directly
used
in
in
large
large-scale
layer,
three
network.
F
F
F
And
thirdly,
everything
the
ip
node
have
been
designed
to
send
traffic
as
quickly
as
possible,
and
they
do
not
know
whether
the
downstream
knows
buffer
can
handle
the
traffic
and
in
our
this,
in
this
draft,
in
our
job,
we
provide
the
solution
or
our
idea,
a
potential
idea
for
this.
We
to
decrease
this
microburst.
F
F
F
F
F
If
all
works
good,
then
the
buffer
will
be
maintained
with
the
proper
depth.
There
are
also
some
other
requirements,
but
we
can
see
we
think
it
can
be,
can
be
solved
not
very
difficult
example.
We
need
some
idp,
like
mechanism
with
a
good
scalability,
to
make
sure
the
bandwidth
on
the
interface
is
not
exceeded.
F
This
is
some
compilation
about
the
potential
asset
mechanisms.
We
think
that
traditional
ip
forwarding
is
easy
to
explore,
but
deploy
the
with
a
good
scalability,
but
they
cannot
provide
this
100
percent
low
level
assurance,
and
the
second
is
traditional
ip
forwarding
with
the
priorities
that
we
give
the
critical
traffic
of
higher
priority.
C
C
Okay,
I
think
that's
good
that
matches
what
we've
done
with
bounded
latency.
Also
I'll
note
that
you
know
what
you're,
seeing
with
the
microburst
thing
you
didn't
talk
about.
If
they
were
implementing
a
standard,
queuing
mechanism
or
not
and
the
the
the
the
equipment
you
were
testing,
and
so
what
you
may
be
talking
about
is
either
a
implementation
problem
or
a
a
standardized
queuing
mechanism
problem.
C
If
it
was
the
standardized
queuing
mechanism
problem
that
would
go
to
whatever
or
whatever
group
to
find
that,
whether
it
be
an
ieee
one
or
a
tsv
one-
and
I
know
as
as
we
heard
earlier,
david
black's
online,
so
that
would
be
his
working
group,
but
an
informational
document.
It's
okay
to
do
do
here
and
look
forward
to
seeing
what
you
put
together.
C
A
Just
one
comment
that
may
maybe
it
seems
to
me
that
you
are
actually
talking
about
multiple
problems
to
be
solved
like
the
scale
of
a
network
and
what
other
problems
like.
I
don't
know
if
I
got
it
right.
The
message
that
practically
speaking
what
I
heard
you
saying
that
time
sync
is
not
applicable
in
a
high
school
network
and
the
microburst
seems
to
be
another
problem.
F
F
A
And
maybe
one
more
note
that
actually
there
have
been
couple
of
mechanisms
put
on
the
table
in
antiplato
2.1
as
well.
Not
everything
has
been
standardized
like
there
was.
The
one
of
the
proposals
is
the
so-called
paternoster
shaper
kind
of
with
similar
goals
in
the
sense
of
decreasing
the
state
to
be
maintained.