►
From YouTube: IETF101-IPPM-20180320-1550
Description
IPPM meeting session at IETF101
2018/03/20 1550
https://datatracker.ietf.org/meeting/101/proceedings/
A
B
A
A
C
C
As
you
can
see,
this
is
the
note.
Well,
this
is
an
IETF.
C
The
working
group
status
is,
we
have
submitted
somebody
drops
to
the
iesg
in
the
past
couple
of
days
that
they
have
blue
screened.
Our
meeting,
there's
only
so
many
blue
screen
jokes,
you
can
do
in
a
row,
so
I
am
Brian.
I'll
have
your
all
week.
Actually
I
do
think.
I
can
start
running
through
on
some
of
this
stuff.
I
can
put.
The
I
can
put
the
note
well
off
in
a
moment,
so
our
working
group
status
we've
published
two
RFC's.
Oh
actually,
I
don't
have
the
up
way
too
updated.
C
Chair,
slides
here,
that's
unfortunate
because
we've
published
8321
IETF
icbm
Altmark
has
now
been
published
and
eighty-three
37
s
looked
at
the
last
draft
from
our
Orlando
charter
in
March
of
2013,
forty
thirteen,
thirteen,
okay
yeah,
it's
our
happy
5th
birthday
to
RFC
83
37
on
drop
by
ATF
I
ppm,
model-based
metrics.
So
that
is
done.
We
have
also
submitted
2330
ipv6.
So
even
though
it's
on
the
agenda,
I
have
no
idea.
Why
do
you
want
to
talk
for
a
couple
of
seconds
about
what
you
did?
C
D
C
C
E
G
E
Two
drafts
and
I'm
about
to
talk
about
it's
good
thing:
I
brought
my
machine,
so
one
of
them
is
the
update
of
our
framework
for
ipv6
testing
and
that
that
is
now
basically
done
as
far
as
the
working
group
is
concerned,
but
we
had
to
update
it
a
bit
and,
and
the
reason
we
did,
that
was
because
the
ipv6
updated
drafts
in
their
large
series
dropped
in
the
8000k
range.
So
we
had
to
update
I.
E
Guess
Nalini
noticed
that
so
thank
you
know
we
need
for
running
the
you
know
the
the
knits
checker
to
find
that
problem,
and
then
we,
then
we
actually
revised
the
text
that
refers
to
the
references,
so
that
took
a
little
time
and
then
Neville
who's
here
Neville.
Our
document
shepherd
found
the
same
problems.
Unfortunately,
we
had
a
working
version
like
ready
to
go
to
fix
those
and
Yocum
Fubini
did
most
of
the
updates
to
the
xml
and
then
once
we
all
agreed
to
it.
E
We
submitted
it
so
and
that's
so
that's
why
that
one
was
updated
and
is
now
on
its
way
good.
So
then,
so,
basically,
the
last
time
we
talked
about
so
now.
Another
draft
one
I'm
co-authoring
with
greg
mirskiy
who's
here
in
the
front.
It's
the
draft
IETF
IP
p.m.
port
T
WAMP
test.
That
is
a
draft
where
we're
moving
a
a
UDP,
well
known
port,
from
an
assignment
to
the
tea
WAMP
control
protocol.
E
Control
protocol
to
the
to
the
test
protocol,
and-
and
we
believe
this
is
done-
it's
the
combination
of
two
individual
drafts,
and
so
that's
this.
This
should
really
be
on
its
way
to,
and
we've
done
what
we
can
to
accommodate
it
in
the
yang
model.
I
think
I
would
have
liked
to
have
done
more,
but
it
was.
It
was
tricky
that
yang
stuff
is
tricky
so
anyway.
Thank
you
very
much
for
the
stats.
Thank
you
out
any
questions
on
those
two.
H
Just
looked
at
that
draft
just
before
coming
to
the
meeting
and
I
think
there's
a
mistake:
the
port,
the
last
one
you
talked
about
the
changing
of
the
UDP
port,
862
I.
Think
there's
a
mistake
in
the
table:
the
bottom
that
tells
what
Diana
should
do
it
says
I
believe
it
says:
861
1,
1
2.
Instead
861
861,
861
861.
H
C
Maybe
can
we
get
maybe
a
backup
note-taker
in
maneet
your
pad
he's
known
to
you?
If
you're
bad,
we
got
somebody
on
the
ether
pad.
Can
you
can
you
login
E?
If
you're
bad?
Ok?
Can
you
back
up
on
ether
pad
Thank
You,
Tommy
I'm
jabber,
scribe,
oh
cool?
Thank
you
too
birria
for
jabber
scribing
good.
So
this
is
our
actually.
Why
did
I
make
you
sit
down
al
you're
up
here
for
like
the
entire,
so
the
next?
So
let
me
see
we
got.
C
We
got
right
here:
ok,
20,
to
30
a
56,
we're
done
with
40
tests.
We
have
you're
gonna,
have
a
quick
look
at
what's
going
on,
then
we
have
the
metric
registry,
initial
registry
and
then
routing,
and
then
we
switch
from
the
elm
Orton
show
to
the
Greg.
Murski
show
and
he'll
talk
about
stamp
and
the
yang
models
and
then
we'll
go
to
the
IOM
portion
of
this
evenings
entertainment.
C
There
are
there's
Frank
good,
ok,
good,
and
then
we
go
to
the
lightning
talks.
Quick
question:
Carson,
Norris
and
hobo.
Are
you
here,
excellent
I
did
not
get
slides
from
you
so.
C
E
E
E
Right,
so
this
is
the
yeah.
So
this
is
the
contents
draft,
and
this
is
the
registry
that
we're
trying
to
put
the
contents
in,
and
that's
a
pretty
long
one
too.
So
we're
trying
to
oh
the
concept
here
is
that
we're
trying
to
specify
with
precision,
metrics
and
methods
of
measurement,
so
that
folks
can
make
these
measurements
all
the
same
and
we're
going
to
provide
unique,
IDs
and
so
forth
detailed
exposition,
so
that
these
things
can
be
done
the
same
way
everywhere.
E
This
is
a
general
description
of
the
registry
concept.
Each
registry
entry
is
a
row,
no
surprise
lots
of
things
that
you
can
read
there.
I'll
just
hesitate
for
a
moment,
so
the
next
slide
shows
the
category
and
column
headings,
and
so
we
have
a
summary
metric
definition,
method
of
measurement,
the
output,
administrative
info
and
the
full
history.
In
the
comments
lots
of
detail
there,
it's
the
same
for
passive
and
active
measurements,
also
hybrid
measurements,
so
they
should
all
fit
in
here
when
they,
when
they
matter
so
here's
the
updates
for
both
graphs.
E
So
we've
revised
the
passive
TCP
metric,
which
was
added
in
13,
we've
added
a
handshake
metric.
This
was
previously
the
the
TCP
syn
ACK
metric,
but
I
generalized
this
to
be
called
handshake
because
that
that
kind
of
future
proof
sit
for
the
the
days
when
we're
trying
to
do
something
like
this
with
quick.
If
we
get
there
and
and
it's
not
going
to
be
quick
so
so
there's
the
name
round-trip
delay,
passive
IP,
TCP
HS,
that's
a
new
naming
element
for
handshake
and
that's
the
one
we
can
reuse
and
then
I'll.
E
Note
I'll
note
down
there
at
the
bottom
that
that
we've
also
added
quick
to
the
naming
elements.
So
when
a
qualified
and
corresponding
packets
are
a
TCP
syn
and
they
see
peace
in
ACK.
That's
when
we
get
the
round-trip
delay
in
the
forward
direction,
we're
assuming
and
an
observation
point
sort
of
in
the
middle
between
the
two
endpoints
and
you
get
basically
two
halves
or
the
round-trip
delay.
The
RTD
forward.
Rtp
reverse
put
them
together.
You've
got
the
total
alright,
so
oh
I
went
back
sorry,
oh.
E
It's
the
same
slide.
All
right
now,
wait
a
minute
wait:
a
minute,
yeah!
Okay!
There
we
go
sorry
about
that.
So
registry
and
metric
drafts
update
the
future.
Here's
the
future.
Now
we
we
really
need
look
at
them
at
the
heuristics
for
the
methods
of
measurement
in
the
TCP
passive
work.
I
I
said
right
here
at
hackathon
101.
We
had
a
good
discussion
about
the
heuristics
in
general
and
we
examined
sort
of
ourselves
how
the
TCP
heuristics
would
change.
When
we
look
at
TCB
I'm.
E
Sorry,
quick
with
a
spin
bit
implementation,
a
spin
bit
basically
means
for
those
who
haven't
become
familiar
with
it.
It
basically
means
that
you
get
one
sample
of
round-trip
time
sort
of
per
window.
Let's
say
for
per
total
round-trip
time.
You
don't
get
a
round-trip
time
for
every
packet.
So
that
means
that
it
that
when,
when
we
have
a
when
Brian
has
used
in
the
past
a
round-trip
time
window
for
evaluating
round-trip
time
samples
for
TCP,
now
we're
not
going
to
be
able
to
do
that.
We
need
a
larger
window
to
do
that.
E
Brian's
at
the
mike
I'm
an
already
in
line
keep
going.
Okay,
so
I've
got
a
lot
of
items
here
which
we,
which
we
recorded
I,
want
to
thank
Emil,
Stefan
and
Alex.
His
colleague
for
going
through
a
lot
of
this
with
me
I
think
we
collected
a
lot
of
good
stuff
here
and
ways
that
we
can
improve
both
the
metrics,
the
heuristics
we've
got
for
the
methods
of
measurement
and
the
future.
C
C
Method
here
is
not
really
necessarily
quick,
specific
right.
It
actually
looks
kind
of
like
an
alternate
marking
method,
but
it's
an
alternate
marking
method,
where
the
alternate
marking
is
dependent
on
transport
state
because
of
how
the
how
the
spin
algorithm
works.
We
did
some
experimentation
with
this
at
ETH
and
found
that
it
actually
gives
you
better
RTT
measurement.
C
Then
you
get
inside
the
crypto
in
certain
cases
because
of
just
the
frequency
of
acts
when
you
have
a
unidirectional
traffic,
so
the
spin
bit
actually
gets
you
more
edges
than
you
get
RTT
samples
just
looking
at
the
extreme
Wow
when
you're
coalescing
acts.
So
this
is
we're
doing
this
work
for
quick
and
we're
doing
this
metric
work
in
quick
and
if
the
spin
bit
doesn't
end
up
in
quick,
then
it's
probably
not
extremely
useful
to
put
it
in
this
registry,
but
the
the
two
different
spin
mechanisms.
C
One
is
a
one
bit
spin
and
one
is
a
three
bits
been
that
we
were
looking
at
are
kind
of
general
of
mechanisms
right.
You
could
add
them
to.
You
could
put
them
on
an
extra
bit
and
I
mean
I.
We
have
many.
C
Many
extra
bits
in
the
ipv4
header,
obviously
we
just
grab
one
of
those
you
could
have
a
you
know
a
gigantic
destination
option
for
your
little
three
bit
thing
which
use
incredibly
wasteful,
but
I
mean
like
so
the
general
marking
mechanisms
are
generic,
so
it
might
make
sense
to
nail
this
down
a
little
bit
more,
regardless
of
what
happens
on
Thursday,
I'm,
cautiously
optimistic,
but
well.
C
B
C
The
estate
you
have
to
keep
the
thing
that
you're
looking
for
the
signal
that
you're
using
it's
all
different
so
and
the
yeah
the
three
bit
spin
is
actually
kind
of
it's
kind
of
weird
and
designed
it's
designed
to
solve
a
specific
problem
that
runs
that
you
run
into
when
you're,
using
a
one
bit
signal
in
a
environment
where
you
have
Lawson
reordering
right,
great
okay.
So
it's
not
that
weird!
But
I
mean
it's
a
fundamental
problem.
B
C
F
E
Good
thanks
for
your
comments,
so,
like
I,
said,
I'm
not
going
to
go
through
all
this
in
detail,
but
you're
welcome
to
read
it
and
appreciate
it
more
updates.
E
E
We
could
do
more
and
also
I
got
an
email
from
Fred
Baker
from
basically
from
the
root
server
and
a
service,
a
root
server,
Service
Advisory
Committee
our
sasak,
and
they
need
metrics
to
support
recommendations
to
root
server
providers,
so
kind
of
SLA
like,
and
so
it
would
help
them.
If
we
did,
if
we
did
more
in
this
space,
it
may
be
beyond
the
scope
like
I
said
future
there.
It
may
be
beyond
the
scope
of
what
we're
trying
to
accomplish
here
now,
but
but
that's
that's
something
worthwhile,
noting
all
right.
E
So
next
steps
we
really
need
this
TCP
section
section,
10
reviewed
we've
I'd
like
to
see
DNS
response
time
and
loss
also
reviewed,
because
I've
got
that
quad
at
symbol
there.
We
have
to
look
at
two
methods
in
order
to
be
able
to
measure
loss
and
sort
of.
The
final
thing
is
that
on
Thursday
I've
been
asked
to
come
and
talk
to
the
XR
block
group
it's
late
Thursday
afternoon,
and
they
want
to
provide
input
to
the
registry.
This
was
kind
of
a
surprise
to
me,
but
glad
to
get
it
I
mean.
E
I
Yeah
actually
yeah.
That's
me
Brittany's
work
too,
as
a
POC
and
I
think
things
are
saying:
yeah
I'm.
So
today
we
are
going
to
discuss
whether
this
over
this
metrics
should
be.
You
know,
including
whether
it's
a
buck
should
do
this
work
or
and
if
we
do,
what
kind
of
a
metric
is
repeating?
Could
yeah.
E
I
E
E
H
E
G
E
E
Anybody
for
dns
really
needed
somebody.
Anybody
know
anybody
who
knows
Ignacio
good.
Thank
you
all
right,
so
this
so
this
is.
This
is
one
that
we
really
ought
to
sort
of
pick
up
and
get
going
again
now
that
we've
got
an
RFC,
I
think
and
Matt
and
I
will
we'll
work
that
in
our
copious
spare
time-
and
that's
my
last
thought
on
on
this.
Thank
you.
Oh
Matt.
D
This
document,
and
actually
the
general
problem
of
extensibility
for
the
registry,
has
suddenly
become
worried
to
me.
It
feels
like
we're
gonna
grease,
a
huge
population
of
tiny
RFC's
to
essentially
add
one
line
in
a
registry,
and
it
feels
to
me,
like
a
lot
of
those
in
many
cases,
belong
as
a
separate
section
in
the
base
document,
and
it's
future
based
documents.
D
E
E
E
Doing
the
the
now
interestingly
named
Ora
draft
advanced
unidirectional
route
assessment,
I
can
say
the
names
from
memory
yeah,
Ignacio
I
was
here
in
the
front:
al
Morton,
Yoakam,
Fubini
and
Carlos
pignataro,
well,
I'm,
not
sure
who's.
Here,
this
time
I
don't
think
he
is
I
haven't
seen
him
yet
yeah.
So.
E
So
we're
doing
it
and
okay
so.
C
E
We
we
introduced
this
draft
kind
of
a
year
after
meeting
Ignacio
and
in
Buenos
Aires,
and
got
some
good
comments
from
rüdiger
gibe
and
Frank
Bachner.
We
had
a
strong,
strongly
informed
scope
discussion
at
IETF
100.
We
had
proposals
from
Carlos
to
cover
more
than
IP,
basically
to
start
to
look
at
other
layers
and
and
and
so
forth.
What
we
agreed
was
that
we
could
make
the
definitions
of
a
hop
and
a
host
identity
and
so
forth,
I'll
get
to
those
in
a
minute.
We
can
make
them
more
general,
but
we
have
to.
E
We
will
consider
what
work
is
applicable
at
other
layers
as
needed
and,
as
I
said,
we
at
Carlos.
So
here's
how
we've
generalized
the
definitions
so
the
for
the
for
the
true
scope,
it's
the
internet
and
hosts
communicating
on
IP,
that's
where
this
is
directly
applicable,
but
we're
saying
it's
applicable
to
other
network
domains
if
desired.
E
Its
current
wording.
So
now,
we've
generalized
terms
like
host
identity
so
that
they
remove
IP
from
the
first
sentence
and
then
make
it
specific
for
IP.
So
that
makes
it
generalizable
Jose
and
any
the
unique
address
for
hosts
communicating
within
the
network
domaine
it's
a
globally
routable
IP
address
for
IP.
This
is
the
address
that
they
use
for
normal
communications
and
error
communications.
E
That
error
part
is
important
for
discoverable
hosts
it's
host
to
convey
their
host
identity
according
to
the
requirements
of
the
network,
domains
such
as
when
error
conditions
are
detected
and
that
that
would
be
important
when
ICMP
sends
a
time
and
exceeded
message
when
discarding
packets
and
it
means
it
complies
with
1122
and
1812,
so
we're
jet.
So
now
we're
still
generalizing
the
definitions
and
more
a
cooperating
host,
it
must
respond
and
it
should
provide
other
info
and
that's
a
this
is
me.
E
This
is
the
interrogation
kind
of
protocol
we'll
hear
more
about
that
later
from
other
authors,
but
this
is
where
you're
we're
being
explicitly
asked.
What's
your
address,
what
let's
see
so
in
the
remainder
of
section
3,
we've
really
cleaned
up
all
sorts
of
things
like
the
fact
that
the
IP
address
and
TTL
and
other
terms
appeared
in
various
parameters.
We've
generalized
those
four
hop
member
route
and
route
ensemble.
That's
kind
of
the
hierarchy
of
of
things
that
we'll
measure
and
report
here
so
here's
questions
for
the
working
group,
something
we
can
discuss.
E
So
consider
first
whether
work
needs
to
be
done
and,
and
one
way
to
do,
that
is
to
kind
of
look
at
how
it
might
be
done
in
this
context.
So
we
think
a
candidate
for
for
an
appendix
that
shows
the
applicability
beyond
IP
would
be
based
on
MPLS
ping
and
traceroute
would
use
RC
a
29
can
be
applied
to
IP
because
it's
already
being
sort
of
done
in
a
v6
datacenter
and
last
time,
greg
mirskiy
suggested
63
74
for
loss
and
delay
measurement
in
this
space.
E
H
E
All
right
anything
else
on
that:
okay,
so
reporting
the
metric.
One
point
that
Carlos
asked
me
to
make
at
this
point
was
that
we
don't
want
to
sort
of
fix
a
something,
rigorous
format
wise
here,
that
when
we
make
the
measurement
there
can
be
multiple
ways
to
report
this.
We
might
have
multiple
options
here,
but
we've
looked
at
this
on
various
times
in
various
places
and
seeking
some
wise
and
experienced
input
on
on
this
particular
topic.
C
C
Think
we
want
to
do
that
right.
Anyone
who
wants
to
understand
why
I
say
that
go
read
the
first
couple
of
pages
of
it.
One
thing
that
I
think
whatever
format
we
have
for
this
should
capture
is
that
you
never
from
any
of
the
methods
that
we
know
how
to
do
for
for
route
connectivity.
You
never
get
an
assertion
that
no
Dax
is
connected
to
node
Y
right.
C
So
the
we
should
somehow
capture
in
the
V
in
the
format
that
we're
not
talking
about
hops,
we're
talking
about
measurements
that
at
a
certain
distance
at
this
point
in
time
we
saw
this
right
and
then
you
can
infer
what
you
want
to
from
that.
But
we
don't
to
repeat
the
inaccuracy
here.
There
are
there's
recent
academic
work
in
inferring
interconnection
among
entities
from
priests,
route
data,
okay
and
BGP
data.
C
It
turns
out
you
need
both,
so
there
is
anti-aliasing,
so
there's
a
thing
called
map
it
and
a
thing
called
border
map
and
you
can
actually
glue
them
together
and
they
they
work
nicely
together.
But
that
gives
you
a
more
in
a
s
level:
interconnection
graph
and
not
a
IP
layer,
interconnection
graph,
which
is.
B
C
L
L
L
If
you
are
talking
about
BGP,
this
is
different
things,
but
normally
you
can
got
some
more
more
information
because
just
to
map
the
IPS
to
the
prefix
and
traffic
to
the
IES
number,
you
can
got
some
connections
on
real
connections
and
but
normally
you
got
less
connections.
Then
you
see
the
BCP
tables
attribute
project
because
you
more
or
less
you
got
a
lot
of
information
there
and
sometime.
There
are
some
informant
routes
that
they
are
not
being
used
because
you
have
not
problems
or
because
another
things
there
for
you.
E
M
Remark
if
you
work
on
on
MPLS
or
an
Ethernet,
this
would
delay
your
draft
I
guess,
because
you
need
the
expertise
and
that
needs
to
be
sober
and
it
will
be
different
from
what
you
write
on
IP,
because
in
order
to
make
sure
that
packet
passes
the
same
link
on
MPLS,
you
do
something
completely
different
than
you
do
on
IPs
suggested
by
Ignacio.
So
maybe
you
should
only
write.
One
could
do
that
for
MPLS,
and
then
this
will
be
another
document.
Yeah.
E
Okay,
we
wanted
to
ask
thanks
for
the
input
all
right,
so
we
still
have
lots
of
things
to
do
that.
A
lot
of
them
were
suggested
by
Carlos
when
he
was
a
commenter
and
not
a
co-author
one
by
Frank
bottners
there
and-
and
then
we
skip
that
last
one.
So
we'll
keep
those
in
mind
got
to
get
those
solved
for
another
discussion
area.
E
It's
the
temporal
composition
for
route,
metrics
passed
measurements
influence
current
results.
This
is
pretty
well
understood
if
you
measure
something
now
and
it's
doesn't
change
it'll
be
the
same
route.
So
can
we
spot
check
past
measurements
at
critical
hops
where
they
have
sort
of
diverged
into
you,
know
multiple
parallel
paths
and,
and
that
way
reduced
the
measurement
load
and
a
time
that's
something
I
think
we
should
think
about
I'd
like
to
sort
of
hear
from
folks
in
their
route
measurement
experience.
E
You
know
whether
they
found
you
know
how
much
stability
they
found
in
their
little
corner
of
the
internet
because,
as
Matt
pointed
out,
rightly
in
the
last
meeting,
what
what
what
you've
seen
of
the
Internet
is
different
from
what
everybody
else
has
seen.
So
so
you
really
have
to
ask
the
question
in
the
broad
context
of
this,
of
this
crowd
here.
E
So
there's
other
things
that
we
should
probably
develop.
I
like
the
idea
that
the
hop
and
route
concepts
they
sort
of
treat
a
class
of
packets,
what
we
call
Class
C,
we
treat
them
equally,
they
all
get.
You
know
routed
on
the
same
path.
Typically,
it's
useful
to
know
it's
a
concept
from
a
couple
of
RFC's
that
we've
that
we've
had
in
the
past,
they're
all
the
way
back
to
2330
and
and
the
newer
77
to
99,
but
I
think
that's
that's
sort
of
worth
thinking
about
and
doing
more
with
here.
E
So
let
me
leave
those
errors
or
areas
they're,
so
complete
the
do's
and
continued
development
and
discussion
items.
But
here's
where,
thanks
to
Ronnie's
good
reminder
from
last
time,
let's
try
to
line
up
some
reviewers
for
the
draft,
especially
sections
4
5
&
6,
which
are
ignacio's
main
contributions
to
this
work
and
which
talk
about
the
methods
of
measurement
talk
about
that.
The
tools
that
can
make
these
measurements
and
the
delay
analysis.
So
that
should
be
fun
should
be
a
good
read.
C
Who,
in
the
room,
done
work
with
trace
routes.
E
C
G
E
C
Not
sure
yet,
okay,
that's
really
research,
II,
stuff,
okay,
so
for
so
I
shouldn't
say
too
much
because
some
of
this
will
be
discussed
tomorrow
during
the
plenary.
But
a
side
project
off
aside
project
was
a.
C
Yari
primarily,
is
putting
together
sort
of
as
a
as
I
project,
a
tool
to
figure
out
what
the
efficiently
figure
out.
What
the
path
distance
between
two
points
on
the
Internet
is,
so
it's
basically
like
priests
route,
but
it
tries
to
send
fewer
than
a
traceroute
worth
of
packets,
and
you
know
what
caches
things
remember,
stuff
and
so
on
and
so
forth.
So
so
hot
distance
is
an
interesting
like
not
the
actual
Hopsin
entries
route,
but
the
number
of
hops
new
trace
route
is
an
interesting
secondary
metric
for
doing
classification
of
primary
metrics.
C
So,
for
example,
there
was
this
this
thing
that
I
did
for
the
quick
RTT
design
team.
C
C
E
L
Just
a
little
comment
about
the
last
one:
when
you
do
some
measurements
using
TCP
or
quick
or
whatsoever,
and
the
difference
is
the
way
that
you
are
gathering
the
information
with
traceroute.
You
say:
okay,
I
will
gather
every
second
or
every
fixed
time
deterministic
time,
and
this
is
different.
You,
you
got
less
resolution.
You
got
much
more
resolution
in
the
other
case,
but
from
the
statistic
point
of
view
you
are
not
doing
exactly
the
same,
and
this
is
a
special
point.
I
J
Since
we
already
discussed
what
was
became,
zero
version
in
Singapore
I
only
give
you
a
diff.
We
welcome
Richard
foodie,
you
know
him.
Mr.
fuller.
He
provided
very
good
comments
and
helped
us
to
advance
this
version.
So
we
expanded
introductions
section
did
update
on
the
terminology
to
make
it
more
I
goofed,
to
make
it
more
familiar.
J
Those
who
work
with
t1
and
make
it
less
Sdn
centric,
so
that
to
point
out
that
control
of
stamp
entity
can
be
provided
from
OSS,
BSS,
proprietary
COI
or
as
the
end
using
neck
and
yank
and
clarified
use
of
Z
field
of
error
estimate
field
that,
based
on
RFC,
that
we
have
to
support
TTP
format.
How
interoperates
we
discussed
among
offers
and
decided
so
to
make
this
document
leaner
and.
J
So
what
we
see
is
in
open
issues
is
security
encrypted
authenticated
mode.
What
we
want
to
support
in
stamp
because,
as
we
discussed
in
the
previous
meetings,
the
goal,
the
requirement
we
set
for
the
staff
is
to
be
compatible
with
the
T
WAMP
in
unto
gated
mode.
We
think
that
achieving
compatibility
on
a
wire
with
the
T
WAMP
encrypted
authenticated
mode.
It's
too
high
requirement
because
of
the
way
how
encryption
and
authentication
negotiated
in
81
control
protocol
so.
H
Yeah
yeah
kufstein
number
one
I,
think
that's
fine,
because
the
use
of
the
authentication
and
encryption
in
the
field
is
actually
relatively
limited.
The
encryption
I
personally
never
understood
why
anyone
would
want
secrecy
on
a
test
packet
anyway.
The
authentication
makes
sense,
but,
as
I
said
before,
it's
really
not
that
used
so
losing
the
ability
to
inter
work
with
the
system,
which
really
is
not
that
much
in
the
field.
I,
don't
think,
is
a
major
loss.
H
B
J
H
H
Absolutely
it
could
be
either
service
stealing
of
this
or
doing
bad
things
and
I
understand,
but
encryption,
it
doesn't
I,
don't
understand
the
use
case
and
therefore
I
think
you
can
just
you
know,
forget
about
it.
If
someone
really
says
they
may
need
that
put
something
in
it
doesn't
have
to
be
compatible
with
anything
right.
Okay,
so,
okay,
we.
J
Agree
on
that
compatibility
may
not
be
a
requirement,
is
a
non
requirement.
I
think
that
the
only
possible
scenario
is
that,
because
now
monitoring
SOA
becomes
a
part
of
why
cycle
orchestration
and
failing
of
out
of
SLA
may
become
some
event.
That
system
will
react
so
man-in-the-middle
mingling,
with
your
measurement
results,
can
affect
your
view
of
quality
of
the
service,
which
would
not
be
objective.
H
Because
it
will
be
skewed
and
I
think
actually
your
career
or
actually
giving
a
good
proof
of
the
opposite,
because
if
you're
going
to
look
at
an
LS,
oh
monitoring
system,
if
it's
encrypted
packets,
then
you
don't
really
know
how
to
monitor.
Unless
you
push
the
keys
into
the
middle
of
the
network,
which
sort
of
is
creating
a
problem
that
probably
says
that
the
encryption
is
a
bad
idea,
so
yeah
I
understand
what
you're
saying
about
you
can
read
it.
H
J
Our
call
to
the
community
is
to
look
at
current
document,
because
we
just
effectively
replicated
the
format
of
the
packet
as
it
is
integral.
So
is
it
something
that
we
want
to
carry
on
just
knowing
that
this
package
would
not
be
compatible
with
the
tea
womp
in
encrypted
authenticated
mode,
because
what
we
would
like
to
do
is
we
would
like
to
progress
this
document
as
rapidly
as
possible.
H
J
H
J
H
H
J
Okay,
so
again,
it's
too
small
script:
I
cannot
read
it
from
here.
I
have
to
acknowledge
that.
But
yes,
please
read
the
document
and
or
you
can
do
a
deep
with
the
zero
version
one
to
zero
and
take
a
look
on
unlived
ifs
and
review
there.
What
we've
changed
and
common
that
it,
whether
you
like
it
or
not
on
yes,
we
split
a
little
bit
different.
J
So
outside
of
the
step.
It's
just
a
matter
of
preference.
You
can
use
ACLs
to
filter
our
traffic
that
it's
destined
the
step,
and
especially
that
is
easier,
because
if
you
use
a
well
known
port
862
that
we
make
and
a
default
for
reflector,
then
it
makes
it
much
easier
to
put
up
ACLs
and
then
make
reflector
configuration
minimum
as
possible.
H
J
I
can
I
can
pour
into
BB
FTR
390,
which
has
a
similar
idea.
As
you
know,
I
thought
it
was
wrong
there
as
well.
Okay,
I,
don't
argue,
but
again
III
want
to
stress
that
this
is
optional.
So
this
is
not
the
only
way
to
do
reflector.
Yes,
you
can
do
it
very
explicit,
configure
identity
of
the
senders
on
the
reflector.
Of
course.
J
H
From
the
point
of
the
default
once
again
going
back
to
security
from
the
security
point
of
view,
I
believe
that
even
a
quote,
unquote,
dumb
reflector
should
have
the
concept
of
a
session.
Otherwise
you
can
overwhelm
it
by
sending,
in
this
case,
port
862
added
from
unknown
places
and
just
overwhelm
it,
and
then
you
don't
get
response
from
it.
Here's
a
security
problem.
Do
it
the
right
way,
I.
H
J
Point,
ok,
so
that's
an
example
of
sessions
that
are
configuration
I
on
purpose.
Are
we
on
purpose
left
everything
which
will
go
away
because
it's
basically
default
just
to
demonstrate
that
and
you
can
did
you
so
we
can
just
produce
the
real
configuration
how
a
small
configuration
would
be
if
we
use
the
default
settings.
J
J
E
C
E
C
Yeah
you're
all
going
talk,
guys
I,
don't
I
I
can't
remember
when
we've
been
this
far
not
behind
at
this
point
in
an
IP
p.m.
meeting
Frank.
D
B
N
I'm,
sorry
for
that
I
tended
to
go
and
copy
that
title
slide.
It's
it's
corrected
on
the
draft
by
the
way,
so
the
draft
has
even
David's
new
headers.
So
sorry
for
that
good
catch.
Well,
I'll
correct
that
for
the
Montreal
meeting,
so
there
is
I
think
two
main
changes
to
the
draft
as
it
stood.
The
first
thing
is-
and
we
have
quite
a
debate
in
Singapore
on
that
timestamps
again-
that
we
had
well
a
need
for
more
than
one
time
Stan
format.
Some
people
argued
for
1588.
Some
people
argued
for
MTP.
N
There
is
been
more
recently
even
argument
for
positive
time.
A
POSIX,
timestamps
and
people
not
only
wanted
to
use
the
time
stamps
for
hop-by-hop,
but
they
also
wanted
so
for
tracing,
but
they
also
wanted
to
use
it
in
an
end-to-end
way.
So,
and
we
wanted
to
harmonize
that
instead
of
having
multiple
things
flying
around,
that's
something
that
we've
done
that.
N
N
So,
on
the
IOM
type
thing,
that's
apparently
something
that,
from
a
problem
perspective,
Brian
brought
to
us
and
Bryant
started,
writing
and
encapsulation
draft
for
GRE
and
well
then
he
started
doing
that
and
he
found
out
that
with
the
original
approach,
how
data
was
structured,
we
had
a
OM
type
field
for
the
two
versions
of
tracing
incremental
tracing
and
pre-allocated
tracing.
What
we
didn't
have
is
a
code
point
in
the
iom,
data
draft
for
and
to
end
options
or
proof
of
transit
options,
which
means
from
a
parent
protocol
perspective.
You
need
it.
N
N
There
is
now
room
for
multiple
additional
types
if
we
ever
come
up
with
us
in
the
future,
and
the
other
benefit
is
that
we
have
a
single
code
point
from
a
requirements
perspective
when
we
ever
ask
a
parent
protocol
go
and
go
and
encapsulate
and
we'll
see
that
in
a
sequence
of
additional
things
later
on
so
I
think
that's
the
benefit
that
we
can
go
and
harmonize
single
code
point
from
upstream
and
that
obviously
solves
the
problem
with
the
GRE
draft
immediately.
We
only
need
single,
either
type.
So
there's
a
question
just.
H
A
comment
I'm
glad
you
have
made
this
extensible
because
I
have
another
option
here
having
to
do
with
proof
of
transport
or,
but
you
know,
P
ot,
as
personally
defined,
does
not
check
order
just
that
it
goes
through
the
different
points
and
I
have
made
an
extension
to
that
which
also
checks
the
same
time
order
and
once
again,
not
right
now
bringing
it
to
the
IDF.
But
at
some
point
I
will
be
in
with
me
another
point.
So.
N
N
N
Right,
so
that's
an
interesting,
so
let's
chat
offline
because
so
far
we
had
that
trade-off,
discussion
and
P
ot
like
if
you
do
crypto,
then
you
need
typically
hot
vs.
to
do
that
in
an
efficient
way
on
every
single
packet.
If
you
do
shimmy
your
secret
sharing
the
vanilla
way
like
we
did
it
then
well,
you
lose
that
particular
attribute
of
being
able
to
check
sequence
and
okay.
N
Well,
let's
chat
offline,
because
that
might
be
the
perfect
middle
way,
because
people
have
been
arguing
over
proof
of
transit,
two
options,
not
great
options
are
awful
because
it
leads
to
duplication
in
implementation,
so
that
might
be
a
good
option
to
go
and
explore
us
as
a
kind
of
solution
option.
So
well,
that's
what
we've
done
so
far
so
from
a
clean
up
perspective,
encapsulation
now
as
far
smoother
and
you'll
see
that
later
on.
So
the
basic
asks
for
every
single
encapsulation
for
every
single
upstream
protocol
that
we
have
is
for
a
single
core
point.
N
The
second
thing
goes
to
the
timestamp
format.
What
we've
been
harmonizing
is
there
is
now
a
single
section
that
discusses
timestamps,
and
so
we've
been
farming
out.
The
text
that
was
kind
of
scattered
around
in
incremental
tracing
in
pre-allocated
tracing
in
the
edge
to
edge
option,
and
we
found
that
out
into
a
dedicated
into
a
dedicated
section,
and
in
that
dedicated
section
we
cover
now
well
the
three
typical
uses
of
time
from
a
format
perspective,
be
it
NTP,
POSIX
time
or
p
TP
1588.
N
You
know
that
IOM
had
a
little
bit
of
from
an
implementation
perspective
heritage
from
ipv6,
so
we
use
doctors
left
not
too
great
because
it
started
to
confuse
people,
so
those
things
became
their
own
nomenclature.
Now
we're
using
things
like
the
remaining
length
to
important
voice
potential,
confusing
confusion
with
upstream
other
protocols.
That's
basically,
what
we've
done
on
the
data
draft.
N
Well,
please
continue
to
shoot
your
comments
trying
to
get
this
thing
stable.
It's
starting
to
really
look
clean
by
now.
There's
two
areas
that
need
clima
cleanup.
The
Security
section
needs
a
load
of
additional
love,
hoping
to
get
that
filled
in
over
the
course
of
the
next
couple
of
weeks.
Same
goes
for
the
manageability
section,
and
we
have
a
section
on
IOM
data
export
there
that
I'm
about
to
go,
kill
because
Mickey
with
a
couple
of
other
guys,
including
myself,
wrote
a
draft
that
covers
a
very,
very,
very
simple
way
to
do.
N
N
C
N
C
Talk
to
me
is
an
information
element
expert
about
that.
At
some
point
we
should
have
that
discussion.
Yeah.
N
C
Great
questions
so
I
have
a
chair
question.
You
say
targeting
a
stable
document
by
IETF
102.
Does
that
mean
you
want
to
start
the
working
group
last
call
in
Montreal.
Let's.
N
C
C
C
B
B
N
N
Yeah
so
baseline,
what
we
want
from
a
from
an
overall
encapsulation
perspective
is
people
will
do
and
do
this
already
in
hardware.
So
there
is
running
code
in
hardware
today,
and
that
means
whatever
we
do
from
an
encapsulation
perspective.
If
the
protocol,
the
upstream
protocol
allows
for
choice,
let's
not
make
their
life
or
let's
not
make
the
the
implementers
life
in
Hardware
too
hard.
N
So
that's
one
of
the
mantras
that
we've
been
in
being
preached
so
avoid
nested
structures
wherever
possible,
because
pointer
lookups
in
hardware
are
difficult
and
challenging
because
you
need
to
do
that
at
high
speed.
The
other
thing
is
what
we
learn
and
I
already
talked
about.
That
is
make
sure,
or
you
can
only
in
many
cases,
use
a
single
code
point
from
upstream.
N
Well,
we've
been
evolving
the
data
draft
for
doing
that.
So
with
that,
we
can
pretty
much
have
an
encapsulation
approach
for
all
the
protocols.
That
is
very
consistent,
because
all
we
need
is
a
single
upstream
code
point.
The
question
is
only
what
is
the
upstream
code
point
in
certain
cases
there
is
choice.
N
N
The
other
thing
is
that
io
am
is
not
expected
to
alter
really
the
forwarding
behavior
off
the
packet
more
than
it
needs
to,
and
that
means
whenever
we
encapsulate
into
a
protocol,
we
don't
want
the
traffic
to
be
flagged
as
OAM
traffic,
because
it's
customer
traffic
we're
just
adding
additional
metadata
to
customer
traffic
as
opposed
to
we
are
creating
OAM
traffic.
This
is
not
probe
traffic
just
because
we
suddenly
add
the
iom
and
form
a
and
that
means
well.
N
We
want
to
make
sure
that
well,
that
distinction
is
is,
is
clearly
in
there,
because
many
protocols
have
a
notion
of
Oh
am
traffic,
and
that's
not
that
nothing
that
we
already
want
to
go
do,
and
the
other
thing
is
that
we
want
to
go
and
keep
I
of
what
it
does
relatively
separated
from
the
parent
protocol
right.
So
the
semantics
that
I
has
don't
necessarily
need
to
be
known
and
vice-versa
off
the
parent
protocol,
because
people
might
want
to
go
and
do
the
I
up
operation
in
a
blow-up.
N
O
Ok
well,
I'm,
probably
wise
I
still
had
a
use
case
for
the
end
case
with
Giri,
and
so
I
ended
up
inheriting
a
draft
as
it
goes
so,
though
that
became
useful
which
and
that
did
help
us
I,
think
understand
how
to
clean
up
the
encapsulations
a
little
bit
from
what
was
there
just
to
eat
just
because
it
was
a
something
that
we
finally
had
to
really
focus
on.
So
this
is
really
simple.
There's
this
one
new
code
point
is
Franco
saying,
which
is
that
says
this
is
IOM
packet
and
then.
O
That
defines
the
IOM
what
they're
going
to
happen
next
in
Giri,
and
then
you
immediately
go
to
what's
defined
in
the
data
grafter
after
that.
So
there
was
an
intention
here
of
not
redefining
whatever
was
in
the
data
draft
but
point
to
the
namespace
I
think
we've
gotten
there
very
nicely
and
okay,
so
we
really
just
defined
one
little
shame.
J
O
J
N
N
J
Because
the
idea
of
and
actually
the
Charter
of
overlay
design
team
was
to
produce
om
that
can
be
used
in
different
overlay
networks,
and
so
we
have
that
and
we
came
up
with
one
single
document
and
now
we
have
three
different
document
that
proposed
the
same
construct,
whereas
their
construct
is
the
same,
which
is
not
surprised
to
me,
because
I
know
that
it
can
be
same
so
I.
Just
wonder.
J
N
So
we
are
not
so
that
if
you
read
through
the
documents
right
so
the
endcap
looks
similar,
but
it's
not
entire
the
sign.
That
means
you
have
to
go
and
come
up
with
something
that
little
shim
that
is
protocol-specific,
right
and
I,
think
we're
repeating.
Maybe
we
just
go
and
quickly
skim
through
that
that
was
the
GRE
shim,
where.
D
N
Using
next
protocol,
you
need
something
that
gives
you
the
IOM
type
and
the
overall
length
of
this
body
right.
That's
what
you
do
in
a
GRE
if
you
are
in
V
X
lon
and
using
the
shim
header
there,
you
end
up
again
using
next
protocol
and
you
need
a
shim
that
encapsulate
your
IOM
data
right.
It's
slightly
different.
The
approach
is
the
same,
but
I
think
there
is
no
that
no
such
thing
that
you
can
use
a
generic
header
for
all
those
protocols.
J
N
J
J
J
Solution
is
limited
because
you
limit
yourself
only
to
1k
of
IOM
data.
Okay.
So
if
you
have
more
than
one
kom
data,
what
you
want
to
transport
you
are
in
the
same
problem.
You
have
with
the
teo
v
with
the
limited
length.
Okay,
so
why
to
offer
limited
solution
when
you
can
get
another
throw
another
for
octaves
and
then
the
sky's,
the
limit.
You
have
all
the
flexibility
you
need,
you
even
have
reserved
fill.
You
have
a
versioning.
You
have
everything.
N
Which
is
well
we'll
come
in
here
right.
We
want
that
debate,
so
we've
been
arguing
this
for
for
quite
some
time
from
an
efficiency
perspective.
So
Gregg
is
in
the
I,
want
it
in
the
most
clean
way
as
possible.
Can
we
can
also
argue
the
thing
from
let's
do
it
in
the
leanest
possible
way
camp
way?
N
Originally,
why
did
we
arrive
at
using
not
a
single
code
point
from
upstream
but
three
originally?
Why
was
it
that
way?
Because
we
try
to
go,
do
it
as
kind
of
condense
as
possible,
so
if
you're
able
to
steal
stuff
from
upstream,
you
don't
have
to
go
and
define
it
yourself,
which
ended
up
being
more
efficient
on
the
wire
here.
Well,
we're
trying
to
go
and
walk
this
fine
line
between
cleanness
and
efficiency.
N
Yes,
we
can
spend
another
four
bytes,
but
we
already
know
even
today,
that
certain
lookup
engines
are
relatively
constrained,
how
far
they
can
go
and
look
into
the
pocket.
Certain
lookup
engines
today,
from
an
IOM
perspective,
only
support,
say
time,
stamping
for
instance,
why,
because
they're
limited
in
their
lookup
depth,
if
you're
looking
at
use
cases
that
are
just
caring
about
end-to-end
time
stamps,
and
you
just
want
to
go
slot
that
in
and
certain
use
cases
do
that
Ryan
right
then
well,
this
lookup,
that
becomes
a
constraint.
N
So
people
wanted
to
go
and
have
it
dense.
If
we
find
consensus
that
well,
we
want
to
go
and
spend
extra
bytes
for
getting
more
flexibility
I'm.
All
for
that.
If
we
can
get
well
the
entire
party
behind
that,
because
here
with
VX
LAN
yeah
fine,
we
go
with
the
next
protocol
approach.
But
if
you
fast
forward
to
genève
it's
getting
even
worse,
right,
Geneva
is
a
real
headache
for
me,
because
if
you
do
G
genève
well,
you
can't
really
do
next
protocol
because
that
thing
doesn't
exist
with
genève.
N
What
does
that
mean
you're
using
the
T
of
the
approach,
engine
Eve
and
then
you're
limited
because
of
the
five
bits
to
a
length
of
MUX
maximum
128?
That's
far
less
than
1
K
right
right,
it's
significantly!
Lessened
might
be
too
few
for
a
load
of
generic
use
cases,
so
it
is
a
concern.
Can
we
solve
it
yeah
we
can
solve
it
with
more
bits.
Our
people
ready
to
go
there
well,
I.
Think
that's
what
we're
trying
to
find
out
here.
J
N
C
So
the
recommendation
here
is
that
we
have
basically,
this
is
in
parallel
to
the
process
we
used
with.
The
six-man
are
about
the
v6
PDM.
Do
this
was
a
destination
option.
It
was
designed
for
use
for
passive,
hybrid
measurement
in
IP
PM.
The
proponents
took
that
to
six-man
the
ipv6
people
looked
at
it
and
said:
I,
don't
really
get
the
use
case.
So
no
they
came
over
here.
I
mean
the
original
idea
was
okay,
we're
gonna,
do
the
encapsulation
over
there
and
we're
gonna.
Do
what
how
you
can
measure
things
with
this
over
here?
P
B
C
So
yeah
I
suggested
that
they
come
over
here
to
talk
about
them
because
exactly
for
this
particular
problem
right,
the
different
cat
relations
have
different
limitations
on
the
applicability
of
the
data
and
like
so
it's
you
know.
It
is
interesting
to
know
that
this
proposal
for
genève,
for
example,
limits
what
you
can
do
with
IOM
right.
So
there's
there
there
are
restrictions
on
thee,
and
that
is
feed
into
the
sort
of
the
process
of
you
know
how
we
define
that
measure
methodologies
metrics
based
on
this,
so
yeah
the
I.
C
Clearly,
the
idea
here
is
not
an
end
run
right.
The
idea
is
that
things
come
in
here.
We
discussed
the
the
impacts,
but
the
owning
working
groups
obviously
have
to
ratify
any
any
change
if
they
own
that.
But
if
the
charters
of
those
working
groups
say
that
any
chain
any
additional
code
point
within
the
protocol
defined
by
this
working
group,
must
be
your
working
group
item.
Then
you
have
to
do
it
that
way,
because.
C
P
C
P
C
And
actually,
we
were
basically
told
by
we
were
told
by
the
six
man
people
yeah.
You
can
actually
do
it
over
there,
like
so
even
I,
don't
even
thing
it
was
a
six
man.
People
I
think
it
was
Brian
Haberman
as
as
in
Terry
he's
like
yeah.
Just
we
don't
care,
but
you
might
next
up
is
Greg
right
in
the
notes.
This
conversation
will
continue
in
nvo,
3,
yeah.
A
J
So,
as
I
mentioned,
we
split
their
document
that
was
adopted
by
the
working
group
and
into
two
documents
the
base
specification,
which
defines
the
base
format
of
a
stamp
test
packet
and
extensions.
The
extensions
that
we
are
proposed
to
use
govt
type
length
value
format,
and
some
of
this
extensions
already
been
the
part
of
stem
document.
It's
heading.
J
Location
times,
information
to
provide
to
communicate
or
characterize
their
synchronization
source
and
time,
stamping
method,
I
personally
believe
that
the
idea
of
error
estimate
was
to
provide
this
information
and
somehow
we
haven't
finished
the
job
of
quantifying.
What
is
what
so,
if
somebody
believes
that
it's
better
to
finish
the
work
with
an
error
estimate
to
characterize
the
sources,
timestamp
and
method
of
obtaining
the
time
value
like
whether
it's,
whether
how
close
its
hardware,
it's
a
software
or
not,
then
this
might
be
an
alternative
that
we're
planning
to
work
on
coercive
service
coercive
service.
J
It's
just
has
two
options:
weather
just
reflector
reports
of
DC,
p-value
and
ECM
value
as
packet
been
received
and
puts
it
as
a
sender,
DCP
and
a
CN
value,
or
there
is
an
extension
to
that.
That
sender
includes
the
value
of
the
ACP
to
be
used
on
the
reflected
packet,
so
that
allows
you
to
run
DCP
testing
because
you
can,
especially
in
multi
service
wireless.
J
Backhaul,
when
you
have
different
services,
2g,
3G
and
4G,
you
often
have
to
manipulate
with
the
acquiescence
of
service
marking,
and
sometimes
this
configuration
is
manual,
it's
very
easy
to
miss
configure
and
that
leads
and
very
difficult
scenarios
that
it's
hard
to
troubleshoot
and
identify
the
problem.
So
this
mode
been
seen
as
a
way
of
very
easy
test
of
the
network
to
verify
that
their
handling
of
these
CP
values
in
both
directions
is
as
expected,
hi.
C
J
H
Christine,
do
I
understand
that
you're
going
to
be,
or
at
least
allow
changing,
let's
say
dscp
on
a
packet
by
packet
basis,
in
other
words,
have
a
jump
around
like
that,
creating
a
crazy
way
once
again,
the
obvious
idea
of
having
a
session
as
in
t
ramp.
Then
you
in
it
per
session
basis.
You
could
do
that,
but
here
you're
you're
doing
something
which
is
just
no
packets.
Yes,.
H
Is
no
session,
this
is
in
the
packet,
so
you
could
do
this.
One
packet.
Has
this
dscp
annex
back,
there's
another
one
right?
Yes
and
okay,
you're,
allowing
that?
Maybe
your
wait.
We
should
put
in
wording
that
you
shouldn't
use
it,
but
if
you
do
use
it,
what
you
expect
to
happen,
do
you
expect
everything
along
the
way
to
be
stateless.
J
Well
again,
if,
if
there
is
some
cost
remapping
in
the
path,
then
we
want
to
expose
it.
That's
idea
of
it.
It's
a
test
how
this
path
handles
DCP
of
particular
value
weather,
because
again
it's
hard
to
say
whether
remapping
is
appropriate
or
erroneous.
H
J
H
J
H
J
J
We
can
do
it
on
there
in
the
sender,
and
the
reflector
will
just
follow
whatever
it's
taught.
You
know
we
don't
want
to
complicate
yang
model
on
a
reflector,
ok,
because
reflector,
it
should
not
be
aware
of
it.
Reflector
should
follow
instruction
given
by
the
sender
sender
anyway,
we'll
be
analyzing
processing
or
sending
this
data
for
the
post
processing
somewhere
and
the
same
for.
B
Is
a
footer
with
Nokia
I
think
the
the
general
general
comment
of
a
packet
by
packet
each
correct
me
if
I
read
this
wrong
in
the
draft,
but
each
packet
that
relates
to
this
session
from
the
sender
is
going
to
have
a
consistent,
diffserv
code
point
if
you're
using
this
on
the
reflector
for
congestion
notification,
some
along
the
passo,
it's
a
packet
by
packet.
But
if
the
session
sender
launches
each
packet
in
the
session
with
the
same
diffserv
code
point,
then
it
is
by
sent
by
session
right.
It's
just
an
action
on
the
reflector
right.
J
Direct
measurement,
so
we
actually
direct
measurement
is
the
idea
is
similar
to
well-known
Ethernet
loss
measurement,
where
you
have
a
definition
of
what
is
in
profile
frames
so
that
for
layer
three,
it
will
be
in
definition
of
in
profile
packets.
The
exact
definition
is
obviously
outside
of
this
specification,
but
there
are
service
that
we
provide.
We
just
collect
counters
from
the
sender
reflector
in
one
trip
of
packets,
similar
to
Ethernet
LM
LM
mo
elimar.
So.
J
J
J
K
This
is
just
a
recap
slide,
so
you
know
that,
as
my
unmentioned
before
the
FEC
8321
has
been
just
published,
and
there
are
also
some
use
cases-
some
application
within
ITF,
in
particular
directory
documents
that
define
how
to
use
two
too
long,
two
bits
long
field
to
perform.
The
marking
methodology
nets
in
bare
SFC
I'm,
your
dream,
and
also
in
MPLS
to
perform
the
an
improvement
of
the
RFC
63
74
with
the
use
of
the
synonymous
flow
level,
and
then
we
have
also
recently
and
alternate
marking
variation
in
quick,
like
you
know,
so
what
isn't?
K
What
our
next
steps?
There
are:
some
performance
measurement
where
a
lot
of
flows
and
nodes
can
be
involved.
So
this
is
a
big
data
problem.
For
example,
the
idea
is
to
generalize
this
kind
of
methodology,
so
RFC
8321
works
very
well
for
point-to-point
flow,
but
what
happened
if
I
have
a
point-to-multipoint
pot
or
I
have
a
multi-point
to
multi-point
part,
so
we
have
to
formalize
how
to
take
the
counter
and
how
to
make
the
performance
monitoring
more
flexible.
So
this
framework
is
about
multi-point
alternate
marking.
K
We
want
to
add
flexibility
to
performance
measurement,
so
we
can
reduce
the
order
of
magnitude
of
the
counters
if
needed,
and
this
can
allow
also
a
flexible
orchestration,
because
the
orchestration
the
orchestrator
can
calibrate
and
can
manage
the
performance
measurement
in
virtual
networks.
So
the
first
idea
is
to
introduce
the
clustered
pocket
rows.
So
if
we
were,
if
you
have,
if
we
have
a
nut
and
large
network,
we
can
identify
a
portion
of
the
network.
So
a
group.
B
K
To
group
segment
that
we
call
the
cluster,
and
so
the
definition
is
that
the
clusters
are
the
smallest
sub
networks.
Maintaining
the
packet
loss
properties,
packet,
rows,
property
means
that
the
number
of
incoming
packets
are
equal
to
the
number
of
about
going
packets.
So
there
is
a
very
simple
algorithm
that
I
show
you
in
the
next
slide
is
to
step
out.
Do
it,
but
in
general
the
cluster
can
be
also
combined,
and
so
we
can
perform
a
partition
of
the
networks
at
different
level.
Depending
on
the
detail,
we
want
to
achieve.
K
K
And
so
on,
in
second
step,
we
combine
the
link
group
ID
in
the
first
step,
with
at
least
one
ending
node
in
common.
So,
for
example,
we
can
build
in
this
way
for
clusters
partition
for
the
figure.
So
the
second
and
the
third
links
group
add
in
the
first
step
combined
it
because
have
the
you
know
the
increment.
So
this
is
just
an
example,
but
we
apply
this
algorithm
also
on
more
complex
networks.
K
B
K
Multi-Point
part,
so
we
know
that
in
our
FAC
8321
we
introduced
the
double
marking
methodology
to
perform
the
delay
measurement,
but
double
marking
meter
does
not
work
in
case
of
multi
pointin
parts.
So
what
is
the
solution?
The
solution
is
that
we
can
consider.
We
can
consider
a
single
packet
delay
measurement
by
using
an
acid-base
selection
of
the
packet,
so
that
is
detail
in
a
in
a
older
FSE
RFC
5475.
K
This
is
a
use
case,
for
is
a
multi-point
alternate
marking
scenario.
So,
as
I
mentioned
before,
we
add
flexibility
so
and
as
the
end
controller
can
perform
a
flow
filtering
or
a
cluster
zooming,
depending
on
the
use
case,
depending
on
the
level
of
detail,
we
will
level
of
detail
we
want
to
achieve
so
we
can
start
with
without.
K
K
C
K
D
C
K
Okay,
these
are
the
draft,
is
also
on
same
technology
alternate
marking
methodology,
but
at
the
point
of
view,
is
different.
So
now
the
scope
of
the
of
the
current
draft
is
to
make
an
analysis
of
officiate
321
methods
to
introduce
new
methods
that
with
low
overhead,
so
single
bit
also
what
we
can
use
if
we
have
zero
bits
for
marking
and
so
in
the
end
of
the
scope
of
this
document
is
to
understand
what
is
the
most
useful
method
we
can.
K
We
can
use
if
we
have
zero
bit
one
bit
or
two
bits
available,
so
the
black
background,
the
F
SAT
321,
okay,
the
packet
loss
measurement
is
well
known,
but
we
can
discuss
about
how
to
perform
the
delay
in
their
facility
321.
That
is
the
single
marking
method,
where
first
and
last
packet
have
been
used
as
a
time
reference
for
the
delay,
calculation,
the
min
delay
and
double
mark.
K
This
draft
introduce
an
additional
variation
that
is
the
multiplex
ad
marking.
So
we
can
have
the
same
resolution
of
double
marking
map,
but
we
can
use
the
opposite
bit
of
the
current
from
the
current
batch
in
order
to
perform
it.
Just
one
bit
or
so
the
delay
measurement
so
the
time
stamp.
It
is
opposite
to
the
bit
of
the
current
batch.
So
in
this
way
we
can
use
just
one
bit
to
perform
a
double
marking.
Math
the
double
marking
meet.
Oh.
K
Another
alternative
that
is
introduced
in
in
this
draft
is
about
the
use
of
the
acid-base
election,
in
particular.
If
we
don't
have
be
some
bit
to
perform
ultimate
marking
method,
how
we
can
perform
performance
measurement,
so
so
we
call
zero
mark
English.
We
use
the
ashen
base
selection
to
select
packet
bot
for
loss
and
for
delay
measurement.
K
K
This
is
a
table
that
is
in
the
draft
and
show
you
with
the
focus
on
delay
measurement.
What
are
the
difference
with
the
difference
technology
in
particular
the
last
two,
the
last
two
roll
show
rows,
show
you
that
the
single
marking
edge
could
be
the
most
complete
method,
because
there
is
the
there
is
the
t's
resilient
to
reordering
to
packet
drops
and
it
is
also
multi-point
compatible.
That
is
also
a
good
point,
so
it
is
very
similar
to
double
marking,
but
it
is,
it
can
be
considered
better
if
you
want
to
perform
multi
point
measurement.
K
N
C
Know
we
have
one
more
on
young
models
for
IOM
and
then
actually
because
we
have.
We
still
have
time
to
step
a
if,
if
you
and
agnostic
I
want
to
get
up
and
go
back
to
the
conversation
that
you
were
going
to
have
on
the
previous
draft,
because
we
have
a
little
bit
time
and
trying
to
hold
the
lightning
talks
to
five
minutes.
Oh.
J
J
So
what's
the
problem
we
see
are
the
quality
of
measurements
in
the
world's
degree
depends
on
consistency
of
taking
the
measurement
and,
in
our
t
month,
extension,
that's
one
of
things
that
were
employing
that
the
method
of
taking
the
timestamp
so
we're
the
time
step
is
taking.
That's
a
directly
affects
the
consistency,
because
if
the
timestamp
is
not
taking
when
they're
transmission
or
reception
of
the
packet
physically
begins,
then
the
packet
may
experience
unbound
delay
and
that
will
affect
the
quality
of
the
measurement
so
closer
to
the
hardware.
J
So
and
another
is
that
the
measurement
information
the
telemetry
should
be
secured
and
based
on
that,
if
we
transporting
the
telemetry
in
clear-text,
then
we're
opening
it
possibility
to
the
man
in
the
middle
attack
skewing
it
and
that's
affecting
the
scenario
that
we
discussed
earlier
with
Yaakov
discussing
their
security
levels
of
the
stamp
okay.
Because
now
we
pay
attention
to
SLA
and
it
affects
how
the
system
being
mapped.
And
if
somebody
can
misrepresent
the
real
picture
of
their
class
of
service
a
class
of
experience
present,
then
it
will
be
unnecessary.
J
L
J
L
D
J
Yes,
so
solution:
if
we
take
a
look
at
RFC,
81,
69
residence
time
measurement
in
MPLS
networks,
it
has
defined
two
modes
of
operation
for
our
TM,
capable
OS
are
one
step,
a
2
step.
So
the
1
step
is,
as
it's
suggested
by
its
name,
puts
the
timestamp
in
the
packet
that
carries
p,
TP
control
message
and
the
2
step
produces
the
message
which
has
characteristic
information
that
identifies
or
refers
it
to
the
message
with
a
bt,
p,
control
message
and
then
transports
only
and
collects
residence
time.
J
What
we
want
to
take
from
this
RFC
is
idea
of
the
two
step
method,
so
that
the
measurement
can
be
not
not
necessarily
to
be
transported
on
a
packet
itself,
because
then
it
allows
us
to
read
values
and
then
transport
them
in
a
separate,
secure
packet
with
a
characteristic
information
which
will
associate
to
their
packet
that
triggered
this
collection.
So
that's
ensured
the
idea
of
the
two
step
method.
H
J
C
F
F
Each
of
them
well
relates
to
one
IOM
encapsulation
type
and
according
to
the
ion,
the
data
specification,
the
multiple
I
want,
data
types
can
be
encapsulated
into
the
same
IOM
header
and
the
the
sub
profiles
includes
the
pre-allocated
a
tracing
profile
as
described
here,
and
also
the
incremental
tracing
profile,
and
also
the
proof
of
transit
profile.
Right
now
that
this
this
profile
is
imported
from
the
proof
of
transit
document.
Later
I
would
suggest
to
integrate
it
into
this
young
model
directly
and
also
the
edge
to
edge
profile.
J
J
F
C
C
L
My
question
is:
how
do
you
plan
to
collect
information
and
okay-
you
put
some
nice
idea
to
separate
in
in
the
different
cluster
and
so
on,
but
how
do
you
collect
the
information
and-
and
why
is
so
important
to
determine
if
the
in
the
previous
slide,
the
the
basic
harsh,
dynamic
harsh
way
is
so
important?
I
I
didn't
catch
from
your
presentation.
Okay,.
K
I
mean
the
Asha
Base
erection
of
the
the
pocket.
Okay
for
the
collection.
Okay,
you
have
the
reference
of
the
marking
batch.
So
as
in
double
marking
approach,
you
know
the
number
of
packets
that
can
be
selected
within
a
marking
gauge.
So
it's
the
same.
If
you
want
to
the
problem,
is
that
in
bicycle
shops.
L
K
K
J
The
ultimate
marking
method
does
not
specify
how
the
measurement
results
being
exported.
It
only
specifies
the
triggers
that
being
measured,
export
of
data
can
be
done
in
IP,
fix
and
GRP
see
in
any
transport
and
the
direction
configuration
of
data
collector
is
orthogonal
to
alternate
marking
method.
K
K
K
So,
but
in
this
way
there
is
a
dynamic
ad
shop
in
the
dynamic
ash
approach
where
you
can,
there
is
an
iterative
algorithm
that
is
detailed
with
in
the
draft
where
you
can
start
to
make
a
selection
based
on
ash,
but
you
can
discard
the
samples
in
order
to
occur
almost
an
almost
constant
number
of
pockets
within
a
marking
batch,
but
this
this
can
be
detailed.
This
is
this
is
detailed
within
the
draft
that,
if
I
can
describe
you
more
in
the
next
presentation,
if
I
can.