►
From YouTube: IETF113-BMWG-20220323-0900
Description
BMWG meeting session at IETF113
2022/03/23 0900
https://datatracker.ietf.org/meeting/113/proceedings/
A
Improvement
of
the
of
the
internet,
so,
if
you've
ever,
if
you've
ever
tested,
something
that
that
connects
to
the
internet
or
is
part
of
the
internet,
this
will
probably
be
interesting
to
you.
C
So,
are
you
guys
what
open
source
tools
are
you
guys
using
for
these
measurements,
or
are
you
using
open
source
tools
for
these.
B
There
are
some
of
the
tools
which
are
open
source
stuff
and
I
think,
actually,
at
the
last
meeting
there
was
some
discussion
on
a
tool
whose
name
I've
completely
forgotten,
which
was
you
know,
hey
we
implement
rfc
blah
blah
and
here's
how
but
I
completely
swapped
the
name.
D
E
F
A
G
A
All
right,
it's
it's
actually
three
minutes
after
the
hour,
so
I
think
we'll
we'll
we'll
start
slowly
with
the
preliminaries
here.
Sarah
I
haven't
heard
your
voice.
Yet
are
you
able
to
activate
your
microphone.
A
Not
yet
all
right!
Well,
we
we
we
might
as
well
get
started
at
least
slowly
here
so
welcome
everybody.
A
A
So
it's
a
it's
a
it's
a
zero
dark
400
here
in
chicago
and
even
worse,
on
on
the
west
coast
and
in
seoul.
It's
not
too
bad
it's
about
dinner
time,
so
we're
glad
to
get
things
going
here.
I'm
al
morton
co-chairing
with
sarah
banks
and
if
you'd
like
to
join
our
mailing
list.
This
is
how
you
do
it
right
down
here
at
the
bottom,
so
getting
into
it
it's
wednesday.
A
We
have
an
extra
line
in
our
note.
Well,
we
work
as
individuals
and
we
try
to
be
nice
to
each
other
and
that's
always
worked
except
for
one
or
two
times
I
can
remember,
but
in
any
case
we're
we're
a
good
crowd
of
people
that,
as
as
you
know,
as
testers
and
and
folks
interested
in
testing
and
the
results
of
testing,
we
usually
get
along
pretty
well.
A
So
here's
the
note
well
and
and
it's
a
reminder
of
itf
policies
in
place.
There's
a
patent
policy
and
definitions
of
contribution
and
participation.
A
Please
read
it
carefully
and
of
course,
if
you're
aware
of
any
itf
contribution,
that's
covered
by
patents
or
patent
applications
owned
by
you
or
your
sponsor
that
and
you
you
must
disclose
that
fact
or
not
participate
and
so
forth.
You
should
have
heard
this
five
or
six
times
by
now.
So,
let's,
let's
assume
that's
as
written.
A
Okay.
Our
agenda
here
today
is
to
talk
about
status
of
the
working
group
drafts
and
the
working
group
status
in
general.
So
we've
got
a
couple
of
working
group
drafts
lined
up
for
presentation
and
discussion
and
then
we'll
look
at
the
draft
that
we've
been
trying
to
get
adopted
into
the
working
group.
I
think
we're
pretty
close
on
that.
A
There
was
another
email
yet
on
that
again
this
morning
we've
got
a
couple
of
proposals
that
are
been
around
for
a
while,
and
then
we
can
talk
about
some
more
and
then
some
new
proposals
related
to
segment,
routing,
mpls
and
ipv6
flavors
of
sr.
So
that
should
be
exciting
and
and
that's
the
total
agenda
today,
I
think
I've
got
slides
for
every
one
of
these.
Now
so
that's
that's
a
good
thing
too
any
bashes
to
the
agenda.
A
All
right
hearing,
none,
that's
good.
We
did
the
ipr
thing.
It
looks
like
we
can
fairly
easily
covered
jabber.
I
think
warren.
If
you
sort
of
keep
an
eye
on
that.
That
would
be
great.
A
warren.
A
Warren
is
our
our
ad
advisor
he's
sitting
up
front
today,
as
our
our
bmwg
delegate
and
bmwg
chair
for
a
day.
A
F
A
For
thanks
for
helping
out
there
in
the
room,
so
this
should
be
fun
we'll.
Let
me
move
on
to
the
next
thing
here:
here's
the
working
group
status,
the
evpn
draft,
got
a
lot
of
comments
and
discusses
in
iesg
review.
A
The
bottom
line
is
the
authors
tried
to
get
to
a
point
where
they
were
addressing
the
comments,
but
no
new
file
was
was
ever
submitted
and
you
know
they
sort
of
sort
of
claimed
that
they
were
looking
for.
One
author
was
looking
for
approval
of
the
other,
and
then
everyone
disappeared,
so
we
set
deadlines.
We
last
tested.
Other
people
take
up
the
work,
basically
no
response,
so
this
is
officially
status
dead
now
and
sad
to
see
that
a
lot
of
work
went
into
it.
A
But
that's
the
way
it
goes
next
generation
firewall
benchmarking,
we're
hearing
a
lot
more
about
that
today,
they're
working
hard
to
discuss
to
resolve
the
discuss
ballots
and
one
of
those
is
going
to
require
a
transport
area,
review
request
again
and
then
tommy
paulie
is
is
going
to
be
the
target
for
that,
since
he
reviewed
it.
A
The
first
time
around
multiple
loss
ratio
search
has
had
a
large
rewrite
sort
of
in
progress,
we're
still
working
on
that
yang
model
and
that
resolving
that
objection
and,
as
I
said,
proposals
keep
coming
no
new
rfcs.
This
time
we
got
a
nice
stable
charter,
which
is
fantastic
and
we've
got
a
supplementary,
bmw
webpage.
That
tells
you
how
to
join
up
so
glad
to
share
that
link
with
you
all
milestones.
A
The
one
thing
I'm
really
bad
at
as
chair
is
keeping
milestones
up
to
date.
So
they're
not
you
know,
I
think
we
we
usually
somebody
usually
takes
an
action
item
out
of
the
meeting
to
propose
new
milestones.
Oh
hey,
sarah!
You
got
your
audio
going.
H
You
noticed
yeah
and
I'll
take
the
action
actually
to
go
through
and
update
milestones
with
you
afterwards.
Thank
you
good
morning.
All.
A
A
Cool
all
right,
then
let
me
I
guess
I
stopped
this
right
and
then
I
started
up
again
with
a
new
deck
of
slides
and
that's
this
one.
A
And
hopefully
you
guys
can
see
the
new
deck
for
the
multiple
loss
ratio
search,
and
that
means
we're
looking
for
ratco
to
step
up
to
the
virtual
microphone
and
give
us
a
short
presentation
here.
So
please.
I
I
The
previous
versions
of
the
draft
were
trying
to
describe
multiple
goals
and
multiple
ways
to
achieve
those
goals,
and
the
text
was
too
interconnected
and
hard
to
parse.
So
we
are
doing
a
rewrite,
trying
to
explicitly
state
different
goals
and
explicitly
state
different
parts
of
the
solution
of
what
we
are
proposing
and
discuss
what
is
possible
on
the
smaller
areas
before
putting
it
all
together.
I
Also,
we
are
trying
to
get
rid
of
the
terminology
we
are.
We
were
using
in
the
previous
versions:
names
like
ndr
and
pdr:
non
drop
plate
that
partial
drop
rate,
which
is
not
the
official
terminology,
so,
where
possible,
we
are
trying
to
use
terminology
present
in
previous
rfcs
and
yeah.
So
we
were
starting
this
rewrite,
but
we
realized
that
it
is
way
more
work
than
we
allowed
our
the
time
for
us.
So
this
is
the
progress,
but
for
anybody
interested,
I
think
it
is
a
worth
a
read.
A
I
This
is
just
you
can
see.
This
is
an
old
slide.
I
have
already.
I
have
only
updated
the
links.
Basically,
this
is
describing
an
algorithm
that
we
are
already
using
for
quite
a
few
years
and
we
are
doing
small
improvements
to
it
but
yeah.
Basically,
this
is
like
code
first
approach,
and
maybe
this
is
why
the
draft
currently
is
more
complicated
than
if
it
was
like
more
theoretical
work.
I
Next
slide,
please,
okay.
So
this
is
like
a
very
quick
overview,
so
try
to
highlight
the
main
ideas.
The
one
important
idea
is
to
search
not
only
for
throughput,
which
is
the
load
that
achieves
zero
loss,
but
also
various
loads
that
achieve
a
specific
ratio
of
loss.
I
I
So
you
want
to
formalize
this,
so
it
is
for
some
types
of
duties.
It
is
also
interesting
to
find
for
this
load
that
achieves
some
non-zero
ratio,
because
this
result
is
more
stable
and
one
of
the
main
motivations
for
our
approach
is
to
save
time
while
doing
the
the
search.
So
there
are
multiple
like
I
can
call
it
tricks
that
can
be
applied.
All
of
them
are
related
to
the
way
the
load
for
the
next
trial
is
selected,
also
duration,
because
it
is
possible
to
use
short
iterations
and
yeah
one
more
thing.
I
Maybe
you
can
go
to
the
next
slide,
I'm
not
sure
where,
where
I
put
it
okay,
so
it
is
not
there.
Alright,
I
will
go
back
to
it.
There
are
some
requirements
that
are
kind
of
implicitly
present
already
in
rfc
2544,
but
they
are
not
stated
as
explicitly
as
needed.
This
is
mostly
related
to
the
discussion
we
had
on
the
mailing
list
and
also
on
these
meetings.
I
One
big
requirement
is
that
how
is
it
called
test?
Equipment
has
to
be
reliable.
Basically,
if
you
want
to
start
a
trial
with
some
load
that
this
equipment
should
be
able
to
really
put
as
many
frames
in
the
about
its
time
as
is
required,
because
we
know
that
for
some
setups,
the
the
this
equipment
can
struggle
to
achieve
high
enough
load,
and
this
is
not
addressed
in
the
rfc
254.
But
of
course
it
is
very
important
and
there
are
other
rfcs
that
are
already
describing
basically
difference
between
intended
load
and
offered
load.
I
And
we
want
to
make
the
language
of
our
draft
to
use
those
terms
and
make
it
clear
that
this
equipment
has
to
be
ridable.
And
if
it
is
known
that
it
is
only
reliable
up
to
some
load.
It
is
for
the
testing
group
or
the
person
realizing
those
tests
to
ensure
that
the
test
equipment
never
attempts
to
send
more
loans
than
it
is
able
to
do.
And
there
is
like
a
side
question
of
how
do
you
know
how
much
your
test
equipment
is
able
to
do?
Which
is
another
kind
of
worms.
I
Our
draft
is
not
planning
to
offer
a
solution
for
those
kind
of
questions.
We
just
want
to
make
it
explicit
that
this
is
work
required
and
leave
it
to
the
people.
How
do
they
achieve
that?
I
Also?
Another
thing
that
was
not
presented
rfc
to
544
is
any
search
top
criteria.
Basically,
it
only
says
you
either
increase
or
decrease
the
load
for
the
next
trial,
but
it
doesn't
tell
you
when
you
can
stop
so
in
our
mlr
search.
We
are
also
proposing
some
search.
Stop
criteria
next
slide,
please,
okay,
okay!
This
is
the
real
example.
I
Basically,
some
of
you
are
have
already
seen
similar
presentations,
so
this
is
not
news
to
you.
This
is
here
just
for
people
that
are
maybe
new,
so
they
can
see.
How
does
it
work
in
real
life?
And
I
will
if
there
are
questions
I
can
go
back
here
and
describe
what
is
going
on,
but
just
looking
at
the
bold
numbers,
you
can
see
that
there
are
more
trials
aimed
to
examine
the
ndr,
so
zero
loss
ratio
and
less
trials
able
to
search
for
pdr
next
slide.
I
Please
and
that
that
pdr
is
the
partial
drop
ratio
right,
yes,
and
as
usual,
it
is
more
stable.
There
are
less
surprises
during
the
search
in
the
ndr
lower
column.
When
you
see
n
slash
a
that
means
that
we
have
increased.
The
duration
repeated
the
the
measurement
with
the
same
load
that
worked
before,
but
now
it
didn't
work.
Basically,
the
same
load
increase
duration.
A
And
and
you've
got
four
phases
here,
this
initialization
in
one
into
and
final
and
and
then
of
course,
your
your
final
results
come
out
in
that
in
that
final
phase-
and
these
are
the
these-
are
sort
of
your
precision
on
the
on
the
ndr
offered
load.
I
Here
at
the
bottom
yeah,
basically,
so
you
can
see,
for
example,
that
the
final
trial
duration
is
30
seconds
and
not
60
years
required,
but
by
rfc
254.
This
is
our
team.
Deciding
saving
more
time
is
more
important
than
be
fully
compliant
but
yeah.
Basically,
we
have
our
position
goal.
I
think
it
is
half
a
percent
okay.
This
is
a
rounded
value,
so
you
cannot
verify
it,
but
basically
that
is
it
and
so
for
these
values
it
is
basically
0.01
mega
packets
per
second.
I
I
believe
that
is,
and
you
can
see
that
for
the
iteration
two
it
is
higher
and
it
iteration
it
is
even
higher.
So
there
are
some.
I
Clever
tricks
to
really
try
to
do
as
few
well
to
spend
as
few
seconds
as
possible
for
the
search
in
this
particular
situation.
The
duty
was
not
very
stable.
You
can
see
that
for
one
second
trials,
five
point:
seven
eight
was
enough,
but
for
five
seconds
we
needed
to
lower
point
six
and
for
30
seconds
5.26.
A
I
A
So
that
so
you
know
those
are
the
interrupts
we're
dealing
with
that.
You
know
we
can't
get
rid
of
the
virtualized
environment.
They're
they're
happening
for
system
functions
that
are
stirring
for
health,
so
you
know
we
gotta
work
around
that.
I
Well,
walk
around.
This
is
a
benchmarking,
so
we
have
to
accept
whatever
barrier
and
absolutely
absolutely.
But
this
is
like
one
of
the
examples
why
we
are
choosing
some
values
that
are
maybe
not
not
obvious,
because
this
is
an
example
of
the
search
that
takes
longer
than
the
usual
in
ideal
case.
You
need
only
four
measurements
at
30
seconds,
and
now
you
can
see
there
are
way
more
than
the
four
measurements.
I
So
this
is
spending
some
time,
so
we
were
like
trying
to
find
good
values
that
are
resulting
in
fast
search
time,
even
if
the
dod
behavior
is
not
as
nice
right,
okay,
okay,
so
we
can
go
to
the
next
slide
yeah.
This
is
a
basically
me
inventing
a
numbers
just
to
get
to
a
scenario
that
is
interested
interesting.
I
So
if
you
can
find
it,
there
are
well
one
cell
with
two
red
numbers
and
the
other
cell
with
a
100
number.
Basically,
the
situation
with
the
two
word
numbers
is
similar
than
before
and
now
for
pdr
lower
bound.
We
have
repeated
the
measurement
and
instead
of
an
a,
I
have
written
the
ndr
upper
bound
and
basically
one
of
the
not
well.
One
of
the
questions
with
no
obvious
answer
is
what
should
be
the
offered
load
there.
I
In
this
particular
example,
I
have
chosen
the
20
to
be
the
next
offered
load
which
well,
let
me
talk
about
it
one
more
time.
So
the
third
line
from
the
bottom
we
have
measurement
at
17
and
the
measurement
at
22..
I
I
So
the
question
is:
what
should
we
choose
as
the
next
load
to
get
to
the
pdr?
One
possibility
is
just
okay:
you
have
lower
bound.
You
have
upper
bound,
even
if
they
are
far
apart,
you
can
do
the
bisection.
I
Another
reasoning
is
that
you
have
new
pdr
upper
bound
and
you
have
old
pdr
upper
bound
like
a
second
titus.
At
the
64
second
measurement-
and
you
can
do
external
search
from
there
and
well
maybe
even
another
approach
is
that
if
on
this
re-measurement,
the
22
value
has
failed.
Maybe
it
is
a
signal
that
the
pdr
will
be
closer
to
the
ndr.
So
maybe
we
can
continue
external
search
from
the
ndr
values
like
16
17,
okay,
so
let's
try
knighted.
So
there
are
multiple
choices
and
it
is
not
the
obvious.
I
What
is
the
best
approach
in
perhaps
in
practice
it
may
depend
on
your
experience
like
what
do
you
expect
of
your
duty?
Would
you
imagine
that
the
period
lower
bound
will
be
at
64
seconds?
But
of
course,
if
you
want
to
specify
the
algorithm,
it
has
to
be
deterministic
well
right.
Maybe
now
I
can
talk
about
it.
One
of
the
goals
of
the
smaller
search
is
to
make
this
load
selection
deterministic,
because
if
you
do
not
have
deterministic
load
selection,
you
have.
I
You
do
not
have
as
high
repeatability
of
the
result.
Basically,
if
you
run
the
search
once
maybe
you
run
the
search
second
time.
Of
course
you
can
get
a
different
result
just
because
the
otp
has
differently,
but
sometimes
you
can
get
different
results
if
you
use
similar,
but
not
exactly
the
same
algorithms.
I
I
Of
course,
this
is
only
affecting
devices
that
are
not
deterministic
but
yeah,
as
we
have
seen.
There
are
quite
many
devices
that
are
not
deterministic,
and
one
of
my
goals
is
to
have
something
that
gives
us
small
standard
deviation
when
you
run
the
same
search
on
the
same
device
multiple
times
as
possible,
while
still
having
a
small,
total
duration.
H
So
rocco,
I
think
I'm
I'm
struggling
with
two
things
here.
First
and
I'll
I'll
take
up
the
majority
of
this
feedback
to
the
list,
the
slides
and
what
you're
seeing
don't
match,
and
they
really
need
the
color
and
context
of
what
you're.
Seeing
if
I
were
to
look
at
these
later
on
my
own,
without
the
commentary
or
without
looking
at
the
video,
I'm
not
sure
these
things
hold.
H
If
I
just
look
at
the
side
here,
I
don't
exactly
know
what
it's
telling
me
without
you
explaining
it.
So
thank
you
for
explaining
it,
but
I'll
take
some
of
this
feedback
to
the
list,
because
I
think
it's
just
stuff
that
helps
me
make
sense
of
the
slides
afterwards
and
it's
editorial
so
I'll.
H
The
smallest
standard
deviation
makes
like
I'm
not
sure
what
the
value
is,
because
at
that
point,
if
the
device
isn't
deterministic,
it
is
what
it
is
and,
and
I'm
not
sure
why
you
would
want
to
try
to
artificially
reduce
the
standard
dvd.
The
spread
on
the
standard
deviation
there.
I
This
whole
search
takes
time
and
you
want
to
run
multiple
tests,
so
you
do
not
really
have
time
to
repeat
the
search,
and
sometimes
you
see
from
the
results
like
you
change
the
duration,
you
get
a
different
loss
rate
loss
ratio.
Then
this
is.
That
is
a
proof
that
the
dot
is
not
that
mystic,
but
sometimes
you
get
compatible
result
in
your
one
search
and
you
do
not
see
that
it
was
not
guaranteed.
I
If
it
is
deterministic
that
it
doesn't
matter
this
details
that
I'm
talking
about,
but
if
it
is
not
deterministic.
I
A
Sure
how
important
it
is,
it's
it's
I
you
know
taking
up
from
sarah's
point,
it's
it's
important
to
make
the
table
sort
of
wide
enough
and
the
column
headings
useful
enough
to
describe
both
of
the
numbers
in
each
column
or
or
just
put
a
key
to
that
someplace
and-
and
you
know,
I
would
observe
that
if
this
was
real
data
and
you
had
64
second
duration
trials,
those
would
be
really
hard
to
make
deterministic.
A
You
know
sort
of
in
the
face
of
the
transients
that
we're
seeing
in
the
you
know,
virtualized
networking
world
these
days
so
and
but
I
think
that's
the
same.
That's
the
same
kind
of
thing
that
you
encountered
at
30
seconds
and
and
so
forth.
So
you
know
I
I
I
encourage
you
to
think
about
the
transients
and
the
and
the
steady
state
performance,
which
is
what
exists
in
between
the
transients,
perhaps
in
in
in
different
ways.
A
You'll.
I
think
you'll
find
that
that
that
might
help
it
might
help
to
add
some
determinism,
and
you
may
need
to
repeat
trials
too
the
same
same
sort
of
way
that
we
did
with
the
binary
search
with
loss
verification.
A
I
mean
that's
been
a
that's,
been
a
a
valuable
addition
to
a
tried
and
true
search,
algorithm
to
repeat
trials
at
at
a
duration
in
between
transients.
You
know
once
we
figured
out
what
that
typically
is.
So
you
know,
as
you're
searching
for
quote,
quote
determinism
here
and
and
trying
to
make
the
algorithm
deterministic
think
along
those
lines
too.
I
I
think
that
might
help.
I
Yeah
well
basically,
it's
a
part
of
that
reasoning
went
into
our
other
draft
plr
search
that
is
aimed
specifically
for
devices
that
can
be
deterministic
and
but
yeah.
That
is,
that
is
not
even
close
to
being
finished,
so
we
do
not
expect
wide
adoption
there.
But
this
this
is
just
making
rfc
two
five.
Four
four
and
making
throughput
like
more
strict.
The
starter,
algorithm
more
speaks
so
that
the
results
are
coming
faster
and
if
possible,
they
are
repeatable.
A
Right
right,
so
I
guess
the
best
thing
to
do
is
you
know,
as
as
sarah
says,
let's
try
to
make
the
the
tables
you're
producing
clear,
and
maybe
let's
and
let's
look
at
some
results
together
on
the
list
and
see
what
we
can
say
about
those.
I
Yeah,
definitely
if
you
have
specific
questions
right
to
the
list-
and
I
will
reply
basically,
I
was
thinking
about
describing
the
current
load
selection,
because,
basically
showing
the
six
values
that
are
considered
the
tightest
lower
bound.
Second,
that
is
lower
bound,
that
is
upper
bound
seconds,
tightest
upper
bound
and
tightest
lower
bound
from
previous
duration
and
tightest
upper
bound
from
previous
duration.
I
Only
those
six
at
most
six
values
are
considered,
and
then
there
is
some
logic
that
computes
something
and
decides
what
will
be
the
next
load,
but
I
figured
that
first
of
all,
it
is
likely
to
be
changed
for
another
draft
version.
I
I
think,
mainly
from
vladimir,
that
it
may
be
more
useful
to
finish
searching
from
ndr
before
starting
a
search
for
pdr
and
yeah.
Currently,
I
think
that,
yes,
in
some
cases,
it
can
save
some
time
at
the
cost
of
me
not
being
sure
what
the
correct
note
selection
rules
will
be.
I
expect
that
will
be
slightly
more
complicated,
yeah.
Basically
I'm
reading
here,
but
yeah,
and
the
other
thing
is
that
it
will
take.
I
I
believe
too
much
time
for
me
to
even
go
through
that
here,
while
talking
about
so
what
you
see
in
these
slides
yeah,
it
is
like
very
condensed
information.
It
doesn't
make
sense
without
my
commentary,
but
I
haven't
found
a
good
way
to
put
all
the
required
commentary
on
the
slide
right
yeah
when
the
logic.
H
Is
on
the
list,
I
don't,
I
didn't
mean
to
disrupt
your
your
flow
today.
So
I'll,
take
those
comments
to
the
list
and
thank
you
for
considering
them.
I
appreciate
that.
A
All
right,
so
these
are
the
these
are
the
next
steps.
I
think
we've
got
this
now
with
some
good
examples,
and
is
that
pretty
much
it
frecko.
A
Incidentally,
I
I've
I've
put
our
agenda
into
the
the
hedgehog.
The
hedgehog
note
paper
thing
and
we
can
just
add
some
add
some
notes
in
there
for
our
minutes
as
we
go
along
all
right.
So,
let's
see
what's
next.
A
All
right,
I
see
bala
and
is
brian
on
too.
A
Yeah
so
yeah,
I
am
very
good,
so
whoever
whoever
is
going
to
present
these
please
go
ahead
thanks,
guys
for
putting
the
slides
together.
J
All
right
next
slide.
Okay,
all
right!
So
essentially,
the
draft
is
at
the
point
where
it's
gone
through
the
area
director
review
and
we
got
a
significant
amount
of
feedback.
So
we
have.
We
received,
discuss
submissions
from
five
different
participants,
totaling
an
eight
total
number
of
eight
eight,
eight
submissions
that
we've
got
to
work
through.
J
We
come
to
a
resolution
for
five
of
them
that
are
going
to
be
proposed.
We're
looking
at
the
remaining
three
and
two
submitters
were
lars
edgar
and
benjamin
cadduck,
the
the
the
submission
the
submissions
were
interesting
and
we
believe
that
we
have
have
have
good
solutions,
but
we
are
struggling
a
bit
with
with
how
to
respond
to
lars
and
and
benjamin,
but
we're
working
through
that.
I
think
warren
was
had
a
question
or
comment.
B
Thank
you
yeah,
just
a
quick
note
that
it
seems,
like
you,
have
everything
under
control.
You
know
it
seems.
The
conversations
are
happening
and
I've
been
staying
out
of
it.
But
let
me
know
if
you
know
I
should
be
doing
more,
but
it
looks
like
the
conversations
are
happening
and
you're
all
coming
up
with
great
answers.
So.
J
Yeah,
it's
the
the
definitely
is
that,
but
this
is
saying
it's
under
control.
I
think
it's
a
bit
generous,
but
but
thank
you
thank
you
for
that.
So
next
next
slide
out.
A
I'll
I'll
just
mention
here
that
ben
cadeck
is,
I
think,
he's
stepping
down
from
the
iesg
this
time
around
and
and
I'm
being
replaced.
So
I
think
there's
going
to
be
a
little
bit
of
changeover
there
as
well.
But
what.
J
Happened
what
happens
in
that
case
with
his
his
discuss
points?
Do
they
just
go
away.
A
No,
I
I
don't
think
so.
I
think
what
what
could
happen
is
that
ben's
replacement
might
pick
up
his
discuss
and
then
and
then
do
his
own
review,
but
I
think
warren's
gonna
help
me
out
with
that.
Go
ahead.
Warren.
B
Yeah
so
the
incoming
ad
takes
over
the
outgoing
ones
points,
but
they
may
be
less
not
going
to
say
invested
in
the
document,
but
they
may
be.
A
And
I
and
I
didn't
even
even
from
what
ben
said,
I
didn't
think
that
that
his
his
comments
were,
you
know
it
was
sort
of
like
you
know.
I
mostly
have
a
question
here,
but
I
want
to
see
it
answered
kind
of
thing,
so
yeah.
J
So
this
is
the
lion's
share
of
the
issues.
Six,
we
there's
69
comments.
66
we've
come
up
with
a
path
to
it
to
address
them.
You
know
we
do
appreciate
all
the
effort
that
is,
that
has
gone
into
the
reviews.
I
you
know
definitely
have
it's
going
to
improve,
improve
things
significantly.
I
believe
there's
three
remaining
comments
that
we
need
to
come
up
with
the
solution
on
our
on
our
side.
J
I'm
sure
you
can
appreciate
that
69
comments
alone
isn't
a
true
representation
of
of
the
impact,
because
you
know
when
you
make
one
change
to
the
document,
you
have
to
sort
of
like
trace
it
through
the
rest
of
the
document
and
make
sure
that
that
there
aren't
any
contradictions
introduced
and
and
so
on,
and
also
we're
we're
doing
our
level
best
to
ensure
that
that
most
of
the
changes
we
make
are
going
to
be
editorial
and
won't
impact
in
a
significant
manner,
the
actual
performance
testing
requirements.
J
So
that's
that's!
That's
where
we're
working
at
next
slide.
J
So
this
is
this,
is
this
is
an
area
that
we're
we're
really
struggling
with
someone
raise
a
comment
about
you
know
about
the
over
abundant
use
of
the
word
or
or
the
action
should
you
know
throughout
the
document,
and
I
must
I'm.
J
I
must
agree
that
there
was
a
significant
number
in
in
there
and
when
I,
when
I
went
through
them
with
with
bala,
realized
that
a
lot
of
the
shoulds
were
us
just
trying
to
be
polite,
and
yes,
sir,
like
who
are
we
just
to
sort
of
dictate?
J
You
know
you
know
there
might
be
scenarios
that
we
would
consider.
You
know
a
must
under
normal
circumstances,
but
something
could
happen
that
would
make
it
sort
of
yeah.
No,
not
really,
and
we
thought
well,
let's
just
make
it
a
should
not
really
thinking
about
how
this
would
play
out
within
the
ietf
and
how
precise
documents
like
this
should
be.
You
know
so
in
in
the
spirit
of
that
we
went
through
it
and
there
clearly
are
a
number
of
shoulds
in
there.
J
That
will
just
change
to
must,
but
where
I'm
having
the
biggest
issue
is
the
suggestion
that,
if
you're
going
to
use
a
should,
you
need
to
explain
why
it
has
to
be
should,
instead
of
a
must
and-
and
I
I
did
some
reviews
of
you
know-
and
this
was
totally
unscientific,
but
some
reviews
of
other
rfcs,
and
I
don't
really
see
any
significant
statements
along
those
lines
and
in
other
rfcs
now,
just
because
it's
not
anywhere
else
doesn't
mean
that
it
shouldn't
shouldn't,
be
something
that
we
do
in
this
one.
J
H
A
Working
with
you
on
that,
and-
and
I
think
that
you
know
the
the
real
test
process,
in
my
mind,
is
where
you,
where
you
believe
you've
been
polite
and
you
can't
come
up
with
you
can't
come
come
easily
to
a
reason.
Why
there's
a
legitimate.
A
Sort
of
reason
not
to
do
the
the
requirement,
then
it
probably
should
have
been
a
must
or
a
shall.
A
H
Yeah,
no,
I
I
agree
with
al
like
on
one
hand
brian.
I
get
that
you
probably
don't
want
me
on
the
isg,
because
I
really
agree
with
that
comment,
and
I
really
agree
with
your
observation
that
yeah
it
doesn't
clearly,
it
doesn't
mean
it's
ubiquitously
applied
across
all
of
the
ietf
and
some
drafts
or
rfcs
are
better
written
than
others.
I
totally
agree
with
that,
but
I
also
agree
with
what
I
was
saying
that
look.
H
If
you
go
through
and
you're
eyeballing
them
and
you
can't
really
sort
of
identify
hey,
why
is
this
a
then?
I
I
think
I
was
absolutely
in
the
zip
code.
Well,
maybe
it
shouldn't
be
a
must
or
maybe
it
should
be
sure
you
know
you
sort
that
out.
The
other
thing,
though
brian,
is
it
struck
me
as
when
you
were
walking
through
the
your
talk
track
there.
H
A
lot
of
these
things
are
would
be
musts
and
you
would
absolutely
do
them,
but
we
put
them
as
should,
because
we
recognize
that
there
could
be
situations
in
which
you
would
want
to
totally
change
that
anybody
who's
ever
done.
Testing
understands
and
sometimes
totally
goes
against
what
a
draft
says
or
an
rfc
says,
because
we
have
something
in
our
environment
that
that
says
yeah
I
get
that
that's
probably
normal
for
everybody
else,
but
right
now
I
have
this
new
use
case
and
it's
changed.
H
So
the
other
thing
is,
you
could
handle
a
bunch
of
your
shirts
or
your
musts
with
that
sort
of
broad
brush
to
say:
look.
Our
guidance
is
in
normal
circumstances,
here's
how
we
see
the
world,
but
we
accept
that
there
are
times
where
you
might
not
be
in
that
situation,
and
so
you
know
it's
okay
to
do
this
and
I'm
wondering
if
that
would
alleviate
the
the
need
to
address
specifically,
at
least
at
least
110
shids,
in
your
draft.
J
Do
you
think
so,
sir,
that
that
that
scenario
that
you
just
outlined,
which
makes
sense
we
could
could
easily
be
addressed
with
with
a
short
you
know,
paragraph
on
that
topic
at
the
top
of
the
rfc.
K
H
B
No
no
worries,
I
mean
I'm
just
an
eq
like
anyone
else
so
yeah.
I
don't
think
that
you
really
need
to
address.
You
know
each
and
every
one
of
the
shows
I
think
it's
worth
going
through
and
be
like
yeah.
This
one
seems
reasonable
this
one
doesn't.
I
also
don't
know
that
you
can
entirely
solve
the
concern
by
just
saying
you
know
putting
a
disclaimer
at
the
top
being
like
well,
these
shoulds
are
there
in
case.
You
want
to
change
your
mind.
B
What
I
think
you
can
probably
do
is
some
of
the
uppercase
shoulds.
Maybe
could
be
better
done
with
lowercase
shirts,
but
also
you
know
if
they're
ones,
where
it's
easy
to
say
when
you
can
ignore
the
should
do
that,
but
also,
I
think
you
know,
have
a
chat
with
the
ad
and
be
like
we've
done
a
bunch
of
them.
I
think
it's
relatively
clear
to
whoever's
doing
this
under
what
conditions
they
would
ignore
the
should
so
you
know,
are
you
okay
with
this?
B
A
And
rob
go
ahead.
L
Yeah,
I
just
gotta
echo
what
what
warren's
saying
really
so.
I
don't
think
that
it's
really
fair
for
the
ads
to
go
beyond
what's
in
rfc
2119,
so
that
doesn't
say
you
have
to
have
this
extra
explanation
of
when
it
should
he
sort
of
is
not
a
must
and
things.
I
think
it
is
sort
of
makes
sense,
though,
in
various
places
to
do
that,
but
yeah
completely
to
one's
point
I
think
actually
chatting
with.
Is
it
murray,
horry
the
discuss
on
this?
L
I
think,
if
he's
just
asking
in
some
places,
this
is
unclear.
If
you
look
through
them
and
it
looks
like
that's
good
and
you
go
back
to
him,
I
would
have
thought
that
he's
not
going
to
be
too
strict
on
this.
There
is
thought
about
trying
to
make
this
stricture
in
future,
but
I
think
that
needs
an
update
to
rc2119,
but
that's
just
my
opinion.
B
J
Yeah,
that's
it
on
the
slide,
so
path
forward,
then
get
given
the
feedback
that
we're
getting.
Is
that
we'll
do
one
update
to
the
draft
covering
off
everything
we'll
first
order
will
be
to
get
an
email
out
to
the
various
area,
directors
for
to
address
their
discuss,
submissions
and
the
comments
and
then
we'll
deal
with
the
shoulds
and
then
we'll
do
one
update
to
the
to
to
the
draft
and
submit
it
and
the
reason.
A
And
one
thing
that
lars
asked
for
was
more
transport
area
review,
but
since
we've
got
one
already
then
tommy's
on
the
hook.
For
that-
and
you
know,
I
think
we
can
get
him
to
look
at
this
and
and
respond
yeah.
A
Yeah
yeah,
yeah
and-
and
you
know
what
basically
lars
is-
is
still
reviewing
from
the
transport
area
point
of
view,
even
though
he's
supposed
to
be
internet
area
now
or
general
area
as
as
chair.
So
you
know
you
do
what
you
do.
B
Thank
you
and
yeah
waiting
and
submitting
a
new
document
with
all
of
the
changes
is
definitely
an
idea.
Another
thing
you
might
want
to
consider
is
submitting
a
version.
If
you
have
one
easy
that
has
addressed
the
initial
set
of
discuss
points
just
goes
that
way.
Those
ads
can
clear
them
and
you
don't
need
to
sort
of
wait
around.
B
J
Okay,
yeah
that
that's
definitely
reasonable.
What's
the
imp,
what's
the
impact
on
the
process
then
like
if
we
we
do
that,
and
then
you
know
everyone
is,
is
is
happy
at
that
point
and
then
and
then
we
make
the
changes
with
respect
to
the
comments
and
the
shoulds
to
the
document.
B
I
may
have
missed
your
question
or
misunderstood
it,
but
I
mean
at
the
moment
there
are
four
people
with
discusses
if
you
submit
a
version
which
clears,
for
example,
eric's,
discusses
and
he's
happy
with
him.
He
will
then
remove
his
discuss
point
and
you
know
he
won't
be
able
to
come
back
later
and
reapply
it
or
forget
about
it
or
something.
A
It's
a
it's
a
it's
sort
of
a
one-time
review
thing
and
as
long
as
you
don't
have
comment
creep,
you
know
which
some
of
us
have
seen
before.
Then
you
know.
But
but
now
all
the
comments
are
written
and
they're
stored
in
the
data
tracker,
and
you
know
that's
a
lot
harder
to
for
anybody
to
get
away
with.
So
you
know
just
consider
updates
of
the
draft
that
address
specific
comments
or
discuss,
blocking
comments
and
and
and
and
we'll
knock
them
down,
as
as
we
can.
B
I
mean
another
advantage
to
that,
is
you
know
once
you've
addressed
lars's
and
the
other
one
who's
confirmed
who
the
other
hold
up
was
we
still
need
to
actually
get
the
people
whose
comments
have
been
addressed
and
are
happy
to
actually
click
the
button
saying
clear,
and
you
know
if
they
happen
to
be
away
on
vacation
that
week
or
whatever
they
might
take
some
time
so.
J
B
A
So
next
up,
we've
got
a,
I
believe,
a
short
talk
with
that.
We
don't
really
need
slides
for
and
that's
going
to
be,
the
the
working
group
adoption
review
on
the
yang
data
model
for
network
interconnect,
tester
management
and-
and
I
read
out
the
whole
title,
because
the
title
is
the
crux
of
the
objection-
and
I
saw
this
morning
that
vladimir
has
made
a.
A
A
So
vlad
has-
and
I
see
you're
in
the
room
feel
free
to
turn
your
mic
on
there.
You
know
remotely
hi
hi
good
thanks
for
joining
us.
Have
you
seen
any
response
to
the
seen
any
response
to
your
proposal
from
this
morning?.
N
Not
yet,
but
I
think
the
the
discussion
is
now
focusing
on
pretty
pretty
clear
like
points
and
I
I
think
that
the
argument
that
reusing
network
interconnect
device
as
a
term,
although
it
appears
a
long
sequence
of
nouns,
it
is
still
a
noun
that
describes
something
that
is
known
in
the
work
group.
So
it
should
be
considered
as
an
option,
even
if
tom
thinks
it's
long
and
complicates
the
sentence
somehow.
N
So
I'm
I'm
not
sure
the
the
title
should
be
changed,
but
I
don't
mind
if
it
is
changed.
If
it
is
made
shorter,
it
kind
of
broadens
the
scope
which
is
not
like
corresponding
to
what
the
actual
contents
of
the
draft
is
like.
If
you
say
a
network
tester,
and
then
you
include
probably
also
the
the
stateful
protocols
and
other
things
that
go
outside
of
the
scope
of
testing
and
network
interconnect,
either
it's
a
device
or
a
more
complex
system,
which
is
what
the
draft
actually
focuses
on.
A
Right
and
also
the
I
mean
you
can
you,
can
you
can
aid
the
title
by
putting
more
scope
in
the
abstract,
at
least
it's
it's
fairly
close
by.
N
A
Great
so,
let's,
let's
try
to
get
some
agreement
on
this
fairly
quickly
and
then
I
think
we've
we've
got
potential
adoption
here,
the
it's
it's
pretty
unusual
for
us
to
get
a
you
know,
an
objection
about
anything
specific
and
and
then
the
title
ended
up
being
the
main
sticking
point
here.
So
let's,
let's
try
to
try
to
get
bass
that
in
a
good
way
and
keep
going.
So
thanks
for
your
thanks
for
your
work
on
that
flat.
A
All
right
rob
you're
in
the
queue.
L
Yes,
robertson,
cisco,
just
to
make
a
quick
comment.
I
didn't
comment
on
the
adoption
poll,
but
actually
I
think
this
is
a
good
piece
of
work.
I
think
it's
a
good
thing
to
be
doing.
I
think
that
finding
a
sort
of
formal
data
model
for
programming
these
things
will
make
it
easier
to
write
automated
tests
and
then
have
those
into
operate
with
different
implementations.
So
so
I'm
very
supportive
of
this
work.
A
Okay,
all
right,
so
when
now
we're
making
good
progress
again
so
up
next
we've
got
the
benchmarking
methodology
for
stateful
nat
xy
gateways
using
rfc
4814
pseudorandom
port
numbers.
That's
a
good
long!
Title
too.
A
But
keith,
I
think
you're
going
to
do
the
presentation
today
right.
A
I
see
you've
got
your
mic
turned
on
keiichi,
but
I
but
I
I
can't
hear
you.
H
K
Hello,
yes,
there
you
are
okay,
okay,
okay,
so
my
my
headset
didn't
work
correctly.
So
I'm
now
using
my
notebook
microphone,
so
the
sound
might
be
a
bit.
K
That's
fine,
not
very
good,
but
anyway
no,
it
sounds
good,
okay,
so,
okay,
so
hello,
my
name
is
keith
shima
from
iij,
and
in
this
thought
I
will
talk
about
the
latest
updates
about
draft
which
title
is
this:
benchmarking
methodology
for
states
for
not
xy
gateways
using
the
pseudorandom
port
numbers?
Okay,
next
slide,
please.
A
Yeah
very
good
and
and
caichi
I'm
going
to
give
you
I'm
going
to
give
you
like
a
14
minute
time
clock
here,
the
the
minute
I
I
figure
out
how
to
do
that
here
we
go
and
just
to
just
to
try
to
divide
the
time
among
the
drafts
that
we've
got
remaining
okay.
K
Okay,
that's
right,
okay,
and
this
draft
is
a
guideline
to
provide
a
lot
usable
and
meaningful
measurement
procedure,
using
existing
benchmarking
method
for
not
xy
and
gateways.
Since
these
data
flow
boxes
has
to
manage
the
connection
tracking
table
entries,
so
we
need
some
special
cares.
So
this
draft
focus
on
the
three
parts.
The
first
one
is
a
connection
establishment
performance
measurement.
K
K
Okay,
this
is
at
the
brief
history
of
the
the
drugs.
I
I
think
I
don't
need
to
explain
this,
so
we
have
submitted
the
third
draft
this
time,
which
include
the
connection,
tear
down
performance
measurement
part,
and
we
have
added
some
preliminary
test
results
in
the
draft
too.
Okay,
next
slide,
please.
K
Okay,
so
this
chart
shows
the
overview
of
the
the
test
bit
configuration.
So
I
also
don't
think
we
need
to
explain
in
detail
in
this
figure
by
the
way,
so
there's
some
tester
and
the
duty
and
the
testosterone
some
measurement
packets
on
one
interface
and
receive
the
packet
on
the
other
interface.
And
we,
when
we
do
the
bi-directional
testing,
we
do
the
similar
thing
using
the
different
interfaces.
K
The
point
is
that
the
dut
is
a
stateful
box,
so
the
dut
has
to
manage
a
connection
tracking
table
in
it
and
we
don't
know
we
can.
We
don't
have
any
control
on
the
connection
tracking
cable
from
tester,
but
we
have
to
synchronize.
We
have
to
be
have
the
same
state
table
in
the
testosterone,
because
we
need
to
do
some
kind
of
a
testing
using
the
opposite
direction.
So
this
is
the
point
we
want
to
discuss
in
this
draft.
K
And
to
achieve
the
reproducible
measurement,
we
ensure
these
two
things:
the
we
split
the
test
phase
into
two
phases.
The
one
is
applying
preliminary
test
phase,
which
is
focusing
on
the
filling
out
the
connection
tracking
table
of
the
duty
and
make
a
synchronized
state
table
in
the
tester,
and
the
second
phase
is
the
real
test
phase.
This
is
almost
the
same
as
the
other
benchmarking
methodology
method
like
rfc
2544.
K
K
K
Okay-
and
this
slide
explains
the
new
items
in
this
draft
in
the
states
from
nat
xi
gateway.
It
is
important
to
measure
the
performance
of
the
teardown
operation
of
the
connection
tracking
entries
to
do
that.
We
added
a
procedure
to
measure
the
performance
in
the
latest
draft.
The
basic
idea
is
to
delete
the
entire
connection
tracking
table
entries
during
the
measurement
process
and
measure
the
time
spent
for
the
deletion
operation.
K
Okay,
this
is
what
we
have
done
in
this
draft,
so
we
create
a
connection
tracking
tables
in
the
preliminary
phase,
which
is
we
create
and
the
number
end
of
the
connection
tracking
table
entries
in
the
duty
and
other
when
we
measure
the
connection
teardown
performance,
we
remove
the
entire
connection
tracking
table
by
using
some
kind
of
out
of
band
methodology
like
a
command
line.
Operation
remotely
manage
the
command
line
operation
on
the
duty,
so
by
measuring
the
time
and
the
split
divide,
the
the
total
time
to
delete
the
entire
connection
tracking
table.
K
K
And
since
this
part
is
a
new
in
this
draft,
we
probably
have
still
some
debatable
points
in
this
connection
kia
down
measurement
procedure.
We
want
to
continue
the
discussion
in
the
bmw
list
to
enhance
the
quality
of
this
draft.
K
K
Okay,
this
is
some
detailed
configuration
explanation
of
the
ip
tables
experiments
we
have
done
and
the
detailed
result
is
also
written
in
the
draft.
So
if
you
want
the
more
data
information,
probably
you
can
check
the
draft
contents.
So
in
this
case
we
use
ip
tables
functions
and
we
do
the
not
4
4
address
translation
mechanism
and
we
have
measured
especially
for
the
connection
theodom
performance
in
this
case,
by
changing
several
parameters
of
the
nut
4-4
box
and
the
result
is
in
the
next
slide.
K
Okay,
so
this
is
a
bit
complicated
table,
but
the
actual
barriers
are
is
not
very
important.
So
the
point
is
that
each
column
is
each
different
tests
using
the
different
parameters.
The
top
law
is
the
number
of
connections,
the
minimum
one.
On
the
left
side,
one
is
a
1.5
million
connections
and
in
the
largest
case,
in
the
right
heights
right
hand
side,
we
created
800
million
connections
on
the
nat
four
four
box,
using
our
testing
procedure
and.
K
And
finally,
we
in
this
case
we
are
focusing
on
the
connection
teardown
performance
measurement,
so
we
remove
the
entire
connection
tracking
table
after
we
have
created
that
much
of
the
connection
tracking
entries
and
the
lowest
law
shows
the
rate
of
the
connection
tracking
table
deletion
count
per
second.
So
in
this
case
we
can
see
that
almost
4
350
to
400
entries
can
be
removed
per
second,
when
we
use
ip
tables.
K
Of
the
other
target
duty
node
and
again,
so
the
actual
value
is
not
very
important
here.
The
important
point
is
that
we
are
providing
some
procedure
to
measure
the
connection
theorem
method
for
the
duty
and
we
could
get
this
kind
of
a
stable
measurement
result
with
our
methodology.
K
Okay,
next
slide,
please
very
good,
and
this
is
another
experiment
which
is
also
written
in
the
draft
too
in
detail.
So
in
this
case
we
use
the
dual
color
module
linux
kernel,
module,
which
is
used
as
the
not
force,
not
six
for
gateways,
and
next,
please,
okay,.
K
And
the
same
as
the
ip
tables
case,
we
have
tested
several
different
parameters
and
that
the
parameters
are
almost
the
same,
but
there
is
a
little
difference
in
the
right
hand
side.
So
this
is
because
of
the
some
resource
limitation
of
our
test
bet
environment.
So
we
are
sorry
it
is
not
very
consistent,
but
anyway,
the
actual
absolute
value
is
not
very
important.
We
could
the
important
thing
is.
We
could
provide
some
testing
procedure
for
connection
tied
on
performance
measurement,
using
this
methodology
and
just
for
your
information,
the
connection
teardown
late
in
june.
K
Counter
module
is
much
faster
than
the
ip
cables
case.
We
didn't
get
into
detail
why
this
is
much
faster
than
ib
cables,
but
the
point
is
again:
the
methodology
provides
some
stateful
and
repeat
as
a
stable
and
reproducible
procedure
for
the
connection.
Theater
methodology-
okay,
next,
please
and
okay-
and
this
is
the
final
slide
of
my
presentation-
and
in
this
draft
we
have
added
the
connection
theater
measurement
method
in
the
latest
draft.
K
So
we
have
already
provided
connection
establishment
performance
measurement
methodology
in
the
past
draft,
and
we
have
also
mentioned
some
kind
of
operation
guideline
when
performing
the
packet
folding
benchmark
testing
for
stateful
gateways,
stateful,
not
gateways
when
using
with
a
suit
random
port
numbers.
K
So
we
have
to
manage
to
control
the
size
of
the
connection
tracking
table
entries
and
at
the
same
time
we
have
to
provide
some
reproducible
testing
methodology
for
that
type
of
a
stateful
testing.
So
we
have
mentioned
the
three
points
as
we
I
have
explained
in
the
beginning-
and
this
is
the
latest
draft,
and
so
this
draft
is
focusing
on
the
stateful,
not
xy
gateway
performance
measurement.
K
A
Thank
you
kkg
and
nice
job,
keeping
it
within
time
quickly.
Let
me
ask
if
there's
any
questions
and
if
anyone's
read
the
draft
recently
to
you,
know
sort
of
go
to
the
mic
and
and
comment.
A
And
we've
had
we've
had
pretty
good
commentary
on
this
last
year,
in
particular,.
A
Through
the
may
july
time
frame,
I
believe-
and
so
it's
just
you
know
it's
it's
it's
really
just
a
matter
of
you
know
you
guys
feeling
comfortable
and
and
we'll
try
to
start
a
working
group
adoption
after
we
get
the
yang
model
sorted
out.
I
think
so
any
thoughts
on
that
from
the
working
group.
A
Okay,
well
kind
of
a
quiet
crowd
here
today,
but
that's
all
right
all
right,
so
so
we'll
we'll
we'll
proceed
with
a
with
an
adoption,
call
and
see
how
that
goes
and,
and
hopefully
some
of
the
folks
who
commented
on
the
list
will
we'll
react
to
that
and
and
then
we'll
have
another
another
draft
to
work
on
here
in
the
in
the
group.
But
you
know
you,
you
kg
you
and
gabor
have
kept
up
very
well
with
your
experiments
and
and
that's
great
stuff.
A
All
right
so
next
up
we
have
the
considerations
for
benchmarking,
network
performance
and
containerized
infrastructures
and
I'm
going
to
bring
that
slide
up.
A
All
right
and
minute
tran
are
you:
are
you
with
us
there,
tran?
Yes,
yes,
yes,
I
can
hear
you
just
fine.
Welcome
to
the
group.
I
think
this
is
your
first
time
presenting
as
well
right.
O
O
So
first
a
brief
overview
and
about
our
drafts
of
wrap.
Is
there
to
distinguish
the
band
matching
of
containerized
infrastructures
from
previous
membership
methodology
for
vm.
B
O
O
O
So
our
latest
presentation,
as
itf
even
is,
if
I'm
not
wrong,
is
itf
106..
So,
let's
supplement
our
drop
in
version
three,
and
from
from
that
time,
till
now
see
we
have
multiples
in
it.
So
this
I
give
a
summary
of
the
update
that
we
have
made
to
our
draft.
So
the
first
thing
is
the
old
section
3.1.
That
is
a
comparison
with
the
vmware
infrastructures
and
the
section
4.
That
is
a
bandwagon
scenario
for
the
coding
right
infrastructure.
O
O
So
inside
this
section
we
classify
the
networking
models
based
on
the
district
location
and
the
third
update
is
we
make
the
session
three
by
three
in
version
three?
That
is
resolved
consideration
to
the
new
system?
Five
and
we
rename
it
the
performance
impact
to
show
different
kind
of
resort
configuration
or
deployment
configuration
that
can
make
an
impact
on
the
performance
of
the
container
network.
And
finally,
we
add
a
new
openness
sections.
Also,
our
blemish
link
experience
to
multiple
hackathon
that
we
have
participated
so
far.
Let's
try
this.
O
O
O
So
the
update
is
the
second
update.
Is
a
networking
model
in
category
infrastructure,
so
the
previous
one
is
a
container
networking
classification,
so
in
our
pivot,
graphs
just
include
three
kind
of
model:
the
kernel
space
user
space
srov
and
to
this
draft
we
have
update
two
new
categories:
that
is,
the
ebpf
acceleration
model,
with
notable
use
in
psyllium
and
calico
cli
parking
and
the
model
combination,
and
this
one
is
normally
used
in
service
function,
training
case
where
users
may
be
sweeping
you
for
eastwood
traffic
and
sr
will
be
for
not
such
traffic.
A
Okay,
well,
I
think
you've
got
a
question
there
bill.
Did
you
want
to
want
to
ask
a
question
on
this
on
this
particular
slide.
E
Yeah,
specifically
on
the
combination
model,
did
you
consider
using
beats
directly
between
the
two
containers
for
east-west
traffic
and
eliminating
the
v-switch
altogether.
E
Yes,
let
me
try
speaking
more
clearly
in
the
model
combination
on
the
lower
right
picture.
A
I'll
do
it.
Thank
you,
yeah
it
it
in
the
in
the
physical
world.
It
would
be
like
connecting
a
crossover
cable
between
the
two
ethernet
ports.
Instead
of
going
back
to
the
v-switch.
O
Okay,
so
the
third
update
is
the
performance
impact,
so
in
the
old
section
3.3
we
consider
the
hilpet
new,
magnet,
cpu
acceleration
and
in
this
track
we're
adding
two
new
impact.
The
first
one
is
service
function,
training
and
because
we
see
that
in
every
environment,
physical
network
part,
it
can
be
connected
to
multiple
vna
rather
than
a
single
vietnam,
and
we
consider
two
aspects
in
the
700
chaining
scenarios,
that
is
a
number
of
bnf
inside
chains
and
different
networks,
technology
that
can.
O
O
So
you
tend
to
employ
this
baseline
bgp
only
to
underlay,
so
we
actually
want
to
do
additional
consideration
because
we
haven't
make
a
test
on
it
yet
and
we
plan
to
do
it
in
our
neck
idea.
Hackathon
next
slide.
Please.
A
And
tran
we
got
about
a
little
less
than
seven
minutes
left
so
cover
things
cover
the
most
important
things
in
the
most
amount
of
detail.
Please
thank
you.
P
O
So
this
is
the
summer
of
our
update
from
the
reddit
hackathon,
so
we
make
the
marking
on
the
swift
and
chaining
scenario
where
we
measure
throughput
when
using
srp
comparing
the
bbp,
and
we
consider
two
scenarios
that
the
service
chain
is
single
node
and
silicon
in
matinos.
We
also
bear
match
the
impact
of
the
number
of
vmf
by
increasing
the
number
of
ports
inside
from
2
to
46.
O
O
So
this
slide
saw
the
multi-node
scenario
result.
So
we
observed
that
to
put
in
the
material
scenario
in
slightly
smaller
than
the
single
node,
with
smaller
packet
size
less
than
512,
due
to
the
equine
the
increasing
number
of
ports
and
for
the
like
a
bracket
side
from
like
a
zone
1000,
there
will
be
no
significant
impact
on
the
triple.
O
So
this
is
the
next
step
of
our
draft,
so
first
we
will
try
to
keep
updated
driveway
on
the
latest
technologies
and
in
the
high
carton.
We
we
test
internal
networking
technique
that
we
add
on
on
the
drive.
We
also
want
to
test
the
evp
accession
model
with
and
without
nsc
uploading,
and
we
use
the
result
to
prove
our
personal
features.
A
M
A
Grant
any
any
questions.
I
know
you
went
through
the
the
test
conditions
fairly
quickly
there
and
it's
good
to
see
the
directions
that
you're
going
and
that
you're
you're,
basically
following
following
all
the
draft
scenarios
with
tests
that
you've
conducted
in
the
open
where
people
can
look
over
your
shoulder.
That's
great
any
any
any
comments
on
the
on
the
draft
so
far.
A
All
right,
well,
bill's,
gonna
get
in
touch
with
you
by
email
about
the
the
ethernet
fairing
option,
and
that
might
be
a
way
to
improve
performance
as
well
by
avoiding
the
v-switch
or
the
fee.
So
I
think
that's
that's
something
else.
You
could
try.
A
And
I
mean
one
thing
we
usually
ask
is
how
many
people
have
read
the
draft
if
you've,
if
you've
read
the
draft
and
and
sort
of
want
to
support
this
work,
just
sort
of
raise
your
hand
and
get
in
the
cube
for
a
moment
and
we'll
we'll
be
able
to
see
that
you're
you're
you're
actively
doing
that?
Oh
okay,
good,
fratco's,
ready!
Thank
you.
Vreco.
A
Yeah
this
is
this
is
pretty
close
to
the
to
the
work
that
you
guys
have
been
doing
in
fdio
for
a
long
time.
So
I
would
think
that
this
would
be
a
good
good
place
for
a
cross
pollination
of
your
experiences.
So
thanks
for
thanks
for
that.
I
A
Well,
if
there
isn't
anything
else,
I
think
we'll
we'll
move
on
with
one
last,
thanks
to
you,
tron,
for
for
presenting
today,
good
job.
A
All
right,
giuseppe,
I'm
gonna,
bring
your
first
deck
of
slides
to
the
hello.
Can
you
hear
me?
Yes
yeah?
I
can
hear
you
very
well.
A
A
It
looks
like
we
can
go
with
14
minutes
again.
So
that's
what
we're
gonna
do
and
go
right
ahead
whenever
you're
ready.
I
P
Already
zero
one
version,
since
we
got
some
input
from
luis
from
telefonica
and
we
included
those
swim
as
qualcomm,
so
next
light:
okay,
yeah
just
the
ground
and
the
motivation
for
this
work.
There
is
an
rfc
5695
that
described
the
methodology
for
benchmarking,
mpls
forwarding
device,
while
segment
routing
that
defined
in
rfc
8402
is
applied
to
mpls
data
plane
and
we
found
interesting
to
understand
how
to
benchmark
dsr
mpls
behavior
and
we
didn't
find
a
standard
method
defined
to
compare
and
contrast
the
the
fundamental
sr
and
pls
for
wording
capabilities.
P
P
Yeah
just
a
recap
about
the
sr
mpls
operation,
so
segment
routing
is
applied
to
mpls
architecture,
with
just
a
minimum
change
to
forwarding
plane.
In
particular,
this
a
segment
is
encoded
as
an
npls
label,
and
an
sr
policy
is
instantiated
as
a
stack
of
labels.
P
So
there
are
three
fundamental
operations
for
sr
mpls
that
is
push
next
and
continue
operations.
So
push
consists
of
the
insect
of
the
insertion
of
a
segment
at
the
top
of
the
segment
list.
Next
consists
of
the
inspection
of
the
next
segment
and
the
active
segment
is
completed.
Then
the
next
segment
is
active
and
continue
happens
when
the
the
active
segment
is
not
completed.
So
it
remains
active
next
slide.
P
Yeah
now
we
can
see
what
we
this
draft
can
keep
similar
or
equal
to
rfc
5695.
In
particular.
The
device
under
test
is
connected
to
test
port
and
test
tool
according
to
rfc
2544.
So
not
big
change.
From
this
point
of
view
also,
the
recommended
topology
for
sr
mpls
forwarding
benchmarking
can
be
the
same
as
mpls
so
as
described
in
rfc
5695
for
bot,
single
part
and
multi-portion
areas,
and
also
the
frame
characteristics
can
be
basically
the
same.
We
can
see
some
changes
in
the
next
slide,
but
the
frame
characteristics
can
be
the
same.
P
P
Yeah
in
this
draft,
we
want
to
summarize
just
the
initial
proposal
changed
from
lfc
5695.
So,
first
of
all,
we
need
to
recommend
that
the
device
under
test
support
an
sr
extension
for
dynamic
igp
such
as
isis
spf
or
bgp.
P
That
is
also
given
by
the
rfc
5695
and
in
addition,
there
are
new
parameters
that
need
to
be
specified
and
also
need
to
be
reported,
which
forwarding
operation
so
push
next
or
continue
the
number
of
segments
that
are
considered
so
because
this
may
affect
the
the
benchmark
performance,
also,
whether
global
seed
or
local
seed
are
used.
So
the
forward
which
forwarding
behavior
is
you,
and
also
whether
we
are
talking
about?
We
are,
let's
say,
benchmarking,
an
sr
policy
head
and
or
endpoint
behavior.
P
P
So
the
only
change
is
related
to
the
member
level
to
the
number
of
labels
and
to
the
to
the
structure
of
the
yes,
of
course,
and
also
the
reporting
format
is
going
to
change.
So
next
life
yeah.
What
are
the
next
steps?
So
we
welcome
feedback
from
the
community
because
there
are
some
some
pending
points
that
also
were
raised
during
the
discussion
with
luis.
P
P
In
addition,
rfc
5695,
as
I
said,
includes
only
one
label
in
the
stack,
so
it
may
be
needed
to
test
more
labels
to
support
us
a
policy.
Also
in
this
case
we
may
be.
We
need
to
discuss
how
many
labels
is,
can
be
a
reasonable,
reasonable
number
so
this,
but
in
any
case
the
number
of
labels
must
be
reported.
P
In
addition,
a
good
point
that
was
raised
by
lewis
was
the
opportunity
to
consider
additional
background
traffic
in
place,
so
he
suggests
to
add.
Also
these
scenarios
and
another
point
is
about
the
traffic
engineering
test,
because
we
noticed
that
usually
in
benchmarking,
working
group
traffic
engineering
was
in
a
separate
document.
P
For
example,
we
see
rfc
6894
that
is
separate
from
56
94
5.,
so
also
in
this
case,
your
input
will
be
welcome
to
see
if
we
have
to
include
also
the
traffic
engineering
test
in
this
document,
or
we
can
keep
in
a
separate
one.
P
Of
course,
we
also
are
open
to
new
co-authors
new
contributors
and
welcome
comments.
So
thank
you.
A
That's
great
thanks,
giuseppe
any
any
questions
and
and
comments
at
this
point.
A
Okay,
well,
let
me
let
me
get
things
started
because
I've
read
the
draft
the
one
one
other
thing
I
one
of
the
things
I
saw
is
that
when
it
comes
to
the
throughput
and
latency
and
and
other
measurements
that
that
are,
you
know,
were
originally
defined
in
rfc
2544,
there's
there's
been
some
sort
of
piecewise
updates
to
the
way
these
measurements
are
made,
for
example,
when
when
when
one
of
our
collaborators
here
was
was
doing
the
initial
work
on
state,
you
know
state
transition
and
I
think
it's,
I
think
it's
rfc
8219.,
but
memory
escapes
me
at
the
moment
and
in
any
case
we'll
we'll
get
that
right
number
for
you,
but
the
like,
I
said,
we've
kind
of
been
updating,
rfc
2544
on
a
sort
of
a
section
by
section
basis
and
right
now
the
test
equipment
that
generally
measures
rfc
2544
systems
does
a
lot
more
with
latency
than
the
original
2544
anticipated
that
equipment
could
do
so.
A
You
know
this
idea
of
measuring.
If
you
went
back
and
read
it
giuseppe
you,
you
saw
that
it's
a
measurement
of
a
single
packet,
and
you
know
we.
We
just
can't
stand
that
anymore,
so
you
know
at
least
the
the
test
equipment
that's
out
there
today
will
do
a
like
a
minimum
latency,
a
maximum
and
an
average,
and
we
we
have
some
aspirational
stuff
in
this.
A
I
think
it
you
know
the
the
rfc
that
I'm
talking
about
and
it
would
be,
it
would
be
better
to
to
reference
like
the
latest
latency
measurement
material
along
the
way
here.
So
you
know
I
I
think
a
few
comments
like
that
will
help
so
that
we're
not
kind
of
blindly
referring
back
to
you
know
stuff
from
20
years
ago
we
we
have
made
some
changes
and-
and
it
would
be
good
to
incorporate
those
references
in
the
in
the
in
your
new
draft.
P
E
P
A
And
one
of
the
one
other
thing
I
would
I
would
like
you
to
consider
is:
is
you're.
If
you're
implementing
any
of
these
devices
under
test
in
a
virtualized
world,
virtualized,
networking
and
and
instantiation,
then
you
probably
want
to
take
a
look
at
a
a
a
document
from
one
of
our
sort
of
collaborating
organizations.
That's
the
etsy
network
function,
virtualization
test
working
group.
A
They
have
a
document
which
has
been
updated
fairly
frequently
on
on
benchmarking
in
the
you
know,
in
the
virtualized
test
environment.
So
and,
and
there's
some
good
suggestions
there
about.
You
know
additional
measurements
that
can
be
made,
and
you
know
additional
stuff
on
latency,
back-to-back
testing.
In
fact,
yeah
we
have.
We
have
an
update
on
the
rfc
2544
back-to-back
testing
procedure,
which
I
think
I
think
is
rfc
9002
and
with
that
update,
it's
a
much
more
viable
and
useful
benchmark
to
measure.
A
So
you
might
consider
including
that
as
well.
I
don't
think
I
saw
that
in
your
list
of
benchmarks.
It's
the
back-to-back
frame,
benchmark.
P
Yes,
yes,
I
I
will
look
at
also
this
document
I
yeah.
I
I
saw
that
there
was
this
update
of
rfc
2544,
but
yeah.
I
didn't
have
time
to
to
look
at
it,
but
I
will
do
yeah
and
in
case,
of
course,
the
use
of
the
maybe
an
additional
scenario
of
the
of
the
visualize.
My
machine
is
also
interesting
to
to
be
evaluated.
Of
course,.
A
Yeah
that
that's
kind
of
a
window
for
you
to
you
know,
try
out
some
of
these
tests
and
and
like
you
just
saw
with
in
in
tron's
presentation
and
and
earlier
earlier
today,
with
veraco's
presentation.
I
A
Yeah
the
I
mean
the
this
is
a
testing
working
group
and
everybody
resonates
when
they
see
testing
results.
So
you
know,
if
you
really
want
to
grab
everybody's
interest,
you
know
put
some
graphs
or
some
tables
up
on
the
on
your
charts
and
and
the
blood
will
really
start
flowing
here.
Okay,
yeah
yeah.
Q
P
This
is
just
an
initial
proposal
also
to
to
see
the
interest
of.
Of
course,
we
we
aim
to
improve
and
also
to
receive
your
feedback
because
yeah
we.
P
The
the
possibility
to
benchmark
segment
routing
can
be
a
good
tool
for
operator
or
for
for
people
that
would
like
to
to
deploy
this
technology.
So
that's
why
I
think
it's
important,
but
we
also
want
your
feedback
to
considering
your
experience
to
integrate
and
to
make
the
comment.
The
document
more
useful
for
people.
A
Yeah
yeah
sure
and,
and
my
my
thought
at
the
moment
is
to
keep
te
out
of
out
of
scope
for
now.
Let's
see
what
what
progress
you
can
make
with.
You
know
the
suggestions
I
gave
you
today
and
and
and
actually
running
some
tests.
I
think
that
would
be
good
as
well,
so
no
no
yeah
all
right
and
then
you're
up
for
the
next
one.
Here.
Oh
we
have.
We
have
a
comment
from
eduardo
v.
Please
go
ahead.
R
Okay,
fine,
I
I
have
a
question
to
to
the
working
group
about
background
traffic.
It
may
be
very
different
different.
Do
you
know
anybody
of
you?
Do
you
know
any
rfc
or
any?
Maybe
even
draft
okay
draft
is
enough
where
background
has
been
specified
the
ground
traffic,
because
it's
difficult
to
guess
what
it
could
be.
It
may
be
very
different.
A
Yeah
yeah,
it's
it's
not
typical
that
the
benchmarking
methodology
working
group
talks
about
background
traffic.
Usually
you
know
we're
in
an
isolated
lab
setup.
A
All
the
traffic
is
synthesized
traffic
and
it
comes
from
the
test,
equipment
and-
and
you
know,
and
and
goes
back
to,
the
test
equipment,
and
so
we're
we're
not
really
we're
not
really
sort
of
setting
a
like
a
real
world.
You
know
an
attempt
to.
A
Simulate
real
world
traffic
in
any
way.
It's
it's
all
test
traffic.
Does
that
kind
of
answer
your
question.
R
Okay,
okay
answer:
no!
He
is
the
answer
to
because
yeah,
if
nobody
did
it
before,
then
it
sounds
for
you.
A
The
way
there
is
a
there
is
a
draft,
that's
sort
of
attempting
to
do
that
in
the
responsiveness
measurement
area,
but
that's
in
the
ip
performance
metrics
working
group-
and
I
I
you
know-
I
think
that
you
know
they're
they're
still
trying
to
to
specify
what
it
means
to
have
like
a
working
level
of
load,
and
you
know
they're
they're,
currently
doing
that
on
the
basis
of
good
put
and
an
innovative
algorithm
to
do
that
but,
like
I
said
we're,
we're
we're
not
touching
anything
like
that.
A
So,
but
if
you
go
to
the
ippm
working
groups
agenda
from
monday
first
session,
you
should
be
able
to
find
that
draft
on
responsiveness
fairly
easily
thanks
thanks.
Yes,
sure.
A
Yeah,
it's
I
mean
unless
I
understand
it
better,
I
think
it's
it's
it's
it's
more
more
appropriate
just
to
go
with.
You
know
the
way
we've
done
things
in
the
past
year.
It
seems
like
all
your
references
go
that
way.
So
that's
what
I
would
suggest
so.
A
Piece:
let's
look
at
the
v6
segment
routing.
P
Yeah
yeah,
okay
yeah:
you
can
go
on
next
slide,
maybe
yeah
the
let's
say
the
background
is
the
same,
but.
P
P
By
defining
the
methodology
for
benchmarking
srv6,
so
next,
the
let's
say
in
comparison
with
the
mpls
rfc
now
with
srv6,
there
are
more
changes
to
the
ipv6
architecture.
Also,
if
you
go
in
six
months,
there
was
a
new
draft
that
analyzed
all
the
change
of
the
srv6
to
ipv6
architecture,
because
with
srv6,
a
new
type
of
routing
header
has
been
defined.
The
segment
is
encoded
as
an
ipv6
and
then
sr
policy
is
is
an
ordered
list
of
srv6c
in
the
srh.
P
There
are
three
categories
of
nodes
that,
in
this
case,
are
look
similar
to
the
esr
mpls
behavior,
so
the
source
node.
That
is
the
end
node,
that
steal
the
packet
into
an
nsr
policy.
The
transit
node
that
forwards
packet
as
a
normal
ipv6
packet
and
the
sr
endpoint
node
that
received
packet
was
destination.
Address
is
configured
locally
as
a
segment,
and
so
it
replaced
the
ipv6
destination
address
with
the
new
active
segment.
P
And
in
addition
to
the
basic
srv6
packet
processing,
there
is
also
the
srv6
network
programming
model
that
has
been
defined
in
the
rfc
8986
that
describe
a
new
sector
function,
because
the
128
bit
of
the
seed
can
be
split
into
three
different
fields:
locator
function
and
arguments,
and
the
list
of
behaviors
is
specified
as
a
subset
of
function
that
can
be
also
tested
to
benchmark
the
srv6
network
network
programming
capability.
So
this
is
an
additional.
P
P
Yeah
regarding
the
test
methodology,
also
in
this
case
there
are
some
similarity
with
rfc
51
regarding
80
example.
The
device
under
test
connected
to
the
test
tool
also
regarding
the
test
topology
may
be
considered
the
same
as
in
the
previous
document,
and
the
frame
characteristics
also
be
also
considering
that
in
rfc
5180
there
are
several
considerations
on
the
ipv6
addressing
space
that
can
be
considered.
So
we
can
keep
the
same
consideration
also
here
next
slide.
P
First
of
all,
the
first
change
is
similar,
so
we
need
to
support
extension
for
igp
protocols
that
are
also
defined
in
several
documents,
but
the
first
big
limitation
in
the
nfc
5180
is
that
it
recommends
a
limited
extension
header
chain
for
testing.
P
I
have
reported
that
it
includes
routing
adder
of
maximum
32
bit
bytes
destination
option
adder,
fragment
adder,
and
this
is
not
enough.
Considering
the
typical
scenario
of
the
srv6
deployment,
because,
for
example,
the
length
of
s
h
is
n,
plus
16,
plus
8
bytes,
where
n
is
number
of
segments
and
if
we
consider
a
number
of
segments,
of
course,
that
is,
that
is
greater
than
one
the
limitation
of
and
the
limited
extension
other
chain
of
rfc
5180
is
is
not
enough
for
srv6.
P
So
maybe
we
need
to
do
this
change
and,
in
addition,
we
have
to
add
more
parameters:
the
type
of
nodes,
the
number
of
segments
in
the
sh,
the
characteristic
of
extension,
either
chain
that
maybe
need
to
be
redefined
and
also
the
behavior
in
terms
of
network
programming
model,
as
I
mentioned
before.
Next.
P
Yeah
we
maybe
we
can
skip
this
light
so
for
just
for
sake
of
time.
This
slide
just
described
the
basic
tests
that
are
already
defined
in
ipv6
forwarding
case,
but
need
to
be
added
in
this
new
document,
because
we
have
to
distinguish
between
the
processing
of
sr
source,
node
sr,
endpoint,
node
and
sr
transit
node.
P
P
The
first
point
is
similar
to
srm
pls.
The
second
point
is:
what
are
the
functions
that
we
we
must
test.
So
we
need
to
consider
all
the
behavior
that
are
included
in
nfc89
nfc
8986
are
just
a
subset
of
that
additional
question.
There
is
an
activity
on
compressed
seed,
so
should
we
cover
also
compressed
seed
tests,
but
we
should
consider
that
the
reference
document
is
still
in
progress,
so
we
we
may
add
these
in
a
future
version.
P
R
A
little
bit
comment
more
about
function
because
in
the
service
six
a
function
is
not
just
like
vpn
services
like
layer
3p
and
for
some
transistors
transit
nodes.
There
is,
there,
are
functions
like
and
and
x
and
t
it's
for,
transit
nodes.
Therefore
we
could
not
include
function
at
all
we
couldn't
include,
or
in
in
the
test
function,
which
is
related
only
for
transit
nodes
effectively
for
for
transport
effectively,
and,
of
course,
we
could
include
all
functions
but
all
functions.
R
The
huge
list
which
I
doubt
should
be
included
here,
because
all
functions
is
already
already
vpn
and
vpn
is
a
typically
different.
Different
document,
probably
probably
vpn,
should
not
be
included,
but
about
transit
functions
and
and
x
and
x
is
for
traffic
engineering,
especially
for
index,
because
it's
traffic,
engineering
and
maybe
traffic
engineering
stuff
is
the
different
document.
Maybe
index
should
not
be
included.
I
don't
know,
therefore,
it's
a
question.
A
Yeah,
so
any
response
to
that
giuseppe.
P
No,
this
is
something
that
I
also
put
in
the
slide.
So
what
are
the
functions?
Should
we
consider
only
the
basic
and
then
tax?
Oh.
I
P
Or
those
define
the
complete
list
of
rfc8986
so
yeah.
This
is
something
we
can
do
a
proposal,
but
we
also
need
feedback
to
from
the
community
from
the
operators.
That
is
one
of
the
main
points
that
we
want
to
address,
for
example
by
the
next
meeting:
okay,
more
feedback
from
operators,
yeah.
A
Yeah,
so
I
so,
I
think,
you're
really
going
to
have
to
beat
the
drum
about
this
to
to
get
the
feedback.
You
want
the
quick
feedback.
I
can
give
you
because
we've
reached
the
end
of
our
session
is
you
know:
we've
got
this
reference
through
51
80
to
2544
and
there's
even
less
about
there's
even
less
about
the
actual
procedures
of
throughput
and
latency
and
and
other
forms
of
benchmarking
in
in
the
actual
test
procedures
in
5180.
I
think
it
was.
P
Yeah,
this
will
be
great
if
you
can
point
out
to
these
more
updated
stuff,
more
updated
rfc.
How
we
can
include
and
read,
of
course,.
A
M
P
A
Have
to
say,
I
don't
think,
we've
ever
updated
anything
more
than
once
from
rfc
2544..
So
if
you
find
something
that
updates
2544,
it's
it's
probably
a
good
thing:
okay,
all
right!
Okay!
Well,
thanks
for
those
two
good
presentations
and
good
proposals,
and
I
think
any
other
business
today.
A
No
sarah
any
final
thoughts.
H
Lots
of
things
to
take
a
look
at
lots
of
things
to
read,
so
please
everybody
take
a
look
at
the
drafts.
Feedback's
always
welcome.
Al
often
teaches
us
when
I
first
joined
the
group
hey.
If
you
want
feedback
on
your
draft,
it's
really
easy
to
do
when
you're
reading
others
and
sharing
feedback
on
there.
So
please
take
a
look
share
your
feedback
on
the
list.
It's
always
appreciated.
A
A
Okay,
so
thanks
everybody
thanks
warren
for
standing
in
as
our
delegate
good
to
see
everybody
good
to
see
you
bill,
and
I
know
karee
left
already,
and
but
it's
at
least
good
to
see
you
guys
on
video
a
little
better
than
it's
a
little
better
than
gather
and
we'll
we'll
we'll
talk
to
you
again
on
the
list
and-
and
I
hope
to
see
you
in
the
city
of
brotherly
love,
philadelphia.