►
From YouTube: IETF113-CCAMP-20220325-0900
Description
CCAMP meeting session at IETF113
2022/03/25 0900
https://datatracker.ietf.org/meeting/113/proceedings/
A
B
A
A
A
And
then
there's
a
piece
of
the
information
about
the
you
know,
conductor
guideline
the
iesg
has
asked
all
the
chairs
to
remind
that:
the
working
group,
the
need
for
appropriate
behavior,
which
means
that
you
know
at
any
at
any
time.
In
any
cases
we
all
you
know
I
should
respect
each
other
especially
extend
the
respect
and
the
controversy
to
our
colleagues.
When
we
are,
you
know,
are
disgusting
or
you
know
on
you
know,
debate
something.
A
A
Yeah
there's
some
tips
about
this
meeting.
You
know
actually,
this
time
it's
a
face-to-face
meeting
we
so
usually
there
will
be
some.
You
know
in-person
participants,
but
for
us
there's
none.
So
actually
we
can
skip
this
kind
of
thing.
We
all
we
all
are
remote.
So
I
think
you
know
in
in
in
the
rest
recent
meetings
we
all
you
know-
are
participating
in
the
meeting
by
the
remote.
You
know
echo,
so
we
know
how
to
you
know,
participate
in
this
kind
of
you
know.
Conference
call
next.
A
A
D
A
A
A
So
the
last
the
things
about
the
mailing
list,
you
know
we
always
encourage
people
to
use
the
melodies
as
much
as
possible
to
discuss
anything
about
the
you
know:
technologies
inside
the
scope
of
the
work,
see
camp
working
group
and
you
know,
there's
important
demand.
One
group
consensus
is
determined
on
the
main
list,
even
though
we
get
some
consensus.
You
know
in
the
online
conference
on
face-to-face
meeting
we
still
need
to
bring
to
the
list.
You
know
on
to
confirmed
consensus
next,
okay,
it's
for
you
daniele.
C
Tai,
so
let's
go
through
a
little
bit
and
update
on
the
working
group
status
since
last
meeting.
We
don't
have
any
new
rfcs
or
documents
in
the
editor
queue.
Actually,
we
we
have
a
couple
of
drafts
which
are
fairly
needed
advanced
stage.
We
have
the
otna
be
on
the
100
gigabits
draft,
which
is
waiting
for
the
ship
at
the
right.
Shepherd
right
up
and
the
oscar
is
is
taking
off
that
because
both
are
involved
in
the
draft
and
the
other
one
is
the
transport
nbi
applicability
document.
C
C
No
big
changes
since
the
last
meeting
on
these
ones,
the,
as
I
said
the
first
and
the
third
one,
are
the
ones
that
are
past
working
group
lost
las
cola,
and
we
also
have
the
microwave
topology
and
the
w
zone
tunnel,
which
we
could
be
ready
to
move
forward
soon,
because,
if
I'm
not
mistaken,
the
t's
working
group
is
running
right.
Now.
The
last
goal
of
the
t
model
of
the
tunnel
t
model.
C
C
C
Has
been
updated
and
to
fix
the
comments
I
received
from
the
young
doctor
review,
I
was
wondering
whether
we
should
ask
the
ops
working
group
to
have
a
review
on
this.
Since
all
the
layer,
2
and
layer
3
services
are
in
the
in
the
operation
area.
What
what
do
you
think
should
we
or
maybe
john?
If,
if
you
are,
if
you
are
with
us,
what
do
you
think
should
we
ask
ask
them
for
for
a
review?
B
C
Minimal
minimum
updates
here
here,
as
well
as
well
as
the
otn
topology
young
model,
these.
These
are
the
two
on
next
in
in
the
row
to
be
to
go
through
the
last
call
otn
tunnel
model.
This
is
another
document
with
a
dependency
on
the
related
document
in
teaser,
so
that
the
the
itfte,
so
these
this
is
this-
will
be
unlocked
as
as
well.
C
Number
of
deadlines
in
in
the
next
month.
This
is
due
to
the
fact
that
we
have
a
number
of
pretty
stable
documents,
pretty
mature
documents.
Most
of
them
have
gone
through
the
young
daughter
review.
So
we
expect
in
the
next
month
to
be
ready
to
to
to
progress
many
many
documents
to
to
the
law
school.
Some
of
them
were,
let
me
say,
capitaled
by
other
documents
that
the
non-technological,
technic,
technological,
specific
ones
in
teas,
now
that
those
blocks
are
removed.
We
we
are
ready
to
progress.
C
C
C
It's
classified
as
communication,
because
actually
the
itf
doesn't
have
a
formal
liaison
relationship
with
with
etsy,
but
I
mean
this
is
something
for
for
information.
They
are
telling
us
that
the
isg
nfv
is
has
started
a
work
on
the
wema,
the
one
infrastructure
manager
and
they
they
are
planning
to
use
the
net
conference
of
young
models
and
base
it
on
on
ctn.
So
that's
why
these
ops,
working
group
and
ccamp
are
might
be
interested
in
this
communication.
F
F
Regarding
the
introduction
of
to
substitute
oms
and
ots
link
with
oms
ots
media
channel
group
and
the
we
we,
we
touched,
the
text
2.4
to
add
the
description
of
ram
amplification
and
we
added
text
to
clarify
the
usage
of
the
term
channel
versus
a
media
channel.
So
the
media
channel
is
described
in
the
g807
as
a
boat,
topology
model
and
related
to
the
the
resource.
F
F
F
F
The
point
is
that
in
this
case,
there
is
no
multiplexing.
There
is
not,
and
for
this
reason,
even
if
the
optical
impairment
are
the
same,
we
introduce
text
to
describe
explicitly
these
these
points
so
that
the
impairments
are
related
to
the
link
between
remote
optical
transponder.
Located
in
a
different
shelf
can
also
be
modeled
using
the
same
optical
impairment
as
those
defined
for
a
link
between
wdmt
nodes.
F
F
F
F
F
Okay,
we,
this
is
another
issue
that
we
solve
in
this
period-
that
we
wanted
to
avoid
a
specific
specified
behavior
in
case
of
a
mandatory
attribute,
for
example,
if
the
survey
is
not
present.
So
to
avoid
the
strange
value
that
can
be
returned
because
it's
mandatory,
so
something
has
to
be
returned,
but
even
in
for
optional
case,
we
want
to
distinguish
the
case
in
which
there
is
a
real
problem.
For
example,
the
service
is
not
able
from
what
is
the
not
applicable
case.
F
For
example,
the
till
for
amplifier
the
tilt
target
attributes
is,
is
needed
and
has
to
be
returned
in
case
of
edfa
amplifier,
but
is
not
a
problem
in
case.
There
is
not
a
return
that
because
does
not
is
not
applicable
in
case
of
rama.
So
are
two
different
cases,
and
for
this
point
we
introduce
the
type
empty
taking
from
rse
7951.
F
And
we
have,
we
have
introduced
in
the
module
the
description
that
distinguish
the
case,
that
if
the
value
of
a
mandatory
attribute
is
unknown,
it
must
be
reported
using
the
empty
type.
So
in
case
we
change
many
of
the
type
of
the
attributes
putting
the
union
between
specific
type,
as
it
is
now
and
the
the
case
of
empty
in
case
they
the
the
the
impossibility
to
return
the
value
in
case
of
optional,
if
it
is
applicable,
as
in
case
of
mandatory,
it
must
be
reported
in
case.
F
F
G
F
G
So
rob
wilson,
cisco.
I
I
think
this
is
possibly
over
engineering
it.
So
I
don't
quite
know
the
cases
where
you
can't
return
data.
If
this
is
a
plausible
case
or
you're
thinking
just
like
I
want
to
cover
sort
of
belt
and
braces
and
make
sure
cover
or
scenarios,
I
think
it
would
be
better
if
the
expectation
is
you
can
sometimes
not
return.
G
This
value,
then
don't
make
it
mandatory
if
the
expectation
is
that
the
server
should
always
return
this
value,
if
that's
sensible
and
sane,
then
mark
is
mandatory
and
if
it
comes
to
the
case
where,
for
some
reason
a
server
is
unable
to
return
the
value
it
just
doesn't
give
it
to
you,
so
it
just
doesn't
send
anything.
So
I'm
I'm
not
sure
that
this
is
a
problem.
You
want
to
solve
this
way
here,
because
because
either
it's
a
generic
yang
issue,
I'm
not
a
generic
solution
or
or
otherwise.
G
G
Not
not
recently
that
I
can
think
of
it
did
come
up
in
the
discussion
to
the
nmda
architecture,
where
the
there's
text
in
that
that
effectively
says
that
the
server
is
allowed
to
not
return
data
in
these
sort
of
scenarios
and
the
one
case
that
is
interesting
is
if
you
have
telemetry
and
your
stream
telemetry
off
the
box.
Then
if
you
don't
send
a
value,
then
you
have
a
case
where
you
don't
know
it's,
you
got
no
value
or
just
the
receivers
expected
to
have
the
previous
value
received.
G
F
F
F
G
D
G
C
G
H
C
C
I
I
If
you,
if
you
don't
report
an
attribute,
there
was
an
interest
for
the
client
to
know
whether
the
attribute
is
missing,
because
it
has
not
to
be
reported
for
that
specific
configuration
or
it
is
missing
because
for
some
reasons
it's
not
available
it's
unknown
and
that's
the
reason
why
we
had
these
this
different,
not
reporting
at
all.
It
doesn't
give
this
this
capability
to
notify.
C
G
And
just
one
other
thought
on
that
is
again.
I
didn't
quite
pick
up
the
nuance
of
the
different
sort
of
not
reporting
the
values
you're
saying
there,
but
it
may
be
that
you
would
be
better
off
if
you
need
to
get
that
extra
distinction
in
there
to
have
an
enumeration
as
your
second
union
type.
And
then
you
could
have
enumerated
value,
that's
more
clear
as
to
to
what
it
means
to
return
that,
rather
than
returning
null
like
returning
empty,
is
quite
strange
thing
to
return
operationally.
F
So,
for
example,
we
have
created
the
the
the
list
of
type
def
in
layer,
zero
type
extension
I
don't
know
like,
for
example,
type
def
power
in
db
or
null,
and
in
this
case
we
have
the
junior
union
between
the
power
in
db
and
and
then
the
eptic
case,
and
in
parallel
we
have
changed
a
lot
of
attributes
putting
the
union
instead
of
the
single
time.
This
is
what
we
have
done.
F
Okay,
as
usual,
we
track
tracking
open
issue
in
this
link
and
we
closed
9
issue
since
the
last
itf.
We
have
still
11
open
issue.
Well,
we
have
11,
but
there
are
some
issue
to
this
for
in
the
first
ballot
that
we
already
know
how
to
solve
that,
and
so
I
will
be
solved
with
the
next
pull
request,
because
I
already
discussed
and
agreed
they
the
the
the
issue
88.
F
F
C
F
F
F
F
F
That
is
just
for
bit
rate
that
is
to
to
indicate
the
gross
bit
rate
like
100
200
300
for
optical
tributary
signal,
but
we
still
exploit
atlanta
bitrate
leaf
in
case
of
standard
reference
when
there
is
not
just
the
bit
rate
that
is
needed,
but,
for
example,
also
modulation
format,
because,
for
definition
of
line
coding
in
itu-t
line
coding
is
more
than
the
line.
Bitrate
is
just
representing
other
attributes.
F
F
Okay,
here
is
the
modification
we
have
done
related
to
the
issue
99
we
discussed
before
in
optical
impairment
for
the
empty
in
case.
We
do
not
get
value
in
in
some
cases,
so
we
introduce
new
type
def
for
that
and
update
types
in
optical
impairments
and
the
layer,
zero
type
extension
in
some
grouping
with
the
new
type
empty
and
with
the
union
between
the
value,
the
the
the
former
type
and
the
new
type
empty.
F
E
C
Example
recently
I've
seen
a
draft.
I
don't
remember
which
one
where
the
authors
were
requested
to
just
write
a
small
draft
with
an
update.
So
I
don't
know
so
sorry,
john,
for
bothering
you
again.
I
know
it's
pretty
early
for
you,
but
can
you
please
confirm
that
the
bc
is
the
right
way
to
go
here
or
do
you
prefer
an
update
like
they
are
doing
in
this.
C
So
this
is
we
we
recently
published
rfc
1993..
This
is
a
an
update
to
that
one.
We
are
adding
some
parameters,
some
concepts
that
we
removed
in
order
to
have
1993
published
pretty
pretty
fast.
I've
seen
two
different
ways
of
solving
this
issue.
The
one
is
to
go
for
abyss
and
the
other
one
is
to
write
a
small
draft
with
just
an
update
I've
seen
in
the
past
that
the
visa
was
the
most
widely
adopted
solution
here.
B
A
J
J
J
J
So
there
are
three
other
bullets
just
say.
For
example,
layer,
one
vpn,
t,
topology
and
t
tunnels
can
be
considered
as
a
realization
of
an
otn
slice
and
also
we
briefly
touched
the
discussion
on
whether
otn
slice
mbi
is
a
top-down,
is
used
as
a
top-down
configuration
or
bottom-up,
and
the
conclusion
is,
it
is
an
intent
interface
which
can
be
used
as
a
top-down
configuration
to
to
configure
an
otn
slice.
J
Nltn
slice,
as
I
will
show
on
the
next
page,
and
we
also
added
a
text
to
clarify
the
relationship
between
otn
slice
intent
and
its
realization,
which
is
which
can
be
used,
can
be
realized
by
any
existing
means.
As
shown
on
the
previous
page,
we
added
text
to
clarify
that
otn
slice
control
mpi
is
technology
specific
and
augments,
the
ietf
network
size
mbi.
J
There
are
with
with
other
cosmetic
updates
next
page,
so
here's
a
an
updated
diagram
on
the
right
side
and
in
which
we
clearly
marked
the
three
different
options,
as
there
can
be
used
to
create
an
otn
slice
with
option,
one
being
the
ietf
network,
slice
controller,
directly
interface
with
the
pnc,
and
in
this
case
no
tns
slice
controller
is
used
and
in
option.
Two.
J
Next
page,
there
is
a
very
little
young
model
updates
in
this
revision
and
just
to
to
format
just
on
the
formatting
to
conform
with
the
young
guidelines
and
we
plan
to
make
additional
updates
once
we
clarify
the
way
moving
forward
with
otn
slicing
next
to
page,
we
also
did
some
discussion
on
harmonizing
with
the
network
slides
and
via
yeah
as
yeah.
As
I
think
I
already
said,
we
agreed
for
the
otn
slice,
young
otn
slice
control,
mpi
model
to
augment
the
network
slice
mbi
model
from
my
from
tees.
J
We
are
currently
analyzing
the
model
structures
and
for
the
network,
slice
mbi
moves.
Just
specifically,
we
are
checking
whether
the
network
slice
mpi,
contains
all
the
required
parameters
for
otn
slicing
and
whether
which
parameters
are
technology
agnostic,
which
could
be
technology
specific
for
ip
etc,
and
whether
we,
whether
the
base
model
the
network
size
mbi,
can
support
resource-based
slicing
with
topologies.
J
The
the
main
thoughts
towards
that
change
is
that
we
have
an
mdsc
which
could
consist
of
a
service
orchestrator
as
well
as
a
network
orchestrator,
and
in
that
respect,
the
ietf
and
sc
mbi
slash
otn
sl
otns
mbi
is
equivalent
to
an
interface
between
the
mdc
service,
orchestrator
and
network
orchestrator,
and
there's
there's
currently
no
official
name
for
that.
But
I
I
think
we
will
leave
for
the
author
of
that
drafted
to
clarify
next
page.
J
So
the
next
steps
for
this
draft
is
to.
We
will
continue
to
address
the
comments
from
the
working
group
and
we'll
start
the
work
to
align
and
augment
ietf
network
slice
yang,
and
we
will
add
otn
technology,
specific
definitions
such
as
slos
and
other
parameters.
According
to
the
next
discussions
yeah,
I
think
that's
it
any
questions
comments
more
than
welcome.
J
I
think
that
the
main
issue
raised
by
igor
on
whether
it's
necessary
to
have
otn
slicing,
I
think
it
has
been
addressed
and
have
has
been
concluded,
as
shown
in
the
slides
there
are.
There
are
a
few
other
questions
about
about
slicing,
but
I
think
it's
it's
not
otn
specific.
It's
it's
a
slicing
in
general
right
that
can
be
addressed
by
teeth.
J
So
for
that,
for
example,
one
other
question
is
whether,
like
a
slice,
could
support
just
a
p2p
or
like
it
could
support
the
p2p
p2
p2
mp
or
mp2mp.
It
has
to
support
all
of
them
in
order
to
consider
to
be
considered
as
a
as
a
slicing
service.
I
think
those
kind
of
questions
are
really
relevant
to
network
slicing
in
general
and
can
be
done
in
teas,
yeah.
C
Yes,
in
fact,
I
mean
adrian
was
presenting
the
other
thing
the
other
day
and
he
was
asking
if
there
were
questions
coming
from
c
camp
that
the
states
needed
to
be
addressed.
But
I
think
that,
with
the
discussion
that
we
had
on
that
is
meeting
list,
we
should
consider
all
these
issues
the
more
or
less
solved.
If
there
is
any
anything
else
left
to
discuss.
K
K
So
hi
good
morning,
we
wanted
to
provide
a
quick
update
on
two
documents:
the
the
flexigrid
dug
document.
One
was
the
topology.
The
other
is
the
tunnel
and
also
just
raise
some
issue
that
we've
actually
been
having
that
not
only
affects
these
two
documents
but
also
affects
other
ccap
and
also
tease
documents
in
the
way
that
we
use
augmentations
and
when
statements
so
danielle,
I
don't
don't
have
the
ability
to
advance
the
slides
yeah.
E
K
K
We
really
kind
of
just
had
to
resolve
the
issue
with
the
augmentations
that
that
that's,
that
that
was
the
main
issue
with
the
document,
and
that's
really
why
why
the
document
was
slightly
delayed,
and
I
will
I
will
cover
that
with
some
slides
a
little
later.
But
for
all
intents
and
purposes
the
topology
document
flexigrid
is,
is
now
finished
and
if
the
working
group
is
happy
with
our
solution
for
the
augmentations,
then
we
will
proceed
with
this
document
and
submit
it
next
slide.
Please
so
the
the
tunnel
documents.
K
Oh,
there
is
a
slight
typo
there
just
to
see
if
anyone's
paying
attention
still
we
actually
changed
it
from
media
channel
to
to
tunnel.
But
essentially
this
is
a
document
which
isn't
as
mature
as
the
flexigrid
topology
document.
There's
there's
still
quite
a
bit
of
work.
That
needs
to
be
done
with
the
document.
The
code
itself
is
is
relatively
stable,
but
there
has
been
some
dependencies
with
other
documents.
K
There's
also
some
specific
sort
of
technical
discussions
required
for
things
like
the
way
the
tunnel
is
used
and
dependencies
or
associations
with
the
ots
ig,
specifically
the
tunnel,
identifiers
and
and
path
set
up.
So
there's
also
some
further
sort
of
ancillary
work.
That's
happening
with
the
path
computation
document
as
well,
so
we
we
just
expect
this
document
to
have
multiple
issues
that
are
going
to
be
discussed.
As
you
probably
remember,
we
have
a
a
weekly
call
for
the
flexigrid
documents.
K
The
focus
is
now
really
on
the
tunnel
document
itself,
but
we've
we've
also
moved
the
path
computation
discussion
into
our
flexiwood
calls.
So
when
you
see
the
invites
for
the
flexigrid
discussion,
I
should
really
sort
of
add
our
sort
of
optical
path,
computation
topic
to
that
as
well,
and
those
calls
have
been
postponed
just
prior
to
and
during
ietf
113,
but
those
will
restart
after
113.
K
In
fact,
danielle
could
you
go
on
to
the
next
slide?
Now
I'll
skip
this
one?
So
what
was
the
issue
that
affected
the
topology
document?
And
you
know
I
think
here
we
need
to
kind
of
highlight
the
great
work
that
our
our
young
doctors
do
when
they
review
the
anco.
There
is
obviously
a
lot
of
technology,
specific
content
that
they
have
to
kind
of
pass
and
for
c
c-camp
and
tease.
We
have
a
tendency
to
use
with
our
yang
models
at
numerous
augmentations,
often
numbering
sort
of
tens.
K
So
that's
that's
a
lot
of
work
that
needs
to
be
done,
not
not,
obviously
by
just
the
young
doctor,
but
anyone
who's,
actually,
a
human
who's
sort
of
reading
through
or
passing
this
document
next
slide.
Please
so
there's
good
news.
Actually
there
is
a
function,
it's
a
x
or
an
axis
or
a,
and
it
uses
this
thing
called
an
ancestor
function.
K
So
this
is
this
is
a
cool
feature
and
we
started
using
it
extensively
in
our
documents
and
next
slide.
Please
we
hit
an
issue
when
we
started
uploading,
our
our
new
internet
drafts
through
the
submissions
tool,
because
it
turns
out
it
breaks
one
of
the
tests
that
is
performed.
So
the
the
yangling
test
is
actually
something
that
happens
when
you,
when
you
upload
your
document
or
you
can
use
it
to
sort
of
test
code
before
you
submit,
and
this
we
thought
would
be
maybe
just
a
a
minor
issue.
K
K
K
So
we
are
kind
of
you
know
we,
we
we
bounced
sort
of
backwards
and
forwards
for
about
a
month,
just
really
trying
to
figure
out
what
to
do
here.
Ultimately,
from
an
implementation
perspective,
when
it's
you're
read
by
machine,
it's
it's
not
a
major
issue,
but
considering
you
we
we
do
expect
more
young
models
in
the
future
and
there
are
sort
of,
I
suppose,
not
just
impacts
here
for
c-cam,
but
also
teas
it.
K
It
would
be
worth
kind
of
widening
the
discussion
beyond
the
flexi
grid,
folks
to
see
what
what
other
people
thought
of
this
for
the
time
being.
We've
reverted
back
to
our
previous
code
base,
as
mentioned,
so
we're
no
longer
using
the
ancestor
function,
which
is
a
shame,
but
that's
where
we
are
now
because
we
just
wanted
to
move
ahead
with
the
document.
K
E
G
Sorry,
I
didn't
realize
I
put
my
hand
up
and
then
the
me
taker
wasn't
quite
working.
Yes,
I
I
actually
think
here
my
personal
preferences.
If
it,
if
the
existing
one
works,
then
that's
going
to
give
you
the
widest
sort
of
deployability.
Most
tools
are
going
to
work
with
that,
whereas
if
you
try
and
do
the
sort
of
clever
thing,
even
though
technically
it
might
be
allowed,
I
would
suggest
you
you're
more
likely
to
hit
tooling
issues
in
future.
G
I
think
if
we
want
to
support
this,
I
suggest
this
goes
on
like
the
yang
next
issue,
tracker
and
he's
more
explicitly
thought
about
in
the
context
of
an
updated
version
of
yang
would
be
my
view
on
this.
I
think
you
that
keeping
it
simple,
even
though
you've
got
the
longer
expressions,
is
probably
the
best
way.
That's
just
my
my
personal
opinion.
B
Yeah,
I
was,
I
actually
put
myself
in
line
to
say
almost
the
same
thing
you
did,
which
is
yeah.
If
we
need
to
ship
it
right
away,
then
do
the
pragmatic
thing,
but
if
we
you
know,
can
afford
to
to
take
our
time,
then
I
mean
it
sounds
from
rob's
comment
and
rob
I'd
be
interested
in
your.
You
know
read
back
if
I'm
understanding
you
right
that
this
isn't
thought
to
be
like
we're
using
it
wrong.
B
G
So
rob
so.
I
think
I
need
to
look
a
bit
more
closely.
Exactly
what's
being
used
here
is
xpath
in
its
use
in
its
usage
of
in
yang
the
sort
of
some
bits
of
x
bar
that
they
want
and
some
bits
of
x
path
you
just
get,
because
it's
x-path
and
in
terms
of
the
implementations,
I
suspect,
a
lot
of
them
just
do
the
basic.
G
I
want
a
path
into
the
tree
type
thing
and
don't
do
the
more
complicated
stuff
of
of
actually
allowing
different
sorts
of
ancestors
and
searches,
and
things
like
that,
because
you
can
write
these
sort
of
more
concise,
x-path
expressions,
but
it's
just
more
likely
that
tooling,
that
should
handle
this
just
won't
because
they
just
do
the
basic
things.
So
that's
my
concern
is
that
I'm
not
sure
whether
they
will
be
running
a
generic
xpath.
G
Parser
might
also
be
I'll.
Have
a
look.
The
other
thing
is
to
see
what
the
yang
author
guideline
says,
because
they
may
well
also
have
some
recommendations
here.
I
think
there's
some
text
about
that.
I
can
check
that,
but
I
don't
mind
you
trying
it,
but
I
think
it's
definitely
worth
having
a
wide
discussion.
D
K
Issue
for
us
right
now,
we
can
continue
with
the
document.
Obviously
there
are
other
documents
that
are
sort
of
complementary
to
this.
Anyway,
we
will
highlight
this-
I
guess
with
some
of
the
other
document
authors
in
in
teas,
and
follow
up
again
with
the
guys
in
that
mod
and
just
you
know
see
where
we
are
in
another
month
or
so.
I
Yes,
thank
you
yeah.
When
we
do,
my
understanding
is
from
the
manual
discussion
from
the
rsc8407
is
that
it
is
a
legitimate
use
on
chestnut.
The
problem
is
that
if
the
tool
does
not
support
it,
there
will
be
a
roadblock
to
the
adoption
by
the
market
of
our
module,
and
that's
why
my
suggestion
is
to
to
go
with
a
relative
partner
and
in
the
future
if
and
become
supportive.
I
I
I
I
Next
slide
what
we
changed
from
the
previous
version,
we
added
the
ayana
considerations
and
we'd
added
some
acknowledgements,
because
an
initial
version
of
zone
flex
will
be.
The
computation
model
has
been
taken
out
from
the
from
the
from
the
from
their
drafts
and
we
put
acknowledgement
to
sal
to
their
authors,
for
the
initial
work
or
to
the
authors
of
those
we
didn't
join
this
traffic
document.
I
I
We
did
a
major
changes
on
the
double
zone
and
flexibility
computation
based
on
the
weekly
call
discussion
and
in
particular
the
changes
has
been
reflected
in
the
llc
1993
bs.
Only
a
zero
part
constraint
is
properties
and
we
are
using
them
to
con,
configure
the
gsnr
margin
and
report
the
estimated
json
r
in
the
computational
response.
I
Next
slide:
okay,
one
open
issues
since
the
last
meeting
is
again
how
many
modules
there
are
many
documents.
At
this
moment
we
have
one
document
with
the
three
modules
and
we
we
see
that
the
otm
pack
rotation
is
quite
are
related
to
the
other
documents.
Toyota
modules.
Sorry,
while
that
doesn't
complexity,
computation
has
a
lot
of
commonalities
among
themselves,
especially
because
all
the
otsi
related
the
configuration
is
independent
from
whether
the
grid
is
fixed
or
flexible.
I
While
the
label
specific
information
which
is
related
to
the
grid,
configuration
is
different
between
amazon
and
flexigrid
and
we
are
using
the
types
in
the
c93bs
actually
1993,
which
are
common
between
the
computation
and
doubles
and
topology
models.
So
the
the
doubts
that
we
have
is,
what
do
we
do
here
and
we
had
some
discussion
in
the
last
few
days
among
quotas
and
our
proposal
as
as
quarters
is,
maybe
we
can
have
one
document.
We
can
split
into
two
documents.
I
In
one
document
we
develop
the
otm
computation,
which
is
quite
independent
from
the
other
one
and
also
has
a
different
maturity
level,
and
in
the
second
document
we
we
try
to
put
together
into
one
module
as
well.
The
w
zone
and
flexibility
computation
configuration
modules
into
one.
We
need
to
understand
how
to
reconcile
the
issue
with
the
label
configuration,
but
we
can
exploit
this
option
and
see
what
are
the
whether
it
is
technically
feasible.
I
L
D
I
C
C
Keeping
layers
in
layer
1
separator
is,
he
is
a
good
idea
as
well,
because
I
mean
we
have
different
implementations
that
only
care
about
the
optical
and
only
care
about
the
piano.
So
keeping
the
documents
separate
there
is
is
a
good
idea
as
well,
but
I
mean
this
is
just
let
me
say
a
reflection
I
I'm
open
to
whatever
the
working
group
believes
is.
That
is
the
best
idea.
E
M
M
M
M
In
the
current
model
proposal,
most
of
the
object,
just
like
chases
slot,
sub
slot
etc
are
defined
as
never
elements
component
and
they
are
distinguished
by
their
class
in
real
network
scan
scenario.
If
the
output
system
want
to
do
a
full
synchronization,
we
can
now
retrieve
all
the
network
elements,
including
the
their
components
and
one
request,
because
no
system
can
bear
so
such
huge
amount
of
data
and
the
number
of
each
component
time
in
in
one
network
element
is
not
certain
so
so
that
it
is
hard
to
use
pagination.
M
So
one
possible
way
is
that
the
network
controller
provides
retrieving
data
from
network
animals
one
by
one
and
secondly,
in
currently
relational
database.
Implementation
are
commonly
used
in
ict
industry
and
for
different
in
one
to
object.
They
are
safe
in
different
tables,
both
in
the
network
controller
and
the
other
system.
M
So
when
doing
the
full
synchronization,
the
network
controller
shall
combine
component
objects
together.
According
to
this
modal
structure,
while
the
upper
system
needs
to
cross,
classify
and
and
so
them
into
different
group,
this
combination
and
sorting
progress
is
inefficient,
even
if
the
time
consumed
from
one
narrow
element
is
not
too
much,
but
it
increased
by
increased
linearly
with
the
number
of
network
elements
and
could
become
hours
with
10
thousand
never
ends
game
network.
M
In
the
first
step,
the
client
can
collapse.
Some
other
inventory
object
which
are
not
defined
under
the
network
element,
for
example,
equipment,
room
and
racks,
and
then
the
kind
can
start
to
synchronize
the
network
elements,
data
and
and
the
components
underlay,
but
before
that,
you
need
need
to
retrieve
the
identifier
of
all
the
network
elements,
but
this
step,
but
don't
take
too
much
time.
M
M
M
M
M
In
parallel,
we
will
analyze
more
use
cases
considering
other
technologies,
and
we
think
that
the
job
is
ready
for
working
group
adduction
and
the
technical
issue
can
be
addressed
through
normal
working
group.
Progress
process
also
in
contributed
have
a
weekly
meeting
every
so
here
I
make
some
mistakes
every
wednesday
from
10
a.m
to
11
a.m
in
american
central
standard
time.
M
C
I
didn't
remember
that
you
already
had
the
the
the
draft
presented
in
opsa
working
group.
That
is
extremely
good,
so
if
they
are
happy
to
have
the
draft
being
progressed
as
it
is
in
c
camp,
I
think
that
we
can.
We
we
we
can
make
we
can
make
a
poll
is
my
understanding
that
correct
that
the
obstacle
working
group
is
is
happy
to
have
that
the
work
being
done
in
sea
camp.
M
G
Hi
sorry
robinson
I've
not
been
able
to
review
this,
but
I
do
think
that,
with
the
overlap
with,
maybe
the
entity
yang
model,
that's
there
today
somewhere.
Maybe
this
is
a
network
wide
one.
I
basically
need
to
review
this.
It
may
be
that
this
might
be
better
to
do
in
the
ops
area
rather
than
see
cam.
I
just
want
to
understand
what
the
scope
of
this
document
is.
G
I
want
to
make
sure
that
we
get
sufficient
reviews
across
the
right
areas
to
make
sure
that
we
don't
we're
not
standardizing
a
very
generic
thing
within
this
working
group
and
start
getting
sufficient
reviews.
So
I
think
that's.
The
key
thing
to
me
is
make
sure
we
get
those
reviews
they're
not
saying
it
can't
be
done
here,
but
that's
one
one
aspect,
the
other.
The
other
comment
on
in
terms
of
the
structure.
G
Again,
I
haven't
actually
reviewed
the
documents.
So
it's
hard
to
comment,
but
in
terms
of
flexible
models,
it's
worth
looking
at
the
open,
config
platforms
yang
model
because
they
have
a
way
of
being
quite
generic
and
flattening
a
tree-like
structure
down
into
a
list
with
parent
and
and
sub
parent,
subcomponent
or
children,
pointers
that
allows
you
to
have
fairly
generic
structures
and
still
have
the
data.
So
I
think
that
that
approach
may
possibly
work
here
or
it's
worth
looking
at.
M
C
He
could
easily
so
sorry.
I
was
just
saying
that
it
could
easily
be
that
the
the
the
draft
might
end
up
being
split
into
two
parts,
one
of
which
is
a
generic
and
will
be
progressed
in
in
the
opposite
working
group,
and
there
might
be
a
more
specific
one
that
we
can
take
in.
Second,
that
that's
a
a
fairly
viable
option
as
well.
G
Yeah
yeah,
let's
just
say
it's
just
trying
to
find
the
reviews,
get
the
right
reviews,
I'm
not
that
concerned
about
where
the
document's
done.
It's
just
making
sure
we
get
the
right
comments
and
things.
If
you
drop
me
an
email,
then
then
I
can
they
follow
the
discussion
on
that
side
and
also
I
can
give
you
a
point
in
terms
of
the
structure,
but
I
need
to
review
this
anyway.
Okay,
thank
you.
G
L
In
a
good
order
to
come
right
after
robert
yeah
yeah,
actually
I
agree
with
danielle
saying
that
the
ops
awg
expert
is
feeding
back
saying
that
this
model
is
quite
close
to
the
hardware
inventory
when
it
looks
well.
Currently,
the
term
inventory
is
a
little
bit
misused
or
overused
in
the
ops,
awg
and
the
same
terminal
having
different
meaning
so
it
it
would
be
extremely
useful
to
clarify
the
quote
for
each
inventory,
related
work
and
the
expert
some
of
the
experts
fit
that
with
us.
N
C
C
O
O
O
It
uses
the
flexi
the
information
and
it
also
defines
some
privacy
adaptation
functions
from
two
termination
functions
and
the
relevant
management
information
in
ietf.
Second
or
group,
there
are
several
jobs.
Talking
about
flexi
frame
controls
and
configuration
models
currently
using
the
proxy
computer
model.
Draft,
get
a
good
catch
of
previous
discussions
about
flux,
modeling
and
gives
a
basic
effect
c
configuration
model.
That's
a
good
start
point
to
put
forward
the
flexi
modeling.
Thank
you
next
page.
O
Based
on
the
standards
and
the
drops
mentioned
and
some
discussion
in
the
mail
list,
convergence
requirements
are
summarized
into
three
categories
here
you
can
see.
Flex
group
reflects
calendar
from
the
first
client
for
the
flight
scope.
It
includes
such
requirement
as
configuring,
the
device
google
play
wireframe
configuration
and
if
inconsistency
exists,
notifications
to
be
invoked
for
the
flux
current,
the
requirements
include
configuration
updating
the
usage
state
of
canada,
source
and
verification
for
flex
client.
O
O
O
G
Hi
robinson,
yes,
thank
you
for
this.
I
think
it's.
I
know
that
the
record
was
trying
to
work
on
flexi
previously
and
then
that
work
sort
of
got
stopped,
and
so
I'm
really
pleased
to
see
this
coming
back.
I
think
it's
great
for
you
to
work
on
a
model
in
this
area
and
to
get
that
done
so
so
that
I'm
really
pleased
with
I
sort
of
agree
also
agree
that
merging
these
two
drafts
together,
the
one
that's
talking
about
applicability,
the
actual
yang
model
that
makes
sense
to
me.
G
Often
you
sort
of
see
examples
of
how
to
use
the
ammos
in
the
appendix.
So
that's
a
good
thing
to
do.
One
comment:
I've
got
in
terms
of
this:
the
current
structure,
the
model-
this
is
probably
more
on
the
other
draft
than
this
one
is.
I
questioned
a
bit
about
having
the
flexi
client
configuration
under
the
client
interface
rather
than
having
it
under
the
sort
of
flex
e
container
that
you've
got
on
on
slide
five.
G
So
it's
about
side,
five
and
seven,
and
my
reasoning
for
that
is
that
the
flexi
client
configuration
isn't
really
so
much
about
the
client
interface
as
in
everything
else,
you
would
normally
expect
to
be
on
there,
but
it's
actually
related
to
how
the
flexi
interfaces
are
set
up.
So
if
you
look
at,
for
example,
a
time
slot
list
that
list
isn't
sort
of
independent
of
each
client
interface,
you
need
to
make
sure
that
the
time
slots
you're
using
are
sort
of
organized
with
the
other
client
interfaces
under
the
same
flexi
as
a
group
interface.
G
C
O
C
I
I
only
have
one
question
I
mean
I
I
will
I'm
seeking
for
confirmation
from
you.
There
was
another
draft.
Another
configuration
model
draft
a
while
back
that
was
left
to
expire.
That
seemed
to
be
competing
with
the
configuration
model,
not
with
the
one
that
you
just
presented,
but
more
with
the
configuration
model.
C
I
don't
know
how
the
let
me
say
the
competition
was
assault.
It
was
just
that
the
other
one
was
left
to
expire
or
a
solution.
A
common
ground
was
founded
between
the
two
drafts
in
the
in
this
configuration
model,
because
I
mean
I'm
I'm
happy
to
merge
these
two
drafts
and
progress
them,
but
I
would
like
to
make
sure
that
this
is
something
that
everyone
is
happy
with
is
not
that
we
are
leaving
something
competing
behind
and
forgetting
about
it.
C
P
P
P
P
P
P
A
high
quality
private
land
on
intel
support,
unlocked
fundraise,
low
latency,
high
security,
high
reliability
and
the
proposed
control
and
management
system
of
of
the
new
optical
network
should
support
differentiation
of
sra
adapted
to
dynamic
performance
chains,
be
aware
of
traffic
demand
and
faster
deployment
to
customer
customers.
The
event
next
slide,
please.
P
It
turned
into
the
bandwidth
next
step,
please
so
in
summary,
and
requirement
for
the
control
and
management
service
for
optional
network
to
exercise
clause
need
to
support
the
following
core
features.
The
first
is
it
supports
supporter
various
such
as
earth
are
one
two
are
three
sorry
service
to
to
assess
the
clause.
P
P
K
Hi
hi
guys
thank
you
for
the
presentation
and
I
just
noticed
on
your
summary
slide
that
that
you're
looking
for
contributions
and
sort
of
interest
in
the
work,
the
use
cases
were
quite
high
level.
It
will
be
really
interesting
to
know
what
specific
requirements
have
been
derived
from
those
use
cases.
K
So
there
is
maybe
some
interesting
requirements
that
we've
identified
in
that
project.
Although
it
is
research,
it
has
commercial
applicability.
There
are
operators
involved
in
the
project,
so
I'm
wondering
if
there's
maybe
some
some
technical
findings,
conclusions
that
we've
sort
of
documented
that
may
be
useful
for
this
work.
I
will
post
those,
maybe
in
the
chat
window
and
follow
up
with
you
offline.
L
As
a
few
more
information
from
the
previous
days
on
this
ietf
meeting,
we
are
also
aware
of
some
nice
work
from
irtif
from
the
cam
buff
and
from
some
other
work
groups
talking
about
the
future
of
the
routing
protocols,
and
it
looks
we
are
also
from
this
draft.
We
are
also
evaluating.
Where
is
the
filter
gaps
and
try
to
find
the
next
objective
we
are
setting
to
the
current
protocol
stack
and
yeah?