►
From YouTube: IETF111-CCAMP-20210726-1900
Description
CCAMP meeting session at IETF111
2021/07/26 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
B
B
Okay
good
morning,
good
afternoon,
good
evening,
everyone
so
welcome
to
see
cam
session,
as
we
just
mentioned
that
maybe
this
time
the
timing
is
not
so
friendly
for
the
asian
people
but
anyway,
let's
just
you
know
overcome
the
challenges.
Okay,
so
move
to
the
next.
B
B
B
And
then
on
this
agenda,
so
I
think
you
know
this
time.
The
agenda
is
still
quite
busy
and
we
have
eight
presentations,
so
I
hope
we
hope
that
we
will
have
a
fruitful
discussion
this
time
next.
B
And
then
digital
some
information
about
the
mid
echo
and
I
think
we
are
using
the
mid
echo
and
we
know
how
to
use
it
next.
B
And
then
for
the
with
takers,
so
I'm
not
sure
if
our
secretary
oscar
is
killed
or
not.
Maybe
he's
not
you
know
coming
and
but
anyway,
we
really
hope
that
anyone
could
take
the
minutes
and
then
that
will
be
much
appreciated
and
blue
sheets
no
blue
sheets
required,
and
it
will
be
hard
to
see
automatically
created.
B
And
then
the
last
the
the
information
a
bit
about
the
many
lists.
We
always
encourage
people
to
use
the
how
to
say
utilize
to
mail
list
as
much
as
possible
to
discuss
any
anything
about
technologies
and,
and
especially
there's
one
more
on
mind
which
says
that
working
group
consensus
is
determined
on
the
main
list,
rather
than
you
know,
to
the
online
meeting
or
even
to
the
face-to-face
meeting.
Even
though
we
got
some
consensus
here,
we
still
need
to
bring
to
the
main
list
for
our
confirmation.
C
A
D
A
An
update
since
the
last
the
last
meeting
we
have
no
new
rfcs,
but
we
have
two
drafts
in
the
editor
queue:
the
layer,
zero
types
and
the
w7
younger
and
one
in
the
asg
processing,
which
is
the
transport
mbi
applicability,
applicability
statement.
A
Actually
we
run,
we
are
still
running
the
ipr
polling
for
for
two
other
drops.
So
as
soon
as
the
ipr
polling
is
complete,
we
will
start
at
the
the
last
call
for
for
them
as
well.
A
I
think
we
have
not
received
any
any
update
on
this
draft,
but
I
think
it's
just
a
matter
of
of
reviving
it
that
the
document
is
absolutely
still
still
alive.
We
have
plenty
of
documents
on
the
on
the
agenda
today,
which
is
very
good
from
the
layer.
Zero
types
update,
the
optical
impairment,
topology.
A
We
have
one
draft,
an
update
of
of
a
draft
from
frontier,
which
is
the
applicability
of
sct
and
two
packet
optical
integration.
We
have
the
flexigrid
the
documents,
the
media
channel,
young
and
the
young
document,
an
update,
a
quick
update
on
the
transport,
mbi
applicability
statement,
etc.
A
We
don't
have
these
drafts
on
the
agenda
today,
not
they're,
not
discussed,
but
we
have
some
some
updates
that
we
received
offline,
which
is
the
applicability
of
otn
two
networks
beyond
100
gigabits,
it
has
been
updated
just
to
keep
to
have
a
keep
alive.
This
is
one
of
the
two
drafts
that
I
was
mentioning
before
being
pulled
as
preparation
for
working
group
plus
call,
and
then
we
we
received
some
information,
the
otn
ones,
which
are
not
discussed.
Today
we
have
the
otn
topology
young.
A
A
new
revision
has
been
has
been
submitted
to
align
at
the
prefix
to
the
latest
discussion
that
we
had
on
the
mailing
list
and,
namely
on
the
usage
of
otnt
as
as
prefix
in
in
the
young
module,
and
this
one
is
basically
ready
for
the
working
group
last
call.
This
is
a
be
stable
for
a
while,
probably
as
as
we
did
for
the
optical
draft,
so
we
will
make
a
sort
of
cluster
progressing
at
the
layer.
One
types
and
the
otn
topology
to
start
with
then
on
the
otn
tunnel
model.
A
In
with
the
the
last
call,
depending
on
the
itft
model,
the
the
generic
model
that
is
almost
ready
in
the
teas
working
group
listening
communication,
we
received
the
the
usual
periodical
liaison
from
from
iqrt
study
group
15
on
an
update
on
the
otnt
standardization
work
plan
it
was,
it
was
submitted
in
in
may
actually
yeah.
As
usual.
You
can
find
the
link
to
the
to
the
liaison
in
the
in
the
data
tracker
you
can
find
it
here
for
for
simplicity
and
an
action
is
needed.
D
D
D
A
E
Okay,
okay,
good
so
good
evening
to
everybody
or
good
morning
for
someone,
I'm
sergio
belotti
speaking
and
I'm
going
to
make
an
update
about
optical
impairment.
Topology
young
model.
E
E
Okay,
so
the
we
had
from
the
normally
we
have
a
weekly
call,
and
so
we
have
a
practically
stable
team
that
is
following
the
update
of
the
model
and
actively
contribute
to
the
to
the
to
the
model.
E
In
the
from
the
last
itf,
we
added
two
parts
we
in
part
in
particularly
work
about
the
triad
generator
part
and
we
added
an
entire
new
section
2.6,
describing
the
general
characteristic
of
the
functionality.
E
E
It
is
fine
that
everybody
knows
what,
where
the
the
the
two
option-
and
there
was
a
lot
the
long
debate
about
that
so
just
to
provide
the
characteristic
of
the
two
different
options
that
we
have
discussed.
E
There
is
still
a
pending
issue
related
to
the
trial,
and
then
we
will
see
what
is
the
other
part
that
we
complete.
We
have
addressed
the
in
the
previous
version,
the
c
plus
l
band
for
amplifier.
We
complete
that
with
also
rodan
part.
E
Okay,
these
slides
shown
how
we
are
the
typical
typical
architecture
from
atrial.
E
On
top,
we
have
the
back
to
back
of
bi-directional
architecture,
and
in
this
case
the
a
pair
of
transponder
or
to
better
say,
transceiver,
are
used
to
create
the
regenerator
part
and
the
to
transceiver
that
they
are
used
for
this
functionality
can
be
used
only
for
this
functionality,
so
it
is
not
possible
to
use
the
client
port
for
the
for
that
transponder
as
a
in
a
typical
drop
case
on
the
bottom
part
of
the
slide.
E
There
is
the
unidirectional
architecture
in
which,
instead,
the
20
can
be
also
used,
as
not
only
for
3r
but
also
in
if
it
is
needed,
also
to
come
back
in
the
usage
of
point
of
of
ot
normal
termination,
a
drop
point.
So
this
is
the
typical
characteristic
of
architecture.
E
E
E
E
E
At
other
point,
we
have
talked
that
we
have
no
dependency
of
the
other
models
and
let
me
the
other
point
is
that
we
consider
that
as
a
natural
approach
in
case,
we
start
from
a
bottom-up
approach,
in
the
sense
that
we
looking
from
a
physical
characteristic
of
the
functionality.
E
That
we
use
the
same
entity
topological
entity
and
in
fact
we
can
exploit
again
the
local
lincoln
activity
list
and
the
fact
that
we
can
have
optical
impairment
from
ltp.
That,
in
this
case,
is
degree
towards
the
the
tunnel
termination
point
that
in
which
is
mapping
the
optical
transponder
and
transceiver.
E
So
the
tunnel
termination
point
local
lincoln
activity
list
can
provide
the
impairments
of
the
rodham
towards
the
trial
on
the
right.
I
just
report
what
was
the
characteristic
that
we
used
for
the
rodent
with
a
drop
with
the
optical
impairment
part
and
we
just
reuse
the
same
type
of
attributes
for
for
for
the
transceiver
for
the
trial.
E
E
Okay,
here
is
the
young
update
about
the
the
model,
but
we
you
can
check
that
directly.
The
draft
next
slide.
E
Okay,
so
this
is
the
this:
the
other
option
that
we
discussed
a
lot
in
the
in
our
meeting
and
the
other
option
was
to
consider
the
triar
as
a
service
function,
so
practically
a
real
new
topology
entity.
E
The
important
point
is
that
from
the
path
computation
perspective,
as
I
said,
we
use
in
the
option
one
a
similarity
and
they
we
use
still
the
tunnel
termination
point,
but
in
from
termination
point
perspective,
the
part,
the
the
the
ttp
the
tunnel
termination
is
an
input
of
a
part
computation.
So
is
this
not
subject
subject
at
constraint
or
path?
E
Selection
from
treyarch
instead
is
different,
because
triara
is
an
output
of
a
part
computation
as
they
needed
to
have
the
capability
of
particular
information
that
permit
selection,
optimization
and
the
constraint,
for
example,
including
or
excluding
some
trial
with
respect
the
other
and
so
require
that
some
type
of
information
that
normally
tunnel
termination
point
does
not
need.
E
So
in
with
the
d
option,
this
this
option
two.
We
have
no
behavior
changing
in
the
in
the
path
computation
because
the
ttp
is
separated
from
3r.
E
It
is
this
option.
Two
is
a
a
more
natural
approach.
Top
down
so
based
on
the
on
abstraction
and
providing
a
service
function
is
client
friendly
because
you
have
a
topology,
unique
identification.
E
You
have
an
indication
of.
You
can
easily
indicate
the
feasibility
of
the
resources
or,
if
the
resources
is
taken
by
another
service
and
okay,
the
triometric.
We
said
that
we
have
also
the
theometric
also
in
the
option,
one.
E
The
last
point,
but
not
least,
is
that
okay,
the
trial
functionality
is,
we
know
that
is
not
always
at
the
layer
zero,
because
this
the
regeneration
is
provided
also
considering
the
audio
part
and
the
service
function
is
inherently
modeling
layer
violation
and
it
protects
this
possibility
for
possible
concern
regarding
the
layer
violation.
E
E
Next:
okay
for
the
c
plus
l
band,
we
have
completed,
as
I
said,
the
addition
related
to
the
rhodam.
We
base
this
on
the
capability
to
provide
linkedid
and
application
od,
so
to
identify
uniquely
amplifier,
so
solve
the
issue
to
have
more
than
one
amplifier
on
one
band.
E
E
E
E
Okay
for
the
open
issue,
we
have
close
six-
I
I
I
put
here
the
github
link
in
which
you
can
see
and
track,
and
it
is
tracked
the
opposition
of
our
drafts.
We
have
a
close
six
issue
from
the
last
itf
meeting.
E
We
have
still
20
first
open
issue,
but
two
of
them
out
of
them
are
a
typical
young
issue
not
related
to
our
drafts,
and
so
we
have
some
clarification
and
then
and
need
to
raise
point
to
to
to
the
net
mode,
and
we
have
at
least
five
of
these
issue
in
which
we
have
already
discussed
a
proposal,
and
so
we
need
just
to
wait
for
the
next
pull
request
to
to
to
fix
the
point
and
the
the
other
real
we
have
from
a
real
pending
enhancement
of
the
model.
E
We
have
just
three
issue,
because
the
83
and
23
is
all
related
to
the
pending
issue
related
to
the
trial,
so
the
real
enhancement
of
the
model.
The
issue
is
just
three
related
issues.
E
Next,
please,
okay,
so
we
mentioned
that
we
have
still
an
issue
related
to
the
trial.
The
issue
is
related
to
how
to
assert,
as
I
said,
that
the
trial
functionality
is
done
by
a
pair
of
of
a
transceiver.
E
E
So
in
this
picture
we
just
represent
the
case
of
the
of
the
single
otsi.
So
no
no
problem
in
this
case
to
associate
that
this
is
what
is
represented
here
is
the
only
directional
case
architecture.
E
But
in
case
instead
we
have,
for
example,
a
digital
client
at
400
gigabit
that
will
be
supported
by
20
at
200
gigabit.
In
this
case,
we
need
at
the
at
the
regenerator
point
to
mix
and
invert
multiplexing.
E
In
this
case,
you
need
to
have
inverse
multiplexing
on
the
other
side
of
3rd
generator,
and
in
this
case
it
is
not
clear
how
I
can
connect
the
transceiver
5,
for
example,
with
the
transceiver
8
or
transceiver
seven.
What
is
the
characteristic
information
that
is
needed
to
to
see
that
this
is
the
real
connectivity
that
you
mean
one
of
the
possibility
that
has
been
discussed
to
solve
the
issue
is
to
have
a
pull
of
transceiver
and
to
connect
this
pool
of
transceiver,
not
one
to
one.
E
This
is
one
of
the
possibility
that
we
discussed
in
case
instead,
the
trial
is
made
up
the
op
at
the
otsi
part.
In
this
case,
we
have
no
issue
because
it
is
a
one-to-one
and
there
is
no
inverse
multiplexing.
E
The
same
is
even
if,
with
the
characteristic
of
the
unidear
happen,
in
the
case
of
unity,
this
is
what
is
represented
here
for
the
unidir.
There
is
also
the
point,
but
we
can
solve
that
of
the
association
on
the
transceiver
that
is
providing
the
one
of
the
direction,
for
example
transceiver,
5
and
receiver
7,
but
also
in
this
case
we
can
have
inverse
multiplexing
unless
we
are
still
at
otsi
pro
tsi
level
of
3r
functionality.
E
E
So
the
first
we
needed
to
finalize
the
trial
functionality
with
the
association
required
addressing
the
issue
that
we
in
which
we
already
have
a
discussion
solution
that
imply
both
some
model
enhancement
and
the
editorial
adjust
editorial
announcement
and
the
the
plan
is
to
be
ready
for
doctor
review
for
the
next
itf
meeting,
with
also
the
hope
that
will
be
face
to
face
and
to
have
a
stable
version
by
the
end
of
the
year.
This
is
the.
A
A
Question
actually,
I
know
most
of
the
people
interested
in
this
topic
are
attending
the
weekly
calls,
but
maybe
I
don't
know
if
it's
worth
bringing
to
the
list
of
the
discussion
on
the
two
options
on
on
three
hour
regeneration
to
to
to
get
a
little
bit
more
feedback
from
from
the
working
group.
I
don't
know
how
you
feel
about
that.
Do
you
think
that
the
the
situation
is
mature
enough
to
come
to
the
mailing
list
and
discuss
the
pros
and
cons
about
the
two
options
there.
E
Well,
we
have
a
solution,
a
young
solution
at
the
moment,
but
yes,
I
mean
the
discussion.
In
my
view,
there
is
no
one
model,
one
option
that
is
right
and
the
other
wrong.
Depending
of
the
perspective,
as
I
I
try
to
depict,
one
is
a
bottom-up
approach.
The
other
is
up
up
down.
E
So
is
a
bit
different
point,
but
there
is
no
one
is
right,
the
other
wrong,
so
the
choice
that
we
made
to
go
for
the
moment
with
the
with
this
solution
is
that
that
molotow,
the
majority
of
the
the
people
in
the
in
the
team
was
more
in
favor
to
to
to
that
option.
But,
frankly
speaking,
no
one
has
said
that
the
other
is
wrong.
So
that's
right.
F
E
E
In
the
sense
that
the
discussion
has
been
done
but
well,
I
probably
I
do
not
expect
many
help
today,
but
well.
A
E
So
we
said
okay
for
the
moment,
since
the
majority
is
more
happy
with
the
this
type
of
option,
try
to
have
the
young
model
based
on
that
and
provide
the
information
to
the
working
group
so
that
they
are
aware
the
fact
that
has
been
a
discussion,
that
there
is
two
options
and
again
no
one
of
the
two
are
wrong,
but
just
a
choice
of
the
preference
of
the
majority
of
the
of
the
of
the
team.
But
since
the
the
draft
is
a
working
group
draft.
E
A
E
Okay,
here
is
the
update
of
the
draft,
that
is
a
layer,
zero
type
extension
just
a
next
slide.
Sorry,
okay,
just
a
brief
background
of
the
scope,
and
why
is
has
been
introduced
this
this
draft,
the
layer,
zero
type
and
this
is
represented.
E
The
last
version
has
been
reduced
in
the
scope,
addressing
just
a
spectrum
management
to
cover
just
impairment,
free
optical
draft,
in
order
to
progress
the
layer,
zero
type
towards
the
the
publication
and,
in
parallel
to
permit
to
go
ahead
with
the,
for
example,
atf
was
on
topology
that
is
based
on
this
importing
of
this
layer,
zero
type.
E
So
we
we
have
a
addressing
in
this
draft
instead
the
complementing
of
the
content
of
the
xero
type,
reconciling
what
are
the
various
information
regarding
transponder
that
was
spread
in
different
drafts
in
the
second,
covering
the
information
regarding
the
impaired
impairment
aspect
and
using
for
many
of
the
draft
in
c
camp.
A
common
young
structure
and
definition,
and
the
intention
of
this
draft
is
to
have
a
life
cycle
parallel
of
layer.
E
The
next
slide,
please
daniel
that
I
already
commented
last
time,
but
just
reporting
what
I
I
said
by
words
and
providing
the
schema
of
the
life
cycle
of
layer,
zero
type
extension
and
the
zero
type
with
the
example
of
in
the
bottom
of
the
optical
impairment,
that
is
importing
already
layer,
zero
type
extension
structure.
E
The
intention
is
that
also
the
interface
parameters
that
gabriele
or
gert
will
talk
about.
After
this
presentation
we
also
introduce
and
use
the
same
grouping.
We
added
new
identities
for
power
equalization.
E
We
move
definition
of
the
phab
type
identities.
We
have
a
new
grouping
for
penalties,
relative
polarization,
dependent
loss.
We
added
the
new
grouping
related
to
the
c
plus
l
band
and
change.
Also,
the
definition
of
a
specific
attribute,
like
otsi
carrier
bandit
and
related
attributes
like
a
nyquist
spacing
factor
or
loft
crosstalk
penalty.
All
these
have
been
introduced
from
the
last
version.
E
Next,
please
so
the
next
step.
The
first
step
is
the
work
group
adoption.
E
The
ipr
polling
is
practically
completed
because
it
was
missing
just
one
vote
but
now
is
arrived,
so
I
would
expect
that
the
polling
for
working
group
adoption
can
start
as
soon
as
that
after
itf,
I
suppose,
and
and
then
obviously
the
the
scope
of
this
draft
is
the
other
other
young
structure
that
can
be
used
and,
by
other
all
the
other
drafts
and
promoting
the
the
aspect
of
sharing
as
soon
as
possible.
The
same
structure
for
layer,
zero
model
in
c
camp.
E
H
G
The
document
itself
is
is
a
is
very
good
and-
and
I
like
it,
but
also
I
saw
that
there
is
an
extension
of
zero
type,
and
I
would
like
you,
daniel
and
fertile
to
to
indicate
the
way
we
can
proceed
with
the
extension,
because
the
extension
is,
as
far
as
they
saw
is
is
is
important
as
well
of
the
as
this
have
the
working
group
documents.
So,
even
if
the
extension
is
still
an
individual
contribution.
A
G
A
G
Right
away
available
in
terms
of
consolidated
document
so
yeah
for
example-
that
is
I
I
can
talk
later
on
this
point
at
the
end
of
my
presentation,
just
to
clarify.
D
G
I
I
think
what
what
we
were
hoping
to
hear
was
the
chair
say:
yeah.
Now
we've
done
the
igr
polling.
We
are
going
to
start
the
adoption
poll
on
pick
a
date
and
let
us
know,
rather
than
just
it's
sort
of
in
the
queue.
A
We
we
will
be
starting
it
after
the
after
the
itf,
if
I'm
not
mistaken,
that
one
one
reply
was
missing,
that
that's
what
we
were
waiting
for.
I
A
E
In
the
sense
that
yes,
the
last
vote
has
been
completed
in
the
last
two
three
days,
because
one
of
the
outdoors
was
vacation
so
and
so
come
back
and
already
answer
so
yeah
at
the
moment,
ipr
we
can
consider
concluding.
Okay,
that's
great.
I.
G
So
gabriele,
okay,
thank
you!
Thank
you,
so
gabrielle
bertie
and
I
present
now
the
state
of
the
art
of
the
dwm
interface
parameters,
young
on
behalf
of
the
other
quarters,
and
next
like
this.
G
So
the
goal
here
is
a
pretty
evident
and
consolidated
number
one
is
to
define
the
set
of
parameters
good
enough
to
let's
say
understand
what
kind
of
interface
a
possible
controller
is
starting
to
manage
and
then
also
to
keep
all
this
information
aligned
with
the
other
atf
working
group
documents,
like
they,
parent
impairment,
topology
layer,
zero
types
and
so
on.
G
Okay,
since
the
last
version,
we
did
a
lot
of
modification.
G
G
So
what
we
did
is
to
reshape
all
the
optical
impairment
models,
trying
to
make
them
closer
to
the
to
the
t,
topology
optical
models.
G
This
make
the
possibility
to
retrieve
from
the
module
the
three
kind
of
information
so
can
address
by
the
standard
models,
organizational
models
and
also
the
esprit
explicit
models
in
the
last
version
of
the
document.
Actually,
we
were
covering
only
the
explicit
models
and
the
standard
models
so
that,
if
you
look
at
the
the
topology
optical
young
models,
you
and
you
you
look
at
the
models
we
define
in
this
document
are
pretty
the
same.
G
G
We
can
also
retrieve
or
correct
the
current
models
and
then,
of
course,
it
is
possible
to
provision
some
some
some
other,
some
parameters.
That
is
the
way
we
we
reshape
the
the
document
next
slide.
Please.
G
But
we
have,
we
have
to
clarify
a
point
here.
So
basically,
the
supported
models
are
all
read-only.
The
current
models
are
all
redundant.
G
G
G
But
let
me
say,
the
number
of
the
the
information
will
flow
back
and
forth
from
the
module
to
the
controller
is
could
be
quite
a
lot,
the
other
one,
the
option
to
could
be
more
efficient
and
effective,
but
we
needed
to
define
different
kind
of
models
for
the
provisioning
models.
That
is
something
we
need
to
discuss
and
address
for
the
next
time.
G
Of
course,
we
need
to
keep
always
an
eye
to
the
iqt
recommendations
and
the
revolution,
because
we
don't
want
to
misalign
the
itilt
for
the
standard
models
we
we
have
to
keep
in
sync
with
the
optical
impairment,
topology
young,
as
well
as
the
layer,
zero
types
and
as
soon
as
the
layer,
zero
type
extension
would
become
a
working
group
document.
At
this
point,
really,
we
could
use
the
new
definition
that
have
been
set
in
that
currently
individual
contributor
document,
aligned
with
the
terminology
and
and
on
the
contents
of
draft
and
so
on.
G
I
think
once
we
have
done
this
realignment
and
whenever
the
optical
impairment,
topology
young
and
the
layer
zero
type,
we
go
to
the
last
call
just
after
a
revision.
G
Also,
this
document
could
be
could
go
in
last
call,
that's
that's
all
from
my
side.
F
C
Why
ask
a
question
sure,
so
I
think
this
would
pay
that
close
attention,
but
am
I
writing
saying
this
model
augments
the
itf
interfaces
model?
Is
that
what's
been
proposed
here?
C
If,
if
so
my
question
is,
is,
is
the
interface
there's
been
modeled
here,
just
a
layer,
one
an
optical
construct,
or
does
it
still
have
like
the
layer,
two
properties
that
the
itf
interface
normally
has.
G
Okay,
this
this
draft
cover
only
the
layer
one
and
is
extending
the
interface
mode,
the
itf
interface
model.
So
if
you
look
at
the
layer
2,
for
example,
you
should
look
at
the
interface
model
already
available
in
atf,
so
so.
C
G
G
D
G
Building
block
at
that
point:
yes,
we
we
start
talking
about
auto
audio
statistics,
but
again
there
are
other
kind
of
documents
are
already
available
covering
this
part,
and
but
what
what
probably
is
missing
is
is
a
document
that
is
joining
all
the
different
layers
together
in,
in
a
way
that
from
ethernet
statistics
you
can
correlate
the
photonics
statistics.
C
G
G
We
should
start
from
from
a
different
route.
A
different
naming.
The
idea
at
the
at
the
beginning
was
okay,
as
we
are
talking
about
interfaces,
and
we
see
that
there
is
already
the
final
bunch
of
interfaces
starting
from
layer
2
whatever.
Why
not
also
adding
the
dwdm
interface
as
well.
At
the
end,
if
you
look
at
the
router,
you
can
have
a
layer
to
interface
gigi.
Thank
you,
100
gig,
as
well
as,
for
example,
a
dwdm
interface
today.
G
C
Yes,
I
just
think
there's
a
sort
of
an
implicit
assumption
that
the
things
that
are
in
itf
interfaces
today
you'd
expect
to
be
able
to
do
either
l2,
switching
over
or
l3
forwarding.
So
I
think
we
should
need
to
be
careful
here
and
just
check
that.
That's
that
we're
not
effectively
breaking
some
assumptions
by
complementing
that
one.
G
I
I
understand
what
you
have
in
mind
and
maybe
could
have
sense,
but
probably
need
to
discuss
more
in
detail
on
how
to
to
drive
this
solution.
Okay,
thanks.
Thank
you.
D
G
J
Okay,
okay,
thank
you
carefully.
I'm
noticing
your
slides,
maybe
pick
number
three
you
are
mentioning.
We
are
aligning
with
the
mode
id
from
the
impairment
module.
But
when
I
read
the
draft
it
looks
like
we,
we
are
using
the
g
dot
698.2
instead
of
a
standard
mode,
so
is
it
deliberately
or
or
we
have
some
some
reason
behind.
A
D
A
A
F
Thanks
guys
hi
everyone,
this
is
a
relatively
short
update
on
the
flexigrid
work.
We
have
two
documents
currently
in
progress.
We
have
the
flexi
grid
topology
document,
so
this
obviously
describes
sort
of
the
components
that
we
use
to
generate
the
flexigrid
topology
and
then
we've
got
a
companion
document,
which
is
the
the
flexi
grid
media
channel
document.
So
this
is
essentially
setting
up
our
tunnel
across
our
flexi
grid
topology.
F
So,
let's
start
with
the
first
document,
so
we've
been
working
on
this
for
a
while.
Now
we
are
up
to
version
10,
it's
it's
now
stable.
We've
had
a
early
review
from
the
young
doctor,
so
thank
you
very
much.
We
essentially
received
a
number
of
really
useful
comments.
Some
were
editorial
others
in
sort
of
direct
relation
to
the
yan
code
itself.
F
We
we
we
have
responded
to
the
list
regarding
these
sort
of
yang
code
issues
and
we
do
need
to
follow
up
a
couple
of
these
comments.
There
are
sort
of
things
about
use
of
containers
and
things
like
when
statements
as
well,
but
but
we've
we've
tried
to
be
consistent
in
sort
of
defining
when
statements
with
some
of
the
other
yang
work,
including
wson.
F
So
we
think
we
don't
think
there's
a
particular
issue,
but
we
would
just
like
to
clarify
that,
with
with
the
young
doctor,
in
addition
to
sort
of
just
cleaning
up
the
code,
the
most
recent
version
includes
a
much
more
detailed
explanation
on
how
we
augment
some
of
the
the
imported
yang.
So
these
will
be
things
like
how
we
use
the
topology
and
so
tt,
topology
and
tunnel,
and
also
things
like
how
we
use
bandwidth
and
things
like
label,
augmentation,
attributes,
etc.
F
We
have
now,
I
believe,
agreed
on
the
prefix
to
the
naming
pre-prefix.
F
So
we've
we've
updated
the
document,
it's
now
flex
gt,
so
flexi
grid
topology,
and
this
this
should
now
be
consistent
with
all
of
the
other
documents,
some
of
which
have
already
been
updated
as
well
to
remove
the
hyphen.
It
just
seems
to
be
one
of
those
discussions
that
that
just
seemed
to
go
on
for
a
long
time
with
lots
of
opinions,
but
it's
good.
I
think
that
we
finally
reached
a
conclusion
there.
F
There
were
sort
of
several
comments
actually
made
by
a
couple
of
the
more
recent
reviews
about
the
use
of
informative
and
normative.
Obviously,
if
this
has
to
be
implemented,
this
document
needs
to
be
implemented.
Then
we
have
to
be
very
clear
about
any
ancillary
work
that
that
should
also
be
reviewed
or
understood
in
detail
in
order
to
actually
implement
this.
So
I
think
we've
we've
made
those
changes
now
and
and
moved
what
were
sort
of
informative
to
normative,
but
it's
probably
worth
just
taking
another
look
at
that.
F
If
you
have
a
vested
interest,
I
suppose
I
should
just
say
thank
you
to
adrian
and
helmi
and
for
their
reviews
of
this
document
as
well,
and
there
there's
also
been
some
parallel
discussion
with
another
document
that
the
working
group
worked
on,
which
is
the
ietf
c
camp,
wson
yang
document.
F
I
think
it
was
mentioned
actually
by
danielle
starch
and
that
that's
currently
in
the
rfc
editor's
queue
and-
and
there
was
a
couple
of
open
issues,
some
sort
of
main,
very
minor
things,
but
but
one
thing
that
may
impact
not
only
the
flexi
grid
yang
work
but
maybe
other
c
camp
young
documents
is
really
regarding
the
security
section
and
the
security
considerations.
F
So
there's
there's
been
sort
of
some
pushback
by
the
rfc
editors,
just
to
make
it
very
clear
what
the
security
implications
are
for
some
of
this
yang
work,
certainly
in
regards
to
wson
anyway,
and
that
that
that
includes
things
like
you
know
what
what
may
be
writable
and
what
modules
sort
of
augment
additional
data
nodes
from
say,
itf,
network
or
t
topology,
and
making
sure
that
make
it
very
clear
that
we
we,
we
potentially
inherit
some
of
those
sensitivities
or
particular
sub-sub
trees.
F
So
so
any
potential
issues
equally
applied
to
the
new
data
nodes.
You
know
that
that
that
we
have
in
in
the
wson
or
the
flexi
grid
or
the
microwave
yang
model.
So,
thank
you
very
much
actually
to
john
our
illustrious
ad
for
sort
of
reaching
a
conclusion
here.
So
I
guess
the
the
the
net
net
is
we're
going
to
update
the
security
section.
F
I
think
very
minor
updates
just
to
say
that
we
do
sort
of
reuse
some
of
the
existing
security
best
practice-
that's
defined
in
in
other
young
modules,
but
also
be
aware
that
these
nodes
are
writable
and
therefore
present
security
risks.
F
I
think,
therefore
we
are
very
close
to
sort
of
having
a
final
version
that
will
be
ready
for
last
call.
So
it's
just
really
the
security
section
that
needs
to
be
updated
now
and
then
addressing
some
of
the
some
minor
things,
some
knits
things
like
the
the
date
of
code
generation.
I
think
that
that
was
another
issue,
so
I
think
these
are
all
tracked
in
our
github,
so
you
can
see
that
on
the
url
there.
F
Document,
good,
okay,
excellent,
so
the
the
media
channel
is
the
sort
of
the
the
connection
across
the
flexi
grid
topology.
So
it's
our
flexi
grid
tunnel.
F
It
was
sort
of
put
on
hold
really
until
we
finished
the
discussion
on
the
flexigrid
topology,
we
issued
a
new
version
of
a
relatively
old
document,
actually
just
just
before
the
last
ietf,
and
we
we've
transitioned
our
weekly
flexiwood
call
and
sort
of
bi-monthly.
Actually,
it's
not
necessarily
weekly
from
the
topology
discussion
to
the
media
channel
discussion.
F
So
it's
still
a
relatively
recent
document
without
a
significant
amount
of
of
new
code,
there
are
essentially
a
basic
yang
proposal
that
that
is
in
the
the
latest
version
of
the
document
I
think,
is
zero.
Three.
We
still
have
lots
of
of
discussion.
I
think
ahead
of
us
how
this
actually
gets
used.
There's
a
excuse
me
sort
of
the
limited
set
of
vendors
that
that
are
implementing
or
have
implemented
as
well.
So
it
will
be
good
to
know
if
there
are
beyond
the
document
authors.
F
If
there
are
other
vendors
who
who
have
implemented
or
are
implementing
or
considering
implementation.
You'll
be
very
welcome
on
the
call
and
we
do
try
to
copy
updates
from
the
calls
directly
to
the
list
as
well
to
make
sure
that
the
working
group
are
are
in
fact,
you
know
part
of
this
development
process.
F
So
the
sort
of
the
main
changes
really
are
things
like
using
the
new
prefix.
We
added
a
security
section
sort
of
a
trending
topic
right
now
we
fixed
a
variety
of
young
errors
that
were
mainly
sort
of
historic,
because
this
document
hadn't
been
updated
in
in
over
a
year
and
just
just
just
tried
to
make
the
more
sort
of
the
document
more
re-readable.
F
What
what
we
will
need
to
add
for
the
next
version
is
kind
of
the
data
model,
augmentation
aspects
as
well,
so
you're,
what
we
augment
and
and
and
how
we
augment-
and
I
I
guess
we
may
sort
of
hit-
that's
that
issue
again
of
the
use
of
when
statements
and
things
as
well.
We
will
restart
the
flexigrid.
F
F
So
people
are
are
very
welcome
to
attend,
and
then
I
guess
we
will
just
issue
various
iterations
and
you
know
try
to
encourage
working
group
members
to
review
and
comment
and
then
hopefully
we
have
a
a
more
sort
of
a
version
of
the
documents,
more
substantive
in
time
for
itf-112.
F
So
any
questions.
F
Anyone
still
awake
does
everyone
still
hear
me
yeah?
Yes,
okay,
good
well,
unfortunately,
for
you,
I
also
have
the
second
presentation,
so
let
me
just
jump
straight
into
that
cool.
So
what
am
I
talking
about?
Yes,
applicability
statements,
yes,
indeed,
just
a
general
comment.
First
of
all,
so
this
there's
two
statement:
there's
two
applicability
statements,
I'm
going
to
be
talking
about
now.
The
first
is
the
transport
or
transport
mbi
applicability
statement,
and
then
the
the
second
document
isn't
actually
a
ccamp
document.
F
It's
a
tease
document,
but
because
it
relates
to
optical
packet,
optical
integration,
and
there
are
sort
of
various
c-com
documents
that
are
referenced
in
the
applicability
statement.
F
We
thought
it
might
be
nice
for
you
just
to
sort
of
get
an
overview
of
the
document
and
just
be
sort
of
made
aware
of
the
document
and
just
just
a
general
comment
that
as
sort
of
engineers,
we
tend
to
be
sort
of
quite
good
at
inventing
technology
and
and
protocol
mechanisms
and
and
sort
of
crafting
bits
and
bytes
or
generating
yancode
to
define
function.
F
But
we
off
we,
we
we
often
lack
some
of
the
sort
of
the
bigger
picture
aspects.
As
you,
how
how
are
these
young
models
or
these
protocols
going
to
be
used?
Are
they
fit
for
purpose?
What
are
the
use
cases?
Are
they
applicable?
Are
there
issues?
What
are
the
gaps?
Are
there
operational
considerations
that
we
never
considered?
Are
we
going
to
break
things
quite
significantly?
F
So
so
I
think
these
these
applicability
documents
tend
to
be
really
useful
and
it's
it's.
It's
certainly
a
good
way
to
kind
of
advertise
how
some
of
the
technology
we've
developed,
gets,
applied
and
certainly
any
gaps
if
identified.
Then
then
those
are
obviously
generally
quite
important
to
fix.
So
this
this
first
document
was
the
sort
of
the
product
of
a
design
team
that
that
dates
back
to
2018..
F
So
thank
you
very
much.
The
long
list
of
people
there.
We
have
published
the
the
the
output
essentially
from
that
design
meeting
and
it
was
sort
of
we
had
a
mini
charter
which
was
really
just
sort
of
identify
the
use
cases
for
the
transport
mbi.
F
So
we
essentially
had
things
like
odu
transit
epl
over
odu
as
well,
attributey,
slash,
transparent
client
services,
etc,
and
then
a
variety
of
topologies
with
things
like
sort
of
protection
requirements,
protection
and
restoration,
and
then
what
we
could
do
is
identify
well,
what
are
the
young
models
that
we
would
use
in
order
to
deliver
those
types
of
services
over
these
specific
yang
models?
How
do
we
protect
them?
F
How
do
we
secure
them
and
maybe
even
sort
of
more
fundamentally,
you
know
how
do
you
compute
them
as
well,
so
there
are
sort
of
path,
computation
aspects
there
as
well.
So
it's
a
relatively
large
document,
because
this
is
not
your
simple
technology.
I
think
we're
up
to
sort
of
100
plus
pages
and
a
variety
of
models
are
applied
and,
as
you
can
see
from
the
topology
itself,
the
reference
network
is
complex.
I
suppose
we've
got
multiple
domains
with
sort
of,
inter
into
a
s
into
domain
networking
required.
F
So
this
is
sort
of
at
the
fundamental
level,
our
otn
network,
with
tributy
interfaces
attached
to
routers
across
the
across
the
optical
network.
F
Then
we've
got
an
action-based
control
hierarchy,
so
we've
got
mdse
and
your
our
focus
is
really
on
the
mpi's
and
those
will
be
the
interfaces
between
the
domain
controllers
for
each
of
the
specific
sort
of
maybe
technology,
specific
vendor
specific
or
some
kind
of
supervisor.
Slash
sphere
of
responsibility,
you're
going
to
have
a
sort
of
different
controller,
slash
management
entity
for
each
of
those
domains.
F
And
then,
when
we're
ready
to
kind
of
set
up
the
the
sort
of
logical
connectivity
to
carry
the
the
client
signals
the
service
itself
across
the
topology.
Then
we've
got
the
the
tunnel
setup
which
is
sort
of
sort
of
te-based
and
then
the
client
set
up.
F
So
we
we
go
through
all
of
the
phases,
so
sort
of
discovery
or
or
maybe
a
precursor
to
that
is
inventory
management,
topology
discovery,
maybe
sort
of
capability
exchange
negotiation,
not
just
between
the
nodes
which
may
be
sort
of
lldp
or
lmp,
and
that's
that's
generally
sort
of
out
of
scope
anyway,
because
it's
quite
sort
of
proprietary,
but
also
how
the
the
mdsc
and
the
pnc
relationships
are
established.
Maybe
that's
statically,
maybe
maybe
there's
an
automation
or
automated
requirement.
F
There
as
well
and
then
we've
got
sort
of
the
tunnel
set
up
and
then
the
client
set
up,
which,
which
includes
things
like
mapping
of
signals
into
tunnels
and
things
and
and
of
course
there
could
be
a
variety
of
abstraction
methods
that
are
applied
here
so
for
some
pncs
they
may
explode,
expose
the
full
topology.
F
Other
pncs
may
only
exposed
a
you
know
a
effectively
a
single
hop
across
the
network.
It's
an
abstracted
topology,
so
we've
got
the
sort
of
black
topology
white
topology.
F
F
There
are
now
a
variety
of
open
issues
with
the
document
itself
and
it's
it's
mainly
sort
of
editorial
and
we
we
will
now
need
to
kind
of
work
through
those
we
had
a
a
a
routing,
direct
review
from
dhruv
who
did
a
sort
of
a
sort
of
a
a
really
monumental
sort
of
effort,
because
there's
so
much
content
here
and-
and
you
know
he-
he
he's
obviously
very
experienced
with
a
variety
of
technologies
but
sort
of
bringing
all
of
these
together
for
the
applicability
statement.
F
F
F
So
these
are
all
essentially
generated
using
json,
and
then
you,
you
can
sort
of
translate
that
whatever
sort
of
hyper
polyglot
you
want
to
use
to
your
favorite
schema,
but
but
we've
used
json.
We
also
developed
a
tool
that
would
allow
the
json
code
to
be
well
encoded,
not
only
in
the
document
but
extrapolated
from
the
document
and
then
sort
of
compiled.
Obviously,
because
of
the
things
like
the
72
character
limitation,
we
we
will
need
sort
of
next
steps.
F
Now
we
will
need
to
have
a
sort
of
an
editorial
session.
I
think
italo
and
myself
have
volunteered
to
do
this,
just
to
kind
of
go
through
the
document
and
make
the
necessary
changes
just
for
readability
and-
and
there
is
a
lot
of
cross-reference
in
in
the
document-
we
refer
to
a
variety
of
figures
and
sections
and
just
making
sure
all
of
those
are
sort
of
consistent
where
we
kind
of
reference
within
the
document.
F
I
think
it's
better
if
we
just
have
sort
of
two
editors
for
that
session,
anticipating
sort
of
half
a
day
to
do
that,
and
and
then
we
will
publish
the
new
version
of
the
document,
respond
to
dhruv
our
sort
of
routing
area
directorate
reviewer,
and
then
we
will
request
other
members
of
the
working
group
now
review
the
document.
F
F
Your
substantive
information,
then
then
we'll
just
leave
it
as
is,
and
I
I
suppose,
the
other
issue
sort
of
highlighted
on
the
slide
here
really
for
next
steps
is
considering
just
sort
of
how
useful
this
document
might
be,
and
the
fact
that
we
do
reference
work
generally
sort
of
itu
work
as
well.
Should
we
remind
some
of
our
partners
or
other
sdos,
and
I'm
thinking,
thinking,
itu,
but
maybe
oaf,
maybe
even
mef?
F
Should
we
make
them
aware
that
that
we
now
think
the
document
is
stable
and
we
will
be
progressing
it
through
the
itf
process.
So
that's
kind
of
a
question
for
the
chairs
and
the
working
group
as
well.
F
We
yeah,
so
I
I
just
assumed
that,
because
we
were
going
to
make
some
edits
to
the
document-
and
they
may
be-
maybe
only
editorial-
that
we
would
have
to
go
through
another
last
school.
A
It
depends
on
the
type
of
edits,
because
I
mean
after
the
working
group
plus
coral,
there
is
a
number
of
iterations.
There
will
be
the
security
review,
the
operations
review,
et
cetera,
et
cetera
and
as
part
of
those
review,
there
will
be
comments
to
fix.
So
edits
are
for
sure
a
part
of
that.
If
they
are
not
major-
and
I
mean
this
is
an
informational
document,
so
I
don't
expect
that,
after
those
reviews
that
we
will
have
something
completely
different
that
needs
to
go
through
another
working
group
last
call.
A
I
think
that
all
all
of
the
changes
that
can
be
done
at
the
document
that
can
be,
let
me
say,
are
not
impacting
the
fact
that
the
document
has
already
passed.
The
working
group
plus
code.
F
Yeah
yeah,
okay
and
it
is
it
is
it's
definitely
editorial
okay.
So
so
I
think
what
what
we
can
do,
then,
is
italo,
and
I
will
have
our
review
session
and
and
sort
of
publish
the
the
new
version
of
the
document.
We'll
send
the
list
kind
of
an
update
of
of
what's
changed
and
and
you
if
there
is
some
something,
that's
substantive.
That
needs
to
be
reviewed
by
the
working
group
again
in
detail.
F
Then
then,
then,
obviously,
that's
the
decision
for
the
chairs,
whether
or
not
we
need
to
last
call
that
if
it
is
just
sort
of
the
editorial
and
just
just
cleaning
up
and
formatting,
then
great,
we'll
just
kind
of
continue
to
move
ahead
and
it
will
sort
of
progress
through
the
pipeline.
A
F
Yeah,
I
guess
I
guess
the
iesg
would
be
waiting
for
the
for
the
routing
directorate
review
as
well
before
sort
of
processing
that
and.
A
F
F
F
F
In
the
appendix-
but
I
know
I
I
know
that
we
may
get
some
pushback
that
that
this
is
a
particularly
long
document.
So
so
I
just
just
think
it's
worth
just
seeing
if
we
could
go
on
a
bit
of
a
dive.
That's
all,
but
but
yeah.
F
I
think
perfect,
I
saw
how
me
and
just
pop
up
in
the
in
the
virtual
mic
list,
yeah.
J
Yes,
thank
you
daniel
yeah.
Actually,
this
is
useful
work
and,
of
course,
we
are
having
more
modules,
so
so
it
would
be
also
necessary
to
reconsider
if
we
need
to
continue
working
on
that,
even
even
if,
after
the
publication
of
this
document.
J
F
This
is
an
ongoing
challenge
right,
some,
the
problem
that
we
have
and-
and
in
fact
it's
it's
kind
of
a
problem
that
we
have
with
the
next
document
I
was
going
to
talk
about,
which
is
the
the
applicability
of
acn
to
poi,
is
that
the
use
cases
are
continuing
to
evolve
and
what
what
we've
tried
to
do,
and
sometimes
it's
very
hard,
because
we
have
a
number
of
members
of
the
design
team
and
everyone
has
their
own
use
case
or
div
or
slight
sort
of
deviation
of
the
use
case.
F
F
It's
it.
You
know
it
it's
a
it's.
We
have
to
be
very
careful
because
it's
a
bit
of
a
trap.
As
soon
as
we
start
sort
of
extending
the
use
case,
the
document
suddenly
becomes
massive.
You
know
exponentially
bigger
in
terms
of
of
problems
and
gaps
and
and
what
what
we,
what
we
should
be
really
careful
about
is
never
closing
these
documents.
They
almost
become
living
documents.
F
There's
you
know
this
is
a
wider
discussion,
maybe
for
the
ads
and
and
the
chairs
and
the
working
group,
and
it
you
it
should
we
think
about
some
of
these
applicability
statements
in
the
future
as
a
as
as
things
that
could
be
published,
but
then
sort
of
continually
update
it
without
going
through
sort
of
the
the
current
method
of
an
rfc
bis
or
something
so
so,
yes,
thank
you
helmian.
That
is.
That
is
a
good
point.
F
No
problem
fully
agree:
yep,
thank
you
and
it's
it's
well
well
done
for
staying
up
so
late
or
getting
up
very
early
or
I'm
not
sure
what
it
is,
but
it
must
be
like
4am
in
china
at
the
moment.
F
F
I
think
the
motivations
are
or
the
intention
of
the
work
is
very
similar
to
our
sort
of
applicability
of
the
of
the
transport
northbound
interface,
and
that
is
you:
how
do
we
use
these
technologies
so
in
this
case
the
actin
architecture,
the
various
functional
components,
the
apis
and
our
technology
specific,
in
this
case
optical
and
some
packets,
yang
models
for
actually
setting
up
poi
services
in
in
provider
networks
and
and
it's
again
it's
kind
of
a
due
diligence
of
your
are:
are
the
various
itf
documents
suitably
informative,
clear
about
how
to
use
the
technology,
how
to
apply
it?
F
How
to
implement
it?
Are
the
yang
models
themselves
suitable
for
specific
use?
Cases?
Do
they
contain
the
necessary
information?
Are
they
implementable
and
then,
if
gaps
exist?
What
are
they
do?
We
need
to
extend
existing
young
models.
Do
we
need
you,
so
you
new
yang
models
and
then,
of
course,
there's
the
sort
of
operational
and
security
aspects
as
well
with
the
the
ac
tn
poi
work.
Actually,
we
did
find
a
significant
number
of
of
gaps
and
that
has
sort
of
spawned
additional
sort
of
yang
development.
So
so
it's
been
a
really
useful
exercise.
F
So
this
is
a
slightly
simpler
topology.
So
there
are
a
number
of
domains,
two
packet
and
two
optical,
and
then
there
were
sort
of
some
slight
sort
of
variation
of
scenarios
here.
So
this
could
be
this
entire
network
could
be
single
provider
single
operator
or
it
could
be
multi-provider
multi-operator
and
it
may
be
multi-provider
multi-operator
of
the
packet
only
but
then
single
provider
at
the
optical
or
it
could
be
in
you
know
some
situations
and
sort
of
optical
interconnectivity.
F
Between
providers
has
kind
of
been
sort
of
fraught
with
all
sorts
of
pitfalls,
but
you
know
increasingly,
there
is
more
integration
as
well
as
a
requirement
for
automation,
so
we
are
considering
the
sort
of,
inter
as
inter
domain
provider
at
the
optical
layer
as
well.
F
So
we
cover
the
startup
phase,
so
things
like
interface,
link,
discovery
and
then
you're
right
through
the
sort
of
the
optical
going
up
the
stack
into
the
packet
aspects
as
well
as
sort
of
srt
path,
discovery
as
well,
so
that's
kind
of
the
first
phase
of
of
the
use
case
and
then
the
second
phase
is
you
know:
how
do
we
set
up
the
services?
So
how
do
you
communicate
the
request?
F
How
do
you
specify
the
constraints?
What
are
the
objective
functions?
Compute
the
service
now
set
it
up
and,
of
course,
that's.
That's
kind
of
a
multi-layered
approach
with
the
server
layer
providing
connectivity
that
then
gets
exposed
to
the
to
the
client
layer
or
you
know
whatever
you
want
to
call
it,
the
the
the
underlay
or
versus
the
overlay
and
then
sort
of
we've
kind
of
focused
on
srt
path,
setup
as
well
cool.
So
what
what
are
the?
F
F
Yes,
of
course,
but
but
typically,
these
systems
have
been
proprietary
and
sort
of
provider,
specific
operator
specific.
But
now
there's
there's
more
of
a,
I
think,
a
demand
for
having
an
interoperable
capability.
So
you
could
have
offline
network
inventory
that
could
be
made
available
when
you're
setting
up
a
particular
type
of
services,
because
there's
a
lot
of
sort
of
ietf
technology
that
just
presumes
that
that
setting
up
a
service
is
sort
of
computed
across
online
resources.
F
F
Up
right,
so
so
so
so
these
are
the
the
various
gaps
that
we're
identifying
there
are.
F
The
discussions
are
generally
sort
of
via
a
a
weekly
conference
call
and
issues
are,
are
documented
and
specified
as
as
part
of
the
github.
So
you
can
see
sort
of
the
open
issues.
I
won't
spend
any
time
going
through
those,
obviously
I've
just
taken
too
much
time
already,
but
considering
the
the
area
of
technology.
We
just
wanted
to
highlight
this
document
for
for
people
that
may
not
have
seen
it
if
you.
If,
if
you
have
the
time,
then
we
would
certainly
appreciate
a
review
of
the
documents.
D
D
D
J
Okay,
good
just
thank
you.
This
is
harming
speaking
and
I'm
presenting
two
documents
here
and
the
first
one
is
a
working
group
documents
c-cam
climb
signal
young
that
has
been
adopted
for
a
while
next
place.
J
So
it's
not
a
big
update.
This
time
we
have
just
revised
a
few
iterations
of
the
draft
to
integrate
the
e3
as
a
client
signal
in
this
update,
and
we
are
also
targeting
on
satisfied
multi-technology
applicability.
So
this
is
the
kind
of
supporting
of
the
poi
and
other
multi-technology
coordinations.
Next,
please.
J
So,
okay,
in
this
page,
we
have
two
main
changes
since
last
presentation-
and
the
first
one
is
just
mentioned:
is
the
module
is
extended
to
support
e3,
but
it's
not
in
the
main
module,
but
it's
in
the
in
the
ethernet
transport
types,
and
here
we
are
having
a
kind
of
access
rule
and
and
and
we
have
added
some
new
child
identities
and
there's
a
base
identity,
including
the
primary
rules,
backup
rule
and
the
leaf
for
excess.
J
So
so
these
three
rules
will
be
will
be
helping
the
configuration
to
be
complete
when
representing
our
e3
client
signal,
and
the
second
chain
we
have
made
is
an
editorial.
We,
we
actually
implemented
this
module
for
a
validation
in
omap
project
called
the
ccvpn,
and
we
in
this
project
we
have
been
using
the
ethernet
service
young
module
as
a
ctn
mpi,
and
we
included
in
two
into
this
document
as
a
independent
section,
with
the
the
referencing
to
to
the
onap
website.
J
Next,
please,
okay,
so
that's
all
the
change
for
this
document
and
we
are
also
checking
and
understanding
what
are
the
potential
gaps
so
far
and
we
are
trying
to
cover
more
client
signals
and
we
also,
we
are
also
driving
to
the
maturity
before
we.
We
request
work
for
working
group
last
call,
but
there
are
a
few
open
issues
still
and
we
believe
we
are
converging.
A
Do
you
already
know
which
other
clients,
in
your
signals,
are
you
planning
to
cover.
A
We
fall
into
the
problem
that
dan
was
describing
before
we
risk
it
to
have
an
endless
document
in
terms
of
versions.
J
J
J
This
is
an
individual
draft
and
the
previous
presentation
I
checked
it
was
on
108
it's
one
year
ago,
next,
please
and
yeah,
because
it's
one
year
from
now,
so
I'm
re-emphasizing
the
the
motivation
of
this
work
and
it's
highly
based
on
the
client
signal
document
presented
before,
because
this
is
a
the
documentary
specifying
how
to
do
the
performance
monitoring
based
on
the
client
signal
configurations,
and
we
are
summarizing
a
group
of
parameters
listed
in
this
table
from
layer
0
to
layer,
2,
switching
technology
and
it's
not
have
a
enumerated
anything
but
everything.
J
But
it's
a
kind
of
good
representation
of
what
kind
of
parameters
can
be
monitored
and
the
next
please
so
the
the
changes.
Okay,
we
are
now
having
two
more
co-authors
and
we
welcome
them
for
for
their
comments,
contribution
and
supporting.
J
We
made
some
editorial
changes
to,
especially
in
the
module
to
make
it
in
compliance
with
8407
guideline
of
young
modules,
and
we
have
also
extended
the
bandwidth
to
ingress
and
the
egress
bandwidth,
which
means
we
even
for
the
same
parameters.
We
are
monitoring.
We
are
extending
to
be
more
explicit
on
where,
where
the
the
parameter
is-
and
this
was
done
by
adding
to
a
new
child
identity
under
the
the
performance
parameter
types.
J
So
if
we
stay
from
the
perspective
of
secant
okay,
we
imported
the
the
the
two
client
signal,
configuration
modules
and
we
align
the
index
with
that
one.
Okay:
this
is
a
kind
of
advantage,
but
if
we
look
from
the
perspective
of
a
bigger
scope,
actually
there
are
more
than
one
performance
monitoring
drafts
in
itf
and
there
was
proposal
to
reuse
some
types
or
even
have
common
types
for
the
performance
monitoring
and
here
in
the
slides
we
are
listing
two
of
them.
J
One
is
from
the
test
working
group
talking
about
the
ict
and
telemetry
for
for
for
performance
monitoring,
and
the
other
is
from
best
who
is
doing
the
pm
on
the
vpn
level,
so
there
are
kind
of
overlapping,
but
not
fully
overlapping,
so
it
would
be
very
challenging
for
for
for
do
a
kind
of
cross
working
group
coordination.
J
J
Okay
and
the
second
big
issue
would
be
the
kind
of
module
structure,
so
we
will
capture
the
the
tree
so
far
and
we
are
using
one
unified
structures
to
do
the
monitoring
of
different
parameters.
J
J
We
need
to
also
looking
at
the
kind
of
features
for
for
each
detailed
parameters
like
for
the
bandwidth,
for
example,
it
can
be
measured
by
rate.
It
can
be
measured
by
other
kind
of
parameters,
so
we
need
to
have
a
kind
of
unifor
uniform
the
format
for
each
of
the
perform
performance
parameters,
but
they
may
be
different
with
each
other
and
the
second
issue,
which
is
less
than
89
on
the
github,
is
okay.
J
We
need
to
understand
that
which
points
the
measurement
is
required
because
even
for
the
same
parameters,
if
you
do
the
sampling
on
the
different
point,
endpoints
or
access
points,
the
number
of
the
the
parameters
numerical
value
can
be
different.
So
we
also
need
to
have
some
consensus
on
this
and
the
next.
J
Okay,
this
is
the
final
page
and
we
are
planning
for
something.
I
I
think
we
we
can
us
decompose
it
to
a
stage
before
the
working
group
adoption,
and
we
can
do
some
some
some
for
some
issues.
We
can
do
it
even
after
so
before
the
working
group
adoption
we
need
to
confirm
the
work
is
useful
and
the
good
news
is
so.
We
almost
receive
a
lot
of
positive
feedback,
and
we
also
think
we
need
to
agree
on
the
the
model
relationship,
especially
how
to
coordinate
with
other
pm
modules.
J
I
think,
as
long
as
we
have
a
kind
of
approach,
it
can
be
proceeded
and
for
the
other
open
issues
we
can.
That
would
be
a
more
more
detailed
technologies
and
we
can
do
it
after
the
adoption
is.
We
need
to
agree
on
the
module
structure,
how
to
represent
the
different
considerations
for
different
parameters,
and
we
are
going
to
working
on
the
details
for
each
parameters
and
including
the
sampling
point.
A
K
Great,
can
you
hear
me
yes,
perfect,
okay,
okay,
so
yeah!
This
is
iowa
gold
and
I'm
presenting
here
at
the
draft
individual
draft
of
framework
and
data
model
for
otn
network
slicing
on
behalf
of
the
other
co-authors
and
contributors
next,
so
here's
a
overall
summary
of
the
major
updates
since
the
last
itf-
and
this
is
the
third
revision
of
the
of
of
the
draft.
K
K
We
have
had
a
good,
expanded
list
of
authors
and
contributors
since
the
last
meeting
and
with
thanks
to
many
of
the
much
of
the
interests
coming
from
the
community
and
welcome
all
those
contributors
and
others
so
on
the
draft
aside.
So
the
update
is
mainly
focusing
on
answering
this
question.
So
what
is
the?
K
K
To
answer
how
an
otn
slicing
is
in
the
the
scenario
of
an
end-to-end
slicing,
which
could
incorporate
the
work
coming
from
the
ietf
network
slice
and
we
clarify
the
definition
of
an
otn
slice
and
an
audience
controller
which
which
manages
the
configures
the
otn
slice,
and
we
also
make
explicit
the
relationship
between
an
otn
slice
and
an
itf
network
slice
and
how
they
can
work
together
to
to
form
an
end-to-end
network
slice
in
the
otn
domain,
as
well
as
in
the
metal
domains
with
opn
in
the
middle
and
the
we
defined
a
two
abstraction
methods
that
could
be
used
to
create
otn
slices,
which
is
a
connectivity
based,
as
well
as
a
resource
based
resource
reservation
based
otn,
slides.
K
And
then
we
also
updated
the
description
for
otn
slice
controller
recursion
to
deal
with
the
multi-domain
and
multi-domain
use
case.
So
yeah,
I'm
gonna
go
through
all
those
updates
in
the
next
few
slides
next.
K
So,
with
the
definition
and
scope
of
okay
and
slice,
we
aligned
the
definition
with
the
current
ongoing
work
of
ietf
network
slicing
in
that
network
slice
draft,
which
we
basically
sort
of
make
the
otn
slice
a
particular
otn
virtual
network
topology
that
connects
nokian
endpoints
with
the
same
term
to
to
satisfy
specific
service
level
objects,
but
expressed
in
terms
of
otn
technology.
K
And
in
that
respect,
an
otn
slice
is
essentially
a
technology
technology.
Specific
realization
of
an
ietf
network
slice
in
the
otn
domain
and
on
the
right
side
is
the
it's
a
it's
a
figure
that
describes
the
the
scope
of
an
otn
slice,
both
in
in
the
single
domain
and
multi-domain
scenario,
where
the
otn
slice
for
a
single
domain.
K
The
scope
is
between
the
access
link
and
access
link
of
of
the
domain
and,
in
the
case
of
a
multi-domain
for
each
of
the
domains
that
an
otn
slice
is
established
on
the
scope
of
that
slice
and
we
call
it
a
segment
slice.
Its
scope
is
between
the
access
link
and
the
inter
domain
link
of
the
of
the
of
the
otn
domain,
and
those
otn
sacramento
slices
could
be
could
be
created
in
both
hierarchical
meaning,
recursive
or
sequential,
in
a
stitched
combination.
K
K
So
here
we
have
updated
the
two
abstraction
methods
to
configure
okin
slices.
K
The
first
method
is,
is
the
is
a
connectivity
based
protein
slice
in
which
an
otn
slice
is
abstracted,
as
just
a
set
of
you
know,
end
point
to
endpoint
links
and
which
each
of
the
link
which
of
the
links
is
formed
by
just
an
enter
in
a
tunnel
across
the
otn
network.
K
And
this
is
this
is
in
line
with
the
current
description
of
the
itf
network
size,
and
we
also
have
seen
the
second
method
of
app
for
abstracting
an
otn
slice
based
on
resource
reservation
and
in
which
a
an
otn
slice
is
abstracted
as
as
an
abstract,
topology
and
within
that
of
abstract
topology.
K
The
resources
allocated
to
a
nuclear
slice
could
be
shared
between
multiple
endpoints
and
the
user
of
the
slides
could
actually
perform
on
demand
commissioning
of
resources
within
the
slides
to
satisfy
their
own
need
of
connectivities
within
between
endpoints
within
otn
slice,
and
this
basically
comes
with
the
benefit
of
having
a
better
optimization
of
resources
of
sharing
resources
and
also
the
user.
K
Has
the
flexibility
to
to
use
make
use
of
the
resources
within
their
size
as
as
it
as
they
need
and
like
here,
there's
a
actually
a
real
world
example
in
which
we
see
a
good
benefit
of
this.
K
This
resource-based
slice
is
in
the
case,
let's
say
if
I
have
multiple,
if
I
have
an
otm
slice
used
to
support
a
high
quality
and
real-time
broadcasting
of
you
know,
sports
events
between
multiple
stadiums
and
the
tv
station
and
because
at
any
day
there
are
only
a
few
stadiums
that
has
the
event,
and
so
it
only
needs
to
create
a
few
of
the
a
few
connect
connectivities,
a
few
connections
between
the
stadiums
and
and
the
tv
station.
K
It
does
not
need
to
have
to
maintain
a
full
end-to-end
connection
between
each
tv
station
and
the
between
each
stadium
and
the
tv
station
to
basically
to
start
with
right.
So
this
resource-based
otn
slice
could
well
satisfy
the
the
requirement
of
such
such
an
slice.
K
Request
and
actually
these
two
methods
of
abstraction
are
very
similar
to
the
virtual
network
concepts
as
defined
in
rfc
8453,
where
we
have
the
vm
type,
one,
which
is
corresponds
to
connectivity-based,
slicing
and
type
2.
The
end
type
2
is
is
actually
for
resource-based
slicing.
A
Can
I
ask
you
to
speed
up
a
little
bit
because
we
just
have
a
five
minutes
left
and
rather
another
presentation,
good
thanks.
K
Okay
sure
sure
so
I'll
go
real.
Real,
quick,
so
on
this
page
is
the
we
defined
okay
and
slice
controller,
as
well
as
how
it
interfaces
with
the
with
the
iekf
network
size
controller.
As
you
see
here,
we
can
slice
controller.
K
Nvi
is
technology
specific,
which
could
have
requests
to
come
in
directly
from
the
orchestrator
to
to
create
an
otn
slice
and,
on
the
other
hand,
the
icf
net
slice
controller
can
also
make
use
of
the
otn
size
controller
to
create
the
to
basically
to
translate
a
technology
agnostic
slice
configuration
into
an
otn
specific
slice,
configuration
and
and
provision
the
otn
slice
in
the
otn
network
domain,
but
the
icf
network
slice
controller
will
also
have
the
flexibility
to
not
use
the
otn
slice
controller,
but
talks
directly
with
the
underlying
pnc
or
the
network
controller
to
create
the
network
slice.
K
Okay
yeah,
so
this
one
discussed
about
the
recursion
for
otn
slicing
in
multi-domain,
and
there
are
actually
two
cases.
One
is
to
use
the
recursion
between
otn
slice
controller
to
to
to
support
the
otn
slice
across
multiple
domains,
and
the
other
option
is
to
rely
on
the
mdsc
to
pnc
recursion
to
to
cover
that
and
the
otn
slice
controller
only
interacts
with
the
single
and
dsd.
K
Basically,
the
model
is
just
to
define
how
we
coloring
the
t,
links
and
in
it
in
a
t,
topology
and
use
the
key
topology
kind
of
color
the
t
topology
to
configure
the
ogn
slice
ford
and
send
it
to
the
and
to
the
to
the
pnc,
and
we
we
so
here
we
discuss
the
possibility
of
coloring
the
t-links,
using
both
the
type
number
of
audio
container,
as
well
as
the
number
of
time
slots.
K
So
here
are
the
next
steps.
We
will
continue
updating
the
young
model
for
mpi
and
we
are,
we
start
to
develop
the
young
models
for
the
mbi
by
also
looking
into
the
related
work
as
listed
here,
and
we
will
be
covering
the
slicing
for
external
links,
meaning
accessing
into
domain
link,
which
supports
client
signal
other
than
hotend.
K
We
will
address
comments
and
reviews,
and
also
the
authors
believes
that,
basically,
this
draft
is
ready
for
working
group
adoption
based
on
the
consensus
on
the
major
part
of
the
slice,
and
also
a
good
interest
in
the
community
to
push
forward
move
forward.
The
work
and
young
model
is
needs
updates,
but
is
stable
for
the
mpi,
and
we
have
a
clear
path
for
the
mbi
model
development.
A
Thank
you
thanks
a
lot.
We
will
take
comments
to
the
list
because
we
are
really
running
out
of
time,
so.
H
This
young
module
actually
provides
a
providers,
a
point
overview
of
how
the
flex
e
young
model
can
be
a
model.
Could
please
connected
to
the
next.
H
Slides
provide
a
service
management
from
a
service
provider's
point
of
view.
From
the
start,
the
flexi
group
can
be
configured
at
first
as
a
whole
bundle
and
provides
a
first
year
files
and
the
time
slot
and
then
from
one
piece
to
another
piece.
Each
flight,
flexi
client
can
can
be
configured
with
a
time
slot
and
from
third
conga
transporter
network
flexi.
Standardization
is
also
an
important
piece,
so
we
are
additives
that
support
our
the
synonymization
communication
from
the
start
to
the
next
slide.
Please.
H
So
this
first
data
plan,
I
will
not
create
a
gated
slide
to
the
next
place.
H
This
global
perspective
of
the
management
model.
The
free
time,
is.
H
Which
contains
a
multiple
of
35
and
with
a
free
time
slots
are
all
contained
in
in
such
a
container
and
the
synchronization
flexi
phi
is.
It
can
be
retrieved
on
the
flex
device
to
the
next
slide
please.
H
So
this
is
the
core
two
diagrams
on
the
left.
Is
the
flexi
group
container,
with
all
the
stuff
on
a
flexi
group
and
also
flexified
with
a
sinker
synchronization
file
number
on
the
right
is
the
interface
for
the
flexi
client
for
each
client.
We
can
support
the
configuration
of
the
canon
number
and
all
the
time
slot
list.
H
So
this
is
an
initial
version
of
this
model
would
like
to
see.
People
can
have
a
review
of
this
jordan
feedback,
so
we
can
update
it
later
on.
Thank
you.
A
Thanks
thanks
a
lot
for
for
the
presentation
and
for
squeezing
it
into
into
a
few
minutes.
My
suggestion
is
that
to
start
the
discussion
on
the
many
lists
that
you
see,
if
there
is
interest
from
the
working
group
to
work
on
this
topic
and
to
collect
the
first
first
feedbacks.
A
It's
now
time
to
wrap
up
thanks
a
lot
to
everyone
once
again
for
for
participating
for
your
contribution
and
your
presentations
and
have
a
very
good
rest
of
the
day.
Thanks
a
lot,
everyone.