►
From YouTube: IETF100-TEAS-20171114-0930
Description
TEAS meeting session at IETF100
2017/11/14 0930
https://datatracker.ietf.org/meeting/100/proceedings/
A
Good
morning,
welcome
to
our
only
first
and
only
session
of
teas
here
in
Singapore
before
I
get
started,
I'd
like
to
make
a
request
to
presenters.
Please
try
really
hard
to
get
us.
Your
slides
at
least
the
night
before
the
session.
Getting
things
to
us
in
our
five
minutes
before
mean
you're
gonna
get
your
old
version
because
sometimes
like
right
now
we
weren't
able
to
download
for
some
reason,
I,
don't
know
what
was
going
on,
but
I
bet
that
we
were
not
able
to
download
the
latest.
A
A
A
Can
you
hear
me?
Oh
okay,
sorry
about
that.
So
that's
a
fitting
time
to
point
out
that
you
couldn't
hear
me
because
please
do
type.
It
talked
at
the
microphone.
We
are
recording
both
video
and
audio.
So
that's
really
important.
Also
for
remote
people.
It's
quite
helpful.
Please
also
say
your
name
for
the
minutes.
We
are
take
using
etherpad
as
usual.
You
can
find
it
off
the
tools
page.
This
is
the
shortened
version.
A
If
you
go
to
tools,
IPS
or
working
group,
these
minutes,
as
shown
on
the
screen,
you
can
help
contribute
to
the
minutes,
even
if
you're
not
going
to
write
anything,
please
go
there
and
make
sure
comments
that
you
make
or
comments
that
you
hear
are
correct
and
feel
free
to
edit.
That-
and
this
applies
both
for
people
that
are
in
the
room
as
well
as
listening
remotely
and
you'll,
see
that
we
do
have
a
few.
A
A
A
We
have
a
few
documents
that
are
preparing
for
last
call
we're
moving
these
forward
as
a
set
did
have
well
we'll
come
to
I
have
a
question
on
one
of
these
we'll
come
to
that.
In
a
moment,
we
have
two
new
working
group
documents
and
we
have
several
working
group
documents
that
we
expect
to
adopt
based
on
how
things
have
progressed.
A
A
It's
really
important
to
have
conversations
on
the
working
group.
This
is
mailing
list.
This
is
particularly
notable
for
those
who
are
authors
of
working
group
documents.
If
you
are
an
author
of
a
working
group
document-
and
you
want
to
make
a
change-
and
you
talk
to
them
out-
talk
among
yourselves
and
get
agreement
and
publish
that
change-
that's
okay,
but
that
doesn't
constitute
working
group
consensus.
What
constitutes
working
group
consensus
is
getting
buy-in.
So
if
you
work
on
in
private
and
then
publish
a
change,
you
then
have
to
have
a
discussion
with
the
working
group.
A
While
you
made
that
change
and
be
open
to
reverting
that
change.
On
the
other
hand,
if
you
have
the
discussion
on
the
working
group
mail
list,
even
between
the
authors,
anyone
in
the
group
has
an
opportunity
to
contribute
to
chime
in
and
at
the
end
of
a
discussion
on
list.
If
agreement
is
reached,
that
is
consensus.
So
it's
really
important
to
use
the
list,
even
among
just
authors,
discussion
of
working
group
documents.
A
B
How
about
now,
can
you
guys
hear
me?
Okay,
okay,
we
have
20
active
working
of
documents.
There
are
six
in
the
post
publication
requested
process,
the
three
for
which
we
just
finished
last
call.
There
are
three
for
which
we
are
about
to
commence
last
call.
We
have
two
brand
new
working
group
documents:
the
zero
zero
versions
of
those
got
published
yesterday
so
of
the
remaining
six
three
or
on
the
agenda
today,
so
I
will
go
at
the
status
of
the
remaining
three
in
this
slide.
B
Deck
first
up
is
the
associated
core
outed
bi-directional
life
for
our
draft,
a
revision
for
this
was
published
yesterday
the
changes
were
included
alignment
with
RSC
82
71,
that's
the
GMP
lsfr
our
document
and
an
addition
of
a
section
that
talks
about
one-to-one
backups.
This
was
published
yesterday.
So
please
do
give
this
a
read
and
reach
out
to
the
authors
on
the
list.
If
you
have
any
questions
or
concerns
next
is
the
PCE
CC
use
cases
document?
We
did
not
receive
an
update
for
this.
There
were
no
change
to
the
draft.
B
Since
the
last
ITF
meeting
there
was
in
the
status
update
that
was
sent
prior
to
the
last
meeting.
The
authors
did
indicate
that
they
wanted
to
add
additional
use
case.
I,
don't
know
if
that's
still
part
of
the
plans.
If
there's
somebody
from
the
author's
side
either
here
in
this
room
or
remote,
it
would
be
useful
if
they
can
chime
in
now
and
give
an
update,
I,
don't
see
anyone
approaching
the
mic.
We
will
try
and
reach
out
to
the
author's
offline
and
see
if
they
can
send
a
status
out.
B
Next
is
the
tea
metric
recording
draft
this
expired
a
while
ago
we
even
stopped
discussing
this
on
the
list.
The
others
suddenly
woke
up
last
night
and
published
a
new
Rev
there's
still
some
outstanding
comments
from
mid
last
year
that
need
to
get
addressed.
So
in
terms
of
next
steps.
The
authors
would
need
to
discuss
this
on
the
list
and
stay
awake
for
the
rest
of
the
process.
That's
all
I
have
in
this
deck.
B
So
the
for
some
reason
this
turn
out
to
be
really
messy
this.
This
is
an
update
on
network
assigned
upstream
label
draft
and
one
of
the
co-authors
doing
ad
evaluation
develop
on
a
few
issues
with
us.
We
submitted
a
revision
late
last
month
addressing
those
concerns.
This
slide
goes
over
the
changes
that
we
made.
The
document
now
updates
our
se
is
3471
and
6205.
This
is
in
addition
to
updating
our
SC
3473.
B
B
We
also
added
a
request
to
include
a
new
sub
registry
for
the
for
special
purpose:
generalized
label
values,
the
all
one's
pattern
that's
used
in
this
drive
for
upstream
label
is
the
only
one
in
this
registry.
For
now,
we
also
added
some
text
to
clarify
the
scope
of
the
procedures.
The
scope
of
the
procedures
is
limited
to
the
exchange
and
processing
of
the
messages
between
given
up
seen,
node
and
its
downstream
node.
With
these
set
of
changes,
we
believe
that
all
the
concerns
raised
so
far
have
been
addressed.
A
A
B
This
is
an
update
on
the
rsvp-te
scaling
techniques
draft.
There
were
some
comments
and
questions
raised
on
the
mailing
list
during
the
iesg
review.
We
address
all
of
those
this
slide
in
the
next
will
give
you
an
overview
of
the
changes
that
we
made
and
the
highlight
the
discussions
that
we
had
on
the
list.
The
first
thing
we
changed
was
the
title:
it's
now
title
techniques
for
improving
scalability.
B
If
rsvp-te
deployments,
we
added
a
statement
in
the
introduction
saying
that
the
support
of
capability
object
is
a
prerequisite
for
the
two
techniques
Tiff's
discussed
in
the
draft.
We
have
an
appendix
in
the
draft.
We
were
asked
to
add
reference
from
the
main
text
to
the
appendix
we
did
that
we
were
asked
to
add
abbreviation
for
periodic
retransmission
intro
for
unacknowledged
part
and
receive
messages.
We
did
that.
We
were
also
provided
some
good
tech
solutions
by
Allen
Davis
to
improve
overall
readability
of
the
draft.
We
accepted
that
and
acknowledged
his
contribution.
B
B
They
sent
text
in
a
draft
that
talks
about
retransmission
of
unlike
Pathan
Rossini
sages
after
the
rapid
retire
limit
is
reached.
There
were
some
questions
on
whether
this
violates
any
of
the
RSC
2961
procedures.
We
clarified
that
on
the
list
and
said
that
that
isn't
the
case,
there
is
a
question
whether
these
techniques
are
enabled
by
default.
The
answer
is
yes,
that
that's
what
is
recommended
in
the
draft
there's
a
question
on
what
happens
when
a
Refresh
reduction
capability
is
deactivated.
B
Rr
is
a
prerequisite
for
the
two
techniques,
so
deactivation
of
the
fish
reduction
would
result
in
the
activation
of
RI
RSVP
and
per
Pia
flow
control.
All
of
that
is
documented
in
the
draft.
At
this
point,
we
don't
believe
that
there
are
any
open
issues.
We
believe
that
all
the
questions
and
comments
that
have
been
raised
over
have
been
addressed,
so
the
next
step
would
be
to
get
by
is
giving
us
a
pull
this
and
get
this
document
progressed
to
the
next
stage.
A
C
Morning,
my
name
is
dieter
Beller
I'm,
one
of
the
core
editors
of
the
LSP
diversity
draft.
This
is
a
very
brief
status,
update
of
what
has
been
what
what
happened
with
the
draft
and
what
the
next
steps
are
current
status,
the
LSP
diversity
did
undergo
the
iesg
directorate
review.
The
outcome
was
that
it's
approved
and
that
revised
IDs
needed.
We
actually
received
quite
a
number
of
review
comments
from
the
reviewers
and
we
were
able
to
address
all
the
comments,
but
two
are
still
missing.
C
C
D
D
D
D
D
D
Prague
ID
so
the
neutralizer
medical
discovery
mechanism
and
in
each
of
them
desires
to
have
a
separate
range,
so
we
change
the
type
from
nomensa
to
talk
to
a
wearable,
and
so
here
the
changes.
The
top
case
is
the
black
ID
and
also
we
move
to
the
bottom
portion
and
then
makes
the
type
change
another
change
idea.
There
will
be
some
common
attributes
between
our
model
and
other
occupation
models,
so
we
can
solid
em
together
put
in
here,
so
that
the
the
augmentation
models,
don't
all
do
the
repeated
work.
A
That's
that's
a
reasonable
number.
How
many
of
you
are
looking
to
augment
this
model
or
in
like
gcapp?
That's
a
pretty
good
amount
to
if
you
are
working
on
an
augmentation
I'd,
really
like
you
to
take
a
look
at
the
new
section
on
augmentation
guidance
and
make
sure
that
it
makes
sense
to
you
and
that
aligns
with
how
you're
planning
to
use
it
and
that
it
will
be
useful
for
the
next
person
who
comes
behind
you
to
do
an
augmentation.
A
This
is
really
the
last
section
that's
holding
up
the
document,
so
please
take
a
look
at
it
in
the
next.
If
you
do
it
this
week,
that
would
be
great,
but
maybe
within
the
next
the
week
after
ITF
and
once
you've
looked
at
it,
please
send
a
message.
Just
saying
looks
good
and
after
we
get
a
few
of
those
we'll
proceed.
What
would
be
even
better,
though,
is,
if
you
say,
you'd
like
to
see
a
change
in
it.
A
The
it's
really
important
that
our
documents
not
only
help
the
people
that
are
currently
looking
at
it,
but
the
next
readers
that
come
along,
and
particularly
something
like
this,
which
is
foundational,
we're
hoping
that
it's
worked
on
by
people
that
are
not
in
this
room
and
it's
important
that
we
capture
the
ideas
so
that
they
can
benefit
from
what
we
know
and
what
we
understand.
Thank
you,
I'm,
hoping
we'll
have
in
the
next
two
weeks,
proceeded
on
it
with
a
submission
for
publication.
F
E
E
E
G
E
E
E
So
bi-directional
tunnel
support
added
so
for
each
primary
path.
There
is
a
reversed
primary
path
and
for
each
reverse
primary
path.
There
is
a
reverse
secondary
path,
so
for
the
core
outed
by
the
external
LSPs,
we
don't
really
need
the
reverse
path,
so
it
can
be
auto
created
that
matches
the
forward
path.
E
E
E
E
E
E
G
A
H
A
There's
a
SR
model
Sonya.
Does
it
make
sense
to
now
that
the
work
detective
work
is
all
done?
Does
it
make
sense?
The
publishes
is
three
separate
documents
so
that
there's
it
separately
referenceable
generally,
we
try
not
to
put
different
to
different,
essentially
technologies
into
the
same
document
and
to
be
clear.
What
I'm
talking
about
is
a
reformatting
of
the
current
work,
publishing
publication
immediately
as
working
group
documents
and
then
moving
to
the
last
call
we're
not
talking
about
a
process
reset
or
anything.
Here.
It's
really
just
a
publication
piece,
yeah.
E
A
A
A
A
D
D
D
A
It
could
be
an
update
to
our
if
it's
an
update,
that's
not
a
big
deal,
because
that's
just
an
update.
If
it's
a
dis,
then
that
does
become
a
problem
because
then
you
have
to
be
revving
models
that
you're
not
revving,
a
document
that
contains
models
that
you're
not
really
changing
I.
Do
you
think
that
it's
an
update,
or
do
you
think
it's
abyss
and.
A
I
Just
brief
the
ground
or
the
model
structure,
the
model
startled
by
primitives
that
represent
a
network,
the
basic
action
needed
to
support
a
city,
a
network
function
and
this
primitives
Archer
at
arise
by
object
and
properties.
The
object
are
the
real
asset
en
resources
that
need
to
be
exchanged
on
the
interfaces
define
in
a
city
and
ok,
the
updates
from
the
to
version
I.
I
This
is
our
to
version,
because
the
version
3
practically
is
just
the
changing
of
the
name
of
the
physical
network
controller
that
is
moving
from
physical
network
controller,
to
provision
at
a
controller,
and
so
the
major
update
is
from
version
2
and
the
basic
modification
has
been
a
heavier
structure
of
the
day
after
separating
explicity.
What
are
the
primitives
that
is
related
to
the
real
troll
network
management
and
the
primitives
that
are
related
to
the
traffic
engineering?
I
I
Then
we
have
a
consequently
redefine
refiner.
They
some
part
of
the
objects,
so
we
added
the
vehicle,
not
a
topology,
we'll
turn
that
on
man,
Lander
definition
and
they
are
refine
tunnel
much
autistic
and
that
yet
an
atlatl
is
yet
yet
topology
update
and
that
generally
fight
among
the
object
and
then,
as
I
said,
the
change
of
the
name
on
the
physical
motor
controller
to
provisional
metal
control.
I
So
they
start
to
is
based
on
the
separation
between
the
virtual
network,
primitive
nuts,
as
as
me,
I,
in
which
there
is
no
need
it
for
the
taste
of
engineer,
information
and
the
basic
functionality
is
to
translate
what
are
the
customer
information
service
information
into
the
application?
The
virtual
network
service
instead
in
the
traffic
Ginga
at
any
eye
level,
the
basic
functionalities
to
create
an
end-to-end.
I
Coordination
between
a
multi
balloon
and
for
data
to
create
a
loan
to
an
abstracted
network
in
which
the
traffic
information
is
extension
according
to
different
definition,
guarding
topology,
the
virtual
motto
topology-
that
is
a
customer
view,
topology
for
a
view
at
the
control,
the
customer
and
the
traffic
gene
topology.
That
instead
is
based
on
what
is
the
real
provider
network
resources
and
in
which
you
can
apply
policy
to
decide
whether
they'll
be
correct
and
they
will
level
of
abstraction
to
a
presented
a
and
the
languorous
sources.
I
Computation
Victoire,
not
a
pod
computation
that
is
just
exploring
a
just
a
priori
exploration
to
compute
note
or
a
source
adjust
whether
to
prove
availability
of
resources
and
when
the
query
and
the
virtual
network
date
in
parallel
need
to
find
the
related
traffic
engineering
action.
Primitives
related
to
MPI.
So
with
the
RAF
engine
instance
eat.
They
modified
the
delayed
at
the
path
computation.
I
Core
secretary,
you
have
the
finest
and
said
before
you
object,
that
is
the
virtual
network
topology
and
both
for
the
virtual
network
and
the
traffic
engine
topology
that
I
listed
here.
So
basically
the
Violeta
topology
definition
and
the
traffic
gene
topology
definition,
and
here
is
the
mapping
of
the
primitives
with
the
new
object
and
also
the
only
one
and
all
the
the
definition
of
the
primitives
mapping.
All
the
related
object
with
a
clear
separation
between
the
earth,
one
Network,
primitives
and
traffic
Genie
primitives
so
has
represent
of
the
co-authors
of
the
Java.
I
A
Comments
questions
at
the
last
meeting.
There
was
a
comment
on
actually
a
different
document
related
to
type
1
and
type
2,
and
how
much
different
do
they
really
need
to
be
in
your
document?
While
you
define
type
1
type
2,
you
don't
identify
different
sets
of
information
elements
needed
to
support
each
correct
ooh.
A
A
G
I
A
That's
good,
so
the
plan
right
now
is
to
move
this
document
as
a
set
with
the
framework
and
the
requirements
to
move
those
all
together,
as
set
through
last
call
so
be
prepared.
For
that.
Take
a
look
at
the
documents
you
can
send
comments
before
the
last
call
comes
out,
but
I
think
we
just
have
to
make
sure
that
all
the
IPR
disclosures
are
in
and
once
that's
done,
we're
going
to
do
the
law
issue.
The
last
call.
K
Okay,
good,
okay,
good
morning
good,
my
name
is
Tommy
and
I'm,
going
to
present
to
this
new
draft
applicability
of
your
models
for
a
city.
This
is
a
draft,
a
newly
adopted
by
the
working
group,
so
this
graph
that
actually
explains
to
how
the
different
of
the
IETF
young
models
can
be
applicable
to
the
ICT
and
framework,
including
both
of
those
controllers
and
the
corresponding
interface.
So
the
P,
the
models
are
divided
into
a
few
different
categories.
K
The
first
kind
of
model
is
called
customer
service
models
and
we
describe
the
application
in
the
asic
in
architecture
called
CMI,
and
then
it
is
a
service
delivery
model
in
the
ICT
architecture
which
is
in
in
the
inside
NDRC,
and
it
can
be
used
of
internal
model.
And
finally,
the
network
configuration
models,
I
even
used
in
the
exiting
architecture
in
the
MPI
interface,
and
the
objective
is
mainly
for
the
multi
vendor
interoperability.
B
L
So
my
name
is
Michael
sharp.
So
on
that
slide,
could
you
comment
on
the
difference
between
the
service
model
that
you
mentioned
here
and
what
a
VN
member
is
because
I
think
this
draft
somehow
doesn't
clearly
define
what
is
the
service
model,
for
example?
Try
it
once
CSM
and
what
is
the
VN
member
model
and
how
they
relate
to
each
other
or
whether
they
overlap.
So
there
I
think
there's.
K
Know
to
me
the
weir
is
a
kind
of
high-level
description
of
the
water
network
by
describing
this
kind
of
a
topologies
and
a
set
of
different
tunnels.
Always
we
call
this
we're
members
and
consider
bringing
the
layer
specific
issues.
We
assume
that
air
one
or
two
or
three
VPNs
they
are
some
quite
mature
service
and
can
be
achieved
by
this
kind
of
a
service
models.
So
that's
slightly
different.
Yes,.
L
Slightly
different
is
not
a
precise
definition
of
the
exact
difference
and
specifically
for
layer,
1
I
think
you
have
to
work
out.
So
what
is
this
difference?
Wider
is
actually
a
need
for
two
different
things
and
how
a
customer
would
be
on
the
CMI
interface,
how
it
would
really
use
this
as
a
for
example,
how
he
would
set
up,
be
a
member
how
he
would
set
up
a
layer,
1
service,
and
how
did
the
workflow
works
this
the
implications
of
all
this
and,
as
I
said,
if.
L
K
Okay,
the
next
slide
shows
the
models
and
the
applicable
to
the
MPI,
which
a
host
object
is
mainly
for
the
multi-window
interrupts
and
for
this
interface
we
have
achieved
a
few
different
functionality,
including
the
scheduling
past
computation,
provisioning,
topology
and
channel.
So
we
have
try
to
integrate
a
few
different
young
models
developed
from
mariah's
working
groups
and
coexist
and
Inter
working
on
the
same
interface
and
considering
the
more
technology
specific
problems.
K
So
we
have
also
all
tnw
song
and
the
flexi
grade
topology
and
the
ton
of
models
to
support
this
and
I
think
the
current
work
is
just
adopted
by
the
working
group
and
the
currently
the
content
and
techniques
are
quite
stable
and
we
have
reached
a
common
understanding
in
the
authors
team,
and
so
this
is
a
document
that
says
how
to
build
a
sitting
interface
by
using
what
kind
of
models.
So
we
may
need
to
update
to
some
some
text
to
align
better
align
with
latest
ATT
and
framework.
K
A
What
do
you
see
happening
with
the
transport
service?
I
think,
was
a
document
presented.
A
couple
of
IQ
have
to
go
about
transport
service
model
where
a
bunch
of
the
text
was
merged
into
I.
Think
this
document
as
well
as
maybe
a
little
into
the
framework.
Do
you
still
see
a
need
for
that?
Other
document
I
asked
you
and
any
of
the
other
authors
of
that
yeah.
G
K
Of
the
network
there
is
usually
a
kind
of
clientele
layer
and
and
at
the
server
layer-
ok,
ok,
better!
So
nearly
given
the
metro
layer
in
the
network
where
there
is
client
layer
and
this
server
layer
in
the
internet
worker.
So
there
is
that
model
transport
service
is
trying
to
define
how
the
Krait
layer
describe
the
request.
So
it
is
different
from
the
the
customer
service
listed
here.
So
that's
applied
all
different.
The
interface.
H
Thank
you
just
intertia
commenting
wording.
So
draft
defines
close
relationship
between
young
and
napkin
fresco
in
the
future.
It
might
be
something
different.
Probably
you
don't
want
to
specify
in
some
that's
going
to
become
a
ref,
see
that
it
must
work
over
net
could
be
your
pc.
Could
the
chief
could
be
we
don't
know?
What's
going
to
be,
your
focus
is
young
mothers
not.
You
know.
M
A
M
A
M
You
know
if,
if
something
is
still
not
answered,
the
slides
are
there.
So
please
reach
out
to
the
authors
and
we
will
try
to
clarify
where
we
are
coming
from.
So
this
is
the
AC
tmv
and
yang
model.
We
talked
about
the
info
in
which
we
said
that
we
would
need
Servian
primitives,
which
are
little
different
from
the
T
primitives,
and
then
we
also
talked
about
the
various
yang
model
in
the
previous
presentation.
So
this
is
the
VN
yang
model
for
CMI.
So
let
me
introduce
this
a
little
bit.
M
The
focus
is
inside
the
framework
document.
We
clearly
define
what
is
the
VN
service
and
we
defined
two
types
of
VN
v:
n
type,
1
type,
2
and
in
service.
We
have
the
whole
lifecycle
management,
so
we
we
saw
in
the
info
model
as
well,
be
an
instantiation
we
and
modify
we
and
query
we
and
compute.
So
all
these
operations
that
we
would
like
to
do
it
on
the
VN.
So
this
young
model
tries
to
model
the
CMI
and
the
VN
operations
that
would
be
needed.
So,
as
per
the
architecture.
M
We
know
this
belongs
at
the
business
boundary
between
the
customer
and
the
network,
and
thus
this
model
is
aligned
to
the
customer
service
model.
The
same
concept
that
happens,
that's
been
like
I
think
it's
an
RFC
editor
queue.
Now
the
ops
working
group,
the
model
classification,
think
how
we
have
a
customer
service
model,
network
delivery
model
and
network
configuration
model
and
the
device
model,
so
this
AC,
T
and
V
and
yang
for
us
is,
is
at
the
customer
service
model.
What
all
information
do
we
want
to
put
in
this
model?
M
It's
all
the
information
that
a
customer
would
need
so
talking
about
how
the
access
points,
that
is,
how
the
customer
sites
and
the
provider
networks
are
connected.
That's
where
the
access
point
and
VN
ap
concept
comes
in
as
per
our
architecture
document,
when
we
define
a
VM
of
what
what
are
the
properties
we
need
to
put?
That
is
what
are
our
endpoints?
What
are
our
V
and
members?
How
are
they
interconnected
to
each
other?
M
What
are
the
constraints,
policies
and
things
like
that
and
most
of
the
time,
these
things
apply
through
the
VN
as
a
whole,
and
it
applies
to
all
the
different
VN
members
and
different
interconnections
that
I
may
have
in
the
site.
So
the
main
point
is
that
we
want
to
give
a
view
to
the
customer
based
on
the
based
on
how
he
sees
the
VN
rather
than
how
the
VN
is
actually
achieved
inside
the
provider
network.
So
what
all
the
updates
that
we
did?
M
We
made
sure
that
we
are
aligned
to
the
framework
because,
as
you
know,
there
were
recent
changes
there.
So
all
those
changes
are
taken
care
of
making
sure
that
the
VN
types
and
VN
s
types
are
well
handled
in
the
document.
So
we
made
those
as
a
separate
feature
in
the
yang
and
where
we
need
to
define
something
v,
NS
type,
to
specific,
that's
unable
under
the
that
feature
and
info
model
which
we
saw
where
all
so
we
kind
of
differentiated
between
the
VN
primitives
and
the
T
primitives.
M
So
this
model
focused
on
the
VN
primitives
part
of
the
info
model
and
the
nmda
things
are
also
handled
in
the
document.
The
latest
updated
so
just
a
little
bit
of
recap
so
that
we
can
agree
on
this
kind
of
model,
whether
this
kind
of
model
is
needed
or
not.
We
know
that
in
in
our
architecture
document
and
in
info
model,
we
have
talked
about
this
v
NS
service.
M
We
say
there
are
two
ways
to
operate
the
VN
we
could
do
it
very
simply
by
talking
only
in
terms
of
edge
to
edge
links
which
is
type
one
so
I
have
customer
sites,
I
simply
say
how
these
customer
sites
needs
to
be
connected
and
those
are
nothing
but
the
VN
member
and
how
these
VN
members
are
actually
instantiated.
All
that
details
are
kind
of
a
hidden,
but
it's
a
very
simple
view
of
the
network
to
our
customer.
M
In
some
cases
there
might
be
a
need
to
show
a
little
bit
more
detail
and
give
a
little
bit
more
control
to
our
customer.
That's
where
the
VN
topology
comes
in
and,
as
was
discussed
in
the
previous,
that
we
enter
policy
and
T
topology
are
little
different.
The
in
topology
is
this
the
view
of
the
topology
to
the
to
the
customer
here
as
well.
M
We
have
two
modes,
whether
the
topology
is
pre-negotiated
or
pre-configured,
and
whether
we
allow
changes
to
it
or
we
don't
that's
where
the
two
way
and
the
to
be
comes
into
the
picture.
But
overall
the
concept
remain
the
same.
So
with
this
model,
we
wanted
to
make
sure
that
we
are
able
to
operate
on
both
both
the
types
of
topology
and
as
per
the
info
model,
where
we
said
that
most
of
the
operations
and
things
are
same,
whether
we
do
type
1
and
type
2,
and
you
will
see
even
in
this
yang
model.
M
That
remains
to
be
that's
quite
true
there
as
well-
and
this
is
just
an
illustration
of
how
the
VN
topology
will
look
like
I-
think
the
main
focus
is
at
the
CMI
level.
That
is
how
the
interaction
is
between
the
MD
SC
and
the
CNC,
so
customer
comes
in,
tells
I
would
like
these
sites
to
be
interconnected,
and
these
are
my.
This
is
my
VN.
These
are
the
these
are
the
endpoints,
and
these
are
the
which
kind
of
connection
whether
I
want
a
full
mesh.
M
Whether
I
want
some
hub-and-spoke
kind
of
a
set
up,
or
what
is
my
policy
constraints,
all
those
things
as
a
whole,
so
the
main
concept
here
is
that
we
are
able
to
define
a
VN
as
a
single
entity
as
per
our
framework
as
per
our
info
model,
and
that's
what
is
shown
to
the
customer
and
in
some
cases
the
customer
would
configure
in
some
cases,
customer
may
just
want
to
view
or
how,
how
they
a
particular
service.
What
is
the
VN
slice
that
I
am
getting
and
that
information
is
modeled
in
the
same
way
right?
M
So
so,
once
you
have
the
customer
view
of
this
VN,
of
course,
the
real
work
is
has
to
be
done
by
MD
SC
in
mapping.
That
particular
view
into
the
real
a
real
of.
But
let
me
start
again,
so
we
have
the
customer
view
coming
from
the
CMI,
and
this
is
the
job
of
the
MDS
C
to
translate
that
view
into
the
real
provider
network.
What
set
of
tunnels
that
I
need
to
set
up
what
boundary
nodes
should
I
use?
M
M
So
we
believe
that,
having
this,
this
entity
called
VN,
which
is
a
core
part
of
the
a
CT
and
architecture
and
having
a
model
that
deals
with
VN
as
a
whole,
has
various
advantages,
and
it
is
a
definitely
a
different
model.
Then
the
other
models
that
are
available
in
the
tunnel,
as
well
as
in
the
topology
case.
A
E
G
Good
morning,
guys,
sorry
that
I
couldn't
make
it
to
Singapore.
So
my
coolant
is
that
Dru
food,
whatever
you
discussed
and
described
this-
is
exactly
what
she
topology
can
do
right
now.
Okay,
the
customer
can
configure
the
abstract
topology
can
negotiate,
can
get
the
view,
and
it
has
nothing
to
do
with
the
native
topology.
M
G
So
if
you,
if
you
can
point
out
what
exactly
cannot
be
done
without
first
ecology,
why
do
you
think
that
this
is
like
at
the
same
model
that
that
is
used
by
customer
and
by
their,
for
example,
MDS
see
in
all
of
you?
It
basically
is
just
different
levels
of
abstractions,
but
otherwise
they
are
completely
same
topologist.
M
G
A
Often
do
end
up
with
models
that
for
a
philosophic,
your
philosophical
question,
we
try
to
have
the
same
models.
Yes
to
do
that
now.
You
do
bring
up
other
points
where
there
might
be
some
technical
details
that
are
not
covered
in
the
current
model.
That
would
be
good
to
go
through
and
say,
give
it
a
specific
definition
of
here's.
A
What
we
can
do,
here's
what
we
can't
do
and
then,
rather
than
having
sort
of
an
abstract
philosophical
conversation,
we
can
understand
where
the
real
limitations
exist
and
then
answered
at
with
understanding
of
the
specifics,
whether
it's
better
to
have
a
new
model
or
to
reuse
and
augment
the
current
one.
So
maybe
it's
a
little
early
to
answer
the
question,
but
from
the
the
question
on
the
design
philosophy.
A
Yes,
we
do
want
to
reuse
and
we
do
want
to
come
up
with
mechanisms
that
support
our
arbitrary
levels
of
layering
and
stacking
on
top
of
each
other,
where
the
layer
below
you
is
your
provider,
the
layer
above
you
is
your
customer.
We
can
just
iterate
it
over
and
over
again
that
was
one
of
the
changes
I
had
actually
requested
in
the
framework
document,
and
the
funny
thing
is
I
said
on
was
no
I'm.
Sorry
I
wasn't
a
plane,
it
was
in
the
the
newcomers
meet-and-greet
someone
said.
A
L
My
name
is
Michael
sharp
from
Nokia
I
just
want
to
back
what
you
said
and
all
the
other
comments
that
it
is
perfectly
true.
So
it's
not
at
all
clear
to
me
at
this
stage
why
another
model
is
needed,
and
specifically
one
of
the
problems
is
the
latest
changes
to
the
framework
document
that
you
show
a
hierarchy.
You
actually
enter
in
your
situation.
You
have
the
t's
models
below.
Then
you
have
the
CMC,
then
you
have
in
the
next
layer.
On
top
you
have
then
the
t's
topology
models.
L
So
it's
not
at
all
clear
why
you
need
another
model
in
the
middle
and
in
that
specific
case,
also
keep
in
mind
the
weather,
the
relationship
between
the
MVS
C
and
the
C
and
C
is
a
business
relationship
or
not.
That's
not
at
all
clear.
In
some
cases.
Yes,
this
can
be
an
external
interface.
In
some
cases,
this
might
be
an
internal
interface
inside
the
robbed
operator
between
different
layers
in
a
dead
specific
case.
L
For
example,
the
amount
of
attributes
that
you
expose
can
be
different
and
you
will,
in
my
opinion
in
many
cases,
need
quite
a
quite
a
significant
number
of
the
attributes
that
you
have
in
the
t's
models
already,
for
example,
in
the
existing
drafts.
You
don't
have
anything
on
diversity,
you
don't
have
a
G's
in
there.
That's
a
really
relevant
use
case,
and
if
you
go
down
that
road,
you
will
probably
end
up
in
adding
more
and
more
attributes
to
it.
This
VN
model
that
we
already
have
an
existing
one.
L
So
it's
not
at
all
clear
as
of
nor
why
a
separate
model
is
needed
and
all
the
other
things
that
you
have
on
the
DB
n.
So
this
is
all
things
that
can
be
sorted
out
by
implementation
as
a,
for
example,
applying
a
policy
to
a
set
of
tunnels.
This
is
something
we
don't
have
to
sort
that
out
in
this
specific
young
model.
There
are
other
techniques
how
to
do
this.
M
M
I
agree,
and
so
the
idea
there
was
that,
since
this
model
further
refers
to
the
topology
model
internal
model,
it
has
it
hides
it
abstract
things
and
when
you
need
details,
so
if
you
are
using
as
a
part
of
your
provider,
you
want
more
details,
a
reference
so
that
you
can
go
to
the
topology
model
or
you
can
go
to
the
tunnel
model
and
find
those
details.
So
the
abstraction
is
maintained
at
the
same
time.
J
I
think
you
know
Lu,
as
you
said,
I
think.
What
you
are
trying
to
do
here
is
that
you
know
Y
T,
tunnel
model
and
topology
may
not
satisfy
you
know
customer
expressing
their
service.
That's
why
we
introduced
VN
concept
and
we
actually
reuse
a
most
of
the
construct
that
a
topology
used
specially
the
N
type.
We
don't
reinvent
the
wheel,
we
just
reference
the
right
tunnel
and
then
topology.
J
So,
as
ego
said,
you
know
we
are
we
using
the
you
know,
semantics
already
so
I
think
VN
concept,
however,
is
a
very
useful
concept
and
I
think
required
concept
from
customer
perspective.
That's
why
we're
interested
in
this,
so
we're
not
reinventing
the
wheel,
so
we're
going
to
make
it
a
little
more.
You
know
clarification
in
the
new
document
why
we
think
that
VN
concept
is
needed
on
top
of
the
eternal
and
topology
I.
Don't.
G
J
Present
and
also
in
answering
your
question:
diversity
customer
don't
kill
diversity,
they
have
SLA.
You
know,
provide
my
delay
and
then
my
you
know
loss
if
this
budget
you
take
care
of
it
in
the
network.
That's
network
stuff.
We
don't
express
diversity
in
the
VN
level.
So
that's
answering
your
question.
Customer
don't
need
to
know.
You
know
yep,
okay,.
L
L
A
Good
range
of
what
happens
in
use
cases,
every
user
is
a
little
different.
For
example,
in
my
experience
with
transport
networks
being
able
to
tell
your
customer
that
you
use
a
diverse
path,
is
table
stakes,
and
if
we
presented
a
dynamic
interface
that
didn't
include
that
they
would
never
use
it.
So,
but
that's
just
you
know
that
one
use
case,
there's
other
use
cases
where
I
think
you're
right
where
the
customer
doesn't
want
to
look
at
that
they
just
want
to
get
this.
Whatever
the
service.
That's.
J
A
Different,
they
have
different
requirements,
so
I
think
what
would
be
really
helpful
and
I
think
the
authors
can
come
back
and
say
yeah.
This
is
crazy,
but
or
too
much
work
would
be
really
helpful.
Is
to
take
the
te
topology
model
and
see
if
you
can
just
awed
meant
it
to
give
you
give
the
extra
things
extra
control.
Knobs,
you
think,
is
important
and
the
other
thing
is
there's
already
a
lot
of
presence
and
features
in
them
in
the
base
model.
A
So
you
don't
have
to
use
everything
and
if
you
find
that
maybe
there's
a
couple
of
containers
or
Leafs
and
in
that
model
which
are
required
but
for
your
use
case
really
should
be
optional.
Maybe
we
can
change
that
at
this
point
and
say
well,
rather
than
make
it
a
required
note,
let's
make
it
an
optional
mode.
Remember
that
yank
is
already
gives
you
the
ability
to
not
use
everything.
That's
there,
not
everything
in
the
model.
Yeah.
A
M
One
thing
that
I
kind
of
found
with
Tito-
maybe
you
could
also
correct
if
that's
if
I
had
made
a
wrong
assumption
there,
so
when
we
are
doing
a
topology,
if
it
is
a
very
simple,
as
we
said
single
node
topology,
if
a
customer
is
just
expressing
that
or
end-to-end
it's
pretty
straightforward,
but
when
it
comes
to
say,
I
want
to
like
what
we
do
in
type
two,
that
the
topology
that
we
want
is
a
little
bit
more.
Details
are
exposed,
then
also
on
that
topology
further
setting.
M
What
are
my
habit,
whether
I'm
going
to
do
a
full
mesh,
whether
I
want
to
do
hub-and-spoke
and
having
a
little
bit
more
control,
I
kind
of
found
that
that's
a
little
bit
messy
for
me
to
do.
It's
very
simple
from
the
abstract
topology
that
I
want
to
define
is
very
straightforward,
link,
link
link
you
it's
up
to
you.
How
do
you
translate
this
link
into
further
details,
but
when
I
have
a
topology
and
I
want
customer
to
control
that,
oh
by
the
way?
M
B
Would
be
really
useful
if
you
go
through
the
exercise
and
point
out
where
it's
lagging
I
I
still
think
it's
a
question
of
not
having
a
F
well
advanced
tutorial
for
the
topology
model.
There
is
a
document
out
there
that
should
give
you
more
guidance
on
how
to
use
it.
But
whatever
you
mentioned
so
far,
that's
still
part
that's
possible
in
the
Tito
policy
model.
I
I
don't
buy
a
statement
that
it's
hard
to
do
it
with
topology
more.
N
Daniella,
actually
here
the
problem
often
is
not
what
is
missing,
but
is
what
is
too
much
in
the
sense
that
the
guys
sitting
on
top
of
them,
you
see
often
is
nos
s
is
a
provider
that
just
provides
a
connectivity
between
between
endpoints.
They
don't
want
to
know
anything
about
tunnels
and
topology.
They
often
say
I
just
want
the
connectivity
between
these
points
with
these
characteristics.
That's
it
that's
why
the
Vienna
concept,
the
VN
model,
it's
very
thin.
Everything
is
nothing
very
big.
N
Like
a
complex,
topology,
complex,
a
bunch
of
tunnels,
they
don't
want
to
often
to
to
deal
with
multiple
domains,
multiple
technologies,
just
that
connectivity
with
given
characteristics
between
between
points
and
the
dvn
aims
at
solving
there's
a
very
simple
issue,
hiding
all
the
complexity.
This
was
the
main
goal,
I
think.
A
We
talked
about
that,
there's
a
range
of
customers
and
a
range
of
use
cases.
Some
are
very
abstract.
Some
are
very
detailed
and
we
really
want
a
solution
that
supports
the
range
as
opposed
to
just
picking
one
or
the
other.
So
if
we
have
the
case
where
we
have
a
solution,
that's
only
very
abstract.
Well
clearly
that
doesn't
support
the
middle.
A
A
G
So
I
want
to
say:
is
that
basically
optimize
an
abstract
apology,
it's
a
single
attribute,
so
you
can
say
optimize
a
boy
delay
or
optimize
it
by
cost
and
that's
always
needed
from
from
the
client
point
of
view
and
configuring,
for
example,
a
single
node,
topology
or
mesh
Lin
topology.
It's
it's
the
same
exercise,
it's
very
simple,
so
I
would
like
to
see
the
roof's
results.
A
M
H
Answer
so
I
actually
was
the
customer
rather
mean
vendor,
so
its
ability
to
express
particular
constraint
if
you
work
with
banks
or
hospitals,
physical
diversity
is
a
scene
sequence
of
you
see
business
logic
when
I
was
a
customer.
I
would
ask
you
for
layout
of
your
tables
and
the
way
they
live.
So
you
really
need
to
provide
ability
to
express
this.
Does
it
have
to
be
mandatory
up
solutely?
Not
most
people
will
work
with
you
on
level
of
us.
M
I
think
it
exists
right
here,
I'm,
not
sure
whether
you
guys
can
see
it
or
this
those
things
exit
there,
but
it's
not
done
at
the
power
Tunnel
level.
Overall,
we
kind
of
say
that
for
the
whole,
Vienna's
all
makes
sure
that
all
VN
members
are
diverse
to
each
other,
so
that
we
we
are
able
to
make
sure
that
even
if
something
goes
down,
some
other
person
can
take.
So
the
whole
idea
is
doing
the
same.
M
We
could
I
cannot
disagree
with
the
fact
that,
yes,
the
same
can
be
easily
done
by
tea
tunnel
and
tea
topology.
The
only
part
where
we
are
disagreeing
is:
is
it
too
complicated?
For
example,
if
I
have
a
full
mesh,
9
is
2
9
connection
I
make
a
change.
I,
don't
have
a
way
to
say
that
I'm,
making
a
change
on
a
VN
as
a
whole
I
usually
have
to
go
to
each
things
and
make
the
change
it's.
So
the
main
question
for
us
is
it:
can
we
make
this
a
little
bit
easier
as
well.
H
A
C
Bel
Nokia,
specifically
looking
at
your
VN
s
type
2
model.
I,
really
would
like
to
understand
why
the
et
topology
model
cannot
be
used
to
describe
what
you
need
for
this
purpose,
because,
specifically,
when
we
developed
the
TT
polity
model,
we
know
we're
looking
at
those
kind
of
topologies
and
I
think
the
model
is
perfectly
suited
to
describe
these
topologies
and.
M
We
reuse
the
the
D
topology
model
by
maintaining
a
reference
to
the
T
topology
created
there,
but
only
X
because,
as
we
said,
the
VN
is
the
same,
irrespective
of
whether
you
use
type
1
or
type
2,
that's
there.
So
the
the
whole
idea
of
even
if
you
have
more
details
about
about
the
VN
topology,
that
you
go
and
configure
using
the
abstract
de
topology
model.
But
what
are
your
VN
members?
What
is
the
policies
based
on
which
this
VN
is
created
that
we
are
maintaining
in
this
model?
And
then
this
is
not
just
configuration.
M
It's
also
operational
so
operationally.
If
I
want
to
know
how
my
VN
as
a
whole
work
is
working,
I
could
easily
figure
it
out
from
this
particular
simple
view,
without
going
individually
in
each
tunnel
each
link
and
each
status
of
everything
else
in
my
topology.
That's
where
it
so.
Let's
have
this
discussion,
do
I
still
have
time
or
yeah.
A
M
Let
me
try
to
I
think
most
of
the
conversations
we
have
kind
of
had.
This
is
basically
trying
to
go
over
that.
Why
having
a
separate
customer
service
model
is
useful.
Most
of
the
points
we
have
already
covered,
some
of
the
further
discussions
that
we
are
having,
which
is
that
having
a
telemetry
on
the
VL
as
a
whole
or
how
the
VN
can
be
mapped
to
the
service
model,
which
is
in
the
further
discussion.
So
that's
also
this
especially
the
last
point.
M
That
is
something
that
we
may
not
have
covered
so
far
that
in
all
cases
we
do
not
expect
the
customer
to
in
create
of
VN
explicitly.
Sometimes
the
VN
is
created
automatically.
For
example,
if
a
customer
is
using
an
L,
3,
SM
interface
and
providing
the
details
but
automatically
based
on
the
L
3
SM
requirement,
the
site
information
ovn
could
be
created,
so
you
don't
use
this
VN
model
to
actually
instantiate
it
internally.
M
So
it's
not
just
configuration
some
other
some
other
services
that
are
documented
documented
in
the
AC
TN
requirement
document,
as
well
as
in
some
of
the
use
cases,
have
been
the
VN
compute
that
how
doing
the
computation,
the
pre
instantiation
and
getting
the
view
that
what
is
the
VN
that
I'm
going
to
actually
get
before
I
actually
instantiate.
It
that's
quite
useful
for
me
for
a
customer
to
make
lot
of
interesting
decision.
The
same
can
also
be
done,
for
instance,
by
using
path.
M
Computation
API,
which
is
just
just
adopted,
but
again
where
we
are
coming
from
is.
Is
there
a
easier
and
simpler
way
to
do
the
same
spatially
towards
the
customer
that
can
I
ask
the
whole
VN
how
to
be
computed
as
a
whole,
rather
than
giving
separate
path,
computation,
API
requests
and
having
much
more
complicated,
our
computation
so
having
a
VN
as
a
whole
entity
in
a
young
model
according
to
us
was
quite
useful.
Another
thing
was
the
multi-source
multi
destination
problem,
which
has
been
I,
think
discussed
in
the
info
model
as
well.
M
This
is
something
not
to
be
confused
by
P
to
MP
the
this
is
a
interesting
problem
that
the
some
of
the
data
center
operators
asked
us
to
make
sure
that
this
is
a
part
of
our
a
part
of
our
actn
model,
in
which
suppose
for
a
data
center.
Any
of
these
destinations
can
host
a
particular
service
and
he
would
like
to
know
from
the
customer
or
from
the
mdac
that
way
should
I
host
it
and
instead
of
like
doing
computation
separately
and
then
picking
one,
we
simply
provide
this
information
to
the
MDS
C.
M
M
Just
to
summarize,
I
think,
according
to
us,
this
is
useful.
We
will
further
go
through
that
exercise
that
what
we
have
agreed
on
that
how
this
D
topology
versus
this
model
and
see
if
some
of
these
things
can
be
done
on
this,
at
least,
we
have
had
some
conversation
regarding
the
multi-source
multi
destination
problem,
the
VN
compute
problem
with
some
of
the
authors,
and
we
do
realize
that
it's
little
hard
to
do
these
kind
of
things
on
the
abstract,
T
topology
model.
This
is
the
as
you
can
see.
The
yang
model
is
not
that
complicated.
M
We
have
the
access
point
VNA
P.
These
also
helps
us
to
map
to
the
LTS
M
site,
IDs
and
L
inside
site
IDs
from
the
service
side,
which
I
think
will
be
covered
by
Daniel
E
as
well
as
you
have
the
VM.
In
some
cases,
if
you
have
the
topology
created,
you
can
make
a
reference
to
the
T
topology
model.
You
have
concept
of
what
are
your
VN
members
in
some
cases,
we
want
to
give
control
to
the
to
a
customer
on
what
on
the
VN
topology.
M
What
part
should
be
taken
so
again,
this
is
not
the
provider
view
from
the
customers
view.
What
part
should
be
taken?
Those
information
can
be
configured
and
it's
up
to
the
MDS
C
to
further
translate
this
customer
view
to
the
provider
network,
what
needs
to
be
sent
to
the
domain
topology
and
the
PNC's
etc.
The
concept
of
multi-source
multi
destinations
is
covered
and
all
the
other
properties
are
at
the
VM
level.
So
I
think
that's
one
of
the
key
thing
that
we
wanted
to
do.
M
Okay,
so
we
wrote
this
document
with
the
philosophy
of
customer
service
model
that
having
a
separate
model
might
be
useful
in
some
cases
and
where
more
details
are
exposed,
then
the
T
topology
model
and
the
and
the
tunnel
model
will
satisfy
that
purpose.
But
even
if
that
is
done,
this
model
has
that
relationship
and
that
references,
so
it
it
becomes
a
more
like
an
ecosystem
of
models,
rather
than
use
this
versus
this.
Rather
they
all
work
together.
That's
where
that's
the
view
that
we
had.
A
F
J
So
this
one
is
basically
from
customer
view.
Customer
has
some
concerns
about
their
performance
data
of
their
end-to-end
tunnel
from
C
to
C,
or
if
you
have
a
more
than
just
C
C
connectivity,
you
may
construct
virtual
network
may
have
multiple
locations
connected
together,
for
instance,
ten
data
centers.
They
are
interconnected
together
they
want
to
see
how
there
are
key
performance.
You
know
data
is
performing
so
that
they
would
be
able
to
react
to
that
data.
J
So
this
is
actually
one
of
the
key
requirements
specified
in
a
CTN
requirement.
Documents
operator
one
to
be
able
to
see
they
are
they
one
want
to
see
without
getting
a
tie
to
detail
levels
of
multi
domains
and
things
like
that,
and
also
we
have
a
use
case
document
which
is
written.
You
know
before
this
actn
work
has
triggered.
They
have
very
clear.
J
So
so
from
last
version
we
added
utilization
percentage,
which
might
be
very
useful
for
customer
to
just
know.
Instead
of
they
calculate
based
on
you,
know,
capacity
and
then
utilize
bandwidth.
So
we
just
had
a
percentage
and
we
have
a
two
module
is
FTE
KPI
telemetry
and
also
it
have
AC
TNT
KPI
telemetry.
Both
both
of
them
are
an
NDA
compliant.
J
Given
the
controversy
of
ICT
and
DN
I
think
this
document
itself
can
prolong
without
a
CT
and
VN.
If
you
will,
because
we
have
two
module,
the
basic
idea
is
that
customer
can
configure
some
grouping
operation
or
some
performance
data
they
want
to
see,
and
then
they
specify
this
then
subscribe
to.
You
know
such
such
data
and
then
basically
mdac
basically
translate
that
into
you,
know,
domain
level
and
LSP
level
and
then
concatenate
that
to
give
or
end-to-end
you
know,
performance
data
to
the
customer
back,
so
that's
their.
Basically,
the
idea
of
is
draft.
J
As
I
said,
we
have
a
two
young
modules.
One
is
a
T
KPI,
telemetry,
a
simply
arguments,
t
tano
and
another
one
is
a
TT
+
v,
NT
telemetry
that
arguments
a
city
and
VN
model
that
group
just
presented
on.
So
the
purpose
is
same
but
different
level,
so
teach
a
KPI
telemetry
model
provides
Tito,
no
level
performance
monitoring.
This
is
actually
C
C
data
and
then
they
they
they
are,
depending
on
the
operator
to
provide
p2p,
eternal
data
so
that
they
understand
how
are
their
end-to-end.
J
J
So
let's
keep
that
so
scaling
intend
is
basically
allows
the
grouping
operation
by
the
customer
of
various
performance
data
and
react
accordingly.
Basically,
it
has
a
scale
in
or
scale
down
mechanism.
42
know
that
include
list
of
parameters
to
monitor
and
then
logical
operation
to
be
applied
to
the
monitored
parameters,
and
it
can
give
holding
a
stress
holding
time
and
cooling
time
so
that
they
understand
the
nature
of
this
performance
data.
J
So
this
is
a
young
model
that
we
basically
are
specified.
It's
just
argument:
T
a
tonal
model.
The
burials
of
you
know
data
as
you
can
see
on
the
screen,
and
then
we
have
a
mapping
with
T
tonal
reference.
What
this
data
is
referring
to
in
the
te
tunnel
model,
so
that
customer
understand
artist
belongs
to
which
tunnel
are
they
referring
to.
J
L
Actually
have
two
questions:
my
name
is
Michael
sharp.
The
first
one
is
about
technology.
Specifics,
I
think
I've
mentioned
before
that
this
list
contains
some
technology
specific
entries,
such
as
packet
loss,
but
the
general
question
is
so
I
mean
we
don't
fully
know
how
this
model
would
be
used,
it
can
be
applied
at
different
technologies,
telemetry
or
whatever,
that
is
about,
could
apply
to
different
technologies.
L
So
you
will
have
to
think
about
how
you
deal
these
different
technologies
and
how
you
add
the
corresponding
attributes-
and
it's
not
clear
to
me
in
that
model
how
you
deal
this
is
because
you
probably
need
different
augmentations
or
things
like
this,
so
you
have
to
think
about
it,
and
it's
not
clear
to
me
in
the
specific
draft
how
you
do
that.
The
second
comment
is
on
these
intent
things.
So
you've
already
shown
some
examples
in
general
for
these
scaling
things
or
there
can
be
things
beyond
scaling
by
the
way.
L
Do
you
really
think
that
you
can
hard
code
here,
all
different
policies
that
or
all
these
different
business
logics
that
would
be
required
in
such
cases?
I'm
not
sure
if
it
makes
sense
to
put
this
in
this
yang
model,
to
be
honest,
because
there
can
be
very
different
conditions.
It's
really
business
logic
and
I'm,
not
sure
if
you
really
want
to
encode
all
different
conditions
here
in
a
yang
module
that
this
might
be
pretty
hard.
J
Yep
I
think
we're
taken
so
I
think
about
the
packet
loss.
I,
don't
know.
Maybe
we
need
some
guidance
from.
We
thought
the
packet
loss
is
generic,
but
you
know
a
lot
of
customer.
They
know
packet
loss
and
delay
and
bandwidth
level,
but
optical,
maybe
bender
may
have
BER.
So
maybe
we
can
take
our
packet
loss.
I,
don't
know
what
is
your
opinion
on
here?
I
think.
J
Then
this
can
be
augmented
in
C
camp
right
in
Ethernet
and
then
C.
You
know
maybe
layer,
1
layer,
0.
Maybe
it's
a
Perl.
We
can
augment
that
ok
and
then
second
question
on
the
stress
holding
and
the
scaling
and
scaling
our
mechanism.
I
agree
with
you
that
that's
not
really
telemetry
model
in
itself,
so
either
we
take
it
out
and
then
pursuing
different
model.
If
people
think
it's
useful,
but
we
can
think
about
that.
Ok,
ok,.
A
I'm
not
sure
if
you
just
said
this,
but
one
of
things
that
would
be
really
useful
and
we
talked
about
this
I.
Think
if
the
previous
meeting
is
on
the
parts
that
are
you're
augmenting
technology
that
are
truly
generic,
you
might,
it
might
be
valuable
to
bring
this
immediately
into
T
ecology
before
we
finalize
it.
A
So
if
we
can
send
some
comments
in
like
the
next
week
or
two
and
say
these
pieces
of
telemetry
information
are
generic,
send
it
to
the
list
and
propose
it,
and
then
we
can
have
a
quick
discussion
and
figure
out
whether
we
bring
that
in
so
that
is
part
of
the
core
I
think
there
is
general
agreement
that
Kalama
tree
is
an
important
part
of
any
model.
Nowadays,
some.
B
J
B
J
J
J
B
H
From
usability
perspective
with,
and
we
made
now,
you
could
compare
your
operational
stage
arrived
from
telemetry
into
your
intended
state.
So
few
weeks
ago,
we've
published
in
your
draft
where
we
define
number
of
RPC
a
new
action
called
compare.
So
by
using
that
you
can
define
search
targets
filters.
It
would
be
very
useful
to
be
able
to
compare
your
operational
state
from
telemetry
derive
from
a
problem
telemetry
into
what
it
should
be
and
take
some
actions.
Okay,.
J
A
J
N
Hello,
this
is
daniela
presenting
the
traffic
engineering
and
service
mapping
yum
model.
This
is
this
is
a
very
simple
model
that
is
used
to
create
a
relationship
between
a
service
and
ended
infrastructure
where
the
service
can
be.
For
example,
we
try.
We
try
to
make
it
to
cover
all
the
different
possibilities.
We
have
l,
3,
sm,
l,
2
sm,
the
new
layer,
1
c
sm,
and
it
can
be
easily
extended
to
supposed
to
support
further
our
services.
On
the
other
side.
N
On
the
infrastructure
side,
we
have
a
support,
48
tunnels
and
is
it
can
be
4
networks?
This
can
be
easily
augmented.
Also
from
from
that
side.
This
is
a
document
that
falls
under
the
city
an
umbrella,
but
doesn't
necessarily
need
to
be
implemented
in
any
city
and
environment.
You
can,
for
example,
the
side
within
a
single
domain
without
any
narrative,
Sdn
controllers
to
have
layer,
3
VPN
bound
by
in
DD
228
Anna,
updated
updates.
Since
the
last
version.
N
First
of
all
the
scope,
we
made
it
clear
that
the
scope
of
the
document
is
limited
to
a
set
of
domains.
Under
the
same
network
operator,
we
received
a
comment
about
the
applicability
of
the
city
on
to
multiple
domains
with
different
with
different
operators.
This
is
not
yet
covered
by
by
the
document,
its
orbital,
its
otoscope.
We
added
the
support
for
the
new
layer,
one
service
model,
the
one
that
has
been
presented
in
in
Sikkim
and
added
consideration
of
different
modes
of
operations.
You
will
see
in
the
next
in
the
next
slides.
N
Ok,
so
these
are
the
the
old
ones.
Sorry,
sorry
about
that,
we
had
in
the
latest
version.
We
had
some
examples
of
on
how
to
use
it
but
never
mind
you'll,
find
it
in
the
intermediate
material.
So,
let's
go
directly
to
the
modes
different
modes
of
operations.
We
identified
the
three
of
them.
This
doesn't
mean
that
they
are
the
only
three
available.
N
Some
other
cases,
some
other
modes
can
be
discussed
and
added.
The
three
that
we
focused
on
are
the
binding
of
a
service
to
a
new
infrastructure.
This
means
that
when
a
service
is
requested,
the
infrastructure
to
support
it
is
provided
as
Wella.
For
example,
I
want
a
new
l3
VPN
between
three
end
points
with
100
Giga
bits
allocated
three
tunnels
or
one
Vienna
will
be
allocated
as
well.
This
is
something
extremely
common
and
useful
in
network
slicing,
for
example.
N
The
second
one
is
the
selection
of
existing
infrastructure.
This
means
that
when
a
customer
asks
or
for
a
VPN,
nothing
new
is
created,
but
a
choice
is
performed
among
the
different
tunnels
and
virtual
networks
already
already
available.
The
DeLaughter
allows
for
the
modification
of
existing
tunnels
and
the
vital
networks
the
where
the
simplest
case
is
just
increasing
the
babbitt
receptor
for
such
for
such
tunnels.
Here
we
have
a
an
example
of
the
flow.
N
Basically,
the
service
like,
for
example,
the
NL
3
SM
model,
is
used
to
request
a
service
at
the
MDS
sea-level,
also
on
top
of
them
DSC.
The
mdac
translates
the
requestor
into
a
setup,
selection
or
modification
of
an
existing
tea
tunnel
or
or
BN
and
Cascades.
They
the
requested
to
the
values
to
the
various
PNC's
in
the
in
the
front
of
the
form
of
a
tea
model,
for
example
a
tea
tunnel.
N
N
L
Micah
sharp
so
a
general
comment
on
that
draft,
but
also
specifically
on
that
slide.
What
is
definitely
missing
in
this
whole
draft
is
that
is
it
discussion
how
this
would
really
work
in
realistic
use
cases,
for
example,
the
topology
that
you
show
here
doesn't
show
P
routers.
It
doesn't
show
PE
Rogers.
It
doesn't
talk
about
what
IP
tunnels
you're
talking
about.
L
You
put
an
optical
network
Somerby
in
the
middle
between
two
IP
nodes,
in
fact,
actually,
if
an
overlay
of
the
IP
or
network
on
top
of
the
underlying
optical
network,
so
this
picture
here
is
really
unrealistic.
It
even
contradicts
another
use
case
or
another
way
to
do.
It
is
that
it's
listed
not
explicit
in
the
framework
document.
So
before
talking
about
details
here,
I
think
the
first
thing
you
do
that
you
have
do.
Is
you
have
to
show
these
kind
of
flows
for
actual
technology
talk
about
what
you
would
would
map
stop?
L
L
N
L
Too
late,
the
slides
at
the
data
trackers,
it's
the
same
comment,
at
least
at
realistic,
topologies,
realistic
use
cases,
multiple
IPAs
put
it
explicitly
is
define
what
IP
tunnels
your
mapping
tool
and
then
start
it
from
there.
So
this
is
not
at
all
addressed
or
non
slide
that
I've
ever
seen.
So
you
have
to
add
a
slide
where
you
have
P
routers,
PE
routers,
and
things
like
this
ASPRS
at
the
IP
level.
L
L
A
A
G
So
why
why
why
do
we
need
this
document?
Why
we
a
rope
this
document?
Basically,
the
reason
is
precisely
because
people
like
drew
I
keep
complaining
that
the
models
are
too
complex
and
the
documents
are
too
esoteric
to
understand
what
could
be
done
and
what
kind
of
use
cases
could
be
addressed.
What
kind
of
problems
could
be
solved
and,
unfortunately,
it's
not
just
truth.
We
also
hear
the
same
thing
from
operators.
G
Okay,
so
so
the
document
includes
basically
three
sections:
one
has
described
in
the
etymology
model
analogy
internal
and
the
third
one
provides
use
cases
which
combines
the
two
models
and
describe
how
the
common
problems
could
be
solved.
Incidentally,
one
of
this
use
cases
is
V&S
how
you
can
configure
v
unless
it's
an
absurd,
topology
red
flag.
O
G
Just
adjusts
its
loads,
it
takes
time.
So
this
is
the
second
time
when
we
are
presented
that
the
first
time
was
in
fracking
native
99
and
since
then,
basically
our
goal
is
to
keep
it
aligned
with
the
latest
development
in
the
topology
tunnel
model.
So,
for
example,
we
included
various
new
concepts
that
were
introduced,
such
as
dependency
tunnels
in
the
Titano
model,
the
recovery
and
perfection
configuration
and
also
protection
commands
that
our
chief
was
talking
about,
and
we
also
edit
examples
of
Jason
included
into
the
use
cases.
Next,.
G
G
Not
use
cases
were
basically
well
ready.
It
was
presented
in
Prague,
so
just
next
steps
I
wanted
to
yes,
so
next
step,
we
wanted
to
get
the
definitions
and
use
cases
that
that
were
recently
added.
We
didn't
finish
this
walk
okay
and
we
want
feedback
from
the
working
group.
Basically,
do
you
guys
think
that
it's
a
useful
document
and
if
so,
we
want
to
make
it
work
in
Pokemon?
A
Okay,
as
a
reminder,
this
is
an
informational
document
to
help
understand
work
on
teeth.
Apology,
I
think
it's
very
helpful.
We
see
even
inside
the
working
group
there's
confusion
is
Igor
mentioned
it's
even
worse
when
our
customers
don't
understand
what
we're
doing,
how
many
think
that
this
is
a
useful
type
of
activity
for
the
working
group?
A
P
P
So
of
I
really
introduced
scenario
summary
and
our
requirement
and
our
probe
hood
solution.
We
also
compare
with
the
current
technology
and
for
excellence.
You
know
here
is
the
in
our
summary
here
in
studio,
stay
in
last
in
ideal
media.
There
are
four
scenario
that
we
required:
the
traffic
and
you're
really
in
the
nature
IP
network.
The
first
thing
is
a
class
or
shortens
the
for
the
hybrid
cloud
communication
for
end-to-end,
the
cholesterol.
So
instead
the
secondary
is
the
traffic
engineering
for
the
our
IDC
men
or
semi
slings,
the
saudis.
P
We
want
to
increase
our
link
utilization
based
on
the
title
phenomena,
because
the
different
and
kaiser
connected
different
customers-
they
are
trafficker,
has
a
title
phenomena.
The
last
thing
is,
we
want
to
eliminate
the
temporary
network
congestion,
so
this
is
the
for
generate.
We
are
in
contrary
to
our
do.
Network
based
on
is
a
sonography.
We
are
seeking
the
solution,
it
can
eat,
howard
acquire
with
the
14
equipment
or
our
accept
ace
expression.
The
first
thing
is
this:
loosen
up
riser
for
network
network,
the
third.
P
The
second
is,
we
want
to
authorize
network,
it
is
identical,
Department
for
the
intra
and
Inter
domain
and
the
sturdy
the
we
want
to
solution
to
have
no
influence
to
the
agree.
Skin
hot
water,
fording
behavior,
because
there
are
a
lot
of
rotary
our
network,
we
were,
we
cannot
change
them
at
the
very
short
time.
The
force
is
eating
in
her
operation
for
rotor
from
different
vendor,
but
our
network,
our
comp
rider
from
her
pilot
rotor
from
the
Cisco
high
or
juniper
and
Nokia
the
faeces,
because
we
want
to
use
the
PC
we
want.
G
P
The
soft
in
your
soft
air
any
year
and
the
things
that
we
can
you
can
we
want
to
utilize.
The
power
of
a
central
controller
such
as
the
PC
and
the
flexibility
and
of
the
button,
is
over
the
computer
control
protocol.
The
last
requirement
or
experimenter
we
want
to
the
solution,
can
commence
the
differences
requirement
for
logic
among
North
America
and
the
prefix,
because
our
network
has
about
tens
of
a
deep
but
traffic
on
the
tens
of
thousands.
The
predict
in
our
network
here
is
our
appropriate
solution.
P
We
first
we
want
to
deploy
the
PC
all
Sdn
controller,
our
innate
IP
network.
The
this
controller
is
principle
for
the
complex
algorithm
to
to
optimize
this
and
the
laser
a
trafficker
open.
A
GeoNet
was
iteration
because
under
sink
controller
has
the
whole
view
of
the
networker,
and
we
use
the
important
protocol
to
populate
the
traffic
by
the
even
PDP
sessions.
Katina
appears
and
the
menu
manually
to
the
past
will
be
next
hopper
of
these,
the
prefix
by
priests
a
year.
What,
if
two
different,
had
fought
you
traffic
for
the
imposter?
P
P
Well,
summary:
the
is
solution.
The
benefit
of
this
solution
either
because
the
PC
controller
had
a
powerful
capability
to
so
complex
is
having
a
nurse
in
arrow,
and
we
also
finished
the
large
network.
Simulator.
The
ploy
to
grabber
is
the
you
just
in
the
recent
drought.
I
hope
you
to
do
so
in
traditional
media
and
the
kind
of
solution
can
deployment.
P
You
know
you
zoom
in
same
manner
for
the
internet
in
her
domain
for
NATO
IP
network
and
later
we
can
easy
to
expand
to
cover
other
kind
of
network,
for
example,
for
Android
heavily
optimization
and
the
least
Rosen
can
exploited
the
advantage
of
central
control
and
the
key
good
and
protocol
we
have
submitted
swings.
Rigid
shaft,
for
this
is
a
scenario
and
the
solution.
The
first
day,
Jesus
was
in
error
and
the
simulation
from
China
humpy,
China,
Mobile
and
telecom
honey.
They
are
all,
have
the
larger
network
network
and
wanted
to
traffic
engineering
the.
P
Secondly,
the
the
framework
of
all
is
a
solution
by
expert
from
the
highway
and
transient
in
20
30
year,
the
30
the
piece
a
per
protocol,
extensive
report,
so
we
we
are
also
seeing
what
is
our
problem
in
the
end,
you
know
the
there
are
three
three
tashera
way
we
run.
We
run
to
cater
for
hours
Rosa.
Firstly,
the
we
want
to
select
a
piece,
a
protocol
to
transfer
the
policy
to
wrote
her
this.
P
There
are
also
a
lot
of
discussion
about
an
instability
in
the
PC
working
group
and
I.
Think
we
we
supported
this
era
under
four
kind
of
pro
pro.
There
are
only
sneaky
Herman.
Her
need
to
be
transferred
on.
It
would
be
expanded
for
the
peaceable
protocol.
Here
is
a
list
of
the
peop
type
of
project.
So
if
this
group,
this
is
the
chapter
accepted
by
the
his
group,
we
can
discuss
it
detailed
in
the
millions
PC
group
and
for
our
scenario
we
also
come
here.
P
We
are
with
other
technologies,
and
but
it
seems
that
none
of
them
can
meet
the
requirement,
all
our
expertise,
our
expectation
for
the
mission
scenarios,
for
example
the
first
day
in
the
segment
Guardian,
because
we
seeing
a
second
monkey
need
not
the
same
solution
for
in
front
of
man
and
the
required
a
change
of
the
fourth
behaviour
on
the
TV
other.
By
the
way,
there
are
many
many
pirata
in
our
new
our
network
and
for
interoperability.
The
same
as
all
require
the
map
server
for
coexist
here
with
a
nice
hot
water,
the.
P
Secondly,
the
re,
speed
rsvp-te,
it
is
a
I
think
everyone
here
know
it
is
this
protocol
he'll
sing
on
bottom
and
the
state
of
pressure
on
routers
the
Cerrito
comprising
it
is,
cannot
cope
with
the
pressure
from
large
amount
of
traffic
differential
requirement,
and
it
emphasized
only
the
central
control
not
accepted
by
the
network
operator.
The
last
thing
is
the
American
young,
so
some
personnel
said
the
vicar
realized.
Oh,
there
are
large
hour
solutions
by
the
Native
Hawaiian
butter.
We
seeing
how
the
four-year.
P
Folium
may
be
some
big
point.
The
first
thing
is
the
the
every
young
has
a
detailed
elaborate,
the
configuration
style.
This
is
not
really
understood
by
our
soft
and
your
software
engineer
of
the
SDN
controller,
so
they're
free
for
simple,
abject
command.
The
second
week
considered
the
efficiency
and
so
because
the
Desmond
young
Indian
textile
and
his
ever
using
binary
mode
and
for
union
utilizing
yeah.
We
want
to
unity
in
the
initial
configuration,
but
for
the
dynamic,
a
judgment
we
want,
will
the
PC
protocol
to
get
our
requirement.
H
H
H
P
P
Q
Hi
any
Adrian
Powell.
Thank
you
for
this.
I
want
to
just
clarify
something
in
my
head
that
putting
taking
an
IP
network
running
on
IGP
and
putting
static
routes
into
that
network
is
something
we've
done
for
a
long
time,
but
the
interface
has
been
typically
CLI
and
the
management
has
been
some
human
looking
at
what
they
want
to
do,
and
so
the
essence
of
your
proposal
is
not
really
changing.
Anything
that's
happening
in
the
network.
P
You
know
traditionally,
the
IP
network
is,
it
is
computer
controlled
by
and
by
a
human
Jovie
hell
no
capability
to
provide
this
customer
for
the
inn
and
the
service.
So
we
knew
we
needed
a
PC
or
single
controller
in
our
network
and
we
part
of
a
to
not
want
to
change
our
network
dramatically.
So
we
want
to
develop
a
northbounder,
no
sauce,
not
one
interface,
not
the
east-west
interface.
A
How
many
think
that
working
on
te
for
IP
networks
is
something
that
we
should
be
doing
in
this
working
group
independent
of
the
specific
solution,
but
just
the
topic
is
something
we
should
be
considering.
We
do
te
in
the
IETF,
it's
our
scope.
So
question
is
to
the
working
group.
Should
we
be
looking
at
this?
A
That's
that's
a
few
people,
it's
actually,
quite
honestly,
more
than
I
expected
it's
not
a
great
number.
It's
a
few
people
if
we
said
that
we
were
looking
at
this
as
experimental
work
versus
standard
work,
so
that
we
would
provide
a
home
to
sort
of
foster
development
of
this
and
see
where
it
goes.
How
many
would
be
interested
in
it
and
I'm
explicitly
asking
for
those
who've
raised
their
hands
before
not
to
raise
their
hands
now,
so
are
there
any
that
with
by
making
this
an
experimental
effort?
H
H
H
A
A
A
A
O
John
Hardwick,
yes,
so
this
was
discussed
in
PCE
a
couple
of
meetings
ago
and
I.
Think
I
just
want
to
I
wanted
this
to
come
to
T's,
because
I
wanted
some
sort
of
guidance
on
whether
this
was
sort
of
a
problem
that
we
will
want
to
be
working
on
and
I.
Think
you
know
having
having
a
poll
in
T's
to
see.
If
we
want
to
adopt
this
is
experimental,
will
give
me
the
information
I
need
to
see.
O
G
Basically,
this
is
all
a
use
cases
that
could
benefit
if
the
service
functions
are
viewed
as
topological
elements,
and
this
document
describes
a
bunch
of
such
use.
Cases
so,
for
example,
drew
from
his
presentation
also
was
talking
about
similar
use
case,
at
least
along
the
same
line
and
in
his
language
it
was
basically
a
virtual
network
which
is
enriched
with
with
software
function,
information
so
that
service
functions
could
be
discovered
and
moved
around
the
network,
and
it
would
be
possible,
for
example,
to
replace
a
failed
source
function
with
another
one
on
a
different
destination.
G
G
Alright,
so
it
was,
this
is
not
the
first
time
but
presented
it
was
presented
in
Prak
and
since
Brock
we
have
like
a
few
changes.
We
have
two
new
co-authors
Lewis
Nvidia
during
Tesco
orphans.
Okay,
we
have
a
new
section,
which
is
terminology
section.
This
define
it.
What
is
network
fonts
and
service
forms
to
service
function,
chain,
transport,
function
and
stuff
like
that,
and
we
have
to
look
at
a
lot
of
discussions.
G
So
this
is
what,
as
soon
as
function
of
where
network
topology
looks
like
graphically
on
this
picture,
you
can
see
that
service
functions
are
really
elements
of
the
team
goals
right
and,
if
you
think
about
them
as
elements
similar
to
limb
termination
points.
Tunnel
termination
points
that
you
also
know,
and
if
you
also
know
how
this
service
functions
could
be
connected
locally
and
at
what
cost.
Right.
So
having
this
information
will
provide
you,
basically,
a
very
good
graph
to
dual
optimize
service
function.
G
G
G
So
you
see,
then
you
can
actually
a
recalculation,
respond
to
change
and
pick
up
another
service
function
which
performs
the
same
functions
but
reside
on
a
different
node
and
in
inter
connect
them
with
a
different
T,
eternal
T
tunnels.
But
at
the
end
of
the
day
you
will
still
have
the
optimization
and
constraints
in
place
next
slide.
G
G
All
right,
so
one
thing
is
important
that
this
is
not
about
Lea,
free
and
up
service
functions.
Transport
functions
could
be
applicable
in
layer,
zero
and
one.
For
example.
You
can
think
about
optical
trails
with
three
re
generators
as
a
service
function
chain,
and
you
can
dynamically
select
the
proper
regenerators
all
the
network
and
basically
compute
service
function
chains
in
such
a
way
that
you
can
minimize,
for
example,
how
many
rich
aerators
you
need
for
a
critical
service
function
in
order
that
the
signal
on
receivers
will
be
optically,
reachable
next.
G
Okay,
so
the
next
person
we
want
to
solicit
more
feedbacks
from
working
group
I
have
some
discussion
part
of
those
discussions.
We
are
not
on
that
of
the
list,
so
we
would
like
to
have
some
discussion
on
the
leave
list
and
identify
more
use
cases
if,
if
it's
possible-
and
also
we
want
to
relate
this
work
to
the
network
slicin,
because
we
believe
this-
this
could
be
a
very
good
basis
for
metal
slicing
I
mean
the
software
functional
were
at
the
board.
M
This
is
true
from
probably
a
clarification
question.
Is
this
Dandy's
model
be
useful
if
I'm
using
the
excellent
tunnel
and
that's
where,
if
that's
my
common
case,
that
I
am
using
SFC
and
underlying
I'm
using
VX
lon
goodbye
model
mysterioso,
because
there
are
some
things
in
this
model
which
are
very,
which
I
find
very
interesting
and
are
useful.
So
is
it
only
when
underlay
is
de
tunnel?
That's
where
this
comes
in
or
if
can
I
reuse,
yeah.
G
Well,
this
is
Teton
House,
but
basically
we
do
not
want
to
focus
to
narrow
down
for
the
traffic
engineering
tunnel.
It
could
be
any
other
tunnels
that
interconnects
service
functions
well.
But
but
the
point
is
that,
if,
if
you
have
just
reachability
tunnels,
then
it's
not
really
important
where
the
service
functions
are
on
the
topology
right.
M
No
I
actually
I
feel
like,
even
though,
if
you
don't
use
to
eternal
since
when
we
are
computing,
the
SF
path
itself
and
if
I
have
a
choice
between
the
same
service
function
being
available
at
multiple
places.
Even
though
the
reach
ability
is
the
same.
Just
looking
at
those
properties,
I
can
make
good
decisions
on
which
service
functions,
I
should
choose
during
the
service
boy,
yeah
I
agree,
but
it's
very
interesting.
G
G
So,
as
I
mentioned
in
the
previous
slide,
we
want
to
view
a
service
functions
as
elements
of
that
of
the
node
right.
So
so
those
are
guys.
You
see
this
red
guy.
So
there
are
some
service
functions
and
we
want
to
define
them
as
a
big
boxes
which
could
be
identified
by
a
global,
unique
IDs,
and
we
don't
want
to
actually
define
sort
of
function
per
se.
G
We
want
to
reuse,
it
see
definitions
so
that
US
client
interested
client
can
use
this
service
function
IDs
and
get
the
details
of
the
service
functions,
that
open
network
and,
for
example,
understand
to
what
extent
they
are
mutually
substitutable
right,
but
over
on
the
node,
you
have
service
functions
which
have
also
connection
points
and
for
this
connection
points
they
could
be
connected
with
each
other.
In
in
a
local
service
function
chains,
they
could
be
also
connected
to
their.
H
G
G
Right
so
one
of
the
interesting
and
important
concept
of
the
key
topology
is
connectivity,
matrix,
matrix
right
and
this
connectivity
matters
can
describe
their
switching
capabilities
or
limitations
of
of
a
node.
Basically
how
the
link
termination
codes
could
be
interconnected
across
a
load
and
at
what
cost.
G
So
this
model,
basically
capitalizes
or
leverages
this
concept
and
defines
three
new
connectivity
metrics
one
of
the
first
one
is
so
responsive
to
service
Frandsen,
which
describes
how
how
the
service
function
and
which
of
them
could
be
locally
interconnected
and
the
course
and
then
source
function
to
LTP
and
so
response
on
to
TTP
right.
So,
basically,
this
is
the
connectivity
matrix
which
describe
which
source
function
could
be
connected
to
which
nodes,
LTP
and
nodes
gtps
respectively.
G
That's
right
so,
and
this
is
what
you
can
get
using
this
model.
The
client
can
get
a
for
example,
or
mdac
in
terms
of
a
CTN
terminology
can
get
from
a
domain,
a
topology
which
has
basically
the
political
information
right
and
also
sort
of
functions
which
are
sitting
on
all
the
nodes,
and
this
is
what
you
can
do
and
achieve.
For
example,
a
CTN
goals
like
service
function,
mobility
that
Daniela
was
talking
about
next.
G
G
A
It
okay.
Thank
you
interesting
early
work.
We
definitely
would
like
feedback
from
the
working
group.
Please
feel
free
to
send
it
to
the
list
sure
send
comments.
Please
do
we
are
actually
30
seconds
early
with
that
30
seconds
I'm,
going
to
go
back
to
an
item
that
we
forgot
to
mention
I
forgot
to
mention
in
the
opening
slides,
which
is
you
may
notice
that
we're
only
meeting
once
this
meeting
we
did
not.
A
Do
the
joint
yang
session
wanted
to
point
that
out
to
the
working
group
and
get
feedback
on
whether
or
not
they
feel
that
it
is
missing
or
that
the
current
format
of
having
our
individual
working
groups
not
synchronizing.
Our
model
work
across
MPLS
see
camp
and
PCE.
If
you
have
thoughts
on
that
think
it
was
a
good
thing,
a
bad
thing,
we'd
love
to
hear
from
you
individually
or
on
the
list,
and
with
that.
Thank
you
very
much
and
we'll
see
you
in
well
looks
like
we're.
Gonna
get
a
comment
almost
at
the
door.
Yeah.