►
From YouTube: IETF113-TEAS-20220323-1330
Description
TEAS meeting session at IETF113
2022/03/23 1330
https://datatracker.ietf.org/meeting/113/proceedings/
B
C
C
This
update
is,
is
very
small
and
backward
compatible
with
what
has
been
already
defined.
The
fact
that
we
need
to
create
to
add
a
new
type
def
and
in
the
new
grouping
with
two
leaves,
and
we
had
some
processed
issues
to
this
guy,
which
discussed
on
monday
on
tuesday
yesterday
with
a
networking
group,
because
we
are
a
little
bit
afraid
there
is
some
reluctance
on
the
on
the
visa
approach.
C
Reason
is
the
document
is
quite
long
and
we
just
need
to
do
a
few
changes,
some
very
minor
changes
and
that
we
in
the
a776
we
have
other
rear
modules
which
do
not
need
to
be
updated,
and
what
we
want
to
put
into
this
draft
is
very
simple
is
a
little
things
which
is
very
mature
because
it's
just
moving
things
which
are
already
funny
in
other
working
group
documents,
some
of
which
are
actually
now
in
the
working
group.
That's
called
so
we
need
to
have
a
way
to
be
fast
on
progress
in
this
document.
C
If
you
want
to
make
this
entities
available
to
a
broader
applicability
and
without
blocking
the
progress
of
the
documents
which
are
already
mature.
So
what
do
we
need?
The
technical
content
is
basically
a
new
typedef,
which
is
called
bandwidth
scientific
notation
to
represent
the
bandwidth
of
of
a
packet
link,
but
also
of
a
packet
lsp
in
a
way
that
is
readable,
not
like
floating
32,
but
is
a
scientific,
notation
numbers.
C
This
is
already
defined
in
a
draft
itft's
young
lpt
toppo.
However,
the
proposal
is
to
move
it
in
the
t
types,
because
this
type,
def
ever
broader
applicability,
is
not
only
limited
to
packety.
Topology
can
be
used,
for
example,
by
lsp
or
tunnels,
and
also
not
limited
to
packet
technology.
We
have
recently
seen
some
cases
of
nonpacket
technology
that
may
need
many
to
express.
C
The
band
will
require
the
bandwidth
in
in
as
a
number
in
bit
per
second,
and
they
could
benefit
from
this
type
def,
and
then
we
have
a
new
grouping
which
is
called
encoding,
the
switching
type
which
contains
the
two
leaves
for
encoding
and
switching
type.
This
grouping
was
initially
defined
in
the
pac
computation
draft
by
copying
from
the
tr
model,
idft
model
trying
to
keep
alignment
between
the
two
models.
C
However,
we
discovered
that
quickly
we
went
out
of
sync,
so
we
agreed
to
move
this
grouping
in
the
t
in
the
itf
young
te
import
it
in
the
in
the
computation.
Then
we
guarantee
the
alignment
between
the
two
models,
but
again
this
grouping
may
have
a
bigger
applicability
than
just
an
empire
computation,
so
moving
it
to
t
ties.
We
will
make
it
available
to
a
broader
applications
and
make
sure
that
everybody
has
a
common
approach
to
configure
encoding
a
switching
type
in
younger.
C
So
we
need
just
this
one,
which
is
quite
a
tiny
update.
The
process
that
we
propose
is
therefore
not
to
go
with
another
c8776b,
but
to
have
this
document
updating
the
rsc8776
with
a
new
version
of
the
80
types.
Only
so
the
theta
packet
types
in
the
rsc
8776
will
be
remain
unchanged
and
will
still
be
valid
because
s76
is
not
obsoleted
and
since
the
changes
are
quite
small
we
can
have.
C
We
can
expect
to
have
a
fast
standardization
to
make
not
to
delay
the
work
on
layers
into
a
topology
on
itft
and
rtft
computation.
The
la
the
the
last
two
are,
the
dt
is
already
in
the
in
working
room.
Quality
computation
is
ready
for
working
group
last
call,
so
we
will
not
like
to
to
delay
too
much
if,
by
moving
the
common
part
on
this
rafter,
we
discussed
the
approach
from
the
process
point
of
view
and
that
more
gives
the
feedback
that
updating
the
rsc
is
a
viable
option.
C
So
even
if
this
type
definite
grouping
are
coming
from
natural
working
group
documents,
please
review
and
give
us
any
comments
and
feedbacks,
and
if
the
proposed
approach
is
accepted,
we
think
the
document
is
ready
for
working
group
adoption.
Hopefully
soon
we
will
keep
updating
the
draft
based
on
the
comments
from
the
working
group
and
we
can
align
the
working
groups,
ideas
that
depends
on
this
document.
C
According
to
the
decision
to
move
forward
on
this
direction
and
either
it
would
be
great
if
you
can
go
last
call
together
with
the
first
abandoned
working
group
id
not
to
give
too
much
delay
on
the
processor,
and
that's
that's
all
about
the
content
of
this
draft.
Thank
you.
Thank
you.
Any
comment
or
question.
B
B
So
that's
option
one
option
two
is
do
a
a
document
that
contains
only
the
change
and
up
as
an
update
to
the
existing
document.
So
no
bis,
just
an
update,
and
that
was
proposed
because
I,
the
way
you
presented
it
is
is
that
of
the
modules
that
are
in
the
base
document.
You're
only
updating
one,
not
the
others,
and
so
the
update
approach
seemed
to
be
a
better
match.
B
E
F
F
Today
I
will
not
dig
deep
into
the
solution
we
presented
that
earlier.
I
will
give
a
current
status
of
where
the
document
stands
and
then
a
talk
about
the
next
steps
that
we
have.
If
you
can,
should
I
click
for
forwarding,
or
maybe
you
someone
can
go
forward
to
the
next
slide.
Please
you
have
it
at
the
bottom
of
your
screen.
F
F
F
We
have
received
detailed
review
comments
and
review
as
well
from
the
working
group
members,
multiple
working
group
members-
and
there
were
some
clarification
questions
raised
on
the
email
list,
notably.
I
would
like
to
thank
adrian
for
his
thorough
review,
as
well
as
his
review
comments,
med,
abeau,
kenichi,
zebu
and
roof.
There
were
some
comments
that
we
tried
to
address
on
the
list
and
there
are
still
some
comments
open
and
we're
planning
to
address
them
document
them
in
the
next
revision
and
we'll
talk
about
the
plan
to
progress
further.
F
F
Some
of
them
are
related
to
references
of
individual
solutions
that
are
driven
in
other
working
groups,
so
those
we
will
leave
them
out
of
this
document.
For
now-
and
you
know
maybe
the
other-
the
solutions
will
be
referencing,
the
the
this,
this
solution
document
and
we
will
add
a
new
section
to
track
all
open
issues
that
were
raised
on
the
email
during
the
working
group
adoption.
So
these
issues
will
need
to
be
addressed
before
working
group
last
call.
We
will
change
the
status
of
the
document
informational.
F
We
got
this
feedback
from
from
the
poll
and
for
now
you
know
we'll
go
with
the
working
group
consensus
on
that
and
that
and
depending
on
how
the
document
progresses,
we
will
revisit
once
the
revision09
is
published.
We
will
notify
the
working
group
of
its
existence
and
ask
them
or
solicit
for
further
feedback.
If
there
are
no
concerns
phrased,
the
guidance
is
to
republish
from
the
working
group.
Chair
is
to
republish
the
document
as
a
zero
zero
worker
group
document.
F
G
G
G
G
So
this
is
the
description
about.
How
do
we
do
this?
The
idea
is
that
we
group
several
connectivity
constructs
together
and
once
we
group
them
together
for
the
replication
group,
any
traffic
to
send
to
one
of
this
group
will
be
replicated
to
other
constructs.
This
way
will
easily
make
the
p2
and
p2p
construct
into
a
p2mp.
G
G
G
G
G
G
So
then
the
eighth
way
is
already
supported.
We
don't
need
to
measure
here
so
with
this
way,
then
we'll
be
able
to
handle
every
types
required
by
the
networks.
Writing
document
this.
This
augmentation
is
only
for
this
model
for
now,
but
we
propose
this
as
a
generic
method
which
can
be
applied
to
other
models.
If
the
working
group
agrees
to
do
that,
that's
about
it
and
yeah
yeah
this
document
of
it
other
things
will
be
ready
for
the
talk
adoption.
H
G
G
G
I
I
G
F
F
F
F
F
F
G
K
Drew
can
I
keep
it
short.
Like
query
is
basically
I
understand
that
you
in
your
document,
you
also
mentioned
type
2
vn
model,
where
you
want
your
service
model
to
have
a
more
control,
but
the
approach
that
we
took
in
the
vn
model
was
adding
a
reference
to
the
topology
model,
not
augmenting
the
topology
model.
So
I
was
thinking
that,
instead
of
creating
an
itf
network
slice
model,
in
fact,
you're
using
the
same
name
as
the
current
npi
model,
so
it's
kind
of
very
confusing.
K
But
the
main
point
is
that
having
a
completely
independent
model
is
that
the
right
approach,
or
if
you
have
these
requirements,
can
it
be
that
itf
network
slice
nvi
model
is
augmented
with
a
reference
to
the
t,
topology
model
and
the
rest
of
the
things
that
you
are
doing
to
connectivity
matrix
anyway
makes
sense.
You
also
say
that
you
want
to
generalize
that.
So,
if
you
want
to
generalize
that,
isn't
that
a
better
modeling
approach
than
what
you
have
currently
in
the
document.
G
K
G
K
G
K
Actually,
should
I
I
was
thinking
because
we
have
the
t
service
mapping
and
in
the
t
service
mapping
graph,
we
decided
that
we
don't
want
to
add
idf
network
slice.
It's
going
to
be
confusing.
In
fact
I
was
proposing.
I
have
a
document
on
this
where
we
say
that
itf
network
slide
is
getting
mapped
to
t
construct
in
the
same
way
how
we
did
for
l3,
sm
and
l2
sm,
etc.
G
L
H
A
A
So
the
rationale
behind
that
is
that
we
I
mean
from
the
operator
perspective.
Once
we
have
the
the
capabilities
of
instantiating,
these
networks
license.
They
will
be
to
use
not
only
for
just
one
city
set
of
use
cases,
but
for
whatever
use
cases
that
we
could
have
even
services
that
we
can
provide
today
without
the
notion
of
a
slice,
so
at
the
end,
to
take
advantage
of
the
slice,
was
a
concept
for
er
associating
a
white
kind
of
services.
A
So
the
the
purpose
of
the
draft
is
to
cover
the
gap,
analysis
in
terms
of
use
cases
identifying,
slos
or
sles
attributes
and
methods
that
could
be
needed
for
for
requesting
the
slices
to
the
towards
the
idea,
nevertheless
controller,
so
the
draft
has
been
already
presented
in
in
previous
idf.
So
this
is
just
an
update
on
the
progress.
A
So
the
use
cases
documented
so
far
we
have
by
now
we
documented
5g
services.
We
consider
both
public
and
private
networks,
also
nda
based
services,
so
chaining
of
network
functions
that
could
be
deployed
in
different
data,
centers
also,
network
sharing,
sd1
and
the
radio
functionality
splits
that
are
being
specified
in
bodies
like
oran.
A
So
the
updates
in
in
this
version-
so
essentially
we
were
through
some
fixes
in
electrical
terms,
mainly
the
figures,
and
so
we
also
added
the
content
related
to
the
private
5g
networks.
This
is
a
special
case
that
could
bring
up
some
new.
They
need,
let's
see,
defying
new
requirements,
for
instance
the
fact
of
probably
having
multi-homing
or
the
customization
of
the
abstinence
and
downstream
rates,
and
also
the
fact
that
this
use
case
can
imply
that
the
service
provider
uses
network
slices
provided
even
by
other
companies
more.
A
That
could
be
the
verticals
in
this
case,
so
we
added
also
a
section
summarizing
the
attributes
and
procedures,
so
a
kind
of
summary
or
at
the
very
end
part
of
the
document,
so
the
the
objective
that
would
need
to
identify
comprehensive,
slos,
the
sles
and
the
procedures
that
could
allow
to
support
whatever
use
case
so
having
a
solution
that
could
be
useful
for,
for
whatever
purpose
the
weather
is
possible
right.
So
that
section
is
yet
a
work
in
progress
or
need
much
more
work
for
sure,
but
well
the
idea
would
be
at
the
end.
A
So
as
next
steps,
the
idea
is
to
complete
the
the
work
in
progress.
We
are
considering
to
add
a
an
an
additional
use
case
about
data
center
interconnection
and
the
level
8
elaborates
or
a
bit
more,
the
summary
section
so
essentially
to
complete.
We
will
also
scan
for
additional
relevant
use
cases
if
any.
So
we
invite
people
here
if
there
is
something
that
could
be
offenders
to
be
documented,
to
have
to
send
to
share
with
us
and
to
send
to
the
mailing
list,
and
so
so
invite
contributions
for
sure.
A
The
idea
would
be
for
today
to
collect
feedback
and
comments
from
the
working
group
and
we
are
expecting
to
prepare
a
new
version
for
the
next
meeting,
including
the
data
center
case.
So
we,
the
authors,
consider
that
the
draft
is
ready
to
be
adopted.
So
we
are.
We
would
like
to
ask
for
working
group
adoption.
A
We
think
that
is
a
valuable
document
for
having
a
clear
view
on
the
needs
that
could
be
required
to
be
supported
by
the
itf
negotiation
controller
and
also,
we
think
that
the
recent
discussion
in
the
mailing
list
make
this
evident
the
need
of
having
some
document
collecting
the
use
cases
and
the
needs
that
could
be
expected
to
to
to
feed.
Let's
say
the
idea,
nevertheless,
controller
for
instantiating
the
slice
services.
So
with
this,
I
think
that
it's
all
from
my
side.
Thank
you.
K
A
Yes,
well,
we
think,
yes
for
the
framework,
probably
to
to
define
potential
methods
or
procedures
that
could
be
required
for,
for
instance,
in
in
terms
of
capabilities
that
could
be
required
to
be
supported
once
we
instantiate
the
slices,
for
instance,
retrieving
information
from
the
slices,
or
there
is
a
case
that
is
not
coming
now.
To
my
mind,
give
me
just
one
second
to
think
about
that
this
is
related
to
modification
of
slices.
I
can't
cannot
remember
right
now.
A
E
E
F
A
Well,
we
are
approaching
the
nfb
use
case
now
from
the
perspective
of
connectivity.
There
is
some
work
in
hc
nfb
detailing
that,
in
fact,
we
we
talked
earlier
about
deletions
for
nab,
so
I
I
related
to
actn.
So
all
that
work
is
related
to
respect
the
connectivity
and
and
what
could
be
the
the
mechanisms
expected
for
net
cnb
for
control
the
connectivity
in
terms
of
requesting
capacity
and
so
on
so
far
what
you
are
commenting
about
the
possibility
of
also
including
functions
if
I
don't
interpret
wrong
the
question.
A
B
M
M
Okay,
first
of
all,
a
brief
recap
about
the
background.
The
vpn
plus
and
the
network
slicing,
the
vpn
plus
framework
is
described
in
this
draft
atf.
Enhanced
vpn
and
one
of
the
typical
use
cases
is
to
deliver
the
idf
network
slide
services
and
in
the
itf
network,
slides
draft.
The
high
level
realization
architecture
of
item
number
slice
is
described
and
mentioned
the
mapping
of
the
nether
slice
connectivity
constructs
to
another
label
nrps,
as
shown
in
the
figure
on
the
right
side.
M
So
here
are
the
updates
after
the
last
item
meeting.
Basically,
the
main
major
change
is
that
the
name
of
the
draft
is
changed
from
the
vtn
scalability
to
the
nrp
scalability.
This
is
based
on
the
terminology
discussion
in
the
working
group
and
also
the
discussion
between
the
draft
authors.
We
think
that
the
concept
of
an
rp
and
the
vtn
is
really
similar,
but
with
different
context,
so
it
is
better
to
align
the
terminology
in
this
document
with
the
other.
M
M
M
F
Hi
go
ahead.
Thanks
g
for
the
great
presentation
there
was
the
second
slide.
There
was
a
diagram
that
you
showed,
if
you
don't
mind,
flipping
back
yeah,
that's
it
so
it
drew
my
attention
this
diagram
and
thank
you
for
compiling
it.
It's
that's
great
in
here
you're,
not
mentioning
anything
about
vtn.
I
know
that
you
have.
You
had
described
the
relationship
between
vpn
and
nrp.
F
M
In
this
diagram,
I
think
we
use
nrp
instead
of
vtn
and,
as
I
mentioned,
that
the
relationship
between
the
video
and
the
nrp
is
described
in
the
vpn
plus
framework.
So
in
this
document
I
think
we
changed
both
the
draft
name
and
the
terminology
in
the
document
from
atm
to
an
rp.
I
think
that
should
be
okay,
let's
reflect
the
consensus
from
the
working
group
and
officers
yep
thanks.
B
I
think
this
is
an
interesting
document.
Also
we
go
to
get
more
discussions.
A
lot
like
the
comments
on
the
last
document,
be
good
to
get
more
discussions
and
see
if
there's
comments
or
objections
to
adoption,
I
think
we
need
a
little
more
review
before
we
do
an
actual
poll
also
on
the
discussion
of
ni
nrp
versus
vpn
plus.
I
personally
think
that
you
know
nrp
is
a
more
abstract
term
and
and
there's
different
ways
to
realize
an
nrp.
B
M
Yeah,
just
one
quick
comment:
actually
this
is,
I
think
this
is
a
another
new
draft.
We
have
presented
several
times.
This
is
just
a
new
version
based
on
the
new
terminology
and
the
draft
name,
so
the
content
has
already
been
stable
and
perhaps
we
can
consider
to
start
the
poll
on
it
unless
there's
some
significant
comments
or
concerns.
B
I'm
not
sure,
there's
a
question
there.
I
mean,
I
think,
we've
just
said
I
mean
I'll
talk
to
bevan,
see
if
he
sees
it
differently,
but
you
know
the
the
the
way
we
saw
it
at
the
start
of
the
meeting.
If
you'd
like
to
see
a
little
more
discussion
on
the
list
before
polling
or
at
least
give
opportunity
for
some
discussion.
M
H
F
F
F
There
is
the
network
resource
partition,
which
is
introduced
in
the
network
slicing
framework,
it's
a
collection
of
resources
identified
in
the
underlay
network
to
support
the
network,
slice
service
or
any
other
service
that
needs
this
logical
network
structure
with
the
required
characteristics,
and
then
we
have
the
nrp
policy.
That's
introduced
in
the
solution
draft
that
I
provided
an
update
earlier
today.
F
F
F
F
So
these
fields
genetically,
we
call
them
flow
aggregate
selector
field
and
it
it
is
provisioned
using
the
nrp
policy
as
well
and
in
the
other
two
modes
we
for
reservation
purposes.
We
we
could
rely
on
a
distributed
or
centralized
resource
reservation
manager
so
that
we
can
do
bandwidth,
aware
or
traffic
engineering.
F
F
Resource
reservation
will
manage
the
reservations
on
this
link
in
the
control
plane,
and
then
we
have
a
flow
aggregate
selector
that
can
be
carried
inside
the
packet
or
and
then
it
allows
nodes
along
the
path
to
identify
those
packets
and
then
associate
them
with
the
nrp.
The
per
hop
behavior,
which
is
the
data,
plane
policies,
qs
policies
that
are
associated
with
nrp
and
then
finally,
there
are
filters
that
can
be
invoked
so
that
we
can
compose
the
topology
that's
associated
with
the
the
network
resource
partition.
F
The
flow
aggregate
selector
we
I
did
meant
to
touch
on
this
lightly
earlier
it's
a
field
carried
in
the
packet.
It
can
take
multiple
forms
we
have
we.
The
model
allows,
is
flexible
enough
to
allow
multiple
variants,
so
the
flow
aggregate
selector
for
an
nrp
can
be
a
range
of
labels.
For
example,
it
can
be
one
label
carried
in
any
packet
or
can
be
an
ip
destination
address
or
or
it
can
be
carried
in
an
extension
header
in
ipv6.
F
F
B
It
says
you
want
to
share,
but
I've
already,
given
you
permission
and
I'm
a
little
worried
to
touch
the
screen,
because
this
is
how
we
ended
up
with
adrian
not
being
able
to
talk.
So,
if
you
don't
mind,
we'll
just
go
through
just
tell
me
next,
then
I'll
advance
for
you.
Okay,
that's
good!
I
think
adrian
was
this,
was
agent's
theory
of
how
he
you
know
ended
up
with
him
with
no
audio.
So
please
continue.
J
J
J
J
J
J
N
I
J
J
J
I
J
Yes,
this
one,
I
mean
this
nfp
is
quite
like
each
link
is
relevant
with
the
underlay
network.
It's
it's
not
the
like
abstract
link
between
sdp.
I
mean
like
that
red
point-to-point
network
slice
service
it
can
map
to
an
rp2
right,
so
it
will
traverse
two
nodes
or
it
could
be
with
protection.
They
could
be
traverse
five
nodes.
J
J
J
Each
link
has
has
its
resource
bandwidth
usage
and
it
could
has
the
perlink
delay
or
loss,
so
it
can
be
used
for
the
network
slice
controller,
to
evaluate
whether
this
nfp
instance
can
be
used
to
support
a
new
network
slide
service.
So
this
is
for
the
nfp
monitor.
We
augment
the
network
ietf
network
model
with
link
specific
status.
F
F
I
just
want
to
make
a
clarification
or
a
correction,
because
you
referenced
the
nrp
policy
data
model,
while
you
are
describing
the
bullets,
so
in
fact
the
nrp
policy
data
model
covers
all
three
bullets
that
you
have
all
the
three
bullets:
the
bandwidth
reservation,
as
well
as
the
data
plane
selector
field,
you
call
it
data
plane
id
as
well
as
the
control
plane
or
the
topology
associated
with
with
nrp.
So
that
was
a
clarification.
F
J
J
K
J
J
J
J
So
I
I
think
this
I
will
quick
go
through
this.
This
is
almost
the
last
one
and
this
nappy
modification
is
used
to
to
echo
the
framework
draft
definition
that
that
each
nrp
is
not
fixed.
It
can
be
extended
as
network
condition
change,
so
the
model
also
support
this
use
case
next,
please,
so
that's
all,
and
we
think
this
model
and
also
nlp
policy
model.
They
don't
contradict-
and
I
think
this
is
one
approach
and
rp
policies
or
the
other
approach.
B
B
A
Thank
you.
So
what
I
will
present
now
is
another
draft
with
the
idea
of
exploring
the
ways
of
instantiating
the
itf
network
slices
in
service
provider
networks
by
using
all
the
machinery
of
itf.
So
with
the
tools,
I
say
that
we
have
nowadays
right.
So
I
work
on
this
with
my
colleague,
samir
and
oscar
from
telefonica,
with
victor
lopez
and
andres
arukuy
from
siena.
A
A
A
This
is
in
terms
of
requirements
in
terms
of
the
framework
itself
for
providing
the
the
network
slide
services
and
also
to
consider
the
slice,
attributes
and
functionalities
that
could
be
expected
in
another
slice.
From
the
point
of
view
on
our
automation,
that
could
be
the
what
we
could
find
in
the
salvo
interface
we
are
considering
or
whereas
for
other
ideas
to
consider,
let's
say,
service
models
available.
A
So
lxsm
I
mean
l2sm
3sm
and
so
also
to
consider
network
models
again
larger
to
an
m
like
the
three
and
m
and
then
considering,
if
necessary,
as
well
the
t
models,
the
series
mapping
associated
to
these
te
models
and
other
models
that
could
come,
maybe
related
to
acl,
routine
policies.
And
so
on
so
far
and
from
the
point
of
view
of
architectural
framework,
we
are
looking
at
the
the
refses
that
you
can
see
there.
A
So
the
framework
for
automating
services
and
network
management,
the
framework
for
abstraction
and
control
of
the
inaugural,
so
the
act
and
framework
and
the
service
models
rfc
as
well.
So
there
are
any
potential
architecture,
architectural
options
we
are
looking
at
that
are
now
documented
in
the
draft
we
are
considering
three
of
them.
A
The
architecture
in
the
middle
is
essentially
the
canonical
architecture
that
is
being
defined
in
the
framework
documents
so
well
known
in
in
this
community
and
the
one
on
the
on
the
right,
which
consider
is
to
have
the
the
networkless
controller
as
part
of
a
network
controller
right.
So
probably
the
the
differences
are
not
so
many
on
this,
but
the
idea
would
be
to
try
to
understand
what
could
be
different
options
to
to
have
right
so
updates.
A
From
the
previous
version,
we
introduced
a
an
idea
of
mapping
of
the
or
relationship
between
the
models
that
are
described,
based
on
different
architectural
options,
so
essentially
with
a
framework
of
different
service
models.
How
we
interpret
that
could
be
the
the
mapping.
Then
we
added
a
new
section
for
service
models
that
previously
were
was
the
the
the
content
were
there,
but
not
the
section
itself.
A
Normal
interface
service
has
been
defined
today
with
one
of
the
use
one
one
of
the
cases
that
could
be
to
realize
that,
with
a
liar
free
service
model
right.
So
our
idea
is
to
keep
progressing
on
this
and
identify
gaps
and
so
on.
So
I
will
detail
a
little
bit
each
of
these
updates.
So,
regarding
the
relation
relationship
between
models,
we
took
the
the
the
idea
of
models
that
is
now
provided
in
rfc
8309,
but
essentially
we
we
have
on
on
the
right
side
the
the
oss
and
bss
models
that
could
be
applicable.
A
A
So
this
is
where
you
can
see
the
the
arrow
interconnecting
these
two,
so
we
could
expect
some
translation
from
the
network
slide
service
model
to
either
layer,
2
service
model
or
the
systems
model,
but
also
we
could
consider
another
kind
of
translation
that
could
be
from
the
itf
network
slide
service
model
towards
the
network
service
models.
Here,
probably
the
the
arrow.
How,
as
it
is
depicted,
is
a
little
bit
misleading
because
the
intention
is
not
to
reflect
a
kind
of
east-west
interface
but
also
a
kind
of
let's
say,
salvon
interface
or
a
southbound
translation.
A
Let's
say
so.
We
will
correct
this
in
the
in
the
next
version.
So
the
idea,
essentially
that
we
reflected
in
the
graph
is
that
we
could
have
this
kind
of
relationship
between
the
models
so
taking
the
the
the
parameters,
the
attributes
of
the
network
model
and
being
translated
either
to
service
model
or
to
network
model.
A
So
a
second
update
was
the
addition
of
this
section
for
a
neighborhood
slice
mapping
to
the
service
model.
Mapping
again,
the
context
was
the
con.
The
text
was
more
or
less
there,
but
was
not
clearly
reflected.
So
we
created
this
a
new
section
and
yeah,
basically
with
the
idea
of
aligning
with
the
rfc8969.
A
A
It's
an
ongoing
pro
work
in
progress,
so
probably
is
not
exact
or
not
correct
at
all,
but
our
idea
is
to
keep
continuing
these
kind
of
exercises
to
understand
what
could
be
potential
gaps
between
the
models
or
what
kind
of
parameters
could
not
be
taken
into
consideration,
because
the
let's
say
the
the
the
the
service
model
of
the
regular
model.
We
are
mapping
to
lacks
of
these
capabilities.
A
The
phone
is
in
in
this
case
in
the
larger
free
service
model.
We
see
that
there
are,
there
could
be
aspects
like
packet
packet,
error
rate
or
so
that
could
be
expressed
and
negative
is
a
level
that
cannot
be
mapped
today
at
larger
three
service
models
right.
So
this
is
the
objective
is
on
how
to
start
understanding.
What
could
be
these,
this
kind
of
gaps
that
that
could
be
could
exist.
A
This
does
not
prevent
that.
The
later
on,
the
slides
could
be
realized
in
this
case
with
liability
service
model.
Maybe
yes,
but
probably
we
could
consider
at
the
time
of
realizing
the
slides
with
some
specific
technology
to
leverage
that
technology
for
accomplishing,
for
instance,
the
packet
loss
rate
in
this
example
right.
So
this
is
the
analysis
that
is
there
by
now.
A
A
A
Our
objective
is
also
to
keep
working
on
on
detailing
the
different
implementation
options,
so
you
have
to
say
ladder
freezer
model
to
service
model
and
so
on
so
far
and
for
sure
collect
additional
operational
requirements
that
could
result
of
this
gap
analysis
without
trying
to
provide
feedback
to
the
solutions
labs
and
for
sure
we
are
open
to
collective
from
the
working
group.
If
this
is
of
interest.
Thank
you.
Oh
sorry,
just
one
one,
the
very
last
slide
with
this
additional
proposed
architecture.
So,
but
this
is
totally
working
progress.
A
This
is
not
in
the
document
just
to
to
collect
feedback
from
you
if
possible.
In
this
meeting,
we
are
considering
two
potential
architectures
additional
ones.
The
one
on
the
on
your
left
is
essentially
to
consider
the
fact
that
the
one
one
service,
as
requested
today,
could
be
later
on
realized
through
a
negative
slice,
so
somehow
having
a
service
model
on
top
and
a
negative
model
at
the
bottom
okay.
A
This
could
be
maybe
just
as
an
example
could
be
the
case
that
we
receive
a
liar
free
service
model
like
a
3bpm,
and
we
realize
that
vpn
may
be
using
an
otn
slice.
That
could
be
an
example
and
the
one
on
the
right.
Essentially,
what
considers
is
that
the
network
slice
controller
could
be
part
or
it
could
be
moved,
let's
say
to
the
oss
so
somehow
interacting
on
the
top,
with
an
existing
deployment
of
sdn
control
capabilities
in
the
network.
So
these
are
just
ideas
for
the
for
discussion
and
that's
all
from
my
side.
H
Right
hi,
pawan
piram,
the
document
does
make
for
a
good
read.
It
has
sufficient
amount
of
detail
thanks
for
that,
my
question
is
I
mean
how
does
this
relate
to
the
act
and
the
working
group
crafted
act
and
document
that
we
have
so
my
understanding
is
that
it
also
talks
about
using
the
same
set
of
data
models,
service
data
models,
network
data
models
and
others
that
we
have
currently
defined.
H
A
Well,
I
I
see
probably
acdn
is
an
example
of
how
to
realize
this
with
a
specific
architecture.
No,
probably
this
could
intend
to
be
a
little
bit
more
abstract,
so
maybe
we
could
go
with
the
actino
with
other
kind
of
of
solution
or
framework
solution.
I
guess,
but
certainly
there
are
common.
Some
commonalities,
because
I
mean
the
architectures
are
yeah.
I
mean
scpn
is
a
kind
of
realization
of
an
overall
architecture
right.
K
Yeah
one
quick
question
in
the
yang
mapping:
there
is
one
more
document
I'll
put
the
link
in
the
chat
that
document
talks
about
mapping
ipf
network
slices
to
l2
nm,
as
well
as
team
mapping,
in
the
same
way
how
we
did
the
t
service
mapping,
so
that
document
already
exists,
and
I
think
I
can
just
look
at
it
and
maybe
you
can
add
it
in
your
list
of
young
models
there.
Thank
you.
N
A
So
the
motivation
is
somehow
3dpp,
as
one
of
the
potential
use
cases
is
defining
the
concept
of
slicing
having
a
number
of
different
logical
constructs
and
trying
to
create
this
idea
of
slides
with
a
particular
qs
characteristics.
On
the
other
hand,
we
have
the
ip
all
the
idf
network
slice
stuff
that
I
will
not
comment.
So
the
objective
is
on
how
to
understand
how
both
ideas
could
match
at
the
point
of
development
that
they
have
today
in
either
3gpp
and
its.
A
So
just
for
for
understanding.
Cpp
in
the
definition
of
network
slicing
is
defining
a
number
of
constructs
right,
so
they
are
defining
all
this
idea
of
network
slice
identifiers
and
for
doing
the
the
realization
of
the
slides.
They
are
defining
different
artifacts
one
artifact
that
somehow
it
determines
what
could
be
the
interface
to
to
be
connected.
A
A
Parameters
that
we
will
comment
later
on
and
we
could
have
connection
between
ep
transfer
for
realizing
the
slice
at
3bp
level,
but
also
as
in
the
case
at
the
bottom,
we
could
have
even
components
of
3gbp
like
the
ubf
number
3.
That
does
not
support
slicing,
so
this
is
somehow
options
that
3epp
is
considering
and
he's
defining.
So
the
idea
would
be
okay.
This
is
a
certain
point.
This
is
what
3ebp
needs
and
requires
how
we
could
map
this
into
ipf
networks
license.
So,
let's
look.
A
What
eptransport
is
defining
if
the
transport
is
considering
a
number
of
parameters,
the
ip
address,
which
is
a
mandatory
parameter,
and
it's
stated
as
ipv4
or
ipv6,
then
the
logic
interface
info,
which
is
mandatory
as
well,
and
they
define
a
type
and
interface
id.
This
would
correspond
coming
back
just
one.
Second,
this
will
correspond
to
the
vlan,
2
or
vlan
1
that
you
can
see
the
ap
transport
in
the
figure.
So
we
have
the
ip
address
and
we
have
the
vlan.
A
The
billing
will
be
the
interface
type
and
the
device
id
the
the
number
of
the
billing.
Then
we
have
a
two
optional
parameters:
the
lens
hook
info
that
will
refer
to
the
english
transport
node
in
case
the
three
epp
knows
about
this
ingredient:
transport,
node
and
then
the
keyos
profile,
which
is
also
optional
and
could
be
provision
on
that
logical
interface
in
the
3dbp
and
then
the
application
reference
which
is
mandatory
and
essentially
refers
to
the
interface
to
the
interface.
A
So
a
preliminary
exercise
with
it
for
considering
these
different
parameters
was
to
create
this
kind
of
table
to
understand
what
could
be
how
we
could
play
with
these
different
parameters
in
order
to
map
it
into
a
slice.
This
is
also
working
progress-
probably
it's
not
complete
at
all,
but
it's
just
to
consider
the
different
capability
possibilities
that
we
could
have
in
order
to
yeah
to
realize
that
the
slice-
probably
this
link
a
little
bit
with
what
being
was
commented
before
about
this
multiplexing
and
how
to
consider
the
multiplexing
with
the
different
identifiers.
A
So
we
have
that
eb
transport,
and
then
we
have
somehow
two
different
concerns.
The
3dpp
concern
that
this,
what
we
saw
in
the
figure
before
with
those
slices
and
so
and
then
on
the
the
bottom
part.
We
have
the
itf
concern
and
we
need
to
perform
so
how
do
kind
of
mappings
the
mapping
from
the
ep
transport
and
all
the
three
three
epp
concerns
towards
the
itf
network
slice
and
the
ce
part,
which
we
really
the
part.
A
This
is
all
the
stuff
that
has
been
defined
in
the
framework
document.
So
so
we
could
leverage
on
that.
The
work
for
for
identifying
what
could
be
the
this
I
mean:
what
can
we
do
at
that
level?
So
the
idea
would
be
to
elaborate
more
on
how
we
could
do
how
we
could
perform
these
mappings
to
have
a
clear
idea
of
how
we
could
realize
these
lines.
Okay,
so
in
the
draft
there
is
a
a
section
for
discussion.
A
O
D
B
B
Yeah
and
you
should
you
should
have
controls,
you
should
have
controls
and
during
your
presentation,
we'd
really
like
to
hear
about.
If
you
took
the
action
from
the
last
meeting
where
we
asked
to
take
a
look
at
the
existing
framework
and
propose
text
there
rather
than
having
a
stand-alone
document,
I
don't
believe
we
saw
a
response
on
the
list.
So
it's
really
like
that
point
to
be
addressed
from
the
last
meeting.
As
you
talk,
thank
you.
Q
Q
Q
Q
Now
this
is
the
talk
about
this
scalable
itm
network
slice,
realization,
based
on
the
decoupling,
the
topology
and
the
resource
for
the
network
slicing,
and
this
draft
for
the
encapsulated
the
vpn
and
the
vtid
in
the
ipv
secretary
plan
has
been
adopted
by
the
working
group.
So
I
think
this
is
also
the
base
for
the
for
us
to
go
on
to
move
to
the
end
to
end
itr
network
slice,
realization.
This
is
this
framework
draft.
Q
Okay,
so
here
we
can
see
that
this
is
the
framework
for
the
end
to
end
so
there's
the
the
5g
and
to
end
the
network.
Slicing
they'll
use
the
iss
ai
to
identify
this,
the
network
for
for
identify
the
under
to
end
the
5g
network
slice,
and
also
this
in
the
for
the
transporter
network,
there's
the
multi
domain.
So
there's
we
also
have
this.
The
intel
domain,
ietf
network
slicing
work.
Q
So
at
the
beginning
we
use
vtune
as
the
terminology,
but
according
to
the
latest,
progress
of
the
ietf
networks
license
architecture
document.
Our
draft
is
aligned
with
this
architecture.
We
use
an
rp
as
this
is
the
terminology
that
means
the
network
resource
partition.
So
this
this
is
just
this
is
the
update.
Okay,.
Q
Okay,
so
here
this,
we
also
use
the
change.
This
terminology,
we
use
as
the
local
domain
rpid,
to
indicate
this,
the
identifier
for
the
resource
for
the
specific
network
resource
partition
and
also
we
had
this-
the
global,
this
rpid
to
represent
the
global.
This
is
the
network
resource
partition
resource.
Q
Q
Okay,
so
this
is
the
just.
This
is
the
requirements
about
this
wire,
so
this,
in
fact,
this
will
not
change
much,
but
this
is
the
this
is
refined.
This
is
the
process,
especially
that's
in
the
other
edge
of
this,
the
ietf
network
slicing
domain,
there's
a
need
to
support
map
the
5g
network,
size
id
to
the
global
rpid
and
the
domain
and
rpid,
and
also
for
the
transport
network
domain
and
the
domain
border
nodes
should
support
to
map
the
global
rpid
to
the
domain
rpid
of
the
local
domain.
Q
So
this
is
just
to
implement
the
undertool
under
mapping
between
the
5g
network
slicing
to
the
ietv
network
slicing
and
between
the
global,
this
rpid
to
the
local
domain
rpid
similar
and
for
the
management
and
the
control
plane.
It
should
be
through
the
protocol
control
protocol
extension
or
this
linear
model
to
implement
the
mapping
at
the
edge
node
for
the
for
the
transporter
edge
devices.
Q
Q
B
All
okay,
thank
you,
we're
letting
late.
We
don't
really
have
time
for
questions
or
comments.
Please
take
them
to
the
list
again.
This
is
a
super
super
short
document.
It's
what
two
or
three
pages
of
content
would
be
great
to
see.
If
you
could
figure
out,
if
there's
an
existing
document,
you
could
combine
it
with
particularly
a
working
group
document
just
send
email
the
list
proposing
content
for
the
for
an
existing
document.
M
Okay,
next
page
here
are
the
backgrounds.
I
think
the
hierarchical
network
slicing
is
briefly
mentioned
in
the
item.
Number
slice
frame
of
draft
as
below
ideologue
slides
can
be
further
sliced
into
other
natural
slices
and
recursive
composition
allows
another
slice
and
one
layer
to
be
used
by
another
layer,
slice
and
but
there's
no
details
about
how
the
hierarchical
natural
slides
can
be
realized.
M
M
The
first
one
is
about
the
resource
partitioning
in
the
forwarding
plane,
because
since
we
want
to
support
hierarchical,
slides,
the
nrp
in
underlay
are
used
to
support
one
or
multiple
slide
services
and
for
the
hierarchical
slicing
scenario,
the
forwarding
planning
resources
need
to
be
able
to
be
partitioned
in
a
hierarchical
manner
and
we
need
to
show
the
different
levels
of
an
rps
in
the
network
and
to
the
up
layer.
Planes
like
the
control,
plane
and
data
plane.
M
There's
two
options
about
how
to
modeling
the
hierarchical
nrps
at
the
link
resource
level.
The
first
one
is:
we
can
treat
the
level
one
slice
resource
partition
on
the
link
as
a
layer,
three
sub-interface
and
for
the
second
level
nrp
resource
can
can
be
treated
as
the
separate
data
channels
within
the
layers,
research
interface.
M
M
M
M
This
information
may
be
advertised
as
a
later
three
or
later
information
to
the
network,
and
this
can
have
different
functionality
and
scalability
implications
to
the
control
plane
and
as
the
number
of
the
hierarchical
network
slides
increases,
we
also
need
to
consider
the
control
plane
optimizations
to
support
the
better
scalability
in
terms
of
the
management
plan
functions
for
the
hierarchical
network.
Slicing.
B
B
D
B
It's
not
even
showing
them
as
trying
to
trying
to
speak.
So
it's
something
on
the
browser
interface.
If
you
can
hear
me
just
reload
your
browser
and
see
if
you
can
then
re-enter
and
until
then,
if
you
don't
mind,
thank
you,
you
mean
to
ask
the
trooper
to
try
again.
I
know
I
I
think
I
just
did
hopefully
hears
me,
but
that
you
could
just
start
presenting
while
we're
waiting.
M
M
M
M
Currently,
this
network
carries
the
three
major
types
of
service:
the
healthcare
education
and
the
the
enterprise
internet
service
and
they're
planning
to
introduce
more
vertical
industry
services
into
this
network.
So
for
this
new
network,
they
create
a
separate
like
vtns
or
an
rp's
with
different
natural
resources,
but
these
resources
partitioned.
M
The
technology
used
for
research
partitioning
is
based
on
virtual
sub
interfaces
with
dedicated
bandwidths
and
in
the
data
plane.
They're
using
the
srv6
assist
to
identify
different
resource
partitions
on
the
interfaces
and
the
nodes
in
the
control
plane
mechanism
used
here
is
using
as
a
policy
with
link
affinity
as
constraints
for
the
as
a
policy
pass
computation.
M
Okay,
this
one
is
another
use
case
of
the
network
slicing
for
the
fixed
mobile
convergence
network.
Basically,
this
is
a
operator
using
network
slicing
to
provide
a
separate
separation
and
the
resource
isolation
between
the
mobile
service,
enterprise,
proving
line
service
and
the
broadband
in
network
internet
service
in
the
same
network
and
in
this
case
they're
using
srm
peris
as
a
data
playing
mechanism
and
resource
partitioning,
is
based
on
flexible
internet
and
the
virtual
sub-interface,
with
dedicated
bandwidth
for
the
control
plane.
M
It's
also
used
as
a
policy
with
the
link
affinity
as
a
constraint
for
this
operator.
Consider
that
the
automatic
network
slice
management
operation
is
an
important
feature
to
reduce
the
operational
operational
overhead
and
complexity
introduced
by
network
slicing.
So
this
is
a
very
useful
tool
and
they
want
more
improvement
with
this
automation
capability
and
the
second
thing,
because
they
consider
for
the
next
step,
is
since
the
number
of
the
next
slides
will
increase
in
this
network,
they're
considered
to
even
evolve
towards
a
high
speed,
scalability,
never
slicing
solution
in
the
future.