►
From YouTube: IETF102-ROLL-20180717-0930
Description
ROLL meeting session at IETF102
2018/07/17 0930
https://datatracker.ietf.org/meeting/102/proceedings/
B
A
C
Good
morning
miss
vinegar.
This
is
such
the
wrong
session.
I
wanted
to
start
I
want
to
say
that
anus
hopeless,
unfortunately,
is
between
jobs
and
couldn't
comment,
but
I'm
very
happy.
That
DK
is
here
well
known
from
the
group
communication
drafts
disappear,
sending
an
ace.
Thank
you
again
for
assistance
here
is
the
note
well
sheet,
please
note:
well,
if
things
go
wrong
and
all
the
work
of
the
working
group
goes
to
nowhere,
that
would
be
very,
very
much
regretted.
C
C
No
wishes
very
good,
then
the
milestones
for
the
moment
everything
is
green.
There
is
just
the
proposed
augment
this
flux
and
options,
which
is
late
and
I.
Think
they'll
remain
late,
so
you
see
later
how
we
have
to
handle
that,
but
for
the
restoration,
very,
quite
green
milestones,
the
active
internet
drafts.
We
have
the
end
of
the
RPL
which
we'll
discuss
today
the
do
projection
which
we'll
discuss
today.
There
is
the
forward
selection,
which
is
on
hold
I,
don't
know
when
it
will
go
further.
It
depends
on
the
interest
later
on.
D
Hi
I
wanna
run
ad
before
I,
say
anything
I've
been
on
vacation
for
three
weeks:
I,
maybe
forgot
half
of
anything,
so
this
may
not
make
all
the
sense
yes,
I've
been
reading.
This
I
am
about
halfway
through
the
document.
There
are
some
concerns
that
I
have
around
some
of
the
updates,
and
some
of
the
things
are
not
really
clear
as
to
why
we
need
to
update
specific
documents.
What
do
we
do
with
the
compression,
for
example,
where
the.
D
The
RPI
is
not
specifically
signaled
meaning
when
you
decompress,
for
example,
how
do
you
know
they're
using
23
and
not
63
at
the
other
end,
so
about
halfway
through
there
I'm
getting
close
to
use
cases
which
I
hope
will
be
a
lot
faster,
because
it's
okay,
this
use
case
you
can
say
here
there
so
I'm,
hoping
there.
The
next
row
say
two
or
three
weeks
after
the
ITF
I
should
be
done
with
that
and
be
able
to
send
comes
back.
D
C
It
thank
you
very
much.
It's
a
long
and
complex
document,
I've
seen.
Okay.
Then
we
have
to
meet
boyoung.
We
will
discuss
it
today.
It
is
one
of
those
young
models
which
are
asked
for
I
hope
that
there
will
be,
and
some
if
you
later,
on
the
be
a
design
team
takes
her
offer.
It
will
be
our
first
subject
for
today
and
we
will
have
NP
Deo.
C
Then
we
have
the
unaware
lives
which
will
be
discussed
today,
which
is
still
impacted.
The
ripple
observations
which
we
have
called
for
adoption
has
been
started
and
you
have
the
other
private
valves
who
shall
be
discussed
today.
Any
questions
about
that.
No,
there
are
open
tickets,
they
be
able
handles.
It
has
been
promised
buying
a
bus
companies.
D
F
That
helps
folks
were
able
to
figure
that
out,
because
from
here
it's
no
now
here,
okay,
cool
right
so
and
then
basically
the
idea
was
that
there
there
seemed
to
be
a
lot
of
interest
in
the
room
and
we're
saying:
okay,
let's
do
a
design
team.
So
since
then,
unfortunately,
not
a
lot
of
progress,
so
I
got
through
all
the
bureaucracy
from
the
ITF,
with
the
help
of
albro.
F
So
we've
got
a
working
group,
mailing
list
name
so
just
normal
non
working
group
mailing
list
with
an
archive
and
everything
got
a
wiki
page
on
track
with
the
Charter
that
had
to
be
approved
by
the
area
director,
so
that
you
can
get
the
mailing
list.
But
then
really
not
a
lot
of
activity,
except
for
me
trying
to
reach
out
but
didn't
get
any
response
then,
but
I
also
had
you
know
something
like
more
than
a
month
or
it
or
two
where
I
couldn't
do
anything
so
in
the
following
slides.
F
What
I'm
going
to
do
is
my
own
analysis.
What
I
did
try
to
figure
out
and
then
at
the
end
we
can
see
how
much
more
interest
there
is.
So
I
was
trying
to
figure
out
what
are
the
most
interesting
high
level
points,
because
I
think
Pascal
has
been
doing
a
pretty
good
job
at
the
bottom-up
stuff.
In
terms
of
you
know,
how
could
we
bring
it
together
from
the
protocol
level
and
I
have
still
absolutely
no
clue
about
ripple
signaling,
so
on
the
signaling
side,
I
can't
really
contribute
at
this
point
in
time.
F
So,
let's
let
me
first
talk
about
bloom
filters
and
hopefully
Karsten
isn't
going
to
be
e
to
death
about
it,
but
I'm
trying
to
be
as
a
serious
understand
it,
and
hopefully
you
know
I'm
understanding
things
incorrectly.
So
the
first
thing-
and
you
know
maybe
this-
is
there
a
way
to
bling
it
out
now.
Okay,
sorry
way
too
much
text.
This
is
this
is
much
more
meant
for
people
after
the
IDF
to
read.
So
let
me
start
from
the
bottom
right,
so
how
an
IP
multicast,
what
you
basically
be
building,
try
to
control.
F
You
know
500
lights,
right,
let's
say
every
light
is
you
know
an
end
point
on
the
network
it
has
associated
with
it.
You
know
whatever
IP
address,
or
so
an
IP
multicast.
What
you
would
need
to
do
is
you
phone
a
multicast
group,
all
the
lights
join
to
it.
You
come
up
with
an
application
protocol
in
the
application
protocol.
You
would,
for
example,
give
every
light
a
bit
and
then
you
basically
sent
down
in
the
application
a
bit
string.
F
F
If
you
can
do
beer
end-to-end
up
into
the
application,
so
you
can
basically
send
a
beer
packet
with
you
know
the
15
bits
set
that
represent
the
lights,
that
you
want
to
switch
on
or
off,
and
you
basically
don't
need
IP
multicast
for
it
now
that
type
of
end-to-end
beer,
I,
think
is
really
the
coolest
thing
about
beer
and
we
haven't
been
dealing
with
it
and
I,
don't
think
we're
still
not
dealing
with
it.
Officially
in
the
beer
working
group,
the
chair
can
update
me
on
that.
I
haven't
been
following
I'd.
G
Say
you're
writing.
We
have
been
specifically
gone
after
that
with
drafts.
It's
been
Oh,
Greg,
Shepherd,
Cisco
and
I'm
the
beer
one
of
the
co-chairs
for
beer,
but
it
is
been
in
our
sights
since
the
beginning
and
finally
getting
the
ethertype
was
that
big
step
in
that
direction?
We've
had
feedback
from
from
countless
operators.
Who've
said
the
same
thing:
we've
heard
things
like
I
want
to
get
rid
of
multicast
from
data
center
to
desktop,
so
that
is
and
then
and
have
been
able
to
do.
G
F
So
the
word-
and
that's
basically
what
I
had
at
the
top
of
the
slide.
So
basically
when
beer
started
the
obvious
use
cases
where
multicast
was
done,
a
lot
was
basically
multicast
and
service
provider,
which
is
just
as
an
underlay
for
IP
multicast.
That's
why
all
the
standardized
work
is
really
focusing
on
that
use
case.
There
is
one
draft
where
you
know
we're
trying
to
outline.
F
Also,
you
know
in
to
the
end
into
the
post,
or
you
know,
application
layer,
gateway
native
end-to-end
use
of
beer
and,
and
so
the
benefits
of
that,
so
that
that's
mentioned
there.
So
that's
really
the
cool
thing
about
beer,
which
I
think
you
know
way
beyond
the
point
of
trying
to
reduce
the
amount
of
state
because
of
non
storing
mode
or
so
I
think
would
be
cool
to
think
about
as
being
beneficial
in
the
IOT
space.
Where
ripple
sits
right,
because
I
would
hope
that
applications
like
what
I
was
mentioning
about.
F
You
know
Building
Control
and
others
where
you
have
group
communications
and
one
I
efficiently
send
individual
commands
to
a
subset
should
be
well
in
scope
of
really
the
use
cases
of
networks
with
ripple.
So
okay,
what
does
it
got
to
do
with
bloom
filters?
Well,
the
bloom
filter
is
unfortunately
not
exactly
the
same
bits
as
the
ones
you
want
to
address,
but
it's
a
superset
of
them
right.
F
F
D
Say
it
so
in
the
constrained
cost
draft,
the
bloom
filter
is
not
for
identifying
in
notes
right.
It's
for
identifying
forwarding,
notes,
sure
and
that's
why
it's
so
key
that
it
occasionally
has
false
positives,
because
a
little
bit
of
additional
forwarding
in
multicast
orders
is
not
going
to
hurt.
You
very.
F
Much
right,
which
is
which
is
again
the
question:
what
is
it
that
we're
trying
to
achieve
right
so,
and
you
know
the
be
a
working
group
lives
perfectly
with
use
cases
that
don't
do
end
to
end
beer
I'm.
Just
the
fan
of
end
to
end
Pierre
and
I
was
just
trying
to
explain
the
differences
and
the
impact
of
bloom
filters
to
it
was.
H
Catchable,
the
one
advantage
of
beer
in
the
particular
case
of
repo
is
that
storing
mode
is
usually
not
so
successful
in
small
devices
because
of
the
amount
of
state
that
you
have
to
keep
and
using
beer
allows
us
to
keep
a
state
per
child
as
opposed
to
a
state
for
a
leaf.
And
that's
a
humongous.
F
So
the
other
problem
of
the
the
bloom
filters
and
that's
where
you
know
I'm
not
very
sure
because
of
missing
detail,
understanding
about
ripple
and
everything,
and
that
is
that
there
is
a
basic
mechanism
in
the
you
know:
you're
working
group
forwarding
for
beer
and
beer
te,
which
is
about
resetting
bits,
and
that
is
done
to
avoid
duplicates
and
it
is
done
to
avoid
loops
and
so
obviously,
because
we're
indicating
hop
by
hops.
It
is
more
of
a
problem
here
to
Ethan
in
beer,
so
and
I
was
trying
to
figure
out.
F
D
F
F
D
F
I
mean
yeah,
so
those
basically
are
the
main
things
that
you
know.
If
you
want
to
update
the
draft
right,
I
think
that
would
be
good
to
have
as
highlights
better
understand
it,
because
just
from
reading
the
draft
was
difficult
to
figure
out
these
high
level
points
for
me
right.
It's
just
getting
into
the
yeah.
H
Quick
information
and
ripple
is
that
ripple
is
loop
less
not
because
the
dag
is
going
T
to
be
completely
converged
at
any
time.
That's
wrong!
It's
never
really
convert.
We
don't
have
a
concept
of
convergence
in
report.
That's
one
of
those
things
that
is
basically
different
from
other
routing
protocols.
F
That's
it
I'm
getting
closer
to
this
stuff,
so
here
with
me
in
terms
of
but
okay,
that's
fine,
so
we
yeah
yeah,
yeah
but
I
think
the
the
duplicate
that
you
can
get
with
the
bloom
filters.
That's
certainly
a
concern
that
you
know
needs
to
be
really
understood
in
terms
of
whether
they
feasible
for
deployment
or
not
right
so
yeah.
It's
just
the
quantification
of
all
these
parameters.
D
F
D
F
D
D
That's
one
observation
and
of
course
the
other
observation
is
if
we
can
put
in
a
little
bit
of
mechanism
to
reduce
the
impact
of
that,
that's
good.
Let's
be
why
we
came
up
with
a
sequence:
nirvash
is
still
the
local
to
the
path
from
the
root
node
to
the
receiver.
So
it's
not
necessary
to
put
anything
into
the
hosts
to
do
this.
F
So
second
point
so
that
was
basically
about
bloom
filter.
Now
the
rest
I
think
is
in
general
about
the
non
bloom
filter
things
so
right.
So
basically
repeating
the
the
basic
point
that
you
know,
the
hop-by-hop
would
be
good
to
support
the
non
storing
mode
and
then
the
question
of
course,
is
how
long
do
we
make
the
bit
string?
Pascal
came
up
with
crazy
numbers,
or
maybe
good
numbers
I,
don't
know
right,
so
definitely
not
the
boat.
F
The
exponents
of
two
that
we
had
in
the
beer
working
group,
560
bit
or
so,
and
so
defining
the
size
right
has
been.
You
know
big.
You
know,
Greg
could
talk
better
to
this
question,
going
back
and
forth
in
the
be
a
working
group
because
it's
based
to
make
it
work
on
a
six
right.
So
you
make
a
very
long
bit
string,
especially
with
beer
te.
F
That
would
only
come
in
here
and
roll
when
we're
saying
we
want
to
use
it
really.
As
you
know,
a
simple
way
of
shall
I
sell
segment
routing
right
instead
of
a
hop
by
hop
path
with
a
single
bits
right
just
for
unique
as
if
we
use
it
that
way.
So
the
way
I
would
see
it
a
good
way
to
deal
with.
That
is
to
recognize
these
things
and
then
say:
ok
for
multicast
right.
We
can
have
a
really
really
large
bit
string.
F
Just
compare
the
bend
did
say
you
know
you
have
2000
note:
okay,
let's
a
2000
bit
string
right.
How
much
is
that
compared
to
sending
multiple
packets
right,
because
you
don't
have
a
hardware
limitation
to
look
into
a
large
bit
string
right.
So
it's
not
difficult
to
figure
out
the
three
or
four
bits
of
your
adjacencies
or
ten
or
twenty
from
a
2048
long
bit.
String
I
would
contend
on
a
software
note
right
and
sure
there
is
overhead.
F
H
F
F
Are
also
ways
around
it
right,
but
then,
if
we're
thinking
about
unicast
right,
I
think
there
is
a
very
simple
way
to
reduce
the
the
bit
string
size
and
that
is
obviously
very
simply
to
say.
If
we
only
unicast
well,
we
only
need
to
have
bits
for
the
actual
topology,
not
for
the
receiver
node.
We
just
need
to
have
the
logic
that
the
last
hop
router
basically
just
looks
up
the
encapsulated
destination,
IP
address
or
whatever
and
basically
knows
which
of
his
directly
connected
hosts.
It
wants
to
send
the
unicast
traffic
right.
D
F
No,
what
I'm
saying
this
is
about
sorry.
This
is
point
two.
This
was
not
about
filters
anymore,
I'm,
saying
when
I'm,
not
compressing
the
bit
stream
I
think
I
can
reduce
the
bit
string
size
by
really
only
carrying
the
interface
between
routers,
because
when
you
don't
have
a
bit,
you
can
easily
come
up
with
a
rule
that
says
okay.
So
now
my
next
connected
hop
is
going
to
be
looked
up
through
looking
up
the
unicast
address
in
the
IP
header.
Follow
you
right,
I.
D
Came
up
here
just
to
talk
about
the
use
case,
so
the
reason
we
developed
this
was
the
the
control
problem
think
about
lighting
systems,
where
you
want
to
talk
to
a
few
dozen
light
bulbs
at
the
same
point
in
time
and
the
actual
payload
we
have
there
very
small.
So
we
actually
expect
the
payload
plus
the
network
overhead,
including
the
bloom
filters
to
fit
into
180
215
for
Packard,
which
is
128
bytes,
and
you
have
to
remember
that
of
the
worst
128
bytes
you
can
use
about
72
84
actually
useful
things
so
already.
D
F
Of
outside
I'm,
just
trying
to
bring
in
you
know,
alternative
approaches
to
deal
with
the
bits
now.
Obviously,
if
the
control
is
exactly
to
control,
you
know
a
subset
of
endnotes
I
would
say:
end-to-end
beer
and
yes,
every
EndNote
or
interface
to
an
end.
Note
what
need
to
have
a
bit
but
I'm
saving
all
that
space
at
the
application
layer
of
the
payload
right.
And
if
that's
not
what
I'm
wanting
to
do,
then.
F
Basically,
you
know
for
the
unicast,
for
example,
I
can
save
bits
and
basically
come
up
with
two
bit
string
sizes,
one
larger
one.
You
have
less
payload
for
multicast,
one
short
bit
string
size
just
for
the
intermediate
one
unicast,
you
have
the
shortest
possible.
You
know
network
header,
so
those
and
you
can
have
them
together.
Right
I
mean
that's,
that's
not
an
issue.
Yes,.
H
I
think
there's
a
lot
we
can
do
in
particular
for
unicast.
There
are
two
aspects
that
I
really
want
to
discuss
your
for
unicast
to
just
matter
of
it.
You
don't
have
don't
think
that
you
have
to
place
the
bitmap
in
the
packet.
That's
wrong.
It
is
virtually
it's
there,
but
now
you
think
that
everything
we
put
in
the
packet
is
compressed.
There
is
six
leverage
of
things
like
that.
So
what
is
the
sixth
edge
for
a
unique
as
bitmap?
H
H
And
so
the
other
thing
is
oh:
if
I'm
using
bits,
then
then,
if
I
have
256
bits
all
of
a
sudden,
I'm
screwed
if
I
want
to
have
257
nodes.
Well,
no,
because
when
you
send
a
bitmap,
you
can
always
say
I
eliminate
the
heavier
zeros,
so
you
can
grow
it
by
just
dynamically.
It's
just.
Can
I
transport
that
in
a
compressed
fashion?
So
the
key
thing
here
is
how
you
express
the
compressed
fashion,
but
you're
not
limited,
but
no.
F
The
IP
address
it's
just
that
you
know
I
think
from
the
simple
things
right,
so
this
one
I
know
deterministically
how
many
bits
I
need
right
on
the
far
end
is
the
bloom
filters
where
I
would
like
to
see
a
lot
more
statistics
now
you're
talking
about
loss,
free
compression
of
a
bit
string
that
somewhere
in
the
middle,
but
also
something
where,
for
example,
topologies.
We
would
need
to
run
the
numbers
right.
F
H
F
But
I
think
you
know
the
these
high-level
choices
that
we
make
right,
I
think
what
we're
trying
to
figure
out.
What
is
the
minimum
set
that
you
know
we
can
focus
on
that
gives
us
the
you
know,
best
return
for
the
investment
right
and
the
less
we
can
come
up
with
that,
the
more
we
need
to
be
broader
in
what
we're
specifying
and
standardizing,
and
that's
ultimately
going
to
be
more
work.
Then
right,
yeah.
D
F
F
Right,
which
actually
is
this
slide
right
so
I,
think
the
the
question
is
to
me:
what's:
what's
the
method
of
signaling
right
and
the
way
I
understood
it?
There
is
a
lot
of
history
in
in
in
rippln
and
much
of
the
signaling.
Also,
being
you
know,
EndNote
driven
right
going
up
to
the
root
and
there's
obviously
signal
from
the
root
as
well.
F
I
would
be
saying
that,
especially
if
we're
doing
the
TE
stuff,
where
we're
basically
trying
to
engineer
something
on
the
path
like
you
know,
we
have
multiple
alternative
paths
going
downstream
and
we
need
to
figure
out
which
particular
traffic
uses
this
person,
the
other
so
could
be
arbitrarily
complex.
Trying
to
load
share
the
traffic
right
if
I'm
already
having
that
much
centralization
on
the
route
with
with
all
the
policies
involved.
F
It
would
certainly
be
very
you
know
in
line
if
also
the
signaling,
for
the
assignment
of
the
bits
to
the
output
interfaces
was
driven
by
the
route,
because
then
I
can
do
cool
things,
for
example
like
make
before
break
assignment
of
bits
like
I
want
to
renumber.
Okay,
I
first
assign
new
bits,
but
I'm
not
using
them.
For
the
traffic
once
they're
established,
I'm,
basically
starting
to
sent
with
these
bits
now
I
remove
the
other
bits
right.
F
So
it
allows
me
to
have
very
smooth
reliable
mechanisms
that
are
very
hard
to
replicate
if
I'm
trying
to
do
a
distributed,
signaling
stuff
from
the
receiver
nodes,
so
yeah,
encapsulation
compression,
so
I
mean
you
folks
already
have
a
lot
better
ideas
on
that.
Why
don't
you
bring
them
up
on
the
design
team
mailing
list
right?
F
What
was
I
trying
to
say
here,
yeah
so
I,
don't
understand
the
existing
header
compression
schemes
right,
but
if
I'm
trying,
for
example,
on
the
things
that
I
do
understand
to
make,
for
example,
this
crazy
stupid
bet,
IP,
multicast
applications
work
together
with
beer
and
compress
it
right,
then
I
think
I
would
I
would
assume
that
the
number
of
multicast
groups
that
I
actually
need
is
fairly
small
right.
I
might
only
have
a
single
group
for
a
particular
multicast
group.
Like
all
these.
You
know,
lightbulbs
and
I
still
use
the
bit
string
right.
F
The
loss
free
compressed
bit
string
to
indicate
for
every
individual
picot
what
the
receiver
is.
So
the
IP
multicast
is
just
a
shim
to
the
stupid
receiver.
Application
that
doesn't
know
beer
right.
That's
just
receiving
its
multicast
packets
because
of
the
multicast
group
and
the
only
guy
I
need
to
be
able
to
set
and
deal
with
bits.
Is
the
application
integrated
or
near
the
root
node
right.
So
that
way,
I
don't
need
to
upgrade
my
receivers.
F
They
still
have
multicast,
but
I
need
a
small
number
of
multicast
groups,
and
so
I
can
extremely
compress
the
destination
multicast
IP
address
of
the
packet,
maybe
just
two
down
to
four
bits:
I
have
you
know
16,
you
know
multicast
application.
The
network
good
forever
right
there
just
to
show
the
most
extreme
case.
I
can
think.
Oh
yeah.
D
F
F
F
D
F
F
We
all
have,
you
know
at
least
I
and
a
few
other
I
think
some
lying
around
draft.
We
didn't
bring
into
beer
in
terms
of
the
API
how
to
do
these
things.
So
that's
what
we
would
need
to
pull
up-
and
probably
you
know
not
even
resolve
here
but
in
the
beer
working
group,
but
I
think
what
the
beer
working
group
definitely
wants.
Is
somebody
standing
up
and
saying:
where
have
the
use
case?
We
want
it
and
if
that's,
what
role
is
saying
then
you
know
might
require
a
chartering.
D
F
So
right
so
I
and
I
think
this
obviously
is
is
the
the
ongoing
thing
that
we
need
to
finalize
writing
down
in
terms
of
recommendations
right,
so
beer
te
approach
required
for
storing
mode.
True
I
mean
that's
my
current
understanding,
sorry
nan,
storing
mode
right
so
the
bit
for
each
of
the
outgoing
interfaces.
Do
we
do
or
do
we
have
a
solution
to
just
do
it
with
beer
without
the
bits
I
think
we
needed
for
the
non
storing
mode
right,
yeah.
F
No,
no
but
I
think
you
know
on
one
hand
we
can
try
to
simplify
and
you
know,
streamline
whatever
terminology
one
a
half
but
the
more
we
stick
to
what
he
has
already
is
there.
So,
for
example,
you
called
the
word
in
the
header,
for
you
know
a
particular
set
of
a
string
not
a
set
by
the
group
right,
so
that's
different.
Then
it's
called
in
the
in
the
beer
working
group,
so
I
think
that's
unnecessary
I,
like
group
better.
But
you
know
the
beer
working
group
has
chosen
a
different
word.
So
just
the
terminology.
C
F
The
closing
remark
would
really
be
that,
so
there
are
a
lot
of
cool
things
we
can
do,
but
really,
if
we
can,
if
you
folks
know
some
example
topologies
with
between
not
even
need
to
be
real
world
kind
of,
is
exactly
but
kind
of
the
largest,
a
good
midsize,
a
minimum
right.
A
few
topologies
with
the
constraints,
then
I
think
we
can
each
try
to
map
our
preferred
options
into
that
and
then
Express
how
better
the
appropriate
solutions
would
be.
F
C
H
H
Our
protocols
today
is
already
done
like
that,
like
if
you
want
to
have
a
shot
at
rice,
need
to
go
up
there,
the
other
route
or,
if
you
look
at
minimum
security
at
6,
don't
waste
work
that
way
you're
getting
a
number
of
information
from
the
route
or
from
some
servers
which
is
connected
to
the
route
and
use
that
in
the
network.
So
it's
just
using
the
same
flow
we
need
dad
like
we
go
to
an
LP
or
six
lvl
to
do
that
and
all
those
things.
H
So
it's
completely
consistent
assigning
me
I,
said
I'm
assigning
bits,
it's
just
yet
another
tasks
we'll
have
to
do
it
in
there.
The
other
thing
asked
is
how
we
do
ripple
compression.
There
is
only
one
RFC
for
that.
It's
eighty
one,
thirty
eight
and
it's
it's
made
for
waiting
for
beer.
Actually,
we
started
a
draft
which
is
the
beer
side
of
it,
but
it's
very
minimal
I
mean
the
hot
draft
will
be
bad
interesting.
It
would
be
a
lot
of
fun,
so
people
think
about
it.
H
Just
what
we
said
about
the
bit
version,
and
then
there
will
be
the
bloom.
The
bloom
cannot
be
compressed
right.
You
have
to
know
what
your
bloom
size
is.
It's
it's
computing
is
pre
computed
based
on
on
the
world.
You
know
their
Artemis
ations,
it
works
better
or
it
can
be
optimized.
Now,
if
you,
if
your
network
changes
from
what
its
optimized
for
it's
going
to
work
a
bit
less
well,
it's
gonna
work.
H
The
the
the
bits
version
will
have
a
lot
more
of
the
kind
of
fun
you're,
very
good
at
which
is
depending
on
what
you
want
to
do.
Unicast
multicast,
how
many
bits
I'm
using
at
this
moment
of
time?
How
can
I
express
that
I
just
pushed
the
minimum
number
of
bits
may
I
get
to
express
exactly
what
I
want
to
do
so
that
will
be
various
I
guess
there
will
be
different
ways
of
saying
the
same
thing
and
you'll
have
packet
by
packet
to
figure
out,
which
is
the
optimal
one.
C
You
for
the
word
creative.
It
was
very
happy
with
to
us
that
he
could
take
delete
and
that
he
has
make
this
group,
but
unfortunately,
I
mean
has
been
also
prevented
since
I
teach
I'm,
not
a
man
which
I
really
appreciate
it.
I
think
it's
time.
Subject:
lots
of
things
to
be
done
and
there
has
been
this
silence
and
I
really
hope
that
we
take
up
this
new
momentum
and
work
and
work
on
the
sit
on
the
subject.
C
E
Okay,
so
quick
update
here,
there
has
been
no
major
changes
to
the
draft
here:
Thank
You
George's
for
the
review
comments
and
we'll
be
making
some
text
amendment
to
accommodate
those
comments.
We
have
added
Pascal
as
a
co-author,
Thank
You
Pascal
for
your
inputs
just
briefly
about
the
solution.
What
we
are
trying
to
do
here
is
to
optimize
that
out
in
validation
procedure.
What
happens
is
that
the
target
node
in
informs
or
make
sure
that
the
common
ancestor
load
is
in
charge
of
the
router
invalidation
procedure
on
behalf
of
the
target
node.
E
E
So
the
updates
primarily
were
were
on
the
security
aspects.
We
have
included
the
D
Co
nd
co-ack,
secure
version
of
D
quantico
ACK.
We
have
piloted
this
implementation
to
us
before
and
it
has
been
in
the
pilot
phase.
Since
then,
the
contact
implementation
is
already
open
and
the
performance
report
is
available.
Any
questions
happy
to
take
any
questions.
Thank
you
cheers
for
calling
for
the.
C
C
I
H
Be
very
much
appreciated,
yes,
scale
yeah.
Actually
we
have
a
number
of
working
groups
who
just
started
less
close
two
weeks
ago,
and
there
was
the
HF
preparation
now.
So
it's
it's
actually
very
hard
to
do.
I
realized
it's
hard
to
do
this
review
two
weeks
before
the
HS
very
dense
period.
It
would
be
nice
that
we
have
a
little
bit
more
time.
I.
C
H
J
Okay,
so
maybe
just
a
little
bit
of
background,
I
ODB
ripple
was
in
last
call
for
this
year
and
the
comments
came
back
that
there
were
a
number
of
features
in
RFC
6997
that
were
not
brought
forward
into
a
OTV
ripple,
and
so
that
turned
out
to
be
a
good
bit
of
work.
And
then
Remy
observed
that
there
was
a
error
condition
that
couldn't
be
handled
when
we
were
really
using
the
T
bit
to
try
to
save
the
space
required
for
the
target
option
by
using
a
reference
to
the
ripple
instance.
J
So
I
tried
for
a
long
time
to
try
to
figure
out
how
to
save
that,
because
it's
a
nice
bit
of
optimization,
but
in
the
general
case
it's
extremely
unlikely.
This
would
happen,
but
it
can
happen
in
as
far
as
I
know
that
any
remedy
would
be
worse
than
just
taking
the
option
out.
So
so
there's
been
a
good
bit
of
going
around
and
on
the
design
team,
and
we
finally
came
up
with
this
version
4,
which
I'll
describe
to
you
now
in
which
I
hope
will
enable
it
to
finish
going
through
last
call.
J
All
right
so
I
mentioned
it
a
bit
and
I
guess:
I
should
at
least
also
to
say
that
a
OTV
ripple
is
a
peer-to-peer
mechanism
that
handles
I
can
find
routes
to
and
from
a
destination.
That
may
not
be
symmetric.
So
that's
part
of
the
value
of
this
document,
so
the
tea
bit
was
put
in
so
that
we
wouldn't
have
to
carry
the
address
of
the
target
if
it
was
already
able
to
be
inferred
from
the
instance
ID.
J
There
you
go
so
if
both
a
and
B
are
making
your
request
for
target
C,
and
this
metric
rat
reply
from
C
arrives
at
BB
can't
tell
whether
or
not
that's
from
a
throughout
request
or
from
its
own
request.
So
this
is
actually
an
essentially
I
can
show
up,
and
you
must
say,
multiple
sort
of
configurations,
so
that
still
may
be
possible
at
a
future
day
to
find
a
way
to
still
not
require
the
carrying
of
this
target
address.
But
in
the
meantime,
since
we
want
to
go
forward,
we
had
to
take
the
bit
out.
J
Then
there
was
something
that
needed
to
be
done,
since
one
of
the
features
of
the
previous
experimental
draft
was
to
have
multiple
targets
and
well,
it
turns
out.
We
can
do
this
cause
I'm
in
a
straightforward
way,
also
with
a
woody
B
ripple,
but
it
has
to
be
careful.
You
have
to
be
careful
about
how
you
forward
on
the
route
request.
So
if
you
go
through
here,
let's
say
a
is.
J
Wanted
to
find
routes
to
destinations,
B,
D
and
F,
and
this
show
this
graph
shows
the
way
that
the
route
requests
goes
broadcaster
the
network.
So
when
B
gets
that
route
request
well,
they
can
obviously
satisfy
that
with
a
route
reply,
but
it
needs
to
continue
to
look
for
destinations,
D
and
F,
and
so
it
has
to
take
out
its
own
address
from
that
list
and
it.
Finally,
the
same
thing
goes
on
the
other
side,
so
that
when
D
can
satisfy
the
route
request
by
sending
a
reply,
it.
J
Essentially
takes
the
intersection
of
these
and
forwards
of
route
request
down,
so
that
F
can
send
a
route
replied.
So
this
required
a
bit
of
specification
in
the
document,
and
that
has
also
been
done,
and
the
final
thing
did
to
discuss
here
had
to
do.
Oh
wait.
A
minute.
I
also
should
explain
how
we
manage
this
process
of
pairing.
The
ripple
instance
IDs
between
the
route
request
and
route
replied.
Well,
there's
still
the
case
that
you
can
have
two
different
sources
of
route
requests
using
the
same
instance
ID,
because
these
are
local
numbers
and.
J
I
J
Be
the
way
the
draft
has
written
is
that
the
pairing
takes
place
by
using
relationship
between
the
ripple
instance
ID
from
the
originating
node,
but
that
could
lead
to
duplication,
so
we
allow
for
that.
We
resolved
that
by
this
shift
parameter.
So
if
you
look
in
the
reply,
packet
you'll
see
that
there's
little
shift
that
can
be
sent
to
make
to
read
the
local.
The
instanceid
sub
still
unique
and
allow
the
originating
node
to
find
out
how
to
make
the
DES
pairing.
J
And
then,
finally,
about
multicast
I
didn't
understand
exactly
how
the
multicast
was
work
supposed
to
work
in
6997,
because
when
I've
tried
to
map
it
out,
it
looked
like
it
would
be
terribly
terribly
inefficient
and
cause
a
lot
of
overhead
traffic
in
the
network.
So
for
that
reason,
and
also
because
there's
this
other
work
going
on
with
other
approaches,
I
think
that
multicast
is
deserves
to
be
a
separate
effort
anyway,
and
hopefully
we
can
go
forward
with
a
ot
V
ripple
without
providing
a
multicast
solution
in
this
specification.
J
This
is
an
aside.
There
has
been
a
sort
of
related
multicast
efforts
going
on
in
other
groups
in
the
past
and
and
they
ended
up
basically
finding
it's
a
pretty
complicated
problem
as
well.
So
I
guess,
that's
into
the
presentation,
certainly
would
appreciate
more
review
from
the
existing
document,
but
we've
gone
over
it
pretty
well
with
a
fine-tooth
comb
and
so
I
think
it's
quite
ready
to
go
forward.
H
I
H
Itself
is
meaningless.
What's
meaningful?
Is
the
pair
ipv6
address
of
the
route
Kabbah
local
instance,
for
that
would
that's
the
topple
which,
which
now
gives
you
a
unique
network,
unique
thing,
and
now
what
we're
doing
is
we
are
coupling
one
from
the
left
to
the
right
to
one
from
the
right
to
the
left
right.
H
So
there
are
a
two
numbers
to
two
tuples
which
rise:
slash,
November
right
today,
yeah
so
usually
when
you
do
that,
like
you
have
a
news
app
and
a
piece
up
or
whatever
you
call
that
it's
just
a
matter
of
sending
back
to
the
other.
When
you
talk
to
me
with
this,
you
set
up
I
talk
to
you,
this
piece
upright
or
something
like
that
system.
Why
do
we
have
to
add
all
those
ships?
Could
we
just
say?
Okay,
your
name
for
relationship.
Is
your
address
your
local
instance
ID.
H
J
H
Must
know
that
your
names,
our
relationship,
is
your
IP
address
your
instance
and
my
name
for
that
same
relationship,
so
they
are
linked.
It's
just
that
I
think
your
shift
or
something
that
just
two
numbers
picked
from
two
different
space.
The
space
is
the
IP
address
of
the
root,
and
then
you
get
this
number
in
within
that
space
we
just
exchange
as
part
of
building
this
the
rods
request.
You
give
me
your
name
in
the
watch
response.
I
say
your
name,
my
name.
I
H
K
J
H
Basically,
you
say
you
send
your
out
requests,
charlie,
comma
five.
They
say:
okay,
I
will
send
the
Roger
reply,
Pascal,
comma
100
and
in
the
reply
I
put
25
that's
got
100
there.
No,
no!
You
stole
Pascal,
100
and
I.
May
I
keep
Charlie
5
each
time.
I
talk.
I
took
Charlie
5,
it's
like
you
turn
the
talk.
You
took
Pascal
10,
whatever
number
I
picked,
that's
the
you
user
SAP
provide
a
self-service
access
point
really
from
Holly.
E
H
Fact
the
polymer
is
that
tag.
No.
The
tag
node
cannot
merge
these
two
requests
using
the
same
repo
instance
ID,
because
you
you
may
you
may
have
different
requirements
from
the
two
original.
It
is
not
the
same
deck
it's
two
different
duel
deck,
but
in
the
road
reply,
I
should
have
a
small
option
somewhere
to
just
say
a
this
rod.
Reply
is
the
reply
to
the
rod
request,
which
was
said
from
Charlie
five.
So.
J
H
H
Sorry,
it's
because
for
for
pairing
between
the
same
pair
of
original
and
tell
note
it
may
have
the
multiple
instance
right
because,
for
example,
yeah
yeah,
multiple
pairs
of
instance,
yes,
and
it
may
be
at
the
same
time.
So
if
if
we
wants
to
pair
the
two
instances,
we
can
somehow
somehow
to
two
to
the
pairing.
Currently
in
the
draft
we
use
the
same
instance.
H
H
E
So
the
pairing
of
two
de
Guise
D
is
sort
of
a
central
to
this
draft
is
what
I
thought
always
you
know
when
I
revealed
the
draft,
and
one
of
the
reason
why
it
might
be
required
is
because,
on
the
intermediate
hops,
they
have
to
keep
a
mapping
between
what
was
the
router
ik
questions
are
out
reply,
the
instanceid.
They
have
to
make
sure
that
the
route
reply
is
on
the
same
or
on
the
or
or
online
instanceid
which
matches
to
the
route
request.
E
So
that
is
why
the
pairing
is
about
pairing,
a
sort
of
a
sort
of
central
concept
for
this
particular
traffic.
In
my
opinion,
yeah
yeah.
So
now,
they're
now
they're,
like
I
mentioned.
If
we
can
have
second
totally
different
in
society
which
is
managed
by
so
then
we
will
have
to
have
additional
bits
in
the
reply
which
says
that
okay,
the
original
instance
idea
was
this.
So
it
requires
more
I,
that's
what
it
optimizes.
So
in
fact,
in
fact,
I
we.
J
E
J
E
Is
no
more
there
right?
Okay,
that
sounds
good.
Actually,
in
fact,
I've
seen
the
shifting
of
instance,
ID
concept
I
feel
it
is
it
is,
it
is
the
best
way
of
solving
ratio.
It
is
really
really
nice
way
of
making
sure
that
the
target
note
doesn't
end
up
with
the
same
instance,
ID
from
well
I
didn't
get
it
in
the
first
first
first
place.
So
what.
I
J
E
Final
command,
so
people
keep
saying
me
that
this
is
highly
improbable
to
happen,
that
it
is
not
possible
for
the
instance
idea
to
collide
and
I
really
don't
feel
so.
The
entropy
is
just
seven
bits.
It
is
going
to
collide
for
sure,
so
this
has
to
be
handled
clearly
in
a
very
good
way
now
to
send
bits,
because
that
one
bit
is
now
notice.
Yes,
one
bit
is
now
removed,
went
back
right,
the
earlier
the
odd-even
bit.
C
C
I
should
like
to
have
some
reviews
of
this
draft
school.
Two
weeks
ago
we
was
left
very
little
information
there
still
plenty
of
room
for
discussion
here.
Nevertheless,
spunk.
To
conclude,
this
laugh
so
I'm
looking
forward
to
reduce
model
very
good,
okay,
I'm
looking
forward.
Is
there
a
second
form
on
tier,
please
I.
H
I
H
C
H
Root
initiated
routing
stating
report
the
projections
there
was.
There
was
some
discussion
on
the
mailing
list
about
the
complexity
of
implementation,
thanks
to
role,
implementing
and
feeding
us
back,
so
that
that's
recreated
and
thinks
about
roles,
and
so
we
did
a
number
of
things.
First
thing
is
inviting
round
to
the
draft
because
he
did
a
lot
of
work
on
it
discussions
and
he
also
pointed
out
that
we
get
to
better
discuss
the
loop
avoidance
prom,
so
we'll
probably
in
the
future,
work
harder.
Even
but
there's
already
things
started
there.
H
There
was
a
discussion
and
Michael
Richardson
was
not
with
us
today
at
a
point
about
whether
this
protocol
should
also
be
the
way
the
route
knows
about
the
capabilities
of
the
devices,
because
one
key
point
in
this
design
is
that
the
route
pushes
state
in
the
devices
within
what
the
device
can
take.
So
it
needs
to
know
what
the
device
can
take
and
for
us
this
was
control
plane
like
how
do
you
know
the
topology
here?
Who
do
you
know
many
things
else?
H
We
know
we
need
this
component
somewhere
in
row,
which
will
feed
the
route
with
your
are.
The
peers
here
are
the
neighbors.
Your
are
the
cost
of
the
link,
whatever
metrics
you
use,
etc,
etc.
So
the
route
can
make
intelligent
decisions.
Right
I
mean
just
like
any
traffic
engineering
protocols.
We
will
need
a
ripple
te
of
some
form
to
feed
the
route
with
with
intelligence,
about,
what's
going
on
in
the
network
and
I
thought
that
the
capability
of
the
node
would
be
part
of
that
intelligence
of
the
network.
H
Now
Michaels
on
the
mail
is
sent
like
a
year
ago
pointed
out
that
we
should
provide
us
information
within
within
the
protocol
so
and
it
sit
back
on
that
bit
in
the
Mike
Gravel.
E
H
E
H
Anybody
else
so
for
me,
this
draft
is
all
about
to
make
machinery
to
establish
rods,
how
the
root
knows
which
rods
to
establish
is
out
of
scope.
So
Raul
seems
to
agree
which
tells
us
that
we
need
this
other
document
which
which
informs
the
row
the
roots
first
about
what's
available
in
the
network,
including
the
nod
capabilities.
Okay,
so.
H
That's
consistent
with
that
document
as
another
feedback
we
got
and
from
home
again
was
that
I
never
liked
it
in
the
previous
version.
How
do
you
know
if
you're,
using
a
storing
mode
or
an
on
storing
mode,
a
POS
weaker
it
now
what
projection
option,
and
so
the
resolution
on
the
mailing
list
was
to
actually
make
two
of
them
have
a
different
option
if
you're
using
sauce
rod
versus
non
so
throughout
the
auction.
H
So
nobody
contractor
contradicted
that
on
the
mailing
list,
so
we
edited
the
documents
with
the
change.
Now
you
have.
We
call
the
generic
a
rod,
projection,
option
appeal,
but
then
there
are
two
different
codes.
One
of
them
is
the
sauce
rod
the
option
and
the
other
one
is
the
normal,
storing
Maggio.
H
Looking
at
dupe
avoidance,
there
is
a
bit
of
a
complexity
here.
The
question
is:
can
we
trust
that
the
route
will
never
make
a
mistake
and
that
the
state
is
always
installed
correctly
everywhere
and
stays
there
all
the
time?
If
that
is
true,
then
we
don't
have
a
loop
but
very
clear
that
we
can
trust
that,
but
the
complete
extreme
can
be
node
which
forwards
along
the
projected
rod,
make
sure
that
is
going
to
get
there
without
a
loop,
and
the
answer
is
yes.
H
There
are
cases
where
you
can
make
sure
an
example
of
that
is
a
straight
sauce
part.
If
you
have
a
strict
sauce
route,
you
know
exactly
the
hops
so
either
the
packet
gets
there
or
gets
dropped,
but
it
will
never
because
you
have
the
streets
or
SWAT.
You
share
the
news
source
right
now.
You
may
have
a
loop
because
getting
from
one
heart
to
the
next
hub
without
the
Russos
route
may
actually
thank
you
behind
yourself.
So,
oh
no,
no
I
start
having
problems
so
the
basically.
H
What
the
text
says
is
is
that
when
you're
getting
in
your
router,
whether
it's
storing
a
non-story,
you
must
be
loop
less
to
get
to
the
next
hop.
That's
what
the
text
said
today,
that's
in
new
text
and
the
text
says
you
must
know
that
your
new
place
to
get
to
the
next
hub
in
the
rod
and
to
be
loop
less,
you
know
the
guy
is
a
direct
neighbor
of
yours
or
you
have
a
strict
source,
routing
path
to
him
or
recursively
know.
H
When
once
you've
done
all
your
Roderick
Ocean,
you
have
a
strict,
sorting
path
to
the
next
half
of
your
recursion,
and
this
way
you
know
that
you
will
get
to
the
next
indicated
the
heart
without
a
loop.
So
if
the
globe
will
rot
and
to
Andy's
new
place-
and
you
know
that
you
have
no
look
between
each
hub,
then
you're,
okay.
So
basically
the
text
today,
sighs
do
this
check?
H
You
can
have
a
multi
hot
sauce,
rotted
path
which
is
loose
but
to
get
to
the
first
hub.
You
must
have
a
strict
or
if
it's
a
loose,
then
to
get
to
the
first.
Stop
of
the
second
rules.
You
must
have
a
strait,
all
the
guy
is
your
neighbor
see.
So
that's
what
the
text
says
today
if
people
are
interested
in
thinking
about
that
and
coming
back,
but
but
that's
that's
rule
that
we
have
right
now
in
the
text.
H
Now
we
still
have
this
discussion
on
how
and
whether
to
use
the
whole
orbit
the
or
an
equivalent
to
the
opiate.
The
obit
says
you
go
up,
you
go
down,
but
you
kind
of
go
up
again
pretty
much,
but
it's
that
with
projection.
You
can
do
whatever
you
like,
so
you
can't
protect
against
that.
The
one
thing
you
can
protect
against
is:
if
you
enter
projected
rot,
you
should
never
get
out
of
the
project.
You
rot
your
deeper
into
a
nesting
of
topologies
parent.
H
The
loops
that
you
get
in
multi,
topology
routing
is
like
I
live
in
this
topology
I
moved
to
LA
after
Paulo
G
and
that
can
be
no
place.
But
if
I
come
back
to
a
previous
topology
now
I
can
have
a
loop,
that's
a
bit
conceptual,
but
as
long
as
the
topper,
the
rotting
topologies
for
whatever
jessica
graph
you're
hopeless.
That's
pretty
much
of
this
cells,
so
going
from
normal
River
rotting
down
to
projected
route
is
loop
last
as
long
as
you
never
go
back
to
a
normal
rotted
reported
vault.
H
So
there
is
a
possibility
to
use
the
equivalent
to
the
obit,
but
it's
not
up
and
then
down
and
then
never
help.
Again,
it's
no
more
approaching.
They
are
not
projection.
They're,
never
reporting,
Union.
Okay,
so
that's
the
complexity.
I
mean
the
rules
can
be
very
simple
in
the
finals
back
but
understanding
exactly.
H
What
we
are
doing
here
requires
some
brain
work
and
finally,
we
never
discussed
on
the
meaninglessness
the
mode
of
operation,
but
still
this
question
of
how
do
we
signal
which
mode
of
operation
do
we
need
to
define
new
mode
of
operation,
cetera
the
whole
mystery
bit
already
saturated?
So
what
do
we
do
here?.
H
H
Mixed
mode
is,
for
instance,
I,
have
a
story
mode
projected
route
to
somebody,
but
it's
loose
and
I
can
use
non,
storing
source
routed
to
my
next
hub.
Do
we
want
to
support
them
right
now?
The
draft
arose
it,
but
do
we
want
any
sort
of
mix
like
the
ripple
around
us
is
non
stirring
and
we
are
using
storing
mode
projection
and
inside
the
story
mode
projection.
We
are
using
non
stirring,
which
ability
to
the
next
hop
well
I
mean
it
works.
Do
we
want
that.
H
Basically,
I
would
like
people
interested
in
thinking
in
deep
thought,
basically
of
exactly
what
won't
oh
I
wanna
go
with
this,
because
ripple
when
we
did
it
was
decision,
was
to
keep
it
very,
very
simple,
like
don't
mix
mode
at
all
right
when
we
did
Road
projection,
it
made
a
lot
of
sense
to
use
the
projection
mode,
which
was
not
necessarily
the
same
as
the
ripple
around
it.
One
sense
you
use
non,
storing
your
source
route,
but
you
project
storing,
so
you
can
compress
the
source
route
for
long
lines.
H
That
makes
a
lot
of
sense
that
the
projected
rot
is
not
necessarily
the
same
as
the
ripple
around
it
now
do
we
need
do.
We
have
those
cases
where
we
want
to
mix,
storing
and
non
storing
projected
routes
it's
doable
to
want
to
support
it.
Just
matter
of
complexity
of
the
code
will
be
feedback
from
implementations
again,
hello.
E
I'm
Rahul
Jadhav,
whoever
technology,
so
this
the
hybrid
mode
of
operation
is
definitely
required
because
non
storing
mode
of
operation
has
its
own
limitations.
Storing
mode
of
operation
has
its
own
big
limitations,
so
we
need
the
neighborhood
approach.
We
we
plan
to
use
it
in
our
implementation
as
well.
Even.
H
H
Just
want
to
make
sure,
because
it's
more
complexity
and
I
remember
at
the
time
we
did.
Repos
and
people
reacted
to
this
sort
of
complexity
and
say:
let's
just
make
two
different
networks
and
that's
why
we
are
starring
in
on
starring
in
the
new
mix
of
them
right
I
mean
it
was
an
oversimplification
if
you
like,
but
we
went.
We
took
this
path.
I
mean
my
own
implementation
of
what
became
Ripple
could
do
both
at
the
same
time
and
they
had
no
problem
doing
it.
But
working
group
said:
let's
make
that
separate.
H
E
Okay,
hello,
everyone,
our
travel
Giada
from
hobby
technologists,
so
this
chapter
talks
about
some
of
the
observations
that
we
had
when
we
tried
to
deploy
the
storing
mode
of
operation.
Now,
what
we
want
to
do
is
we
want
to
bring
to
the
notice
of
this
working
group.
What
are
the
issues
with
storing
mode
of
operation
and
that
people
have
to
choose
it
wisely?
This
is
one
of
the
outcome
possible
outcome.
The
poll
the
second
possible
outcome
of
this
work
is
that
we
might
have
some
errata
addictive
six
by
five
zero
or
we
might.
This
with.
E
This
work
might
result
in
new
new
working
group
drafts
which
might
try
to
solve
some
of
the
issues
with
the
storing
mode
of
operation.
So
most
of
the
observations
that
were
done
here
were
when
we
were
trying
to
be
probably
smart
meter
or
the
mi
padre
network
in
the
last
plane
or
in
the
single
channel
mode
of
operation.
E
We
had
some
sort
of
implementation
in
place
for
the
problems
that
were
described
here,
but
we
definitely
feel
that,
whatever
the
implementation
of
whatever
solutions
we
had
worked
over,
definitely
not
the
best
not
optimal.
So
one
of
the
discussions
that
we
had
before
going
into
the
details
of
the
draft
one
of
the
discussions
that
we
had
on
the
mailing
list
was
regarding
whether
DTS
n
is
the
lollipop
counter
or
not.
E
Well,
six,
five
five
zero
says
knows,
and
this
is
something
that
we
realize
later
when
Michael
pointed
out,
DDS
n
stands
for
drought,
Dow
triggered
sequence
number,
but
having
said
that,
it
is
not
supposed
to
be
a
sequence
counter,
because
there's
this
explicit
section
in
six
five,
five
zero,
which
says
sequence,
counters
and
DTS
n-
is
not
mentioned
there.
So
one
one
point
is
clear:
that
the
implementations
are
clearly
confused
right
now,
so
in
our
internal
implementation,
we
have
thought
of
it
as
a
whole.
E
Lollipop
counter
kontiki
has
also
thought
of
it
as
a
lollipop
counter,
but
riot
has
not.
So
there
is
definitely
a
confusion
about
that.
The
bigger
question
is
what
it
should
really
be.
Should
it
really
be
a
lollipop
counter
or
no
now,
one
of
the
issue
with
being
a
lollipop
contrary
is
that
you
have
to
start
randomly
with
the
new
DTS
in
when
you,
when
the
node
reboots,
and
if
it
so
happens
that
when
the
node
reboots
it
picked
up
the
same
DTS
in
on
stop
before
the
reboot,
then
the
outcome
is
unpredictable.
E
E
E
Once
the
node
goes
into
the
positive
part,
then
you
don't
need
to
flash
it
again,
so
it's
actually
better,
in
my
opinion,
to
actually
have
DTS
and
as
a
lollipop
counter
than
not.
This
is
something
that
I
feel
this
working
group
has
to
consider.
If
it
is
considered,
then
it
might
require
clarifications
in
6
5
at
0,
regardless
it
requires
clarification
in
6,
5
or
0,
because
implementations
are
taking
different
routes
already.
H
H
Is
the
update
of
ripple
okay,
it
start
to
think
about.
Okay,
let's
fix
the
bugs
right
and
that's
usually
called
an
update.
So
why
don't
we
I
mean
chairs
build
of
interest?
Why
don't
we
start
thinking
about
creating
this
draft
RFC
6550
update
thing?
No,
we
talked
long
ago
about
trying
to
make
an
Internet
standard
of
reports
at
the
time
we
were
missing
feedback
and
this
sort
of
work
that
router
is
doing
now
and
I
guess
the
result
of
Falls
work
could
be
that
now
we
have
a
better
quality
at
that
document.
I
think.
E
Okay,
so
one
of
the
other
things
that
hampers
storing
mode
of
operation
is
the
use
of
DT
s
n,
so
DTS
n
is
clearly
the
biggest
has
the
single
most
biggest
impact
on
the
overall
operation,
quality
of
ripple
in
storing
mode
of
operation.
So
this
it
has
dependents
on
the
route
update
for
the
dependent
nodes,
it
has
implications
on
the
downswing.
Router
will
rotate,
has
direct
implications
on
the
overall
control
traffic
over
hand,
and
there
are
it's
very
difficult
for
an
implementation.
E
So
that
sounds
like
a
very
bad
idea,
but
then
the
problem
is
that
the
router
redundancy
in
case
of
storing
mode
of
operation
will
become
very
less
if
the
DTS
n
is
not
incremented
in
case
of
every
takagi
reiko
timer.
I
know
previous
versions
of
the
Quantic
implementation
used
to
increment
DTS
in
every
day,
a
timer,
but
then
it
stopped
doing
that
because
I'm
assuming
it
would
result
in
high
control
overhead.
E
E
So
another
question
that
we
always
faced
was
on
parents,
which
should
the
note
increment
its
DSM,
so
that
all
the
neighboring
peers
realize
that
there
has
been
a
change
of
the
parent
so
that
they
have
to
update
the
down
DD
s
n,
so
that
an
updated
now
can
be
flow.
It's
not
only
about
the
neighboring
beers,
though
the
completes
budak
rooted
at
that
particular
6lr
needs
to
or
needs
to
be
updated.
The
whole
drought
the
subdued
air
has
to
update.
E
There
is
a
specific
test
text
in
six
y50
regarding
this
that,
when
the
parents,
which
happens,
the
subdued
AG
rooted
at
that
particular
6lr,
has
to
obtain
the
route.
But
how
how
to
do
it?
Whether
it
should
be
done
by
incrementing
the
DTS,
and
that
is
not
mentioned.
How
that
subdued,
agar
out-of-date
happens
is
not
clearly
mentioned,
or
it
is
actually
very
difficult
to
daily
mention
that
in
the.
H
Yes,
there
is
for
that
because
it
really
bears
on
the
reasons
why
you're
apparent
if,
if
your
mobile,
node
and
you're,
apparently
because
you
moved
probably
your
children-
you
know
it's
part
of
the
use
case,
but
they
moved
with
you
what
they
did
not
yeah
yeah.
So
you
have
to
expect
what
kind
of
shoes
gets
your
hand
too.
If
you
have
a
good
chance
that
your
children
did
not
move
with
you,
then
you
need
to
send
it.
H
Yes,
I
do
use
the
other,
because
normally,
if
you
move
you
have
you
have
your
routing
table
you,
you
don't
need
your
children
to
rebuild
the
dough
for
what
you
have
in
memory.
We
have
this
discussion
last
time,
you're
supposed
to
be
able
to
recreate
down
for
everything
in
your
writing
table.
So
when
you
move,
you
can
always
tell
your
parent
I've,
get
all
those
children's
to
the
others
channel.
But
do
you
know
for
sure
because
you
moved
so
maybe
they
did
not?
Maybe
they
hear.
H
Is
not,
and
if
you're
in
a
a
smart
grid,
type
of
environment
where
everything
is
very
stable,
there's
a
good
chance
that
your
children
are
still
there.
So
you
could
say:
okay,
let
me
advertise
that
they
have
still
I
still
have
them
and
send
all
my
children
to
my
new
parent.
But
if
I'm
no,
in
course
very
much
more
mobile
before
I
advertise,
anything
on
behalf
of
somebody
I
should
make
sure
they
are
there.
So
I
should
not
advertise
them.
E
So
that
is
definitely
another
way
to
do
it
so
that
the
6lr
itself
advertises
on
behalf
of
all
the
sub
child's
to
the
to
the
upstream
peers.
That
is
another
way
to
do
it,
but
that
requires
target
aggregation,
multiple
targets
in
the
same
dow,
and
that
is
very
inefficient.
So,
for
example,
if
I
have
write
a
routing
table
size
which
is
50
or
20
or
50,
even
modestly
sized
table,
it's
very
difficult
to
send
aggregated
targets
and
6x5
zero,
doesn't
mandate,
reception
of
target
aggregated
targets
in
the
dow
doesn't
matter.
E
So
there
are
some
open
loops
that
open
holes
in
6,
5
x,
0
that
we
are
trying
to
point
out
here
another.
The
point
that
I'm
going
to
discuss
about
is
the
DAO
Act.
Now
there
has
been
a
discussion
on
the
mailing
list,
so
there
are
multiple
interpretations
possible
already,
and
we
can
see
this
interpretations
happening
in
the
current
implementations
already.
So
there
is
hop
by
hop
Act
acknowledgments.
You
send
out
to
its
immediate
peer
and
they
immediately
response
back
as
it
is
so
there.
E
The
advantage
is
that
the
sequence
of
operation
is
really
really
straightforward,
very
easy
to
do.
There
is
no
additional
program
requirement.
There
is
no
additional
state
that
is
to
be
required,
but
the
problem,
the
biggest
problem
with
the
DAO
Act
in
storing
mode
of
operation,
is
that
how
does
the
target
come
to
know
that
the
DAO
indeed
has
reached
the
border
out
or
the
route?
That
is
the
biggest
question
that
has
to
be
answered
by
a
doubt
act
in
case
of
non
slowing
mode
of
operation.
E
It
is
very
easy
to
determine
that
because
the
DAO
is
directly
targeted
to
the
route,
but
in
case
of
non
storing
mode
of
operation
it
has
high
level
of
complexity,
and
that
is
what
this
so.
So
the
reason
chromatic
implementation
tries
to
do
something
like
n2
and
acknowledgements,
so
the
node
sends
a
Dao
upstream
and
doesn't
a
kit
immediately
unless
until
the
border
router
starts
responding
with
that.
So
that
is
one
one
one
one
interpretation
that
has
been
done
based
on
I'm.
H
Confused
that
you
can
understand
the
spec
that
way,
but
we
can
promise
that's
not
the
intent,
the
intent
is
you
acknowledge
you
get
something
you
just
acknowledge
it.
It's
just
the
layoffs
react
punishment
when
you
don't
have
a
layer,
2
acknowledgment,
but
plus
it
goes
a
little
bit
higher
at
the
stack.
So
we
technologies
that
the
river
water,
above
you
I,
has
understood
your
Dao.
We
discussed
that
last
time,
but
the
intention
is
clearly.
You
acknowledge
immediately
like
on
the
left
right.
I
H
What
makes
so
that
it
reaches
the
top
is
that
if,
if
your
parents
cannot
advertise
that
up,
then
he
needs
to
reparent
until
he
finds
a
way
to
advertise
up,
but
if
that
doesn't
work,
then
he
needs
to
poison.
So
you
know,
and
now
you
go
somewhere
else
right.
So
it's
this
is.
This
is
working,
it
might
not
be
spelled.
Well
that's
what
the
updates
document
can
be
useful,
but
this
is
working.
It
may
take
time
if
you
one
of
your
parts
could
be
broken
and
it
does
not
poison.
H
E
E
For
example,
let's
consider
let
us
consider
the
node
n
3
here
if
it
has
to
keep
stay
on
behalf
of
the
complete
multiple
nodes
in
the
subdue
dad,
so
that
it
can
retransmit
Dao
on
behalf
of
all
those
nodes
we
transmit
down,
so
that
that
that
state
is
substantial
first,
second,
it
still
doesn't
guarantee
to
know,
because
the
node
has
already
replied
with
a
dhow
act
to
the
downstream
neighbor.
So
if,
for
some
reason
it
might
still
fail,
let's
say,
for
example
the
node
god
stopped
the
node.
What
stopped
the
node
Anthony?
What
stop?
E
H
H
E
H
E
That's
still
more
information
that
still
more
state
the
state
has
been
taken
for
us
still
more
longer
amount
of
time
than
what
it
was
required.
Currently
I
mean
in
this
case
and
for
we'll
have
to
keep
checking
whether
entry
has
gone
out
of
its
range
I
mean
if
we
parenting
is
not
an
easy
decision
now.
N4
is
not
sending
anything
activity
to
n3.
If
entry
moves
off,
there
is
no
way
in
fluent
in
you.
You.
H
Have
to
monitor
it
one
way
or
another,
either
Nathalia
to
activity
you
when
tourists
I
use,
you
can't
stay
for
100
years,
having
lost
your
parent
and
you
don't
know
okay,
so
yes,
you
have
to
you,
have
to
monitor
your
parent
one
way
or
another
is
texting
report
which
tells
you
that
and
repo
as
ways.
If
you
don't
have
a
lower
lay
your
way
of
doing
it.
Just
like
nerd
right.
E
Just
one
more
problem
that
I
need
to
highlight
here,
because
the
context
is
right
here.
So
what
happens
if
n3
it
tries
to
send
the
doubt
back
above
it
receives
a
negative
acknowledgement
on
behalf
of
n4.
What
does
it
do
that?
Let's
say,
for
example,
entry
try
to
retransmit
the
Dow
it
sent
a
Dow
upstream
that
cannot
be
handled
so.
H
H
So
you
always
have
not
only
parents
which
one
negative.
Basically,
so
if
you
fail
with
and
then
one
then
you
go
to
n2,
but
if
basically,
what
designer
said
was
like,
if
you
don't
have
a
parent
with
enough
storage
for
your
down,
then
you
have
a
network
design
plan,
not
a
protocol
problem.
Okay,
that's
you
know.
So
the
whole
game
of
beer,
for
instance,
is
to
avoid
that
case
more
and
in
the
meantime
people
said.
Oh,
is
that
so
that
I
won't
do
story,
but
that.
E
B
Know
so,
basically
from
what
you
just
say,
I
think
you
might
have
just
answered
what
I'm
going
to
ask,
but
just
to
clarify
you're
saying
that
if
you
don't
have
end-to-end
Dow
AK,
then
you
when
you
take
it
out,
you
act
on
it
immediately
and
then
you're
committing
to
forward.
And
if
you
fail
your
podium,
but
do
you
poison
unicast
to
the
specific
child?
Or
do
you
broadcast
poisonous.
H
To
failures
right,
the
one
that
we
don't
support
is
I
give
to
my
parents.
Now
what
I
got
from
my
child
and
my
parents,
which
turns
negative
because
doesn't
have
storage.
We
said:
ok,
outerscope,
ok,
design
your
network,
so
you
have
enough
room
in
the
parts.
That's
basically
what
triple
size
but
not
say,
I'm,
not
saying
it.
B
H
Pretty
much
the
design
yeah!
That's
why
people
don't
do
it
yeah
yeah?
Well,
we
do
it
in
a
smart
grid.
So
I
mean
you.
You
have
nodes
which
are
big
enough
to
store
that
if
it's,
because
you
cannot
see
them
to
the
parent,
so
it
never
gets
an
acknowledgment
back.
That's
when
he
discovers
that's.
That's.
B
H
That's
written
somewhere,
but
basically
role
as
all
this
good
question,
I
mean
the
text.
Basically,
what
host
points
out
is
gaps
in
the
explanation
in
the
draft.
After
that,
you
can
say:
oh
I,
don't
want
to
I
want
to
support
story
mode.
That
I
can't
agree
with
this
limitation
out
of
scope
right,
that's
new
work,
but
at
least
the
existing
work
should
be
self-consistent
self-explanatory
and
peer.
What?
How
shows
us?
It's
not
necessarily
all
all
that
good,
so
without
changing
anything
in
the
spec
at
least
clarify
what
it's
supposed
to
do
is
is
very
good.
E
But
I
have
select
contradiction
to
make
their
sword
to
say,
but
you
know
whatever
the
three
interpretations
that
are
pointed
out
right
now,
which
are
the
possible
interpretations
as
part
of
six
five
zero
right
now,
I,
don't
feel
that
they
solve
the
right
issue.
I
mean
still
the
it
is
possible
to
actually
have
a
much
better
implementation
of
the
ax
in
story
mode
of
operation
which,
but
with
much
less
overhead,
both
in
terms
of
control
as
well
as
the
resource.
E
E
Yes,
yes,
that's
a
new
work,
definitely
so,
but
that
that
is
what
I
feel
it's
very
easy
to
implement
its
friendly.
The
biggest
problem
with
that
mode
is
a
CAG
regression
on
the
return
path,
but
I
feel
that
might
not
be
a
very
big
issue,
because
you
right
now
it
is
possible
to
aggregate
multiple
acknowledgments
that
now
acknowledgments
it
is
possible.
But
with
this
unicast
directly
to
the
rule,
we
with
the
Dow
ad
getting
directly
to
the
target,
it's
not
possible
to
aggregate
multiple
acts
in
the
same
packet.
C
E
H
E
Okay,
so
this
is
what
I
already
talked
about
the
doubter
a
transmission
in
our
there
is.
It
is
possible
to
solve
this
problem
in
a
much
different
way,
but
then
again,
this
has
to
I
discussed
on
the
mailing
list.
Handling
node,
reboots
I
feel
this
section
can
be
remove,
because
I
feel
there
is
an
implication
on
flash
handling
as
well.
E
The
graph
that
is
observed,
but
you
can't
really
do
away
with
that.
So
lollipop
counter
is
the
best
way
of
managing
the
state
information.
You
have
to
still
flash
it
again.
There
is
some
work
that
is
required
for
handling
the
social
mobility.
Some
work
is
been
already
driven
by
some
of
the
droughts,
for
example
in
60s.
That
is
the
rank
priority
and
joint
priority
that
that
sort
of
solves
this
issue
this.
Basically,
the
issue
is:
what
happens
if
the
router
cable
gets
full
on
the
upstream
know?
E
What
happens
if
it
our
neighbor
table,
gets
moved
in
the
optional
some
important
points,
miscellaneous
points
should
transit
information
be
optional
right
now
the
RFC
says
it
is
optional,
but
clearly
it
cannot
be
made
optional,
because
there
is
life
time
and
I.
Think
IIIi
think
there
is
other
work
that
also
requires
it
to
be
mandatory.
Aggregated
to
target
containers
can
aggregation.
We
made
optional
at
least
Kenda
can
6y5
say
zero
say
is
that
at
least
the
reception
should
be
mandatory
data,
if
not
sending
the
reception
of
targeted,
aggregated
target
container
I
should
be
mandatory.
E
C
H
H
Very
great
work
very
useful,
and
the
other
thing
is:
how
do
you
find
this
new
end
to
an
acknowledgement
after
we
discussed
that
who
want
it,
which
I'm
not
certain
at
all,
but
you
have
to
convince
me
go
ahead,
but
which
is
completely
numeracy
which
describes
this
new
mechanism
in
addition
to
the
existing
mechanism.
So
it's
meant
when
are
supposed
to
look
like
a
something.
So
we
have
to
two
things:
how
both
documents
would
be
structure
I
can
use
for,
etc.
H
D
D
E
One
more
point
that
I
just
want
to
highlight
here
so
some
of
the
world,
that
the
reason
why
we
put
out
this
document
is
because
they
stole
the
implications
it
has
on
the
story,
mode
of
operations
and
some
of
the
implications
might
be
sorted
out
by
other
documents.
Other
works,
such
as
beer,
beer,
beer
related
work,
it
might
have
so
there
should
be
some
way
of
referencing
the
problems
somewhere
so
that
this
document
might
help.
In
that
sense,.
C
L
C
I
I
So
in
this
version
we
have
published
our
implementation
for
Kentucky
iOS
and
actually
have
I.
Don't
have
the
links
here
in
the
slides,
but
I
can
paste
them
in
the
chat
room
or
send
them
to
the
email
for
all
whatever,
and
we
have
also
published
some
Wireshark
dissectors
for
the
optional
fields
that
have
been
reduced,
but
we
have
not
included
the
compression
and
I
will
discuss
that
a
bit
later.
We
have
done
renamed
some
acronyms,
which
were
somewhat
poorly
chosen
and
we
have
addressed.
I
So
I'll
go
over
this
material
a
bit
quickly
because
we
have
presented
previous
IDF.
So
this
draft
regard
trying
to
achieve
determinism
so
as
far
as
possible
as
possible
as
reliable
as
possible
communication
and
low
jitter,
and
in
order
to
do
that,
we
are
trying
to
use
packet,
replication
and
nation.
So.
I
A
I
I
So
the
information
used
which
we
will
transmit
in
this
extension
allows
selecting
an
alternative
parent
which
has
some
commonality
with
the
default
parent,
so
that
the
path
doesn't
diverge
too
much.
So
we
are
not.
We
could
just
use
normally
the
second
preferred
parent,
but
we
don't
want
to
do
it
as
simply
as
that,
because
we
are
trying
to
contain
the
alternative
path
to
be
as
close
to
the
original
one
as
possible.
I
So
in
this
example,
we
have
a
sending
node
s
and
he's
trying
to
send
some
information
towards
the
route
top
and
his
preferred
parent
is
a
and
there
is
a
potential
alternative
parent
B.
So
the
information
that
we
are
sending
is
information
available
to
a
and
is
to
parents
and
and
parent
set
of
s,
so
a
will
send
his
parent
set
in
this
case,
D
C
and
in
that
order
and
B
will
send
E
and
D.
And
now
these
are
ordered
in
objective
in
terms
of
reference
through
the
objective
function.
I
The
format
an
example
for
the
format
of
this
information,
so
we
are
using
the
Dao
message
and
within
the
optional
fields,
we
are
extending
the
dug
metric
container
next
slide.
Please,
and
specifically,
we
were
adding
within
the
nod,
state
and
attributes
routing
type,
a
optional
lv,
with
a
type
of
value
which
needs
to
be
decided.
The
length
is
size
in
bytes
of
the
ipv6
addresses
which
will
send,
and
basically
the
actual
data
we
need
carry
is
the
a
list
of
ipv6
addresses
of
the
parent
set
of
a
node.
I
So
we
have
implemented
this
in
Kentucky
OS
and
we
have
modified
wash
are
able
to
display
it
here
at
the
bottom.
I
don't
know,
do
I
have
a
way
of
know
of
pointing
somewhat
No,
okay,
so
at
the
bottom
you
can
see
the
expanded
field
for
the
note
state
and
attributes
routing,
I
and
the
road
date.
It's
a
relatively
simple
the
dissector,
but
it
next
slide
please
so
the
issues
we
would
like
to
address.
There
are
three
of
them.
The
first
one
regards
the
size
of
the
information,
as
so
normal.
I
It's
invite
or
ipv6
address,
and
that's
quite
a
lot
and
useful
one
would
expect
at
least
two
addresses
should
send.
Otherwise
you
don't
have
possibility
for
doing
any
kind
of
real
replication.
So
32-byte,
it's
quite
a
lot.
So
next
slide,
please
with
a
helpful
pointer
of
Michael.
We
can
use
6lowpan
the
6lowpan
routing
header
and
in
our
case
all
the
ipv6
addresses
contained
in
this
extension
bar
definition.
They
by
definition
belong
to
the
same
product.
I
I
I
Next
slide,
please:
okay,
we
will
just
want
to
add
basically
a
threshold
on
the
link
quality
or
whatever
metric
is
used
for
ordering
the
potential
parent
so
that
potential
parents,
a
parents
in
the
panel
set
who
do
not
fulfill
this
constraint,
are
not
sent
at
all.
So
this
would
cut
out
in
this
example,
is
no
sir
next
right.
I
Finally,
that
is
an
issue
of
flooding.
So
in
the
previous
examples
we
generally
used
a
strict
version
of
how
to
implement
this
constraint,
so
the
state
version
requires
that
the
preferred
parent
of
the
default
parent.
So
a
is
the
preferred
parent
of
s
and
F
is
the
preferred
parent
of
a
that.
F
is
the
preferred
parent
of
an
alternative
parent.
So,
for
example,
b1
has
a
preferred
parent
of
e
p2
has
a
preferred
parent
of
F
and
b3
has
a
preferred
parent
of
G
at
v3.
I
Only
b2
has
the
same
preferred
parent
as
through
a
so
using
this
strict
implementation.
Only
B
would
be
an
acceptable
alternative
parent
for
us
next
slide.
Please.
There
is
also
a
less
strict
version
which
does
not
require
that
you
know
equality
between
two
nodes.
It
still
uses
the
preferred
parent
of
the
preferred
parent
again
F.
However,
it
does
a
comparison
between
sets.
So
in
this
case
we
take
the
whole
parent
set
of
b1
y
ND.
I
So
the
problem
is
that
the
relaxed
implementation,
although
it
provides
more
options
for
replication
through
experiments
published
in
nut
hook
now
as
an
18
X
Thomas,
for
that
showed
that
we
have
uncontrollable
flooding.
So
that's
a
problem
in
terms
of
network
efficiency,
so
our
idea
firstly,
is
to
use
a
midi
more
strict
version
so
that
we
don't
have
so
much
replication
and
there's
also
the
idea
of
controlling
the
devil.
I
Rober
hearing
so
we'd
like
to
control
how
many
of
the
parents
in
the
parent
set
actually
forward
the
packet,
and
the
idea
is
that
we
would
use
a
parrot
set
of.
Do
please
go
to
the
previous
slide,
so
I
can
show.
Maybe
so
here
the
idea
would
be
that
a
when
they,
when
a
broadcasts,
his
parent
set,
so
F
E
and
the
G
f
ing
the
same
parents
would
also
listen
to
the
DAO
message
and
they
would
know
that
they
are
in
the
parents
at
away.
I
Now
we
would
control
these
virgins,
but
by
saying
that
a
fixed
number,
a
fixed
subset
of
these
parents
in
the
parent
set
only
forward
in
case
of
overhearing.
So
if
a
packet
is
overheard
by
either
one
of
them,
for
example,
a
and
F
would
forward
as
well,
but
the
G
wouldn't
the
last
one
in
the
list.
So
in
this
case
the
first
two
over
here,
but
last
one.
Next
slide,
please.
I
Next
slide,
so
we
were
wondering
what
the
road
forward
would
be
for
this
draft.
We
have
presented
it
more
or
less
in
the
three
last
IDF
meetings
and
we
have
an
extension
addressing
some
of
these
issues
on
the
way
we
have
received
comments
from
multiple
opponents,
direct
Michael,
Owen
and
Tomas,
and
we
have
published
this
work
in
journal
and
three
conferences.
So
we
are
wondering
if
there
is
a
adoption
by
the
working
group
and
what
that
would
look
like
I
think.
I
I
H
Piscotty,
if
I
can
insist
on
this
one,
we
always
think
we
are
talking
about
radio
networks.
You're
healed.
It's
well
known.
It's
been
well
known
for
very
long
time
that
just
using
a
wired
type
of
thinking
on
these
networks,
where
you
just
pick
a
shortest
path
or
something
your
best
parent
cuz,
he
is
high
level
of
loss.
You
have
a
wireless
medium.
You
need
to
to
think
Wireless
when
you
forward
something
you
don't
forward
to
a
next
step.
H
H
H
C
I
I
There
are
already,
obviously
so.
A
lot
of
this
material
has
already
been
presented
again,
so
I'll
go
a
bit
quickly
over
it.
So
we
have
existing
objective
functions
so
which
help
determine
the
parent,
and
there
is
also
the
load-balanced
objective
function,
which
has
expired
if
I'm
not
mistaken.
Right
now,
next
slide,
please.
So.
The
problems,
at
least
with
the
standard
objective
functions,
is
that
you
don't
have
any
kind
of
balancing
for
the
network.
Some
might
do
more
over
more
forwarding
than
others,
at
least
at
the
same
layer.
You
don't
control
for
node
lifetime.
I
We
have
a
simple
example
here,
where
all
the
nodes,
C
1,
C,
2,
C,
3
and
D
ones,
and
have
the
same
sending
rate
of
packets.
However,
the
power
on
the
left,
the
network
is
unbalanced,
so
a
receives
three
packets
per
second
and
B,
only
one
pack
per
second,
and
if
you
balance
it,
you
basically
need
to
reparent
C
three.
In
this
example,
obviously
c1
or
c2
would
be
good
next
slide.
I
Another
example
worry
all
the
nodes
don't
send
at
the
same
rate
would
be
this.
You
do
have
the
same
number
of
children
or
both
a
and
B.
However
other
nodes
themselves,
the
children
don't
send
it
out
the
same
right.
So
in
this
case,
balancing
them
on
the
right
would
mean
said:
give
setting
D
2
just
to
be
and
putting
all
the
rest
on
a
to
have
a
balanced
transmission
rate.
Next
slide,
please.
I
So
this
metric
tries
to
send
information,
which
is
the
packet
transmission
rate
as
calculated
at
each
node.
It's
information
that
will
be
sent
through
the
DAO
metric
container
and
we
haven't
exactly
decided
how
exactly
expressed
this
information,
but
the
idea
is
that
the
objective
function
that
we'll
be
able
to
use
this
information
will
select
as
a
parent
parent,
which
seems
to
be
less
overloaded,
which
seems
to
forward
the
less
packet
transfer
the
fewer
packets
at
this
moment.
I
I
In
this
instance,
we
implemented
it
a
bit
simpler.
We
just
created
a
new
routing,
metric
matter,
container
type,
I'm,
still
not
100%
sure,
which
would
be
the
correct
approach.
But
in
this
case
we
did
this
way
and
the
information
contained
is
the
packet
transmission
rate.
It's
octet
and
it's
just
a
number
expressing
how
much
the
packet
transmission
rate
at
a
node
sending
list
IO
is
read
next
slide,
please.
So
one
issue
highlighted
during
the
previous
IDF
was
what
happens
if
a
node,
given
that
there
are
neighbor
table
size
limitations?
I
So
if
the
parent
has
a
full
neighbor
table,
one
option
is
for
the
parent
to
send
back
with
the
rejection
status,
saying
no,
you
can't
or,
alternatively,
we
can
integrate
the
packet
transmission
rate
metric
with
a
charge
and
metric,
and
this
way
potential
child
will
know
both
of
the
transmission
rate
of
potential
parent
and
how
many
children
it
hasn't.
This
way
they
might
opt
to
another
parent
who
hasn't
full
RNA
portable,
please
and
now
in
general.
These
issues,
the
what
have
been
we
have
been
working
on,
seems
to
address
two
issues.
I
So
when
you
join
the
network,
you
have
some
information
in
the
eb
packet
and
then,
although
there's
no
discussion
about
that,
specifically,
you
need
to
also
change
a
ripple
instance
and
then,
within
that
a
daughter,
a
specific
total
and
we
have
a
drastic
progress
for
that
issue.
And
then
you
also
need
to
select
a
parrot
parent.
So
the
question
is:
is
there
a
way
of
putting
information
in
such
a
way
so
that
it's
available
at
each
of
these
points
or
somehow
are
using
it
so
that
we
don't
have
address
each
issue
independently?
C
Things
who
has
read
this
draft
one
person,
so
what
I
will
do
I
mean
there
several
drafts,
which
have
been
a
percentage
here
which
are
personal
drafts
and
people's
in
there,
and
the
question
is:
are
we
going
to
take
it
off
in
the
working
group
in
the
working
group?
We
all
have
a
half-life
set
of
traps.
There
is
this
new
beer
were
coming
in,
so
I
think
the
river
group
actually
has
enough
on
its
plate,
also
seeing
what
is
going
on.
C
C
This
is
a
very.
This
is
a
very
old
raft.
It's
the
maple
model
have
received,
and
young
doctors
review
I
have
waited
six
months
at
least
and
I've
implemented.
All
the
changes
to
the
young
model
do
if
you
what
I
added
is
a
section
on
the
network
management
director,
Asha
textured.
It
tells
you
the
structure
of
the
model,
the
data,
the
description
text,
which
was
not
very
clear,
edit
units,
because
it's
also
a
bit
vague
if
about
seconds,
milliseconds
or
anything
else.
So
you
must
have
me
editing
there
in
the
draft.
C
I
have
had
three
modules,
which
are
operation
ceases,
that
this
states,
which
augment
no
and
the
main
module,
as
was
asked
by
the
young
doctor-
and
this
is
new
I
assigned
seats
to
the
young
identifiers-
to
reduce
the
payloads.
So
that
is
the
work
which
has
been
done,
I'm
all
alone
on
this
draft
I.
Don't
think
this
is
very
responsible
attitude,
I'm
looking
forward
to
co-authors,
or
at
least
people
review
it
and
say
things
like
yes,
this
is
what
we
want
to
measure
in
for
young.
C
E
C
In
young,
you
can
specify
both
of
things
which
are
observable
acceptable.
So
if
you
have,
for
example,
for
the
other
graphs
I
think
there
are
lots
of
opportunities
to
add
this
kind
of
stuff
in
and
especially
now
that
we
have
this
it's,
it
gets
much
smaller,
but
it
isn't
open
it,
but
I
would
recommend
other
drafts,
and
not
this
one.
H
H
We
have
worked
hard
at
six
slow
to
improve
the
six
low
registration,
6lowpan
neighbor
discovery
registration
so
as
to
enable
it
as
a
way
to
register
for
various
services,
including
rotting,
back
and
I,
will
show
you
what
we
did
and
how
that
helps
us
that
role.
So,
basically,
the
need
that
that
we
are
talking
about
is
to
be
like
any
router
capable
of
serving
nodes
which
don't
understand
our
Archon
protocol
and
that's
something
that
was
missing.
H
The
other
thing
is
when
you
have
a
node
which
is
deep
into
a
network,
you
have
a
number
of
Kippur
lives
that
you
have
to
do.
One
is
the
down.
You
have
to
keep
your
route
alive,
every
lifetime
units,
and
now
otherwise
the
status
came
up.
The
same
time
you
have
to
to
send
the
dog
back.
The
Cicero
has
to
send
it
back
on
the
Alpha,
the
6ln,
so
as
to
maintain
the
state
for
the
duplicate
address
detection
mechanism
to
work.
H
In
six
Lipan,
there
is
a
concept
of
a
6
lb
or
in
the
6
lb
are
by
definition
in
6,
7
and
G
is
a
border
router,
it's
a
function
of
a
router.
Now,
if
you
look
at
what
6lowpan
does
with
the
6l
bureau,
it
has
only
one
row:
it
is
a
registrar.
It
is
the
place
where
you
store
all
the
addresses
in
your
open.
H
So
you
wonder
why
the
register
and
6lowpan
is
called
a
6
lb,
oh
and
why
it's
defined
as
a
border
router
when
in
fact
all
it
does
is,
is
a
registry.
The
real
border
router
in
a
ripple
Network
is
the
root.
Okay.
So
now,
with
this
question,
should
the
root
be
a
6
lb
r,
because
6lowpan
defines
that
what
it
is
it's
about
a
router
or
should
the
6
lb
r
be
a
separate
entity,
but
then
we
should
not
even
call
it
a
6
lb
r.
H
So
this
Draft
has
two
flows
to
separate
the
two
entities
in
practice.
I
don't
see
that
we
need
that
at
all.
We
could
say:
ok,
let's
make
6
top
and
true
and
effectively
make
the
6
lb
on
the
river
route,
but
it's
kind
of
a
design
decision,
because
if
they
are
not,
we
need
to
implement
flows
like
our
defined
dispatch.
What
I
care,
6
lb
r
wrote
some
guy,
not
some
guy.
H
Okay,
so
if
anybody
can
come
to
the
mic
and
say
yes,
it
makes
sense
to
separate
them.
No,
that
would
be
useful.
So
basically,
this
draft
addresses
all
that.
This
draft
is
what,
if
my
six
allowed
my
6lowpan
router
is
a
Reaper
router.
My
611
doesn't
know
repo,
but
now
it
understands
the
new
6lowpan
Andy
can
I
do
everything
needed
in
repo
so
that
this
guy
gets
these
packets
back.
That's
what
the
draft
is
about.
It
runs
in
the
six
or
are
mostly
the
6
ln.
H
There
is
nothing
to
do
for
it
so
long
as
in
deployment
6lowpan
ng.
So
let
me
just
in
a
few
sentence:
show
you
what
6,
apparently,
what
happened
on
6th
of
rng
and
how
that
impacts
our
live
draft,
so
the
the
main
biggest
thing
that
happened
on
6th
operandi
was
Charlie's
with
you.
We
went
through
all
the
ASG
steps,
I
think
we
okay
and
we
were
in
draft
19
and
then
Charlie
came
in
and
since
he's
a
co-author
yeah,
you
did
a
lot
of
good
editorial
work,
rated
it
it'll
work.
H
The
draft
is
much
more
understanding
more
much
more
well.
The
right
thing
at
the
right
place,
if
you
like,
and
obviously
the
English,
is
much
better.
Now.
It's
not
me
writing
yet,
but
that
changed
the
document
quite
a
bit
so
so
need
to
know
that
this
happened.
Then
we
we
actually
changed
the
way
we
send
either
he
dodged
and
that's
not
too
important
for
repo,
but
what's
more
important,
is
that
we.
H
The
sixth
open
registration
I
cannot
stick
to
the
routing
protocol
that
you
registered
to
initially
6lowpan
ng
was
only
to
register
to
a
6bb
or
a
backbone.
Router,
that's
well.
What
was
a
big
reason
why
we
made
it
now?
We
have
two
routing
protocols,
not
one
but
two
which
actually
refer
6lowpan,
ng
and
benefit
from
it.
One
is
this
draft
and
the
other
one
is
rift.
H
You
know
the
key
thing
is
we
fix
up
an
Indian
node,
which
does
not
that
speak
to
the
routing
protocol
can
indicate,
for
instance,
a
I
was
their
home.
Here
you
have
a
sequence
counter
which
is
missing
in
most
play
on
to
router
interfaces.
So
now
the
routing
protocol
can
inject
the
latest
location
of
the
device
when
it
moves.
So
that's
why
rift
is
actually
keen
on
using
six
open,
MD
and
ripple
well.
I
will
show
that
we
carry
a
number
of
information
as
well,
so
big
change
in
six
dependency.
H
H
So
what
did
we
change
the
80?
We
already
had
the
registration
last
time,
which
translates
into
the
path
lifetime
in
the
dowel.
We
are
the
tid
which
has
the
exact
same
semantics
of
the
path
sequence
in
repo
and
what
we
just
added
is
this
concept
of
well
know
back
then,
today,
with
the
six
Open
Graph,
the
word
yo
PAC
is
used
by
default
when
this
I
feel
sure
is
zero
years.
H
It's
a
topology
indication
if
you
do
multi
topology
writing.
If
you
have
rapport
instances,
then
you
can
fit
that
here
now
the
eye
field
allows
you
to
extend
whatever
you
pass.
The
OPAC
field
is
passed
directly
from
the
client
to
the
routing
protocol
and
so
back
to
six
copa90.
That's
why
it's
called
this
way.
Superman
she
doesn't
care
about
the
repo
instances
and
the
AI
field
is
just
the
way
we
signal
what
goes
into
the
open
field.
Okay,
so
that
that's
the
changes
that
we
made
in
6lowpan
ng.
H
Belief
was
only
somebody
who
would
not
relate
back
yet,
so
this
new
draft
defines
the
ripple
unaware
live,
which
does
not
even
send
it
out
to
first
router
above
it
as
to
send
I
wonÃt
be
else,
but
the
node
does
is
just
plainly
support
the
RFC
6725
update
and
the
F
flag
in
the
update.
Tells
you
whether
you
want
your
router
to
do
ripple
for
you.
It
doesn't
say
ripple
it
does.
H
And
now
the
big
thing
is
the
big
change
in
this
version
of
the
draft
is
that
now
we
can
use
the
arrow
backfield
lining
to
the
change
in
six
double
ng.
We
can
use
the
OPAC
field
to
signal
the
instance
ID.
So
that's
the
way
you
can
have
a
node
registering
to
a
router
and
saying
a
actually.
If
there
is
ripple
above
you
here
is
the
instance
ID
that
I
want
to
use
from
from
a
traffic.
H
H
And
last
but
not
least,
there
is
the
separation
of
the
root
and
the
6l
beyond.
So
if
we
keep
them
separate,
then
there
is
this
whole
section
in
this
document,
which
explains
what
you
do.
Well,
it's
really
a
big
question
for
this
group.
I
really
really
expect
people
to
say
a
what
direction
of
the
other.
Do
we
merge
the
root
and
the
6ro,
or
do
we
keep
all
this
text
in
the
document?
E
H
The
the
previous
okay,
the
sir,
is
talking
about
the
robber
field.
The
robber
field
right
now
is
between
the
six
11
and
the
six
zero.
It
allows
the
seller
to
validate
that
the
6ln
owns
the
address
and
the
question
that
I'm
addressing
is,
since
we
are
using
your
provisions
from
from
6lowpan
to
twinject
rods.
Could
we
also
use
those
provisions
to
protect
the
rods?
That's
one
so.
H
So
yes,
in
this
light
here,
what
you
see
is
the
initial
exchange
note
from
the
address
register
between
6lr
with
an
SRO
that
goes
with
an
extended
all
the
way
to
a6
I'll,
be
right
back,
that's
how
you
do
duplicate
address
detection.
That's
six
open!
Angie!
Just
that
with
the
new
update,
it's
an
extended.
We
have
more
information
there,
but
it's
the
classic
und
flow.
After
that
there
will
be
a
periodic
download
our
watch.
H
You
know
if
you
want
to
save
sending
the
the
dark
again,
all
the
way
from
the
six
are
off
to
the
6
l
bureau.
Then
what
the
drug
does
it
tells
the
route
which
gets
you
know
the
Dow
without
storing
mode
or
non
storing
mode.
The
route
ends
up
getting
down,
uses
that
to
just
keep
alive
the
six
since
we're
missing
information
like
the
rover.
We
cannot
update
it,
but
at
least
we
can
keep
it
alive.
So
that's
what
the
trout
says
there
is
provision
for
that.
H
You
know
by
bon
Rutter:
you
realize
that
the
backbone
roto
is
all
about
rotting,
so
the
guy
who
needs
to
proxy
the
ng
registration
is
not
the
six
LVR
anymore.
It's
the
root.
So
in
run
time,
when
you
have
this,
this
guide
to
ridiculous,
ending
and
then
SRO,
just
as
we
keep
alive,
the
six
Allah
will
send
a
single
Harper
LC
multi-up,
a
single
hop
repeatedly
the
dowel
story
not
stirring
to
the
root.
H
H
C
Who
read
this
draft
want
to
other
things
too?
Okay,
sorry
I
will
send,
as
I
said,
that
was
sent
out
an
email.
There's
an
list
of
to
have
cycles
ask
people
if
they
want
to
contribute,
read
or
review
them
drafts,
and
it
is
a
list,
and
we
have
already
lots
of
work
in
this
very
good,
see
what
comes
out.
Okay.
Thank
you,
but
open-mike.
Who
wants
to
comment
on
how
things
are
going,
for
example,
Raja.
E
Is
there
anyone
in
the
room
who
is
working
on
integrating
ripple
with
the
Linux
kernel
or
any
other
outer
product
Linux
kernel,
basically
integrating
the
ripple,
especially
the
routing
table
and
the
extensible?
The
extension
header
options
that
have
to
be
added
I
just
wanted
to
have
a
discussion
if
someone
is
doing
that,
but
any
other
routing
for
that
matter,
which
any
other
routing
which
is
integrated
with
the
Linux
kernel.