►
From YouTube: IETF106-OPSAWG-20191120-1000
Description
OPSAWG meeting session at IETF106
2019/11/20 1000
https://datatracker.ietf.org/meeting/106/proceedings/
B
The
note
well,
please
make
sure
you
understand
those
important
illegal
issues.
Basically,
all
your
contributions
need
to
follow.
The
ITF
rules
and
the
first
three
are
welcome
to
the
obsolete.
Wg
is
chaired
by
Kenya
and
the
Joe
and
the
blue
shirts
is
circulating.
Please
fill
in
your
name
so
that
we
can
get
room
with
right-size
next
time
and
before
we
can
really
start,
we
need
Java
scriber
yeah.
Is
there
a
new
volunteer.
C
D
C
If
the
past
two
meetings
I've
done
transcription
from
the
YouTube,
it's
worked,
but
I
do
recommend
anyone
who
can
join
the
etherpad
the
links
there.
It
really
helps
if
you
have
something
that
you
want
to
make
sure
is
captured
in
the
minutes
or
that
you
can
clarify
some
things.
Please
also
when
you're
presenting
or
when
you
come
to
the
mic
for
comments,
make
sure
to
say
your
name.
So
we
can
record
that,
but
we
would
appreciate
if
anyone
can
contribute
to
the
etherpad
notes
and
anyone
who
can
sign
into
ever
I'm
on
as
well.
C
E
Okay,
perfect
so
I'm
getting
used
to
the
remote
presentation,
but
I
prefer
to
be
in
person.
So,
okay.
So
let's
get
started.
So.
Thank
you
very
much.
So
we
are
gonna
present
today
the
layer,
3
VPN
network
model.
So
now
it's
a
working
load
document.
So
please
go
to
the
next
slide.
So
just
will
quickly
introduce
the
the
motivation
just
for
for
background
purposes
and
then
we'll
go
into
the
meat
and
what
are
the
updates
in
this
new
version?
A
explain.
Clearly,
what
is
the
the
hierarchy?
A?
E
What
is
the
relation
between
l3,
enema
and
threesome,
and
many
definitions
were
the
tilde
from
the
working
group
is,
is
welcomed
on
the
next
step.
So
please
go
on
next
slide,
so,
first
of
all
the
motivational
of
the
war.
So
what
were
the
requirements?
So
basically
the
requirements
was
to
be
able
to
monitor
three
VPNs
and
in
order
to
help
the
automation,
we
wanted
a
jam
module
to
be
able
to
be
used
from
a
network
controller,
so
it
could
interact
with
piece
doing
the
solution.
E
Registration
either
be
a
human
network
operator
that
interest
with
the
client
or
it
is
an
automatic
piece
of
soul
where
the
interest
with
a
client,
so
the
existing
Wardell
threesome
works
perfectly
fine
to
interact
with
the
customers.
Let's
say
it
takes
all
the
requirements
from
the
customer,
but
does
not
speak
the
error
they
or
does
not
have
notions
of
the
internals
of
the
operation
operator
network.
E
So
here
is
the
young
module
to
monster
l3
VPN
services
in
a
service
provider
network
and
includes
information,
also
of
some
of
the
logical
resources
for
sample
options
of
some
polite,
artisan
energies,
and
here
we
tried
to
remove
all
customer
related
information
that
that
piece
will
remain
at
the
OSS
or
BSS
a
layer
and
we
care
about
the
really
the
network
layer.
So
please
go
on
the
next
slide,
so
the
the
document
is
now
working
group
document,
so
first
new
things
in
this
in
this
world.
E
We
welcome
new
new
contributors,
so
Mara
and
Stefan,
and
join
the
work
so
also
they
both
bring
a
lot
of
perspectives
from
l3
VPN
management
and
from
the
war
from
atrium.
So
they
provided
very,
very
good
inputs
and
help
to
clarify
the
relation
between
the
the
models
and
helped
in
the
refining
and
they
got
the
containers.
Also.
The
the
first
thing
was
to
polish
all
the
deterioration,
so
there
was
a
good
review
by
Tom
pet,
which
we
try
to
fix
all
the
editorial
issues
also
suggested
by
the
working
group
chairs.
E
We
added
the
implementation
status,
so
here
you
have
the
best
imitation
status
section
with
three
known
implementations:
I.
There
might
be
more
out
there,
but
at
least
three
that
I
am
aware
that
are
documented
in
this
version.
Of
course,
the
young
model
is
updated
and
the
main
changes
that
we
moved
from
the
more
science
centric
view
that
was
inherited
from
chrome
l3m
to
a
pure
Network
centric
view.
E
Okay.
So
it
is
the
solution
for
the
network,
so
also
we
did
in
as
we
started
from
maybe
from
the
recording
from
the
Adele
threesome.
We
now
did
him
the
prune
and
take
out
all
the
customer
related
parameters
that
are
not
necessary
and
all
the
unused
containers
were
stripped
out,
and
so
here
a
lot
of
thanks
to
Stefan
little
skill
that
he
helped
us
a
lot
to
to
work
through
this
to
the
young
train
model.
Also,
we
added
some
sample
section
to
help
to
understand
how
the
model
can
be
used.
E
So
here
in
the
just
in
this
regression,
we
are
started
with
a
very
simple,
widely
use
example
in
service
provider,
so
it
is
the
shared
l3
VPN
for
the
4G
service
provisioning
for
the
baho,
for
the
mobile
backhaul
is
a
very,
very
simple
use
case.
So
in
the
future
versions
will
include
more
complete
examples.
Also,
we
refined
clarify
the
terminology.
So
in
order
to
avoid
misunderstandings
and
to
help
the
readers
of
the
document
understand
quarterly
what
what
we
are
referring
to
in
the
document
we
revisited
all
the
terminology
section.
E
Also
there
were
some
had
minor
additions
in
the
Rohtak
on
the
routing
protocols
part.
So
in
there
was
the
process.
Id
in
OSPF
was
missing,
so
we
we
added
it.
Also,
the
big
change
in
the
document
is
the
description
of
the
jam
model
itself.
So
here
you
have
extended
all
the
description,
so
people
can
understand
the
the
young
model
and
the
implementers
and
users
of
the
model
a
can
understand
it
and
can
and
we
can
avoid
a
an
amputee's.
E
Also,
we
added
a
section
with
the
relation
with
all
young
models
so
which
are
the
the
other
young
model
that
relation
to
this
one,
and
we
have
added
the
security
section
with
the
potential
threats,
for
example,
from
malicious
clients
or
from
unauthorized
clients
and
the
reference
app
that
didn't
we
organized
okay.
So
please
go
on
the
next
next
slide,
so
I
said
the
first
and
the
third
big
changes
they
just
get
away
from
the
the
sides.
So
here
with
on
deck
sides
are
the
custom
side.
E
So
here
we
are
what
we
want
to
deploy
the
services
from
the
from
the
P,
so
that
side,
information
we
no
longer
need
it.
That
is
already
pin,
process
and
decided
to
which
points
to
enter
the
network.
So
here
the
main
container
are
this:
the
VPN
service
and
the
bpn
profiles.
So
the
the
VPN
service
contains
a
VPS
nodes.
We
have
this
option.
E
Are
the
abstractions
the
point
that
are
like
a
common
set
of
policies
that
applied
to
a
network
node
and
within
the
VPN
node
you
have
the
VPN
network
systems
that
are
the
points
where
the
traffic
really
comes
into
the
into
the
VPN,
and
there
we
had
the
two
parameters:
IP
information
or
forcible
days
of
the
wire
termination
ratio,
basically
sees
the
new
hierarchy.
So
please
next
slide.
E
So
then
relation
with
the
the
l3
name.
Scope
is
from
the
from
the
piece
from
p2p
and
we'll
it
l3
and
ma
scope
will
be
from
the
sides
and
the
bitter.
So
here
you
can
see
clearly
what
will
be
the
scope
and
view
of
both
of
both
models.
So
please
next
slide
so
here.
This
is
just
an
example
for
for
gbpn
provisioning.
So
here
what
we
want,
three
VPN
service
that
that
connects
the
the
node
B
with
the
platforms.
E
E
By
the
three
P,
so
here,
basically
the
service
in
l3
name
will
be
modeled
as
a
to
VPN
nodes
with
one
VPN
network
access
in
this
one,
one
between
networks
is
facing.
They
not
be,
and
one
VPN
no
taxes
facing
the
platform,
so
he
here
in
the
index
sample
you
would,
and
you
will
see
how
a
BBN
note
would
be
represented.
Okay,
so
don't
bother
the
details,
you
have
them
in
them
in
the
draft,
so
we
can
move
forward
and
next
slide,
please.
E
So
here
continuing
with
the
example
here.
This
is
how
we
would
seal
also
the
the
VPN
network
access
information.
So
this
is
how
we
would
model
the
other
relevant
part
of
the
gang,
so
the
VPN
node
and
the
VPN
and
network
access.
So
here
in
this
example,
as
in
a
simple
example,
the
VPN
node
a
maps
clearly
into
a
physical
P,
but
as
mentioned
the
VPN
node
is
an
abstraction.
So
here,
if
you
use,
if
you
are
using
sample
abstract
topology,
you
could
map
a
that
abstract
token.
E
That
astronaut
couldn't
be
further
expanded
into
multiple
nodes.
So
then
the
controller
will
decide
where
to
exactly
to
place.
The
DBS,
so
it
is
not
always
I-
want
to
one
mapping
between
VPN
no
than
beer,
if
okay,
so,
but
in
basic
and
sample
in
simple
example
like
this,
it
will
be
on
Tanaka.
So
please
go
go
on
so
here
when
the
next
slide.
Please,
okay,
so
here
a
the
open
issue.
That
is
what
we
want
to
get.
E
The
defeat
from
the
working
group
is
the
one
open
issue
is
the
Delta
assignment
of
the
resources
here
at
the
energy
out
assignment.
So
here
we
have
several
several
scenarios,
so
one
of
them
is
okay.
You
leave
the
network
controller
two
out,
assign
this
logical
resources.
Okay,
you
please
fill
twos
for
me.
They
are
tea.
Nerdy
other
is,
for
example,
for
multi
domain
scenarios
or
forever
or
for
scenarios
where
you
have
these
resources
outside.
E
You
want
to
explicitly
assign
artisanal
DS
and
also
there
are
other
scenarios
where
the
network
were
within
one
know
where
the
energy
to
be
assigned.
There
are
some
some
cases,
some
simple
VPNs-
that
we
don't
want
that
assignment
so
here
in
the
what
happens
now
in
the
current
version
of
the
trap,
the
they
are
Tianna
there
are
optional.
So
the
assumption
is
that
if
you
don't
fill
them,
they
will
be
assigned
by
the
controller,
and
you
can't
return
later.
E
So
the
question
to
the
working
group
is
whether
okay
do
we
need
an
out
of
sign
in
the
flock
to
indicate
is
yeah
that
this
resources,
these
values,
must
be
filled
or
it
is
redundant
in
junk
it
is
on,
it
is
already
implied.
So
can
we
assume
that
is
an
optional
parameter
is
not
filled?
It
must
be
calculated
by
the
server
okay.
So
this
is
an
open
question,
so
please
go
to
the
next
slide
to
work
to
continue
with
the
definitions.
E
So
here
there
are
some
some
open
issues
that
we
need
to
clarify
with
the
rest
of
office
on
working
group
is
the
the
it
extranet
VPNs
for
the
3sm
are
not
needed
in
the
3nm.
They
can
just
be
mapped
into
an
import
policies,
review
the
VPN
profile,
the
containers
of
far
we
have
found
the
QoS
profile
useful,
the
rest
of
them
not,
but
as
they
are
available
in
a
threesome,
we'll
need
to
check
them,
though
we
need
to
review
the
multicast
now
the
requirements
and
already
mapped
a
couple
of
open
issues.
E
The
relation
with
other
models,
for
example,
with
the
network
topology.
So
currently
the
VPN
node
has
the
net
the
NAD,
the
network
lemoned
ad,
that
is
used
to
identify
the
net
were
not
in
the
in
which
the
VPN
notice
required.
So
here,
one
possibility
is
to
add
a
leaf
ref
in
a
libyan
node
to
a
node
in
an
ITF
network
module.
So
then
it
will
be
much
knighted,
but
it
will
require
the
model
to
use
to
wear
with
a
an
ITF
network
model.
So
question
the
warning
display.
E
It
is
worthwhile
in
this
cross
relations
to
other
doing
mandatory
or
if
it
will
be
a
choice
between
okay,
blue,
provide,
I
D
or
is
a
leaf
leaf
man
to
to
a
network
topology.
And
finally,
the
port
identification
in
the
VPN
network
says
that
a
here
we
might
also
need
to
add
a
reference
to
a
topology
to
the
Uni
interface.
Also
to
make
this
relation
a
unambiguous.
E
E
We
want
to
ask
you
to
review
the
work
in
the
current
version
of
the
document,
a
implementers
from
feedback
and
work
on
definitions,
and
we
understand
this
work
also
to
to
world
to
be
P
ends
and
create
a
topology
model
with
yoona
interfaces
to
attach
the
VPN
addresses,
which
is
a
word
that
you
cover
to
review.
So
thank
you
very
much
and
if
you
have
any
question.
F
F
Unity
tells
us
such
as
our
key
Rd
yeah,
so
I
think
that
the
auto-assign
should
have
ent
fought
her
measured,
but
to
be
honest
some
days,
because
the
network
operators
that
they
are
transit
Heda
from
this,
the
traditional
network
management
way
to
the
acid
in
based
away.
So
they
do
use
some
days
of
the
concern
about
this.
The
the
our
key
Rd
cannot
be
explicit
here.
F
G
Thank
You
donors,
speaking
without
an
ad
headed
as
an
operator
in
in
most
of
the
deployments
that
I
have
seen
artists
energies
are
strictly
controlled
and
that
is
coming
from
a
source
of
truth,
which
is
much
more
related
to
a
lot
of
other
parameters,
and
just
networking
making
it
has
a
default
photo
assignment,
will
directly
clash
with
a
lot
of
existing
deployments.
Yes,
that
option
is
needed,
but
that
definitely
doesn't
need
to
be
the
default.
One.
E
H
C
Thank
you
ask
her
to
the
working
group.
Please
read
and
comment
on
list
to
his
to
the
authors,
open
items
again
Oscar.
Thank
you.
I
think.
We've
said
it
before
it's
great
to
see.
Operators
come
and
present
this
work
here.
I
have
a
comment
for
you,
but
I
will
send
it
to
the
mailing
list
because
we're
running
a
few
minutes
behind.
So
thank
you.
H
Good
morning,
I
am
mining
machinery
from
hobby
I
like
to
pretend
it's
young
beta
mode
of
framework
job,
so
apologize
actually
for
one
of
the
cars
actually
I.
You
know
the
name
actually
is
correct,
but
there's
a
perforation.
It's
not
a
corrector,
so
sorry
about
that.
Actually
I
will
fix
this.
Actually
we
have
bouncer
of
the
author
and
because
the
nematode
that
the
also
number
on
the
front
page,
so
we
move
some
also
to
the
contributor,
so
the
Java.
H
Actually
we
changing
the
nickname
because
we
have
something
with
chair
anomalies
that
because
the
traffic
name
seems
a
little
bit
less
a
so
we
try
to
figure
this,
and
so
now
we
have
this
name
still
very
known.
So
what
is
this
job
about?
Actually,
when
we
prepare
this
chart,
we
we
were
asked
by
many
operator
service
provider.
So
you
you
have
so
many
young
any
model.
How
you
put
this
model
together
to
to
provide
end-to-end
a
solution.
H
How
do
we
deploy
this
kind
of
model?
How
to
integrate
this
model?
So
this
is
motivated
us
to
write
this
document.
We
really
want
to
document
the
yamoto
architecture
more
from
the
service
provider
perspective
based
on
service
provider
importer
and
try
to
give
the
guidelines
for
operator
to
see
how
to
glue
the
model
together,
how
to
integrate
a
young
data
model.
H
In
addition,
for
this,
can
a
creature
actually
is
service
oriented
oriented
architecture,
so
women
support
various
different
services
layer,
three
service
there,
maybe
tea
service,
so
different
service
has
given
a
functionality,
so
we
try
to
do
is
identify
the
common
common
functionality
and
a
common
concept.
So
one
example
actually
for
layer,
3,
service
or
tea
service,
you
may
support.
Different
functionality
may
be
preparing
all
the
tea,
but
this
kind
of
analogy
can
be
supported.
Various
different
online
technology,
for
example,
MPs
gie
and
pseudo
wire
in
central
actually
so
so
last.
H
So
this
is
the
kernel
stat
of
this
draft.
This
Java
has
just
been
adopted
before
this
meeting,
and
actually
we
make
it
a
lot
of
changes
based
on
the
last
medium
discussion
and
try
to
address
the
common.
The
reason
in
the
last
meeting
my
important
issues,
which
I
to
document
the
old
iti
model
in
the
previous
version,
seems
to
give
us
a
view
for
this
kind
of
a
ETA
Yamato
standard
input
status
that
we
single
is
not
appropriate.
So
that's
why
we
move
this.
H
Can
IDF
Yamato
servitude
appendix
and
another
one
is
in
the
previous
version.
We
mix
the
how
the
model
is
discovered
from
with
how
the
model
is
integrated.
So
we
try
to
clarify
this
and
separate
these
two
since
imaging.
Actually,
the
the
the
job
have
tried
to
generate
this
kind
of
architectural
concept
to
cover
the
common
functionality
and
a
concept
why
another
concept
actually
is
a
model
layer
in
the
rivers
in
Beijing.
We
will
discuss
in
a
next
slides,
so.
H
So
what
is
it
important
concept?
I
think
it
is
this
model
layering
and
a
model
representation,
so
you
may
obstruct
the
service
requirement
from
the
top.
You
may
abstract
the
metal
infrastructure
technology
in
on
the
line
from
the
bottom,
so
yuri,
you
will
classify
the
model
into
service
layer
and
divides
ever,
but
also
in
the
middle.
You
know
you
need
to
schedule
the
resource
to
meet
the
requirements
to
schedule
results
to
try
to
you
know,
adapt
to
the
network
changes,
so
the
Neto
level
is
very
crucial.
H
Important
and
you
know
tell
you
where
you
can
get
these
results.
How
do
you
are
located
these
kind
of
results?
One
of
the
example
is
you
may
figure
out
how
to
select
a
VPN
attachment.
Point
may
be
the
P.
You
may
need
to
decide
whether
I
reuse,
existing
vif
or
I
need
to
create
a
new
way
out
whether
I
need
to
get
a
new
port.
So
we
hit
clear
give
an
example
actually
in
a
service
lever.
Actually
from
customer
perspective
they
don't
care
what
technology
you
are
using.
H
What
kind
of
results
you
located
so
usually
they
will
request
a
VPN
service
to
describe
it
like
I
want
to
have
a
3,
VPN
side.
I
wanted
these
ribbons
are
interconnect
which
yes,
I,
want
to
require.
The
connectivity
between
the
side
with
some
bandwidth
requirements,
latency
requirements
at
the
drill
down
to
the
net
will
ever
actually
need
to
figure
out
where
you
can
get
this
result.
How
do
a
locator
is
its
kind
of
results,
so
in
a
net?
H
You
really
want
to
activate
a
some
feature
within
a
device,
so
you
can
read
on
device
level
model
to
do
that,
so
that's
the
concept
of
module
layer
and
representation,
so
this
is
architecture
overview
for
young
Taylor
motor
automation.
Actually,
there
are
several.
You
know
common
functionality
in
within
this
architecture.
These
actual
architecture
really
classified
the
the
into
the
device
level
net,
whatever
service
level,
the
commonality
between
the
service
level
and
a
net
will
ever.
H
You
will
support
a
service
life
cycle
form
from,
for
example,
service
of
creating
modification
and
a
service
optimization
when
you
gotta
do
the
net
over
set
up
or
you
really
want
to
optimize
their
service
based
on
the
Nano
at
last
that
you
really
need
to
consider
how,
to
you
know,
break
down
its
kind
of
surveys,
so
you
will
have
this
kind
of
service
lifecycle
management.
In
addition,
actually
you
need
to
cover
service
and
maintenance.
One
of
the
importance
of
is
when
are
important.
H
The
feature
in
the
service
maintenance
is
service
assurance
and
the
service
diagnostic,
and
you
need
you
need
to
figure
out
how
given
a
model
put
together
to
provide
the
several
assurance
or
service
diagnostic.
This
is
something
we
actually
have
some
economic
in
the
later
slides
and
enriching.
You
want
to
support
a
close
local
metal
management
or
service
network
management,
so
the
model
you
can
leverage
all
the
maximum.
H
You
can
leverage
a
freedom
for
motor-driven
telemetry,
you
have
ITA
to
find
young
push,
telemetry
mechanism
or
you
may
use
its
job-
is
to
GMI
whatever,
and
also
you
need.
You
have
motor
driven
policy
model,
actually
there's
some
technologies.
Specific
policy
model
like
a
ACL
routing
policy,
use
policy
model,
and
you
also
can
leverage
you
some,
because
the
ECA
model
is
kind
of
imperative
policy
model
with
this
is
a
model
or
motor
driven
policy
model
and
model.
Given
an
image
model,
you
can
build
a
close
look,
never
imagine
management.
H
Another
thing
actually
actually
is
important.
Is
model
layer
and
translation.
Actually,
you
have
a
different
layer
model.
You
need
to.
You
know
smoothly,
translate
it
between
each
other.
You
may
translate
between
given
a
layer
image
translate
in
the
same,
never
mind
examples
for
translation
between
different
layers.
You
translate
a
service
level
into
net
we'll
ever,
but
the
there
are
some
challenge,
because
during
these
translation,
you
need
to
figure
out
where
you
carry
these
resolve,
how
to
allocate
resource.
Also,
similarly,
simply
static.
Translation
is
not
enough
actually
for
device
level
translation.
H
H
H
So
you
can
pet
benefited
from
this
tenet
men.
She
opens
the
may
amend
the
model
to
try
to
keep
track
with
the
network
performance
and
so
can
provide
a
better
insurance
before
in
some
cases
and
maybe
performance
services,
it's
done
greater.
You
can
optimize
the
network.
So
second
example
is
cross-layer.
H
Example,
actually
these
actually
allow
you
to
delegate
the
climate
generate
the
policy
into
the
device
level
allow
the
device
several
control,
so
you
say
we
have
several
model
actually
to
do
this
and
as
it
can
support
of
where's
different
action.
Actually
one
of
our
action
is
actually
you
can
trigger
some
Locker
notification.
Also,
you
can
actually
to
reconfigure
summer
with
a
dog
city
within
the
divine
within
the
device.
So
another
way,
actually
maybe
you
have
bunch
of
young
beta
model,
you
need
to
put
them
together
and
a
clue
them
into
super
device
model.
H
Actually,
in
this
way,
you
actually
can
you
know
make
a
better
know
that
wheezing
each
model
has
a
unique
X
passes,
so
you
can
provide
a
consistent
reporting
representation
and
a
configuration.
So
this
is
something
very
powerful
put
in
a
virgin
so
that
Mecca
zone
/.
The
idea
actually
is
a
scream
moment.
We
can
leverage
these
to
do
that,
so
we
provide
several
cases.
The
first
case
is
VPN
service
delivery.
H
H
How
do
you
allocate
these
kind
of
results
and
also
you
can
dip
compose
arrow
Sri
and
a
model
into
BGP
model
views
model,
a
sailor
model
and
a
cat
Annette
was
set
up
in
April
the
PGP
protocol
or
SAR
feature
in
the
device
another
one
we
showed
you
actually
use
a
service
assurance
use
cases
in
the
case.
Actually
we
can
leverage
some
loss,
Bunga
performance,
environment,
animation,
model,
there's
two.
H
Typically,
some
wine
is
T's,
V
antenna
measurement,
that'd
be
developer,
Yankees,
walking,
cool
and
another
one
is
radium
opposed
amendment,
any
measurement
that
you
define
in
the
best
working
go.
We
actually
can
leverage,
it
is
lost,
bound
performance,
a
man
model
to
mayor
the
no
network
performance.
So,
usually
you
will
mayor
pruning
the
nano
performance
and
I
go
late
and
say:
penny
wait,
penny
wait
and
then
you
can
aggregate
this
into
the
tunnel
level.
H
We
can
never
know
from
the
customer
perspective,
so
the
the
the
operator
can
use
these
kind
of
VPN
lever
policy
metric
to
optimize
the
network.
So
in
this
way
we
can
provide
better
service
assurance.
Another
one.
Actually
we
want
to
emphasize
is
easy
approach
to
use
a
closed
loop
network,
optimization
so
easy,
actually,
the
canary
climbed
the
scraper.
We
can
push
it
down.
This
kind
of
clan
generate
the
scribbly
into
the
device
so
enable
the
device
can
server
control
server
management.
I
H
K
H
K
L
L
So
this
is
the
country
model
and
since
last
meeting
we
just
added
the
the
session
note
to
reflect
the
John
Harris
comments,
because
he
suggests
to
add
this
session
know
to
reflect
that
in
a
one
single
single
connection.
There
could
be
more
sessions
involved
and
this
here,
the
changer
since
last
meeting.
L
So
there
is
a
one
remaining
issue
that
is
from
urban
areas
that
the
current
system,
authentic
application,
only
allows
local
and
radius.
So
we
added
the
text
plus
authentication
math
method
to
it,
but
the
problem
is
that
current
system
defines
a
mask
constraint,
that
it
only
allows
to
verify
the
radius
configuration.
So
in
that
way,
although
we
add
we
added
the
Takas
plus
authentication
in
an
identity,
but
still
we
cannot
use
a
must
to
verify
the
other
parameters
of
Takas
plus
like
whether
we
configure
servers
yet.
So
this
is
only
problem.
L
So
here
I
had
discussion
this
happen.
He
he
thought
that
if
I
added
the
identity,
then
it
can
be
very
like
it's,
but
it's
valid,
so
it
can
be
used.
The
they
are
no
problem
is
that
this
same
system
gives
a
very
restricted
definition
so
based
on
the
young
one
dot,
one
definition,
the
augmentation
a
target
note
cannot
be
leaf
list.
So
in
that
way
we
cannot
use
mast
to
element
this
note,
so
in
that
way,
mass
cannot
be
added.
L
So
in
that
way
we
think
this
is
a
remaining
issue,
but
way
we
don't
know
how
to
solve
it.
So
the
problem
that
the
question
to
the
working
group
is
that
we
just
leave
it
as
it
and
we
we
propose
to
add
a
note
to
the
appendix
to
see
whether,
like
in
the
next
system,
release
can
like
must
could
be
removed
or
be
replaced
with
a
new
one.
So
that's
a
question
for
this.
C
Can
help?
Okay?
Okay,
thank
you
that,
okay,
something
else
you
since
you
added
the
the
normative
reference
to
tack,
acts
just
for
you
and
the
working
group,
so
the
rebbe
16
of
that
draft
was
just
posted
and
the
authors
are
now
working
to
clear
all
the
remaining
discusses.
So
I
talked
to
Ignace,
we're
hoping
that
we
get
that
through
in
the
upcoming
telecheck,
and
then
it
moves
forward.
So
just
FYI
on
that
and
I'll
take
the
action
to
see.
If
there's
any
alternate
thing
we
can
do
here
with
the
ITF
system.
Yes,.
L
M
Question
about
the
mast
statement
so
have
you
already
discussed
this
outer
sofa
ITF
system
about
when
the
next
version
will
be
released,
says
that
you
could
identify
if
you
could
add
this
master
appendix
and
after
to
collaborate?
This
idea
of
system
outers
to
include
basically
to
combine
both
documents.
Can
you
state
your
name,
Metro
City,
from
a
safer
Altis,
sorry
I.
L
D
D
So
the
message
conveyed
by
this
draft
is
a
very
simple.
We
are
all
are
seeing
the
emergence
of
a
new
type
of
data
pennington
mg
technologies.
We
call
them
on
pass
on
data
telemetry
and
the
operators
see
are
very
interesting
in
applying
this
kind
of
technology,
not
only
in
data
center
and
and
price
networks,
but
also
in
operator
networks.
D
We
want
to
leave
them
for
the
real
implement
area
implementers
and
also.
We
think
that
the
purpose
here
is
only
to
inspire
such
a
network.
So
first,
we
think
we
already
have
the
two
type
of
a
passive
and
active
type
of
OM
technologies.
But
here
we
are
clearly
seeing
there's
assertive.
We
can
call
that
hybrid
type,
three
or
unpassed
data
plane,
telemetry
techniques,
and
we
can
also
further
partition
this
into
two
different
subclasses
one.
We
can
name
it
a
password
passport
type,
which
includes
our
iom,
trees
mode.
D
I
ôm
e
3,
E
and
I
FA
happy
to
stab
and
enhanced
alternative
marking.
So
you
can
see
the
common
feature
shared
by
this
type
of
techniques
is
that
you
need
somehow
modify
as
a
user
packet
along
the
path
or
you
just
do
them
more
monitoring
or
measurement
and
the
end
of
the
path.
But
the
second
sub
class
is
called
postcard
mode.
Well,
which
means
you
are
along
the
packet
forwarding
path.
You
don't
modify
the
user
traffic
anymore.
Instead,
you
just
read
the
instruction
carried
by
the
packet.
D
D
So
how
we
will
successfully
why's
this
kind
of
technologies
so
far
we
may
need
specifies
underlying
techniques.
What's
a
packet
format,
it
looks
like
how
the
nose
will
process
it,
but
we
haven't
considered
many
other
challenges
so
far.
The
first
wines
as
the
performance
implications,
this
kind
of
processing
may
are
actually
stress,
you're
falling
playing.
You
have
to
consider
about
the
performance
and
also
that
the
data
generated
by
these
technologies
may
be
to
us
and
also
they
can
overload
the
other
export
the
network
anyways
and
also
the
data
connectors
and
also
so
far.
D
We
only
defined
a
fixed
set
of
data
as
we
can
that
can
be
exposed
by
the
data
plane.
There's
a
note
enough
of
flexibility
and
extensibility.
We
want
to
also
change
that
and
also
to
to
actually
deployed.
We
have
to
consider
various
kind
of
data
plane,
encapsulation
protocols.
There
are
some
proposals
available,
for
example,
for
IOM
how
to
incoming
capsule
encapsulate
it
in
different
type
of
transport
protocols,
but
first
it's
not
a
complete
some
some
important
the
protocols
are
left
out
and
also
how
we
can
expand
this
to
support
other
similar
type
type
of
technologies.
D
Let's
not
consider
we
think
we
should
have
a
holistic
view
to
support
them
either
and
also
there
are
different
tunnels
in
Cairo
Network
and
we
have
to
consider
in
different
type
of
tano's
how
we
can
successfully
AB
a
properly
handle
this
kind
of
package
and
the
last
challenges
are
surely
about
what
kind
of
or
primitives
and
models
API
is
to
support
this
type
of
technology,
and
this
there's
no
tower
in
this
job.
We
just
point
out
what's
missing
and
it
was
a
current
status.
D
Hopefully
this
can
inspire
a
bunch
of
new
job
to
detail
about
this,
these
kind
of
requirements
so
to
address
as
a
shriek
channel
mine's
performance
that
the
probability
and
the
flexibility
we
proposed,
several
key
components:
functional
components.
We
can
work
on
them
to
provide
our
own.
You
know
innovative
solutions,
then
we
can
address
these
different
challenges.
D
The
force
wise
how
we
can
correctly
configure
the
network
to
only
pick
the
flow
and
the
data
we
want
to
really
look
at
so
without
stressing
the
network
resource
and,
secondly,
how
we
can
take
advantage
of
the
in
network
processing
capability
to
reduce
amount
of
data
actually
exposed
to
the
data
collector.
There
are
many
ways
to
do
that.
One
of
them
we
can
deploy
some
programmable
probes
into
the
system
to
actually
defines
a
good
smart
filter
or
some
data
reduction
techniques.
D
For
example,
we
can
deploy
the
events
into
the
system,
then
only
the
triggered
when
the
events
triggered.
We
can
start
the
data
exporting
so
the
this
a
very
effective
to
save
the
bandwidth
and
also
the
processing
power
and
the
server
side,
and
we
we
think
the
encapsulation
that
animals
are
very
important
to
support.
We
need
to
provide
standard
ways
to
support
those,
and
finally,
we
offer
resync
in
one
application.
Maybe
just
using
one
underlying
technique
is
not
enough.
D
D
So
here
we
show
that
overall
high
level
of
this
this
architectural
framework.
Actually
it's
a
should
look
very
familiar
to
you.
It's
just
like
normal
Sdn
architecture.
We,
basically
the
controller,
will
configure
the
entire
all
the
nodes
in
the
U
1
F,
which
domain
and
then
after
that,
we'll
get
I'm.
Sure
data
from
different
knows
through
the
character
then
collector
after
analyzing
this
data,
it
will
feed
the
information
to
the
controller.
The
controller
can
take
into
consider
these
regions.
This
feedback
then
adjust
its
configuration,
so
you
can
see.
D
D
You
can
look
at
or
trapped
and
in
the
draft
that
we
describe
several
very
interesting,
interesting
applications
enabled
by
this
a
closed
loop
architecture.
So
let's
have
some
discussion
so
in
the
email
list.
I
have
already
request
the
adoption
of
this
disrupting
in
the
working
group
and,
as
its
triggered,
a
lot
of
discussions,
the
majority
of
them
many
from
operators.
They
are
very
interested
in
this
kind
of
work
and
support
it,
and
also
there
are
some
feedbacks
about
ok.
D
We
are
not
very
clear
about
defining
some
terms
in
this
draft
and
we
deepen
a
very,
not
very
clearly
defined
scope
of
the
disrupt.
So
in
the
newer
revisions
we
fixed
that
we
gave
a
formal
definition.
All
all
terms
used
you
stay
in
this
draft
and
also
we
provide
another
independent
section
to
talk
about
standard
gap,
so
basically
released
what
I
will
available
right
now
and
what
has
they're
missing.
Hopefully,
that
can
trigger
more
works
in
the
working
group,
and
so
here
we
are
soliciting
and
maybe
suggestions
about
new
future
work.
D
N
G
D
N
D
D
N
Know
I'm
not
talking
about
that
I'm
arrogant
about
the
use
of
the
term
closed
loop.
Only
it's
about
trying
to
find
a
way
of
describing
that
you're
not
talking
to
trying
to
control
the
network
but
to
control.
How
to
deploy
the
probes
and
to
control
the
telemetry
and
of
the
network.
Closed-Loop
is
normally
more
used
to
the
control
of
the
network.
D
It's
just
in
this
domain.
You
have
a
clearly
defined
domain
to
apply
this.
This
look
you
only
all
the
controls
only
applied
to
the
to
the
node
in
this
domain.
Why
enable
the,
by
through
supports
that
this
athlete
functions?
If
it's
not
enable,
then
you
can
no
it's
out
of
the
the
control
at
the
main.
D
If
you
have
a
good
other
alternative
suggestions,
we
can
use
that,
but
right
now,
I
think
that's
the
most
powerful
behavior
actually
happening
in
the
this
application,
indeed,
is
you
know,
is
a
dynamic,
take
the
feedback
from
network
and
apply
the
new
policies
to
change
a
previous
configuration
that
I
don't
know.
If
you
know.
D
O
My
phone
came
from
China
Mobile
I,
don't
you
know
right
the
mobile
network,
our
talk
about
a
divided
Baker,
for
example.
There
are
more
than
13,000
notes
in
big
yield.
It
is
difficult
to
localize
with
the
Newseum.
Oh
yeah,
my
cert,
but
I
did
two
important
for
us
to
localize,
to
the
specific,
for
the
note
weakest
in
deserve
the
forwarding
performance
and
how
to
reduce
that
it,
the
power
to
the
to
the
controller
we
compared
and
chose
to
learn
suitable
bit
of
line.
We
also
have
different
wine
and
fader
dat
applying
either
Network.
O
We,
the
man
winter's
about
our
house,
it's
an
hour
to
Tokyo
a
great
to
refer
to
only
to
the
pond.
I
didn't
know
a
nice.
We
hope
their
Islamic
to
retain
what
countries
anteclo
the
group
now
working
in
stroke,
work
working
in
solos
from
our
past
follow
telemetry
I.
Think
there's
a
prominent
work
also.
They
trust
in
the
word
useful
for
us
tell
them
about
our
new
fiend
and
scope
of
this
trust
in
the
wider
career.
Now
we
hope
they'll
call
the
P
working
in
group
document
so
write
the
bad
faker
in
a
solution.
D
I
I
You
have
a
set
of
requirements
outlined
that
might
be
another
document,
so
second
document
and
then
you're
trying
to
go
and
start
off
doing
something
that
looks
like
a
specification
and
I
think
some
of
the
earlier
comments
that
you've
seen
around
nomenclature
not
being
clear,
I
think
this
trickles
all
through
the
document.
You
are
defining
things
or
you're,
mentioning
things
that
are
not
really
specified
at
specification
level.
Ie
I
can
go
and
implement
something
based
on
that.
You
say
in
a
knife:
it
note
it's
the
start
of
a
knife,
it
domain.
I
What
is
a
knife
if
domain?
What
is
an
iPad
application?
What
is
a
knife?
It
end
node.
So
all
the
things
these
things
need
to
be
spelled
out.
You
want
to
be
an
application
if
you
want
to
be
a
specification
so,
as
I
said,
like
you're
doing
three
things
in
one
document
and
all
of
areas
are
under
specified,
so
what
I
would
suggest
you
doing
is
focus
on
one
thing
at
a
time
and
then
really
focus
on
closing
this
particular
item
and
then
move
on
so.
D
Actually,
we
clearly
states
the
scope
of
this
is
dropped
and
we
don't
give
any
specification.
We
just
provide
a
very
high-level
framework
but
to
defy
this
high-level
prim
work.
We
need
to
spell
out
the
terms
we
used
so
to
help
you
understand
what
we
are
talking
about.
So
that's
all
and
we
don't
actually
have
a
very
ambitious
to
cover
everything
to
even
talk
about
detail.
The
implementation
there's.
D
I,
what
I
say
is
right
now
there
are
up
of
four
similar
technologies
and
none
of
them
can
address
all
the
issues
specify
the
operators.
That's
why
we
need
a
high
level
framework
to
consolidate
all
them.
You
want
place
so
to
allow
the
operator,
through
ten
them
to
choose
one
or
another
or
integrate
them
together
in
their
application.
We
want
to
provide
this
kind
of
flexibility.
We
don't
want
to
stick
to
just
one
underlying
techniques.
Let's
note
I,
don't
think
this.
There
will
be
the
way
to
go.
C
P
D
So
that
why
I'm
free
the
even
higher
level
ways
Cour
different
planes,
even
control
plane,
a
telemetry
data,
plane,
telemetry
and
American
plane,
but
this
wise
that
dedicated
to
the
data
plane.
Also,
it's
dedicated
to
a
specific
class
of
a
data
plane,
telemetry
techniques.
We
call
that
on
pass
or
in
situ.
Whatever
is
a
basically
are
different
from
the
previous
passive
and
active
OAM
techniques.
Q
R
D
C
So
sping
is,
as
chair,
I've
heard
and
read
many
of
the
positive
and
negative
feedback
on
this
I
I
think
there
is
still
some
issues
to
resolve
myself
personally
I
now
speaking
individually.
I
reread
this
and
while
you
say
that
you're
doing
you're
setting
forth
a
problem
description
at
the
end,
you
say
we
solve
some
of
these
challenges
and
I
I
kind
of
sympathize
with
Frank.
D
Yes,
so
I
need
to
clarify
that
we
don't
intend
to
provide
solutions.
We
don't
either
claim
we
can
solve
this
problem.
You
just
provides
potential
opportunities.
I
introduced
several
useful
components
into
the
framework
based
on
our
previous
support
work,
and
we
already
show
the
great
potential
of
all
that
and
that's
why
we
want
to
document
the
challenges
and
share
experience
and
also
show
from
standard
perspective,
was
what's
the
gaps
it's
there.
So
that's
all
our
intention
for
this
draft
yeah.
C
So
I,
you
said
you
had
another
version
coming
I
would
say
to
the
gentleman
from
telefónica.
If
you
could
comment
on
list
I'm
going
to
make
another
comment
on
list
Frank
as
well.
Let's
see
if
we
can't
sort
those
things
out.
If
we're
going
to
move
this
forward,
we
need
to
address
some
of
those
points.
I
think
they're,
critical
and
also
what
Tim
was
saying.
Maybe
it's
not
clear
enough
how
this
differs
from
in
TF,
so
I
would
say
we
need
to
address
some
of
those
before
we
can.
We
can
once
again
consider
moving
forward.
C
B
Can
we
ask
what
the
interest
about
I
want
to
know
the
consensus
of
the
interest
on
this
draft
and
how
many
of
you
have
read
this
document?
Please
raise
your
hand,
then,
how
many
of
you
think
this
is
this
is
this
work
is
useful
and
would
like
to
work
on.
This
would
like
the
working
group
to
work
on
this
draft.
Please
raise
your
hand.
M
So
there
is
a
classical
approach
that
is
followed
by
the
ice
is
nowadays.
This
is
using
multiple
hardware
appliances
on
the
customer
premises,
equipment
that
are
interconnected
between
each
other
to
provide
the
service,
but
to
perform
the
installation
and
configuration
equipment
you
have
to
send
I
speak,
have
to
send
a
technician
on
the
site
to
perform
the
configuration
with
relative
of
the
topology
and
of
the
interior
service.
This
is
a
first
points
at
the
draft
address.
The
second
point
that
each
equipment
needs
to
be
shipped
and
it
occupies
in
space
in
the
rack.
M
The
third
point
that
if
there
is
some
modification
of
the
topology,
the
technician
should
be
sent
to
this
customer
premises,
equipment
of
customer
premises
to
perform
the
modification
of
this
topology,
and
here
we
try
to
provide
at
UCP
approach.
That
is
addressing
these
issues
so
because
the
UCP
is
our
only
ask
to
brutalize
network
appliances
at
our
hardware
to
perform
the
possibility
to
have
this
hardware
as
utilized
on
as
virtual
network
functions
that
are
interconnected
between
each
other.
M
This
is
the
first
point
that
is
trying
to
address
the
second
point
that
is
trying
to
address
the
draft
as
it.
If
you
need
to
specify
the
desert
configuration
bootstrap
of
the
equipment,
it
could
be
easily
changed
in
the
ECP
and
when
it
changed,
the
hardware
appliance
should
be
they
instantiated
and
instantiated
a
game.
So
the
UCP
is
trying
to
approach,
say,
discussed
points
that
were
highlighted
in
by
this
slide.
M
The
second
thing
that
we
in
the
draft
we
trying
to
address
it
each
supplier,
has
its
own
net,
convey
an
interface
that
is
managing
the
HCP.
The
CCP
includes
three
layers:
the
first
layer,
it's
hard
weather,
the
second
layer,
its
liberalisation
layer
and
FES
network
function,
virtualization
infrastructure
software
and
the
third
one,
its
Vienna
Flair.
M
So
to
manage
the
UCP.
The
explicit
is
the
second
layer
and
FES.
There
are
different
models
used
for
each
supplier
and
this
draft
tries
to
introduce
you
could
see
on
this
slide
on
the
bottom.
The
an
example
of
the
UCP
infrastructure
that
and
n
FES
is
a
key.
You
could
configure
be
a
annette
confirm,
interface
and
the
draft
is
addressing
the.
M
The
draft
is
proposing
that
Nia
is
a
young
model
that
is
unique
for
all
of
the
suppliers.
So,
basically,
with
this
young
model,
you
could
manage
the
CP
explicit,
easily
veered,
quick
emulator,
so
that
we
announce
that
inside
and
you
also
could
manage
the
vertices
or
vector
packet
processor
inside
of
the
UCP.
M
So
basically,
this
lights
presents
the
model
itself
on
right
and
you
could.
We
have
some
questions
to
the
working
group
regarding
the
improvement
of
the
document.
For
example,
do
we
need
to
include
some
specific
details
about
this
type,
for
example,
I,
D,
V,
R,
T
or
specific
options,
because
we
could
some
built
on
machines
require
specification
of
this,
so
the
question
should
be:
should
it
be
agnostic
in
gesture
service
in
the
Python
or
Java
logic,
or
should
it
be
at
the
part
of
the
young
model?
M
The
second
thing
that
we
would
like
to
address
its
do:
we
need
some
augmentations
statement
on
the
top
of
the
model,
because,
if
you
want
to
include
it
to
the
series
3
or
network
modeling
tree,
we
would
like
to
we
need
the
young
element.
Ation
model
in
this
young
model
and
another
question
is
about
the
CP
pinning.
M
Well,
sometimes
we
want
to
be
enough
to
not
intersect
between
each
other,
so
we
need
to
assign
one
core
to
one:
Yein
have
one
little
Corky
purse
wedding
or
the
physical
book,
or
in
this
case
two
little
course
to
say
specifically
enough
says
it
to
have
the
CPP
and
the
kind
of
isolation
between
zhenya
nerves.
Thank
you.
So
could
you
please
suggest
some
questions
or
suggestions
about
the
how
we
could
improve
the
draft.
S
M
In
this,
this,
this
model
introduced
introduces,
is
a
desire
configuration
that
is
specifically
allowing
us
for
the
network
element
to
have
the
possibility
to
specify
the
variable
and
the
value
is
a
variable
and
the
value
to
these
variables
that
you
would
like
to
put
in
the
series,
because
it's
like
kind
of
the
bootstrap
that
you
are
putting
to
the
to
the
BNF,
you
could
substitute
some
variables
from
this
bootstrap
with
some
values.
It's
the
first
thing.
S
M
H
M
So
thank
you
for
the
suggestion
actually
there's
new
versions
coming
and
we
included
the
young
model
to
the
T.
So
we
have
networks,
networks,
T
and
after
we
used
a
service
function
aware
topology
too,
as
it
is
draft
from
Tyus,
and
we
also
try
to
we
worked
during
some
time
on
it
and
we
will.
We
will
be
try
to
combine
together
different
tariffs,
ease
and
drafts
that
are
provided
by
the
IDF
to
achieve
the
goal.
So
the
basic
point
that
ZT
is
used
in
the
next
version,
so
we
augment
the
tt-33.
H
M
Yes,
indeed,
there
some
working
the
work
existed
at
sea,
but
the
idea
here
is
it
with
trying
to
to
integrate
the
not
explicitly
with
this
model,
the
next
model
in
the
new
job
that
is
coming.
If
you
are
interested,
you
could
come
and
we
could
discuss.
We
have
this
model
in
the
our,
not
notebook.
So
it's
openly
available
the
ideas
here
that
there
is
some
work
at
Etsy
and
they
we
have
some
structure
at
ITF
that
we
are
developing.
M
M
Okay,
so
they
do
that
in
the
next
version
of
the
draft.
We
are
kind
of
not
creating
everything
from
the
scratch.
It's
more
like
reusing
of
the
existing
RFC
and
drafts.
If
you
want
I
could
take
the
notebook
and
give
you
some
specific
details
after
the
session.
All
right
now
is
the.
It
depends
on
your
desire.
So
basically
the
idea
here
that
we
are
not
ready,
fining
the
existing
stuff,
we're
trying
to
use
not
explicitly
in
this
model.
L
M
L
M
Okay,
we
I
think
we
in
the
next
question
of
the
draft.
We
will
have
this.
Basically,
we
will
have
the
RFC
that
is
networks
network
after
we
have
T
and
we
augment
Eve
is
specific
series
away
and
Sarah
Sarah
topology
and
we
add
some
other
RFC's
to
convert
to
add
the
configuration
to
the
digital
configuration
and
for
the
image
image
booting
for
TCP.
So.
C
T
All
right
so
I'm,
Andrew
gray
and
I'm
here
to
talk
about
a
draft
idea
that
we
started
circling
a
little
bit
at
the
last
IETF
kind
of
put
a
little
meat
on
it.
So
we're
kind
of
opening
it
up
for
wider
audience
at
1:06
here
and
trying
to
get
some
more
feedback
and
input
on
it
right
now.
It's
called
sampled
streaming.
So
as
an
operator
I've
got
a
problem
coming
up
and
I
can
see
this
train
coming
at
me
from
a
little
wild
away.
T
I
have
a
lot
of
cooling
right
now
that
takes
actual
packet
data,
its
sampling
it
at
one
in
1,000
or
1
mm
I
have
dedicated
in
line
appliances.
Doing
this
or
sometimes
I'm
doing
this
on
box,
as
my
link
speeds
grow,
every
single
iteration
of
that
I
have
to
replace
that
hardware,
and
this
seems
kind
of
silly
when
I
have
a
giant
router,
that's
sitting
there
with
Hardware
on
board,
that's
perfectly
capable
of
replicating
packets.
For
me,
previous
arguments
against
this
had
been.
Oh,
you
know.
T
Computes
expensive
I've
got
so
much
virtualized
compute
right
now,
I've
got
gobs
and
gobs
of
computer.
That's
not
really!
My
problem
I
need
to
get
the
data
off
the
box
and
a
lot
of
the
existing
methods
today
use
on
BOTS
capabilities,
but
they're
either
have
control,
plane,
punts
and,
as
I
start
looking
at
higher
speed
cards
where
I'm
started
doing
you
know,
14
for
Terra
28
Terra
on
a
line
card
punting
to
the
control
plane,
it's
not
feasible,
I'm,
not
gonna,
be
able
to
get
a
sampling
rate
anywhere
close
to
where
I
want.
T
You
know
we're
hearing
one
in
20,000
might
even
be
optimistic
from
that,
so
I
need
to
be
able
to
control
this
sampling
or
this
packet
replication
or
span
or
whatever
you
want
to
call
it.
I
want
to
be
able
to
do
different
variable
sampling
rates
and
I
want
to
be
able
to
filter
this
on
ports
or
layer,
3
information,
or
what
have
you?
T
The
other
kind
of
nifty
thing
I
would
like
to
be
able
to
do,
is
be
able
to
grab
both
traffic
that
I'm
forwarding
and
traffic
I'm
dropping
so
inside
the
draft
itself
there's
a
little
bit
of
nomenclature.
We
just
put
in
there
just
to
try
and
keep
things
saying.
The
client
is
basically
the
Box
doing
the
configuration
work,
the
replicator
you
can,
if,
for
most
of
our
purposes,
think
the
main
router
the
control
plane.
T
So
my
must-haves
that
I
want,
as
an
operator
from
this
is
I,
need
this
to
be
extremely
light
on
my
own
box
CPU,
the
data
planes
are
scaling
incredibly
high
incredibly
quickly,
but
on
box
control
plane
and
on
box
CPU
aren't
I
cannot
be
sending
Tara
bits
of
traffic
to
my
own
box.
Cpu
it
will
melt
down
so
I
need
something
that
can
be
handled
strictly
on
the
data
plane.
I
want
to
avoid
ASIC,
recirculation
or
anything
that
causes
me
to
lose
performance
on
this
box.
T
Because,
again,
you
know
I'm
ringing
these
boxes,
pretty
hot
I,
don't
want
to
have
to
sit
here
and
worry
about
it
and,
most
importantly,
I
need
one
standard
method
to
cover
everything.
Routers,
ideally
servers.
Anything
that's
really
passing
traffic
should
be
able
to
handle
it
say
anything
nice
to
haves
as
a
packet
goes
through
a
box.
The
ASIC
certainly
knows
more
information
about
it
than
just
the
bits
and
bytes
of
the
packet
itself.
It
has
things
like
what
port
did
come
in
on
when
precisely
timestamp
wise,
so
that
packets
start
arriving.
T
What
is
my
intended
disposition
of
that
packet
am
I
gonna
forward
him,
I
gonna
drop
it
if
I'm
gonna
queue
it.
What
am
I
actually
doing
with
it
generally
internally
Asics
will
know
this
information
they'll,
have
it
in
various
bits
in
different
places
in
the
cells
that
are
it's
using
for
traffic,
with
I'd
like
to
be
able
to
get
that
I'd
like
to
be
able
to
pull
that
off
box,
so
I
can
do
analytics
and
everything
else
on
it.
T
T
We've
ran
this
Draft
around
a
few
different
people.
I
always
seem
to
get
the
same
set
of
questions
right
away
so
kind
of
heading
some
of
this
off
at
the
pass.
One
question
comes
up
fairly
often
so
why
not
use
an
IP
fix
extension
or
something
along
those
lines?
The
bullet
points
up
here
kind
of
talked
about
the
big
ones
of
that,
but
the
main
thing
is
I
want
the
raw,
packets
and
I
want
that
a
signet
it
Meishan
come
off
of
it.
T
T
It
sees
something
strange,
a
DDoS
or
a
micro
flow
DDoS,
whatever
you
want
to
call
it,
and
it
can
add
in
an
additional
rule,
says:
hey
I
want
to
see
this
traffic
and
I
want
to
see
it
at
1
to
1,
for
example,
and
a
lot
of
these
things
are
CPU
driven
they're,
either
control
plane
ponds
or
you
have
to
do
a
lot
of
work
on
the
chip
or
you
have
to
do
it.
Recirculation
implement
inside
the
specification
or
inside
the
draft.
T
There
is
actually
a
little
bit
negotiation
that
goes
on
in
the
actual
format
of
the
data
that
comes
off
towards
the
receiver.
Here
that
green
arrow
is
actually
determined
entirely
dynamically
in
the
protocol
it
is
not
set,
there
is
no
set
packet
format.
Instead,
what's
defined
is
basically
a
way
to
communicate.
This
is
the
structure
the
data
I'll
be
receiving.
So,
for
example,
it
can
say:
hey
I've
got
6
bits
at
the
header.
I'll
tell
you
what
the
input
ports
are
in
by
the
way.
T
Here's
the
mapping,
a
value
of
8
here
will
be
port
0
or
what
have
you
all
of
that
is
handled
in
the
control
plane,
negotiation
up
there
between
the
replicator
and
the
client.
The
point
doesn't
need
to
do
any
data
conversion
on
its
own.
It
just
copies
replicates
throws
a
header
on
it
and
gets
it
off
the
box.
T
So
that's
the
main
reason
behind
not
having
a
fixed
format
having
this
negotiate
format,
having
an
ASIC
try
and
do
anything
fancy
with
bit
minion
bit.
Manipulation
almost
inevitably
results
in
slowing
down
the
information,
the
how
much
it
can
work
through
the
specification
is
written
to
be
reasonably
future-proof
and
we're
looking
for
additional
inputs
or
what
else
we
can
add
in
there.
But
if
worse
comes
to
worse,
there
was
even
a
generic
padding,
just
hey.
This
is
13
bits
of
internal
garbage.
T
T
So
I'm
accepts
we're
at
a
OH
right
now,
which
kind
of
rework
a
couple
of
things.
There's
actually
now
a
mechanism
for
having
the
replicator
present
different
options
back
to
the
client,
so
the
client
can
say:
hey
I
want
this.
Replicator
can
say:
okay,
I
can
give
you
exactly
that,
but
you're
going
to
take
a
research
penalty
or
I
can
give
you
this
that's
kind
of
close.
Without
a
penalty,
we've
had
a
lot
of
good
feedback
and
from
a
few
different
operators
and
a
couple
different
hardware
providers
about
it.
I
You
have
one
friend,
programmers
and
so
I
have
a
load
of
sympathy
for
the
draft,
and
you
said
that,
well,
you
have
a
load
of
questions
that
you
typically
get
and
I
would
really
definitely
suggest
that
you
address
them
in
the
draft
right.
So
if
you
scan
through
the
draft,
you
don't
even
find
peace,
a
mention
so
I
would
have
expected
that
you
compare
to
5476
and
say
well,
this
is
what
we're
doing
differently
and
so
I
would
exact.
I
Well,
you
can
have
that
example
that
you
have
in
section
4
where
you
have
ACT
fields,
that's
forwarding
status
with
IP
fix
right,
so
you
have
incoming
port.
That's
ingress
interface.
You
have
the
time
stamp
field,
which
is
your
export
I'm
in
an
IP
fix.
So
all
these
fears
are
defined
we
can
should
should
have
at
least
if
you're
comparing.
This
is
how
you
would
do
it
with
IP
fix
and
peace
I
am,
and
this
is
how
we
do
it
and
hence
were
more
compact
and
that's
what
we're
adding
on.
I
T
S
Bogdanovich,
you
were
mentioning
performance,
yes
and
I
would
have
a
question
on
capacity
and
indirectly
you're
mentioning
capacity.
If
you
want
to
do
any
data
playing
packet
in
the
collection
mirroring,
you
always
have
a
choice,
there's
only
so
much.
You
know
things
on
the
ASIC
that
you
can
do
with
it
right
any
other
way.
What
you're
asking
for
is
sort
of
up
you,
you
cannot
have
both.
You
can
either
have
more
telemetry
from
the
data
point
or
you
have
more
packet
forwarding,
which
one
do
you
want.
T
T
So
that's
the
reason
why
that
option
was
in
there
in
terms
of
what
I
want
from
an
operator
perspective
I
want
the
data
off
the
box,
I'd
like
to
do
it
for
free,
but
that's
incredibly
optimistic
now,
I
will
say
generally
speaking
in
this,
the
reason
I
pulled
this
slide
back
up
the
the
interfaces
are
being
used
for
the
normal
traffic
flow
or
almost
certainly
not
going
to
be
the
interfaces.
I
use
the
Sun
traffic
off,
at
least
in
our
use
case.
T
Yes,
so
having
the
ASIC,
do
its
normal
processing
and
also
doing
effectively
a
packet
replication
going
somewhere
else,
yeah,
that's,
okay,
something
Asics
can
do
fairly.
Well.
Usually,
this
is
just
saying:
hey
copy
the
additional
med
data
and
throw
UDP
header
on
in
front
of
it
so
understood
it
is
a
concern,
but
you
know
to
your
point:
sacrifices
have
to
be
made
and.
S
The
other
part
is
also
when
you're
saying:
oh,
we
would
like
to
get
this
additional
data
mm-hmm
from
it.
You
can
get
it
in
this
whole
data,
but
again
it's
coming
at
the
cost.
So
it's
all
it's
all
about.
You
know
everything
comes
there
with
the
cost
and
there
has
been
you
know
a
long-standing
issue
with
that
many
people
was
oh.
We
would
like
to
know
to
have
this
information
from
it.
Yeah
sure
you
can
have
it,
but
this
is
what
it
cost
you
and
then
they're,
starting
to
rethink
that
the.
T
Issue
so
the
way
the
draft
is
written,
the
replicator
is
offering
what
it
can
provide
you
essentially
for
free.
So,
for
example,
if
it
knows
its
internal
format
has
this
additional
information.
That's
all
it's
describing
it's
saying.
Here's
the
additional
information,
that's
available,
we're
not
really
asking
for
it
to
do
additionals
so.
C
G
T
C
H
I
This
is
a
new
draft
that
we
just
recently
published
to
fill
an
old
gap,
so
we
have
quite
a
few
IEM
drafts
in
flight
and
they
are
touching
on
multiple
aspects.
There.
It
started
off
specific
specifying
the
data
fields
we
have
drafts
that
cover
operations.
We
have
a
yang
model.
We
have
a
draft
on
data
export.
We
have
multiple
drafts
on
the
various
encapsulations
for
the
various
protocols
that
IOM
lives
in,
but
we
never
had
one
draft
that
pulled
it
all
together.
I
Well,
we
have
one
now
I
think
that's
the
announcement
that
I
want
to
want
to
make,
because
many
people
have
been
asking
me:
how
does
it
all
fit
together
kind
of
give
me
an
inventory
of
what
is
out
there
and
tell
me
how
can
I
go
get
it
deployed?
What
do
I
need
to
go
and
consider
if
I
move
from
the
very
specification
into
something
that
is
real
life
and
Wiccan?
I
What
do
I
need
a
don't
take
into
account
so
discuss
how
I
use
namespaces,
how
I
use
layering
how
the
various
trade
option
types
are
used?
Why
do
you
have
different
trace
option
formats,
something
that
is
maybe
better
for
a
hardware
implementation,
something
that
is
maybe
better
for
a
software
implementation?
We're
discussing
all
of
that
in
that
particular
draft.
I
I
We
need
to
go
and
expand
on
what
a
particular
layer
is
and
how
you're
gonna,
don't
suppose
that
it's
supposed
to
use
the
layer
above
and
beyond
the
what
we
have
in
the
draft.
So
there's
a
couple
of
things.
We
need
to
go
and
expand
with
certain
and
caps
that
are
not
really
fleshed
out
as
part
of
the
original
drafts,
like
with
eg
re.
How
do
you
use
it
because
there's
multiple
ways
and
how
you're
gonna
go
use
it
so
I
think
we
have
a
home
for
that
now.
That's
it
any
thoughts!
Anything.
I
J
Jeff
I
think
it
is
very
useful.
It
puts
all
the
different
work
in
single
document
and
especially
for
people
who
come
into
this
area.
Now
it's
really
complex
to
understand,
what's
been
going
on
for
last
five
year,
starting
who
was
int
and
barefoot
in
everything
that
came
after.
So
it's
really
good
document
and
out
support
progress.
Okay,.
U
Rajeev,
oh
sorry
and
cisco,
this
is
really
useful.
One
thing
that
might
suggest
you
to
consider
is
that
maybe
expand
on
some
recommendation
like
there's
so
many
things
that
you
know
it's
like
a
recipe
for
how
to
cook
something
out
of
it.
If
there
is
a
section
where
you
could
give
some
sort
of
recommendation,
that
would
be
immensely
useful.
Okay,
thank
you.
N
They're,
all
up
at
night,
I
found
the
document
quite
useful,
because
navigating
all
the
IOM
at
the
ends
becomes
really
challenging.
If
you're,
not
part
of
the
people,
writing
the
documents-
and
you
try
to
apply
it.
I
would
agree
to
that.
Even
if
you're
right
in
that
right,
correct,
no
but
probably
I
mean
this
idea
of
the
strict
recommendations.
Probably
is
gonna
go
a
little
bit
too
far.
N
I
V
V
Ok,
thanks
yeah.
The
first
version
of
this
draft
was
presented.
The
last
idea.
We
made
significant
changes
to
the
draft
after
that
and
I'll
be
presenting
an
update
to
this
raft
we'll
go
over
a
quick
review
of
free
cap
of
what
this
draft
talks
about
from
the
solution
review
and
our
observations
with
IOT
devices.
V
So
what
we
have
been
doing
for
the
first
few
months
is
basically
correcting
a
TLS
profile
from
various
malware
families
from
eka
Phillips
and
what
we
had
identified
was
there
were
significant
differences
between
benign
flows
and
malware
flows.
I've
listed
some
of
them,
basically,
where
the
certificates
from
malware
flows
had
a
mismatch
between
s
and
I
and
DNS
names
they
were
using.
Self-Signed
certificates
were
using
expired
certificates.
V
So
what
we
identified
was
that
mud
as
such
is
very
useful
to
basically
protect
various
IOT
devices.
But
it
was
not
that
useful
for
IOT
devices,
which
had
very
broad
communication
patterns,
especially
those
I,
would
he
devices
which
put
new
skill
and
that
new
skill
would
change
the
server
and
other
devices
it
would
communicate
with,
and
we
also
saw
various
IOT
devices
were
vulnerable
to
TLS
based
attacks,
especially
the
man-in-the-middle
attacks.
So,
based
on
that,
we
have
been
profiling.
V
V
We
will
publish
a
paper
with
all
the
data
that
we
have
got
for
various
types
of
IOT
devices,
but,
for
example,
if
you
see
here,
the
number
of
extensions
offered
for
my
hardware
was
quite
different
from
what
echo
show
had
for
a
benign
flows.
We
could
also
see
a
difference
in
the
number
of
extension
types
used
by
benign
and
malware
flows.
I
think
the
graph
has
gone
bad.
I
right
sorry
for
that
benign
flow,
so
using
grease
values,
but
we
did
not
observe
any
of
the
malware
families
were
using
grease
values.
V
There
was
quite
a
bit
of
difference
in
the
supported
groups
that
were
used.
Sorry,
the
graph
has
gone
bad
again.
This
was
interesting
that
there
was
some
malice
which
were
using
a
PK
base
certificates,
but
many
of
the
malware
for
using
self-signed
certificates.
There
was
quite
a
bit
differences
in
the
signature
algorithms,
cypher
suits
and
for
google
home.
It
was
quite
astonishing
that
there
was
quite
a
bit
of
differences
in
the
cypher
suits
that
were
picked
by
Google
home
versus
what
was
picked
by
malware
flows,
and
the
protocol
versions
was
quite
different.
V
That
malware
was
using
TLS
1.0,
whereas
we
could
see
Google
home
was
using
TLS,
1.3
and
based
on
this
observation,
the
conclusion
that
we
could
at
least
initially
draw
is
that
malware's
cannot
mimic
the
detail,
asprova
files
of
several
hundreds
of
IOT
devices
and
cannot
keep
up
with
the
updates
to
the
Detailers
profile.
So
we
thought
it's.
It's
going
to
it's
gonna
be
really
useful
to
have
a
profile
for
IOT
devices
that
can
be
used
to
permit
intended
DTLS,
behavior
and
block
malicious
TTS
behavior.
C
W
W
X
I
want
to
present
our
service
assurance
for
in
10
days,
networking.
So,
first
of
all,
it's
an
architecture,
but
also
it's
a
set
of
API
to
the
yang
module.
It's
the
first
time,
I'm
presenting
I,
receive
also
already
some
feedback.
That's
why
there
isn't
like
it
is
our
non
zero,
zero
version,
the
drafts
all
right.
X
X
X
If
I
know,
a
component
is
failing
like
an
object,
for
example,
then
I
would
like
to
know
which
services
are
impacted
and
in
the
end,
what
we
want
to
do
is
how
to
solve
the
closed
loop,
because
you
like
to
get
human
out
of
the
art
of
this
now
the
end
goal
is
self,
whatever
healing
driving
in
10
days.
Networking
the
thing
was
intent
is
that
yeah,
this
top-down
approach,
declarative
way,
is
a
nice
concept
right.
We
try
to
be
super
first
with
ECA.
X
X
So
this
architecture
is
about
service
assurance
for
in
10,
basement
working.
We
want
to
decompose
a
bigger
problem
with
user
sessions
into
smaller
components,
and
we
want
to
assure
those
smaller
components.
One
by
one
to
complement
them
was
active.
Probing
right,
active
probing
is
great
end
to
end,
but
it's
like
a
black
box
of
the
network.
Yes,
there's
nothing
happening.
We
want
to
know,
what's
happening
crystal
box
right
exactly
what
the
issue
is
now
a
couple
of
cancer
that
I
want
to
bring
here
and
again.
X
I
will
be
quick
because
your
concepts
read
a
draft,
but
we
want
to
decompose
service
instance
and
I.
Take
a
very
simple
one.
Like
a
tunnel
there
into
sub
services
instances,
a
tunnel
depends
on
what
the
source
or
interface
destined
external
interfaces
and
then
those
depend
on
the
physical
interface
that
depends
on
the
device
right.
I
also
need
to
have
IP
connectivity.
That
depends
a
control
plane.
X
So
if
you
could
assure
every
single
part
of
those
sub
source
instances
in
embed
link,
then
we
would
know
what
we
could
infer
the
score:
the
house
core
of
the
device
and
that's
exactly
what
we
want
to
do
here
and
we
could
have
the
sentence
for
each
of
these
sub
service
instance,
and
we
would
be
able
to
know
what
well
first
of
all.
Okay.
X
X
Obviously
my
tunnel
would
be
broken
right
if
my
interface
with
my
Turner
phase
is
down
same
thing,
these
are
impacting
dependencies,
but
you've
got
also
like
informal
dependency
because,
most
of
the
time,
it's
more
difficult
to
find
a
symptom
that
the
route
goes
right
if
I
put
in
ecmp
there,
my
ecmp
is
not
healthy.
It's
unbalanced,
now
I
want
to
receive
is
an
information
that,
maybe
might
my
services
impacted.
It
depends
which
bus
I'm
taking
right,
maybe
so.
This
is
the
distinction
between
informational
and
impacting
dependencies.
So
so
far,
what
do
we
know?
X
We
know
that
one
is
service
degrades.
We
know
where
the
fault
is
because
we've
got
this
assurance
graph.
We
know
where
it's
not
because
it's
healthy
and
we
know
where
it
is
with
the
symptoms
or
the
route
goes,
and
we
know
the
reverse,
because
if
we
got
the
three
in
one
direction,
because
it's
a
gigantic
tree
for
all
services,
we
know
which
services
are
impacted,
which
is
also
very
important
for
customers.
I
have
to
solve
that
issue.
First,
now
the
architecture
we
take
from
the
service
from
figuration
Orchestrator.
X
We
extract
the
service,
type
and
ideas
of
what
we
want
to
configure.
This
is
the
start
of
the
intent
of
service
from
there
we
go
to
this
Orchestrator
there.
That
will
create
a
Xuan's
3
and
the
assurance
tree
goes
into
what's
called
signage
and
there
that
will
tell
actually
to
make
sure
I
get
the
interface
house.
X
I
need
to
go
on
a
device
for
interface,
get
a
set
of
metrics
and
compute
the
health
and
that's
hella
score
along
with
all
the
symptoms
would
be
sent
through
telemetry,
and
this
is
I
believe
the
way
to
solve
the
closed
loop
automation,
because
maybe
we'll
be
able
to
tell
that
interface
feeling
badly.
That
ecmp
has
got
an
issue
and
we
could
either
reconfigure
or
optimize,
but
you
know
exactly
what
we
configure
and
not
the
entire
service.
X
X
But,
more
importantly,
this
architecture
should
be
open.
Why?
Because
they're
only
if
they
are
not
many
operators
having
a
single
vendor
right.
So
if
we
want
this
to
work,
it
should
be
open
in
terms
of
API.
How,
for
me
an
API
is
a
young
model,
a
young
model
that
we
could
have
man's
so,
whether
what
is
open
actually
in
there.
These
are
the
two
arrows
over
there:
the
ability
to
read
and
configure
this
assurance
tree
whenever
you
got
the
service
and
the
ability
to
stream
the
health
status
so
the
score
and
the
symptoms.
X
This
is
what
you
got
in
the
in
the
yang
module
there.
What
this
work
is
not
about
it's
not
about
solid
izing,
yet
an
Orchestrator
too
difficult.
It's
not
about
aligning
the
same
agent
or
telling
exactly
what
expression
are
needed
to
to
discover
the
house
core
vision,
P
right,
we
could
do
some
in
the
ITF,
like
interface,
etc.
Great,
but
not
everything
now
typically,
I
put
this
in
a
purpose
in
a
very
small
font,
because
every
single
yang
tree
I
see
are
unreadable,
but
this
is
like
a
huge
screen
so
where
she
could.
X
X
What
else
we
could
tell
what
are
the
parameters
of
a
sip
service
if
I
go
to
device
house?
A
typical
parameter
is
the
device
ID
if
I'm
doing
the
interface
health?
This
is
this
interface
on
that
device,
etc.
But
what
we
could
do
as
well,
there
is
that
we
could
go
command
this.
We
could
create
more
of
those
sub
service.
X
So,
okay,
maybe
I,
was
quick
on
the
concept
on
the
architecture,
but
this
is
what
I
wanted
to
do
to
to
give
you
the
ability
to
read
a
draft
command.
So
is
this
something
like
a
read
problem
and
so
far
the
feedback
operator
is
yes,
and
is
this
something
we
should
be
solving
for
the
industry
and
here
so
feedback
flame
Tomatoes
up
to
you
a
little
bit
of
everything.
They
are
move
language,
yes,.
S
I
know
you,
so
this
is
a
problem
to
solve.
Most
of
the
operators
today
still
use
radius
accounting
records
for
the
service
assurance
they're
saying:
oh,
you
know
what
service
is
up
if
we
start
receiving
accounting
records
looking
at
what
they
were
using
they're,
you
know,
essentially
what
metadata
is
in
there.
That
would
be
a
good
thing
to
try
to
model
according
to
that,
because
they
are
different
ways.
S
X
It
is,
and
that's
why
there
is
something
Evan
mentioned-
is
that
even
if
I
would
like
to
get
yang
models
for
everything
sometime,
we
don't
have
that.
That's
why
there
is
a
notion
of
a
metric
engine
where
we're
getting
one
time
from
CLI,
one
time,
formation
and
P
one
time
from
yang
etc,
and
we
have
to
map
it
yes,
I
know,
but.
S
S
The
architecture
I
have
some
problems
because
I
consider
that
architecture
a
little
bit
you
complicated-
and
this
is
a
separate
discussion
and
last
would
be
there-
is
difference
between
autonomic
system
and
in
intent,
driven
networks.
These
are
two
separate
terms
and
you
mangal
them
up
at
the
beginning
of
your
presentation.
S
X
J
Just
you
just
kind
of
explain
what
they
do
on
daily
basis,
so
number
of
observations,
one
is
the
intent
consumption.
We
still
don't
know
how
to
program
the
system.
There
are
a
number
of
workflows
and
products,
but
they
are
not
industry
standards.
Everybody
does
something,
so
it
would
be
very
utiful
to
focus
on
that
number.
Two
expectation
generation.
It's
not
explained
in
the
draft,
and
this
is
one
of
the
most
complex
thing
you
need
to
generate
expectations
with
regards
to
operational
stage.
As
you
define
the
service
not
afterwards
I
mean
nobody
cares
about.
J
You
know
what
you
care
about,
whether
service
a
can
reach
service
B,
and
if
it's
over
the
tunnel
shall
be
budget
expectation
for
it
to
be
up
should
be
generated
within
number.
Three
here
is
normalization
layer,
which
is
one
of
the
most
complex
thing.
It's
really
what
didn't
refer
to
high
level
obstructed
model
I
get
data
over
streaming,
telemetry,
CLI,
all
kind
of
api's
grid.
How
do
you
model
of
the
stuff
in
the
hereand
way?
F
Two
comments
at
the
first
comment,
so
you
I'm
not
sure
I'm
understanding
you
the
riot
but
I
see,
is
clearing
more
layers.
You,
the
interior,
you
use
the
you
introduced,
so
I
have
a
little
concern
about
this:
walk
about
the
convergence
II
of
the
young
model,
walk
IETF,
so
I
think
we
already
do
a
lot
of
layers,
so
I
don't
think
we
try
to
make
more
layers.
F
So
these
are
first
concerned
the
second
one
I
think
I
follow
you
in
the
base
the
work,
in
fact,
for
the
past
three
years,
I
also,
we
also
do
a
lot
of
work
from
our
point
of
view,
I
think
the
most
that
had
injury
is
not
the
years.
A
lot
of
the
architecture,
and
also
this
is
the
model
I
think
the
most
important
that
you,
the
universe.
Attractor.
Definitely
you
need
a
provider
mom.
You
can
ISM
to
collect
the
network
estate
hers
as
much
as
possible.
U
Eva
sorry
Cisco
first,
it
is
very
useful.
Second,
if
you
think
about
from
the
perspective
of
you,
know
configuring
configuring
configuring.
There
has
not
been
a
concerted
effort
on
an
industry
person
on
this
night.
You
have
to
actually
be
able
to
model
the
assurance
aspect
and
create
that
hierarchy.
Now
things
can
mean
service
assurance
such
a
big
enchilada.
It
means
a
lot
of
things.
A
lot
of
people
might
be
useful
to
actually
contain
and
define
what
that
really
means.
Now
many
of
us
might
be
thinking
about
network
service
assurance.
U
Some
might
be
thinking
about
just
security
assurance,
and
the
list
would
go
on
now.
The
concept
that
what
I
gleaned
from
the
slide
could
equally
apply
in
any
of
those
cons,
specific
type
of
services
but
I
think,
what's
really
useful,
is
to
figure
out
the
hierarchy.
A
service
depends
on
ABC,
a
depends
on
X
Y,
Z
Z
depends
on
and
so
on
and
so
forth.
So
that
hierarchy
and
modeling
that
hierarchy
is,
they
are
extremely
useful.
Few
things
in
there
you
know
physical
versus
logical
awareness
would
be
very
key
to
reflect.
U
X
Y
Example,
yeah
Alex
can
I
have
two
comments.
One
thing
is
I
think
basically,
I
think
it's
I
see
two
problems,
actually
that
they
are,
which
you
might
actually
want
to
separate.
One
thing
is
actually
the
service
assurance
itself.
Is
the
service
monitoring
not
exactly
sure
where
you
call
it
it
tend
to
combine,
but
it's
really
basically
service
busy
monitoring
there
and
they
showing
the
the
service
service
insurance
for
the
service.
I.
Guess
that
there's
one
aspect.
The
second
aspect
is
the
dependency
graph
that
you're
doing
for
the
model,
driven
reasoning.
Y
There
is
something
that
we
could
almost
separate
out
from
that,
because
model-driven
reasoning
and
basic
dependency
graphs
basis
one
technique
to
address
that,
and
you
could
use
this
not
just
for
services
but
for
other
dependencies
in
network
ecology
as
well,
and
that's,
of
course,
is
separate
because
there
are
other
issues.
Of
course
with
this,
even
if
you
are
correctly,
there
are
two
separate
problems.
Thank.