►
From YouTube: IETF99-IPPM-20170719-0930
Description
IPPM meeting session at IETF99
2017/07/19 0930
https://datatracker.ietf.org/meeting/99/proceedings/
C
C
C
C
All
IETF
sub
contributions
are
sub,
the
rules
of
53
78
and
81
79,
usually
at
this
point
I
say
probably
by
Wednesday.
You
should
have
seen
this
at
least
once
if
you
haven't
seen
this
and
actually
read
it,
and
to
understand,
what's
going
on
I'm,
going
to
draw
attention
to
the
fact
that
the
RFC
number
for
IPR
disclosures
has
changed,
that's
because
the
policy
has
actually
changed
someone.
So
please
do
make
sure
you
have
a
look
at
81
79
and
understand
what
it
says.
C
Here
is
what
we
think
the
status
of
our
working
group
drafts
is.
I
would
be
happy
to
be
corrected
by
any
of
the
authors.
If
we
have
this
wrong
I'm,
pretty
sure
that
RFC
idea
186
was
in
fact
published
because
I
know
what
the
RFC
number
is
so
yay
another
IP
PMRF
see
we
have
a
11
Rev
of
model-based
metrics
that
was
updated
just
before
the
meeting.
I
believe
this
is
ready
for
ballot
L,
okay,
so
that
is
it
scheduled
on
the
telecheck,
yet,
okay
cool.
C
It's
through
okay,
so
hey.
We
have
two
that
are
basically
on
your
way
out:
23
30,
ipv6,
0
1,
we're
gonna
have
a
talk
about
my
understandings,
we're
still
waiting
on
6
min,
so
we're
not
waiting
as
much
on
6
men
because
I,
because
the
the
internet
standard
has
been
published.
There
are
continuing
discussions
about
addressing
architectures
that
will
terminate
at
some
point
before
the
heat
death
of
the
universe.
C
We've
got
Altmark
0-5
working
group
last
call
is
complete
and
we're
waiting
for
a
right
up
from
the
Shepherd
Thank
You
Carlos.
Thank
you
very
much.
We
are
going
to
start.
The
working
group
last
call
on
twin
peeing
during
this
meeting.
Basically
this
and
that
email
out
to
the
list
as
soon
as
I'm
not
projecting
these
slides
any
volunteers
for
shepherds
people
who
have
been
following
the
egg
model
41.
C
Who
would
like
to
help
us
out
in
writing
the
Shepherd
statement,
so
the
Shepherd
statement
is
essentially
a
statement
that
goes
up
to
the
iesg.
It
says
you
know:
here's
how
the
working
process
worked
out.
Here's
I've
actually
checked
their
all
the
IPR
disclosures
have
been
made
have
been
made.
This
is
a
report
of
how
things
were
at
the
ie
at
the
if
they're
working
group
level,
and
it
helps
the
isg,
do
their
evaluation.
So
it's
not
an
enormous
amount
of
work
and
it
is
sort
of
a
good
way
to
get
some
experience
with.
C
You
know
the
depth
of
the
process
that
we
use
here
at
the
IETF,
so
any
volunteers
to
shepherd.
That
document
through
we'll
take
that
call
in
the
list
so
metric
registry
and
initial
registry,
twelve
and
four.
This
is
another
one
that
we
actually
probably
are.
We
knew
that
this
was
going
to
take
as
long
as
it
was
going
to
take
one
of
the
things
that
we
chased
down
in
discussions
about
this
draft
I
believe
in
Chicago,
but
it
might
have
been
Seoul,
was.
C
C
Excellent,
so
that's
where
we
are
with
the
drafts:
here's
our
agenda,
we're
gonna
start
with
initial
metric
registry
from
from
owl,
and
then
we're
going
to
have
twenty
three
thirty
ipv6
from
Joaquin.
Then
we
have
basically
two
larger
discussions
on
the
agenda.
One
is
our
reach
are
during
discussion,
which
you
know
will
come
back
to.
We
have
some
some
slides
introducing
that
and
going
into
the
details
of
the
charters.
There
will
be
a
bit
of
a
shorter
bashing
session.
C
The
thing
that
raised
this
issue
was
the
discussion
in
Chicago
about
bringing
the
in-situ
OEM
work
into
AI
ppm,
but
it
turns
out
that
actually
most
of
the
changes
that
we
want
to
make
of
the
Charter
are
about
reflecting
work
that
we're
already
doing
or
that
we've
realized
in
the
course
the
past
four
years
that
we
need
to
do
so.
C
C
After
that,
we're
going
to
talk
about
taewin
plight,
presentation
from
al
two
presentations
from
Greg
and
a
discussion
afterward
about.
So
what
this
is
is
basically
about
is
the
pregnant
for
would
like
to
be
able
to
use
the
T
map
test
protocol
on
its
own
and
needs
a
registered
port
for
it.
So
that
seems
like
a
good
time
to
basically
clear
up
remaining
ambiguity
about
the
status
of
that
as
a
protocol
and
I
think
we
can
come
to
I'm.
C
C
You
might
actually
have
time
for
six
now,
because
we
took
15
minutes
back
out
of
the
agenda,
so
these
are
work
that
has
not
been
discussed
on
list
but
may
be
of
interest
to
the
IPP
M
community.
These
are
ordered
basically
in
order
of
first
things
that
are
directly
applicable
to
continuing
working
group
work.
There's
a
couple
on
alternate
marking,
then
new
work
that
we
have
not
yet
seen
in
order
of
request,
timestamp
and
then
a
returning
work
that
is
not
directly
related
to
two
other
work
in
the
working
group.
C
D
Okay
registry
for
performance
metrics
good
morning,
everybody
nice
full
room
today,
so
I'm,
al
Morton
and
and
doing
this
with
Marcelo
been
one
fill
and
er
next
slide.
So
we
we
a
long
time
ago
decided
that
we
needed
to
specify
metrics
with
more
precision
than
we
did
with
the
flexible
versions
that
we
put
in
the
RFC
s.
D
So
we're
actually
kind
of
minimized.
What
we
asked
of
Vienna
in
this
and
we're
going
to
support
that
with
the
additional
detailed
information.
So,
as
you
can
see,
this
is
organized
in
categories
and
columns.
We've
got
summary
columns,
metric
metric
definition.
Actually,
the
categories
are
here
on
the
left
and
lots
of
detail
has
to
be
added
here
so
that
we
really
nail
down
what
the
implementations
have
to
do
in
order
to
make
these
measurements
okay.
D
So
it
may
come
back
to
that.
So
we
added
a
lot
of
new
loss
metrics
this
time
around
in
the
initial
contents
and
that
yielded
feedback
on
the
names
so
down
here
in
the
bottom.
The
Ayana
section
talks
about
three
things
that
we're
asking
them
to
do:
we're
asking
them
to
give
us
URI
namespace
as
as
indicated
there,
and
to
help
us
with
a
sub
registry
of
the
name
types
and
the
elements
of
each
name
that
feed
into
the
names.
So
what
did
we
do
with
that?
D
Let's
see
here's
this
a
good
place
to
go
through
that,
no
actually,
so
on
on
the
on
the
one
of
the
next
drafts.
I'll
talk
about
that
some
more,
but
we've
got
the
name
elements
divided
up
into
these
categories,
the
metric
type,
the
method,
the
subtype
method
and
you'll
see
how
that
works
and
and
the
subtypes
can
be
expanded
so
that
you
can
be
as
expository
as
possible.
D
What
to
do
and
I
don't
expect
you
to
read
all
the
the
little
text
here,
but
I
did
try
to
make
the
names
as
big
as
possible.
So
you
can
see
that
the
very
first
metric
is
a
round-trip
delay.
Rt
delay
metric,
it's
active
method,
the
subtype
methods
are
IP,
UDP
Plus
on
the
RC
number
will
be
filled
out.
The
units
of
measure
of
seconds
and
the
actual
metric
is
95th
percentile,
so
pretty
easy
to
figure
out
from
the
name.
D
But
we've
got
a
description
there
too,
and
one
key
point
is
that
under
the
URI
column-
and
you
can't
see
all
the
columns
here
that
I
Anna
will
produce,
but
one
key
thing
there
is
is
that
there
will
be
a
URL
to
the
complete
registry
description
which
wouldn't
work
in
a
you
know
a
screen
kind
of
thing
like
this.
You
basically
want
to
be
able
to
see
all
the
information
read
it
like
a
document
and
that's
what
the
you
are.
D
D
If
we
get
a
chance
and
on
on
the
outputs,
we
have
a
singleton
which
is
just
a
single
sort
of
single
number
output
and
that's
now
distinguished
from
raw,
which
is
multiple
Singleton's.
That
was
that's
the
way
these
things
were
always
mentioned,
so
we're
gonna
have
both
singleton
and
raw,
and
we've
now
explicitly
got
this
lost
ratio
in
there,
which
is
lost
to
total
packets,
usually
less
than
or
equal
to
1
all
right.
So
here's
the
mock-up
of
the
element
named
element
sub
registry
this
year.
D
These
are
all
for
metric
type,
and
these
are
the
ones.
This
is
a
subset
of
the
ones
that
we
have
there
now
for
a
round-trip
delay
for
round
trip
response
time
for
the
DNS
response,
loss
for
DNS,
one
way
delay
you
round
trip
loss,
there's
a
whole
bunch
more
in
this
first
category
of
metric
type
and
you'll
actually
see
more
caught
more
columns
off
to
the
right
there
as
well.
E
D
Look
the
question
we've
been
asking
and
for
anybody
who
does
true
passive
measurement
to
the
name
element
sets
cover
passive
well
enough
and
I.
Think
if
someone
actually
doing
passive
measurement
was
to
take
a
look
at
this,
they
might
have
some
ideas
for
us,
but
that
doesn't
seem
to
be
kind
of
feedback
forthcoming
and
every
time
we
look
at
this
and
add
a
few
metrics
or
whatever
it's
been
a
chance
to
adds
new
name
elements
and
we've
done
that,
and
so
it's
fairly
easy
to
do
this
in
the
future
and
I
think
that's
our
protection.
D
If
we
don't
get
this
feedback,
we'll
be
okay.
So
how
am
I
doing
on
time?
Alright?
So
here's
the
the
initial
performance
metric
registry
entries
these
are
the
actual
detailed
entries
that
we're
going
to
propose
right
away
to
put
in,
and
you
can
see,
there's
a
long
history
of
drafts
here
for
our
co-authors,
Marcelo
Phil
and
Keven
D'souza,
my
colleague
at
18
T,
so
the
feedback
on
the
registry
contents-
we're
actually
you
know
still
seeking
what
folks
would
like
to
see
if
they
go
ahead
and
look
at
this
stuff
hard.
D
These
detailed
registry
contents
and
and
appreciate
what
it
takes
to
implement
these
metrics
we've
had
regulator
guests
in
the
past.
That's
what
reg
you
guests
stands
for
and
and
actually
over
the
last
three
or
four
meetings
in
a
row,
probably
not
this
time.
But
you
know
we'd
like
like
people
to
feed
into
this.
D
So
now,
sections
four
through
eight
in
this
draft
introduce
all
the
the
new
detailed
of
registry
contents
and
what
we
found
this
time
around
was
that
it
was
fairly
easy
to
add
a
loss,
metric
kind
of
like
as
an
overlay
or
a
subsection
in
each
one
of
the
ones
were.
For
example,
if
we
had
round
trip
delay
before
with
UDP
the
first
metric
I
mentioned,
it
was
fairly
easy
to
add
loss
and
that's
because
the
methodologies
are
so
closely
related
with
loss
and
delay.
D
You
use
a
timeout
to
determine
whether
the
packets
lost
or
delayed
and
or
just
not
going
to
wait
for
it
anymore
and
because
of
that
commonality
of
the
methodologies
fairly
easy
to
to
put
in
loss.
So
now
in
the
in
the
draft,
we
have
many
questions
that
were
sort
of
answered
and
and
decided
with
short
discussions
and
and
based
on
the
I
Anna
work
to
clarify
the
protocols.
D
We've
got
the
ability
to
four
editors
like
me
to
to
expand
our
list
of
metrics
and
to
do
that
economically
by
having
an
approach
where
one
section
can
actually
create
the
registry
entries
for,
let's
say
four
or
five
all
delay
related
metrics
and
loss,
as
I
said,
because
they're
very
closely
related.
So
we've
applied
that
approach
now
to
almost
all
the
sections,
so
the
early
sections
and
the
later
sections,
seven
and
eight.
So
here
are
the
new
metrics
and
now
you
can
look
at
some
more
names
and
a
little
bit
larger
font
size.
D
As
I
mentioned.
These
are
all
going
to
be
loss
related.
Obviously,
so
we've
got
round
trip
loss,
active
IP,
UDP,
the
response
loss
for
DNS,
one
way,
loss
for
active
IP,
UDP,
Poisson
and
one
way,
loss
for
IP,
UDP
periodic
and
the
rest
of
the
information
there.
Anybody
need
the
blue
sheets
actually
I
do
Spencer.
D
I
stood
up
at
the
wrong
time.
Thank
you.
Okay,
so
so
I
said,
loss
has
been
added
in
the
absolute
simplest
way.
We've
got
this
traceroute
metric
proposed
we'll
be
discussing
that
at
the
at
the
meeting
here
and
and
I
think
this
is
I
think
this
is
worthwhile
adding
you
know.
Maybe
we
don't
need
to
do
it
as
part
of
the
initial
contents.
D
Maybe
we
can
do
it
as
an
adder
or
something
like
that,
but
let
the
working
group
decide
that
there's
many
methods
of
measurement,
though
that's
the
interesting
part
and
and
that's
what
we
there's
some
new
work
going
on
in
that
area
and
there's
always
research
in
the
area
of
traceroute,
both
the
active
and
the
hybrid
methods
of
measurement.
So
here's
a
question
to
the
group
in
the
past
folks
have
said:
yeah
we'd
like
to
have
a
registered
metric
for
ICMP.
Echo
request
echo
reply,
but
and
I
and
it's
a
big.
But
here
is
anybody.
D
D
C
Project
I
guess
so
it's
broadband
mapping
project
that
the
Commission
is
running.
The
European
Commission
is
running
for
regulatory
use
cases
primarily
and
their
their
latency
metrics
I
think
they
haven't
really
decided
what
they're
gonna
use,
but
it's
gonna
be
whatever
they
have
in
the
dataset,
from
the
act
of
measurement
provider
and
in
a
whole
lot
of
cases,
that's
ping,
so
I
think
we
need
this
well
and
because
I
mean,
if
you're
actually
looking
for
again,
it
sits
back
down
to
the
do.
C
You
want
to
look
at
the
difference
between
53
and
55
milliseconds,
which
actually
you
can
if
it's
stable
paying?
Well,
you
know
you
can
do
a
bunch
of
math
and
you
get
or
do
you
want
to
look
at
the
difference
between
ten
and
a
thousand
milliseconds
and
things
okay
for
between
ten
and
a
thousand
milliseconds
yeah.
So
it's
really
down
to
that
yeah!
So
I
think
we
really
actually
do
need
this,
but.
G
C
C
D
C
H
C
C
Is
terrible
or
you
don't
use
the
system
which
doesn't
actually
give
us
the
comparability
that
we
want
so
I
think
that
I
think
that
we
kind
of
need
to
so.
There
was
a
second
question
that
you
asked
earlier
in
the
previous
you
don't
have
to
go
back
to
it
is
that
is
this?
Okay?
Actually,
no,
no
show
me
that
show
me
the
just.
C
I
C
C
Versioning
to
this
right
well,
because
so
so
rttt
cpr
TT,
there's
not
a
delay.
Comperable
loss
metric
for
TCP
RT
t
the
very
nature
of
it
right,
but
I
think
they
beat
the
exercise,
basically
taking
the
the
just
the
delay
yeah
at
Rex
for
UDP
and
then
reframing
them
as
TCP
RTT,
passive,
passive
yeah.
So.
E
E
C
D
D
A
D
D
D
D
A
D
Right
well,
let's,
let's
talk
about
getting
towards
the
first
I
think
we're
actually
running
out
of
time,
but
this
was
the
major.
This
was
the
major
question
I
wanted
to
ask
here
and
also
I
think
we're
gonna
convert
a
couple
of
the
metrics
in
section
4
and
section
5
to
periodic.
Instead,
that
seems
to
be
the
actual
implementation.
So
that's
what
I
think
we'll
go
for
make
it
really
quick,
Nalini,
I'm
overtime.
Here,
sorry,
yeah.
D
Yeah
great
well,
but
the
problem
is,
it
may
not
be
populated,
I.
Think
that's
the
problem,
but
let's
talk,
let's
talk!
That's
why
I
raised
the
question,
let's
let's
nail,
that
down
all
right,
so
thanks
very
much
everybody
jeez
read
the
draft.
If
you're
gonna
have
to
implement
metrics
read
the
draft
who.
C
L
So
hello,
my
name
is
your
confer
beanie
I'm,
covering
this
with
L,
Malini,
Mike
and
VIN.
This
is
about
nap
date
of
the
IP
performance,
metrics
framework
for
IP
version,
6.
So
a
background.
Most
of
you
probably
know
it
already.
So
we
have
that
B
performance,
metrics
framework
summarizes
the
basics
on
which
we
build
metrics,
so
we
have
the
basic
trades
there.
We
have
some
some
definitions.
L
We
have
some
some
assumptions
about
packets
there
and
so
the
result
of
measurements
might
depend
in
this
case
on
packet
types
in
this
and
unfortunately,
the
IP
performance
metrics
framework
was
written
back
in
1998
if
I
remember
correctly.
So
by
this
time
we
didn't
have
IP
version
6
or
it
was
in
the
course
of
being
standardized.
So
we
have
there
a
statement
that
says
a
packet
must
include
the
valid
header
and
the
version
field
is
for
meaning
IP
version.
6
is
out
of
scope.
L
We
have
defined
our
metrics
with
IP
version
6
in
mind,
but
according
to
that
performance,
metrics
framework,
it's
out
of
scope,
any
IP
version
6
met
measurement
good.
We
had
some
input
of
Brian
carpenter
during
a
review
and
we
said
we
will
fix
it
in
update
good.
It
was
adopted
as
a
working
group
item
back
a
year
ago
and
yes,
that's
some
work
done
on
this.
We
had
some
inputs
status
at
last.
Itf
was
that
there
is
discussion
needed
and
we
need
to
wait.
L
Finally,
we
had
some
some
working
items
and
we
tried
now
to
find
solutions
to
no
longer
wait
to
in
reply
to
your
question
so
and
Institute
to
have
or
us
to
find
our
assumptions
to
find
our
way
and
to
propose
solutions,
and
these
are
the
solutions.
So
first
question
was
what
fragmentation
IP
version
6
fragmentation,
which
is
commonly
encountered.
We
have
this
quite
distinct
method
of
fragmentation,
just
at
the
sending
cost
and
so
on,
and
so
on.
L
Everybody
knows
and-
and
we
thought
about
how
to
include
IP
version,
6
fragments
and
it
turned
out
to
be
impossible,
because
if
we
all
all
metrics
are
built
on
the
assumption
that
we
have,
we
do
not
have
fragmentation,
meaning.
If
we
introduced
now
allow
fragmentation
for
IP
version
6,
it
means
we
need
to
review
and
revisit
all
metric
definitions
and
we
also
with
respect
to
IP
version
4
and
that's
not
feasible.
L
So
this
is
we
adopt
exactly
the
same
approach
that
we
have
for
IP
version
4,
and
this
is
what
we
propose
and
say:
IP
version.
6
fragments
are
out
of
scope
so
fragment
so
so,
if,
if,
if
fragments
are
used
everyone's
on
his
own,
in
defining
and
and
and
finding
right
scope
for
these
measurements
Brian
so.
C
K
L
Yeah,
so
ok,
6lowpan
and
IP
version
6
header
compression,
so
we
did
some
maths
and
it
turns
out
and
also
it's
it's
originals
in
the
6lowpan
I
spent
some
time
on
reading
these
6lowpan
RFC's.
It
turns
out
that
we
have
about
31
bytes
of
user
data
per
packet
and
in
addition,
we
do
not
have
any
IP
addresses
neither
IP
version
4
nor
IP
version,
more
IP
version,
6
addresses
in
IP,
except
if
you're
tunneling.
L
So
this
is
if
our
packet
fits
into
these
31
bytes,
then
we
can
use
a
kind
of
tunneling
mo
just
transfer
plain
IP
version,
6
packets
over
IP,
over
six
low
and
so
on,
and
so
on.
So
our
impression
was
that
doing
six
low
and
including
six
low
here
and
allowing
six
low
means
that
we
have
to
revisit
anything
that
is
even
the
concepts
of
standard
form
packets
do
not
fit.
We
need
to
review
all
of
them,
and
this
is
definitely
out
of
scope.
L
So
it
is
clear
that
we
do
not
include
include
this
explicitly
the
six
lowest
out
of
scope,
but
we
feel
that
it
is
better
to
have
this
to
have
IP
version
6
going
on
the
right
track,
so
to
have
IP
version
6
standardized,
and
if
someone
feels
that
is
the
need
of
a
6
low,
then
to
do
it
in
a
separate
document.
So.
C
C
In
my
opinion
is
if
there
is
an
interesting
measurement
application
where
you're,
comparing
ipv6
to
6,
low
packets
or
you're,
doing
path,
composition,
metrics,
where
you
have
a
gateway,
that's
actually
doing
some
sort
of
algorithmic
transform
on
the
packets
and
making
them
turn
into
6
low
packets,
which
doesn't
seem
like
that
seems
like
such
a
little
corner
case.
That
I
think
that
we
can
safely
carve
it
often
say
if
6
low
people
want
to
use
the
want
to
use
the
framework,
then
please
come
and
do
the
work
to
update
it.
D
C
C
D
F
L
We
need
some
way
to
contact
them,
but
in
fact,
so
the
problem
that
I
see
is
really
with
this
definition
of
a
standard
form
packet
that
we
try
to
fit
to
IP
version
6
now
to
find
solution
to
this
and
having
16-bit
or
16-bit
addressing
that
is
proprietary
to
to
28.2
dot
15.4
is
it
creates
some
kind
of
difficulty
because
we
have
the
RFC.
We
try
to
stick
as
much
as
possible.
The
existing
RFC
with
us
with
the
framework.
F
L
Robust
Heather
compression
is
like
so
so
we
have
stayed
in
the
network.
That's
one
more
one
more
problem:
we
have,
we
create
stayed
in
the
network
in
network
nodes
that
that
also
impaired
on
the
type
of
P
that
change
the
type
e
of
packets.
So
it's
somehow
difficult
and
and
will
try
to
promote
this
fast
to
have
IP
version,
6
included
into
our
measurements
good.
We
have
this
context.
Is
this
concept
of
a
minimal
standard
form
packet
and
it's?
L
It
said
the
RFC
says
that
it
is
often
useful,
I,
don't
know
of
one
singer
single
reference
to
this
concept
of
a
minimal
standard
form
packet
and
I.
Don't
know
how
it
could
be
treated
in
practice,
because
this
means
that
we
basically
do
not
have
any
payload
any
transport
layer
paid
and
the
transport
layer
headers
in
a
in
a
packet,
perhaps
an
IP
version
6.
L
We
could
do
it
with
a
no
next
header
field,
directly
in
the
IP
header,
but
I,
don't
know
to
which
extent
this
much
this
makes
any
sense
and
it
for
IP
version.
4
I
don't
know
of
any
way
how
to
specify
that
we
do
not
have
any
transport
header
because
we
did
and
the
protocols
the
field
must
be
left
unspecified.
L
L
We
wanted
to
wait
for
six
men
to
find
the
conclusion
they
haven't
found
it
and
now,
with
in
situ,
om
and
and
all
other
aspects,
we
just
said
we
increasingly
see
an
encryption
of
higher
layers.
If
we
refer
to
quick,
we
see
that
transport
layers
are
encrypted.
We
have
no
way
of
conveying
OAM
information,
timestamp
and
so
over
the
network.
So
from
the
perspective
of
IP
performance
metrics,
it
does
make
sense
to
allow
addition
of
trend
of
extension,
headers
on
the
path
and
removal
of
extension,
patters
extension
headers
along
the
path.
L
This
is
our
position
we
would
like
to
have
it.
We
do
not
know,
and
perhaps
before
the
end
of
the
universe,
we
will
know
if
it
will
be
allowed
or
not
allowed,
but
from
an
OEM
perspective
and
IP
pmbus.
If
we
believe
it
should
be
allowed,
we
need
it.
We
have
some
challenges,
we
need
to
define,
and
this
is
what
we
will
do
so
define
also
changes,
adding
an
extension
header.
We
seen
on
Saturday
in
the
a
nrw
workshop.
L
There
was
a
discussion
on
on
segment
routing,
obviously
adding
a
segment
routing
header
somewhere
along
the
path
changes,
the
route
and
therefore
the
type
II
of
the
packet.
So
there
will
be
some
some
needful
discussion,
but
we
feel
that
adding
the
extension
headers,
removing
them
and
even
modifying
them
along
the
path
could
be
helpful
for
our
perp.
So
the
proposal
is
allowed
to
allow
this
and
stators
and
next
steps.
Thanks
for
updating
the
slide
good,
we
have
proposals
for
basically
all
of
our
open
items
we
want
to
int.
L
We
want
to
have
a
discussion
around
list
or
off
list
and,
finally,
to
reach
a
conclusion.
We
will
update
a
draft
and
then
we
want
to
go
working
group
last
call
and
we
want
to
do
it
soon.
So
integrating
all
of
these
items
into
the
draft
should
take
a
matter
of
weeks
and
perhaps
we
can
be.
We
can
do
the
working
group
last
call
even
before
next
IETF
meeting
all.
C
C
Okay,
I
can't
see
a
whole
lotta
I
mean
like
punch
down
over
here.
Okay
Mike
that
doesn't
count
okay,
cool
again
encouraging
eyeballs
on
this,
because
we
will,
let's
see
working
backward
from
November,
will
want
to.
C
Yeah
will
want
to
do
this
sort
of
like
early
October
at
the
latest,
so
actually
as
soon
as
you
guys
get
the
next
Rev
up,
I'll
will
start
W
DLC,
please
not
just
on
that
before.
That
will
also
need
a
document
shepherd
anybody
in
the
room
with
ipv6
expertise.
C
D
C
I
know
he's
gone
through
yeah.
We
can't
do
that.
Okay,
yeah
nice,
try
Michael's,
also
a
co-author
right
and
it's
unfortunate
alright,
so
we
we
will
we
will.
We
will
leave
that
as
an
open
question
for
the
work
of
your
class.
Call
the
please
consider
whether
or
not
you
can
help
out
a
shepherd
on
this.
It's.
A
Mike
Ackerman
a
quick
question
on
the
previous
slide
about
extension,
header
processing.
What
can
we
you,
you
articulated
it
perfectly.
My
question
is:
what's
the
next
step
relative
that
do
we
want
to
carry
this
opinion
well,
first
off.
Is
it
the
opinion
of
IP
p.m.
secondly?
Do
we
carry
that
forward
to
six-man
is
my
question,
or
is
this
a
premature
question
on
my
part?
Well,
I.
C
L
C
C
C
there
seem
to
be
rough
working
group
consensus
that
that
work
fits
here.
There
seem
to
be
working
group
disagreement
that
that
work
fits
here
under
the
current
Charter.
So
we
decided
that
we'd
have
a
discussion
about
the
Charter,
so
I'm
bill
and
I
actually
sat
down
and
opened
this
up,
and
when
we
open
it
up,
we
actually
found
that
it
doesn't
really
optimally
cover
what
we're
doing
now.
C
It
was
worded
in
such
a
way
that
everything
we're
doing
not
technically
kind
of
fits,
and
that
was
on
purpose
because
we
wanted
to
have
a
relatively
wide
Charter
to
you
know,
be
able
to
chase
down
sort
of
things
that
raised
came
out
of
the
metric
stuff
things
that
came
out
of
the
2330
stuff,
that
you
know
we
had
a
line
in
there.
We
have
a
line
in
charge
of
it,
says
we're
gonna
update
our
framework,
but
not
necessarily
reacting
to
external
things,
but
hey.
It
does
really
matter
any
ideas.
C
Let's
make
some
small
edits
to
catch
up
to
the
present,
so
we're
gonna
go
through
these
paragraph
by
paragraph.
We
only
touched
four
paragraphs
at
the
end
and
it
turns
out
that
that
touching
those
paragraphs
doesn't
really
change
much
normative
language
with
respect
to
whether
IOM
comes
in
so
the
first
thing
we
want
to
do
is
rename
the
working
group
we've
been
called
IP
performance
metrics
since
1980
mumble.
C
If
you
look
at
the
work
on
our
agenda,
we
have
we're
spending
a
little
bit
less
than
that
for
time
on
metrics
and
a
little
bit
more
than
half
our
time
on
methodologies,
and
those
methodologies
are
on
charter
for
our
working
group
in
that
they
allow
us
to
measure
metrics,
but
it
might
actually
be
more
useful
to
be
explicit
about
the
fact
that
we
do
measurement,
there's
yeah,
so
yeah.
This
is
I'm
I'm,
sorry
for
the
red-green
color
blind
people
I
do!
If
it's
bold,
then
it's
new.
C
If
it's
crossed
out,
then
it
goes
away.
I
tried
to
have
it
so
that
would
actually
work
but
I'm
seeing.
But
the
bold
might
not
actually
be
bold
enough
to
point
out
that
it's
new,
so
strike
metrics
replaced
with
measurement.
Then
we
take
the
census
specifying
network
and
our
lower
layer,
OEM
mechanisms
out
of
scope,
the
I
ppm
charter.
C
Now,
when
I
look
at
what
I
OEM,
is
it's
not
a
lower
layer,
OEM
mechanism,
it's
a
mechanism
for
carrying
certain
information
on
path
which
can
be
bound
to
lower
layer
headers,
but
it
doesn't
like
the
naming
is
unfortunate,
but
I
think
the
naming
is
unfortunate
as
a
collision
between
sort
of
ops
area,
terminology
and
transport
area
terminology,
anything
that
looks
kind
of
like
measurement
in
ops
in
my
understanding
gets
called
OEM,
because
that's
it's
it's
a
management
function.
C
In
order
to
remove
confusion
here,
we
would
suggest
that
we
just
strike
this
line.
I,
don't
think
that
striking
this
line
is
necessary
to
bring
IO
am
in,
but
on
the
other
hand
we
have
a
line
that
says
we
don't
do
OEM,
and
then
we
have
a
draft
called
IOM.
That's
I!
Can
see
how
that
can
be
confusing
right
and
it's
splitting
it's
splitting
hairs
to
say
well,
so
it
this
is
something
that
I
think
makes
it
clear
and
I
don't
actually
know
what
having
this
in
solves.
C
I
don't
know
the
problem
that
this
line
solves
women.
Basically
the
rest
of
the
edits.
Are
we
add
protocols
and
methodologies
to
the
things
that
we
do.
It
was
a
metrics
heavy
introductory
paragraph.
Now
it's
and
metrics
protocols
and
methodologies
having
intro
paragraph
again.
This
just
reflects
you
could
say
that
this
is
Evan
toriel.
This
reflects
sort
of
we've
been
doing.
C
Owl
had
a
suggestion
that
we
strike
and
not
a
value
judgment,
because
it
could
be
somewhat
confusing
that
the
way
that
mbm
works
is
you
do
an
acceptance
test
which
looks
kind
of
like
a
value
judgment,
because
yes
and
newer
values,
but
it
still
does
provide
an
unbiased
quantitative
performance
measurement,
and
that
was
what
we
were
really
trying
to
get
out
with
that
text
and
I.
Think
that
this
end,
not
a
value
judgment
is,
is
this
is
some
of
the
oldest
text
in
the
Charter
right.
F
C
So
I'm
gonna
make
an
individual
comment.
I
should
probably
run
up
to
the
mic,
but
I'm
lazy
now
I
think
I
know
why
we
have
that
line
in
there
about
putting
that
out
of
scope,
because
so,
on
the
one
hand,
yes,
maybe
on
the
other
hand,
we've
always
been
focused
here
on
the
types
of
measurements
that
you
can
do
from
IP
endpoints
and
it's
very
difficult
to
measure
in
pls
from
an
IP
endpoint.
You
can
measure
from
an
MPLS
endpoint,
but
you
can
also
measure
in
pls.
N
C
N
Yes,
the
network
layer
and
wor
layer
is
confusing,
because
now
we
have
many
overlays
that
go
above
at
E
and
what
about
them
because
they
do
put
packets
of
om
packets
on
the
wire
and
they
do
have
their
own
performance
measurement
on
their
layers
on
sub
layers.
If
we
want
to
so
I
think
that
trying
to
generalize
and
look
at
performance
measurement
methodologies
applicable
to
networking
technologies
being
worked
at
ITF,
that
might
be
a
worthy
goal
and
then
try
to
scope
out
specific
encapsulation,
because
specific
encapsulation
should
be
decided
in
appropriate
working
groups.
N
N
H
C
Brian
Trammell
as
an
individual
I,
really
like,
where
you're
going
with
that
I
think
the
key
is
so
it's
it's.
So
there's
commonality
and
methodology.
That's
very
interesting
one
of
its
it.
It's
not
interesting
because
it
saves
code,
although
it
also
saves
code.
It's
really
interesting
because
you
start
to
get
comparability
across
these
different
layers
and
that's
not
a
thing
that
we've
ever
really
had
and
I.
Think
part
of
the
reason
that
we
haven't
had
that
is
that
there's
a
little
bit
of
a
firewall
between
TSV
and
ops
on
this
that
shouldn't
be
there
right.
C
I
mean
like
I,
mean
the
way
that
we
don't
have
that
firewall
or
there
are
people
who
participate
on
both
sides
like
yourself,
I
am
chair
head
on
I
am
not
sure
how
to
write
charter
text
for
that.
It's
hard
right.
So
so,
there's
a
I
think
we're
opening
up
a
bigger
question
that
we
it's
good,
that
we
have
the
time
an
agenda
to
discuss
is.
Is
this
a
thing
that
other
people
in
the
room
are
interested
in
opening
up
and
basically
saying?
Okay,
we
we!
We
have
these
methodologies
and
things
like
Altmark
work.
C
Do
we
want
to
bring
essentially
convergence
in
metrics
methodologies,
not
protocols,
not
encapsulations,
but
in
metrics
methodologies,
and
have
comparable
metrics
across
that
boundary.
Discuss
I
I
think
we
do
I'm,
not
sure
how
to
scope
it.
So
the
problem
is,
is
that
is
that
my
Eve
scoping
that
I
would
write,
for
that
puts
a
whole
bunch
of
stuff
in
scope
that
really
shouldn't
be
in
this
room.
Great
I,
don't
know,
I,
think
that
by
saying
that
we're
going
to
we're
going
to
measure
take
these
metrics
that
we
have
experience
with
and
take
these
methodologies.
C
N
C
Well,
I
mean
we
we
do
want
to.
We
do
want
to
continue
maintaining
our
own
act
of
measurement
protocols
on
top
of
IP,
where
we
do
have
our
wire
format
straight
so
I
mean
we
need
to
do
it
in
such
a
way
that
a
rampant
he
went
for
me
in
in
scope,
but
and
anything
else
we
come
up
with
on
the
IP
side-
remains
in
store.
N
N
Okay:
okay,
in
my
other
experience,
so
we
do
have
bi-directional
forwarding
detection
for
kind
of
continuity,
verification
between
systems
leave
denotes
that
is
applicable
to
IP.
It
was
that
technology
was
developed
and
defined
in
VD
working
group,
but
applicability
to
MPLS
is
an
MPLS
working
group
as
long
as
doesn't
change
the
BFD
based
protocol
and
so
in
all
other
groups,
so
applicability
of
BFD
as
a
protocol
to
different
layers
as
long
as
doesn't
affect
the
FD
based
is
done
on
this
working
groups
and
then
for
be
of
these
FYI.
C
Seems
like
a
again,
it
seems
like
a
very
good
arrangement.
I
think
we
need
I,
think
we're
now
I
think.
Actually
what
we
should
do
is
we
take
to
the
list
a
new
paragraph
that
essentially
talks
about
the
scoping.
Then
we
refer
to
at
Ford
from
the
from
this
paragraph,
and
then
we
make
any
changes
that
need
to
happen
in
this
paragraph.
That
contradict
it
right.
So
I'd
like
to
keep
I'd
like
to
keep
IP
in
the
name
of
the
working
group,
because
it's
been
AI
ppm
forever.
B
Tell
Mizrahi
again
so
I
think
the
work
we're
doing
today
already
goes
beyond
the
scope
of
IP
in
some
cases,
so
I
think
as
an
exercise.
One
thing
we
can
try
to
do
is
remove
IP
from
the
Charter
and
see
what
what's
the
result
and
think
consider
whether
that's
valid
or
not.
Another
thing
we
can
do
is
just
add
a
paragraph
that
says
in
some
cases
the
methodologies
will
go
beyond
IP
and
that's
still
part
of
the
scope
of
the
working
I
think
those
are
two
options
we
can
think
about.
D
C
O
Oh
Cisco
I,
also
like
the
spirit
of
what
Tali
saying,
I
I,
think,
there's
great
value
in
that.
How
that
translate
to
the
Charter,
however
I
could
be
I
would
really
try
not
to
innovate
too
much
on
the
wording
on
this
part
and
Libby
disease.
I
would
actually
much
rather
have
a
targeted
paragraph
stating
what
you're
talking
on
the
other
slide
leave
IP
leave
everything,
as
is.
In
addition,
the
working
group
will
blah
blah
blah
I.
Think
that's
a
much
safer
way
of
not
attacking
the
government.
C
Thank
you.
If
I
may
make
a
comment
again,
all
right,
I'm
gonna
make
a
I'm
gonna
make
a
non
chair
comment:
cuz
I'm,
getting
I'm
tired!
So
is
it
safe
to
say
that
we
are
not
interested
in
methods
or
metrics
that
are
not
measurable
at
IP
at
all,.
C
Right,
so
it's
like
the
the
way
that
we
decide.
Things
are
in
scope
or
out
of
scope
are,
if
it's
not
applicable
at
IP,
then
it's
out
of
scope
here,
if
it's
applicable
at
IP
and
applicable
at
other
layers,
then
it's
in
scope
here
and
we
should
make
sure
that
we
explore
the
applicability
those
other
layers.
O
Way
of
reading
it
right,
it's
because
you
know
within
the
Charter
you're
trying
to
get
clarity
both
what's
in
and
what's
out,
yep
and
you
know
if
it
is
for
AP
it's
in,
but
it's
also
within
Charter
to
go
and
explore,
and
you
know
the
other
thing
that
I
the
other
word
key
word.
That
I
think
needs
to
be
on
the
Charter
as
a
goal
is
collaboration,
collaboration
with
other
working
groups,
yeah.
E
O
C
C
P
Dave
Allen
Erickson.
Actually
your
last
comment
pretty
much
I
code
where
I
was
going
to
go
because
when
you
start
talking
non
IP,
you
make
me
a
bit
nervous
and
the
reality.
What
you're
talking
about
is
a
ETF
technology.
Yes,
and
if
that
was
if
that
was
simply
made
clear,
because
just
about
everything,
that's
not
I
P
in
the
IETF
is
some
form
of
IP
helper
oration.
C
C
A
bunch
of
satellite
protocols,
yeah
exactly
yeah
yeah,
so
I
think
I
think
a
good
way,
so
so
that
this
makes
me
a
lot
more
comfortable
with
this
than
when
Tom
first
got
up
I.
Think
by
basically
saying
that
the
scope
is,
you
know,
is
applicable
on
an
IP
network
than
yes
and
let's
look
in
the
other,
the
other
layers
that
it
might
be
applicable
at
in
foster,
cross
layer
collaboration.
We
don't
wanna,
say
crops
layer
in
the
IDF,
but
you
know
there's
sports
nothing
to
be
done.
P
C
C
That's
pretty
good,
okay
cool.
That
sounds
like
an
answer:
let's
actually
get
through
the
really
easy
editorial
stuff
now
so
I
think
I
think
we're
gonna
have
to
do
a
little
bit
more
wordsmithing
here
and
we're
gonna
have
to
take
this
discussion
to
the
list.
I
think
we've
got
good
input
from
the
from
the
in-person
discussion
here.
I
think
that
this
is
we
can
get
to
something
that
we
can
iterate
on
relatively
quickly.
I
think
I
understand
where
the
scope
is,
though,
are
you
happy
with
you
think
we
can
bang
this
out?
Okay,
all
right!
C
There
was
a
comment
that
we
might
want
to
remove
the
dependency
on
63
90s,
since
EMDR
doesn't
really
seem
too
much
of
a
going
concern
anymore,
but
I
think
that
the
the
framework
in
63
90
we've
actually
figured
out
how
to
work
with
it.
So
I
don't
see
any
reason
to
actually
pull
this
out
like
it's
as
a
as
a
base
performance,
metrics
template.
It's
actually
pretty
good
as
a
performance
metrics
template
that
defines
how
you
measure
things:
we've
kind
of
augmented
it
with
the
registry,
so
I'm.
D
F
C
C
C
One
is
we
we
talked
about
context,
so
anything
that
we
can
get
like
just
a
metric
in
isolation
doesn't
give
you
anything
really
optional
right.
A
metric
and
isolation
with
a
couple
of
endpoints
and
some
type
P
gives
you
a
little
bit
more
a
metric
along
with
all
of
the
metadata
about
how
it
was
created.
You
know
which
tools,
how
was
the
measurement
set
up?
References
to
other
things
is
much
more
useful
and
comparable
right.
C
So
our
goal
and
I
like
the
where
we
got
sort
of
in
the
the
more
points
I'm
charter
on
what
our
goal
is,
is
we're
really
at
a
point
now,
where
we've
got
the
metrics?
We
have
some
experience
with
them.
Now
we
want
to
foster
comparability,
and
one
of
the
big
ways
to
foster
comparability
is
to
make
sure
that
when
you're
looking
at
measurements,
you
know
as
much
about
the
environment
in
which
the
measurement
was
taken.
As
you
can.
C
This
was
this
text.
Was
written
to
be
extremely
general
and
we
thought
it
might
be
useful
to
add
some
examples
here
in
order
to
make
it
clear
what
kinds
of
of
context
information
we
think
is
interesting,
so
measurement
implementation
information,
not
just
with
which
methodology
were
using
but
which
revision
of
which
tool
was
being
used
because
there
are
always
bugs
in
inactive
measurement
methods.
C
There
are
always
bugs
in
passive
measurement
methods,
you'd
like
to
be
able
to
know
whether
you've
got
invalid
rows,
because
you
found
a
bug
later
and
it's
like
okay,
well,
I
can't
rely
on
it
any
more
conditions
on
the
networks
in
which
measurements
are
taken.
So
you
know
if
you're
in
especially
this
is
especially
important
for
passive
right.
C
So,
if
you're
doing
or
even
active
right,
if
you're
doing
a
study,
that's
using
a
lot
of
ripe,
Atlas
notes,
knowing
about
the
the
load
condition
on
those
ripe,
Atlas
nodes,
it
turns
out,
gives
you
information
about
the
fidelity
of
the
measurements
that
you're
running
and
or
information
about
the
data
plane.
Topology
of
these
networks,
we
have
a
whole
bunch
of
work
on
spatial
composition
of
metrics
across
paths
and
no
way
to
measure
what
those
paths
are.
C
So
this
is
this
is,
let's
think,
about
trace
route
and
other,
and,
let's
think
about
in
Vandal
Yemen.
Let's
think
about
other
ways
that
we
can
get
path,
information
into
our
metrics
lots
of
methods.
C
The
second
one
is
something
that
actually
came
up
after
our
discussion.
Alright,
let's
let's
talk
about
the
first
one
is
so
this
is
not.
It
says,
for
example,
but
not
limited
to,
and
this
is
really
clarifying
clarifying
text,
so
we
can
probably
do
without
it,
but
it
says
that
right
now
we're
pointed
in
the
direction
of
looking
at
these
sorts
of
information,
because
we
also
don't
want
to
say,
hey
we're.
Gonna
collect
a
lot
of
metadata,
including
the
user
identifiers,
are
the
people
who
are
involved,
because
that
would
not
work.
So
we
want
to.
C
J
J
Just
thinking
of
situations
like
if
you're,
using
ICMP
and
ping,
not
every
router
renderer
handles
ICMP
packets
in
the
very
same
way
which
impacts
what
you're
getting
it
as
an
outcome
of
that
particular
measurement,
especially
thinking
of
the
earlier
conversation
that
we
were
having
around
using
ICMP
as
part
of
the
registry
for
metrics,
that
other
people
will
well
use
for
decision-making
or
qualification
of
a
network.
So
is
that
something
that
we
could
go
and
add
here
is
that
in
the
sea.
C
Gives
you
a
better
idea
about
comparability?
No,
in
that
we
actually,
these
are
so.
The
contextual
information
is
on
a
collection
of
measurements
in
the
error
bar
should
be
on
each
measurement
right
if
I
have
a
long
series
of
pings
over
a
peep
over
a
period
of
time
that
are
between
52
and
53
and
1/2
milliseconds
I
have
a
pretty
good
idea
that
that
52
is
I,
mean
it's
it's
within
you
know,
I
have
high
confidence
in
that,
because
I
have
a
thousand
of
them
and
they're
all
about
the
same.
C
E
C
Measurement
so
so
I
think
that
methods
for
measuring
the
confidence
in
for
the
types
of
measurements
that
we've
done
so
far
measurement
methods
for
quantitate
Kwan
quantifying.
The
confidence
that
we
have
in
measurements
are
still
seems
to
me
to
be
on.
A
single
measurement
is
a
is
an
open
area
of
research
right
like
being
able.
C
Hard
right
having
the
ability
to
I
mean
there
are
other.
There
are
other
methods
where
you
can
like.
There
are
other
methods
where
you
can
do
cryptographic
things,
for
example,
where
you
have
more
confidence,
because
you
can
actually
quantify
the
number
of
bits
that
you
need
to
that
need
to
be
wrong
for
this
measurement
to
be
wrong,
but
in
ping
it's
like
it's
really
really
hard
to
quantify
the
things
that
can
go
wrong
with
ping.
There's
like
a
whole
subfield
of
Internet
research
about
unbreaking
ping,
the.
C
So
yes,
this
is
absolutely
in
scope
here:
I'm,
not
sure
how
to
capture
it,
because
it's
because,
because
that
one
term
captors,
two
different
things
great
and
we
need
to
make.
We
need
to
make
clear
so
I
have
a
note
here
that
we
should
figure
out
how
to
get
that
in.
But
we
need
to
make
clear
that
we're
not
confusing
the
two
kinds
of
confidence.
C
Other
comments
on
this
list
of
examples
I
mean
so
with
with
the
note
please
don't
you
know
put
you
know
every
single
example
in
here,
because
we
it's
a
list
of
examples.
It's
got
like
five
examples
in
it.
Then
it's
good,
it's
goal
is
two
examples
is
20
examples
in
it.
Then
people
are
gonna,
treat
it
as
if
it's
complete
and
if
it's
not
in
the
list
of
20
things,
then
it's
not
on
charter.
I.
Think
we're
good
here.
Are
there
other
comments
on
this
point?
C
Moving
on
to
the
light
green
section,
this
is
actually
some.
Oh,
that's
a
terrible
highlight
we're
gonna
leave
that
one
highlighted
this
is
something
it
actually
came
out
of
the
applied
networking
research
workshop
that
was
held
in
this
very
room
on
Saturday
wow.
It's
been
a
long
week.
C
You
spend
about
80%
of
your
time,
writing
parsers
and
about
10%
of
your
time
assigning
confidence
and
the
other
10%
of
your
time
doing
work.
It
seems
like
there
could
be
a
better
wave
in
this
I
had
personally
I
had
an
offline
conversation
with
some
of
the
right.
That
was
people,
and
they
would
be
a
minimal
to
print
to
to
take
their
experience
with
data
formats
on
their
platform,
which
is
relatively
large.
It
does.
It
does
trace
routing
and
some
response
time.
Stuff
rate,
it's
not
it's
not
a
large
distributed,
Oh
amp
infrastructure.
C
It
seems
like
we
do
know
some
people
who
run
large
distributive
infrastructures
and
we
could
possibly
talk
to
them
about
their
data
models,
but
they
seem
to
be
slightly
heavier
weight
than
what
right
has
done,
and
it
seems
like
this
would
be
a
way
to
have
a
conversation
about.
How
can
we?
C
How
can
you
learn
from
the
experience
of
some
of
these
measurement
platforms
in
order
to
define
ways?
It's
like?
Okay?
Well,
if
you're
gonna
publish
a
thing
like
so
you
say
to
this,
this
broadband
mapping
thing
if
you
publish
it
and
if
there's
a
standard
that
comes
out
of
here,
if
it
says,
you've
referenced
this,
and
this
is
how
we
represent
this,
and
you
know
that
when
you're
parsing
it
that
you
can
use
the
same
person,
it
means
the
same
thing
that
seems
like
it
might
be
very
useful,
so
comments
on
this
part.
O
E
O
I
think
is
fairly
generic,
and
you
know
in
particular
the
one
specific
concern
that
I
have
is
to
is
to
mark
a
you
know,
finer
demarcation
between
working
line,
because
you
know
part
of
the
work
there
is
about
data
models
on
some
OAM
things
which
may
include
some.
You
know
way
in
which
we
export
measurement
data.
O
C
J
J
J
C
Excellent,
so
crow
as
Wilson
text
yeah.
So
one
thing
that
I
think
is
the
problem
here
is
that
in
the
internet
measurement
research,
community
data
model
means
something
very
different
than
it
does
in
the
operations
community.
So
in
that
it's
basically
the
information
model
is
the
set
of
classes
and
sort
of
what
attributes
they
have
in
the
data
model
is
how
you
bang
that
into
a
JSON
object
right.
C
So
it's
much
it's
a
much
lesser
or
or
into
a
sieve
or
object
or
into
CSV,
or
you
know
how
you,
how
you
represent
it
down?
It's
it's
a
much
less
precise
term
of
art
in
that
area
than
it
is
in
so
terminology
in
in
that
was
an
unfortunate
and
unintentional
terminology.
Collision.
C
So
I
don't
want
to
open
mic
the
Charter
at
this
point
because,
like
it's
like,
oh
we
chartering,
let's
put
let's
put
in
some
ponies
and
Spencer's
Spencer
chuckle
means
that
he
would
also
like
us
not
to
do
that.
I'm
Spencer
could
I.
Ask
you
to
come
up
and
take
the
temperature
VAD
on
this
one.
Or
can
you
just
you,
can
you
can
you?
Can
you
give
a
Roman
gladiator
if
you
don't
have
to
walk
all
the
way
up.
C
Okay,
cool
yeah,
let
the
record
show
thumbs
up
from
Spencer
alright.
So
with
that,
let's
talk
about
stuff
related
to
what
we're
okay,
so
that
yeah
the
outcome.
The
action
item
is
bill
and
I
are
gonna.
Take
text
from
Carlos
and
the
comments
that
we
had
here
we're
gonna
propose.
Probably
we're
gonna
stop
talking
about
just
diffs.
At
that
point.
J
J
E
J
So
that
was
a
major
concern.
So
we
edit
that
section
with
kind
of
scope,
specific
information
for
NC
to
OEM
and
the
deployment
domain
I
think
is
specifically
spelled
out
and
we've
done
a
load
of
widsom
I
think
even
over
the
list
to
go
and
get
there.
The
other
thing
that
we
specified
as
part
of
the
scope
section
is
in
situ
OEM
control
points
which
is
encapsulating,
ecaps,
elating
and
transit
nodes,
encapsulating
puts
on
the
header,
be
capsule,
aiding
and
removes
the
header
and
transit
notes,
either
update
or
add
to
the
header.
J
Then
we
also
had
a
clarification
that
NC
to
OEM
not
know
something
doesn't
necessarily
apply
to
all
the
traffic
but
can
apply
to
subsets
off
the
traffic.
And
again
you
can
use
some
classifier
to
decide
on
what
that
subset
of
the
traffic
would
be.
That
goes
well
hand
in
hand
with
other
drafts,
like
we've
seen
the
UDP
ping
or
draft
from
predator
LaPook,
often
team,
so
that
well,
the
UDP
pinger
can
be
used
with
in
situ
OEM,
which
is
why
patter
is
of
co-author
of
the
draft.
J
We
clearly
stated
that
encapsulations
for
inbound
for
in-situ
OEM
will
be
done
in
a
variety
of
different
working
groups:
ie
it's
out
of
scope
for
what
we're
doing
here,
but
it
would
need
to
go
into
the
various
various
transports.
So
exactly
what
the
new
charter
should
go
and
try
to
achieve
so.
The
earlier
discussion
that
well
tell
and
Greg
drove
will
have
multiple
layers.
Eventually,
these
layers
can
all
use
in
situ
OEM
data
formats.
Hopefully
they
all
use
the
same
formats.
J
So
that's
what
we
want
to
go
and
and
achieve
here,
so
that
also
talks
about
the
layering
aspects.
It's
absolutely
possible
that
you
have
a
tunneling
protocol
like
genève,
using
in-situ
OEM
and
underneath
you
have
a
transport
protocol
like
ipv6
using
another
for
for
itself,
flavor
or
instance,
I
have
to
say
often
see
to
OEM
and
well.
Obviously,
you
will
also
want
to
go
on
specify
things
that
they
combine
well
with
other
REM
mechanism.
So
I
already
mentioned
the
UDP
finger
from
patter.
That
comes
along
quite
nicely.
J
In
addition
to
that,
there
is
one
change
that
we've
also
done
for
t1
and
doe
amp,
as
well
as
for
ntp,
that
we
have
a
field
to
make
the
overall
insertion
of
information
that
we
are
adding
checksum
neutral.
So
that's
an
option
so
that
you
don't
have
to
recompute
the
checksum.
If
your
protocol
uses
UDP
but
you're
you're,
staying
where
you
are
and
that's
exactly
the
same
reference
mechanism
and
that's
taken
reference
to
RFC,
seventy
eighty,
seventy,
seventy
eight
twenty
and
seventy
eight
twenty
one-
and
so
that's
another
addition
and
another
change.
J
Given
that
we've
seen
quite
a
few
silicon
vendors,
even
putting
the
thing
into
silicon
as
we
speak,
I
don't
want
to
go
and
iterate
through
the
names
again,
but
we've
seen
at
least
three
public
announcements
plus
we
have
the
open
source
implementation,
so
things
are
moving
and
things
are
moving
quickly.
So,
let's
make
this
a
Sanders
track
document.
J
C
Thank
you
very
much
so
actually,
as
a
procedural
note,
I
think
we're
going
to
just
so.
Everything
is
nice
and
clean
continue
doing
any
further
edits
on
this
as
draft
Bruckner's
until
the
recharter
goes
through
and
then
as
soon
as
that's
happened,
the
adoption
call
that
we
already
did
will
take
effect
right.
So.
C
Q
C
C
Q
J
J
J
R
R
Q
Q
J
Related
question
I
know
is
very
difficult
to
be
resolved
here.
Yes,
so
nothing
from
a
procedural
perspective.
What
I
would
expect
happening
is
once
this
is
a
working
group
document
so
that
we
can
officially
refer
to
that
in
other
working
groups.
We
will
see,
there's
been
this
kind
of
scratchpad
document
that
we
call
the
transport
draft
that
has
yeah.
J
Q
J
C
C
C
S
Knology,
but
when
we
actually
increments
that
we
need
to
consider
what's
impact
to
the
actuary
data
plane
performance,
also,
when
you
consider
in
the
future
how
you
mix
the
solution
really
scale.
So
you
this
proposal,
we
have
a
address
several
issues
or
based
on
some
real
use
cases,
so
I
consume
them
fast.
The
first
one
is
about
how
to
scale
the
to
support
more
data
types.
Currently,
there
are
only
16
beats,
are
used
to
for
data
types
and
support
at
most
16
different
types,
but
currently,
for
here
we
have.
S
S
S
So
exactly
wise
to
do
is
a
some
potential
limitation
on
the
past
lands
and
I'm
too,
because
also,
we
may
have
a
just
limited
budget
to
hold
the
IOM
data.
If
the
past
is
very
long-
and
you
know
the
overhead
may
be
too
large
so
to
solve
resolve,
this
issue
will
be
proposed
to
use
van
David
beats
to
indicate
the
segment
IOM.
S
So
the
contents
then
given
the
IOM,
is
that
we
give
a
fixed
size
of
the
segment
and
we
only
hold
the
IOM
data
up
to
that
segment
in
image
and
answer
sending
in
the
head
will
remove
the
header
and
just
send
the
data
to
some
mental
insanity
and
we
started
working
and
we
addition
this
Lancefield
into
two
parts.
The
first
part
is
for
pete's
you
to
indicate
second
in
size,
which
means
that
you
segment
can
be
up
to
sixteen.
S
Sixteen
Hawks
and
the
sectional
cards
are
useless.
You
still
to
indicates
the
remaining
hops
in
the
segment,
so
there
are
some
also
some
use
cases.
For
example,
if
you
have
you
have
we
have
fixed
budget
to
hold
the
IOM
data,
we
can
calculate
how
many
hops
weakness
support
each
segment.
Then
we
can
see
the
segment
that
Courtney
okay,
I
was
keep
some
other
your
species
I'm
like
at
the
last.
S
There
are
some
possibilities
for
virus
reason,
some
notes
as
cannot
provide
the
IOM
data
or
cannot
provide
part
of
the
data
so
how
to
handle
that
we
proposed
user
data,
know
the
bitmap
to
indicate
which
node
is
a
is
valid
to
provide
the
IOM
data.
So
if
some
note
can
pass
a
header-
but
they
prefer
to
note
added-
is
own
dated
to
the
to
the
to
the
full.
An
old
bank
and
just
research
is
respond,
engage
in
a
bitmap
so
that
which
means
the
following
data
list.
That's
no
parity,
there's!
No!
S
Similarly,
for
each
for
each
node,
I
have
another.
We
have
another
relative
bitmap,
so
in
the
case
of
which
data
is
that
this
is
actual
valid
or
not,
which
means
that
it
and
you
use
kisses-
is
that
you
know.
Sometimes
maybe
the
traffic
is
very
heavy
and
the
no
just
cannot
keep
publish
if
want
to
add
data
to.
The
note,
maybe
is
in
danger
of
drops
the
package
so
in
this
case
is
rather
to
note
add
new
data
to
that
after
that,
to
the
node
I
can
simply
set
the
amenities.
C
I
I
I
Well,
this
is
just
a
tour
network
to
make
our
examples.
We
have
a
source
and
destination
nodes
and
some
routers
in
the
middle
next
slide.
Please
here
we
want
to
identify
a
particular
flow
from
source,
choose
a
destination
and
in
particular,
the
flow
is
identified
for
IP
source
address,
IP
destination,
address
the
port
source
number
and
the
port
source
destination,
and
also
the
protocol
next
slide.
I
Please
we
we
can
see
that
normally
there
are
different
flows
from
source
to
destination,
because
the
different
routing
policies
or
balancing
something
like
that,
and
we
want
to
measure
the
different
flows.
The
idea
is
to
measure
round-trip
delay
from
source
to
every
intermediate
hope,
and
we
want
to
call
this
T
I
is
the
intermediate
hope
and
the
cost
identification
is
the
IP
ingress
interface
for
active
measurements
or
alternative
alternative
identifiers
in
the
case
of
in
situ
or
all
a.m.
I
we
also
call
this
cover
our
cost.
According
to
our
FEC
eleven
twenty
five,
twenty
two
in
this
case,
the
host
she
do
not
decrement.
Ttl,
therefore,
is
not
discoverable
next
slide.
Please
we
identify
two
different
things:
route
member,
which
is
for
a
particular
flow,
in
this
case,
the
green
one,
which
is
the
set
of
round
two
times:
TI
t
BG
e,
TK,
TM
and
destination,
and
also
route
and
sandal,
which
is
the
every
possible
flaws
in
in
order
in
in
the
thus
except
hops
distance
from
the
destination
next
slide.
I
I
Here,
we
we
propose
to
use
polystrate
route,
which
is
a
tool
developed
in
2006,
and
you
embarrass
ons,
because
this
is
a
floor,
Y
stool,
which
means
that
can
identify
in
99%
of
cases
every
hope
for
every
flaw
that
you
that
that
Tron's
a
source
and
destination
we
we
have
different
tools
like
scampers
companies.
This
base
is
a
very
includes
many
other
features,
but
also
implements
this
idea,
a
proposed
for
Paris
trail
route.
I
Also,
the
the
field
dscp
in
order
to
to
be
the
to
be
observer
as
the
same
flow
for
UDP
is
a
little
more
complicated
because
we
want
to
ensure
the
backward
part.
I
mean
we
are
measuring
round-trip
time
we
can
measure
just
we
can
no
chance.
The
IP
of
the
hope,
the
ingress
IP
number,
but
the
backward
packet,
which
is
a
CMP,
can
follow
different
paths,
the
IDH
to
maintain
the
idea
to
follow
exactly
the
same
part
for
this
cop.
This
particular
hawk
for
that
we
need
to
observe
the
UDP
checksum
and
well.
I
I
Well,
what
what
are
the
goals
to
measure
this
round-trip
time
here?
We
have
like
four,
but
perhaps
there
are
more.
In
particular,
we
want
to
identify
Intercontinental
summary
links,
satellite
communications,
congestion,
entitlement
cuts,
I
added
some
articles
related
with
this
for
problems
in
particular
congestion,
is
a
little
tricky,
the
definition,
but
the
paper
that
I
highlighted
for
this
item
is
related
to
compare
the
minimum
RTT
versus
the
actual
RTT,
and
when
you
see
some
some
variation,
you
can
see.
I
This
is
the
the
reason,
because
we
want
to
to
find
some
kind
of
indicator,
some
kind
of
measurement
that
can
get
some
idea.
Well,
what
is
happened
please
next
line,
then
our
idea
of
statistics
is
based
mainly
on
well
on
traceroute.
Oh
I
forgot
to
put
a
debris,
it's
the
rich
method,
but
in
this
case,
if
we
use
trade
route,
we
should
use
something
like
a
straight
route
with
asurs
the
the
road
and
the
idea
is
to
use
quantities
for
represent
each
cob.
The
quantities
are
I.
I
Well!
This
is
the
the
algorithms
that
show
an
example.
What
we
are
having
in
our
mind,
we
we
are
sampling
during
some
time
window.
We
use
some
time
between
two
measurements.
We
say
if
you
want
to
be
exhaustive,
which
means
explore
every
every
possible
path,
every
possible
route
for
every
flow
of
just
a
single
flow
and
we
got
destination
and
the
output
is
the
de
Qantas,
and
this
is
very
simple.
Just
to
you
got
a
loop
during
the
time
window.
I
I
We
have
to
incorporate
some
standard
turn
for
FEC,
21
and
19.
We
have
to
define,
discover,
cost
in
terms
of
the
RF
EC
1122,
perhaps
an
idea
more
more
more
complete
than
that.
We
we
need
to
make
a
clear
parallel
lines
about
what
can
be,
can
be
detected.
The
parallel
means,
for
instance,
for
hops,
which
means
perhaps
the
same
distance.
Three
hops
away.
You
get
three
different
eyepiece,
but
then
problem
with
that,
it's
some
roads
can
have
more
links
than
another.
I
I
There
are
several
are
just
to
disk
to
discuss
between
crude
metric
and
in
situ.
Oh
I
am,
for
instance,
how
what
happened
with
the
checksum
is
happy,
remove
and
okay,
how
to
deal
with
that,
and
also
more
feedback
are,
will
come
next
slide.
Please
well
with
this
slide.
I'm
finish.
If
you
have
some
questions
will
be
happy.
Thank
you.
N
I
K
I
I
E
N
N
Go
out
it
basically
that
you're
crossing
the
saying
they
routed,
yes,
crossing
the
same
interfaces,
links
who
knows:
okay,
the
similar
problem
being
identified,
for
example,
in
the
lag
because
there
are
different
hashing
mechanisms.
So
what
they
came
up
is
that
realized
and
protocol
that
pins
flows
to
the
particular
constituent
link.
N
I
Okay,
you
can
use
anything
before
for
the
forwarding
one,
but
normally
the
the
problem
arises
in
the
return
path.
Yes,
I
know
there
are
different
hashes
methodologies,
but
normally
the
poly
straight
route
normally
works
for
the
return
path.
True
because
they
try
to
maintain
several
fields,
constant.
I
N
I
It
depends
because
I
already
said
to
do
one-way
image
measurements.
You
need
to
give
to
to
get
some
support
in
the
intermediate
hops,
which
is
normally
it
doesn't
exist.
I
perform
a
lot
of
trash
route
around
the
internet,
and
even
if
you
want,
if
you
need
to
to
use
IP
timestamp
option,
normally
is
not
supported
for
intermediate
routes.
It's
really
hard
to
get
information.
What
you
are
not.
I
N
I
C
All
right,
thank
you
very
much
and
Greg
don't
go
away,
so
that
concludes
sort
of
three
chartering
and
work
covered
under
the
reach
or
during
the
intention
for
actually
for
the
previous
one
is
to
ask
for
adoption
at
some
point
after
the
Charter
is
in,
because
we
can
do
that
either
on
the
list
before
Singapore
or
in
Singapore.
I
presume.
C
Okay,
so
we'll
do
that
between
now
and
Singapore,
if
it's,
if
it's
ready,
if
you
guys
want
to
rev
one
or
two
more
before
then
just
let's
take
that
to
the
list
all
right
now
we're
going
to
talk
about
TM
TM
plight,
TM
test,
and
you
know
how
we're
going
to
fix
the
the
ambiguity
about
these
that
we've
had.
This
is
actually
kind
of
an
externally
clocked
things.
I
brought
this
work,
even
though
there
hadn't
been
a
whole
lot
of
discussion
about
this
on
the
list.
C
This
actually
came
in
from
BBF
requesting
a
way
to
get
a
port
assign'd
40
mm
test
traffic,
where
the
control
I
understand
the
BBF
application.
The
control
is
actually
happening
over
to
your
69
or
something
comparable
right.
So
it's
like
there's
a
BB,
F
control,
plane
and
then
t1
test
on
the
data
plane.
So
you
need
a
port
for
this,
so
you
can
actually
do
control
with
it,
and
this
seems
like
a
good
opportunity
to
have
the
what
is
T
lamp.
What
is
T
went
up
test.
What
is
control
it
are.
C
N
N
N
We
had
a
discussion
in
the
round
in
Chicago
and
there
was
a
great
discovery
made
in
Chicago
that
when
T
womp-womp
and
t1
protocols
went
through
Ayana
processing,
both
received
not
only
tcp
ports
for
their
control
protocols
but
were
allocated
the
same
number
from
the
UDP
port
range
and
they
were
accordingly
assigned
to
all
WAMP
control
and
t1
control.
So
we
changed
request
for
allocation
to
port
reallocation
to
take
these
ports
that
being
allocated
for
control
protocols
and
allocate
them
to
test
protocols
respectively
or
one
test
protocol
and
t1
test
protocol.
N
So
this
is
a
capture.
What
we're
proposing
the
port.
862
tcp
is
used
for
t1
control
protocol
and
it
was
allocated
a
UDP,
862
and
assigned
to
t1
protocol.
So
the
recommendation
is
to
reassign
to
t1
test
protocol
as
T
WAMP
receiver,
reflector
port
and
use
it
as
default
port
in
t1
test
so
effectively.
This
is
all
what
this
proposal
does.
D
Controlling
T
web
test
based
measurements
using
alternative
means
is
an
idea,
and
it's
a
good
idea.
I
think
t
lamplight
also
suggested
this
idea,
but
we'll
talk
about
that
more
in
a
minute.
Allocating
a
port
for
tia
when
test
would
help.
Obviously-
and
that's
this
precise
request
from
BBF,
so
I
proposed
this
reallocation
solution
in
Chicago
in
discussion,
at
least
with
three
or
four
different
folks,
and
then
we
also
had
this
question
about
what
is
T
Wham
that
came
up
in
the
meeting.
D
So
I
decided,
let's
write
a
draft
or
I'll
write
a
draft
that
solves
all
the
questions
that
emerged
in
Chicago
and
answers
the
questions,
I
think
in
the
in
the
best
way.
So
we
don't
have
an
ability
to
negotiate
the
use
of
a
template
without
the
control
protocol,
and
that
was
a
key
consideration
and
whitie
went
late,
got
moved
to
an
appendix.
It
was
actually
Lars
Gertz
ad
comments
that
caused
that
to
happen
and
further.
D
We
we
actually
had
to
reinforce
that,
because
t
want
light,
which
only
mentions
the
test
protocol
and
has
proprietary
means
for
other
communication.
It
basically
has
no
way
to
communicate
the
required
keys
in
order
to
operate
in
a
secure
mode,
and
so
it
had
to
be
sort
of
relegated
to
this
appendix
and,
as
we
know,
it's
mandatory
for
all
the
protocols
in
ITF
to
have
sort
of
mandatory
to
implement
security
features.
D
So
that's
kind
of
the
background
and
I've
got
more
detail
on
the
draft
and
especially
links
to
the
messages
that
that
discusses
and
ad
comments
and
so
forth
that
resulted
in
this
lineage.
But
that's
why
it's
a
very
simplistic
requirement
for
the
both
the
control
protocol
and
the
test
protocol
in
O,
amp
and
T
lamp
to
be
together.
So
let's
talk
about
that,
but
first
of
all
we're
going
to
recall
RFC
77
99.
D
We
had
to
go
back
beginning
in
Hawaii
and
define
what
active
and
passive
and
the
new
form
of
measurements,
which
were
very
glad.
We
define
now
the
hybrid
type,
1
type,
2
and
spatial.
It
was
very
good
and
very
important
to
have
an
RFC
that
defined
things
clearly
for
our
work.
And
why
do
we
need
to
do
that?
Because
we're
a
standards
group,
we
have
to
have
definitions
of
terms
that
we
can
refer
to
unambiguously
and
when
we
don't
have
those
we
can
use
the
dictionary.
The
dictionary
is
usually
pretty
good
too.
D
We
can't
define
every
word
in
the
English
dictionary
here.
So,
let's,
let's
not
waste
our
time
with
that
so
for
have
in
order
to
have
unambiguous
terms
in
om,
panty
WAMP.
We
have
to
consider
the
text.
That's
there,
so
L
WAMP,
actually
that's
an
important
word
here.
It
actually
consists
of
two
interrelated
protocols,
om
control
and
om
tests,
and
when
you
look
at
the
dictionary
definition
of
consists,
it's
very
explicit.
D
It's
made
up
of
composed
of,
and
there's
no
ambiguity
here,
it's
to
two
protocols,
so
the
oh
way
up
control
and
when
tests
are
defined
in
sections
three
and
four
and
we've
got
a
very
similar
section
sentence
in
T
wimp.
It
consists
of
two
interrelated
protocols
again,
and
it
refers
back
to
the
Oh
wimp
definition
and
remember
neither
of
these
documents,
standards
track,
Oh,
amp
and
standards
track
TM.
They
would
not
have
gone
through
the
iesg
successfully,
but
they
didn't
have
both
the
control
and
the
test
protocol.
As
mandatory
points.
D
So
what
is
TM
polite?
It's
basically
an
idea.
It's
not
this
light
bulb
necessarily,
but
of
that
sort
it
could
be.
The
point
is
that
T
WAMP
light
is
really
just
an
idea.
It's
an
informative
appendix
it
gave
the
possibility
for
other
forms
of
control,
but
it's
just
some
information.
There's
not
enough
information,
they're
done
of
detail
for
anyone
to
claim
compatibility
with
t
way
of
life.
There's
too
many
details
left
wide
open
and
so
a
rigorously
specified
set
of
protocols
that
reuse,
T
web
test
truly
need
a
new
name.
D
Bbf
has
our
own
spec
number.
So
there's
no
ambiguity.
There
I
think
that
will
work
fine.
But
if
we
work
on
things
here,
we
need
a
different
name,
other
than
T
went
light
as
well.
So
in
my
proposal
we
do
what
I
said
in
Chicago
and
we
do
it
for
both
o
WAMP
and
T
when
we
basically
take
this
is
the
UDP
assignment
and
it
used
to
be
control.
Now
it's
test
and
I've
been
thinking
about
this
for
a
long
time.
D
In
fact,
when
I,
when
I
wrote
the
I
Anna
section,
40
Wham
I
really
just
followed
what
they
had
done
in
Owens,
and
it
wasn't
the
right
thing
to
do,
because
the
control
protocol
is
TCP
only
and
the
test
protocol
is
UDP
only
so
if
we
were
gonna
sign
a
port,
it
should
have
been
40
wins.
14
want
test
to
know
when
test
so
I'm
fixing
my
own
mistake.
How
about
letting
me
do
that.
D
So
here's
the
proposal,
we
clarify
the
names
of
our
protocols
for
the
industry
standards.
Traco
WAMP
is
a
two
protocol.
Suite
standards
track.
T
win
is
a
two
protocol
suite
we
reallocate
the
well-known
ports.
That's
the
simplest
solution
here,
shouldn't
gonna
any
worry
about
that,
and
also,
let's
take
a
let's,
take
a.
D
Why
worried
approach
to
what
we
do
with
the
what
we,
what
we
let
the
implementations
do
with
these
ports,
it
would
be
pretty
easy
to
try
to
specify
something,
but
you
know,
although
all
the
standards
track,
tyo
implementations
are
out
there
doing
what
they
wanted
to
do
without
this
help.
It's
the
new
protocols
that
take
the
benefit.
So,
let's,
let's
let
those
guys
specify
the
specifications
to
keep
themselves
from
shooting
themselves
in
the
foot
by
having
this
one?
Well,
no
port.
Maybe
multiple
tests
trying
to
contact
that
loan,
then
port.
Q
Like
char
'm
as
a
shadow
room,
do
I
brought
I
think
what
you're
saying
is
that
the
light
version
does
not
have
the
control
protocol.
That's
what
it
is.
That's
right
and
you're
saying
that
won't
be
the
t
vamp,
that's
what
it's
definitely
not
t1,
so
it's
like
Oh
MPLS,
also
they
used
to
say
you
must
have
a
leafy
or
RSVP
and
then
eventually,
so
you
can
configure
it.
You
can.
D
F
E
N
So
it's
yeah,
you
basically
have
Sdn
environment
and
you
don't
have
a
dynamic
distributed
protocol.
So
it's
a
little
bit
different
paradigm.
So
if
we
can
agree
that
tea
womp
uses,
distributed
control,
plane
protocol
and
uses
t1
test
protocol,
and
then
we
can
discuss
whether
we
work
on
something
which
is
using
Sdn
control
environment
and
then
we
talk
about
test
plane
separately.
D
B
N
My
view
what
t1
control
is
so
the
t1
control
is,
is
distributed,
control
plane,
similar
to
LDP,
you
RSVP,
which
is
does
label
signaling,
okay
to
instantiate
MPLS
LSP.
But
at
the
same
time
now
we
are
developing
data
models
that
allow
that
to
do
without
LDP
RSVP
from
the
same
Sdn
controller.
So
I
think
you're
agreeing
with
my
definitions
that
yeah
I'm
perfectly
fine
that
basically
we
can
say
that
T
WAMP
consists
of
distributed
control
plane,
which
instantiates
test
instances.
G
N
I
think,
okay
in
my
understanding
of
our
draft
is
the
difference,
is
that
it
addresses
or
womp
right,
which
is
good,
proactive
measure,
I
agree
with
it,
and
then
it
clarifies
the
terminology
which
is
fine
too.
So
we
can
I
think
that
will
be
easy
to
merge
the
two
drafts
and
because
I
don't
see
anything
that
you
know
questionable
in
Al's
work
and
we
have
some
security
considerations.
Section
I
think
that
might
be
useful
too.
C
C
C
C
N
Okay,
so
let's
keep
in
mind
we're
talking
about
stamp
again,
so
this
is
what
we're
talking
about
it.
What
I
think
that
we
kind
of
converging
agreeing?
We
have
configuration
client
as
the
environment
that
talks
to
session
sender
and
session
reflector
of
the
same
tira
of
the
same
stamp
test
session,
correct
that
okay.
So
what
were
the
changes?
We?
We
have.
Two
coffers
joined
us
and
we
modified
some
of
extended
some
of
their
metrics
calculation
back
into
a
statistic:
percentile
percentiles,
the
three
percentiles
that
can
be
programmed
by
default,
they're.
N
Ninety
five,
ninety
nine
and
ninety
nine
point:
nine
they
defined
as
a
floaties
with
the
two
decimals.
So
basically
it
could
be
not
ninety
nine
point
nine,
but
it
could
be.
Ninety
nine
point.
Ninety
eight,
for
example,
but
the
same
person
tile
applicable
to
all
measurements,
to
one-way
near
and
far
delay
in
the
round
trip
and
to
one-way,
near
and
far
and
round
trip,
delay
variation.
N
We
had
some
discussions,
whether
it's
flexible
enough
and
that
we
appreciate
the
consideration
and
the
feedback,
whether
the
same
person
tiles
to
be
reported
for
all
these
metrics
or
there's
some
use
case
where
you
have.
You
want
to
have
a
different
person
to
house
reported
for
different
performance,
metrics
and
DCP
handling
mode.
N
So
this
is.
These
are
some
examples
of
the
changes
being
applied.
I
just
don't
want
to
read
them
out
loud.
You
can
look
at
the
materials
and
being
uploaded
or
just
run
diff
between
version,
seven
and
nine.
You
can
skip
version
eight,
so
periodic
testing
mode
for
session
Center,
as
we
I
think
they
discussed
in
back
in
Chicago.
We
differentiate
two
test
modes,
continuous
and
periodic
in
continuous
the
test,
packets
being
generated
continuously
and
then
operator
can
define
the
peer
of
calculating
metrics
in
theoretic
testing
mode.
N
Each
text
test
session
has
certain
time
it
runs
and
then
it
seeds
and
after
certain
time
out
period,
all
their
packets,
all
information
being
collected
and
the
metrics
calculated,
but
in
periodic
mode
this
can
go
in
infinite
indefinitely.
So
basically,
you
can
repeat
the
same
test
in
its
duration
indefinitely.
N
In
our
view,
an
hour
and
saying
that
it
might
produce
a
little
bit
different
metrics
because,
for
example,
in
continuous
mode,
we
stop
at
a
certain
time
and
we
don't
wait
for
the
packets
that
might
be
severely
delayed,
or
it's
like
out
of
order.
Delivery
in
periodic
testing
modes,
this
packets,
more
likely
to
be
accounted
for
because
you
have
a
timeout
period
for
your
test
session
associated.
N
N
Percentile
I
already
mentioned
that
we
have
three
levels
that
can
be
configured
and
that
these
three
levels
who
will
be
reported
if
they're
configured
if
they're
non
zero,
they
will
be
reported
for
one-way,
near-far
and
delay
in
deliberation,
so
DCP
handling
mode
being
defined,
because
there
are
some
implementations
that
just
merely
take
a
DCP
value
of
received
test
packet
and
put
it
in
the
reflected
packet.
Or
there
are
some
implementations
that
allow
you
to
configure
explicit
value
for
the
reflector
to
use
for
the
test
session.
N
Q
Am
the
vibrato
I'm
not
related
to
your
draft?
In
general,
we
have
a
problem
measuring
the
average.
No,
so
I
was
I
wanted
to
see.
If
the
has
anybody
worked,
or
has
anybody
proposed
doing
a
running
average
or
weighted
average
in
certain
normal
average
good
to
do
the
average
you
have
to
you
know,
have
all
the
numbers
and
then
add
them
up
and
then
divide
by
the
number
of
packets.
You
have
received
to
get
the
average,
which
is
difficult
to
do,
or
you
need
a
lot
of
memory
for
that.
So
far,.
C
N
Q
Q
D
There's
a
there's
a
kind
of
a
running
average
in
the
RTP
jitter
evaluation-
that's
I
mean
if
you
have
you
looked.
Q
Alright,
so
difficult
is
because
if
you
have
too
many
flows,
let's
say
I
have
I,
don't
know.
10K
flows
I
have
to
first
of
all
a
big
in
the
chip.
I
should
have
a
big
memory
for
so
I
had
to
count.
Those
number
of
you
know
you
need
a
counter
for
add,
and
you
also
need
the
accumulator
for
all
the
add
them
up.
All
of
them
together,
which
is
a
big
number.
So,
instead
of
all
of
that,
I
can
just
have
it.
I,
don't
know
like
16-bit
or
32-bit.
So.
M
M
N
C
C
H
H
So
if
you
think
that
there
are
also
some
application,
when
you
have
a
lot
of
flows
and
a
lot
of
monitoring
points,
the
order
of
magnitude
of
the
mocking
meter
counters
could
increase,
is
NaN,
multiplies
by
hand,
for
example,
so
we
think
about
methodology
in
particular,
for
an
SDN
environment
so
and
to
make
the
performance
monitoring
more
flexible.
So
next
the
flow
classification
as
a
also
tile
mentioned
in
a
previous
presentation.
We
see
that
we
can
identify
the
flow
we
want
to
monitor
with
some
identification
fields,
for
example,
for
an
AP
flow.
H
B
H
You
can
enable
the
performance
monitoring
without
any
constraint
about
the
identification
field,
so
the
type
of
the
kind
of
flow
that
you
can
monitor
in
next
slide
are
very
general,
so
point
to
multi-point
to
multi-point
to
point
flow
and
also
in
general,
multi-point
to
multi-point
flow
next,
how
multi-point
marking
the
first
thing
is.
We
have
to
build
a
graph,
so
we
have
our
production
network.
We
haven't
identified
our
nodes
of
the
graph
that
are
the
monitoring
points.
H
The
measurement
points,
the
link
between
these
measurement
points
that
could
be
real
or
also
withdrawal,
and
then
we
build
our
monitor
ad
network
graph
that
was
composed
by
into
ingress
measurement
point
the
egress
measurement
points
and
intermediate
measurement
points.
Next,
for
this
monitor
ad
network,
we
can
define
the
network
packet
rows,
so
this
is
always
true.
The
packet
rows
property
that
packet
toss
of
this
monitor
and
network
is
the
sum
of
the
input.
Packets
means
the
sum
of
all
the
output
pockets
for
all
output
measurement
points.
H
So
this
is
a
very
simple
rule
and
we
have
the
formula,
but
these
are.
This.
Rule
is
just
general
for
all
the
all
these
multi-point
network.
Next
slide.
We
can
see
how
we
can
recognize
the
cluster
within
our
monitor
ad
network
and
we
can
defy
the
concept
that
is
the
small
s
sub
Network,
maintaining
the
packet
rows
property
for
each
sub.
E
H
So
for
every
we
can
say
that
for
every
complex
network
for
every
multi-point
to
multi-point
flow,
we
can
always
recognize
this
smaller
sub
networks
that
I
have
this
pocket
rows
product.
This
is
also
under
the
study
of
a
collaboration
with
the
university
that
if
we
have
this
complex
network,
we
can
always
recognize
this
cluster
with
the
graph
theory.
Some
graph
theory
consideration
some
algorithm
that
we
can
demonstrate
and
will
be
detailed
in
the
next
version
of
the
draft.
So
next
as
well
of
the
packet
trust,
this
method
can
be
applied
also
to
the
delay.
E
H
Just
last
words,
nice.
So
the
idea
is
that,
for
example,
you
can
see
the
potentiality
of
these
methodology,
because,
if
you,
if
you
think
about
a
nice,
the
oriented
and
Sdn
oriented
Network,
a
controller,
for
example-
can
calibrate
performance
measurement
for
all.
The
network
then
can
in
case
of
problem
in
case
of
packet
loss
in
case
of
height
delay
can
recognize
the
cluster
and
cane
detail
with
the
by
changing
the
the
filter
criteria
or
our
flow
can
recognize
Makassar
and
make
a
per
cluster
or,
in
case
of
needed,
more
detail
at
a
flow
performance
monitoring.
D
B
C
B
So
this
draft
has
been
around
for
a
while,
but
it
has
a
new
title
and
a
new
scope,
and
basically
the
new
scope
of
this
draft
is
it
does
two
things.
One
is
to
define
new
alternate
marking
methods
which
are
compact,
that
is,
they
require
either
one
bit
per
packet
or
0
bits
per
packet.
The
other
thing
we
do
is
we
summarize
all
the
existing
and
new
methods
for
alternate
marking.
B
B
Basically,
if
you've
read
the
alternate
marking
draft,
which
has
past
working
group
last
fall
recently,
you
should
probably
read
this
draft
as
well,
and
you
should
probably
have
an
opinion
about
it
if
it,
even
if
you
haven't
read
actually,
if
you
haven't,
read
the
alternate
marking
draft,
you
should
definitely
read
this
draft
and
we
do
expect
to
get
comments
and
feedback
about
this.
Even
comments
like
this
is
not
useful,
or
this
is
not
interesting,
can
also
help
us,
so
any
feedback
would
be
welcome.