►
From YouTube: IETF-CCAMP-20220216-1300
Description
CCAMP meeting session at IETF
2022/02/16 1300
https://datatracker.ietf.org/meeting//proceedings/
B
C
C
C
C
C
C
A
Okay,
so
let
me
put
this
into
presentation
mode,
so,
first
of
all,
thank
you
cheers.
Thank
you.
Thank
you
for
all
the
participants
to
join
the
discussion.
So
we,
the
authors
over
the
past
few
weeks,
have
discussed
about
the
comments
and
feedbacks
also
with
with
the
question
raisers
as
well
to,
and
we
put
together
like
some
slides,
to
share
our
thoughts
here.
So
here
I'm
I'm
presenting
this
draft.
This
slides
on
behalf
of
all
the
authors
and
co-authors.
A
Out
of
those
comments
we
have,
we
tried
to
categorize
them
into
four
parts.
The
first
part
is
about
more
or
less
about
the
improvements
to
the
direct
draft
text,
and
here
we
have
noted
down-
and
the
authors
are
working
towards
a
second
update-
to
incorporate
those
comments
and
and
then
for
those
comments
that
we
have
kind
of
reached.
A
consensus
during
the
adoption
call
is
to
first,
we
need
to
harmonize
with
the
network
slice
nba
yang
in
ts,
and
the
consensus
is
the
otn
slicing
model.
A
That
needs
to
be
kind
of
clarified
or
updated
to
reflect
our
thoughts.
So
we
could
match
what
we
are
discussing
with
network
slicing,
as
well
as
otn
slicing
with
the
picture
in
defined
in
the
ict
and
slicing
draft,
and
there
are
also
a
lot
of
questions
during
the
discussion
which
we
believe
it
could
be.
A
So
we
probably
should
wait
until
it
becomes
clear
to
move
forward
with
the
with
the
network.
Slicing
work
as
well
as
otn
slicing,
for
example,
so
those
questions
can
probably
be
addressed
towards
teeth,
and
so
what's
left
is
of,
I
think,
five
questions
that
are
really
related
to
this
draft
and
we're
gonna
see
to
put
some
responses
towards
those
main
points.
A
A
C
A
Technologies
available
for
the
realization
of
of
a
slice
and
also
on
the
otn
layer
in
the
control
and
management
plane.
For
example,
the
all
the
points
about
l1
vpn,
t,
topology
t
tunnels
could
be
used
to
realize
a
a
slice
and
also
people
could
even
use
nms
or
direct
net
confident
young
by
to
configure
the
cross
connects
with
that
supports
an
otn
slice.
A
A
A
A
A
A
The
left
side
is
what
we
see
a
typical
use
of
for
otn
slices
in
an
otn,
only
networks,
and
in
this
case,
when
we
have
otn
slice
controller
and
a
an
otn
slide
aware
consumer,
which
uses
the
the
audience
slice
nvi
to
configure
a
and
an
otn
only
slice
right,
whereas
on
the
right
side
is
an
ip
plus
otn,
and
there
are
also
two
two
options
to
for.
I
for
to
create
an
audience,
create
a
slice
over
ip
plus
otn
networks.
A
When
it
comes
to
the
otn
domain,
then
the
technology-specific
otn
slice
mpi
could
be
used
or
it
could
use
any
existing
models
to
do
the
job
right
and
for
for
otn
slicing
on
the
left
side,
then
the
technology,
specific
otn
slice
mbi
will
be
used
to
support
an
ot
and
aware
customer
to
configure
an
option.
Slice.
A
A
C
Okay,
so
actually
I'm
I
understand
that
the
first,
the
first
use
case
at
the
tien
only
where
we
need
the
otnsc
to,
let
me
say,
be
a
sort
of
a
gateway
between
the
con,
the
consumer
and
and
the
network.
So
I
understand
the
way
we
need
the
no
dns
cnbi
over
there,
but
in
in
the
picture
in
the
in
the
middle,
since
the
itf
nsc
as
an
spi
that
is
capable
to
directly
interact
with
the
ip
network.
C
C
A
A
Oh
for
yeah,
for
this
picture:
yes,
you're,
you're
right
so
for
the
ietf
network.
Slice
controller
can
directly
use
the
pnc
mbi
to
request
to
realize
the
slice
in
otn
right,
but
it
also
has
an
option
to
to
delegate
the
piece
of
the
slice
configuration
to
the
otn
slice
controller,
with
the
intent
like
interface
and
the
the
the
framework
also
points
out
that
we
could
create
configure
a
slice
either
in
a
hierarchical
way
or
stitch
them
together
right.
A
So
in
that
sense,
when
we
have
an
otn
sc
mbi,
we
allow
both
options
to
work
and,
as
a
matter
of
fact,
you
see
this.
So
the
the
the
use
case
on
the
left
and
use
case
in
the
middle
for
otn.
There's
no
difference.
You
know,
so
it
doesn't
matter
whether
the
request
comes
directly
from
otn,
aware
customer
consumer
or
from
the
ietf
network
slice
controller
right.
C
Yeah,
but
in
in
one
case
I
mean
on
the
left.
I
understand
that
the
intent
based
type
of
request,
because
that
comes
from
a
consumer
but
on
the
right
on
the
middle
in
the
middle.
I
don't
understand
why
the
itf
nfc
needs
to
have
something
that
is
intent.
Based
that
that's
just
my
my
concern,
but
I
see
the
queue
is,
is
populating
probably
I
mean
I
live.
I
leave
room
to
the
others
for
discussion.
We
have
igor
at
the
beginning
of
the
queue
okay.
D
D
In
my
opinion,
it
doesn't
make
sense
and
here's
why?
Okay,
the
network's
license
is
inherently
took
down,
process
emerging,
dynamic
process
and
the
goal
of
the
process
is
to
create
connectivity
constructs
of
various
types
of
various
complexity
levels
which
can
support,
slows
throughout
the
lifetime
of
the
slice.
D
That's
the
purpose
of
network
slicing,
okay.
So
again,
it's
top
to
bottom
immersion
process.
Okay,
now
otn
is
still
the
transport
layer
and,
as
such,
it
do
what
it
always
does.
Basically,
it
can
offer
a
bottle
up
network
building
process,
okay,
basically
by
providing
point-to-point
links
to
hire
clients
so,
for
example,
imagine
an
application
which
needs
point
to
multiple
in
distribution
without
solos,
and
it
asks
for
a
network
slice.
D
D
Basically,
for
example,
it
wouldn't
try
to
map
point
to
multiple
point.
Three
onto
point
to
multiply
connection
created
in
otm,
okay,
what
it
will
do
it
will
ask
otm-
and
not
just
one
atm
but
probably
multiple
independent
networks,
multiple
independent
otms
and
not
just
others.
By
the
way
it
could
be
different.
Other
transports,
probably
even
without
idea,
but
all
the
same,
all
it
will
ask-
is
to
create
more
links
to
enrich
it
ip
topology,
so
that
it
can
realize
the
point
to
multiple
connectivity.
D
Okay,
so
it
is.
Basically,
there
is
something
normal
that
slicing
were
discussed
in
the
network
framework,
but
absolutely
nothing
new.
What
we
are
trying
to
do
in
otn,
okay,
even
when
you
have
end-to-end
otm
at
the
end
of
the
day,
it
is
the
end
result
is
a
end-to-end
otn
service
which
provides
a
link
to
a
higher
client.
D
Okay.
This
is
one
point.
The
other
thing
is
that
I
I
asked
many
times
about
this
question
where
this
other
than
point-to-point
connectivity
will
come
from
and
they
come
and
go
away
out
of
the
question
list.
Okay,
so
I
want
this
to
be
answered
and
finally,
the
authors
think
that
into
the
network's
license
framework
is
not
limited
to
5g.
D
But
there
is
nothing
in
the
ns
framework
which
is
defined
in
the
in
ns
framework,
which
is
not
needed
for
5g
there's
nothing
at
all,
and
there
is
nothing
that
came
from
other
applications
other
than
from
g
into
in
this
framework.
So
in
this
sense
it
is
limited
to
5g.
In
fact,
it's
all
about
5g.
It
is
some
it's
a
very
old
concept
that
existed
for
decades
and
it
only
came
to
life
because
of
a
5g.
D
D
A
Okay,
so
let
me
try
to
respond
first,
so
in
terms
of
the
comments
that
there's
nothing
new
for
otn
slicing.
Well,
I
mean
for
the
with
we
are
so
we
agree
that
there
are
a
lot
of
technology
that
are
currently
available
in
ietf,
right
so
from
the
perspective
of
say,
realizing
a
sort
of
quote-unquote
slice
for
otn
there's
nothing
new,
because
we
have
the
data
plane
and
we
have
control
plane
technologies
right.
A
A
A
A
A
D
D
What
I'm
saying
again,
the
only
way
it
could
it
could
make
work
is
that
the
transport
networks
provide
point-to-point
links,
that's
what
it's
all
limited
to.
Okay
and
use
at
this
point
to
point
links.
Then
the
higher
layer
can
do
point
to
multiple
point
distribution
and
one
one
more
comment
that
I
forgot:
okay,
it's
to
danielle
and
for
thai
say
if
we
decide
to
go
with
autumn
slicing.
D
Of
course,
we
will
have
to
do
the
same
for
all
other
transport
layers
right,
for
example,
there
could
be
no
athens
at
all,
and
but
you
will
need
to
do
to
consider
slicing
in
microwave,
in
och,
in
flexi
in
everything.
So
basically
it
opens
up
the
whole
slew
of
pretty
much
the
same
work
that
we've
done
for
topology
at
tunnels.
C
Well,
actually,
yes,
you're
right
in
the
sense
that
if
there
will
be
contributions
and
the
working
group
will
believe
that
it
makes
sense.
Why
not
if
the
working
group
decides
that
it
makes
sense
that
we
have
what
tiana's
license
and
there
are
contributions
on
microwave
slicing
and
it
makes
sense.
Why
am
I
not
doing
that?
C
D
D
Okay.
So
so
you
cannot
say
that
you
know
we
have
to
decide
so
the
way
you
define
slicing
it.
Basically,
nothing
is
not
slicing.
That's
what
I'm
saying
so
the
wires
are
sliced.
Everything
is
slicing,
becomes
okay,
fiber,
slicing,
fiber
layer
slicing.
All
the
things
could
be
sliced
exactly
the
same
way
as
the
the
discuss
in
the
otn
context.
A
You
go,
I
think
I
I
I
agree
with
you
so
if,
today,
all
those
can
be
used
to
to
for
the
slicing
right
while
we
are
more
or
less
talking
about
this
slicing
as
a
concept,
which
is
a
management
concept
that
that
basically
says
I
am
a
user,
and
I
wanted
it
to
have
something
which
I
now
we
call
it.
A
slice.
A
D
D
A
D
E
E
D
G
If
you
can
go
back
to
the
figure,
my
question
was
very
much
related
to
what
even
danielle
was
pointing
out,
and
my
thinking
was
coming
from
what
is
the
relationship
between
the
idea
of
network
slice
controller
and
the
otn
slice
controller
in
the
current
figure?
It
totally
feels
like
that.
The
otn
sc
is
completely
independent
from
itf
nsc.
It
is
not
using
any
of
the
components
that
are
going
to
be
a
part
of
itf
nsc
and
something
that
needs
to
be
rebuilt,
but
on
the
other
hand,
to
me
what
it.
G
What
makes
sense
is
like
how
we
look
at
the
ndi
for
the
nbi.
We
are
saying
that
we
are
just
gonna
augment
the
itf
nsc
nei,
with
the
technology,
specific
otn,
specific
elements
and
it's
sort
of
like
an
augmentation,
and
I
think
of
idea
of
network
slice
controller,
also
as
an
augmentation
in
the
sense
id
network
slice
controller
does
all
the
operations
that
we
want
a
slicing
controller
to
do,
but
it
is
technology.
Agnostic,
odin
sc
is
just
an
instantiation
of
an
itf
network
slice
controller
that
understands
otn
parameters
right.
G
G
A
A
G
In
a
way
it
does-
and
I
would
think
that,
like
you
know,
is
there
really
a
need
for
hariki
in
this
kind
of
system?
Like
imagine,
if
the
top
controller
understands
the
otn
specific
parameters,
then
it
makes
it
makes
it
so
much
more
simpler
than
like.
You
know,
having
a
separate
box
need
for
a
separate
box,
because
at
that
it's
just
a
software
component
that
we
are
talking
about,
which
is
going
to
understand
the
otn
parameters.
G
A
A
Yes,
actually
so
so
those
pictures
shows
what
we
call
the
functional
block
right,
but
in
the
in
in
deployment
or
in
implementation,
you
could,
if,
if
the
ietf
network,
size
and
otn
slides
are
put
together
in
a
single
single
deployment,
that's
that's
not
a
problem.
It's
just!
It's
just
that.
We,
let's
say
to
support
otn
technology
specific
slices.
There
needs
to
be
this
functional
block
in
either.
A
G
A
Okay,
let
me
see
if
there
so
maybe
maybe
I'll,
move
forward
with
the
rest
of
the
slides,
and
then
we
can
continue
the
discussion.
You
know
just
to
quickly
go
through
that.
Okay,
where
we
are
at
okay,
the
the
next
one
is,
can
we
call
it
an
otn
slice
right?
I
think
this
goes
along
with
with
our
last
argument.
So
basically,
the
concept
of
network
slicing
is
originated
from
5g,
which
assumes
a
an
ip
scenario
for
with
packet
transport
networks.
A
A
Vpn
is
a
possible
realization
of
nulty
and
slice
and
of
course,
we
have
other
realizations,
also
possible
and
as
far
as
as
as
we
understand,
some
of
them
have
been
already
implemented
so
and
the
relationship
between
one
vpn
to
otn
slice
to
layer.
One
vpn
is
analogous
to
what
itf
network
slice
is
towards
the
l1
l2
l3,
vpn
and
yeah,
which
also,
for
example,
enhance
the
vpn.
C
D
Good
quick
so,
basically
to
say
that
its
slice
qualification,
it's
actually
something
specific
to
atf
and
has
nothing
to
do
with
5g
is
is
inaccurate.
Okay,
it
is
basically
it
has
everything
to
do
with
5g
slicer,
but
this
is
a
way
to
say
that
itf
cannot
handle
things
like
ram
okay,
so
it
it.
It
cannot
be
responsible
for
m2
and
5g
slice,
okay,
but
it's
it's.
D
It
is
pertinent
to
certain
components
for
five
5g
slice
like
core
and
black
hole.
Okay,
now
the
otn
has
nothing
to
do
with
5g.
Basically,
it
prints
nothing
to
do,
and
it's
it's
incorrect
to
to
compare
this
way.
It
is
incorrect
to
basically
to
do
the
same
qualification
by
saying
that
this
is
otherwise.
A
C
D
D
F
D
A
Okay,
but
but
okay,
I
understand
it's
a
work
in
progress
right,
but
the
this
this
again
the
I
think
we
probably
should
put
comments
to
the
network
slice
framework
to
clarify
that,
if,
if
that
is
the
the
way
you
intend
to
do,
the
the
my
other
comments
on
your
question
is,
you
said:
otn
has
nothing
to
do
with
5g
and
I
kind
of
I
disagree.
There
are
5g
services
that
could
run
directly
over
otn
as
we
as
we
see
today,
right.
A
D
Of
course,
because
because
ip
is
actually
two
layer,
two
layer
layer,
okay,
there
is
a
service
layer.
Okay,
and
this
is
a
transfer
plate
in
ip
okay.
So
the
the
transport
layer
in
ip
is
actually
could
be
replaced
by
otn,
but
the
service
layer
cannot
be
replaced.
So
you
cannot
run
anything
5g
wise
on
top
of
a
tier.
D
D
A
D
F
F
D
You
confuse
it.
This
particular
argument
with
iowa
is
about
5g.
Okay,
we
are
not
discussing
the
framework,
yet
here,
okay,
the
framework,
we
basically
it's
something
which
is
work
in
progress
and
it's
a
big
question,
whether
it's
about
5g
or
it
goes
beyond
5g.
This
is
one
of
the
questions
that
needs
to
be
decided
in
tears,
but
all
I'm
saying
is
that
5g
has
zero
effect
effect
on
what
here.
F
D
F
A
D
D
Reason,
the
reason
why
it
is
the
interest
back
to
slicing
is
because
previously
in
4g
the
radio
links,
though
they
basically
have
low
capacity
and
the
end-to-end
quality
of
service,
didn't
matter
much
okay.
Now
now,
because
if
you
use
a
microwave
for
5g,
it
puts
a
lot
of
pressure
to
to
do
end-to-end
quality
of
service,
and
this
is
why
the
solution
is
to
go
back
to
network
slicing.
H
H
So,
according
to
the
5g
slicing
components,
it's
composed
by
the
the
run
segment,
the
core
segment
and
transport
segment
and
the
itf
network
class
was
trying
to
focus
on
the
transport
side
and
ota
is
a
part
of
that.
So
so
we
don't
have
to
directly
link
the
otm
or
otn
slides
to
5g
slides,
but
that
is
definitely
a
part
in
the
transport
it
can
be
called
domain
or
or
some
network
in
the
as
a
5g
slice
components
and
within
the
transport
network.
H
A
A
Yeah,
so
I
think
I
have
just
one
or
two
so
yeah.
The
the
same
arguments
applies
to
the
abstract
topology.
As
we
have
pointed
out
this,
the
the
realization
could
be
done
by
using
t
topology
for
both
otn
and
for
ietf
network
slice
right
yeah.
I
think
we
can
skip
that
this.
I
think
we
already
touched
it.
It's
yeah.
I
think
I
have
that's.
A
A
East
I
mean
I,
I
think
we
we
could
do
both
right,
but
but
my
my
concern
is
a
lot
of
the
comments.
Actually,
it
should
probably
be
clarified
in
the
teeth
for
network
slicing.
First,
like
the
scope
of
our
itf
next
network
slice
right
is
it
is
it
for
5g
only
or
for
something
else.
Is
it?
Is
it
just
ip
or
something
else
right
with
this?
If
if
let's
say,
if
the
ietf
network
slice
decided
to
say
okay,
it's
it's,
it
should
be
just
the
ip.
C
A
And
if
and
also
if
they
say,
oh,
we
do
not
want
to
call
it
a
slice.
Then
then,
if
we
are
still
trying
to
put
it
in
a
scope,
we
then
we
also
should
change
the
names
right
I
mean
all
those
are
are
relevant.
I
think
a
lot
of
the
problems
are
just
generic
generic
per
se.
You
know
which
brought
to
a
lot
to
to
otn
slicing.
D
C
A
C
Okay,
let's
do
let's
do
like
that?
Let's,
let's
continue
the
discussion
on
or
or
better,
let's
put
together
the
right
questions
with
the
right
wording
on
on
the
c
campaign
list.
Once
once
we
we
find
a
some
sort
of
agreement
and
they
consolidated
the
set
of
questions
we
we
send
them
as
a
liaison
to
do
this.