►
From YouTube: IETF108-TEAS-20200731-1100
Description
TEAS meeting session at IETF108
2020/07/31 1100
https://datatracker.ietf.org/meeting/108/proceedings/
A
Hello
welcome
to
teas
at
itf
108
online.
I
am
lou
berger.
We
have
vishnu
burum
my
co-chair
online
and
I
haven't
seen
if
matt
will
join
us
or
not,
but
matt
hartley
is
our
secretary
and
he's
very
helpful
behind
the
scenes.
So,
even
if
we
don't
have
him,
we
do
appreciate
his
contribution
online.
We
have
the
agenda
that
is
the
same
as
what
was
distributed
previously.
One
change
is
how
we're
going
to
do
note-taking
we're
going
to
use
this
new
tool.
A
A
A
We
know
we're
on
media
echo
because,
if
you're
hearing
this
this
is
how
you're
viewing
it
we've
already
talked
about
note-taking
and
the
online
agenda,
I
am,
I
am
trying
to
watch
jabber,
as
is
my
co-chair.
We
will
try
to
channel
anything
that
anyone
would
like
to
say
just
put
at
mic
in
front
of
it
if
you'd
like
to
ensure
that
it
gets
read,
our
agenda
was
as
uploaded
it's
packed,
so
we're
going
to
try
to
keep
things
moving.
A
I
believe
we've
said
this
before,
but
we
wanted
to
reiterate
that
in
this
new
all
online
mode
of
working,
it's
we
want
to
offer
that
the
working
group
resources,
notably
the
webex,
is
available
for
informal
meetings.
Obviously
we
continue
to
have
our
mailing
list
is
the
way
we
judge
consensus.
The
way
we
do
our
primary
business.
We
also
have.
We
can
have
virtual
interims,
and
we
also
have
these
now
informal
meetings
that
are
available.
A
So
what's
new
in
terms
of
major
document
status,
we
have
a
new
rfc,
that's
always
great
to
see
since
that's
why
we're
here
and
that
covers
the
yang
data
types.
Thank
you
very
much,
the
authors
and
contributors
in
the
working
group
for
producing
that
in
the
editor
queue
we
have
a
te
topology,
that's
a
fairly
major
document.
It
wasn't
author
48.
A
We've
received
one
liaison
and
one
communication:
the
liaison
is
from
3g
e
and
is
related
to
their
work
and
slicing
and
the
and
discussion
of
network
slicing.
So
this
is
obviously
highly
relevant
to
our
network
slicing
discussions
and
there
is
a
request
for
a
response
on
this,
and
I
think
it
makes
sense
for
maybe
to
ask
the
design
team
for
a
response.
A
But
really
the
response
is
from
the
working
group,
so
we
will
get
together
a
draft
on
that
it'll
be
sent
to
the
list
and
go
from
and
we'll
go
from
there
to
ensure
that
we
have
working
group
consensus
before
sending
that
we've
also
received
a
communication
from
the
gsm
alliance.
By
the
way,
the
difference
between
a
liaison
and
a
communication
is
a
liaison
is
something
we
have
a
formal
relationship
established
by
the
iab
with
that
organization.
A
That
communication
is,
we
don't
have
that
formal
liaison,
and
I
believe
this
group
is
actually
going
to
talk
to
the
ieb
about
potentially
establishing
a
liaison,
but
that's
will
be
driven
from
them,
so
they've
sent
out
liaison
to
both
3gbp
and
the
ietf
with
specific
requests.
They
are
not
asking
for
a
response,
but
they
do
identify
future
meetings.
I
take
that
as
an
implicit
invitation.
Don't
really
know
if
that's
the
case,
but
that's
what
was
in
the
communication.
A
A
B
B
So
there
are
20
working
group
documents
listed
here,
four
of
those
marked
in
blue
or
on
the
agenda.
Today
there
is
one
the
one
in
red
for
which
we
put
in
a
publication
request
sometime
in
recent
weeks,
the
status
for
each
of
the
remaining
15
documents
is
covered
in
this
deck.
I
will
not
go
through
each
and
every
one
of
those
but
I'll
highlight
a
few
things:
the
modeling
drafts
for
t
and
rsvp
and
l3,
and
sr
topology
augments
they're
all
nearing
completion.
B
B
B
B
B
The
authors
have
indicated
that
this
would
now
be
covered
in
detail
in
other
documents,
but
it's
not
clear
how
and
what
the
plans
are
with
regards
to
it.
There
is
a
reference
to
some
work
that
hasn't
been
adopted,
yet
I
would
like
to
request
the
authors,
if
they're
present,
to
elaborate
on
that,
and
also
in
the
meantime,
ask
the
working
group
to
review
these
changes,
as
these
are
significant
edits.
C
B
A
B
G
Okay,
so
I
just
want
to
address
something
that
adrian
said.
I
I
think
that
the
the
new
draft
that
he's
talking
about
the
ac
10
actn
applicability
to
network
slicing
draft
does
have
some
general
applicability,
but
it's
not
really
as
broad
as
he
says,
since
it
is
limited
to
acpnte,
so
that
technologies
that
are
not
visibly
relying
on
t
e
will
not
necessarily
use
this.
G
B
H
A
Of
sort
of
the
the
the
tension
between
work
group-
individual
documents,
if
something's
a
working
group
document,
you
really
can't
extract
it
and
put
it
in
an
individual
document
without
discussion
with
the
working
group
and
it's
fine
to
flag
it
and
say
hey,
we
think
that
belongs
in
an
individual
document.
But
the
working
group
controls
the
content
of
a
working
group
document,
while
individuals
control
the
content
of
an
individual
and
it's
not
accepted
yet.
So
we
there's
retention
there,
please
in
the
future,
just
flag.
B
Yeah,
so
this
is
the
new
work
that
we
adopted
much
thanks
to
adrian
and
everyone
else
who
were
instrumental
in
getting
this
to
this
stage.
It's
it's
a
big
effort
and
thanks
for
all
your
efforts,
there
was
some
brief
discussion
on
the
list
on
what
constitutes
a
full-fledged
tea
and
what
really
entertains
entails
partiality.
B
So
this
discussion
is
really
important
for
us
in
order
to
categorize
other
tea.
Ish
work,
that's
being
done
in
other
working
groups,
say,
for
example,
traffic
steering,
vs
policies
or
tree
engineering
via
beer.
So
if
you
do
have
any
opinion
on
this,
please
do
chime
in
on
the
thread
I
mean
it
was.
It
was
a
fairly
brief
discussion
on
on
the
mailing
list,
but
I'd
like
to
see
more
opinions
come
in.
B
This
is
the
rsvp
rmr
document.
This
was
in
expired
state
for
quite
some
time.
The
authors
just
revived
this
and
the
the
promise
is
that
they
would
reassess
the
next
steps
for
this
after
the
base,
mpls
rmr
document,
which
is
kind
of
stuck
in
the
isg
process,
gets
going
yeah
we
yeah
we.
We
will
reassess
the
fate
of
this
after
that,
goes
through
I'll
stop.
Here,
you
can
go
over
the
remaining
slides
by
yourselves.
B
H
H
H
H
H
H
H
The
the
other
part
of
the
choice
is
related
to
the
value,
and
this
is
considered
the
case
in
which
there
is
no
need
to
associate
multiple
part
request,
and
so
it
is
an
explicit
list
of
attributes
and
so
the
server
as
a
this.
In
this
way,
all
the
information
related
to
know
how
to
create
a
tunnel
within
the
operational
data
store,
and
so-
and
this
is,
there-
was
a
strict
alignment
with
tunnel
model
and
thanks
channel
guys
that
helped
us
in
this
topic
next
slide.
H
H
Also
in
this
case,
we
adopted
the
same
concept
of
dependency
tunnel
that
is
proposing
the
tunnel
model
and
okay
is,
and
there
is
a
differentiation
in
the
update
of
the
young
in
case
the
dependency
tunnel
is
already
present
in
the
data
store
or
is,
can
be
any
an
entry
in
the
tunnel
attribute
list
for
which
we
have
the
name
and
the
leaf
ref
related
to
the
list
of
the
tunnel.
Outputs.
H
H
H
C
H
A
A
H
Okay
for
the
next
step,
we
think
the
addressing
the
last
comments
and
the
extension
suggestion
for
new
feature.
We,
the
the
draft,
is
stable
enough
and
we
think
we
are
ready
for
young
doctor
review.
Okay.
We
we
need
to
resolve
the
open
issue
that
I
mentioned
before,
and
in
particular,
we
need
a
cooperation
with
the
tunnel
model
autos
and
we
have
planned
for
working
group
last
call
after
yeah,
itf
109,
obviously,
depending
of
also
the
of
the
feedback
from
young
doctors
thanks.
B
I
B
D
D
So
the
the
three
yang
models
that
we
have
is
the
vn
yang
model,
the
augmentation
of
vn
and
pe
young
model
with
the
kpi
telemetry
and
the
third
set
is
the
service
mapping,
where
we
have
a
common
type
and
various
augmentations
to
the
service
model
and
the
new
update,
which
is
the
augmentations
to
the
network
model.
Next
slide,
where
we'll
start
with
the
v
and
yang
update
next
time.
D
So
vn
basically,
is
the
customer
view
of
our
of
our
network.
It
uses
it
uses
the
topology
model,
the
abstract
node
and
the
connectivity
matrix
concept
of
the
d
topology
model.
So
it's
an
abstraction
over
the
other
te
model
with
a
customer
view
next
slide.
So
let's
focus
on
the
updates
that
were
made
recently,
so
the
updates
were,
we
changed
the
type
diff
for
all
the
identifiers
that
we
were
using
in
our
document.
D
We
were
using
un32
before
we
changed
them
to
inet,
uri,
mainly
of
by
looking
at
rfc
8345,
which
is
the
network
yang
model
where
it
uses
inet
uri.
So
we
prefer
to
use
the
same
thing
and
we
made
the
change.
There
was
one
comment
regarding
this
on
the
list
we
checked
with
the
authors.
The
author
said
that
this
is
a
good
practice,
so
we
are
looking
for
feedback
from
implementers
and
other
people
as
well,
whether
this
seems
to
be
a
problem
for
anyone
or
whether
they
are
happy
with
this
change.
D
D
We
have
removed
one
one
grouping
that
we
had
for
path,
disjoint,
which
we
were
redefining.
There
was
no
need
for
us
to
redefine
this
already
exist
in
the
te
types,
so
we
have
done
that
change
in
appendix
we
have
added
a
small
description
on
how
to
set
our
constraints
when
using
the
vm,
because
that's
a
worry
that
many
people
had.
So
we
have
something
to
point
people
to
on
how
to
do
it.
We
would
like
to
thank
tom
petch
for
giving
us
various
yang
comments
on
how
to
fix.
D
So
we
have
done
that
even
after
that
we
have
something
pending,
so
we
will
get
on
to
them
very
very
quickly,
so
one
more
thing
would
be
next
slide,
which
is
this
another
suggested
change
that
we
have
from
the
kddi
folks,
so
they
provided
us
a
requirement
that
they
have
difficulty
using
the
vm
compute
rpc
right
now.
The
main
issue
is
that,
since
we
are
dependent
on
the
t,
topology
and
connectivity
matrix
to
do
this
vn
compute,
they
have
to
do
it
in
two
steps.
D
They
have
to
first
call
the
t,
topology
model
create
an
abstract
topology,
set
the
constraints,
constraints
there
and
then
call
v
and
compute
rpc,
so
this
they
feel
for
them.
This
was
becoming
a
problem
and
they
was
asking
us:
is
there
a
better
way
to
do
that
where
they
can
get
the
vn
compute
result,
especially
when
they
are
doing
testing,
and
they
are
probing
the
network,
whether
they
can
do
it
via
a
single
rpc?
So
this
to
satisfy
this?
We
it's
it's
pretty
easy
to
do.
D
We
can
optionally,
add
two
groupings
which
already
exist
in
the
t:
types
rfcs,
which
is
generic
path,
constraints
and
generic
path,
optimization
as
a
part
of
vm
compute,
where
optionally
they
can
provide
us
this
information
directly
in
the
vm
compute
itself,
and
we
think,
as
authors
discussed
with
them,
and
we
feel
that
this
is
a
reasonable
request.
We
would
like
to
know
from
the
working
group
whether
there
is
any
objection
on
this
and
next
slide.
D
D
A
D
Yeah,
that's
always
welcome,
so
if
there
is
no
one
who
is
rushing
to
the
mic
queue
I'll
move
on,
so
the
next
document
is
the
kpi
telemetry
yang
model
next
slide
piece,
so
this
yang
model
is
basically
adding
performance,
performance,
monetary
telemetry
structure
by
augmenting
the
t
tunnel
model
and
the
vn
model.
So
these
are
the
two
young
that
you
see
on
your
screen
and
customer
will
subscribe
to
this
telemetry
using
the
existing
mechanisms
and
we
also
have
a
scaling
intent.
D
This
is
something
new
which
has
been
added
in
the
document
and
it's
been
there
for
a
while.
So
this
is
just
a
quick
summary,
so
the
updates
that
we
have
next
slide
would
be
mainly
doing
editorial
changes
and
and
fixing
the
requirement
language
in
the
draft.
Updating
the
prefix
and
reference
table
again.
Thank
you,
tom
petch,
for
pointing
these
thing
out,
so
we
have
fixed
these.
We
have
one
comment
pending
which
was
sent
by
greg.
D
This
was
regarding
since,
at
the
vm
level,
we
are
aggregating
the
telemetry
data,
so
we
have
to
put
a
clear
reference
on
what
is
our
methodology
of
how
we
are
doing
this
aggregation?
So
this
will
apply
to
especially
at
the
vm
level.
What
is
the
methodology
we
are
using
to
aggregate
our
telemetry
data?
D
So
this
we
have
not
yet
handled
I'm
looking
for
feedback
from
folks
who
have
done
that
in
other
yanks
and
whether
we
have
good
reference
and
a
technique
to
describe
it,
whether
it
should
be
added
clearly
in
a
description
or
whether
just
a
reference
is
enough,
so
even
from
greg,
I
will
continue
to
discuss
and
if
other
people
have
thoughts
on
this,
please
reach
out
to
me
or
on
the
mailing
list
we
are.
This
is
still
pending
this.
We
need
to
resolve.
D
D
This
is
our
mapping
model,
which
maintains
a
mapping
between
the
service
models,
l3sm
l2sm,
l1
csm,
with
rte
models
at
various
different
granularities
at
vm
level,
at
the
topology
level
at
the
tunnel
level,
etc.
So
any
level
it's
able
to
do
this
mapping.
This
mapping
facilitates
for
easy
service
operations.
You
can
just
focus
on
the
service
and
what
is
the
underlay
te
network
visibility
we
can
provide?
Even
we
can
do
while
having
different
map
types,
we
can
control.
D
D
This
was
being
discussed
in
the
ops
area
working
group
as
well
as
on
the
tease
earlier
that-
and
we
discussed
this
in
the
last
meeting
as
well,
where
what
about
mapping
from
network
model
to
our
pe
resources,
and
since
we
have
this
common
type,
which
is
well
defined,
it
can
easily
be
used.
So
that's
what
we
have
done
in
this
update
as
well.
D
So
in
this
case,
when
the,
when
the
customer
wants
to
provide
the
service
yank,
they
have
the
idea
of
what
is
the
pe
constraints
they
have,
but
they
do
not
know
what
is
the
underlying
pe
because
it
might
not
have
established
right
now,
so
they
would
still
want
to
use
our
mapping
model
to
do
that.
So
this
requirement
came
from
operators
and
made
quite
a
bit
of
sense.
D
This
is
a
similar
requirement
that
you
saw
in
the
previous
presentation
as
well,
where
we
want
to
do
path
computation
on
and
referring
to
constraints
without
without
having
to
set
those
tunnels
create
those
tunnels
in
the
system
first.
So
the
idea
here
is
that,
in
our
common
data
structure
we
can
maintain
these
constraints
and
optimization
criteria
and,
like
any
other
mapping,
we
have.
J
Okay,
I'm
yeah.
This
is
stark
from
with
juniper
networks
the
roof.
I
have
a
question
about
the
the
constraints.
Template
is
the
intention
to
have
a
stateful
request.
You
know
you
set
your
constraint
and
you
know
these
are
give
me
the
path
whenever
it
changes
notify
me
as
well,
or
this
is
a
stateless.
D
D
K
Okay
hi:
this
is
daniel
that
wanted
to
add
a
very,
very
small
bit
of
information
on
what
the
true
accent
explained
in
a
very,
very
good
way.
I
mean
this
is
a
requirement
that
that
comes
from
the
oss
layer.
The
fact
that
in
many
cases
that
the
service
orchestrator
doesn't
care
about
the
fact
that
a
given
vpn
is
bounded
for
given
to
tunnel.
K
K
L
Yeah-
and
this
is
yadi
also,
I
I
thought
I
would
spend
30
seconds
introducing
the
two
two
pieces
of
work
ahead
of
you
before
letting
reissa
and
eric
talk
about
the
drafts.
The
design
team
has
worked
on
two
things:
the
the
definitions
and
framework
based
on
the
good
feedback
from
the
working
group,
and
I
think
we
heard
comments
from
the
working
group
we
took
them
to
heart,
and
hopefully
the
drafts
are
much
improved,
not
perfect.
L
L
First
of
we
believe
less
is
more
so
so
this
version-
or
these
versions
are
actually
trying
to
be
like
a
minimalistic
frameworks
that
they
cover
some
aspects
or
some
characteristics
that
one
might
wish
to
have
for
once
slices
or
connections
things
that
the
customers
can
request.
It
doesn't
cover
everything.
Things
can
be
extended,
but
it's
been
problematic
to
sort
of
try
and
cover.
L
You
know
everybody's
favorite
things
and
so
rather
take
this
minimalistic
approach
and
the
second
issue
that
we've
worked
quite
a
bit
on
is
sort
of
clear
separation
between
requirements.
The
customer
asks
for
these
characteristics
for
for
the
connections
and
and
then
the
way
that
that
gets
realized
or
implemented,
and
that
shows
up,
in
particular
with
the
context
of
isolation
and
the
terminology
around
that,
and
the
current
draft
tries
to
make
it
clear
that
you
have
some
some
requirements
that
typically
about
like
you
know.
We
want
this
bandwidth.
L
L
M
M
This
is
the
first
draft
in
nsdt
we
started
with
the
definition
of
the
transfer
sliced
from
the
very
high
level.
We
define
the
transfer
slice
to
be
a
group
of
connection
between
values
and
points
with
the
specific
slo
that
we
want.
So
this
is
from
high
level
in
the
draft.
We
went
through
detail
of
that.
What
does
it
exactly
mean?
M
M
We
discuss
about
the
transport,
slice,
controller
and
interface
to
that
from
the
northbound
nbi
from
the
southbound
and
in
a
specific
nbi,
and
also
how
we
put
an
example
at
the
very
end
that
how
a
transverse
light
fit
in
the
ecosystem
of
the
end-to-end
network
as
well.
This
was
very
good.
The
basic
introduction
to
just
give
a
context
of
where
the
transfer
slides
face
in
the
the
overall
end-to-end
network.
M
So
if
you
go
to
the
next
slide,
these
are
the
changes
it's
coming.
I
guess
these
are
the
changes
from
107..
It
is
very
important
to
consider
that
the
existing
draft
that
you
would
see
is
basically
the
work
of
around
15
20
people
for
last
three
months,
so
we
had
a
weekly
meeting
between
co-authors.
We
had
the
weekly
meeting
between
the
all
nsd
team.
We
had
spent
lots
of
time
going
through
the
emails
and
the
discussion
and
basically,
whatever
you
see,
is
a
by-product.
M
After
all
those
discussions,
we
try
to
consider
all
the
suggestions
that
we
get
from
the
previous
one.
The
there
was
joel
adrian
other
people.
Basically,
given
the
comments.
For
example,
we
add
rfc's
draft
references
to
the
existing
draft,
why
we
are
using
transfer
slice
term.
What
is
the
meaning
of
the
transport
in
this
context?
M
All
are
added
and
we
try
to
give
the
reference.
In
addition
to
that,
there
are
lots
of
discussion
during
the
nsdt
meeting
about
the
objective
slos.
So
we
then,
at
the
very
end,
define
a
group
of
minimal
set
of
the
objectives
which
are
directly
measurable,
like
a
bandwidth
latency,
so
on
indirectly,
measurable,
but
security
restriction
for
geographical
location
and
so
on
and
other
objectives
that
it's
not
really.
M
Neither.
No.
We
want
to
have
some
characteristics
which
are
optional.
We
want
to
have
some
mtu.
We
want
to
have
some
implementation
of
the
transfers,
but
using
various
techniques,
our
technology,
those
are
obviously
optional-
and
last
but
not
least,
we
added
the
or
we
had
lots
of
discussion
about
isolation.
M
In
a
specific
this
topic,
I
remember
we
discussed
it
at
least
four
few
weeks
and
eventually
we
moved
that
one
to
the
appendix
it's
a
kind
of
realization
if,
as
also
jori
mentioned
at
the
very
beginning
of
this
meeting,
that
we
feel
that
isolation
like
any
other
objective,
are
a
way
of
realizing
a
transfer
slice,
a
customer
send
a
request
to
us
to
create
a
transfer
site
and
when
we
want
to
realize
that
in
the
network
implemented
internet
work,
the
isolation
will
come
to
that
picture
from
that
aspect.
So
we
move
everything
to
appendix.
M
M
M
What
is
the
relationship
between
that
and
he
links
the
termination
points
and
also
similarity
between
that
and
termination
points
which
is
defined
in
8345.
We
basically
clarify
all
these.
If
you
go
to
the
drive,
you
will
see
that
we
put
the
the
logical
reasons
why
we're
introducing
that?
What
are
the
differences
and
similarities
and
also
we
introduced
a
new
concept
of
the
transverse
light
realization
input.
M
M
G
G
We
presented
the
status
last
actually
not
at
ietf
107,
but
the
interim
in
april
23rd.
I
think
it
was
I'm
not
sure,
and
no
one
had
any
questions
at
that
time,
but
we
have
had
some
changes
that
you
know
ripple
through
and
and
so
the
presentation
in
the
in
the
intermediating
information
is
right
there.
The
current
summary
is
it's
not
requirements
or
architecture.
It's
a
framework.
G
G
Okay
changes
this
time,
so
the
editorial
changes
some
minor,
abstract
table
contents
introduction
changes,
did
some
capitalization
consistency,
improvements
for
transport,
slides,
telemetry
statistics,
states,
et
cetera,
consistent
with
the
definitions
draft
as
well.
So
a
lot
of
the
same
changes
or
at
least
that
we're
trying
to
be
consistent
between
the
two
punctuation
and
usage
corrections.
There's
a
couple
of
places
where
there
was
text
that
just
was
hanging
around
or
there
was
issues
with
punctuation.
G
There
was
a
paste
error.
I
correct,
I
actually
included
the
same
reference
twice
and
then
one
place
that
was
actually
the
numbers
were
transposed,
and
so
we
had
to
correct
that
and
remove
this
digital
or
redundant
text,
and
then
we
had
to
do
the.
You
know,
of
course,
that
we
used
the
make
process
in
github
and
so
the
usual
reference
updates
were
done
without
our
explicit
interference.
G
G
We
had
to
deal
with
the
interrupt
interpretation
of
the
roles
in
actin
as
they
relate
to
the
transport
slice,
controller
and
the
northbound
interface
and,
to
a
lesser
extent,
to
other
concepts
that
we
deal
with
in
a
definitions
draft
and
there
may
may
not
actually
be
in
scope
for
the
for
the
rest
of
the
work
like
the
southbound
interface
and
the
pnc,
and
so
on.
So.
G
So
the
applicable
interpretation
is
one
where
the
mdsc
more
or
less
maps
to
the
transport,
slice
controller
and
the
cnc
more
or
less
maps
to
the
higher
level
function.
That
is,
the
consumer
of
network
slices
or
transport
slices
and
so
other
roles
where
there's
app
overlap
and
then
rolls
it
kind
of
make
the
applicability
somewhat
questionable.
G
And
so
we
we
kind
of
deal
with
that
in
the
text
in
the
applicability
section,
and
then
we
also
clarified
that
that
this
is
one
potential
interpretation
of
the
acetn
architecture
or
description
or
whatever
to
call
it
and
so
next
screen.
Please
next
slide
so
currently,
pending
changes,
we
got
last
minute
comments
from
at
least
one
of
the
design
team
members
and
so
and
there's
also
a
discussion.
That's
ongoing
really
regarding
some
other
things.
G
G
G
We
need
some
text
to
resolve
some
other
issues
like
net
network
structure
and
topology,
there's
some
confusion
of
using
one
term
or
the
other
term
in
different
places.
So
we
need
to
kind
of
clean
that
up.
We
need
to
resolve
issues
with
references
for
existing
technology
and
object,
objections
to
related
references
to
the
vpn.
I'm
sorry
repeated
references
to
the
vpn
plus
draft
of
the
enhanced
vpn
map
and
there's
a
section
heading
which
it's
been
suggested
suggested
that
we
use
objective
rather
than
intent.
G
The
issue
is
that-
and
this
kind
of
relates
to
the
earlier
comment
about
bringing
in
the
definition
of
service
level
objective
a
little
earlier.
Is
that
we're
not
defining
service
level
objectives
in
this
section?
What
we're
trying
to
talk
about
is
what
it
is
that
the
transport
slice
consumer
would
be
asking
for.
G
G
That
doesn't
mean
we
don't
need
to
have
some
description
of
it.
We
have
it
in
the
definitions,
draft,
it's
sort
of
a
logical
concept,
but
there's
physical
instances
of
a
southbound
interface,
the
l2
sm,
the
l3
sm
and
some
others,
and
there
are
some
applicability
statements
that
are
out
there,
that
related
to
like
a
ctn
and
pli
and
actn
and
traffic
engineering
of
in
that
that
are
specific
to
technologies.
G
G
Okay,
discussion
of
a
ctn
applicability,
there's
a
resurrected
draft
that
specifically
addresses
applicability
of
acpn
to
te
network
slicing.
I
kind
of
mentioned
this
earlier.
It's
the
draft
king
ts,
flexibility,
acpn,
slicing
version,
four
expired
april,
2019
new
version,
five
and
six
were
posted
in
june
and
july
this
year,
so
they
weren't
on
our
radar,
but
we
need
to
actually
sort
of
factor
them
in
so
this
it
it.
G
So
this
draft
outlines
a
ctn
applicability
specifically
for
key
networks
using
ietf
technology,
which
is
right,
it's
good,
but
it
sort
of
then
becomes
technology,
specific
and
so
sort
of
falls
into
the
outer
scope.
But
we
need
to
talk
about
it
again.
As
I
mentioned
about
the
other
other
technology
specific
stuff,
we
need
to
talk
about
it,
and
so
we
should
probably
include
a
reference
in
our
a
ctn
applicability
document
section
and
and
then
maybe
we
can
eliminate
some
of
what
we
have
in
there
now
next
slide.
Please.
G
G
G
A
M
K
K
In
sctn
we
did
we
defined
the
interface
between
the
cnc
and
the
mdsc
as
a
boundary
between
the
customer
and
the
operator,
in
my
opinion,
not
not
an
epi
decision,
because
we
are
now
lacking
an
interface
or,
let
me
say,
an
attachment
point
between
an
higher
level
of
operations
in
the
in
the
operator's
network
and
the
and
the
transport
so
you're
perfectly
right
in
speaking
about
the
consumer
as
opposed
to
customer.
This
is
something
that
we
would
like
to
fix.
K
Probably
with
the
poi
team.
We
are
trying
to
identify
a
a
new
interface
or
better
a
a
different
declination
of
the
cmi
that
can
be
used
between,
for
example,
the
oss
team
and
the
transport
team
within
the
operator,
as
opposed
to
the
customer
talking
to
the
to
the
operator-
and
this
is
the
very
good
that
you
spot
this,
this
limitation
on
the
mdsc
ruler.
I
perfectly
agree
with
that.
I
A
A
All
right
well,
we're
we'll
take
it
to
the
list
and
look
for
support
and
objections
on
the
list.
So
with
that,
thank
you
very
much
excellent.
Thank
you
all
right,
so
we
are
now
moving
into
a
set
of
five
individual
drafts.
We
I
originally
thought
to.
I
just
dropped
the
last
one,
but
I
don't
think
that's
fair,
since
they're
all
individual-
or
I
should
say,
suggest
it's
not
fair
and
we
agreed
that
we're
going
to
try
to
split
the
remaining
time.
N
N
Right
so
we're
talking
about
the
model
here,
and
this
is
the
model
trying
to
use
the
existing
ietf
network
topology
models.
We
already
have
a
set
of
models,
including
the
base.
It
is
345
based
network
quality
model
and
based
on
that,
we
have
layer,
2
layer,
3te
on
top
of
that,
and
so
please
go
to
the
next
slide.
N
N
So
here
the
way
we
model
this
we'll
use
the
existing
models
and
we
make
the
slicing
model
a
multiple
inheritance
model.
So
we
mark
this
model
as
a
type
network
sizing
and
whenever
a
particular
technology
is
applicable,
so
we
will
have
that
the
project
type
also.
So
in
this
case
we
can
hide
both
slicing
and
the
t
next
slice.
N
N
N
So
here
we
have
two
examples:
one
example:
here
we
are
using
the
virtualization
to
achieve
the
sizing,
and
so
the
network
slicing
now
we're
trying
to
realign
the
terminology
once
the
sizing
definition
model
is
finalized,
so
the
slicing
model
can
be
either
t
capable
or
non-t
capable.
In
this
case
we
use
a
virtualization
technology
which
is
not
te-based,
and
so
we
have
a
physical
router
on
top
of
it.
N
On
top
of
the
physical
router,
we
can
do
the
virtualization,
as
each
physical
router
will
have
a
few
virtualized
virtual
water,
and
on
top
of
the
virtual
router,
we
can
have
a
slice
in
this
case
we'll
have
blue,
which
each
node
map
to
a
virtual,
router
and
again
map
to
the
very
low
level
physical
router.
Next
slides.
Please.
N
N
N
N
N
N
Wrap
up
right
so
here
is
a
conversion
data
and
this
example.
So
whenever
we
have
been
talking
about
the
definitions
and
the
frameworks
find
they
are
all
finalized
within
the
working
group,
we
are
aligned
to
all
the
documents
and
then
we
welcome
reviews
and
suggestions.
So
next
step
will
also
be
working
with
adoption.
Thank
you.
A
A
O
O
O
Piece
since
just
like
chiffon
just
also
talked
about
the
the
83
45
augmented
network
model,
they
also
think
in
our
draft.
We
also
give
a
comparison
with
the
some
candidate
transport
slice
model
definition
sayings,
there's
a
mapping
in
the
transport
slice
framework
draft,
this
current
ac
tn
framework
and
also
the
transport
slice
architecture.
O
O
Abstract
model,
so
we
are
thinking
the
actin
or
the
network
model
could
be
composed
compared,
but
we're
thinking
that
this
transfer
slice
model
is
quite
a
customer
view
model
and
they
don't
talk
about
network
detail.
So
we
were
thinking.
Shuffling's
model
were
related
with
transfer
slice,
realization
model
so,
and
we
also
borrow
some
and
vm
model
is
more
tea
specific.
So
we
are
thinking
we
try
to
borrow
some
modeling
design,
mod
method
from
the
ac
tmv
model
and
create
this
new
model.
Next
piece.
O
O
We
directly
use
the
like
transfer,
slice
definition
and
ts,
transpose
lines
and
point
definition
from
the
definition
draft,
but
we
introduce
two
ts,
member
and
as
a
group
to
to
implement
like
multiple
slo
in
in
a
one
transport
slice
and
also
for
monitoring
the
transfer
slice
status.
So
these
are
next
piece.
O
O
O
O
Piece,
oh
yeah,
and
also
there
are
another
one
because
try
right
now.
The
transfer
slice
is
more
of
is
the
like
the
technology,
agnostic
definition,
but
there
we
think
there
may
be
some
technology
specific,
maybe
introduced.
So
I
next
piece
just
go
recap
about
this
model,
so
we
we
we
give
the
the
open
v
issues
of
this
modeling.
So
we
we
like
to
hear
more
comments
and
suggestions
from
the
from
working
group
to
see
whether
there's
some
other
suggestion
from
the
working
group.
A
We're
out
of
time
on
this
topic,
it's
an
important
one
and
there's
as
devon
put
into
the
chat
two
approaches
here.
Also
the
notion
of
augmentation
versus
new
model.
These
are
important
things
that
we
should
discuss
on
the
list
italo.
If
that's
okay,
we'll
take
it
to
the
list.
If
it's
critical,
okay,
thanks
atala,
so
we're
gonna,
move
on.
C
The
controllers
will
calculate
st
paths
and
to
steer
traffic
in
across
the
network,
but
that
may
still
not
be
enough
with
that.
The
last
scale
and
many
many
slices
the
controllers
could
be
overwhelmed,
especially
when
you
consider
that
if
you
have
to
do
multicast,
the
controllers
may
also
have
to
do
a
lot
of
calculations
for
multicast
trees.
Next
slide.
Please.
C
So
the
proposal
here
is
what
we
call
flexible
te,
because
it
combines
the
flexible,
algorithm
and
srt
paths.
We
upload
the
per
algorithm
pass
calculation
to
edge
routers
and
then
with
that,
like
with
the
controller-based
approach,
the
internal
routers
do
not
need
to
maintain.
The
information
do
not
need
to
do
the
calculation
and
even
the
edge
routers.
They
only
need
to
know
the
information
that
they
really
care
about.
If
does
not
need
to
know
about
the
slice
and
and
then
it
does
not
need
to
know
information
about
the
slice
at
all.
C
C
So
the
key
here
is
the
use
of
a
new
raw
target
called
bitmaster
wall
target.
So
the
computers
are
pro
configured
with
link
administrative
groups
for
all
links
coming
in
the
lags
that
the
I'll
just
refer
to
them
as
link
colors,
as
people
normally
do
so.
The
routers
are
not
configured
with
that
information,
but
only
controllers
are
provisions
and
then
the
controllers
will
originate
linkedin,
rois
and
distribute
using
the
southbound
pdp
os.
C
C
So
with
that
we
can,
we
can
very
efficiently
distribute
the
information
only
to
target
routers.
For
example,
if
you
have
a
link
with
it's
covered
with
red
and
blue
and
a
link,
nri
will
carry
a
bitmaster
out
target
with
two
bits
set
for
red
and
blue
and
now,
if
a
router
cares
about
red
link,
then
it
it
is
configured
with
the
bitmap
material
target
with
the
red
bits.
C
C
So
the
summary
we
use
centralized
provisioning
and
signaling
of
flexible
algorithm,
algorithm
information
using
and
using
this
new
bitmaster
raw
target.
We
can
do
the
targeting
distribution
very
efficiently
and,
and
then
those
edge
routers
will
be
able
to
do
the
sd-rt
path
calculation.
But
that's
the
basic
idea.
A
If
you
could
just
send
it
to
the
list,
we
really
appreciate
the
comments
and
we're
sorry
running
late.
As
I
mentioned
in
chat,
we
give
sort
of
priority
to
time
to
working
group
documents
and
working
group
charter
topics.
So
these
these
are
all
new,
so
we're
we're
definitely
squeezing
them
so
apologize
for
that.
A
Q
Q
Yes,
ai
administration
issues
in
other
compiler,
explicit,
visual
network
administration.
It
could
be
used
as
exchange
license
failures.
It
indicates
the
topology
computing
storage
resources
of
the
dedicated
virtual
network.
There
are,
let's
see
the
feature.
A
talking
feature
of
the
area
is
identifier
of
the
dedicated
virtual
network
for
the
slides
and
supports
the
end-to-end
slicing.
Q
Q
Q
Q
A
I
I
cannot
hear
you,
I
don't
know
if
others,
I
occasionally
purple
speech,
we're
actually
pretty
much
out
of
time,
so
I
think
we
really
would
like
to
discuss
it
unless,
as
I
mentioned
in
jabber,
we
give
priority
to
you,
know
the
chartered
activities
so
sorry
about
squeezing
these.
We
have
just
a
few
minutes
left
we're
gonna
move
on
apollo.
K
R
Okay,
yes,
life
is
okay:
I'm
italo
boozy,
I'm
presenting
this
new
draft
foreign
topology
next
slide:
okay,
history:
this
draft
has
been
presented
in
itf
104
as
mplstp
topology,
and
the
feedback
from
the
working
group
was
that
people
will
prefer
to
integrate
tp
capabilities
into
the
models.
There
has
been
a
lot
of
discussion
with
the
young
model
otters.
R
The
output
of
the
discussion
is
that
we
have
an
mplst
topology,
which
is
this
rafter,
and
to
update
the
mplsd
tunnel
to
support
the
empty
sdp
capabilities,
and
we
share
this
output
on
the
main
list.
From
of
both
these
and
mpls
working
group
a
couple
of
weeks
ago,
I
think
you
can
go
to
slide
number
four
last
number:
three
is
just
a
recap
of
the
original,
so
the
solutions
now
is
the
mpstp
key
topology
is
defined
as
an
augmentation
of
the
packet,
the
topology
following
the
projects
cast
in
rtf-106
next
slider.
R
Okay
for
the
mpls
cp,
okay,
we
thanks
all
the
participants
on
the
young
discussions
and
we
we
described
in
section
302.
We
described
exactly
how
the
the
drop
the
model
is
applicable
to
ample
stp
so
for
b
direction.
Lsp
everything
is
already
covered
by
the
t
topology,
so
nothing
special
is
needed
for
ecmp.
We
have
added
an
attribute
to
report
whether
the
lag
or
a
t
bundle
link
is
performing
load
balancing
on
a
perf
row
on
a
per
top
label.
The
latter
option
will
be
asset
which
will
be
required
by
mplsdp.
R
The
former
can
be
used
by
mplsde
generic
for
php.
We
report
whether
an
ltp
is
not
capable
to
support
ultimate
or
popping
such
that
when
you
do
power
computation
for
an
mlstp
lsp,
you
can
avoid
to
enter
the
last
node
from
that
ltp
and
the
gal
we
think
is
outside
the
scope
of
this
rough
is
more
related
to
oem
capabilities.