►
From YouTube: IETF108-IPPM-20200731-1410
Description
IPPM meeting session at IETF108
2020/07/31 1410
https://datatracker.ietf.org/meeting/108/proceedings/
B
A
C
That
makes
more
sense:
okay,
yeah.
We
have
a
pretty
full
agenda
today.
We
have
a
lot
of
presentation,
so
you
know
we'll
have
to
be
careful
about
keeping
on
time.
We
have
some
so
for
existing
work.
We
have
greg
speaking
about
option
tlv,
an
update
on
the
ippm
capacity
metric
graph
and
the
in
progress
ioam
drafts.
C
C
So
draft
ippm
stamp
option:
tlv
is
an
isg
evaluation
and
iom
data
is
set
up
for
ad
evaluation.
D
Sure
yeah
I
I
did
read
iom
data,
it's
in
pretty
good
shape.
I
did
have
a
small
number
of
comments
that
they're
scared
in
somebody's
inbox.
Please
reply
to
them
a
markers
revised
id
needed,
I'm
happy
to
discuss
that.
Maybe
that's
not
the
case
and
we
should
just
ship
it
the
way
it
is
and
just
do
the
fix
later.
But
I
would
like
a
reply.
C
A
C
E
Okay,
great,
thank
you
next
slide.
Please.
E
E
Okay,
the
tio
format
we
introduce
the
flex
field
and
three
flags
been
allocated
to
indicate
the
unrecognized
message:
type
mal,
formed
tov
and
to
do
authentication
or
integrity
failure,
no
integrity
check.
E
Others
are
still
available
and
well
it's
a
kind
of
scarce
resource,
so
we'll
be
careful
and
allocating
them
next
slide.
E
E
E
E
Clarified
how
the
integrity
check
works
with
the
hmac
and
what
we've
done
is.
It
was
very
good
discussion
about.
The
original
proposal
was
to
use
the
text
only
in
tlvs,
and
it
was
pointed
out
that
this
way
it
creates
a
possible
basically
absence
of
any
connection
between
the
base
packet
and
their
extension
creates
the
possibility
of
replay
attack.
E
So
what
we
added
is
that
the
sequence
number
in
the
base
packet
is
used
to
calculate
the
hmac
digest.
So
thus
it
creates
a
link
and
several
updates
in
ionic
considerations.
Next
slide.
Please.
E
Location
tlb:
it's
changed
because
a
very
interesting
scenario
that
we
originally
missed
is
that
if
between
sender
and
reflector,
we
have
nat
64.
So
thus
one
cannot
know
what
their
address
family
will
be
returned
so
because
we
are
supporting
the
symmetrical
packet
size.
E
We
worked
out
and
introduced
sub
tovs
and
that,
in
addition,
that
it
addresses
a
comment
we
had
for
mac
address
length
because
there
is
a
48
bits
and
64
bits.
Mac
addresses
so
now
ip
addresses
in
the
mac
address.
They
are
queried
using
the
sub
to
these,
and
then
the
subtle
v
is
the
size
of
to
accommodate
the
longest
possible
data
next
slide.
Please.
E
So
we
still
have
some
discusses
that
all
the
comments
were
acknowledged
and
responded
to
changes
proposed,
and
I
believe
that
after
the
meeting
we'll
just
resume
the
discussion
and
publish
the
new
version.
A
All
right,
thank
you
so
much.
We
have
a
couple
minutes
if
anyone
has
any
questions
on
that
or
wants
to
make
any
comments
on
those
last
changes
and
updates,
we
have
for
this
draft
and
I
would
encourage
people
to
read
the
updates.
F
Greg
all
right:
okay,
thanks
thanks
tommy
thanks
ian,
I
can
see
my
first
slide
here.
I'm
just
gonna
back
up
to
chair
status
and
mention
that
the
route
metrics
draft
didn't
appear
there,
but
it's
a.
F
It's
a
right.
It's
a
it's,
an
iesg
on
the
telechat
agenda
for
for
next
time,
around.
F
Okay,
so
I'll
I'll
try
to
keep
this
to
five
minutes.
The
clock
is
operating,
so
this
is
a
draft
that
I'm
writing
with
rudiger
and
and
len
chaveton,
and
let's
go
to
the
next
slide
and
I'll
try
to
cover
these
first
three,
four
really
quickly.
So
here's
where
we're
going
to
end
up
today
trying
to
reach
consensus
soon,
so
we
can
start
protocol
support
and
that
means
getting
agreement
on
the
metric
and
method
and
try
to
trigger
any
concluding
reviews
with
the
working
group.
F
F
You
can
see
a
trial
results
taken
about
every
50
milliseconds
in
the
current
system
and
the
time
divided
up
into
subintervals
of
a
total
test
interval
and
there's
feedback
from
the
receiver
on
the
test
stream
to
the
sender,
which
includes
the
rate
measurement
and
loss
delay,
delay
variation,
outer
sequence,
packets
and
so
forth.
So
those
are
the
kinds
of
things
that
are
happening
in
this
method
and
metric
next
slide.
Please.
F
This
version
of
the
metric
follows
the
ippm
framework,
which
is
to
define
a
first,
a
singleton
which
are
the
the
dt
measurements
sub-interval
measurements
and
then
looking
at
a
sample
of
those
which,
in
this
diagram
below,
is
10
and
then
finding
the
maximum
of
those
10
measurements
and
we've
defined
it
in
words
and
and
an
equation
which
is
kind
of
the
the
typical
thing
that
we've
done
in
ippm
next.
G
F
Please
so
here's
the
draft
status
we've
been
getting
additional
comments
and
reviews
from
lots
of
places
the
etsy
stq
mobile
technical
committee,
which
is
a
good
one.
You
know
we
certainly
want
this
to
be
applicable
to
the
mobile
environment
broadband
forum
in
the
context
of
preparing
their
technical
report
and
a
a
new
one.
This
time
around
is
the
fcc
working
group
on
gigabit
access
measurement
in
the
united
states,
some
interesting
feedback
from
those
folks
there.
F
Unfortunately,
you
know
it's
up
to
me
to
transfer
all
this
good
knowledge
and
comment
into
the
document.
Also,
four
new
members
of
itu-t
study
group
12,
who
are
testing
companies
and
they've,
provided
their
feedback
so
in
in
version
2.
The
access
policies
are
basically
the
a
new
area
that
we
discussed
in
in
the
fcc
group.
We're
got.
We've
got
new
references
for
things
on
the
load
adjustment
for
our
running
code
section
and
we're
referencing,
the
broadband
form
tr
on
on
471
for
the
information
model
and
reporting.
F
F
F
So
a
quick
global
status
is
that
this
is
approved
in
itu-t
study
group
12
and
in
etsy
technical
committee
on
speech
and
multimedia
transmission
quality,
and
now,
just
last
month,
broadband
forum
approved
this
document
as
well.
F
We've
also
got
a
new
supplement
in
the
itu-t
study
group,
12
interpreting
the
capacity
results,
kind
of
our
measurement
considerations,
we're
still
we're.
Our
draft
is
adopted,
of
course,
in
ippm
and
two
new
items
down
at
the
bottom.
There
that
are
gonna
be
a
little
bit
of
a
surprise.
F
The
etsy
stq
mobile
committee
is
is
taking
this
up
as
part
of
their
5g
performance,
measurements,
kpis
and
qos,
and
there
will
very
soon
be
an
open
broadband
udpst
utility
project
announced
soon
next
slide.
F
So,
like
I
said,
we're
seeking
last
call,
and
you
know
the
reason
for
for
doing
this
in
multiple
standards.
Bodies
is
buttressed
here
by
the
xkcd
cartoon.
We
certainly
didn't
want
to
just
add
another
competing
standard.
What
we've
tried
to
do
is
do
the
a
a
unique
approach
where
we've
tried
to
produce
four
harmonized
standards
across
stos
and
basically
all
my
friends
when
I
started
out
trying
to
get
four
standards.
F
Everybody
said
well
al
good
luck
with
that,
and
we
all
know
what
that
means
that
no
one
thought
it
was
going
to
happen
and
we're
actually
pretty
close
to
that
right
now
and
and
we're
actually
doing
better
than
that
we're
getting
some
help
got
some
help
with
the
running
code
got
some
help
in
an
additional
standards
body
on
mobile
and
5g,
so
it
I
think
it's.
F
It
would
be
a
good
time
to
start
a
working
group
last
call
here
and
that
way
we
can
move
ahead
with
knowing
what
we
want
to
develop
in
protocol
development
for
stamp
and
t-wamp
and
so
forth.
Thank
you.
A
And
the
document
seems
pretty
stable
at
this
point,
so
it
seems
like
a
reasonable
time
to
go
to
last
call,
I
think,
we're
a
good
place
with
her
q.
Just
I
guess
very
quickly.
If
anyone
does
have
comments
or
thoughts,
please
speak
up
now
and
would
encourage
people
to
make
sure
that
we're
reading
any
of
our
documents
like
this-
and
I
think
the
last
call
would
be
a
good
way
to
trigger
that
more
attention.
So.
H
All
right,
so,
hopefully
you
can
hear
me,
can
you
all
right?
So
I
think
the
iom
section
has
three
portions
and
the
first
one
is
on
v6
options
and
I'm
gonna
go
cover
that
the
second
two
portions
will
be
covered
by
towel
so
on
the
v6
options
next
slide,
that
draft
has
been
an
individual
draft
for
a
while,
and
it's
basically
could
you
go
to
the
next
slide.
H
Maybe
thank
you
and
given
that
it's
just
as
for
the
allocation
of
two
values,
it's
a
relatively
short
document
and
it's
been
stable
and
the
early
allocation
thanks
for
taking
off
the
process
a
while
back
has
been
completed.
H
We
have
early
allocation,
that's
going
to
go
last
until
april
next
year,
and
I
know
that
justin
we
have
on
the
call
here
is
already
using
those
for
his
linux
kernel
implementation.
I
H
Iom
and
well
that
needed
clarification,
because
there
is
a
contradiction
in
their
next
slide.
Let
me
go
and
give
you
a
little
bit
of
background
so
that
we
understand
what
the
problem
is
about.
H
We've
written
a
document
which
is
kind
of
a
sister
document
to
the
working
group
document
that
is
adopted
a
deployment
document
for
ipv6
that
tells
how
to
use
these
options
and
there
we
clearly
spelled
out
that
iom
domains
are
either
bounded
by
host.
So
the
host
inserts
the
iom,
option
extension
header
and
it's
going
to
go
and
remove
it
again
at
another
host
or
they're
bounded
by
networking
devices
and
in
case
they're
bounded
by
networking
devices.
H
It
is
always
the
case
that
we
do
dual
link
app,
so
the
packet
will
always
be
encapsulated
into
an
ipv6
packet
and
that
v6
packet
will
carry
iom
extension
headers,
which
means
that
by
no
way,
packets
could
go
and
escape
from
that
particular
iom
domain,
which
is
something
to
keep
in
mind
because
there's
been
a
paragraph
in
the
document
that
causes
the
confusion
that
was
about
escaping
packets
from
a
particular
iom
domain.
Next
slide.
H
To
expand
a
little
bit
on
well,
the
forwarding.
H
I
think
the
key
highlight
is
that
not
all
nodes
in
an
iom
domain
are
necessarily
required
to
be
aware
of
iom
in
tracing.
You
want
to
go
and
decide
which
points
you
want
to
go
on
trace
in
the
domain
improve
of
transit.
You
obviously
only
have
those
nodes
probably
available
for
iom,
where
you
do
want
to
go
on
proof,
transit,
same
thing
for
direct
export
you're
only
going
to
go
and
enable
those
nodes
that
necessarily
need
to
go
on
that.
You
want
direct
export
from
and
well
for
e2e.
H
Maybe
you
only
want
to
go
and
enable
the
option
that
yet
the
the
edge
nodes
of
a
particular
iom
domain,
so
I
think.
I
H
Important
to
recognize
that
not
all
nodes
need
to
go
and
do
that,
which
is
why
next
slide
from
an
early
encapsula
from
an
early
allocation
perspective.
What
we
asked
for
is
well,
we
got
two
no
two
to
two
values
allocated
and
one
has
a
one
in
the
third
bit,
because
it
might
change
on
route
for
tracing
and
for
proof
of
transit
and
the
first
one
and
and
what
they
both
have
in
common
is
that
they
both
say
in
the
two
first
bits:
zero:
zero.
H
H
If
you
can
flip
forward
what
the
text
in
and
that's
a
little
bit
of
a
left
over
from
the
very
early
discussions
that
we
had
in
six
man,
what
the
text
says
right
now
is
that
notes
need
to
be
explicitly
configured
on
a
particular
interface
to
go
and
support
iom,
and
otherwise
you
would
need
to
go
and
drop
the
packet
and
that
obviously
contradicts
with
the
zero
zero
two
bits
in
the
starting
point
from
a
v6
perspective
in
the
in
the
optional
location.
H
Now
that
was
originally
put
in
because
of
concerns
that
packets
might
escape
a
particular
iom
domain
and
then
cause
harm
and
confusion
to
people
that
have
no
clue
about
iom,
don't
understand
it
and
don't
want
to
go,
see
it
and
okay,
that's
fine,
but
the
world
has
moved
on
since
that
we
have
the
deployment
draft
for
iom
over
v6
and
that
very
much
contains
iom
2a
domain.
As
I
said
before,
so
we
can
simply
remove
this
text
and
we
have
consistency
and
we
don't
really
have
a
problem.
H
So
it's
a
very,
very
straightforward
fix
to
a
problem
that
we
well
had
no
proper
solution
for
when
we
initially
wrote
the
text,
but
since
the
world
moved
on
and
progressed
and
we
have
the
deployment
draft,
I
think
we
have
a
solution
now,
it's
just
like
the
text
is
no
longer
required.
We
can
remove
it
next
slide.
That
means
proposition
is
very
simple
and
that's
also
what
I
said
over
the
email
list
on.
I
think
wednesday,
when
I
replied
to
tom.
H
Let's
get
rid
of
that
paragraph
if
everybody's
fine
with
that,
because
we
have
a
good
solution
and
that
good
solution
is
pretty
much
framed
by
the
deployment
draft.
So
my
question
is
shouldn't
we
go
and
adopt
the
deployment
draft,
also
as
a
working
group
document,
so
that
you
can
go
and
progress
as
a
sister
document
with
the
options
draft,
because
it
shows
here
that
deployment
context
is
important
for
people
who
code
up
a
an
iom
implementation,
but
the
thing
naturally
came
up
because
of
justin's
work
on
the
kernel
implementation.
A
All
right,
thank
you.
If
people
want
to
comment,
please
get
in
the
queue,
because
one
one
question
here.
A
I
H
A
request
to
ayana
right
and
the
deployment
draft
was
more
like
something
yeah.
We
could
go,
keep
it
informational
and
originally
we
just
supplied
it
as
something
that
is
as
an
fyi,
so
that
people
understand
really
how
it's
been
used.
H
What
we
see
right
now
it
it
might
there
might
be
a
benefit
to
provide
for
longevity
so
that
it
stays.
So
I'm
fine
either
way
we
can
go
and
fold.
I
H
We
can
make
it
a
longer
document
or
we
can
go
and
have
it
as
a
separate
document.
I
think
that
and
it
just
there
is
merit
to
go
and
keep
it.
A
Yeah,
I
mean
particularly
the
paragraph
that
you're
referring
to
if
it
is,
if
it
was
originally
brought
up
as
a
concern
in
the
kind
of
the
standards
track
document
of
saying,
we
need
to
make
sure
that
this
is
contained
if
our
replacement,
for
that
is
saying,
oh,
we
do
have
a
containment
mechanism.
I
I
feel
like
that
should
be
part
of
the
standards
track
document
and
it's
totally
fine
to
have
a
section
in
your
document
that
is
here
is
an
informational
example
about
how
to
do
this,
but
still
have
a
normative
requirement.
G
Can
I
hear
me
yes,
okay,
so
I
just
want
to
let's
always
aware
that
later
we
will
have
a
short
talk
and
actually
relate
to
this
draft,
and
in
that
top
we
particularly
concern
about
buffer
passing
buffer
issue
and
suggest
some
alternatives
to
avoid
the
big
overhead
introduced
by
the
potentially
large
iom
data
in
the
hvac
option
header.
So
we
think
that's
a
potential
issue
faced
by
this
drop.
A
All
right
do
we
have
any
other
opinions
from
the
group
on
the
status
of
kind
of
including
the
the
the
deployment
considerations.
Can
we
get.
H
H
It
adopt
it
as
a
separate
one
right
so
that
decouples
the
getting
the
option,
definition
relatively
quickly
and
kind
of
flashing
out
the
deployment
in
in
greater
level
of
detail.
Maybe
that's
something
that
how
are
you
was
referring
to
right,
because
I
think
the
there
is
benefit
of
having
the
the
numbers
stable.
A
A
So
if
everyone
knows
the
hum
tab
is
their
little
graph
bars
over
on
the
left.
So
I
think
we
have
a
couple
different
options
here.
A
A
Second,
if
people
don't
want
to
do
that,
would
they
want
to
adopt
it
as
a
separate
document
and
then
third
do
they
not
want
to
at
all?
So
I
guess
I'll
start
a
hum
now
and
please
go
over
to
the
hum
tab
and
hum
softly
or
loudly.
If
you
believe
that
we
should
incorporate
the
v6
deployment
considerations
into
the
v6
options
document
to
clarify
scope
of
how
these
options
can
stay
within
a
domain.
A
A
Got
a
piano,
okay,
so
quiet
and
comments
on
jabber:
let's
do
a
the
second
home
for
do.
We
want
to
consider
adopting
the
v6
deployments
separately,
I'll
start
that.
A
H
A
Yeah
next
time
we
need
to
make
these
hums
faster,
be
an
easy
now.
Okay,
so
it
sounds
like
we
have
overall
feeling
that
we
want
to
put
something
of
this
in.
It
seems
like
the
group
doesn't
really
care
if
it
goes
in
the
same
document
or
not,
so
I
think
we
will
talk
with
rad
about
what
we
prefer.
Personally,
I
would
lean
to
heaven
to
be
in
the
same
document,
and
we
will
move
forward
from.
There
sounds
good.
D
I
think
it
might
be
worthwhile
to
see
if
there
are
any
strong
objections
in
any
of
those
camps
or
if
it
really
is
just
people
are
mild
preferences
for
one
or
the
other.
A
Yes,
that's
a
good
point
if
anyone
does
have
any
strong
feelings,
one
way
or
the
other,
please
speak
up
or
write
that
in
jabber
interest
of
time,
I'll
let
tal
in
all
right.
Thank
you,
frank.
K
K
So
a
short
update
in
version
zero,
one
which
we
actually
discussed
in
the
previous
ippm
meeting.
K
The
main
change
we
applied
back
then,
was
to
change
the
security
considerations
and
specifically,
we
discussed
the
amplification
attacks
and
I
think
the
general
feedback
we
received
back
in
that
ippm
meeting
a
few
months
ago
was
pretty
positive
and
a
couple
of
people
said
they
were
still.
They
still
wanted
to
review
it
again,
but
I
think
we
can
expect
probably
to
get
some
more
comments
in
working
with
last
call,
but
at
this
point
it
seems
to
be
pretty
stable
at
this.
At
least
from
this
perspective,.
K
K
K
Generally
speaking,
if
anyone
has
any
thoughts
about
that
would
be
happy
to
hear
either
right
now
or
on
the
mailing
list,
and
I
think
anyway,
we
want
to
resolve
this
issue,
so
we'll
probably
continue
the
discussion
on
the
mailing
list,
hopefully
to
resolve
this
soon.
A
A
E
Thank
you.
I
have
a
question
about
and
I
don't
think
that
we
have
discussed
it
earlier
before
on
active
flag.
E
So
we
we
do
have
a
set
of
active
oem
protocols
for
performance
monitoring
defect
detection.
So
what
you
see
is
the
benefit
of
creating
this
flag
in
iam,
rather
than
if
there
is
a
need
to
include
iem
header
into
existing
protocols.
K
Yeah,
so
I
believe
actually,
this
question
was
raised
before
and
there
is
a
specific
section
in
the
in
the
draft
that
was
meant
to
address
this
question.
So
there
there's
a
section
about
use
cases
where
the
active
flag
is
used,
and
that
section
describes,
I
think,
two
use
cases.
If
I
remember
correctly,
one
of
them
was
basically
like
you
said
when
you
use
active
protocols
which
are
not
defined
in
this
context,
you
may
want
to
also
include
an
iom
header
and
to
have
ion
nodes
along
the
path,
push
their
iom
data.
K
That
was
one
use
case.
Another
use
case
was
basically
the
scenario
that
we
called
the
cloning
or
application,
where,
basically,
you
have
data
packets
which
are
forwarded
along
the
path
and
then
there's
the
iom,
encapsulating
node,
which
may
replicate
some
some
or
all
of
the
packets
and
the
replica.
The
copy
of
the
packet
includes
the
active
flag
and
again
that
replica
follows
the
same
path:
has
the
ion
data
pushed
into
it?
K
E
Again,
I
have
a
concern
similar
to
what
we
had
the
discussion
with
the
lube
bank,
because
the
security
implications,
especially
if
there
is
a
replication
and
creation
of
like
multiple
shadow
copies
of
the
data
flow.
Yes
it
it
is
very
tempting
to
use
it
as
a.
K
Right
and
and
again
this
goes
back
to
the
amplification
attack
and,
and
also
this
is
addressed
in
the
document.
So
again,
when
we
discuss
the
amplification
attack,
we
address
both
the
lubeck
flag
and
the
active
flag,
and
I
believe
the
text
right
now
at
least
analyzes
that
aspect
and
proposes
mitigation
methods.
E
A
Yeah,
I
think
in
general,
I'd
like
to
see
more
reviews
from
the
people
who
have
concerns
about
this,
because
I
think
they're
important
to
address
before
we
move
this
further.
Looking
at
the
notes
from
last
time,
I
think
it
sounded
like
martin,
duke
and
brian
trammell
had
offered
to
kind
of
review
this
more.
I
haven't
seen
activity
on
the
list,
so
I
guess
I
would
ask
them
again
to
kind
of
give
consideration
to
this
another
option.
L
L
Yeah
I
would
like
to
actually
do
that
too.
I
would
like
to
have
a
chance
to
do
that
review
before
we
send
it
in
for
early
early
security,
because
I
think
yeah
for
for
for
obvious
reasons
I
don't
want
to
sit.
I
don't
want
to
get
killed
in
the
early
security
review.
L
L
The
I
just
haven't
had
a
chance
to
look
at
it
since,
since
april,
I
haven't
actually
paid
any
attention
to
ippm
since
the
last
meeting,
and
I
do
need
to
pick
this
back
up.
So
thank
you
for
the
reminder.
I
will
try
and
get
that
done
in
the
next
couple
of
weeks
and
we'll
challenge
martin
to
do
the
same,
so
we
can
move
forward
on
this
perfect.
Thank
you.
Both.
A
Okay,
let's
quickly
talk
about
direct
export,
I
think
it's
in
a
relatively
similar
boat.
So
if
we
can
make
this
quick
right,
okay.
K
So
next
slide
please
so
again.
This
is.
This
draft
combines
two
different
concepts
which
originally
were
defined
in
two
different
documents,
and
I
think
most
of
the
draft
is
pretty
stable.
There
is
one
pending
open
issue
which
we
discussed
in
the
previous
ippm
meetings
and
also
on
the
mailing
list,
also
in
the
design
team
meetings,
and
so
far
we
haven't
been
able
to
resolve
this.
Actually,
there
are
two
opinions
around
this
next
slide.
Please.
K
So
just
a
reminder:
we're
talking
about
the
question
whether
we
want
in
the
iom,
direct
exporting
header,
whether
we
want
to
include
an
explicit
hop
count
field
or
not,
and
if,
if
we're
talking
about
not
what
we
mean
is
that
we
can
use
the
hop
limit,
node
id
data
field,
which
is
already
defined
in
the
ion
data
draft,
and
that
can
be
used
as
an
alternative.
K
Now,
of
course,
each
of
these
two
possibilities
has
its
pros
and
cons,
and
these
pros
and
cons
have
been
discussed
thoroughly
on
the
mailing
list
and
actually
there's
a
section
in
the
draft
right
now
which
discusses
the
pros
and
cons
of
each
of
these
alternatives,
and
we
heard
the
the
same
opinions
over
and
over.
So
I
think,
if,
if
people
who
are
non-authors
would
like
to
express
their
opinions
about
this,
that
would
be
great.
K
We
would
love
to
hear
from
other
people
who
are,
you
know,
not
authors
and
also
any
suggestion
from
the
working
group
chairs
about
how
to
resolve.
This
would
also
help.
A
All
right
sounds
good.
First,
I
guess:
is
there
anyone
else
in
the
working
group
who
who's
not
an
author?
Who
would
like
to
comment
on
this?
There
was
a
thread
on
the
list
about
this.
In
may,.
H
A
A
G
Also,
I
just
want
to
quickly
point
out
that,
in
addition
to
the
yes
or
no
and
there's
a
third
option
to
make
this
field
actually
optional,
that's
also
discussed
in
the
us.
The
design
group.
B
B
G
M
M
M
So
we
introduced
the
delay,
beat
second
marking
packets
inside
the
one
market,
one
double
market
packets
inside
each
spin
bit
period
in
order
to
have
a
precise
point
of
measurement.
If
there
is
the
double
market
packet,
the
delay
beat
the
market
packet.
We
have
a
precise
measurement
if
there
isn't,
if
this
packet
is
lost
or
if
this
price
is
not
created
because
there
isn't
real
traffic.
In
this
moment
we
have
an
approximate
measurement
using
only
the
spin
bit
next
slide.
M
M
This
is
a
plane
of
packets
between
client
and
server.
In
this
way,
we
have
an
intermediate
server,
can
see
one
packet,
a
complete
packet
round
of
the
train,
so
comparing
the
two
numbers
that
he
measured
on
this
train
the
first
time
and
the
second
time
of
the
round
he
can
it
can
measure
the
packet
loss
between
a
round
trip,
maintain
the
train,
the
two
train
with
the
same
speed.
If
the
speed
of
the
the
number
of
packets
in
the
two
direction,
the
speed
of
the
pack
is
different.
M
M
M
M
This
is
an
example:
if
we
have
50
percent
of
pacquiao
rate
in
download
respect
upload,
we
can
have
a
four
square
wave
of
64
bits
in
the
upload
side,
only
two
square
wave
of
62,
because
it's
the
average
between
61
and
63
that
arrived
to
the
to
then
point
and
63
that
is
average
from
6163
from
the
other
side.
M
So
if
the
this
is
the
opposite
situation
with
the
alpha
packer
rate
upload
the
50
percent
of
packet
right
of
download,
we
can
replay
the
square
waves,
so
square
wave
cam
became
a
263
square
by
this
song.
It
works
not
only
for
for
integer
square
wave,
but
only,
but
also
for
fractionary
square
waves,
because
we
keep
the
rest
and
we
insert
in
the
next
square
waves.
There
is
a
method
next
slide,
please,
okay,
when
this
is
the
algorithm
that
we
tested
in
two
academs
and
it
works
when
the
transmission,
the
new
airblocks
starts.
M
The
size
of
this
square
square
block
is
set
equal
to
the
size
of
the
last
market
period,
whose
reception
has
been
completed.
If,
during
the
transmission,
the
air
block
is
terminated.
The
reception
of
the
last
one
further
cool
market
period
is
completed.
The
size
of
the
air
blocks
is
updated
to
the
average
size
of
the
farther
received
to
market
periods.
So
is
a,
let
me
say,
a
sliding
average.
M
It
is
freezing
when
the
the
reflected
block
is
terminated,
it
works
they.
The
ongoing
properties,
are
quite
interesting.
It
works
in
both
cases
when
the
reflection
packet
number
is
greater
than
there
is
received,
and
when
the
reflected
package
number
is
lower
and
all
traffic
is
measured.
All
the
production
traffic
has
both
the
kubit
and
the
rbit
market
differ
in
is
a
different
between
the
previous
method
that
use
only
one
bit
that
not
all
the
packets
are
market
for
the
measurement
next
slide.
M
Okay,
so
a
one
direction
server
can
subtract
the
packet
loss,
measured
using
the
kubit
to
the
packet
loss,
measured
using
the
air
bit.
M
M
M
M
If
we
privilege
the
option
to
the
measurement
of
the
packet
loss,
we
have
only
the
spin
beat
for
the
measurement
of
retreat
type
and
two
bit
for
the
one-way
packet
loss
they
could
beat
and
are
beating
our
proposal
next
slide.
M
M
Explicit
measurement
only
work
if
both
client
and
server
mark
the
production
traffic,
and
it's
not
so
frequent
in
quick
protocol
implementation
till
now,
another
problem
in
the
scalability
network
probes
could
monitor
all
the
connections
is
quite
difficult
in
intermediate
points
of
the
network,
where
there
are
a
lot
of
connection
paras
millions
of
connections
if
they
can
to
which
one
to
choose
which
connection
to
choose
to
monitor
and
how
to
monitor
both
the
traffic
direction,
if
not
always
possible
for
network
probes
in
case
of
a
symmetric
connection,
how
to
answer
to
this
operation?
The
next
slide.
M
The
idea
is
to
put
the
special
performance
of
server
also
on
the
user
device-
mobile
phones,
pc.
There
are
some
answers
to
the
previous
issue:
less
less
capability
on
the
user
device.
There
are
few
connections
to
monitor,
which
connection
to
monitor
the
ones
that
have
problems.
User
device
and
network
probes
can
be
coordinated.
M
Okay,
the
device
owner
activates
specific
performance
monitoring.
This
idea,
the
decision
whether
to
activate
depends
from
the
device
owner
he
can
configure
the
application
browser
based
on
client
server
protocols
that
support
the
species
measurement.
All
applications
should
provide
for
activation
and
activation
fact
marking
providing
a
user
interface
or
exposing
apa.
M
The
problem
is
who
will
see
the
performance
data,
the
performance
information
displayed
on
the
device
if
the
owner
of
the
device
decide
to
mark
and
possibly
send
to
external
body?
If
the
owner
agrees,
the
main
recipient
would
be
the
internet
service
provider,
see
user
device
network
coordination
point,
but
this
data
could
also
be
of
interest
by
the
national
regulatory
authorities
or
other
authorized
subjects.
M
M
Implementation
there
are
some
implementations
shown
in
many
accounts,
and
the
thread
on
the
ppm
and
quick
mailing
list
are
quite
interesting,
so
it's
possible
to
evaluate
the
future
working
group
adoption
the
document
on
the
basis
to
give
it
a
place
and
welcome
questions
and
comments,
especially
on
the
last
part
that
are
quite
new
and
quite
tricky.
I
think
thank
you.
C
Thank
you
yeah.
Thank
you
I,
this
is
ian.
C
I
wanted
to
add
one
note
just
because
tommy
and
I
talked
about
this
draft-
and
you
know
this
type
of
measurement
in
general-
that
this
working
group
is
definitely
not
in
in
charge
of
allocating
any
bits
in
in
click
in
any
way,
shape
or
form,
and
so
you
know
any
draft
that
got
accepted,
I
think,
would
have
to
only
you
know
reference
things
like
quick
as
a
a
potential
substrate
on
which
you
could
you
could
do
this
sort
of
measurement
with
these
mechanisms
and
not
not
rely
on
it,
so
that
probably
probably
most
people
understood
that,
but
I
just
want
to
make
sure
we're
everyone's
clear.
N
Queue,
can
you
hear
me.
N
Thank
you
very
much
for
bringing
this
work
to
the
working
group.
I
think
lost
measurement,
and
anybody
who's
heard
me
before
is
I'm
all
for
it,
and
just
for
people
in
this
working
group
who
are
not
frequent
in
tspwg
or
in
quick.
Basically
just
want
to
point
out
that
we've
also
had
another
draft
on
lost
bits
presented
in
tspwg
and
then
quick
that
uses
similar
step
functions
of
the
qubit,
and
we
use
a
different
mechanism
for
end
to
end
loss
reporting
where
basically,
it
doesn't
require
bi-directional
observation.
N
It's
all
unidirectional.
It's
also
both
endpoints
must
agree
to
it
and
it
doesn't
suffer
from
possible
limitations
in
terms
of
like
possibly
ten
to
one
difference
in
uplink
and
downlink
packet
rates.
N
So
that's
just
fi,
and
if
there
is
interest
in
the
working
group,
I'm
happy
next
time
to
present
our
draft,
although
it's
possible
that
we're
gonna
meet
with
the
current
authors
and
maybe
have
something
out
together
as
well,
but
my
main
thing
was
to
just
point
out
the
people
who
are
interested
in
this
read:
tsvwg
or
quick
loss.
Bitstraft.
N
A
A
A
Essentially,
just
asking
if
we
would
be
able
to
have
one
document,
potentially
as
a
collaboration
between
the
authors
of
the
two
different
approaches,
the
one
that
was
proposing
quick,
at
least
for
the
the
mechanism
of
measurement
and
be
able
to
have
that
be
the
basis
of
something
that
we
can
adopt.
Ippm.
M
Okay,
yes,
there
are
in
this
document.
There
are
many
kind
of
measurement.
We
can
add
another
one.
It's
not
a
problem.
The
difference
is
is
only
about
the
use
of
a
one
bit.
We
use
the
reflection
bit
that
reflects
the
square
bit
and
igor
draft
uses.
The
l
bit
that
export
remission
export
an
internal
variable
that
counts
the
packet
loss.
M
D
Thanks
for
for
doing
this,
I
plus
one
what
ian
said
about
what
the
scope
should
be
of
any
document
we
do
in
ippm,
but
I
would
like
you
and
people
working
on
this
draft
to
to
think
through
the
privacy
implications
very
carefully.
I
think
this
could
easily
run
aground
in
an
ietf
last
call
or
isu
review
in
this
sort
of
unrecoverable
way.
If
we
don't
get
this
right,
the
idea
of
user,
you
know
explicit
user
consent
is,
is
meaningful.
D
User
consent
is,
is
often
a
very
difficult
thing
to
have
and
defaults
matter
a
lot,
and
if
the
model
here
is
that
you
know,
I
call
the
support
line
and
I
turn
it
on,
and
otherwise
it's
always
off.
That's
one
thing:
if
it's
you
know
browsers
are
going
to
decide
on
behalf
of
users.
That's
another
thing
and
I
I
I'm
actually
advocating
for
a
particular
position
here,
but
it's
something
we
should
really
tread
carefully
and
maybe
get
some
outside
review
outside
the
measurement
community,
which
has
particular
biases
thanks.
A
Great
yeah,
I
think
that's
one
thing
that
I
don't
see
addressed
in
the
draft
as
it
is,
and
I
think,
there's
room
to
potentially
adopt
this
work
before
then.
But
any
document
that
we
would
have
is
a
working
group
document.
We
need
a
significant
privacy,
section,
okay
fabio.
I
Hello,
everyone,
okay
mauro,
mostly
answered
to
what
I
I
was
going
to
say.
I
agree
for
collaboration
with
orange
guys
just
to
find
a
solution
that
can
be
good
for
everyone
and
about
the
orange
one.
Implementation
of
the,
albeit
as
mauro
said
before
the
beat-
depends
on
the
variable
and
events
inside
the
protocol.
I
Our
solution
instead
is
detached
from
the
from
the
protocol,
so
it
can
be
applied
to
free
protocol.
It
can
be
applied
to
tcp,
for
example,
it
can
be
applied
to
any
connection
oriented
protocol.
So
this,
I
think,
is
an
advantage,
but
I
agree,
I
totally
agree
with
the
collaboration
with
the
with
the
other
draft
guys
yeah.
Okay,
thank
you.
Thank.
O
And
then,
since
it's
a
generalization
of
methodology.
It
makes
sense-
and
it's
just
to
mention
a
use
case
when
we
have
a
good
result.
And
then
we
are
now
applying
this
methodology
to
ipv6
and
so
on.
And
we
can
do
the
same.
So
we
can
define
the
general
methodology
and
you
can
then
go
to
cook
and
certificate
and
apply.
O
A
Okay,
so
it
looks
like
we
don't
have
more
questions
in
the
queue
we
should
probably
move
on
for
time.
I
think
we
have
some
good
next
steps
here.
A
J
Me
hi
everyone.
This
is
lakis
gandhi
from
cisco
systems,
presenting
the
draft
and
pm
using
a
stamp
a
simple
two-way
measurement
protocol
for
segment
routing
networks.
On
behalf
of
the
authors
listed.
So
there
is
a
companion
draft
as
well
for
the
t1
light
as
well.
J
J
J
So
the
requirement
is
the
delay
and
loss
p.m
for
links
and
end-to-end
sr
parts
links
can
be
physical,
virtual
bundles
bundle,
members,
it's
applicable
to
srm
pls
or
service
six
data
planes
handle
the
cmp
for
sr
parts
and
also
the
standalone
direct
mode
loss
measurement
for
measuring
actual
customer
data
traffic
loss.
The
scope
for
this
draft
is
a
stamp
rfc
8762,
as
well
as
the
stem
tlvs,
take
advantage
of
the
great
work
done
in
the
ippm
working
group.
J
J
J
It
has
the
draft
had
the
t1
plight
as
well
as
stamp
from
the
beginning,
and
it
was
agreed
with
spring
and
ippm
working
group
to
progress.
This
work
in
the
spring
working
group,
but
just
we've
been
asked
to
keep
the
ipbn
working
group
in
the
loop,
because
there
is
a
lot
of
base
work
being
done
in
ippm
working
group,
especially
lately
stamp
dlvs
next
slide.
Please.
J
J
We
have
updated
the
return
path.
Tlv
to
now
include
the
written
address.
We
also
define
another
tlb
for
destination
address.
There
is
a
minor
registry
cleanup
and
editorial
changes
we
as
as
we
went
through
previously.
There
is
some
updates
to
the
stem
tlv
draft,
so
we
will
align
with
that
latest
updates
as
next
step
for
this
next
slide.
Please.
J
So
we
had
a
pretty
good
discussion
on
the
mailing
list
where
to
put
the
control
code
and
many
thanks
to
greg
and
others
who
are
contributed
to
the
discussions
on
the
ippm
mailing
list.
So
we
have
defined
a
control
code
field
in
the
stamp
packet
at
this
location
and
it
is
used
if
you
want
to
get
the
response
out
of
band
or
in-band
in-band
is
used
for
the
two-way
measurement
for
the
bi-directional
channel.
J
So
our
written
path
here
we
we
are
added
another
subtle
to
include
the
return
address
as
well.
It
contained
previously
the
srm
pls
label
stack
or
binding
sheet.
J
As
same
for
the
srv6,
next
slide,
please.
So
there
are
two
modes:
there
is
a
one-way
measurement
mode.
We
call
it
where
reply
can
be
sent
out-of-band.
You
know
on
default,
ip-udp
path
and
in
two-way
measurement
mode
replies
an
inband
using
the
control
code
that
we
have
defined,
and
it
can
also
use
the
written
path
tlv
to
send
a
reply
on
a
specific
reverse
path,
could
be
a
srm
pls
label
stack
or
binding
sheet,
as
mentioned
in
the
previous
slide,
and
next
slide.
Please.
J
So
we
have
defined
a
node
address
tlv
for
stamp
and
it
can
contain
the
destination
node
address,
and
this
is
useful
for
segment
routing
path
where
destination
can
be
127.8
loopback
address,
so
it's
important
that
node
is
the
the
probe
is
processed
by
the
right
node.
So
we
have
defined
this
tlb
to
identify
the
intended
node
next
slide.
J
J
The
draft
also
define
defines
a
standalone
lm
message
for
stamp.
There
is
a
corresponding
message,
also
for
t1
lite,
as
well
defined
in
the
sibling
draft,
and
it
is
it's
it's
there
for
efficient
hardware,
counter,
stamping
with
well-known
locations
for
the
traffic
counters.
This
is
the
actual
data
traffic
counters
carried
in
the
probe
messages.
It
uses
a
separate
udp
port,
so
there
is
no
real
interest
intersection
with
existing
procedure
in
the
stamp
or
t1
applied
for
the
delay
measurement.
J
So
this
is
really
an
extension
next
slide,
please
so
it's
an
example:
provisioning
model,
it's
very
similar
to
what's
there
in
the
stamp
rfc.
What
the
the
what's
new
here
is
your
measurement
mode,
one
way
or
two
may
or
you
have
lost
measurement
more,
which
is
not
defined
as
a
direct
mode.
J
This
draft
or
the
delay
or
loss
measurement
modes,
and
which
udp
port
belongs
to
which
type
and
all
that
it's
it's
part
of
the
provisioning
model,
recall
that
there
is
no
signaling
either
in
the
light
or
the
stamp
next
slide.
Please.
J
J
There
are
separate
ports
used
for
delay
and
loss,
as
mentioned
it's
basically
the
same
idea
for
the
stamp
as
well
as
you
applied,
and
the
payload
is
slightly
different.
That's
all
next
slide,
please
for
srm
pls
again,
the
pro
pro
packets
are
pre-route
or
routed
over
their
mpls
or
srv6
policy
path,
and
they
used
either
mpls
label
stack
or
srv6
segment
list
for
that
policy,
but
they
follow
along
the
path
of
the
policy,
so
they
are
routed
on
a
specific
part.
J
And
the
response,
as
mentioned
before
it
can
be
just
ip
udp
or
it
can
be
using
the
control
code
or
written
party
lv
to
follow
a
specific
path
of
just
an
ip
path.
Next
slide,
please.
J
Sr
path
has
acmp,
as
mentioned
so
destination
address
can
be
127.8,
which
is
used
to
sweep
to
traverse
all
the
cmp
parts
in
case
of
ipv4
and
for
ipv6
in
a
probe
would
speed,
sweep
the
flow
label
values
in
the
ipv6
header
next
slide.
Please.
J
So
we
welcome
your
comments
and
suggestions,
so
there
is
this
draft
first
using
stamp.
Payload
is
a
companion
for
t1,
lite
and
both
drafts.
I
think
we
have
presented
it
last
year
and
it
was
presented
again
in
the
spring
this
week,
so
we
do
have
implementation.
We
have
asked
for
spring
working
group
adoption
and
we
would
keep
the
ippm
working
group
in
the
in
the
loop
for
milestones
and
many
thanks
to
the
ippm
working
members
and
the
chairs
for
the
opportunity
to
be
part
of
this.
Thank
you
any
comments,
suggestions.
E
J
So
it's
it's
a
particular
it's.
It
will
not
change
for
a
session,
so
you
have
a
session
that
session
could
be
a
one-way
or
two-way,
and
it
would
not
change
for
packet
to
make
it
for
that
session.
E
Thank
you
so
then,
looking
at
the
model
that
you
use
so
using
the
centralized
controller
to
provision
sender
and
reflector,
wouldn't
it
make
sense
that
provisioning
of
a
return
path,
the
mode
of
reflector
to
send
reflected
packet
back
to
to
the
sender,
will
be
part
of
the
data
model.
J
So
the
in
segment
routing
the
it's
a
stateless
on
the
reflector,
so
there
is
no
state
reflector
is
basically
just
responding
to
the
packet
received,
so
it
has.
There
is
no
state
and
there
is
no
segment
list
there.
No
bindings.
There
is
nothing
there
to
so.
It
just
uses
the
information
from
the
packet
to
reflect
the
packet
back.
E
But
that's
only
one
case:
why
why
it's
on
this
case?
Because
again,
if
we
look
at,
for
example,
stamp,
the
reflector
stampwise
could
be
stateful
or
stateless,
you
assume
only
one
mode
that
you
cannot
associate
return
path,
label
stack
or
srh
for
service
six
on
the
reflector,
with
the
specific
session
stamp
session
id
and
the
source
and
send
their
identity.
E
I
think
that
makes
it
easier
and
I
do
have
a
concern
of
updating
their
stamp
base
format
for
the
type.
If
you
want
to
communicate
this
with
a
test
packet
and
you're
already
sending
it
in
tov,
why
not
to
include
it
into
tob
itself
so
to
how
to
interpret
it
on
the
reflector.
J
Yeah,
so
the
to
answer
the
first
one.
This
is
the
stateless
model
so
sr.
You
know
there
is
no
state,
that's
how
the
segment
routing
extensions
are
used
that
you
you
avoid
having
states
on
the
on
the
other
side.
So
this
the
information
is
carried.
The
state
is
carried
in
the
packet
itself,
so
this
is
the
the
way
segment
routing
is
designed.
J
So
this
is
the
reason
why
the
information
is
there
in
the
packet
itself,
label
stack
can
change
on
the
on
the
imposition
side
and
reflector
would
have
no.
There
is
no
signaling
to
in
segment
routing
to
go
back
and
forth,
like
you
would
have
in
rsvp,
so
the
state
is
always
in
the
packet
itself.
J
So
this
is
why
you'll
see
that
there's
a
written
party
lv-
and
there
is
a
it-
expect
that
you
send
me
information
this
certain
way
and
to
I
mean
if
there
is
a
stateful
mode
in
in
non-segment
routing
networks,
then
it's
fine
to
use.
You
know
provisioning
or
maybe
some
external
signaling
mechanism.
E
J
No,
the
the
it's
the
same
session
and
the
path
can
change
and
it
will
be
stored
in
this
assassin
state
at
the
ingress,
node
and
yeah
path
can
change
it.
It
doesn't.
We
don't
want
to
impose
a
new
session,
stop
the
existing
assassin
and
start
a
new
session,
because
you
know
a
reverse
path
has
changed
so
in
the
interest.
A
Of
time,
I
don't
want
to
have
this
go
on
too
long,
because
I
think
this
is
an
important
conversation.
Could
we
take
this
to
the
list?
I
don't
know
if
greg
you
want
to
just
shoot
in
no,
no,
no,
of
course,
yeah.
Let's
continue
in
the
list
all
right.
Thank
you
thanks.
Thanks
for
bringing
up
this
conversation,.
A
So
we
are
now
done
with
our
official
agenda
time
we're
into
lightning
talks.
These
are
five
minutes
each.
We
have
time
for
four
of
these,
so
apologies
to
the
people
who
we
will
not
be
able
to
get
to,
but
please
do
bring
up
your
drafts
for
discussion
on
the
list.
P
G
Yes,
oh
okay,
so
many
about
concern
for
the
overhead
issue
when
applying
i186
and
we
suggest
several
potential
solutions
accordingly.
Next
slides,
please.
G
So
the
key
issue
here
is
on
because
the
iom
truth
mode
needs
to
perform
processing.
Then
it
must
be
kept
in
the
ipv6
callback
option.
Extension
header,
but
hbh
extension
header-
must
also
be
the
first
extension
header
in
ipv6.
G
So
there
are
two
issues
about
this
applying
iom
twist
mode
in
hbh
extension
header.
The
first
issue
is
about
the
the
header
can
be
very
large,
so
each
node
can
accumulate
a
dozen
power
five
of
data
and
consider
the
number
of
pops
the
the
the
potential
overhead
can
exceed.
The
you
know.
The
the
sun
can
be
very
large
in
remember,
and
also
a
more
important
issue
about.
G
It
is
that
in
the
incremental
mode,
each
node
will
add
some
more
data
to
make
this
size
changeable,
which
means
if
some
other
headers
need
to
be
processed,
and
then
its
position
is
floating
it's
floating,
so
you
can
not
easily
pass
it.
So
it
is,
is
this
either
prohibited,
as
pointed
by
tom
or
even
if
possible,
then
it
will
make
the
package
processing
much
harder.
G
So
we
have
several
workarounds
about
it.
The
first
is
when
in
doubt,
or
we
cannot
afford
the
overhead
we
might
just
avoid
using
it
at
all
and
or
in
some
special
case,
like
the
in
the
srv6
mode
mode.
We
can
apply
the
iom
on
the
as
a
srh
option.
So
then,
which
means
we
will
only
apply
iom
on
the
srv6
nodes,
but
note
all
the
ipv6
nodes,
but
those
solutions
are
apparently
not
ideal,
because
in
many
cases
we
do
need
iom
to
cover
all
the
ipv6
nodes.
Next
slightly,
so
we
have
several
possible
solutions.
G
The
first
one
is,
we
can
separate
iom
data
instruction
part
and
the
data
part,
so
we
still
keep
the
fixed
size.
Iom
instruction
header
in
the
hbf
hbh
extent
header,
but
we
postpose
the
iom
data
in
some
in.
I
G
Extension
header
after
the
routing
header
in
this
way
the
hph
is
small
and
its
size
is
also
fixed,
but
the
problem
is
where
we
will
put
the
data.
We
shall
we
introduce
some
new
extension
header
or
put
it
in
some
tlv
field
in
some
existing
snatch
head.
So
there's
a
problem
about
it,
so
the
second
potential
solution
is
use
the
concept
of
the
segment
iom
export
we
proposed
before
in
another
draft.
G
So
for
there
are
two
variations
about
this,
the
first
we
can
just
fix
the
number
of
hops.
We
will
accumulate
the
iom
data
and
whenever
we
reach
that
fixed
number
of
hops,
we
just
export
the
data
out.
Then
we
can
make
room
for
the
following
nodes
to
continue
to
collect
the
iom
data.
A
second
approach
is
applied
for
the
srv6,
specifically.
G
For
example,
when
whenever
we
reach
a
services
node,
we
need
to
handle
the
routing
header,
we
just
export
the
iom
data.
First
then
now
the
the
hph
header
only
includes
iom
instruction
part,
so
if
size
is
also
fixed,
so
this
makes
easier
to
access
the
later
extension
headers.
So
the
third
option
is
use
iom
direct
export
mode
so
which
means
basically
every
every
hub
will
directly
export
data
so
without
needing
to
accumulate
the
iom
data
in
the
package,
so
that
can
also
keep
the
header
small
next
slide.
G
So,
basically,
in
this
slides,
we
list
the
current
proposed
solution,
which
is
just
that
puts
the
iom
truth
option
header
entirely
in
the
hbh
exchange
header
and
the
other
four
alternatives
to
be
proposed
in
these
jobs.
So
each
of
them
has
its
own
pros
and
cons.
It's
all
summarized
in
this
in
the
table
and
for
the
time
stick
I
will
not
repeat
it
and
also,
if
you
are
interested,
you
can
look
at
our
trust
for
details.
A
In
five
minutes
yep,
so
yeah
yeah
do.
P
P
We
have
evolved
several
versions
to
align
with
the
latest
iom
data
draft
and
the
iom
directory
export
draft,
and
the
latest
version
corrected
the
admin
type
things
as
suggested
by
tom
in
the
mailing
list,
including
the
reference
copyrights,
three
diagrams
and
the
correct
reference
to
the
approval
of
transits
and
so
on.
And
next.
P
And
the
model
structure
is
like
this:
the
model
is
organized
as
a
list
of
profiles,
as
suggested
by
the
working
group.
Each
profile
container
is
enabled
by
the
by
the
corresponding
features,
so
the
device
do
not
need
to
support
all
the
features
each
profile
associates
with
one
flow
and
the
corresponding
ion
information.
P
P
P
P
The
iom
edge
to
edge
option
is
to
carry
the
data
that
is
added
by
the
iom,
encapsulated
node
and
the
and
the
re
interpreted
by
the
iron
encapsulating
node
next
yeah.
That's
that's
the
i1
model,
as
the
ion
data
draft
is
getting
mature
and
stable.
A
You
get
a
whole
minute
back
any
comments
on
this
one.
Any
of
the
other
iom.
Authors
want
to
comment.
H
Yeah,
maybe
quickly,
I
think
this
is
now
looming
in
the
back
for
a
while.
I
think
we
need
something
config,
no
matter
what,
and
I
think
that
could
be
a
good
candidate,
it's
in
progressing
in
lockstep
with
a
data
draft,
given
that
the
data
draft
is
pretty
mature
by
now,
as
we
heard
from
martin
early
on,
how
would
we
you
suggest,
to
go
and
move
this
forward?
Should
we
go
and
continue
to
progress
this
as
an
individual
one
for
now
or
when?
A
I
mean
since
we're
since
we're
pretty
mature
on
the
data
draft.
I
think
we
could
look
at
doing
this
earlier
and
just
kind
of
keep
it
in
the
working
group
and
keep
updating
it,
but
that
would
seem
reasonable.
A
H
Q
Okay,
so
well
hello,
everyone,
leslie
from
huawei
and
the
list
of
we
defined
optional
theories,
which
can
be
carried
in
stamped
test
packet
to
to
measure
the
the
performance
data
at
every
intermediate
node
that
step
test
packet
travels.
Q
So
let's
look
at
background
and
the
requirement
so,
as
we'll
know,
the
stem
can
matter
the
one
way
and
around
three
performance,
but
we
we
can
see
that
the
the
performance
of
intermediate
knows
that
travels.
Q
The
the
paths
are
invisible
and,
on
the
other
hand,
we
we
want
to
try
to
measure
the
intermediate
nodes
performance
that
we
need
to
configure
the
stem
instance
at
every
intermediate
node.
So
let's
lead
to
the
complex
of
the
oem
in
in
such
a
large
scale
network.
So,
let's
address
we
try
to
define
optional
tailways
to
to
to
realize
the
and
performance
measurements
at
every
intermediate
node.
So
so,
as
we
list
here,
the
first
tier
is
the
iom
tracing
data
theory.
Q
So,
let's
tell
we,
we
defined
that
as
a
test
pack
can
carry
less
to
v2
to
to
actually
the
performance
measurements
as
defined
the
iom,
data
fields
in
and
the
second
one
is
the
second
one
and
the
third
one
is
the
for
worry
and
the
backward
hope.
Q
I
hope
the
late
theo
is
so
these
two
is
we
try
to
measure
the
the
delay
by
upper
hub
along
this
path,
so
this
this
three
tier
vis,
we
we
define
here
as
we
we
want
to
add
the
update
of
the
stamp
theory
extension
draft
next,
please.
Q
So
so
the
important
thing
or
we're
saying
is
the
length
we
we
need
to
predefined
because
as
we
as
we
know,
because
the
step
I
use
a
symmetric
packet,
so
we
need
to
set
the
value
of
the
length
depends
on
the
number
of
nodes
and
and
the
rm
bitmap.
Q
We
see
it
in
the
the
iom
header.
So
this
is
the
lens
when
we
need
and
we
need
to
set
and
another
one
is
the
node
copy
list
here
we
defined
it
as
a
a
viral
variable
lens
field,
so,
let's
see
can
be
used
to
as
a
copy
the
test
data
list
into
the
reflector
test
back
packet.
Q
So
here
we
list
the
the
the
brave
procedure
here
as
we
we
can
see
that
the
sender
I
need
to
insert
the
header
into
the
test
pack
and
carry
back
the
element
twisting
data
in
the
reflector
packet,
so
yeah.
This
is
the
iom
tracing
data
tv.
Q
Next,
please,
this
is
a
forward
hope,
I
hope,
delay
theory.
So
here
we
also
defined
the
lens
field
and
another
one
has
no
left
field
so
the
length
the
value
we
we
also
must
be
set
according
to
number
of
the
intermediate
nodes
and
the
timestamp
format,
so
the
node
left.
It
means
that
the
the
number
of
of
the
listed
intermediate
nodes
the
packet
need
to
visit
along
the
and
another
large
part
of
field
is
a
timestamp
tuple
list.
Q
Here
we
we
used
to
record
the
ingress
and
the
egress
timestamp
per
hub,
and
also
we
we,
we
followed
the
stamps
the
season
tested
and
procedural
here,
and
there
is
a
teal
within
to
the
test
package.
Next
one
please.
Q
Yeah
yeah
it
does
a
backward,
is
similar
and
the
next
step.
We
we
welcome.
Everyone,
give
the
comment
and
the
input
here
and
we'll
come
to
cooperate
with
others
to
refine
this
document
together
and
that's
all
thank
you.
A
C
We
had
a
productive
meeting,
so
thank
you,
yeah,
thank
you
and
definitely
take
a
look
at
the
slides
that
we
didn't
get
to
present.
To
make
sure
you
know
the
same
thing
just
take
interesting.
Take
it
to
the
list.