►
From YouTube: IETF110-TEAS-20210309-1600
Description
TEAS meeting session at IETF110
2021/03/09 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
Hello,
I
think
it's
time
welcome
to
the
tease
working
group
session
in
ietf110.
My
name
is
pawan
bhiram
and
I
will
be
co-chairing
this
session
along
with
lou
burger
matt
hartley
is
our
working
group
secretary.
A
A
A
A
A
You
don't
need
any
explicit
blue
sheet
signing
to
be
done
in
these
online
meetings.
We
will
be
using
kodi
md
for
minute,
taking
a
link
for
that
was
pasted
in
the
chat.
A
A
As
you
can
see,
we
don't
have
any
time
scheduled
at
all
for
the
working
group
draft
updates
on
the
agenda.
We
sent
out
a
link
to
a
slide
deck
that
has
the
collated
status
reports
please
to
go
through
them
and
use
the
mailing
list
to
ask
questions
or
send
in
your
comments
regarding
the
status
of
those
documents.
A
As
always,
we
have
tried
to
give
preference
to
the
working
working
group
graphs
and
the
drafts
that
have
had
some
discussion
time
on
the
list
while
putting
this
agenda
together.
We
have
about
20
minutes
on
the
agenda
today
to
discuss
the
ietf
network,
slice
definitions
and,
I
believe,
there's
a
change
in
the
presenter
reza
would
be
presenting
this
now
next
slide.
A
Please
do
use
the
mailing
list
as
much
as
possible.
Please
be
aware
that
this
is
where
the
working
group
consensus
is
actually
determined.
A
We
don't
know
how
long
we'll
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
on
the
documents
working
group
members
can
always
request
for
an
online
interim
to
be
scheduled
if
there
is
sufficient
interest
to
cover
a
specific
topic
also
do
note
that
we
already
have
several
working
participants
making
use
of
the
working
group
of
webex
to
hold
a
regular
informal
working
meetings.
A
A
There
are
two
mandatory
steps
before
accepting
a
document
into
the
working
group
and
before
taking
it
to
the
last
call,
we
do
mandate
all
authors
and
contributors
of
the
document
to
explicitly
come
out
and
state
if
they
are
aware
of
an
ipr
that
applies
to
the
document.
In
addition
to
these
two
required
steps,
we
are
now
introducing
an
another
step
in
the
process.
If
any
new
author
or
contributor
is
added
to
a
working
group
adopted
document,
we
do
request
them
to
send
out
an
ipr
statement
to
the
list.
A
A
A
We
would
like
to
acknowledge
all
the
hard
work
that
went
in
into
bringing
these
documents
into
this
particular
stage,
and
we
would
like
to
thank
everyone
involved
for
their
efforts.
There
is
still
a
fair
bit
of
work
to
be
done
before
we
can
proceed
towards
publication
with
this
work,
and
we
do
look
forward
to
more
fruitful
discussions
in
the
coming
weeks
and
months
that
will
help
us
get
there
next
slide.
A
We
do
have
two
young
documents
that
are
not
being
presented
today,
but
they're
ready
for
working
up
last
call
as
per
the
authors.
These
are
the
young,
rsvp
and
young
tea
documents.
Please
do
review
them
in
anticipation
of
the
last
call.
There
is
also
this
pending
question.
Regarding
the
pcc
use
cases
document
we
did
pose
the
same
question
in
the
last
meeting.
A
We
asked
if
we
should
progress
the
document
to
lc.
The
authors
left
it
to
us
and
there
was
no
strong
opinion
expressed
one
way
or
the
other
regarding
this
by
anyone
in
the
working
group.
The
chairs
are
leaning
towards
taking
it
to
lc
in
the
next
few
weeks.
So
if
you
have
any
opinion
on
this
yeah,
please
do
state
it
now.
A
B
Go
ahead
through
hi,
probably
I
would
also
suggest.
Maybe
we
should
talk
to
the
new
ad
and
see
if
the
new
isg
has
like
you
know.
The
main
issue
earlier
was
whether
the
use
case
document
should
be
living
documents
or
whether
they
should
be
published
in
rfcs,
and
maybe
before
we
proceed.
It
would
be
good
to
maybe
have
a
quick
discussion
with
our
ad
as
well.
What
does
the
chairs
think
about
that.
A
Yeah
we
yeah,
we
will
discuss
this
and
take
the
necessary
steps.
If
there
is
any
opposition
going
forward
on
taking
to
the
last
call,
we
will
figure
that
out
during
the
lc
process.
B
Yeah
as
someone
who's
holding
the
pen,
there
are
a
few
sections
which
are
empty.
So
if
we
proceed
to
working
group,
lc
just
give
me
a
heads
up-
and
I
will
finish
up
on
that
as
well.
B
A
Like
drew
mentioned,
we
do
have
a
change
in
our
80..
John
scudder
will
be
officially
taking
over
from
deborah
as
our
ad
tomorrow
lou,
and
I
would
like
to
take
this
opportunity
to
thank
deborah
for
all
the
great
work
that
he
has
done
as
an
ad,
and
we
would
like
to
wish
her
the
very
best
with
a
new
role
with
the
iab
we'd,
also
like
to
welcome
john
to
the
working
group.
We
look
forward
to
working
with
you,
john,
so
that
brings
us
to
the
end
of
this
deck.
B
Okay,
hi
everyone
I'll
quickly
go
over
update
of
couple
of
these
yang
models.
Next
slide,
a
quick
overview
of
or
what
all
the
model
updates
that
I
will
be
covering.
We
have
a
v
and
yang
model.
We
have
a
telemetry
model
that
augments
the
itfte
and
itf
vn,
and
then
we
have
a
service
mapping
models
which
has
a
common
types
and
various
augmentations
to
the
service
models
and
the
network
models.
B
So
let's
go
over
the
update
of
all
these
model
in
quick
fashion
next
slide,
and
maybe
you
can
skip
to
the
next
one
as
well.
Yes,
so
a
quick
overview.
This
is
the
yang
model
for
vn
operation.
It
is
the
customer
view
of
vn,
it
reuses
the
t,
topology
and
t
tunnel,
as
in
like
vn
topologies,
build
over
the
single
node,
abstract
topology
model,
and
it
uses
the
connectivity
matrix
for
description
of
how
the
vm
connectivity
and
vn
member
connectivity
is
done.
So
this
is
our
at
a
very
high
level.
B
What
is
the
overview
of
this
v
and
yang
model,
so
next
slide
would
show
what
all
updates
that
we
have
made.
We
have
got
the
yang
doctor
review.
So
thank
you
for
that.
The
main
comment
was
the
handling
of
vn
compute,
our
pc
needed
to
be
described
in
a
better
fashion,
and
we
have
done
that.
We
have
added
error
handling
for
the
same
as
well.
We
got
comments
that
we
were
redefining
a
lot
of
statuses,
so
we
have
gone
back
and
used
the
the
t
common
types
wherever
we
could.
B
So
those
were
the
comments
which
we
have
handled
from
andy
and
there
were
some
minor
comments
as
well,
which
we
are
very
thankful
for
for
the
young
dictator
review.
We
got
comments
from
tom
petch
as
well,
which
were
handled
in
the
last
itf
109.
We
got
a
comment
related
to
vn
compute
rpc.
B
There
was
a
pending
item
there,
which
was
describe
this
via
figures,
so
we
have
done
that,
so
that
should
be
very
easy
for
anybody
to
read
and
understand
why
this
change
was
made.
So
these
were
all
the
recent
changes.
We
still
have
some
open
issues.
So
that's
next
slide
in
the
open
issue.
The
main
issue
that
is
pending
is
naming
the
our
earlier
name
is
what
you
see
up
on
the
first
point,
which
was
ap
access.
B
Point
list,
slash
access,
point
id,
we
shortened
it
a
little
bit
made
it
ap,
ap
id,
but
then
slash
ap,
slash
ap
is
something
that
is
not
preferred.
So
we
were
thinking
either
we
go
by
aps
as
in
apps
or
maybe
extend
access
point
slash,
ap,
slash
apid.
B
There
is,
like
you
know,
mix
of
usage
of
both
that
we
saw
in
other
published
documents,
and
this
is
something
that
we
have
to
handle
at
ap
level,
as
well
as
at
the
vm
level.
So
if
there
are
some
good
guidance
from
folks,
please
suggest
what
would
be
the
best
naming
that
we
could
settle
on.
B
B
So
we
were
thinking
that
maybe
we
can
just
describe
that
in
the
yank
text,
that
these
some
values
are
not
applicable
and
they
should
be
considered
as
unknown
as
one
way
forward,
or
we
need
to
redefine
the
common
status
just
for
the
use
case
inside
v
and
compute.
So
these
are
the
two
open
issues
that
are
pending.
So
if
anybody
has
any
feedback
on
that,
please
send
us
either
on
email
or
right
now,
and
then
I
also
have
an
open
discussion
point
which
is
in
the
next
slide.
B
This
discussion
point
is
mainly
about
how
do
we
handle
vn
when
our
vm
members
are
realized
by
sr
paths
or
sr
policy,
as
I
was
mentioning
in
my
overview
that
we
reuse
t
topology
and
we
rely
on
the
connectivity
matrix
connectivity
matrix,
but
when
the
original
t
topology
was
developed,
our
thinking
was
that
this
could
be
the
underlay
could
be
rsppt
parts
or
it
could
be
sr
policy
or
srt
paths
as
well.
That
doesn't
seems
to
be
true
anymore.
B
So
in
this
scenario,
what
is
the
best
way
to
map
vn
members
to
sr
policy,
and
this
is
not
just
related
to
vm,
but
I
would
think
that
this
is
the
bigger
question
that
we
should
handle
with
respect
to
the
itfte
yang
model.
As
in
what
will
be
the
relationship
between
these
models
and
the
sr
policy
is
not
very
clear.
We
have
an
sr
topology,
but
we
are
not
sure
whether
that
can
play
any
role.
In
fact,
today,
on
agenda,
we
have
t
profile.
B
Can
that
play
a
role,
so
I
was
hoping
that
we
could,
like
you
know,
use
this
way
to
trigger
some
discussion.
I
can,
of
course,
take
this
to
the
list
as
well
and
try
to
get
more
feedback
on
this,
but
I
wanted
to
know
whether
these
are
the
right
set
of
questions
with
respect
to
discussing
the
underlay
of
sr
policy
with
respect
to
vm.
Before
I
continue.
If
there
is
any
questions
on
this
like,
maybe
we
can
spend
a
few
minutes
on
that
and
then
we
can
proceed.
C
Yeah
this
is
starting
with
juniper.
There
is
another
model,
the
roof
about
for
realizing
sr
policies,
and
there
is
a
separate
model
for
te
tunnels.
Originally,
we
had
thought
that
tunnels
can
be
sr.
C
You
could
you
could,
you
know,
could
support
tunnel
sr
paths
with
with
tunnels,
but
then
spring
working
group
decided
that
the
sr
policy
construct
is
it's
not
an
analogous
to
a
tunnel?
Is
that
what?
Why
is?
What's
triggering
your
question
here?
The
underlay
path,
discussion,
yeah,
so.
B
Yeah
my
requirement
was
that
when
we
started
with
bn
yang
model,
we
decided
that
we
would
reuse
t
tunnel
and
t
topology
as
much
as
we
could.
But
now
that
has
led
us
to
not
been
able
to
map
to
sr
policy
and
that's
a
big
issue.
So
if
the
conclusion
is
that
maybe
we
need
to
have
some
case
statement
up
in
yang
model
and
whether
in
some
cases
we
map
to
t
topology
and
and
in
some
cases
we
map
to
sr
policy.
B
C
Exactly
I
I
agree
with
you
it's
worth
discussing
within
the
working
group.
We
initially
we
had
started
to
model
the
sr
path,
which
is
a
color
color
aware
tunnel
in
our
t
tunnel
model,
but
then
we
backed
out
because
of
the
interest
in
spring.
Maybe
we
should
resurrect
the
discussion.
I
agree.
B
When
we
analyze
the
sr
policy
yang
model,
the
main
issue
that
we
see
is
like
it
is
missing
a
lot
of
the
constraints.
Information
that
we
currently
have
in
in
the
t
tunnel
model
so
what's
happening
is
that
from
from
the
vn
point
of
view
or
from
the
northbound
interface
point
of
view,
it
should
not
really
matter
whether
the
underlays,
rsppte
or
underlay
is
sr.
The
constraints
part
should
be
as
similar
as
possible.
B
So
in
some
ways
I
think,
like
you
know
what
italo
did
for
topology
profile,
do
we
need
to
do
something
for
tunnel
profile
as
well?
Like
you
know,
this
is
quite
confusing,
so
we
need
to,
like
you
know,
as
a
working
group,
give
a
very
clear
way
forward
here.
D
No
just
just
to
add
that
the
currently
there's
our
policy
model
is
only
a
device
model,
so
it's
it
augments
the
itf
routing
model,
okay,
so
it's
not
applicable
for
for
a
north
bound
and
that
the
problem
is
is
similar
for
the
for
the
service
mapping
case.
You
know
there
is
another
draft
of
the
service
mapping
to
attach
tunnels
to
or
traffic
engineering,
tunnels
to
services,
layer,
3
or
layer
2,
and
we
faced
a
similar
problem.
There.
A
Okay,
so
I
think
it's
clear
that
the
sub
policy
data
model
needs
to
start
using
some
of
the
tea
groupings
and
contains
that
we
have
developed
in
this
working
group.
I
think
that's
an
action
item
on
the
essa
policy
young
document
author's
point,
but
for
drew
for
your
model
for
the
act
and
vn
yang.
I
think
there
are
two
things
that
you
probably
need
to
worry
about.
One
is
the
underlay
topology
and
then
the
underlay
parts
right,
the
underlay
topology.
A
You
can
directly
reference
the
srt
topology
model
that
we
have
defined
in
this
working
group.
I
I
that
should
work
seamlessly.
The
problem
is,
I
guess,
with
respect
to
the
underlay
parts.
The
way
it's
defined
in
the
t
topology
model
is
it
uses
a
generic
te
path
construct
and
that
doesn't
necessarily
align
to
this
notion
of
nasa
path,
but
yeah
do
take
it
to
the
list.
Maybe
this
is
something
that
needs
to
be
resolved.
B
Yeah,
thank
you
and
let
me
just
quickly
cover
up
based
on
time.
Maybe
I
think,
let's
just
directly
jump
to
the
service
mapping
and
I
can
skip
the
the
kpi,
because
the
update
is
very
small
there.
Okay,
so
this
is
this.
This
is
the
service
mapping
yank,
as
was
earlier
mentioning
it
maps
the
services
with
the
underlay
resources,
which
could
be
t
topology,
t
tunnel
or
vn
model
next
slide.
B
So
the
main
change
that
we
did
was
we
got
a
requirement
from
kenichi
which
was
discussed
on
the
list,
whether
we
should
allow
the
l3,
s7,
l2,
sm,
site
and
site
network
access
mapping,
which
is
per
qs
profile
level
to
vnab
vnap,
and
this
has
been
done.
What
is
still
missing
is
we
need
to
add
a
clear
description
for
this
use
case
and
that
I'm
discussing
with
kenichi
and
we'll
update
in
the
next
version.
B
Some
other
changes
that
we
made
was
also
to
allow
t
mapping
templates,
which
was
earlier
put
inside
a
choice
statement.
But
since
we
thought
that
the
mapping
template
something
that
can
be
lived
on
and
it
is
independent
of
the
other
mapping
types
and
we
have
moved
it
outside
of
the
choice,
we
are
added
one
more
generic
container
for
policy
requirements
so
that
they
can
all
be
grouped
together.
Next
slide.
B
We
also
added
some
examples
on
how
the
t
mapping
template
could
be
used.
So
in
the
first
example,
we
are
basically
saying
that
the
requirement
is
to
optimize
path,
metric
delay
average.
In
the
second
requirement.
We
are
basically
saying
that
you
have
two
constraints:
one
is
bandwidth
and
another
is
another,
is
based
on
hop
metric.
Similarly,
more
examples
have
been
added
for
ease
of
understanding
of
our
models.
Can
we
directly
go
to
the
last
slide?
B
Then
hello,
since
I'm
out
of
time,
so
we
also
had
some
further
discussions
that
were
happening
related
to
traffic,
that
how
do
we
put
a
particular
map
traffic
to
the
parts?
This
is,
of
course,
not
part
of
the
t
service
mapping,
but
this
is
again
an
open
question
to
the
working
group
that,
where
should
we
model
this?
B
There
are
also
requirements
with
respect
to
calendaring
and
scheduling,
t
resources
which
are
currently
not
modeled,
and
we
are
not
sure
because
the
requirements
somehow
got
came
to
us,
but
we
were
not
sure
whether
our
young
model
is
the
best
way,
but
we
wanted
to
trigger
some
discussion
on
where
to
model
these
in
future,
and
that's
it.
I'm
done
thank
you.
B
A
Thanks
drew
elin.
E
E
E
The
this
job
is
actually
about
describes
how
the
gmp
control
system
can
interact
with
the
centralized
control
system,
but
in
different
scenarios,
for
example,
multi-domain
multi-layer
or
recovery
scenarios
and
the
main
changes
of
this
zero
five
version
is
that
we
we
added
a
description
about
the
sp
recovery
in
the
jmps
and
centralized
controller
system
in
the
working
scenario
and
next
page.
Please.
E
So
this
slides
shows
shows
a
brief
introduction
of
the
idea
of
this
draft.
So
we
know
we
have
the
gmps
control
system
and
in
each
domain-
and
we
also,
we
may
also
have
other
domains
have
which
are
running
different
different
protocols
than
umps
and
as
you
and
on
on
top
of
them,
we
also
introduced
the
act,
the
centralized
conjunction,
such
as
the
actin
architecture
and
the
centralized
control
system
and
the
distributed
gms
consistent.
They
are
not
competing
to
each
other,
but
they
can
work
together
to
make
better
control
of
the
network.
E
So
what
we
added
in
this
new
version
is
that
we
and
we
had-
we
are
actually
analyzed
on
how
the
sp
is
recovered
in
the
in
this
gps
and
controller
interworking
scenario.
So
actually
there
are
three
scenarios:
the
span,
protection,
sp
protection
and
speed
restoration.
E
So
for
spend
protection,
the
first
one
is
actually
a
kind
of
a
link
level
protection.
So
we
believe
there
are
no
new
extension
needed
for
in
these
scenarios
and
in
second
one,
the
sp
protection.
We
think
that
the
centralized
controller
can
help
on
the
destroyed
the
centralized
way
of
past
computation.
For
the
joint
past
past
computation
and
in
the
switchover
stage,
we
can
still
use
the
distributed
way
to
do
the
protection
switch
over,
because
it
is
a
much
faster
reaction
in
the
distributed
way
and
for
the
airspeed
restoration.
E
There
are
two
kind
of
method:
one
is
the
pre
preplanned
as
period
restoration
and
the
other
one
is
the
full
spirit
routine.
So
for
the
pre
plan,
sp
reloading,
similar
to
the
sp
protection.
At
the
sense,
the
centralized
controller
can
help
on
the
central's
pass
computation
and
considering,
with
the
result,
sharing
on
the
protecting
our
space,
because
it
has
the
global
view
of
the
network
and
for
the
full
speed
reloading.
E
The
centralized
controller
can
help
on
the
pre
compute
of
the
reloading
path
installed
in
the
controller
or
in
the
source
node
of
the
of
the
sp,
and
once
the
the
network
change
we,
the
controller,
can
trigger
the
refreshment
of
the
pre-computing
restoration
path
to
make
the
better
use
of
the
resources.
E
So,
to
sum
up,
we
think
that
centralized
consortium
can
take
the
advantage
of
centralized
past
computation
and
the
distributed
control
plane
can
help
to
make
a
faster
reaction
to
the
next
event,
for
example
the
switch
over
etc.
E
That's
the
main
idea
next
page,
please,
we
think
we
have
finished
most
of
the
work
of
this
draft.
So
we
kindly
asked
the
expert
in
the
tease
to
help
us
to
review
on
this
draft
and
feedback
to
us
by,
for
example,
the
email,
a
mailing
list
and
before
we
add
before
we
ask
him
for
wj
last
call,
so
that's
all
for
the
slides.
Thank
you.
F
Comments
one
thing
I
noticed
in
reading
the
document:
is
you
don't
cover
fr
and
that's
probably
something
fast
reroute.
You
probably
want
to
add
that.
I
Hello:
everyone,
my
name,
is
reza
the
raqqa
from
nokia.
On
behalf
of
my
co-authorship
and
success,
I'm
going
to
present
the
itf
network
spice
draft
next,
please.
I
If
there
is
any
question,
it
would
be
great
if
you
can
hold
on
to
your
question.
We
have
at
the
end
the
q,
a
q
a
hopefully
as
we
go
through
the
slides.
I
will
answer
the
question
as
well,
so
the
current
status
of
the
document,
as
most
of
you
are
ever
this
document
has
been
adopted
as
a
working
group
document
the
beginning
of
this
year,
most
notably
the
the
term.
The
transfer
slice
is
renamed
to
itf
network
slides.
There
are
lots
of
good
discussion.
I
I
encourage
you
to
take
a
look
at
the
link
which
is
giving
here
why
we
come
up
with
that
name
and
for
last
few
weeks
there
are
lots
of
good
discussion
on
the
mailing
list
about
the
draft,
and
these
are
the
area
which
was
discussed
and,
as
I
go
through
this
slide
for
each
of
them,
I
have
one
try
to
describe
that.
I
We
send
a
comprehensive
response
also
to
mailing
lists.
Last
week
again,
the
link
is
here:
you
can
take
a
look
at
whatever
we
discussed
today.
Basically,
the
detailed
description
will
be
in
that
mailing
list.
Next,
please,
the
the
first
item
and
the
suggestion
from
the
mailing
list
was
that
to
use
a
term
service
and
consider
the
ieta
network
as
life
as
a
service,
as
we
outline
here,
the
the
co-authors
are,
do
agree
with
the
suggestion
and
as
a
result
of
that,
as
we
will
go
through
the
slice
today,
we
will
see
that
you
know.
I
F
To
remind
the
authors
that,
as
a
working
group
document,
the
working
group
consensus
is
what
dominates
not
the
author's
opinion
and
it's
the
authors,
actually
the
editor's
obligation
to
match
what
the
working
group
decides.
Not
what
the
authors
decide.
So
I
it
was
probably
just
a
turn
or
phrase
to
say
the
authors
agree.
F
I
So,
as
stated
here,
we
compiled
the
value
suggestion
that
was
given
that
we
have
the
pros
and
cons
of
each
one,
the
yellow
item
in
the
middle.
There
was
a
suggestion
for
the
ap
v
as
a
co-author,
suggested,
nsap
and
nse,
and
the
access
circuit
and
ce,
and
the
idea
here
is
that
we
do
agree
with
the
basically
the
suggestion
here
that
we
have
to
use
the
cp
cepe
terminology.
I
Having
said
that,
since
the
cotton
code,
endpoint
in
this
case
is
not
really
mapped,
is
not
either
of
those
you
know
ceop
but
mapped
to
that
one
during
the
realization.
So
the
suggestion
that
we
have
is
and
we're
putting
on
the
mailing
list.
We
need
the
everybody's
opinion
that
we
are
suggesting
to
use
a
tab
to
have
that
abstraction
view
between
p
and
c
e,
something
similar
to
ap
or
nsat,
which
is
aligned
with
the
vn80,
and
we
put
the
rfc
here.
I
I
don't
know
if
you
wanted
the
have
the
question
right
now
or
later
joel.
You
are
in
line.
J
J
Okay,
I
don't
know
what
the
working
group's
conclusion
is.
I
know
what
my
suggestion
was,
which
was
that
the
end
point
of
the
ietf
network
slice
was
the
pe,
which
you
have
explicitly
excluded
from
your
list
of
choices
and
the
the
other
suggestion
that
I
saw
was
that
the
end
point
of
the
ietf
network
slice
service
was
the
ce.
I
K
I
Yeah,
the
if
there
is
any
other
suggestion
that
joel
mentioned
that
is
not
here.
We
will
take
a
look
at
the
mailing
list
and
we
will
include
them
here
to
make
sure
the
completeness
of
this
list.
The
captures
everybody's
opinion
on
that
one
and
we
put
it
on
the
mailing
list
for
the
further
suggestion
or
conclusion.
I
Some
of
the
discussion
that
the
joel
mentioned
is
captured
here
as
well.
Now
come
back
the
next
step
about
the
next
discussion
that
we
had
on
the
mailing.
It
was
related
to
how
we
are
mapping
the
network
slides
during
the
realization,
as
the
the
the
discussion
for
the
the
ietf
network
slice
is
an
abstraction
connectivity
when
it
comes
to
the
the
real
network.
Realization
part.
I
There
are
two
main
category
of
the
use
cases
and
also,
as
suggested
by
the
the
few
people
on
the
megalin
is
we
use
the
figure
2
of
the
rfc
3985
as
a
base
for
our
discussion.
The
two
types
of
the
category
for
the
use
cases
are
described
here
in
short
and
in
the
mailing
list.
We
have
the
more
detail,
for
example,
for
the
first
case,
which
the
end
point
during
the
realization
mapped
to
the
ce.
I
The
prime
example
of
this
type
of
use
cases
are
in
their
mobility
for
your
5g,
and
I
put
a
few
two
examples
here
in
the
backhaul
or
the
meethal
network.
This
is
the
kind
of
the
mapping
that
will
happen
again.
Mapping
happen
when
we
want
to
realize
that
we
know
the
network
and
we
want
to
realize
in
the
network
the
second
type
of
the
use
case.
The
mapping
happened
on
the
pe
side.
Again,
two
examples
were
given
here
when
we
want,
for
example,
these
are
not
the
use
cases.
I
These
are
just
a
few
use
cases
to
capture
the
idea,
data
center
interconnect
and
the
wholesale
transfer
in
those
cases
when
the
transfer
slides
will
be
realized
in
the
network
operator,
use
the
pe
to
realize
that,
and
if
we
go
to
the
next
slide,
we
have
the
picture
view
of
these
two
three
slides
that
is
explained
here.
This
is
based
on
that
rfc
3985.
I
We
included
the
idea
of,
for
example,
on
the
top
picture.
There
are
a
network
of
slice
number
two
iit
network
advisor
is
number
two.
There
are
some,
the
endpoint
or
whatever
term,
that
we
are
going
to
come
up
as
a
main
as
a
the
working
group
it
maps
to
pe,
which
is
during
the
realization
of
the
transfers.
I
I
Obviously,
there
are
a
lot
of
differences
and
subtle
differences
between
those
two
pictures,
so
this
is
capturing
the
idea
of
the
end
point
and
the
mapping
so
that
we
believe
that
these
are
related
related
to
each
other
has
relationship
with
each
other,
and
hopefully
this
picture
captures
the
idea.
If
the
answer
is,
we
can
modify
that.
I
really
encourage
everyone
to
send
out
the
suggestion
that
how
we
can
make
this
picture
the
reflection
of
the
discussion
that
we
have.
I
really
need
the
consensus
on
this
one
from
the
mailing
list.
I
There
was
another
discussion
about
the
consumer
versus
customer
again
with
the
lose
the
when
he
mentioned
something
at
the
beginning
that
maybe
english
agreed
that
this
term
can
be
used,
but
we
agreed
that
this
could
be
either
or
we
need
more
concerns.
F
I
think
the
discussion
is
still
ongoing
and
maybe
we're
getting
closer.
Ultimately,
we
like
for
the
editors
of
the
document
to
make
the
call
and
if
they
don't
then
we'll
make
the
call,
but
I
I
don't
think
we
have,
I
think,
joel's
right.
We
have
not
fully
closed
it
on
the
list.
J
Said
what
I
said
was
that
the
list
that
they
had
captured
was
not
the
full
list
that
had
been
brought
forward
in
the
discussion.
That's
separate
from
whether
there
is
or
is
not
a
rough
consensus
on
what
the
answer
is
that
I
think
in
this
situation
the
working
group
chairs
need
to
be
watching
for
and
judge
when
it
is
achieved.
F
We're
we're
watching
and
we
think,
there's
still
a
little
more
room
for
discussion.
H
I
did
good
okay,
so
unfortunately,
so
a
couple
of
things,
one
one
thing
at
the
very
beginning
of
the
presentation
you
started
with
this
is
the
green
networks,
like
actually
just
definitions,
mostly
about
terminology.
H
It's
not
a
generalized
graph,
and
the
thing
is
part
of
the
dishonest
is
driven
by
need
to
eventually,
I
think,
merge
these
graphs,
and
so
we
kind
of
have
consensus
on
what
this
is
going
to
say.
F
Eric
I'm
not
sure
I
got
everything
you
said.
I
think
you're
saying
that
there's
agreement
on
that
we
have
a
definitions
document,
we
have
a
homework
document
and
we
have
an
expectation
of
emerging.
I
think
you
said
one
additional
point
in
there,
but
I
didn't
hear
it.
H
It's
funny
I'm
hearing
myself
being
echoed
from
somebody
else.
The
other
point
that
I
think
is
we
need
to
arrive
at
consensus
on
terminology
as
quickly
as
we
can.
We
can't
do
any
merging
unless
the
determine
that
that's
the
best
way
to
get
consent.
H
I
So
this
is
the
last
slide
from
my
site,
the
just
working
with
the
mailing
list
and
get
all
the
suggestion,
consensus
and
included
the
next
draft.
Any
other
discussion
and
comments
are
also
welcome.
Thanks.
F
Fresher
as
we
move
on
to
the
next
presentation,
I
think
this
is
a
good
point
to
mention
that
we
have
a
a
bunch
of
documents
now
that
are
moving
more
towards
solutions
and
we're
happy
that
we
now
have
the
definition
document
close.
I
know
we're
not
done
and
a
frame
an
adopted
framework
to
serve
as
a
foundation.
For
those
excuse
me,
those
definition
documents.
F
We
do
think
that
there's
a
bunch
of
good
text
in
those
documents
that
could
go
to
the
framework
and
are
going
to
suggest
to
those
authors
to
make
suggestions
on
the
list
to
incorporate
pieces
that
they
think
are
missing
in
the
framework
and
suggest
that
they
bring
it
into
make
sure
specific
suggestions
on
what
they
would
like
to
see
with
in
what
is
now
a
working
group
document.
F
So
with
that
we're
going
to
go
on
to
this
one's
next,
sorry
I'll
have
to
find
the
right.
C
Yeah:
okay,
hello,
everyone,
my
name
is
tariq
and
I'm
going
to
give
you
an
update
on
this
document
that
that's
a
solution
document
for
realizing
network
slices
in
ip
and
mpls
networks.
The
update
is
on
the
behalf
of
the
co-authors,
shown
on
the
slide
next
slide.
Please.
C
Okay,
so
on
my
agenda
is
a
quick
update
and
then
I'll
do
a
recap
of
the
solution
that
we're
proposing
and
then
close
off
with
some
next
steps.
Next
slide,
please!
C
So,
since
last
presented
in
itf
109,
we
have
added
some
key
terminology
to
the
draft
and
we've
merged
the
draft
network
slicing
into
this
one.
The
co-authors
joined
this
effort,
and
we've
received
some
very
useful
feedback
from
the
working
group
and
we've
addressed
those
comments
in
the
recent
revision.
C
Lastly,
some
new
co-authors
joined-
and
we
thank
the
working
group
for
the
review
comments
that
were
provided
the
next
slide.
Please.
C
So
some
key
terminology
that
was
added
or
clarified:
we
have
the
slice
policy,
it's
a
construct
that
is
used
to
support
iedf
network
slices
instantiation.
C
The
slice
aggregate
may
be
comprised
of
one
or
more
itf
network
slices
or
slice
slice
traffic
streams.
The
the
mapping
of
one
or
more
itf
network
slices
to
a
slice
aggregate
is
maintained
in
the
itf
network,
size
controller.
I
see
people
are
lining
up
on
the
on
the
mic.
C
F
C
G
Thank
you
try
to
be
brief.
I'm
I'm
struggling
with
the
term
slice
policy
because
it
it
it
didn't
fit
with
the
meaning
that
I
expected,
which
was
the
set
of
rules
that
a
router
might
apply
to
a
to
a
big
pile
of
packets
in
order
to
decide
which
packets
went
on,
to
which
slice
and
that
doesn't
seem
to
fit
here
with,
with
with
the
the
phrase
and
which
I
can't
quite
decipher
the
the
instantiation
of
mechanisms.
C
Indeed,
indeed,
definitely
that
if
you,
if
you
hold
off
till
the
next
slide
or
subsequent
slides,
it
will
talk
about
the
parts
of
a
slice
policy
and
par
and
part
of
that
slice
policy
is
a
rule
that
says
what
identifies
a
packet
as
belonging
to
a
slice
aggregate,
and
there
are
other
rules
in
the
slice
policy.
C
We
can
talk
about
them
in
the
subsequent,
slides
and
I'll.
Let
you
you
know
chime
in
after
we
go
through
the
different
parts.
I
do
now
that
I
was
given
the
choice.
Maybe
it's
better
that
we
asked
the
questions
after
so
I'll
progress
given
the
time
constraint,
so
here's
a
an
attempt
to
quickly
define
the
life
of
an
itf
network
slice.
C
How
do
we
place
paths
within
a
slice
we
have?
We
can
do
that
on
demand
and
use
a
suitable
path,
control
technique.
In
fact,
we
do
not
advocate
a
specific
one,
but
we
we
can.
We
can
work
with
any
of
the
path
setup,
control
techniques
defined
at
idf
next
slide.
Please.
C
This
is
what
identifies
a
packet
as
belonging
to
a
slice
aggregate,
a
set
of
control,
plane
resource
rules,
so
these
are
like
bandwidth,
reservations,
policies
that
are
enforced
in
the
control
plane
and
there
are
data
plane,
resources,
rules
that
are
downloaded
in
the
data
plane
like
queuing
and
and
so
on
and
drop
probability,
and,
lastly,
is
a
customized
topology
for
the
slice
aggregate.
It
basically
defines
what
resources
are
part
of
this
slice
aggregate.
What
links
and
nodes
define
the
membership
of
this
slice
aggregate.
C
Now
this
dissemination
of
this
slice
policy,
the
slice
policy
can
be
defined
on
a
network
slice
controller
and
then
disseminated
into
the
network
using
a
multiple
techniques.
You
can
download
them
using
netconf
or
advertise
it
in
igp
or
any
or
bgp
for
that
purpose.
C
C
C
C
The
slice
aggregate
context
itself
and
then
a
packet
arriving
with
this
forwarding
label
will
map
to
the
slice
aggregate
other
options.
The
that
we
are
looking
into
is
carrying
a
specific
field
in
the
packet.
It
can
be
called
as
a
slice,
identifier
or
a
slid.
There
are
multiple
attempts
to
to
realize
this
or
to
carry
this
in
different
data
planes.
We
I
I
did
mention
multiple
drafts
here.
One
of
them
is
proposing
carrying
the
slid
inside
the
entropy
label
in
mpls.
C
The
other
is
defining
another
another
field,
a
forwarding
action
field.
Lastly,
it
could
be
a
multi-field
packet
selector
that
determines
the
slice
two
minutes.
Okay.
Next
next,
please.
Next
slice
next
slide.
F
C
The
slice
policy
resources-
I
did
mention
the
control,
plane,
resources
and
data
plane
resources.
These
are
also
rules
that
are
downloaded
as
part
of
the
slice.
Next,
please
next
slide
the
slice
topology.
I
did
mention-
and
I'm
reiterating
here
it
defines
the
membership
of
the
specific
network
elements
that
are
part
of
this
slice,
and
these
can
help
do
path,
placement
or
slice.
Aware
traffic
engineering.
C
C
I
am
going
to
skip
talking
in
detail
about
the
modes.
We
have
identified
multiple
modes
in
the
draft,
so
I
encourage
people
to
go
through
the
different
modes
for
slicing
in
the
control
plane
and
data
plane
that
we
can
do
with
the
slice
policy
in
terms
of
next
steps.
We
we
have
presented
this
work
in
last
ietf.
C
C
F
Of
questions:
let's
try
to
keep
it
really
brief.
We
do
have
four
minutes
at
the
end
of
our
agenda,
so
we'll
end
up
using
a
little
that.
C
M
C
That's
a
very
good
question:
we've
already
engaged
yeah
I
mean
on
the
list
as
well.
There
were
points
made
that
the
vtn
resembles
some
similarities
with
a
slice
aggregate.
We
don't
think
that
slice
aggregate
is
a
topology.
So
that's
one
thing
that
the
authors
of
this
draft
are
keen
on
is
that
it
is
not
a
slice.
Aggregate
is
not
a
topology.
A
slice
aggregate
has
a
set
of
links
and
resources
and
nodes
that
are
member
of
the
slice
aggregate.
It
also
has
the
you
know.
C
Other
parts
that
I
described
the
topology
is
one
part
of
it.
So
that's
one
difference
that
we
disagree,
that
a
vtn
is
not
equal
to
a
slice.
Angry.
F
L
Hello,
yes,
performance.
First,
in
fact,
in
our
meetings,
availability
draft
we
already
indicated
the
vtn
is
also
can
be
used
to
indicate
the
resource
in
the
data
plane
for
the
isolated
network.
Slides
well
at
the
same
time,
is
associated
with
the
topology
attribute.
I
wish
the
co-author.
The
author
of
this
draft
can
have
more
have
more
reveal
on
our
draft.
The
first
one,
the
second
one
I
explained-
concern
in
the
in
the
main
list,
because
now
there's
many.
L
F
I
Think
he's
bringing
up
a
couple
of
points.
F
Overlap,
even
though
the
terms
are
different
between
your
draft
and
his
draft,
and
I
think
he's
suggesting
maybe
to
figure
out
how
to
align
them
or
work
work
together.
I
think
that's
what
he's
saying
I
may
get
it
wrong.
I
have
gotten
it
wrong.
Yeah.
C
Sure,
thanks
for
decoding
that,
thank
you
for
decoding
that
and
yeah.
I
I
agree
we
need.
We
need
to
investigate
further
alignment
in
terms
of
the
terminology
yeah.
We
will
take
it
a
step
forward,
no
problem.
F
Yeah
we
we
really
are
are
over,
so
we
have
three
people
and
I'd
like
them
to
to
ask
if
they
don't
mind
taking
it
to
the
list,
if
they
really
feel
that
they
need
to
say
something
on
record,
you
know
like
15
seconds
each.
Please.
F
If,
if
not,
please
do
take
your
comments
to
the
list.
I
I
do
think
that
going
back
to
adrian's
comment
on
policy.
You
are
introducing
some
new
concepts
here.
Please
consider
whether
or
not
they
belong
in
the
framework
or
belong
in
a
specific
solution
document,
and
with
that
we're
going
to
move
on,
I'm
going
to
assume
people.
F
In
queue,
even
though
they
don't
really
want
to
be
there,
we're
going
to
go
to
luis's
slice
controller
as
soon
as
I
find
it
so
luis
if
you
can
unmute
and
bring
it
up,
that
would
be
great.
N
N
So
the
structure
essentially
consists
on
two
main
components:
the
network
slice
mapper,
which
essentially
takes
the
customer
slice
request
and
and
process
it
in
order
to
put
into
the
overall
context
of
the
itf
network
slices
being
managed
by
the
by
the
provider
and
then
a
second
component.
That
was
the
realizer,
which
essentially
processed
that
information
and
selected
technology.
The
proper
technology
and
interact
with
the
network
controllers
below
the
nsc.
N
So
the
models
that
we
consider
in
in
this
draft
were
the
ones
being
proposed
in,
within
the
framework
of
the
network
size,
design
team.
We
have
as
custom
initially
as
customers
view
the
the
wdt's
eitf
and
network
size,
nba
young
and,
as
provider
view,
the
luts
transport
network
size
young,
the
models
that
are
below
the
network
slice
controller.
That
would
be
the
ones
interacting
with
the
network
controllers
are
out
of
scope
of
this
draft.
So
next,
please.
N
So,
the
days
from
the
previous
version,
essentially,
we
mark
two
those
to
to
accomplish
for
the
version
zero
one.
One
of
them
was
to
add
two
new
sessions
as
placeholder
for
elaborating
more
on
the
components
that
we
saw
before
the
mapper
and
the
realizer.
We
already
created
these
placeholders
and
added
some
initial
description
for
them,
also
something
that
was
pending
to
be
resolved
for
zero.
N
We
we
go
through
that
in
this
version,
and
also
there
were,
there
was
another
comment
from
boris
kashanov
asking.
If
the
network
controller
could
be
considered
or
not
part
of
the
logical
architecture,
we
decided
to
keep
yet
as
part
of
the
logical
architecture,
because
this
is
what
is
being.
I
mean
to
make
it
consistent
with
the
definitions
and
the
french
draft
by
now
consider
the
network
controller
there.
N
So
next
step
would
be
to
collect
feedback
and
comments
from
the
working
group
to
propose
a
draft
as
a
great
outcome
of
the
design
team.
If,
if
we
get
working
on
the
design
in
a
structure
or
otherwise,
we
will
move
as
a
contribution
for
the
group
and
essentially
to
prepare
a
new
person
and
ask
for
adoption
in
next
meeting
if
possible.
So
this
is
all
from
my
side.
So
there
are
some
questions.
F
Okay,
I
think
thank
you
very
much.
I
don't
think
we
really
have
time
for
much
comments.
Doesn't
look
like
anyone's
coming
I'll
make
the
same
comment
I
made
on
the
last
one.
If
you
see
parts
of
this
document
that
you
think
are
appropriate
for
the
framework
document.
F
F
And
we're
going
to
move
on,
I'm
not
sure
bo.
I
I
I
On
the
left
hand,
side,
this
is
the
picture
that
just
lewis
showed
you,
the
network,
a
slice
controller,
has
an
nbi
and
str
the
component
that
we
did
we
discussed
for
this
discussion.
The
young
model
is
the
nbi
and
as
a
whole,
the
nbi
model
contains
then
be
considered
as
a
service.
The
upper
layer
asked
for
a
service
for
this
creation
of
ietf
network
slice.
That
request
contains
the
basically
four
different
major
components.
One
is
the
type
of
the
topology
which
is
needed.
You
know
the
0.21,
multipoint
multipoint
and
so
on.
I
A
group
of
policy
which
identifies
the
slo,
which
is
required
to
create
that
network
slice,
a
group
of
endpoints
which
belong
or
whatever
terminology
will
come
up.
We
will
modify
this
one,
obviously
and
last
but
not
least,
the
link
between
those
endpoints
how
they
basically
should
be
connected
together.
These
are
the
majority
of
there
are
some
other
small,
the
component
in
the
young
model,
but
these
are
the
four
group
of
the
components
that
you
will
see
the
in
the
next
slide.
Next
slide.
Please.
I
The
some
changes
that
has
been
done
versus
the
the
last
update
we
removed
the
concept
of
the
connection
group,
because
we
felt
that
we
want
to
be
aligned
with
the
the
mailing
list
and
basically,
a
single
entrance
as
a
single
itf
network
slice
as
a
service
contains
only
one
or
multiple
connection
with
multiple
slo.
We
believe
that
the
connection
group
is
was
redundant
in
that
model
to
simplify
it.
I
The
modeling
as
a
very
whole,
is
the
captured
here.
We
have
an
end-to-end
network
itf
network
as
well
should
be
created
either
blue
or
red
with
various
connectivity.
One
of
them
is,
for
example,
multi-point
to
point
another.
One
is
the
point-to-point.
The
whole
idea
here
is
if
we
want
to
model
this
one.
The
important
aspect
also
is
the
network
that
is
going
to
be
realized
that
this
ietf
network
slices,
not
necessarily
ipmps,
we
can
think
of.
I
I
have
only,
I
think,
one
more
slide
to
cover
you've
seen
this
picture
before
this
is
not
new,
but
the
idea
here
is
the
attribute
that
nbi
has
them.
I
guess
the
message
of
this
slide
here
is
the
attribute
which
specifies
the
northbound
interface.
Not
all
of
them
are
mandatory.
There
are
lots
of
attributes
which
are
optional
and
depends
on
which
attribute
is
given.
The
role
of
the
network.
I
Slice
controller
is
to
find
the
best
mapping
into
the
network
and
depends
on
the
information
which
is
given
that
cotton
code
best
lodging
inside
the
controller
will
decide
what
is
the
best
way
to
address
and
realize
it
in
the
network.
From
that
aspect,
the
attributes
that
you've
seen
in
the
yang
model,
lots
of
them
are
optional
and
if
they
are
given,
the
controller
is
going
to
take
advantage
of
them
to
find
the
best
realization
and
best
c
or
p
in
the
network
to
realize
next.
Please.
I
I
can
escape
this
one,
but
the
idea
here
is
just
a
quick:
the
discussion
about
the
service
training.
It
is
possible
to
do
that
one,
but
I'm
encouraging
to
take
a
look
at
the
draft.
Take
a
look
and
put
if
there
is
any
comment
or
feedback.
Please
include
in
the
mailing.
I
We
are
the
asking
for
comments
on
this.
Please
take
a
look
and
we
are
getting
closer
to
adoption
when
we
converge
on
the
terminology.
We
will
include
that
here
and
in
the
next
ietf.
Hopefully
we
reach
that
agreement
for
other
draft
and,
as
a
result,
we
will
be
very
close
to
have
an
adoption
of
this
one
as
well.
And
that
concludes
my
presentation.
F
A
A
The
renaming
was
done
to
be
consistent
with
the
terminology
introduced
in
the
best
parties
in
this
packet
draft
that
tarek
earlier
presented
again,
my
name
is
pawan
biram
and
I'm
presenting
this
on
behalf
of
the
folks
listed
on
this
slide.
Next
slide,
like
tariq
mentioned,
the
slice
policy
is
a
policy
construct
whose
enforcement
results
in
the
creation
of
a
slice,
aggregate
tarak
already
covered
what
a
slice
aggregators
and
how
a
slice
policy
can
be
used
to
instantiate
a
slice
aggregates
or
not
reiterate.
A
All
of
those
mechanics
but
I'll
just
focus
the
narrative
in
this
deck
on
the
modeling
aspects.
So,
depending
on
how
the
shared
network
resources
are
partitioned,
there
are
three
different
slice
policy
modes
that
can
come
into
play.
A
is
where
the
partitioning
of
the
share
network
resources
is
achieved
in
just
the
data
plane
b
is
where
the
partitioning
can
be
achieved
in
just
the
control.
A
The
forwarding
engine
on
each
participating
node
is
required
to
identify
the
traffic
belonging
to
a
specific
slice
aggregate
and
apply
the
corresponding,
perhaps
behavior,
and
that's
why
we
call
it
based
on
diffser
principles
right,
so
the
identification
of
the
slice
aggregate
and
the
corresponding
forwarding
treatment,
that's
dictated
by
the
slice
policy,
and
you
will
see
that
captured
in
the
model
proposed
in
this
document
in
the
modes
where
the
partitioning
of
the
share
network
resources
is
achieved
in
the
control
plane.
A
The
distributed
or
centralized
resource
reservation
manager
is
required
to
manage
slice,
aggregate
resource
reservation
and
the
provisions
for
enabling
that
are
dictated
by
the
slice
policy,
and
you
will
see
that
as
well
captured
in
this
model.
And,
lastly,
in
all
the
three
modes
you
do
require
the
topology
associated
with
the
slice
aggregate
to
be
specified
in
some
manner.
The
rules
for
determining
which
topological
elements
cater
to
the
slice
aggregate
are
dictated
by
the
slice
policy
and
you'll
also
see
that
captured
in
the
model.
A
This
new
renamed
version
is
consistent
with
the
terminology
used
in
the
two
network,
slicing
design
team
drafts
and
the
best
bar
draft
that
tariq
had
earlier
presented.
We
had
some
great
feedback
come
in
for
this
since
the
last
itf,
and
we
believe
we
have
incorporated
all
of
that
in
this
version.
Next
slide.
A
This
is
the
high
level
model
structure,
as
you
would
expect.
The
top
level
container
has
a
list
of
slice
policies.
In
addition
to
this,
there
is
a
list
of
phps
and
a
list
of
topology
filters
that
are
referenced
by
the
slice
policies.
It
is
structured
this
way
to
allow
multiple
slice
aggregates
to
use
the
same
php
or
the
same
topology
next
slide.
A
This
is
a
list
of
the
php
entries.
Each
entry
can
be
referenced
by
one
or
more
slice
policies.
It
can
either
carry
a
reference
to
a
generic
ph
profile
that
is
already
available
on
the
node
or
it
can
carry
a
custom
php
profile.
This
is
a
bit
similar
to
how
the
l3,
vpn
or
l3
sm
model.
L3
vpn
model
rather
has
been
modeled
next
slide.
A
This
is
a
list
of
topology
filters.
Each
entry
can
be
referenced
by
one
or
more
specific
one
or
more
slice
policies.
Each
entry
could
either
reference
a
predefined
topology
or
specify
the
rules
to
construct
a
customized
topology
so
for
predefined
topology
you
can
either
I
mean
we
have
a
couple
of
options
here.
You
can
either
reference
a
combination
of
algo
id
and
empty
id.
If,
if,
if
you
want
to
use
flex
I'll
go
of
topology.
A
That's
the
way
to
go.
The
other
option
is
to
reference
a
set
of
key
topology
identifiers
with
respect
to
construct
rules
for
constructing
customized
topology
we
have
a
set
of
include
any
include
all
and
exclude
filters
next
slide.
A
A
First
up
is
the
resource
reservation
container.
This
carries
data
nodes
that
are
required
for
bandwidth
engineering
slice,
aggregate,
aware
bandwidth,
engineering
next
slide.
A
The
slice
selectors
container
carries
a
set
of
ip
and
mpls
data
plane
field
selectors,
which
are
used
to
identify
the
packets
belonging
to
a
given
slice
aggregate.
Each
entry
in
the
list
has
an
index
associated
with
it.
The
one
with
the
lowest
index
is
the
one
used
by
default
by
all
the
topological
elements
that
are
members
of
the
given
slice
policy.
A
A
This
is
the
ph
belief,
is
a
reference
to
the
php
that
needs
to
be
applied
for
the
given
slice
aggregate
unless
specified.
Otherwise,
this
is
the
php
to
be
used
by
default
by
all
the
topological
elements
of
the
given
slice
policy.
The
penultimate
slide
next
slide.
A
This
consists
of
a
list
of
member
topologies
and
is
used
to
determine
the
topology
associated
with
the
slice
aggregate.
As
you
can
see,
you
can
have
multiple
topology
filters
referenced
by
the
same
slice
policy.
In
that
case,
the
union
of
the
topology
filters
will
give
you
the
topology
associated
with
the
slice
aggregate.
The
topological
elements
that
satisfy
the
membership
criteria
also
have
the
ability
to
optionally
override
the
default
php
or
the
default
slice
selector,
and
that's
captured
here
last
slide.
Please
next
slide.
A
We
understand
that
the
working
group
adoption
will
take
due
course,
and
a
lot
depends
on
how
the
framework
draft
shapes
up
in
the
coming
weeks.
We
would
like
a
few
terms
to
be
incorporated
in
the
framework,
but
that
said,
the
authors
do
believe
that
the
slice
policy
model
is
an
essential
construct
to
realize
the
slacks
aggregate,
and
we
do
believe
that
it's
sufficiently
baked
and
ready
to
progress
to
the
next
step
whenever
it's
deemed
to
do
so.
L
Hi,
I'm
I'm
a
little
confused
about
this,
the
young
models,
because
I
think
that's
the
young
models,
depending
on
the
implementation
of
the
control
plane
and
the
forwarding
plane.
But
until
now,
there's
not
the
protocol.
Extensions
for
the
control
plane
and
the
forwarding
plane
are
not
determined
so
how
we
can
go
with
these
young
models.
A
I
mean
ideally,
I
would
like
to
start
with
the
data
model
first
and
then
worry
about
the
extensions.
The
control
plane
extension
that
you're
talking
about.
If,
as
a
working
group,
we
believe
that
we
require
this
construct
called
a
slice
aggregate
and
I
believe
vtn
is
also
being
positioned
as
a
slice
aggregate,
and
I
would
like
to
think
that
is
a
construct,
that's
required.
A
Then
it's
just
a
question
of
how
we
go
about
realizing
or
instantiating
the
slice
aggregate
right
and
we
are
positioning
the
slice
policy
as
a
construct
to
help
instantiate
the
slice
aggregate,
and
once
we
get
some
consensus
with
regards
to
that,
then
getting
getting
the
igp
extensions
to
do
things
like
slice,
aggregate
away,
tea
or
some
extensions
to
cover
flex
algo.
Those
those
are
trivial
activities
in
my
head
in
getting
the
data
model
is
the
key
first
step
before
we
worry
about
the
igp
extensions.
That
would
be
my
take.
A
Yeah,
that's
that's
a
good
way
of
stalling
progress,
but
yeah
I
mean
we.
We
have.
We
have
produced
multiple
data
models
in
this
working
group
without
having
to
produce
an
information
model,
but
if
somebody
wants
to
take
a
stab
at
it
yeah
they
they
are
welcome
to
do
so.
F
Into
the
list,
so
this
topic's
out
of
time
and
I
think
you're
presenting.
O
Next,
hello,
I
will
present
this
on
behalf
of
your
song.
O
O
O
Okay,
here
we
list
all
the
natural
size
identifications
which
may
be
used
for
in
the
5g
entrance
slicing.
Some
of
these
terms,
like
the
network
slice
instance
and
the
ice
subnet
instance,
were
introduced
by
3gpp
and
correspondingly
for
the
transport
network.
We
introduced
the
tn
ssis
for
the
transport
network
slide
subnet
and
for
the
network.
Slides
mapping
between
the
5g
engine,
slides
to
the
transport
network,
slides
to
another
term
called
the
transport
nanoslice
interworking
identifier
is
used
to
describe
this
mapping
relationship
and
it
also
to
represent
the
data
plane.
O
Calculations
used
for
this
mapping
on
the
interface
for
the
connection
between
the
transport
network
and
the
ram
and
the
network
inside
the
transport
network
itself.
There
may
be
another
identifier.
We
use
the
term
here.
The
transport
network,
slice
identifier,
to
represent
this
concept,
which
is
internally
used
in
the
transport
network
and
it
is
different
from,
can
be
different
from
the
mapping
relationship
identifier
used
for
in
the
transport
network,
slice,
interconnection.
O
Okay,
this
page
gives
an
overview
of
the
5g
end-to-end
network,
slides
mapping
and
all
the
in
the
different
planes
in
the,
for
example,
the
management
plane,
the
control
plane
and
the
data
plane
for
the
management
plane.
The
entrance
management
function
is
responsible
for
the
end-to-end
slice
creation
and
to
maintain
the
relation
mapping
relationship
between
the
different
subdomain
slice
identifiers
in
the
access
in
access
in
the
transport
and
this
core
network
and
in
the
car
network
in
the
control
plane.
O
There's,
as,
as
I
say,
I
used
for
the
establishment
of
the
5g
network,
slides
between
the
access
network
and
the
car
core
network.
Well,
the
transfer
network
country
is
not
aware
of
this
kind
of
signaling
context
in
the
data
plane.
This
is
what
we
need
for
the
transport
network
slice
into
working
identifier.
It
is
called
to
identify
the
entrance
slice
mapping
relationship
to
the
transfer
network
slice.
So
this
is
what
we
will
talk
about
more
in
the
next
page.
O
O
Here
we
list
some
of
the
options.
One
typical
encapsulation
is
using
the
wheeler
id
for
the
network
slice
mapping
from
the
end-to-end
slides
to
the
transformer
slice.
Well,
we
also
have
listed
the
other
options
and
give
some
analysis
about
the
options
in
different
layers,
for
example
the
layer,
3
options
and
also
some
possible
options
in
upper
layers.
O
Here
are
the
what
we
have
updated
in
this
latest
version.
Basically,
we
add
some
add
a
reference
to
the
northbound
interface
young
model
and
we
clarify
the
relationship
between
slice
mapping
and
the
qs
mapping.
Basically,
they
can
be
seen
as
independent
behaviors
on.
O
Further
is
we
detail
the
specification
of
the
tnsii
based
on
some
comments?
It's
just
a
new
concept
for
to
ease
the
description
in
this
context.
Well,
it
it
can
be
instantiated
with
either
existing
data
plane
identifiers
like
a
vlan
id
or
some
other
ids.
It
does
not
have
to
be
a
new
encapsulation.
O
Well,
it
can
be
pre-allocated
as
a
global
identifier,
or
it
can
also
be
used
as
a
local
identifier.
Okay,
next
page.
O
So
the
reason
we
present
this
work
here
is,
we
think
we
notice
a
lot
of
interest
from
operators
who
have
research
concerns
about
how
to
realize
the
end-to-end,
slash
deployment
and
the
mapping
is
one
important
technology
used
in
this
to
achieve
this.
So
we
think
the
topic
really
needs
more
discussion
and
the
appreciate
more
comments
and
contributions
from
the
booking
group.
P
I
think
that's
a
lot
of
interest
from
this
topic.
I
think
one
of
the
ways
to
do
this
ig
interactions
a
lot
of
for
this
community.
I
work
in
the
dmm
group.
So
so,
if
you
see
there
is
a
working
group
right
after
draft
so
see
the
delta,
what
is
the
extra
things
need
to
be
done?
Maybe
it's
a
it's
a
good
idea
to
bring
it
to
the
dmm
working
group,
especially
for
the
5g
interactions.
So
a
lot
of
delegates
participate
there.
So
it's
a
good
time
to
get
the
feedback.
H
Q
Yeah,
let's,
let's
take
that
offline,
no,
if
which
is
not
here,
I
can
present
on
his
behalf.
N
N
Finally,
looking
for
consistency
with
some
other
outcomes
from
from
atf,
essentially
the
frameworks
that
have
been
defined
in
nfc
8969
for
automating
service
and
network
management,
and
also
it
fourth,
five,
three
for
the
ectn,
the
structure
and
control
of
te
networks,
so
essentially
looking
at
all
of
them
and
trying
to
understand
how
they
could
fit.
How
what
could
make
use
of
all
of
this
for
the
different
deployment
scenarios
that
we
could
find
in
service
provider
networks
in
sdn.
So
next,
please.
N
Here
we
took
an
example
of
the
5g
service,
but
well
the
idea
would
be
to
from
all
the
attributes
that
are
being
reported
in
that
other
draft
to
have
a
summary
of
what
could
be.
Let's
say,
the
the
general
attributes,
not
the
specific
per
service,
but
being
comprehensive,
comprehensive
for
all
the
services
expected,
but
just
for
an
example,
because
this
is
an
ongoing
work.
So
we
took
the
some
of
them,
for
instance,
for
the
5g,
the
availability
of
the
downlink
throughput
for
registration
purposes,
so
really
availability
for
instance.
N
Nowadays,
we
don't
have
a
gen
data
model
that
could
support
the
as
it
is
stated
in
the
in
the
fight
use
case,
so
that
the
availability
of
the
dimension,
we
could
make
use
of
some
capabilities
on
existing
young
data
models
for
requesting
tunnels
of
path
with
different
resiliency
requirements
in
terms
of
protection
or
restoration,
for
instance.
So
we
could
play
with
that
going
as
another
example
with
the
throughput.
N
Maybe
we
could
leverage
on
what
is
being
done
in
the
bpm
models
that
essentially
try
to
specify
a
bandwidth,
a
given
bandwidth
between
the
interface
between
the
slice
and
the
customer,
or
even
going
to
the
t
models
for
ensuring
a
certain
bandwidth
between
the
pe's
for
for
the
service.
So
these
are
just
examples
of
what
is
the
work
that
we
are
doing
next
slide?
Please.
N
So
once
we
understand
the
requirements
and
and
the
needs,
the
idea
would
be
how
we
could
play
with
the
different
data
models
in
order
to
realize
the
service.
So
we
we
foresee
three
options
by
now.
So
this
we
we
acknowledge
that
we
need
to
refine
it,
but
right
now
we
identify
three
different
options.
The
first
option
would
be
to
have
a
hierarchical
network
controller
that
has
some
other
network
controllers
above
and
essentially
the
in
this
first
option.
We
could
consider
that
the
network
size
controller
is
part
of
this
hierarchical
network
controller.
N
So
in
this
case,
for
instance,
the
slice
request
could
come
from
the
draft
wd
that
was
presented
before
and
we
could
expect
in
the
southbound
interface
of
this
hierarchical
network
controller,
to
make
use
of
the
network
models,
layer,
2
or
layer
3,
for
instance.
So
the
idea
here
would
be
to
trying
to
map
the
different
attributes
and
see
how
we
could
realize
this
leveraging
on
this
network
model.
So
now,
linking
with
a
structure
that
we
saw
before
as
well
proposed
for
the
neighborhoods
controller,
we
will
have
a
first
exercise.
N
N
Next,
please,
a
second
implementation
option
could
be
something
similar
to
what
has
been
defined
in
the
definitions
and
framework
drafts,
so
to
have
a
network
size
controller
that
has
below
a
number
of
enabled
controllers.
In
this
case,
maybe
we
could
consider
that
this
laser
request
comes
from
the
draft
view.
That
would
be
the
outcome
from
the
mapper
and
enter
into
the
realizer
component.
N
So
we
highlight
it
here
in
this
way
and
again
we
would
have
a
in
the
salvo
interface
from
the
network
size
controller,
a
map
into
a
network
model,
one
of
the
network
models,
either
layer,
two
ladder
three
here
again,
the
the
idea
would
be
essentially
the
same
for
mapping
and
for
realizing
so
the
need
of
having
the
complete
view
of
the
of
the
network
in
the
network,
size
controller
and
also
to
realize,
including
forwarding
policy,
routing
policies
and
so
on
so
far.
N
And
the
final
option
that
we
do
for
c
by
now
would
be
to
have
a
a
network
controller
that
incorporates
the
network
size
controller
and
essentially,
we
could
have
on
the
node
one
interface
of
this
network
controller
and
as
a
service
request,
for
instance,
a
layer,
two
layer,
two
vpn
or
larger
three
vpn,
that
is
realized
by
a
network
slice.
So
essentially
we
do.
We
have
a
letter.
Cbpn
be
mapped
and
be
unrealized
in
a
network
slice.
So
next
on
final
slide,
please
so
conclusions.
N
There
is
a
wide
variety
of
models
currently
being
progressing
in
itf.
Some
of
the
slice
requirements
could
be
satisfied
or
by
these
models-
probably
some
others
not
so
this
is
something
that
is
a.
We
need
to
look
at
that
in
order
to
ensure
a
straight
straightforward,
realization
of
what
is
being
requested
in
the
norway
interface
and
a
more
detailed
definition
for
those
uncover
requirements
is
needed.
So
this
is
work
in
progress.
Next
step
from
our
side
is
to
keep
working
on
on
detailing
the
different
implementation
options.
N
A
R
R
First,
this
slides
is
about
the
modification.
The
itf
network,
slice
definition
describes
a
number
of
use
cases
benefiting
from
the
network
slicing
and
also
it
clearly
states
services
that
might
benefit
from
the
network
slides.
They
include,
but
not
limited
to
the
above
use
cases,
and
this
document
supplements
two
cases
from
the
perspective
of
the
operators.
R
R
Page,
this
slides
describes
the
second
use
case,
the
branch
department
that
uses
slices
within
the
operator
in
the
first
picture.
There
are
multiple
sub
company
network,
a
b
and
n,
and
there
is
an
ip
backbone
network.
They
are
all
in
the
same
operator,
ip
network,
similar
to
the
first
use
case.
They
are
also
controlled
by
their
own
slice
controller
and
the
ip
backbone
network
need
to
be
coordinated
with
the
sub
company
in
order
to
control
and
calculate
the
energy
underpass.
R
R
R
Oh
this
is
this
slides
the
appended
the
resource
management,
the
network,
slides
resource
management
for
the
second
use
cases,
so
there
are
slice
id
node
id
as
a
policy
color
within
name
and
the
vlan
sub
interfaces.
R
A
Don't
see
anybody
queueing
up,
we
can
skip
jump
to
the
next
one
lewis.
Do
you
do
you
have.
A
O
O
I
have
some
background
with
the
vpnplus
framework,
as
described
in
the
enhancement
draft
which
is
adopted
two
years
ago
in
the
caseworking
group,
it
is
described
as
layered
architecture
and
the
technologies
to
provide
the
weapon
plus
services,
and
one
typical
use
case
is
the
network
slices
and
then
vtn.
The
term
is
basically
described
a
virtual
underlay
network
with
a
customized
topology
and
also
a
set
of
dedicated
or
shared
network
resources.
O
As
shown
in
this
figure,
we
can
create
multiple
vtns
based
on
a
shared
physical
network
and
each
can
be
used
as
a
virtual
underlay
to
carry
one
or
group
of
vpn
plus
services,
with
the
demand
for
the
vpn
plus
service
increases.
Scalability
becomes
more
and
more
important
in
the
solution,
design
and
deployment.
So
this
document
gives
an
analysis
about
the
scalability
of
the
input
service
in
terms
of
the
control
and
the
data
plan,
scalability
mechanisms
and
optimizations.
O
In
this
figure
we
give
some
possible
scenarios
of
the
network
slice
and
the
typical
numbers
expected
for
each
case.
We
can
see
for
different
scenarios.
There
can
be
different
numbers
we
expected
from
10
to
100
and
to
1000,
or
even
more
so,
for
the
solution.
We
need
to
meet
the
requirements
of
different
scenarios
from
the
initial
deployment.
A
solution
for
us,
relatively
small
number
of
the
vpn
plus
or
vpns,
can
be
used
well,
a
high
scalable
solution
is
needed
to
ensure
the
massive
deployment
in
the
future.
O
Also,
the
number
of
the
routing
computation,
such
as
the
spf
computation
executed
on
the
nodes,
in
addition
to
the
distributed
control
plane.
The
centralized
controller
may
also
have
some
concern
in
this
aspect
and
because
of
the
load
on
the
communication
channels
and
the
processing
burden
for
the
global
compensation
may
increase.
As
the
number
of
the
vts
increases
next
page.
O
For
the
control
plane
optimization,
we
proposed
several
approaches
in
this
document.
The
first
is:
we
can
use
a
shared
protocol
instance
on
protocol
session
for
the
information
distribution
of
multiple
returns.
As
shown
in
this
figure.
We
can
create
one
igp
instance
using
igp
adjacency
for
the
distribution
of
multiple
vtn
information.
O
This
can
avoid
overhead
of
increase
the
number
of
the
instances
and
sessions,
and
the
second
approach
is.
We
can
decouple
the
advertisement
and
processing
of
different
type
of
attributes
of
the
btn,
for
example,
the
topology
topology
attribute
and
the
resource
attribute
can
be
distributed
and
present.
O
We
can,
for
example,
we
can
create
multiple
vtns
which
have
can
share
the
same
topology
so
that
they
can
share
the
computation
of
spf
computation.
This
can
also
reduce
overhead
in
the
control
plane
for
the
centralized
controller
that
can,
we
can
just
use
in
hybrid
mode
to
divide
the
computational
load
to
the
centralized
controller
and
also
the
distributed
control
plane.
O
The
first
option
is,
we
may
choose
to
reuse
existing
fields
in
the
package
to
identify
vtn.
There
are
several
examples
like
seeds,
addresses
and
existing
labels.
The
process
we
don't
need
to
introduce
new
fields
to
the
data
packet.
While
the
cons
is,
we
may
change
the
semantics
of
the
existing
fields.
The
processing
behavior
may
be
changed
and
the
scalability
of
these
existing
identifiers
may
be
changed.
O
Another
option
is
we
can
introduce
a
dedicated
field
in
the
data
packet
to
carry
the
waiting
id.
For
example,
we
can
use
extension
headers
or
some
dedicated
amps
labels.
This
can
avoid
the
impacts
to
the
existing
fields.
While
the
cons
is,
there
may
be
some
difficulty
in
introducing
a
new
field
in
the
data
in
the
data
plane,
especially
if
you
need
to
be
processed
at
home
hub.
O
O
It
gives
analysis
about
the
control
plan,
data,
plane,
scalabilities
and
optimization
suggestions,
and
then
the
0.01
version
was
proposed
submitted
last
year
november,
with
many
editorial
changes
and
we
add
a
new
co-author,
the
0-2
version
submitted
before
this
itf.
We
add
some
further
analysis
about
the
database
options,
especially
the
controls
and
the
cons
of
each
approach,
and
we,
I
also
try
to
align
with
the
definition
draft
that
the
slice
definition
drops
about
the
terminologies
okay
next
page
here
are
some
conclusions
from
this
analysis
draft.
O
Firstly,
so
we
think
scalability
needs
to
be
considered
in
the
design
of
the
control
plane
data
plane
of
vaping
plus
there
are
mechanisms
with
different
scalability
which
may
be
used
for
different
scenarios
and
for
the
control
plane.
We
can
improve
the
scalability
by
sharing
of
the
instance
the
protocol
session
and
the
computation
for
the
data
plane.
We
may
improve
the
scalability
by
introducing
the
dedicated
identifier
in
the
data
packet,
while
the
costs
need
to
be
understood,
there's
no,
no
advantage
without
cost
yeah.
A
M
A
K
K
We
have
seen
a
lot
of
discussions
in
different
idea,
working
groups
which
are
very
c
which
are
discussing
similar
scenarios
where,
for
example,
we
have
networks
which
are
known
traffic
engineering,
but
for
which
we
need
some
attributes
which
are
a
subset
of
those
which
are
already
defined
by
the
at
topology
model
in
rfc878795,
and
there
is
some
there
was
some
proposals
to
create
a
new
modus
rather
than
using
the
t
topology
model,
and
the
reason
is
usually
the
fact
that
the
t
topology
model
in
the
rsc
is
looks
very
complex
at
the
first
glance,
because
it's
very
huge
and
the
reason
why
it
is
very
huge
is
because
it
is
supporting
a
lot
of
features
and
some
of
which
features
are
intended
to
be
used
only
with
traffic
engineering
networks.
K
But
either
of
these
features
are
actually
equally
applicable
to
traffic
engineering
and
no
traffic
engineering
networks
and
all
these
features
and
attributes
in
the
topology
model
are
actually
optional.
So
what
what
is
what
appeared?
What
very
clear
to
to
to
many
people
outside
of
the
set
of
people?
The
authors
is
that
a
subset,
something
like
a
profile
of
this
model
can
be
actually
used
in
specific
network
scenarios,
including
use
cases
which
are
not
traffic
engineering,
and
the
draft
is
intended
to
clarify
this
next
slide.
K
Please
and
the
and
the
draft
is
examines,
describes
five
examples.
These
are
examples
they
are
not
all
new
scenarios
may
be
also
useful,
maybe
also
applicable,
but
okay.
We
focus
only
on
the
five
on
this
files,
just
to
show
that
there
are
some
cases
which
are
known
traffic
engineering
or
not,
may
not
be
traffic
engineering
where
there
are
useful
attributes
in
the
t,
topology
model
that
can
be
used
to
address
these
use
cases
and
next
slide.
K
Please,
okay,
and,
as
you
can
go
quite
quickly,
it's
just
to
show
that
the
profile
can
be
very
small.
You
can
see
that
instead
of
tens
of
pages
like
the
topology
three,
you
can
stay
in
one
slide,
because
you
just
need
one
or
few
attributes
next
slide.
Please
I'll
try
to
go
okay
next
yeah
also
next
yeah.
These
are
just
examples
for
people
to
read.
Then
there
was
some
discussion
about
how
to
augment
the
topology
model,
and
there
are
three
options.
K
One
option
is
that
we
can
augment
that
the
the
topology
model
or
a
profile
of
it,
depending
on
your
needs.
It
depends.
This
is
applicable
where
you
need
to
provide
technology
specific
attributes
to
both
entities
which
are
defining
network
topology,
as
well
as
entities
which
are
defined
in
the
topology
like
bandwidth
or
ttps,
or
connectivity
metrics
next
slide.
K
K
So
you
can
instantiate
both
a
topology
model
or
a
profile
of
it,
and
the
network
technology
and
the
technology-specific
net
topology
model
in
your
network,
and
that
works
very
fine,
and
we
have
also
option
three
in
the
next
slide
is
where
you
can
split
into
two
models:
one
which
augments
the
network
topology.
Once
you
recommend
the
t
topology
or
the
profile
of
it,
and
there
is
no
big
advantage,
but
it
could
be
a
useful
option
in
case
where,
for
example,
the
network
topology
augmentation
already
exists
and
you
want
to
create
a
new.
K
You
add
the
new
attributes
for
the
t
topology.
So
we
discuss
these
three
options
next
slide
and
we
give
some
example
for
a
link,
for
example,
about
where
you
can
put
technology
specific
commentation
for
the
bandwidth,
for
example,
you
must
follow
option
one
or
three.
If
you
want
to
put
something
under
the
link
attributes,
you
must
follow
other
option,
one
or
three,
but
if
you
want
to
put
something
under
the
link
you
can
do
in
whichever
option
you
wish
all.
You
need
next
slide.
K
Okay,
a
couple
of
comments
I
got
offline,
which
are
of
an
issue.
The
first
issue
is
that
one,
since
the
server
implements
a
profile,
how
the
client
is
can
know
which
profile
is
implemented,
I
seems
that
they're
not
an
issue
when
you
read
the
operation
at
a
store,
because
by
reading
you
know
that
the
server
reports
only
the
leave,
the
the
leaves
that
the
the
young
leaves
which
has
been
implemented.
K
This
seems
a
more
generical
issue
and
the
question
is
better
whether
we
need
to
discuss
it
in
this
draft
or
somewhere
else-
and
I
don't
know
the
answer
at
this
moment
time-
and
I
was
planning
to
to
send
the
question
to
the
networking
group,
but
actually
I'm
I'm
a
little
bit
late,
okay,
so
a
an
investigation.
K
With
that
moment,
he
is
going
to
start
to
understand
how
to
deal
or
how
the
client
can
know
whether
an
optional
attribute
can
be
configured
or
not
by
the
server
implementation,
and
there
was
also
a
comment
about
the
option.
Two
and
three
where
we
use
the
multiple
inheritance.
This
multiple
inheritance
is
discussed
in
many
roughs,
but
not
discussed,
not
detailed
anywhere
and
there.
Some
was
a
question:
why
not
using
this
draft
to
discuss
to
describe
in
details
how
the
multiple
inheritance
can
be
used?
K
In
next
slide.
Maybe
we
can
take
the
discussion
compacted.
Okay,
the
next
steps.
Okay,
we
want
to
advertise
this
draft.
We
have
already
advertised
oc
campaign
upsell
a
working
group,
but
if
you,
if
you
see
any
other
working
groups
which
maybe
benefit
from
this
information,
I'm
with,
I
think
we
should
send
this
note.
K
We
solicit
more
review
and
feedback.
Sir
and
we
I
thanks
daniela
for
the
first
feedback,
sir,
and
we
can
address
additional
these
open
issues
and
any
other
comments
which
are
received,
and
the
other
question
is
whether
there
is
an
interest
to
further
work
progress.
This
work-
and
I
there
are
some
some
options.
One
option
is
to
progress
this
document
as
an
information
rsc,
but
I
know
there
is
some
reluctance
from
the
isg
on
too
many
informations.
K
A
I
think
we
are,
but
we
have
just
passed
our
stipulated
time
drew.
Can
you
take
the
your
question
to
the
list
and
it
look
if
you
can
pose
these
questions
on
the
list
where
you
can
probably
get
some
feedback.
A
Yeah
good,
I
will
raise
comments
on
the
list.
Yeah
thanks
everyone.
We
will
see
you
next
time
have
a
productive
week
ahead.
Thanks.