►
From YouTube: IETF103-IPPM-20181106-0900
Description
IPPM meeting session at IETF103
2018/11/06 0900
https://datatracker.ietf.org/meeting/103/proceedings/
A
All
right,
I
think
it
is
our
time
to
begin
good
morning.
Everyone
welcome
to
AI
ppm
in
ITF
103
here
in
Bangkok.
If
you
are
looking
for
a
ppm
you're
in
the
right
place,
if
you're
not,
you
can
stay
here
and
join
us
anyway,
so
I
am
Tommy.
Poly
I
am
one
of
your
new
co-chairs.
I
am
here
on
behalf
of
Bill
and
Brian
as
well,
or
both
able
to
be
here
and
I'm
sure
we
all
wish
Brian
the
best
with
his
family.
A
A
So
we
have
a
fairly
full
agenda.
We
have
a
lot
of
working
group
document
updates,
as
well
as
a
bunch
of
lightning
talks.
Thank
you.
Everyone
for
that
I
just
want
to
give
a
quick
update
on
some
of
our
working
group
document
statuses
right
now,
so
we
have
the
two
three
three
zero
ipv6
document
which
had
been
in
off
48.
We
actually
have
moved
to
all
48
done,
it's
fully
approved,
and
so
that
will
be
RFC
84-68
quite
shortly.
A
We
also
still
have
the
tea
lamp
being
document
waiting
in
mr.
F
for
the
other
documents
to
come
through.
So
that's
fine.
We
have
the
tea
lamp
test
document
got
some
ad
comments
from
area
I,
think
that
has
been
updated
now
and
I
I
think
we're
just
going
to
wait
for
another
approval
from
that,
and
that
should
be
good
and
since
last
time
now
that
we
have
more
documents
coming
out
of
the
queue
we
have
adopted
a
new
document,
so
we've
adopted
the
multi-point
Altmark
document.
So
thank
you,
everyone
for
chiming
in
on
that.
A
That
was
a
good
amount
of
feedback
right.
So
here
is
our
agenda.
Please
bash
it!
If
you
need
to
so
we're
gonna,
be
we
have
the
Welcome
right
now.
I'm
gonna
briefly
mention
something
about
github
and
how
we
can
have
people
contribute
in
a
more
open
area.
That
would
be
great
to
do
a
Liz
going
to
give
us
some
liaison
updates,
and
then
we
are
going
to
go
through
our
documents
in
the
working
group.
So
we
have
those
here.
A
These
are
all
the
active
ones
that
we
have
along
with
the
newly
adopted
document,
and
then
we
have
a
bunch
of
requests
for
lightning
talks,
because
we
have
limited
time.
I
really
do
request
that
these
be
limited
to
just
around
five
minutes
per
person.
Some
of
these
have
more
slides,
probably
then
we'll
fit
in
five
minutes.
A
I
know
that
some
of
the
documents
that
people
are
working
on
or
are
already
in
various
kind
of
separate
github
repos-
we
do
have
a
IPM
official
repo,
but
it's
as
you
can
see
from
the
image
here
fairly
sparse
right
now
and
there's
really
nothing
in
it.
But
I
do
want
to
highlight
that
there
is
this
home
for
documents
here.
A
So
I
think
some
of
the
IOM
documents
are
are
are
already
on
github
and
so
I
think
you'd
be
great
if
some
of
these
could
kind
of
come
into
the
shared
working
group
area
so
that
as
people
are
coming
and
going
and
working
on
different
stuff,
we
have
a
place.
So
you
can
see
these
documents
and
a
place
for
other
people
in
the
working
group
to
contribute
and
give
comments.
B
A
I
think
there
are
ways
so
there's
actually
various
strategies
and
stuff
documented
here
just
go
go.
You
can
look
at
these
slides
and
follow
these
links
and
we
can
follow
up
offline.
Okay,
I
think
there
are
very
strategies
for
how
to
set
up
your
repo
and
also
how
to
migrate
what
you
have
and
essentially
have
it
show
up
under
the
umbrella
of
the
entire
group.
A
So
essentially
anyone
who
is
a
document
author,
or
especially,
if
you're
starting
new
work
and
you'd
like
it
to
be
considered
by
the
working
group
I
invite
you
to
please
come
work
on
that,
alright,
so
moving
on.
If
there's
no
any
agenda
bashing,
we
can
jump
right
in
I.
Think
the
first
thing
we
have
is
our
liaison
statements
from.
C
Okay,
so
it's
liaison
time.
This
is
the
kind
of
thing
we
do
when
we
behave
as
a
real
standards
body.
We
we
get
that
didn't
work.
Oh,
it
goes
like
this.
There
we
go.
We
occasionally
get
communications
from
other
standards
bodies
and
we
read
them
and
we
take
action,
whatever's
needed
and
we
respond
back
so
very
quickly.
C
There's
a
liaison
that
ended
up
in
the
liaison
data
tracker,
there's
a
link
for
it
there
and
there's
a
huge
number
of
standards
bodies
included
in
this
liaison,
including
us
in
IPM,
but
also
a
couple
of
different
Etsy
standards
groups,
a
couple
of
different
itu-t
study
groups,
a
couple
of
let's
say:
I
eat,
EF
BBF,
maybe
even
some
others,
some
other
organizations,
so
that
the
whole
idea
of
this
is
to
try
to
harmonize
this
idea
of
measuring
internet
performance,
particularly
speed
and
latency.
Across
many
different
standards
bodies.
C
I
talked
to
a
couple
of
people
about
this.
This
morning
at
least
Leslie
Daigle
and
Dave
ran
and
Dave
ran
said.
We
we've
struggled
with
this
long
enough
that
maybe
now
people
are
willing
to
come
together
about
it,
and
we
also
have
an
idea
that
if
we
evaluate
different
methods
of
measurement
against
a
ground
truth,
a
calibrated
path
that
we
can
really
know
something
about
how
these
measurements
work.
So
let's
hope
that
these
concepts
are
valuable
and
that
we
can
make
some
progress
in
this
topic.
C
So
you
can
see
that
from
itu-t,
where
this
liaison
comes
from
I
al
Morton
and
my
friend
Ruettiger
gibe
are
the
co-editors
of
a
section
of
the
IP
performance,
metrics
recommendation
there,
which
we're
planning
to
update
with
an
evaluation
plan
and
improving
the
metrics
that
are
there
as
well.
So
here's
the
evaluation
plan,
the
pretty
picture
of
what
we're
going
to
do.
This
is
phase
one
where
we're
recognizing
that
access
speeds
are
moving
into
the
gigabit
range
and
also
having
very
low
latency.
C
We
are
seeing
companies
like
Comcast
in
the
United
States,
announcing
that
they've
got
60
million
homes
where
they're
offering
gigabit
internet
access.
Twenty-Five
years
ago.
All
the
cable
companies
in
the
United
States
were
offering
television
service
to
60
million
homes.
Now
that's
the
contrast
and
that
doesn't
even
include
80s
I,
don't
know
15
cities
with
gigapower
and
and
other
offers
as
well.
So
this
is
coming
and
it's
coming
fast
now
what
happens
when
that
happens?
C
When
we
get
to
gigabit
today's
access
test
methods,
whether
using
end
times
TCP
to
connections,
they
are
not
going
to
be
able
to
keep
up
with
this.
That's
a
pretty
safe
bet,
but
let's
find
out,
let's
evaluate
it
and
and
and
there's
also
a
crossover
in
the
benchmarking
world.
Benchmarking
methodology
working
group-
that's
the
group
I
chair-
we've
been
doing
this
for
years
with
UDP
streams,
measuring
gigabits
and
gigabits
and
doing
it
accurately,
and
so
we're
we're
not
afraid
of
trying
this
in
the
production
network.
C
With
a
couple
of
caveats,
we
know
that
we
have
to
put
limits
on
the
amount
of
traffic
we
send
and
therefore
the
amount
of
congestion
we
caused.
It's
got
to
be
a
short
test
and
all
those
sorts
of
things,
but
we've
got
new,
robust
search,
algorithms.
That
will
let
us
encounter
the
problems
that
we
get
in
a
production
world
and
and
live
through
that
searching
for
the
the
maximum
level
maximum
Warford
load.
So
we've
done
some
testing.
C
We've
replaced
the
the
access
pipe,
the
big
blue
access
pipe
there
with
a
host
a
couple
of
physical
ports
on
it.
We've
got
a
traffic
shaper
on
both
sides
on
egress
and
running
the
traffic
through
a
V
switch,
we've
got
a
test
device,
they're,
basically
running
the
the
test
streams
and
lo
and
behold
we
got
very
good
results
with
UDP
testing
and
our
new
search
algorithms.
We
need
to
get
iperf
working
in
the
same
environment,
so
we
can
test
the
time
simultaneous
TCP
streams.
But
this
is
the
quick
calibration
here.
C
We've
got
the
device
under
test
with
our
ground
truth
at
a
hundred
or
two
hundred
milliseconds
and
those
are
the
values
we
measured
100.5
201
in
a
laboratory.
We
should
be
able
to
do
this,
but
I'll
bet,
there's
gonna,
be
methods
of
measurement
that
don't
so
now
is
our
time
to
behave
like
a
standards
body.
We
should
have
a
liaison
reply.
C
Would
people
like
to
join
this
effort
I'd
like
people
to
think
about
that,
because
this
is
something
we've
been
working
on,
supposedly
an
IP
PM
ever
since
Matt
started,
Matt
Mathis
did
the
buff
about
25
years
ago,
so
but
I'd
like
to
see
people
do
is
contribute
methods
perform
calibrations
in
other
labs,
make
access
technologies
available
in
the
laboratories.
That's
the
phase
2
of
this
program,
and
so
let
me
know,
will
propose
a
reply,
we'll
put
it
on
the
list
and
we'll
do
something
together.
That's
that's
the
plan.
Any
comments
on
this
so.
D
E
E
F
E
E
Great
points-
yes,
but
perhaps
you
okay,
I,
am
bringing
this
up,
because
I
am
working
on
on
this
kind
of
of
the
problem,
and
my
approach
is
just
to
test
in.
In
another
way,
I
mean
perhaps
measuring
some
information
about
the
traffic
measuring
the
variation
of
delays.
You
can
make
some
inferences
about
the
traffic
how
the
traffic
is
behaves
in
into
the
network.
Yes,
for
sure,
it
needs
more
more
explanation
than
that,
but
I
think
they
perhaps
ideas
to
find
another
kind
of
approach
to
this
very.
C
Good
thanks,
Ignacio
and
I
and
Ignacio
got
in
touch
with
me
by
email,
he's
sort
of
interested
in
joining
up
with
this
as
well.
So
look
the
those
of
us
who
are
doing
this.
We
we
welcome
you
to
think
about
it
and
join
us.
If
this
is
a
sort
of
a
hot
topic
for
you,
it's
it's,
it
will
certainly
have
tremendous
visibility
if
we
can
manage
to
harm
this
across
the
industry.
I
think
it's
time
thanks.
G
C
C
That
back
easily
alright,
so
so
now
we're
transitioning
to
the
topic
of
the
registry
and
the
initial
contents
for
the
registry.
This
draft
is
providing
the
initial
contents
a
set
of
performance
metrics
that
will
go
into
the
registry,
we're
defining
for
performance
metrics.
So
you
can
see
that
where
we've
done
plenty
of
iterations
here,
number
eight
for
the
registry
contents
and
number
sixteen
for
the
design
of
the
registry.
So
that
means
that
we're
going
to
go
through
the
next
four
slides,
really
fast,
watch
active,
passive
and
hybrid.
C
Those
are
the
kinds
of
metrics
we
handle
was
with
up
with
precision
I'm
getting
too
quick
here:
registry
concept
versions,
15
and
16.
No
substantial
revisions,
I
did
a
little
editing,
I,
just
read
part
of
it
and
fixed
some
stuff
up:
here's
the
registry
design.
We
got
different
categories
of
summaries,
metric
definition
and
so
forth.
This
has
all
been
really
solid.
C
So
here's
what
really
happened
in
the
red
metric
contents
from
the
we're
closing
the
opens,
so
the
DNS
response,
time
and
loss
section.
It
now
requires
the
support
of
the
ID
generation.
So
we
can
get
query
and
response
correlation,
UDP,
one-way,
delay
and
loss.
We
did
that's
in
section
8.
Now
it's
a
periodic
run
time
run
time.
Parameters
are
fixed
so
that
it's
a
was
always
a
periodic
test.
It's
going
to
look
like
a
void
stream.
We
got
20
milliseconds,
spacing
a
little
bit
rate
packet,
size
and
so
forth.
Next
steps,
the
lingering
issues.
C
We
did
not
see
the
reviews
of
the
TCP
section
that
were
requested
or
hoped
for
or
would
be
better
if
we
had-
and
others
have
reviewed
this
section
so
I'm
saying:
let's
not
wait.
Let's
go
request.
Working
group
last
call
with
a
deadline.
Please,
let's
shake
any
final
comments
loose
with
that
deadline
and
the
con.
The
observation
that
longevity
is
unattractive
for
internet
drafts,
reminding
you
that
we're
at
version
16
in
version
8.
So
that's
it
we're
at
a
point
of
interaction
here.
Mr.
chairman
mm-hmm.
A
All
right
so
yeah,
thank
you.
Al
I
agree
with
the
idea
that
yep
these
are
long
lived
drafts.
They
seem
to
be
in
pretty
good
shape.
The
recent
updates
have
been
minor.
I.
Think
it
makes
sense
to
have
these
go
into
a
working
group.
Last
call
how
many
people
have
read
the
documents
just
to
recalibrate
that
so
first
ever
is.
Are
you
familiar
with
the
documents
in
general?
A
L
A
So
I
think
actually
doing.
The
last
call
would
be
really
good
and
a
good
opportunity
to
ask
the
whole
working
group
to
seriously
do
review
the
documents
in
their
entirety
and
kind
of
see
that
full
flow.
Does
anyone
have
any
objections
to
doing
that?
Are
we
good
to
go
great,
so
yeah
I
will
start
a
last
call
on
that,
hopefully
this
week
and
give
a
deadline
to
that.
If
people
could
please
take
the
time
to
review
these
on
your
flight
back
home,
maybe
I'd
be
great.
Thank.
C
You
very
much
working
group
and
mr.
chairman
I
will
make
a
note
that
there
is
a
section
in
the
registry
contents
draft
on
our
TCP
metrics,
which
we
will
remove.
So
don't
bother
reviewing
that.
That
was
there
as
a
proof
of
concept
that
this
worked
across
all
these
different
metrics
and
it
was
not
intended
to
to
keep
it.
So
that's
going
to
disappear.
Don't
bother
with
your
comments
on
that.
Thank
you,
okay!
That's
it.
A
C
C
So
the
quick
background
on
this
is
that
we
first
presented
it
at
IETF
99.
We
got
it
adopted
shortly
after
100,
we've
generalized
all
the
definitions,
so
that
it's
more
widely
applicable
and
the
version
we
put
in
at
101
and
we
got
some
good
feedback
just
before
and
after
a
working
group
session
and
that
108
f-102,
so
we
added
rüdiger
as
an
author
he's
produced
an
MPLS
appendix
carlos
added,
a
reference
for
that
and
that's
in
there
now
to
Yakov
Stein.
C
Who
didn't
put
this
comment
on
the
list
said
you
guys
are
describing
your
route
ensemble
and
your
metric,
your
member
routes
as
an
ordered
graph
and
that's
the
wrong
term.
He
said
so
we
looked
into
it.
We
turned
out.
Yakov
was
right,
so
we
fixed
this
and
it
only
appeared
in
the
in
the
draft
in
one
place.
C
So
we've
got
a
section
on
that:
we're
still
developing
a
section
on
the
this
concept
of
routing
Class
C,
where
we
somehow
discover
if,
if
I,
if
I
have
multiple
paths
through
the
network,
what
are
the
characteristics
that
describe
whether
packets
go
through
those
paths
or
not?
And
if
we
understand
that
that's
a
piece
of
information
that
we
can
use
in
further
testing,
specifically,
we
can
use
it
with
testing
routes
at
a
midpoint.
C
C
So
then
we'll
have
synthesized
route
measurement
packets
and
we
will
basically
be
trying
to
match
the
hash
value
and
keep
our
checksum
concept
constant,
it's
another
so
that
the
multiple
packets
follow
the
same
route,
just
like
we're
doing,
with
parish,
trace,
routed
or
MDA
or
whatever
the
various
things
are
today,
and
when
you
try
to
do
both
these
things
at
once,
I
think
it
gets
interesting.
So
I
had
hoped
to
spend
more
time
on
this
in
the
interim
period.
But
I
see
Gregg
has
a
comment
here.
So
please
Greg.
M
C
I
M
C
C
K
I
C
D
N
C
Guess
I
did
see,
I
did
see,
you
are
you
last
night
and
I
I
did
not
mention
it,
but
I
will
try
to
talk
to
him
about
it
during
this
week.
So
we
have
these
other
things
we
had
to
fix
there
on
our
list.
Next
steps,
authors,
we
got
to
complete
our
to-do
items.
The
working
group
and
the
authors
continue
developing
these
sections
input
from
others.
So
a
wide
appeal.
C
Please
read
this:
it's
it's
I
think
it's
useful
information,
it's
a
good
background
to
what's
being
done
in
the
network
today
and
and
also
the
measurements
that
we
need
to
understand.
What
we're
measuring
I
mean
right
at
the
beginning
of
the
RFC
23
30
I
ppm
framework.
It
says
you
know
paraphrasing
understand
the
path
that
you're
measuring.
C
Do
we
do
that?
Every
time
in
my
old
measurement
system,
on
the
backbone
we
did
but
I,
you
know,
I
think
a
lot
of
the
things
I
talked
about
on
the
on
the
liaison
topic.
Do
not
so
they
may
know
the
two
end
points
that's
about
it.
So
I
mean
there's
more
to
do
here
and
and
stuff
that
can
be
routinely
done.
That's
actually
quite
informative,
not
just
measuring
speed
and
latency
during
speed
tests
ICMP
off
to
the
side
meaningless.
C
So
you
know
and
know
your
path
know
where
your
packets
went.
This
is
fundamental
stuff,
that's
what
it's!
What
our
forefathers
and
I
ppm
told
us
we
should
be
doing
20
years
ago.
Let's
not
forget
it!
So
that's
it!
No
actions
here,
except
to
line
up
some
authors,
Tommy
anybody
care
or
not,
authors,
reviewers,.
A
C
A
C
B
Yeah
I
think
it's
not
only
me.
It's
Brian
he's
I
think
somewhere
in
the
back.
Maybe
you
could
come
up
front
and
we
have
Mickey
on
line.
He
was
gonna,
go
and
take
the
third
portion,
so
I'm
gonna
go
and
talk
about
the
update,
so
everything
that
is
marked
with
a
little
blue
star
is
covered
in
this
particular
presentation.
B
That
would
carry
things
and
there
is
also
a
bunch
of
adain
I
related
work,
popping
up
so
I'm
very
happy
to
see
that
my
stuff
is
really
about
the
core
document,
which
is
the
data
raft,
defining
the
data
fields,
and
we
are
at
revision
for
right
now
and
revision
for
is
pretty
much
a
reflection
of
the
discussion
that
we
had
in
the
last
meeting
in
Montreux
in
Montreal.
We
already
started
to
discuss
adding
a
namespace
identifier
and
that
I
namespace
identifier
is
now
in
the
document,
and
it
is
there
to
distinguish
between
operational
domains.
B
Let's
remember
we
defined
all
the
iom,
namespace
only
the
IOM
fields,
data
fields
with
the
notion
saying.
Well,
it's
within
a
particular
domain.
It
is
within
a
particular
namespace,
but
we
forgot
to
add
the
definition
if
the
namespace
and
the
document,
so
that
is
kind
of
a
fix
into
what
we
we've
been
referring
to
for
quite
some
time,
but
never
ever
really
defined.
So
it's
there
to
distinguish
operational
domains.
It
helps
you
provide
context
for
fields
that
are
there
like
node
ID,
but
nobody
tells
you
how
to
interpret
the
node
ID
well
with
namespace
ID.
B
You
can
go
do
that
and
you
can
even
differentiate
different
sets
of
devices
that
way
if
you
really
want
to
so.
If
you
have
one
namespace
for
devices
that
support
a
certain
set
of
options
and
another
namespace
for
another
set
of
options,
you
can
easily
distinguish
that
using
namespaces.
So
it's
a
useful
thing
and
which
is
why
it's
in
there
right
now.
The
definition
is
for
16-bits
namespace
identifier
and
there's
been
discussions
on
well,
should
that
all
be
operator
defined
or
not
well,
right
now
the
feeling
is,
maybe
not
so.
B
We
want
to
go
and
allow
for
operator
defined,
as
well
as
I
Anna
defined,
trying
to
figure
out
what
I
entity
find
might
really
mean
that
discussion
is
ongoing
and
also
how
to
go
and
carve
up
the
bits
right
now
we
had
this
thing
like
it's,
either
or
I.
Think
that's
reflected
in
the
in
the
document
right
now.
That
might
not
be
smart
enough.
We
might
even
want
to
have
a
combination
where
you're
saying
well.
B
There
is
an
int
value
and
the
INA
value
says
it's
only
belonging
to
well,
it's
applicable
worldwide,
or
it's
only
applicable
to
a
certain
region,
or
it's
only
applicable
to
a
certain
whatever
domain
like
anything
Europe,
because
in
Europe
things
are
different
than
anywhere
else
on
the
planet
or
whatever
right,
I
think
we're
just
thinking
of
that,
and
you
want
to
go
and
combine
it
with
an
operational
domain
with
an
operator
to
find
definition
and
well.
The
current
way
is
not
really
cutting
that.
So
that's
an
ongoing
discussion.
B
What
is
pretty
sure
is
we
want
to
have
a
default
and
the
default
is
all
zeros
so
well.
We
probably
need
to
go
and
turn
that
and
update
that
as
we
learn
more
on
how
people
really
want
to
go
and
use
the
namespace
Rd
and
assign
the
er
namespace
ID
above
and
beyond
what
we
have
it's
there
in
all
the
different
option:
headers.
So
it's
there
on
the
trace
option,
header
it's
there
and
the
approve
of
transit
option
header
and
it's
there
and
the
e2e
option.
B
Header
so
no
surprises
there,
given
that
well,
its
namespace
everything
it's
a
VM
space.
The
other
thing
that
happened
with
we
introduced
the
namespace,
and
that
meant
we
needed
to
go
and
move
the
fields
around
as
we
moved
the
fields
around
well,
we
wanted
to
go
and
give
credit
to
some
of
the
records
that
we're
seen
earlier
on
for
well.
B
B
B
We
had
this
thing
that
was
called
app
data
for
the
time
being
and
well.
It's
really
namespace
specific
data
and
we're
calling
the
thing
now.
So
it's
editorial,
but
I
want
to
go
and
call
that
out.
So
if
people
want
to
go
and
play
with
things
that
are
just
for
them,
that's
the
field
right.
If
you
have
something
that
you
want
to
go
and
carry
and
trace
data
that
you
don't
want
to
go
and
see
standardized,
but
you
still
want
to
go
and
have
that
in
your
domain.
B
That's
the
way
to
go
well
put
free
format,
data
if
you
have
more
free
format,
data
there
is
this
notion
of
state
opaque
states,
net
snapshot,
which
is
a
soft
teal
v
within
that
TLB
harder
to
do,
go
and
built-in
in
hardware,
which
is
I.
Think
while
we
have
the
two
options,
there
is
one
additional
thing
at
it
as
another
trace
option
we're
just
buffer
occupancy.
So
we
already
started
to
eat
more
bits,
ongoing
discussion
on
well
how
much
additional
stuff
we
wouldn't
really
want,
as
a
baseline
in
the
document.
B
O
Following
comments,
the
first
one
you,
the
we
have
the
hacksaw
you
know
tell
me:
I-
should
mention
yeah
I.
In
the
you
know,
we
found
a
VP
Pete
who
increment
the
I
am
so
we
found
some
of
these.
So
the
issues,
some
of
the
apparent
her
errors
in
the
current
her
craft
here,
yeah
yeah
I,
said
the
comments
to
the
minimis.
B
Thank
you
so
much
harder
than
that.
So
what
you
did
is
great
and
you
called
a
load
of
editorial
knits
and
loads
of
these
editorial
in
its
sometime
somehow
happened
when
we
did
the
oh
three
to
all
four
because
well,
we
grew
the
field
from
16
to
24
and
then
well,
not
all
the
calculations
kind
of
caught
up
with
that
great
stuff
and
we'll
make
tickets
for
all
of
that
on
github.
B
There
is
a
bunch
of
other
editorial
tickets
that
are
lining
up
right
now,
yeah,
it's
well,
okay,
good
that
you've
done
that
and
I
think
that's
showing
another
benefit
off
the
hackathon
right
as
people
trying
to
go
and
reason
about
the
latest
version
and
I.
Think
one
of
the
objectives
of
the
hackathon
was
to
implement
the
all
four
versions.
You
suddenly
start
to
stumble
across
all
these
little
things
that
well,
we
weren't
too
careful
about,
and
so
thanks
for
for
keeping
a
straight
here.
Okay.
O
Thank
you,
okay.
Second,
why
you?
The
I
am
with
the
encapsulation,
in
fact,
I
think
the
SR
and
I'm
sure
I
important
here
scenario.
So
the
for
the
NPR's
I
mentioned
that
the
you
know
I'm
sure
so,
working
group
we
proposed
the
draft
called
I'm
Chelsea
header.
That
means
the
extremes:
either
is
a
try
to
encapsulate
a
between
the
I'm,
how
the
label
stack
and
the
payload
we
hope
I'm
Jocelyn
header
can
incorporate
the
I
AMA
date
her
and
the
SFC
date.
Her
so
I
think
that's
a
you.
O
O
Another
one
you
will
also
read
the
draft
you
to
mention
the
SR
and
the
SR
and
the
oh
I
am
so
I
think
that
in
either
some
alignment
between
the
SRO
am
and
I'm
header,
because
some
the
I
am
an
information
over
to
be
encapsulated
in
the
SR
action.
So
but
I
think
the
SRM
cars
and
ice
are
mistakes
may
have
the
different
process
different
process.
Okay,.
B
O
K
B
Just
chime
in
one
second,
so
I
think
this
is
an
updated
version
of
the
GRE
draft
that
you
shepherded
prior
right
and
I,
think
it
was
a
Lea
to
inspire
in
the
last
working
group
meeting.
Well,
if
you
do
something,
either
type
do
a
generic
for
all
either
types
instead
of
just
doing
for
GRE
and
I.
Think
that's
a
reflection
of
what
what
Brian's
going
to
go
present
here.
M
M
P
P
D
Q
So
it's
pretty
similar
to
the
0
0
version
that
we
had
before
the
updates.
One
is
on:
IO
am
encapsulation
type,
so,
as
you
saw
the
end
caps
are,
there
are
new
end
caps
being
being
proposed,
so
I
added
a
point
for
ipv6,
hoping
that
something
will
move
forward
in
with
the
ipv6
end.
Cap
and
Ginny
now
has
two
options:
one
is
with
engine
Eve
using
an
option
class
and
the
other
is
what
we
just
heard
using
the
ether
type
and
a
next
protocol
type
of
approach,
so
just
to
code
points
in
for
that.
Q
The
main
thing
is
to
add
two
new
information
elements
in
order
to
optimize
the
use
of
IP
packet,
section
and
Ethernet
frame
section.
So
these
were
issues
that
I
noted
last
time
and
last
time
there
were
some
comments
that,
like
it's,
not
really
possible
to
change
the
definitions
of
the
existing
information
elements.
Q
Q
Q
So
the
definition
of
the
IP
header
packet
section
so
the
first
three
paragraphs
are
basically
the
same
as
what
can
I
be
at
her
package,
section,
the
original
and
then
with
padding
just
reorganize
the
wording.
So,
instead
of
talking
about
whether
you
have
section
export
of
octets
or
not,
it's
just
organized
the
other
way
around
to
fix
length
or
variable
length.
So
if
it's
fixed
length,
you
can
have
an
arbitrary
number
of
padding
off
tats.
Q
Next
slide
so
Ethernet,
so
one
thing:
if
you
want
to
do
a
layer,
2
packet
section
or
in
Ethernet
packet
section,
so
one
issue
is
the
padding
which
is
the
same
as
what's
being
proposed
for
the
IP
header
packet
section.
The
other
issue
is
that,
right
now
the
section
is
a
data
link,
same
section
which
could
be
Ethernet,
could
be
802,
11
or
so
on.
I
wanted
to
propose
something
specifically
for
Ethernet
here,
so
that
you
don't
have
to
include
the
data
link
frame,
type
and
data
log
frame
size.
Q
Q
B
Q
B
From
a
nap
steps,
perspective
I
think
on
the
the
data
draft,
we
definitely
have
to
go
and
do
an
o-5
version
with
all
the
editorial
knits,
but
also
closing
on
some
of
the
discussion
items.
The
document
is
getting
pretty
mature,
so
hopefully
we
can
do
either
the
O
5
or
all
six
for
working
group.
Last
poll,
that's
what
I'm
really
hoping
for.
So
we
can
close
on
that
because
we've
already
seen
some
people
or
not
say
bitching,
but
close
to
that
or
unhappiness
about
yeah
well.
You're
still
moving
feels
around
we're.
B
So
there
is
review
happening
this
week
with
an
NV
o
3
on
things
that
are
related
to
genève.
There
is
reviews
happening
later
on
today
with
regards
to
six
men
and
the
devii
six
out
capsulation.
The
say
review
correct
me
if
I'm
wrong
ali
zafar,
if
if
things
are
wicked
in
spring
with
regards
to
the
segments
routing
stuff,
so
I
think
we're
trying
to
go
and
progress
that
and
get
feedback
and
lo4
for
all
the
various
working
groups
and
then
I
see
some
nodding
his
head
on
man
bo3.
So
that's
more
over
a
heads
up.
B
R
11,
so
it's
not
our
decision
if
we
want
to
keep
the
work
here,
if
we
have
to
coordinate
with
the
other
working
groups
and
decide
where
those
drafts
go
yeah,
it's
not
only
about,
we
really
have
to
figure
out
where
the
home
is
and
I
already
started,
coordinating
with
the
other
air
directors
and
chairs
on
that.
So.
R
B
R
L
Thanks
yeah,
as
a
house
owned
from
Huawei
I,
asked
a
similar
question
in
the
email
list.
I'm
still
a
little
bit
confused
about
the
ISA
type
shouldn't
that
be
standardized
in
actual
year
and
if
we
can
define
he's
a
type
here
and
was
a
procedure
for
the
liaison
with
the
HP
and
my
question
and
why
you
want
define
the
Easter
type
in
the
GRE
and
we
Jenny
so
I
think
this
I'm
still
little
bit
confused
I.
B
B
L
S
M
Greg
nurse
ect,
I
certain
the
previous
opinion,
because
code
point
requires
definition,
because
if
code
point
is
not
allocated,
it's
valid
to
drop
the
packet.
So
it's
probably
not
the
behavior.
You
expect
if
this
code
point
expects
some
processing
that
has
to
be
defined
and
if
this
either
type
happens
to
be
on
Ethernet
packet
on
Ethernet
frame,
then
what's
the
proper
behavior,
so
I
think
that
at
least
we
need
to
reason
with
I
to
pony
and
ask
them
for
their
opinion.
M
T
Sorry,
oh
yeah,
let's
so
the
IETF
goes
to
I
Triple,
E
and
requests
Ethernet
point
even
at
type
allocations
occasionally
for
drafts.
When
they
have
been
approved,
we
have
an
agreement
with
the
I
Triple
E
for
the
a
assigning.
This
is
really
pretty
cut.
Well,
I,
once
it's
pretty
common,
we've
only
done
it
like
three
times
in
the
last
two
or
three
years,
but
it's
not
unusual.
T
T
A
T
Yes,
but
the
process
can
take
a
while
and
given
our
relationship
with
I,
triple
it
being
I,
Triple,
E
being
so
absolutely
excellent.
You
could
probably
put
the
request
in
after
working
your
blast
call
or
something
it,
and
it
will
take
some
time
it
does
usually
take
about
three
months
or
so,
and
then
you
need
to
sort
of
sometimes
encourage
them.
U
T
O
Another
question
for
the
encapsulation,
because
I
have
a
marketÃs
caution
with
the
operator
and
all
he
case
they
have
much
interested
you
know.
I
am
is
very
useful,
but
you
know
that
so
for
the
legacy
devices
the
supporting
ipv4,
you
know
you
can
see.
Stian
hit
walk,
so
the
hope
also
be
supported.
Iom,
so
I
want
to
know.
What's
the
opinion
making
a
hit
here
for
because
from
our
poem
now
the
most
people
think
the
ipv6
but
a
legacy
devices
a
lot
off
or
the
ipv4
traffic.
So
but
these
are
seems
of
practical
requirements.
B
O
O
H
And
what
a
cool
shirt
we
tried
so
I
was
mr.
Dawkins
I'm,
the
irresponsible
transport
area
director
for
this
working
group.
Now
it
was
the
pleasure
when
we
was
talking
about
the
you
know,
relationship
with
the
I
Triple
E
attitude,
people
being
excellent,
oh
we're
actually
having
breakfast
with
them
on
from
our
coordination
meeting
on
Friday
morning.
If
you
all
wanted
to
give
them
a
heads
up
and
just
see
if
there's
that
yo
at
the
50,000
foot
level,
this
is
coming.
Is
there
anything
that
like
have
you
guys
decided
to
stop
allocating
them?
H
H
N
You
hi
Barack
looks
just
a
coin
on
the
Reformation,
so
we
do
also
see
a
lot
of
interest
in
the
V
for
years
case.
Definitely,
we
started
working
on
a
draft.
At
least
I
was
working
on
draft
or
is
that
the
problem
is
where
to
put
all
these
kind
of
bits,
because
v4
is
very,
very
restrictive.
Just
a
note.
Actually
I
people
already
have
some
kind
of
IO
am
inside,
so
the
ones
did
it
tens
of
years
ago
already
thought
about
it,
but
it's
very
restricted
in
terms
of
what
can
you
put
there?
A
F
A
S
M
So
update
on
stem
based
protocol,
quick
recoup,
so
it's
the
act
of
measurement
or
in
protocol
compatible
with
the
t1
test
to
reuse
packet
formats
and
changes
introduced
backwards
compatible
with
the
t1
quite
default
values.
Reflector
configuration,
simple
activation
of
a
stem
configuration
supported
yang
model
and
yang
model
is
another
working
group
draft
that
we
have
working
on
and
a.
M
Introduced
a
step
may
not
be
supported
by
t1,
so
there
is
extensions
using
TLV
and
we
have
individual
draft
for
your
review
and
comments
appreciated.
So
this
is
a
packet
format
for
stamp
sender.
Everybody
familiar
with
the
t1
Oro
amp
will
see
familiar
structure,
and
this
is
a
reflector
for
uneducated.
A
B
B
M
We're
protecting
against
somebody,
spoofing
measurements
and
creating
false,
negative
or
false
positive
on
the
picture
of
the
back
condition
of
the
network,
because
performance
monitoring
is
important
as
to
verify
that
certain
service
receives
the
expected
SLA,
so
operators
care
big
deal
about
it,
especially
for
the
premium
services.
So
if
somebody's
proof
measurement
results,
so
it's
not
only
a
tag
because
it's
more
computational
load
but
at
the
same
time
it
changes.
The
perception
of
the
network
state.
B
Well,
I
think
it
would
be
good
to
go
and
rather
I
understand
the
threat.
But
what
is
the
kind
of
thing
that
you're
really
protecting
against
what?
If
somebody
would
really
break
the
measurements,
because
128
is
breakable
right
and
I?
Think
I'm
just
wondering
kind
of
why
you
chose
that
one
and
well.
If
somebody
would
go
and
well
brigade.
M
V
M
V
M
W
S
Your
argument
was
about
integrity,
but
have
you
got
an
argument
that
anyone
ever
wants
to
use
confidentiality
given
their
measuring
stuff,
that
you
can
measure
yourself
so
that
it
and
that's
not
about
processing?
That's
about
implementation.
You
know
if,
if
you're
making
people
implement
something
that
no
one's
ever
going
to
use
and
I
mean
certainly
integrity
and
authentication
in.
M
S
E
Well,
hi
again
just
to
add
that
sometimes
out
and
not
authentication,
but
verification
of
the
information
is
very
useful
for
some
kinds
of
protocols.
For
instance,
if
you
are
doing
some
clock,
synchronization
is
very
useful
to
know
that
the
data
that
you
are
sending
are
are
really
good.
I
think
that
it's
in
some
context
there
is
maybe
this
this
kind
of
security,
but
I
also
agree
that
128
bits
it's
not
enough
for
that.
Perhaps
you
should
consider
to
change
that
2056.
Thank
you.
P
Prime
wise
yeah
I
think
it's
max
sha-256
or
something
is
the
more
appropriate
for
any
new
protocol
that
we're
adding
attached
to
tag
these
days.
I
would
say
that
adding
an
H
integrity
tag
is
very
reasonable.
Many
cases
you
have
to
be
a
little
more
careful
as
confidentiality
and
how
the
encryption
actually
is
done
so,
for
example,
you're
suggesting
ECB
mode
for
the
first
8
bytes
in
the
fennec
aidid
case,
which
I
hope
I
guess
that
must
be
authenticated.
But
the
ECB
is
not
a
mode.
P
We
actually
really
use,
because
it's
these
days
it's
it's
nice
that
it
doesn't
expand,
but
it
doesn't
really
have
a
lot
of
good
properties,
good
to
properties
as
other
modes
of
AES
and
then
in
the
other
communists
in
the
encrypted
mode
you're
using
CBC,
which
is
good.
But
you
have
to
have
an
initialization
vector
for
that
and
use
that
in
the
packet
or
how
otherwise,
how
you
drive
that.
M
P
Or
mostly
random
IV
and
it's
percent
in
the
packet
we
tend
to
prefer
or
the
cryptographers
tend
to
discourage,
using,
for
example,
the
same
IV
across
all
packets
in
a
stream
and
this
sorts
of
things.
So
it's
just
something
you
want
to
pay
attention
to
and
that's
why
I
say
really:
there's
a
lot
more
complications
to
adding
confidentiality.
You
might
want
to
just
restrict
this
integrity.
Okay,.
M
A
And
I
think
at
this
point,
because
we
have
some
of
the
other
documents
that
look
like
we
could
be
getting
to
work
in
class
call
first,
so
we're
going
to
run
those
first
and
then,
if
people
can
give
some
of
these
comments
that
they
just
had
onto
the
list
even
before
we
go
to
working
group
last
call
for
us.
That
would
be
good.
M
G
M
G
J
Analyzed
spanned
from
alternate
marking
it's
to
generalize
at
the
span
data,
not
marking
we
create
for
monitoring
purposes,
you
Flo's
joining
several
point-to-point
frozen.
So
in
the
RFC
8321
we
have
a
point-to-point
flow.
In
this
case
we
have
a
multi-point
to
multiple
flows,
for
example.
So
we
have
less
counters
and
we
have
less
computation
in
in
the
motoring
points
in
the
management
center,
but
we
can
add
the
sum
flows
and
we
can
split.
The
net
were
using
our
concept
of
cluster
in
the
network.
Ok,
we
can.
J
A
J
For
example,
we
have
some
kind
of
application
that
demonstrate
that
we
can
reduce
the
number
of
flow
that
we
can
monitor.
The
first
one
is
VPN,
usually
in
a
VPN.
We
have
to
monitor
a
lot
of
rows
because
to
monitor
all
the
point-to-point
flows.
If
we
have,
for
example,
1,000
ppm
endpoint,
we
have
one
medium
of
flows
that
connect
any
twenty.
If
we
define
a
flow
as.
J
One
flow
for
each
VPN
endpoint.
This
flow
is
a
multi
one
point-to-multipoint
that
connects
one
point,
one
endpoint
of
the
VPN
to
the
other
points.
So
in
this
case
we
have
to
monitor
only
1000
flows
for
1000
endpoints.
Naturally,
this
case,
the
motoring
is
less
precise.
Let
me
say
is
precise
for
the
inter
flow,
but
don't
identify
the
precise
flow
point
flow
where
the
loss,
for
example,
the
packet
loss,
happened.
Okay,
we
can
split,
the
net
were
using
the
cluster
concept.
The
other
are
very
similar.
F
J
Okay,
the
principle
of
this
cluster
division
of
the
network
is
the
packet
loss
property
in
a
packet
net,
or
the
number
Moustakas
is
number
of
input.
Packets
means
the
number
of
packets.
This
is
very
trivial,
but
if
this
property
is
intended
not
for
the
whole
network
but
for
single
sub
networks,
we
define
a
principle
that
permits
to
individuate
the
smaller
sub
Network,
in
which
this
property
is
valid.
In
the
next
slide,
we
show
a
simple
meter
that
permits
to
split
the
network
in
all
the
cluster
cluster
is
the
smallest
sub
networks
that
maintain
this
property.
J
J
Not
precise
with
me
say,
but
more
general
principle
that
the
thing
in
the
u8
the
area
of
the
network,
where
their
losses
happens.
If
we
want
to
have
a
more
precise,
we
have
to
add,
as
other
intermediate
points,
is
choosing
other
interface
in
the
networks.
So
it's
possible
to
split
the
cluster.
Adding
other
measurement
points.
J
This
is
a
not
so
precise
because
it's
an
average
if
we
want
to
have
a
single
packet
measurement,
the
topology
used
to
select
the
point
of
measurement
on
the
bezel
on
the
basis
of
cluster.
So
we
use
the
machine
to
select
the
packets
in
the
next
slide.
I
think
yes,
in
the
RFC
five
four
seven
five
is
a
show,
the
method
that
permits
to
select
some
packets
and
to
invade
the
packets
in
different
point
of
the
network.
J
In
this
case
we
collect
all
the
packets
for
each
cluster
in
the
input
point
and
all
the
packets
in
each
class.
In
the
out
point,
we
can
make
some
comparison
to
individuate
the
same
H
in
the
waiting
area,
so
it's
possible
for
each
packet
to
follow
the
path.
So
the
measurement
is
not
multi-point
is
point-to-point.
The
multi-point
network
and
the
cluster
concept
term
is
to
have
less
computation
less.
J
J
If
there
is
a
problem
with,
we
can
select
the
flow,
so
we
split
this
multi-party
flow
in
a
smaller
flows
or,
in
another
case
oome
physically,
not
to
consider
all
the
networks
but
consider
the
cluster
inside
the
network
overall
group
of
cluster,
because
the
packet
loss,
property
works
also
for
group
or
cluster
data
that
are
connected.
So
in
this
case
is
the
final.
The
finite
state
machine
that
works
in
this
way
in
order
to
make
a
dynamic
monitoring.
J
Okay,
this
is
the
summary,
is
very
simple:
a
controller
can
calibrate
performance
measurement,
dynamic
performer
measurement
is
introduced
in
the
alternate
marking,
+
Asian
technique,
+
cluster,
add
to
perform
optimize
the
single
packet
performance
analysis,
so
we
put
together
many
methodology
to
optimize
the
performance
analysis
that
is
very
complicated
to
do
without,
let
me
say,
segmenting
of
the
network
segmenting
of
the
flows,
the
working
group
just
adopted.
That
is
this
draft,
so
we
can
I
hope
we
can
begin
the
path
became
FC.
Thank
you.
Thank.
J
A
X
Thanks
Jay
I'm
Jay
and
as
earlier
during
the
conversation,
the
point
was
made
that
the
problem
is
with
the
v4
and
measuring
the
v4.
Information
is
very
important,
so
this
proposal
came
out
of
that
discussion
and
idea
is
very
simple:
that
we
want
to
be
able
to
measure
the
metrics
for
the
v4
traffic,
which
is
80
percent
of
the
traffic
in
a
data
center
TCP,
UDP
traffic
and
the
scheme
should
work
seamlessly
for
ipv6
traffic,
any
other
kind
of
tunnel
traffic
and
MPLS
as
well.
X
But
this
presentation
is
focused
on
your
nighty
or
an
MPLS,
so
the
requirement
which
came
to
us
that
there
is
a
deployment
where
the
protocols
fields
are
already
used.
Let's
say
the
VX
line
header
the
field
is
used
in
that
and
we
cannot
really
have
a
new
GP
extension
to
use
this.
So
is
there
a
proposal
which
can
use
the
existing
format?
Same
thing
is
on
the
IP.
Some
folks
use
the
dhcp
bits.
Can
we
use
something
where
I'm
not
relying
on
the
dhcp
bits
proposal?
X
The
other
thing
very
important
is
that
the
path
of
the
packet
should
not
change,
meaning
that
the
l4
headers
and
the
information
in
the
f4
header
should
be
preserved,
and
thank
you
go
fast,
so
so
so
that
that
was
a
protocol
requirement
on
the
operational
side.
I
think
this
is
something
which
came
in
in
the
conversation
that
the
insertion
of
the
metadata
should
not
increase
the
size
of
the
packet.
We
are
the
P
NTU
protocols
are
messed
up
so
P
and
T.
X
That
was
a
concept
which
was
needed,
and
then
there
was
some
limitation
we
wanted
to
put
on
the
amount
of
metadata
which
need
to
be
inserted
in
the
packet.
So
on
the
performance
side,
this
is
something
which
the
question
I
had
earlier
in
the
presentation
that
have
we
discussed
it
with
the
silicon
vendors,
because
one
of
the
cost
I
mean
the
cost
of
implementing
this
in
Hardware.
X
Given
that
this
is
a
data
path
feature
if
it
is
too
much
getting
the
backing
from
silicon,
when
they
will
be
very
difficult,
so
what
I
am
proposing
here
is
salient
points
that
we
should
not
rely
on
DMA
in
the
next
cell
of
the
package
into
the
hardware,
which
impacts
the
performance,
not
recycling,
the
packet.
All
the
edits
on
the
packet
should
happen
in
low
place.
Wheels
should
not
go
beyond
certain
local
offsets
so
that
the
hardware
is
very
efficient
and
that
essentially
helps
the
cost
of
implementation
in
the
hardware.
X
X
And
then
the
hardware
knows
whenever
the
IP
protocol
is
this
proto
I
have
a
then
it
has
to
pick
the
actual
protocol
for
the
hash
computation
from
the
from
the
copied
information,
which
is
so
that's
one
part
of
it.
And
if
you
see
the
metadata
is
actually
treated
as
a
layer
for
information
and
it's
it's
after
the
layer
for
information
and
essentially
what
it
does.
It
helps
to
keep
the
various
computation
which
relies
on
the
l4
information.
So
that's
pretty
much
it
and
my
request
is
to
look
at
it
poke
at
it.
X
X
M
F
X
The
institution
as
well
it
depends
what
information
you
are
trying
to
gather.
If
you
are
trying
to
gather
the
information
about
the
network
and
network
alone,
then
your
statement
is
right,
but
you
want
the
information
about
the
network
in
a
context
of
an
application.
Then
you
need
the
light
there
right.
X
Z
Hi
everyone,
my
name,
is
Rakesh
Gandhi,
and
this
is
the
first
time
I'm
presenting
in
AI
ppm.
So
we
have
this
couple
of
drafts
for
performance
measurement
in
spring
working
group.
They
are
four
segment
routing.
The
first
draft
is
is
for
the
MPLS
data
plane,
it's
an
informational
draft,
so
both
drafts
that
we
have
relies.
Z
They
rely
on
the
RFC,
6334
and
RFC
7876.
So
those
are
the
existing
RFC's
and
the
focus
is
that
how
we
use
them
for
segment
routing.
So
in
some
sense
they
are
not
defining
any
new
protocols
per
se,
so
the
for
the
first
one,
the
agenda,
the
requirements
and
scope.
So
what
drafts
are
for
the
probe
messages
for
the
SR
links
and
the
p2p
and
p2
MPs
are
policies
for
the
delay
and
last
measurement.
Z
So
there
are
few
things
that
go
with
it
in
different
irises
that
we
have
put
put
them
together.
So,
as
mentioned
billion
last
measurement
and
extended
the
team
matrix
for
the
delay
and
loss,
the
scope
is
there
in
this
draft
the
segment
our
thing
with
MPLS
data
playing
the
probe
messages
and
the
two
RFC's
that
we
mentioned
and
informational
in
nature.
Z
So
for
links,
the
probe
packet
is
sent
with
the
gal
as
defined
in
the
Odyssey
60
C
74
for
policies
they
are
sent
with.
The
label
stack
the
data.
She
defines
the
gallon
gas
values
for
the
delay
measurement
for
lesson,
as
well
as
for
loss
measurement
for
the
probe
responses.
The
RFC
7870
C
defines
the
uro
TLV
for
out-of-band
reply
and
for
the
two,
a
measurement
the
replies
send
the
same
way
as
the
query.
Z
Z
So
we
welcome
your
comments
and
suggestions
and,
as
mentioned,
those
are
existing
RFC,
so
implementations
already
exists
and
of
this
is
for
the
spring
working
group.
We
would
be
requesting
adoption
for
it
and
the
second
draft
is
defining
the
UDP
path.
So
when
we
have
segment
routing
with
ipv6
data
playing,
there
is
no
gaol
support.
So
we
are
adding
UDP
port
to
point
the
RFC
63
74
packets.
So
again
we're
not
defining
any
new
protocols
per
se
same
as
60
74
has
already
been
implemented.
Z
This
one
adds
the
UDP
path
for
it
again,
requirements
and
scope.
These
are
for
the
probe.
Messages
for
the
there
are
few
TLB
is
not
present
in
RFC
66
already
for
that,
and
it
can
be
useful
for
segment
routing.
So
we
have
added
those
TL
ways
and,
as
you
know,
the
segment
routing
policies
there,
the
ICMP
along
the
path,
so
what
we
can
do
about
them
for
performance
measurement.
Z
Z
Z
So,
as
as
mentioned,
there
is
one
UDP
port
for
the
delay
measurement
and
one
UDP
port
for
the
last
measurement
that's
requested
and
this
one's
messages.
If
you
are
oh,
is
there
from
the
RFC
7876,
then
that's
use
for
the
reply.
Otherwise,
responses
sent
using
the
information
from
the
probe
messages,
so
there
is
a
little
part
TLV.
Z
It
can
contain
either
the
segment
list
or
the
binding
site
for
SR
MPLS
or
less
a
v6.
So
the
RFC
6624
doesn't
have
a
second
sequence
number.
We
thought
is
quite
useful
to
have
so
we
have
added
a
TLB
for
it
again.
The
same
RFC
does
not
have
a
block
number
and,
as
you
know,
the
8321
alternative
marking
scheme
requires
block
number
or
coloring.
So
we
added
a
TLB
for
the
last
measurement.
As
you
know,
there
is
EC
mp4s
our
policies
and
many
MPLS
OAM
RFC
is
already
talked
about.
Z
Ecmp,
so
we
can
use
the
destination
source
address
in
the
UDP
or
SRM
pls.
There
is
entropy
label
or
a
service
six.
This
flow
level,
if
you
wanted
you
know,
may
serve
the
certain
ICMP
path.
So
we
welcome
your
comments
and
suggestions
again.
Those
RFC's
are
already
there.
So
implementations
are
there
as
well.
So
in
the
spring
we
would
be
asking
for
working
group
adoption.
Thank
you
just
a
couple.
M
Seconds
over
okay
couple
comments:
first,
in
your
first
presentation,
you
erred
on
label
element.
There
is
no
exp
field.
This
field
was
renamed
a
traffic
class
several
years
ago.
Second
of
all,
is
that
this
draft
I
believe
doesn't
have
any
archival
value.
It
looks
more
like
design,
specification
and
I.
Don't
see
the
value
of
discussing.
M
Less
adopting
for
the
second
presentation
is:
why
not
to
use
a
1
T,
1
plus
stamp
over
a
server
6.
Why
invent
something?
Because
these
protocols
are
for
IP
network
and
segment
routing
in
IP
network,
where
ipv6
is
nothing
different
from
IP
network,
so
why
you
cannot
use
that,
and
it
already
gives
you
sequence
number
on.
Your
other
point
is
63.
74
is
quite
well
equipped
to
do
synthetic
OS
measurement.
That's
where
you
need
a
sequence
number,
so
you
don't
need
to
invent
any
new
till
v4,
63,
74,
so
I
think.
M
Z
N
G
Y
My
name
is
Talon
from
Huawei.
This
draft
is
a
joint
work
with
karma
Josette
and
Malraux
Mac
Bureau
and
Craig
a
bit
of
background.
The
idea
alternate
marking.
We
want
to
be
able
to
measure
the
traffic
between
two
measurement
points:
NP
1,
+,
NP
2.
That
means
lost
delay,
delay
variation,
RFC
8321
defines
a
way
to
do
that,
using
marking
bit
the
marking
bit
changes
periodically.
Y
Y
This
Draft
defines
new
alternate
marking
methods
which
allow
you
to
use
single
bit
per
packet
with
the
same
level
of
accuracy
as
the
double
marking
method
or
to
use
zero
bits
per
packet.
So
it
defines
a
few
a
few
new
methods
of
alternate
marking.
It
also
summarizes
the
existing
methods
of
alternate
marking,
so
we
have
kind
of
a
summary
and
comparison
between
the
methods.
Y
There's
a
draft
by
TN
Ron,
which
wasn't
added
here
yet
and
actually
also
the
multi-point
marking
draft,
which
was
presented
by
Morrow,
which
is
now
a
working
group
item,
uses
some
of
the
concepts
from
this
draft.
So,
first
of
all,
we
believe
that
quite
a
few
of
these
drafts
can
make
use
of
the
current
draft.
Y
We
believe
that
the
authors
of
these
drafts
should
certainly
be
familiar
with
the
current
draft
we'd
be
happy
to
hear
comments
from
these
authors,
so
I
certainly
believe
that
this
draft
is
something
that
should
be
reviewed,
we'd
love
to
hear
comments
about
it
and
that's
at
least
the
first
step
after
that,
we'll
ask
for
working
with
production.
It's.
G
A
AA
Short,
you
guys
can
all
hear
me
okay.
So
what
this
is
is
we
talked
about
it
last
time
it
combines
PDM
and
the
marking
method.
I'm
gonna
go
kind
of
quick,
because
there
was
only
one
issue
that
was
well
a
couple
issues
would
have
brought
up,
and
this
is
a
resolution
to
one
of
them.
Okay,
so
basically,
what
we're
doing
is
is
PDM
as
a
destination
option,
it's
int
and
we
want
the
hop-by-hop.
AA
So
basically,
if
you
think
of
trace
route,
but
hybrid
measurement
and
in
the
packet,
then
you
got
what
we're
trying
to
do
here.
Okay,
so
this
is
in
PDM
round
trip
delay
but
doesn't
have
one
way
delay
or
middle
box
delay.
So
PDM
is
wonderful,
but
then,
if
you
have
a
problem,
we
need
this
okay.
So
let's
stop
a
second
here.
So
the
problems
were
is
that
we
have
defined
this
hop
by
hop
header
for
v6.
AA
We
had
a
middle
box
identifier
and
then
a
time
stamp
in
and
out
for
obvious
reasons,
but
it's
a
16-bit
timestamp.
So
the
question
was
what
how
you
gonna
do
that?
What
what's
in
that
time
stamp?
Okay,
I
know
it's
like
it's
like
out
of
alignment
so
like,
if
your
eyes
are
crossing
there's
a
reason.
Okay,
so
since
is
16
bits
what
we
said
and
time
stamp
obviously
is
bigger
than
that,
so
we
made
this
a
delta
field.
AA
AA
I
mean
it's
a
pretty
simple
concept,
pretty
easy
to
see,
and
the
thing
is
is
like
because
it
actually
doesn't
even
require
time
synchronization
from
one
middle
box
to
the
other,
because
it's
really
inside
that
middle
box,
and
so
that's
kind
of
the
the
thing
that
you
get
so
with
this.
What
you'll
get
is
so,
let's
say
you
have
a
big
hop
in
the
middle.
You
got
a
satellite
link
in
the
middle.
This
could
be
super
useful.
There
is
some
talk
about
performance
enhancing
proxies
well.
They
could
certainly
use
this.
AA
If
you
have
a
middle
box
on
your
network,
that's
causing
you
delays,
we
can
help
you
out
there
that's
kind
of
the
functionality,
so
any
comments,
everybody
loved
it.
We
love
it.
No,
no
comments,
my
guy.
What
is
wrong
with
everybody,
my
head,
like
does
nobody
care,
Mike,
get
up
and
tell
Tommy
hair
everybody
how
you
love
this
and
he'll
be
so
super
useful.
AA
Y
AA
V
M
Okay,
so
this
will
be
update,
so
what
we're
proposing
the
method
to
do
on
path,
telemetry
collection,
but
it's
a
split
into
their
measurement
and
collecting
so
this
protocol
it
doesn't
define
how
the
measurement
are
done.
There
are
some
suggestions,
recommendations
possible
options,
but
it
defines
how
their
collection
on
paths
is
supported.
M
So
what
is
proposed?
So
this
is
a
just
a
diagram
of
HTC
domain.
We
have
an
egress
node
and
we
have
transit
nodes
and
an
egress,
node
and
so
packet.
It
represents
the
data.
The
trigger
is
some
condition
that
triggers
the
measurement,
and
then
there
is
a
HTC
follower
packet
that
being
injected
by
the
ingress
or
possibly
transit
nodes
and
is
consumed
by
the
egress,
so
that
this
packet
should
not
leave
the
domain.
So
the
operation
is
quite
simple.
M
One
of
specifics
of
mechanism
are
that
is
in
HTC,
is
that
we
are
not
bounded
by
the
size
even
of
a
single
follower
packet,
because
there
there
might
be
a
sequence
of
follower
packets
on
the
same
path
trigger
it
well
caused
by
one
trigger
crossing
all
the
transit
notes.
So
that's
overcomes
the
restriction
of
their
amount
of
information
to
be
collected,
so
comments
suggestions
were
opened
for
new
offers
contributions
and
would
like
to
consider
working
a
reproduction.
Yes,
please
great.
X
M
So,
basically,
what
we
have
and
that
we're
going
into
specifics
of
what's
in
document,
so
there
are
certain
mechanics
that
transit
node
wait
for
and
how
we
limit
the
number
of
outstanding
flows,
HTC
flows
for
the
same
service,
so
that,
basically,
if
there
is
some
like
rico's,
okay,
let's
take
example:
SFC
recursive
fire
in
between
of
sft
right.
It
can
change
the
path.
M
So
then
it
will
be
generated,
new
follow-up
packet
which
will
go
to
their
end
to
the
egress
and
then
egress
can
really
put
them
together
and
correlate.
But
thank
you
yeah,
but
again
there
might
be
some
edge
scenarios
that
we
haven't
considered
so
I
appreciate
your
thoughts
and
comments
and
discussion.
M
F
F
Is
a
principle
of
this
job,
as
shown
in
this
diagram?
I
am
encapsulating.
Note
can
catch
his
ayam
configuration
data
from
all
I
am
note
along
the
path
the
army
Kamsa.
Lady
note,
it
can
send
echo
request
to
each
note
along
the
path
and
they
received
echo
reply
from
this
node
and
the
through
this
process.
I
am
configuring
encapsulating
note
can
catch
the
configuration
data.
F
F
And
the
second,
the
main
change
is
time
step
in
a
0-2
version
of
data.
It
introduced
the
new
format
of
time
step,
currently
the
codes,
pvp
ntp
and
the
p
IX
e
OS
x,
and
this
change
in
his
job
to
enable
the
I/o
mean
caps
ability
node
to
know
the
format.
The
lens
of
the
time
step.
That's
configured
at
the
decapsulation
node.
F
L
Hello,
this
is
how
you
from
Hawaii
I'm,
going
to
present
an
alternative
method
to
the
Institute.
Oh
am
so
we
all
know
the
data
printing
m3.
Now
we
prefer
to
use
the
in
band
monitoring.
So
IOM
is
a
perfect
way
to
do
that.
It
basically
is
a
way
to
do
the
in
bayonetta
geometry.
It
can
directly
carry
the
data
in
the
user
packet
and
reflects
a
real-time
experience
of
user
traffic.
L
L
For
example,
we
don't
need
to
correlate
the
data
because
they
all
come
go
together
and
so
data
is
self
describing
and
also
we
use
a
single
package
to
export
the
accumulated
data
as
so,
so
the
overhead
is
low
and
we
don't
need
a
lot
of
for
configuration
to
the
network
nodes
because
we
carry
the
instruction
in
the
package.
However,
it
as
a
IOM
also
have
some
issues.
First,
we
need
a
lot
of
data,
header,
parsing
and
processing
and
the
my
incur
some
performance
penalty
and
also
will
keep
increasing
the
practice
size.
L
There
are
some
mq
concerns
of
the
packet
processing
issues
to
the
system
that
they
depend
in
device.
Also,
we
introduce
some
encapsulation
issues.
For
example,
people
has
pointed
out
it's
difficult
to
encapsulate,
seen
ipv4
network
also
also
for
MPS.
Fortunately,
those
two
type
of
networks
are
most
popular
today
and
also
the
data
must
be
instruction.
L
The
data
must
be
carry
in
the
plain
text
that
might
have
some
security
concerns,
because
if
you
intercept
the
packet
or
you
with
your
temper,
the
data-
you
don't
know
its
end
node
and
also
if
the
packet
is
dropped
somewhere
internet
for
people
not
to
be
able
to
find
where
it's
dropped.
So
we
have
alternatives
that
we
call
the
PBT
post
card
base.
I
you
stand
up
for
carry
the
data
with
a
user
user
packet.
We
just
send
the
each
the
data
with
independent
the
export
packet
to
the
to
the
character,
so
it
basically
are.
L
We
only
need
to
configure
each
node
to
tell
on
what
what
kind
of
day
turn
are
they
to
need
to
be
collected
for
each
user
user
packet.
So
we
can.
You
can
see
you
and
solve
all
the
issues
faced
by
the
iom,
but
it
does
incur
some
extra
cost
like
we
now
need
to
correlate
the
data,
because
we
need
to
know
which
side
of
postcards
belong
to
the
same
user
packet.
Also,
we
may
slightly
increase
export
overhead
because
each
individual
packet
level
has
its
own
transport
layer
header.
L
Also,
we
need
a
lot
of.
We
need
some
configurations
in
the
device.
So
that's
why
we
have
the
second
alternative
for
that
we
call
that
postcard
based
telemetry
instruction
aki
BTI
in
this
alternative.
We
also
include
the
instruction
header
in
the
user
packet,
but
we
still
just
export
the
data
with
a
independent
IOM
packet.
L
It
still
has
the
encapsulation
issues,
but
you
know
now:
we
don't
need
to
correlate
the
data
because
the
instruction
in
the
instruction
header,
we
can
carry
the
flow
identifier
and
a
packet
sequence
number,
so
we
can
easily
to
identify
that
the
postcards
so
also
there's
no
need
to
configuration
and
because
the
instruction
header
will
carry
all
the
other
informations,
we
need
to
tell
node
what
to
do
so.
This
I
skip
this
lines.
This,
as
a
PBT
I,
show
the
format
of
the
instruction
header.
L
L
O
Quickly,
added
information,
the
first
so
I
you
that
we
found
a
some
diesel
scenario.
Neither
this
is
a
postcard,
a
basic
elementary,
so
there's
a
later
header
after
that's
a
user
for
the
IP
of
young.
We
can
use
this
as
a
postcard
because
we
needed
IP
IP
on
Europe
or
hope
to
perform
to
detect
the
packet
loss
ratio
and
the
delay
so
that
maybe
you
would
oppose
a
card
abuse
at
elementary
for
this
scenario.
O
Second,
why
you
talk
to
many
customers?
They
have
much
concern
about
the
you
can
see
steam.
The
changer
of
the
encapsulation
because
of
the
SR
receives
network
programming
and
I
am
so
that
seems
so.
That's
the
header
of
the
packet
increased,
bigger
and
bigger.
So
the
matter
concern
about
the
existing
the
network
devices,
so
the
postcard,
the
master.
That
is
also
you,
the
one
we
to
try
to
reduce
the
requirement
to
upgrade
you
disease,
gene
devices,
alright.
So.