►
From YouTube: IETF105-IPPM-20190724-1330
Description
IPPM meeting session at IETF105
2019/07/24 1330
https://datatracker.ietf.org/meeting/105/proceedings/
A
Good
afternoon,
everyone
this
is
AI
ppm
might
be
performance,
metrics,
oh
no!
It's
not
IP
performance,
metrics
anymore.
We
actually
had
a
conversation
about
that
about
a
year
ago
now,
in
type
II
performance
measurement,
it's
actually
correct
on
the
slides,
I'm
Brian
criminal
co-chair
polychaete.
Are
you
gonna
comment
on
the
name
Matt
thank.
A
A
A
Next
we
have
an
agenda,
it's
extremely
full
I,
don't
think
we're
going
to
get
to
all
of
the
things
on
our
lightning
talk
to
you,
they're
gonna,
look
at
the
status
on
some
of
the
documents
that
are
heading
out.
We're
gonna
talk
a
little
bit
about
next
steps
for
IOM,
then
some
updates
on
these
are
the
ITU
liaisons,
I
guess
alwal
I
will
keep
us
up
to
date
on
how
he's
been
talking
to
himself
I
think
because
you're
you're
both
sides
of
that
liaison
a
very
trip
right.
Oh
no,.
A
Excellent
talk
about
advanced
route,
metrics,
the
multi
altmark,
then
we'll
go
into
the
iom
content
section
of
today's
agenda.
We
have
a
few
individual
drops
that
have
had
list
discussions,
so
we're
gonna
go
ahead
and
give
them
some
you
Jenda
as
well
so
stamp
option.
Tlv
is
actually
quite
a
lot
of
discussion
and
is
basically
ready.
It
was
already.
He
call
for
adoption.
Is
though
yeah
I
know
right.
A
We
have
to
figure
out
that
yeah
exactly
great
screen
team
of
s
rpm
and
then
the
postcard
kilometer
II
stuff,
which
I
understand
there
was
also
some
hackathon
activity
on
the
postcard
telemetry
as
well.
Then
we
have
our
our
lightning
talk
queue.
As
I
said,
there
are
more
here
than
will
fit,
but
if
we
go
fast,
then
all
of
them-
and
if
we
don't
go
fast,
they
will.
C
A
Apologies
to
those
at
the
end
of
this
queue.
So
let's
talk
about
status
updates
we
published
8545.
We
sent
the
registry
drops
to
the
iesg.
It
actually
turns
out
that
I
am
the
I.
There
was
a
miscommunication
on
that
one,
the
on
the
Shepherd
for
one
of
them
and
the
Shepherd
statement
is
incomplete.
He
sends
the
iesg
anyway,
but
I
will
fix
that
this
week,
but
those
should
go
through
relatively
quickly
and
it
was
cool.
D
A
Done
with
it,
but
no
nothing
to
support.
There
was
clear
support
for
adoption
on
the
list
for
stamp
from
TLV.
There
was
a
discussion
about
some
changes
there
requested.
Will
these
be
addressed
in
the
IETF
I
ppm,
zero,
zero
on
Gregor
you
here
or
is
someone
else?
Who
is
a
author
of
that
document
here?
Okay,
so
we
will
note
yeah
we
will.
We
will
note
that
we
as
chairs
would
prefer
to
see
the
resolution
of
that
discussion
in
is
your
zero
Rev
of
that.
So
let
that
be
minute.
A
E
A
Perfect
I
think
personally
and
also
as
chair,
this
was
a
good
idea.
I
think
we
got
a
really
good
on.
This
is
what
sort
of
Crosse
area
contribution
in
the
IETF
and
cross
your
review
in
the
IETF
is
supposed
to
look
like
I
mean
this
came
from
a
different
community
came
in
here
we
got,
you
know
good
feedback,
good
discussion.
There
are
a
few
other
sort
of
like
options
to
add
on
here
that
data.
The
data
model
graft
is
basically
done.
A
Then,
as
we
discussed
a
lot
at
our
meeting
in
Prague,
the
next
set
of
documents,
a
lot
of
them
focused
on
encapsulation
headers.
The
question
that
I
want
to
ask
from
the
chair
is
so
bringing
eilean
and
I
ppm
got
a
lot
of
sort
of
measurement
focused
and
transport
focused
eyes
on
it.
I
think
this
was
a
very
good
thing.
Is
this
room
the
right
place
to
get
the
right
eyes
on
the
in
caps
drafts
so
with
respect
to
the
ipv6
destination
option?
F
So
I'm
a
little
concerned
with
the
broadness
of
these
encapsulations
okay
I
know
so
we
know
about
the
ipv6
yep.
That
makes
sense.
I
am
a
little
worried
that
this
is
going
to
try
to
cover
every
possible
cancellation,
including
some
UDP
encapsulations,
where
questionable
whether
or
not
you
can
even
do
that
participant,
yeah
I
assume
that's
our
visa.
So
what
is
the
scope
of
these
encapsulation
every
kind
of
so.
A
There's
the
set
of
documents
there's
the
set
of
documents
that
have
been
written.
So
that's
the
when
I
say
these
in
calculations,
I
mean
the
documents
that
exist,
and
so
there
was
a
discussion,
for
example,
on
an
ipv4
option
which
is
II
I.
Don't
think
that's
going
to
happen.
Let's
put
it
that
way.
That's
the
non-pejorative
way
to
say
that
is
I.
Don't
think.
That's
going
to
happen.
There
was
discussion
about
an
ether
type
or
about
using
a
next
header
field.
There's
all
of
these
so
they're,
the
encapsulation.
F
A
A
F
F
C
E
C
E
All
a
key
priority
I
think
that's
more
useful
to
decide
so
I
think
we
have
we're
going
on
and
multiple
working
groups
were.
There
is
a
national
home
for
that
particular
in
caption
encapsulation
to
happen.
I
think
the
best
example
was
Ennis
age
was
relatively
straightforward
and,
as
age
got
picked
up
in
SFC.
E
So
I
think
that's
a
good
example.
There
is
work
on
SR
that
happens
in
spring.
There
is
work
on
MPLS
that
happens
in
MPLS.
There
is
work
on
genève.
That
kind
of
happens
in
em
do
three
at
the
pace,
2003
and
but
I
still
believe
that
it's
useful,
even
though
there
is
kind
of
peering
working
routes
that
we
need
one
place,
because
otherwise
you
end
up
with
3x
planing
the
case
to
these
other
working
groups,
especially
if
they're,
fresh
and
new
to
I
is
technology.
E
Despite
the
fact
I
think
that
we've
done
the
shopping
tour
so
many
times,
so
if
we
can
keep
a
handle
and
have
kind
of
a
home
for
the
thing
step,
well,
I
related
and
I
ppm
and
then
go
for
Peoria
be
used
with
the
various
working
groups
in
case
they
are
not.
We
focused
and
willing
to
go
and
pick
some
things
up.
Then
I'd
much
welcome
that,
and
this
also
a
way.
E
E
E
A
E
H
Yeah
maybe
leave
an
area
director.
I
just
want
to
add
one
point,
because,
like
every
working
group
has
a
charter
and
some
of
the
working
groups
I
tread
it
to
do
their
own
extension
and
they
own
a
no
other
work.
We
have
such
extensions,
so
we
have
to
like
look
what's
in
their
chart
as
well.
Not
only
wasn't
the
Charter
and
individual
note
on
what
something
you
said,
I
think
this
is
going
around
and
explaining
it
every
time
to
all
the
people
over
and
over
again.
E
Point
I
think
the
comment
was
more
towards
stuff
that
doesn't
have
a
natural
or
so
certain
things
don't
have
a
natural
like
this
either
type
thing
yeah
it's
hard
to
go
and
find
the
right
place
for
it.
If
you
have
a
have
the
right
place
for
something,
then
well
I
think
we,
both
with
the
exception
of
six-man.
Maybe
we
have
all
the
people
pick
it
up.
That
thought
like
yeah
here
is
the
whole
I
think
the
problem
doesn't
we
exist
where
we
have
a
real
working
group?
A
I
would
I
would
submit
that
would
be
either
tight,
specifically
the
right
people
to
make
the
determination
about
how
to
do
that,
or
definitely
not
in
this
room.
However,
let
me
make
a
suggestion
and
see
if
this
works
for
future.
You
know
for
president
encapsulations,
where
we
don't
know
where
there's
a
home
and
future
encapsulations
that
people
might
be
interested
in
I.
Think
I
ppm
is
a
place
to
discuss
those
and
dispatch
them
out
to
the
place
they
need
to
go
okay.
So
let's
do
that
and.
I
So,
of
course,
we'll
want
to
hear
you
know
more
in
your
talk,
Frank,
but
I
think
the
one
of
the
proposals
I
was
going
to
make
that
we
can
think
on.
While
we're
listening
to
all
of
this
is,
you
know,
definitely
have
a
slot
E&I
ppm
in
which
we
kind
of
get
the
update
of
the
status
of
all
depth,
Nations,
but
I
think
we've
definitely
seen
load-in
lightning
talks
or
in
other
talks
of
individual
presentations
for
given
encapsulations,
for
which
I
think
the
content.
I
We
don't
have
the
experts
in
the
room
to
really
know
whether
or
not
this
is
the
right
direction,
so
I
think,
having
updates
of
summaries
of
how
these
are
all
progressing,
how
we
can
dispatch
how
we
can
help
is
very
productive,
but
we
we
may
want
to
consider
like
when
we
get
requests
for
a
lightning
talk
of
here's.
A
new
encapsulation
say
this
should
instead
be
folded
into
the
update
of
how
we're
expanding
our
encapsulations
throughout
that.
Yes,.
D
J
J
So
here's
the
progress
to
harmonize
on
a
metric
of
IP
layer
capacity,
really
on
the
maximum
IPR
capacity
at
ITT
study
group
12.
We
have
sort
of
moved
their
end-to-end
performance
and
specification
recommendation
by
1540
down
the
approval
line
with
about
39
I.
Guess
it's
about
39
new
pages,
something
like
that.
The
lab
and
field
testing
is
complete
field
tests
with
many
different
access
types
confirm
the
lab
results
that
we've
been
doing
for
about
a
year
now.
So
we've
still
got
some
speed
bumps
comments
to
resolve,
but
we're
on
the
way
to
do
that.
J
So
in
the
etsy
Technical
Committee
on
speech
and
multimedia
transmission
quality,
stq
they've
are
telling
us
that
they've
approved
their
revised
technical
specification
on
high-speed
Internet
kpi's
and
that's
so
that
ones
have
done
for
maximum
IP.
You
air
capacity,
that's
going
to
help
us
get
those
other
comments
resolved.
In
fact.
So
that's
a
good
thing:
I'm,
not
really
working
in
BBF,
but
I've
had
some
informal
discussions
as
I
mentioned
here
at
the
bottom,
but
they
sent
us
a
liaison
here
in
IP
p.m.
J
on
their
quality
of
experience
delivered
basically
three
items
that
are
of
interest
to
folks
here
who
measure
performance
QED
the
application
performance
that
they
are
performance,
that's
done
and,
of
course,
they've
got
IP
where
performance
testing
it's
based
on
stamp
and
Greg
mirskiy
is
working
with
them
diligently
there.
So
the
informal
discussions
I've
had
kindly
set
up
by
Dave
cynic
rope,
I've
encouraged,
taking
up
the
work
on
IP
layer
capacity
and
I'm
gonna
fly
around
Europe
in
September
trying
to
get
that
started
so
we'll
see
how
that
goes.
J
And
so,
let's
see
we
have
the
opportunity
to
discuss
and
possibly
join
the
hardened
organization.
This
week
it
seems
like
we've
got
about
three
three
and
a
half,
maybe
let's
say
three
and
a
half
legs
of
a
four
legged
table
in
harmonizing
on
IP
layer
capacity
and
a
planned
side
meeting
this
week
to
discuss
both
the
draft
and
the
liaison
rep
I.
So
that's
it
I
wrap
I've,
rounded.
It
all
up,
oh.
J
J
A
J
A
J
Thank
you
so
no
update
to
the
draft,
but
lots
of
good
comments.
Thank
you.
Frank
partners,
let's
go.
Let's
say
we
got
some
terminology
problems.
The
terminology
for
nodes
in
the
path
was
defined
in
our
framework.
Rfc
host
is
a
computer
capable
of
IP
communications.
It
includes
routers,
that's
not
bad,
but
wait.
A
router
is
a
host
that
facilitates
network
where
communication
between
hosts
and
forwarding
packets
and
now
it
sounds
like
a
router.
J
Something
special
in
the
middle
then
8,200,
which
you
know
is
the
bits
of
the
original
v6
document
says
a
host
is
not
a
router,
but
but
the
definitions,
not
paths
specific.
So
you
know
we
got
some
context
thing
going
on
here
and
and
in
the
mail
like
I
said
to
Frank
and
as
a
result
of
our
discussions
in
the
hallway,
then
Cerf
used
to
describe
a
router
as
a
PC
with
a
graduate
student
wrapped
around
it
I'm.
Thank
you
to
vent
for
giving
me
a
chance
to
get
a
laugh.
J
There
is
there's
a
lot
of
commonality
there
with
our
host
definition.
So
in
any
case,
let's,
let's
look
at
this
today.
Nodes
in
the
path
can
be
a
coherent,
compute
environment,
so
virtualized
within
the
computer.
All
right,
so
we
got
some
options.
I
put
them
on
the
list
feel
free
to
jump
all
over
that
for
option
a
retain
host,
add
a
new
node
term
and
definition.
So
we,
you
know,
keep
20
through
30,
as
is
a
node.
Is
any
network
function
on
the
path
capable
of
IP
alert?
Communication
includes
the
23
30
hosts.
J
On
the
other
hand,
we
could
revise,
host
and
use
the
word
node
in
a
general
way,
a
node
on
the
path
possessing
a
coherent,
compute
environment
capable
of
IP
layer
communication.
It
also
includes
RFC,
23,
33,
23,
30
hosts
and
option.
C
is
the
one
you
suggest
on
the
list
or
now
really
quickly
and
creatively.
Yet
the
Mike,
any
any
preferences
for
these
a
B
or
keep
looking
out
see.
E
E
Physical,
like
just
invent
some
new
nomenclature
and
at
some
point
I
think
you
need
to
do
at
23:30.
This
I
didn't
really
and
I
asked
around
quite
a
bit
before
us
writing
an
email,
I
didn't
find
a
terminology
document
for
the
ITF
I.
Think
that's
the
bigger
problem
where
things
like
a
note,
host
router
are
really
clearly
defined
and
what
they
do
and
what
they
don't
do,
but
otherwise
I
think
some
of
the
8200
six
men
mess
that
happened
from
a
discussion
perspective.
It's
irrelevant.
If
you
just
referred
to
twenty
to
thirty.
A
K
J
K
J
E
C
K
L
K
J
J
C
J
More
minutes,
cool,
okay,
so,
let's
see
yeah,
we
have
to
do
some
work
here
to
align
the
traceroute
style
methods
with
the
hybrid
methods.
The
hybrid
methods
are
much
more
reliable
ways
in
that
almost
everything
is
a
cooperating
host
in
the
in
the
tracing
path
with
with
the
trace
route
that
that's
not
always
the
case,
so
we'll
seek
ways
to
align
this
I
kind
of
think
that
some
there's
some
qualification
of
the
statements
in
the
section
you
know
like
the
one
I've
quoted
here,
they
need
to
be
qualified.
J
This
is
traceroute
only
kind
of
problem,
something
like
that
and
then
53:38
is
our
XML
expression
of
traceroute
output,
basically
route
output
and
would
be
good
to
at
least
get
all
the
requirements
for
an
update.
I
agree
with
that
Frank.
It
would
be
better
if
we
had
an
updated
data
model
as
an
IETF
yang
model,
that's
even
more
wonderful
show
of
hands
of
who
would
like
to
work
on
that.
J
Okay,
but
we're
gonna
make
that
we're
gonna
make
that
definitely
different
from
the
path
that
this
draft
is
on.
We'll
assemble
their
requirements,
the
best
we
can,
and
hopefully
others
will
put
that
together
at
some
future
time.
Maybe
even
these
offer
authors
when
they
can
find
a
minute.
So
the
next
steps
are
the
working
group
weighs
in
on
these
key
questions.
We've
got
a
we've
got
to
leave
some
time
for
the
list
on
ABC,
and
that
includes
the
questions
in
the
texts
are
easy
to
find.
There's
some
more
areas
for
development
there
and
footer.
J
Today,
foot
footer
gave
me
his
comments.
I've
read
them.
Footer
I've
got
the
response
conjured
in
my
mind,
there's
things
we
can
do
there
I,
like
that.
You
jumped
right
on
this
and
actually
did
more
work.
This
morning
after
we
talked
that
was
great
I
appreciate
it
thanks
so
much
so
so
both
the
reviewers
from
last
time
checked
in
and
actually
did.
The
reviews
reminders
help
folks.
This
is
what
I've
learned
I'm
hoping
for
a
working
group
last
call
on
this
by
106
and
co-authors.
J
A
N
Everybody,
this
is
an
update
about
the
multi
point
at
mark
tuft.
We
are
at
zero
to
version.
This
is
just
a
recap
about
what
is
the
motor
motivation
for
this
work.
We
started
from
the
base
our
FSC
8321
that
presented
the
point.
That
is
valid
for
point-to-point
flows,
and
there
is
only
one
limitation
that
if
it
works
for
point-to-point
flows
or
multicast
flows,
we
have
to
select
the
v
identification
fields,
but
we
want
to
introduce
a
methodology
that
can
be
more
general,
so
we
want
to
define
the
identification
field
without
any
constraint.
N
In
this
way,
we
can
monitor,
for
example,
an
entire
network
or
multi-point
flow.
So
in
this
way,
but
we
have
to
define
a
new
approach
for
the
measurement
the
multi-point
network
can
be
split
into
a
cluster
partition
and
cluster
partition
can
be
combined
in
different
ways,
and
this
allow
a
more
flexible
and
intelligent.
We
can
say
performance
measurement.
The
draft
details
also
the
algorithm
for
this
cluster
partition.
N
So
we
call
as
I
say,
intelligent
performance
management
approach,
because
we
call
the
network
zooming
in
a
controller,
can
calibrate
and
manage
the
performance
measurement
it
can
start
without
examining.
In
depth
our
network,
but
so
in
the
beginning,
we
can
monitor
just
the
full
network
from
the
input
from
the
ingress
to
the
egress
point
and
in
case
of
problem.
N
So
if
we
experimented
some
packet
rows
or
the
delay
is
two
Ike,
we
can
reconfigure
the
network,
we
can
configure
the
clusters
and
we
can
make
a
ditalion
edit,
more
detailed
analysis,
and
we
can
act
in
two
ways
or
we
can
change
change
the
traffic
filters
or
we
can
activate
you
measurement
points
within
our
networks.
This
is
just
an
example
for
packet
rolls,
so
at
the
beginning,
we
can
activate
the
counters
only
at
the
edge,
so
the
number
of
ingress
packet
and
numbers
egress
packets
is
equal,
so
packet
loss
is
zero.
N
N
If
we
apply
the
algorithm
that
we
have
also
described
during
the
last
meetings,
we
find
we
can
find
four
clusters
with
four
colors
and
if
we
analyze
and
we,
if
we
calculate
the
packet
loss
for
each
cluster,
we
see
that
for
the
red
one
we
can
experiment
at
the
part.
So
we
can
focus
the
analysis
for
the
red
clusters
and
in
that
case
we
apply
more
specific
traffic
filter
to
understand
the
part
that
is
experimented
the
loss.
So
in
this
case,
and
so
we
are
able
to
identify
the
fault.
C
N
Intelligent
approach,
so
in
general,
is
a
complete
performance
measurement
framework,
so
this
can
be
applied
not
only
for
packet
loss,
so
we
can
calculate
no
Tony,
Parker's
procrastinate
or
a
combination
of
clusters,
but
also
the
delay
measurement
apply
to
this
kind
of
measurement
and
the,
but
for
the
delay
measurement
we
have
two
different
ways
to
worked
the
first,
the
first
one
is
about
the
multi-point
at
basis
measurement.
In
this
case,
we
can
calculate
the
mean
delay
that
is
representative
for
all
the
multi-point
path
or
of
our
clusters.
N
N
Some
of
us
can
can
know
that
has
some
problems,
because
if
you
have
to
identify
the
ashing
values,
the
essence,
import
can
had
some
difficulties,
but
if
you
can
correlate
help
with
correlations
in
terms
of
space
with
the
topological
point
of
view,
by
using
the
clusters
and
in
terms
of
time
by
using
the
alternate
marking
that
creates
the
block
of
packets,
we
can
easily
make
a
correlation
between
the
symbols
also
in
a
multi
point
environment.
So
that's
why
we
say
it
is
a
complete
frame,
so
we
analyze
all
the
alternatives.
N
We
have
to
measure
packet
loss
to
measure
delay
for
multi
point
paths
for
single
single
packet
analysis.
So
what
are
the
change
from
the
zero
one
version?
We
make
some
consideration
about
the
overall
architecture,
because
we
do
need
to
have
a
centralized
management
to
may
to
do
some,
this
intelligent
approach
and
we
are
the
doors
on
some
use
cases,
for
example,
as
the
one.
The
path
selection
can
be
done
also
by
analyzing
the
cluster
behaviors,
and
this
can
help
also
traffic
visualization
and
topology
mapping.
N
K
N
There
is
the
algorithms
and,
unfortunately,
I,
don't
have
the
slide,
but
there
are
several
algorithm
that,
unfortunately,
there
is
a
paper
that
will
be
published
in
this
year,
probably
in
September,
and
that
will
details
additional
methodologies
to
find
a
classic
partition
in
the
draft.
We
defined
also
be
simple
algorithms
that
we
can
identify
the
sub
networks
in
the
net,
so
the
basic
color.
It
means
that
we
have
to
identify
the
cluster
and
the
group
of
nodes
where
the
packet
rows
property
is
still
valid.
N
K
N
A
So
your
easy
beginning,
the
path
there
come
RFC.
Can
you
give
these
out
a
little
bit
more?
What
you
mean
there,
so
it
sounds
like
you've
got
feedback
that
there's
some
missing
detail
come
in
the
next
Rev
are.
There
are
other
things
that
you
expect
to
put
in
the
document
before
we
could
go
for
a
working
group.
Last
call
I.
Think.
N
A
No
great
yo
you
wanted
to
be
published
before
he
had
the
reference
to
it
because
yeah,
even
as
an
even
as
an
informative
reference.
If
it's
informative
referenced,
we
think
nobody
can
get
to
that's,
not
useful,
okay,
good,
okay,
so
we'll
bring
this
back
I
guess
quickly,
next
time
and
then
talking
about
moving
a
fort
excellent
okay,
Justin.
O
O
So,
for
instance,
we
allocate
IOM
names
basis,
data
and
related
extension
errors
to
be
a
capsulated
with
IOM
adores
inside
it
and
much
more.
We
also
took
advantage
of
the
current
parsing
of
extension
headers
of
the
kernel
by
improving
it
and
adding
some
useful
info
that
would
allow
us
to
ease
and
fast
and
decapsulation
process
for
that
we
store,
for
instance,
the
total
padding
size
of
an
extension
header
and
during
iron
bar
Singh.
O
We
also
saw
offsets
and
size
of
each
IOM
blocks,
so
each
option
to
be
removed,
obviously,
and
at
the
bottom
of
the
slide,
you
can
see
a
graphical
representation
of
the
data
structure.
We've
used
to
represent
an
extension
header,
so
here
it's
generic.
It
can
either
be
a
PI
up
or
a
destination
option,
and
this
one
is
stored
at
each
I/o
interface,
which
must
encapsulate
IOM
headers,
and
you
can
also
see
some
data
offsets
in
red
and
actually,
when
a
node
encapsulate
I
am
headers.
O
It
also
needs
to
insert
its
IOM
data
and
that's
a
way
to
further
note
to
remember
what
option
is
and
where
it
needs
to
insert
the
data
corresponding
to
that
option.
So
what
we
got
from
measurements?
Well,
those
are
still
early
results,
but
we
can
already
learn
a
lot
from
them
at
the
top.
We
can
see
the
topology
we
have
used
for
measurements
and
actually
for
measurements.
That
I
will
show
you.
O
We
have
just
used
a
portion
of
this
topology,
so
forget
about
what's
outside
and
the
cloud
so
just
focus
on
what's
inside
iron
domain,
and
the
reason
for
that
is
that
we
want
it
to
be
compliant
with
the
RFC
h200,
which
says
that
you
cannot
invite
insert
or
remove
extension
headers.
So
this
way
we
generate
an
a-cup
to
the
traffic
I
am
traffic
inside
the
I
am
doing
on
the
same
node
at
the
Bahamas.
So
for
the
left
graph,
you
can
see
a
comparison
between
Tropos
measured.
O
O
That
is
interesting
and
we
can
come
the
first
one
with
the
last
one
and
I'm
sure
you
can
see
a
small
drop
of
around
seven
percent,
and
this
is
not
that
huge,
especially
when
you
know
that
this
may
not
be
the
most
realistic
case.
Indeed,
in
this
case,
we
insert
iron
bidders
into
any
packets.
We
see
so
by
definition
of
IOM
I.
Think
so
that's
my
point.
I
think
that
you
should
not
insert
at
Iometer
stats
any
packet.
O
So
that's
why
I
wanted
to
measure
another
thing,
the
impact
of
percentage
of
insertion-
and
you
can
see
on
the
bottom
right
graph
that
between
zero
and
twenty
percent
of
insertion,
you
are
still
quite
you're,
still
quite
good
performance.
Then
it
starts
dropping
until
fifty
percent
and
then
it's
remained
stable
until
one
hundred
percent,
so
I
think
that's
my
advice
to
any
operators
that
would
implement
this
and
configure
this,
and
my
advice
would
be
to
limit
the
percentage
effect
or
insertion
to
at
maximum
too
many
persons.
I
think.
O
O
It
status
it's
quite
unclear,
especially
when
you
are
in
a
pre-allocated
context,
because
all
it
does
is
actually
break
the
idea
of
provocation,
so
I
get
the
whole
point
of
this
option,
but
I
think
they
need
some
discussion
and
improvement
to
end
up
with
something
very
good.
The
second
one
is
more
I
just
wanted
your
opinion
on
that.
O
Would
you
see
some
interests
of
having
the
incremental
trace
mode
enabled
inside
the
kernel?
Because
my
point
is
I?
Don't
worry
thing
that
will
be
good,
because
this
is
not
a
performance
solution
at
all
in
the
kernel
and
I.
Don't
think
that
operators
would
use
it
by
knowing
that
and
so
yeah
I
just
wanted
your
opinion
on
that
and
the
last
one
is
about
the
new
version
that
we
will
just
merge
on
the
repository,
which
will
be
totally
compliant
with
the
RFC,
and
one
of
the
solution
was
to
use
ipv6
Turner
encapsulation.
O
But
this
solution
also
brings
a
lot
of.
Let's
call
them
some
small
issues
and
the
first
one
is
that
you
could.
You
may
have
a
leak
of
iom
data,
so,
let's
think
about
a
scenario
when
you
have
overlapping
channels
and,
for
instance,
I'm,
a
node
and
I'm
configured
to
the
capsulate
iron
namespace
to
for
instance,
but
this
namespace
is
also
encapsulate
it
in
other
one.
So
it
is
in
a
inner
header
and
I'm.
I
cannot
see
that
so
I
will
just
let
it
go,
and
this
is
almost
the
same
idea
for
the
second
point.
O
The
scenario
is
with
that
nested
to
nose
so
again,
I'm
a
node
and
I'm
configure
to
insert
my
data.
If
I
see
the
IMS
and
again
I
can't
see
it
because
it's
inside
so
I
will
not
insert
my
data
I
just
forward.
It
so
someone
told
me
that
for
the
second
point,
it's
totally
fair
because
who
knows
actually
like
that,
so
you
could
just
ignore.
O
What's
inside
and
I
tend
to
agree
because
it's
easier
for
me
and
it
makes
life
easier,
but
I
think
you
should
take
into
account
that
operators
may
want
to
configure
such
a
configuration,
such
ever
sorry
I,
have
such
a
configuration
and
they
still
wanted
to
have
each
node
inserted
their
their
data.
So
I
think
again,
there
is
room
for
discussion
on
that
point
and
the
last
one.
O
Actually,
when
you
encapsulate
IOM
headers
well,
you
have
to
know
what
the
destination
is
so
right
now
this
is
a
static
configuration,
but
it
would
be
nice
to
have
something
based
on
the
routing.
So
I
was
thinking
at
first
as
something
like
a
signaling
protocol
like
LTP
or
something
like
that.
I
think
they
are
certainly
exist.
Other
easier
solutions
without
reinventing
the
wheel,
so
I'll
be
happy
to
share
on
the
mailing
list,
or
here
or
whatever,
on
those
important
points.
O
P
O
P
O
O
P
Q
E
For
a
baton,
what
song
tell
us
earlier
point
I
would
second,
that
incremental
is
useful
for
the
very
reason
if
you
really
have
I
am
started
on
the
host
and
then
really
connected
a
fabric
that
does
incremental.
Maybe
you
don't
want
to
go
into
that
mode
where
you
mixing
incremental
and
pre-allocate
it
in
the
very
same
packet,
which
is
what
otherwise
probably
do
so
I
do
believe
that
there
is
a
use
for
doing
from
that
goal.
E
Yeah
the
host,
despite
the
fact
that
well,
if
you
just
have
forwarding
hosts
that
are
all
software,
an
old
kernel
based
yeah
well
even
argue
whether
that's
useful
I
think
the
mixture
libraries
as
easy
as
well.
The
other
point
on
kind
of
blaming
opaque
we've
done
all
that
for
awhile
I
think
there
is
a
way
to
go
and
at
least
contain
the
problem
and
containing
the
problem
might
be
using
the
profile
idea.
E
That
tell
came
up
with
where
you
say
well,
if
I
know
that
my
nodes
are
not
inputting
random
data,
but
I
can
go
on
three
to
find
that
and
I
could
do
the
length
project
and
calculations
upfront
so
loads
of
the
variety
that
you
can
dream
of
doesn't
really
happen
and
we
ought
to
be
people
drop
offs
and
a
final
ask
for
you
to
comment
on
so
when
you
did
that
for
the
5:12
kernel.
What's
your
kind,
could
you
shed
some
light
on
what
you're
gonna
go
do
with
getting
that
into
master
luxury
yeah.
F
E
A
E
A
Google
Doc
we
just
changed
the
location
anyway,
so
where
are
we
at
a
very
high
level
kind
of
what
is
the
ecosystem?
Looking
like
and
I'm?
Sorry,
if
not,
every
single
draft
is
up
there,
but
I
think
those
were
the
ones
that
kind
of
got
discussed
quite
a
bit
from
a
data
fields,
perspective
and
the
flag
stuff.
Let's
table
that
for
a
minute,
we'll
discuss
that
in
detail.
We
had
a
recent
mailing
list.
E
Discussion
on
immediate
export,
postcard
I
think
we
have
a
good
resolution
for
that,
which
means
get
rid
of
the
flag
that
we
have
for
immediate
export
and
write
a
new
draft
that
is
dedicated
for
postcard,
slash,
immediate
export
that
just
defines
that
one
new
option
to
go
and
handle
that
case.
So
we
just
need
to
see
the
document
like
future
reference,
but
I
think
there
is
at
least
resolution
on
the
way
forward,
or
we
want
to
go
would
do
would
this
one,
then
we've
been
seeing
quite
a
bit
of
kind
of
background
work.
E
The
documents
been
progressing,
we've
not
seen
a
lot
of
discussion
around
it,
but
we
have
a
yang
document
for
IOM.
It's
better
for
a
while,
and
it's
also
been
updated
and
kind
of
fix
has
been
worked
into
that.
So
maybe
I
think
at
some
point.
Maybe
now
we
should
go
and
ask
the
question:
do
we
want
to
go
and
adopt
it?
E
E
The
conclusion
was:
go
and
read
the
document
and
send
mail
to
the
list,
which
brings
me
to
the
area
that
we
touched
on
earlier
on
we're
just
this
encapsulation
laundry
list.
We
talked
to
six
men
post,
the
last
I
ppm
meeting.
The
the
feet
was
back,
was
good
and
saying:
well:
go
and
progress
it
and
come
back
frequently
and
give
us
an
update
on
where
you
are,
but
we're
happy
that
you
do
the
work,
because
we
had
precedents
earlier
on
that
it
worked
out.
A
E
Need
other
people,
sorry
about
the
other
people
that
we
don't
know
there
is
restrictions
that
are
pretty
hard
around
that
which
means
like
problem
space
constraints
that
you
have
with
options
may
may
render
it
only
nichy.
For
certain
cases
there
is
work
to
go
and
solve
the
problem.
A
completely
different
way.
Tom
mentioned
not
here
about
earlier
on.
E
In
other
venues,
the
work
on
putting
extension
headers
into
v4
yeah
might
solve
our
problem,
but
we
need
something
for
v4
and
the
best
current
thing
is
a
kludge,
which
means
you
slap
on
eight,
unnecessary
bytes
so
that
you
can
slap
on
the
IOM
header,
which
is
the
either
typing
capsulation.
That
would
also
go
and
cater
for
other
protocols
like
genève,
so
that
same
option
we
can
go
there
plus
well.
E
The
discussion
that
we
had
is:
we
can
only
get
an
either
type
if
isg
asks,
through
a
liaison
to
it--
I
Triple
E
for
an
either
type,
and
that
requires
that
we
have
a
working
group
adopt
the
document
that
asks
for
that
either
type.
So
there
is
a
little
bit
of
a
wrong
way
ahead
of
us
and
question
is:
do
we
want
to
go
and
take
that
effort?
I
have
not
seen
too
many
lovers
of
GRE,
but
well
it's
the
best
acceptable
option
that
I
know
of
that
is
somewhat
fitting
into
IETF
overall
general
rules.
E
The
other
option
would
be
to
go
and
see
what
else
we
can
go
do
about
before
and
well.
That's
extension
headers
for
before
we
can
ask
for
an
I/o
and
protocol
type
to
go.
Ip
protocol
type
to
go
and
just
well
have
one-size-fits-all,
probably
harder
than
either
type
so
I
think
we
need
ideas,
and
maybe
here
at
the
mic,
but
also
maybe
broader,
on
the
list
on
how
to
solve
the
v4
question
in
a
somewhat
reasonable
way.
Let
me
pause
here,
Tom.
F
E
F
F
Things
we
had
to
come
up
with
this
crazy
magic
number,
so
I'm
not
sure.
If
that's
what
these
are
intended,
there's
may
not
be
feasible
in
the
long
run
and
then
so
yes,
I
didn't
mention
the
idea
I
gave
before
extension
headers.
That
is
possible.
If
the
choice
was
between
that
and
creating
a
new
IP
protocol,
number
I
would
say,
use
the
existing
one.
I
think
that's
actually
going
to
be
a
lower
part
and
I'm
a
little
confused
about
the
ether
type,
but
this
would
be
hop-by-hop
options
but
and
I
peed
before
hopping
up
often.
A
A
A
Very
important
office
between
number
of
bytes
on
the
wire
a
number
ye
a
number
of
years
working
for
meetings,
great
so
I
hate
to
say
this,
but
I
think
the
thing
that's
there
is
GRE,
sorry
to
say
so.
Jerry
in
V,
for
is
I,
mean
weeks
are
thing.
What
is
the
easiest
way
to
get
a
thing?
That's
if
you're
kind
of
identified
in
before
it
it's
dirty
right,
yeah,
but.
A
F
F
If
there's
enough
traction
so
I
didn't
post
the
ipv4
extension
headers
and
it
was
quite
interesting
to
see
the
feedback
primary
concern
is:
oh
we're,
improving,
ipv4
and
I
thought
we
were
sunsetting
it,
and
yet
the
operators
we
operated,
came
back
and
said:
I
still
have
customer
as
an
ipv4,
so
we
have
to
keep
improving
it.
So
it
may
be
less
of
a
technical
question
anymore.
F
F
F
I
F
E
A
I
Q
Q
So
it
it
died
on
the
pressure
personal
in
the
process
error
because
it
accidentally
forked
and
then
the
two
communities
couldn't
agree.
I
p.m.
he
was
in
many
resembled
was
in
many
ways,
but
one
of
the
things
that
they
did,
that
was
kind
of
a
hack,
Noel
seis
extremely,
was
a
hack.
Is
they
used
magic
numbers
in
the
payload,
so
the
hardware
could
find
the
measurement
object
and
the
rule
was
that
the
measurement
object
enemas
or
checksum.
So
you
can
have
a
measurement
object
had
its
own,
the
offset
checksum
and
the
hardware
guy
said
yeah.
Q
They
can
do
this
in
ships.
No
problem
you
can
put
a
measurement
measure
commit
the
application
has
to
know
that
the
data
isn't
real,
but
you
can
make
do
measurements
then,
with
streams
that
mimic
arbitrary,
other
applications
find
the
cookie
announced
of
whatever
it
is
updated
on
the
fly
going
through
the
hardware
correct
the
checksum
at
the
end
and
send
it
on
its
act.
Q
R
Just
did
to
point
out,
we
also
have
will
work
on
ipv6
encapsulation
for
Iowa.
It
is
also
listed
in
the
agenda,
the
last
one
and
basically,
if
we
want
to
put
the
Iowa
data
in
the
hopper
hoc,
the
options
header
and
there
may
be
a
risk,
especially
for
the
incremental
tracing
mode,
so
the
data
may
become
very
large.
So
there
is
a
risk
risk
to
push
working
Heather
out
of
the
passing
window
on
the
chip.
R
S
You'll
be
profile
I
wanted
from
for
the
one
suggestion
I
think
you
know.
That's
the
IO
hammer
time,
you're
very
pretty
sure.
I
hope
that
later
we
can
confine
our
discussion
on
that
you
capsulation,
because
they
use
a
to
market
time.
You
think
we
can
focus
on
the
IOM
Heather.
It's
a
sale
because
I
will
father
like
this.
One
I
know
that
I'm
chars
also
several
the
options,
how
I'm,
Heather
and
also
maybe
the
tre
I.
Don't
like
this
one.
So
you
can,
we
I
think
I
mean
I
cannot
afford
us
on
my
walk.
S
T
A
E
Let
me
go
and
progress
to
the
two
documents
that
are
I,
think
core
and
center,
and
that's
kind
of
the
core
document
that
we
started
the
journey
on
three
years
ago,
line
that
I
PBM
is
working
on
since
two
years.
If
you
look
at
the
key
updates,
we've
done
a
little
bit
of
editorial
cleanup
and
we've
done
text
specific
to
the
flags
where
we
really
have
beyond.
That
was
the
only
piece
of
discussion
that
we
had
in
Prague
that
well
fly
were
not
really
not.
E
Everybody
was
comfortable
with
what
the
flags
are,
how
they
were
used
and
the
likes
and
we've
seen
even
on
immediate
export,
that
we
already
came
to
a
new
conclusion
that
a
resolution
for
that
and
that
we
moved
that
out
and
found
that
stuff
out
and
to
dedicate
a
document.
Why?
Because
we
wanted
to
go
on
separate
the
stuff
that
is
in
discussion
from
the
stuff
that
is
really
stable,
so
that
we
can
really
settle
the
stuff
that
is
really
stable,
which
is
the
date
arrived.
E
So
there's
a
couple
of
FICA
I
post
that
are
fakes
and
I've
did
done
in
that
update
one
clarification.
Well.Tell
actually
have
to
get
the
patch
one
clarification
on
how
the
namespaces
are
used,
because
there
was
some
confusion.
We
got
from
the
discussion
that
said
well,
some
people
interpreter
that
from
discussions
that
I
had
with
people
implementing
the
thing
like
if
I
use,
namespace
one
I
have
to
go
and
follow
the
document.
If
I
use
a
different
name,
space
number
I
can
do
whatever
I
want
that.
E
Wasn't
the
idea
of
a
namespace,
the
namespace
idea
was
that
it
gives
you
more
context
to
the
fields
that
we
have
defined.
That's
what
we're
saying
now
right
so
I
think
that
makes
obvious
sense,
but
just
making
sure
that
it's
not
misinterpreted.
The
other
thing
is
the
the
document
split.
So
all
the
sections
that
touched
flags
have
been
farmed
out
to
tells
new
document.
So
whenever
something
Flags
was
discussed,
so
flags
that
are
real
flags
like
active,
immediate
export
and
then
loop
back,
they
were
found
out
from
a
document
perspective,
excluding
the
flags
now.
E
Well,
there
weren't
really
updates
and
it's
relatively
stable
and
there
has
been
very
few
additional
proposals.
I
think
the
big
last
real
big
debate
on
the
whole
data
fields
document
was
the
introduction
of
namespace
and
that's
kind
of
now
money
many
moons
ago.
So
from
my
perspective
and
nothing,
multiple
people
voiced
the
very
same
opinion.
It's
ready
for
working
glue,
blast
coal,
and
maybe
we
can
go
and
home
on
that.
If
that's
ok,
but
there
is
a
question
earlier.
U
Infuse
okay
I
captured
this.
My
lunch
I
I
just
find
their
cell
checks
on
complementor
fuel
in
the
fuel
I
think
it
a
bit
fuel
is
use
the
two
indicator
that
the
data
need
to
be
shipped
out
to
the
controller
or
collector.
So
it's
kind
of
confused
people
there's
the
masturbate
is
used
to
indicate
the
sister
took
some
compliment
so
I'm,
not
I'm,
not
to
say
this
isn't
not
useful
I
just
would
say.
Maybe
we
need
to
use
it
another
bit,
for
example,
in
the
flag,
to
indicate
there's
just
some
commitment.
U
E
Okay,
maybe
you
can
go
and
send
an
email
to
the
list
on
that
one
so
that
we
can
go
yesterday
on
the
list.
So
I
think
the
argument
is
not.
Is
we're
not
really
no
data,
but
it's
kind
of
operational
data
to
help
the
overall
thing
work
and
hence
you
want
to
go
and
use
it
in
a
slightly
different
way
than
the
operational
data.
Okay,
I
can
I
think
it's
a
different
type
of
data
that
we
insert,
given
that
it's
just
to
help
operations.
Sorry
tell
I.
E
P
F
F
F
One
near
peg
data
is
somewhat
awkward,
a
variable
variable
length
field
right
in
the
middle
of
this
bit
field,
so
we
probably
would
think
about
restructuring
that
another
interesting
thing
was
for
some
of
the
fields
there's
both
like
a
shorter
field
and
a
white
field.
What
happens
if
both
of
those
are
set?
So
it
kind
of
gets
this
interesting
dilemma,
so
you
could
actually
have
both
fields
present
for
like
an
identifier.
F
E
V
E
The
the
question
on
whether
we
use
a
bit
vector
or
a
number
thing
has
been
discussed
multiple
times.
There
is
benefits
and
downsides
to
the
whole
thing,
I
think
a
couple
of
moons
back.
We
settled
on
that
people
wanted
the
bit
vector
mainly
for
the
reason
that
we're
and
you
see
that
I
think
so
far.
We
are
struggling
to
define
what
what
tell
has
with
the
profiles
we
are
struggling
to
understand,
which
combinations
are
actually
meaningful
from
real-world
deployments.
E
So
what
I
would
say
is
let's
go
with
the
bit
vector
for
now
until
we
have
more
operational
experience
and
then
we
can
revisit
that,
maybe
in
a
version
2
of
Io
a.m.
and
see
well,
those
are
the
typical
combinations
that
we
need
and
then
we
can
encode
them
in
a
more
compact
way.
Right
now,
I,
don't
know
whether
anybody
would
feel
like,
especially
in
the
ITF
as
an
authoritative
source,
to
say
those
are
the
combinations
that
people
will
need
and
those
are
the
ones
that
they
can't
use
and
I.
E
Think
that's
the
big
problem
right
now
with
choosing,
which
is
why
a
couple
of
moons
ago
we
arrived
at
well.
Let's
stay
with
a
bit
field
and
I:
don't
really
think
that
revisiting
things
that
we've
done
so
far,
especially
on
the
current
revision,
makes
too
much
sense.
It's
just
like
extending
a
runway
and
I'm,
not
sure
whether
we
would
arrive
at
a
different
conclusion,
given
that
we
have
too
many
operational
insights
and
very
happy
that
we
see
more
and
more
implementations
popping
up
now,
thanks
to
Justin,
for
instance,
but
yeah.
V
E
E
V
E
I
Yeah
this
is
important,
but
we're
going
to
lighting
talk
time.
So,
if
you're
in
the
end
of
that
sorry,
just
yeah
right
with
just
with
regard
to
this
document,
so
I
think
the
plan
would
be
let's
go
through
this
feedback.
We
have
from
the
hackathon
and
we'll
expect
another
Rev,
or
at
least
yep
a
good
thorough.
This
discussion
on
you.
I
E
A
A
A
C
A
A
People
came
up
and
had
comments
right
like
so
a
really
good
way
to
get
people
to
say
things
is
just
a
threatening
a
working
group
last
call,
but
this
discussion,
when
this
has
been
has
been
sort
of
like
long
and
ongoing
enough
that
we
haven't
had
to
threaten
the
working
group
last
call
in
order
to
get
people
to
stand
up
and
say
things
he
yeah,
it's
it's
Tom.
Do
you.
F
F
C
F
A
I've
heard
some
I
think
the
comments
yeah
I've
heard
some
I've
heard
some.
Maybe
if
you
rearrange
things
but
I've
also
heard
some
feedback,
that's
a
little
bit
more
a
little
bit
more
substantial
with
respect
to
like
sort
of
editorial
stuff
and
things
that
were
hard
to
figure
out
right
like
so
we're
not
looking
to
change
the
the
implementations
as
much
as
we
are
looking
to
improve
the
specification
to
improve
the
chances
that
it
is
easy
to
build.
An
interoperable
implementations
only
reading
this
back
before
we
zoom
is
working
applause.
F
A
E
Q
E
All
this
timeframe
so
that
it's
not
like
dry
again
yeah.
So
the
other
document
is
the
more
active
thing
that
we
had
in
the
last
meeting
was
around
flags,
so
the
new
draft
was
really
the
stuff.
That
was
not
really
feeling
like
completely
settled
by
the
group
in
Prague,
and
so
all
of
that
is
in
the
flags
draft.
Now
it's
ready
to
go
and
split
the
conversation.
So
what
is
in
there?
It's
three
flags.
E
It's
the
loopback
flag
and
the
loop
flag
flag
existed
from
the
very
beginning,
it's
a
flag
to
go
and
do
what
I
would
call
efficient,
traceroute
it's
mentioned
and
refer
to
Inara
and
else
document,
so
that
you
can
go
and
compare
that
to
the
classic
methods
like
Paris,
twice,
rot
or
even
a
really
classic
twice
route
and
what
you
can
go
with
do
with
hybrid
methods.
Just
tells
you
at
every
single
hop
like
go
and
send
a
copy
back
to
the
originator
and
the
originator
has
to
be
the
encapsulation
encapsulating
notify.
E
The
second
thing
is
the
immediate
export
flag
and
I
mentioned
that
that
there's
been
active
discussions
on
the
lists
on
that
particular
one
around
well,
not
using
that
flag,
but
using
an
IO
am
option
and
borrowing
text
from
the
the
PBG
draft,
which
is
as
many
things
in
there,
including
how
we
could
go
do
things
with
our
and
we
have
a
dedicated
document,
Oh
Matt
and
then
well.
If
you
have
an
option,
you
don't
need
the
flag
anymore
and
the
third
one
is
the
active
flag,
which
is
a
bit
of
a
helper
flag.
E
I
would
call
it
it's
not
active
in
the
sense
like
I
want
you
to
do
something
with
this.
It's
active
in
in
the
sense
of
77
99,
where
you
say
well,
this
is
traffic
that
is
used
for
probing
active
measurements,
so
the
UDP
probe
that
you
guys
have
done
at
the
hackathon,
including
IOM,
could
have
put
the
active
flag
on
so
that
from
an
operational
perspective,
that
traffic
would
have
been
easier
to
detect
for
whatever
reason
right.
W
E
E
So,
as
I
said,
like
it's
been
built
very
with
a
very
specific
use,
guys
and
Petra
brought
that
to
us
where
he
said
well:
I
have
my
UDP
ping.
Er
I
won't
drop
it
detection.
Can
we
do
something
by
combining
the
UDP
ping
er
with
IO
am
and
well
we
built
that
and
we
both
as
a
prototype.
We
socialized
that
at
that's
invited
in
IETF
and
then
it
kind
of
entered
the
draft.
C
F
Pro
we
send
it
all
the
way
to
the
destination.
We
want
it
to
come
back,
all
the
notes
still
about
their
information,
and
we
just
get
one
reply
packet,
so
I'm
wondering
so.
If
I
and
I
think
it
posted
about
having
that
neck
conic
reflection,
but
for
the
loop
back,
is
there
a
real
use
case
for
this?
That's
been
identified,
yeah.
E
That's
what
that
was
to
work
with
better
raft
on
on
you,
D,
beeping,
probe
or
whatever,
because
the
thing
is
like,
if
you're,
if
you're
probing,
doesn't
make
it
to
be
very
end.
So
you
have
probes
configured
a
new
data
center
all
over
on
all
the
application
ports
and
then
well,
you
see
a
probe
breaking.
What
do
you
do
for
that
particular
probe
that
broke
you're?
Attaching
iom
information
to
that?
And
that
means,
if
you
do,
that,
borrow
from
both
side
bidirectionally.
B
W
E
W
E
A
H
A
Gonna
take
that
question
in
a
second
I
mean
I'm
gonna
handle
this
one
and
then
I'm
gonna
go
back
to
that.
Okay,
sorry,
yeah,
all
right,
good,
so
adopters
working
group
document
I,
don't
really
think
we
need
to
go
through
the
whole
rigmarole
of
doing
a
two-week
call.
I
will
make
the
following
statement
from
the
chair.
We
intend
to
adopt
this
as
a
working
group
document.
E
E
A
So
the
instruction
would
be
the
next
revision
of
this
document.
According
to
the
plan
of
the
authors,
should
be
an
IETF
IP
DM
document,
and
if
anybody
has
a
problem
with
that-
and
you
can
yell
at
the
chairs
and
have
a
good
reason
because,
like
they're
doing
the
whole,
like
actually
I
mean
this,
this
is
its
its
content
from
organ
group
document.
Correct.
It's
fine,
alright,
I
have
a
question
from
the
chair
now.
A
I
have
another
question
from
the
chair
before
that
is:
does
it
make
sense
from
a
specification
readability
standpoint
for
the
content
in
this
document
to
be
in
a
separate
standards
track
RFC
from
the
rest
of
the
IOM
data
model
document
like
this
was
separated
out
to
make
the
discussion
easier.
Do
you
want
the
text
back
in
one
doc,
or
do
you
want
two
Doc's
that
you
don't
have
the
answer
now?
Well,.
E
Q
A
E
E
Oh
seven
I
would
be
in
favor
of
that,
as
opposed
to
having
two
documents
yeah,
because
I
think,
if
you
have
everything
in
one
place
and
you
dump
that
on
one
person
and
you'll
do
it
their
way
and
then
yes,
all
the
references
in
one
document,
it's
always
better
than
having
two
documents.
Can
people
also
read
two
documents
as
absolutely
H,
so.
A
H
Then
again,
so
beside
any
security
and
application,
I
checked
and
whatever
so
like
I
had
some
general
concerns
that
if
you
use
flags
to
instruct
the
intermediate
router
to
do
something
specific,
that's
like
be
going
to
scope
of
what
you
initially
he
was
intending
to
do
right.
So
that's
like
for
me
it
would
be
a
different
protocol,
so
I
am
seeing
a
little
bit
more
discussion
needed
yeah.
A
A
A
H
A
That
is
it.
That
is
a
bit
of
a
risk.
Exactly
are
there
any
documents
here,
especially
in
the
encapsulation,
so
I
think
everything
else
is
fine.
Are
there
any
documents,
your
kneecaps
elations,
that
it
is
not
clear
from
y'all
commence
meeting
what
the
next
step
is
yeah,
yes,
even
that
can
be
either
tight
and
I.
Think
the
outcome
of
the
discussion
was
do.
H
E
H
E
I
think
we
discussed
that
in
men
vo3
as
well,
so
we've
been
doing
a
little
bit
of
a
shopping
tour
with
that,
and
so
it
originated
from
the
original
grn
cap
and
that
people
said
you
want
an
either
type.
If
you
want
an
either
type,
please
go
to
I
totally
only
ones,
because
it's
very
unlikely
that
he
getting
more
than
one
because
there's
multiple
protocols
that
would
benefit
from
one
and
that
evolved
to
Brian
riding
the
who's
now
retired.
He
has
loads
of
time.
So.
A
A
C
H
A
W
Extensions
to
simple
two-way,
active
measurement
protocol.
Thank
you
Rakesh
and
Tehran
for
comments,
suggestions
and
help
to
improve
the
document.
Okay.
So
what
extensions
we
take,
what
we
refer
as
base
stamp
packet
format
for
the
sender,
it's
well
known,
sequence,
number
time
stamp
and
30
updates
of
betting
to
make
it
symmetrical,
and
then
we
append
TVs
until
these
can
be
enclosed.
W
Extra
padding
TV
to
be
able
to
create
packets
of
different
size,
vocation
TV.
It
was
a
very
good
discussion,
so
location
till
the
idea
is
that
reflector
copies
from
the
received
packet,
the
source,
MAC,
address,
source,
IP,
address
and
destination,
IP
address
destination,
port
or
source
port
and
send
it
back
to
the
sender.
W
So
the
sender
can
monitor
what
is
it
an
ultimate
router
for
their
reflector
and
that
we
get
the
contribution
from
Hendrick
a
Syrian
from
their
experience
in
using
teal
and
white
in
the
field,
so
they
find
that
it's
a
very
useful
feature
again:
it's
not
a
testing.
It's
a
monitoring
time
stamp
TV!
Well,
because
of
the
way
high
time
stamp
is
obtained
and
what
synchronization
is
used.
It
effects
clearly
the
accuracy
of
the
time
stamp
and
understanding
the
accuracy
of
the
time
stamp.
We
believe
it's
useful.
W
Backhaul
wireless
backhaul,
when
the
provider
operator
has
multiple
services
on
the
same
path,
then
the
services
are
differentiated.
They
use
a
different
class
of
service
and
traversing
different
domains.
Sometimes
are
these
services,
this
markings
cost
of
service
Marcos
has
to
be
remapped
and
because
it's
a
very
manual
labor,
sometimes
humans
do
make
errors
and
their
behavior
that
it
exhibits
itself
dem
asserts
itself
is
that
how
services
packets
get
dropped
while
there
are
whole
service
of
example,
3G
keeps
going.
W
So
the
idea
of
this
is
that
sender
can
request
the
reflector
to
return
back
DCP
marking
and
is
what
received
more,
so
it
can
instruct
reflector
to
use
the
specified
DHCP
value
for
the
reflected
packet.
So
in
this
way,
in
a
very
short
sequence
of
test
packets
operator
can
verify
how
their
mapping
in
the
network,
if
it
works
properly
of
their
reserves,
miss
configuration
direct
measurement
TV.
So
it's
a
pretty
simple
there.
W
W
L
W
L
L
27
busy
plus
there
is
a
byte
offset
so
I.
The
issue
was
that,
if
responder
its
stamp
and
query
years,
of
course,
this
year
we
extensive
respondent
doesn't
and
you
get
a
message
I
the
way
I
understood
the
respondent
make
it.
It
might
think
that
28
and
29
5
is
supposed
to
tell
you
the
size
of
the
padding
afterwards
and
in
this
case,
is
zero
zero,
but
that
it
is,
there
is
one
more
bite,
so
then
it
may
not
be
able
to
process
it.
So
I
shared
that
comment
on
the
list.
Okay,.
L
W
L
L
So
agenda
is
basically
to
have
a
look
at
requirements
and
scope,
the
probe,
query
and
response
messages.
There
is
a
need
for
a
CMP
and
next
steps,
so
the
requirement
is
to
for
the
delay
in
last
measurement
for
segment
routing
for
links
and
into
end
SR
policies
for
both
SR
MPLS
NS,
a
v6
data
pins,
we're
not
using
the
control
channel
signaling,
so
eliminate
signaling
as
well
as
state
4
on
the
egress
node.
That's
the
spirit
of
SR.
There
is
requirement
for
a
CMP,
as
well
as
a
support
for
direct
mode
loss
measurement.
L
L
So
there
is
a
new
alum
message:
format
define
it's
a
fixed
message
very
similar
to
the
DM
message,
has
fixed
offsets
for
the
counters
and
another
UDP
port
is
configured
to
indicate
that
this
is
an
alum
message
for
SL
v6.
There
is
a
solid
header
with
n
function,
OTP
for
the
delay
measurement
OB
for
LM
for
SR
MPLS.
There
is
a
label
stack
for
response,
so
this,
if
you,
depending
on,
if
you're
doing
one
way
measurement
to
a
measurement.
L
L
L
G
G
L
A
I
mean
you
can
also
ask
them
to
an
adoption
call
by
email.
If
you
want
to
do
it
between
now
and
Singapore.
Right,
yes,
is
the
one
thing
that
I
would
ask
as
chair
is
that
you
keep
us
up
to
date,
at
least
on
the
mailing
list,
as
as
that
progresses
through
and
as
that
goes
to
working
across
call
and
spring,
we
should
also
do
a
work
in
your
process.
Call
here
to
make
sure
that
no,
the
changes
that
happen
in
spring
would
make
it
not
work.
A
Well,
I
would
I
can't
even
imagine
what
that
would
be,
but
just
given
given
how
this
works
and
how
the
integration
seems
pretty
clean,
but
we
want
to
make
sure
that
people
had
a
chance
to
have
a
last
look
at
it
before
it
goes
through,
and
working
group
last
call
so
yeah,
otherwise
excellent.
You
wish
you
luck.
Yeah.
U
Turn
from
Malawi
I
would
like
to
introduce
poster
carpenter
Elementary.
We
discussed
a
lot
in
this
working
group
about
the
passport
baster
telemetry,
that
is
the
IOM
the
existing
high,
and
here
this
this
drafter
is
going
to
describe
the
postcard
based
eternity.
We
described
a
lot
about
the
trade-offs,
including
the
performance
impact,
the
encapsulation
and
overhead
and
security,
and
the
configuration
correlation
and
Java
location
indication.
We
also
describe
the
postcards,
determine
solutions
and
the
implementation
considerations.
Basically,
we
introduced
the
to
PvP
mode.
Why
is
called
the
PBM?
U
Want
me,
as
now
discussing
on
how
to
apply
this
mode
here,
we
propose
a
PPT
I
said
I.
One
often
will
we
discuss
on
upgrading
in
the
side,
making
a
mental
list
to
define
a
PPT
is
a
harm
option,
and
we
close
this
discussion
on
floor
ID
and
sequence
number
by
make
them
optional
optional,
and
we
also
agreed
on
the
foreign
option
header
as
the
starting
point,
and
we
also
do
the
hack
song
and
two
three
implements
this
option
in
physical
devices.
U
Here's
an
extended
discussion
actions
to
indicate
how
to
use
them
the
data.
This
is
also
from
a
suggestion.
This
is
also
a
suggestion
from
many
lists
and
we
here's
the
initial
proposal.
We
propose
to
allocate
five
bit
from
the
flag
for
actions
and
we
propose
this
four
bits
right
now
which
are
motivated
from
from
IFA
and
our
own
panic
as
draft
and
here
there's
other
related
action
described
in
the
hi
peewee
600
a.m.
until
we
draft
like
the
sender,
telemetry
packet
and
the
sender,
ICMP
I
think
it
should
in
this
architecture.
U
U
U
V
I
Let's
see
how
long
this
question
takes
yeah,
so
just
with
regards
to
moving
forward
with
this
earlier,
we
were
mentioning
that
some
of
the
content,
that's
currently
in
flags.
We
were
going
to
be
taking
out,
and
it's
actually
we've
come
to
a
acknowledgement
that
we're
gonna
do
some
postcard
approach
check
thing.
So
I
got
the
impression
earlier
that
we're
going
to
have
a
new
draft
for
doing
that.
Is
that
something
that
this
draft
will
be
merged
with?
What?
What
is
the?
What
is
the
end
goal
for
our
postcard
end
Flags
story
here,
maybe
Frank.
F
T
I
Yes,
as
far
as
how
we
end
up
publishing
things,
that's
fine,
sir,
so
well.
What
I
would
like
to
see
is
what
we
go
forward
for.
What
we
want
to
adopt
as
work
is
one
document
on
this
approach
and
ideally
get
the
authors
from
both
working
together
on
that
document.
So
I
guess,
are
you
guys?
Okay
with
doing
that,.
U
I
I
Right,
yeah
I
think.
Ideally,
we
would
want
to
see
that
text
because
folded
into
the
thing
that
we're
discussing
as
the
PTI
draft
and
if
we
eventually
need
to
fold
the
other
one
in
as
well
that'd
be
great
but
I
think
we
do
want
to
see
collaboration
here
and
a
single
draft
as
a
guide,
especially
when
we're
you
know
looking
at
the
process
of
how
we
do
working
group
documents
like
there's
some
overhead
for
that.
I
I
E
Know
I
think
to
get
to
Cameron's
question
I
think
there
is
an
aspect
that
applies
still
IP
p.m.
and
that's
the
only
a
mess
back.
There
might
be
a
broader
thing
on
how
you
want
to
go
and
do
the
provisioning
piece
and
texture
of
the
packets
for
export
and
also
the
requirements
discussion
that
you
have,
because
that's
all
come
with
related
to
int,
as
opposed
to
what
we're
doing
here
that
might
even
go
somewhere
else
right
right.
C
A
E
A
My
point
is
the
or
our
point
from
the
chair:
it's
very
hot
Mike.
Is
that
the
document
that
we
pull
the
document
that
we
pull
for
IO
am
for
IP
p.m.
to
if
we
make
the
adoption
call
on,
should
talk
about
the
data
model
should
talk
about
the
mechanisms
driving
the
data
model
and
talk
about
the
mechanisms
for
deriving
measurement
information
from
the
data
model.
So
there
should
be
a
single
document
that
takes
some
of
the
stuff
from
the
flag
stuff.
A
That's
coming
out
of
the
current
one,
and
from
this
document
we
don't
care
who
the
authors
are,
but
we
would
like
to
see.
Collaboration
that
would
be
proposed
like
do
is
you're
a
new
0-0
individual
and
then
propose
that
for
adoption,
as
opposed
to
propose-
and
this
ralphing,
the
other
from
government
and
we'll
mix
them
up
later
cos.
It's
just
kind
of
messy.