►
From YouTube: IETF114-CCAMP-20220729-1630
Description
CCAMP meeting session at IETF114
2022/07/29 1630
https://datatracker.ietf.org/meeting/114/proceedings/
B
C
B
A
A
Actually
I
think
you
know
we
are
all
family
with
the
load
wheel,
information
actually-
and
this
is
the
kind
of
demand
for
the
idf
policies
which
means
that
by
participating
in
the
itf,
you
agree
to
follow
idea
policies
and
you
know
I.t
process,
including
idf.
You
know
our
patent
policy
and
also
if
you
would
like
to
get
more
information
about
the
load
where
you
can.
You
know,
have
a
look
at
the
pcp
and
documents
in
the
below
next.
A
A
First,
we
have
to
make
sure
to
sign
into
the
session.
You
think
online
tour
with
echo
and
also
use
the
mid
anchor
to
join
the
mic
q
and
especially,
please
keep
audio
and
the
video
off,
if
not
used
on
site
version
and
the
last
one
is
very
important
because
it
is
relevant
to
our
health.
So
please
wear
masks
unless,
when
you're
speaking
at
the
mic
and
so
the
remote
participants,
we
also
have
to
make
sure
your
audio
and
the
radio
are
off.
A
A
So-
and
there
is
also
some
contact
and
guidelines,
I
think
this
is
more
like
a
kind
of
supplement
supplement
to
the
you
know:
load
wheel,
this
thing's
more
described
in
the
bcp
54
in
sudbury.
It
says
that
anyway,
we
should,
you
know,
be
polite
and
you
know
respect
each
other
at
all
times.
I
think
this
is
quite
very
important,
no
personal
attack.
We
can
only
just
focus
on
the
you
know,
technical
stuff.
A
A
And
for
session
this
time
we
have
only
one
session
with
two
hours.
Actually
I
don't
think
the
time
is,
you
know,
are
friendlier
for
the
especially
for
the
mode
participant
for
the
asian
people,
but
also
it's
not
friendly
for
the
you
know
in
in-person
participants,
because
this
is
friday
afternoon.
Maybe
some
you
know
in
person.
Participants
may
leave
for
home
at
this
time.
A
A
So
for
the
meet
takers,
I
think
you
know
how
men
can
help
us,
but
I'm
not
sure
or
sky
is
key
or
not,
it
seems
oscar,
you
know,
is
not
in
the
meeting
so
anyway,
if
anyone
you
know,
I
could
you
know
capture
something
slow
on
my
tour.
That
will
be
a
much
appreciated,
but
anyway
I
asked
how
many
to
help
the
children
blushes
so
anyway,
this
will
be
automatically
created.
A
Based
on
your
you
know,
mid
echo
information,
not
information,
so
no
need
to
do
anything
and
for
the
ipr
process,
though,
this
is
quite
very
important
reminder
about
the
ipr
process.
So
usually
you
know,
prior
to
moving
to
the
next
step
in
the
working
group
process,
the
the
chairs
we
are
sending
the
ipr
polling
and
then,
which
requires
the
authors
and
the
contributors
of
a
draft
to
respond
to
ipr
polling
as
soon
as
possible.
D
B
Okay,
let's
see
if
it
works,
so
a
brief
update
on
the
document
on
the
status
of
the
documents
of
the
working
group.
Actually,
we
have
two
documents
in
the
isg
processing
the
applicability
of
gmp
ls
to
ot
on
rtn
beyond
100
gigabits
and
which,
which
has
been
there
for
a
while
now
and
the
recently
pushed
young
model
for
flexibility,
the
topology.
B
B
Then
we
we
are
running
the
apr
polling
for
the
layer,
one
types
and
the
otna
topology
young.
If
I'm
not
mistaken,
we
received
all
the
replies
for
the
layer,
one
types,
but
we
are
still
missing
two
or
three
of
them
for
dft
and
topology.
So
please
answer
to
the
to
the
polling
as
soon
as
possible,
so
that
we
can
start
the
working
group
last
call.
We
would
like
to
to
run
a
joint
last
call
for
for
both
of
the
documents.
B
Then
we
have
the
otn
the
tunnel
model.
These
this
one
has
been
updated
with
consistent
description
on
terminologies
tree
diagram
and
graphic
and
graphics.
It's
technically
stable.
I
mean
the
authors
said
that
they
are
trying
to
keep
in
alignment
with
with
the
generic
model.
Actually,
this
is
this
is
one
of
the
many
documents
that
have
dependencies
on
the
itft
document
from
fronties.
B
We
have
also
the
transport
ndi
applicability,
stick
statement.
This
is
a
document
that
already
went
through
the
working
group.
Last
call
all
the
comments
have
been
been
addressed.
This
is
a
pretty
long
and
extensive
document.
We
tried
to
reduce
a
little
bit.
We
we
reviewed
it
trying
to
cut
some
some
fat
and
just
leave
with
the
meat
around
the
bones.
B
B
Then
we
have
a
set
of
documents
which
is
moving
a
little
bit
slow,
but
I
mean
I
I
fully
understand
that,
because
we
have
a
fairly
reduced
number
of
authors,
which
is
working
on
many
documents
in
parallel
and
it's
of
course
some
of
them
are
are
progressed
with
the
low
priorities.
We
are
speaking
here
about
the
dwdm
interface
lmp
extensions,
but
if
I'm
not
mistaken,
this
is
already
applicable
also
to
the
dwdm
interface
parameter
young
model.
B
Then
we
have
the
flexi
the
young
model
for
flex
internet,
which
was
recently
adopted.
There
was
a
quite
quite
good
support,
but
after
the
adoption,
no
big
changes
on
on
the
documents,
so
a
little
bit
more
more
discussion
and
the
more
review
from
from
from
the
entire
working
group
would
be
would
be
great.
B
Then
we
have
two
documents:
the
basically
the
tunnel
model
for
wson
and
for
flexigreeta.
These
are
both
pretty
stable
documents.
They've
been
out
for
a
while,
both
of
them
are
blocked
by
the
itf
te
model.
We
were
considering
to
merge
the
the
two
documents,
since
both
of
them
have
common
layer,
zero
attributes.
So
I
mean
this
is
something
that
we
would
like
to
to
to
discuss
to
to
to
reduce
the
effort
from
from
the
sg
from
the
reviewers
to
analyze
a
single
document
instead,
instead
of
two.
B
Finally,
we
have
liaisons
and
communication.
We
have
two
of
them,
one
from
the
etsy
isg.
This
is
a
a
follow-up
on
the
a
young
modeling
for
sdn
sbi.
This
is
mostly
focused
on
microwave.
If,
if
I'm
not
mistaken
and
this,
the
deletion
is
to
announce
the
next
round
of
applause
test
arranged
by
etsy,
you
can
find
the
the
link
to
the
to
the
liaison
here,
but
you
can
find
it
also
on
on
the
mailing
list.
This
was
just
for
information.
B
We
have
also
another
liaison
which
which
we
received
a
couple
of
days
ago,
so
pretty
fresh.
I
I
I
just
scanned
through
through
it.
This
is
a
liaison,
an
invitation
to
update
the
information,
the
imt
2022
and
beyond
roadmap.
So
if,
if
you're
interested,
you
can
find
a
link
to
that
as
well
here
and
on
the
main
list,
if
there
is
no
comment,
I
would
move
to
the
first
presentation,
which
is
the
young
data
model
for
microwave
topology.
If
I'm
not
mistaken,
scott
is
presenting
it.
D
C
Chair
land,
okay,
great
well,
welcome
everyone
to
the
yang
session
for
c
camp.
It
seems
to
be
something
that's
very
popular
these
days.
What
I'm
here
to
do
is
just
to
present
very,
very
quickly,
a
update
on
where
we
are
with
the
microwave
topology
yang.
It's
work,
that's
been
going
on
for
a
while.
We
have
a
team.
The
team
that's
up
on
there,
that
are
the
authors
of
the
of
this
update
to
the
draft,
are
ones
that
we
participate
in
conference
calls
like
every
two
weeks.
C
So,
if
you're
interested
in
this
work,
we
do
have
a
lot
of
conversations.
So
please
join
those.
If
you
go
to
the
next
slide,
please
so
the
status
is
very
simple:
we've
we've
taken
the
work
that
we
were
doing
before
and
we've
migrated
it
all
to
github
we're
using
the
the
github
templates
from
I
think
it's
martin
thompson
and
so
we're
using
that
to
track
our
issues.
So,
if
you're
interested
in
this
go
there-
and
you
can
see
where
we
are
and
see
the
latest
drafts,
we
had
minor
changes.
C
Very
minor
changes
to
the
yang
module.
We've
completed
the
topology
model
figures
fixed
and
validated
things.
We've
added
some
instance
data,
and
this
is
from
then
from
daniella.
She
did.
She
did
a
great
job
on
producing
some,
some
more
examples,
so
that
you
can
see
instance,
data
and
how
it
how
it
is
used,
and
we
validated
that
using
tools
like
in
yanglin.
So
if
you
go
to
next
slide.
C
The
so
what
do
we
have
for
issues
so,
if
you're
interested
in
some
of
the
issues
that
we're
currently
still
working
through
and
there's
some
tweaks
around
bandwidth
utilization
and
there's
a
pointer
to
the
issue
and
an
issue
around
operational
mode?
And
this
is
something
where
we're
trying
to
decide
how
to
model
the
operational
mode
and
trying
to
decide
if
we
need
to
update
the
8561
to
support
a
different
way
of
of
supporting
operational
mode.
So,
if
you're
interested
in
that,
I
have
a
private
draft
that
I've
started.
C
C
This
is
this
provides
a
little
more
background
on
it
and,
if
you're
interested
in
this,
I
like
this
type
of
work
because
they're
using
the
yang
that
the
it
the
ietf
creates
they're
using
it
in
plug
fests
and
actually
validating
that
it
works
and
finding
issues
and
reporting
back
and
those
are
all
very
useful
things.
So
there
is
a
new,
an
invitation
here
on
what
they're
going
to
be
doing
next
year.
C
So,
if
you're
interested
in
this
kind
of
work,
especially
around
topology
or
around
configuration
microwave,
that's
what
this
is
about,
you
can
find
more
work
there
and
find
background
there.
So
go
next
slide.
Please
we're
going
to
try
to
get
the
draft.
We
want
to
get
all
of
our
issues
done
and
and
get
all
that
stuff
done
and
try
to
get
a
last
call
by
next
ietf
next
slide.
I
think
that's
it.
G
G
So,
thank
you
for
re-spinning
this,
this
draft,
and
I
I
know
you
do
all
the
work
in
github
and
and
so
on.
Could
you
do
me
a
favor
and
try
to
keep
it
alive
going
forward
as
because
it's
really
hard,
as
you
say
when,
when
people
outside
are
picking
up
this
stuff
to
use-
and
they
can't
quite
tell
whether
we've
abandoned
microwave
or
not,
I've
been
fielding
questions
on
that.
C
Oh,
thank
you
very
much
for
that.
Yes,
one
thing
that
we're
trying
to
do
is
do
a
lot
more
with
our
with
our
meetings
and
and
publicize
this
using
the
github
tooling,
but
something
that
we
should
do
more
of
is
when
we
have
a
meeting.
We
do
put
the
minutes
in
github,
but
we
should
do
a
better
job
of
putting
it
out
on
the
mailing
list
as
well.
That
would
help
people
see
that
the
work
is
still
progressing,
especially
if
we're
trying
to
get
to
last
call
by
next
meeting.
C
C
A
C
Well,
that's
I'm
going
to
answer
it.
The
way
a
good
chair
would
answer
that
if
there,
if
you
feel
that
there's
work,
that's
necessary
in
that
area,
please
submit
a
individual
draft
and
then
we'll
look
at
at
doing
that
work.
I
I
think
that
there's
the
the
work
to
be
a
little
more
serious
in
my
answer.
C
The
way
that
we're
trying
to
do
this
work
is
we're
trying
to
do
it
in
a
very
modular
way,
so
that
if
people
want
to
have
things
that
run
over
top
of
this,
it's
easy
to
to
create
augmentations
that
will
then
you
do
the
other,
the
the
new
functionality.
So
hopefully
that
answers
the
question
in
a
sensible
way.
Thanks.
C
Well,
my
my
response
to
that
is
just
because
I'm
on
the
floor
and
nobody's
requested
it.
Yet
I
think
that
it
is
very
useful
to
remind
people
to
do
this
sort
of
thing
to
continue.
The
discussion
on
the
mailing
list
is
even,
if
you're,
using
github
to
make
sure
that
the
entire
working
group
knows
what's
going
on.
So
thank
you.
H
H
Okay.
So
since
the
last
revisioning
becoming
the
working
group
of
draft,
we
have
updated
both
the
text
as
well
as
the
yam
data
model
for
otn
slicing.
So
on
the
text
side,
the
the
main
change
is
that
we
added
a
section
that
describes
the
realization
of
ogn
slices
with
the
network
resource
petition,
along
with
other
cosmetic
updates
for
the
young
models.
H
H
H
B
B
H
B
Having
that
the
common
transporter
network
slicer
defined
inside
the
dltn
document
is,
is
a
little
bit
ambiguous,
I
I
would
say
so
I
mean
this
is
just
my
preference,
I'm
not
I'm
not
asking
you
to
do
that.
I'm
asking
the
the
the
working
group.
If
what's
what's
his
opinion
here,
we
we
we
can
take
it
to
the
least,
but
I
mean
I
just
wanted
to
raise
to
raise
this
point.
H
D
I
Yeah,
I
think
what
is
currently
happening
is
the
idea
of
otn
slice
that
is
currently
not
defined.
There
is
a
section,
but
that
section
is
currently
empty
and
what
we
basically
have
in
this
document
is
the
itf
transport
network
slice.
So
what
confusion
is
happening?
Is
the
document
is
called
otn,
but
the
yang
model
that
is
currently
the
main
focus
is
the
idea
of
transport
network
slice.
So
I've
urged
the
authors
to
think
a
little
bit
more
and
come
up
with
a
good
strategy.
B
H
B
J
A
short
answer:
yes,
he's
right,
it's
partially
right
in
the
sense
that
from
nbi
prospective
you're
right,
so
there
is
nothing
specific
for
tien,
but
the
document
is
considering
also
the
mpi
extension.
For
that
point,
it
is
specific
for
otn.
So
this
is
why
we
have
not
changed
nothing
for
the
moment,
but
surely
the
suggestion
from
from
transport
networks
lies
that
can
be
a
different.
B
E
B
H
What
italo
has
said
so
from
the
yamato
development
perspective?
We
wanted
to
have
the
basic
framework
for
transport
network
slice
ready
as
a
generic
model,
and
then
we
know
what
exactly
we
could
put
over
the
otn
slice
model.
So
basically
we
do
it
as
a
step-by-step
approach,
but
as
I
also
agree
with
with
the
chairs
and
other
comments,
we
could
consider
separate
those
two
models
into
two
drafts.
H
So
now
for
otn
and
possibly
other
transport
networks,
the
resources
are
like
much
course
granular
because
of
the
because
of
the
time
tdm
nature
of
the
of
the
network.
So
in
this
case
we
could
see
that
the
use
of
nrp
it's
still
optional,
but
certainly
will
have
its
benefit
to
support
large-scale
networks
and
also,
if
we
consider
that
in
the
future,
when
we
see,
for
example,
otn
data
plane
will
start
to
evolve.
H
For
example,
there
are
proposals
about
considering
to
develop
a
sub
one
gotn.
So
in
that
case,
then,
the
complexity
of
supporting
slicing
for
otn
networks
will
also
become
much
much
more
complex
and
then,
in
that
case
the
use
of
nrp
has
certainly
has
its
benefits.
So
all
those
texts
text
has
been
put
into
the
draft
for
the
consideration
of
the
audience.
H
H
H
Okay,
next
page,
please,
so
there
are
a
couple
of
open
issues
of
of
the
modeling.
So
one
open
issue,
which
also
has
been
mentioned
in
the
t's
network's
license
modeling
discussion-
is
how
we
could
define
technology-specific
attributes
right.
So
currently,
the
the
design
in
the
teas
networks
icon
is
to
try
to
use
an
opaque
definition
of
attributes
that
can
and
and
try
to
capture
technology
specific
parameters,
and
they
are
in
the
form
of
key
value
pairs
right.
H
H
So
with
regards
to
otn
slicing,
so
the
our
preference
is
to
go
directly
with
explicit
and
technology
specific
attributes
and
probably
we're
not
going
to
use
the
opaque
definition
of
the
of
the
attributes.
So.
But
that
will
continue
working
on
that
and
to
discuss
with
the
with
the
network,
slice
young
team
and
try
to
figure
out
the
best
way
to
move
forward.
F
H
Okay,
yeah,
so,
okay,
next
page,
okay,
another
issue
is
to
so
right.
Now
we
could
see
there
are,
there
could
be
multiple
options
for
the
mpi
model,
one
using
nrp
and
the
other
one
of
not
using
nrp,
and
in
which
case
we
identified
some
gaps
in
the
current
topology
and
we
added
an
option
for
for
coloring
the
links
in
the
in
the
model
right.
H
H
I
Yeah
I'll
try
to
be
very
quick
with
respect
to
nrp.
I
think
we
need
to
also
clarify.
Would
there
be
any
interaction
between
nrp
in
the
ip
layer
and
the
nrp
here,
or
are
they
going
to
be
completely
independent,
because
that
was
not
very
clear
from
the
document
and
the
related
question
from
the
yang
modeling,
since
there
is
a
model
for
nrp
in
teas?
Would
there
be
any
interaction
between
that
model?
Is
that
model
also
supposed
to
be
some
kind
of
generic
model,
whereas
the
nrp
otn
is
going
to
be
something
specific?
I
The
second
thing
which
I
wanted
to
talk
about
was
the
topology
part,
since
we
have
added
that
topology
in
the
in
the
model,
and
we
had
one
discussion
in
the
tease
also
that
what
if
a
teas
model
used
the
vn
type
2
mechanism,
where
we
put
a
reference
to
an
abstract
topology
same
as
what
we
do
in
vn
type
2..
Would
that
meet
your
requirement
or
you
still
need
a
topology
separate
from
that
in
the
t.
H
Thank
you.
Okay.
Let
me
make
a
quick
comments.
Yes,
so
I
agree
with
you:
one
of
the
main
driven
factor
for
for
defining
a
common
model
for
transport.
Is
we
don't
have
an
option
to
specify
topology
in
the
base
model,
so
yeah
but
short
answer
is
it
depends
and
then
we
we
could
discuss
that
offline
to
figure
out
the
best
way
to
have
the
support
for
topologies.
G
I
H
F
1
connectivity
service
model
on
behalf
of
all
the
authors
and
contributors
next
page,
please
yeah.
So
this
one
is
a
brief
update
on
the
status
and
it
has
been
a
while,
since
our
last
presentation
it
was
in
itf
109
for
version
13
and
after
that
we
have
actually
a
few
updates
over
there.
But
I
think
the
major
one
would
be
to
address
the
comments
in
the
young
doctor,
alaska
review.
D
F
Early
one
csm,
and
we
check
it
out
because
it's
very
close
to
the
working
group
last
call
and
we
figure
out
there
are
two
issues
to
be
discussed.
So
that
would
be
the
next
two
pages.
Next,
please,
and
the
first
open
issue
is
actually
a
hello
high
level
one.
The
question
is
about
okay:
how
to
coordinate
the
performance
monitoring
stuff
regarding
the
layer,
one
connectivity
in
this
document
and
the
other
document.
F
But
we
also
have
received
some
comments,
say
whether
it
is
useful
to
coordinate
with
other
pm
models
like
the
one
in
our
working
group
as
individual
draft
client
signal,
performance
monitoring
and
some
other
like
the
vpn
pm,
ippm
and
whatever
so
yeah
well,
but
but
that
part
of
the
work
is
just
starting.
So
we
are
providing
a
few
options
that
can
be
considered
as
resolutions,
and
the
first
option
would
be
okay.
How
about
if
we
remove
the
the
pm
related
part
and
then
proceeded
and
leave
this
work
to
other
tpm
models?
B
F
Okay-
and
the
next
issue
is
about
the
descriptions
in
the
young
itself
and
the
problem
was
according
to
math
63,
the
configuration
of
the
protocol
coding
function
and
the
interface
functions.
Attributes
should
be
consistent
and
there
are
some
kind
of
constraint
when,
given
the
definite
when
people
give
the
definitions
of
such
kind
of
parameters,
we
were
trying
to
describe
in
the
young
grammar,
but
after
checking
with
the
young
experts
in
that
mode,
we
find
okay.
This
is
not
accomplished
achievable
and
we
finally
decided
to
to
tweak
only
the
descriptions
in
the
module.
F
B
E
D
I
B
B
J
E
J
J
J
So
the
the
point
is
that
the
the
in
the
case
of
unidirectional
transponder,
a
unidirectional
3r,
the
transceiver
of
each
optical
transponder,
receive
the
signal
from
one
cent
and
transmit
the
regenerator
optical
signal
in
the
other
urgent
adherence
segment.
So,
in
the
case
of
carrier
for
the
carrier
frequency
we
can
operate
a
different
frequency,
optical
frequency
between
the
receiver
and
the
transmitter.
J
But
in
the
model
we
have
defined
the
transceiver
capabilities.
That
is
the
transceiver
mode,
and
this
is
a
property
of
the
transceiver.
It
is
applied
at
the
at
the
same
time
to
the
transmitter
and
the
receiver,
so
the
transceiver
mode
has
to
be
the
same
in
the
two
segment
of
the
two
side
of
three
hour
generator.
So
for
this
reason
the
transceiver
mode
can
be
cannot
be
changed
in
the
context
of
of
uni-directional
3r.
J
We
added
specific
tests
for
that,
and
then
we
started
to
have
a
new
section
regarding
the
protection
architecture
for
the
young
model.
We
we
fix
two
issue
that
is
basically
regarding
the
tilt
target
to
to
clarify
the
the
context
of
the
tilt
turret.
It
is
related
to
the
upper
and
lower
frequency
of
amplifier.
J
We
introduced
modification
regarding
the
protection
modeling.
This
is
a
work
on
going,
but
we
started
on
that
and
we
started
to
to
make
a
modification
and
we
have
other
issue
that
is
impacting
the
young,
but
the
the
these
are
fixing
in
the
context
of
itf
layer,
0
type,
but
is
still
related
to
the
to
the
optical
impairment.
J
J
So
they
they
what
we
need
to
have
in
the
topology
model,
so
in
the
topology
module.
The
path
computation
need
to
know
the
existing
otsi
in
each
omx
section
for
the
reason
to
determine
what
are
the
optical
impairments
of
the
existing
otsi
on
the
calculation
of
the
optical
flexibility
of
the
newer
tsi
and
the
opposite,
so
the
impact
of
the
new
rtsi
with
respect
to
the
existing
one.
J
So
in
the
case
of
protection,
the
the
question
that
the
the
the
autos
put
on
the
demo
is
how
to
represent
the
existing
ltsi
already
there
in
the
network.
So
we
there
is
a.
We
have
two
optical
seniors
at
the
up
are
the
at
the
input.
The
selector
that
may
have
optical
impairments
impact
because
is
is
linked
to
the
different
parts
and
in
case
and
the
optical
feasibility
has
to
check
anyway
in
the
two
parts,
because
we
need
to
be
independent
of
the
action
related
to
the
switching
for
the
protection.
J
J
J
There
is
a
basic
physical
assumption
that
at
the
ingress
of
or
and
aggress
of,
a
splitter
and
selector
dots,
identify
is
the
same
and
the
nmc
are
can
are
different.
The
nmc
parts
are
different
in
the
same
same
way,
the
in
that
the
oms
section
will
we
will
have
the
reference
to
all
the
utsi
and
the
reference
to
the
related
parts
for
each
other.
J
J
J
J
There
is
an
issue
that
is
related
to
the
expert
in
in
life
ref.
We
open,
we
discussed
with
the
expert
like
robertson
about
the
net
mode
in
the
network,
because
we
have
in
mind
that
to
sudden
to
use
unchester
function,
but
there
is
still
debate
on
the
topic
and,
for
example,
in
the
context
of
the
flex
grid,
we
practically
decide
to
come
back
to
the
relative
path.
Part.
J
There
is
a
a
need
that
for
a
review
technology
that
has
been
addressed
partially
and
that
there
is
a
a
an
issue
related
to
the
boundary
between
layers,
the
only
one
because
the
the
model
there
are
some
functionality,
like
effect
inverse
multiplexing,
that
is
a
layer
one
functionality,
but
is
in
the
scope,
because
he
is
a
related
to
the
transponder.
So
he's
in
the
scope
of
this
document,
and
we
need
to
clarify
in
the
text
that
then
there
is
a
a
specific
issue
that
is
related
to
the
process.
J
J
J
J
J
J
They
we
have
a
first
presentation
last
time
about
the
rfc
1993
bs
and
that
these
slides
represent
the
fact
that
we
changed
the
quotas
because
we
encompass
the
cover
part
of
both
the
documents,
so
the
original
rfc
1993
and
the
layer
zero
type
extension
draft.
So
this
is
why
there
is
a
long
list
of
quotas.
J
J
J
J
J
J
Here
practically
the
4233
is
related
to
to
fix
a
wrong
reference
from
the
the
the
for
the
left.
We
need
that
to.
We
have
modified
the
reference
in
the
definition
of
the
operational
mode.
There
is
a
wrong
reference
for
the
iqt.
Instead,
we
added
in
yellows
in
the
in
the
slides
a
specific,
the
specific
reference
of
the
section
in
the
optical
impairment
draft
in
which
we
describe
what
does
it
mean
operational
mode
on
the
right
part?
J
J
J
J
E
B
K
K
These
are
the
updates
to
our
job.
Since
last
itm
meeting
for
the
first
part
of
the
of
our
work,
we
have
apps,
we
added
more
attributes
to
the
young
data
model
based
on
the
model
defined
in
rfc
8348
and
some
integration
experience
at
first
we
have
identified
some
common
attributes,
such
as
uid
name
areas,
description
and
location
which
can
apply
to
all
the
unwanted
objects
and
secondly,
for
the
component
object
of
narrow
element.
K
K
K
We
all
agree
that
most
of
the
attributes
in
absolute
834a
defined
for
components
are
also
applicable
for
network.
The
second
part
of
our
work
is
we
continue
the
discussion
of
scalability
issues
raised
in
last
version.
The
conclusion
will
be
also
introduced
in
the
following
slide:
okay,
let's
go
with
the
refinement
introduced
at
first
next
page.
Please.
K
K
K
K
K
The
first
option
provide
a
hierarchical
structure,
just
like
the
parent
identifier
identify
list
these
in
previous
slides.
This
line.
This
design
can
support
similar
flexible
retrieval,
like
I
mentioned
previously,
but
this
structure
is
less
flexible
and
risk
risks
to
be
applicable
to
optical
network
animal.
Only.
K
K
K
K
As
a
summary,
we
have
introduced
a
attribute
discussion
and
scalability
issue
discussion
today
and
for
the
next
step,
since
we
have
decided
to
continue
to
move
forward
with
the
current
model
and
enrich
a
lot
of
attributes
on
it.
We
think
that
our
draft
is
now
ready
for
second
working
group
adoption.
K
B
B
B
D
B
H
E
E
Okay,
the
initial
proposal
for
otimpa
computation
rav
was
presented
into
in
itf
112
and
together
with
w
zone
flexigrid
and
the
feedback
in
the
itf
2013
discussion
was
to
split
the
otm
part
on
a
different
rafter.
So
now
we
moved
the
otm
computation
into
this
new
drafter.
The
work
is
quite
straightforward.
E
So
the
next
steps
is,
of
course,
to
get
feedbacks
and
comments
from
the
working
group
and
progress
it.
Accordingly,
we
will
keep
alignment
if
there
is
any
change
in
the
authentic
model
which
have
an
impact
on
the
computation.
We
will
keep
an
alignment
and
we
will
complete
the
document
adding
the
security
management,
manageability
considerations
which
are
currently
empty
sections,
and
we
believe
the
document
is
now
ready
for
working
group
adoption.
E
D
D
E
Even
though
we
have
a
little
bit
more
open
issues
given
the
complexity
of
the
wwm
technology,
we
are
discussing
those
issues
together
with
the
flexibility
and
tunnel
model
weekly
calls
on
thursday
and
what
we
have
done.
We
have
reviewed
some
use
cases
for
the
wm
tunnel
model
and
identify
the
some
changes
to
the
tunnel
common
attributes,
which
has
been
reflected
in
the
rsc
1993
b's
draft
update,
which
is
it
is
a
grouping
used
by
our
model,
but
it
has
been
updated
in
that
draft
next
slide.
Please.
E
The
major
issue
that
yeah
the
major
yeah-
okay,
yeah.
Yes,
this
is
a
major
issue
that
you're
facing
now
is
whether
we
are
able
to
merge
the
ws
and
flexibility
composition
modes
in
the
current
mod
in
the
current
graph.
We
have
two
modes
and
we
can
see
that
there
are
some
things
which
are
different,
like
the
label,
the
w
zone
and
flexibility
specific
labels.
But
there
are
a
lot
of
items
which
are
in
common
within
www,
specific
constraints
like
osnr
margin
and
layer.
E
Zero
tunnel
common
attributes
are
really
really
the
same
between
the
two
models
and-
and
there
is
a
desire
to
try
to
see
if
you
can
merge
these
two
modes
into
one
model.
We
have
the
similar
discussion,
also
for
in
the
context
of
the
tunnel
model,
whether
we
can
merge
also
doubles
and
flexibility
tunnel
modes.
E
So
the
suggestion
here
is:
maybe
we
need
to
investigate
defeat
the
technical
impact,
whether
this
is
possible
for
both
tunnel
and
pac
computation,
and
then
we
can
bring
the
option
to
the
working
group
and
hopefully
have
the
common
approach
between
composition
and
tunnel
model
on
merging
the
the
two
little
modes.
The
wizard
and
flexity
part
next
slide.
E
E
We
have
to
evaluate
this
option
to
merge
the
two
modus
into
one
model
and-
and,
as
I
said
before,
we
since
we
are-
we
need
to
keep
alignment
with
ws
on
flexibility,
tunnel
modes
and
the
rfc
bs,
as
well
as
the
computation
model
in
the
teaser.
So
if
there
is
any
impact
there
with
any
change
there,
which
impact
this
model,
we
need
to
take
into
account
and
other
security
manageability
considerations
to
the
document.
E
B
B
H
D
D
H
H
H
H
Okay,
so
a
quick
update,
a
summary
of
the
updates,
so
before
this
revision
we
spend
quite
some
chapters
talking
about
the
use
cases
which
a
lot
of
the
use
cases
are
actually
asking
for
requirements
for
for
otm-based
data
plane.
So
this
is
not
the
focus
for
ietf,
so
we
have
moved
and
consolidated
all
those
use
cases
into
a
description
of
within
the
overview
section,
and
we
clearly
state
that
the
data
plan
requirements
are
out
of
the
scope
for
for
this
draft.
H
H
H
H
H
H
H
H
L
B
H
Devices
isn't
that
yeah.
This
is
as
far
as
I
can.
As
far
as
I
know
there
is,
there
is
not
much
of
a
bgp
use
in
optical
networks
and
also,
like
I
said,
there's
there's
no
extensions
for
optical
networks
in
bgp
or
bgpls,
so
that
that's
probably
another
gap
that
prevents
bgp
from
being
used
in
in
optical
domain.
B
H
B
L
I
think
we
need
some
calculation
among
several
concepts.
One
is
the
idea
presented
by
iowa
and
another
is
the
the
layer,
one
ot
layer,
one
vpn
and
also
the
third
one.
The
otn
slicing
just
danielle
mentioned
to
my
understanding
the
differences
between
the,
for
example,
the
layer,
one
vpn,
and
this
idea
is
that
actually
we
are
the
same
using
otn
as
the
underlay
plane,
underlay
layer
of
the
network,
but
for
the
overlay
network
I
think
for
l1
vpn.
It
is
a
kind
of
carrying
layer,
1
services.
L
But
in
this
idea
I
see
a
lot
of
layer,
2
layer,
3
services,
because
data
centers
always
use
the
layer,
2
layer,
3
services,
layer
1..
So
I
think
that's
the
in
my
understanding
that
the
key
differences
between
layer,
1,
otn,
sorry,
layer,
1,
vpn,
and
this
idea
and
for
network
slicing,
my
understanding
is
that
now
slicing
is
only
for
the
otn
resources
itself,
not
touching
on
the
overlay
layer.
I'm
not
sure
if
I
understand
correctly,
but
maybe
I
could,
the
author
of
this
document
of
this
document
could
check
yeah.
That's
my
comments.
H
D
D
H
I
Regarding
the
work
that
you
are
suggesting
extension
for
pisa,
are
they
really
audience
specific,
or
are
they
quite
general,
like
some
of
the
things
that
I
see,
which
is
saying
identification
for
slice?
That
would
be
common,
whether
it
is
like
you
know,
normal
network,
or
it
is
otn.
So
just
think
about
that
as
well.
H
H
E
Yes,
you
know,
okay,
since
there
is
time
I
take
the
opportunity
to
answer
to
the
question
from
daniele.
I
think
that
it
is
both
the
subset
that
you
mentioned.
In
other
words,
I
I
think
that
this
solution
can
be
a
one
way
to
realize
an
audience
license.
So
this
is
a
subset
of
slicer,
but
ots
licensing
can
be
one
way
to
request
the
to
express
the
intent
for
a
service
that
is
realized
by
this
solution,
but
maybe
other
way
to
request
this
service
to
be
realized.