►
From YouTube: IETF-TEAS-20210927-1400
Description
TEAS meeting session at IETF
2021/09/27 1400
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
A
A
As
you
may
have
noticed,
we
do
have
a
personal
change.
We
have
a
new
working
group
secretary,
luis
contreras,
will
be
serving
as
our
working
group
secretary.
Starting
with
this
meeting.
Please
join
us
in
welcoming
him.
We
would
like
to
thank
matt
hartley,
our
outgoing
working
group
secretary,
for
all
the
hard
work
that
he
has
done
in
this
role
for
for
the
past
few
years.
We
would
also
like
to
thank
those
of
you
who
volunteered
to
serve
as
the
working
group
secretary.
A
It's
always
good,
to
see
folks
willing
to
come
forward
and
serve
the
community
in
terms
of
meeting
logistics.
We
are
using
miteko
thanks
for
joining
the
session.
Wyoming
techo
the
integrated
chat
or
jabber
is
available
for
use.
We
will
be
tracking
the
chat
during
the
session.
Please
use
the
notes.itf.org
link,
that's
listed
here
for
minute.
Taking
any
help
with
regards
to
note
taking
would
be
greatly
appreciated.
A
Today's
session
is
a
network
slicing
focused
meeting.
The
focus
is
exclusively
on
the
open
issues
in
our
working
group,
adopted
network
slice
framework
document
and
on
the
network,
slice
nba,
modeling
discussion
that
is
still
active
on
the
list.
The
objective
is
to
discuss
some
progress
as
much
as
we
can
towards
resolution
on
these
open
items.
A
This
is
the
agenda
for
today.
Adrian
will
have
a
go
first
and
highlight
the
open
issues
in
the
framework
document.
We
will
attempt
to
address
open
questions
on
the
definition
of
the
service,
the
endpoint,
and
also
look
at
the
realization
architecture.
As
part
of
this
section,
we
will
then
dive
into
the
next
section,
which
is
the
nbi
discussion.
The
authors
of
the
document
that
we
are
currently
polling
for
adoption
would
go
first
and
talk
about
the
rationale
behind
that
modeling
approach.
This
would
be
presented
by
bo.
A
Daniely
would
follow
that
up
with
a
view
on
the
concerns
related
to
the
document
that
is
under
consideration.
We
have
about
20
minutes
after
that
for
open
discussion
on
the
topics
covered.
We
will
use
this
20
minutes
discussion
time
as
we
team
fit.
The
chairs
would
then
hopefully
be
able
to
wrap
things
up
by
summarizing.
How
we
did
with
the
session
objectives
in
the
last
five
minutes
in.
A
Okay
in
terms
of
liaisons
and
communications
from
other
standards
bodies,
we
received
one
communication
from
gsma.
In
august
they
sent
a
pointer
to
a
white
paper
that
they
put
together,
which
discusses
the
end-to-end
network,
slicing
architecture.
They
are
asking
us
to
take
this
paper
into
consideration
and
are
seeking
feedback
on
it.
A
There
is
a
request
for
an
action
to
be
taken.
I
think
the
deadline
is
october
15th.
If
anyone
in
the
working
group
is
interested
in
sending
a
response
to
gsma,
please
to
review
the
white
paper
and
and
propose
a
response
on
the
list,
we
can
then
have
this
discussed
and
coordinated
with
the
isg
and
also
with
the
iab,
if
needed,
because
we
don't
have
a
formal
liaison
relationship
with
gsma.
We'll
get
this
done
by
our
ad.
A
A
As
a
reminder,
we
do
have
an
ipr
process
in
place
to
for
our
working
group.
There
are
two
mandatory
steps
before
accepting
it:
accepting
a
document
into
the
working
group
and
also
before
taking
it
last
call,
we
mandate
all
others-
all
authors
and
contributors
for
of
the
document
to
explicitly
state
if
they
are
aware
of
an
ipr
that
applies
to
the
document
in
recent
months,
we
did
introduce
another
step
in
the
process.
A
Finally,
please
do
use
the
mailing
list
as
much
as
possible.
Please
be
aware
that
the
mailing
list
is
where
the
working
group
consensus
is
actually
determined,
so
it
always
makes
sense
to
have
these
conversations
happen
on
the
list.
We
don't
know
how
long
we
will
continue
to
be
in
this
online
mode,
so
we'll
try
and
make
the
best
use
of
the
tools
that
are
available
to
us
to
make
progress
in
the
documents
working
group
members
can
request
for
an
online
interim
to
be
scheduled
if
there
is
a
need
to
cover
a
specific
topic.
A
Today's
session
is
a
good
example
of
that,
and
also
note
that
several
other
several
working
group
participants
are
already
making
use
of
the
working
group
webex
to
hold
regular
informal
working
meetings.
You
can
request
the
chairs
if
you
have
such
a
need,
these
meetings
will
be
announced
on
the
list
and
will
be
open
to
all.
That's
all
I
believe
we
have
for
this
lot.
I
will
now
go
over
to
adrian
for
his
presentation.
B
B
B
B
So
when
you
build
a
a
network
slice
service
request,
you
might
be
saying
I
want
a
set
of
points
to
point
potential
connections
so
that
I
can
build
a
full
mesh
and
send
my
traffic.
How
I
want-
or
you
might
be
saying
I
want
several
point
to
points
and
several
point
to
multipoints
and
one
multi-point
to
multi-point
and
build
it
up
like
that.
B
C
C
B
D
You
adrian,
my
only
point
here
was
that
also
in
this
definition
of
the
connectivity
matrix,
there
was
the
the
idea
of
only
a
the
the
parameters
for
the
delivery.
No,
I
mean
for
the
transmission
for
the
reception,
so
this
will
be
covered
later,
but
I
mean
my
opponent
here
will
be
okay
for
the
for
having
more
than
one
matrix.
This
is
at
the
end.
It
can
be
realized
in
different
manners
later
on
by
the
a
network,
slice
controller,
but
this
matrix
should
be
complete
and
probably
for
for
being
complete.
B
A
Not
to
myself,
hopefully
yeah
personally,
I
think
the
information
model
adding
that
to
this
framework
document
is
a
bit
of
an
overkill
like
you're
saying
I
think
you
do
have
most
of
the
components
already
listed,
maybe
a
bit
more
text,
and
I
think
we
should
be
good.
I
I
think
info
model
in
this
document
at
least
is
oracle.
B
E
B
E
B
B
So
you
need
to
go
back
and
look
at
that
definition
of
connectivity
matrix.
If
what
you
want
to
do
is
stick
with
that
definition,
then
all
you're
saying
is:
let's
have
lots
and
lots
of
slices
compared
to
right
compared
to
one
slice
with
multiple
matrices
lots
of
lots
of
them
yeah.
So
my
my
original
point
was:
if
an
implementer
wants
to
support
multiple
matrices
on
a
slice
and
they
can
do
it,
why
should
we
stop
them?.
E
B
E
E
B
B
G
F
I
am
a
little
confused
by
igor's
assertions,
because
I'm
looking
at
the
email
that
kristoff
sent
to
the
list,
which
pointed
out
that
you
may
want
multiple
connectivity
matrices
to
represent
different
services
for
different
subsets
of
traffic
within
the
slice
and
separately.
You
may
have
properties,
for
example,
of
the
port
that
are
slice
wide.
F
Therefore,
it
is
not
sufficient
to
just
say
well,
just
have
to
use
a
separate
slice
for
each
connectivity
matrix,
because
there
are
properties
that
are
for
the
slice
and
there
are
properties
that
are
for
the
connectivity
matrix,
and
if
that
is
true-
and
I
believe
he
is
correct,
then
the
structure
you're
using
is
correct.
We
may
need
to
allow
more
cases
where
there
are
multiple
connectivity
matrices,
but
again
exactly
how
the
traffic
is
bound
is
not
a
problem.
We
need
to
deal
with
at
this
level.
B
B
The
debate
was:
where
is
the
slice
service
delivered,
and
a
lot
of
this
discussion
has
happened
in
the
context
of
cs
and
pes,
but
we
should
recognize
that
this
terminology
of
cemp
is
not
universally
helpful
when
people
are
interested
in,
for
example,
network
functions
and
so
on.
But
it's
it's
a
useful
picture
and
I
identified
four
cases
of
where
the
service
endpoint
might
be,
as
shown
on
this
figure
and
the
text
goes
through
those.
B
B
I
B
B
B
B
B
B
B
This
pretty
picture
is
attempting
to
get
some
terminology
out,
and
so
the
way
to
read
this
picture
is
to
read
it
from
the
top
down
and
the
bottom
up.
At
the
same
time,
from
the
top
down
a
network
slice
is
this
set
of
potential
connections
between
end
points
and
that's
a
customer
view,
and
from
the
bottom
upwards
we
have
a
a
physical
network
that
has
to
be
programmed
to
forward
and
treat
the
traffic
correctly.
B
Then
continuing
from
the
bottom
upwards,
there's
the
potential
to
filter
a
topology
to
produce
a
set
of
nodes
links,
resources
that
have
specific
capabilities,
for
example,
they
might
be
links
that
support
maxsec
whatever
from
the
top
down.
We
have
this
thing
of
grouping
slices
into
a
bundler
set
that
we
operate
on
a
partition
of
the
network
resources,
and
then
we
have
this
thing
of
generating
that
set
of
resources
from
the
available
topology.
B
The
names
we
have
here-
ietf
network
slice
and
itf
network
size
service.
I
think
we're
happy
with
physical
network
we're
happy
with,
and
that
just
gives
us
two
names
to
deal
with
the
network
resource
partition
and
I
think
I'm
seeing
debate
now
that
we're
down
to
either
network
resource
partition
or
network
resource
group
with
slightly
different
overtones
for
group
or
partition,
and
then
we've
not
really
talked
about
the
filter
topology.
B
E
G
B
G
B
C
Yes,
I
I
think
this
is
a
very
useful
diagram.
Honestly,
thanks
for
putting
it
together,
it
clarifies
a
lot.
You
know
how
we,
at
the
end
of
the
day,
realize
the
service
in
our
on
on
the
underlay
transport
network,
and
you
know
the
steps
might
vary,
which
one
starts
before
the
next
one,
but
overall
at
least
the
solution
that
we
are
pushing
for
is
aligned
with
this.
So
I
would
like
to
see
this
in
our
network
slice
draft,
at
least
this
diagram.
If
you,
if
you
can.
B
Yes,
yeah,
I
you'll
notice
it's
pre-prepared
in
ascii
as
well
and
you're
right.
I
I
had
started
work
on
a
workflow
and
then
I
believe
that
which
order
you
build
these
things
in
is
very
much
implementation,
specific
and
probably
doesn't
matter
from
a
framework
point
of
view.
Thanks
chairs
over
to
you.
B
A
Okay,
we
will
now
shift
our
focus
to
the
network
slice
nbi
discussion.
We
did
initiate
that
option
for
draft
wd
on
august
27th.
There
seems
to
be
consensus
on
the
need,
at
least
at
least
on
the
need
for
an
ietf
network
slice,
nba
data
model
to
be
furnished.
There
is
reasonable
support
for
adopting
this
document
as
the
starting
point
for
this
work,
but
we
do
have
a
reasonable
number
of
working
group
participants
who
have
raised
concerns
on
the
modeling
approach
used
in
this
document.
A
We
do
need
to
resolve
these
concerns,
and
that
would
be
the
objective
for
this
section
of
the
session.
At
a
high
level,
there
are
primarily
two
questions
that
we
would
like
to
get
discussed
and
resolved.
The
first
question
is
with
regards
to
the
scope
of
the
nbi:
is
this
a
service
model,
or
is
it
something
else?
There
seems
to
be
a
school
of
thought
positioning
this
as
a
network
model,
we
will
have
somebody
we'll
have
daniel
represent
that.
A
The
second
question
is:
what
should
the
nbi
be
based
on?
Should
we
define
a
new
independent
service
model,
as
is
defined
in
traffic
wd,
or
should
we
use
the
existing
vn
model,
or
should
we
define
a
new
model
by
augmenting
the
vn
model
or
any
other
existing
service
model
like
l3s
model
tsm,
or
do
we
leave
room
for
all
options,
so,
hopefully,
by
the
end
of
this
session,
we
will
have
some
clarity
on
the
way
forward
for
these
questions,
so
without
any
further
delay.
A
J
J
J
So,
the
this
slice
service
model
is
used
when
service
provider
for
provides
like
slicing
as
service,
like
so
different
from
the
existing
one
like
layer,
three
vpns
service
or
ac
tmvn
as
service.
So
in
this
way,
customer
could
focus
on
the
service
requirements
rather
than
whether
it's
a
vpn
technology
or
whether
it's
a
ctn
technology.
G
J
H
J
So
it's
very
in
the
model
it's
hard
to
use,
so
we
are
thinking
reusing.
This
wheel
model
is,
is
pro,
is
quite
hard
and
the
other
approach
is
augmenting
with
model
and
then
the
same
issue
applied
here.
So
still
this
is
t
topology
coupling
and
there's
also
some
comments
proposed
that
they
want
to
remove
t
topology
banding,
but
because
this
model
doesn't
exist
and
and
right
now,
ietf
network
slice
definition
doesn't
see
that
a
network
slice
is
a
type
of
virtual
network
and
and
nse
is
also
defining
ap
or
vnap.
J
J
So
in
this
way
the
network
slice
service
model
is
modeling,
a
user
modeling
approach
as
layer,
3,
sm
and
layer,
2
sm,
and
it
doesn't
use
other
t,
topology
model
or
other
top
topology
model
to
support
the
service
and
because
and
also
right
now,
in
teas
network.
There
are
other
approaches
to
implement
slice
services,
something
like
multi-topology
flexago.
J
J
Yes,
here's
we
want
to
give
a
more
detailed
modeling
approach,
comparison
on
like
the
what's
the
difference
with
accused
point,
defining
win
model
and
what's
and
the
nse
definition-
and
you
can
see
in
this
picture
that
I
show
a
t
topology
here
and
access
point.
Defining
wheel
model
refers
to
the
access
link
between
customer
node
and
also
the
provider
node.
So
with
each
access
link,
then
we'll
we'll
use
an
access
point
to
identify
this
access
link.
J
So
it's
a
one-to-one
mapping,
this
access
link
and
with
this
and
we'll
also
use
t
topology,
abstract
node,
to
define
the
weigh-in
connectivity
matrix.
So
they
are
using
this
modeling
approach.
But
given
the
difference
with
networks,
slice
endpoint,
actually
network
slice,
endpoint,
just
like
adrian,
just
give
the
definition
on
the
and
service
endpoint
this
modeling.
J
J
J
J
J
J
J
And
next
pack,
please
yeah.
So
our
conclusion
still
is
that
we
believe
a
new
independent
network
slice
service
module
is
needed
as
per
a
current
ietf
network
slice
definition
and
this
model
doesn't
have
some
can
coexist
with
other
existing
customer
service
model,
and
so
this
is
very
helpful
for
this
network
slide
service
work.
J
G
K
K
The
draft
is
presented
as
a
customer
service
model,
but
our
impression
was
that
it
was
used
a
little
bit
differently.
It
was
claimed
to
be
a
customer
service
model,
but
it
was
used
a
little
bit
differently,
so
we
took
rfc8309
and
we
started
to
analyze
the
various
models
here,
given
that
we
often
speak
about
customers.
K
K
K
Probably
the
answer
the
answer
is
not
is
no,
and
I
mean
the
previous
preventive
presentation
also
said
clearly
that
it's
not
something
that
sits
on
interface
b
and
by
the
way.
One
thing
that
we
seem
to
agree
on
is
the
fact
that
the
service
delivery
model
doesn't
really
exist
in
in
real
networks,
because
the
service
orchestrator
and
the
network
orchestrator
in
many
cases,
are
collapsed
into
into
a
single
entity,
which
is
what
we
call
here
for
simplicity,
oss,
slash
orchestration.
K
K
K
If
you
look
at
the
right
side
of
the
picture,
we
have
what
we
thought
would
happen,
but
didn't
happen,
which
is
the
the
left
side
branch,
where
the
cnc,
the
customer
application
controller.
Whatever
is
direct
access
through
customer
services,
service
models
to
the
mdsc
to
the
operator
network
in
general.
K
What
really
happens
in
the
industry
is
what
you
see
on
the
right
where
you
have
the
oss,
the
orchestrator,
what
we
call
the
before
oss
orchestration,
which
again
is
joined
the
service
orchestrator
and
the
network
orchestrator,
but
managed
and
operated
by
the
operator
which
have
access
to
the
mdsc.
So
there
is
where
we
have
the
network
models.
In
fact,
it's
where
we
have
the
l2
nm
model,
3,
nm,
etc,
we
etc.
K
We
hardly
ever,
if
not
ever
see
the
service
models
between
those
two
components.
The
customer
then
sits
on
top
of
this
oss
box.
There
can
be
other
boxes,
the
bss,
etc,
and
it
uses
the
customer
service
model
to
request
for
services,
connections,
etcetera
to
the
operator
from
a
network.
Slicing
point
of
view,
we
agree
that
this
customer
service
model
is
missing.
K
K
K
If
you
see
on
the
left,
we
have
an
ect
and
enable
the
network
where
we
have
the
mdsc,
the
pnc
is
etc.
On
the
right,
if
we
have
a
known,
ctn
type
of
network
with
or
without
traffic
engineering,
for
example,
unf
topi,
tip
master
method,
so
the
architecture
is
is,
is
always
the
same
with
the
same
type
of
models
being
used,
and
here
we
are
adding
now
the
nfc,
the
nsc
I
mean
is
not.
K
K
Let's
assume
that
the
network
slicing
nbi
is
a
customer
service
model,
so
it
seems
that
we
are
all
starting
to
a
degree.
This
is
the
case.
A
service
model
for
network
slicing
is
missing.
Yes,
yes,
this
is
this
is
true.
We
have
service
models
over
there
del2
sam
three
sm,
but
they
are
not
enough
for
for
nato
slicing,
it
could
be
possible
to
augment
them,
but
I
mean
no
one
is
objecting
the
fact
that
a
new
model
can
be
can
be
used
there.
K
K
It's
expected
to
be
done
to
against
the
uss.
Not
so
it's
not
an
nfc
ndi.
If
we
all
agree
that
the
nsc
is
something
sitting
at
the
mdsc
level,
slash
hierarchical,
sdn,
controller
level
and
this
model
shouldn't
be
used
by
the
operator
as
a
network
model.
So
it's
not
something
that
should
be
used
by
between
the
two
operator
components
so
between
the
oss
and
the
mdsc
or
hierarchical
sdn
model,
simply
because
existing
models
can
already
meet
the
requirements.
K
K
K
By
the
way.
Speaking
about
models
we
went
to,
we
tried
to
understand
a
little
bit
better
better
where
the
l2
sm
and
nm
and
three
sm
and
then
m
position
themselves
to
see.
If
there
was
alignment
with
the
sorry
I
I'm
already
jumping
into
the
next
slide.
I
can.
Can
you
go
to
that
thanks
thanks
a
lot,
so
we
we.
K
We
wanted
to
check
how
the
service
and
network
models
position
themselves
against
rfc
8309,
and
we
found
that
there
is
actually
a
lot,
a
lot
of
confusion,
because
the
l3
nm
says
it's
a
service
delivery
model.
The
l2
nm
says
it's,
it's
a
network
model,
so
I
mean
we
have
some
confusion
in
mind,
but
I
would
say
this
is
something
that
is
a
pretty
much
widespread.
K
K
So
again,
what
is
this
component
to
this
customer
level
operation
for
what
we
said
before?
This
is
what
we
call
the
dss
orchestration,
something
that
belongs
to
the
operator
that
doesn't
belong
to
the
customer.
In
fact,
if
you
see
the
mapping
on
the
right,
everything
is
red,
light
red
and
not
and
not
blue.
K
K
Next,
please,
so
a
very
quick
overview
of
the
existing
models
with
them.
Without
a
sctn
there
between
the
oss
and
the
hierarchical
sdn
controller,
we
have
a
wide
set
of
modules:
vpn
network
models,
l1
csm,
l2
and
m3,
and
m
network
models,
not
not
service,
not
to
the
service
version.
Topology.
We
have
the
network,
topology
t
topology
for
the
infrastructure.
We
have
t
tunnels,
virtual
network
lsps
policies
and
the
t
service
mapping.
How
is
it
possible
to
to
to
to
realize
a
an
ethos?
K
Slicer
today
in
a
non-te
type
of
network,
you
can
ask
for
a
plain
vpn
layer,
2
or
layer
3..
You
can
ask
for
plain
infrastructure
in
lsp,
a
simple
policy
that
can
be
implemented
via
flexalgo
segment,
routing,
etc.
If
yen,
with
or
without
tea.
Today,
the
vienna
doesn't
support
the
non-tea
scenarios,
but
the
augmentation
is
is
extremely
extremely
simple.
K
In
a
tea
type
of
environment,
you
can
do
something
a
little
bit
more
more
sophisticated.
You
can
create
a
vpn.
You
can
create
a
a
t
tunnel,
a
and
then
bind
the
vpn
to
the
t
timer
using
the
t
service
mapping,
which
is
the
reason
why
the
t
service
mapping
was
created.
You
can
do
it
with
a
t
tunnel.
You
can
do
it
with
a
vm,
I
mean
both.
Both
of
them
are
perfectly
perfectly
work,
as
I
said
before.
K
K
Proposed
augmentations
so
first
one
supporter
for
technology,
agnostic,
topology,
the
vienna
abstract
node,
to
be
used
to
reference,
a
topology
which
today
is
a
t
topology
using
a
profile
of
the
t.
Topology
for
non-t
scenarios
is
perfectly
possible.
It's
as
it's
explained
today,
in
an
existing
draft.
In
the
end
that
is
working
group,
so
it's
possible
to
apply
the
the
abstract
node,
also
to
non-t
topologies.
K
This
is
something
that
needs
to
be
a
little
bit
discussed
and
then
a
simple
mapping
of
terminologies
like
like
the
following
one
net
slice:
virtual
network,
slo,
sle
policy,
part
constraints,
nsn,
point
access,
point,
mdn,
access,
point,
ns
connection
is
a
vn
member.
The
all
of
these
things
that
perfectly
map
one
to
one
and
they
meet
all
all
the
constraints
of
the
nether's
lies.
K
K
G
B
B
The
next
small
point
is
that
when
I
look
at
bose
draft,
the
only
time
it
mentions
nbi
is
actually
in
the
file
name,
the
whole
of
the
rest
of
the
time.
It's
talking
about
network
slice,
customer
service
model,
and
my
belief
is
that
we
need
a
network
slice
customer
service
model
in
the
working
group
and
provided
we
make
sure
that
we
all
know
that.
That
is
what
we're
talking
about.
We
should
just
get
on
and
deal
with
it
and
then.
B
J
Yeah,
I
think
adrian
helps
us
to
clarify
the
fellow
name
yeah.
We
are
sorry
about
the
file
name.
It
may
be
misleading
that
that
seems
more
like
a
network
model,
but
actually
we
are
doing
a
customer
service
model
and-
and
the
other
thing
is
that
dan's
talking
about
the
net
slice
network
model
and
we
we
think
the
these
are
quite
useful.
But
this
is
not
our
model
and
we
hope
we
can
get
consensus
that
on
defining
this
customer
service
model.
L
I
Yeah,
I
guess
one
clarification
that
adrian
also
mentioned,
and
I
think
it's
very
important-
it's
the
concept
of
the
consumer
or
customers.
So
I
don't
want
to
repeat
what
adrian
mentioned,
but
the
important
aspect
here
is
that
depends
on
the
use
case.
You
know
we
put
a
group
of
use
cases
in
the
framework
document
and
definition
document
that
what
are
the
use
case
of
ietf
network
depends
on
the
use
case.
This
consumer
could
be
an
orchestrator,
could
be
end
user.
I
Another
thing
that
it
was
in
the
presentation
of
daniele
was
the
he
mentioned
about
network
slice
or
sorry.
Net
forecast
slice,
and
that
is
basically
from
our
terminology,
is
a
network
slice
realization.
Any
technique
that
you
mentioned
has
some
sort
of
the
technology
specific
referring
to
the
te
or
referring
to
l2sm
or
l3sm.
I
All
those
are
values,
including
hctn
itself,
are
the
realization
techniques
they
can
well
live
with
the
model
that
we
have
our
model
sitting
at
the
top
and
all
those
realization
models
can
be
used,
and
from
that
aspect
you
mentioned
that
mdsc
and
nsc
are
the
same
level
so
from
that
as
well.
You
will
see
that,
if
consider
that
realization
versus
technology
agnostic,
the
view
is
a
bit
different.
C
Yeah
thanks
danielle
for
the
great
presentation
I
do
want
to
mention
the
the
mappings
that
you
suggested
on
one
of
the
slides.
They
are
not
for
someone
working
on
network
slicing.
They
are
not
obvious
to
come
up
with
these
mappings
and
you
know,
although
it
is,
I
totally
agree,
it's
possible
to
you
know
augment
the
vn
model
to
achieve
the
you
know,
connectivity,
matrix
and
slos,
and
realize
the
network
slice
service,
possibly
those
mappings.
C
C
M
Go
ahead.
Okay,
I
just
I
was
a
little
bit
confused
by
the
discussion,
so
I
understand
the
difference
between
customer
and
as
an
end
user
and
and
and
a
consumer,
but
I
have
not
understood
whether
this
year
model,
the
wd
via
model,
is
a
customer
service
model
used
by
the
customer,
not
by
the
consumer
of
the
neto
slice,
to
request
a
service
or
it
is
a
consumer
service
model
or
to
be
used
by
the
consumer
of
the
neto
slicing.
I
have
been
a
little
bit
lost
by
that
discussion.
L
Hi
my
comment
to
danielle
one
was
danny
in
the
in
the
rfc
8453.
We
do
split
the
mdsc
functions
across
boxes
and
we
say
that
mdsc
can
easily
be
split
at
the
service
orchestrator
and
at
the
network
orchestrator.
But
throughout
the
analysis,
I
think
you
kind
of
showed
mdsc
as
a
single
box,
and
I
was
kind
of
thinking
that
why
we
always
thought
mdsc,
not
as
a
physical
box
but
more
as
a
functional
elements
that
needs
to
do
that
and
even
when
we
map
itf
nfc.
L
D
E
I
have
a
question
actually
to
derek
and
paul
so
if,
for
example,
a
network
slice
has
several
connectivity,
mattresses,
okay,
what
would
it
make
to
the
definition
of
network
slicing
corrugator?
What
does
it
mean
in
this
case
this
one,
this
question
to
you
and
another
question
to
danielle:
how
do
you
say
that,
when
you're
using
a
particular
vm
service,
you
need
to
use
a
particular
connectivity
mattress
within
vm,
okay-
and
I
I,
as
far
as
I
remember,
it,
is
not
possible
today
to
have
more
than
one
connectivity
matters
per
gram.
J
E
L
B
B
So,
for
example,
a
layer
3
vpn
customer
is
the
person
or
organization
that
uses
the
layer,
3
vpn
and
it
may
be
an
internal
structure
within
an
operator
and
it
may
be
cascaded
hierarchically.
It
doesn't
really
matter
and
that's
why
we
moved
to
the
term
consumer
for
for
slicing
and
probably
if
we
were
rewriting
the
8309
we
would.
We
would
call
it
a
consumer
service
model
rather
than
a
customer
service
model.
B
C
C
If
the
idea
of
multiple
connectivity
matrices
is
to
allow
for
load,
balancing
or
redundancy
or
something
of
the
like,
then
I
think
it
should
not.
It
should
be
hidden
from
the
service
request.
If
that's
what
my?
What
I'm
seeing
is
you
know
what
the
underlay
can
create
multiple
lsps
to
satisfy
the
same
connection,
that's
possible,
but
it's
still
one
connection.
At
the
end
of
the
end
of
the
day,.
H
G
Consumer
or
customer
whatever
we
want
to
call
that
consumer
facing,
I
think,
while
daniel
was
here,
he
I
think
he
agreed
with
that
point.
Unfortunately,
we
don't
have
him
here
right
now
to
say
he
yes
on
that,
so
you
know,
but
I
do
think
we
in
this
group
at
least
have
agreement
on
that.
That's
that's
an
important
distinction
of
scope
and
but
we
still
clearly
have
a
number
of
topics
that
we
have
to
flush
out
on
the
list.
G
Hopefully,
this
discussion
has
helped
move
that,
along
somewhat,
we
will
take
an
action
to
we,
as
chairs,
will
take
an
action
to
look
back
on
the
discussion
and
send
out
some
summary
points
but,
and
more
importantly,
also
put
it
forward
a
statement
on
how
we
we
think
we
should
take
the
next
step
on
the
adoption
poll,
and
I
think
those
are
the
main
summary
points.
Pavan
did
they
miss
anything.
A
G
But
also
don't
wait
for
us
if
you
have
a
topic
that
you'd
like
to
continue
discussing,
for
example,
igors.
Please
send
that
to
the
list
and
try
to
get
that
discussion
also
point
out
in
the
first
half
we
did
reach,
I
think
some
notable
agreements,
at
least
in
this
forum,
on
on
adrian's
questions.
So
we
will
also
send
that
to
the
list
for
general
agreement
as
pavan
started
us
out
with
we
reach
agreement
on
the
list,
not
in
these
meetings.