►
From YouTube: IETF105-OPSAWG-20190724-1000
Description
OPSAWG meeting session at IETF105
2019/07/24 1000
https://datatracker.ietf.org/meeting/105/proceedings/
A
This
is
an
official
IETF
working
group
meeting
as
such.
The
note
well
applies.
I
assume
many
people
in
here
have
read
this
thoroughly,
but
if
not
I
will
leave
it
up
there
for
people
to
glance
at
and
be
aware
of
how
your
contributions
work
here
at
the
IETF.
So
do
be
aware.
This
is
a
formal
meeting
and
the
note
well
applies.
A
A
The
good
news
is:
we've
seen
a
lot
of
mailing
list
activity
this
time
around
we've
got
some
new
adopted
documents
as
well,
so
we'll
cover
those
after
the
ops
area
working
group
portion,
we
will
hand
it
over
to
our
area
directors
to
do
the
ops
area
portion
of
the
meeting
before
we
go
any
further.
May
I
ask
for
a
jabber
scribe,
a
jabber
scribe
only
and
I'm
kind
of
looking
at
Joel
yeagley
over
here
in
the
corner
of
my
eye.
Joel
has
agreed
to
do
it.
That's
fantastic
in
terms
of
minutes.
A
We
do
have
an
ether
pad.
You
see
the
link
up
there,
I'm
currently
in
it,
but
what
I
did
last
time
was
I
just
transcribed
this
off
the
YouTube
thing,
and
that
worked
pretty
well,
so
I'm
gonna
say
we'll
do
that
again.
However,
we
would
appreciate
that
if
anyone
wants
to
note
something
down
in
one
of
these
sessions
and
one
of
the
presentations,
please
join
the
ether
pad
and
Mark
that
in
there,
so
we
can
capture
it
officially
in
the
minutes.
That
would
be
fantastic.
You
see
the
link
to
the
slides
there.
A
The
slides
are
posted
in
our
Genda
are
sorry
in
our
material
section
for
this
meeting
and
they
are
in
the
order
that
they
will
be
presented.
We
have
four
remote
presentations
this
time,
but
the
most
I've
ever
had
is
zero
remote
presentations.
So
this
is
substantially
more
we'll
see
how
that
goes.
They've
all
been
notified.
We
work
with
meet
echo.
So
we
will
will
attempt
to
do
the
remote
presentations
when
they
come
up.
Have
people
sign
the
blue
sheets?
I
think
they
just
came
back
up
to
the
front.
A
A
Okay.
So,
where
we're
at
right
now,
we
have
four
one
just
got
adopted
recently
for
working
group
documents.
The
TAC
acts
draft
is
gone
through
a
round
of
iesg
review.
The
authors
have
replied
to
most
of
the
discusses.
We
are
awaiting
a
updated
revision
of
the
tac-x
draft.
I'm
told
I
contacted
the
author's
they
weren't
able
to
do
one
prior
to
this
meeting.
However,
they
expect
an
update
to
address
the
discusses,
as
have
gone
out
on
the
mailing
list
in
the
next
two
weeks,
so
we
will
expect
to
see
an
update.
A
Then
we
recently
adapted
the
network
telemetry
framework
on
draft
that
has
become
a
working
group
document.
That's
been
presented
here
a
couple
of
times
the
secure
device
initialization
that
Warren
and
others
have
written.
That
was
recently
adopted.
That
has
got
some
good
initial
feedback
and
it
might
be
in
a
fairly
stable
state.
A
So
we
would
encourage
all
of
you
to
read
all
of
these
drafts
and
comment
on
the
mailing
list
and
finally,
just
last
night
I
think
the
tac-x,
a
yang
module
draft
became
a
was
switched
over
and
this
is
a
complement
to
the
radius
portion
of
the
ITF
system,
module
to
be
able
to
configure
tax
server
parameters
and
that
will
be
presented.
The
updates
of
that
and
some
open
issues
and
and
requests
for
feedback
from
the
working
group
will
be
presented
this
morning.
A
B
B
So
right
now
the
tacos
plus
only
contains
TECO's
client
parameters.
Here
is
the
tree
structure
of
the
tacos
class
young
right
now
for
this
version
and
this
version
we
address
the
comments
from
the
Middle
East
and
now
like
the
like,
the
sauce
interface
and
vrf
interface
right
now.
This
is
the
edit
since
last
meeting
for
now,
there's
still
some
issues
here.
The
first
one
is
the
down
Rev
TECO's
protocol.
B
It's
now,
as
the
chair
said,
is
under
the
ISD
and
but
it
the
tacos
truck
prodigal
right
now
is
information
mock
draft
and
will
be
published
as
information
I've
received.
So
our
job
is
too
dependent
on
this
protocol.
So
we
see
the
comment
from
the
melon
is
that
it
from
idiot
he
proposed
to
discuss
it
in
the
working
group,
so
he
he.
He
said
that
we
should
be
that
the
ad
knows
that
and
should
approve
this.
It's
okay,
then
the
next
one,
okay.
A
C
C
Ignazio
Donna's
right
now
the
document
that
is
being
in
energy
relations
about
tactics
the
work
on
what
is
beyond
the
tax
with
different
transports
and
extensions.
That's
obviously
it's
not
chatter
it
or
is
not
happening.
That
was
an
agreement
that
the
working
group
first
pushes
the
tactics,
tactics
flow
and
only
then
the
new
work
over
the
new
item
starts
and
now
are
you
certain
that
the
way
how
you
model
the
the
TLS
extensions
were?
That
will
be
what
the
working
group
wants
to
see
from
a
transfer
perspective
for
the
new
attacks
or
for
extended
tactics.
A
B
The
the
other
issue
is
also
from
admin.
He
haven't
actually
proposed.
This
comment
at
their
first,
the
beginning
of
this
draft
young,
because
I
think
right
now
the
system
model
already
defined
the
the
like
how
to
use
the
local
authentication
and,
together
with
radius
and
tech,
Hawks,
no,
not
include
TECO's,
but
we
propose
that
echoes
tech,
ax
plus
young
model,
so
this
should
be
also
be
considered
to
be
integrated
into
system
young
model.
B
So
right
now,
although
we
already
defined
Atticus
client,
but
we
still
need
to
define
the
system,
authentication
extension
to
include
the
Texas
authentication
methods
in
it.
So
for
now
we
we
don't
have
the
think
out
solution
to
address
that.
I
think
it
needs
to
be
a
dropped
to
address
this
like
a
systems
and
triple
a
draft
to
do
another
augmentation,
because
I
think
there's
also
a
comment
from
radius
extension
working
group.
They
they
don't
like
the
system.
Triple
A
just
include
the
tax
plus
of
authentication.
B
They
want
to
have
whole
if,
if
it's
a
triple
a
system,
triple
a
draft
but
I
also
think
maybe
we
can
add
a
section
to
give
example
for
like
what
will
the
system
authentication
would
be
like
if
the
tentacles
plus
would
be
added
into
it.
So
right
now,
I
I,
don't
have
answer
for
that.
So
I
think
it's
belongs
to
Opera's
area.
So
I'd
like
to
hear
the
eighties.
C
Gospel
donors,
what
am
I
thinking
for
this
is
a
sort
of
a
simple
change.
Do
it
here
and
well,
as
you
call
it
an
example,
section
going
a
net
mode
way
and
publishing
a
draft
which
changes
one
line
there
as
think
it
will
take
free
by
DT
of
cycles,
and
that
will
result
in
probably
over
engineer
system.
This
is
something
like
a
point
fix,
especially
given
the
discussions
about
the
versioning
and
changes
of
the
models
themselves,
possibly
taking
them
out
at
some
point
of
time,
away
from
an
RFC
publishing
process.
B
C
B
So
I
would
choose
that
the
second
one,
okay
I,
also
had
the
comment
from
the
John
Hursley
he
his.
He
said
that
the
current
TECO's
counter
include
the
not
include
that
connection
opens
count,
but
for
like
single
connection
case,
then
the
TECO's
connection
may
be
more
than
one
session,
so
maybe
we
can
add
sessions
count.
So
I
also
like
to
hear
more
comments
from
the
working
group,
so.
B
I
will
add
this
one
to
the
update
dropped.
So
that's
all
this
issue
is
related
to
this
drop
right
now,
so
I
will
resolve
the
comments
from
because
John
has
me
propose
a
more
editorial
and
also
some
technical
drafts
comments
from
so
I
will
next
up
I
will
resolve
these
comments
and,
together
with
this
issued
proposed
so
I
like
to
hear
more
comments
and
suggestion
from
the
working
group.
So
that's
all
furthest
thanks.
A
I
would
say,
we'd
all
like
to
hear
more
comments
as
well,
but
it
sounds
like
you
have
another
action
to
at
least
handle
the
initial
authentication
piece
as
an
augmentation
here
we're
whether
or
not
another
draft
about
a
more
fleshed
out.
Triple
A
happens
that
could
be
proposed,
but
seems
like
that's
another
piece
before
we
can.
We
can
keep
progressing
this
okay.
A
A
A
Will
update
a
new
one,
so
that's
in
two
is
I.
Think
after
that
it
feels
like
it's
it's
getting.
It
seems
like
a
fairly
straightforward
yang
module
reads
that
way
to
me:
we've
taken
out
some
of
the
triple-a
stuff
I
think
we
would
be
ready
to
move
to
last
call
unless
there
are
any
blocking
issues
that
come
up
on
the
list.
I.
C
Think
as
well,
no,
in
fact
that
was
my
question-
it's
not
about
when
to
publish
the
next
version,
but
when
you
believe
that
you
have
addressed
the
community
comments
and
socialized
that
with
the
user
base,
and
you
will
think
that
this
will
be
done.
So
in
a
sense
when
this
model
can
be
considered
stable
and
shipping
I.
B
B
This
draft
is
about
sd1
service,
delivering
model
and
right
now
it's
a
the
first
version
of
in
the
video
one
and
so
I.
Just
give
a
brief
in
description
of
what
it's
Estevan
service
model
is.
So
it's
this
SQL
service
is
a
connected
connection.
Service
will
be
offered
between
one
two
or
more
sites
across
this
is
all
customer
sites
and
could
be
use
a
one
or
more
underlay
networks
and
what
this
model
for.
B
We
think
the
it's
just
a
further
service,
crud
service
provider
scenario,
and
that
this
model
is
used
for
service
providers,
service
box,
traitor
to
dynamically,
create
modified,
the
as
divine
service
components.
The
components
could
be
like
at
a
new
site
or
an
a
new
VPN
connection
between
the
sites
and
also
at
some
applications,
ala
C
component,
so
things
last
IETF
meeting
we
have
such
changes
and
first
we
have
a
new
co-author
chose.
A
co-chair
is
chairing
the
muf
application.
Community
and
sd1
project
is
under
his
lead,
so
he's
very
familiar
with
SQL
service
staff
manager.
B
So
we,
with
his
help,
we
make
the
the
sp1
and
EF
as
to
project
alignment.
With
this
draft,
we
added
the
mouth
related
references
now
enough
has
already
published
its
dropped
specification
about
SQL
service
attributes,
and
we
also
add
the
terminology
comparison,
because
in
that
way
our
draft
is
more
will
be
more
easily
to
n
standard
by
the
ITF
traditions.
So
this
is
a
main
changes
and
we
also
made
the
whole
editorial
change:
the
entire
trapped
to
be
better
aligned
with
math
project
and
readability.
B
And
besides
all
this,
we
also
highlight
this
ice
as
divine
application
based
policy
service
sayings
as
Devon.
It's
quite
different
with
a
traditional
hu
huiqian
and
our
European.
It
has
application
based
multi,
pass
selection
feature.
So
there's
a
lot
of
policy
related
this.
This
multi
pass
selection
policy.
So
this
is
the
main
changes
and
they
also
add
a
section
to
hi
elaborate.
What's
of
difference
with
the
OSE
draft,
it's
proposed
being
RTG
WG,
so
that's
a
them.
The
elbow
changes
and
for
the
OSI
model
difference
here
is
the
major
difference.
B
The
major
difference
is
our
SD
one
service
model,
which
is
a
quite
high
high
level
interface
to
the
customer.
We
its
upon
the
users
or
request
service,
will
do
some
infrastructure
service
like
sites
connection
and
also
application
policy.
This
is
it's
a
very
high
level
one
for
the
for
this
model.
It
will
not
be
aware
any
like
real
underlay
resources
here,
but
for
OSE
model,
the
assumption
is
quite
different.
B
They,
the
field,
Estevan
infrastructure
service,
is
just
a
within
their
wonder
domain
as
d1
managers
a
scope,
so
they
don't
want
to
touch
anything
about
the
sideway
peon
part.
They
just
want
to
do
the
OS
e
gateway
service
between
the
two
domains.
So
right
now
they
have
the
OS
e
gateway
service
model
and
they
also,
but
they
also
have
a
past
service.
B
Very
symbol
of
is
as
d1.
Our
model
is
application
policy,
but
they
just
touched
the
application
SL
a
based,
a
policy,
that's
because
the
because
across
domains
inter
domains
there,
the
need
to
make
the
different
domains
have
the
consistent
policy.
In
that
way,
the
SOA
can
be
guaranteed
across
the
domains.
So
this
is
a
major
difference.
It's
the
OSE
dropped
so
now,
I
think
I
changed.
B
I
am
part
of
the
other
drafts,
sir,
so
we
hope
that
the
disrupter
has
two
components,
so
it
can
easy
be
understandable.
Okay,.
B
And
for
right
now,
I
think
they're
the
drugs
open.
This
issue
may
be
the
first.
We
think
whether
because
right
now
Chow's
it's
already
the
co-author
of
this
draft.
So
we
would
like
to
hear
whether
the
working
groups
think
this
is
enough
for
the
math
working
project
alignment.
So
we
like
to
hear
whether,
because
in
that
way,
we
can
update
the
draft,
so
Charles
can
propose
a
changes
to
the
math
community
to
ask
the
comment
so
I
think
in
this
way
we
can
make
the
a
better
alignment
with
the
two
standard
edition.
B
E
Charles
cycle,
so
you
know,
I
have
been
working
with
within
meth
they're
aware
of
this
work,
that's
going
on
the
one
thing
that
makes
it
a
little
bit
tricky
is,
you
know,
meth
is
more
of
a
closed
membership-based
organization
right.
E
So
a
lot
of
things
that
happen
in
meth
are
by
default
private
to
the
members
and
it's
you
can
make
effort
to
share
things
like
not
just
to
be
a
liaison,
but
there's
other
mechanisms
to
so,
but
the
you
know
so
doing
the
work
within
IETF
and
then
coordinating
back
to
meth
just
makes
things
easier
because
in
IGF
everything's
you
know
open
kind
of
by
default.
So,
in
terms
of
layers
on,
though,
are
working
with
meth.
Are
we
comfortable
with
just
sort
of
this
informal?
E
C
E
It's
not
a
done
deal,
but
one
of
the
things
that
looks
quite
likely
now
is
that
both
will
be
worked
on
within
meth,
because
if
you
look
at
the
overall
meth
architecture,
there's
a
lot
of
the
first
draft
that
we're
doing
now
is
from
a
subscriber
to
a
service
provider.
But
there's
also
within
math
service
provider
of
a
service
provider.
E
Hasn't
gotten
to
that,
yet
it's
not
that
they
don't
plan
on
doing
that,
so
it
would
fit
very
nicely
into
the
Islamic
architecture
and
I
think
methanoic
seemed
to
be
they're
still
discussing,
but
it
seems
more
promising
that
they
will
work
together
on
that
and
perhaps
by
both
being
in
that
to
be
determined.
But.
B
So
I
think
for
the
OS
e
estimate
dropped,
I,
think
in
later
Oh
in
the
future,
we
we
should
align.
The
terminology
of
the
two
drops.
I
will
relieve
the
working
groups
comments
to
to
Steve,
because
he's
not
here
at
this
time
at
IGF,
so
and
I
also
propose
using
like
grouping
statement
on
the
component
model
component
to
allow
reuse
like
the
site,
VPN
application
policy
grouping.
So
in
that
way,
maybe
this
two
dropped
will
not
have
too
much
overlap
with
the
modeling.
A
B
Think
from
the
medallist
Karen
asked
this
question
Steve,
but
Steve's
think
there's
because
they
think
they
rely
on
the
routing
areas.
Expertise
on
the
like
inter-domain,
like
different
options
configuration
so
he
prefers
to
RT
gwg,
but
I
I
I.
Don't
tell
him
further
about.
What's
our
like
this,
our
SD,
one
motto
is
if
it's
will
be
doing
work
here
so
I
like
to
here.
Maybe
we
can
like
a
presentation,
doing
some
presentation
or
getting
comments
from
both
working
group
and
to
work
together.
A
Yeah
I
I
would
like
to
see
personally
see
as
a
chair
more
the
discussion
where,
where
does
it
make
most
sense
for
this
work
to
happen?
Where
do
we
have
the
expertise
because
it
sounds
like
the
coordination
with
the
other
stos
is
useful,
especially
bringing
parties
together
here
at
the
ITF,
but
where
do
we
have
the
most
likely
chance
of
making
this
work?
Successful,
yeah,
okay,.
G
Actually,
for
OSC
Yamamoto
chapter:
actually,
what
is
the
progressing
right
now?
We
didn't
do
too
much
updated
besides
the
terminology
alignment.
So
from
also
point
of
view,
we
don't.
We
don't
have
a
strong
opinion
for
this
charter,
where
we,
which
working
will
be
right
place.
The
duties
reveal
this
to
the
chair
you
to
decide
this.
C
Business
book
donors,
as
divine
itself,
is
not
a
technology
component.
It's
it's
a
mix
of
of
separate
technologies,
bundled
into
something
like
a
product.
An
idea
doesn't
work
on
that
idea.
Works
on
on
specific
sub
components
of
this,
based
on
a
guidance
coming
from,
oh,
not
from
a
from
from
some
other
entities
in
the
industry.
C
The
other
important
aspect
is
that,
even
if
we
are
talking
here
about
a
service
model,
the
service
model
eventually
has
interfaces
to
the
technology
specific
models,
and
that
is
where
the
biggest
gaps
I
at
this
time.
If
we
are
looking
into
the
security
side,
the
situation
of
the
modeling
various
is
quite
a
sad
if
we're
looking
into
route
inside
that
situation
is
quite
good,
but
again
in
order
to
practically
be
able
to
use
this
divine
as
a
service.
Those
components
need
to
combine,
therefore,
and
I'm.
Just
now.
C
Annika
math,
probably
and
IETF
here
in
this
case,
is
an
owner
of
the
youngers
and
modeling
language
and
the
guidance
of
how
that
should
be
done.
The
technology
specific
components
which
are
not
in
scope
of
those
drafts,
which
are
happening
there
are
some
documents
elsewhere,
probably
are
within
the
scope
of
IETF
and
not
an
OPS,
a
WG,
but
in
the
specific
working
groups
focusing
on
a
technology,
routing
tunneling
IP.
Second,
things
like
that:
yeah.
B
C
This
question
is
raised
from
a
practicality
perspective.
Yes,
as
Devon
is
fashionable
buzzword
these
days
and
therefore
it
attracts
attention
an
idea.
The
question
is:
what
ITF
has
sufficient
words
to
say
for
the
community
of
the
users
that,
let's
look
realistically
as
the
run
is
not
being
standardized
in
IETF
and
another
thing,
as
divine
is
not
something
to
standardize.
This
is
a
collection
of
technology
components
and
that
work
is
done
outside
of
idea.
I
think.
D
C
That
is
perfectly
fine
if
this
is
done
in
the
context
that
I
is
source
of
guidance
on
how
to
design
the
thing.
If
we,
if
we
are
certain
that
we
have
enough
of
a
requirements
and
that
model
will
eventually
match
what
they
expect
and
will
be
usable.
Yes,
fine,
let's
do
that.
Otherwise,
if
this
is
a
situation
that
the
IDF
is
trying
to
tell
the
operations
community
on
how
this
should
be
done
on
a
parade
that
probably
it's
not
the
right
way
of
doing.
D
E
Charles
are
called
Neph
70,
the
dock-
that's
already
referenced
here
that
that
is
the
requirements
for
sd-1.
Now,
that's
a
Memphis
decided
that
if
you
made
it
publicly
known
that
they're
doing
a
phased
approach,
there's
already
a
phase
2,
which
is
going
to
add
more
capabilities,
kind
of
more
details
into
the
requirements
and
the
specification
of
the
service
there's
almost
certainly
going
to
be
a
phase
3
rather
than
wait
and
try
to
get
everything
MF
wanted
to
bring
this
to.
E
You
know
to
mark
it
and
make
it
public
as
soon
as
possible,
so
they've
decided
to
take
a
phased
approach,
so
these
requirements
are
going
to
continue
to
expand
I
guess
so
what
our
current
approach
was
yeah,
let's
just
reference
the
publicly
available
specifications
and
make
it
an
IETF
draft.
Otherwise
we
could
do
the
yang
modeling
work
within
meth,
but
then
we
would
just
really
rely
on
IETF
expertise
to
not
only
review
and
comment
on
it.
E
That'd
help
us
maintain
alignment
so
that
people
that
try
to
use
the
meth
service
models
and
tie
it
to
you,
know
the
technology
and
the
underlays
that
are
actually
used
that
that
that
could
be
a
straightforward
type
of
thing.
So
you
know
method
need
help
with
that,
because
what
I've
seen
with
meth
models
in
the
past
is
they
kind
of
sit
out
on
their
own
and
it's
hard
to
figure
out
how
to
make
use
of
any
ITF
models
in
combination
with
them.
Yeah.
E
Needs
to
happen,
but
how
best
to
do
that?
Whether
to
do
the
yang
models
here
or
in
that
fight?
I,
honestly,
don't
know.
I
just
want
to
try
to
give
the
two
groups
to
cooperate
more
and-
and
the
one
thing
that
makes
me
think
ITF
is
better.
Is
that
working
on
these
things
in
the
open
in
ietf
again
is
the
default,
whereas
in
meth
I've
been
trying
to
make
meth
more
open
and
put
out
early
versions
of
things
and
it's
possible
to
do
that.
E
C
And
well,
this
is
one
of
the
worrying
aspects
from
eyesight
Charles,
you
say
periodically.
Does
this
mean
that
this
this
set
of
drafts
right
now
or
focuses
on
phase
one
and
nothing
more
and
once
they
have
the
required
if
you
are
working
on
the
requirements
for
phase
two,
that
will
be
a
set
separate
model
and
not
just
iterative.
The
endless
work
on
this
model
here.
E
Yes,
so,
as
I
mentioned,
there
is
already
a
phase
to
document
it's
going
to
be
MEF
71,
it's
already
started
and
they're
almost
certainly
BMF
72,
that's
just
the
way
meth
rather
than
du
bist
versions.
That's
the
way
math!
Does
it
only
this
time
they
intentionally
said
specify
just
you
know:
I
can
MVP
type
of
thing
for
SD
land.
That's
enough
70,
knowing
up
front
that
they
would
immediately
start
am
f
70.1
and
that's
the
way
they're
working
on
this
so
it'll
continue
to
add
additional
SD.
E
When
related,
you
know
service
functionality
into
it,
not
only
that,
but
to
start
to
work
on
other
interfaces.
Just
this
is
just
one
interface
as
image,
and
this
is
the
interface
between
a
customer
and
of
subscriber
right.
There
are
gonna,
be
sorry.
A
customer
and
the
service
provider,
though,
will
be
interfaces
for
service
provider,
the
service
provider
and
then
also
north/south
interfaces
within
a
service
provider
where
hopefully,
we'll
be
able
to
leverage
a
lot
of
ITF
existing
yang
models.
E
G
You
allow
a
chance
to
add
to
something
here,
actually,
I
think
that
the
collaboration
between
Amy
and
I
idea
should
be
encouraging.
We're
already,
you
know,
do
this
besides
the
Charles
look
at
in
BO,
and
we
also
have
our
colleague
on
in
that
number
actually
get
engaging
this
sty
activity
in
amiable,
happy
to
coordinated
between
a
Mia
and
I
have
an
iconic.
The
new,
also,
you
know,
came
to
check
out
this
Mei
progress
to
make
sure
online,
so
I
think
it
also.
We
also
hear
there's
some
requests
from
Mei.
G
They
really
want
to
see
how
to
map.
You
know
services.
There
were
technicians
with
online
technology,
so
they
look
into
some
phone
interface
of
box
trailers,
so
they
trying
to
you
know
want
to
get
help
from
the
ITF.
So
so
that's
why
we
see
if
this
is
something
we
should
you
know
giving
to
clever
ways.
Muf.
Thank
you.
A
Thanks
we're
gonna
have
to
take
I
think
we
should
keep.
Having
have
this
discussion
and
ask
the
pointed
question
on
the
list,
because
we
are
running
out
of
time
as
to
what
what
is
this
work
interesting
here
and
I'll
I'll
take
an
action
to
start
that
discussion
on
list,
so
we
can
capture
some
more
of
these
comments.
H
A
A
A
A
F
F
F
So
I'm
gonna
do
a
presentation
today
of
the
layer,
3
VPN
network
model
that
we
submitted
the
first
person
in
May
and
recently
we
submitted
a
second
version.
It
is
an
initiative
by
a
bunch
of
operators
who
we
are
trying
to.
We
were
trying
to
implement
the
automation
of
layer,
3
VPN,
and
we
took
as
a
starting
point
the
layer,
3
SM,
and
we
found
some
things
to
implement.
So
this
is
why
we
were
pushing
for
this
network
model.
So
next
slide,
please
so
we're
gonna
see.
Why
do
we
need
a
new
network
model?
F
What
have
we
found
missing
so
far
in
the
threesome,
which
are
the
approaches
that
we
can
follow
to
do
this
work?
Some
modifications,
I
think
I,
don't
mind
not
gonna
enter
into
the
modifications
really
in
detail.
You
have
the
draft
and
the
document
and
the
young
model
to
go
through
them
if
needed
and
just
focus
on
the
open
issues
and
get
more
feedback
from
the
community.
So
next
slide.
Please.
F
Yeah,
so,
first
of
all,
why
do
we
need
a
new
model?
Ok,
so
there
is
currently
an
VPN
service
model,
the
l3
SM
and
it's
a
very
good
model,
and
we
do
think
that
it
is
a
good
model
to
be
used
in
the
communication
between
the
customer
and
the
network
operator.
So
we
believe
that
for
that
kind
of
communication,
it's
it's
ideal.
Ok,
however,
as
it
is
always
seen
from
the
customer
point
of
view,
a
it
does
not
enter
and
it
should
not
enter
into
some
parameterization
of
the
network.
F
Resources
also
does
not
enter
into,
for
example,
identifying
really
the
PE
or
the
real
port
that
we
are
using
in
the
in
the
operators
network.
So
this
is
why,
when
implementing
it
to
be
used
to
what
our
automation
tools
call
it,
some
people
call
it
as
being
controllers
and
people
call
it
network
restriction.
There
are
several
ways
of
using
it
in
the
just
in
yesterday's
presentation
in
Ratan
trillion
working
group,
we
explain
the
different
architectural
options
or
how
this
model
will
fit
in
the
different
architectural
lectures.
F
But
basically
this
is
the
or
this
model
would
be
the
peace
between
the
service,
orchestration
and
then
network
restoration,
part
okay.
So
it's
once
you
have
received.
The
drink
was
from
the
customer
and
then
you
are
able
to
do
select,
which
are
the
real
impose
from
where
the
service
is
gonna
be
used,
and
it
you
need
to
define
resources.
Then
model
is
used
for
that
part.
Okay,
and
this
is
where
we
are
implementing
it
in
in
telefónica
and
also
other
operators
plan
to
implement
it
in
that
part.
F
Okay,
so
please
Nessus
light
please
so
here,
I'm
gonna
just
describe
very
briefly
some
scenarios
where
the
there
were
some
gaps
with
l3
SM.
So,
for
example,
one
of
them
is
the
specific
P
identification
points.
Also
details
about
the
bidders.
We
think
that
the
keys
are
the
the
bidder
that
are
the
physical
connections
to
the
to
the
piece
so
specify,
which
is
the
encapsulation.
F
So
in
our
use
cases
we
have
a
wide
variety
of
l3
VPN,
starting
with
different
kinds
of
encapsulations,
so
we
also
need
to
be
able
to
inform
about
which
are
the
list
of
available
beers
per
site.
So
for
us,
even
for
both
for
inventory
and
for
medicine
purposes,
it
is,
it
is
needed.
Also.
We
have
found
use
cases
in
our
network
where
the
trend.
I
F
Remote,
so
when
acid
water
stitching
the
l3
VPN
also,
we
need
to
cover
a
use
case
with
it,
so
that
is,
we
need
to
split
layer,
3
VPN,
into
several
domains.
You
know
when
orchestrate
his
resources
in
different
domains
and
also
related
to
his
multi-domain,
be
able
to
configure
what
we
call
the
VPN
nodes,
which
would
be
like
an
abstraction
of
the
of
the
BRF
so
just
take
into
cannot
here
we
are
adding
two
device
conflation.
F
Knife
so
I
just
want
to
discuss
one
of
them,
which
is
that
so
we
had
our
original
approaching
the
zero
zero
version
was
okay.
Go
for
the
augment
approach.
Okay,
let's
take
the
three
same,
an
extended
to
with
what
were
off.
We
found
missing.
Okay,
then
we
realize
that
there
are
a
lot
of
things
from
the
sir
is
modeled.
The
customer
service
model
that
we
no
longer
need.
They
were
used
in
the
service
orchestration
face
to
make
them
some
decisions,
and
then
okay
once
not
made,
we
don't.
We
don't
need
them.
F
So
then
we
think
that
this
is
a
better
and
when
we
requested
for
feedback
in
the
main
in
this
people
said:
okay,
the
prune
honest
approach
might
be
better,
so
is
okay,
I
start
with
and
3sm
remove.
What
is
not
needed.
Keep
everything
related
to
the
service
that
we
need
to
maintain
it
to
to
pull
down
and
then
augment
whatever
is
is
needed.
We
know
that
this
might
take
a
long
time.
F
This
might
take
more
discussions
in
IETF
that
every
SM
was
even
now
working
group
itself
or
whether
it
might
have
some
family
thing
as
the
kind
of
augmentations
and
won't
be
hopefully
not
too
much
I.
Think
we
can.
This
is
a
button
approach.
Just
in
the
image
we
need
to
define
what
what
do
we
need
to
keep
yesterday
there
were
some
suggestion
of
keeping
some
information
just
as
optional,
not
mandatory
to
who
sit
down
okay.
So
this
is
light
please
so
with
the
pronoun
next
and
approach
we
can.
F
I
F
So
how
does
it
up
to
the
network
deployment
so
basically
with
having
a
net
worth
of
call
as
a
collection
of
bees
and
in
that
collection
of
pieces?
Well,
we
will
say:
ok
and
we'll:
ask
the
PPS
node
yes,
and
the
bidders
will
be
the
physical
ports
that
connect
to
the
piece,
and
these
builders
can
have
a
several
connections
over
day
and
these
connections
to
the
to
the
side
to
the
customers
are
at
the
side
network
access.
So
this
is
how
it
relates
of
Icarus.
This
sim
or.
F
The
connection
between
the
customer
side
and
the
he
goes
to
a
set
of
switches
and
what
you
do
is
some
different
levels
of
encapsulation
or,
as
we
mention
earlier,
it's
a
silly
wire
to
the
ultimate.
Basically,
this
is
a
the
main,
the
main
concepts.
Ok,
so
just
we
keep
the
site
as
a
logical
structure
say:
ok,
this
is
our
some
remote
location
will
be
connected
here.
So.
F
So
this
is
where
we
can
put
the
resources
so,
for
example,
the
artists
artists.
So,
for
example,
we
have
observed
in
many
services
in
telefónica
that
the
same
RTR
D
is
used
in
all
the
locations.
So
then
we
can.
We
can
put
it
here
in
this
profile
and
associated
to
a
VPN.
No,
so
then
we
do
this
a
location
on
the
on
the
USS
level
and
we
pass
it
today
to
the
model,
and
then
this
is
in
further
taking
down
to
that
otherwise
model.
F
Also,
for
example,
in
the
in
the
side,
what
we
have
for
the
facade
is
the
the
bitter.
So
this
is
the
list
of
bitter
that
are
associated
to
that
side.
Okay,
so
for
some
before
that,
for
some
customer
okay,
you
are
using
this
specific
bitter
and
in
the
Senate,
were
actually
have
the
pointer
to
that
bitter
okay.
So
if
you
go
to
next
slide,
please
just
gonna
go
very
quickly.
F
Next
slide,
please!
Okay!
So
here
in
India
top,
we
have
a
least
most
open
issues
that
people
have
identified
in
the
many.
So
we
have
it
open
it
as
an
issue
in
github
just
to
be
able
to
to
track
it,
and
now
we
have
already
solved
two
of
the
history
issues
and
we
still
have
some
some
open
open
points
so,
for
example,
how
to
link
the
network
service
young
model
with
other
modules,
for
example,
the
topology
I
am
assuming
that
the
net
water
orchestration
London
will
controller,
can
expose
a
topology
and
this
topology.
F
It
contains
the
PE.
So
maybe
it's
easier
that
we
can
just
do
a
live
reef
from
the
network
service
model
to
those
nodes
in
the
topology
for
traffic
engineering.
The
result
Radian
initiative
in
in
TS
to
map
the
service
to
the
to
the
set
of
tunnels
that
might
composite
so
I.
Think
if
we
go
for
this
approach,
we
need
to
link
with
that
work
and
also
the
composed
opinion,
which
goes
for
more
complex
multi
operator,
VPN
scenarios.
F
F
Have
their
implementations
of
going
of
this
model,
so
we
can
take
it
to
to
the
network.
So
we
think
that
this
is
a
topic
that
it
is
in
the
scope
of
the
ITF
and
we'd
like
to
continue
working
on
it
and
we
plan
to
post
a
new
version
just
soon
just
fixing
some
some
bugs
and
keep
collecting
more
and
I
would
like
to
hear
also
from
from
you
how
to
move
forward
these
this
work
and
it's
interesting
for
the
community.
So
thank
you
very
much.
K
Ios
card
assists,
but
not
less.
So
thanks
for
his
work,
it's
always
great.
When
ever
we
have
operators
coming
in
finding
feedback
on
the
service
models,
and
yes,
sometimes
our
iteration,
on
service
models.
So
my
only
question
is
so
those
were
also
operators
who
came
and
getting
a
service
model,
the
first
one,
and
they
were
also
from
orange
and
kdi
and
Verizon.
If
you
get
their
feedback
on
what
you're
proposing
here
a
yes.
F
I
got
the
feedback
is
what
that
the
imitation
who
was
aimed
at
creating
the
service
for
the
customer
of
the
from
the
customer
point
of
view,
so
so
I
think
their
focus
was
not
exactly
they
say
as
as
the
model,
so
it
was
like
in
a
higher
level.
So
I
think
that
the
uses
of
these
models
are
at
different
steps
in
the
chain
within
an
operator.
F
K
A
Substantial
number
of
hands
went
up,
okay,
III
think
Oscar.
You
had
a
you.
You
gave
yourself
an
action
item
to
update
you.
You're
gonna
update
this
draft
with
some
of
the
open
issues.
I
was
looking
at
your
github.
You've
got
a
few
of
them.
There
I
think
do
that,
and
then
we
can
decide
to
progress
this
for
it.
It
sounds
like
there's
enough
interest
in
the
working
group
here
and
we'll
double-check
on
the
list
to
keep
this
work
moving
forward,
an
ops,
AWG,
okay,.
A
A
G
Good
morning,
everyone,
this
is
Hugh
I'm
here
to
discuss
the
framework
for
automated
service
and
network
management.
We
see
young
actually
these
topical.
Actually,
we
set
up
the
side
meeting
to
discuss
this,
so
we
will
bring
some
feedback,
so
this
is
also
loose.
We
actually
work
together
with
the
many
operator
on
these
workers,
so
go
back
to
the
goal
and
motivation.
We
sink.
Rino
ITF
developer
huge
amount
of
young
data
model
how
this
model
can
put
it
together,
integrate
together
in
the
same
namespace.
G
How
do
you
you
know
to
to
to
put
a
young
model
at
a
different
layer
together
to
deliver
a
service
and
also
for
its
kind
of
service
in
enforcement,
but
the
we
cannot
boil
the
ocean
so
really
this
work,
actually,
you
know
focuses
on
the
young
Taylor
motor
integration
at
a
different
layer
or
in
the
same
layer
so
somehow
work.
Actually,
we
already
have
some
many
needed
caching
or
we
get
a
feedback
from
some
operator.
We
single,
we
want
to.
G
You
know,
know
to
put
everything
in
this
draft
so
first
up,
actually
whether
we
should
list
all
the
llamado
divine
idea
for
in
this
job.
Actually,
that's
not
our
intention,
because
it's
a
it's
very
challenge.
We
in
memory
all
these
young
data
model,
also,
maybe
we
have
as
a
yamaraja
beverage
in
other
SQ.
How
to
you
know,
put
all
these
together.
So
it's
not
a
reasonable,
so
we
don't
cover
first
piece,
second
years
to
any
need
to
pry
inventory
of
the
tools
or
mechanism.
G
Actually,
one
of
the
example
is
we
have
many
OM
tools
or
mechanism,
and
but
we
think
this
is
not
the
folk
of
this
worker.
This
book
just
focus
on
Youngjae
the
model
in
equation.
I,
think
a
tool
chain
is
very
important,
but
we
can
leave
this
out
and
and
to
more
focus
on
the
younger
the
motor
integration.
G
Also,
you
know
in
a
society,
meaning
we
really
want
to
address
use
kept
kept
up
between
ITF,
Yamamoto
and
operator
really
operate
the
requirements
actually,
but
we
think
put
this
kind
of
gap.
Adoption
in
this
job
also
not
a
reasonable,
so
we
DVDs
out
and
another
comments
actually
from
operators
ease.
We
talk
about
whether
we
can
provide
young
Vinney
motor
registration.
We
single
already
I,
do
have
young
catalog
effort.
G
They
actually
can
help
operator
to
figure
out
how
to
select
the
model
when
they
deploy
the
service,
so
young
catalog
can
be
a
good
tours
to
actually
has
these
kind
of
issue.
So
we've
this
out
also
because
young
to
the
model,
you
know
many
as
thought
use
is
so
increasing
model
in
across
the
SDO.
Actually,
this
is
something
very
useful.
I
I
think
the
weight
on
one
companies
so
status
update.
Actually
we
present
this
job
in
the
last
idea
here.
G
Meeting
him
in
of
office
area
and
rotting
area
and
a
solitary
feedback
from
the
operator
and
implementer,
and
we
actually
based
on
OBS
double-teaming
in,
is
discussing
actually
some
commentaries
by
the
show
and
and
some
other
vendors,
and
we
try
to
address
some
of
the
the
issue
actually
so,
when
maker
actually
to
revision
in
them.
In
a
previous
revision,
there
were
four.
G
Actually
we
charge
your
chairs,
that
your
comms
and
other
vendors
comments
and
to
try
to
clarify
the
module
position
and
a
young
catalog,
and
also
we
actually
work
which
out
of
the
operator
team,
actually
get
a
lot
of
feedback,
the
all
of
them.
Actually
many
of
them
actually
integrate
interesting
in
how
to
integrate
a
young
data
model
in
a
same
namespace.
G
So
so
we
added
several
new
car
car,
sir,
actually
from
from
operator
actually-
and
we
also,
you
know,
clarify
the
scope
who
tried
to
make
it
more
focused
yeah,
that's
the
change
we
made
and
a
quick
rapid
data
for
the
side
meeting.
Actually,
they
started
meeting
actually
organized
on
Tuesday
morning
and
and
and
we
invited
many
orbiter.
Also,
we
socialize
this
sunny
meeting
through
the
man
in
East
and
we
make
it
a
public
on
the
side.
Meeting.
Wake
up,
Asia
make
it
official.
G
Try
to
address
this
gap,
how
to
do
the
younger
model
integration,
and
so
we,
you
know,
work
with
china,
mobile
and
also
telephony
car
and
for
these
represent
a
young
lady
motor
frame,
walker
and
also
China
Mobile
presented
the
promised
space
and
the
Colonel's
were
young,
they
the
model
and
and
telephony
campus
and
their
use
case
and
requirements.
So
we
get
a
lot
of
discussion,
and
so
here
we
listed
the
meeting
Matt
here
in
a
minute,
so
you
can
take
a
look
at
that,
so
the
outcome.
Actually
we
we
feel.
G
Actually
you
know
people
agreed,
that's
there's
a
game.
Actually
these
guys
need
to
be
addressed
and
so
there's
a
many
way
to
Jerry's.
So
we
are
actually
approach
it
ad
to
talk
about
that.
It
doesn't
actually,
we
have
many
propose
own.
I
thinkin
we
may
create
the
many
mister
to
sorta,
see
the
feedback
from
operator
chameleon
also
from
the
implementer
or
developer.
Also
for
this
kind
of
young
day,
the
model
integration
framework
is
very
useful
towards
and
also
we
we
should
actually
to
figure
out
how
to
reach
out
at
a
real
community
with
many
ways.
G
G
A
Action
comments
on
on
this
draft,
so
personally
more
is
I,
guess
a
contributor
I
still
I
saw
your
out
of
scope
when
I
read
through
it
there
still
you
you
list
a
lot
of
the
the
ietf
yang
modules,
how
they
fit
together.
What
the
capabilities
currently
are
I'm,
not
sure
how
they,
how
that
structure
currently
gets
to
some
of
the
the
questions
and
the
gaps.
A
G
A
single
there's,
a
man
in
discussing
this
issue,
for
we
listed
many
younger
model
at
a
different
level,
so
which
I
do
address
these,
that
we
think
it
will
be
useful
use,
ITA
motor,
as
example,
to
to
see
how
this
model
can
put
together
like
actually,
some
people
may
such
as
move
to
the
appendix,
but
we
still
single,
maybe
there's
some-
you
know
we
can,
you
know,
make
it
more.
Generic
doesn't
need
to
know
type
to
specify
et
I
define
a
model.
G
L
Such
information
is
handy
and
explaining
the
lifecycle
and
stuff
and
I
think
that's
the
after
what
them
back
then,
which
is
talking
RT
gwg,
was
also
getting
to
yesterday,
whether
there
should
be
any
specifics
about
particular
models
and
how
they
interact
written
into
a
draft
that
I'm
not
so
sure
about,
because
I
think
that
stuff
probably
needs
to
evolve
quite
quickly
and
by
the
time
you
go
through.
The
specification
process
is
not
so
useful.
L
I
think
that
almost
there
needs
to
be
on
github
somewhere
or
something
that
that's
the
place
where
I
think
the
sort
of
running
code
side
of
this,
which
is
why
I
regard
that
the
relationship
between
those
models
is
probably
more
useful.
Maybe
so
no
there's
not
a
comment
on
this
draft,
but
I
I
would
see
trying
to
describe
the
abstract
architecture
as
being
the
key
piece
for
me.
M
From
China
Mobile
I
think
there
are
more
coordination
work
than
technical
work,
but
for
these
thoughts
of
young
model
status
and
I
think
it's
quite
useful
to
have
a
framework
as
a
guideline.
If
that
can
help,
operators
understand
more
what
model
has
been
developing?
What
working
group
in
such
a
status
so
that
the
operator
can
give
more
feedback
to
the
community?
L
G
Know
just
the
way
information
when
I
see.
Actually
we
also,
you
know,
receive
a
lot
of
positive
feedback
from
many
operators
in
this
idea
meeting.
When
people
really
really
know
the
donor
realities,
talk
about
the
journal.
Sorry
beam
energy
gave
a
lot
o
coulibaly
singer.
This
kind
of
framework
is
needed
to
have
them
to
deploy
the
service,
so
I
I
think
you
use
what
you
have.
This
I
think.
A
N
What
I
believe
would
be
useful
is
to
break
this
thing
up
and
maybe
initially
focus
on
one
two,
three
initial
use
cases
where
you
really
do
the
mapping
exercise
and
really
nail
it
to
the
detail,
and
once
you
have
that
learning
experience,
then
you
can
go
and
up
level
that
into
something
that
is
more
generic.
If
we're
trying
to
do
both
things
at
the
very
same
time,
it
might
be
that
we're
doing
disservice
to
the
generic
framework.
N
As
to
the
thing
that
you
don't
really
spell
out
to
the
level
of
detail
where
it
becomes
actionable
and
implementable,
because
the
devil
with
this
mapping
exercises
in
detail,
there's
multiple
layers
of
indirection
and
you
can
get
it
wrong
at
every
single
layer
of
indirection
and
then
most
of
these
layers
of
indirection
are
non-deterministic
from
an
implementation
perspective.
Necessarily
right.
So
what
do
you
choose,
which
particular
counters?
C
Business
with
Donna's
framework
is
good
and
is
needed,
but
you
cannot
deploy
a
framework.
You
also
need
a
set
of
validated
modules
that
actually
work
together
and
do
something
of
value
to
the
operations
framework
is
a
guidance,
but
that
guidance
should
also
drive
the
work
of
actually
validating
the
things
together.
C
A
J
All
right,
so,
let's
see
here
the
first
thing
we'll
talk
about
is
the
mud,
controller
selection
and
then
we'll
get
into
mud
reporting
all
right.
So
just
by
way
of
review
when,
when
a
device,
when
a
device
wants
to
be
protected
by
manufacturer
usage
descriptions,
it
publishes
a
mud
URL,
the
Met
manager
picks
up
a
mud
file
and
that
mud
file
contains
a
bunch
of
access
control
statements.
Those
access
control
statements
can
say
things
like
allow
me
to
connect
to
a
controller
or
my
controller.
J
Now
it
could
also
say
things
like.
Let
me
go
to
this
domain.
Let
me
talk
to
same
manufacturer
most
the
other
abstraction
Zoar
classes.
They
can
be
filled
in
automatically
by
the
mud
manager,
but
the
controller
class
and
my
controller
class
requires
at
least
at
the
moment.
Some
system
ended
traitor
network
administrator
input.
J
Well,
the
network
administrator
might
want
some
help
in
answering
the
question.
Who
should
be
the
controller
for
this
particular
device?
There
are
two
different
classes:
there's
my
controller
and
there's
controller.
My
controller
is
that
does
not
require
there
any
class
naming
on
the
part
of
the
manufacturer.
Just
says
for
this:
given
Mudd
URL,
the
might
of
my
controller
should
I
should
have
access
to
my
controller
in
the
administration.
Administrator
can
fill
in
that
for
controller,
they
name
a
class,
the
benefit
of
naming
the
classes.
You
can
use
that
across
many
different
device
types.
J
So
that's
what
this
draft
starts
to
to
flesh
out
it's?
This
is
for
the
controller.
You
know
this
is
a
controller
driven
approach,
that
is
to
say,
the
controller
is
declare.
I
can
be
a
controller
for
a
particular
type
of
device
on
the
controllers
themselves
are
assumed
to
have
mud
files
in
this
context,
and
that
means,
by
the
way,
at
least
at
the
moment,
that
they're
assumed
to
have
a
single
purpose.
J
They
they
can
use
an
extension
to
declare
this,
which
basically
names
the
classes
that
they
can
control
and
this
up
to
the
admin
to
decide
whether
or
not
they
like
the
idea
of
this
controller
having
access
for
this
purpose.
So
that's
pretty
much
the
draft
in
a
nutshell,
and
so
this
is
how
it
works.
I
can
clean
this
guy
says:
I
can
control
class
brand
on
example.com,
slash
home
owner,
and
these
guys
all
say,
forgive
me
they
all
put
in
their
things,
essentially
a
permit
statement,
as
I
said.
J
Let
me
access
this
thing,
so
you
have
a
nice
rendezvous
and
so
that's
this
is
a
something
that
we
wanted
to
get
around
to
in
the
initial
version,
it
was
probably
just
a
bit
much
for
the
initial
version
of
mud.
It's
just
nice
extension
that
ties
a
nice
bow
around
the
automation
process.
Here
now
there
are
a
couple
of
open
questions.
Ok,
the
first
one
is
that
the
roll
itself,
as
I
mentioned,
has
to
have
a
mud
file
in
mud.
You
are
Ella,
meaning
that
the
controller
itself
is
not
an
application.
J
There's
something
we'd
like
to
fix,
but
at
least
on
the
mud
list
and
I
think
we
this
even
got
to
the
opt
area
working
group
list.
This
is
still
a
pretty
hard
problem.
The
second
point
is
that
manufacturers
may
want
to
advertise
which
devices
can
fill
in
these
classes.
From
their
sites,
so,
if
I
go
back
to
this
picture
here
it
rather
than
having
this
guy
say,
I
can
control
these
guys
in
its
class.
J
The
other
way
to
do
this
is
to
say
these
guys
can
say
here
are
a
list
of
controllers
that
can
control
me
now.
I
can't
say
quite
quite
yet,
which
one's
the
better
approach
to
do.
This
I
think
we
need
a
little
implementations
experience.
We
need
to
talk
to
some
manufacturers.
It
could
be
that
both
of
the
right
approach,
one
area
I
want
to
explore-
is
whether
we
can
get
the
model
right
such
that
it
can
be
used
in
either
case.
J
J
When
you
do
it
from
the
controller
side,
it's
really
easy,
I
think
Rangga.
There
could
probably
do
it
in
20
minutes
with
with
his
headphones
on,
and
to
give
you
an
idea,
I
mean
I.
Think
it's
very
easy
to
implement,
and
but
the
only
issue
is
you
have
to
have
some
UI
elements
in
there
as
well
to
say
yes,
these
are
the
things
and
sort
of
a
drop-down.
J
Here
are
the
guys
who
are
able
to
be
controllers
for
this
device
in
some
cases,
if
you're,
the
only
control
you
might
just
want
to
fill
it
in
and
say,
I
see
this
guy
is
that?
Okay,
when
you
do
the
initial
approval,
all
right,
so
is
there
interest
in
this
work
anybody
people.
J
O
O
Controller
works
with
a
with
an
agent.
We
had
the
same
thing
in
some
other
places
that
that
I
was
actually
looking
at
this
work
to
see.
If,
if
it
made
sense
to
extend
the
other
work
that
had
controllers
in
agents
for
IOT
and
other
management
of
devices
in
to
utilize,
the
mud
and
incorporate
it.
But
I
didn't
have
the
framework
elements
that
that
I,
that
I
could
really
understand.
O
I
could
infirm,
but
I
didn't
see,
and
so
I
was
just
wondering
if
there's
a
if
we're
gonna
move
this
from
a
URL
to
do
two
more
systemic.
That
elements
is
there.
Is
there
something
that
we
need
to
produce
for
the
industry
to
I
understand
what
what
all
they
had
components?
Mud
is
and
how
they
interact.
Alright,.
J
Thank
you
for
the
question.
I'm
gonna
respond
briefly
for
for
time
sake.
If
you
look
at
the
history
actually
of
the
RFC,
if
you
go
back
into
the
tracker,
there
was
a
framework
document
and
we
collapsed
everything
into
that
that
mud
drop
of
that
mud,
RFC
the
mud
consists
of
what
I
would
say
are
three
components:
really:
the
URL
the
description
file
and
the
the
its
interpretation
at
the
mud
manager
level.
J
What
I
would
suggest
is
we
have
an
offline
conversation,
though
about
whether
additional
guidance
is
needed
for
industry
I'm,
always
happy
I
blather
on
I'm
always
happy
to
provide
whatever
guidance
we
think
industry
needs
in
order
to
implement
this
and
from
a
systemic
view,
I
was
hoping
that
we
have
a
reasonably
systemic
view
in
that
document.
If
you're
saying
that
we're
missing,
then
I'd
like
to
correct
yeah.
O
It's
just
that
as
we're
as
it
seems
like
we're,
extending
things
just
trying
to
understand
what
the
responsibilities
of
the
various
components
are
right.
You
know,
I
think
that
was
kind
of
missing
other
than
some
short
descriptions
in
the
initial
RFC
all
right.
Let
me
come
back
to
that,
because
I
have
a
question
later
on
in
the.
G
I
said
I
think
a
second
team's
opening
actually
I,
don't
see
the
whole
picture
how
these
out
he
divides.
You
know
what
is
the
life
cycle,
the
whole
IOT
device,
the
management
we
may
mean
some
framework
or
two
to
see
how
how
it
works
mad
mad
at
fit
in
you.
This
framework
is
not
a
very
clear
to
me,
but
I.
J
Your
draft,
that
is
to
say,
please,
write
one
okay,
so
the
next
thing
is
a
little
different.
This
is
work
that
Rangga
from
NIST
and
I
are
working
on,
and
this
was
in
response
to
some
industry
interest.
They
say
well,
okay,
great
I.
Have
my
mud
file.
I
have
I,
have
my
mud,
URL
output?
How
do
I
know
that
the
device
is
being
treated
appropriately
within
a
given
network?
J
Now,
if
the
title
of
this
as
reporting
on
fails,
it
could
also
be
reporting
on
successes.
I
just
want
to
highlight
that.
Might
you
know
I
tend
to
be
a
bit
of
a
pathologist,
so
I
always
look
at
the
fails
in
my
head.
So
the
problem
statement
is
here:
it
is
exactly
what
you
see
there,
which
is
what
happened
for
at
least
in
my
mind.
J
What
happened
if
the
device
isn't
getting
the
access
that
it
needs,
even
though
it's
putting
out
the
mud,
URL
and
a
mud
manager
is
interpreting
it
all
right
now,
so
we
have
an
initial
version
of
a
draft
which
is
draft
Lior,
ops
area
group
mud
reporter.
So
imagine,
roughly
speaking,
what's
reported
is
a
think
of
ARF.
You
got
Murray
in
the
back
of
the
room
there
all
the
way
in
the
back.
Actually,
who
did
this
thing
called
ARF,
which
is
a
reporting
mechanism
on
how
Demark
is
being
used,
for
instance,
to
reject
or
quarantine
email?
J
The
same
sort
of
concept
applies
with
mud,
you've
deployed
this
mud.
Url,
you
put
deployed
this
device
now.
What
happens
you
know?
Is
it
is
it
acting?
It
is,
is
it
being
used
appropriately?
Is
the
device
getting
the
access
it
needs
and
within
a
deployment?
If
you
have
multiple,
multiple
devices
are
some
of
them
getting
the
access
they
need
are
some
of
them
not
getting
the
access
they
need,
and
what
information
does
the
manufacturer
need
in
order
to
determine
a
couple
of
questions?
What
are
those
questions?
J
J
The
network
management
system
is
operating
exactly
as
it
should
be
operating,
but
the
device
has
been
hacked
and
is
trying
to
go
in
different
directions
which,
by
the
way
is
one
of
the
design
goals
of
mud
is
to
actually
spot
that
is
there
a
problem
with
the
mud
manager
where
it's
not
filling
out
the
abstractions
correctly?
Is
it
a
problem
with
say,
domain
lookups?
J
If
you
have,
if
you're
saying
please
permit
access
to
domain
such
and
such
is
the
resolution
occurring
such
differently
between
the
device
and
the
policy
enforcement
point
such
that
the
device
is
being
blocked,
even
though
the
domain
maps
to
a
particular
to
that
IP
address,
see,
there's
some
of
the
problems
that
you
could
crop
up
in
a
model
implementation,
so
our
model
needs
to
support
a
little
bit
of
this.
Now.
This
is
an
initial
draft.
Give
you
an
idea
how
initial,
just
in
the
span
of
four
days,
Rangga
went
and
implemented
about
80%
of
it.
J
Actually,
he
meant
implemented
about
80%
of
it
in
two
days
and
in
those
in
those
two
days.
Probably
the
draft
has
changed
about
20%
in
terms
the
model,
so
maybe
even
a
little
bit
more,
so
it's
really
really
actively
being
developed,
but
it
also
leads
to
a
couple
of
questions
right,
and
the
biggest
issue
I
want
to
highlight
is
that
there
are
privacy
concerns
here.
So
the
mod
manager
starts
reporting
this
stuff.
Let's
say
it's
reporting
it
to
the
manufacturer.
J
All
of
a
sudden,
you
know
what
information
is
the
manufacturing
is
the
manufacturer
getting
that
here
that
they
otherwise
wouldn't
get,
and
is
that
something
can
we
establish
an
appropriate
permissions
model
such
that
this
reporting
model
is
actually
useful?
So
this
is
the
part
where
I
say,
run
pay
attention
because
you're
very
focused
on
privacy
issues.
This
is
where
we
need
a
lot
of
guidance.
We
might
want
to
bring
this
draft
to
perd,
for
instance,
for
some
advice
as
to
how
we
can
have
an
appropriate
permissions
model
that
that
that
succeeds.
J
You
know
the
manufacturer
might
learn
some
operational
state
in
the
locale.
The
locale
might
be
linkable
on.
There
may
be
devices
where
you
definitely
don't
want
to
do
this
for
wear
where
you
might
not
want
to
leak
the
link,
the
leak,
the
location
of
what
you're
doing,
for
instance.
So
we
need
to
think
a
little
bit
about
this
and
some
of
this
information
leaks,
naturally
with
mud
already
just
by
retrieving
a
mud
URL.
J
A
J
So
look
we
have
some
nice
heated
debates
at
the
IETF
I'm,
pretty
sure
we
can
have
a
couple
on
this.
One
I
think
it's
really
interesting
work,
but
it
needs
a
lot
of
eyes
to
get
it
just
right.
I
don't
want
a
fast
roll
I.
Don't
want
to
speed
through
this
draft,
but
I
suggest
that
the
best
way
for
this
draft
to
be
the
best
it
can
be
is
for
two
things
to
happen.
Number
one.
We
need
manufacturers
to
look
at
it
to
make
sure
they're
going
to
get
what
they
want
out
of
it.
J
Number
two
is
that
the
IETF
this
will
require
substantial
area
review
in
order
to
really
be
the
right
thing
that
comes
out.
Finally,
one
last
point,
which
is
whatever
the
manufacturers
want
to
see
the
deployment
will
want
to
see
more.
That
is
to
say
you
know,
is,
is
my
own
deployment
working
appropriately,
and
so
we
probably
want
the
draft
to
accommodate
that
use
case
as
well,
and
in
that
context
one
of
the
questions
we
will
have-
and
there
are
privacy
issues
related
to
this,
as
well
as
who
is
the
mud
manager
in
the
enterprise.
J
This
is
an
easy
case.
It's
going
to
be
something
adjunct
to
triple-a
infrastructure
for
an
example,
but
in
the
home
it's
a
different
kettle
of
fish.
Is
the
mud
manager
going
to
be
Google,
it's
going
to
be
Amazon?
Is
it
going
to
be
Telus?
Is
it
going
to
be
cable
comcast?
You
know
so
there's
a
privacy
considerations
even
in
the
deployment,
so
I
really
do
think
we
need
a
lot
of
eyes
and
with
that
I
would
just
like
to
say.
Are
there
any
questions
about
this
work
of
comments.
A
A
P
P
So
what
we're
proposing
is
to
extend
it
to
look
at
the
handshakes,
hyper
Suites
offered
the
cipher
suite
accepted
the
ESN
I,
that
is
in
the
client,
hello,
the
server
name
and
the
certificate
that
are
in
the
server
hello.
What
the
reason
is
research
has
found
in
their
citations
below
that
there
are
mismatches
between
what
happens
with
malware
and
what
happens
with
what
we'll
call
legitimate
software
especially
running
on
things.
P
The
things
can
be
profiled
and
a
mud
profile
can
be
published,
indicating
what
TLS
parameters
are
normal
for
that
device
to
operate
with,
therefore,
helping
to
identify
if
that
device
has
malware
running
on
it.
The
characteristics
that
we
found
in
that
research
is
now
where
it
does
not
use
the
same.
Crypto
Suites
does
not
connect
to
the
same
servers
that
you
know
behaves
differently,
then
the
legitimate
software
running
on
the
device.
So
that's
that
use
case
on
the
left
on
it.
P
Fine
and
on
the
right,
we've
also
found
situations
where
we
can
use
this
same
technique
to
detect
what
I'm
going
to
call
broken
TLS,
so
failures
of
best
practices
such
as
validating
the
server
certificate
expiration
date,
things
like
that
which
have
been
found
in
a
wild
and
we
have.
We
have
citations
on
the
next
slide
on
that
and
and
reuse
of
the
same
private
key
with
mutually
authenticated
TLS,
as
we've
seen
in
the
wild
next
slide.
Please.
P
P
So
how
valuable
is?
Is
this
overall
and
while
it's
true
it
doesn't
encrypt
the
handshake?
What
is
most
valuable
for
us
to
get
for
the
profiles
that
we're
interested
in
is
what
still
remains
in
the
clear
with
TLS
1.3,
and
that's
all
that
I
have
next
slide.
Please
and
hopefully
earned
you
back
some
time
and
if
you
have
any
questions,
please
come
to
the
mic
or
drop
me
an
email.
J
P
K
Benoit
clay,
so
it's
not
specific
about
this
draft,
but
it
seems
that
mud
became
something
big
recently
right,
so
we
went
from
one
R
I've
seen
observable
ug
and
I
was
checking
that
the
mud
mailing
list.
Now
there
is
like
the
hackathon
there
is
this
mud
maker.
There
is
like
seven
documents
here
right
and
that
that
led
to
the
questions
that
were
asked
before,
how
does
all
this
fits
together?
So
you
know,
isn't
it
time
to
just
create
a
working
group?
K
What
you
combine
this
together,
I
mean
and
I've
not
been
discussing
with
people
Avada,
but
just
thinking
you
know
to
me
whenever
I
want
to
get
like
a
picture
of
everything
of
muds,
it's
like
a
mud
mailing
list
sometime
in
update
absolutely
G.
There
is
a
mat
maker,
so
you
know
just
throwing
the
stone
in
the
pond.
Like
people
react.
G
J
Occasionally
I
presented
to
t2
TRG,
however,
this
isn't
really
t2
t.
This
is
more
t2n
right.
The
mud,
never
configures
a
device,
mud
configures,
the
network
infrastructure
and
it's
it
could
be.
It
could
be
addressing
more
than
just
access
control.
I
know
we
have
a
few
concepts
there
like
around
this,
but
it
is
all
focused
on
configuring,
the
network
and
never
communicating
back
to
the
device
and
never
actually
and
the
device
should
never
actually
assume.
Then
that
network
is
actually
doing
anything
with
this
information
because
there
might
not
be
a
mud
controller
on
the
network.
A
Related
to
benoit's
question
and
in
the
interest
of
time,
I'll
discuss
this
via
email.
More
there's
also
captive
portal
discussions
that
have
been
happening
on
opposite
working
group
lists.
Maybe
it
is
time
to
consider
how
is
mud,
something
to
to
centralize
more
and
make
more
in
its
own
realm
versus
versus
an
ops
AWG.
If
that
work
is
going
to
continue
to
evolve.
J
No
I
don't
mind
if
we
work
in
the
working
group
or
work
elsewhere.
I
think
Warren
was
around
for
when
we
and
Joel
where
it
was
around
for
a
lot
of
discussions
around
where
we
do
all
this
work,
and
it
was
it's
always
one
where
you
can
split
it
multiple
ways.
However,
one
of
the
things
I
would
like
us
to
contemplate
in
this
in
the
discussion
that
ensues
is:
does
it
discover
mud
recover
some
of
the
onboarding
work
that
is
go
related
to
mud?
J
Like
that's
a
lot
of
stuff's
going
on
in
anima,
some
of
the
stuff?
That's
going
on
EMU,
there's
discussion
going
on
in
acne
around
onboarding
here,
which
there's
stuff
that's
been
going
on
in
six
dish,
which
looks
like
it's
about
to
close,
there's
a
whole
animal
architecture.
That's
never
before
or
before.
It's
not
anima
is
the
wrong
word.
It's
the
83
66
voucher
work
that
Kent
and
others
did
which
is
being
built
upon,
and
then
we
need
to
look
at
how
that
works.
An
on-prem
should
we
should.
J
A
Q
A
R
R
Talk
about
this
in-situ
flow
information
to
lamprey
framework.
We
have
been
talking
about
this
in
two
meetings
ago
and
then
we
also
present
this
in
AI
ppm
working
group,
but
we
still
think
OBS
aw
geez
a
right
feet
for
this
document
and
therefore
we
are
seeking
for
the
working
group
adoption
for
this.
Eventually,
please
go
to
the
next
slide,
so
the
motivation
for
this
document
are
threefold.
R
Firstly,
there
are
currently
some
novel
data
plane:
geometry
technology
are
emerging,
especially
cuz.
They
are.
We
call
that
on
past
geometry,
it
involves
several
are
different
technologies
and
we,
you
think
there
is
a
need
to
actually
classify
the
terms
and
underlying
techniques
so
that
we
can
have
a
formal
understanding
about
those
different
technologies
and
secondly,
as
these
techniques
are
very
useful,
not
only
for
the
data
center
and
the
price
Network.
We
also
see
a
strong
interest
from
the
carrier
operators
to
apply
these
kind
of
technologies.
R
However,
on
you
know,
tearing
or
prototyping
and
deployment
of
this
technology,
we
find
there
are
quite
a
few
challenges
we
need
to
address
before
they
can.
It
can
be
a
delayed
providing
in
our
networks,
so
we
also
want
to
provide
an
architectural
framework
to
summarize
the
challenges
and
if
some
guideline
for
the
future
standard
development,
so
therefore
it's
also
very
important
to
continue
to
identify
any
other
issues,
and
so
it
will
be
very
helpful
for
us
to
continue
to
develop
collapse.
The
suite
of
protocols,
next
slice
yeah.
R
So
in
previous
RFC's
we
have
a
defined
several
distinct
type
of
4om
techniques.
They
are
passive
and
active
OAM.
The
pensive
means
basically,
you
just
a
filter,
ER,
filter
or
sample
user
traffic,
and
you
stand
to
infer
the
form
itself.
You
use
the
traffic.
The
active
is
on
the
opposite
side,
you,
the
ural,
a
you
just
inject
some
dedicated
om
package
and
you
just
mirrors
those
kind
of
active
probing
packets
to
get
performance
of
the
networks.
But
they
said
you
kind
of
on
past
data.
R
Printed
entry
techniques
are
different
from
either
passive
mode
or
active
mode.
So
we
think
we
can
call
that
a
hybrid
mode,
because,
instead
of
just
capture
the
user
traffic
or
inject
a
new
package,
it
actively
modified
the
user
packet
by
adding
metadata
or
instructions
to
the
user
packet
and
therefore
collects
those
direct
data
from
the
user
traffic
to
infer
the
performance
of
each
user
flows
or
the
network
and
below
this
hybrid
mode.
They
can
be
further
are
separate
to
two
different
type
of
underlying
techniques.
R
We
call
them
a
wise
password
mode
and
under
its
postcard
mode,
bypass
per
mode
means
it's
just
basically.
Are
you
stamp
the
new
date
to
the
user
pack
in
the
ante,
each
each
hop
on
the
40
pass,
so
the
representative
technologies,
IOM,
trees,
mode
and
E
to
e
mode.
The
posts
I
belong
to
this
category
and,
in
contrast,
the
postcard
mode
is
a
different.
It's
a
instead
of
you
know
adding
the
user
data
to
the
packet
itself.
R
It's
just
a
directly
exported
data
using
a
separate,
dedicated
OM
packet
and
the
user
traffic
will
be
kept
intact
and
or
RSS,
or
carry
some
instruction,
but
note
page
a
self.
So
so
we
think
a
weekend
in
this
document
we
can
clarify
this
different
type
of
technologies
will
be
one
contribution
to
our
compliments.
You
know
that
already
defined
terms
for
the
OEM
techniques.
R
Next
slide,
then
this
slide
summarizes
everal
challenges.
We
are
we
found
when
we
trying
to
divide
the
technology
scene
carrier
networks.
The
first
ones
are
related
to
the
performance,
because
it,
this
kind
of
techniques
involve
quite
a
lot.
They
deplane
are
processing
if
you're
generate
data
or
generate
export
package,
so
sometimes
it
can
have
a
direct
impact
on
the
folding
performance.
We
call
an
observant
effect,
which
would
call
actually
damage
the
fidelity
of
our
telemetry
data
and
also
you
know,
I.
R
It's
not
intolerable
to
actually
impact
the
folding
performance
and,
on
the
other
hand,
as
a
as
a
export
data.
Due
to
that
a
huge
amount
of
I
exported
the
data.
The
benefits
consumption
is
huge.
Also
those
data
will
may
overload
the
processing
servers
will
handle
this
kind
of
data.
So
this
this
a
performance
issues
must
be
addressed
to
allow
this
kind
of
tactics
to
be
applied
and
also
we
find
the
current
design
current
standard
proposals.
R
There
are
limited
data,
flexibility
and
extensibility,
which
means
it
can
be
useful
to
add
some
predefined
set
of
data,
but
but
I
see
there
are
to
apply
this
in
the
wider
scope
to
support
different
Network
scenarios
or
to
select
different
kind
of
data
source,
even
user
data.
That's
this
standard
proposal
still
can
o
do
that.
So
we
need
to
extend
the
flexibility
and
accessibility
and
the
last
one
is
a
deployment
issues
because
inherent
networks.
R
There
are
so
many
different
type
of
transport
protocols,
and
there
are
many
related
work
going
on
in
ITF
to
to
talk
about
how
you
will
encapsulate
such
protocol.
Headers
you
address
into
the
different
protocols,
so
these
are
very
useful
and
we
need
to
continue
that
kind
of
work
to
try
to
cover
a
different
kind
of
Network
scenarios
and
also
we
to
consider
how
to
handle
the
different
tunnels,
how
to
make
this
work
in
both
underline
and
underlay
and
overlay
networks.
R
So
that's
what
we
are
very
important
clarified
that
the
technique,
how
to
write
in
tunnel
mode
next
slide
is
okay.
So
the
the
high
level
framework
I
include
four
key
components:
the
first
one
I
smart
flow
data
selection,
which
works
and
the
basically
has
had
a
node.
It
allow
to
us
to
define
what
kind
of
packets
or
what
can
flow.
We
should
actually
enable
this
kind
of
data
collection
technique.
R
Right
then,
there
there
can
be
a
different
algorithm,
based
approaches
and
or
some
user-defined
smart
filters
of
this
kind
of
techniques
are
very
useful
if
you
reduce
as
a
load
to
the
network,
and
the
second
component
is
explored
data
reduction,
which
means
when
and
every
node,
if
it
ever
need
to
export
data,
and
we
can
deploy
some
event
based
smart
filters
to
actually
reduce
amount
of
data
that
need
to
be
exported.
So
that's
a
very
effective
to
to
reduce
theta
X
bandwidth
also
reduces
load
of
the
processing.
R
So
the
last
one
is
that
dynamic
and
natural
probe
is
actually
a
very
key
components
can
be
used
to
support
the
previous
three
components
by
you
know:
allow
user
to
device
data
filtering
out
intersection
policies,
underground
hi.
So,
with
this
of
core
components,
we
came
a
support.
We
can
address
the
performance,
the
prior
ability
and
the
flexibility
issues
we
are
facing
in
Korea
networks,
next
slice
yeah.
So
basically,
you
want
to
take
this
opportunity
to
have
a
more
discussion
with
a
working
group
and
we
want
to
collect
more
feedbacks
from
working
group.
R
R
What
was
missing
in
this
is
document.
Is
there
any
suggestions
to
accept
framework
more
complete
and
we
yeah?
We
welcome
any
feedback
on
this
draft,
and
so
we
can
like
help
us
to
improve
this
document
and
we
move
it
towards
the
call
for
the
working
group
adoption.
Thank
you
very
much
any
question.
So
thank.
S
Shwetha,
cisco
I've
gone
through
this
draft
a
few
times.
It
looks
more
like
a
white
paper
describing
a
solution
less
like
a
framework.
It's
a
bit
confusing
on
how
who
is
targeted
towards
and
how
to
how
to
use
it,
including
the
the
challenges
requirements
that
the
framework
is
going
to
meet,
and
it
has
a
bunch
of
references
to
to
a
whole
lot
of
individual
work
which
I'm,
which
are
neither
RFC's
or
have
been
adopted
it.
S
It
looks
more
like
the
data
that
is
collected
here,
which
is
useful,
could
be
could
be
given
as
feedback
to
the
existing
drafts
that
are
under
work
elsewhere
and
and
then
revisit
and
see.
How
do
you?
How
do
you
want
to
proceed
with
giving
a
operator
feedback
on
how
to
use
those
inbound,
telemetry
protocols
that
are
going
to
be
defined
and
some
implementation
guidance,
but
as
a
frame,
it
doesn't
make
much
sense
to
me.
S
R
So
the
technique
coward
here
that
quite
new
via
or
RFC
draft
ITF
drops
right
now,
and
so
this
this
document
doesn't
introduce
any
new
techniques.
It's
a
means
to
be
an
informational
and
also
we
want
to
collect
actually
the
feedback
from
operators
for
their
experience,
all
departments
for
the
deployment.
So
we
also
want
to
provide
best.
You
know,
industry
practice
so
that
we
can
help
in
our
IDF
to
to
continue
work
on
this
related
to
the
technique.
S
Documenting
in
deployment
experience
would
be
useful,
but
that's
not
in
there
yet
and-
and
there
is
reference
to
algorithms
that
would
make
it
better.
There
is
reference
to
unbox
processing
that
would
make
it
better
without
any
concrete
examples.
I
think
those
adding
those.
What
would
make
it
useful
thanks.
A
T
T
So
essentially,
if
packets
traversing
a
network
in
the
in
a
domain
and
maybe
at
when
the
packets
come
into
the
domain,
you
start
adding
at
every
hop
some
network,
telemetry
information
and
then,
when
you
get
to
the
other
end,
you
need
to
export
that
in
some
way
amount
to
a
processing
system
that
can
do
analytics
or
whatever
type
of
monitoring
you
want.
So
this
kind
of
complements
all
that.
It's
not
about
how
you
affect
the
normal
data
plane
packets,
but
now
that
you've
collected
a
bunch
of
information.
T
So
so,
as
I
mentioned,
IOM
records,
operational
and
telemetry
information
in
its
initial
form.
In
the
packet
itself,
though,
there
are
proposals
to
export
directly
from
nodes
as
well,
so
in
raw
export.
We're
really
saying
that
for
a
lot
of
the
hardware
switches
and
routers
out
there,
they
want
to
focus
primarily
on
forwarding-
and
you
know
just
getting
the
data
to
its
endpoint.
It's
very
useful
to
collect
this
telemetry
information
and
that's
what's
new
about
IO
am
but
we'd
like
to
minimize
the
processing
load
and
the
difficulty
of
doing
that
within
those
nodes.
T
And
one
way
to
do
that
is
to
do
what
we
call
raw
export,
which
is
kind
of
a
minimal
form
of
where
you
do
as
little
processing
is
necessary
to
retrieve
that
IO
am
data
that's
been
collected
and
then
export
that
in
the
simplest
manner
possible.
So,
as
you
see
in
the
figure
on
the
right,
the
IO
am
node
is
a
switch
or
router
that
is
forwarding
packets.
You
do
that.
T
The
raw
export
is
in
allowing
to
offload
a
lot
of
the
processing
or
aggregation
or
reformatting
to
an
IOM
data
processing
system,
so
we're
just
trying
to
get
the
information
off
the
IOM
notice
as
simply
as
possible,
and
then
from
that
it
is
possible
that,
after
that
I
data
processing
system
it
may
do
some
formatting
or
aggregation
or
processing.
It
may
do
some
interpretation
and
from
there
you
may
have
something
else:
it's
gonna
progress
that
to
a
monitoring
or
analytic
system.
So
this
is
really
focused
on
that.
T
T
So,
as
we
look
at
raw
export,
we
really
want
to
get
just
the
the
telemetry
information
and
some
packet
fields
as
well.
So
we
want
to
be
able
to
identify
the
packet
or
the
flow,
and
for
that
we
just
we're
basically
saying
if
you
just
take
a
chunk
of
the
packet
itself
involving
a
bunch
of
the
headers,
then
you
can
figure
out
what
the
packet
is.
T
Ip
fix
is
a
generic
export
protocol,
so,
while
initially
it
was
primarily
used
for
counters
and
meters,
and
things
like
that,
there
was
a
packet
sampling
framework
to
find
and
that
exports
chunks
of
packets,
and
we
found
that
that
is
a
pretty
good
match
for
what
we
want
to
do
and
IP
fix
has
these
templates
that
allow
you
to
construct
fairly
concise
packet
formats
or
formats
for
the
exported
packets,
where
you
can
add
various
fields
that
can
help
provide
contacts
and
could
include
the
IOM
headers
themselves.
T
Now,
because
we
want
to
support
this,
you
know
billions
of
packets
per
second
kind
of
crazy
line
rates.
It's
likely
that
an
implementation,
that's
using
IP
fix
for
export
of
IO
a.m.
is
going
to
do
a
small
subset
of
what
IP
fix
normally
does
so
we're
not
talking
at
generic.
You
know
to
find
any
template.
You
want
and
go
off
and
run
with
it.
We're
we're
talking
about
supporting
a
small
number
of
all
of
templates
that
are
rather
fixed
and
but
a
template
can
then
describe
whoever's
receiving
this.
T
What
that
format
is-
and
it
allows
a
fair
amount
of
flexibility,
then
different
implementations
could
use
different
IP,
fixed
templates,
which
allowed
them
to
optimize
and
support
it
well
in
hardware
and
systems
receiving
them
would
do
the
more
flexible.
The
full
IP
fix
implementation
and
they
could
interpret
it
with
various
formats
coming
say
from
different
vendors
or
so
on
next
slide.
Please.
T
So
there's
a
bunch
of
information
elements
that
are
already
defined
for
packet,
sampling,
so
section
of
an
IP
header
or
a
section
of
a
data
link
frame
or
Ethernet.
So
some
of
those
have
been
identified
here
next
slide.
Please
so
we're
also
proposing
some
new
information
elements
to
provide
a
district,
more
context
or
tell
you
something
about
the
IOM
encapsulation
type
before
on
the
bottom
are
the
actual
IOM
information.
So
you
just
take
that
chunk.
T
T
So
so
this
has
been
presented
an
IP
PM
before
and
the
question
is,
as
we
look
at
these
issues
and
try
to
define
this
and
progress.
This
does
this
topic,
make
more
sense
in
ops,
AWG
or
an
IP
PM.
There's
no
real
home
for
IP
fix
at
the
moment,
I
believe
so.
We're
really
asking
if
ops
AWG
will
be
interested
in
progressing
this
work
and
soliciting
technical
input
and
feedback.
How.
A
A
C
I
C
Right
any
comments
about
that,
so
mud,
the
core
of
the
mud
workers
seems
to
be
done
now.
There
are
extensions.
Similar
thing
is
happening
with
brewski
Bruce
key
is
being
processed,
but
the
rest
now
incoming
work
on
what
was
called
brewski
profiles,
extensions
uses
and
other
things
onboarding
in
general
is
topic
of
interest
for
the
community.
The
question
is:
how
large
is
that
community?
F
G
There's
a
lot
of
relevant
really
to
use
T
device
management.
It
would
be
good
to
have
a
single
place
to
talk
about
this,
and
I
also
am
having
what
know
where
there's
a
home
gateway
home.
Networking
group
I'm,
not
sure.
What's
the
ask
over
so
since
the
for
this
matter
will
cover
a
lot
of
the
you
know,
security
partner,
onboarding,
Brisky
acacia
is
very
complicated.
I
cannot
have
the
Hopi
show
so
and
want
to
better
understand
the
scope
is
matter
work.
A
For
me,
Joe
Clark,
similar
I
I,
don't
mind
the
the
mud
work
happening
in
ops
area
working
group
as
a
working
group
chair,
but
it
sounds
like,
and
there
is
a
lot
of
side
meetings,
other
aliases
other
areas
where
there's
interest.
It
might
make
sense
to
centralize
that
to
give
that
community
a
more
focused
ability
to
progress.
This
work.
Q
C
Thanks
thanks
for
laying
the
question
that
I
would
have
from
my
side
is
having
work
spread
in
different
places
in
grouped
by
topic,
probably
results
in
the
fast
work
on
those
components.
If
this
becomes
so.
If,
for
example,
a
new
working
group
is
established
to
kind
of
coordinate
all
of
that
work,
wouldn't
that
result
in
a
long
but
probably
needed
discussion
on
how
to
organize
that
on
framework
documents
on
on
kind
of
guidance
and
less
focus
on
actual
shipping
products,
specifications.
G
K
C
Would
probably
this
would
not
disagree
with
that,
but
that's
up
to
the
working
group
actually
trying
to
adhere
to
that
and
doing
something
and
well.
We
have
a
really
good
history
of
over
thinking
about
the
problem,
space
not
necessary
for
bad
reasons,
but
that
takes
a
really
long
time.
So
the
question
is
if,
for
example,
there
are
only
extensions
in
a
pipeline
for
mud,
maybe
it's
more
efficient
to
do
that
here,
concentrated
on
on
mud.
If
there
are
extensions
to
brewski,
maybe
it's
more
efficient
to
concentrate
an
anima
to
address
those
extensions.