►
From YouTube: IETF109-CCAMP-20201120-0900
Description
CCAMP meeting session at IETF109
2020/11/20 0900
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
B
Yeah,
I
think
I'm
sharing
the
screen.
I
see
the
mythical.
A
Okay:
okay,
let's
start
so
yeah
good
morning,
good
afternoon
and
good
evening
for
everyone
so
welcome
to
c
camp
session.
You
know
this
is
the
online
meeting,
and
actually
this
is
our
first
online
meeting
right.
Let's
start
from
yeah
start
from
the
next
page.
A
Before
the
you
know,
our
notewheel,
I
think
you
are
familiar
with
the
load-free
information,
it's
about
a
demand
for
the
id
policies,
so
here
I
still
would
like
to
repeat
some
piece
of
information.
Some
important
piece
information
like
it
says
by
participating
in
the
itfu,
agreed
to
follow
itf
policies
and
idf
idf
process,
and
if
you
are
aware
that
any
idf
contribution
is
covered
by
patents
or
even
patent
applications,
you
must
disclose
this
fact.
A
A
Okay,
so
this
meeting
this
session,
we
have
two
hours
and
you
know
which
is
120
minutes.
Next
and
and
actually
looking
at
the
agenda.
We
have
only
four
presentations.
A
So
it's
you
know
120
minutes
minutes,
so
I
think
we
should
have
sufficient
time
for
the
deep
discussion.
So
anyway,
I
think
we
will
have
some
some
fun
on.
You
know
young
models
for
the
optical
impairment.
We
see
some
what
much
discussions
on
the
on
the
list.
Okay,
next.
B
Yes,
just
just
just
what
gert
was
very
kind
to
put
together
some
slides
to
bring
to
the
session
the
discussion
that
was
started
on
the
main
list,
so
that
we
can
use
the
the
time
the
q
a
time
to
discuss
a
little
bit
about
the
the
open
issues
and
maybe
poll
for
for
for
consensus
and
move
the
work
forward.
B
So
we
will
have
within
a
slot
of
three.
We
will
have
two
presentations.
A
So
you
know
at
this
time
we
were.
We
are
using
with
echo,
so
I
think
we
all
know
how
to
use
the
echo
and-
and
you
know,
if
you
are
going
to
ask
questions
or
comments,
you
have
to
enter
session
queue.
For
example,
you
have
to
raise
your
virtual
hand
and
then
the
chair
will
allow
you
to
to
talk.
A
A
And
for
the
minute
takers-
and
I
think
right
right
now-
we
are
using
code
md
and
this
kind
of
online
tool
to
take
minutes.
So
anyone
you
know
you
could
take
two
minutes
and
that
would
be
much
appreciated
and
for
the
blue
sheets
this
will
be
automatically
generated
created.
So
a
lot
in
for
us
to
do
nothing
for
us
to
do
on
the
for
the
blue
sheets.
Yeah.
A
For
the
ipr
process,
this
is
quite
very
important.
You
know
on
demand,
and
so
you
know
pride
for
a
document.
You
know
try
to
move
into
next
step
in
working
group
process.
For
example,
before
individual
draft
becomes
a
working
group
document
or
a
working
group
document
goes
to
last
call.
You
know
the
chairs
will
send
out
ipr
polling,
and
so
we
encourage
you
to
respond
to
you
know
if
you're
pulling
as
soon
as
much
as
soon
as
possible,
otherwise
it
will
delay.
You
know
your
work
move
forward.
A
A
A
So
and
also
you
know,
another
monday
is
that
you
know
working
group.
Consensus
is
determined
on
the
on
the
list
rather
than
you
know
on
this.
At
this
you
know
online
meeting
or
even
face-to-face
meeting.
You
know
so
you
know.
Actually,
if,
if
we
got
some
consensus
here,
we
still
need
to
bring
this
kind
of.
You
know
our
discussion
on
to
the
list
you
know
to
to
to
get.
You
know
formal
working
group
consensus
yeah
next.
B
We
have
two
drafts
in
the
isg
processing,
the
layer,
zero
types
and
the
young
model
for
for
davison,
none
in
the
edit
or
queue
or
which
recently
became
a
nrfc.
B
The
tunnel
model
is
is
expired,
but
I
mean
I
guess
the
reason
is
waiting
on
the
updates
on
the
young
t.
I
don't
know
if
the
others
would
would
like
to
add
something
more
about
about
the
status
of
the
draft,
but
I
assume
that
it's
just
waiting
on
on
dependencies.
B
B
I
take
it
as
a
look
okay
on
the
agenda.
We
have
four
documents
on
the
agenda
today:
the
layer,
one
types
layer,
one
csm,
the
ot,
the
applicability
of
jpls
to
the
otn
beyond
the
100
gigabit
and
the
optical
impairment.
Topology
young
model
actually.
B
We
have
many
more
working
group
documents,
but
I
believe
that
just
a
few
of
them
are
have
is
not
requested,
because
we
did
a
quite
effective
interim
meeting
between
itf
108
and
and
this
one,
where
we
spent
quite
some
time
discussing
about
the
layer,
1
layer,
1
documents
and
for
some
of
them
we
requested
the
young
doctor
review
and
they
are
pretty
close
to
to
working
group
to
working
group.
Last
call
there
is
a
number
of
other
drafts
which
will
not
be
presented
today.
B
We
didn't,
we
didn't
collect,
feedbacks
or
status
on
on
most
of
them,
so
we
would
like
the
mic.
We
we
would
leave
the
the
mic
open
now
to
to
to
to
to
allow
the
authors
to
to
share
information
about
about
them
so
feel
free
to
start
in
whatever
order
you
feel
we
are
not
following
this.
This
particular
one.
B
There
are
some
some
drafts
that
we
have
not
discussed
in
in
the
last
two
three
meetings
and
it
would
be
nice
to
know
what's
what's
the
status,
what
are
the
next
steps
that
the
authors
believe
are
necessary
to
to
progress?
The.
C
D
E
Just
another
one
comment:
if
you
can
hear
me,
is
completely
speaking
about
the
dwdmlmp
interface
lmp
and
the
interface
parameter
young,
especially
the
second
one.
I
will
follow
the
draft
on
the
t,
topology
young
and
today
there
is
not
a
an
update
to
realign
this
document
to
the
topology
tte
topology,
but
we'll
we'll
do
just
after
this
call,
and
then
we
plan
to
to
have
a
internal
meeting
to
the
group
next
week.
B
Okay,
let's
move
to
the
to
the
stages
of
drafts,
not
an
agenda
for
which
we
have.
We
have
an
update.
The
young
there
are
bi-weekly
calls
on
on
this
draft.
B
B
B
I
I
did,
I
personally
did
the
review
of
the
of
the
draft
and
I
believe
that
it's
ready
to
be
moved
to
be
moved
forward.
Even
now.
The
fact
that
the
doubles
zone
young
and
the
l
zero
types
are
the
isg
processing.
This
is
the
natural,
the
natural.
B
We
sent
we
replied
to
the
classical
liaison
from
the
itu-t
study
group
15
on
the
otn
standardization
work
plan.
This
was
done
back
back
in
august.
This
is
the
usual
liaison
to
c
camp,
these
pce
mpls,
etc.
B
So
I
mean
this
is
the
classical
liaison
relationship
that
we
keep
on
having
with
the
study
group
15.
as
usual.
If
you
would
like
to
to
to
review
and
provide
your
comments,
they
are
more
than
welcome.
B
On
the
send
audio
streaming
button,
you
can
you
can
start
your
your
audio
automatically.
C
Excuse
me,
can
you
hear
me
now?
Yes,
oh,
okay,
sorry,
okay!
So
this
is
from
huawei
and
I'm
going
to
present
the
update
for
the
layer,
one
csm
young
module.
Actually,
we
are
going
to
update
a
little
bit
about
the
layer,
one
types
together
and
next
please.
C
Okay,
so
this
is
the
the
work
we
have
been
updated
after
the
our
interim
in
september,
and
the
mainly
work
we
do
is
to
fix
the
comments
in
the
early
young
doctor
review,
and
we
are
mainly
addressing
one
comment
from
the
extreme,
especially
for
the
coordination
between
the
math
structure
with
itu
uri
stops.
We
also
provide
some
editorial
changes
in
the
draft
and
text
description.
C
So
in
the
math
there
is
a
specification
30
60
string,
talking
about
the
layer,
one
service
attributes
and
all
the
connection
connectivity
service
model
is
specified
in
a
straight
tuple,
including
the
protocol,
the
coding
function
and
the
optical
interface,
while
in
the
itu-t,
in
the
mean
time,
actually,
the
the
similar
things
is
defined
in
a
different
way
named
as
the
client
signal,
which
is
now
consistent
with
layer,
1
types
with
the
layer.
One
types
client
signal,
so
we
are
trying
to
use
a
table
to
okay
list.
C
What
is
the
difference
between
the
math
and
the
itu
side
on
defining
the
same?
Let's,
let's
call
it
client
signal
temporarily.
So
for
the
math
there
is
a
three
tuple.
We
are
using
the
giga
ethernet
as
an
example.
C
So
for
the
giga
internet
we
maf
specifies
protocol
as
a
ethernet
and
the
coding
function
is
1000
base
x
and
for
the
optical
interface.
There
are
a
few
different
options
which
are
specified
in
the
ipoe
recommendations,
including
the
sxpmd,
rx,
pmd,
different
and
so
on.
So
it's
a
very
kind
of
detailed
specification
regarding
the
the
details
of
the
ethernet,
but
if
we
look
from
the
perspective
of
the
optic
side,
so
basically
we
are
only
considered
as
ethernet
one
gigabit.
C
In
layer,
one
types
named
as
client
signal,
and
so
so
for
the
same
kind
of
for
the
same
kind
of
client
signal.
We
are
having
different
representations
and
we
wish
the
l1
csm
can
support
both
cases.
So
here
we
update
our
young
tree
in
the
bottom
of
this.
C
So,
accordingly,
to
make
the
model
work,
we
also
go
back
and
change
and
change
the
layer,
one
types
and
for
the
client
signal
we
are
having
the
common
client
signal,
identity
from
from
both
bases
from
the
math
and
the
i2t.
So
there
are
list
of
identities.
We
need
to
follow
up
with
multiple
bases.
C
C
So
we
put
different
reference
here
and
they
are
referring
to
the
specification
in
iq
and
the
map
respectively
and
in
this
page,
we'll
list,
the
all
the
identities
that
we
introduce,
the
multiple
bases,
including
the
stm
series,
with
different
rate,
one
for
16,
64
and
256,
and
the
oc
series
3,
12,
48,
192
and
768,
and
the
last
one
is
a
fiber
channel
with
100
200,
400,
800,
1600
and
3200.
C
C
So,
okay
and
that's
what
we
have
been
progressing
and
now
we
still
have
one
open
issue:
number
72
on
the
github
to
maintain
the
consistent
configuration
on
the
pco.
The
problem
is,
the
problem
will
occur
when
people
mistakenly.
C
Configure,
for
example,
a
stm
protocol
with
ethernet,
for
example,
optical
interface
or
coding
function,
so
so
no
one
is
guaranteeing
the
successful
of
such
configuration.
So
we
need
to
maybe
just
put
more
text
description
in
the
draft
to
to
do
this
kind
of
things
or
specify
some
mechanism
in
the
model
to
make
sure
that
the
configuration
is
consistent
and
we
also
need
to
coordinate
the
performance
metric
part
with
a
few
other
documents.
G
Can
you
hear
me,
I
think
I
think
so
yeah
thanks
amanda.
I
think
it's
interesting
work
they're
looking
forward.
There
has
been
discussion
in
ieee
of
and
so
on,
about
400
gcr
interfaces.
G
C
In
this
document
we
didn't
put
this
in
the
scope.
So
far
the
target
is
only
math
for
16,
I'm
sorry
63
and
the
client
signal
we
have
been
specified
in
i2t
now
for
400
zr
and
it's
related
the
ethernet
configuration
we
didn't
touch
it
yet.
Yeah.
G
C
Horizon,
I
think
it's
a
good
point,
and
maybe
we
need
to
if
we
really
taking
this
into
account,
it
will
impact
more
than
one
document,
not
only
this
one
but
yes,
probably
the
other
client
signal
works
as
well,
but
anyhow
we
need
to
look
into
that.
The
detail
of
that
to
start,
of
course,
what
is
the
pro
progress
of
the
the
400
zr
because
we
are
not
allowed
for
oif
anymore.
G
C
G
B
Okay
thanks
a
lot
just
one
question
from
my
side
that
do
you
need
any
support
in
terms
of
liaisons
towards
math
or
itu,
or
is
anything
that
can
be
solved
without
it.
C
I
think
it's
mainly
internal
work
within
itf.
The
methods
has
done
their
job
now.
B
I
Okay,
so
hi
everyone.
This
is
chile
from
zt,
so
this
protection
that
I
will
I'm
going
to
give
is
about
the
applicability
of
the
mps4
beyond
the
100
gig
optical
transport
network.
So
next
slide,
please.
I
Okay,
so
this
slide,
let's
just
describe
the
updates
since
last
version
for
the
first
item.
Okay,
since
this
slide,
okay
for
the
first
update
it's
about
the
oti
site.
Also,
it's
it's
related
description
is
deleted.
They
are
not
in
the
scope
of
this
draft.
This
traffic
is
about
how
to
operate
the
audio
layer
so
for
the
opportunities
that's
the
problem
out
and
for
a
second
update,
it's
about
how
to
apply
gmps
to
audio
using
case
it's
also
outside
the
scope.
I
So
we
also
delete
a
related
relevant
description
and
for
the
third
update,
it's
about
the
publication
of
the
latest
709
2020
version.
We
also
did
some
evaluating
evaluation
work
to
say
if
this
latest
version
would
bring
unattended
to
this
draft.
So
after
discussing,
we
believe
that
there's
no
impact
on
this
draft.
I
The
reason
is
because,
as
a
currently
as
think
that
that
crossing
algorithm
is
not
standardized,
that's
always
things,
so
I
have
the
conclusion
that
the
value
is
not
sufficient
and
just
before
the
start
of
the
second
bin
circumference
meeting
a
couple
of
hours
ago,
we
I
uploaded
a
new
04
version,
it
just
to
reflect
the
changes
suggested
from
one
of
the
also.
I
think
they
are
purely
editorial
changes.
I
B
Thank
you.
Thank
you
yeah.
So
I
mean
this
is
this
has
been
around
for
quite
some
time
and
that
in
the
end,
it's
an
informational
draft
which
is
not
defining
any
major
extensions
at
the
gym
pls,
but
it's
just
an
applicability
it
evolved
at
the
very
beginning.
It
was
defining
extensions
that
we
realized.
They
were
not
needed,
so
it
became
an
applicability
document.
B
I
would,
I
would
tend
to
agree
that
all
of
the
work
that
was
needed
is
now
is
now
completed
and
we
could
consider
the
last
call
we
have
yuji
in
in
the
queue
please.
H
Yes,
okay,
thank
you
back
to
the
previous
slide,
please
here!
Yes,
so
about
the
third
world.
H
So
I
would
suggest
the
draft
should
be
updated
from
2016
to
2020
version,
and
so
I
don't
think
we
should
stick
to
260
version
of
digital
7
9..
Thank
you.
F
I
A
You
hear
me,
I
think
so,
yep,
okay,
okay,
I
I
have
a
comment
on
the
last
bullet.
So
on
you
you
mentioned
you
know,
map
m
value
may
be
a
lot.
You
know
efficient,
so
I
mean
my
question:
is
that
what
additional
information
is
needed
or
what
are
missing?
I
think
this
kind
of
thing
should
be.
You
know
described
in
this
job.
Otherwise
it's
not
clear
right.
I
Yeah
yeah,
okay,
thank
you,
father,
and
we
added
some
description
that
to
attract
that.
Currently,
information
missed
is
about
the
crossing
algorithm,
so
we
don't
have
any
standardized
algorithm
to
operator
on
how
which
slots
should
be
discarded
or
not.
So
that's
a
reason
that
we
think
that
m
value
is
not
a
sufficient
for
deciding
this
yeah.
A
So
you
mean
this:
this
issue
is
relevant
to
iqt
specification
or
just
how
to
say
vendor
specific
yeah.
I
B
H
The
description
about
crunching
or
for
other
cn
data
frame-
maybe
this
is
ipod,
mata
and
and
so
for
everybody,
otn
or
audio
scene
itself,
maybe
that
documentation
in
this
job
should
be
more
simplified.
In
my
opinion,
thank
you.
J
To
clarify
a
little
bit
about
the
value
of
them,
yes,
as
chiles
is
right.
The
reason
why
m
is
not
sufficient
is
because
it
is
vendor-specific.
So
if
you
cascade
you
don't
know
what
is
the
what
other
type
which
are
available?
But
in
the
draft
we
clarify
which
information
is
useful
and
the
information
will
be.
What
are
the
is
just
the
list
of
the
time
slots
which
are
available
on
the
two
ends
of
the
link
and
instead
of
the
m.
So
we
have.
J
We
have
clarified
that
in
the
draft,
not
in
the
slide,
but
it
it'll
roughly
write
down
that
the
qns
are
supposed
to
know
the
list
of
available
times
lots
and
how
they
know
it
is
depends
on
how
you
set
up
the
ucn,
which
is
outside
the
scope
of
this.
K
Hello.
Okay:
now
it
works
yes,
okay,
okay!
So
I'm
going
to
present
the
update
of
the
optical
impairment,
away,
topology
model
the
young
model
for
optical
internal
world
topology
model
and
on
the
alpha
of
co-authors
and
contributors.
Next,.
K
Okay
with
the
group
of
co-authors
and
also
other
attendees
in
the
weekly,
we
have
a
weekly
call
to
progress,
the
the
model
and
okay.
We
met
together,
asi
camp
in
september,
so
it
is
not
many
times
and,
as
said
in
the
next
step,
in
that
occasion
the
topic
was
to
finalize
the
transponder
model,
and
this
is
what
happened
so
we
finalized
the
transponder
model
with
the
version
5
of
the
uploaded
draft,
and
so
we
updated
both
the
younger
and
we
introduced
a
text.
K
The
new
text
in
section
2.5,
with
this
approach.
So
with
this
with
this
version,
so
basically
we
produce
a
young
that
reconcile
with
the
different
other
definition
related
to
the
transponder,
another
layer,
0
model.
K
We
have
defined
a
new
model
layer,
0
type
extension
model
in
containing
all
common
young.
That
should
be
the
reference
also
for
farter
document
and
update
and
in
fact,
we
plan
to
also
upload
the
the
the
draft
related
to
these
common
models,
so
the
layer,
zero
type
extension
and
then
the
second.
We
reconcile
the
transponder
model
with
what
we
consider
a
complementary
work,
that
is,
the
interface
model
containing
the
interface
parameter
yang
model.
K
K
Okay,
so
one
of
the
basic
factors
for
part
computation
is
is
in
the
case
of
the
the
use
cases,
for
the
optical
impairment
is
to
select
a
compatible
configuration
from
source
and
source
transceiver
and
destination
transceiver,
and
to
determine
optical
senior
compatibility
to
this.
The
to
make
these.
Since
singapore
meeting
so
itf
100,
we
decided
to
have
a
tree
approach
of
three
modes.
K
Interoperability,
since
in
the
parameters
that
are
provided,
implicit
in
in
specific
in
the
specification
from
i2t.
They
encompass
also
already
comes
optical
part
constrain.
K
K
With
with,
with
the
subsume
parameters
mentioned
before,
the
two
transceivers
are
interoperable,
if
they
have
at
least
one
common
pair
of
operational,
identify
organization
identify
operational
mode
plus,
they
support
a
common
range
between
frequency
and
power.
K
Then
there
is
the
explicit
mode.
So
there
is
a
list
of
parameters
that
this
explicit
mode
is
practically
coming
from
the
interface
model,
this
list
of
parameters
that
can
consistently
configure
the
mode
operation,
the
transceiver
in
the
parameters-
they
don't
consider
optical
path
parameters.
So
with
this
method,
we
cannot
guarantee
interoperability
and,
but
is
useful
in
case
you
have
not
iqt
or
ico
or
organizational
mode
or
the
optical
constraint
of
the
application
called
organizational
mode
cannot
meet,
cannot
be
met
by
by
the
the
wdm
system
by
the
line
system.
K
K
Okay,
here
is
a
slide
that
tried
to
explain
better
destruct
why
the
structure
of
the
organizational
mode,
how
is
provided
so
there
is
a
we.
K
We
want
to
show
the
mapping
of
the
actual
structure
of
the
organizational
mode
with
respect
to,
let
me
say
the
physical
of
the
typical
optical
transceiver,
so
we
have
two
different
blocks,
so
we
have
a
part
related
to
the
digital
signal
processing
and
these.
K
In
this
part,
we
have
the
set
of
parameters
that
are
subsumed
so
is
implicit
in
the
in
the
organizational
mode
in
the
operational
mode,
and
then
there
is
a
the
the
the
optical
front-end
that
is
managing
power
and
frequency,
and
this
is
our
and
the
the
the
preset
model
for
related
to
the
digital
signal
processing
need
to
have
an
exact
match
between
source
and
destination.
K
While
in
the
case
of
the
parameter
related
to
the
frequency
and
power,
we
don't
need
to
have
exact
match,
but
we
need
to
have
just
a
common
range
between
the
the
source
and
destination
parameters.
K
Moreover,
another
point
regarding
the
the
fact
to
advertise
explicitly
the
power
and
frequency
is
that
these
this
explicit
advertising
permits
to
support
what
is
the
the
real.
So
the
fact
that
at
the
moment,
the
optical
front
ends
so
the
pluggable
can
usually
have
a
slight
different
power
and
frequency
range,
and
so
to
avoid
to
have
a
proliferation
of
operational
mode.
K
K
So
this
is
just
a
summary
practically.
So
what
we
said
is
that
we
have
the
three
modes-
and
this
is
a
has
been
the
the
purpose.
K
Since
singapore
meeting
the
application
code
and
the
organizational
mode
are
at
style
of
behavior
very
similar,
so
we
need
to
find
the
source
and
destination
transceiver
common
set
of
application
code
or
the
organizational
mode,
and
then
the
part
computation
should
compute
a
pet,
a
part
that
can
meet
the
the
requirement
of
one
of
this
common
application
code
or
organizational
mode
is
a
similar,
but
the
problem.
K
Moreover,
last
but
not
least,
the
explicit
mod
gives
an
alignment
with
the
device
interface
model.
Next.
K
So
related
exactly
how
to
is
done
at
the
model,
so
the
the
the
transceiver
capability
are
described
for
any
transceiver.
We
describe
all
the
modes.
That
is
all
the
modes
that
is
supported
for
any
transceiver
and
the
young
model
is
is
flexible
in
the
sense
that
one
transceiver
can
support.
K
The
the
the
set
a
characteristic
of
explicit
mode,
explicit
mode
list
of
parameters,
can
support
theory
more
than
one
organizational
mode
or
application
code,
in
the
sense
that
the
set
of
value
can
be
complied
to
zero
to
n
of
the
organizational
mode
or
application
code
in
the
model.
We
we
provide
the
two
lists
with
the
soferoni
list
for
any
a
list
of
explicit
mode
attributes.
K
We
have
a
pointer
to
what
are
the
application
code,
organizational
mode
that
with
this
set
of
parameters,
you
also
support,
so
you
have
a
complete
picture.
K
Moreover,
the
the
the
transceiver
comprises
the
a
set
of
of
the
properties
that
can
be
explicit
or
implicit
that,
depending
of
the
modes
as
explained
before,
and
we
also
provide
the
next
slide.
Sorry
daniele.
K
We
provide
a
table
that
summarizes
the
the
mapping
in
for
the
different
attributes,
so
we
have
power
and
frequency
that
are
the
related
to
the
attributes
range
for
the
transceiver.
That
is,
okay.
Everything
is
implicit,
as
said
by
itu-t
and
in
the
both
in
the
organizational
mode
and
explicit
mode.
K
This
parameter
are
explicit
for
the,
and
then
there
is
the
the
list
of
all
optical
impairments
limit,
so
fact,
type
modulation,
baud
rate
etc,
and
these
are
both
implicit
for
application
code
and
organizational
mode
and
well
still
implicit
for
explicit
mode.
This.
This
is
just
a
summary
in
the
table
of
the
mapping
between
the
implicit,
explicit
relative
to
the
parameters.
K
Next,
the
model
is
providing
in
the
two
part.
One
part
is
a
providing
the
description
of
the
capability
of
the
transceiver
and
the
other
is
the
part
of
the
setting.
So.
K
Any
otsi
is
is
a
signal
that
is
generated
by
the
transceiver,
the
transceiver
that
is
attached
to
a
transponder,
and
so
we
describe
the
setting
in
the
sense
that
any
otsi,
transmitter
or
receiver
is
a
is
related
to
a
specific
transceiver
attached
to
a
transponder.
K
So
for
each
otsi
we
have
three
pointers:
one
pointers
that
provide
what
are
the
what
is
the
transponder
instance
containing
the
transceiver
terminating
the
otsi
one
pointer
to
related
transceiver
instance,
terminating
the
otsi,
and
then
the
pointer
of
the
currently
configured
transceiver
mode.
K
For
any
independent
of
the
type
of
mode
that
is,
configuring,
transceiver
all
audio
tsi,
described
in
the
model,
the
current
curry,
frequency
and
transmitter
power
and
the
received
power.
These
are
parameters
and
the
total
power.
So
for
the
for
the
total
bunch
of
to
that
for
the
total
spectrum,
these
parameters
are
are
always
provide
for
any
other
sign,
depending
on
the
mode
that
is
configured
next
in
in
the
next
slide.
We
okay.
This
is
the
snapshot
of
the
model.
K
There
is
a
the
three
pointer
for
the
configuration
that
is
actually
in
the
in
for
the
otsi
and
the
in
the
red.
There
is
the
the
the
common
structure
for
the
configured
parameters,
so
the
current
power
and
frequency
value
on
the
left.
K
You
can
see
the
structure
that
has
been
defined
and
this
structure
are
what
I
I
mentioned
in
the
in
the
second
slide,
related
to
the
extension
layer,
0
type
extension
that
collect
the
common
structure
that
we
have
defined.
So,
on
the
left
on
the
right,
you
can
see
the
the
structure
that
is
a
common
and
defined
in
the
in
in
this
new
module.
K
For
any
transponder,
you
have
a
set
of
transceiver
and
for
any
transceiver,
you
have
this
trans-supported
mode,
and
this
supported
mode
any
on
any
supported
mode
can
be
belong
to
the
class
of
or
application
code
organizational
mode
or
explicit
mode,
and
the
the
other
two
red
grouping
that
has
been
defined
is
one
of
the
related
to
the
the
the
common
power
and
frequency
range
attributes,
and
the
last
one
is
the
the
long
list
of
the
attributes
that
is
explicit
in
the
explicit
mode
are
all
instead
implicit
in
the
application
code
and
organizational
mode
that
subsume
all
these
parameters.
K
K
K
Because
I
this
this
slide
has
been
shared
by
any
one
of
the
cuatos,
and
so
this
is
the
the
official
one
in
which
I
summarize
the
issue,
so
so
the
organizational
mode,
the
the
issue
that
we
have
treated
is
related
to
these.
So
there
is
a
one
use
case
that
some
people
in
the
discussion
consider
a
corner
case
in
which
you
have
a
protecting
some
soup
parameters,
but
you
have
also
explicit
power
frequency
range
and
you
have
also
implicit
parameters,
setup
of
power
and
frequency.
K
The
example
that
I
report
is
is
that,
for
example,
if
a
server
report
that
is
transceiver
is
able
to
support
an
organizational
modex
that
has
a
frequency
mean
10,
but
organizational
modics
as
implicitly
also
set
up
in
this
in
their
specification
as
they
subsume
parameters
are
also
the
the
frequency
mean,
and
this
is
set
us
to
50..
K
One
of
the
possible
rules
that
has
been
raised
in
the
discussion
is
that
okay,
the
organizational
mode
optical
specification,
if
the
organizational
mode
optical
specification
define
already
and
implicit
parameters,
the
young
model
should
not
report
the
same
parameter
explicitly.
But
these
are
is
discussion
in
the
sense
that
we
have
not
a
definitive
answer.
K
K
K
Okay,
here
is
a
summary
of
what
is
the
status
of
the
open
issue.
Here
is
the
link
for
the
open
issue,
so
everyone
can
have
a
look
at
that.
We
have
at
the
moment,
16
issue
still
open,
but
there
are
a
couple
of
that
this
issue,
the
this
is
the
4142
that
is
related
to
the
transponder
model,
but
it's
just
require
a
better
definition
of
some
of
the
parameters.
K
So
this
is
an
issue
that
was
raised
by
gabriel
and-
and
we
expect
definition
from
from
him-
and
it
is
just
a
a
slight
modification
of
the
definition.
K
Then
there
is
the
issue
related
to
the
i2t
terminology,
but
it
is
linked
to
a
that
part
of
the
terminator
of
terminology,
also
an
iqt
and
okay.
There
is
a
big
issue,
the
number
23
that
is
related
to
the
trial
generator.
That
is
one
of
the
basic
plan
that
we
have
after
completion
of
the
transponder
model.
So
now
so
we
we
have,
as
in
the
next
step,
the
issue
5
and
12
have
been
closed
because
it
was
related
to
the
transponder
model.
K
Okay,
next
step,
I
said
basically,
we
already
start
a
discussion
about
the
trial
regenerator,
but
we
need
we
will
need
to
finalize
first,
the
optical
transponder
model,
so
we
plan
to
start
immediately
on
the
on
the
model
for
3r.
K
Obviously,
we
need
to
address
the
remain
open
issue
and
important.
As
said
before,
we
have
planned
to
upload
the
layer,
zero
type
extension
containing
the
module
that
we
have
created
and
last
not
list
keep
the
the
draft
itf
interface
model
align
with
what
is
contained
in
the
in
the
topology
model.
B
B
Issue
he
prepared
some
slides
to
make
the
discussion
easier
to
follow.
B
G
G
So
wson
has
a
definition
saying:
okay,
there's
some
future
work
for
vendor-specific
application
codes
and
essentially
it
reserves
64
bits
for
implementing
what
they
call
the
interface
class,
which
I
think
is
pretty
much
aligned
with
what
let's
say
something
that
looks
like
an
application
code.
Is
you
find
the
definition
here
below
there's
also
an
open,
config
implementation
that
basically
says
okay
and
there's
an
operational
mode
which
is
simply
an
unsigned
integer
of
16?
So
it's
it's
kind
of
a
simple
identifier
and
that's
it.
G
Then
there
was
some
discussions
up
till
october
26,
which
was
when,
when
I
sent
out
the
email
to
the
working
group,
we
had
this
kind
of
definition
in
our
draft,
which
basically
says
that
transceivers
supporting
the
same
organizational
mode
and
matching
the
same
constraints
they
will
interpret.
So
there
was
at
least
in
the
definition.
There
was
nothing
about
explicit
parameters.
G
So
the
next
one
was
then
there
was
an
update
on
november
2nd,
where
essentially
the
definition
changed
saying
when
you
can,
you
can
read
the
the
full
text.
The
the
thing
that
really
changed
here
on
the
right,
let's
say
in
yellow,
is
to
say
that,
in
addition
to
the
transceiver
properties
subsumed
by
the
operational
mode,
we
have
power
and
carrier
frequency,
modeled
separately,
meaning
kind
of
explicit,
and
the
reason
for
that
was
that
there
were
slightly
different
power
frequency
range
properties
for
interoperability.
G
So
that's
I
think,
in
line
also
with
what
sergio
was
reporting
next
page.
So
that's
how
it
looks
like
in
the
in
the
model.
So
you
see
here
that
there's
a
standard
mode
which
is
basically
an
identifier
there's
the
organizational
mode
on
the
left
with.
G
G
G
So
this
is
a
bit
about
the
the
matching
logic
for
organizational
code,
so
I'm
trying
to
describe
it
here
a
little
bit
so
the
the
case,
a
is
assuming
that
the
frequency
ranges
would
be
implicit,
so
this
would
be
in
line
with.
Let's
say
the
w
sun
assumption
or
the
current
open,
config
thing
and
case
b
is
supposed
to
describe
what
has
been
discussed
by
paseo
before
so,
let's
go
through
it
one
by
one.
G
The
key
point
is:
if
you
pick
a
single
application
code
or
mode
id,
I
call
it
mode
id
because
it's
easier
to
discuss,
let's
say
with
the
name,
so
I
said,
moda
d
is
equals
42..
So
that's
basically
the
code
that
has
that
the
interface
y
tells
to
the
pass
calculation.
That's
that's
the
mode
it
is
operating
and
the
pass
calculation
knows
its
local
mode,
which
happens
to
be
also
42.
G
So
there
is
a
complete
match.
Now
there
are,
let's
say
four
different
sub
cases
number
on
the
the
first
one,
the
first
column
is
they
completely
match.
So
if
frequency
arranges,
the
min
max
frequency
are
implicit,
they
need
to
match
because
you
have
the
same
mode
id
and
the
mode
id
is
defined
by
all
the
implicit
ranges.
G
So
that's
it
in
case
b,
there's
still
the
in
the
case
that
you
need
to
evaluate
the
the
mean
max
frequency,
because
it's
external
in
addition
to
the
mode
id
okay,
second
column
again
there
are.
We
have
two
different
interfaces.
They
both
report
to
support
mode
ide
42,
but
they
have
extended
frequency
ranges.
G
So
in
case
in
case
a
if
you
say:
okay,
I
don't
I'm
not
interested
in
any
kind
of
extended
frequency
range.
You
just
match
the
mode
id
mode
id
is
implicit,
so
you're.
Basically,
oh
there's,
probably
a
typo.
It
should
be
42.
there.
The
the
mode
id
is
implicit,
so
it's
kind
of
the
same
case
as
a
left
column.
G
But
if
you
really
want
to
have
the
extended
range,
you
could
still
do
it
with
match.
Matching
the
extended
range
by
using
the
explicit
code
so
x,
underscore
range,
as
you
see
on
the
bottom
right
is
the
explicit
range
in
an
explicit
code,
the
overrange
just
photocompletion.
That
would
be
the
explicit
range
in
the
organizational
code.
G
So
it
could
end
up
in
you
have
an
explicit
range
defined
in
explicit
mode.
It
points
to
an
operational
code
that
has
a
different
range
and
yeah,
so
it
kind
of
sticks
up
the
other
column.
Number
three
is
what
happens
if
the
the
frequency
range
of
let's
say
the
green
and
the
red
interface
are
slightly
different.
G
So
in
a
sense
there
is,
let's
say,
the
the
the
common
mode
that
you
would
would
think.
That
is
this
kind
of
purple
square,
so
there's
there's
some
gaps
to
the
left
and
the
right.
The
the
case
a
doesn't
allow
this,
because
again,
ranges
would
be
treated
as
implicit
and
by
definition,
only
the
first
column
is
allowed.
G
G
Similarly,
this
is
the
right
thing.
It's
a
kind
of
extreme
way
of
showing
the
column
of
the
three
again.
It's
the
same
logic
case.
A
doesn't
allow
to
model
it
case
b
would
allow
to
model
it
and
the
result
of
the
model
could
be.
There
is
no
interoperability
at
all,
because
simply
the
the
frequency
ranges
do
not
match.
G
G
So
the
question
is:
what
exactly
is
the
issue
we
are
trying
to
address
by
saying
there
are
slightly
different
input,
power
ranges
or
frequency
ranges?
G
Is
it
let's
say
the
column
two
three
or
four,
then
the
next
question
is:
okay,
let's
figure
out
what
it
is
that
is,
it
is
the
the
team
proposal
really
clear
and
addresses
the
issue
effectively
I
mean
is:
is
this
from
a
engineering
standpoint
really
the
way
to
go
and
the
other
one
is
whatever
it
is
and
is
our
is
that
proposal
that
comes
out
of
it?
Is
it
consistent
with
other
work,
or
what
do
we
need
to
do
with
the
other
work
in
order
to
make
it
match?
G
So
again,
that
is,
my
interpretation
is
that
the
change
from
only
implicit
on
organization,
mode,
to
implicit
to
explicit
codes
and
organization
mode
is
a
pretty
heavy
lifting
compared
to
what
is
already
available,
and
I
think
it
makes
sense
that
the
working
group
a
is
aware
of
it
and
makes
a
decision
if
they,
if
we
want
to
go
in
this
direction
or
not.
B
G
So
I
think,
when
we
look
into
consistency
with
prior
work,
only
the
column
two
would
use
a
combination
of
an
implicit
mode,
which
is
this
mode
id
42,
and
only
if
you
want
to
use
this
kind
of
extended
ranges,
the
kind
of
orange
orange
square.
Only
in
this
case,
you
need
to
go
via
the
exte,
the
explicit
mode.
G
So
think
of
it
make
a
concrete
example:
let's
assume
an
organization
like
say
meth
would
define
a
a
code
mode
id
which
is
kind
of
the
the
purple
one
then
different
vendors
may
have
different
implementation
and
they
can
do
that's
an
extended
range
in
frequency
and
power.
So
that's
the
the
column
two
I
say:
okay,
look!
If
you
want
to
interpret
on
the
purple
on
a
pure
standard
basis,
you
stay
with
the
mode
and
that's
it.
L
Can
you
hear
me
yes,
very
good,
yeah?
I
would
like
to
point
out
that,
as
sergio
has
mentioned
during
his
presentation,
we
did
actually
agree
that
we
should
support
the
three
modes
describing
the
capabilities
back
at
ietf
100
in
singapore,
and
he
also
mentioned
the
rationale
that
was
behind
the
three
options.
L
Now
we
have
further
refined
the
organizational
mode
approach
for
describing
the
capabilities,
and
we
said
taking
into
consideration
the
physical
realization
of
optical
transponders,
where,
in
today's
technology,
very
often
optical
pluggables
are
used
and
the
optical
pluggables
for
the
optical
pluggables,
you
need
to
know
the
capabilities
in
terms
of
frequency
range
and
power
ranges
in
transmit
and
receive
direction.
L
We
said
that
this
is
defined
as
an
optional
attribute
on
top
of
the
organization
in
the
operational
mode,
together
with
the
organizational
id
these
parameters
explicitly
to
allow
slight
modifications
of
physical
properties
that
these
pluggable
modules
have.
So
that's
also
an
implementation
can
actually
decide
or
an
organization
can
decide
whether
some
of
these
parameters
are
included
in
their
organizational
mode
description
or
if
they
should
be
described
explicitly.
L
So
that's
a
very
flexible
model,
which
is
also
a
future
safe
and
allows
some
variations
in
terms
of
the
physical
realization
of
the
equipment
taking
the
technical
part
aside
for
a
moment.
L
I
also
would
like
to
point
out
that
we
discussed
this
point,
at
least
for
three
months
in
the
last
half
a
year
for
at
least
three
months
constantly
in
every
meeting,
and
this
discussion
is
really
preventing
us
from
moving
forward,
and
this
was
in
a
discussion
that
was
within
the
group
of
the
contributors
and
authors
which
are
meeting
every
week
for
an
hour
every
thursday
and
was
then
brought
up
by
one
individual,
because
he
seems
to
not
agree
with
what
most
of
the
group
has
been
agreed
and
is
actually
supporting,
and
I
have
no
idea
why
we
can't
move
forward
just
because
of
one
individually,
one
individual
constantly
questioning
the
usefulness
of
the
approach,
which
is
supported
by
all
the
others
in
the
group.
B
L
Can
I
just
add
one
one
one
sentence:
I
think
the
ietf
rules
is
that
there
should
be
a
rough
consensus,
and
my
perception
was
that
there
was
rough
consensus
in
the
group
before
we
started
to
continuously
discuss
this
specific
point.
B
That
that's
why
we
are
bringing
this
to
the
to
the
full
working
group.
Now,
if
there
is
a
no
consensus
between
the
group
of
authors,
so
we
will
see
what
is
the
the
consensus
of
the
group
we.
F
K
So
not
just
that
daniel,
since
you
point
to
the
fact
that
to
stay
on
the
technical
part,
okay,
this
is
a
young
model
for
topology
and
in
the
couple
of
the
first
slide
that
gert
presented,
he
made
some
hints
about
the
data
of
text
related
to
the
finish
organizational
mode.
Now.
What
has
happened
is
that
there
has
been
a
young
model
update
no
on
the
27th
of
october,
and
this
young
model
has
been
approved
by
some
reviewers
by
chance.
K
One
of
the
reviewers
that
approved
the
model
was
gertrum
so
in
that
young
model,
as
you
have
seen
before,
there
is
this
difference
of
related
to
the
explicit
parameters
related
to
the
organizational
code.
So
what
is
the
intent
to
discuss
again
when
a
young
model
has
been
already
committed
in
the
github?
K
We
have
a
lot
of
discussion
about
how
to
reach
the
the
agreement
for
the
young
model
and
when
the
the
model
has
been
approved
by
the
the
the
the
team
that
is
supporting
and
working
on.
The
draft
then
raise
questions
about
the
list
of
parameters
by
the
way,
the
fact
that
to
have
they
possibility
to
avoid
proliferation,
operational
mode.
As
as,
as
explained
before,
one
one
of
the
reason
for
which
the
explicit
power
sample
power
and
frequency
are
explicit
is
the
fact
that
we
have
a
proliferation
operational
mode.
K
There
was
some
discussion
raised
by
gerta
exactly
on
the
point
that
at
the
beginning
of
this,
the
some
at
least
one
year
ago,
the
fact
that
one
of
the
problem
organizational
code
is
the
risk
to
have
a
proliferation.
So
these
explicit
parameters
avoid
to
have
proliferation,
but
now
the
explicit
parameter
does
not
work
anymore.
So
I
think
that
we,
it
seems
that
we
just
jump.
K
Behind
and
then
ahead
again-
and
it
seems
that
if
there
is
no
willingness
to
produce
something
effort,
active
effort
and
not
just
try
to
stop
the
progressive
of
the
work.
Okay,
not
no
one
compelled
a
people
to
stay
in
a
group.
B
B
B
J
Thank
you,
mr
chairman.
Okay,
the
a
few,
a
couple
of
comments.
I
notice
in
the
about
the
previous
work
on
double
zone
and
I'm
not
fully
familiar
on
all
the
details,
but
the
rfc
that
has
been
mentioned
by
gert
is
just
providing
a
hook
for
vendor
specific
modes,
but
it
doesn't
say
too
much
on
how
they
are
refined.
So
I
think
here
we
are
going
a
little
bit
doing
a
step
forward
with
respect
to
what,
in
that
rfc
is
not
incompatible.
J
J
For
the
case
b.
Where
you
have
the
species
range
explicit,
then
I
understand
the
two
quizzes.
You
either
pick
up
the
mode
42
and
then
you
you
take
a
frequency
range
in
a
common
range
which
is
defined
in
the
organizational
range
registration
code,
or
you
can
pick
up
mod
43
and
then
take
a
frequency
range
in
the
explicit
code
common
range.
The
combination
of
both
looks
very
messy
and
I
don't
understand
how
you
can
combine
the
two
modes
and
make
it
work.
G
Yes,
yeah
so
yeah.
Thank
you
for
the
comment.
I
tried
to
let's
capture
what
detailers
said
in
let's
say
those
three:
let's
orange
boxes
later
on,
where
the
second
box
in
case
b
is
max,
match
explicit
range
or
a
combination
of
both,
so
that
that
looks
a
little
bit
messy
to
me
as
well.
G
In
any
way,
I
would
like
to
to
ask
the
proponents
of
the
of
the
code.
What
exactly
is
the
model
you
or
the
problem
you
intended
to
solve?
Is
it
column
two
three
or
four.
B
L
Unfortunately,
I
haven't
okay,
yes
yeah.
Unfortunately,
I
haven't
seen
this
light
before
and
I
I
was
just
trying
to
follow
during
the
presentation.
What
is
the
explanation,
but
what
what
we
see
today
is
that
we
have
in
the
realization
of
optical
transponders.
L
We
can
use
optical
pluggables,
and
these
optical
pluggables
sometimes
have
different
power
ranges
slightly
different
power
ranges,
and
they
may
also
support
different
frequency
ranges
and
in
order
to
allow
the
part
computation
function
to
calculate
a
path
that
takes
those
properties
into
consideration
which
are
not
a
part
of
the
operational
mode.
We
said
that
those
parameters
should
be
described
explicitly
in
addition
to
the
operational
mode.
That
was,
that
was
the
issue
that
we're
trying
to
solve.
L
I
have
some
difficulties
to
exactly
understand
on
this
slide
because
it's
very
crowded,
to
which
case
it
really
matches.
B
L
L
L
On
the
other
hand,
you
may
have
also
a
plugable
that
supports,
I
don't
know
a
power
range,
for
example,
from
0
dbm
to
minus
8,
dbm
and
another
one
that
supports
a
range
from
minus
1,
dbm
to
minus
10
dbm,
for
example,
and
this
is
important
information
for
the
path
computation
function
to
calculate
also
the
optical
feasibility.
So
this
is
important
information
that's
required
for
the
path
computation
function
that
actually
makes
use
of
the
topology
model.
The
optical
impairment
aware
topology
model.
L
G
The
big
issue
which
I
would
like
to
bring
up
here
is:
when
do
we
need
to
use
a
different
mode
id,
and
when
can
we
use
the
same
mode
id
so
coming
back
to
what
ddr
just
said
about
c
plus
l
band?
So
that's
the
case
on
the
right,
the
right
column,
where
you
say
hey,
I
I
have
a
transceiver
that
operates
in
c
band
and
another
transceiver
operates
in
the
l
band,
but
they're
using
the
same
mode
id.
G
L
I
mean
that's,
that's
one
possibility
an
implementation
can
decide
to
do
it
one
way
or
the
other
way.
The
young
model
is
flexible
enough
to
do
it
both
ways.
B
Exactly
so,
if
the
point
is
whether
I
should
use
mode
id42,
plus
some
extensions
which
are
allowed
by
the
model,
or
I
should
define
a
mod
id
for
t3,
I
think
this
is
outside
our
scope.
We
provided
the
tools
to
encode
the
information,
then
how
how
it's
included
this
should
be
left
to
the
the
the
producer
of
the
transponder.
M
Hello,
this
is
gemerick.
Can
you
hear
me?
Well,
yes,
okay,
actually
you
almost
summarized
my
the
point
I
was
about
to
make.
Thank
you
for
that.
M
There
may
have
some
wrong
ways
to
use
the
open
fields,
because
you
may,
in
many
protocols,
carry
two
fields
who
carry
country
opposite
information,
so
obviously
there
are
a
bad
way
to
use
a
protocol
specification,
but
here
the
idea
is
to
be
able
to
describe
a
wide
range
of
possible
hardware.
I
feel
the
model
with
the
various
specification
modes
fully
fully
fits
this
requirement
and
unable
to
describe
various
things.
M
I'm
here
under
the
current
displayed
slide,
I'm
really
confused
and
I
think
I'm
fully
aligned
with
italo
on
detail
on
that,
because
it
feels
to
me
that
the
mod
here
is
badly
used
on
it's
referring
to
different
things
and
clearly
they
shouldn't
either
it's
42
taken
for
different
species.
So
in
fact
it's
not
the
same
42
and
they
don't
collide
or
either.
If
it's
the
same
numbering
space,
there
shouldn't
be
42
in
all
cases.
So
it
feels
to
me
that
here
it's
not
a
clear
problem
statement
and
probably
a
way
to
address.
M
It
is
not
to
stand
to
change
the
specification,
but
maybe
to
add
some
clarification
text
or
guidelines
to
mitigate
the
wrong
use
that
an
implementer
may
be
tempted
to
to
take
if
they're
not
familiar
enough
with
the
with
the
model.
But
I
feel
the
model
is
large
enough
to
accommodate
very
needs
and
for
me
it's
the
way
to
go.
G
Okay,
can
I
assign
a
lot
to
actually
yes,
sorry
yeah,
so
I
understood
that
you,
let's
say,
would
support
that.
The
model
supports
also
the
column.
Let's
say
the
the
two
last
columns
where
I
say:
okay,
I'm
using
the
same
mod
id
but
let's
say
frequency
range
or
power
range.
G
M
Yeah
on
this
one,
I
feel
the
need
to
point
to
italo's
presentation
that
he
shared
a
week
a
couple
of
weeks
ago
within
the
group,
and
I
think
it's
deeply
linked
to
that
and
if
you
feel
there
is
some
unclear
spec,
we
may
give
some
inputs
in
the
draft.
But
I
don't
think
it's
a
it's
a
modeling
issue.
M
G
M
Well
to
me,
the
two
write
columns,
don't
describe
a
pro
a
problem
statement
clearly
enough
to
to
give
you
an
answer.
The
mod
id
is
supposed
to
be
attached
to
another
organizational
code
if,
within.
D
M
B
C
Yeah,
thank
you.
I'm
also
trying
to
understand
this
table.
It
seems
on
the
on
on
the
same
play,
page
of
slides
on
the
left
top
corner.
The
mode
id
42
has
a
list
of
parameters
with
some
quantitative
values.
It
is
too
small
to
read,
but
I'm
just
trying
to
say
it's
not
a
modeling
problem,
but
it's
a
kind
of
implementation
and
people
just
confused
on
okay,
who
is
specifying
this
kind
of
value?
C
D
D
C
C
We
need
to
know
okay,
how
to
use
the
mode
id
in
the
organizational
mode,
because
I
I
don't
see
the
debate
on
the
application
code
or
explicit
mode,
because
everything
we
could
we
can.
We
can
tweak
or
everything
is
fixed,
but
for
organizational,
it's
quite
flexible,
and
if
we
still
want
to
guarantee
the
interoperability,
we
need
to
be
very
carefully
on.
B
K
I
I
have
just
a
short
comment
that,
probably
before
in
my
presentation
I
I
forgot
to
say
that
the
explicit
parameters
that
you
have
in
organizational
mode
are
also
optional.
So
because
this
reflect
the
model
is
very
flexible,
and
so
the
fact
that
you
can
you
an
implementation
can
use
that
or
not
it's
just
an
implementation
problem,
not
a
problem
with
the
model.
K
So
this
is
the
a
clear
point
that
probably
I
miss
in
the
in
the
presentation.
So,
frankly
speaking,
I
think
that
what
julian
said
is
that
a
text
that
can
clarify
a
possible
problem
in
the
precedence
provided
that,
frankly
speaking,
the
table
provided
by
gert
for
me,
is
very
confused.
So
he's
not
I'm
not
able
to
judge
that,
based
on
these
slides
and
but
the
discussion
we
had
in
the
weekly
we
already
provided
that
they
needed
to
have
a
text
that
clarified
the
precedence
pointed
out
by
by
guard
this
morning.
K
So
it's
nothing
that
has
not
been
already
discussed.
B
A
H
A
Page
five
yeah,
so
actually
I
in
this
page
it
says
that
it
mentioned
that
you
know
one
of
the
coming
for
application,
application
code
mode
and
it
says
application
does
not
support.
You
know
beyond
100g
capability,
so
my.
A
That
shall
we,
you
know,
shall
we
as
iqt
members
go
to
you
know,
iqt.
I
bring
some
contributions
to
iqt
to
define
the
applications
for
the
young
beyond
100g,
and
then
we
can
go
back
to
itf
to
define
the
you
know.
Young
models
for
the
optical
impairment,
especially
for
the
beyond
100g.
Is
this
unfeasible.
A
Yeah,
so
my
just
you
know,
comment
to
sergio,
and
so
what's
the
issue,
if
this
the
issue,
just
you
know
from
i2t
recommendations
anyway,
I
think
we
should
fix
this
issue
in
i2t
right.
A
B
First
of
all,
thanks
for
the
discussion,
because
this
was
really
useful
and
it
it
needed
all
the
time
to
to
to
to
sort
this
out.
I
think
that
the
way
forward
is
to
send
out
the
polling
to
the
to
the
mailing
list.
B
Not
not
more
than
that,
the
options
that
I
was
thinking
on,
while
you
were
speaking
aware,
option
a
leave
everything,
as
is
option
b.
Add
the
text
to
the
draft
describing
the
scope
a
little
bit
better,
which
means
if
there
are
possibilities
in
that
we
don't
want
to
cover.
We
explicitly
say
these.
These
use
cases
are
not
over
covered
by
by
us
option
c:
go
back
to
itu
to
have
more
application
codes
that
can
cover
that
can
cover.
B
All
all
the
cases
option
d.
I
would
ask
gert
to
send
me
his
proposal
for
option
d.
If
there
is
an
option
d-
everything
by
monday,
if
possible,
because
I
would
like
to
send
out
the
polling
on
monday
and
close
it
by
next
friday.
B
By
the
weekend
and
on
monday,
I
will
send
the
four
options
to
the
working
group
for
for
decision
to
find
an
agreement
by
the
end
of
next
week.
F
B
D
D
Yes,
okay
hi,
so
my
name
is
iowa
go
and
I'm
from
futurewii
and
I'm
here
presenting
this
new
draft
framework
and
data
mode
of
otn
network
slicing
on
how
behalf
of
the
co-authors
and
contributors
next.
D
So
an
ota
network
can
provide
hard
pipes
with
quality
service
such
as
deterministic,
latency
and
bandwidth.
D
So,
and
here
we
are
talking
looking
at
providing
volcano
network
resources
to
support
against
specific
use
cases.
For
example,
we
were
talking
about
supporting
least
aligned
services
with
opn,
in
which
a
customer
typically
like
a
node
over
the
top
rider
uses
one
or
multiple
point-to-point
origin
connections
to
connect
its
data
centers
across
the
network.
D
Second
use
case
is
called
construction
and
sharing
of
otn
network,
where
multiple
service
providers
can
build
the
same
routine
network
to
in
order
to
save
cost
and
each
of
the
service
provider
in
this
case,
shares
and
uses
network
resources
and
are,
and
their
resources
are
kind
of
isolated
from
each
other
and
in
the
third
use
case
we
have
a
wholesale
of
optical
resources
where
one
provider,
one
service
provider,
is
serves
as
an
otn
wholesaler
to
provide
otn
network
resources
to
another
service
provider
and
the
other
service
provider
would
expect
to
be
able
to
use
the
the
purchase
the
network
resources
just
like
they
are
self-constructed,
the
the
last
but
not
least,
the
use
cases
vertical
dedicated
network
in
other
industries.
D
Like
financial
industry
or
manufacturing
industry,
where
people
are
asking,
they
are
asking
for
dedicated
otn
network
to
satisfy
some
stringent
network
conditions
like
deterministic,
latency
and
and
non-gendered
bandwidth.
D
D
Yeah,
so
what
is
an
otn
size?
You
know
we
can.
Slice
is
just
a
collection
of
otn
network
resources
used
to
create
a
logically
dedicated
virtual
network
over
one
or
multiple
underlying
otn
networks.
D
So
for
for
for
an
o-10
slice,
some
of
the
slos.
D
Of
an
ocean
slice
can
be
must
be
expressed
in
the
node
in
specific
way.
For
example,
the
the
bandwidth
is
expressed
in
terms
of
numbers
and
types
of
odu
and
osu
odu
time
slots
and
osu
is
a
new
term
for
a
smaller
and
flexible
granularity
of
time
slots
and
when,
if
we
are
talking
about
specific
otn
time
slots,
we
could
we
were
talking
about
in
terms
of
the
tributary
slots,
intuitive
reports,
so
other
definition
of
the
slos
generica
those
generica.
D
So
those
follow
can
follow
the
definition
now.
Oh,
I
think
I'm
missing
some
words
here.
I
can
follow
the
definition
coming
from
the
the
itf
network,
slice
discussion
in
the
tease
working
group
and
the
current
relationship
with
the
with
the
itf
network
slice
er
model,
the
one
for
that
defines
a
generic
network
slice
using
network
topology.
D
That
one
is
for
some
further
investigation,
as
also
I'm
going
to
show
in
in
the
later
slides
it's
possible
to
augment
the
model
by
with
and
add
otm
specific
information.
Next.
D
Yeah,
so
this
is
the
picture
of
a
where
we
are
defining
otn
slicing
function
in
the
in
the
whole
picture
and
as
well
as
the
the
placement
of
the
model.
D
So
we
we
see,
there's
a
otn
slice
controller
called
otn-sc
that
can
be
either
placed
inside
an
sdn
controller
as
a
internal
function
of
an
sdn
controller,
or
it
could
be
as
a
separate
function
box
outside
of
the
controller
and
if
it
is
placed
outside
of
the
controller,
the
otn
slice
controller
will
be
translating
slice
configuration
from
from
a
high
level
orchestrator
into
into.
D
A
technology-specific
model
using,
for
example,
t
topology
and
t-tunnel
and
talk
to
the
s-pen
controller,
whereas
if
it's
inside
an
sdn
controller,
it
can
use
internal
api
to
talk
to
a
pnc
which
is
out
of
scope
of
this
of
this
draft,
and
please
note
in
this
whole
picture,
we're
talking
about
the
requirement
request
for
note
and
slice
coming
from
the
user
with
for
otn
specific
slice
requirement
requests
right,
so
the
interaction
the
otn
slice
could
be
hierarchical,
meaning
that
one
otn
slice
controller
can
talk
to
yet
another
otn
slice
controller
in
in
a
recursive
manner,
using
the
same
interface
yeah.
D
So
there
are
two
modes
for
otn
slice.
One
is
what
we
call
link
based
slicing,
in
which
a
link
and
also
its
ports
are
dedicated
to
a
single
uk
and
slice,
and
in
the
second
case
we
could
actually
create
an
open
slice
using
some
one
or
multiple
time
slots
tributary.
D
Right
so
currently
we
are
defining
the
young
models
and
the
updated
model
will
be
coming
out
in
the
in
the
next
version
and
as
we
as
I
said
before,
we
are
cons.
The
authors
are
considering
augmenting
from
the
itf
network
slice
yarn
model
to
add
otn
information
for
for
configuring,
the
origin,
slice.
D
That's
the
next
step
to
come
up
with
your
model
definition,
and
also,
at
this
point,
we're
more
welcoming
comments
and
also
looking
for
coalition
for
this
draft.
N
Yeah,
thank
you
try
to
be
really
quick
on
this.
Firstly,
it
would
be
helpful
to
put
this
document
in
context
of
the
work
being
done
in
teens
rather
than
defining
new
stuff.
Do
you
do
the
authors
expect
any
deviation
from
the
terminology
and
framework
that
teas
is
is
working
on.
D
I
okay,
so
I
think
the
the
framework
would
be
in
line
with
with
the
peace
draft,
but
because
the
use
cases
we
are
looking
at
is
more
from
from
an
otm
perspective.
So
we're
hoping
to
augment
or
add
more
otn
technology
specific
requirement
into
the
into
the
slides
definition.
N
Okay,
yeah
that
that
sounds
reasonable.
The
other
thing
I
draw
your
attention
to
is:
there's
a
document.
That's
been
discussed
in
teas
on
the
applicability
of
a
ctn
to
slicing,
so
that
may
be
relevant
for
you.
B
Much
thanks
adriana-
and
this
brings
to
my
question,
which
is
in
what
he
know-
tiana's
lice,
is
different
from
an
otna
service.
I
mean
I
see
this
can
be
like
a
number
of
otn
tunnels,
stitched
with
each
other.
So
in
the
end
it's
an
ectn
virtual
network
and
what
is
different
from
that.
D
Yes,
this
is
one
type
of
otn
slice,
but
we
are
more
looking
into
what
do
you
call
it?
It's
it's
a
resembles
like
an
ac,
tmdm
type
2,
which
is
a
resource
slicing
that
that
forms
a
virtual
network
that
can
be
used
to
for
the
client
to
set
up
connections
on
the
on
the
sliced
network.
D
B
H
Please
clarify
the
scope
of
otn
itself.
What
do
you
mean
by
otn
here,
and
the
reason
is
that
it
includes
osu
at
the
new
discussion
like
duties.
D
B
K
Can
you
hear
me
yep,
okay,
so
thanks
iowa
for
for
the
presentation,
there
are
a
lot
of
interesting
things
in
there,
but
I
have
a
new
clarification
following
the
design
theme
of
the
slicing.
K
Well
for
me,
otn
slice
is
a
realization
of
a
slice
base
on
some
requirements,
for
which
transport
slice
controller
decide
that
the
best
technology
is
ltn.
K
D
It's
it's
not
just
a
realization,
in
my
view,
because
we
are
the
the
the
in
this
case
right.
The
requirement
from
all
the
way
from
the
top
is
to
specify
which
otm
resources
or
what
what
type
of
rodium
resource
is
needed
for
this
for
the
slice.
D
So
it's
it's
not
just
say
you
know
you
have
you
come
with
a
generic
network
slice
and
that
the
the
realization
will
be
carried
over
an
otn
network
this.
Well,
this
I
mean
this
is
one
scenario,
but
we
are
talking
about
another
one
that
says
the
customer
expresses
its
slice
in
terms
of
otn
resource.
J
I
will
try
to
reply
to
boss
sergeant
to
some
extent
also
to
alien.
Actually,
that's
exactly
why
we
were
a
little
bit
struggling
with
the
alignment
with
the
design
team
in
teas.
The
reason
is
that,
in
some
cases
the
audience
lies
may
be
implemented
to
realize
a
generic
transpose
lies,
as
defining
these,
in
other
case
may
be
used
to
offer
a
service
to
the
customer.
In
this
case,
the
cmi
is
also
tn
technology.
J
B
Okay,
thanks
a
lot:
italy
thanks
a
lot
everyone
for
the
good
discussion.
We
learned
that,
no
matter
how
much
time
we
ask
for,
we
always
manage
to
feel
it,
which
is
good,
because
it
means
that
there
is
a
lot
of
interest
and
energy,
and
so
I
will
wait
for
option
d
from
from
gert.
Remember,
please,
remember,
to
check
the
polling
next
week
on
the
optical
internment
draft
and
that's
it
let's
meet
again
virtually
at
the
itf
110.