►
From YouTube: IETF111-TEAS-20210726-2300
Description
TEAS meeting session at IETF111
2021/07/26 2300
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
A
I
do
want
to
point
out
that
there
is
a
change
to
this
slide,
notably
matt
hartley,
who
has
served
as
secretary
for
many
years,
has
said
that
his
obligations
preclude
him
continuing
and
we
really
appreciate
the
help
he
has
given
us.
That's.
The
secretary
is
often
behind
the
scene
type
of
role,
but
it's
been
very
important
to
us.
We
are
working
on
bringing
on
a
new
secretary,
that's
not
finalized,
so
we
don't
have
it
up
on
this
slide.
A
Hopefully,
everyone
is
seeing
slide
two,
which
is
the
itf
note.
Well,
the
today's.
The
first
day
of
the
ietf
111,
so
some
may
not
be
familiar
with
the
practices
that
we
follow
in
terms
of
how
we
conduct
ourselves,
as
well
as
how
our
information
that
is
contributed
to
the
ietf
by
through
your
participation,
becomes
part
of
our
permanent
record.
A
A
You're
here
on
meat
echo,
so
that
means
you've
figured
out
the
first
part.
Thank
you.
So
much
for
joining
that's
great
note,
taking
we've
talked
about
is
collect
through
collective
note-taking.
We
used
to
use
etherpad.
Now
we
use
a
tool
called
kodi
md.
If
you
click
on
the
both
screen,
you
can
enter.
If
you
get
onto
a
screen
that
you
it
looks
like
you
can't
enter
information
go
to
the
top
and
you
can
also
hit
control
alt
b.
We
really
appreciate
anything
you
can
do
to
help.
Take
those
notes.
A
All
the
material
you're
seeing
here
is
online
and
available,
and
you
know
we
make
it
available
so
that
for
your
reference,
we
have
a
super
packed
agenda.
The
the
the
being
online
hasn't
reduced
the
demand
we
apologize
for
having
the
agenda
be
so
tight,
but
this
is
what
it
is.
We
will
we
do
point
out
and
it's
in
the
slides
that
we
can
have
interim
meetings
that
are
driven
by
the
desire
for
participants
to
have
a
longer
period
to
interact.
A
We
really
encourage
both
informal
meetings
and
formal
interims
and
all
it
takes
is
contact
us.
We,
I
believe,
we're
gonna
suggest
at
least
one
possible
interim
as
we
go
on,
but
let's
see
how
the
discussion
goes.
In
addition
to
interim
meetings
and
also
informal
online
meetings,
we
do
have
the
mail
list.
We
encourage
you
to
use
that
list,
it's
actually
where
all
of
our
final
discussions
take
place
and
how
we
judge
consensus.
A
Just
a
reminder:
we
do
have
an
ip,
a
formal
ipr
disclosure
process
within
the
working
group.
We
did
add
a
step
a
little
while
back
about.
When
you
add
authors,
we
we're
going
to
add
we're
going
to
ask
for
ipr
statements
and
you'll
see
that
going
on
with
one
of
the
documents
who
had
a
recent
edition
of
authors.
A
So
we
have
one
new
rfc.
Thank
you
to
all
who
contributed
to
making
that
happen.
It's
always
good
to
see
those
happen
and,
of
course
that's
the
reason
why
we're
here?
Yes,
we
love
discussions
and
we
once
loved
traveling
to
the
meetings.
Hopefully
we'll
get
back
there
sometime
soon,
but
the
real
purpose
here
is
to
produce
rfcs.
So
it's
always
good
to
see
that
happen,
and
thank
you
again
to
the
authors
and
others
who
contributed
within
the
working
group.
We
have
one
document
whose
publication
has
been
requested.
A
That's
with
our
a.d
john.
I
assume
john
scudder
is
here
hopefully
he's
here,
noting
that,
if
not,
we
certainly
will
mention
that
to
him.
Actually
I
see
him
listed,
so
that's
with
john.
We
have
john
do
you
know
I
thought
he
jumped
into
queue
but
john,
if
you
want
to
say
anything,
feel
free
to
jump
in
anytime,
you
want.
You
are
the
one
we
work
for
well.
At
least
you
manage
the
process.
Go
ahead,
john.
A
B
A
A
I
think
adrian
is
on
the
agenda
for
that
we
have
one
incoming
liaison
that
was
addressed
to
multiple
working
groups.
We
are
at
the
bottom
of
the
list
of
that
and
we
are
looking
to
see
camp
to
take
the
lead
on
the
response.
They
have
historically
done
been
the
lead
on
the
response
to
iqt.
This
is
basically
just
saying
tell
us
about
anything
that
you
think
is
relevant
to
us
and
so
usually
that
the
process
is
run
and
see
camp.
Often
it's
reviewed
in
in
teas.
A
C
We
have
21
working
group
documents,
three
of
those
colored
in
blue
here
or
on
the
general.
Today
we
have
one
document,
the
one
in
black,
the
c,
that's
the
signaling
extensions
chart
for
smp,
for
which
we
put
in
a
publication
request.
Last
month,
it's
it's
with
our
ad,
so
that
leaves
us
with
17
documents.
The
status
for
each
of
those
17
is
covered
in
this
deck.
Given
the
packed
agenda,
I
will
not
be
walking
through
each
and
every
one
of
those.
C
I
will,
however,
double
click
on
a
select
few
and
dwell
on
them
a
little
bit
for
the
rest
of
them.
You
can,
at
your
own
pace,
go
through
the
slides
and
the
reports
that
are
sent
out
to
the
list
and
if
they
any
questions
or
concerns,
please
do
reach
out
to
the
authors
on
the
list,
so
let
me
jump
to
slide
four.
C
This
is
the
act
and
vn
young
document.
There
haven't
been
any
updates
to
this
since
the
last
meeting,
but
there
was
a
discussion
point
from
the
last
meeting
that
we
haven't
closed
on.
This
is
with
regards
to
which
topology
model
in
which
tunnel
slash
path
model
are
to
be
referenced
in
the
vn
yang
model,
when
the
underlay
parts
are
placed
using
segment
routing
for
the
topology.
The
suggestion
was
to
reference
the
srt
topology
model,
that's
being
discussed
in
this
working
group.
C
The
authors
mentioned
last
time
that
there
were
a
few
empty
sections
that
they
would
like
to
fill
in
before
it
can
progress
to
the
next
step,
so
arthas,
please
do
take
care
of
this.
I
do
see
through
has
already
initiated
a
thread
on
this.
We
would
like
to
see
this
get
wrapped
up
before
the
next
meeting.
C
C
C
The
ask
from
the
chairs
is
to
have
this
document
define
what
srt
actually
means
and
also
discuss
the
relationship
with
sr
policies
in
general.
This
can
be
discussed
and
debated
further
on
the
list.
If
the
authors
have
any
questions
regarding
this
ask,
please
do
reach
out
to
the
chairs.
We
would
be
happy
to
clarify
any
questions
or
comments
before
I
jump
to
one
other
draft.
C
Okay,
let's
jump
to
slide
18..
This
is
the
base
tea
young
document.
The
authors
believe
that
this
is
now
ready
for
working
group.
Last
call
a
lot
of
work
has
been
done
to
get
the
document
to
the
stage
a
lot
of
hours
have
been
put
in
thanks
to
everyone
involved
in
this
activity.
The
plan
for
now
is
to
progress.
This
document
and
three
other
documents-
the
rscp
young
document,
the
rsvpte
young
document
and
the
t
mpls
young
document
to
the
last
call
in
the
next
few
weeks.
C
The
exact
order
in
which
this
will
be
done
hasn't
been
decided.
Yet
whether
the
t
and
rsvp
models
go
first,
followed
by
the
other
two
or,
if
all
of
them
go
together
over
an
extended
last
call
period.
Those
details
need
to
be
ironed
out,
but
please
do
review
these
four
documents.
In
anticipation
of
the
last
call,
those
are
the
items
that
we
wanted
to
cover
as
part
of
this
deck.
If
there
are
any
questions
either
on
this,
these
items
or
any
other
working
group
document
now
would
be
a
good
time.
D
D
So,
essentially,
we
wanted
to
document
how
we
can
use
some
of
the
the
various
teas
models
and
the
actn
architecture,
along
with
a
couple
of
key
use
cases
for
packet,
optical
integration.
So
we're
we're
very
good
at
developing
these
technology
yen
models.
But
often
we
find
that
there
are
things
missing
with
the
operational
security
sort
of
manageability
considerations
and
indeed
the
models
themselves
may
have
particular
gaps.
D
So
the
the
the
topology
that
we
have
there
is
relatively
straightforward.
We
talk
about
in
the
document
how
we
start
up
essentially
bootstrap
the
network
link
discovery
both
in
the
underlay
in
the
overlay
or
the
server
and
the
client
layer.
We
talk
about
the
different
ways
of
populating
the
databases
with
the
pncs
and
the
mdse
and
then
how
we
actually
set
up
services
next
slide.
Please.
D
So
there
are
a
number
of
sort
of
open
issues
currently
with
the
with
the
document
itself
and
those
are
mentioned
on
the
github.
We
we
do
try
to
reflect
sort
of
key
discussion
points
to
the
mailing
list
and
occasionally
during
the
working
group
sessions
as
well,
because
we
don't
always
present
this
particular
document.
So
we
we
don't
want
to
fall
into
the
trap.
D
It
would
be
things
like
the
the
management
of
the
network
inventory
sort
of
how
we
populate
that
and
and
who
is
responsible
for
it,
both
for
packet
and
optical
and
also
there
was
a
gap
for
communication
between
the
mdsc
and
the
pnc
to
set
up
the
srt
path
as
well.
So
these
are
sort
of
srt
augmentations
for
the
t
tunnel
model
and
then
finally,
I
think
we
had
some
optical
augmentations
for
the
path
computation
rpc.
D
D
There
are
some
security
considerations
that
we're
dealing
with
at
the
moment,
especially
around
some
of
the
the
discovery
and
negotiation
between
the
various
nodes,
both
in
the
optic
on
the
packet
layer,
so
sort
of
lldp
snooping.
There
are
some
sort
of
protection
and
restoration
aspects
as
well.
Using
local
protection
with
with
things
like
ti
lfa
needs
to
be
documented
in
the
draft
as
well.
D
C
A
E
E
E
Right
so
two
revisions
since
the
last
ietf,
so
in
the
last
four
months,
revision,
11
added
a
small
section
on
intent,
based
networks
and
also
on
multi-layer
tea,
thanks
to
lou
for
suggesting
that
we
needed
that
and
then
because
the
draft
seemed
to
be
approaching
stability.
I
added
in
the
change
log
from
rfc
3272.
E
And
then
revision,
12
med
did
an
excellent
and
detailed
review
of
revision
11
and
most
of
that
got
caught
in
the
update
for
revision,
12.,
some
reordering
of
sections
bringing
the
taxonomy
forward.
So
it's
easier
to
parse
the
document
and
a
good
number
of
small
clarifications
and
knits,
all
of
which
have
improved
the
document.
E
E
With
a
potential
change
there
in
the
abstract
to
to
to
reflect
that
expansion,
this
is
something
really
that
I
guess
the
working
group
has
to
decide
on.
There
are
two
issues
there.
One
is
it's
a
change
of
direction
from
what
3272
originally
had,
because
that
very
clearly
said
internet
and
the
other
issue.
Is
it's
potentially
a
large
lump
of
work
to
go
through
everything
and
check
the
applicability
to
different
scopes
of
of
network?
A
F
A
A
I
can
read
this
to
mean
you
know
to
cover
techniques
used
in
proprietary
networks,
because
those
are
private
domains
that
may
have
public
customers
and
and
clearly
that
is
beyond
the
scope
of
the
ietf.
So
if
we
wanted
to
say
ietf
or
internet
technologies,
I
think
that
would
be
within
the
scope
of
the
ietf,
and
that
was
comment.
E
A
So
for
me
personally,
I'd
like
to
understand
what
additions
we're
talking
about,
adding
before
we
to
really
address
the
point
of.
Are
we
expanding
the
scope
or
are
we
just
clarifying
what
te
means
in
the
internet
today
and
you
know
the
usage
has
evolved
over
20
years
and
without
specific
examples.
I
I'm
not
sure
I
can
judge
that
question,
but
I
think
it's
the
key
one.
You
know
how
much
are
we
changing.
C
The
scope-
I
mean
you
say
it's
potentially
a
large
lump
of
work,
and
at
least
it's
not
clear
to
me.
What
is
that
large
lump?
If,
if
we
limit
ourselves
to
t
as
cater
to
by
ietf
technologies,
I
think
most
of
it
is
already
covered
in
this
document
yeah
it
would
be.
It
would
be
good
to
understand
what
that
delta
is
and
then
make
a
call.
E
F
F
E
So
I
think
that
the
meaning
of
the
word
internet
morphs
pretty
much
continuously
through
time,
and
you
could
read
internet
traffic
engineering
as
being
traffic
engineering
within
the
internet
or
traffic
engineering
of
the
whole
of
the
internet.
I
don't
think
the
latter
is
what's
intended,
so
we
should
be
able
to
work
on
some
scoping
language
here
that
that
we
can
all
agree
on.
F
E
E
E
E
E
So,
zero
zero
immediately
after
the
status,
the
the
plan
rather
was
just
a
simple
inclusion
of
the
text.
From
the
two
documents
I
didn't
delete
anything
I
just
put
all
the
text
in
and
tried
to
move
it
between
the
the
sections
appropriately
didn't
make
any
attempt
to
harmonize
the
text
either
and
then
in
the
zero
one.
E
The
zero
two-
I
really
then
pulled
the
text
together
quite
a
lot
to
remove
duplication
and
started
work
on
terms
and
and
consistency
the
big
ones
there
were
that
I
picked
the
term
customer
having
had
a
bit
of
a
debate
on
the
list
about
customer,
consumer
and
client,
and
it
was
clear
that
we
needed
one
term
to
cover
this
customer
seemed
to
be
preferred
amongst
the
three
and
since
making
the
change.
Nobody
has
actually
successfully
taken
a
hit
out
on
me,
so
I
think
we're
okay
with
customers.
E
We
split
this
into
slos
being
quantifiable
and
service
level
expectations
covering
things
that
you
might
request
that
the
operator
does
for
you,
but
then
you've
got
no
definitive
way
of
measuring,
and
these
include
security
provided
in
the
network.
Geographic
routing
restrictions,
limits
on
the
occupancy
of
network
resources
and
isolation.
E
E
E
My
belief
is
this:
this
should
not
be
a
data
model
in
this
document
we
already
have
places
to
do
that.
I
don't
think
it
should
even
be
an
information
model,
but
it's
clearly
part
of
the
definition
of
a
network,
slice
and
john
suggested
some
text
on
this
sometime
back.
So
my
next
action
with
this
one
is
to
dig
that
text
out
polish.
It
put
it
on
the
list
for
review
next
slide.
E
So
the
third
upcoming
point
is
a
discussion
of
how
we
actually
realize
network
slice
services.
So
how
is
it
requested?
How
are
the
resources
assigned,
how
is
the
network
operated
to
achieve
this,
and
there
are
a
couple
of
drafts
out
there
that
approach
this
question
from
from
different
directions
says
the
enhanced
vpn
work
and
some
drafts
draft
best
bar
family
from
pavan
and
tarek.
E
E
E
G
I
have
a
couple
of
questions.
I
sorry
I
was
trying
to
multiplex
between
this
and
coin
rg,
so
I
might
have
missed
something
that
you've
already
said,
but
in
terms
of
the
service
endpoints,
and
I
know
that
you
had
a
discussion
about
the
customer
or
the
client
or
whatever
you
want
to
call
it.
But
when
we
talk
about
network
slicing
or
transport
slicing,
the
end
point
could
be
the
5g
network
or
it
could
be
an
end
customer.
G
G
What
I'm
thinking
is
that
the
transport
slice
that
we
are
focusing
on
in
the
ietf
could
have
as
a
end
customer
3gpp,
endpoint
or
3gpp
sliced.
You
know
slice
or
it
could
be
a
an
actual.
You
know
customer.
So
if
I,
if
I'm
verizon,
I'm
running
a
network
and
someone
wants
to
come
to
me
and
get
a
service,
I
could
say
hey,
I
can
give
you
a
slice,
and
so
it
is
an
actual
end.
G
G
E
Well,
no
because
some
might
be
paper
and
some
might
be
young
models
and
some
might
be
procedure
calls,
but
I
think
that
the
the
at
a
a
somewhat
metal
level-
yes,
it
is
the
same
procedure
for
requesting
a
slice,
and
that's
that's
what
this
this
slide.
That's
currently
projected
is
trying
to
to
look
at.
A
D
Question
good
hi
again:
this
is
this
is
dan
again
now
talking
about
the
applicability
of
actin
to
network
slicing.
In
fact,
this
is
a
piece
of
work
that
we
started.
Oh
next
slide,
please.
This
is
a
piece
of
work
that
we
started
approximately
three
years
ago,
when
we
were
sort
of
looking
at
requirements
and
starting
the
discussion
on
ietf
net
network
slicing.
D
D
We,
we
obviously
predated
some
of
the
more
recent
work,
including
what
adrian's
just
kind
of
talked
about,
but
but
we
we
were
mindful
that
there
are
sort
of
key
tease
documents
that
we
needed
to
sync
up
with,
so
we
we
we've.
We've
essentially
worked
with
the
enhanced
vpn
folks
and
and
also
the
network
slices
folks,
and
we
will
continue
to
work
with
some
of
the
other
sort
of
individual
drafts
that
that
are
also
being
discussed.
D
You
know,
wherever
possible,
using
terminology,
that's
that
that's
been
agreed
and
defined
by
those
teased
documents
and
then
sort
of
providing
relevant
references
as
well.
So
we
we
kind
of
focus,
as
mentioned
on
on
actn,
to
deliver
sort
of
a
slice-based
services.
We
talk
about
the
resource
management,
the
models,
the
protocol
interfaces,
resource
isolation,
it's
really
sort
of
again
another
cook
book
next
slide,
please
what
what
to
do
with
this
individual
document?
D
Well,
it
it's
been
helpful
in
the
context
of,
as
as
the
network,
the
itf
network
slice,
discussions,
progressed
and
matured
looking
at
how
we
apply
the
actin
architecture
and
and
those
sort
of
key
interfaces
between
the
the
cnc
and
the
mdsc
and
the
mdsc
and
the
pncs,
so
the
cmi
and
mpi,
and
and
also
what
technology
models
are
available.
What
terminology?
D
These
are
the
examples
that
we've
provided
where
there
were,
or
or
continue
to
be
identified
potential
gaps
around
sort
of
operational
security,
your
how
you
might
troubleshoot,
so
what
telemetry
models
or
or
more
traditional
management
techniques.
Might
you
use
that
that's
kind
of
another
area
of
investigation
that
that
we're
looking
at
what
what
we?
What
we
potentially
have
done
as
well
with
this
document,
is
remove
the
the
the
necessary
discussion
from
from
other
documents,
for
instance,
that
that
tease
itf
network
slices
document
that
adrian
just
talked
about.
D
We
can
essentially
say
that
we've
saved
that
document,
multiple
pages
of
text
by
having
this
document-
and
I
think
the
same
for
the
enhanced
vpn
document
as
well.
So
we
we
wanted
to
ask
the
working
group
and
the
chairs
really
what
what
they
might
like
us
to
do
with
this
document.
So
those
are
the
three
options
we've
got
at
the
bottom
of
the
slide.
D
So
so
no
questions
then
also
option.
One
is:
is
you
we
essentially
take
the
useful
content
from
this
particular
id
and
move
it
sort
of
into
some
of
the
the
working
group
documents
option.
Two
is
to
look
to
ask
the
working
group
if
they
want
to
support
this
work
and
then
sort
of
wipe
up
open
it
up
to
additional
discussion
and
maybe
direction
and
option.
Three
is
just
not
do
anything
at
all
with
it.
D
E
Yeah,
I'm
really
wary
about
the
idea
of
taking
the
content
of
this
document
and
moving
it
into
the
network
slices
document,
because
I
forget
what
it
is
done,
but
this
the
page
count
on
this
document
is
not
small
and
even
cutting
out
any
duplication.
I
think
that
would
seriously
unbalance.
What's
in
the
network
slices
document.
A
We
do
have
one
comment
in
jabber
from
joel
that
option
two
seems
like
a
good
path.
I'll
also
point
out
that
in
the
past,
when
we've
had
this
type
of
discussion,
we've
said
it's
good
to
adopt
the
document
and
then
figure
out
how
many
documents
we
have
and
if
we
continue
making
mature
the
text
and
making
sure
that
it
covers
the
topic
appropriately.
A
Even
at
the
last
minute
we
can
rearrange
documents.
So
from
a
process
standpoint
generally,
we
have
followed
option
two
right
trying
to
wrap
things
up.
You
saw
that
that
were
over
on
time,
I'd
like
to
just
see
if
we
have
any
objections,
anyone
want
to
come
to
the
mic
for
a
last
objection
and
if
you
are
not
interested
in
in
speaking
at
the
mic,
please
send
it
to
the
list,
but
option
two
seems
like
a
good
plan.
B
I
I
I'm
going
to
restrict
my
update
here
to
the
changes
from
the
last
revision
and
any
interactions
that
we
will
report
on
so
next
slide.
Please
I'll
talk
about
the
updates
in
the
next.
In
the
slide
in
terms
of
co-authors,
we
have
a
one
one
new
co-author
who
joined
in
the
latest
revision
reza
from
nokia.
I
We
have
had
meetings
with
the
editor
of
itf
network
slices,
these
network
slices,
and
we
will
report
in
more
details
on
this
in
the
subsequent
slide.
We've
also
met
with
the
office
of
enhanced
vpn
document,
and
we
have
an
update
on
the
agreement
on
this
one
and,
lastly,
I'll
be
updating
in
addition
to
the
these
ns
packet
draft
I'll,
be
giving
a
quick
update
on
the
slice
policy.
Hang
data
model
next
slide
please.
I
I
So,
as
he
mentioned,
we
there
is
a
suggested
text
that
is
going
to
be
floating
around
and
the
working
group
is
welcome
to
comment
on
it
from
our
side.
Next
step
is
to
reference
this
text.
If
it
gets
into
the
document
these
idf
network
slices
or
we
will
directly
incorporate
it
in
our
document
and
and
progress
further,
so
our
ideal
objective
is
to
have
it
in
the
network
slices
document
next
slide.
I
We
have
common,
we
have
identified
common
goals
and
that
we
need
when
we're
realizing
itf
network
slices.
We
we
came
to
an
agreement
that
a
new
term
for
the
aggregate
construct
might
be
needed
and
we
are
proposing.
We
both
us
as
the
authors
of
best
bar
document,
as
well
as
the
enhanced
vpn
authors,
are
proposing
that
this
new
term
be
defined
in
the
network
slices
draft,
so
we
might
require
adrian
as
well
as
others,
help
to
get
this
new
genetic
term.
I
We
have
no
intention
to
you
know,
produce
different
protocol
extensions
for
for
each,
so
that
will
only
be
one
set
of
protocol.
Extensions
and
and
will
be
referenced
in
the
specific
document.
Next
slide,
please
in
terms
of
the
yang
data
model
for
the
slice
policy
that
we're
proposing
we've
added
two
updates.
One
is
a
new
data
node
for
the
lsb
forwarding
label,
infer
slice,
selector
and
we
have
introduced.
I
We
already
had
the
topology
filters
in
the
in
the
yang
data
model,
but
there
is
a
wider
applicability
for
those
topology
filters,
as
was
the
you
know,
identified
and
pce
working
group
as
well.
So
we
have
moved
this,
this
topology
filter
modeling
into
a
separate
document.
I
have
the
draft
there
pointer
to
it,
and
we've
updated
the
data
model
to
reference,
the
specific
external
module
and
new
module
next
slide,
please
in
terms
of
next
steps.
So
we
we
already
requested
a
working
group
adoption.
I
A
Before
opening
the
floor,
I'd
like
to
comment
that
you've
mentioned
quite
a
few
things
where
there's
been
private
discussion
and
decisions
made,
and
I
don't
believe
that
those
have
been
reflected
on
the
list.
I'd
like
to
see
all
those
reflected
on
the
list
before
we
open
the
topic
of
working
group.
Adoption.
I
A
To
be
clear,
there's
nothing
wrong
with
private
discussion.
It's
the
way
we
get
things
done,
it's
just.
We
have
to
bring
it
to
the
list
and
expose
that
those
discussions
and
those
you
know
private
agreements
and
make
sure
there's
consensus
on
them.
It's
good
to
it's
good,
to
make
progress.
So
thank
you
for
making
the
progress.
I
see
we
have
in
the
queue
and
probably
time
for
one
question.
One
quick
question.
J
Robin
go
ahead
first,
because
now
these
are
several
drums.
These
have
this
the
overlap
and
should
be
coordinated.
So
I
think
that's.
The
other
drop
is
better
to
coordinate
with
the
other
draft
and
to
refine
this
the
text
to
solve
this
is
the
possible
overlap.
A
second
point
is
in
order
to
accelerate
the
network
slicing
work.
I
suggest
that
we
have
this
more
entire
meeting,
who
saw
these
overlap,
issues
and
aligned
with
each
other.
J
C
C
K
K
K
In
the
framework,
we
realized
that
the
scalability
becomes
an
important
factor
for
the
widely
deployment
of
this
technologies
for
the
network
scenarios
like
network
slicing.
So
in
this
document
we
provide
the
scalability
considerations
of
the
written
layer
which
are
including
the
scalability
cons,
analysis
of
the
control
plane
and
the
data
plane,
and
we
also
propose
several
scalability
optimization
mechanisms
in
this
document.
K
Here
we
summarize
some
of
the
scalability
optimization
approaches
we
described
in
this
document
for
the
control
plane,
optimization
the
we
highlight
several
possible
approaches.
The
first
one
is:
we
can
reduce
the
number
of
the
control
protocol
instances
or
the
sessions
for
the
written
information
distribution.
K
K
So
this
can
give
us
the
benefit
of
sharing
topology
and
spf
computation
among
multiple
vtns,
as
shown
in
the
figure
on
the
right
side
we
can
have
if
we
have
multiple
regions
which
have
the
same
topology,
they
can
refer
associated
with
the
same
topology
and
the
spf
competition
can
result
can
also
be
shared.
So
we
can
reduce
the
overhead
in
the
control
plane.
K
We
can
also
reduce
overhead
of
the
advertisement
for
duplicated
attributes.
The
third
approach
is
we
proposed
to
have
the
hybrid
control
mode,
which
is
to
make
use
of
both
the
centralized
controller
and
also
the
distributed
control
plane
to
divide
up
the
computation
load
so
that
we
can
improve
the
scalability
of
the
whole
system.
K
So,
with
this
approach
we
will
decouple
the
written
resource
identifier
from
the
topology-specific
ids
in
the
packet
forwarding,
as
shown
in
the
figure
on
the
right
side.
We
can
have
a
separate
ids
in
page
header,
one
to
identify
the
topology
or
the
path
and
the
one
is
to
identify
the
written
specific
resource.
K
Here
are
some
further
considerations
about
the
scalability,
which
we
maybe
for
further
discussions
in
both
in
the
document
and
also
in
the
working
group.
The
first
one
is:
we
need
to
consider
what
type
of
writing
information
needs
to
be
advertised
in
the
distributed
control
plane,
because
there
are
some
limitations
in
advertising
large
amount
of
profiting
information.
K
K
We
know
that
flash
algo
supports
up
to
128
different
geological
topologies,
while
with
iss
and
multi
topology
it
can
support
up
to
4k
topologies
so
depends
on
the
required
number
of
topologies.
We
may
need
to
consider
which
approach
will
be
more
applicable
for
the
high
school
scalability
solution,
and
this
draft
list
here
different
approach
to
use
associating
with
either
topology
or
flash
algo.
K
K
K
So
for
the
next
steps,
we
would
like
to
work
with
the
authors
of
the
itf
nav,
slash
draft
to
produce
the
new
common
new
term,
the
app
this
is
documented,
with
a
new
term
to
make
this
document
ready
for
adoption
and
based
on
this
aligned
technology.
We
can
also
collaborate
on
the
protocol,
extensions
and
other
procedures
for
the
natural
slice,
realization.
A
L
Let
me
know
yes,
yes,
sorry
about
that,
so
I'm
going
to
present
this
draft
on
behalf
of
my
co-author
next
slide,
please
for
the
scope
of
the
draft,
this
informational
draft.
It
lists
the
essential
building
block
needed
for
network
slicing.
It
explains
how
building
law
interacts
seamlessly
and
independently
of
each
other.
The
goal
for
this
seamless,
independent
interaction
is
to
provide
scaling
and
to
support
incremental
deployment.
Next
slide,
please
this.
L
L
So
basically,
this
draft
describes
the
building
block
to
realize
the
network
slides
by
using
constructs
at
the
control
plane,
information
carried
in
the
data
plane
and
orchestration
at
the
controller.
The
building
blocks
are
listed
here,
but
the
key
point
is
that
for
a
scalable
network
slicing,
this
building
block
needs
to
work
together,
seamlessly
independently
and
the
following
slide
will
explain
a
bit
more
next
slide.
Please.
L
L
The
green
and
blue
slide,
sir
slices
is
segregated
by
using
hierarchical
cues.
In
reality,
slide
isd
is
really
constructed
as
like
qos,
it
is
independent
of
routing
and
topology
and
following
slides,
explain
a
bit
more.
Another
attribute
slice
id
needs
to
have
is
backward
compatibility.
It
needs
to
work
in
a
backward
compatible
manner
so
that
we
can
have
incremental
deployments
next
slide.
Please.
L
So
now,
let's
look
at
take
a
look:
how
these
building
block
works
seamlessly.
So,
let's
first
take
a
look
at
the
two
building
block
flex
I'll
go
and
fly
tlfa
in
terms
of
independence.
So
here
please
ignore
the
green
and
blue
box
for
now
and
let's
only
focus
on
flax,
silver,
128
and
129
mentioned
in
the
picture.
L
Let's
assume
flex,
elgo
129
is
for
low
latency,
as
shown
by
the
red
plane.
So
if
the
link
between
node,
5
and
6
fails,
we
expect
the
backup
to
only
use
low,
latency
backup
path,
for
example,
path.
We
are
node,
seven
and
eight
and
in
indeed
that's
an
attribute
of
flux,
elbow
the
backup
path
is
optimized
for
flexible.
L
L
So,
let's
see
how
flat
cell
going
to
lfa
and
the
slit
construct
works
together
for
a
scaling.
We
cannot
replicate
flux,
I'll
go
in
green
and
blue
slices.
It
is
possible
because
slice
is
by
definition
the
slit
is
independent
of
routing
and
is
by
define
by
design.
Similarly,
tlfa
would
work
in
seamlessly
for
each
slice.
For
example,
in
this
picture
notice,
the
slice
id
is
a
stateless.
L
For
example,
at
the
transit
node,
eight,
the
transit
node
eight
will
apply
differential
treatment
based
on
the
slice
id
carried
in
the
packet,
so
it
will
the
things
work
independently
and
seamlessly,
as
as
shown
for
flaxseed
go
to
left
and
slit
as
an
example.
Next
slide,
please
15
seconds
the
other
others
as
slice
other
building,
so
so
the
other
aspects
of
sr
policies
of
like
server
vpn
needs
to
also
work
seamlessly
next
slide.
L
This
is,
this
is
the
work
that
we
reference
or
work
that
we
based
on
or
discuss
here
on
the
next
step,
like
tariq
mentioned,
there
is
some
ongoing
discussion
among
with
both
the
tarek
and
jimmy,
like
the
last
two
presenters
to
to
have
their
ongoing
discussion
for
collaboration
and
merge.
So
we
will
look
forward
to
that
discussion.
Many
things.
H
M
Yes,
hello,
everybody.
Can
you
hear
me
yeah?
We
can
please
perfect.
Thank
you.
So
I
would
this
drop
er,
entitle
itf,
angular
slice
use
cases
and
attributes
for
norwal
interface
of
of
the
controller
I
will
present
on
behalf
of
my
co-authors.
So
next
page,
please,
okay.
The
motivation
of
this
draft
is
essentially
the
the
following,
so
the
definition
of
itf
network
slides,
including
the
high-level
architecture
that
is
documented
in
the
framework
and
or
even
the
data
models.
M
M
Once
we
have
all
this
capabilities
available
in
the
network,
so
move,
let's
say
the
existing
services
to
the
the
notion
of
slices.
So
the
purpose
of
the
draft
is
essentially
to
cover
that
gap,
so
analyzing
different
use
cases
identifying,
slos
and
sla
slas
and
attributes
are
methods
needed
for
itf
network
slice
controller.
Next,
please.
M
M
This
will
be
detailed
in
the
next
slides,
there's
the
one
on
the
radio
functional
split
and
also
we
have
complemented
one
assisting
use
case.
That
was
the
one
about
5g
services
here.
Essentially,
what
we
did
is
to
add
details
in
this
situation
where
the
iatf
networks
less
customer
is
the
3dpp
management
system,
the
overall
3d
pv
management
system
being
discussed
in
sa5
and
3dpp.
M
We
have
the
two
new
co-authors,
jeff
and
christoph,
and
we
are
working
yet
in
further
content.
We
didn't
have
time
for
including
for
this
version.
Essentially,
we
are
working
on
the
consideration
of
slices
being
extended
to
data
center.
So
what
will
be
the
implications
of
of
this
different
scenarios
where
the
slice
is
terminated
and
also
we
are
working
in
a
summary
table
of
attributes
and
functionalities
with
the
idea
of
providing
an
aggregate
view
of
what
would
be
the
the
those
attributes?
M
So,
regarding
the
sd1,
the
objective
would
be
to
support
sd1
overlays,
connecting
spark
customer
sites,
and
any
normal
interface
attribute
that
we
are
identified
have
identified
so
far
would
be
slos
like
a
bandwidth
service,
uptime
packet
loss,
latency
and
additional
characteristics,
such
as
the
need
of
encryption,
addressing
specific
needs
of
addressing
frame
size
and
so
the
running
procedures.
The
policy
we
have
identified,
the
need
of
having
policies
per
application,
flow
groups
like
encryption,
internet,
breakout,
etc
and
well.
M
The
applicability
would
be
essentially
to
map
sd1
services
into
itf
network
slices
or
even
provide
itf
negotiations
as
a
new
form
of
sd1
service,
or
something
like
sd1
plus,
let's
say
simplifying
the
reference
that
we
took
for
collecting.
All
this
information
was
the
meth
documentary
thermal
forum,
70
spec
next
page,
please,
regarding
the
radio
functional
split,
the
idea
would
be
to
accommodate
front
hall
and
mid-hall
connectivity
by
means
of
slices
normal
interface
attributes
considered
here
would
be
as
lows
like
bandwidth,
latency
packet,
loss,
etc.
M
As
indicated
by
the
nature
of
the
connection,
so
from
holland,
me
hall
introduces
specific
needs
that
will
essentially
boot
map
to
a
specific
slices
in
the
network.
Additional
characteristics
such
as
geographical
location
can
have
influence
because
of
the
limitations
in
some
cases,
for
instance,
in
the
front
hall
we
need
to.
We,
we
need
to
accomplish
a
very
extreme
latency,
so
this
can
condition
the
the
geographical
location
of
the
service
regarding
noble
interface
procedures,
we
do
foresee
similar
slice
cycle
as
the
one
in
5g
services.
M
Probably
here
in
this
case,
would
be
at
least
how
the
the
way
in
which
this
has
been
defined
in
oran
and
because
they
are
leveraging
so
much
in
artificial
intelligence
and
close
loop.
Automation,
probably
will
be
more
dynamism
than
in
3dpp,
at
least
by
now.
The
applicability
essentially
provisioning
of
front
hall
and
neutral
connectivity
and
the
reference
is
the
requirements
document
from
oran
next
page.
Please.
M
So
as
next
steps
and
as
a
final
slide,
essentially
or
direction,
is
to
complete
the
work
in
progress
and
correct
some
typos
that
are
now
present
in
the
document
so
work
in
the
data
center
staff
and
the
summary
table
to
scan
for
additional
relevant
use
cases
or
scenarios
negative
scenarios.
If
any-
and
this
from
from
the
content
perspective
from
the
interaction
with
the
working
group,
we
would
like
to
collect
feedback
and
comments
from
the
working
group
and
for
sure
we
will
prepare
a
new
version
for
next
itf
meeting.
M
Hopefully
in
madrid
regarding
well
also
something
some
point
that
we
would
like
to
to
rise
here
would
be
the
the
call
for
adoption
of
this
document.
We
feel
that
this
document
could
be
valuable
as
an
input
for
several
other
documents
in
the
working
group,
like
the
jam
models
or
even
the
network
slice,
controller
structure
or
the
instantiation
of
networks,
licensing
service
providers,
networks
that
will
be
the
following
presentation,
and
so
on
so
far.
M
A
Because
the
way
it
was
uploaded,
your
normal
one
got
actually
got
listed
last.
We
would
be
interested
in
objections
to
adopting
that
document.
It
went
quickly,
so
please
take
their
comments
to
the
list,
but
we
really
want
to
hear
about
objections
to
adopt
adopting
that
document
in
the
original
agenda
that
was
listed
as
number
11.
It
got
presented
as
number
10.
and
with
that
over
to
back
to
you,
luis.
M
M
So.
The
first
point
here
is
to
clarify
what
is
the
intention
of
the
draft
and
what
is
not
the
intention
of
the
draft
just
to
to
have
clear
the
scope
of
this
work,
so
the
intention
essentially
is
to
to
leverage
on
on
existing
itf
capabilities.
The
idf
machinery,
as
we
told
here,
to
operate
itf
network
license
and
service
provided
networks.
M
So
what
we
could
do
today
for
with
all
the
capabilities
that
we
have
these
artifacts,
that
we
already
have
available
and
then
identifying
gaps,
if,
if,
if
any
in
such
a
way
that
we
we
could
understand
if
we
can
satisfy
neighborhood
requirements
with
the
the
this
artifact
that
we
have
today
is
not
intentional
to
staff,
neither
defining
new
young
models,
nor
redefining
architecture
or
terminology
or
adding
new
requirements.
This
is
out
of
totally
out
of
scope
for
the
work
in
this.
M
In
this
document,
we
have
take
care
as
inputs
different
sources,
the
first
regarding
the
network,
slice
architecture
and
the
framework.
So
we
have
the.
We
have
considered
the
the
draft,
the
framework
draft,
the
merged
one
that
was
presented
before
by
adrian
regarding
the
attributes
and
functionalities.
M
So
regarding
the
dates
from
the
previous
version,
we
have
essentially
worked
on
editorial
updates,
so
the
idea
has
been
to
make
the
the
document
much
more
readable,
to
align
aspects
of
of
naming
and
also
to
include
the
new
section
so
essentially
polishing
the
document
and
trying
to
make
it
consistent
and
unreadable.
We
have
renamed
some
sections
such
a
way.
We
have
now
a
structure
with
the
sections
that
you
can
see
there.
It
never
say
requirements
and
data
models,
itf
network
slice
procedure,
network
controller
operation,
operational
considerations
and
network
size
procedure.
Well,
this
is
repeated
sorry.
M
We
have
added
as
well
a
new
section
about
the
reference
architecture
and
components
where
essentially,
we
try
to
explain
how
the
itf
networks
list
controller
can
be
implemented
in
a
network
operator
with
different
options
and
all
of
them
being
based
on
the
overall
framework
that
is
detailed
in
the
in
the
definition
document.
Well,
the
one
and
resulting
from
the
merge.
Let's
say
next
page,
please
so
also
as
an
update
we
well,
we
started
to
dig
into
the
the
different
requirements
or
different
attributes
and
functionalities
needed
so
in
in
the
previous
version.
M
Next
next
page,
please
so
next
steps.
Our
idea
is
to
continue
to
working
on
on
different
implementation
options,
trying
to
understand
different
capabilities.
Different
possibilities
also
work
on
security
and
operational
aspects.
Our
idea
would
be
to
collect
additional
deployment
requirements
for
the
gap.
Analysis
so
essentially
checking
the
suitability
of
the
models
that
we
already
have
to
satisfy
the
respected
consumers,
customers
of
the
network
slices.
M
Our
idea
would
be
also
to
trying
to
provide
from
this
exercise
feedback
to
the
architecture
and
the
solutions
works.
So
the
the
merge
document,
but
also
the
solution,
works
that
we
have
revisited
along
today
and
also
well.
Our
intention
would
be
to
collect
feedback
and
comments
from
the
working
group
to
enhance
the
document
and
then
the
very
big
question
from
our
site
so
to
understand
from
the
working
group.
M
A
F
N
N
N
N
N
And
also
there's
another
hot
one
that
we
received
from
the
med
and
he
said
that
the
the
network
slice
should
accommodate
not
just
the
connectivity
requirements,
but
also
the
some
like
compute
and
storage
requirements
also
be
needed
to
considered
and
right
now
we
don't
touch
about
the
compute
and
storage,
and
but
we
we
touch
the
model,
touch
the
the
slice
invocation
of
service
functions.
We
add
a
policy
to
as
a
steering
constraints
policy
to
to
model
these
requirements
next
step,
please.
N
The
authors
are
also
working
on
the
how
to
resolve
the
resolve,
the
new
additions
of
sle
definition-
and
we
still
haven't
reached
the
agreement
yet-
and
this
is
a
the
first
issue
about
geo
graphic
restriction-
how
to
model
this
and
and
also
the
diverse
connection.
We
still
not
agree
on
this
next
night.
Please.
N
N
And
so
since
this
draft
has
been
presented
several
times
and
we
received
a
lot
of
helpful
comments
to
help
to
improve
this
draft,
and
we
think
this
draft
is
quite
stable
now,
and
there
is
a
lot
of
interest
on
this
and
on
this
draft,
and
also
this.
This
draft
is
the
next
step
of
this
of
network
slice
framework
draft.
So
we
we
ask
for
the
working
group
to
consider
to
adoption
distract
thanks.
That's
all
thank
you.
C
A
Yeah,
so
this
is
clearly
a
topic
that
has
received
a
lot
of
interest
and
the
question
is
going
to
be
for
the
working
group
is:
is
this
good
a
good
enough
starting
point
again
when
we
do
adoption?
It's
a
starting
point,
not
a
final
point,
and
I
don't
think
we
have
time
really
to
ask
for
questions
or
objections,
but
we
will
definitely
take
it
to
the
list.
Thank
you.
A
O
O
O
O
O
O
In
this
case,
we
can
make
a
network
slides
with
layer,
3,
te
and
source
function
aware
so
we'll
use
all
five
models
here
we
have
network
slides,
we
have
a
layer,
three
unicast,
we
have
a
t
topology
model
with
the
key
capabilities
under
the
te,
will
also
have
packet
switching
capability,
and
also
this
is
a
service
function
aware
with
this
we'll
have
network
type
network,
slicing
network,
slides
and
an
l3
unit
cast
topology,
and
also
we
have
t
topology
and
the
te
will
also
have
a
packet
and
sf
next
slide.
Please.
O
C
O
O
O
C
O
H
N
As
presented
before
about
the
slice
aggregate
and
vtn,
the
enhanced
vpn
actually
defined
this
term
of
virtual
transfer
network.
It
contains
the
parts
of
the
physical
network
resource
and
this
customized
network
topology
and
including
a
group
of
nodes
and
links
here
on
the
on
the
left-hand
figure,
shows
what
will
the
wii
team
network
what
we
can
looks
like
from
the
physical
network.
There
will
be
partition.
N
N
And
hey
here
is
a
modeling
approach
of
this
wiki
network
model,
and
this
model
is
designed
to
as
a
augmentation
to
the
network
topology
young
model.
We
think
that
the
the
network
topology
model
can
have
the
information
of
the
physical
network
and,
based
on
this
physical
network,
topology
will
like
partition.
N
N
N
P
P
P
Okay,
the
approach
of
this
of
this
model
is
that
the
mpl
sd
party
topology,
will
be
an
augmentation
of
the
t,
topology
packet
in
parallel
with
eternity
topology,
and
so
we,
the
the
the
idea,
is
that
whatever
is
common
for
any
packet
technology
will
go
into
mpls
into
the
topology
packet.
Whatever
is
specific
for
mplste
will
go
into
mplsd
topology
next.
P
So
the
open
issues
is
now
is
about
whether
we
need
how
much
information
we
want
to
give
to
the
controller
in
terms
of
level
augmentation
and
when
we
look
at
the
the
initial
motivation
of
the
of
the
rough
boost
was
mpl
stp
we
found
that
label
locations
are
usually
done
by
the
network
element
and
the
tunnels
are
single
domain,
so
there
is
the
the
label.
Labor
allocation
is
not
something
that
needs
to
be
exposed
and
a
northbound
interface
of
a
controller
for
an
mpsp
network.
P
So
we
don't
see
the
need
to
provide
too
much
information
about
the
labor
range
available
on
on
a
link,
and
we
would
like
to
get
confirmation
from
the
more
broader
applicability
of
mplsde,
and
we
also
think
that
a
draft
is
really
for
working
group
adoption
and,
as
I
said,
is
just
as
a
starting
point
to
progress.
The
current
work,
I
think,
is
that's
the
last
slide.
Thank
you.
A
I
think
at
this
point
italia
will
take.
We
should
discuss
it
more
on
the
list,
but
you
know-
maybe
maybe
it's
because
we're
running
the
end
of
the
day
for
many
people.
I
know
this
is
somewhere
in
very
many,
but
definitely
less
energy
right
now.
I
don't
think
we
should
take
that
as
disinterest,
though,
as
no
one
came
to
the
mic,
all.
P
P
P
We
have
started
to
add
a
new
section,
four
about
the
issue
that
was
raised
about.
How
can
a
server
knows
what
is
the
profile
implemented
by
the
server
by
the
server,
but
the
client
can
use
what
is
the
profile
parenting
server,
which
is
important
for
when
the
topology
is
read
right
and
we
have
done.
We
have
investigated
with
netmode
working
group
whether
this
is
a
generic
problem.
P
P
We
got
a
comment
from
daniel,
which
we
forgot
to
implement
in
this
version
to
clarify
the
title
that
the
model
is
applicable
also
to
known
to
use
case
the
profile,
and
we
will
appreciate
more
review
and
feedbacks
and
also
on
addressing
the
open
issues
and
any
other
comments,
and
we
think
we
have
some
of
the
discussion
and
we
think
this
document
is
available
and
we
would
think
it
would
be
good
to
progress
this
as
an
information
rsc,
and
we
think
it
could
be
a
good
step
for
a
working
group.
Adoption
as
well.