►
From YouTube: IETF112-CCAMP-20211111-1600
Description
CCAMP meeting session at IETF112
2021/11/11 1600
https://datatracker.ietf.org/meeting/112/proceedings/
B
Okay,
so
right
now
can
we
start.
B
So
everyone
can
see
my
screen.
B
B
Okay
sounds
good:
okay,
hello,
everyone,
let's
start
so
you
know
welcome
to
our
sitcam
session
so
good
morning,
good
afternoon,
good
evening.
B
Let's
start
from
the
first
page:
okay,
as
always,
let's
start
from
the
load.
Where
information
you
know.
Actually
this
demand
about
the
ietf
policies
and
you
know
arduino,
by
participating
in
the
ietf.
We
have
to
follow
itf
process
and
policies,
especially
ipr
policies.
So
you
know
there
are
a
couple
of
the
documents
about
the
bc
bcp.
B
And
this
time
we
have
only
one
session
with
two
hours
and
you
can
get
some
detailed
information
from
the
the
link
and
also
download
some
slides.
B
So
this
the
agenda
this
time
we
still
have
you
know
busy
agenda.
Actually
we
have
two
hours
for
for
decision,
but
we
we
have
nine
presentations
and
five
of
them
are
about.
You
know
our
individual
jobs,
so
maybe
we
can
have
more
discussion
on
their
own,
especially
some
some
new
jobs.
B
So
for
an
administrative,
so
you
know
actually
because
of
that
cop19
we
are
used.
You
know
to
have
enter
online
meeting
by
the
with
echo.
So
I
think
we
know
how
to
use
the
on
this
kind
of
online
tour.
B
And
then
for
the
minute
takers,
so
if
anyone
can
take
some,
you
know
minutes,
and
that
will
be
much
appreciated
and
I
also
ask
how
men
to
help
us
and-
and
I'm
not
sure,
if
for
those
kids
it's
it's
joining
or
not,
maybe
security
is
not
online.
Let
me
check
oh
oscar
you
are
here.
B
And
then
blue
sheets,
so
actually
you
know
the
blue
sheets
will
be
created
automatically
and
nothing
for
us
to
do,
and
then
we
have
the
reminder
about
the
ipr
process.
You
know
you
know
before,
for
example,
an
individual
draft
becomes
to
a
working
group
document
or
a
working
group
document
goes
to
last
call.
The
chairs
were
sent
out
to
ipr
polling
and
then
it
requires,
after
you
know,
authors
and
the
contributors
to
the
sponsor
polling
as
soon
as
possible.
Otherwise
it
might
delay
your
you
know
or
draft
to
move
forward.
B
And
then
about
the
main
list,
we
always
encourage
people
to
use
the
main
list
as
much
as
possible.
You
know
we
can.
You
know,
for
example,
introduce
some
discuss
some
open
issues
or
introduce
some
new
ideas
or
and
some
new
jobs
on
the
list,
and
also
we
may
you
know,
discuss
some
potential
on
new
topics.
B
You
know
relevant
to
the
camp,
and
also
this
one
important
implement
is
that
booking
group
consensus.
You
know
it's
determined
on
the
main
list,
rather
than
if
we
got
some
consensus
in
the
you
know
online
meeting
and
we
still
need
to
bring
to
the
list.
B
A
Both
are
young
models;
basically,
the
first
one
is
the
layer,
zero
types
and
the
second
one
is
the
young
data
model
for
ws
on
wson
networks.
A
A
We
have
a
bunch
of
working
group
drafts
being
discussed
today,
most
of
them,
if
not
all,
are
young
models.
Basically,
we
have
the
optical
impairment
topology
the
extension
to
the
layer,
zero
types.
If
you
could
remember,
we,
we
published
the
layer,
zero
types
and
immediately
after
that
we
started
working
on
an
extension
of
them
to
include
also
transponders,
etc.
A
A
There
are
no
big
changes
since
the
the
last
meeting
on
them.
We
have
the
interface
documents
with
lmps
functions
and
the
young
model
for
interface
parameters.
A
We
have
the
applicability
of
otn
beyond
100
gigabits,
but
this
is
just
I
mean
this
is
already
at
a
pretty
advanced
stage.
I
don't
think
anymore.
We
will
see
any
more
changes
there.
A
A
Next,
please
a
brief
update
on
some
of
on
some
of
them.
We
have
the
layer,
one
types
which
is
basically
the
final,
the
the
young
types
for
for
layer,
one
we
have
minimal,
updates
updates
there.
It's
this
is
ready
for
to
be
to
be
published,
to
be
moved
forward.
A
A
A
We
needed
to
request
for
the
young
doctor
review
next
next
ones.
We
are
next
ones.
Yes,
we
have
the
later
one
csm.
This
is
more
keep
at
life.
This
is
ready
for
working
group
las
cola.
There
is
a
dependency
on
the
layer,
one
types
but
player.
One
types
is
almost
almost
there
as
well
the
nbi
applicability
statement.
This
was
last
called
it.
It
has
been
put
on
old
to
try
to
put
it
on
a
diet,
as,
as
don
said.
C
Hello,
can
you
hear
me
hi
hi,
yes,
hi
everybody,
I'm
sergio
belotti
speaking
from
nokia,
I'm
going
to
provide
the
status
and
they
about
optical
impairment,
topology
young
model,
on
behalf
of
the
other
quotas
and
contributors.
C
Okay,
we
have
a
group
that
is
actually
weekly
hour
meeting
in
which
we
progress
the
document
and
we
are
going
on
on
to
have
this
weekly
and
and
work
during
this.
C
The
time
dedicated
to
that
there
are
from
the
last
itf.
We
have
provided
that
a
lot
of
work,
because
we
have
progress
both
in
the
text
of
the
draft
in
which
we
we
added
the
section
about
existing
the
the
reason
to
know
the
existing
tsi
signal
for
oms
link.
C
We
started
to
resolve
the
issue
that
was
presented
in
the
last
itf,
the
83
that
was
regarding
3r
regenerator,
and
with
this
solving
the
issue,
we
complete
the
trial
modeling
and
then
we
fix
it.
The
other
issue
on
the
on
the
model
next.
C
So
this
slide
is
just
as
the
background
for
the
neck
for
the
last
meeting,
so
we
left
lift
left
each
other
in
the
111
itf
with
this
problem,
so
how
to
associate
the
transceiver
to
provide
the
trial
in
3r
configuration-
that
is
a
trivial
case
in
in
the
case
of
tsig,
is
presented
just
one
otsi,
but
is
not
trivial
in
case
we
have
multiple
tsi.
C
C
So,
to
solve
the
issue,
we
have
a
a
detailed
discussion
and
basically
the
conclusion
was
to
base
the
solution
of
to
model
the
connectivity,
considering
primarily
the
real,
the
real
physical
constraint
and
the
physical
constraining,
the
equipment
at
the
node
level,
and
we
made
five
main
assumptions.
The
first
for
the
solution.
C
We
succeed
to
define
groups,
a
regenerator
group
created
a
transponder
level
associating
a
transponder
in
which
way
the
transponder
are.
Any
group
of
of
transponder
represent
a
set
of
transponder
where
there
is
a
an
electrical
connectivity
in
place
so
pre-provisioning,
or
could
be
also
dynamically
provisioned
to
associate
this
transponder
to
provide
a
three-year
trial
generation.
C
In
the
information
related
to
this
regenerator
group,
we
provide
also
an
attribute
that
is
used
for
part
computation
to
express
preference
between
one
to
the
the
group
to
the
other.
They
there
are
no
constraint
in
the
among
transponder
belonging
to
the
same
group.
C
That
means
that
any
transceiver
belonging
to
the
group
can
be
connected
with
any
other
transceiver
belonging
at
the
same
group.
Obviously,
provided
that
you
connected
bound
ltp
with
outbound
ltp,
the
group
is
basically
characterized
by
hardware
characteristics
that
is
not
provided.
That
is,
is
done
at
the
northbound
interface
and
that
the
controller
can
be
reduced
for,
for
example,
at
the
sbi
level,
but
not
needed
to
provide
the
physical
characteristics
at
the
northbound
interface.
C
C
C
Okay,
so
basically,
what
we
made
is
that
these
are
basically
the
the
two
case.
So
in
the
in
the
picture
in
the
middle,
there
is
example
in
which
we
have
four
transponder,
that
is
belonging
at
the
same
group
and
is
the
case
in
which
all
the
the
transponder
is
belonging.
C
So
the
the
the
orange
oval
is
representing
the
fact
that
all
the
four
groups
are
belonging
at
the
same
hardware
device
in
the
bottom
of
the
picture.
We
have
the
case
in
which
they
transponder
are
not
all
belonging
at
the
same
hardware
device
and
we
have
two
oval
orange,
but
since
the
the
the
two
groups,
so
the
the
two
device
at
which
belonging
that
the
two
transponder.
C
Are
considered
as
the
same
group
because
there
is
an
external
cable
that
is
providing
connectivity,
and
so
this
is
the
reason
for
the
blue
oval
that
represent
the
logical
group
that
is,
is
encompassing
all
together
the
different
responders
so
for
norbound
interfaces
application.
C
There
is
no
difference
between
these
two
type
of
examples,
so
the
full
hardware,
device,
common
device
or
two
different
device
belong
is
some
transponder,
but
this
the
the
cable
that
is
connecting
the
two
so.
C
C
Okay,
so
this
is
the
solution
in
the
young,
so
we
provide
the
description
of
this
regenerator
group
with
the
specific
identifier
for
the
group,
the
attribute,
considering
the
way
of
how
to
solve
the
preference
in
the
port
computation
between
different
group
and
the
the
pointer
to
the
transponder
that
is
belonging
at
this
group.
C
The
issue
in
the
local
link
connectivity
list
is
that
what
is
permitted?
It
is
just
to
have
one
entry
for
any
tunnel
termination
point
ltp
pair,
that
in
our
case,
ltp
represented
the
port
of
the
addrop
part
of
the
rodent.
C
C
So
all
four
transceiver
are
connected
to
the
ltp1.
C
If
we
hypothesize
that
there
are
not
the
same
impairments
between
the
different
between
the
four
transceiver,
and
so
we
would
have
four
different
set
of
optical
impairment
for
each
direction.
In
one
entry
of
the
local
link
connectivity,
while
the
the
the
the
standard
definition,
the
local
link
connectivity,
permit,
only
one
set
of
for
for
each
direction.
This
is
the
problem
and
to
solve
that
on
the
right
part
of
the
picture.
C
We
introduced
a
list
of
possible
transceiver
with.
Let
me
say
differentiation
with
respect
the
default
that
this
list
has
to
be
added
in
the
local
link
connectivity,
entry
and
in
in
the
in
for
any
part
of
represent
in
any
element
of
this
list.
C
C
Okay,
here
we,
I
added
the
basic
other
issue
that
we
solve
with
the
enhancement
in
the
model,
so
we
added
the
information
regarding
geolocation
of
amplifier.
C
C
We
added
also
in
the
model
the
possibility
in
the
for
any
oms,
to
associate
any
in
in
the
oms
link
to
associate
a
unidirectional
link
in
case
of
a
parallel
link
between
two
nodes,
so
to
associate
one
link
to
the
other
to
understand
that
belong
at
the
same
at
the
same
oms
part,
and
to
associate
also
the
oms
element
in
the
reverse
direction.
C
C
So
the
here
I
provided
the
situation
of
the
open
issue
we
have,
you
can
see
the
the
link
to
our
github,
which
is
provided
discussion
and
situation
of
the
issue.
C
We
solve
the
twelfth
issue
after
itf
111
and
we
have
seen
a
still
16
open
issue,
but
for
the
moment
we
have
just
the
two
pending
young
model-
enhancement
that
we
need
still
need
to
add,
and
basically
we
have
a
five
review
terminology
that
is
still
needed
it,
and
this,
anyway,
is
the
situation
of
any
issue
that
is
still
remain
in
the
in
the
drafts.
C
C
So
next
step,
obviously
we
wanted
to
address
the
issue
that
remain
open
both
regarding
the
enhancement
that
we
need
to
have
that
at
the
moment
to
issue
regarding
the
model
and
the
editorial
part.
C
We
would
like
to
be
ready
for
young
doctor
review
and
we
hope
to
have
the
possibility
to
have
a
stable
version.
I
mean,
and
for
stable
version
means
that
we
have
a
model
that
is
supporting
all
the
basic
features
that
we
consider
and
an
alignment
in
the
terminology,
and
this
we
hope
by
next
itf
that
we
also,
but
that
it
could
be
also
in
person.
But
let's
see.
C
Now
this
is
backup
just
to
provide
again
the
picture
related
to
the
reference
configuration
for
3r
and
the
usage
of
the
other
slide.
The
local
link
connectivity
that,
as
I
said,
is
used
to
provide
a
drop
impairment
in
the
case
of
for
rodent.
So
this
is
just
as
reference
in
the
case.
You
need
clarification.
B
No
comments,
so
I
I
have
just
one
minor
comment
from
my
side.
So,
regarding
the
next
step,
you
know,
since
there
are
still
you
know,
a
couple
of
open
issues
to
be
fixed,
so
I
would
kindly
suggest
we
send
this
draft
for
young
doctor
review
once
these
open
issues
are
fixed.
C
B
None
okay,
good
and
then
let's
move
to
the
presentation
too,.
B
C
In
in
in
august,
and
there
was
a
meter
0-0
version,
the
update
that
we
provide
at
this
time
is
basically
related
to
an
issue
that
is
coming
from
optical
impairment.
Topology
model-
that
is
the
issue
42
regarding
the
minimum
channel,
spacing
parameters
that-
and
this
issue
is
being
is
brought
together.
Some.
C
Some
modification
in
the
layer,
zero
type
extension,
so
we
need
to
move
to
remove
the
otsi
carrier,
bandwidth
and
nyquist
spacing
factor
we
added
the
new
definition
of
minimum
carrier
spacing
and-
and
we
clarify
names
and
description
of
some
parameters-
the
minimum
central
frequency
max
central
frequency
and
central
frequency
step
to
be
aligned
with
the
text
that
is
providing
the
section
2.5
to
the
4
of
the
optical
impairment
drafts.
So
this
is
basically
the
update.
C
D
D
B
F
E
Trying
to
help,
but
I'd
like
to
clarify
regarding
the
layer,
zero
types
extension.
What
is
the
expectation
of
this
basic
model
supporting
the
other
document?
For
example,
we
understand
that
it
will
be
supporting
the
optical
impairment,
topology
young
module.
Do
we
have
other
media
devices,
for
example
the
flex
grade
the
anthology
or
others.
C
G
C
B
Oh,
maybe
how
mean
the
connectivity
is
not
good.
So
let
me
ask
her
one
more
comment.
So
at
the
next
step.
The
second
says:
you
know
this.
This
draft
or
fcv2
to
b
will
incorporate
updates
from
fc,
you
know
or
v1
or
layer,
0
types.
B
So
for
me
it
seems
that
rfc
v1
will
be
obsoleted
by
rcv2
right
rather
than
just
updated
by
updated
by
rcr.
We
we
too
so
I
mean
so.
We
would
like
to
we.
I
think
we
should
think
about
which
category
or
either
update
or
obsolete
should
be
used.
B
C
B
B
C
C
So
the
intent
at
the
end,
you
remember,
is
that
we
should
have,
let
me
say,
a
version
2
of
layer,
0
type
rfc-
that
incorporate
everything.
This
is
the
last
step
as
soon
as,
if
you
look
at
the
my
background,
backup
slides
of
the
presentation
that
there
was
the
famous
flow
of
information,
the
last
step
should
be
this
one
was
that
layer,
0
type
extension
has
incorporated
all
the
update
from
layer,
0
type
as
us
today,
in
the
sense
that
isa
became
rfc.
B
G
B
To
reference
the
previous
document,
but
for
the
obsolete
it
says
to
be
used
to
reference
to
an
early
document
that
is
replaced
by
this
document.
So
if
your
you
know,
our
intention
is
to
incu
incorporate
updates
from
the
leo
0
types,
which
means
that
after
v2
will
cover
everything
from
the
you
know,
layer,
2
types
you
know
so
I
mean
so
in
this
way.
Maybe
we
can
think
of
about
if
we
should
use
the
update
or
obsolete.
H
B
H
I
allowed
to
speak
yeah.
Thank
you.
Thank
you,
yeah.
My
understanding
is
actually
that
that
the
the
young
model,
extensions,
we're
currently
defining,
are
actually
adding
to
the
existing
layer,
zero
types
which
are
published
in
rfc
1993
now
and
in
my
opinion,
if
the
new
model
with
the
extensions
will
be
published,
that
should
actually
replace
the
old
or
the
previous
version
of
player
zero
types
that
means
that
it
obsoletes
that
rfc
in
1993
that's
my
opinion.
B
So
if
you,
if,
if
you
know
data
and
and
and
my
understanding,
is
correct
and
then
which
the
changes
are,
you
know
our
category
of
job
c
and
we
should
use
the
obsolete,
naught
and
update.
Maybe
we
can
double
check
anyway,
right
yeah.
H
I
Yes,
hi
yeah,
just
a
quick
comment
on
the
the
next
steps
when
designing
the
layer,
zero
types
extension
groupings.
We
should
also
keep
in
mind
that
it
needs
to
support
other
models
like
the
tunnel
models,
as
well
as
new
models
like
optical
path,
computation.
B
C
No,
no,
I
agree
in
the
sense
that
surely
the
the
intention
of
the
of
the
draft
is
clear:
it's
to
host
a
common
structure
that
can
be
used
by
different
layer,
zero
layer,
zero
model,
young
model,
so
yeah.
If
there
is
other
other
draft
that
is
coming.
It's
true
that
the
the
the
document
has
to
to
be
used
in
the
contest.
Also
of
these
new
drafts.
J
C
K
B
K
L
K
You
can
hear
me:
okay,
excellent,
so
thanks
guys
just
a
short
update
on
our
flexigrid
efforts.
You
might
have
seen
some
some
emails
to
the
c
camp
list
earlier
today.
That
was
me
submitting
a
new
document,
so
one
of
the
things
that
we've
been
sort
of
doing
with
our
flexigrid
work
is
trying
to
harmonize
something
up.
K
Cool,
so
the
first
documents
that
I'm
briefly
going
to
talk
about
is
our
sort
of
optical
topology
document
for
flexigrid
networks.
K
This
is
now
in
it's
version,
11
incarnation,
and
this
was
the
document
that
was
submitted
a
couple
of
hours
ago
and
it
now
points
to
our
new
tunnel
document
and
we've
also
updated
the
terminology
within
the
document
so
essentially
sort
of
replacing
media
channel
with
tunnel.
Although
we
we
do
explain
what
a
tunnel
is,
in
fact
it
is
a
media
channel.
K
We
have
addressed
just
a
few
sort
of
open
issues
since
the
last
ietf,
but
essentially
it's
it's
now
stable.
The
code
is
stable.
It
is
ready
for
sort
of
a
review
from
the
working
group,
so
we
would
like
to
enter
this
document
into
working
group
last
call.
K
You
may
have
thought
that
it
it
had
a
yang
doctor
review,
which
it
has
that
was
an
early
review,
so
we
will
now
hope
that
the
working
group
is
ready
to
kind
of
take
a
look
at
this,
and
let
us
know
if
there's
anything
obvious
or
major
that
needs
to
be
addressed.
Otherwise,
we
can
sort
of
progress
this
through
the
the
isg
and
the
sort
of
the
rfc
process
next
slide.
Please
so
we're
now
going
to
focus
on
our
tunnel
document.
K
This
is
typically
something
that
we
talk
about
on
a
weekly
call
and
I've
posted
the
cool
details
to
the
mailing
list.
They
are
also
available.
I
think,
at
the
end
of
the
slide
deck
that
we've
got
today.
So
anyone
is
welcome
when
we
have
sort
of
substantive
points
that
we
want
to
raise,
or
there
are
your
specific
options
that
we
you
you
we
need
to
agree
or
discard
yeah.
We
will
take
these
to
the
list,
so
don't
think
of
these
kind
of
calls
that
we're
having
as
sort
of
circumnavigating
working
group
process.
K
We
will
absolutely
liaise
with
the
working
group
when
it
comes
to
sort
of
making
key
decisions
and
post
those
to
the
list
or
or
obviously
highlight
them
during
our
presentations.
K
What's
changed
in
our
in
our
most
recent
document,
I
hear
you
cry:
well,
we've
updated
the
prefix
now
again,
that
was
an
ongoing
discussion
that
we
had
sort
of
prior
really
to
itf
111
and
it
sort
of
just
bled
over
post
ietf111,
so
those
that
those
have
been
updated.
You
will
notice
as
well
if
you've
checked
out
the
the
current
code
of
the
document
that
we've
ripped
out
the
rpc
function
for
the
path
computation
specifically
for
flexi
grid.
K
In
this
case,
that
is
now
a
new
document
and
a
new
piece
of
code
which
will
be
discussed
a
little
bit
later
today.
I
think
now
we
found
actually
that
this
was,
I
think,
a
useful
exercise,
and
I'm
sure
I
were
atari
will
explain
that
sort
of
rationale.
K
A
little
bit
later,
there
has
been
some
sort
of
minor
code
changes
as
well,
just
sort
of
fixing
some
compilation
errors,
because
we're
heavily
dependent,
of
course,
on
some
of
the
other
documents
that
the
c
camp
group
are
working
on
things
like
gosh.
What
are
we
yeah,
so
the
the
yangti
model,
the
topology
model
and
so
on
and
so
forth?
In
fact,
it's
probably
the
flexi
grid,
topology
document
as
well
is,
is
kind
of
linked
to
things
like
impairment
topology
as
well.
K
K
So
what
what?
What
would
we
like
sort
of
the
working
group
to
consider
you
know
potentially
help
with?
Well?
We
we've
sort
of
narrowed
some
of
the
discussion
and
the
applicability
really
the
scope
of
you,
how
we're
going
to
use
this
model
and
what
we're
using
it
for.
So
this
is
kind
of
really
important
for
next
generation
optical
technology.
It's
not
you
know
designed
for
some
of
the
legacy
optical
equipment.
K
So
we've
sort
of
clarified
that
now
in
the
document
there
are
sort
of
ongoing
discussions
with
things
like
sort
of
operational
issues,
specifically
the
otsi
and
and
and
how
that's
actually
used
for
sort
of
setting
up
our
our
our
tunnels.
K
I
think,
of
course,
the
otsi
issues
being
raised
in
some
of
the
other
ids
as
well,
so
we've
we've
kind
of
linked
the
otsi
discussion
from
those
other
conversations
with,
and
that's
specifically,
I
think,
the
impairment
top
topology
document.
So
we've
linked
that
with
our
flexi
grip
tunnel
document
we
found
actually
it's
useful
to
have.
K
It
was
one
of
the
review
sort
of
observations
that
we
had
when
we
had
a
sort
of
routing
area
review
of
of
another
document
that
it's
good
to
explain
how
this
model
is
used
in
the
context
of
other
models,
and
just
just
as
sort
of
early
in
the
document,
rather
than
having
to
kind
of
delve
into
the
yan
code
itself
to
see
what's
augmented
or
extended,
we
just
explained
at
a
high
level
very
early
in
the
document.
K
There
are
actually
sort
of
more
open
issues
on
the
order
of
probably
sort
of
10
open
issues,
including
things
like
some
simple
things.
In
theory,
at
least,
we've
got
too
many
document
authors.
In
fact,
it's
really.
K
Anyone
who
showed
any
kind
of
interest
and
actually
commented
or
provided
text
has
been
included
as
an
author,
which
meant
we've
gone
beyond
the
recommended
or
mandated
number
so
that
that
needs
to
be
resolved
as
well,
and
you
can
find
all
of
these
open
issues
on
our
sort
of
c
camp
github
repository
which
which
I
will
talk
to
deta.
I
think
we
will
need
to
change
now
because
it
refers
to
media
channel
rather
than
sort
of
place,
your
grid
tunnel.
K
So,
finally,
the
sort
of
another
observation
that
was
made
on
on
our
recent
call
is
well:
we've
got
the
we've
got
the
flexi
grid,
topology
so
great.
I
can
export
information
about
my
flex
grid
transport
network
from
sort
of
my
physical
devices.
K
K
We've
got
the
flexigrid
media,
channel
documents
and
model
for
actually
setting
up
the
connection,
but
what
about
things
like
sort
of
operational
aspects
and
and
this?
This
is
quite
it's
kind
of
interesting,
because
in
the
in
the
itf
we
always
get
excited
about
sort
of
new
technology,
control,
plane
or
forwarding
behavior
or
at
least
how
to
set
up
and
manage
it.
K
We
often
sort
of
think
about
the
operational
and
even
some
of
the
security
aspects
as
kind
of
a
bit
of
an
afterthought,
although
we
are
supposed
to
have
sections
specifically
that
sort
of
cover
these,
so
I've
just
sort
of
just
raised
an
issue
within
github.
Just
something
we
need
to
be
thinking
about
is
if
we
set
up
our
flexi
grid
transport
network.
What
about
you
know
once
we've
got
our
connections
set
up
as
well?
How
do
we?
How
do
we
monitor
them?
How
do
we
troubleshoot
them?
K
And
yes,
I
know
that
we've
got
other
documents
within
ccamp
which
aren't
actually
being
presented
in
this
session,
so
I'll
follow
up
with
the
authors.
So
so
there
are
things
like
the
optical
interface
parameters
document.
There
are
the
client
signal
and
performance
monitoring
documents
as
well,
and
I'm
just
kind
of
mindful
that.
K
Maybe
we
need
to
be
looking
at
these
and
thinking
about
some
of
this
work
and
and
its
context
of
flexi
grid
as
well
and
and
making
sure
that
we
were
actually
able
to
not
only
set
up
our
infrastructure,
create
services
but
actually
monitor
and
manage
those
services
as
well.
So
that's
another
sort
of
area
we'll
be
investigating.
K
B
Yeah,
I
think,
for
the
first
document,
which
is
about
desperate
topology.
I
think
it's
quite
stable
right,
and
so
maybe
we
can
think
about.
You
know,
move
forward
his
job.
B
E
Yeah,
I'm
trying
to
clarify
a
little
bit
about
the
last
page,
where
you
will
talk
about
the
site
discussion
on
operational
aspects,
so
this
would
be
greatly
appreciated
and
needed,
but
I
believe
this
is
not
needed
only
for
flex
grid
networks.
So
I'm
trying
to
understand
are
we
putting
the
same
functionality,
for
example,
performance
monitoring
for
for
every
kind
of
potential
networks,
or
we
are
doing
this
per
switching
technology,
so
I
would
rather
prefer
doing
this
together,
instead
of
only
discussing
with
yes.
K
That
that
is
actually
a
really
good
point
and
I'm
all
I
kind
of
feel
the
presence
of
lou
berger
here
as
well
saying
you
know,
don't
don't
make
this
technology
specific.
You
know
this
can
be
generalized
and
applied
to
multiple
technologies.
We
can
save
time
and
people's
effort.
So
that's
a
really
good
point.
I
will
I'll
definitely
do
that,
where
possible.
B
So,
let's
move
to
next.
B
Microwave,
I
think
this
force
got.
D
Yes,
I
is
voice
check
here.
D
It
sounds
like
it
looks
like
I'm
coming
through.
I
see
the
little
graph
that
my
voice
is
coming
through,
so
welcome
thanks
chairs
and
welcome
to
the
ccap
working
group.
This
is
the
first
time
you've
heard
about
this
one
in
a
while,
so
we
felt
that
it
was
time
to
provide
a
update
on
the
microwave
topology
yang
data
model.
D
There
is
a
version,
2
draft,
that's
available
and
you
can
see
a
couple
links
there
ones
to
the
data
tracker
and
once
to
our
brand
new
github
that
we're
trying
to
migrate
to
so
we
can
track
issues
and
those
types
of
things.
So
you
can
also
see
the
authors
on
this
page
too.
So
go
to
this
next
slide.
Please.
D
So
I'll
take
you
through
some
of
the
things
that
we've
done
so
our
status
is
that
we've
separated
the
modeling
out.
So
we
now
have
modeling
of
radio
links
and
carriers
as
separate
link
entities.
That
was
something
that
was
modified
since
version
one,
and
then
we
also
have
added
a
couple
of
additional
modules.
So
our
draft
has
a
topology
module
in
it.
D
That
is
an
extension
of
the
te
topology
model
and
the
ietfte
topology
model,
and
then,
in
order
to
make
it
even
more
generic,
we
separated
out
a
bandwidth
availability
as
a
separate
augmentation,
and
also
how
the
traffic
engineer
or
how
the
microwave
model
can
be
linked
back
to
interfaces,
and
so
that's
a
separate
module
and
augmentation
as
well.
So
if
you
just
want
microwave
topology
modeling,
you
can
do
you
can
use
one
of
the
modules.
D
If
you
need
bandwidth
availability,
you
can
add
that
one
and
if
you
want
to
link
it
to
a
interface
in
a
ietf
stance,
you
can
use
the
interface
topology.
So
we
wanted
to
bring
this
up
as
something
that
that
we're
working
on
and
see
if
there
are
others
that,
like
this
kind
of
of
separation
and
modularization,
so
going
on
to
the
next
slide,
we'll
get
into
some
of
the
more
details
around
next
slide.
D
D
L
D
That
seems
to
be
the
so
maybe
I
should
just
put
next
slide
in
the
chat
window.
How
about
that.
D
Yeah,
I
think
that
might
be
the
the
issue.
L
Anybody
know
if
there's
a
yeah
screen.
D
E
Don't
know
scott
if
you
can
share
the
screen
without
his
authentication
from
the
chair.
E
A
A
D
D
L
D
Do
I
just
do
presentation
view
maybe.
L
Danielle
is,
do
you
need
to
do
anything
else
on
your
end
or
I
I
do
see
scott's
sharing
a
request
there.
I
think
so,
but
I
don't
see
any
requests.
D
K
D
D
Yes,
okay,
perfect,
all
right!
So
next
slide
is
oh.
I
already
did
that
one.
So
next
slide.
So
these
are
the
new
generic
modules.
I
I
wanted
to
provide
a
little
more
detail
on
this,
to
make
it
easier
to
see
so
there's
a
bandwidth,
availability,
topology
module
in
this
yang
file
and
then
there's
also
a
interface
reference
topology.
D
You
can
see
the
augmentation
I
stole
from
the
tree,
how
it
adds
yeah,
how
it
adds
the
capabilities
for
a
bandwidth
availability
and
it
extends
the
te
topology
model
and
then
the
same
and
then
for
the
interface,
we're
extending
the
we're,
adding
the
interface
name
to
a
to
the
termination
point,
so
that
allows
us
to
have
our
reference
to
our
the
interface
that's
being
used
for
that
particular
piece
of
the
topology.
D
D
It
wasn't
so
complex
because
we
had
people
like
tallow
and
others
on
the
call
being
able
to
take
us
through
how
most
of
the
ietfte
topology,
as
described
in
87.95,
was
designed
to
be
optional
and
also
agnostic
and
to
support
augmentation
everywhere
so
and
the
te
topology
module
just
as
an
editorial.
It
really
isn't
just
about
te.
It's
really
a
set
of
tools
that
you
can
use
to
augment
topology
and
you
get
the
benefit
of
network
topology.
You
get
the
benefit
of
traffic
engineering
and
you
get
the
the
benefit
of
gis
stuff.
D
So
there's
various
things
in
that
module
that
are
useful
and
the
way
that
it's
written,
it's
very
easy
to
take
and
modify
and
use
only
what
you
need.
So
we
created
these
three
augmentations,
a
augmentation
of
te
topology,
an
augmentation
of
termination
point
and
an
augmentation
of
te
link
attributes.
D
So
we
have
an
example.
So
one
thing
that
we're
trying
to
do
is
we're
trying
to
leverage
some
of
the
tools
like
yang,
lindt
and
and
tools
like
that
to
test
that
our
model
works
and
that
the
must
statements
and
xpaths
and
all
that
stuff
or
right.
So
we
created
an
xml
example
that
we
then
run
through
yanglint
and
produce
a
json
example
and
to
validate
that
what
we're
doing
hangs
together
correctly.
So
this
is
a
pretty
picture
of
an
ascii
art
picture.
D
That's
in
the
draft
that
shows
what
we've
done
in
that.
So
we
have
a
a
couple
nodes
and
a
couple
of
rltps
and
some
ctps
and
you'll
see
the
instance
diagrams
and
and
the
instance
information
in
json
in
the
draft
and
in
the
8.2
so
wanted
to
provide
that
just
to
show
that
we
can
use
it
for
regression
testing
and
also
to
test
our
use
cases
and
such
so.
What's
our
way
forward.
Our
way
forward
is
we
have,
and
I
I
saw-
and
I
felt
bad
because
dan
king
had
an
excellent
point
on
his
slides.
D
He
said
when
his
meetings
were.
The
thing
I
forgot
to
put
in
here
is
that
we
do
have
meetings
every
wednesday
at
11
a.m:
central
european
time
to
discuss
this
with
microwave
experts.
So
if
you're
interested
in
joining
that,
we
share
our
status
on
the
mailing
list
and
one
thing
that
we're
trying
to
do
now
is
get
everybody
over
to
using
our
github
and
get
the
issues
listed.
There
we're
also
right
now
trying
to
convert
over
to
using
markdown
so
that
we
can
generate
the
draft
and
using
some
of
the
more
modern
tools.
D
And
then
we
want
to
add
some
more
json
examples.
We
find
those
to
be
very
useful
in
our
discussions
to
make
sure
that
we
have
everything
covered
and
there's
also
some
microwave,
related
expertise
and
questions
that
we
want
to
make
sure
that
we
have
all
of
the
right
microwave,
knobs
and
buttons
and
dials
that
we
need
in
our
in
our
topology
module.
So
we're
asking
for
feedback
from
the
working
group
and
appreciate
your
time
thanks.
D
B
Yeah,
thank
you,
scott
yeah,
so
we
have
we
have
done
to
you
know.
The
working
groups
are
the
presentations
on
what
group
documents
and
then,
let's
move
to
the
second,
you
know
half
of
the
session
which
about
do
you
know
in
the
video
jobs
next,
one
which
is
slicing
right.
B
I
Good
yeah,
so
my
name
is
imogo
and
I'm
presenting
this
draft
for
utn
advertising
on
behalf
of
all
the
authors
and
courses
next
slide.
I
Okay,
so
here
are
some
major
updates.
Since
the
last
revision,
we
have
an
expanded
list
of
authors
and
contributors
and
we're
welcoming
stephan
and
john
from
channel
moba
to
join
us
and
over
the
last
couple
of
months
we
have
had
some
good
alignment
with
the
peace
network
slice
in
particular
the
all
the
discussions
within
these
working
group
terminologies
and
definitions
on,
for
example,
endpoints
and
connectivity.
Matrices.
I
These,
like
also
are
reflected
in
our
thoughts
towards
building
up
the
the
the
year
model
for
northbound
interface.
I
I
I
By
using
this
model,
it
allows
a
user
to
to
use
connectivity
matrix
to
express
the
intended
connectivity
between
the
endpoints,
but
also
at
the
same
time,
it
could
use
a
topology,
a
network
topology
to
express
the
reservation
of
resources
within
the
network
for
a
particular
slice
and
also
can
express
the
detailed
path
across
the
network.
Topology
and
basically,
it
supports
a
mode
such
that
the
resources
could
be
reserved
with
the
slice
and
then
the
connection
could
be
instantiated
over
the
the
slice,
as
the
customer
needs.
At
a
later
time.
I
So,
with
the
common
model,
we
expected,
like
I
said,
to
support
slicing
for
any
layer
of
transport
technologies,
including,
for
example,
otn
wdm,
as
well
as
mplstp
right
and
then
the
potentialized
mdi
is
just
built
on
the
common
model,
with
otn
specific
arguments
and
within
the
design
of
this
mbi
model,
we
try
to
reuse
concepts
and
model
fragments
from
existing
drafts,
from
both
keys
and
from
the
teeth
group.
I
There
are
a
few
candidates
we
are.
We
have
looked
at
the
draft
liu
network
transport
network
slice
yarn,
which
defines
a
network
topology
for
refresh
based
slicing
and
with
also
a
list
of
technology,
agnostic,
slo
attributes
and
the
act
and
yangyang
model
from
from
tees,
which
is
a
a
cmi
model
that
that
offers
the
support
for
both
type
1
and
type
2,
as
is
written
in
the
draft,
which
corresponds
to
connectivity-based,
as
well
as
a
resource-based
virtual
networks
and
the
the
only
thing
is.
I
This
model
is
much
in
candle
entangled
with
with
actin
and
the
traffic
engineering
t
topology,
which
we
are
trying
to
make
it
more
generic,
and
so
this
there
are
some
support
which
we
imported
from
the
from
the
ict
and
dna
and
the
last
one
is
actually
the
the
keys
working
group
draft,
which
was
just
adopted
for
the
network
slice
mbi.
I
It
has
a
common
definition
for
endpoints
and
slos,
but
the
drawback
is
is
only
supports.
Connectivity-Based
slicing
and
a
lot
of
the
attributes
in
there
is
iq
technology
specific,
which
does
not
apply
to
transport
slicing
so
yeah.
So
those
are
the
reference
drafts
that
we
are.
We
have
looked
at
when
designing
the
the
coming
young
model
for
otn
slice,
npi
next
page.
I
As
you
can
see,
in
the
model
we
have,
a
network
slice
has
has
slo
attributes,
endpoints
network
network
topology,
which
could
be
used
to
describe
a
a
detailed
network
topology
on
which
the
network
slice
is
viewed
on
and
a
list
of
connectivity
matrix
connectivity
matrices
that
much
resembles
what
is
in
the
the
itf,
the
in
the
teeth
network
slicing
draft.
I
Yeah
there
is
a
minor
update
to
the
mpi-young
model
proposed
before,
in
which
we
added
a
a
choice
statement
which
allows
a
resource
to
be
colored
based
on
either
the
number
of
time
slots,
otn
time
slots
or
a
list
of
odu
containers
based
on
the
type
of
the
container.
I
Okay,
so
some
open
issues
first
thing
is
when
we
are
designing
the
mbi
young
model,
as
we
said,
we're
trying
to
reuse
as
much
possible
as
much
as
possible.
The
existing
models
and
one
of
the
options
is
to
look
into
the
schema
mount
and
try
to
include
model
fragments
from
from
from,
let's
say,
draft
a
lieu
network
topology
and
put
it
underneath
the
network
topology
subtree
of
the
of
the
common
mdin.
I
Now
the
issue
we
are
seeing
is
what
we
are
trying
to
do
is
to
do
a
design.
Time
schema
mount
without
redefining
the
the
the
the
models.
I
I
Some
you
know,
support
and
torchem
support
which
we
could
use
for
validation,
yeah
so
and
whether
we
could
use
a
schema
amount
remains
an
open
issue
and
we
need
some
further
investigation,
as
well
as
examples
to
to
understand
how
it
could
be
used,
and
another
open
issue
is
to
whether
to
model
a
connectivity
matrix
as
a
topology,
basically
as
a
single
node
topology
or
as
a
list
of
intended
connections,
as
we
currently
put
in
the
in
the
in
the
model.
I
I
think
this
is
a
also
a
question
to
the
teeth
network.
Slicing.
A
I
This
is
just
two
different
options,
and
so
we
put
we
put
the
connectivity,
a
list
of
connections
as
our
initial
choice,
but
it
remains
open
as
to
what
we
go
for
next.
I
Okay,
next
page
yeah,
so
next
steps
we
will
be
continually
continuously
developing
otn
augmentation,
based
on
the
common
transport
natural
slice
model,
and
we
need
to
also
support
the
slicing
for
non-otn
links,
external
links,
which
is
attached
to
the
to
the
to
the
otn
network.
I
And
there
are
a
couple
of
open
issues
in
the
github
that
we
have.
We
are
looking
at
and
also
comments
and
reviews
from
the
working
group.
I
We
have
seen
and
a
good
list
of
participants
in
a
discussion,
and
we
have
models
proposed
and
I
believe
the
the
worker
can
be
can
be
kept
working
on
with
working
cooper
document,
and
we
have
asked
for
the
working
group
adoption
before
the
meeting
so
yeah.
So
the
weekly
discussion,
we
have
a
weekly
discussion
set
up
and
on
thursday
10
to
11
am
eastern
time,
and
the
github
is
also
listed
here.
So
anyone
interested
in
this
work
is
more
than
welcome
to
join
us.
B
I
Yeah,
I
think,
of
many
interested
parties
participants
already
in
our
weekly
discussion,
so.
I
The
steps
are
clear:
let's
hope
we
could
have
more
comments
from
the
working
group.
E
Most
of
the
issues
are
under
discussion
of
the
weekly
call,
and
I
think
we
reach
good
consensus.
Just
one
more
comment.
Talking
about
the
schema
amount,
I
think
the
such
kind
of
evaluation
is
not
slicing
specific
and
there
should
be
a
generic
question
to
all
the
modules,
so
I
would
rather
suggest
we
focus
on
the
slicing
itself
and
those
kind
of
schema
amount
or
whatever
young
grammar
level
stuffs
can
be
discussed
in
a
more
general
or
or
work
with
more
young
experts
instead
of
the
slicing
itself.
I
Yeah
yeah,
I'm
just
just
to
quickly
respond
to
harmony's
comments.
Yes,
I
agree
with
you
and
I
think
the
use
of
skim
amount
is
just
a
tool
to
face
facilitate
the
design
of
the
model.
It
shouldn't
stop
us
from
moving
forward.
I
The
worst
case
is
just
we
have
to
copy
paste
some
of
the
definitions
but
yeah.
That's
not
a
shoe
stopper.
B
Actually,
thank
you
yeah.
I
think.
Actually,
you
know.
The
slicing
topic
is
quite
interesting
and
and
the
sexy
right
so
and
also,
I
think
this
job
is
organized
very
well.
So
I
would
like
to
power
to
to
test
the
temperature,
so
how
many
people
think
that
this
job
is
ready
for
pubg
adoption
if
you
support
please
type
plus
one
in
the
chat
window?
B
J
And
gentlemen,
okay,
I'm
presenting
a
new
draft
for
requesting
paco,
potentially
optical
networks
and
next
slide
mbr
for
causes
next
slide,
please
and
contributors.
Okay,
what
is
the
problem
that
we
are
trying
to
solve?
We
is
a
problem
when
we
have
an
optical
network
which
can
be
a
w
zone
network,
a
flexi
grid
network
or
even
otn
network,
and
we
would
like
to
request,
via
rpc
the
optical
network
controller,
to
perform
a
part
computation
over
the
optical
network.
J
There
is
a
draft
in
this
working
group
which
describes
a
watcher,
dynamic
requirements
and
use
case
for
an
rpc
to
request
par
computation
over
any
type
of
transport
engineering
network,
a
traffic
engineering
network
and
the
optical
networks
are
mentioned
as
examples
of
network
which
will
benefit
for
such
an
rpc,
but,
and
the
model
that
is
defined
in
that
is
working
group
is
a
generic
and
technology
agnostic
model,
which
is,
you
know,
developed
in
alignment
with
an
e-tunnel
model
in
the
also
developed
in
teaser.
J
So
what
does
this
model
is
simply
taking
the
generic
model
developed
in
teas
and
you're
reusing
the
common
definition
in
layer,
zero
types,
laser
type,
extensionary
one
types
and
augment
the
generic
tunnel?
The
computation
model,
with
these
attributes
for
like
technology-specific
labels
of
autonomous
receiving
bandwidth
definitions
and
so
on,
and
by
being
based
on
the
generic
part
compression
model,
it's
also
aligned
with
the
tunnel
modes
for
the
optical
network.
So
you
can
use
the
paco
potential
model
to
request
the
packaging
and
then
the
tunnel
mode
to
set
it
up.
J
The
lack
of
these
technology
specific
attributes
was
also
notified
during
the
analysis
in
the
poi
stmpoi.
We
noticed
that
if
you
want
to
request
an
optical
controller
to
perform
a
computation
in
optical
network,
you
miss
the
information
about
the
technology.
Specific
attributes
of
the
optical
network.
Next
slide.
J
So,
as
I
said,
the
contribution,
the
draft
is
very
simple:
it's
just
augmenting
there
are,
but
there
are
a
few
open
issues.
Maybe
we
is
more
trying
to
discuss
one.
The
one
open
issue
is
a
little
bit
much
bigger
scope
than
our
draft
is
the
fact
that
we
are
using
the
razer
tunnel,
attributes
and
radio
path
constraints,
groupings
which
are
the
finally
reso
type
extensions.
J
But
there
are
the
attributes
in
this
grouping
needs
to
be
validated
and
we
already
have
two
open
issues
in
the
tunnel
in
the
github
for
the
flexibility
tunnel,
and
we
think
that
this
an
issue
is
equally
applicable
to
all
the
drafts
which
are
using
these
two
groupings,
and
my
suggestion
is
to
address
this
issue
jointly
with
the
other
drafts,
and
second
issue
is
more
organizational:
whether
we
want
to
keep
all
district
modules
into
one
document
or
to
split
into
two
or
three
documents
and
follow
the
same
structure
as
in
the
tunnel
model.
J
We
can
focus
the
discussion
on
these
two
open
issues
and
the
next
steps
is
basically
any
comment
or
feedbacks.
Oh
okay
from
the
working
group
we
we
will
address
and
please
review
and
comment.
We
will
actually
finalize
what
is
the
structure
of
the
document
so
whether
to
have
all
to
progress?
One
document,
two
documents
or
three
documents,
and
then
after
we
have
finalized
the
document
structure.
I
think
we
we
should.
H
Yeah,
I
think
I
I
think
it
makes
sense
to
actually
have
cover
the
wson
and
the
flexi
grid
in
one
draft,
because
both
belong
to
layer
0,
whereas
layer
1
could
be
done
in
a
separate
draft.
H
Yeah
I
mean
I
mean
they
could
be
organized
in
yeah
different,
two
different
modules:
okay,.
B
So
I
think,
from
my
perspective,
I
think,
regarding
one
document
versus
three
documents:
if
there's
no
any
fundamental
difference,
and
then
I
think
we
can
just
keep
one
in
one
document
right
if
the
document
is
not
much
big
and
this
will
be
an
easy
way
to
to
just
document
the
three
documentary
models
in
just
one
single
document.
B
Okay,
but
regarding
the
wg
adoption,
I
think
maybe
we
can
have
one
more
division
and
then
decide
if
it's
ready
for
object,
option
or
not.
J
B
N
N
N
N
N
But
the
inventory
data
stored
in
the
resource
management
oss
system
is
usually
collected
by
some
private
protocols
like
cobar,
xml
and
restful
and
for
rascal
interface.
We
just
find
one
hardware
data
model
in
rfc
8348,
which
is
considered
to
be
used
in
used
to
do
hardware
management
on
the
single
network
element,
and
it
cannot
provide
a
network
level
management
interface.
N
N
So
if,
if
we
augment
the
the
inventory
model
element,
the
network
model,
some
more
filtering
step
will
be
required
and
some
unnecessary
misunderstanding
will
remain
so
and
also
the
integration
difficulty
will
get
worse
in
the
large
scale
or
network.
N
N
N
Besides,
with
with
the
steel
among
technology
defined
in
fc,
8528.
N
N
N
A
rack
can
be
deployed
with
several
narrow
element
and
and
a
network
element
can
also
be
installed
on
different
racks,
so
they
are
no
parent
to
child
relationship.
N
N
Okay,
here
is
the
young
model
we
provide
in
this
draft.
It
follow
the
the
the
young
model
for
the
relationship
we
draw
in
the
last
page
and
we
just
defined
a
simple
inventory
model
with
a
lot
of
detailed
information.
N
N
Okay,
that's
all
for
my
presentation
when
we
also
create
a
repository
in
github
and
we
are
looking
forward
to
your
comments,
feedback
and
we
are
also
open
to
collaboration.
Thank
you.
B
Okay,
thank
you
todd
any
questions.
J
It's
another
question
about
whether
okay,
the
draft
s,
we
plan
to
engineer
to
make
the
rough
more
generic
and
it's
good
to
to
to
clarify
that
this
is
the
working
group
where
we
we
continue
or
or
not,.
J
I
J
G
N
Yeah
yeah,
okay,
okay,
we
we
suggest
to
continue
to
this
job
in
the
in.
In
our
c
camp
group,
okay
and
for
the
other
group,
we
will
okay
report
our
progress
to
them
and
whether
it
will
be
abducted
by
their
the
other
working
group.
It's
up
to
them.
Okay,.
L
Wondering
about
the
same
thing
I
mean
it
seems
like
for
the
moment
continuing
it
here
and
discussing
the
other
working
groups
is
probably
the
right
thing
to
do.
Hopefully
we
can
have
something
a
little
firmer
before
that
we
come
around
to
the
next
ietf,
presumably
in
discussion
with
the
chairs
of
those
other
groups.
B
B
And
we
got
okay.
I
So
yeah
here
just
a
quicker
comment.
I
think,
like
I
agree,
we
could
continue
this
work
in
the
c
camp
working
group,
but
the
name
of
the
draft
contains
optical,
I
think,
which
is
a
bit
too
constraining.
Maybe
we
could
make
it
more
like
a
network
inventory
so
in
the
in
the
future,
if
we,
if
we
make
it
more
generic
and
have
have
it
in
other
words,
groups
that
could
be
could
be
could
be
done
easily.
N
B
B
Let's
move
to
next.
G
B
G
Page
please
so
the
first
slide
thought
about
the
motivation
of
this
world
as
cloud
bases
as
cloud-based
applications
are
going
in
popularity
data
center
and
the
data
center
international
connection
are
becoming
increasingly
important.
G
G
G
So
I
will
give
several
use
cases
for
optical
network
exercising
clause.
The
first
use
case
is
the
multi-cloud
as
of
sizing,
so
basically,
closer
services
are
usually
supported
by
multiple,
interconnected
data
center,
which
are
which
are
spaced
with
within
one
region,
normally
within
one
kilo
meter.
G
The
reason
to
spacing
within
within
one
kilometer
is
that
it's
like
that,
the
cloud
service
you
really
need
to
support
it
to
active
storage
or
virtual
machine
services
and
some
services
of
this
kind,
so
the
distance
should
be
not
too
far,
so
the
closer
is
have
the
demand
of,
for
example,
on
demand
services,
scalability,
high
availability
and
user-based
building
outside
raw,
and
this
raised
the
requirement
for
data
center
interconnection
like
capacity
large
capacity,
low
latency,
reliability
and
the
flexible
scaling,
scheduling,
etc.
G
We
believe
advanced
optical
transport
network
is
ideal
for
this
decentral
interconnection
applications.
G
G
The
second
use
case
is
a
higher
quality
least
light
a
high
quality
private
land
provide
high
large
bandwidth,
low
latency,
high
security
and
reliability
with
optimized
words.
Actually,
we
can
have
all
this.
This
kind
of
attributes
users
can
move
their
core
asset
to
clause
side
and
unless
operator,
try
with
this
optical
network
to
assess
clause
operator
can
accept,
accelerate
the
deployment
of
the
cloud
services
and
reduce
capacity.
Overpass
next
slide.
G
Please,
and
the
third
use
case
is
a
claude
virtual
variety,
as
we
know
that
user
experience
of
the
virtual
reality
is
mainly
depends
on
the
local
dedicated
hardware
for
rendering.
If
we
move
the
rendering
resources
from
local
to
cloud
size,
it
can
improve
the
user
experience
by
having
more
rendering
resources.
G
For
example,
we
need
a
hair
available
and
granted,
and
sometimes
flexible
bandwidth,
for
example,
larger
than
one
gigabit
per
second
and
sometimes,
and
a
lower
latency,
for
example,
smaller
than
10
milliseconds
and
the
lower
jitter,
for
example,
smaller
than
five
minutes.
Second,.
G
Optical
networks
with
vpn
can
be
used
to
to
to
access
multiple
tools.
It
can
be
used
for
multiple
to
multiple
cloud
assessing.
Thus,
actually,
currently,
some
old
tn
equipment
has
already
adopted
the
package
processing
functions,
such
as
package,
switching
nprs,
vpn,
etc.
Optical
networks
also
have
a
high
performance
and
high
reliability,
also
small,
smaller
granularity
container.
G
For
example,
with
the
flexibility
of
from
two
mega
bits
to
one
gigabit
per
second
is
required
to
improve
the
efficiency
of
the
network
and,
lastly,
high
bandwidth
and
the
low
latency
and
the
low
data
are
required
for
specific
application.
That
cloud
vr
nest
slides,
please
so,
and
this
is
the
last
slide
and
talk
about
the
status
and
plan
actually
in
the
other
group.
Rtgwg
has
already
have
two
useful
related
words
network
to
plot
gap,
analysis
and
the
network
to
cloud
proven
statement.
G
G
B
E
For
some
common
objectives
with
given
to
rpgw
document,
but
according
to
their
feedback,
it
looks
like
we
are:
having
separated
the
requirements,
we
have
separated
the
solution.
Of
course
the
solution
would
be
optical
based,
so
it
belongs
to
camp,
and
this
is
just
the
kickoff
of
the
the
new
application
work
and
is
still
at
the
starting
stage,
and
I
will
talk
with
xiang
and
decide
what
to
do
in
next
step,
probably
with
evaluation
on
the
gap
analysis
on
what
is
the
missing
point
for
the
current
product
stack,
and
we
will
report
in
next
meeting.
B
F
F
F
F
By
the
deal
side
there
is
active,
wtm
equipment,
so
we
need
you.
We
need
to
use
a
centralized
management
system
to
control
the
wdm
equipment
and
the
remote
optical
modules,
so
the
the
management
system
can
connect
with
the
wtm
equipment,
but
the
remote
optical
modules
cannot
be
connected
directly,
so
we
use
an
rear
arm
channel
to
transmit
the
management
and
the
control
information
between
the
remote
optical
modules
and
the
wdm
equipment
and
the
oem
channel
can
be
realized
by
by
service
signal
overhead
or
by
the
pilot
tune
with
the
load.
F
Next
page,
please
so
yeah
the
semi-active
wdm
can
not
only
greatly
reduce
the
pressure
of
optical
fibers
resources,
but
also
has
the
advantages
in
cost
management
and
protection.
F
The
first
one
is
some
active
system
can
support
optical
air
protection.
The
second
one
is
semi-active.
Wdm
can
support
a
fault
and
performance
monitoring.
The
last
one
is
the
remote
optical
modules
can
be
also
management
managed
by
the
transport
controller,
and
we
have.
We
have
approached
the
data
plan
schemes
of
of
the
same
active
wdm
in
iu
and
some
some
projects
have
been
established,
so
we
suggest
to
start
the
research
about
the
management
and
the
ndi
for
some
active
wdm
in
itf
next
page.
Please.
F
F
I
will
introduce
quickly,
it
is.
It
is
preferred.
The
some
active
wdm
system
should
be
managed
by
the
transport
controller
tool,
including
the
local
wdm
equipment
and
the
remote
optical
modules,
and
there
are
some
existing
modules
models
in
itf
we
have
listed
here.
Some
of
them
are
defined
for
wdm
system,
so
we
think
maybe
they
can
use
for
same
active
wdm.
Maybe
not
so.
We
think
the
extension
for
semi-active
wtm
is
still
an
undergoing
research.
F
So
next
step:
firstly,
we
will
evaluation,
you
might
evaluate
the
existing
models
and
we
should
think
about
what
need
to
be
extended
for
semi-active
wdm,
and
maybe
we
will
give
a
detailed
description
or
a
conclusion
sometime
later,
maybe
a
next
meeting
so
at
last
we
are
glad
to
invite
more
people
to
enjoy
to
try
this
work.
That's
all.
B
Okay,
thank
you.
You
already
spent
three
more
minutes
yeah.
So
actually
I
see
a
comment
from
deborah
and
he
sent
a
comment
in
the
chat
window.
He
says
she
says
we
should
do.
You
know
separate
date
plan
from
kanji
plan
yeah.
I
fully
agree
with
her
comment
so
anyway
yeah
so
actually
in
the
cam.
We
cannot
define
you
know
our
date:
data
plan
technologies.
We
just
defined
the
county
plan
stuff,
and
so
we
have
to
monitor
the
progress
of
the
data
planning.
F
L
I
hope
I
see
you
see
you
from
the
thai
in
the
in
the
chat
bye,
everybody.