►
From YouTube: IETF110-CCAMP-20210311-1200
Description
CCAMP meeting session at IETF110
2021/03/11 1200
https://datatracker.ietf.org/meeting/110/proceedings/
A
A
Everybody
so
welcome
to
cam
session
and
next
please.
A
So,
let's
start
from
the
load
wheel,
I
think
you
all
know.
I
understand
the
iitf
process
and
the
policies
very
well,
but
I
would
like
to
emphasize
one
sentence
here.
It
says
that
by
participating
in
the
itf
you
agree
to
follow
ietf
process
and
the
policies.
A
A
So
this
is
the
agenda,
so
this
time
we
will,
you
know,
present
the
cup
of
the
drafts
and
also
this
time
we
will
have
some
time
to
discuss
the
milestones
and
also
the
charter
updates.
So
we
as
the
they
can
work
group
and
secretary.
We
provide
some.
You
know
preliminary
text
on
the
milestones
and
the
charter
and
then
later
on,
we
will
have
more
discussion
on
this
kind
of
topic
and
also
we
will
have
some
time
to
discuss
the
you
know:
young
model
prefix.
A
So
we
are
using
the
mid
echo.
This
is
really
very
friend
on
i2,
that's
very
good,
and
we
have
used
this
kind
of
online
tool
for
several
times,
so
I
think
we
all
know
how
to
use
it.
Next.
A
And
also
for
the
minute
taker-
and
you
know
our
secular
che
oscar
is
not
here,
he
cannot,
you
know,
attend
this
meeting,
so
if
anyone
could
take
the
minutes,
you
know
while
they're
on
night
two,
which
will
be
much
appreciated
and
also
I
asked
my
colleague
hamian-
to
help
us
also
for
the
blue
sheets.
Actually,
there's
nothing
for
us
to
do
it.
We
are,
you
know,
created
automatically
next.
A
So
for
ipr,
ipr
policy
is
quite
very
important.
You
know,
and
because
it's
really
about
you
know
money
behind
it's
it's
more
like
commercial
stuff.
So
we
all
should,
you
know,
follow
the
idf
policies
very
well,
and
so,
if
you
are
one
of
the
authors
or
contributors,
I
think
you
have
to
you
know,
respond
to
ipr
polling
as
soon
as
possible.
Otherwise
it
will
delay
your
draft
progress
next.
A
So
for
the
main
list,
we,
you
know,
we
always
you
know
intelligent
seeking
people
who
use
the
main
list
as
much
as
possible
possible
to
be
more
active.
You
know,
for
example,
we
can,
you
know,
use
the
main
list
to
discuss
anything
about
the
camp
topic.
For
example,
we
can
introduce
some
open
issues,
discuss
some
open
issues
or
introduce
some
new
ideas
or
drafts
on
the
list
and
also
there's
a
reminder
about
working
group
consensus.
A
We
know
working
group
consensus
is
determined
on
the
list,
even
though
we
got
some
consensus
here.
We
still
need
to
print.
You
know
to
the
list
to
get
con
official
consensus.
Okay,
next,
okay,
it's
for
you
daniele.
C
Yep,
so
let
me
join
fatai
in
saying
a
big
big
thanks
to
deborah
for
all
the
years
in
which
she's
been
driving
us
through
through
our
oak
and
the
welcoming
john
as
our
new
id.
C
Actually,
if
one
of
you
would
like
to
to
to
share,
I
don't
know
some
thoughts
on
how
things
went.
I
don't
know
projects
ideas
on
all
of
all
things,
you're
more
than
welcome
the
stage
is.
B
Yours,
well,
I'm
just
arriving.
D
So
I
think
that
the
the
floor
should
really
go
to
deborah.
B
For
who
has
so
much
context.
C
D
It's
been
really
great,
you're,
a
great
group
and
we,
I
don't
have
anything
really
to
say
it's
quite
early
in
the
morning
here.
So
I
welcome
john
and
I
wish
you
all
the
best.
C
Okay,
so
let's
proceed
them
recent
rfcs
there
is
nana,
but
we
have
two
of
them
in
the
editor
queue,
the
layer,
zero
type
and
the
w
sonyang
the
young
model
for
the
topology.
C
Both
of
the
drafts
have
been
parked
while
waiting
on
in
alignment
on
on
the
young
prefix
prefixes.
This
is
something
that
we
decided
as
a
as
a
working
group.
I
would
say
a
few
weeks
ago.
So
the
idea,
the
idea
is
a
day
to
come
to
a
conclusion
on
how
how
to
proceed.
C
We
we
left
some
room
for
that
discussion
as
well.
We
we
already
had
quite
many,
let
me
say,
votes
preferences
expressed
on
the
mailing
list.
So
it's
now
time
to
draw
the
conclusion
and
have
the
two
drafts
being
progressed.
C
C
We
have
a
new
working
group
draft
and
we
er
we,
the
authors
showed
that
is,
is
absolutely
possible
to
change
the
name
and
the
title
of
the
draft
from
from
individual
contribution
to
working
group
document-
and
you
see
the
the
change
has
been
successfully
recorded
in
the
data
tracker
and
the
the
the
name
of
the
new
draft
that
we
adopt
is
ethernet
cliente
topology.
C
C
C
C
C
We
decided
now
to
offload
a
little
bit
of
the
young
doctors
and
the
next
two
drugs
that
we
will
submit
to
the
sg
or
after
after
working
group.
Las
cola
will
be
the
mbi
applicability
statement
whose
for
which
the
ipr
polling
is
is
concluded
so
ready
to.
C
We
are
ready
to
issue
the
last
call.
The
working
group
last
call.
This
will
happen
next
week
after
the
atf
week
and
the
otn
beyond
the
one
of
the
gigabit
applicability
will
will
follow.
So
this
is
this
is
the
plan.
These
are
the
next
two
drafts
that
we
are
planning
to
to
move
forward
to
the
next
stages.
C
Do
the
authors
of
the
other
ones
want
to
say
something
about
the
progresses?
The
plans
for
the
dwdm
interface
drafts
the
ide
info
for
for
w
zone.
Do
they
want
to
share
a
status
status,
update
and
plans
for
drafts.
E
C
C
There
is
some
more
work
needed
before
considering
this
adam,
especially
especially
on
underlying
technology
entries
and
and
then
the
authors
believe
that
this
one
could
be
considered
in
a
pretty
good
shape
to
be
to
be
sent
to
to
the
next
stage.
C
C
In
earlier
stages,
so
around
the
network,
the
working
group
adoption
phase,
some
others
close
to
the
last
call
the
ws
topology
has
been-
has
been
reviewed,
a
lot
of
comments,
it's
everything
has
been
fixed
and
it's
in
the
editor
queue.
As
I
said
before,
the
flexibly,
the
younger
is
the
one
for
which
we
asked
the
review
at
the
beginning
of
the
year.
The
deadline
expired.
It
was
supposed
to
be
ready
on
the
22nd
of
february,
so
I
mean.
Hopefully
we
should
have
a
review
pretty
soon.
C
Have
been
reviewed
recently
in
there,
it
was
revision.
The
the
version
that
was
reviewed
was
11.
Now
we
are
in
12
and
it
was
at
the
end
of
last
year.
So
we,
I
don't
think
another
round
of
review
is
needed
before
the
working
group
last
call
different
stories
for
the
l1
csm
and
the
layer.
One
types
which
have
been
reviewed
quite
some
time
ago.
C
No
review
has
been
requested
for
the
wson
tunnel,
but
I
mean
as
soon
as
we
will
get.
We
don't
think
that
there
is
the
need
for
a
an
interim
review
of
the
draft.
Probably
a
classical
young
daughter
review
when
approaching
last
call
would
be,
would
be
enough.
C
C
This
is
something
that
was
not
just
a
center
to
see
camper,
but
the
two
c
camp,
mpls
pulse,
pc
and
tsa.
So
a
coordination
among
the
different
working
groups
will
will
be
done
as
usual,
and
the
joint
reply
will
be
will
be
sent
to
a
tut.
C
So
this
this
is
it
for
the
administrative
part
that
we
as
what
I
anticipated
that
we
allocated
some
time
to
the
discussion
to
get
the
discussion
of
some
topics
that
we
wanted
to.
Let
me
see
that
that
for
sure
I
will
need
to
be
discussed
and
reviewed
on
the
milling
list,
but
taking
the
opportunity
of.
C
In
where
were
pretty
old
and
most
of
them
completed
a
charter,
we
were,
let
me
say
over
the
years,
so
we
didn't
get
too
far
from
our
charter,
so
it
can
be
considered
still
still
valid
and
applicable,
but
an
update
could
be
could
be
needed
and
we
would
like
also
as
anticipated
before
close
the
discussion
on
on
the
young
prefixes
and
make
make
a
decision
on
on
how
to
proceed.
C
So
this
is
the
list
of
the
milestones
actually
on
on
our
web
page.
You
see,
they
are
pretty
pretty
old,
most
of
them
have
been
have
been
successfully
completed.
Some
of
them
have
been
removed
because
drafts
expired.
The
working
group
didn't
show
a
big
interest
in
in
them,
but-
and
this
is
the
list
of
a
new
milestone
that
we
are
proposing-
this
is
a
split
into
two
sections.
C
Submit
items
that
we
wanted
to
submit
to
the
sg
and
new
working
group
adoptions,
so
new
items
that
the
working
group
will
be
working
will
be
working
on.
C
So
one
thing
that
I
would
like
to
discuss
with
with
the
working
group
now
is
priorities,
so
this
is
the
list
of
drafts
that
we
would
like
to
submit
to
the
isd
in
a
prioritized
order.
C
C
Let
me
go
through
them
quickly.
The
first
one
is,
I
mean
this
is
a
sort
of
borderline,
because
it's
something
that
we
already
achieved,
which
is
having
the
ethernet
topology
young
model,
becoming
a
working
group
document.
Then,
as
I
said
before,
the
next
draft
that
we
would
like
to
progress
is
the
transport
mbi
applicability.
C
Then
we
expect
to
to
work
to
deliver
the
first
layer
on
player
1
drafts,
so
the
the
types
which
are,
let
me
say
already
in
a
pretty
good
advanced
the
stage-
the
topology,
the
ot
topology
and
then
the
flexigrid,
the
topology
to
complete
the
topology
set
of
documents,
topology
young
models
for
layer,
zero
layer,
one
then
the
layer,
one
csm
the
applicability.
C
Actually,
this
is
something
that,
in
my
opinion,
could
be
anticipated
a
bit,
because
this
is
something
that
has
no
doesn't
need
any
young
review
young
check.
So
this
is
probably
something
that
we
can
speed
up
and
then
work
on
the
wson
id
info
model
and
then
start
once
the
topology
documents
are
ready
to
start
working
on
the
tunnel
models.
W
tunnel
ws
on
otn,
the
flexi
grid,
the
media
channel
client
signal
the
wdm
interfaces,
etc.
A
C
Okay,
if
there's
no
other
comment,
we
can
go
to
the
working
group
adoption
once
this
is
a
sort
of
summary.
The
topics
which
are
individual
contributions
at
at
the
moment.
This
one
is
highlighted
in
in
yellow,
because
it
seems
that
I
don't
remember
if
it's
expired
and
from
since
when,
but
the
the
the
feeling
at
least
advertising
mine
is
that
there
is
no
big
interest
in
progressing
a
work
on
lmp
extensions
for
flex
grid.
C
If
you
believe
that
this
is
not
the
case,
please
please
let
us
know
or
now
or
on
the
mailing
list,
so
that
we
can
consider
it
when
doing
reprioritization
of
the
work
regarding
the
others
ethernet
tunnel.
C
C
C
G
C
B
C
I
Hi,
this
is
dieter
from
nokia.
I
was
wondering
sergio
is
going
to
present
the
layer,
zero
type
extension
drop,
which
is
still
an
individual
draft
right.
Now,
it's
the
zero
zero
version.
That's
going
to
be
presented
later
in
this
session.
I
think
we
should
also
consider
a
working
group
adoption
quite
quickly.
C
Yes,
I
mean
that
draft
is,
is
something
that
all
the
working
group
agreed
to
work
on.
I
mean
the
the
process
was
agreed
by
the
working
group,
so
I
mean
it's
something
that
we
already
consider
as
adopted.
It's,
okay,
it's
cool!
C
It's
not
a
new
conclusion
coming
from
an
individual,
it's
something
that
as
a
working
group,
but
we
we
decided
to
have.
But
you
remember
the
discussion
yeah.
C
So
charter
update
there
is
this
is
split
into
two
sections,
so
in
the
first
part
we
highlighted
in
red
the
thing
said
that
we
would
like
it.
What
is
just
just
a
specification?
Nothing,
nothing
particular.
C
Basically,
the
old
child
is
saying.
The
working
group
develops
extension
to
core
traffic
engineering
protocols
that
are
under
the
care
of
other
working
working
groups.
C
We
thought
it
was
good
that
would,
as
well
as
a
young
models
for
the
content
management
of
new
bucket
networks,
including
both
the
devices
device
models
and
network
models,
so
nothing
new
compared
with
what
we
are.
We
just
thought
it
was
a
good
idea
to
have
young
modelling
popping
up
in
the
in
the
main
section
of
the
charter,
since
99.
D
C
We
were
just
thinking
of
removing
the
reference
to
the
lime
working
group,
which
is
now
closed
and
update
the
list
of
things
that
the
working
group
is
working
on
actually
so,
protocol
extensions
and
models
for
optical
for
tdm
networks,
microwave
layer,
one
services
to
cover
the
l1
csm
cliente
topology.
Probably
we
can
change
these
into
cliente,
topologies
and
tunnels,
maybe
and
then
the
rest
is
unchanged,
so
maintenance
of
already
specified
extensions
and
the
maintenance
of
lmp.
C
C
A
Father,
so
I'm
wondering
if
we
also
should
you
know,
cover
something
new
or
some
new
topics
in
the
chat,
for
example,
slicing
stuff
right
now
we
already
have
one
individual
draft.
You
know
our
discusser
spicing,
you
know,
slicing
is
a
kind
of
you
know
popular
topic
right
in
itf
or
other
seos,
but
you
know
right
now.
Actually
there
are
more
a
lot
of
discussions
more
about
the
you
know,
packet
slicing,
but
right
now
maybe
otn
or
optical
networks
could
also
be
applicable
to
slicing
stuff.
C
Good
comment,
yes,
I
think
so
I
mean
nice.
I
agree
with
you
slicing
as
a
packet
as
as
a
priority,
but
for
sure
there
are
requests
and
requirements
for
doing
slicing,
also
in
non-packeted
technology,
and
then
it
follows
in
in
our.
G
C
Okay,
so
this
is
this
is
the
last
one
as
as
we
anticipated
that
we
would
like
to
close
the
discussion
deborah.
D
I'd
say
that
mic
works
better
on
the
network
slicing.
C
C
This
is
an
activity
that
is
being
done
also
in
conjunction
with
the
t's,
because
the
number
of
modules
in
common
with
them
is
is
pretty
high.
This
is
the
reason
why
we
decided
to
put
the
two
drafts
in
the
editor
queue
on
old
to
to.
C
There
were
a
couple
of
proposals,
davison
t
and
ws,
on
top,
each
of
which,
with
with
pros
and
cons
w
zone,
t
is
more
aligned
with
the
prefixes
used
in
by
the
network
topology
and
the
t
topology
rfc,
8795
and
8345,
which
use
the
prefix
dt
and
nt.
So
keeping
in
alignment
with
them
is
for
sure.
C
Nice
to
have
this
this
has
been.
This
is
also
the
preferred
solution
by
teaser.
Alternatively,
we
can
use
wsom
toppo,
which
is
more
self-explanatory,
so
it's
easier
from
from
a
readability
point
of
view.
It's
potentially
aligned
with
the
w
centennial
and
the
absolute
trl
prefix
combinations
used
for
for
tunneling.
C
We
have
a
number
of
of
replies
in
in
this
direction,
so
unless
there
is
any
last
minute
objection
or
strong
motivation
and
obstacle
for
it,
I
and
I
have
decided
to
to
proceed
with
wsnt
and
we
will
communicate
this
to
the
rfc
editor,
which
is
holding
old
in
the
pen
for
the
layer,
zero
types
and
w's
on
young
documents.
C
H
H
Okay,
so
from
the
last
itf,
this
is
the
activity
that
we
made
was
the
first
ballot
is
organizational.
H
H
Then
the
the
topic
that
we
touched
in
this
period
was
first,
we
changed
the
section
2.5
that
was
related
to
the
transponder
model
part.
H
Then
second
ballot,
we
addressed
updating
the
model
with
the
support
of
the
c
plus
l
band
amplifiers
and
the
third
we
made
some
modification
of
the
young
tree
with
the
young
tree,
simplification
related
to
the
oms
optical,
multiple
section
part
of
the
model
in
which
there
was
a
redundant
information
that
was
eliminated
next.
H
Okay,
so
there
was,
there
was
a.
There
has
been
a
a
a
a
poll
taken
and
wanted
by
by
the
chairs.
After
some
discussion
apollo
related
to
the
modes
used
in
our
model,
the
modes
are
the
different
way
in
which
the
model
is
dealing
with
the
transceiver
capabilities,
and
so
we
have
some
discussion
about,
in
particular,
the
context
of
the
organizational
mode
and
the
relationship
with
the
interoperability
concept.
H
For
this
reason
there
was
a
poll.
The
poll
was
that
the
chisel
was
to
take
the
young
as
it
is
because
there
was
no
need
to
change
that,
but
to
add
some
text
to
and
better
clarify
the
scope
of
the
drafts
related
to
the
interoperability
concept
and
the
same
way
to
expand
a
bit.
The
text
related
to
specifically
for
the
organizational
mode,
so
a
text
has
been
introduced
about
in
the
in
the
introduction,
has
been
added
a
test
clarifying.
H
The
fact
that
the
optical
data
play
interoperability
is
is
a
complex
task
that
is
usually
requires
some,
let
me
say,
join
engineering
and
there
is
a
outside
the
scope
of
this
draft.
H
The
scope
of
the
draft
has
to
be
very
clear,
is
to
provide
the
needed
information
to
support
optical
impairment,
away
path.
Computation
then,
following
some
comments
that
you
can
see
easily
in
the
github
have
been
expanded.
The
text
from
the
section
2.502
about
organizational
mode
also
here
provide
clarification
about
interoperability
and
provide
clarify
their
role.
H
The
precedence
related
to
the
the
the
fact
that
the
the
modes
subsume
some
basic
attributes,
the
the
basic
attributes
related
to
the
the
system
apart
the
optical
power
and
and
frequency
range,
and
these
attributes
can
be
explicit
or
implicit
given
in
the
in
the
model,
and
the
text
clarified
the
precedence
and
how
to
use
that
in
the
context
of
the
modes,
the
the
last
has
been
updated,
the
mode
related
to
the
standard,
the
so
set
standard
mode,
specifying
better
the
text
and
the
fact
that,
with
application
code
actually
with
the
itu-t
aligned
with
the
itu-t.
H
G609.2.1,
sorry,
the
the
data
plane
interoperability
is
guaranteed
on
the
other
side.
The
important
point
is
that
this
standard
mode
for
the
moment
is
pointing
just
the
iqt
specification,
because
is
the
only
one
that
are
present
in
the
moment
in
the
market,
but
nothing
prevent
from
the
model
to
consider
other
standard
mode
standard
specification
as
soon
as
they
can
be
presented
on
the
market.
H
Okay,
so
the
second
point
that
we
address
is
the
for
the
young
update.
We
added
the
part
related
to
the
c
plus
l
band
amplifier,
so
the
c
plus
cell
abandoned
our
amplifier
are
physically
two
amplifier
that
are
both
part
of
the
of
the
same
type
of
amplifier,
but
are
characterized
by
different
attributes
related
to
the
band
the
gain
noise
of
figures
and
others.
H
So
we
the
model
we
thought
to
solve
this
issue
and
to
update
the
model
for
any
type
of
amplifier.
We
added
a
list
of
amplifier.
H
H
One
amplifier
belonging
to
the
same
class
and
you
can
characterize
if
this
frequency
range
is
belonging
to
the
c
band
or
l
band.
H
H
H
H
Then
we
have
also
added.
We
changed
the
name
for
the
oed
to
clarify
better
the
context
of
the
od.
So
this
is
oms
element
2d.
H
H
So
we
we
have,
we
take
the
the
track
of
the
open
issue
in
the
link
that
I
reported
here.
So
you
can
understand
the
issue
discussion
and
what
are
the
resolution
linked
to
the
young
model?
We
have
closed
the
10
issues
from
the
last
itf
meeting.
H
H
H
H
We
know
that
young
daughters
don't
want
to
have
a
grouping
that
are
in
use
or
use
just
one
only
one.
So
we
try
to
follow
these
rules,
so
we
need
to
understand
if
this
grouping
can
be
used
in
the
future
or
not,
and
and
so
that
the
issue
has
to
be
investigated.
H
H
Some
there
are
three
issues
that
are
practically
ask
more
specific,
some
part
of
the
the
drafts
of
the
of
the
model.
For
example,
I
don't
know
one
one
question
is
related
to
the
future
or
method
of
the
zitar
specification
related
to
the
model.
H
So
this
type
of
question
so
is
is
not
strictly
related
to
the
to
the
young
part,
but
is
a
more
general
question.
Let
me
say
that
the
group
us
to
clarify.
C
Okay,
so
I
I,
I
would
think
that
it
could
be
useful
for
in
this
case,
is
that
to
have,
I
don't
know
a
summary
every
so
often
on
the
main
list
to
say
guys,
please,
we
would
need
the
eureto
with
these
two
three
items,
because
I
mean
I'm,
I'm
not
sure
that
everyone
would
go
periodically
and
check
the
open
issues
on
on
github
sort
of
asking
asking
for
review
of
particular.
H
H
Okay,
so
one
of
the
issue
is
related
to
the
extension
of
the
the
model
to
support
the
t
c,
plus
l
band,
amplifier
c,
plus
l
band,
not
only
for
amplifier
but
for
the
other
network
component
and
in
particular
for
related
to
the
rodum.
So
the
group
started
already
to
discuss
how
to
extend
the
model
to
deal
with
that
and
related
to.
H
The
extension
for
rhodam
have
been
raised,
an
issue,
a
potential
issue
due
to
the
fact
that
they
really
there
is
a-
let
me
say,
some
problem
with
respect.
H
What
are
the
abstraction
topology
model
following
that
is
topo
and
following
what
is
proposing
the
young
with
respect
to
the
real
physical
implementation,
and
so
the
the
the
point
is
that,
and
you
can
see
in
the
picture
on
the
right
side,
there
is
a
what
are
the
structure
in
the
rhodum
related
in
the
mesh
part,
with
the
booster
and
plumpifier
and
and
from
from
this,
from
the
topology
model
and
on
the
left
is
the
mapping
of
what
is
the
the
real
equipment
part,
and
so
the
problem
is
that
there
is
some
from
a
booster
and
pre-amplifier.
H
H
But
the
problem
is,
if
from
abstracted
part
enter
in
the
there
is
the
need
to
map
on
the
equipment
on
the
on
the
real
implementation.
H
H
About
the
fact
that
is
not
the
first
time
that
the
issue
on
the
mapping
between
the
abstract
view
to
the
on
the
others
on
the
on
the
physical
implementation
is,
is
been
raising
not
only
for
optical
impairment,
but
also
another
discussion,
so
the
grooves
talked.
That
would
be
good
to
put
the
question
on
the
on
the
the
list
and
so
on
the
working
group.
H
If
it
is
needed
to
have
a
standardized
rule
needed
to
map
the
topological
port
and
the
in
the
physical
rodent
ports
and
to
solve
the
issue,
we
could
have
two
way.
H
One
way
is
to
adding
additional
attributes
or
defining
a
specific
naming
rule
for
for
for
existing
attributes.
So,
for
example,
I
don't
know
to
concatenate
the
two
level
of
the
two
ports
mapping
on
the
on
the
abstract
port
on
the
preamplifier
booster.
H
So
this
is
the
question
for
the
working
group,
and
but
again
this
is
not
impacted.
The
the
the
solution
of
the
issue
from
modem
in
perspective.
H
Okay,
next,
for
the
next
step,
we
wanted
obviously
to
address
the
other
open
issue
and
solving
them.
H
A
So
actually
I
I
read
a
distribution
of
this
draft
and-
and
I
see
there's
a
change
to
the
price
of
the
application
codes
with
standard
modes.
So
I
actually
think
this
is
a
good
idea
and
I
support
it.
But
I
also
have
another
comment.
So
in
the
body
of
the
main
body
of
this
draft,
it
says
the
young
model
defines
three
different
approach
to
describe
the
transceiver
ability.
A
So
I
think
this
description
is
very
good,
but
I
to
avoid
any
confusion.
I
also
would
like
to
suggest
that
we
should
add
some
text
to
describe
explicitly
something
like
it
does.
A
lot
of
the
choir
and
implementation
must
support
three-year
approach
right,
which
means
that
an
application
and
implementation
could
only
support
one
or
two
approach
is
my
understanding.
It's
correct
or
not.
H
The
I
think
the
model
permitted
to
describe
the
transceiver
capability
in
different
modes,
but
does
not
imply
that
the
system
and
implementation
need
to
support
all
of
the
three
sure.
H
A
You
cannot
hear
me
clearly,
okay,
I
would
like
to
look
it.
I
understand
what
you
just
you
know
said
so
I
mean
we
should
add
some
text
to
describe
something
explicitly
to
avoid
some
confusion.
H
Okay,
so
you
want
to
add
text
to
underline
the
fact
that
is
not
implied
to
support
every
mode.
This
is
what
you're
right.
H
H
H
So
this
this
draft
is
has
been
provided
after
the
discussion
that
we
had
some
months
ago
about
the
fact
that
the
layer,
zero
type,
has
been
reducing
the
scope
before
the
publication
just
dealing
with
just
covering
spectrum
management
aspects.
H
H
They
has
been
created
this
document
that
practically
complements
the
content
of
layer,
zero
type
try
to
reconciling
all
this,
the
the
technical
technical
structure,
the
young
structure
that
was
related
to
transponder
model
that
was
spread
in
different
different
drafts
present
in
c
camp
and
with
the
intention
to
create
a
common
common
collection
of
young
structure
and
definition
that
can
be
used
by
all
the
other
w
zone
of
flexible
grid
and
obviously
the
wdm
interface
model.
That
is
a
very
close
and
complementary
of
optical
impairment.
H
Topology
model,
the
life
cycle
of
this
draft
is
being
will
be
practical
in
parallel
of
draft
itf
layer,
0
type
will
be
updated
with
the
content
of
the
layer
0
type
as
soon
as
it
will
reach
the
publication,
and
in
that
case,
we'll
change
again
the
name
on
layer,
0
type,
and
then
we,
the
intention,
is
that
this
layer,
0
type,
will
proceed
with
a
v2
version
of
and
to
have
a
new
rfc
containing
all
the
part
that
was
in
the
previous
layer,
0
type,
plus
the
the
new
one.
H
So.
What
I
summarize
by
words
is
we
try
to
express
with
these
lights
that
should
provide
what
would
be
the
process
of
layer,
zero
type
and
bouzon.
H
H
Next
about
the
other
layer,
0
draft
that
are
present
in
c
camp,
there
are
some
that
can
follow
the
same
path
as
w
zone,
topology
and
optical
impairment
as
drawn
in
the
slides.
H
H
H
H
Okay,
we
have
discussed
before
danielle
said
that
is
considered
like
an
adoption
automatic
adoption,
but
okay,
we,
we
would
like
to
have
a
working
group
adoption
for
for
these
drafts
and
obviously
the
the
draft
as
to
add
other
young
structure
as
needed
as
soon
as
the
other
layer.
Zero
young
model
need
to
have
the
new
grouping
that
can
be
hosted
in
this.
In
this
collector,
like
layer,
0
type
extension
model.
H
C
Okay,
thank
you
yeah.
I
mean
this.
This
is
a
draft
that
was
requested
by
aza,
so
we
we
could.
We
could
have
it
directly
published
as
a
working
group
drafter,
but
I
mean
no
one
prevents
us
to
follow
to
follow
the
path
things
that
the
classical
standard
process.
So
we
will
issue
a
short
working
group.
Adoption
poll.
H
C
Maybe
one
week,
instead
of
classical
two
three
weeks.
F
Omiana,
I
I
I
should
mention
this
later
sorry
sergio
that
I
noticed.
Sometimes
we
are
using
version
two.
Sometimes
we
are
using
revision2
and
sometimes
we
are
using
a
dash
with
ext
calling
for
extension.
So
I
can
imagine
some
problems
for
future
extension,
because
today,
the
layer,
one
sorry,
the
layer,
zero
types
version,
one
is
in
rfc
editor
queue
and
we
create
this
kind
of
this
error.
Zero
types
ext.
F
H
You
mean
dash
v2
this
one,
a
dash
v2.
H
J
J
H
Yeah
you,
you
are
correct
little
because
they
are
the
intention,
at
least
also
from
my
understanding
was
that
as
soon
as
the
layer,
zero
type
reached
the
publication.
H
C
D
K
So
this
is
a
very
short
update
on
the
flexi
grid,
yang
models
that
that
we've
been
working
on
we've
combined
both
documents
into
a
single
presentation,
so
I'll
start
with
the
yang
model
for
sort
of
flexigrid
topology
and
then
conclude
with
the
young
model
for
flexi
grid
tunnels
or
sorry
media
channels.
K
Next
slide,
please
danielle
there
we
go
so.
Essentially
this
is
a
document
that
describes
how
to
model
our
flexigrid
topology
network.
K
Essentially,
we've
got
a
number
of
dependencies
that
that
sort
of
slowed
down
some
of
the
work,
including
the
tea
topology
we've,
also
got
some
dependencies
as
sergio
just
highlighted
with
the
layer,
zero
types
and
also
sort
of
optical
impairment.
That
said,
we
feel
the
document
is
now
stable.
K
There
were
a
few
sort
of
minor
issues
that
that
we're
waiting
for
the
working
group
to
address,
including
the
the
prefix
discussion-
we've
also
updated
the
security
section
and
has
clarified
our
references
and
sort
of
separating
them
into
clear,
normative
and
informative
documents
that
that
maybe
someone
would
want
to
look
at
in
terms
of
sort
of
implementation
aspects
and,
of
course,
like
most
of
the
other
documents,
we
tend
to
track
the
code
to
the
xml
version
of
the
document
and
also
all
the
open
issues
using
a
github
repository.
K
We
do
feel
that
the
document
is
now
ready
for
working
group
last
call.
We
had
two
fairly
comprehensive
reviews,
thank
you
haumean
and
adrian.
They
posted
their
reviews
directly
to
the
list,
and
so
we've
addressed
those,
and
I
think
the
chairs
already
highlighted
that
we
are
also
queued
for
a
young
doctor
review
as
well.
K
So
next
slide,
please
great.
So
then
the
the
second
document
is
our
flexigrid
media
channel.
I
suppose
it's
it's
worth
reminding
the
working
group
that
this
is
work
that
started
approximately
like
approximately
three
years
ago.
So
it's
it's.
It's
yeah.
We
wouldn't
call
it
historic,
but
it's
certainly
been
queued
for
a
while.
K
K
We
have
done
a
full
refresh.
I
suppose
we
could
see
this
as
a
restart
actually
of
of
the
document
it
hadn't.
You
know
we
hadn't
had
a
new
revision
for
at
least
18
months,
so
I
would
request
that
the
working
group
sort
of
does
take
a
look
at
the
current
version.
K
We
have
now
aligned
the
document
with
some
of
the
the
other
existing
work
as
well
trying
to
sort
of
import
as
much
as
possible.
There
are,
of
course,
some
some
ongoing
issues
and
I'll
sort
of
get
onto
those
in
a
couple
of
moments.
K
I
would
also
ask
the
working
group
to
well.
Let
me
rephrase
that
if
there
are
implementers
beyond
the
document
authors
who
are
going
to
be
implementing
it
or
have
already
implemented,
we
would
like
to
hear
about
it
because
currently,
we've
only
got
sort
of
two
confirmed
implementations
of
the
the
flexi
grit
yang
documents.
K
Good,
so,
in
summary,
we
have
a
number
of
open
issues
and
I
I
do
sort
of
take
on
board
what
danielle
mentioned
earlier,
which
is
we.
We
have
to
be
careful
that
we
don't
end
up
developing
and
reaching
conclusions
in
isolation
in
github,
rather
that
we
use
github
for
tracking,
but
we
bring
specific
sort
of
technical,
open
issues
to
the
list
and
make
sure
that
you
know
we're
following
working
group
process
rather
than
absolutely
doing
everything
in
isolation.
K
So
that's
that's
really
important
and
I
will
I'll
drop
an
email
later
today
to
the
list
just
to
highlight
the
open
issues
that
we
currently
have
and
those
include
working
with
operators
just
to
develop
a
use
case
that
that
that
we
may
use
to
help
with
the
the
yang
model
itself
and
if
it's
useful,
we'll
leave
it
in
the
document.
K
If
it's
not,
maybe
we
will
remove
it
or
just
move
it
to
an
appendix,
as
we've
seen
with
sergio's
previous
presentation,
you
know
there's
some
sort
of
discussion
decision
making.
That
needs
to
be
done
in
terms
of
what
we
specify
in
this
document,
or
do
we
actually
move
some
of
the
attributes
into
the
l0
tunnel,
attributes
or
l0
types,
extensions
and
just
import
instead,
and
I
think
I
think
it's
actually
the
latter.
I
think
we're
just
going
to
import,
but
that's
a
decision
we
need
to
make.
K
As
a
as
a
a
group
of
authors,
we
we
are
looking
to
maintain
momentum
now,
with
with
the
discussion
around
flexi
grid,
by
having
a
a
a
weekly
zoom
call,
and
that
is
open,
and
anyone
is
welcome
to
attend
that.
We
will
report
kind
of
conclusion
and
updates
as
frequently
as
possible
to
the
list
as
well,
and
just
one
request
why
we
have
the
attention
of
the
chairs
and
the
secretary
if
we
could
add
two
additional
contributors
to
the
c
camp.
K
Github
repository
for
the
flexibility
media
channel
they're
listed
on
the
slide
here,
I
have
sent
an
email.
I
didn't
get
a
response
back
yet,
and
that
is
it.
Are
there
any
questions.
C
K
K
C
A
quick
time
check
it's.
We
are
almost
15
minutes
late,
but
we
have
a
buffer
over
15
minutes
at
the
end
of
the
session.
So
we
can
see
we
are
perfectly
on
time,
but
from
now
on,
please
try
to
adhere
to
to
to
your
time
slot.
C
F
Okay,
thank
you
danielle.
So
this
is
hamil
from
huawei
and
I'm
going
to
give
some
update
on
a
group
of
otm
models
and
the
first
one
is
layer,
1
types.
Next,
please
so
now
we
have
been
updating
to
version
10,
and
the
objective
of
this
document
is
to
specify
the
common
used
identities,
groupings
and
type
definitions
used
in
their
one
networks.
Then,
nowadays
only
okay,
the
most
most
popular
one,
is
otn.
F
So
we
have
list
out
okay,
the
the
most
frequently
used
groupings
in
this
slide,
including
the
link
bandwidth
and
pass
bandwidth
and
for
labor
related
groupings.
So
they
will.
F
F
So
next,
please
so,
okay,
the
authors
are
thinking
that
the
the
the
module
is
now
stable
and
we
are
ready
for
working
group
class
call.
But,
as
I
was
aware
earlier
in
the
in
the
beginning
session
that
the
young
doctor
review
has
been
quite
many
versions
ago,
so
so
maybe
we
also
need
another
young
doctor
review.
It
depends
on
the
on
the
chair's
positioning.
But
if
we
do
another
young
doctor
review,
I
would
suggest
we
do
a
joint
review
with
ot,
anthropology
and
tunnel
because
they
are
highly
dependent.
C
C
Also,
let
me
say
from
from
a
practical
point
of
view,
also
not
trying
it
not
to
overload
them
with
a
lot
of
work,
because
we
have
other
other
drafts
that
need
a
more
thorough
review.
So
I
mean
I,
I
would
tend
to
think
that
the
the
the
review
that
we
have
had
so
far
is
more
than
enough
to
proceed.
F
Please
so
here
yeah
here
we
list
the
summary
of
our
changes
from
last
itf.
Okay,
most
of
the
groupings
have
been
moved
to
layer.
One
types-
and
here
we
just
left,
left
a
a
field
over
there,
but
now
we
now
we
added
the
descriptions
about
the
grouping
usage
when
you
collecting
the
topology,
because
this
is
the
the
topology
model.
F
F
F
We
will
use
otnt
with
the
same
w
song
style,
but
another
question
would
be
what
would
be
used
for
the
tunnel.
It
should
be.
This
should
be
listed
in
the
in
the
next
draft,
but
I
put
them
together
so
now.
There's
potential
options
include
the
wsong
dash
tunnel
and
the
w
sound
here
or
w
sound
dash.
Tnr
tnr
is
a
kind
of
abbreviation
for
tunnel,
so.
F
I
think
we
will
we,
we
may
skip
the
w
sound
dash
tunnel
for
full
spelling,
given
that
we
choose
w
sound
t
so,
but
we
may
decide
which
one
to
use
the
one
with
hyphen
or
the
one
without
so
to
to
make
sure
that
we
we
proceed
to
the
tunnel
model
easier.
C
Which
which
one
is
used
in
the
t
e
tunnel
model?
Do
you
remember
by
heart.
F
Okay,
so
it
doesn't
help
yeah,
but
we
may
yeah.
We
may
mention
this
too,
to
tease
as
well,
okay,
so
so,
okay,
the
the
next
two
discussions,
is
less
urgent
compared
with
the
previous
two,
but
I
think
flex,
flexigrade,
topology
and
tunnel
and
ethernet
topology
and
tunnel.
F
So,
okay,
so
there
has
been
young
doctor
review,
maybe
one
or
two
versions
ago,
and
we
all
the
we
saw.
We
addressed
all
the
young
doctor
review
comments
and
we
are
requesting
for
the
working
group
last
call.
Probably
after
we
decide
the
the
prefix,
the
module
is
available
on
github
and
we
also
suggest
to
cluster
this
work
with
the
layer.
One
types
like
what
we
did
for
layer,
0
and
sum.
F
Yeah
this
one,
we
tweaked
a
lot
of
the
of
the
text
because
we
rewrote
the
text
in
abstraction
and
we
revise
the
text
in
security
consideration
to
align
with
the
latest
generic
tunnel
models,
and
we
also
do
some
initial
young
model
changes
by
removing
the
source
and
destination
client
signal
as
well
have
we
are
now
having
a
separate
client
signal
module,
so
so
this
one
these
two
should
be
removed.
F
I
said
this
is
the
initial
young
module
changes,
because
the
there
is
a
big
task
that
we
need
to
align
with
the
itft,
which
is
a
moving
target
from
the
day.
So
next,
please.
F
So
it's
only
about
the
young
syntax
and,
as
mentioned
earlier,
we
also
need
to
select
select
the
prefix
for
the
old
internal
model
as
well,
so,
okay,
so
generally
to
open
issues
so
far
and
but
but
we
didn't,
those
of
these
two
issues
are
not
technical.
So
I'm
wondering
if
we
can
request
the
working
group
last
call,
if
not
blocking
by
the
issues
above.
C
So
for
for
the
working
group
of
las
cola,
as
as
we
said
before
now,
we
we
have,
we
have
drafts
piling
up.
We
it's
just
a
matter
of
defining
defining
priorities.
As
we
said
before,
we
have
a
sort
of
bottleneck
in
the
young
doctors.
C
Area
so
we
decided
to
prioritize
the
transport,
mbi
applicability
and
the
otn
applicability
beyond
the
100
gigabits,
and
this
is
sure
one
of
the
one
of
the
next
in
in
line,
because
if
you
remember
a
while
a
while
ago,
we
said
that
the
the
the
road
map
that
we
were
trying
to
follow
was
topologies
optical
topologies
or
tn
topologies
and
then
and
then
the
tunnels.
So
this
is
more
or
less
the
the
priority
that
we
would
like
that.
We
would
like
to
follow.
K
J
J
Okay,
I
will
try
to
speed
up
okay.
This
is
about
a
one
csm,
a
meter,
boosie
everyone,
you,
everyone,
okay,
next
slide.
J
Okay,
we
had
few
changes
since
the
last
version
and
we
addressed
the
the
comments
from
top
patch
and
basically,
we
move
clean
up
the
model
and
we
have
moved
the
json
example
to
appendix
and
we
have
created
some
issues
related
to
the
sls
model.
Tom
raise
good
comments
and
we
may
need
to
review
it
and
we
are
tracking
all
this
issue
and
changes
into
into
the
github
mentioned
in
the
slide.
J
J
One
of
the
open
point
that
we
have
to
discuss
is
about
the
rules
for
the
the
protocol
coding
function.
Optical
interface
functions.
Not
all
these
three
value
not
only
possible.
Not
all
the
combinations
of
these
three
possible
values
are
are
allowed
and
mf63
has
three
tables
that
describe
four
tables
that
describe
all
the
possible
combination
and
the
problem
that
we
have
is:
how
do
we
check
that?
The
combination
that
has
been
configured
is
valid
and
we
have
some
discussion,
the
previous
meetings
about
leveraging
other
entities.
J
So
maybe
we
need
to
discuss,
describe
these
checks
in
the
document
and
not
in
younger.
I
raised
some
questions
a
few
days
ago
on
networking
group
about
where
and
how
we
can
do
this
check
and
it
looks
like
we
can
do
this
check
before
a
setting
a
configuration
into
the
running
data
store.
That
was
at
least
the
only
comment
I
received.
J
So
maybe
we
need
to
just
describe
this
into
the
raft
to
make
it
clear
that
some
checks
has
to
be
done
on
these
three
attributes,
which
are
not
the
cement
which
are
not
the
c
formally
encoded
into
younger
okay
next
slide.
J
This
is
a
little
bit
about
more
details.
So
what
happens?
The
client
of
writing
is
running
at
a
store
and
and
and
and
then
the
problem
is.
There
are
two
options.
The
invalid
configuration
can
be
a
set
in
the
running
data
store,
but
not
applied
to
the
operation
at
a
store
before
the
option.
J
The
problem
we
have
is
that
the
client
will
never
know
why
they
are
configured
it
has
configure,
has
not
been
applied,
so
we
may
need
to
put
some
warning
so
some
status
in
the
document
in
the
model
to
inform
it.
The
second
option-
and
this
looks
like
possible
from
the
feedback
I
received
yesterday-
is
that
the
valiant
configuration
is
rejected
and
not
asseted
into
the
running
data
store.
J
So
we
need
basically
some
back-end
checks
before
the
configuration
coming
from
the
client
is
written
in
run
data
store,
and
then
we
we
can
have
a
protocol
error
message
that
replies
to
the
client
and
one
question
is
whether
we
want
this
protocol
error
message
to
be
defined
into
the
draft
or
leave
it
as
implementation
specific.
J
J
Then
the
there
are
some
performance
matrix
which
are
defined
in
meth,
but
we
have
also
other
documents
which
are
defining
performance
metrics,
based
on
the
itunes
definition
and-
and
I
think
tom
was
right-
we
need
to
a
little
bit
aligned
to
the
two,
the
two
definitions,
because
maybe
there
should
be
no
major
differences
in
the
semantic
and
then
we
noticed
also.
J
Number
four:
okay:
for
for
the
processing
rules.
Yes,
my
preference
is
that
you
don't
accept
the
configuration
the
running
data
store,
so
it's
a
much
cleaner
for
the
client
because
it
it
sends
a
request
to
write
the
configuration.
It
gets
an
error
message
back
and
I
think
it
will
also
be
nice
to
have
some
some.
As
I
don't
know,
if
standardized
suggested
the
text
to
be
put
into
the
error
message,
so
we
simplify
it
a
bit
the
the
interoperability,
because
you
know
exactly
what.
J
C
I
I
I
think
I
I
agree
with
you,
the
more
you
know
the
mo
the
more
freedom
we
live,
the
less
interoperability
chances
we
have
it's
usually
or
better.
More
work
is
needed
by
by
system
integrators
to
have
a
different,
different
vendors
in
the
world.
G
Good
hi
hi
everyone-
this
is
hogwart
from
future
week
and
I'm
presenting
this
draft
or
otr
network
slicing
on
behalf
of
all
the
cure,
authors
and
contributors
next
page.
G
So
in
this
draft
we
introduce
the
concept
of
ojn
slice
controller,
which
is
can
be
deployed
inside
or
outside
of
an
sdn
controller,
which
has
an
interface
to
an
sdn
controller
with
the
with
the
api
at
the
mpi
and
also
interacts
with
an
upper
layer,
orchestrator
or
slice
controller
at
the
mbi.
G
And
so
there
are
a
lot
of
discussions
in
the
no
not
yet
yeah.
There
are
a
lot
of
discussion.
Can
you
go
back
to
the
last
slide
yeah?
So
there
are
a
lot
of
discussions
in
the
teeth
working
group
about
the
network,
slice,
definitions
and
and
the
the
workflows
and,
prior
to
this,
this
meeting
we
have
received
a
lot
of
helpful
comments
from
interesting
parties,
in
particular
the
relationship
between
the
otn
slice
controller
and
an
orchestrator
or
the
ietf
network
site.
G
Okay,
so
this
mod,
this
truck
is
focusing
on
the
otn
slicer
realization
at
the
er
at
the
mpi,
and
there
are
two
types
of
gen
slicing
that
we
are
considering.
G
One
is
the
connectivity-based
in
which
a
anode
chain
slice
can
be
realized
by
us
by
its
supporting
by
creating
client
services
with
odu
switched
to
tunnels,
and
for
this
one,
the
existing
models,
such
as
the
network,
topology
and
t-tunnel
model
otm-k
tunnel
model
plus
the
client
signal
model,
has
already
supported
this
use
case
and
there's
no
need
at
least
as
we
as
far
as
we
can
see
to
extend
it.
G
The
second
one
is
the
what
we
call
resource
based
audience
slicing,
which
is
to
create
audience
slices
by
reserving
audio
topological
resources
over
an
otn
topology,
and
this
is
the
focus
of
the
young
model
within
this
draft.
G
G
So
we
are
very
happy
to
have
new
authors
joining
us,
in
particular
victor
from
telefonica,
and
there
are
also
a
lot
of
interest
on
this
from
from
other
parties,
and
we
will
be
adding
more
to
this
more
coasters
to
this
draft
once
it
is
agreed
upon
and
also
we
updated
use
case,
descriptions
based
on
the
feedback
from
the
from
the
co-authors
and
we
added
a
young
model
for
the
otnsc
mpi,
with
the
goal
of
realizing
an
opinion
slice
using
resource
coloring
over
a
t
topology,
and
that
coloring
could
be
link
based
or
otf
odu
time
slot
based
next.
G
So
this
is
the
initial
model
of
the
blue
chain
slicing
at
the
api,
and,
as
you
can
see,
it
is
augmenting
the
topology
model
by
adding
a
slice
identifier
to
to
the
to
the
t,
link
and-
and
it
specifies
whether
this
slice
is
is
link
based,
which
is
which
means
the
entire
t
link
is
assigned
it
to
a
slice
or
it
could
be
an
otn
time
slot
based
yeah
and
there's.
G
G
So
here
are
the
next
steps,
so
we
are
also
looking
into
adding
a
young
data
model
for
the
otnsc
mpi
and
again,
as
there
is
alignment,
work
needs
to
be
done
for
the
itf
network
slicing
and
the
ongoing
discussions
within
the
keys
working
group.
G
We
will
put
it
as
a
second
step
and
also
we
will
be
looking
into
the
slicing
for
external
links,
which,
which
is
the
both
the
access
link
for
the
otr
network
and
also
inter
domain
when
we're
dealing
with
multi
when
we
are
dealing
with
the
interoperability
at
the
between
multiple
audio
layers,
audio
domains
and
the
third
one
is,
we
will
be
aligning
this
definition
with
the
discussion
in
the
teeth
working
group
and
we're
likely
to
address
that
with
probably
a
new
use
case.
G
Also
we'll
be
addressing
comments
and
reviews
from
the
working
group
and
also
co-authors
and
reviewers,
and
the
last
thing
is
to
socialize
and
invite
more
coasters
before
we
try
to
ask
for
a
working
group
adoption.
G
So
next
right,
oh
so
yeah!
This
is
just
one
additional
slice
that
we
wanted
to
show
the
the
discussion
about
the
relationship
between
otn,
slicing
and
itf
network
slice
on
the
left
you
will
see.
This
is
what
we
are.
The
current
use
cases
in
which
the
ogn
slice
request
is
coming
from
the
client
which
is
carried
all
the
way
down
to
the
to
the
otn
slice
controller,
with
otn
specific
information,
whereas
on
the
right,
the
ogn
slice
is
just
part
of
realization
of
ietf
network
slice
and
the
network.
G
Slice
controller
initiate
an
ogen
slice
request
to
its
to
a
subordinate
or
gen
slice
controller,
but
no
matter
whether
it's
the
left
or
the
right.
The
interface
used
by
an
ogn
slice
controller
is
always
the
same
yeah,
but
this
this
scenario
we
need
to
be
more
clarified
in
the
following
discussions
and
I
hope
to
hear
more
feedback
from
from
from
the
interesting
parties
on
that.
You
know,
I
think
that's
it
and
comments
are
more
than
welcome.
C
I
I
will
start
so
I
I
think
the
draft
very
good
progresses
and
I
really
appreciated
the
the
alignment
with
other
work
in
other
working
groups
and
the
work
being
been
done
in
teas
being
one
one
of
them.
I
I
had
a
question
regarding
the
scope:
why?
C
What
does
it
cover
just
at
the
mpi
and
not
the
dcmi,
in
the
sense
that
how
can
the
orchestrator
or
the
nato
slice
controller
decide
to
create
a
new
tiana's
lice
upon
a
generic
request
on
top
is,
is
a
simply
optoscope
and
will
be
managed
somewhere
else,
or
it
is
assumed
that
the
generic
request,
for
I
don't
know,
10
gigabit
of
bandwidth,
can
be
accommodated
by
the
orchestrator
or
the
netherslice
controller,
deciding
autonomously,
whether
to
use
an
otna
slice
or
a
different
slice.
G
Yeah,
as
indicated
that
we're
covering
the
routine
slicing
at
the
mpi
is
just
first
step
and
the
the
the
utm
slicing
for
the
mbi
will
also
be
included
in.
Perhaps
the
next
revision.
C
Thank
you,
everyone
for
the
participation.
Thank
you
to
the
presenters
and
you.
We
will
continue
the
discussion
on
charter
update,
milestone,
update,
etc.
On
on
the
main
list.