►
From YouTube: IETF108 DETNET 20200727 1300
Description
DETNET session at IETF108
2020/07/27 1300
A
Do
you
hear
me
yarosh?
Yes,
yes,
I
can
hear
you
thank
speak
earlier,
so
apologize
for
the
the
late
entry,
the
they're
working
on
it.
If
you're
going
to
you
know,
we
were
gonna,
do
an
audio
test
for
everyone.
I
think
we're
too
late,
so
we
should
just
get
started.
Do
you
think
that
you
agree
yanish?
Yes,
let's
go
ahead.
Okay,
all
right!
A
One
thing
to
be
aware
of
it
looks
like
meat.
Echo
is
providing
very,
very
tight
time
constraints
both
for
entry
and
exit.
I
was
just
in
a
session
that
ended
exactly
at
the
end
time
to
the
second
just
cut
off
everyone,
so
please
be
prepared
for
us
to
try
to
stick
very
tightly
to
the
time
and
expect
that
we
cannot
run
over
at
all,
so
I'm
lou
berger,
I'm
co-chair
I'm
here
with
jana
schwarkos
as
well
as
ethan
grossman.
Welcome
to
our
virtual
our
online
ietf1108.net
session.
A
We
have
50
minutes
and
we're
going
to
try
to
keep
things
moving
along
pace
next.
So
this
is
an
ietf.
We
have
a
notewell
that
covers
all
our
participation
and
to
these
meetings.
Basically,
anything
you
say
here
is
it
becomes
part
of
our
permanent
record
and
is
a
contribution
to
the
idea
if
you're
not
familiar
with
it,
please
jump
on
that
url.
If
you're
looking
for
urls
to
slides
that
was
sent
to
the
email
list,
and
you
should
be
able
to
click
on
that
and
move
through
that
at
your
own
pace.
Next.
A
A
We
felt
that
the
group
was
worth
it
was
familiar
with
etherpad
and
we
should
just
stick
with
it,
particularly
on
this
first
day,
and
just
because
we
know
the
kinks
that
exists
with
it
and
we
so
we're
we're
using
etherpad.
Please
jump
on
the
link.
You
can
find
it
in
the
email
to
the
list,
as
well
as
this
url
here
and
on
the
various
slide
pages
and
agendas
that
have
been
distributed.
A
This
is
something
that
I
believe
we
mentioned
at
our
last
interim,
but
we
thought
it
would
be
good
to
read.
To
mention
here
is
in
this
online
world.
We
are
trying
to
transition
to
the
new
mode
of
operating
and
not
lose
momentum,
because
we're
not
meeting
in
person.
Of
course,
we've
always
utilized
the
mailing
list
as
our
official
way
of
gauging
consensus
for
the
working
group
and
nothing
has
changed
there,
but
we
wanted
to
make
sure
everyone
in
the
working
group
is
aware
that
there
is
a
working
group.
A
Webex,
that's
available
for
informal
meetings
among
authors
or
for
collaboration,
and
also
you
can
participants
can
ask
to
for
a
formal
virtual
interim
and
all,
but
all
it
takes
to
get
either
of
those
things
is
to
talk
to
the
chairs,
just
send
them
to
the
det
net.
Chair,
alias
if
you'd
like
to
either
request
something
an
informal
meeting
or
a
formal
virtual,
of
course,
in
either
case
those
will
be
announced.
The
list
and
everyone
in
the
working
group
will
be
there.
A
It
will
be
available
or
the
the
webex
will
be
there
available
for
everyone
to
participate.
We
think
that
these
types
of
meetings
are
really
important
to
maintain
progress,
while
we're
not
meeting
in
person
next.
A
Keep
in
mind
that
we
do
ask
for
ipr
disclosure
confirmation
of
all
contributors
at
both
working
group,
except
document
acceptance
as
well
as
at
publication.
This
is
to
ensure
that
everyone
is
aware
of
whatever
ipr
exists
on
the
documents.
This
is
a
gating
step
at
both
acceptance
and
at
for
submission
for
publication.
Next.
A
So
we've
had
some
nice
progress
since
the
the
last
meeting
we've
had
three
rfcs
published.
So
that's
that's
great
news.
We
have
two
documents
that
are
newly
into
the
rfc
editor
queue.
Those
are
the
data
plane
framework
document
and
the
ip
document
and
we're
hoping
not
far
behind
are
the
mpls
document,
as
well
as
the
ipo
pls
and
mpls
over
ip,
and
these
are
the
other
documents
listed.
A
Also
up
next
are
the
tsn
related
data
plane
documents
we're
going
to
start
last
call
after
this
meeting,
and
it
will
end
two
weeks
after
the
end
of
the
the
ietf.
So
we're
going
to
make
sure
that
everyone
has
a
good
amount
of
time
to
review
the
documents
but
be
aware
that
last
call
on
that
is
about
to
start.
A
A
As
a
reminder,
we
were
recently
rechartered
with
the
main
addition
to
the
work
of
is
bringing
in
the
the
controller
playing
framework
document
and
the
ability
to
work
on
on
control,
plane.
A
Next,
we
also
updated
our
milestones
and
we
don't
have
a
controller
plane
document.
Quite
yet
so
it
looks
like
we're
already
a
little
bit
behind
and
that's
what
the
reason
for
the
asterisk
looks
sounds
like
someone
wants
to
join
in
janos
is
that
you.
A
So
next
up
on
our
agenda,
we
have
an
update
on
the
the
the
end
configuration
model.
I'd
like
to
ask
the
presenters
to
be
aware
that
they
have
actually
12
minutes,
because
I
get
it
a
little
early
and
to
really
focus
on
what
it
is
that
they
want
from
the
working
group,
whether
it's
just
an
update
or
if
you
have
specific
questions.
Please
make
it
clear
what
what
is
it
that
you
want
from
the
group
on
this
again
from
a
time
standpoint
about
12.
B
C
Okay,
I'll
I'll
start
and
I'll
give
an
opportunity
for
others
to
talk
so
first
slides
just
the
contributors
next
slide,
please
so
the
status
that
of
the
the
draft
is
we've
merged
the
two
models
from
the
last
draft.
So
just
a
bit
of
history,
the
the
the
the
original
model
was
was
not
aligned
with
the
the
flow
the
flow
data
models,
so
we
had
two
models.
C
One
was
based
off
the
flow
data
model
and
what
we
have
done
is
we
have
aligned
those
two
and
we've
come
back
to
one
yang
model
and
so
we're
continuing
to
work
through
the
remaining
changes
into
the
signal
model
and
the
the
other
thing
that
I
think
we
should
do
because
it's
brought
clarity
is
publish
the
yang
lit
config
sample
configurations,
so
we've
been
doing
that
in
the
in
some
of
the
slide
decks
and
we've
been
doing
that
on
the
outside,
but
we
haven't
brought
it
into
the
draft.
C
I'd
like
to
see
that
brought
into
the
draft.
We
plan
to
again
review
the
model
and
the
add
service
sub
layer
aggregation.
C
So
we
we've
got
some
aggregation
inherently
in
the
model,
but
we
haven't
quite
aligned
with
what's
in
the
data
plane
drafts
and
the
the
flow
model,
and
we
need
to
go
through
and
just
check
terminology
and
consistency
for
clarity.
So
we've
continued
to
do
that,
but
that
that's
something
that
you
know
that
the
work
group
can
contribute
to
is
help
us.
Make
sure
that
the
terminology
is
the
right
thing
for
the
the
dead
net
worker
and
group.
C
C
We've
been
trying
to
cover
the
the
data
plane
models
that
are
in
red
there
and
we
have
the
various
scenarios
we
have
ip
mpls
and
ethernet
and
how
those
are
are
being
modeled
at
the
application
layer,
the
service
sub
layer
and
the
forwarding
sub
layer,
and
we
we
are
still
doing
a
limited
subset
as
we
do
this,
because
it's
quite
large
and
it's
it's
taken
us
a
while
to
to
do
that.
But
it's
coming
together.
C
C
So
we
had
a
discussion
in
the
in
the
group
about
what
you
know:
what
about
the
debt
net
flows
and
how
do
those
relate
and
in
in
my
view,
what
I'd
said
is
that
from
the
the
mpls
model,
the
detonate
flow
is
basically
that
well,
an
app
flow
is,
is
re
realized
by
a
single
s
label
and
from
the
detonate
flow
it's
one
or
more
app
flows.
So
it's
actually
this
aggregation
piece
that
we
haven't
put
in
to
the
service
sub-layer.
C
C
C
C
You
can
also
have
a
uni-directional
app
flow,
but
we've
reorganized
the
connection
to
the
service
sub-layer
to
allow
it
to
be,
I
think,
a
little
bit
clearer
again.
Anybody
that
you
know
wants
to
comment
on
this
organization.
You're
free
to
you
know,
come
to
the
weekly
meetings
or
comment
on
the
list
next
next
one
please.
C
This
is
the
service
sub-layer
and
some
some
of
these
pieces
have
different
components
based
on
whether
you're
a
relay
node,
an
endpoint
or
a
transit
node,
and
so
we've
highlighted
some
of
the
the
aspects,
whether
you're
a
relay
or
whether
you're
an
endpoint
next
chart,
please
so
for
the
forwarding
sub
layer.
The
same
thing
we've
got
the
the
tree
and
the
how
it
relates
to
the
various
other
components
there.
C
Next
chart
please
so
this
was
a
sample.
Topology
we've
used
to
work
through
the
model.
It
just
shows
some
of
the
relationships
of
some
of
the
labels.
It
doesn't
show
aggregation.
We
have
to
update
this
for
aggregation.
This
is
just
a
single
flow,
but
it's
using
replication
and
elimination
in
that
model
next
chart
please.
C
This
diagram
we've
seen
this
before
this
just
represents
what
I
talked
about
earlier,
so
that
you
have
the
application
side
and
the
various
reference
pointers.
You
have
the
service,
sub
layer
and
the
forwarding
sub
layer
and
they're
shown
as
unidirectional
pieces
and
the
app
flow
can
be
like.
I
said
it
can
be
single,
it
can
be
bi-directional
or
it
could
be
unidirectional
pieces
as
well
and
some
of
the
relationships
etc.
C
This
is
a
a
sample
of
the
yanglin,
the
json
output.
When
configuring
and
this
one
is
just
the
application,
I
believe
no,
it's
got.
It's
got
the
service,
it's
got
all
it's
got
all
pieces,
so
it's
a
a
single
configuration
of
an
edge
node
with
an
application,
a
service
sub
layer
and
a
forwarding
sub-layer,
and
this
is
what
we
have
to
put
into
the
diagram
all
right
next
chart.
C
So
we,
our
plan,
is
to
to
comment
and
review
the
current
model
for
terminology
consistency,
adding
the
service
sub-layer
aggregation
check
that
the
flow
model
and
the
data
plane
models
are
consistent
and
continued
with
that
yang,
lint
validation
and
then
a
general
cleanup
making
sure
that
the
the
document
passes,
knits
and
and
and
everything
in
the
that's
provided
in
there
actually
functions,
so
you
can
test
the
xml,
etc,
and
with
that
I
will
open
it
up
for
comments
from
the
other
authors
or
anybody
else.
D
C
F
Okay,
so
updating
on
mpos.
F
F
Two
models
for
oem
interworking,
the
first
is
a
appearing
oem
model
and
so
on
the
diagram.
What
we're
trying
to
capture
is
that
so
in
one
in
that
mpls
domain,
we
have
that
net
service
and
fate,
sharing
the
debt
and
service
oem
and
in
tsn
in
the
peering
model.
Again,
so
the
death
net
mpls
service
being
mapped
to
a
tsm
domain
and.
F
It
has
to
have
its
own
oem
that
can
be
mapped
in
the
boundary
node
that
is
in
between
in
the
center,
and
then
we
can
realize
end
to
end
oem
next
slide.
F
So
in
the
tunneling
model.
It's
in
some
regard
simpler
because
both
service
and
related
service
oem
being
tunneled
through
their
neighboring
domain,
and
thus
one
oem,
provides
you
with
the
end
to
end
the
tunneling.
The
model
of
oem
has
some
disadvantages,
for
example,
so
the
tunnel
obviously
looks
like
a
single
hop
entity
so
that
there
is
no
visibility
on.
F
F
In
addition,
we
can
use
dfd
in
that
net
mpls,
it's
rfc
5884,
but
very
conveniently
rfc
5880
defined
the
codes
to
be
used
for
concatenated
paths.
So
the
two
paths
in
the
ascenda
main
can
be
mapped
into
their
devnet
mpos
bfd
session
as
concatenated
path
and
then
signaled.
F
When
it's
defect
detected
into
send
domain,
it
can
be
conveyed
and
signal
to
the
head
end
of
the
session
in
that
mpls
domain
performance
measurements,
because
we
have
two
separate
oem
domains.
They
will
have
to
be
performed
separately
in
each
domain
and
then
metrics
that
can
be
additive
to
use
so
that
to
assign
and
have
credit
limits
and
thresholds
of
metrics
for
each
domain.
F
Devnet
mpls
to
death.net
ip
it's
simpler
because,
for
example,
we
can
have
a
bfd
in
each
domain
and
again,
as
mentioned
in
a
previous
slide,
signaling
of
concatenated
path.
Failure
can
be
used
achieved
using
dfd
performance
measurement
can
be
based
on
rfc
8762.
F
Next
slide
for
the
security
consideration
that
we
added
references
to
new
documents,
because
we
haven't
updated
and
pointed
to.
F
Other
concerns
that
related
to
lsp
thing
and
vfd
or
pseudowire,
as
also
applicable
to
this
specification.
F
Next
slide,
please!
Well
again,
we
always
welcome
your
comments,
suggestions
and
have
a
discussion.
Thank
you.
A
Okay,
do
we
have
any
questions.
A
While
we're
waiting
to
see
if
anyone
joins
the
the
queue
greg,
what's
I
noticed
that
your
the
oam
ip
document
has
not
been
updated.
What's
the
plan
there.
F
F
F
B
Far,
okay,
then,
thank
you
very
much
greg
and
sorry.
A
You
know
I
I
had
an
audio
problem
for
a
moment.
What's
your
plan
for
timeline
for
doing
the
update
on
the
ip
document,
or
do
you
think
it's
ready
for
adoption.
F
I
I
need
to
again:
I
I
switched
from
I
ipo
am
that
net
ipo
am
to
this
work,
so
I
need
to
go
back.
Probably
do
it
right
away
after
the
meeting
and
then
I'll
reach
out
to
you
if
we
need
some
time
to
prepare
it
further
or
if
we
believe
that
it's
effectively
ready
for
adoption
poll,
then
I'll,
let
you
know
so
right
after
the
meeting
I'll
I'll
get
to
that.
A
Great,
so
we'll
see
a
comment
on
next
steps
on
the
the
list.
Thank
you.
So
next
up,
I
think
we
have
fabrice
who's
going
to
talk
to
us
a
little
bit
about
what's
happening
in
raw
with
oam.
A
The
chairs
actually
asked
for
this
to
be
presented
here
today,
because
we
think
that
there's
a
lot
of
good
discussion
in
this
document,
which
are
is
completely
generic
to
any
debt
net
network
and
so
from
from
our
chair
standpoint.
We're
looking
at
this
as
potentially
being
brought
into
the
oem
work.
That
greg
was
just
talking
about.
D
Thank
you.
Thank
you
so
much.
Thank
you.
So
that's
a
joint
work
with
yogurt
and
greg
who
presented
the
last
talk
next
slide
and
during
the
last
etf,
we
discussed
during
the
working
group
on
raw
working,
but
we
had
a
very
generic
document
and
actually
some
of
these
details
were
very
specific
to
wireless
networks.
So
that's
the
purpose
of
the
double
version
of
drafts
version
two
and
three
in
which
we
tried
to
address
and
leave
specific
aspects
for
networking,
so
typically
for
everything
which
is
specific
to
wireless
networks.
D
We
will
discuss
about
that
on
next
thursday
for
the
world
walking
group
and
after
all
discussion,
we
concluded
that
perhaps
it
may
be
interesting
to
have
one
part
of
this
document
which
concerns
the
generic
aspects
of
oem
features
and
which
may
be
referring
to
us
for
that
net.
So
that's
typically
the
objective
of
this
position,
presentation
to
present
what
we
did
so
far
with
greg
and
georgios
next
slide
please.
D
So
the
structure
of
my
presentation
is
first
operation
at
which
fashion
and
then
I
will
conclude
with
maintenance
problem
next
slide
for
the
operation.
That's
the
job.
The
job
is
to
keep
the
network
up
and
running,
so
we
have
to
maintain
the
connectivity
to
verify
the
quality
is
okay
for
any
flow,
so
control,
plane
and
also
for
a
specific
flow.
Since
we
have
some
dedicated
resources
for
some
specific
net
net
flows,
so
we
have
to
adapt
some
very
popular
tools,
such
as
ping
and
transfers
to
work
in
this
situation.
D
The
problem
is
that
we
may
collect
a
very
large
amount
of
statistics
which
may
be
heterogeneous
or
not
so
we
have
to
design
some
mechanisms
to
aggregate
this
matrix
and
to
be
able
to
understand
where
the
fault
occurs
in
the
network
and
the
challenge
is
basically
being
to
have
these
frame
tools
that
work
well.
That
use
the
data
versus
the
processes
for
that
advocates,
but
without
disturbing
them.
So
we
have
a
kind
of
cohabitations
which
is
true
or
mind
quite
challenging
next
slide.
D
Please,
for
the
administration,
that's
keeping
track
of
the
versus
and
how
they
are
used
in
the
network.
So
we
have
to
collect
a
large
amount
of
metrics
so
for
waste
networks,
we
have
a
clear
view
of
what
we
should
collect
so
such
as
ssi
the
synonymous
strength,
the
water
consumption
for
every
radio
channel
this
kind
of
stuff
for
that
net.
It
may
be
something
quite
different,
such
as
the
coincidence,
the
packet
losses,
the
distribution
of
our
weavers,
to
verify
that
everything
goes
correctly
and
the
challenge
is
still
to
not
disturb
the
data
packets.
D
So
should
we
insert
some
flags
in
the
packets
should
we
piggyback
some
information,
some
control
packets
inside
the
payload?
That's
an
open
question
to
our
mind,
and
it
also
depends
on
the
force
that
we
have
to
detect
for,
for
instance,
for
how
still
we
have
to
detect
that
something
goes
wrong
for
keeping
widow
channel.
D
So
we
have
to
collect
statistic
pair
whatever
channel,
but
it
may
be
also
pairing
that
circuit
device
to
be
able
to
identify
each
type
of
fault
in
the
network,
and
we
have
also
correct
worst
case
matrix,
since
we
are
quite
convinced
that
the
average
value
may
often
not
be
representative
enough.
So
we
we
have
to
collect
the
distribution
rather
than
these
very
synthetical
values,
so
the
minimum
interior
packet
time
or
the
compliancy
of
the
flow
with
specifications,
for
instance,
next
slide.
D
Please
and
last
but
not
least,
that's
to
facilitate
the
upgrades
and
we
pair
since
we've
have
multiple
paths,
because
we
have
four
trolley
on
topology.
So
we
are
exploiting
multiple
independent
path,
so
more
than
availability
is
that's
the
fact
that
we
have
several
paths
that
are
active
in
parallel,
so
we
have
to
propose
the
mechanisms
to
replicate
the
packets
at
the
wide
places
and
to
eliminate
the
duplicates
so
how
we
should
inject
packets
or
not,
logging,
that's
more
interesting!
D
D
D
Next
slide,
please.
So
the
next
step
is
okay.
Is
this
points?
Are
these
points
of
interest
for
detonate?
What
would
be
the
purpose
of
where
each
direction
we
should
explore?
Volunteers
are
much
more
welcome
for
contributing
criticizing
whatever
so
yeah.
That's
an
open
discretion
now
open
to
questions
comments
or
critics.
A
So
if
you
thought
about
how
you
would
split
the
material
between
between
that
net
and
law
and,
obviously
anything,
that's
really
radio
specific
right.
D
Actually,
we
we
have
removed
from
draft
all
what
we
thought
that
it
was
generic.
So
now
we
don't
have
any
document
which
is
ready,
which
is
specific
to
detect
or
generic
enough.
We
only
focused
on
the
wireless
networks
up
to
now,
but
before
going
in
this
direction,
I
guess
it
would
be
great
if
it's
something
to
us
for
didn't
it
or
if
this
is
true
generic.
That's
that's
an
open
question.
A
Okay,
we
can
always
look
to
your
co-author
greg,
who
just
spoke
to
see,
if
he's
willing
to
take
that
generic
piece
and
bring
it
back
into
net,
because
that's
that's
the
text
that
we
thought
was
worthwhile,
either
in
the
to
bring
into
the
existing
documents
or
as
a
maybe
even
an
oem
framework
work.
E
I
like
the
idea
of
a
generic
framework,
particularly
as
we've
got
multiple
data
planes
in
debt
net
just
want
to
sort
of
caution
that
we
need
to
be
careful
about
getting
overly
enthusiastic
at
this
stage
of
limiting
participants
and
signing
for
half
a
dozen
drafts.
That
would
not
be
a
good
path
forward,
but
I
do
like
the
idea
of
having
sort
of
one
general.
This
is
what
oem
has
to
do
here.
Are
the
crucial
services
now
see
these
other
two
drafts
for
how
to
map
them
into
the
data
planes.
B
Go
ahead,
yes,
so
I
also
like
the
idea
of
having
the
networm
framework
draft
and
similarly
to
the
data
plane,
and
then
we
would
have
an
ampulla
om
or
we
have
an
ampersand
ipo
and
the
working
group
could
enter
the
wireless
specific
parts
to
the
general
aquarium.
G
Hi
rick
taylor,
so
I'm
with
my
chair
of
raw
hat
on
I'm.
I'm
really
pleased
to
hear
people
saying
this
because
in
conversation
with
lou
and
janos
and
eve
about
this,
we
came
to
the
same
conclusion
that
we
thought
there
was
a
lot
of
value
in
this
document
that
was
generic
enough
to
be
held
in
det
net.
If
it
could
be
absorbed
into
a
generic
oem.
G
A
Okay
looks
like
there's
support
for
the
the
notion
of
a
generic
framework.
I'd
say
if
you
are
willing
to
work
on
that,
add
your
name
into
chat,
saying
you
would
like
to
work
on
it
and,
let's
see
if
we
can
get
some
people
to
self-organize,
we
do
have
some
common
authors,
notably
greg
and
maybe
greg
you
can
try
to
self-organize
and
see
if
we
can
come
back
with
the
document,
throw
your
name
into
the
chat
session.
A
H
Do
you
hear
me
yeah
george
here
sorry
if
there's
a
background
noise
just
to
make
sure
if
I
understood
well,
the
idea
will
be
to
work
on
genetic
documents
for
the
deadnet
and
then
we
will
have
the
specific
document
for
the
raw
working
group
right.
A
I
I
I
misheard
part
of
what
you
said,
but
I
think
you
were
saying
that
there
would
be
a
generic,
a
part
in
net
and
a
roth
civic
one
in
raw.
Is
that
correct.
D
So
probably
the
next
step
will
be
with
greg
and
georgios
and
the
possible
contributors
additional
contributors.
We
try
to
identify
that
the
aspects
which
are
generic
enough
to
fit
in
that
net
and
we'll
submit
this
draft
remaining
list
to
see
if,
if
it
fits
well
the
interest
of
the
working
group,
that's
okay,
you.
A
Just
submitted
the
internet
draft
and
then
bring
it
and
then
point
out
the
working
group
that
it's
there,
you
don't
have
to
run
it
by
the
working
group.
You
know
draft
draft
or
sheet,
so
please
publish
it
and
then
you
can
all
see
it.
Thank
you
all
so
much.
I
think
we're
ready
to
move
on
to
this
topic.
I
Okay
hi:
this
is
joseon
and
I
will
introduce
our
progress
in
the
document
of
data
controller
plan
framework
next
slide.
Please
here
is
the
background
and
the
purpose
of
this
document.
I
Actually
there
are
other
documents,
have
some
contents
about
the
data
controller
plan,
for
example
the
data
architecture,
draft
and
net
data
plan
framework.
I
I
I
Here
is
the
update
for
this
version
of
the
draft.
We
have
fixed
some
comments
from
both
the
working
group
and
also
the
chairs.
We
have
update
the
terminologies
in
the
draft.
For
example,
we
change
the
hybrid
control
plan
to
combined
control
plan
and
also
we
have
removed
some
expired
references
and
also
some
editor
modification,
and
we
have
a
new
palace
and
thank
you
for
his
thanks
for
his
contribution
to
this
version
of
the
draft
next
slide.
Please.
I
In
the
following
slides,
I
would
like
to
introduce
some
contents
of
the
draft.
The
first
one
is
the
control
plan
requirement.
This
part
align
with
the
the
contents
in
the
denet
data
plan
framework,
and
I
classified
these
requirements
into
into
three
classes.
The
first
one
is
the
general
requirement,
for
example,
support
the
nine
dynamic
creation
modification
and.
I
I
These
are
all
gen
general
requirements
and
also
we
have
some
requirements
for
survey
supplier,
for
example,
support
the
service
protection
such
as
packet,
replication,
elimination
and
ordering
also
some
forwarding
sub-layer
requirements,
for
example,
the
advertised
static
and
dynamic
node
and
the
link
resources,
also
explicit
paths
and
resource
allocation,
and
maybe
some
q
control
technologies
should
also
be
considered
next
page.
Please.
I
Here
is
some
consider
requirements
for
management
plan,
for
example,
monitor
the
performance
of
data
flows
and
nodes
to
ensure
that
they
are
meeting
required
objectives
both
proactively
and
on
demand,
also
supports
data
flow
continuity,
check
and
connectivity,
verification
functions
and
the
support,
testing
and
monitoring
of
packet,
replication,
duplicating
illumination
and
the
packet
ordering
functionality
internet
domain
and
next
page.
Please.
I
Here
is
that
the
control
plan
architecture
in
this
document,
we
have
defined
three
types
of
control,
plane,
architecture,
the
first
one
is
the
distributed
control
plan
and
the
second
one
is
fully
centralized
control
plan
and
the
third
one
is
the
combined
control
plan.
The
dash
the
line
in
the
picture
is
the
uni
between
the
and
system
and
then
a
domain
which
may
not
be
included
in
the
current
version
of
the
draft
and
the
the
the
arrow
between
then
and
node
shows.
I
The
signaling
protocol
may
be
defined
in
the
picture
and
the
the
arrow
between
the
controller
and
then
a
node
means
that
there
will
be
some
configuration
from
the
controller
and
to
config
the
data
device
in
the
net
domain
next
slide.
I
Please
here
is
some
control
plan
considerations.
For
example,
we
should
consider
how
to
implement
explicit
opacity
in
control
plan,
for
example,
past
computation,
past
establishment
and
the
strict
or
lose
pass
also
resource
reservation.
For
example,
resource
allocation
device
configuration
and
packet,
replication,
elimination
or
ordering
function
should
be
supported.
I
I
I
Management
should
also
be
considered
and
next
slide,
please
in
the
next
version
we
plan
to
end
some
get
analysis
in
the
document,
which
will
include
maybe
some
considerations
about.
If
we
want
to
implement
dynamic
network,
what
is
the
gap
will
be
there
if
we
just
use
the
existing
control
plan
protocols
or
models,
if
there
should
be
some
new
extensions
or
protocols
to
be
defined?
Maybe
there
will
be
some
analysis
in
this
document
also,
and
we
think
this
document
is
a
merger,
and
maybe
it
is
ready
for
working
group
adoption.
F
Oh,
you
can
hear
me.
Okay,
thank
you
clarify
please.
When
you
discuss
oem,
are
you
referring
to
the
management
of
maintenance.
I
I
think
both
of
them
should
be
considered
because
in
the
definition
of
the
net
controller
plan,
it
both
contain
the
control
plan
and
management
plan
and
in
the
management
management
plan.
We
in
our
original
document,
we
intend
to
cover
the
oem
considerations,
so
I
think
both
of
them
should
be
included.
F
Well,
the
there
was
a
historically
some
confusion.
What
m
stands
for
in
oem
acronym
and
it
it
stands
for
maintenance
and
maintenance?
Is
not
the
management
plane
function?
The
results
can
be
exposed
because
again
the
management
usually
is
what's
configurable.
What's
controllable,
what's
exposed
their
maintenance,
as
was
mentioned
and
explained
in
the
previous
presentation
by
fabrice,
is
a
different
entity.
So
I
think
that
it
needs
to
be
a
really
clarified
why
you
think
that
oem
is
part
of
the
management
plan.
I
I
think
terminology
clarification
is
is
necessary
here,
I
agree,
but
whether
oem
should
be
included
in
the
management
plan.
Maybe
some
comments
or
suggestions
from
working
group
is
also
necessary
because
for
this
document,
what
we
are
trying
to
do
is
just
to
cover
the
controller
plan
defined
in
the
architecture.
I
If,
in
the
architecture,
the
controller
plan
cover
the
oem,
no
matter
management
or
maintenance,
I
think
it
should
be
included
in
the
document
if
the
architecture
shows
that
not
all
of
the
oem
parts
should
be
included
in
the
dynamic
controller
plan,
maybe
we
should.
A
I
A
Please
discuss
this
on
the
list,
it's
a
great
topic
and
I
think,
distinguishing
you
know.
The
control
from
the
actual
oam,
the
control
of
oem
versus
actual
oem
is
a
great
place
for
the
framework
documents
and
this
control
plane
dock
and
be
clarified
and
we'll
continue
on
the
rest,
and
once
this
is
resolved,
we'll
talk
about
adoption,
also
on
the
list.
Okay,.
A
So,
thank
you
all
we're
like
five
seconds
over
and
we
might
get
cut
off
at
any
moment.
We
really
appreciate
your
participation
in
this
online
itf108.net
session
and
look
forward
to
working
with
you
on
the
list
and
again
all
should
feel
free
to
request
virtual
meetings
if
they
think
that
it
is,
would
be
helpful
and
with
that
the
session
is
closed.