►
From YouTube: IETF104-NMRG-20190325-1120
Description
NMRG meeting session at IETF104
2019/03/25 1120
https://datatracker.ietf.org/meeting/104/proceedings/
A
Okay,
so
this
is
a
first
session
of
energy
this
week
one-hour
session.
The
the
key
topic
of
this
session
will
be
on
intern
base
networking.
So
we
will
have
a
couple
of
presentation
of
new
new
work
proposed
in
this
activity
of
the
research
group.
We
will
have
also
a
second
session
on
first
day
where
we
will
address
other
topics
of
the
research
group
and
especially
a
discussion
on
our
ongoing
like
a
shuttering
or
evolution
of
the
energy
scope
and
activities.
A
So
starting
with
the
note
well,
so
this
is
a
IOT,
our
research
group,
but
the
Archaea
follows
the
IETF
policy.
So
this
is
the
usual
not
well.
Please
read
it
and
express
anything
with
respect
to
that.
If
you
have
something
to
tell
these,
you
are
requests
for
starting
the
meeting.
Can
we
have
one
or
two
minute
takers?
Please,
and
also
someone
to
relay
questions
and
comments
on
meet
echo
and
subscribe.
So
thanks
Daniel
for
minute
taker,
we
have
someone
for
to
relay
on
mythical
as
usual.
A
If
we
don't
have
someone,
we
will
not
stop
the
meeting.
So
don't
be
shy.
It's
not
a
lot
of
work,
especially
for
me
ta
Co
is
just
to
relay
where
we
are
in
the
presentation.
Okay,
thank
you
there,
blue
sheets,
so
please
circulate
the
blue
sheets
sign
them.
It's
very
important
to
evaluate
the
participation
in
the
session
and
also
to
plan
for
future
meetings.
Last
time
we
had
I
think
several
person
didn't
sign
up
the
blue
sheet,
so
it's
very
important
to
have
this
and
please
circulate
them
across
the
room
during
the
session.
Thank
you.
A
Heads
up
for
for
this
week,
as
I
already
told
you
so
it's
20
years
of
energy
this
year
and
thinking
much
it's
the
kind
of
official
creation
of
quasi-official
creation
of
energy
20
years
ago.
We
will
have
a
short
session
so
discussion
on
the
session
about
a
kind
of
retrospective
of
this
period
and
again
to
reflect
on
what
would
be
the
future
of
an
energy.
A
So
now
we
have
this
session
on
it
embedded
working,
which
is
to
follow
up
on
the
various
ipn
activity
we
have
been
working
on
since
a
bit
more
than
a
year,
and
also
with
the
goal
to
update
a
work
plan
based
on
new
inputs.
The
second
session
will
be
on
Thursday
afternoon,
and
there
we
will
have
a
set
of
inputs
to
the
discussion
about
the
future
of
an
emerging.
A
Today's
agenda
we
have
so.
This
is
a
short
introduction.
We
have
done
a
presentation
from
Richard
on
intend
classifications
reported
by
one
of
the
draft
of
the
submitted
to
the
research
group,
and
then
we
left
Jeff
with
IBM
the
technology.
Second
presentation
and
I
would
like
to
keep
some
time
at
the
end
of
this
session.
To
have
a
discussion
with
a
group,
especially
towards
updating
the
work
plan,
so
we
already
have
some
some
elements
in
the
work
plan,
but
I
think
new
new
new
activity
is
coming
up
also
and
to
define
a
bit
more
precisely.
A
What
could
be
the
deliverables
on
this
activity
for
the
research
group
may
be
identifying
some
milestones
objectives.
We
collect
you
to
reach
and
criteria
for
research
group
adoption,
so
we
will
switch
to
the
first
presentation
which
will
be
done
remotely
by
Richard,
so
Richard.
If
you
can
go
online
now,
please
I
will
show
your
slide.
C
C
But
there
are
an
even
actors,
actually
even
the
actors
involved
in,
in
creating
intents
and
designing
intents
and
are
not
always
agreed.
So
there
are
several
shared
principles
that
we
can
start
from.
The
first
one.
Obviously
intents
should
be
declarative,
focusing
on
the
what
and
not
on
the
Hat
as
far
as
possible.
They
should
be
separated
from
the
deployment
details,
and
if
we
want
to
make
the
intense
easier
for
the
user,
then
we
should
use
the
language
and
terminology
that
user
is
familiar
with
and
try
and
avoid
the
technical
terms
and
concepts.
C
On
the
other
hand,
we
want,
we
want
it
in
technology
independent.
We
also
want
it
to
be
vendor
independent
so
that
it
can
be
completely
portable
across
all
platforms
and,
finally,
the
the
intent
main
work.
So,
even
though
we
want
to
express
the
intent
in
a
non-technical
language,
we
would
like
that
the
the
framework
should
be
able
to
detect
and
resolve
conflicts.
Between
those
intents,
so
the
goal
of
this
document
is
to
discuss
how
we
can
classify
intense
in
in
regards
to
some
of
these
criteria.
C
So
on
the
next
slide,
we
just
talked
about
the
context
about
this,
a
little
where
justice
drops
it
in
the
wider
context
of
NMR,
GE
ietf
and
the
other
stos.
So,
of
course,
it's
closely
related
to
the
work
of
Alexander
clans
draft
on
the
concept
of
intent
and,
to
a
lesser
extent,
on
the
to
the
work
of
the
anima
group
autonomic
networking
our
aims
are
probably
broadly
similar
to
those
groups
to
influence
the
evolution
of
ascent
through
the
networking
to
bring
clarity
to
it
and
encourage
wider
discussion
and
adoption.
C
So
in
our
case,
we
feel
we
can
bring
something
by
defining
a
classification.
For
the
intents,
how
does
this
relate
to
the
NMR,
G
Charter,
and
so
the
Charter
includes
communication
services
between
management
systems
belonging
to
different
management,
domains,
intense
need
to
be
technology
independent
and
easily
transferable,
and
if
we
can
provide
a
robust
system
of
classification,
it'll
make
it
easier
to
transfer
those
intents
as
well
as
easier
to
catalogue,
search
and
retrieve
which
will
make
it
easier
to
reuse
of
the
intent.
C
Secondly,
an
emergency
is
expected
to
identify
and
document
requirements.
Survey
possible
approaches
provide
specifications.
So
this
current
draft,
okay,
we
said,
achieves
the
person.
That
would
be
a
little
premature
to
say
it
achieves
the
first
level.
But
it's
a
starting
point
for
discussion
that
be
identifying
and
documenting
the
requirements.
Are
that
impossible
approaches?
C
C
Okay,
so
the
next
slide,
four
requirements
for
different
users-
and
so
I
mentioned
that
for
different
stakeholders.
There
are
often
different
ideas
about
what
intent
means.
Often,
what
happens
when
new
terms
come
out?
People
assume
that
the
term
means
something
because
of
their
particular
experience
on
domaine.
C
So
what
we'd
like
to
do
is
establish
a
lexicon
for
intent
to
identify
what
each
stakeholder
wants
from
the
intent.
But
beyond
that,
even
who
are
even
the
stakeholders
for
intense
what
different
needs
do
they
have?
What
interfaces
ESL's?
What
models
do
they
need
and
all
the
different
solutions
and
different
users
will
have
different
use
cases,
requirements
for
different
levels
of
technical
expertise.
C
So
if
we
could
go
onto
the
next
slide,
please
yeah
thanks
so
and
what
are
the
best
ways
we
could
look.
At
the
intents,
one
way
would
be
by
solution
type
of
the
same
enterprise
data
center
carrier,
maybe
by
5g
specifically
another
way,
would
be
by
the
user
of
the
intent
so
administrator
intents
might
be
designed
to
keep
the
system
running
smoothly
and
efficiently.
In
an
enterprise
environment
administrators
might
also
create
intense
that
could
be
reused
by
multiple
users
in
a
larger
carrier
organization.
That
might
be
the
role
of
the
separate
operator
and
beyond
that.
C
We
yeah
so
then
intense
can
be
used
to
operate
some
classification
based
on
when
to
activate
intents
can
be
classified
to
based
on
when
the
intent
should
be
triggered.
That
could
be
immediately
if
there's
an
immediate,
urgent
need,
or
maybe
when
some
event
happens
in
the
future,
if
an
intrusion
is
detected
at
a
specific
time
in
the
future,
let's
say
during
a
maintenance
window
periodically
at
a
specific
time,
so
maybe
every
weekend
you
want
to
have
an
intent
or
when
some
condition
occurs.
C
The
next
classification,
maybe
could
be
based
on
lifecycle
management
requirements,
so
basically
either
transient
if
the
if
the
intent
has
no
lifecycle
to
manage
or
persistent,
if
there
is
a
lifecycle
to
manager.
So
a
persistent
intent
would
be
a
more
typical
intent
with
monitoring
closed-loop
self
optimization,
whereas
a
transient
intent
might
be
just
a
fire-and-forget
one
time
only,
and
so
what
the
implications
for
that
I
guess,
a
transient
intent,
maybe
shouldn't
be
considered
as
part
of
intent,
conflict
resolution.
If
it's,
if
it
was
just
a
one-time
intent,
they
have
no
life
cycle.
C
If
they
do,
if
the,
if
they
should
be
considered
as
part
of
conflict
resolution,
then
that
probably
implies
that
they
should
be.
They
should
be
a
persistent
tent.
On
the
other
hand,
although
a
transient,
no
lifecycle
itself,
it
could
be
that
the
transient,
the
transient
intent,
would
have
an
impact
on
persistent
intense.
C
Okay,
so
intent
classification
based
on
granularity
again
intents
can
have.
This
is
a
simple
classification,
in
intents,
can
have
different
granularities
high
granularity.
Intents
would
specify
the
intent
at
a
higher
level
closer
to
the
business
need
further
from
the
details
of
the
technical
of
the
technology,
and
this
would
make
it
may
be
more
difficult
for
the
framework
to
reason,
with
the
intents
for
translation
for
verification
and
conflict
resolution,
but
there
would
be
more
powerful
intense
if
they
could
remove
all
of
that
overhead
and
work
from
the
user
so
they're
more
powerful
intents.
C
Okay
and
then,
finally,
just
that
in
all
of
the
work
on
intense,
we
should
also
build
on
the
on
the
body
of
knowledge
around
policy.
So,
for
instance,
we
should
look
at
possibility
of
classifying
intents
in
the
context
of
the
policy.
Continuum
and
policy
continuum,
describes
actors
at
different
levels
of
abstraction
and
mapping
of
policies
between
layers.
So
this
is
obviously
analogous
to
our
concept
of
different
intent,
users
and
different
intent
layers
so
I'm
having
different,
lower
layer,
intense
support
them
higher
layer
intents,
so,
a
device
intent.
C
So
we
see
that
the
intent
has
a
very
wide
and
slightly
vague
scope
at
the
moment,
so
Alexander's
and
we
need
to
tighten
up.
Maybe
the
terminology
and
Alexander
clans
draft
is
working
towards
this.
So
we
think
that
adding
classifications
could
help
to
break
down
that
work,
to
separate
it
and
provide
different
areas
to
investigate.
And
so
we
need
to
engage
the
community
into
that
discussion
about
what
intent
means
to
different
stakeholders
and
how
how
intense
could
be
formally
classified.
C
C
D
B
D
Great
daniel
keene,
thank
you
Richard
for
the
presentation,
so
is
the
objective
here
to
have
one
intent,
framework
and
potential
language
to
rule
them
all,
because
there
already
are
a
number
of
intent
near
decorative
and
some
in
parrot
of
work
that
that's
out
there.
Things
like
group
based
policy
group
policy,
general
purpose,
information
model
event,
condition
action
role
based
access
control.
So
it
seems
that
before
we,
we
even
think
about
a
framework.
It's
worth
having
some
kind
of
comparative
analysis
of
what
already
exists
where
it's
used.
D
C
The
intent
here
is
not
to
you
have
proposed
a
single
language,
corrosion
law,
I.
Think,
as
you
mentioned,
there
are
different
bodies
of
knowledge
already
that
we
should
we
you
at
different
layers
and
when,
when
you
know
in
our
world,
when
meeting
content,
experience
and
more
at
the
top
level
of
business
content
and
that
needs
to
be
broken
down
into
intents
of
lower
layers,
I
think
that
the
lower
layers,
maybe
of
the
device
and
at
the
network
conductors
even
at
the
service
layer,
there
will
be
more
money
to
existing
existing
works
in
the
policy
arena.
C
That
you've
mentioned.
I
think
that
the
business
layer
there
are
probably
fewer
and
I
think
maybe
again
this
there
are
some.
There
is
some
work
there
again
Alexander
a
reference
Alexander
stuff,
so
we're
not
proposing
to
provide
a
new
intent
language
for
this.
Although
we
we
need
to
work
with
the
intent
language
as
its
defined,
and
we
would
like
to
input
to
it.
But
this
is
more
that
by
classifying
and
you
may
be
able
to
say
there
are
different
languages,
different
intent
of
different
layers,
of
different
of
different
vertical
levels
of
different
horizontal
levels.
F
Will
from
highway
so
actually
I'm
not
here,
to
also
answer
a
tenuous
question.
So
actually,
this
Jeff
is
a
very
good
space
for
us
to
start
in
tender.
A
little
work
in
this
RGB
course,
as
you
already
seen
this
presentation
that
in
the
word
industry,
there
are
already
any
kinds
of
a
categories
of
intent.
So
just
that
I
mean
before
we
have
a
clear
scope
and
a
clear
consensus
on
the
understanding
of
what
is
the
intent
in
the
term.
F
Asafa
I
mean
in
their
perspective
of
IGF
and
arch,
ever
every
scope,
and
then
we
can
start
to
really
work
on
what
it
will
be.
They
may
use
case
architecture
and
even
the
data
models.
However,
and
before
all
of
this
work
started,
we
first
need
to
know
where
we
need
to
know
that
in
the
whole
intent
continuum
which
part
will
I
you
care
for
RDF.
We
work
on
and
I
think
that
what
we
want
to
answer
this
question
I
mean
from
a
based
on
this
transition
and
also
the
trust.
That's
the
thank
you.
A
A
Think
for
this
work,
I
mean
it's
an
interesting
basis
and
inputs
that
the
group
can
build
upon,
but
I
think
we
still
have
to
go
through
some
iteration
to
clarify
the
priorities,
maybe,
as
we
was
mentioning,
also
the
scope
and
what
could
be
reused
or
what
will
be
a
big
directions
for
this
work
and
especially
in
a
I
think
in
a
few
months
how
to
consolidate,
maybe
with
other
works
and
become
more
like
a
research
group
documents
or
set
of
documents.
Okay,
thank
thanks.
We
switch
to
the
next
presentation
from
Tom
Jeff
thank.
C
G
G
So
why
are
we
here?
An
emoji
is
hum
for
IBM,
so
it's
natural
to
be
here,
there's
a
lot
of
stuff
that
still
needs
to
be
researched
before
it
can
go
into
ITF
streams
to
be
standardized
to
be
implemented
actually
so
problem
space
southbound
part
of
it
is
pretty
advanced
thanks
to
all
the
young
work
Benoist
here,
we've
got
pretty
good
set
of
interfaces
to
configure
stuff
and
to
get
telemetry.
If
we
look
at
telemetry
as
of
today,
most
of
it
is
already
model
driven.
I
could
extract
pretty
much
any
piece
of
information.
G
I
need
on
demand,
so
it's
really
great
and
I.
Don't
really
need
to
pull
system
anymore.
I
can
subscribe
to
a
particular
set
of
events
when
I
know
what
I
need
I'll
get,
what
any
the
intent
consumption
interface
is.
A
northbound
part
of
intent
system
is
not
really
defined.
We
know
there.
The
number
of
frameworks
people
trying
to
do
this,
but
as
industry
there's
really
nothing
one
more
point.
I
specifically
avoided
the
policy
part
it's
about
poisonous
tablet.
G
Practically
we
did
quite
some
research
in
the
industry
and
it
looks
a
group-based
policy
is
the
most
developed
part.
As
of
today,
it's
implemented
a
number
of
platform
written
open
stuff,
including
open
daylight.
Most
owners
have
plugins
into
the
framework,
so
it
looks
like
most
mature
framework
geez
from
my
personal
perspective,
again
Donna.
G
Using
southbound
models-
northbound,
yes,
I,
don't
think
any
work
be
done
in
young
today
is
good
enough
or
high-level
enough
to
provide
in
turn,
consumption.
From
my
perspective
least,
I
agree
to
disagree.
I
know,
I,
know
what
you
are
doing
right,
but
you
needed
a
hammer
to
make
it
work
and
I.
Don't
want
a
mercy.
G
So
if
you
look
at
today's
landscape
in
industry,
basically
machine
it
there,
it's
pretty
much
self
problem.
You
could
go
into
something.
That's
closely
related
to
vendors
Hardware
things
like
UCI
and
such
you
could
go
all
the
way
up
into
automation.
Tools
such
as
Snapple
saltstack
and
this
kind
of
stuff
and
just
configure
stuff
Cinda
sort
of
truce
is
being
worked
on.
There's
some
work
on
it.
G
We
know
there's
again
some
tooling
in
the
industry
to
provide
at
least
configuration
management
versioning.
So
it
could
be
uses
symbol.
Stress
it's
a
mandatory
period
quest.
However,
it's
not
really
problem.
The
real
problem
is
real
time
change.
Validation.
How
do
you
deal
with
the
changes?
How
do
you
scale?
How
do
you
decide
what
they
really
mean,
because
your
network
is
not
just
set
of
knots?
It's
all
vertical
stack
of
services,
one
on
top
of
another
and
figuring
out.
What
changed
in
particular
layer
means
to
other
layers,
it's
quite
complicated.
G
G
Problem
to
be
solved,
composition,
the
composition
scale,
you
need
both
functions.
You
need
to
compose
in
order
to
build
vertical
scale
of
services
and
unison.
Networking
routing
space
specifically
very
belong.
Looking
at
number
of
models,
you
need
to
build
and
still
missing
the
service
level.
Abstraction
is
a
problem,
so
composition
is
needed
in
order
to
create
a
service
another
site
in
order
to
troubleshoot.
In
order
to
understand
change
in
particular
level
and
related
to
other
levels,
you
need
to
be
able
to
decompose
your
complete
service
into
different
parts.
G
How
do
you
deal
with
changes
if
I
want
a
change
that
I
plan?
How
do
I
decide?
What
can
be
done
without
affecting
SLA
is
as
a
loss,
but
cannot
be
done
to
what
degree
so
the
understanding,
the
impact
before
change,
taking
place
and
plan
changes,
networks,
break
I
need
to
be
able
to.
You
understand
at
any
given
point
the
deviation
between
operational
state
and
intended
stay
and
take
actions
to
get
back
to
intended.
State.
G
G
The
idea
of
getting
all
the
information
isn't
doable.
We
see
already
today
in
midsize
network
amount
of
data
generated
some
terabytes.
So
getting
all
this
data
analyzing,
it
is
expensive
and
it's
pretty
much
enjoyable.
So
we
need
to
figure
out
how
to
get
less
data
but
much
better
data.
Our
definition,
data
data
that
could
be
used
and
actionable.
G
G
G
So
why
model
as
a
graph-
and
this
is
kind
of
going
to
lead
us
into
all
other
discussions,
because
we
are
our
idea
of
modeling
network
if
relay
graph
is
also
relationship
set
of
attributes
attached
to
this
relationship
ability
to
easily
extend
model
when
needed,
ability
to
query
graph
at
any
given
point
in
time
to
get
data
to
be
able
to
query
my
network
particular
question
so
I'm
not
going
to
ask
you.
Tell
me
everything,
I'm
going
to
ask
my
network.
Tell
me
how
your
interfaces
towards
particular
layer
look
like.
I
G
For
this
discussion,
I've
taken
very
simple
network:
it's
a
data
center
that
three
very
regular,
very
beautiful
apology.
So
it's
easy
to
reason
about
and
we
are
going
to
use
it.
So
if
you
look
at
the
graph
model
of
it,
we've
got
spines
that
helps
interfaces
and
it
has
links
on
it.
That's
connected
to
leaves
that
has
interfaces
on
it
that
connected
to
servers,
and
so
we
are
going
to
use
this
picture.
Keep
it
in
your
mind.
E
When
we're
speaking
just
to
help
you
all,
whilst
you're
doing
the
admin
right,
I'm
trying
to
kill
the
time,
so
you
mentioned
everything
in
there.
This
is
great.
There
is
one
thing
that
I
don't
see.
It
is
like
the
kpi's
first
service
right
because
in
the
end
I
mean
the
service
begin.
Just
configure
is
not
enough,
but
we
need
to
understand
whatever
service
is
des
credits
for
a
definition
of
a
service
which
is
also
a
Nintendo
finition.
Absolutely
will
you
be
covering.
G
That
yeah,
so
if
you
look
at
service
definition-
and
this
is
again
kind
of
missing
part,
because
it's
definition
of
your
service,
how
do
you
express
your
intent?
So
it's
not
only
a
VPN
with
particular
connectivity
point.
It's
else
amount
of
bandwidth
delay
any
set
of
KPIs
and
a
celesia
can
imagine.
We
should
be
able
to
express
an
intent
based
system
to
deliver
the
services.
E
Exactly
a
not
only
at
the
service
level,
on
top
of
an
Orchestrator
controller,
but
also
for
some
more
technologies.
How
do
you
know
if
this
specific
technology
works?
Fine
right?
It's
part
of
your
tree,
which
is
in
there?
It
is
so
yeah.
That's
the
next
thing.
The
IDF
should
be
doing
looking
more
into
the
assuring
specific
technologies
right
to
make
sure
at
the
top.
It's
a
should
as
well,
and
this
is
the
way
to
go
to
intense
we're
in
full
agreement.
G
So
composition,
this
is
the
graph
representation.
What
we
just
described,
just
simple
livings
my
network
in
data
center.
So
how
do
you
compose
a
service
again
full
slice
and
not
just
pieces
of
network?
We
take
spans,
we
take
clips
now.
We
know
how
they
connected
to
each
other.
We
take
servers
and
we
also
model
links
between
them
with
one
more
slide
yeah.
So,
as
you
could
see,
the
last
one
was
virtual
network
validation,
so
we
shall
network
has
nothing
to
do
with
physical
topology.
It's
really
your
service
topology.
G
So
it
could
be
your
LG
BP
and
it
could
be
your
vehicle
and
could
be
your
EVP
and
could
be
something
that
is
required
as
a
service
by
having
relationship
with
physical
topology.
Now
I've
got
full
graph.
That
gives
me
my
ability
to
model
the
service.
I
have
full
context.
I
know
what
to
ask
for
networks.
I
know.
If
particular
you
know
in
my
graph
fails.
G
I
know
what's
going
to
be
affected
in
what
way,
when
I
bring
analytics
on
top
even
simple
things
such
as
counters
on
the
switches
or
bandwidth
between
two
links,
I
know
exactly
what
it
means
for
the
service
if
I
go
into
planned
operations,
I
want
to
upgrade
my
switches.
I
know
exactly
how
many
switches
at
any
given
time
I'm
allowed
to
bring
down
in
order
to
upgrade
because
I
understand
service
definition,
service,
SLS
and
what
it's
going
to
take
to
deliver
them.
G
G
G
G
If
you
look
at
any
modern
graph
database,
it
gives
ability
to
attach
any
metadata
to
the
relationship
itself.
So
I
could
name
a
particular
knot.
I
could
name
it
relationship
to
any
other
object
in
the
graph.
I
could
attach
any
semantics
or
metadata
to
it.
So
if
I
want
to
see
every
knot
that
is
related
to
spine
in
this
case,
I
can
easy
query.
If
I
want
to
see
any
link
that
goes
from
spine
in
particular
direction.
I
can
do
so.
I
can
attach
vendor
name.
G
I
can
ask
I
want
to
see
all
the
switches
that
are
Cisco
I
want
to
see
all
the
systems
that
are
IPC's,
so
the
graph,
the
rich
graph
that
is
built
here.
If
my
ability
to
probe
to
inquiry
it
for
any
given
information
so
for
this
particular
case,
I'm
interested
in
any
path
from
one
part
of
the
network
to
another
part
of
the
network.
So
if
we
walk
so,
as
you
could
see,
there,
obviously
two
switches
on
one
site
and
four
switches
on
another
set,
which
gives
us
eight
paths
in
total.
G
Now,
just
using
simple
routine
for
each
link
in
linked
list,
I
could
walk
every
link.
I
could
measure
performance
of
the
link.
I
can
understand
what
it
means
to
the
service.
So
if
we
keep
walk
eight
times
so
you
see
I'm
just
going
pass
to
pass
to
pass
between,
leaves
and
spines
of
this
network.
I
can
easily
accumulate
lot
on
all
the
links.
I
can
easily
understand
what
it
means.
G
So
if
you
gather
all
the
data,
you
know
what
you're
going
to
end
up
on
huge
data
lakes
now
understands.
What's
in
them,
what
do
you
do
with
them?
You
just
keep
them
and
delete
them
every
two
weeks.
The
definitely
doesn't
work.
So
in
order
to
get
good
answers,
we
need
high
definition
telemetry.
We
need
to
know
a
lot
of
stuff.
G
However,
the
amount
of
data,
if
you
gather
everything,
is
really
analyzed
double
this
an
example
I'm
getting
telemetry
then
ask
for
all
the
telemetry
on
single
leaf
and
then
I
ask
for
all
the
claims
on
my
lives,
as
you
could
see,
amount
of
data
just
grown
exponentially
and
it
just
interface
just
counters.
So
if
you
try
to
ask
everything
related
you'll,
pretty
much.
H
I
have
issue
with
how
the
word
telemetry
is
being
used.
I
think
we
should
agree
upon
what
we
mean
by
telemetry
IRA
mean:
do
we
mean
by
how
what
is
the
scope
of
the
measurement
and
or
you
know,
is
it
the
data
that
is
being
transferred?
Having
a
good
definition
for
a
telemetry
would
be
helpful,
because,
right
now,
that
term
is
a
little
bit
overloaded.
D
Daniel
King,
so
so
on
that
there's
a
document
in
the
ops
area
working
group
right
now,
that's
sort
of
a
telemetry
framework
that
attempts
to
provide
a
definition
for
telemetry
and
it's
really
difficult
actually,
because
I
try
to
look
at
other
stos
and
some
open
source
projects
and
things
you
know
like
the
Linux
Foundation
with
Handler
and
things
and
finding
a
clear
definition
of
telemetry
was
was
not
possible.
They're
all
subjective.
You
know,
depending
on
the
different
deployments
and
news
cases
and.
G
Some
very
much
familiar
document
contributed
to
it
and
on
one
site,
there's
a
lot
of
stuff
around
another
site.
We
are
lucky
that
we
are
finally
getting
telemetry.
Is
that
we
need
it?
We
have
the
ability
to
get
high-definition
telemetry.
We
can
get
telemetry
the
Left
directly
from
the
asic,
so
we
are
not
limited
anymore
by
the
local
city
on
the
house.
So
also
stuff
is
coming
and
it's
finally
model
driven,
so
in
general,
there's
enough
means
to
get
good
telemetry.
G
However,
my
point
here
we
cannot
afford
to
gather
all
telemetry
available,
storing
terabytes
of
data
a
day.
It's
not
financially
viable
and
you
just
you
simply
cannot
analyze
it.
Most
of
telemetry
is
only
relevant
to
the
moment
have
been
gathered.
So
really
what
should
be
done?
You
give
the
telemetry
you
analyze
it.
You
know
the
context
you
throw
it
away.
A
G
So
an
example
how
we
can
do
it
since
I
know
the
part
of
the
network
I'm
trying
to
measure
my
credit
of
the
graph
would
be
show
me
counters
on
all
spine
interfaces
connected
to
live,
which,
as
we
know,
there
are
eight
right,
I
get
the
data.
I
implement
number
of
operations
work,
another
standard,
I,
put
water
market
and
say
get
this
information
for
number
of
minutes.
So
I
could
see
the
behavior
of
my
network
in
number
of
time
exactly
in
this
case,
I'm
interested
in
beer
of
my
network
in
3
minutes
out
of
7.
G
G
G
D
G
Learn
magic
right.
The
real
answer
is
in
at
least
what
I've
been
trying
to
design
is
to
build
by
pleasure
of
events
when
I
can
define
symptoms
and
if
I
can
match
all
the
symptoms.
To
particular
events,
I
could
identify
the
root
cause
analysis.
It's
not
an
easy
work,
it's
difficult!
Technically,
it's
difficult,
because
it's
continuous
process
and
network
changes
as
we
do
this,
so
you
really
need
to
decide
in
advance
the
slice
of
time
you're
going
to
take
in
order
to
identify,
root,
cause
and
I.
G
G
So,
to
conclude,
automation
is
very
hard
to
pick
everybody's
talking
about
automation,
but
practically
automation
of
configuration
is
done
deal
it's
not
so
complicated
anymore.
The
problem,
however,
one
second
after
you
have
deploy
your
configuration,
your
network
tip,
becomes
they
to
network,
because
someone
is
changing,
something
configuration
there
is
change
in
connectivity,
so
there's
drift
of
intent.
G
It's
not
what
you
intended
it
to
be.
It
is
what
it
is.
You
need
to
be
able
to
gather
the
operational
state
of
the
derived
state
compared
to
your
intended
state
and
be
able
to
explain
the
differences,
whether
you
need
to
remediate
whether
we
need
to
do
something
or
still
good
enough
to
meet.
There's
less
so
and
I
believe
this
area
requires
a
lot
of
research,
so
outside
of
definition
of
api's
and
normal
standard
works,
we
need
to
look
into
how
do
we
do
day?
Two
operations?
A
Okay,
before
we
go
for
the
question
because
already
have
several
during
the
presentation,
just
a
situation
point
on
the
blue
sheets,
please
make
them
strictly
because
I
see
that
I've
been
you
participants
in
the
room,
so
raise
your
hand
and
try
to
sign
the
Sheetz
Thanks.
We
try
to
have
okay
I
see
a
lot
of
people
lining
up.
A
I
try
to
be
very
efficient
with
the
comments
try
to
capture
them,
also
in
the
minutes,
because
I
really
would
like
that
we
have
at
least
two
minutes
to
show
what
will
be
the
next
step
for
the
work
plan,
but
we
are
finishing
in
nine
minutes.
So
please
be
good
point
for
the
comments
and
the
answer.
Okay,.
F
Only
two
simple
questions
so
for
the
first
one
I
searched
the
internet
draft,
you
know
ITF
and
the
scenes
now
there
is
no
clear
definition
of
IP
n,
so
I
wonder
I
mean
what
kind
of
scope
what
you
want
for
IP
n
map
I
mean
MRG
work.
This
is
the
first
question
and
second
question
and
actually
I
really
like
this
transition.
So
there
is
a
slide.
You
are
mentioning
the
levels
of
an
ibn
or
it's
like
automation,
or
something
like
that.
So
I
wonder
whether
that's
accurate.
Of
course.
F
G
I
think,
unless
you
can
build
full
lifecycle
management,
this
work
is
meaningless.
You
cannot
just
part
of
it,
so
we
are
talking
about
design
deploy
operations
continuously.
So
this
should
be
the
scope.
You
should
know
how
to
express
your
intent
that
it
becomes
a
blueprint
so
network
you
intend
to
design,
then
how
you
deploy
it.
So
what
you
have
designed
should
be
deployable
or,
if
not,
you
should
know
why,
and
then
the
continuous
operations
ability
to
take
telemetry
from
the
network
and
relate
it
to
the
state
of
your
network.
F
So
you
mean
all
these
sentences
you
mentioned.
Those
is
the
whole
architecture,
and
the
related
to
process
is
the
concept
of
your
intent
to
map
in
emerging.
So
I
have
a
second
class
I
mean
I,
have
an
additional
question
for
this
one,
because
I
don't
think
most
of
them
are
I
mean
only
part
of
them
can
be
mapped
into
I
mean
I
can't
work.
Another
part.
Maybe
some
intern
I
mean
software
realization,
and
that
is
not
sure.
G
K
On
directly
from
that
point,
because
I
I
think
we're
trying
to
discuss
the
same
thing,
are
you
proposing
I
really
like
what
you've
put
together
here?
I?
Think
it's
a
really
good
exploration
of
the
problems,
particularly
with
the
large-scale
data
management,
the
amount
of
and
I
used.
The
word
telemetry
in
quotes
here
think
the
sheer
amount
of
input
data
you
are
having
to
use
to
make
your
decisions
to
match
your
intent.
Great
explanation:
that's
fine!
Where
does
the
IETF
in
the
IRT
ever.
J
K
Into
this,
what
are
we
trying
to
define?
Where
are
the?
Where
are
the
interoperability
points?
And
what
are
we
missing,
that
the
southbound
doesn't
provide
us
or
that
we
need
to
define
in
a
vendor
neutral
manner?
At
the
northbound
side,
I
mean:
do
we
need
a
policy
description
framework,
a
way
of
defining
a
policy
that
can
be
shared
between
different
vendor
installations
and
different
customer
installations?
These
are
questions
describing
how
one
might
solve
constraint,
based
logic,
programming
problems
through
machine
learning
or
expert
systems
or
whatever
I
believe
that's
totally
out
of
scope.
K
That's
great
academic
research-
and
you
know-
we've
been
doing
this
for
50
years
now
and
we
will
continue
to
do
it.
You
know
and
I
there's
a
great
rabbit
hole,
but
this
is
not
the
forum
to
go
down
there.
I'd
love
to
see
what
people
believe
are
the
gaps
that
IETF
should
look
at
and
what
is
fully
out
of
scope,
yeah,
but.
A
Just
remind
I
would
like
to
remind
that
we
are
in
the
Aria
research
group,
so
I
think
it's
fully
valuable
to
in
value
to
think
what
could
be
transfer
or
what
would
be
so
perfect
for
IHS
but
I.
Think
it's
not
the
primary
motivation
of
this
work
in
energy.
Maybe
again,
the
discussion
is,
is
welcome,
but
I
don't
want
everything
to
be
discussed
from
an
IETF
point
of
view.
Absolutely.
K
Absolutely
and
I
do
take
your
point.
I
just
think
if
we
make
the
boundary
of
the
problems
so
big
we're
never
going
to
make
any
progress
and
I'd
like
to
try
and
I
would
suggest
that
this
working
group
scopes
it.
So
research
group
scopes
itself
to
where
it
can
actually
make
some
progress
rather
than
saying
hey.
Let's
look
at
constraint,
logic
programming
for
a
bit.
E
No
just
furring
on
this
because
actually
you
said
most
of
them
wanted
to
say,
I'm
working
on
this
and
in
my
company
and
I'm
scratching
my
hat
on
what
are
we
missing
here?
You
know
there
were
missing
couple
of
building
blocks
right,
a
couple
of
those
couple
of
tools,
but
all
the
rest
will
become
very
quickly
proprietary,
so
yeah
I
understand
the
goal
to
be
multi-vendor,
but
it
will
be.
You
know
there
is
not
much
we
could
do
in
the
ITF
for
to
solve
that
issue.
I
believe
so.
G
E
For
me,
yang
kind
of
done
in
the
right
path,
maybe
not
in
production
yet,
but
it's
there
come
fake
down
operational
data
done.
What
are
you
missing?
The
feedback
loop,
the
kpi's,
the
contacts
that
you
mentioned
and
all
this,
but
how
much
could
be
to
be
done?
How
much
should
be
done
here
as
opposed
to
something
proprietary,
because
it's
what
indigence
will
be?
Ok,.
L
G
A
A
One
comment
more
as
a
contributor
I
think
in
your
proposal.
I
think
it
will
be
very
interesting
to
go
into
some
kind
of
providing
measurement,
some
maybe
aspect
of
evaluation,
because
I
think
you
are
making
a
proposal
here.
I
mean
some
statements.
Maybe
we
also
as
a
research
group
and
maybe
collaborate
with
mapper
G
or
some
some
other
groups,
that
what
do
we
have?
A
G
A
B
A
So
this
is
what
we
discuss
a
bit
more
than
a
year
ago.
We
also
mentioned
that
additional
items
could
be
proposed
like
specific
work
on
function
and
techniques,
use
cases
other
challenging
areas.
So
I
think
we
have
seen
today,
for
instance,
wrote
that
complements
some
of
the
lines,
but
also
propose
new
things,
based
also
on
some
previous
description
before
this
meeting
in
the
energy.
A
Complete
also
extend
the
work
on
terminology
and
taxonomy
with
some
aspect,
pretending
more
to
define
the
concept,
explain
the
concept
in
the
first
stage
to
clarify
in
turn,
base
networking
and
intense
also
mentioned
as
part
of
the
the
presentation
from
Jeff
the
aspect
of
should
we
consider
intents
at
various
times.
I
mean
design
and
run
times
and
more
use
of
continuous
integration.
Continuous
delivery,
as
part
of
the
operation
I
think
Jeff
mentioned
importance
of
state
to
operation.
A
How
intense
was
the
well
could
be
the
rolling
place
of
intense
in
that
in
that
scenario,
and
if
or
not
the
research
group
has
something
to
say
in
that
in
that
aspect,
so
interoperability
I,
think
some
of
the
comments
were
on
the
aspect
of
what
could
be
work
in
the
scope
of
IETF.
With
respect
to
this
IBM
technology,
some
elements
of
interoperability,
we
may
need
to
identify
them.
A
So
this
could
be
an
area
of
investigation
for
the
research
group
as
part
of
the
presentation
of
Jeff,
also
the
aspect
of
be
able
to
continuously
validate
the
realization
of
the
intent
and
also
the
cost
of
this
validation.
If
we
need
to
measure
large
amount
of
data,
is
it
a
right
and
sustainable
way
or
if
we
need
to
attach
to
have
a
more
sophisticated
approach
to
try
to
put
context
into
how
to
extract
meaningful
knowledge
out
of
data?
A
One
element
I
think
it's
very
important
for
the
research
group
is
true
to
to
grow
in
the
area
of
I,
mean
try
to
evaluate
validate
this
concept
of
intend
basis,
working
to
provide
a
bit
more
numerical
or
I
mean
results
to
sustain
or
support
various
various
approaches.
We
may
even
go
towards
proposal
for
aspect
of
implementation
or
demonstration
of
some
of
the
functionality.
This
is
something
we
can
think
about
for
for
this
activity
in
the
research
group.
J
A
We
would
like
to
reach
with
this
work
in
the
research
room,
just
in
terms
of
support
that
we
will
provide
for
this
activity,
so
I
mean
we
have
a
lot
of
discussion
since
Singapore,
but
also
in
montréal
I
think
we
are
a
bit
struggling
to
to
make
more
regular
progress,
so
the
instant
it
will
be
to
have
more
regular,
dedicated
virtual
meetings
for
this
activity.
It
will
be
up
to
the
various
contributor
to
to
define
a
bit
during
the
period
of
these
dis
meetings,
but
we
will
provide
support
for
that.
A
Maybe
use
also
some
couple
of
interim
meetings
to
make
a
bit
of
face
to
face
brainstorming,
editing
session,
whatever
clarification
work
on
the
architecture
that
that
needs
to
be
that
is
more
easily
done
face
to
face
with
some
whiteboards
tentatively,
we
are
trying
to
organise
something
in
June.
The
target
here
will
be
a
second
or
third
week
of
June,
potentially
in
Silicon
Valley
Mountain,
View,
Santa
Clara,
something
like
this
and
details
will
be
discussed
and
communicated
next
target
will
be
also
July.
A
Some,
like
akhaten
participation
in
the
IETF
scope,
then
also
supports
use
them
in
English
I.
Think
we
have
very
good
comments,
forgive
based
on
the
interactions.
Please
try
to
route
brought
them
to
the
mailing
list,
because
some
of
the
people
are
removed.
Some
of
people
cannot
come
to
the
FDF
meeting,
but
they
are
still
interesting
into
this
topic.
So
I
mean
we
will
pause
the
minutes.
A
But
if
you
have
specific
points
of
discussion
use
the
meaningless
to
the
best
possible
and
if
you
think
we
need
other
tools
to
support
this
activity
create,
maybe
a
get
up
repository
all
the
collaborative
platform.
Whatever
you
need
come
to
me,
we
will
discuss
it
and
provide
the
supports
required
to
make
this
progress
because
I
think
we
really
need.
Now.
We
have
a
good
set
of
participants
and
active
contributors,
as
I
said
that
the
work
is
structuring,
but
we
need
to
start
delivering
and
progressing
along
the
year
on
this
topic.