►
From YouTube: IETF99-TEAS-20170718-0930
Description
TEAS meeting session at IETF99
2017/07/18 0930
https://datatracker.ietf.org/meeting/99/proceedings/
B
Our
usual
information
is
available
data
tracker
and
on
the
tools,
page
I,
really
like
the
tools
page
as
a
way
to
get
to
etherpad
as
usual,
we
would
like
to
ask
for
folks
to
jump
on
etherpad
and
contribute
to
the
interactive
note-taking.
It's
very
useful.
If
you
make
comments
to
go
onto
that
page
and
make
sure
your
comments
were
captured
appropriately.
B
I'd
like
to
say
this
is
the
usual
note.
Well,
but
it
actually
isn't.
There
are
some
very
subtle
changes,
so
this
note.
Well,
it
came
out
just
right
before
this
meeting.
The
largest
and
most
significant
change
is
that
we
have
an
updated
document
covering
covering
IPR
disclosure,
that's
RFC,
81-79
and
it
was
just
published
in
May.
The
intent
of
that
document
is
to
clarify
when
disclosures
are
required
and
when
they're
not
required.
B
B
By
the
end
of
the
week,
I'm
sure
you'll
be
familiar
in
them
on
the
administrative
side
as
usual,
we
are
streaming
and
recording
video
and
audio
and
please
jump
on
etherpad.
We
only
have
six
people
on
there
right
now
and
my
bed
as
most
of
those
are
just
gonna
watch,
so
go
to
that
link
the
tools
page
join
in.
We
will
really
appreciate
it.
We
also
are
running
jabber
I'm
on
jabber.
B
B
So
where
do
we
stand
in
terms
on
documents?
The
we
have
one
RFC
that's
been
published
since
the
last
meeting:
Thank
You
authors.
Thank
you
working
group
for
contributing
to
that.
We
have
no
RFC's
in
the
editors
queue,
but
we
have
quite
a
few
that
are
in
IHG
processing.
As
you
can
see,
three
of
them
are
in
expert
review.
B
B
The
we
have
a
couple
of
documents
that
are
post
working
group
last
call,
as
is
our
banana
practice.
We
go
through
detailed
status
for
documents,
not
on
the
agenda.
These
documents
are
an
agenda,
but
they'll
be
covered
in
that
section.
The
later
section
when
we
give
status-
and
we
have
a
couple
of
new
working
group
documents,
we
did
receive
the.
B
B
Request
for
confirmation
of
IPR
disclosure
and
performance
with
our
rules
both
on
adoption.
The
last
called
folks
are
pretty
familiar
with
this.
On
occasion,
this
step
becomes
really
slows
down
the
process.
We've
been
pretty
good
recently,
but
just
keep
it
in
mind
and
when
you
see
the
poll
IPR
poll,
please
respond
and
I'll
point
out
that
contributors
are
required
to
respond.
Participants
are
required
to
respond
if
they
contributed
in
any
way
in
the
new
definition,
which
is,
if
you
hum,
even
on
a
document.
B
You
have
to
respond
to
this
poll
saying
and
you
know
of
IPR.
You
have
to
say
that
it's
been
that
you
need
to
ensure
that
you
disclose
that
IPR
authors
are
the
only
ones
who
have
to
say
that
they
that
there's
no
idea
keep
discussions
going
on
the
mailing
list.
As
always,
private
discussions
are
great,
but
it
doesn't
bring
along
the
rest
of
the
working
group.
So,
if
you're
having
a
private
discussion-
and
you
think
that
it's
generally
applicable
to
a
working
group
document-
please
bring
that
into
to
the
mailing
list.
B
We
have
a
second
session
on
the
agenda.
It's
Thursday
1:30
in
the
afternoon.
That
is
the
joint
meeting
that
we've
been
having
the
last
few
ooh
I
guess
last
couple
years,
lower
I'll
blame
him
for
it
he's
initiated
it.
It's
a
joint
session
focused
on
interactions
of
on
gang
modules
that
are
being
done
in
each
of
the
groups
and
making
sure
that
we
have
some
cross-pollination
and
synchronization
of
solutions,
and
with
that
we're
at
the
end
of
that,
that's
will
move
on
to
document
status.
C
C
Is
the
working
group
document
status?
We
have
20
documents
in
the
working
of
currently
19
of
those
are
active.
There's
one,
that's
an
expired
state.
We
have
eight
on
the
agenda
today,
six
for
which
we
put
in
a
publication
request,
so
that
cases
at
six
and
I'll
go
the
status
of
each
of
those
in
the
next
few.
Slides
first
up
is
the
document
that
talks
about
FRR
for
associated
core
outed
by
directional
LSPs.
We
adopted
this
sometime
in
May.
The
authors
have
published
a
revision
for
this.
C
Since
then,
the
revision
covers
features
like
note
protection
reversion
and
they
also
had
some
text
talking
about
procedures,
handling
unidirectional
link
failures.
They
intend
to
add
more
text
pertaining
to
d2l
SPS
and,
at
this
point,
looking
for
further
review.
So
if
this
is
an
item
of
interest
for
you,
please
do
reach
out
to
the
authors
on
the
list
and
they
would
be
happy
to
address.
Those
next
is
the
document
that
talks
about
PCC
see
use
cases.
We
received
an
update
for
this
yesterday.
C
There's
one
version,
one
revision
that
was
published.
This
covers
all
the
addresses,
all
the
comments
that
were
raised
during
that
option
pool
the
authors
also
say
that
they
are
working
on
adding
another
use
case
to
the
document.
So
this
point
please
do
give
this
a
read
and
reach
out
to
the
authors.
If
you
have
any
questions
or
concerns,
next
is
the
egress
production
document.
We
did
take
it
to
last
call
in
May.
There
was
consensus
to
move
forward
with
this
at
this
point
that
we
are
waiting
on
the
shipper
right
up.
C
I
am
the
shepherd
I
wanted
to
take
this?
Putting
the
publication
request
for
this
before
this
meeting,
but
unfortunately
ran
into
some
issues,
this
one
major
issue
with
respect
to
a
CRO
backwards
compatibility,
there's
the
protection
object
that
shows
up
as
a
support
act
and
a
CRO.
Today
we
have
to
see
types
of
protection
object.
Both
of
them
have
fixed,
fixed
sizes.
C
Next
is
the
English
protection
document,
it's
also
in
the
same
boat
we
awaiting
on
the
Sherpa
right
up.
There
are
some
a
tutorial
issues
that
I
would
like
to
get
cleaned
up.
First,
before
taking
into
publication,
will
be
working
with
authors
to
make
sure
this
gets
done
in
the
next
few
weeks.
I
don't
see
the
need
to
take
last
call
again
for
this
document
for
equal
protection,
given
the
size
of
the
changes
we
may
consider
taking
it
to
last.
Call,
let's
see
how
that
pans
out.
C
Next
is
the
schedule
resources
document.
There
was
one
provision
published
for
this,
mainly
a
keepalive.
At
the
last
meeting,
we
put
a
pin
on
this
and
said
that
we
would
wait
on
the
document
until
the
corresponding
solution.
Stockman
progresses
in
PCE.
The
solutions
document
is
now
a
working
group
adopted
item
in
PCE,
so
it
seems
like
now
is
a
good
time
to
take
this.
To
the
next
stage
thing
we
can
do
a
poll
of
us.
B
Last
time
we
got
input
from
the
PCE
working
group,
chair
and
it'd
be
good
to
hear
if
the
PCE
working
group
had
an
opinion
on
this.
If
it's
now
at
a
point
where
they're
comfortable
progressing
this
document
or
they
want
to
keep
holding
and
for
give
them
time
to
mature
the
solution,
that's
progressing
they're.
E
Generally,
PC
culture,
I,
don't
remember
exactly
what
I
said
last
time,
but
it
rains
sorry.
It
remains
the
arrow
documents.
So
it's
up
to
you
to
decide.
How
is
it
progress
it?
So
the
eruption
in
PC
working
group,
as
far
as
I
remember,
was
clear
consensus
with
the
clear
support
behind
so
I.
Don't
see
any
open
issue
from
a
PC
perspective
here
to
prevent
you
from
progressing.
If
you
want,
you
I,
don't
remember
about
the
details
in
the
document.
E
B
Was
as
much
that
the
PC
working
group
were
taken
on
the
work
as
that,
they
feel
that
the
general
direction
is
stable,
not
the
specifics
of
the
solution,
but
the
general
direction.
If
the
general
direction
was
going
to
change
radically,
we
should
hold
this
document
up
to
make
sure
it's
aligned.
If
it's
just
the
details,
that's
okay!
We
can
progress
with
this
one.
B
D
C
C
C
Last
in
this
deck
is
the
tea
metric
recording
graph.
This
is
the
expired
draft
that
I
mentioned
earlier.
There
hasn't
been
any
revision
for
this
since
last
September.
At
the
last
meeting
we
were
looking
for
volunteers
who
could
help
with
the
progress.
Julian
has
been
kind
enough
to
come
forward
to
help
with
us.
We
are
hoping
that
we
would
get
an
update,
at
least
before
the
next
IDF.
If
there
isn't
any
progress
on
this
by
then
like
I,
guess,
we'd
have
to
drop
the
ball
on
this.
C
G
G
So
in
summary,
what
were
the
changes?
So
the
section
3
now
clarifying
the
document
which
talks
about
a
certain
procedure
on
how
to
do
SRS
will
be
coexistence,
so
the
solution
sort
of
dived
into
using
maximum
reservable
bandwidth.
So
this
text
provides
a
little
bit
more
clarification
on
what
else
could
we
have
done
to
unchurched
bandwidth
and
it,
and
it
finally
ends
in
the
conclusion
as
to
why
we
picked
maximum
visible
bandwidth?
We
also
had
an
appendix
we.
We
are
introduced.
B
B
B
H
Sometimes
you
got
quite
a
few
people,
but
we
are
finishing
up
the
discussions,
so
we
are
doing
some
cleanups
and
fixes,
and
so
we
ticked
weather
parking
items
have
been
much
cleared
so
pretty
much.
We
are
trying
to
move
this
to
the
last
car.
We
heard
that
the
request
so
asking
us
to
to
move
this
as
quick
as
possible,
because
the
implementations
are
coming
on
so
trying
to
do
that.
So
here's
the
items
we
have
change
the
since
last
ITF
sessions,
so
we
now
allow
multiple
instances
of
interlock
ideas.
So
this
is
for
that
matter.
H
We
improve
the
handling
of
the
connectivity,
matrix
label
and
we
work
with
the
t
tunnel
model
so
to
have
some
common
core
pins
and
types
to
be
shared.
So
also
we
found
the
generic
label
modeling
to
make
it
better
and
just
to
talk.
Young
doctors
should
leave
your
comments
and
finally,
we
did
the
start:
change
to
multiple
MVA
compatible
models
with
the
state
companion
model,
so
some
more
details
on
those
changes.
So
here's
an
interleague
interlayer,
lock
ID.
So
we
now
allows
to
have
multiple
instances
of
the
lock
IDs.
So
here
we
changed
from
the.
H
H
I
D
H
So
also
we
improve
the
handling
of
connectivity
matrix
rebels
and
in
some
cases
like
this,
if
you
have
a
region,
some
devices
here
may
change
label
from
wild,
and
in
this
case
they
were
here.
One
side
is
a
sex
change
debate
to
accompany
this
kind
of
use
cases.
We
move.
That's
a
label
restriction
sites
from
common,
connecting
matrix
entry
to
source
and
the
destination.
H
We
have
been
working
with
the
TV
tunnel
models
closely
so
because
this
topology
model
and
the
tunnel
model,
they
are
complementary
and
frequently
used
together.
So
we
want
to
share
the
same
coatings
and
tacks.
So
in
this
time
we
mostly
work,
and
those
are
three
copings
actually
in
normal,
though
we
use
them
for
the
undulation
tunnels.
H
H
So
about
this
is
too
generic,
sometimes
because
we
had
the
encoding
inside
the
string.
So
the
implantation
has
to
passing
that-
and
we
also
got
this
time
suggestion
from
the
northbound
interface
design
team
and
also
from
especially
from
color
and
surgical.
So
we
rework
this
deeper
further.
So
now
we
have
in
common,
we
instead
of
a
single
stream.
We
change
that
to
a
grouping.
So
we
have
a
structure.
Have
this
penguins
modeled
in
further
details
to
allow
some
well-known
technologies
have
got
more
specific
modeling
so
that
you
can
see.
H
H
K
H
Summaries
of
light
so
critically
we
want
to
merge
that
probably
way.
I
don't
want
to
put
too
much
details
here
and
that
we
have
another
session
on
Thursday.
So
this
property,
we
talk
a
bit
more
in
a
session,
so
in
particular
move
combine
the
state
branch
and
the
config
branch
into
single
branch,
and
we
remove
the
configures
state
container
and
the
state
container
make
one
single
tree
to
remove
duplications,
and
so
the
changes
that
guideline
here.
H
Yes,
we,
the
here's,
so
we
need
have
two
modules
this
time.
So
then
we
have
see
that
changes
here.
We
need
to
have
the
state
module
name,
but
here
everything
here
will
be
pretty
much
the
same.
This
is
a
true
model,
so
can
be
implemented
easily.
So
simple,
your
data
copying
and
reused.
Then
no
p8,
we
don't
want,
have
the
duplication,
but
then
for
our
model
in
your
change
is
not
that
simple.
H
So
we
need
to
adjust
of
working
specially
when
we
to
the
leaves
whenever
we
have
the
expires
or
difference
when
the
school
being
will
be
broken.
So
we
can
now
share
between
the
state
model
and
the
config
model.
So
then
we
have
we
just
groupings
and
to
some
changes
for
model.
So
eventually,
where
we
finished.
H
B
H
K
H
B
B
B
So
that's
not
a
problem
informational
reference
to
another
documents.
Fine
and
the
yank
push
is
proceeding
along
these
in
terms
of
the
tunnel.
Do
you
think
it
makes
sense
to
hold
this
document
up
until
tunnels
ready
or
do
you
think
you
can
progress
and
then
just
gets
wait
until
the
ref
wait
state
when.
H
B
D
B
Right
this
is
a
pretty
substantive
piece
of
work
and
there's.
Certainly
a
huge
amount
of
detail.
It'd
be
good
to
find
out
how
many
folks
have
read
this
version.
It
came
out
just
with
the
deadline.
How
many
have
read
this
version-
I
frankly
more
than
I
expected,
but
it's
still
a
few.
How
many
have
read
any
version?
B
See
someone's
gonna
raise
a
handgun
dissipating
what
I'm
gonna
say?
How
many
think
Igor
should
know
normally
that
last
company
I'll
ask
how
many
think
the
document
is
ready
for
last
call
it's
interesting
that
I
think
that's
more
than
that
said
that
they've
read
the
last
version
this
this
is
generally.
We
think
this
is
ready
for
last
call
as
well
and
would
like
to
progress
it
as
rapidly
as
possible,
but
given
the
size
of
the
work
and
the
size
of
the
update,
we
think
it's
really
important
to
give
it
a
very
good
read.
B
So,
even
though
pavan
is
my
co-chair,
I'll
talk
to
them
about
whether
or
not
we
do
anything
special
here,
maybe
run
an
extended
last
call
give
people
time
for
to
deal
with
vacations
that
are
going
to
follow
the
meeting
so
either
we'll
have
a
last
call
that
will
proceed
in
a
few
weeks
or
we'll
have
an
extended
last
call.
Please
start
reading
this
document
with
the
anticipation
of
it
coming
to
last
call.
H
A
few
updates
to
depend
too
late
letter
enhancement
to
this
model,
so
we
we
also
have
a
model
for
the
nursery.
Theater
pod
read
not
much
changes,
so
this
is
such
as
augmentation
to
the
generic
theater
project,
move
the
some
packets
related
in
pieces
to
this
model,
and
so
we
also
link
this
to
the
r32
party
motto,
so
we
also
to
nmda.
So
that's
a
change
it
and
this
one
is
still
in
video
draft.
So
we
want
to
move
this
to
what
coupe
option
there's
a
another
job.
B
So
we're
talking
about
this
document
we've
heard
about
this
a
couple
of
times,
which
is
why
we're
getting
just
a
brief
update
on
changes,
but
this
is
an
individual
document.
It's
been
out
there
for
a
while
the
last
time
I
believe
we
talked
with
the
working
group
and
and
folks
generally
agreed
that
this
was
function
we
wanted
to
cover.
So
we
don't
need
to
go
there
again.
How
many
have
read
this
document
and
I
mean
any
version
of
this
document.
B
It's
it's
also
just
a
few,
but
again
again
an
okay
number.
How
many
think
that
we
should
use
this
as
the
foundation
for
our
work
in
this
area?
Remember
that
we
had
previously
said
we
wanted
to
work
in
this
area,
so
I
think
it's
it's
about
the
same.
It's
a
it's
enough
to
keep
moving
so
I
think
we
should
move,
take
this
to
the
list
and
ask
the
whole
working
group
formally
if
they
would
like
to
add
on
he's
coming
to
the
might
purpose.
Moving
chairs,
okay,
yeah.
H
B
B
Think
this
we're
at
any
time
I
ask
a
question:
we're
gonna
get
the
same
number
of
hands,
even
though
it's
different
people.
So
again
it's
not
it's
not
a
huge
number,
but
also
it's
a
reasonable
number.
How
many
have
read
this
document
any
version
a
little
less,
but
how
many
think
that
this
is
a
reasonable
starting
point
for
work
in
this
area.
Just
a
few.
Does
anyone
have
any
reservations
or
anything
they'd
like
to
say
before
we
say
we're
gonna
take
the
list
for
confirmation.
L
Suppose
I'm
I'm
a
user
of
the
topology.
Why
should
I
care
whether
that,
whether
suppose
I
sit
on
top
of
an
SDN
controller
and
and
a
master
that
is
managing
a
network?
What
a
receiver
is
a
is
a
topology
I
thought.
I
would
use
that
T
topology,
independently
of
the
data
planar
I
mean
I,
don't
care
whether
below
there
is
a
rsvp-te
segment
routing
whatever
I
would
expect
it
to
receive
the
same
type
of
topology.
So
why?
Why
is
this
variation.
H
L
H
L
B
L
C
M
M
M
So
the
first
model
is
the
IDE
tunnel
model
that
we
worked
on.
So
basically,
the
summary
of
changes
are
as
following.
There
is
auto
bandwidth
properties,
it
moved
to
are
the
t
and
pls
module
have.
I
did
the
additional
path
constraints
like
tiebreaker
and
optimization
criteria.
There
is
a
LSP
upper
state,
define
and
steady-state
model
for
the
completed
part
properties
added,
and
also
the
in-and-out
segments
stitching's
added.
M
So
the
part
operational
state
there
is
a
computation
aspects
and
there
is
a
setting
up
expect.
So
it
gives
the
state
as
competition
in
progress
or
competition.
Okay
or
it
fail
or
lsbe
setup
is
in
progress.
Setup
is
okay,
Satterfield's
LSP
is
up,
so
there
is
a
lot
more
details
on
the
operational
state.
Now,
for
the
part,
that's
computed,
there
are
additional
properties,
define,
for
example,
what
is
the
accumulated
weight
in
terms
of
IGP
or
tu
our
latency
or
hop
count
after
of
the
path?
What
are
the
affinities
on
the
path?
M
In
addition
to
those
properties,
there
is
also
the
ero
type
object
define
for
the
computed
path,
so
it
looks
a
very
similar
to
ero.
There
are
a
few
refinements
here
as
well.
In
the
object
there
is
a
seed.
Hop
is
defined
as
well
as
there
is
a
hot
type.
It
could
be
strict
or
loose.
It's
been
enhance
as
well.
M
M
So
basically
a
pound
can
be
the
maximum
metric
or
latency
or
half
or
and
whatnot,
and
as
mentioned
there
is
a
hot
type
and
sit
hop
defined
for
the
ero,
so
the
other
configs
are.
There
is
optimization
criteria,
it's
very
similar
to
the
one
from
RFC
55:41,
so
it
can
be
a
one
metric
or
list
of
matrix
with
weight,
and
there
is
also
tiebreakers
it's
a
list
and
it's
an
orderly's
from
top
to
bottom.
So
in
case
the
two
parts
are
the
same.
We
have
defined
tiebreakers
as
well.
M
M
M
M
Some
of
the
things
we
want
to,
or
we
are
considering-
is
the
impact
on
the
existing
implementation.
So
if
you
have
an
implementation,
please
talk
to
us.
We
also
need
to
understand
the
impact
on
the
mod.
Does
this
augmenting
so
I.
We
know
that
there
is
PC.
There
is
BFD,
there
is
fact
a
petition
that
is
optical,
so
there
will
be
definitely
impact
that
we
should
discuss.
M
M
So
next
steps
for
us
is,
we
need
to
close
on
the
nmda
approach.
There
is
some
work
required
for
the
tunnel
are
pcs
for
the
RSVP
draft.
That
includes
the
base
and
extended.
We
handmade
changes
for
a
while.
Now
it's
stable,
so
we
do
believe
it's
a
default
working.
Your
PLAs
call,
and
we
do
welcome
your
review
in
comments.
N
You
know
brisk
in
Hawaii
I
just
wanted
to
to
make
a
comment.
T
topology,
auntie
tunnel
models
are
there,
they
have
a
lot
of
synergy
and
they
have
a
lot
of
common
types
and
groupings,
and
they
are
so
complementary
that
it
might
be
presumed
that
they
they
always
must
be
used
together,
which
would
be
our
own
conclusion.
N
N
M
N
Know
so
we
worked
very
hard
to
finalize
these
T
types
model
that
event
mentioned,
so
that
basically
there
would
be
no
additional
changes
that
would
affect,
for
example,
two
topology
model
that
would
be
also
needed
in
Titano
model.
So
we
all
work
in
tandem,
so
basically
pretty
much
the
same
group
of
people
who
works
on
teen
topology,
although
also
locks
on
Chicano
model.
So
we
do
care
a
lot
about
this
interdependencies
and
try
to
actually
finalize
before
this
meeting.
So
we
do
not
have
any
issues
at
the
moment.
Great.
Thank
you.
M
B
M
B
B
How
many
folks
are
have
read
these
documents,
I'm
asking
them
in
as
a
collection,
I
think
it
was
four
here,
it's
about
the
same
number
it
does.
Anyone
have
reservations
on
these
modules
that
they
have
not
yet
voiced
on
the
list
or
a
voice
on
the
list
and
want
to
discuss.
We
have
dieter
coming
in
to
Q
all.
K
B
B
F
O
Good
morning,
I
am
young
I'd
like
to
present
a
CTN
framework.
There
are
many
contributors
and
causes
of
this
work,
and
hopefully
we
update
what
happens
since
last
meeting
yeah.
This
is
update
for
this
version,
all
six
I
think
in
terminology
we
actually
added
networks,
lighting
terminology
from
attn
perspective.
Actually
we
used
slicing
terminology
before
5g
or
3gpp
used
slicing,
so
we
try
to
really
define
what
slicing
means
from
ICT
and
perspective.
O
So
we
added
that
I'm,
not
gonna
go
with
the
details,
but
just
you
can
find
out
from
the
document
and
CNC
is
a
customer
network
controller
we
actually
defined
in
the
text,
but
not
in
the
terminology.
So
we
made
it
clear
and
likewise
MDRC,
which
is
most
important
component
of
attn,
and
also
we
clarify
a
VN
type
virtual
network
types
because
of
a
lot
of
misunderstanding,
so
we
had
to
clarify
more
clearly
in
the
document
and
also
virtual
network
service.
O
We
use
this
term
everywhere
in
the
document,
but
we
didn't
have
one
section
that
defines
what
is
virtual
network
service.
So
we
clarified
that
unfortunate
of
service
is
requested
by
the
customer
and
negotiated
with
provider,
and
there
are
three
types
of
DNS.
First
type
of
VN
s
refers
to.
The
VNS
in
each
customer
is
allowed
to
create
and
operate
a
type
one
virtual
network.
What
what
type
one
virtual
means
is
is
a
virtue
native
that
comprises
a
set
of
entry
and
tunnels
from
customer
perspective.
O
So
there's
no
interaction
with
topology
or
t8o
know
from
their
perspective.
Customers
just
have
their
endpoint,
and
then
they
service,
like
a
beauty
like
was
a
set
of
men,
twin
tunnels
and
type
to
Vienna's,
is
most
interesting.
One
which
refers
to
the
service
that
operate
based
on
type
2
VN,
which
is
a
you
know,
type
2
VN
is
basically
abstract.
Topology
customer
can
create
based
on
negotiate,
pre
negotiated
agreement
with
the
operator,
and
then
they
can
manipulate
a
virtual
network
topology
as
part
of
the
service
and
type
2.
O
A
is
a
static,
the
politic
they
cannot
change
and
type
2
B
is
the
one
that
they
can
change,
dynamic,
dynamically,
so
type
2
a
to
be
at
the
same
school
from
the
other
point
of
view.
Is
basically
the
same,
except
for
some
policy
so
to
elaborate
little
more?
This
is
type
1
for
its
related
service
and
type
1.
Virtual
data
type,
basically
customer
create
their
endpoint
connectivity
and
then
it
provides
what
are
the
VN
members
of
that
topology
and
then
what
is
their
choice?
O
Metrics
and
traffic
matrix
is
for
that
fear,
and
also
what
is
service
policy
if
they
want
to
operate
on
and
type
2
VN
is
very
interesting,
one
which
now
we
integrate
with
T
topology
model
that
customers
who
have
and
V
internal
view,
but
the
in
the
middle.
They
have
a
VN
topology,
which
is
basically
abstract,
apology
construct,
we
reuse
a
theater
policy
model
and
then
our
customer
can
also
create
tunnels
over
this
opportunity
to
apology
type
2.
O
So
it's
a
little
more
complex
and
but
there
are
some
customers
they
want
to
have
this
type
of
capability,
so
we
added
we
just
clarify
that
this
is
a
part
of
the
scope
and
also
the
rest
of
the
procedures
are
the
same
and
I
think.
In
our
last
meeting
we
had
some
question
on
how
ICT
and
architecture
with
more
generic
architecture
there
is
address.
In
the
end
service,
young
model,
Adrienne
and.
O
She
knew
they
developed
and
they
also
use
the
orchestrator
terminology.
So
there's
some
issue
with
MDS
C,
because
M
this
is
very
tacky
terminology
with
industries
working
group,
not
many
people
not
familiar
with
what
is
MDS
C,
and
so
we
had
to
kind
of
provide
some
kind
of
mapping
between
MDS
C
and
then
Orchestrator.
As
you
see
here
on
the
right
side
MDS,
he
has
some
components
function,
one
and
function.
They
are
service
related
function
such
as
customer
net
or
mapping
function,
and
then
a
virtual
network
service
operation
function
that
interface
with
a
customer.
O
You
know
request
and
Cambodian
or
network
related
terminology,
and
then
we
have
function
three
and
four,
which
is
a
virtualization
abstraction
function
and
voltage
domain
coordination
function.
So
those
functions
are
actually
especially
function.
One
function
can
be
a
pair
of
service
Orchestrator.
The
service
working
sphere
is
not
same
as
mdac.
O
They
may
have
other
functions
known
as
visiting
functions
to
perform,
especially
an
aunty
type
of
function,
service
function,
layer-3,
mapping,
function,
things
like
that
and
and
the
network
will
consider
we
share
with
some
functions-
functions
3,
&,
4,
but
network
history
may
have
known
as
ET
and
functions
as
well.
So
we
kind
of
added
this
diagram
so
that
people
can
have
a
better
picture
and
even
customer
what
is
customer.
We
have
CNC
controller
perspective,
but
there
may
be
other
functions
that
customer
want
in
there
to
the
network.
O
So
we
draw
on
CNC
blog
and
likewise
pnc
fiance
is
a
physical
network
controller,
which
is
a
component
of
domain
controller.
Our
domain
controller
may
have
other
functions,
then
pnc
so,
and
then
we
try
to
map
our
CMI
is
corresponds
to
customer
service
model
and
then
MPI
is
a
network
configuration
model
basically
and
and
pians
SBI
is
a
service
delivery
model.
So
this
is
basically
we
kind
of
expanded
to
explain
to
their.
O
The
readers
who
are
not
familiar
with
is
a
tea
terminologies
and
a
c10
terminologies,
and
also
we
added
a
new
section,
a
topology
abstraction,
which
is
basically
input
from
other
draft
directly
T's
a
CTN
abstraction
per
working
group
comments.
So
we
brought
back
black
great
white
terminal,
topology
terminology
into
the
framework
and
then
I
think.
One
question
was
then,
who
then
Lee
TAC
10
abstraction
have
enough
content
to
keep
as
a
separate
document.
O
I
think
we
still
believe
is
still
like
of
12
to
13
pages
of
information
there,
which
is
a
sufficient
information
to
be
contained
in
the
document.
I
think
granny
Allah
will
present
later
on.
What
stop
you
know
the
status
of
that.
We
have
other
content
that
may
stay
there,
because
bring
that
into
a
framework
may
be
too
overwhelming,
because
we
have
a
large
pages
already
in
the
framework.
So
this
is
one
resolution
that
we
made,
and
then
we
put
a
couple
of
appendices
to
discuss.
O
Advances
topic,
like
example,
of
MDS
and
PN
C
function
or
integrated
in
service
network,
is
greater
because
a
lot
of
implementation
have
MDS
if
function
and
function
in
one
box.
We
try
to
explain
that
that
can
that
implementation
can
exist,
and
also
IP
and
optical
with
layer,
3
VPN
service,
how
this
architecture
support
and
what
kind
of
functional
component
fit
in
to
support
that.
So
we
kind
of
added
as
an
appendix
to
further
explain
in
a
para
explain
some
other
scenarios.
O
So
summary
I
think
we
believe
that
all
pending
issues
and
discussions
are
made
through
working
group
meetings
in
in
Chicago
and
also
some
other
mayor's
exchanged
having
all
resolved
and
updated
in
this
version
and
I
think
one
issue
was
a
network
I
think
we
had
that
both
yesterday.
So
we
want
to
make
clear
that
all
networks
lies
and
related
work
not
depend
on
this
document.
This
document
is
ready
to
move
ahead
without
being
blocked
by
the
discussion
in
network
slicing
and
once
IETF
has
a
stable
definition
of
network
slicing.
O
You
can
return
to
that
definition
and
then
see
how
a
CTN
is
applicable
to
that
definition
and
and
determine
whether
more
work
is
needed
and
actually
for
that
and
we
actually
Daniel
King
in
yes,
the
network
slides
involve
presented
how
a
CTN
can
be
applicable
to
network
slicing.
So
we
have
we're
going
to
address
those
additional.
O
C
B
P
B
P
The
requirement
document
is
more
or
less
stable
from
some
time,
but
we
get
some
feedback
last
time
related
to
the
need
for
clarification.
What
requirement
is
unfair
to
so?
What
is
this
type
of
requirement?
Okay,
rato
requirement.
What
so
we
focus
and
really
shape
a
little.
The
document-
and
this
document
now
is
just
focusing
on
no
Kirito
requirement.
P
Okay,
rato
requirement
that
I
we
split
in
point.
That
is
the
the
service
specific
requirement
that
is
more
related
to
the
service
coordination
function,
so
the
viprinet
or
service
policy
needed
in
the
in
the
in
the
case
of
a
CDN
and
the
natural
related
operation.
So
the
require
are
related
to
the
managing
of
multi
domain.
Would
layer
aspect
of
the
asset
en,
and
so
we
shape
the
document
and
separate,
and
there
is
no
more
deleted-
has
been
deleted.
All
the
part
of
the
require
ality
today
interface,
specific
requirement.
P
C
Any
questions,
so
we
will
come
back
to
the
question
on
last
call
for
the
requirements
document
after
the
abstraction
after
daniel
is
presentation
for
this,
so
the
infimum
Wordle.
Do
you
want
to
tie
the
fate
of
this
to
the
Talal
yang
model?
Do
you
think
you'll
have
to
keep
aligning
it
to
how
the
data
model
pans
out
or
do
you
think
it's
stable
enough?
Do
you
foresee
any
changes
to
be
made
to
the
informant.
P
P
O
B
B
B
It's
a
little
good
number,
but
it's
definitely
less
on
the
info
model.
How
many
think
that
it's
ready
to
progress
ready
last
call
I'd
say
it's
about
the
about
the
same
number:
let's
see
the
fate
of
the
other
documents
and
Pavan
and
I
will
talk
offline.
If
it
makes
sense,
you
think
it
makes
sense
the
link
or
separate
what
we
heard
from
the
authors
is
that
the
info
model
really
can
be
progressed.
Independent
of
any
other
document.
L
B
L
L
Let's
start
from
the
from
the
applicability.
What's
the
purpose
of
this
draft,
this
is
another
draft
that
has
been
around
for
for
a
while
and
I
believe
it's
pretty
important,
because
it's
the
one
that
explains
how
to
use
existing
models
to
meet
the
seti
requirements
and
to
satisfy
what
is
described
in
the
framework
and
provides
an
analysis
of
what
is
missing.
I
would
say
that
when
this
work
started,
it
was
explaining
what
was
missing,
because
in
the
meanwhile,
we
tried
that
to
fill
the
gap.
That
was
there,
for
example,
the
Debian
models.
L
Short
update
so
again,
this
document
says
hey:
if
you
wanted
to
build
a
cmi,
you
need
the
twelfth
these
models
implemented.
If
you
want
to
build
an
MPI,
you
needed
to
have
these
models
implemented,
we
tried
to
collect
the
set
of
functions
that
are
needed
against
each
different
interface
and
they
are
basically
when
it
comes
to
the
CMI.
We
have
the
transport
service
request.
Here
you
have
a
link
to
the
reference
to
the
related
model,
then
the
butyl
network.
This
is
great
news
in
the
in
the
semi.
Basically,
you
can
request
for
avian
service.
L
You
can
request
for
the
instantiation,
just
rapid,
computation
or
performance
monitoring,
the
telemetry
and
so
on
and
so
forth.
One
more
thing
if
a
Kurt
remember
this
is
an
optional
feature
over
the
semi
is
a
topology
of
suction.
So
whether
you
are
sitting
on
top
of
the
MPI
or
the
semi
you
can
ask
for
topology,
then
we
have
the
MPI,
the
MPI
as
a
set
of
technology,
agnostic
functions
and
the
set
of
technology,
specific
ones.
L
The
technology
specific
ones
are
mostly
that
the
work
that
is
being
done
in
in
Sikkim
regarding
OT,
n,
specific
augmentation,
the
topology
and
the
data
tunnel,
the
table
shown
specific
implementation,
extensions
and
so
on.
When
it
comes
to
the
topology
agnostic.
Once
we
identified
the
dysfunctions,
scheduling,
which
is
I
mean
one
of
the
functionality
you
can
ask
for
against
the
tunnels
anthropology,
but
computation,
but
provisioning,
topology
instruction
and
performance
monitoring
and
summary
again.
D
L
Are
referenced
by
this
draft
are
pretty
stable,
pretty
close
to
last
call
stages
because
did,
for
example,
the
mandatory
models
for
the
MPI
are
the
T
topology.
That
eternal
may
be
the
one
that
is
not
yet
advanced
in
the
in
the
process
is
the
part
computation
one,
but
it's
just
one
of
the
functionalities.
B
Sorry
so
this
type
of
draft,
this
type
of
information
is,
we
have
typically
done,
but
we've
always
done
it
as
inside
a
framework
where
we
talk
about.
What's
there
what's
missing
and
it's
a
snapshot
in
time,
and
we
just
include
it
in
the
framework,
it
is
there
any
reason
that
this
time
you
were
you're
doing
it
separately.
Is
it
just
that
it?
You
didn't,
have
the
text
when
he
wrote
the
framework
and
then
this
is
coming
later
and
you
feel
comfortable,
including
you
know
it.
The
point
is
that
this
is
not
just
a
gap.
Analysis.
L
This
is
a
sort
of
guideline
I
mean
you
want
it.
We
discussed
a
lot
to
whether
these
needed
to
be
a
standard,
rack,
a
standard
track
document
or
an
informational
document,
because
these
mandates,
what
you
need
implemented
to
build
the
dam
pin2,
the
semi.
So
from
a
given
point
of
view,
this
would
be
a
standard
track
document,
but
we
decided
that
would
describe
it
as
an
applicability.
This
is
the
the
main
reason
that
for
for
the
vision
and
the
reason
why
it's
a
separate
and
document
is
it's
not
just
a
governance.
B
B
Q
Homeopathy
personally
I'd
like
to
say
if
we
refer
to
as
the
actn
framework
I
assume
it
should
be
a
self-contained
document
and
currently
I
think
the
shape
is
complete,
and
this
draft
is
mainly
focused
on
a
kind
of
applicability
analysis
on
the
idea
of
young
models.
Today's
the
architecture
and
I
think
we
do
not
need
to
enumerate
every
possibility
or
applicability
and
in
the
framework
crafter
that
is,
that
is
not
fair
for
for
some
potential
approach
or
solutions.
Q
So
I
would
like
to
say
we
we
do
this
separately
and
we
can
follow
the
progress
of
the
framework
route
and
after
the
framework
property
is
perceived,
we
can
double
check
whether
the
this
applicability
analysis
that
is
consistent
with
what
we
have
imposed
a
city
inside
and
I,
give
young
motorcyle.
Thank.
O
You
young
I,
think
we
I
agree
with
how
many
ins
analysis,
because
no
framework
is
technology
independent
and
be
aware
that
in
PCA
we
have
applicability
of
hd10
to
pca.
So
we
need
to
separate
applicability
of
young
from
you
know
framework
as
well,
because
we
don't
want
to
tie
implementation
and
protocol
and
data
model
or
from
this
framework,
because
there
are
different
ways
to
implement.
So
I
just
know
echo
it
that
okay.
B
We've
done
that
in
the
past
the
scope
it
so
the
to
narrow
the
scope
of
the
work.
Do
you
think
this
document
will
be
should
wait
for
the
progression
of
some
of
the
other
work?
Some
of
the
documents
is
referring
to.
Maybe
some
new
documents
that
might
show
up-
or
would
you
like
to
see
it
progress
and
then
be
a
little
out
of
date,
should
be
a
snapshot
in
time.
So.
B
K
B
F
F
B
O
F
Written
bit
like
a
wishful
thinking,
it
doesn't
exactly
describe
interruptions
between
different
models
and
how
they
work
so
I
think
there's
additional
work
required
to
make
it
really
beautiful,
for
people
are
going
to
implement
it.
It's
not
just
you
need
this
number
of
models.
You
also
need
to
describe
how
they
interact
with
each
other
good
point
yeah.
So.
B
I
think
it's
good
to
get
the
preference
of
the
working
group
or
those
in
the
room
of
it,
whether
they
prefer
bringing
this
into
the
framework
or
keeping
it
separate,
as
the
authors
recommend,
so
we're
gonna
ask
the
two
questions:
how
many
folks
think
it
makes
sense
to
keep
the
to
roll
this
document
into
the
framework
and
keep
in
mind
the
comments
both
Daniella
and
young,
made?
How
many
think
it's
it's
good
to
roll
it
in
zero
I,
don't
think
I
even
need
to
the
other
question,
because
zero
losses
so
keeping
it
separate.
B
It
sounds
like
the
way
to
go.
How
many
people
think
that
this
is
a
so
right
now.
This
is
a
individual
document
and
we're
going
to
ask
a
question
about
taking
into
a
working
group
document
how
many
think
that
this
type
of
function
or
this
type
of
document
is
good
for
the
working
group
to
produce
it's
it's,
it's
a
there's,
a
reasonable,
it's
a
reasonable
number,
but
it's
a
small
number.
So
either
people
are
not
interested
in
the
topic
or
they're
sleeping.
B
How
many
have
read
this
document?
It's
about
the
same,
maybe
a
little
more.
How
many
think
it's
a
foundation
good
foundation
for
the
working
group,
the
same
so
I
think
this
is
a
good
thing
to
take
to
the
list
for
confirmation
to
bring
it
as
working
the
document.
Thank
you.
So
you
have
another
part.
Oh
you
have
another
one
and
you
have
about
ten
minutes.
L
Okay,
this
is
probably
even
short,
a
toast.
We
had
a
similar
discussion
about
the
ast,
an
abstraction
methods
and
we
were
in
the
end.
We
decided
to
have
some
text
from
from
the
draft
into
the
framework.
Just
recap:
what
is
described
another
in
the
abstraction
method,
all
the
different
ways
in
which
the
topology
can
be
presented
from
the
M
PNC
20mg
over
the
NPI,
and
on
top
of
them
you
see
to
the
customer.
L
Whiter,
which
is
the
full
detail
on
the
topology
and
then
all
the
different
shades
of
gray.
In
between
that,
so
we
moved
them
the
basic
definitions,
the
framework
then
Devon
point.
Should
we
remove?
Should
we
move
the
remaining
part
of
the
text
to
the
document,
or
should
we
keep
these
drafter
standalone
them?
L
The
authors
believe
that
there
is
still
enough
meat
to
keep
his
document
as
a
standalone
document,
because
it
still
describes
abstraction
factors
in
the
Aegean
architecture.
It
describes
in
details
all
the
different
methods
that
can
be
used
to
build
a
great
apology,
because
that's
a
little
bit
more
complex
that
just
simply
great
or
is
simply
black
or
simply
white,
and
it
also
define
the
protocol
and
data
model
requirements.
L
So
these
are
the
reasons
why
the
authors
believe
that
there
is
enough
enough
emitter
to
keep
this
document
as
a
standalone
document,
but
this
is
obviously
a
good
topic
for
the
next
discussion
summary
next
steps.
This
is
the
next
step
slide
that
we
presented
that
to
the
last
at
the
last
meeting
in
Chicago.
L
Actually,
we
were
super
happy
about
to
the
feedback
that
we
got
from
from
the
presentation,
because
a
lot
of
people
thought
that
there
was
a
lot
of
confusion
on
the
different
types
of
topology.
The
different
ways
that
topology
can
be
presented
over
the
different
ICT
and
interfaces
homework
is
done.
We
we
wrote
this
document,
we
we
have
a
lot
of
a
lot
of
text.
The
draft
is
table
and
again,
depending
on
the
discussion
we
we
believe
this
is
another
good
good.
C
B
It'd
be
good
to
go
into
why
there's
value
into
keeping
it
separate,
because
as
when,
we
really
read
it.
We
think
that
it's
important
to
read
this
document
just
as
much
as
reading
the
framework
and
requirements
and
you
have
to
decide
which
part
goes
where,
but
basically
it's
it's
almost
that
the
framework
and
requirements
don't
stand.
L
Alone,
they
need
this
document
actually,
in
order
to
read
and
understand
the
framework,
you
need
to
know
what
black
white
and
gray
topology
mean
and
that's
what
we
imported
it
to
texture,
but
you
don't
need
to
go
into
the
details
of
the
entire
process,
and
so
on
I
mean
it's
a
suggestion.
If
you
think
that
it's
you
can't
read
it
the
framework,
without
this.
B
It
seems
it
fills
a
necessary
gap
and
it
becomes
an
unnecessary
dependency
that
we
could
just
take
the
matific
the
last
time
we
talked
about
it.
It
seemed
that
the
working
group
agreed
that
this
was
good
material.
We
can
ask
the
room
if
they
change
their
mind,
but
I
don't
think
you
want
to
well.
If
anyone
has
objections
to
the
current
tax,
they
should
come
to
the
mic.
B
So
we
should
we're
going
with
presumption
that
the
working
group
still
believes
this
is
good
material
and
it
just
seems
that
it
would
be
natural
to
incorporate
it
fully
into
some
of
it
goes
to
the
requirements.
Some
goes
to
the
framework,
but
it
seems
it
would
be
natural
to
to
bring
it
in
fully
into
those
documents.
So
there's
not
another
dependency
to
to
go
understand
the
problem.
Space
I
personally,
don't.
L
B
B
L
O
This
is
young
I
think
this.
What
about
the
remaining
content
is
actually
quite
advanced
material
that
the
reader
of
the
framework
would
not
need
to
know
actually,
because
topology
estoppel
is
a
gray
or
black
or
white,
and
then
we
have
key
topology
model
that
explains
well
so,
but
this
one
is
kind
of
building
on
top
of
that
encase
topology
obstruction
is
not
good
enough
for
the
NDS
to
operate.
They
want
to
get
additional
information
through
request
and
reply
type
of
things,
so
this
is
quite
advanced
material
from
my
perspective
and,
of
course
perspective.
O
B
B
O
B
Q
I
think
it's
a
good
hobby,
Holly
I
think
her
the
framework
craft
current
version
already
addressed.
What
is
abstraction
and
what
is
basic
terminology
is
required
in
the
inter,
inter
scenario
and
for
the
abstraction
method
to
draft
it
just
to
indicate
how
different
kind
of
approaches
can
be
used
to
do.
The
abstraction
and
I
think
that's
a
different
dimension
compared
on
the
framework
that-
and
there
may
be
some
potential
future
techniques
or
other
kind
of
related
technologies.
Q
K
Thank
you.
You
know.
My
name
is
Micah
Scharf,
mainly
speaking
here
for
teacher
wood.
That's
what
to
risk
the
button
once
again,
but
I.
Might
it
wasn't
my
my
own
impression
I
think
we
have
quite
a
number
of
different
documents
here
and
yes,
the
risk
of
inconsistencies.
So
if
there's
a
way
of
reducing
the
number
of
documents
that
wouldn't
will
harm
a
map-
okay,
yeah.
B
How
many
would
object
to
merging
this
document
into
the
as
appropriate
requirement
the
framework
and
requirements
documents
it
you
split
it
as
you
see
it
not
rub.
Sorry,
no,
but
you
distribute
the
document
to
existing
working
with
documents,
as
you
as
the
author
see
fit.
So
how
many
think
that
how
many
object
to
absorbing
this
document
into
existing
working
group
documents
any
objections
to
that
young,
you
Alicia
crazy,
so
we
had
no
one.
O
We
can
upload
this
one
right
away
this
week
and
then
would
without
changing
our
content,
just
cut
and
paste,
and
if
we
do
that,
if
you
want
to
do
that
good,
the
working
group
chairs
can,
you
know,
still
call
for
last
call
because
people
ready
right
is,
you
know,
draft
right,
and
what
is
your
position?
You
know
not
delay
another
meeting
to
like
on
November
because
of
that's
not
desirable
at.
B
This
moment
my
position
is
that
it
would
be
best
to
come
up
produce
the
best
document
the
working
group
can
mmm-hmm
and,
if
that's
by
doing
a
simple
cut
and
paste
great,
but
I
would
think
that
it
would
be
more
to
be
produce
a
better
document
to
do
a
real
integration
of
the
text
and
when
the
documents
ready,
we
will
last
call
it.
We
will
not
last
call
it
before
we
and
the
working
group
think
it's
ready
so
I'm
not
going
to
make
any
promises.
You're
gonna
say
that
I
this
will
produce
a
better
document.
B
If
the
documents
going
to
be
ready
at
that
point
in
the
working
group
agrees,
will
last
call
it
right,
but
you
know
I
think
you
should
do
something
intelligent
I!
Don't
think
you
should
just
do
a
simple
drop-in,
because
that
gets
a
verbal
agreement
to
move
the
document
immediately,
and
that
makes
you
for
a
gate.
We're.
O
B
R
So
it's
difficult
for
me
to
answer
I'm,
not
I'm,
not
it's.
Ok,
not
leather,
dedicated
document,
but
I,
don't
see
any
other
documents
where
this
material
can
fit.
So
at
this
moment,
I
would
prefer
to
keep
the
current
document
and
see
whether
new
advanced
features
for
ICT
and
come
up.
So
we
can
try
to
combine
them
because
I
think
advanced
features
in
a
framework
easily
to
be
to
overload
in
the
document.
A
A
It's
too
much
information
kind
of
scattered
out
in
a
number
of
document
that,
if
you
actually
are
due
to
submerge
it
into
those
other
document,
I
don't
see
the
implication
and
I
don't
think
we
I
think
this
discussion
is
an
almost
impossible
to
have
in
this
kind
of
horror,
so
yeah
if
it's
reasonable,
submerge
it
into
it.
If
it's
reasonable
to
have
it
a
separate
view
is
a
separate
off
month,
but
they
I
think
you
need
to
take
that
discussion
a
little
bit
more
educated
than
just
a
question
in
an
open
meeting.
F
L
B
About
since
you're
interested
in
trying
to
make
it
work,
it's
a
pass
at
it,
either
publish
it
if
you
guys,
like
it,
publish
it
as
a
new
Rev.
If
you
don't
like
it,
publish
it,
some
you
know,
put
it
up
on,
get
and
send
it
to
the
working
group
and
say
here's
what
it
would
look
like.
What
are
the
opinions
of
the
working
group
and
we
can
have
a
more
as
Lowell,
was
talking
about
more
thoughtful
discussion
in
specific
context.
It's
always
tough
to
have
hypotheticals.
B
C
O
This
is
young
again,
a
group
I
represent.
There
are
models
for
HTT
and
TN
service
operation.
I
think
you
know
this.
One
I
think
I
elaborated
in
the
framework.
We
added
alternative
service
and
this
basically
fulfills
CMI
customer
to
MDS
interface,
and
this
is
basically
aligned
to
customer
service
model,
and
this
is
actually
see.
Emma
is
a
business
boundary
between
customer
at
a
provider
so
VN
young
model.
O
We
clearly
defined
TN
types
and
VN
s
types
referring
to
the
framework
and
allowing
it
information
model
and
add
its
justification
section
why
this
is
needed
and
then
this
young
model
is
an
MD,
a
compliant.
I
think
this
is
a
repetition
of
the
slide
I
have
presented.
But
let
me
do
it
once
more
Ian
type,
one
is
customer
defines
of
year
and
list
of
VN
members
that
constitute
the
VN
and
with
curious
and
SLA
metric
all
of
the
parameters
for
the
VA.
So
this
is
a
customer
driven.
O
You
know,
type
and
type
to
same
as
type
1
plus,
not
just
a
Cosmo
want
to
operate
an
to
internal
level,
but
it
wants
to
operate
on
the
virtual
network,
topology
logo
for
advanced
customers,
and
they
want
to
utilize
some
virtual
network,
topology
capability
and
tunnel
capability
and
type
2.
A
is
a
one
set.
The
topology
is
to
stay
with
the
same,
but
if
you
want
to
change,
that's
tied
to
dynamic,
so
I
think
I
elaborate
this
in
the
framework,
so
this
is
basically
type
1
and
type
2.
O
As
you
see
here,
it's
a
little
bit
more
complex.
It's
not
just
endpoint
a
tunnel
view,
but
internal
view
has
a
topology
inside
it,
so
they
can
manipulate
some
kind
of
traffic
steering
or
load
balancing
across
this
virtual
topology.
We
are
reusing,
ot,
topology
model
that
xiufeng
and
ego
and
company
worked
on,
and
then
we
can
create
tunnel.
On
top
of
this
virtual
network
topology
from
a
VN
member
perspective,
they
want
to
shift
the
traffic
from
one
location
to
another.
This
is
done
that
way.
O
So
justification,
why
need
a
VN
type
one,
because
most
customers
doesn't
want
to
get
involved
details
of
the
topology?
So
this
is
a
very
justified
and
then
so
we
have
a
VN
compute
module,
and
then
we
have
a
multi
source
destination
idea,
because
multi-source
merged
entity
means
customer
gave
a
set
of
potential
sources
and
the
set
of
potential
destination.
It
doesn't
determine
tunnels
yet,
but
depending
on
the
network,
condition
it
chooses
and
then
customer
can
inject
a
policy
to
the
operator.
Please
choose,
one
of
you
know
sets
defined
in
multi
source
and
merciful
destination.
O
So
this
type
of
model
is
very
important
for,
like
transporting
some
important
us
compute
data
or
store,
which
is
outside
of
Asia
TM,
but
still
customer
can
give
a
preference
based
on
network
condition.
So
network
can
inject
what's
the
best
for
the
customer
to
know
and
other
things.
So
we
have
a
mapping
of
the
end
to
services,
layer,
3,
SRAM
and
layer,
2
SN,
which
is
very
important
because
into
some
are
tied
to
that
and
also
we
are
telemetry,
a
performance
monitoring
and
author
scaling
intent,
configuration
method
for
the
VN
and
also
for
tunnel.
O
So
I
think
you
know
I
kind
of
elaborate
all
these
features
here,
and
this
is
the
VN
young
model.
As
you
see
here,
we
have
access
point
definition
and
the
list
of
virtual
network
access
point
inside
of
each
access
point
and
we
also
reference
to
of
T
topology
reference
so
that
whenever
T
topology
update,
we
can
this
model
will
operate
on
that
so
that
they
can,
you
know,
set
up
the
path
if
you
will
configure
our
abstract
paths
and
then
it
handles
multi-source
and
more
assassination
with
other
service
policies
that
listed
tamborim.
O
B
B
O
J
I
may
try
to
answer
this
question.
So
if
you
look
at
the
yang
model
in
itself
right
now,
you
will
see
that
the
only
difference
between
the
type
1
and
type
2
is.
We
have
a
reference
to
the
abstract
ee
topology.
So,
irrespective
of
which
way
you
are
using
the
yang
model,
constructs
are
the
same.
You
have
the
access
point,
you
have
the
V
and
ap
and
you
have
what
are
the
requirements
in
case
of
the
N
type
2?
J
You
have
an
extra
mechanism
that
you
can
also
refer
to
the
abstract
e
topology
draft,
so
I
I
kind
of
agree
with
you
that
at
the
higher
level
it
looks
like
there
are
two
different
things,
so
maybe
we
should
model
them
except
differently,
but
when
it
actually
comes
to
writing
the
yang
model,
they
kind
of
look
almost
similar.
So
if
you
look
at
the
yang
model,
you'll
get
what
I'm
trying
to
say
here.
K
This
is
really
not
exactly
clear
to
me,
because
it
and
a
lot
of
things
that
you
draft
mentions,
is
a
motivation
for
that
list,
that
you
can
definitely
do
this
in
other
ways,
so
applying
policy
to
more
than
one
tunnel,
for
example.
This
is
something
that's
easy
to
do:
a
young
model
for
that
doing,
pass
computation
on
more
than
one
tunnel
or
his
constraints
between
the
tunnels.
Again,
something
you
can
do
having
a
common
identifier
for
multiple
tunnels.
Is
this
all
things
you
can
do
in
software?
Yes,
this
is
not
rocket
science.
J
So
if
you
read
our
justification,
I
think
the
main
justification.
You
are
right
that
at
the
higher
level,
it
does
look
like
that
we
are
just
grouping
a
bunch
of
the
Eternals
together,
but
the
main
question
is
as
a
customer:
how?
What
is
the
best
way
for
me
to
tell
you
my
requirements
to
the
service
provider
and
if
I
am
thinking
in
terms
of
a
virtual
network?
Are
we
an
info
model?
Are
a
VM
framework
everything
talks
in
terms
of
a
V
n?
J
Wouldn't
it
be
better
for
us
to,
even
in
the
yang,
to
use
the
same
terminology
same
construct.
So
that
is
one
of
the
key
reasons
and
the
same
reasons
hold
good
for
any
service
yank.
You
could
try
to
set
up
an
l2
VPN
also
by
talking
in
terms
of
the
RF,
but
we
don't
do
that.
We
write
a
service
model
with
simplifies
things,
so
I
feel
that
the
still
holes
for
our
DNA
yang
model.
K
N
You
know
person
I,
think
I,
agree
with
my
goal:
I
think
just
having
like
a
list
of
tunnels,
it
doesn't
produce
any
more
value
and
it
doesn't
tell,
for
example,
to
the
customer.
How
exactly
can
I
use
these
tunnels,
for
example?
How
do
what
kind
of
adaptation
capabilities
what
kind
of
payload
I
can
actually
put
on
this
tunnel?
So
this
is
what
apologists
are
for
right.
N
So
when
we
have
our
exam
in
the
teeth,
apology
Moodle,
they
have
a
way
to
say
that,
basically,
those
tunnels
could
be
used
in
this
way
because
they
can
adopt
those
clients
and-
and
basically
this
is
so
much
bandwidth
that
is
still
available
for
application
and
so
forth.
Just
having
connectivity
between
two
sides
doesn't
tell
me:
how
can
I
use
tiles
right?
Okay,
so
basically
topology,
which
is
in
my
opinion,
is
nothing
different
from
virtual
network
would
be
sufficient.
N
O
I
think
that's
why
we
differentiate
type
1
and
type
2
and
you
are
referring
to
type
2.
We
agree
with
that,
but
many
customers
don't
need
that
complexity.
They
just
want
to
operate,
set
up
tunnels
together
in
a
correlated
way
and
I,
don't
think
eternal
model
provides
that
you
know
mechanics
and
the
parameters
for
so
this
policy
aspect.
So.
N
B
Sorry
to
cut
off
an
interesting
discussion,
I
actually
would
really
like
to
continue
this
and
have
some
additional
points
I'd
like
that,
but
I
we're
already
ten
minutes
over.
So
please
discuss
this
more
on
the
list
and
let's
not
wait
until
the
next
meeting
to
discuss
this
graft.
Let's
take
it
up
on
the
list,
so
crew.
If
you
have
enough
points
to
respond
to
start
the
discussion
by
responding
to
those
and
maybe
that'll
help
be
a
catalyst
for
more
discussion.
Ok,
so
let's
move
on
to
your
next
presentation
and
I'm
sorry
you're
running
a
little.
J
J
So
a
quick
introduction.
This
yang
tries
to
map
the
services
like
l3s
ml2
sm,
with
the
traffic
engineering
tunnels
that
are
used
so
either
to
the
t
tunnel
model,
as
well
as
to
the
VN
model.
We
also
try
to
specify,
basically
when
you
set
up
a
service.
What
is
your
requirement
with
respect
to
t
tunnel?
Are
you,
okay,
with
just
picking
up
whichever
t
tunnels
are
available?
J
That
is
let
the
the
peer
outers
and
the
SBR
routers
pick
whichever
tunnel
is
available,
or
you
would
like
to
make
sure
that
we
set
up
a
new
tunnel
and
that
tunnel
is
only
used
by
a
particular
service,
perhaps
like
a
network
slicing
way.
So
this
kind
of
requirement
can
be
easily
set
via
this
mapping
model
and
the
the
VN
and
the
l3
SM
model,
which
are
two
separate
yang
model
and
can
exist
separately.
This
is
the
yang
model
that
brings
them
together
and
say
this
l3
SM
service
use.
J
This
set
of
Aviance
and
we
said,
T
turnip.
This
is
consistent
to
the
MDS
C
framework
as
well,
and
you
would
see
that
they,
the
new
framework
update,
has
appendix
which
talks
about
how
l3
VPN
can
be
set
up,
and
what
is
the
relationship
with
the
actn
VM?
We
also
clarified
that
the
scope
of
this
mapping
model
is
similar
to
the
scope
of
l3
SM.
That
is
in
this
case
the
l3
SM
is
for
a
single
service
provider.
So
here
also,
this
mapping
is
within
one
service
provider
network
next
slide.
Please.
J
In
this
case,
the
sample
flow
would
look
like
this
that
the
customer
may
only
talk
in
terms
of
l3
SM
and
the
MVS
see
internally
may
create
the
VN
required
for
this
VPN
to
set
up
also
asan
necessary
requirement
to
the
PNC
down
to
the
devices
and
make
sure
that
the
vrf
instances
that
are
created
are
binded
to
the
tunnels
of
this
particular
VM.
Next
slide.
J
Next
slide,
please
yeah,
so
we
also
updated
in
the
text
that
yes,
there
are,
there
can
be
multiple
modes
and
multiple
ways.
This
can
be
done.
It
could
be
simply
a
selection
of
an
existing
tunnel
binding
of
a
new
tunnel
created
as
well
as
a
case
where
the
operator
allows
to
use
an
existing
tunnel,
but
change
its
bandwidth
or
its
its
properties.
Some
may
allow
the
changes
only
in
the
IP
layer
and
no
changes
in
the
optical
other
may
allow
changes
in
both.
J
This
model
can
also
take
there.
I
have
shut
the
web
cam
so
that
my
audio
goes
through.
That's
what
the
meet
echo
told
me.
So
that's
why
you
are
not
seeing
our
video
I'll
continue,
so
this
model
also
has
the
ways
to
say:
oh,
you
can
create
new
viens
and
tunnels,
but
try
to
keep
changes
only
in
the
IP
MPLS
there
or
you
can
also
change
in
the
optical.
So
this
has
been
now
added
into
the
document.
Next
slide.
J
This
slide
shows
the
relationship
that,
as
we
know,
that
there
can
be
multiple
services,
so
we
will
have
services
on
the
left
hand,
side
and
you
could
either
talk
in
terms
of
DN
or
in
terms
of
D
tunnels.
So
those
are
things
on
the
right
hand,
side
and
this
mapping
model
is
the
one
that
maintains
the
relationship
between
the
two
next.
J
So
this
is
the
yang
model.
The
yang
model,
perhaps
has
not
changed
too
much.
All
we
have
done
is
created
multiple
map
types,
so
the
relationship
remains
the
same
that
you
have
a
list
of
mappings.
On
the
left
hand
side
you
refer
to
either
the
LT
l2
SM
or
the
l3
SM
model
and
on
the
right
hand,
side
you
refer
to
either
a
VM
or
a
list
of
T
tunnels.
We
also
try
to
map
the
access
point,
since
in
te
we
have
a
P
and
V
and
a
P.
J
J
That
is
know
that
you
have
created
these
V
ends
for
what
purposes,
and
we
have
that
list
clearly.
So
when
we
are
monitoring
a
service,
we
have
a
easy
way
to
figure
it
out,
which
are
the
set
of
tunnels,
and
then
we
can
do
telemetry
performance
and
all
the
other
things
by
having
this
mapping.
Thank
you.
J
K
To
go
to
the
list,
my
name
is
Michael
I.
Think
I
understand
what
you're
trying
to
achieve,
but
I
wonder
if
you
have
really
looked
at
yes
via
small
area
model
in
18-hour,
C
18-49,
because
I
mean
that
model
is
relatively
complex
model
and
you
just
met
it
to
a
site
here.
Sites
can
be
multi-home
and
there
are
other
layers
we
VPN
constructs
such
as
cloud
access,
for
example,
in
models,
but
a
lot
of
things.
What
there
is
really
model
allows-
and
it's
impossible
for
me
to
see
how
the
mapping
would
work
here.
K
J
B
That'd
be
great
and
also
feel
free
to
discuss
on
the
list.
Likewise,
I
was
trying
to
understand
how,
if
we
just
want
to
add
te
to
the
l3
and
l12
an
l-3
service
model,
why
it
has
to
be
specific
to
how
the
l3
is
supported
underneath
does
it
really
need
to
know
beyond
making
making
a
PD
service
request?
You
really
have
to
have
any
knowledge
of
how
it's
being
supported
internally
like
why
is
it
tied
to
a
CTN
specifically
if
we
wanted
to
have
a
fully
distributed
control
plane?
B
F
J
I
think
that's
a
part
of
the
model,
because
I
think
the
next
slide,
which
is
about
the
telemetry,
can
give
that's
the
feedback.
So
once
we
know
this
is
the
l3
sm
model
it
uses
this
particular
VN.
Now
you
can
do
telemetry
on
this
particular
VN
to
get
the
feedback
and
this
the
service
provider
knows
that
everything
is
going
fine
about
the
within
the
network.
Why
are
the
VN?
So
that
was
one
of
our
main
reasons
to
do
that,
but
I
agree
that
we
will
add
these
texts.
These
are
very
good
suggestions.
O
O
Okay
yeah:
this
is
young
again
I.
Think
I
have
a
presentation
this
morning.
This
is
about
telemetry
of
a
performance
monitoring,
so
we
are
kind
of
capturing
only
key
performance
index
telemetry,
basically,
which
is
non
technology
dependent
like
latency
and
utilization
percentage
and
and
so
on,
forty
Eternals
or
end
or
a
to
10v
ends.
So
this
is
a
strict
implementation
from
requirement.
Seven
in
a
GT
and
requirement
document,
which
is
based
on
the
use
case,
provided
here
I.
O
The
telemetry
that's
a
static
one
that
they
get
bombarded,
but
they
want
to
be
able
to
tell
the
network's
in
case
something
happened.
Please
do
so
and
also
scale.
Scalability
of
performance
data
is
one
of
the
requirements.
Customer
doesn't
want
to
get
bombarded
with
millions
of
millions
of
data.
In
many
cases
they
will
have
very
aggregated
and
abstracted
telemetry.
So
so
this
draft,
our
support
for
telemetry
on
subscription
mechanism
are
driven
by
the
customer,
and
then
it
has
a
scaling
intent
in
and
out
intent
can
be
also
subscribe
to.
O
So,
as
you
see
here,
we
have
a
CNC
on
MDS
NPN,
see
our
CNC
basically
subscribe.
I
want
to
have
say,
delay
and
the
Ventus
utilization
of
my
tunnel,
and
it
can
actually,
it
can
also
add
other
data,
and
we
also
love
groove
operation,
for
instance,
for
the
link
utilization
in
a
maximum
of
each
link
would
be
the
right
representation
for
any
internal.
So
you
specify
max
operation
for
band
this
utilization,
but
for
delay,
maybe
end
operation,
because
you
have
multiple
links
involved
for
any
internal,
so
you
have
to
put
end
operation
for
that
telemetry.
O
So
you
basically
allow
customer
basically
subscribe
to
this
internal
to
be
monitored
on
those
statistics
and
then
mdac
basically
translate
that
into
domains
in
equivalence.
So
the
remote
detail,
because
now
each
PNC
has
to
operate
on
LS
key
level.
So
fiancée
has
to
monitor
on
the
link
level
for
that
LS
v
and
then
basically
PNC
report.
It's
a
poor,
LSP
telemetry
to
the
MDS,
see
for
MDS.
O
He
has
all
sentient
to
know,
so
it
has
to
create
end
to
end
concatenation
of
the
tunnel
for
delay
and
appendage
utilization
and
so
on,
and
the
report
back
to
C&C
on
the
level
that
CNC
can
understand
on
the
tn2
internal
level
or
unfortunate
level.
So
this
is
the
basic
idea
and
then
we
have
a
two
modules
here.
One
module
is
a
basically
T
KPI
telemetry
that
augments
T
to
know,
and
then
the
other
one
is
a
CT
and
T
telemetry
organize
a
CT
and
diem.
O
O
Yeah
so
basically
last
comment
was
packet
loss,
so
technology
specific,
so
we
took
it
out
so
now.
This
is
completely
technology
organization
model
from
customer
standpoint,
and
then
this
is
a
NMDA
compliance
for
or
a
CTN
part,
but
the
t,
RK,
p,
t--
Catalina's
rated
still
depends
on
theater
no
model.
So
we
need
to
still
work
on
the
changes
in
the
eternal
model
to
be
completely
NMDA
are
compliant.
O
B
O
B
N
Good
good
morning,
I
have
two
presentations
and
I
actually
would
like
to
borrow
some
time
from
this
presentation
to
my
second
presentation.
So
I
will
real
quick
with
this
one.
So
the
purpose
of
this
document,
basically,
as
we
just
discussed
and
concluded
that
tea
topology
model
and
Caetano
model
they
rapidly
approach
or
already
at
the
stage
of
the
last
call-
and
this
is
a
very
good
news-
what
is
somewhat
worrisome
is
that
we
hear
from
implementers
that
the
models
are
too
complex
and
convoluted,
and
it's
different
difficult
to
implement
on
both
client
and
server
side.
N
Okay,
so
we
wanted
to
to
provide
the
office
view
of
the
definitions
of
the
concerts,
and
you
know
the
the
parts
that
comprise
the
morals
the
relationships
and
our
view
how
the
smallest
could
be
applied
to
solve
various
use
cases.
Okay,
so
it
has
three
three
party
topology
model,
NT
tunnel,
modeling
and
use
cases,
and
basically,
let's
start
with
the
topology
model,
and
so
basically
you
see
that
this
is
a
general
view
of
T
topology
and
tree
topology
could
be
defined
as
a
graphical
traffic
engineering,
a
representation
of
the
resources
of
a
particular
network
domain.
N
N
So
basically,
I
just
encourage
to
go
through
this
presentation
and
to
look
into
both
this
presentation
and
the
manual
that
we
produce,
and
at
this
point
we
want
to
solicit
feedback
right
and
we
are
not
in
any
hurry.
I
think
that's
a
right
time
to
start
the
document,
because
we
want
to
follow
up
of
their
progress
of
the
documents.
B
B
It's
just
how
full
text,
how
many
think
that
this
type
of
document
is
useful,
reasonable,
but
a
good
number.
How
many
have
read
the
document
about
the
same?
How
many
think
that
we
should
bring
this
into
the
working
group
about
the
same
I'm?
Actually
a
little
less
so
I'd
like
to
bring
this
to
the
list
and
and
get
confirmation
from
the
list
that
we
should
bring
it
into
the
working
group.
Thank
you.
B
That
Igor
stop
clicking
okay.
N
N
We
heard
that
the
reason
why
we
need
a
special
working
group
for
network
slicing
is
because,
for
example,
there
is
no
relationship
between
underlay
and
always
apologies
suffered,
which
is
totally
untrue,
but
but
there
are
also
one
I
think
that
the
inventions
that
are
the
kiyose
models
today
they
do
not
include
any
knowledge
of
network
functions
of
the
function,
and
with
this
we
actually
agree.
We
started
to
think
about
this
work.
N
Some
six
months
ago,
we
started
with
Sofia
and
then
quite
a
few
people
doing,
including
Daniela
and
Joel,
how
firm
Martin,
geezers
and
James
dollar
and
other
guys
who
actually
were
very
excited
about
this
work,
and
we
think
that
this
is
something
that
we
can
do
it.
It
fits
very
well
into
a
city
and
architecture
and
I
think
it
would
be
perfect
for
Network
slicer,
okay.
N
So
so
again,
this
is
a
network
topology
and
the
abstraction
of
this
network
topology
could
be
presented
to
a
client,
so
a
client
and
now
have
a
say
how
the
services
like
a
connectivity
sources,
could
be
set
up
or
not
on
a
network
and
in
terms
of
bandwidth
utilization
and
fade
sherry
and
protection.
Stuff
like
that
right.
N
But
but
the
problem
is
that
what
if
the
network
also
offers
not
just
connectivity
stores
but
a
various
functions,
and
as
of
today,
the
client
has
no
clue
what
sort
of
sponsors
are
available
to
to
the
client,
how
they
are
where
they
sit
in
the
network,
how
they
could
be
connected,
what
kind
of
limitations
that
could
be
used
and
so
forth.
So
the
services
we
are
a
net
of
the
poacher
would
look
like
that.
Basically,
we
have
our
nodes.
N
We
have
topology,
it
could
be
T
topology
with
your
ability
to
Paulo
G,
and
then
we
have
like
a
set
of
various
Network
function,
hosted
by
by
some
or
all
of
the
nodes,
and
we
assume
that
there
will
be
a
certain
information
as
to
how
the
service
functions
could
be
changed
together
inside
one
node,
how
they
could
be
connected
to
the
nodes
linked
and
tunnel
termination
points
so
that,
for
example,
various
service
plan
changes
could
be
constructed
across
the
network.
So
our
explicit
no
goal
is
to
actually
define
service
functions.
N
We
only
need
source
function,
IDs.
We
assume
that
sort
of
function,
instances,
attacks
and
instances
are
defined,
someplace
else,
for
example,
by
8c
or
other
S
duos,
and
the
interested
client
would
just
will
be
able
to
look
up
this
sort
of
functions
and
to
an
extent
that
it
can
identify
function
that
identical
or
similar
in
function
that
they
can
go
basically
substitute
one
with
the
other
okay.
So.
Q
N
Right
right,
so
just
just
a
simple
example:
right
say
when
we
want
to
have
a
layer,
3
VPN,
which
has
also
say,
delay,
constraints
the
way
we
do
it.
Usually
we
set
up
a
tea
tunnel
between
piece
which
is
properly
constrained,
and
then
we
connect
brf's
over
this
tunnel
BRF.
So
the
LSP
is
connecting
this
VRS
all
the
stars.
So
basically
this
how
you
can
achieve
the
proper
connectivity
as
well
as
proper
RT
constraints.
N
Okay,
so
you
can
see
this
as
a
simple
service
function:
okay
with
two
service
functions
and
and
which
is
a
nested
through
there
through
the
overlay
properly
constrained.
So
if
you
think
about
a
more
complex
case,
when
you
have
more
than
two
source
functions
and
when
you
have,
for
example,
a
multi
domain
environment,
when
you
want
to
have
like
a
service
function
which
is
also
constrained-
and
it
could
be
orchestrated
this
way,
then
then
you
can
see
that
why,
for
example,
those
kind
of
our
colleges
would
be
useful,
okay
and
then
we
have
like
awareness.
N
Yeah,
so
just
one
thing:
it's
it's
not
it's
not
just
a
layer,
three,
so
responses
right.
So,
for
example,
one
one
use
case
we
considered,
which
is
very
important,
is
basically
having
regenerators
on
the
optical
network
and
because
originator
pools
are
said
only
in
the
strategic
places
and
pools
of
the
network.
There
could
we
consider
that
sort
of
sponsor?
N
B
B
F
F
F
The
first
scenario
is:
is
the
queue
is
AK
us
assurance
for
hybrid
cloud-based
application
and
a
lot
of
enterprise
are
using
public
cloud
to
deploy
their
service,
but
they
also
have
their
own
private
cloud,
so
service,
primary
service
providers,
network
conductor,
their
a
private
cloud
and
a
public
cloud
and
in
service
private
providers
network
we
need.
We
want
to
use
this
EDR
to
make
the
u.s.
insurance
for
their
traffic's
and
the
second
one
is
him.
In
some
in
some
network
program
holding
metro
network,
there
are
title
a
phenomenal.
F
For
example,
the
residential
customer
is
connected
to
bureaus
and
enterprise
customer
is
connected
to
s
are
at
daytime,
as
our
uplink
is
vv,
but
at
nighttime
bureaus
uplink,
it
BD.
So
if
we
can
use
the
we
can
build
some
local
link
between
Paris
and
SR,
and
we
want
to
use
the
CTR
to
steer
the
traffic
at
a
time
from
SR
to
fear
us
and
at
nighttime
we
can
steal
traffic
from
bureaus
to
s.
Also,
we
can
use
you
there
up
links
and
more
efficiently,
and
this
is
seconded
scenarios
and
for
the
services
in
area.
F
It's
the
similar.
It's
similar
to
the
previous
one,
and
and
in
this
picture
we
can
see
I,
DC's,
uplink
and
metro
networks
uplink.
They
are
all
a
symmetry
if
we
can
use.
If
we
can
use
this
idea
to
steal
traffic
between
idea
and
man,
we
can.
We
can
dear-dear
with
symmetry
dean,
kungfu
IDC
and
the
metro
network
to
some
level,
and
the
nasta
scenario
is
the
was
mentioned
in
in
the
master
in
the
in
the
nostril
meeting
in
chicago,
and
it's
a
very,
very
common
problem
in
service
providers
network.
F
F
congestion
happens
in
some
in
some
links,
but
a
lot
of
links
are
not
so
busy,
so
we
want
to
use
this
idea
to
to
steer
traffic
from
the
congested
links
to
congestion
links
to
increase
the
the
whole
link
utilization
in
service
providers
network
in
the
sole
way.
We
do
some
simulation
in
based
on
our
simulation
topology.
This
topology
include
100,
Connaught
and
400
edge,
Noga
and
all
and
all
corners
are
from
edge
connected
and
each
edge.
F
Node
is
connected
to
2
to
30,
core
noda
and
and
the
bandwidth
of
owning
is
100
gigabit
per
second
and
the
metric
between
corner
of
the
ear
from
60
to
100
randomly
and
the
metric
of
link
between
each
node
and
the
corners
is
set
to
1000
to
1060
randomly,
and
we
also
said,
link
aggregation
threshold
for
the
link
between
Connaught.
It's
80%
for
the
link
between
edge
node
and
the
Connaught
is
90%,
and
here
here
is
the
background
traffic.
F
We
we
build
a
traffic
metrics
all
for
500
by
500
and
each
each
traffic
between
two
node.
The
traffic
is
said
to
from
10
megabit
per
second
2
to
7
GB
per
second
randomly
and
after
we
put
the
background
traffic
to
the
simulation
topology
we
based
on
short
shot
is
the
past
protocol,
where
we
found
about
20%
links
become
congested
and
the
average
congestion
agreed
about
more
than
10%,
and
here
and
the
following
is
the
true
simulation
for
the
scenario.
F
1
and
the
scenario
for
here
is
the
solution
for
scenario,
one
for
the
qss
variants
and
we,
we
add,
1000
more
flow
into
the
simulation
topology.
With
the
simulation
background
traffic,
we
found
most
of
the
flow
we're
past
the
contrast
we're
past
the
congested
link,
but
after
we
we
add
our
table
or
my
optimization
mechanism.
We
found
just
a
few
flow
well
well
beach,
the
congestion
situation-
and
here
is
the
smell
relation
for
scenario,
for
it
is
a
simulation
for
the
temporal
congestion,
email,
elimination
and
the
left
a
picture.
F
F
So
based
on
the
based
on
the
scenarios,
description
and
the
simulation,
we
think
it
is
feasible.
It
is
available
to
deploy
a
PCE
in
a
native
network
to
optimize
our
network
and
the
traffic,
and
we
sink
for
the
scenarios.
The
solution
should
be
easy
to
deploy
with
within
one
domain
or
more
domains,
and
a
solution
should
decrease
the
complexity
or
do
not
add
more
complexity
to
the
current
or
distributed
protocol,
and
the
solution
should
should
decrease
the
burden
on
network
devices,
and
we
have.
F
This
structure
has
been
presented
for
several
times
and
also
in
the
in
Chicago's
meeting,
and
the
later
I
will
present
PDP
community
PCE
for
for
our
supplement,
so
for
the
third
further
action,
or
we
want
always
hope
to
move
this
work
forward
and
we
find
some
standard
a
way
to
to
do
PC
in
native
IV
network
and
the
way
reach
faster
request
for
the
PC
in
native
ID
networks
and
our
working
group
draft,
and
also
we
welcome
more
comments,
suggestions
and
most
scenarios.
Thank
you.
B
So
we
pretty
much
exhaust
the
time
for
the
for
the
slot.
What
we
do
have
a
question
for
is
to
see
if
this
is
an
area
the
working
group
wants
to
work
on
so
before
we
lose
their
like
the
routing
working
group
chair
who's,
walking
on
through
I.
Guess
we,
the
question
the
question
is:
is
TE
for
native
IP
networks,
something
we
want
to
be
spending
time
on
as
a
working
group,
our
Charter
is
te.
We've
certainly
have
in
scope.
Things
like
we've
worked
on
a
long
time.
B
We
want
to
be
talking
about
te
for
IP
in
this
group
or
not,
and
it
may
be
that
we're
so
late
in
the
session
that
we
don't
have
the
attention
of
folks
anymore,
like
our
ad
I,
don't
know
she
wants
to
chime
in.
But
this
is
a
good
question
for
the
group.
Does
anyone
want
a
voice
at
opinion
on
whether
we
should
or
should
not
be
doing
te
for
IP
in
this
group?.
E
E
B
B
K
Name
is
Michael
and
I
always
have
some
doubts
that
in
the
way
how
its
presented
here.
This
is
a
good
starting
point,
also
keep
in
mind
for
some
of
the
solutions
that
you're
presenting
against
existing
work.
How
you
can
do
this
in
IP,
and
it's
not
exactly
clear
to
me
what
added
value
the
solutions
that
you
presenter
are
compiled
compared
to
the
techniques
that
are
out
there
and
IP
already.
So
that's
there
might
be
sweet
spots
here,
but
I
think
you've
not
well
presented
it
so
far.
Okay,.
S
This
is
ginger
from
China
Telecom
in
our
network
we
have
a
very
large
network
and
though
we
have
very
different
kinds
of
devices
talking
to
you
or
not,
so
we
really
think
this
work
is
a
very
valuable
and
interesting
topic
and
we
will
hope
a
solution
can
solve
the
problem
in
our
network.
So
we
think
this
is
a
very
important
topic.
Thank.
B
You
for
that
input,
I
think
for
the
group
coming
back
and
talking
a
little
bit
about
the
problem
would
be
helpful.
Obviously
you
don't
want
to
disclose
too
much
about
your
the
internal
of
your
network.
That's
proprietary!
We
respect
that.
But
talking
about
the
problem
and
helping
educate
the
group
on
what
problem
is
you're
trying
to
solve
would
be
useful
before
jumping
into
the
solutions.
Yeah.
I
Speaking
us
ad,
you
have
avoided
to
to
say
anything
on
this
because
I
look
at
it
as
very
early
work
and
it's
very
difficult
to
judge.
You
know
if,
if
this
fits
in
or
not
so,
I
would
say
the
same.
You
need
to
be
more
explicit
on
what
the
application
is.
The
use
cases
before
jump
into
the
solutions,
and
then
we
can
see
if
it
fits
in
or
not
I.
F
Just
don't
want
to
add
some
information
and
surely
I'm
from
channel
bow
and
just
now
shown
film
is
wrong.
China
Telecom
and
we
usually
have
to
network
one
is
a
pure
IP
network
for
the
Internet
traffic
and
another
one
in
the
MPLS
IP
network
for
some
enterprise
service
and
some
internal
service.
So
if
we
only
have
solution
for
NP
RS
trapping
engineering.
G
B
And
they
talked
about
on
the
list
a
little
bit
and
say:
here's
really
the
problem
we're
trying
to
solve.
Maybe
that'll
help
bring
some
people
along,
but
right
now
by
jumping
to
the
solutions.
I
think
people
are
not
necessarily
agreeing
with
the
solutions
which
means
they're
not
going
to
want
to
work
on
the
problem
at
all.
It's.
B
I
think
we're
actually
out
of
time,
so
we
have
to
do
that
on
the
list.
So
thank
thank
you
very
much
for
stepping
in
for
the
presentation
appreciate
it
we're
five
minutes
over.
Thank
you
all
for
the
first
to
eat
out.
We
will
see
you
on
post
right,
Thursday,
1:30,
Congress,
Hall,
one
so
a
different
room.
Thank
you
very
much
for
participating.