►
From YouTube: IETF114 BMWG 20220726 1900
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
Okay,
well,
I
think
we've
got
most
of
the
people
we
need
to
get
the
meeting
started.
Sarah
may
join
us
in
progress.
I
hope
that
she
does,
and
now
she
usually
joins
in
any
case,
so
we'll
welcome
her
when
she
does,
but
I'm
al
morton,
I'm
one
of
the
co-chairs
of
benchmarking
methodology
working
group.
I've
currently
got
a
paralyzed
vocal
cord,
which
makes
me
sound
a
little
different
than
usual,
but
there's
no
there's
no
problem
with
my
trying
to
speak
at
this
point.
B
It
it
just
sounds
funny
and
it
takes
a
little
more
effort
than
usual
so
anyway,
we'll
we'll
take
it
ahead.
Here.
I
see
sarah
joining
us
now
so
today,
as
I
mentioned
a
few
moments
ago,
warren
will
be
our
in
in
the
room
chairman
and
sorted
out
anything
that
we
can't
quite
deal
with
remotely,
but
then
thank
you
very
much
for
standing
in
for
the
both
of
us
again
today.
Warren.
C
B
Oh,
it
sounds
like
the
mic
level
is
kind
of
low
from
the
meeting
room.
I
didn't
quite
hear
what
you
said.
Warren.
B
Oh
okay,
thanks
and
I
thought
I've
turned
up
my
volume
here
too
so
that'll
be
good
thanks.
B
Let's
see
if
you're
currently
not
subscribed
to
the
bmw
g
mailing
list,
we've
got
the
link
right
here,
where
you
can
do
that
and
it's
it's
only
tuesday.
So
we'll
take
a
quick
look
at
the
note.
Well,
as
we
get
going
so
first
off,
we
work
as
individuals.
B
We
try
to
be
nice
to
each
other
and
that
works
that
works
pretty
well.
Also,
at
this
meeting
we
want
everybody
to
wear
their
mask
unless
they're
up
front,
presenting
at
the
podium
or
at
the
microphone
up
front,
and
that's
just
a
safety
for
all
of
us.
So
in
any
case,
I'm
not
I'm
not
showing
video.
At
the
moment.
B
I
want
to
concentrate
on
my
audio,
but
at
some
point
I'll
I'll
open
that
up
in
any
case,
so
the
notewell
is
a
reminder
that
you
know
by
participating
here.
You
have
to
follow
ietf
processes
and
the
contributions
are.
You
know
anything
that
happens
here
in
the
room
talking
in
the
chat
talking
at
the
mics.
B
Those
are
contributions,
slides
the
comments
on
the
slides
and
so
forth,
and
if
you
have
any
questions
about
these,
the
policies
there's
a
long
list
of
bcps
here
that
you
can
look
at
or
you
know
you
can
ask
me
or
sarah
warren
when
peacefully
comes
down
to
you,
know
kind
of
kindly
kind
of,
like
you
know
kind
of,
like
I
said
we're
trying
to
get
everything
covered
here
so
well
there.
It
is
all
right,
so
we've
got
14
folks
with
us.
Now
I'm
gonna
go
on
to
slide
three.
B
B
Agenda,
if
there's,
if
there's.
E
B
In
the
room
who
wants
to
help
help
with
the
notetaker
position,
that
would
be
greatly
appreciated,
we're
using
the
hedge
doc
notes
and
so
far
I
only
see
myself
online
in
there,
but
anybody
can
join
in
and
help
us
type
into
type
in
some
notes
that
will
help
out
with
the
preparation
of
the
minutes.
B
So
if
there's
anyone
who
volunteers
specifically
just
sort
of
raise
your
hand
and-
and
let
us
know
nobody
yet
so-
okay,
but
feel
free
to
join
in
as
we
as
we
do
this
and
so
here's
our
agenda
a
by
the
way
chapters
built
into
the
the
me
tech
host
the
tool
now
and
we've
already
talked
about
ipr,
so
we're
in
good
shape.
B
B
We've
got
a
couple
of
good
proposal
drafts
that
have
been
submitted
and,
under
all
other
business,
there's
actually
been
some
some
progress
on
a
couple
of
drafts
that
we've
we've
talked
about
before.
I
just
want
to
bring
that
up
to
people's
attention
when
we,
when
we
get
done
today,
so
any
bashing
needed
to
the
agenda.
B
Okay,
all
right
very
good,
so
in
the
room,
make
sure
you're
using
the
the
like
the
mobile
meet
echo
tool
to
request
your
access
to
the
floor
mic
and
that
way,
we'll
also
see
you
as
a
participant
and
so
forth.
That
will
be
good,
okay,
so
warren's.
Looking
at
the
agenda,
I
think
you
can.
You
can
get
up
now
warren
and
do
your
thing.
C
Okay
yep,
my
thing's
really
short.
Basically,
it's
hi
everyone,
I'm
currently
up.
Sadie
I've
been
doing
this
for
a
while.
Now
my
role
is
up
at
beginning
of
march
end
of
march,
something
like
that,
I'm
still
enjoying
it,
so
I
will
probably
run
again,
but
I
would
also
be
really
happy
if
there
are
some
other
candidates,
you
know,
so
the
community
can
actually
make
a
choice
this
time.
So,
if
anybody's
interested
in
finding
out
more
about
the
role
or
might
be
willing
to
serve,
it
is
actually
a
lot
of
fun.
C
B
That's
great
thanks
warren.
You
know
one
one
thing
that
has
sort
of
come
up,
which
you
know
it's
been
kind
of
a
question
for
some
of
our
newer
participants
and,
basically,
all
of
our,
I
think,
all
of
our
current.
B
Who
have
drafts
in
the
working
group
or
nearing
completion
may
not
be
familiar
with
your
role
when
the
draft
comes
up
for
the
final
review
in
front
of
the
iesg.
C
C
There's
the
isg
eval,
where
all
the
ads
that
have
reviewed
the
document
and
comment,
another
large
portion
of
it
is
actually
the
isg
reviews,
all
documents
which
get
progressed
so
basically
any
document
which
moves
from
a
internet
draft
to
becoming
an
rfc
ads
sort
of
have
to
review
them
all,
paying
particular
attention
to
conflicts
in
their
area
and
also
sort
of
general
quality,
has
processed
being
followed,
et
cetera
and
then
there's
also
sort
of
four
ops
for
the
ops
area,
managing
around
seven
working
groups,
bmwg
dnsof,
siderocks,
etc.
C
So
the
role
requires
a
fair
bit
of
review,
but
also
quite
a
lot
of
breadth
of
knowledge.
You
know
dns
a
little
bit
of
benchmarking,
routing,
etc.
Did
that
actually
cover
what
you
asked?
The
audio
is
not
great,
so
I
missed
some
of
the
question.
B
C
B
Sorry,
basically,
you
know
when,
when
comments
come
in
from
the
other
area
directors
you
you
take
a
role
in
helping
us
getting
those
resolved,
and
I
wanna
wondered
if
you
want
to
say
a
word
about
that.
C
Yes,
I
do,
I
must
admit,
for
bmwg,
I
have
not
been
taking
nearly
as
active
a
role
as
brian
might
be
able
to
attest
to,
but
I
mean
yeah
a
reasonable
amount
of
it
is
also
sort
of
after
after
iesg
eval.
If
there
are
any
discusses
on
the
document,
part
of
it
is
sort
of
helping
helping
guide
the
document
through
the
last
part,
although
there
is
also
the
responsibility
of
the
document
shepard
but
yeah,
so
having
having
knowledge
in
benchmarking
and
dns
and
cider
ops
and
iot
would
be
very
helpful.
B
B
Really
wanted
to
thank
you
for
all
your
time
as
a
scenario
director
working
with
bmwg.
I
really.
I
really
appreciated
that
when
you
first
took
the
syria
director
role
on
as
and
as
our
our
advisor,
you
started
to
dabble
in
some
benchmarking
to
get
your
feet
wet
in
it,
and
that
was,
I
thought,
really
useful.
B
So
you
know
thanks
for
the
time
you've
spent
so
far
and
now,
obviously
you
know
we'd
really
like
to
have
you
back,
but
you
know
that's
yet
to
be
decided
so
in
any
case,
keep
reviewing
and
keep
calm.
B
Thanks
right
so
on
to
the
rest
of
the
working
group
status,
so
next
generation
firewall,
benchmarking,
is
been
been
in
the
nih
review
since
february,
still
trying
to
resolve
poor
disgust,
ballots,
plus
the
comments.
B
We
got
a
request
for
transport
area
review
again
and
the
good
news
is
a
lot
of
that's
coming
together
in
the
context
of
this
meeting
and
in
the
email
exchanges
in
between
the
march
and
the
february
meeting.
So
you
know,
I
think
that
brian's
gonna
say
some
more
about
that,
but
it
looks
like
we're
pointed
in
the
right
direction.
There
we
can
expect
a
large
rewrite
for
the
multiple
loss
ratio
search
from
maciac
and
brodco.
B
We
did
finally
get
the
yang
model
for
benchmarking,
adopted
we're
going
to
try
to
close.
E
B
On
working
group,
adoption
for
the
statefulnet
xy
gateways
today
and
proposals
keep
coming
so
that
means
keep
reviewing
if
you've
got
proposals
learned
by
by
reviewing
the
stuff
that
we've
already
got
going
and
that
the
you
know
a
good
background
for
you
to.
You
know
what
we're
doing
and
and
what
we
expect
in
the
proposals
that
are
successful
here.
So
just
general.
E
B
To
all
of
our
folks
no
rfcs
in
the
last
period,
our
charter
has
been
very
stable
and
we've
got
this
supplementary
page
that
people
can
go
check
out
thanks
to
sarah
and
company
for
providing
it
so
I've
gone
in
and
looked
at
the
milestones
and
updated
them,
and
so
we've
got
these
new
ones.
I
really
shouldn't
have
made
them
in
red,
but
I've
updated
the
dates
here
for
a
few
of
them
and
there's
one
that's
more
done,
which
you
know
it's
basically
done
since
the
last
meeting.
B
We
still
need
to
to
do
the
you
know
the
publication
part
of
it,
but
this
first
one
here
is
at
least
made
it
to
iesg
review
and
that's
a
good
thing.
The
other
ones
on
our
list
are
done,
and
these
others
have
been
revised.
B
So
we'll.
B
Be
adding
the
yang
model
I
see
is
satisfying
this
one.
The
draft
on
selecting
and
applying
models
for
benchmarking,
and
then
the
other
ones
will
we'll
need
to
take
a
look
at
whether
we
have
something
ready
to
go
or
not.
B
B
Okay,
all
right
so
seeing
none
we'll
move
on
to
the
working
group
drafts
and
for
that
let's
see
here
so.
B
Of
topics
today,
where
we
don't
have
slides
and
what
that
means
is,
I'm
gonna
share
my
screen
somehow
here
it
goes.
B
B
So
can
everybody
yeah,
I
guess
you
can
see
the
wow
okay,
so
everybody
can
see
the
the
muteco
notes
and
the
the
draft
on
multiple
loss
ratio
search.
We
had
a.
We
had
a
detailed
update
from
veraco
one
of
the
co-authors
and
I've
got
the
the
link
pointing
to
that
on
the
mail
list.
B
Basically,
they've
continue
just
a
larger
rewrite
of
the
the
draft
lots
of
earlier
materials
been
commented
out
and
one.
F
B
They've
been
asking,
which
I
highlighted
in
my
response
on
the
list,
was
the
ability
of
the
authors
who
are
trying.
G
E
B
Basically,
trying
to
do
more
work
than
you
know,
the
typical
benchmarking
here
you
know,
they're,
the
typical
throughput
rfc
2544
throughput
is
a
that's,
basically,
a
zero
loss
level
of
throughput,
so
they're
trying
to
measure
throughput
at
multiple
levels
of
loss.
E
B
At
least
when
they,
when
they
measure
the
zero
loss
ratio,
which
is
usually
part
of
the
set,
you
know
that
should
be
a
full
loss
case
and
with
full
support
and
then
kind
of
like
what
they
do
beyond
that
is
sort
of
the
best
they
can
do.
I
guess,
but
if
anyone
else
has
read
the
draft,
anyone
else
has
looked
at
the
email
and
considered
the
questions.
B
Okay,
so
well,
then
you
know,
I
encourage
the
folks
in
the
room
to
sort
of
reach
out
help
the
authors
a
little
bit.
You'll
probably
see.
I
see
the
co-chairs
do
that
and
they
can
make
some
time-
and
you
know
it's
it's
up
for
us
as
a
work
group
to
work
together
and
move
all
the
drafts
forward.
B
The
main
thing
in
that
is
that
helps
us
open
up
some
slots
for
new
work.
So
if
you're
trying
to
get
something
accomplished
here,
help
the
other
folks
out
and
I'm
sure
it'll
be
reciprocated.
That's
the
way
it's
always
worked
here.
So
in
any
case,
thanks
for
that,
and
thanks
for
your
future
collaboration.
B
All
right,
so
the
next
topic
is
which
we
also
don't
have
any
slides,
for
is
benchmarking
and
by
the
way
I
don't
really
I'm
not
really
criticizing
on
this.
It's
just
it's
perfectly
fine
that
we
have
discussions
on
these
topics,
and
you
know
the
information
on
the
security
device
performance
has
been
coming
in
pretty
rapidly
in
recent
days.
So
I'd
like
to
invite
brian
monkman
up
to
the
front
to
you
know,
give
us
a
status.
B
Let
us
know
how
the
side
meetings
have
been
going,
and
you
know
whatever
you
want
to
tell
us
about.
This
would
be
good
brian.
A
Sure,
thanks
al,
so
the
we
plan
to
post
a
new
draft
within
the
next
two
or
three
weeks,
but
there's
been
a
lot
of
work.
That's
been
going
on
behind
the
scenes
since
the
last
ietf,
as
you
mentioned
earlier,
we've
been
working
with
tommy
pauley,
who.
E
A
Helping
us
sort
of
expand
the
draft
to
cover
off
quick
and
http
3
in
a
lot
more
detail
and
I
think
we're
making
some
good
headway
in
that
area.
You
mentioned
the
four
discussed
comments.
We've
we've
addressed
all
of
that,
with,
with
the
exception
of
the
comments
that
lars
put
out
and
we're
we're
dealing
with
tommy
to
help
address
those.
A
There
was
also
some
comments
that
were
made
previously
about
all
of
the
shoulds
that
we
had
in
there
and
we've
identified
a
significant
number
of
the
shows
that
we're
going
to
change
to
musts
or
that
will
expand,
expand
the
text
on
it
to
explain
why
it's
why
it
should
that
will
not
be
in
the
in
the
upcoming
draft,
because
we
wanted
to
get
all
of
the
the
major
points
out
the
door
and
get
the
area
directors
taking
a
look
at
it.
A
But
once
we
get
approval
of
the
changes
that
we
made
with
the
with
all
of
the
discuss
points,
then
we
will
do
the
shoulds
and
it'll
should
be
at
that
point.
No
pun
intended
yeah
it
would.
It
will
be
ready
for
to
move
forward
in
my
opinion
and
shout
out
to
warren.
Thank
you
very
much
for
getting
the
area
directors
to
to
jump
back
on
this
as
well.
B
Yeah,
that's
great
brian.
Let
me
see
I'm
trying
I'm
trying
to
think.
If
I
have
any
specific
questions,
do
you
have
you
have?
Do
you
have
enough
material?
You
need
to
put
in
some
default
values
for
the
like,
for
example,
the
window
sizes
and
things
for
the
other
protocols
that
are
mentioned
in
the
draft,
but
as
you
as
you
mentioned
to
me,
the
test
equipment
currently
doesn't
implement.
Quick.
B
For
example,
I
mean
that
quick
came
in
as
a
as
a
response
to
a
comment,
so
you
know
we're
open,
open
looking
for
help
in
that
regard,.
A
Well,
the
test
test
equipment
does
implement
quick,
but
they
may
not
implement
it
as
per
the
the
standard,
since
the
standard
was
only
about
a,
I
think
was
only
ratified
about
a
month
or
month
or
so
back.
But
we
are
definitely
looking
at
various
references
to
to
address
things
along
the
lines
of
what
you
suggested,
and
you
know
some
decent
reference
sites
that
you
know.
We've
got
links
to.
B
A
No,
I
don't
believe
he
believe
he
did,
but
I
did.
I
did
take
it
as
an
action
that
I
would
forward
him
those
those
sites,
so
he
would
have
an
opportunity
to
take
a
look
at
it
and
I'm
also
thinking
about
how
we
can
reference
those
sites
within
the
draft,
which
is
a
question
that
I
wanna.
I'm
gonna
talk
to
you
about
good.
B
Okay,
all
right
that
was
the
that
was
the
stuff
in
my
mind,
any
other
questions
for
brian.
C
B
Thank
you.
Warren
no
worries.
B
So
I've
got
good
news
on
the
yang
data
model.
We
finally
adopted
that
as
a
work
group
draft.
B
B
H
Hey,
I
appreciate
the
quick
response
of
vladimir
to
the
comments
that
I
left
on
the
list
and
I
didn't
mean
to
imply
that
we
had
to
have
a
yang
doctors
review
so
early,
but
it's
really
good
to
do
because
the
way
it's
written
you
set
it
up
at
the
top
of
the
document
and
then
immediately
get
into
the
yang,
and
so
just
getting
extra
eyeballs
on
that
earlier
is
always
a
good
idea,
but
I
appreciated
the
the
the
easy
read
of
that
and
the
quick
response
to
the
the
comments.
H
If
any
of
you
are
interested
in
the
room
and
haven't
taken
a
look
at
this
draft,
it's
a
really
approachable
draft.
If
it's
your
first
time
to
bmwg
and
you
having
a
yang
experience,
it's
a
really
great
draft
to
take
a
look
at,
as
I
mentioned,
as
you
bring
drafts
into
the
group.
Part
of
how
you
get
other
reviews
is
by
doing
the
same
for
other
folks.
So
this
is
a
really
good
one
to
start
with.
B
Great,
thank
you,
sarah,
and
I'm
glad
I
accidentally
evoked
your
audio,
because
I
couldn't
hear
anything.
So
if
you,
if
you
want
to
request
audio
again,
I
thought
we
heard
you
just
for
a
second.
I
Okay,
good,
yes,
I
agree
with
sarah
and
it's
very
important
if
we
can
find
members
that
are
interested
in
the
draft
and
especially
young
doctor
review,
will
help
we'll
get
at
least
one
more
young
specialist
to
have
his
eyes
on
that
and
we're
looking
to
some
use
cases
like
this
implementation
that
I
have
for
running
codes
that
we
can
use
with
some
third
parties
and
members
of
the
itf
which
are
interested
in
trying
it
out,
seeing
how
it
like
its
usability
and
if
they
have
their
own
use
cases
for
the
draft
which
we
can
support,
eventually
add
to
the
discussion.
I
B
Great
by
the
way,
vladimir,
how
did
the?
How
did
the
hackathon
go.
I
Well,
I
am
going
to
publish
a
presentation
which
always
comes
later
than
the
deadline
for
presentations,
so
I'm
going
to
send
the
link
to
the
mailing
list
and
it's
like
mostly
trying
to
add
the
the
multi-stream
implementation
working
and
trying
it
out,
and
the
funny
thing
is
one
needs.
The
the
multi-stream
implementation
for
the
last
two
test
test
points
in
the
rfc,
which
is
the
reset
test
and
recovery
test
there.
I
B
I
B
E
B
I
don't
see
any
hands,
but
also
that
the
camera
on
the
on
the
audience
is
a
pretty
tight
angle.
So
in
any
case,
thanks
for
your
work,
vladimir
all
right.
B
So
the
next
topic
is,
is
really
closing
out
a
working
group,
adoption
review
and
there's
kind
of
a
long
history
here
for
the
benchmarking
methodology
for
stateful
net
xy
gateways.
B
B
Also
a
couple
of
a
couple
couple
or
three
people
effort
replied
to
the
most
recent
call
for
adoption,
and
so,
let's
turn
it
over
to
gabor
who's
going
to
be
speaking
today
on
the
on
the
draft
gabor,
I'm
gonna,
I'm
gonna
show
the
slides
from
here
after
figure
out
the
right
ways
to
do
this.
F
Okay,
so
I'm
waiting
to
see
my
slides
if
you
can
share
yeah.
F
E
F
Right
now,
thank
you
so
much
I
mentioned.
The
title
of
our
draft
is
a
bit
lengthy,
but
I
think
everywhere
is
important,
because
we
would
like
to
provide
the
methodology
for
benchmarking.
The
space
for
energy
expired
in
place,
xy
means
x
and
y,
both
maybe
4
and
6.,
so
nad44
and
k64
and
even
nh366
could
be
the
gateway,
and
it
is
important
that
we
are
using
rc
4814
saturn
on
both
numbers,
not
fixed
score
numbers
like
both
numbers.
Could
you
go
to
the
next
slide.
F
So
the
aim
of
the
composer
is
to
provide
a
methodology,
how
we
can
benchmark
statefulnet,
xy
gateways
to
to
measure
their
standard
performance,
metrics
defined
by
rfc,
2544,
rfc
or
rfc
8219
like
throughput
the
intensity,
famously
delay
variation
in
the
tech
delegation
and
so
on,
and
and
of
course,
the
title
is
that
this
is
a
stateful
and
I
think
xy
gateway
is
not
not
just
routers
or
reviews
and,
of
course,
because
they're
stateful
they
don't
not
only
have
to
solve
how
to
measure
these
metrics.
F
But
there
are
some
metrics
which
are
specific
to
for
testing.
For
example,
they
define
maximum
connection
instead,
which
moderate
measurement
and
connection
t
direct
measurement
was
the
last
time
and
now
the
new
thing
is
the
connection
taking
capacity
of
capacity
measurements
in
this
today's
slides
and,
of
course
we
have
to
use
these,
so
there
are
no
both
numbers.
F
It
will
be
about
the
history.
Yes,
it
is
about
the
history,
so
it
was
presented
to
us
in
idf
111
with
the
three
world
clan
division
methodology
and
the
next
time
they
defined
the
measurement
of
the
connection
building
table
to
make
clear
measurements,
and
last
time
was
the
connection,
clear
downward
measurement
method
and
now
comes
two
methods:
the
validation
of
conduction
establishment
and
the
next
method
which
uses
this
one
heavily
is
the
connection
tracking
table
capacity,
measurement
method,
and
with
this
I
hope
that
that
the
most
important
things
will
be
completed.
F
So
this
slides
there's
a
few
slides
which
are
reminders,
of
course
reminder
for
those
who
have
already
heard
about
it.
And
if
you
haven't
been
present
in
the
past
idf
meetings,
then
it
may
be
a
new
thing.
F
So
let
me
let
me
just
summarize:
the
parts
which
have
already
been
presented
before
so
test
setup
is
very
simple
for
all
of
you,
because
we
have
one
desktop
and
one
device
under
test,
but,
unlike
this
router
testing,
now
we
have
on
the
one
side,
the
left
side,
private
rb
version
for
addresses
and
public
icon
version,
42
on
the
right
side
and
the
two
ports
of
the
tester
called
initiator
and
responder.
F
This
is
this,
is
their
role
so
initiator
may
initiate
a
new
connection
through
the
facebook
device
under
test,
which
is,
let's
say,
an
mp4
for
gateway.
Now,
because
I
use
happy
version
for
addresses
for
simplicity,
but
it
goes
the
same
for
six
for
another
solutions,
so
the
initiator
just
uses
some
port
ranges
and
sends
frames
through
the
stateful
device
from
the
test
device
and
when
they
are
transmitted
back
to
the
responder,
the
responder
stores.
F
The
four
titles
I
mean
source
active
address,
the
destination
appear
their
source
port
number
extension
port
number
to
their
save
table
and
using
these
four
titles,
of
course,
changes
throughout
the
destination,
it
may
send
a
traffic
back
to
the
states
with
nat
xy
gateway,
because
otherwise
it
couldn't
be
done
because
it
would
just
drop
the
test
stream
which
do
not
belong
to
any
existing
connection.
F
And,
of
course,
when
a
connection
is
initiated,
it
is
stored
in
a
connection
plane
table
with
one
from
the
test
and
which
connections
exist
in
there
that
the
walls
can
be
used.
The
regular
action,
let
me
go
for
the
next
slide.
F
Yes
and
the
measurement
is
done
in
two
phases,
so
the
new
thing
is
the
primary
test
space,
which
serves
two
purposes.
F
Of
course,
we
have
to
fill
the
device
under
tests
for
connection
driven
table
and
also
they
have
to
fill
in
the
state
table
of
the
responder
which
had
four
toppers,
because
from
the
very
first
segment
of
the
of
the
test,
it
has
to
be
eager
to
send
claims
on
in
the
reverse
direction.
F
I
mean
from
the
responder
to
the
initiator,
also
because
we
would
like
to
use
redirectional
traffic
and,
of
course,
this
primary
phase,
which
always
precedes
the
real
test
phase,
but
in
its
past,
terminator
phase
can
be
used
for
measuring
maximum
potential
establishment
rate,
and
if
you
would
like
to
perform
a
traditional
test
like
throughput
train
of
late
latency,
pocket,
deliveration
or
injectable
variation,
it
is
done
in
the
real
test
phase,
which
has
been
considered
by
the
prime
minister
states,
and
they
can
be
done
as
usual.
Will
you
go
to
the
next
slide?.
F
F
One
of
the
situation
is
when
every
time
spending
is
a
new
connection,
it
is
ideal
for
measuring
the
natural
international
establishment
rate,
because
it
is
only
that
it
is
also
necessary
for
the
other
measurements
in
the
community
phase
that
we
have
to
fill
in
the
device
under
tests,
connection
tracking
table
and
the
testers
state
table.
So
it
is,
let
us
say
that,
and
in
the
second
phase,
in
the
real-time
phase,
the
frame
should
not
create
any
new
connection.
F
F
We
need
to
have
a
large
enough
and
empty
connection
telling
table
before
each
test,
and
we
use
the
random
enumeration
of
all
possible
port
opportunities,
the
primary
phase-
and
we
use
the
properly
high
climate
value
in
the
device
of
the
test,
which
means
that
the
final
value
must
be
larger
than
the
length
of
the
primary
phase
and
the
delay
between
the
two
phases
and
the
length
of
the
reactor
space.
Then
the
connection
is
not
not
typo.
F
So
it
was
really
the
reminder
so
far
and
now
comes
the
new
thing.
We
also
repeat
the
measurement
methods
for
the
maximum
connection
transmission
rate,
because
we
would
like
to
refine
it.
Of
course,
it's
very
simple
in
the
primary
phase,
the
in
the
initiator
sense,
n
number
of
we
give
our
photos
that
are
raised
to
the
respondents
through
the
device
under
test
and
the
responder
just
counts,
the
very
few
things
and
of
course
we
use.
We
don't
use
a
multiple
of
patreon
switch,
but
we
use
a
level
of
testing.
F
F
F
The
problem
is
that
we
cannot
prove
that
even
if
a
test
frame
has
gone
through
the
divine
standard
attack
from
the
initiator
to
the
responder,
then
it
is
surely
a
in
an
establishment
of
a
new
connection,
because
we
may
not
examine
directly
the
connection
testing
table
because
we
do
black
box
testing.
So
the
solution
is
that
if
we
do
a
functional
validation
in
the
later
space,
it
means
that
the
responder
uses
all
m4
tappers
stored
in
the
state
table
and
at
the
lower
rate
it
sends
frames
back
to
the
initiator.
F
And
of
course,
if
the
corresponding
connection
is
not
there,
then
the
frame
will
not
arrive
back.
We
need
to
use
a
reduce
rate
so
that
it
may
happen
that
the
frame
is
lost
just
because
the
connection
is
not
there
not
because
we
are
using
a
too
high
rate.
So
this
is
why
we
use
this
vector
one
sub,
which
is
usually
less
than
one,
but
in
some
cases
it
can
be
also
bound.
F
And
of
course,
that's.
Just
a
binary
search
for
the
initiator
comes
the
received
frames
and
the
binary
search
is
done
and
we
do
the
test.
Can
you
go
to
the
next
slide?
There's
some
smash
here.
F
Black
rectangle
is
478
000
connections
per
second
with
dual
n86
for
implementation,
and
then
there
are
some
results
with
different
values
of
foreign.
F
At
the
first
two
columns,
you
can
see
some
degradation
such
as
regulation.
It
means
that
the
trouble
was
that
the
offer
was
too
high,
but
if
you
see
0.5
and
0.25
for
alpha,
in
this
case
the
inner
difference,
of
course,
you
can
see
some
light
side
differences,
because
there
are
computers
and
some
random
events.
It
may
happen
you
can
see
the
medium
is
between
the
minimum
maximum
values
and
there's
a
very
little
difference
from
the
reference
value,
but
actually
we're
going
to
say
that
these
values
makes
no
difference.
F
F
And
this
procedure
is
very
important
because
we
will
have
a
use
this
procedure
for
the
connection
planning
table
proxy
measurement,
which
comprises
of
two
steps.
First,
it
was
xml
search,
exponential
search
to
find
the
order
of
magnitude
of
the
size
of
the
connection
table,
and
then
we
do
find
a
final
binary
first
to
find
this
exact
value.
So
in
some
simple
words,
it
means
that
we
start
with
a
safe
value.
F
Let's
say
we
know
that
for
sure
for
another
experiment
that
one
million
connections
can
be
fully
stored
in
the
connection
training
table,
then
this
double
size
and
we
performed
by
validating
connection
solution
measurement
and
we
measure
with
the
original
per
million
size
and
the
number
with
two
million
signs
and
if
it
seriously
drops
we
have
a
suspect.
We
suspect
that
there's
a
problem
if
it
doesn't
drop
seriously
just
a
little
bit,
then
we
believe
that
two
medium
connections
was
successfully
stored.
F
Of
course,
if
it
is
validated
we
can
know
it
for
sure
and
it
will
store
it
and
then
again
and
once
it
will
stop
and
then
we
have
an
order
of
magnitude
estimation
and
then
we
do
final
bond
research,
which
says
how
many
connections
can
be
released
to
work.
So
these
are
some
some
different
factors
like
authorization.
F
Measurement
and
there's
some
other
values,
data
is
the
reducing
factor
for
the
excellent
cell
search
and
gamma
is
the
reducing
factor
for
the
final
binary
search.
Did
you
go
to
the
next
slide
and
I
don't
want
to
read
this
algorithm
to
the
theoretical
algorithm
of
the
excellent
search
church?
Could
you
go
to
the
next
slide.
F
F
F
F
So
the
first
column
you
see
the
c0
value,
which
is
the
safe
value
for
the
connection
setting
table
size
and
with
that
value
I
measured
the
question
establishment
rate
because
r0
and
then
I
always
doubled
the
sizes
and
the
last
safe
value
was
cf
was
four
million
and
ct
was
when
the
test
failed.
It
was
eight
million.
F
It
was
the
result
so
cs
and
ct
were
the
result
of
the
inference
church
and
then
the
final
binary
search
found,
and
you
can
see
it's
very
exact
so
that
it
was
evaluated
by
these
different
variations
of
the
of
the
results
and
it
fights
quite
good
equipment
with
a
vertical
value,
because
the
hash
size
and
the
nf
conduct
max
size,
which
means
the
size
of
concentrating
table,
was
2
to
the
power
of
22,
and
we
just
found
nearly
the
same
value.
We
didn't.
But
if
you
narrow
it
up
to
the
next
slide,.
B
Okay,
great
thanks
to
gabor,
and
thank
thank
you.
When
you
talk
to
him.
B
You
know
you
guys
have
both
been
working
on
this
then
some
others
as
well
with
their
comments,
I
noticed
a.
I
noticed
a
comment
come
through
in
the
chat.
It
is
better
to
have
an
example
picture
that
is
based
on
ipv6,
not
ipv4.
B
This
is
the
comment
that
comes
from
edward
v
and
edward
is
one
of
the
other.
As
a
co-author
of
one
of
the
other
drafts
that
we're
gonna
talk
about
today,
I
think
so.
What
do
you
think
about
that?.
F
So
originally
this
this
thing
was
done
for
an
an
m80,
a
faithful,
n864
tester.
So
for
me
it
would
be
much
more
natural
to
use
ip
version
6
drawing,
but
I
just
wanted
to
help
others,
because
I
used
to
version
4,
but
I
can
replace
it.
I
have
I
have
the
drawing
and
in
some
paper
I
use
both,
but
I
will,
if
you
want,
I,
I
will
replace.
B
B
Maybe
maybe
the
best
thing
to
do
is
have
both
and
that
way
it
satisfies
everybody.
Okay,
okay
and
one
word
of
one
word
of
input
from
me,
and
that
is
be
sure.
You
use
the
the
address
space
that's
allocated
to
bmwg,
but
it
exists
both
in
the
in
the
v4
space
and
the
v6
space,
and
you
know
that
way.
We
can
avoid
problems
with
the
supposedly.
E
B
Avoid
problems
with
the
nit,
checkers
and
stuff
like
that,
so
just
a
word
to
the
wise.
You
know:
there's
address
space
allocated
for
benchmarking
in
both
v4
and
v6.
B
B
B
Okay
and
yeah
edward
has
edward,
has
put
in
some
additional
comments
there
identifying
the
slash
48
for
bmwg
use
with
v6.
So
thank
you.
B
Let's
see
did
oh,
I
see
somebody
at
the
microphone
here
and
then
the
problem
is
I've
got
like
oh.
E
B
Oh
there's
two
people,
so
I
think
I
think
the
first
one
in
the
queue
is
is
thomas.
Go
ahead,
thomas.
J
Thank
you
very
much.
I
just
would
like
to
briefly
inform
this
community
that
I
am
an
fpga
expert
and
I
recently
joined
to
the
changi
university
activities
on
the
subject.
In
fact,
mr
lynch's
team
and
my
project
will
be
to
implement
the
currently
running,
cperf
and
other
softwares
and
fpga
environment.
J
J
This
development
board
is
appropriate
to
start
to
re-implement
the
currently
running
the
project
in
a
different
framework
which
is
fbga
based,
and
the
expectation
is
that
we
are
going
to
implement
all
the
features.
What
gabor
just
mentioned
in
this
presentation
and
even
the
performance
will
be
much
higher.
Unfortunately,
at
this
point
I
cannot
give
you
any
exact
numbers
or
estimates,
because
we
are
right
at
the
beginning
of
this
project.
J
B
Very
good
thanks
for
your
report,
thomas
and
well.
Let's
make
sure
that
there's
always
kind
of
like
an
implementation
section
in
the
drafts
that
should
you
know,
have
some
sort
of
reference
to
what
you're
doing
there,
and
that
makes
it
easy
for
us
to
find
it.
What
we're
talking
about
yeah,
okay,
kind
of
the
end
game
here
when
you
know
eventually
when
we
get
to
approval,
but
I
think
that's
that's
the
ultimate
kind
of
support
for
the
trap
that
somebody's
burning
these
things
at
the
fbgas.
B
Thank
you,
okay,
timothy.
I
think
you're
next.
E
Hi
tim
winners,
qa
cafe,
I
I
want
to
answer
two
of
these
questions.
One
of
them
is
I
I
do
think
this
should
be.
A
working
group
document
support
that
and
then
the
second
part
of
this
is
I
want
to
review
this
for
the
metrics
missing
so
as
part
of
that
process.
I'll
take
a
long
look
at
this.
We
do
a
lot
of
testing
of
stateful
gateways,
I'm
sure
there's
some.
We
can
put
some
thought
into
this
on
our
side.
E
So
I'll
put
my
name
down
to
review
this
draft
as
part
of
the
adoption
process.
B
Thanks
very
much
tim,
I
appreciate
you
stepping
forward
to
to
jump
in
and
join
us.
This
is
your
first
time
with
bmwt.
E
No,
no,
no.
I
used
to
do
a
lot
of
netsec
open
used
to
work
with
brian
and
some
of
that
stuff.
I've
been
a
participant
for
some
time
in
a
variety
of
different
ways:
yeah.
B
Yeah
I
thought
I
I
thought
I
recognized
you,
but
the
picture
is
really
small
from
here
so
and
I
see
you
got
your
v6
t-shirt
on
there.
So
thank
you.
B
Okay,
well,
I
think
that
you
know
my
goal
of
kind
of
extending
the
importance
of
adoption
through
the
live
meeting
here
has
kind
of
been
met.
B
We've
seen
a
number
of
people
respond
after
the
original
document
of
the
original,
the
adoption
period
closed
and,
of
course
I
was
one
of
them
and
I
think
a
total.
E
B
Four,
after
after
the
period
closed
so
and
then
a
couple
I
think
before
it
closed,
so
that
that
feels.
K
B
Like
we're
going
to
have
enough
people
paying
attention
here
for
a
view
to
make
this
adopt
this
as
a
as
a
working
group
document,
anything
anything
you
want
to
say
on
this
topic,
sarah.
H
Yeah,
I
agree.
I
also
am
a
little
tardy
with
my
replies
and
I
had
giving
gabor
the
feedback
that
I
would
do
that
today
and
I
agree
there's
a
lot
of
enough
interest
here
to
adopt
this
on
list
and
again.
Thank
you,
timothy
for
the
the
extra
attention
you're
going
to
put
on
this
as
well.
Well
excited
to
see
this
move
forward.
Good
job
y'all.
E
That's
that's
a
good
thing.
E
B
All
right,
okay,
so
then
our
next
topic
up
is
the
proposals,
and
now
we're
going
to
see
a
couple
of
related
drafts
on
segment
routing.
The
first
one
is
on
mpls
segment
routing
and
today,
apollo
volpado
will
be
presenting
the
draft
paulo.
This
is
your
first
time
presenting
here
so
welcome
to
the
group
and
I'll
bring
your
slides
up
here.
Momentarily.
L
Okay,
so
thank
you
good
afternoon
my
name
is
paolo
volpato.
I
am
with
huawei
I'm
presenting
this
draft
on
behalf
of
the
authors
you
see
listed
here,
so
people
from
huawei
and
telefonica
luiz
by
the
way
is
sitting
at
the
back
of
the
room
and
said
by
ali.
It's
my
first
appearance
at
the
benchmarking
working
group.
So
I'm
happy
to
be
here,
and
hopefully
this
is
the
start
of
a
long
cooperation.
L
Okay,
so
just
to
give
you
a
bit
of
the
background
of
this
draft
and
also
of
the
other
that
my
colleague
edward
will
present
just
in
a
few
minutes,
so
we
started
from
rfc
5695.
So
basically,
this
is
the
benchmarking
for
a
an
mpls
capable
device.
L
L
So
we
combined
sad
capability
of
5695,
together
with
the
architectural
framework
of
segment
routing
and
specifically,
the
sr
mpls
flavor
of
semi-rooting
defined
by
rfc
8402,
trying
to
provide
a
method
for
benchmarking,
nasara,
mpls
capable
device,
so
we
need
to,
let's
say,
complement
5695
with
some
more,
let's
say:
mechanisms,
some
more
procedures.
So
that's
why
we
provided
this
draft
dedicated
to
the
benchmarking
of
sr
and
pls,
and
clearly
we
based
our
work
on
25
44
in
the
newer
1904.
L
B
A
just
a
question
there
apollo,
when,
when
you
guys
were
thinking
about
filling
this
gap,
was,
was
anyone
asking
for
benchmarking
of
products
in
the
in
the
segment
crowding
space
that
you
know
caused
you
to
want
to
do
the
work
more
formally.
L
B
B
More
like
it's
more
like
where
people
asking
for
benchmarking,
you
know
to
benchmark
their
products
or
testing
the
products
without
doing
formal
benchmarking.
To
this
to
the
need,
did
you
guys
recognize
a
need
from
the
industry,
as
well
as
a
gap.
L
Oh
yes,
the
answer
is
definitely
yes
and
at
least
clearly
I
can
speak
it
just
for,
let's
say
the
two
organizations
that
for
the
moment,
support
the
drafts
of
telefonica
and
huawei.
If
you
just
consider
huawei
as
a
vendor,
telefonica
is
an
operator
as
an
operator.
We
definitely
think
that
this
effort
is
worth.
You
know
our
work.
L
We
are
filling
a
gap
in
the
industry
and
that's
why
we
are
proposing
such
topic
here.
But
of
course
we
are
open
to
any
feedback
from
you,
as
I
said,
I'm
quite
new
to
the
to
the
work
group.
So
probably
I'm
still
a
bit
fresh
to
this
extent.
So
I'm
really
happy
to
take
also
your
your
feedback.
L
B
Just
checking
on
you
know
that
really
we
need
more
than
a
gap
in
the
bmw
g
literature,
to
kind
of
get
things
going
and-
and
I
think
you've
kind
of
answered
the
question
that
you
know
if
an
operator
and
a
supplier
see
the
need
to
do
this.
That's
a
good
place
to
start.
L
L
We
received
quite
a
few
comments,
in
particular
from
the
chairs,
and
we
we
thank
the
chairs.
We
acknowledge
the
value
of
those
comments
just
to
be
very
quick
on
my
recap:
we
reviewed
the
test
methodology
because
probably
was
still
missing
at
that
time.
So
in
the
first
version
of
our
draft
we
also
added-
let's
say
some
more
capability,
I
would
say
so.
We
develop
new
sections
on
the
protocol,
addresses
the
duration
of
a
test
how
to
verify
it.
L
L
And
by
the
way,
we
have
also
put
references
to
rfc
904
and
also
the
work
done
by
etsy
about
the
virtualization
of
some
functions,
where
you
may
also
employ
segment
routing
and
by
the
way,
for
the
moment,
we
have
decided
to,
let's
say,
leave
out
of
the
scope,
the
transport
of
services,
on
top
of,
let's
say
in
sr
mpls
connection.
L
B
B
B
The
one
reference
to
the
etsy
test
document
that
should
actually
be
tst009.
E
B
Seven
is
a
conformance
and
interoperability
spec,
whereas
testers
or
nine
comes
up
in
the
draft
as
getting
some
help
for
when
the.
E
B
E
B
2544
for
virtualized
devices
under
test
in
the
you
know
in
the
virtual
machine
and
the
containerized
world,
so
I'll
just
try
to
set
you
straight
on
on
that
for
the
moment.
But
please
take
a
look
at
that
because
I
think
there's
a
lot
of
good
advice.
There.
L
L
First,
we
have
to
let's
see,
continue
following
the
approach
of
having
multiple
ports
on
our
device,
so
the
packet
forwarding
engine
may
distribute
packets
across
all
the
ports.
We
have
also
to
take
into
consideration,
let's
say
aspects
such
as
over
subscription,
so
we
have
to
take,
let's
say
care
of
that.
L
The
idea
is
that
the
test
should
be
bi-directional,
but
clearly
one
as
the
option
to
let's
say
to
split
the
upstream
from
the
downstream
flows
and
then,
as
also
suggested
by
the
chair.
Let's
say
that
even
if
it's
not
fully
developed
at
the
current
stage,
we
have
also
to
consider
the
availability
of
a
virtual
machine,
so
the
softwareized
version
of
a
function
handling
srmpls-based
packets.
L
Okay,
we
have
also,
let's
say
to
consider
something
that
it's
useful
for
the
industry.
So
this
is
one
of
the
reasons
why
we
see
the
gap
at
the
moment
for
not
having,
let's
say
a
benchmarking
guideline
for
sr
mpls
and,
as
I
said
also
services
later
explained
by
edward,
so
for
running
the
test.
We
need
to,
let's
say:
choose
a
protocol
for
label
distribution,
so
we
have
provided
a
list
for
test,
could
be
igp,
bgp
or
other
ways
to
let's
say,
distribute
the
policies
differently
from
5695.
L
We
will
consider
more
than
one
label
and
the
reason
is
that,
let's
say
otherwise.
We
are
not
fully
exploiting
the
capability
of
srm
pls.
It
is
true
to
do
so.
We
should
have
in
mind,
let's
say
a
service,
but
for
being
ready
to
support
all
the
capabilities
supported
by
srm
pls.
The
idea
is
to
have
at
least
two
labels
corresponding
to
two
seeds:
two
segment
identifiers.
L
Such
that
the
outer
label
will
be
in
the
future,
considered
as
the
entry
point
for
carrying
a
service.
As
I
said,
and
then
we
have
also
to
let's
say
deal
with
a
the
mtu
of
the
packet.
Clearly,
we
need
to
consider
four
bytes
per
label.
So
that's
why,
as
you
see
here,
we
we
have
to
add
at
least
five
bytes
more
to
the
packet
because
differently
from
the
base
mpls,
we
have
two
seeds,
so
two
labels,
so
basically
eight
bytes
for
the
label
stack.
L
B
It's
good
to
calculate
or
to
to
catalog
these
differences
from
56.95
and
why
you've,
why
you've
had
to
make
these
choices?
That's
excellent
material.
Please
continue!
Sorry
for
the
interruption.
L
Clearly,
we
have
also
to
think
about
how
to
provide
the
result
of
the
test
so
for
the
reporting
format,
new
parameters
have
to
be
considered.
You
see
the
full
list
so
just
to
let's
say
going
very
quickly
through
the
items
the
number
of
ports
we
are
using
for
the
test.
As
I
said,
we
need
to
consider
the
full
capability
of
the
packet
for
warning
entry
and
maybe
also
over
subscription
the
possible
differences
between
upstream
and
downstream,
so
the
proportion
of
the
traffic
we
split
between
the
two.
L
What
types
of
srmpls
operation
we
are
dealing
with,
probably
you
are
already
aware:
srmpls
is
based
on
three
operations.
Push
next
continue.
We
will
discuss
in
the
next
slide,
but
just
to
anticipate
the
topic.
Basically,
they
are
corresponding
to
the
different
operations
supported
today
by
base
mpls
with
some,
let's
say,
differences,
the
number
of
labels,
so
the
the
depth
of
the
protocol
of
the
label
stack.
So,
as
I
said
at
least
two
two
seeds,
two
labels,
how
we
instruct
the
device
to
build
the
label
stack.
L
So
we
need
to
also
take
care
of
the
policy
that
should
be
considered
within
the
framework
of
the
test,
the
type
of
the
payload,
the
the
protocol
used
for
label,
distribution
and
clearly,
if
there
is
maybe
somebody
interested
with
that
we
take
for
granted
that
we
are
using
just
ethernet
connectivity,
but
in
case
other,
let's
say,
media
formats
can
also
be
used.
L
I
will
say
next
slide.
Unless
there
are
questions
here
and,
as
I
said,
srm
pls
is
based
on
three
fundamental
operations.
The
push
operation
is
corresponding,
as
the
name
implies
to
the
label
push.
So
basically,
we
instruct
the
device
of
putting
in
front
of
the
packet
couple
of
labels
so
to
to
let's
say
place
as
the
overhead
of
the
packet.
A
label
stack.
The
next
correspond
to
the
label
pop-up.
So
as
it
happens
in
base
mpls
today,
and
then
they
continue,
which
is,
let's
say,
the
equivalent
of
the
label
swap.
L
Clearly,
more,
let's
say:
more
information
can
be
found
in
rfc
8402.
The
basic
architecture
of
the
southern
pales,
and
I
will
say,
that's
it,
so
we
can
move
to
the
next
slide,
which
is
our
conclusion
basically
we'd
like
to
let's
say:
listen
for
you
if
there
is
interest
in
working
on
such
item.
L
B
Good,
thank
you.
So
paulo
you've
asked
the
right.
B
The
we.
B
Some
folks
in
in
bmw
g
to
step
up
and
basically
to
say
you
know,
I've
read
the
draft,
it's
a
decent
draft
and
provide
some
comments.
But
first.
B
E
B
And
that
was
a
great
improvement,
so
thanks
for
doing
that,
that
was
based
on
the
comments
from
last
time.
Around
so
does
anybody
volunteer
to
review
the
draft
today
or
you
know
like
clear
the
draft
for
the
future.
B
B
Knowledgeable
feedback
today,
paulo,
so
maybe
when
boris
posts
his
comments,
it
will
draw
the
interest
of
others
as
well.
So
thank
you
to
your
co-authors
and
contributors
here
for
a
nice
piece
of
work.
B
D
Welcome
good
day,
everybody
about
our
second
slide
deck,
because
the
same
people
have
developed
the
same
two
drafts.
For
the
reason
the
style
is
the
same.
The
scope
is
the
same,
but
the
technology
is
a
little
bit
different.
For
that
reason,
the
text
is
a
little
bit
different,
because
srv6
is
is
a
little
bit
different
from
srmpls.
D
I
would
like
for
start
to
answer
a
question
from
our
chair
about.
Is
it
really
important?
I
could
prove
that
for
srmpls,
it's
even
too
late.
Why?
I
believe
it's
it's!
It's
it's
even
late
because
look
about
a
few
thousands,
maybe
two
two
point:
five
thousands
of
telco
already
has
moved
from
old
style
mpls
to
srmpls
and
for
telco
world.
D
It's
typically
important
and
is
typically
mandatory
to
test
any
new
technology
before
adoption,
and
for
that
reason
already
about
2.5
thousands
of
tests
for
srm
pls
did
happen,
and
it
means
that
we
are
a
little
bit
late
with
our
test
test
plan
for
a
service.
6
situation
is
not
so
urgent,
it's
a
little
bit
better
because
for
service
6,
we
know
that
worldwide,
already
250
something
like
250
projects
in
developments.
D
Some
projects
already
in
production
style
state
some
projects
are
still
in
test
and
preparation,
but
it's
250
now
and
250
tests
already
has
been
done
for
a
srv6.
It's
probably
means
that
250
tests
already
done
worldwide.
It
probably
means
that
we
need
a
test
plan.
We
need
benchmark
methodology
to
explain
how
to
do
properly
this
test
plan,
and
for
that
reason
it's
probably
a
good.
A
good
evidence
that,
if
250
tests
already
has
been
done,
probably
should
be
the
discussion
in
atf
about
how
to
do
it
properly.
D
Okay
about
the
basement
here,
the
basement
here
is
a
little
bit
different
because
of
course,
of
course,
the
primary
basement
is
our
primary
benchmark.
Fc
2544,
of
course.
Of
course
it's
a
it's
really
a
primary
one,
but
but
additionally,
because
service
6
is
ipv6,
we
need
to
take
care
for
lfc
5180
for
ipv6
benchmark.
D
Benchmark
methodology,
but
in
reality,
because
it's
in
behavior
of
services,
like
behavior
srps
in
reality,
we
need
to
inherit
many
things
from
mpls
benchmarking
from
rfc
5695.
Therefore,
it's
it's
a
mix.
It's
a
mix.
There
are
some
number
of
things
which
are
unique
for
services,
but
in
fact
it's
a
mix
of
combination
of
things
which
is
taken
from
ipv6
and
which
is
taken
from
mpls
benchmarking.
D
D
We
have
excluded
from
the
consideration
because,
from
our
point
of
view,
the
methodology
is
already
more
or
less
big,
I
mean
draft
is
more
or
less
big
and
looking
to
the
other
drafts,
which
we
have
seen
for
benchmark
working
group,
we
have
decided
that
probably
it's
enough,
probably
we
have
big
enough
scope
and
we
have
excluded
from
the
scope,
traffic
engineering
and
we
have
excluded,
of
course,
services
vpn
services,
for
example,
because
then
the
draft
would
be
extremely
big
and
and
as
we
as
we
have
seen
before,
from
benchmark
working
group.
D
Typically
such
things
as
traffic
engineering
and
services
were
in
separate
document,
and
for
that
reason
we
we
follow
the
typical
style
of
benchmark
working
group.
From
the
previous
version,
we
could
say
that
we
have
changed
like
facermpls.
Here
is
the
same.
We
have
changed
something
like
from
my
point
of
view.
Forty
percentage
for
zero
forty
percentage
of
text
has
been
changed.
We
really
did
a
major
major
change
if
somebody
has
read
it
before
forget
about
it
and
read
again,
because
we
have
really
changed
a
lot
next
slide.
D
Please,
okay,
what
is
really
maybe
new
here.
You
may
be
different
from
mpls
and
ipv6
benchmarking.
D
As
for
all
other
benchmarking
rfc,
we
assume
that
configuration
of
label
stack
or
seed
stack
here
will
be
automatic,
will
be
by
some
protocol,
isis
or
spf,
or
maybe
segment
routing
policy
which
is
effectively
bgp
or
pc
pc
pcp.
We
assume
that
it's
not
manual
configuration,
of
course,
it's
possible
manual.
We
permit
it
as
an
option,
but
we
recommend
that
it
should
be.
D
It
should
look
like
a
real
situation
should
look
like
a
real
protocol
will
populate
prop
tables
like
for
previous
srmpls
here
for
services.
Of
course,
we
are
trying
to
ask
that
recommended
way
to
insert
at
least
two
seeds
at
least
stack
from
two
seed,
because
if
it's
just
one
seed,
it's
it's
not
a
stack.
It's
it's
not
it
look.
D
It
looks
not
reasonable,
but
but
here
there
is
a
big
difference
between
the
service
six
and
sr
mpls,
because
in
the
7pls
every
label,
every
seed,
every
label,
mpls
label
will
give
you
just
one
hop
or
one
interface.
It's
a
it's.
It's
really
one
next
scope,
one
next
interface
in
v6
case.
It
could
be
two
because
in
in
in
service
six,
the
seed
could
be
splitted
for
three
parts,
and
first
part
is
a
node.
Next
part
is
a
function.
D
The
last
part
argument
is
not
is
not
important
right
now,
but
the
first
part
could
be
the
node,
and
it's
it's
already
the
instruction
where
to
forward,
but
after
the
node
part
inside
the
same
seat
could
be
the
part
which
is
responsible
for
so-called
function
and
sometimes
sometimes
function,
especially
for
traffic
engineering,
could
could
have
name
and
dot
x,
for
example,
and
if
it's
n.x
it's
effectively
the
number.
It's
next
scope.
D
Interface
number
it's
effectively
next
next
next
interface,
and
then
it
means
that
effectively,
one
seat
has
two
instructions,
one
how
to
reach
the
node
and
one
how
to
go
out
of
this
node
on
the
next
scope
and
because
it's
not
related
to
services,
it's
related
to
infrastructure.
We
have
decided,
despite
that,
it
is
a
little
bit
traffic
engineering.
It's
it's
used
for
traffic
engineering.
We
have
decided
to
include
it
in
the
consideration
we
have
included
it
in
in
the
discussion.
D
It's
a
little
bit
disputable
because
look!
It's
it's
not
services!
Okay,
it's
fine,
but
it's
for
traffic
engineering
in
the
future,
but
we
have
included
this
because
without
this
it's
not
proper
test
from
our
point
of
view
of
srv6.
D
Of
course
we
have
corrected
here
the
side,
mtu
and
heather
sizes,
because
here
we
have
additional
heaters,
eight
bytes
for
srh
heater
itself
and
the
additional
16
bytes
for
every
seat
for
for
every
ipv6
address
which
is
inserted
in
inside,
and
if
people
will
would
like
to
test
more
than
two
seats,
for
example,
it's
optional,
but
it's
possible,
then
the
header
could
be,
could
be
big
and
we
have
calculated
properly
and
put
recommendation
about
this
point
that
the
size
is
different.
D
Okay,
of
course,
because
we
have
included
here
a
little
bit
additional
discussion
about
upstream,
downstream
proportion
about
relationship
between
port
numbers
and
pep
because
look
in
the
current
world
there
is
no
one-to-one
relationship
between
port
device
port
device
under
test
port
and
pc.
Typically,
one
pv
is
capable
to
serve
a
few
ports
and
to
really
test
something
on
modern
box.
You
need
to
really
test
all
ports
related
to
one
pc.
You
really
need
to
stress
one
pt,
because
the
pvp
is
very
flexible.
D
If
you
will
stress
just
one
port,
the
pv
will
throw
to
you
much
more
buffers.
You
will
test
wrong
numbers
because
you
will
get
much
better
latency
much
better
performance
than
it's
possible
for
for
load
when
all
pv
ports
are
loaded
and
for
the
reason
we
have
a
discussion
inside
that.
Okay,
we
have
a
discussion
how
to
understand
what
is
the
relationship
between
ports
and
pve,
because
in
fact
you
need
to
stress,
not
port,
you
need
to
stress
pv
and
after
you
will
stress
pt.
D
Of
course
you
need
to
document
which
one
particular
port
has
been
used.
The
same
discussion
about
armstrong
upstream
downstream
like
before,
and
here
we
have
a
little
bit
again
different
names
which
is
used
for
srv6
operations.
For
that
reason,
it
has
been
reflected
in
the
document
and,
of
course,
number
of
seats
seats.
D
How
big
seed
stack
should
be
documented,
of
course,
and
what
particular
protocol
has
been
used
to
populate
seed
stack
is,
of
course,
should
be
discussed,
and
for
that
reason
the
reporting
points
a
little
bit
extended
because
it's
like
for
sr
mpls
more
points
to
to
mention
next
slide.
Please.
D
It's
very
it's
very
similar
to
what
we
have
for
mpls,
but
a
little
bit
different.
Here
we
have
so
called
source
node,
which
really
creates
a
seed
stack
and
hd
srh
header.
Okay,
fine,
then
we
have
endpoint
node
endpoint
in
reality
is
not
final.
Final
end.
It's
a
intermediate
end
point
I
would
say
because
what
it
means
it
means
that
this
is
this.
Endpoint
will
change.
The
destination
address
will
copy
address,
from
top
of
for
from
from
the
point
of
srh
and
change
the
pointer
to
next
one.
D
It's
effectively
like
like
swap
swap
operation,
but
there
is
no
here
swap
operation
because
in
the
middle
we
don't
change
headers,
we
just
change
destination
address
and
we
change
entry.
Entry
point
in
the
srh
stack
and
transit
node
transit
node
is
something
new.
Not
not
present
is
is
a
srmpls,
because
transit
node
is
a
just
ordinary,
ipv6
node,
which
may
not
understand
srv6
at
all.
D
Just
ipv6
and
transit
node
just
look
to
destination,
address
and
forward
the
only
thing
which
is
important
for
transit
node
not
to
drop
the
packet
which
has
bigger
headers,
so
a
bigger
mtu
because
additionally,
srh
heater
is
attached
and
transit.
Node
just
should
not
pay
any
attention
to
this
srh
here.
The
routing
header,
because
he
is
not
transit.
Node
is
not
destination
for
this
particular
srh,
but
anyway
it
should
be
tested
because
performance
may
be
affect
affected
additional
heater
extension
here
the
performance
may
be
affected.
D
Everything
may
be
affected
for
the
reason
it
should
be
tested.
Okay,
probably
that's
it
next
slide.
D
Okay,
because
we
really
spent
more
or
less
big
amount
of
time,
and
we
did
everything
possible,
we
have
changed
a
lot,
the
draft.
In
reality,
we
don't
have
any
more
idea.
What
to
dd.
D
We
have
investigated
all
potentially
potentially
related
rfc
from
benchmark
working
group
and
all
potentially
related
revision
drafts
from
spring
working
group
and
a
few
other
related
working
groups
to
understand
the
full
picture
to
not
to
miss
anything
not
to
miss
some
some
important
things.
But
after
such
investigation
we
have
populated
everything
in
the
draft
and
and
now
we
don't
have
an
idea
how
to
improve
it
better,
and
for
that
reason
any
input
is
very
welcome
and
maybe
it's
a
time
for
adoption,
because
in
general
it's
it's
needed.
D
I
mean
the
problem
exists
and
because
the
problem
exists,
the
text
of
course
could
be
could
be
discussed.
Of
course,
if
somebody
believed
that
somebody
should
be
changed.
Of
course
we
will
change.
No,
no,
no,
no
question,
but
it
looks
like
we
did
everything
possible,
at
least
for
people
who
who
really
participated
in
this.
B
B
Thank
you
edward.
Let
me
ask
a
follow
up
to
your
final
response.
There
have
you,
have
you
done
any
testing
with
the
procedures
that
you've
currently
outlined
in
the
draft.
D
Not
exactly
for
this
one,
but
I
have
participated
in
a
couple
of
tests
of
srv6,
but
because
typically
different
telco
different
carriers.
They
have
different
requirements.
What
they
would
like
to
test,
and-
and
for
that
reason
it's
not
exactly
it's
not
exactly
the
same.
The
similarity
may
be,
maybe
40
or
50
percentage.
D
This
one
is
more
or
less
general
and
in
particular
situation
people
would
like
no
particular
things.
For
that
reason,
I
would
not
say
exactly
the
same,
but
maybe
50
percentage.
D
B
Maybe
maybe
one
of
the
things
we
could
encourage
is
for
people
to
try
out
this,
this
version
of
testing
and
that
will
reveal
the
kind
of
the
areas
for
additional
development
that
you're
looking
at
and.
B
B
Really
two
sources
where
we
might
get
the
inputs
that
you're
looking
for
so
let
me
open
it
up
to
the
floor
now.
Is
anyone
willing
to
sort
of
try
this
draft
out
in
you
know
on
the
test
bench
or
is
anybody
willing
to
just
just
review
it
and
provide
comments.
B
Okay,
louise
please
go
ahead.
G
Yes,
hello,
so
well.
B
G
Go
for
the
draft.
We
are
planning
some
testing
after
the
summer
in
europe
and
to
be
honest
by
now,
the
we
don't
have
yet
a
clear
mapping
of
the
the
the
what
we
can
do
in
the
from
the
draft
to
the
testing,
but
well
the
idea
or
the
commitment
that
I
comment
here
would
be
to
trying
to
match
what
we
will
do
with
what
is
in
the
draft
and
report.
Probably
coming
back
for
itf-115
reporting
what
we
did
and
and
what
is
then
we
we
use
the
content
container
on
that
testing.
G
B
And
gabor.
F
B
Yeah
yeah,
it's
summer,
everybody
gets
to
take
august
off
if
they
want
to.
K
Yes,
hello
same
as
gabor,
also
after.
B
K
B
B
All
right:
well,
I
think
we've
been
able
to
get
you
some
good
potential
reviews
at
edward
and
the
team.
So,
oh,
when
I
see
somebody
else
at
the
at
the
microphone
there.
E
D
I
don't
fully
understand
the
question,
because
it's
it's
more
or
less
new
draft
and
exactly
this
draft
has
not
been
tested,
but
the
people
who
developed
this
draft
has
experienced
before
for
different
many
many
other
different
tests,
and
for
that
reason
we
just
use
our
techno
our
knowledge
about
second
places
rv6,
and
we
have
used
our
knowledge
about
test
itself
because
tested
cell
has
been
done
many
times
with
the
for
different
things,
and
we
have
created
a
new
draft
and
this
exactly
new
draft
has
never
been
tested.
I
I
was
asking
if
the
current
draft
had
had
been
tested
so.
E
B
Okay,
any
other
questions.
B
All
right
well,
thank
you,
edward
and
and
the
co-authors
again
for
your
your
excellent
work
here,
much
appreciated
and
thanks
everyone
for
contributing
to
the
discussion.
B
And
yeah,
boris,
okay:
I
got
that
one
in
there
too,
good,
okay,
so.
E
E
B
B
I
just
wanted
to
mention
a
couple
of
items
under
all
other
business.
A
couple.
E
Of
a
couple
of
meetings,
essentially.
B
Like
two
meetings
ago,
we
talked
about
problems
and
requirements
for
benchmarking,
the
leo
clow
earth
orbit
space
technologies
on
connections
with
terrestrial
networks.
The.
G
B
B
Communications,
many
people
probably
know
that
eln
musk's,
a
company,
has
been
launching
satellites
like
crazy
they're,
aiming
for
you
know,
really
large
constellation
and
right
now
the
constellations
are
fairly.
E
B
But
that
will
likely
change
over
time.
So
there's
some.
You
know
some
some
interesting
feedback
to
give
here.
If,
if
you're
involved
in
this
work
and
also
the
considerations.
B
Network
performance
in
containerized
infrastructures,
that
team
I
mean
really
both
these
author
teams
are
in
the
far
east.
So
this
is
like
the
absolute
worst
time
zone
for
them,
and
so
they
can
be
forgiven
for
not
trying
to
come
in
and
do
a
live
presentation
this
time.
But
the
virtualized
performance
or
containerized
performance
team
participated
in
the
hackathon
and
they
were
doing
some
very
interesting
work
on
express
data
path
and
the
the
berkeley
backward
packet
forwarding
that
you
know
the
current.
B
The
current
the
new
kernel
express
data
path.
Xtp
makes
possible.
So
I
encourage
you
to
take
a
look
at
that
and
I'm
gonna
follow
up
with
them
to
basically
to
try
to
get
them
to
share
some
stuff
on
our
mailing
list.
So
we
can
show,
as
we
can
see
the
advancement
of
this
work,
and
everybody
should
take
a
look
at
that.
If
you
have
interest
in
this
containerized
infrastructures,
oh.
B
B
Since
we're
on
the
topic
of
virtualized
benchmarking
same
comment
to
you,
it's
test,
009,
not
testers
or
seven.
B
B
I
think
that
we've
heard
from
a
lot
of
draft
center
development
here
and
we've
heard
from
a
lot
of
drafts
that
are
nearing
the
end
of
the
road
and
drafts
that
are
successfully
joining
the
the
working
group
as
as
part
of
our
ongoing
work.
So
I
really
appreciate
everybody's
contributions
today
appreciate
barn
for
standing
in
for
us
up
front,
letting
us
know
letting.
A
B
Know
what
it's
like
to
do
his
job
and
to
everybody
for
your
attention
this
afternoon.
Anything
to
add
sarah.
H
A
big
plus
one
as
usual,
you
do
a
great
job
with
that
al
and
yes,
thank
you,
warren
for
stepping
in
and
helping
us
on
site
and
everybody
for
making
this
move.
It
works
so
smoothly
in
such
a
hybrid
environment.
It's
nice
to
see
folks
on
camera,
it'll
be
really
nice
to
see
you
guys
in
person.
Soon,
thanks
for
a
good
meeting,
y'all.
B
Hey
you're
welcome
and
I
hope
to
see
everybody
in
london
after
after
this.
I
think
I
feel
like
they
owe
me
one.
I
was
going
to
go
until
last.
I
was
going
to
go
until
last
last
week
and
monday,
and
you
know
things
changed
too
fast,
so
apologies
about
being
able
to
make
it,
but
I
should.
C
B
A
better
voice
by
london,
too,
we'll
see.
Okay,
everybody.