►
From YouTube: IETF-ROLL-20210831-1500
Description
ROLL meeting session at IETF
2021/08/31 1500
https://datatracker.ietf.org/meeting//proceedings/
A
A
A
About
the
related
internet
draft,
we
are
going
to
have
a
newcomer
contract.
Thank
you
very
much
for
joining
us
and
for
pressing
your
work
to
detect
the
crash
in
the
route
and
then
the
65
50
piece
draft
is
open
to
work
for
now
it's
standby,
but
we
have
to
put
more
effort
on
that
too,
and
next
slide.
Please.
A
B
A
B
A
B
A
And
then
the
lighting
diode
information
and
this
modification
are
going
to
be
configured
later,
and
we
have
two
works
that
we
don't
know
how
to
proceed
with
the
mpl
young
and
the
br
comcast,
so
those
which
suppose
are
going
to
be
continued
later
and
as
well.
One
comment
about
ldv
ripple,
it's
like
to
implement
the
yang
for
that,
so
that
will
be
as
well
work
new
work
to
consider.
C
B
B
E
F
B
A
G
C
F
E
Not
the
priority
yeah
at
the
time
we
put
this
in,
we
actually
had
an
implementation
effort,
and
that
seems
to
have
gone
away,
and
I
would
be
a
little
bit
more
comfortable
with
completing
this
if
we
do
have
an
ongoing
implementation
effort.
So
my
personal
status
for
this
is
waiting
for
implementation.
A
A
Thank
you
and
then
yes,
okay,
we
have
at
the
one
milestone
the
ncaa
extension.
So
let's
do
the
sd
next
slide,
but
we
already
are
very
next
slides.
Please
yeah,
thank
you
and
then
for
the
milestones
we
made
the
recharger.
If
we
integrate
the
contract
proposal,
then
we
have
to
split
the
milestone
of
mopeds
and
capabilities
in
two
and
then
update
the
date
from
other
ones
and
about
the
young
and
comcast
yeah.
We
probably
have
to
discuss
with
dominic
what
to
do.
We
can
keep
them
for
now
and
update
the
date
as
well.
A
C
C
C
Another
one
is
to
the
this
document.
1932
is
to
provide
enough
information
for
devices
that
need
to
enroll
or
onboard
to
the
to
the
network,
and
a
third
thing
was
added
to
that:
enhanced
beacon,
which
was
for
devices
which
may
have
already
unrolled
and
which
have
been
sleeping
and
have
lost
their
synchronization.
A
C
All
right
so
anyway,
so
there
was
a
whole
bunch
of
things
that
9032
assumes,
and
one
of
them
is
a
role
priority
next
slide,
please.
Actually
this
is
probably
a
better
way
to
go
through
so
so
this
this
is
the
enhanced
beaten
from
90
32.
There's
this
proxy
priority
in
which
the
lower
numbers
are
better
there's
a
rank
priority.
The
rank
is
something
that
the
local
node
knows.
It's
the
the
ripple
rank
and
it's
locally
known
as
to
what
it
is,
doesn't
need
to
be
communicated
there.
C
There's
a
pan
priority.
It's
unclear
how
it
would
be
configured,
but
I
believe
it
would
be
constant
across
the
entire
dodag
and
so
in
fact
I
think
could
be
added
to
90
31
if
we
needed
to
do
that.
The
join
proxy
interface
id
is
present.
If
there
is
the
l2
and
l3
addresses
are
not
the
same
or
not
the
that
is.
C
If
the
l3
is
not
derived
from
the
l2,
then
we
need
to
transmit
what
the
l3
address
is
in
the
in
the
enhanced
beacon
and
the
network
id
is
calculated
from
the
dodag
id.
So
everything
in
this
sixtish
object
is
known,
except
for
the
priority
of
the
the
jo
of
the
join
proxy,
and
so
that's
what
this
document
is
about
is
primarily
about
so
next
slide.
Please.
C
Some
of
them
are
22
hex
22,
however
heck's
52,
some
of
them
are
hex,
seven
f,
which
means
infinite,
infinity,
don't
join,
and
some
of
them
are
one
of
those
hex,
seven,
two
okay,
so
this
is
essentially
how
do
we
get
this
and
there's
some
slides
that
we
talked
about
in
which-
which
I
don't
want
to
go
through
through
again,
unless
we
need
to
which
explain
how
this
propagated
through
the
the
network
and
how
it
was
added
to
it
next
slide.
Please.
C
So
we
have
the
minimum
enrollment
priority.
This
is
a
metric
and
this
was
added
in
this
document
and
then
we
merged
in
this
other
document
that
wanted
to
communicate
about
the
total
dodge
size,
and
that
is
not
the
dodge
size
is
not
expressed
into
the
into
the
enhanced
beacon,
because
essentially,
as
I
understand
it,
this
is
something
that
will
be
used
to
decide
which
of
many
possible
parents
and
many
possible
pan
ids
you're
going
to
do,
but
that
the
that
the
it's
not
involved
in
enrollment.
C
So
the
question
is:
would
changes
to
the
minimum
priority
be
considered
a
change
from
the
trickle
point
of
view,
because
if
that
is
the
case,
then,
if
that
value
would
change,
then
a
dio
would
be
emitted,
and
unless
that
caused
some
devices
to
change
things,
there
should
be
no
topology
changes,
but
that
the
dio
change
should
be.
If
it
changes
observed
to
change,
then
there
should
be
new
dios.
C
C
Sorry,
if
we
don't,
if
we
don't
reset
the
trickle
timer,
then
we
need
to
put
this
option
and
some
other
thing
which
is
flooded
in
a
better
way
and
if
so,
we're
going
to
be
creating
essentially
a
new
icmp
message
of
some
kind
that
is
going
to
be
flooded
and
what
other
things
would
we
put
in?
It
is
the
question,
so
that's,
I
think
the
conversation
for
today
and
I
think
that's
the
last
slide
next
slide.
Please,
I
think
the
last
discussion
yeah.
C
F
I
think
the
original
intention
was
like
that,
but
yeah
we've
had
this
recent
discussion
and
I
really
really
changed
my
mind
completely
about
it,
and
I
think
that
the
the
mean
priority
should
be
global
to
the
diode
and
same
for
the
steel
deck
size.
It's
up
to
the
root
to
decide
when
it
changes
it
and
when
the
route
changes
it.
Yes,
it
should.
It
should
cause
trickle
to
to
reset,
but
hopefully
the
route
will
control.
F
How
often
it
does
that
and
yes,
it
should
be
propagated
as
soon
as
possible,
so
yeah,
the
node
should
learn
that
there
is
a
new
value,
and
I
think
part
of
the
discussion
we
had
is
that
we
need
to
sequence
those
things.
So
we
know
which
one
is
newer,
and
so
basically,
a
node
which
has
the
new
value
should
should
reset
this
trigger
and
and
the
node,
which
has
another
value,
should
learn
the
new
value
and
refrain
from
sending.
F
C
F
F
G
Not
changing
mean
priority
will
dramatically
simplify
things,
but
there
was
one
use
case
that
we
had
discussed
before.
I
just
would
like
to
point
it
out
that
if
there
is
an
intermediate
router
who's
for
for
some
reason,
if
the
resources
are
exhausted
on
that
router,
there
should
have
been
some
way
for
that
router
to
specify
that
for
all
the
neighboring
modes
to
not
join
through
it.
So
we
won't
be
able
to
satisfy
that
use
case
right.
F
No,
we
we
could
not
already
haul,
because
now
we
are
talking
about
join
right,
but
first
of
all
you
need
to
tell
me
what
resources
you're
talking
about.
Are
you
talking
about
bandwidth?
Are
you
talking
about
memory,
or
are
you
talking
about
how
many
joined
messages
it
can
carry
through?
For
instance,
you
could
say
this
parrot
cannot
take
more
than
six
joints
in
parallel
right
and
if
there
is
a
seven
I
mean
doesn't
have
enough
buffer
to
manage
the
seventh
registration
right.
So.
G
F
F
The
nodes
which
already
joined
you
would
you
know
you
can't
do
anything
over
that,
for
instance,
you
have
a
child
which
has
not
joined
you
and
he
wants
to,
but
he's
already
part
of
the
deodag,
and
he
wants
to
move
to
you
as
a
parent.
There
is
nothing
you
can
do,
and
this
priority
doesn't
doesn't
affect
that.
This
priority
affects
nodes
which
are
not
in
the
diode,
but
but
what
you
care
about
is
globally
all
the
children
of
this
parrot.
So
it's
not
the
right
thing.
We're
not
that's
not
this
value
understand
your.
C
So
so
I
think
there's
two
things:
first
of
all,
it
the
local,
the
local
node.
If
it's
a
when
it's
a
joined
proxy,
could
can
take
this
minimum
priority
and
it
can
add
to
it
a
value
that
reflects
how
many
neighbor
entries
it
has
available
for
joining
nodes.
So
it
could
wind
up
at
infinity
at
7f
on
its
own,
because
it's
run
out
of
out
of
capacity
for
for
being
enjoying
proxy
right.
So.
F
C
F
F
F
C
F
C
That's
what
we
protect
right,
but
the
point
is
that
there
may
be
a
difference
between.
I
have
space
for
three
nodes
to
join
and
I
have
space
for
six
nodes
to
join,
and
so
that
may
be
the
difference
between
you
know:
seven:
zero
and
seven
f;
okay,
something
like
that
right.
So
we
agree,
and
and
and
also
that,
if
the
root
sets
the
min
priority
to
seven
f-
that
no
nodes
can
join.
F
C
F
F
C
That
solves
a
lot
of
the
problem
of
that
we're
trying
to
deal
with
without
worrying
about
about
how
does
it
get
to
the
proxy
right,
so
we
agree
that,
so
what
I'm
trying
to
say
is
that
if
we
make
it
constant
non-incrementing
throughout
the
dodge
that
we
probably
still
get
a
fair
bit
of
of
benefit
conrad,
would
you
like
to
contribute
something
else
to
this
here?
At
this
point,.
D
Okay,
so
I
don't
know
about
the
use
cases.
However,
when
it
comes
to
the
algorithms,
when
I,
when
I
wrote
this
down,
it
seems
that
this
project,
I
called
flexible
in
which
you
are
able
to
actually
increment
your
your
enrollment
priority
per
hope.
It's
not
that
much
more
difficult
than
than
the
approach
with
the
global.
D
So
basically
you
just
need
one
additional
counter
and
the
the
invariant
that
you
might
maintain
is
that
not
the
the
price,
the
priority
of
not
be
being
equal
throughout
the
day,
but
greater
than
or
equal
to
the
priority
of
the
roots.
So
so
so
the
difference
in
complexity
is
not
that
great.
But
that's.
D
Whether
whether
this
would
be
needed
at
all
so
so,
for
that
I
I
have
no
comment.
I
I
can
imagine
that
when
you
have
a
network
such
that
you
you
have
like
really
precise
schedules,
then
sometimes
your
you
would
like
to
disable.
So
basically,
the
only
case
I
see
is
disabling
enrollment
in
a
whole
sub
dot,
but.
E
F
We
are
mixing,
I
mean
a
lot
of
people
have
been
mixing
in
this
discussion:
the
structure
of
the
diode,
how
many
children,
how
much
throughput
gets
through
me,
which
depends
on
the
shape
of
the
doodag
versus
this
value,
and
this
value
has
nothing
to
do
with
the
shape
of
the
dodge.
It
does
not
control
it.
F
C
F
F
No
well,
it's
we
could,
but
we
don't
want
to
that's.
That's
you
know
by
the
discussion
with
conrad.
I
want
to
tell
you
you
don't
want
to
increment
it,
whether
it's
easy
or
not,
and
conrad
said
I
can
make
it
easier
than
you
think.
That's
really
neat,
but
it's
not
what
we
need
and
that's
what
I
hope
to
demonstrate
to
you
guys
today.
F
C
C
F
F
F
C
F
C
F
C
C
B
B
F
F
F
F
G
F
Not
it
shouldn't,
I
mean
if
it
is
anything,
it
should
be
an
option
which
is
not
good,
talking
trick,
which
is
not
impacting
trickle
and
you'll
find
that
you
have
to
define
a
lot
more
than
just
this
value.
You
will
have
to
define
all
the
properties
that
go
with
that,
like
how
you
increment
it
for
what
reason,
and
probably
a
new
objective
function,
which
is
not
for
rotting,
but
for
just
that
purpose,
because
all
the
different
parents
will
have
to
play
with
the
same
way
so
that
one
child
which
needs
to.
F
I'm
saying
that
there's
a
lot
more
work
than
just
having
one
value
and
and
first
it
does-
it
should
not
affect
trico.
It
should
not
be
there.
It
should
be
somewhere
that
we
have
not
defined
yet.
Second,
there's
it's
it's
as
complex
as
defining
routing
itself,
defining
what
you
want
to
do
so,
balancing
the
dodag
inside
the
dodge,
by
just
looking
how
loaded
my
parents
are.
First,
it's
not
a
joint
problem.
It's
a
runtime
problem
for
nodes
already
joined,
and
second,
it's
a
very,
very,
very
hard
problem.
F
I
don't
believe
you
can
even
solve
it
in
a
distributed
fashion.
I
think
it
needs
to
centralize
fashion
to
do
it,
but
that's
just
me,
but
if,
if
you
find
a
good
algorithm
which
works
asynchronously
to
balance
the
structure,
tell
me
about
it.
I'm
interested
so
probably
is
that
transporting
a
value
of
any
kind
in
in
a
message
is
easy:
telling
me
how
to
use
it
to
get
the
results.
You
want
much
harder
and
if
you
don't
give
me
the
algorithm,
I'm
not
interested
in
the
value.
B
D
F
C
A
F
C
So
if,
if
we're
okay
with
that,
then
the
the
question
still
arises
to
me
is
is
putting
in
the
dio
the
right
answer.
Should
we
have
another
message
that
does
not
not
subject
to
trickle
that
the
root,
essentially
always
floods,
and
that's
it
right-
you
want
it
to
trickle,
put
it
in
the
dio.
If
you
want,
if
you
want
to
do
something,
you
need
it
to
happen
immediately,
then
you
me,
we
have
a
new
message
for
that.
We.
F
C
C
C
F
G
Michael,
I'm
not
much
concerned
about
the
resource
requirement
for
handling
the
sequence
counters
because
anything
that
goes
into
the
io,
so
anything
good.
That
goes
into
dao,
I'm
more
concerned
about,
because
it
it
involves
storing
a
value
in
context
or
routing
entry
versus.
If
there
is
something
going
from
the
dio,
it
means
parent
set
and
parent
set
is
usually
much
smaller.
So
I'm
not
crying
about
it.
Just
wanted
to.
F
C
F
F
C
D
D
It
gets
along
with
border
router
crash
detection.
Can
I
get
next
slide?
Okay,
so
why?
Why
do
consider
albir
crashes
in
the
first
place?
Well,
they
play
central
role
in
any
ln,
and
so
as
dodak
roots,
mostly,
they
are
also,
for
this
reason,
typically
more
involved
than
constraint
nodes,
so
they
breach
natural
ie2
networks.
They
coordinate
data
construction,
so
they
are
more
involved
both
in
hardware
and
software
and
typical
deployments,
at
least
those
that
I
had
a
chance
to
participate.
They
usually
require
a
tether
power
supply.
D
So
so
what
happens?
If
we
are,
we
have
certain
failures
in
rebuild,
and
so
you
here,
if
you
see
sort
of
a
mesh
network
with
a
border
router
at
the
left
side.
Next
slide,
so
they
construct
a
dodge
ranks
and
links
to
preferred
parent
from
from
each
of
the
nodes,
and
now
what
next
like
this?
So
if,
if
a
link
fails,
then
what
normally
happens
is
that
an
old
will
detect
this
so
next
slide,
and
this
is
the
detection
and
then
it
will
try
to
do
some
local
repair.
D
It
will
try
to
switch
its
preferred
part.
So,
for
instance,
you
get
the
node
changing
its
parent
to
another
node,
but
also
some
of
its
ancestors.
Sorry,
the
descendants
in
the
dodge
also
may
switch
their
parents
as
well
as
part
of
local
reaper,
so
next
slide
so
once
again,
next
slide.
So
a
more
tricky
situation
is
when,
when
a
node
fails
in
this
case,
what
is
actually
observed
by
riku
is
that
all
links
to
the
node
fail.
So
this
means
that
all
nodes
next
type
detect
those
failures.
D
Actually,
it's
not
necessarily
all
have
to
detect
them,
but
only
those
that
use
those
leaks
depending
on
a
number
of
factors,
but
in
any
case
they
would
detect
the
failures
of
their
links
and
then
next
like
they
will
also
rebuild
their
say,
local
topology.
By
switching
preferred
parents,
probably
also
in
in
the
suburbs
subtrees
descending
from
from
the
failed
node,
so
next
slide
so
on
the
next
slide
with
a
border
router,
it's
it's
more
tricky.
D
So
if
a
border
router
fails,
then
you
can
imagine
that
all
links
to
this
border
router
fail
as
well
so
next
slide.
And
then
what
should
happen
is
that
in
fact,
no
node
in
the
dodge
has
any
path.
The
border
router,
so
no
path
exists
globally,
so
they
should
all
adopt
infinite
ranks
and
drop
their
preferred
parents.
D
It's
just
what
is
important
for
now
is
that
the
the
actually
the
moment
or
the
algorithm
for
detecting
that
the
border
router
is
dead
next
slide.
So
what
happens
in
practice
when
a
rbl
crashes?
So
we
did
like
a
lot
of
experiments
with
different
implementations
and
some
stacks
and
they
usually
have
major
bugs,
so
they
enter
a
chaotic
state
in
which
the
entire
network
collapses.
D
So
you
have
an
explosion
of
control
traffic
and
you
cannot
route
any
message
any
more
and
basically
you
cannot
rebuild
anything
others
that
have
minor
bugs,
so
they
do
not
detect
the
failure
I
mean
in
a
reasonable
time.
So
what
happens
is
that
the
ranks
grow
to
infinity,
but
very,
very
steadily
so
now
the
nodes
form
routing
loops
and
so
on
and
in
the
end.
D
So
why
is
detecting
this
rdl
crash
in
in
repo
like
playing
ripple
sub
optimal?
So
this
is
because
it
relies
on
on
the
emergent
behavior.
So,
first
of
all,
what
you
have
to
realize
is
that
all
nodes
that
have
links
to
the
that
rbr
have
to
detect
that
this
ldr
is
dead,
and
otherwise,
if
there
is
some
node
that
still
believes
that
its
link
to
the
lbr
is,
you
know,
is
alive.
So
it
will
advertise
a
rank.
That
is
finite
and
then
other
nodes
may
may
join
its
sub-dawdah.
D
Then,
if
you
take
a
look
at
how
those
link
crashes
are
detected,
so
this
is
typically
done
in
a
reactive
fashion
and
noriko
recommends
that
so,
if
you
have
low
data
rate
applications,
detecting
a
crash
overlink
may
take
a
while.
So
if
you
have
many
links
to
the
to
the
ldr,
then
it
may
take
a
while
to
remove
all
of
them
and
then
finally,
so
it
will
just
add
to
your
critical
path
and
then
also
like
learning
by
all
nodes
that
actually
know
path
globally
exist.
The
albir
is
also
slow
and
requires
control
traffic.
D
D
Its
goal
is
to
minimize
time
and
traffic
just
to
detect
the
crash
of
the
lbr,
and
what
we're
able
to
achieve
is,
let's
say
in
terms
of
time:
it's
like
a
few
times
up
to
an
order
of
magnitude,
improvement
in
terms
of
traffic,
typically,
a
few
times
less
traffic
required.
The
cost
is
that
you
need
an
additional
option
in
every
diode
most
of
their
lives.
So
next
slide,
please.
D
So
what
design
principle
does
this
algorithm
use?
So,
let's
start
from
the
last
one.
So
actually
our
goal
was
to
make
it
completely
or
as
much
independent
of
frequent
as
possible.
So
this
means
that
it
tries
not
to
affect
the
protocol
or
the
operation
of
the
protocol
in
any
case,
just
when
it's
necessary.
So,
for
instance,
when
the
failure
of
the
lbr
has
been
detected,
then
it
will
affect
ripple
in
such
a
way
that
that
it
would
prevent
it
from
from
adopting
any
new
parents
in
any
particular
version.
D
D
So
this
means
that
the
nodes
collaborate
so
rather
than
relying
on
the
emergent
behavior
that
they
collaborate
on
detecting
the
failure
of
the
root
which
well
allows
for
reducing
the
time
that
is
necessary
to
detect
this
failure.
Then
it
also
avoids
probing
all
links.
So
if
just
sufficiently
many
links
to
the
lbr
are
considered
as
dead,
then
the
algorithm
concludes
that
the
rdr
has
died.
D
D
This
whole
detection
process
by
advertising
finite
paths
and
then
forming
further
routing
groups,
and
then
this
algorithm
also
to
further
improve
this
failure.
Detection
tries
to
proactively
checking
for
rbr
crash
when
there
is
a
suspicion
that
it
might
have
happened
like,
for
instance,
if
there
is
some
sign
that
other
nodes
believe
that
their
links
to
the
lbr
are
down,
then
some
other
note
may
check
whether
it's
link
is
still
up
or
whether
it's
also
down.
F
D
Yes,
yes,
okay,
but
well!
It's
not
that
it's
not
precise,
it's
not
the
precise
definition,
but
it's
well.
They
do
most
of
the
job.
Okay,
but
but
actually
the
coordination
of
everybody
is
needed,
because
the
nodes
that
are
one
hop
away
need
not
be
connected
in
a
single
connected
graph,
so
they
have
to
also
call
it
well.
D
So
we
have
just
two
rows,
so
this
algorithm
divides
nodes
into
two
roles,
so
the
first
one
is
sentinels.
So
these
are
the
nodes
that
do
most
of
the
job,
so
they
monitor
the
status
of
the
root.
They
are
the
roots
neighbors,
so
to
be
a
sentinel,
an
old
must
be
a
neighbor
of
the
root,
but
being
its
neighbor
doesn't
imply
that
you
have
to
be
a
sentinel
and
the
other
role
is
accept.
Also
there
is
other
any
other
node.
That's
not
sentinel,
it's
just
an
acceptor.
D
D
So
basically,
what
rnfd
uses
is
two
local
data
structures
per
node.
One
is
locally
observed,
or
that
would
state
at
called
lowers,
basically
just
an
animal
that
describes
possible
states
and
it's
an
observation
of
any
node
of
of
the
state,
the
global
state
of
the
lodge
root,
and
then
the
other
structure
is
cfrc,
which
is
sort
of
conflicts.
We
replicated
counter
it
counts,
sentimentals
that
exhibit
certain
property.
D
D
So
a
positive
that
consider
a
link
with
the
routers
up
and
then
negative.
Let's
consider
the
link
with
the
root
as
down,
but
previously
I
considered
it
as
up
so
positive.
Cfrc
is
always
greater
than
or
equal
to
the
negative
cfrc,
so
next
slide
piece
and
then
what
what
what
the
protocol
adds
is
is
one
option
so
basically,
is
important.
Is
that
you
just
carry
these
two
cfrc's,
so
positive,
cfrc
and
negative
cfrc.
These
are
fields
that
can
have
variable
length
and
upon
reception.
D
What
you
typically
do
is
you
just
match
you
they
receive
cfrc
with
your
local
ones
and
then
perform
some
actions,
so
the
whole
protocol
is
not
that
difficult
anyway
next
slide.
So
this
is
lars.
The
possible
values
of
this
n
and
then
transitions
between
them.
So
I
can
explain
the
protocol
by
actually
going
through
the
slide.
So
so
next
slide
please.
So
these
two
states,
so
up
and
globally
down,
are
retained
by
all
nodes.
D
So
up
is
a
state,
meaning
that
everything
is
okay,
so
the
root
the
dot
the
albir
is
up
and
down
globally.
Down
means
that
all
nodes
agree
that
the
root
is
down
and
this
product
should
no
longer
be
used.
Then
you
have
two
intermediate
states.
They
can
be
attained
only
by
by
sentinels,
so
it's
suspected
down.
This
means
that
some
sentinel
suspects
it's
linked
to
the
root
being
down
and
then
locally
down.
This
means
that
the
sentinel
actually
considers
its
link
to
the
rule
with
down.
D
D
So
if
it's
a
sentinel
at
some
point
starts
suspecting
that
the
root
may
be
down,
it
can
do
this.
Suspicion
have
these
suspicions
based
on
external
observations,
sorry,
the
data
plane
so
like
external
events
like
lost
by
hop
acknowledgement.
So
this
is
like
implementation,
specific
or
internal
events
like
local
values
of
cfrcs.
D
D
So
it
can
perform
some
verification,
for
instance,
try
to
send
like
a
ping
to
the
root
or
whatever,
and
if
it
confirms
that
it's
linked
with
the
root
is
down,
then
it
translate
locally
down
and
while
in
this
state
it
increments
its
negative
cfrc,
which
and
aims
to
trigger
other
nodes
to
indicate
to
other
nodes.
Other
sentiments
that
something
may
be
happening
with
the
roots,
so
they
may
wish
to
decide
to
perform
their
own
verification
of
the
links
with
the
root
so
next
type.
D
Sometimes
you
may
want
to
skip
the
verification,
so,
for
instance,
if
you
are,
if
your
node
is
doing
routing-
and
you
are
not
so
forwarding
to
the
root,
so
you
are
sending
and
forwarding
data
to
the
root
and
don't
get
any
acknowledgements
or
whatever
replies
to
your
your
pings
then
well.
You
may
well
believe
that
your
link
is
indeed
done
or
simply
your
enable
reachability
detection
claims
your
link
with
the
root
to
be
down
then
transit
directly
locally
down
without
this
suspected
down
in
between
I.
D
Finally,
if
sufficiently
many
sentinels
consider
the
link
with
the
links
with
the
root
to
be
down,
then
what
happens
is
that
any
node
in
this
case,
an
acceptor
or
a
sentinel,
can
make
a
decision
that
the
route
must
be
down,
so
it
transits
to
globally
down
and
appropriately
changes
its
cflc's
and
then,
when
they
propagate
in
diodes,
actually
every
other
node
and
also
transits
to
globally
down,
and
so
next
slide
wiring
globally
down.
So
this
is
a
terminal
state,
meaning
that
no
routing
is
possible
in
this
particular
product.
D
D
D
So
if
your
network
is
very
sparse
like
what
you
said,
you
have
a
cross
and
if
no
part
of
the
cross
is
actually
connected
in
any
way
with
another
part
of
the
cross,
then
well,
you
have
two
options,
one
you
can
consider
sufficiently
many
as
basically
I
don't
know
how
many
links
with
the
cross
you
have
in
your
let's
say
so
suppose
that
you
have
those
four
network
types.
So
you
divide
the
the
number
of
links,
the
possible
number
of
links
with
the
root
by
four
and
well
divided
by
half.
F
D
F
D
The
thing
is
that
they
need
not
vary
in
in-
let's
say,
I
would
say,
normal
networks
in
a
sense
that
you
have
not
this
extreme
case
of
a
cross
like
if
you
have
sufficiently
connected
network.
I
I'm
not
claiming
that
your
all
sentinels
have
to
be
connected,
but
that
your
network
as
a
whole
doesn't
have
this
sort
of
bridges,
removing
which
actually
removes
well
partitions
the
network.
So
most
networks
have
a
few,
if
not
zero
nodes
of
that
type.
Otherwise,.
F
I
still
would
suggest
conrad
that
you,
you
consider
what
I
taught
you
earlier,
which
is
try
to
do
most
of
your
operations
through
the
route
like
like.
If,
if
you
trickle
through
the
route
right,
everybody
all
the
sentinels
can
send
something
and
because
of
trickle,
there
will
be
only
one
and
it's
a
multicast
to
all
sentinels
and
you
send
it
through
the
root.
C
F
And
if,
if
there's
no
hack
at
the
lower
layer,
because
you've
become
very
much
more
aggressive
pulling
the
route,
now,
you
can
detect
that
the
root
is
down
and
everybody
can
do
that
pretty
much.
At
the
same
time
and
that's
very
important
from
what
you
said
earlier.
You
want
all
the
sentinels
to
detect
at
the
same
time,
because
they
will
all
start
sending
the
ios
with
the
g
bit
off
or
something
and
you'll
avoid
all
those
ping
pongs
that
you've
discussed
so
so.
F
C
C
F
It's
trickled
out,
so
you
have
two
every
period
and
the
period
is
increasing
blah,
but
when
the
two
of
them
don't
flow
through
during
one
period,
all
the
nodes
start
sending
their
own
because
they
are
not
cancelled
and
they
don't
get
lower
layer,
ack
and,
and
so
ideally,
that
would
reset
their
trickle
timer,
which
is
not
really
triggered.
But
if
basically,
failure
to
receive
the
one
of
the
two
or
three
messages
during
a
period
is
considered
like
a
problem,
then
they
would
aggressively
pull
the
all
of
them.
F
D
D
F
C
F
D
D
I
think
that
the
most
of
the
delay
gets
from
the
fact
that
you
have
like
local
rebuilding,
so
basically
the
propagation
of
the
information
down
the
dodge,
for
which
you
really
need
those
dials
and
cfrcs,
so
they,
I
think
at
most
of
the
latency.
So
once
anybody
decides
that
the
route
may
be
down,
then
what
happens
is
that
then
this
information
spreads
very
quickly.
D
So,
basically,
the
verification
part
of
the
stuff
which
is
which
is
actually
left
out
of
the
draft,
but
it
may
be
actually
nice
to
have
it
as
a
suggestion
how
you
can
implement
this,
but
the
core
algorithm
relies
on
quickly
propagating
this
information
on
the
root
being
down
throughout
all
nodes
so
that
they
don't
start
forming
loops
and
so
on.
So
I
think
this
is
complementary,
but
let
me
also
think
about
this
offline.
B
B
D
B
F
F
F
We
had
we
had
other
primes
for
which
we
we
shipped
solutions
in
our
fans
and
and
and
found
that
tuning
in
trying
different
stuff,
and
so,
if
we
standardize
it
and
after
six
months
we
find
you
know.
Actually
the
algorithm
needs
to
be
changed.
We'll
have
we'll
have
locked
all
the
records
and
all
you
know
in
in
the
messages
and
blah
blah
and
I'm
concerned
that
this
is
a
very
difficult
topic.
F
F
Compatibility
etc,
so
so
so
yes,
first
it
needs
to
consider
backward
compatibility
or
to
be
upgraded
easily
and
backward
compatibility
blur
and
so
right
now
it's
a
it's
a
beautiful
algorithm.
It
needs
to
account
for
a
lot
more.
So
as
an
experiment,
I'm
okay
as
a
standard
track.
It
will
take
a
lot
more
thought.
Do
you
want
to
do
it
in
one
shot
or
they
want
to
first,
do
some
experiment
and
then
do
the
real
thing
now,
just
the
question
about
going
through
the
route
or
not.
F
F
B
F
Yeah
expecting,
though
so
I
did
not
put
too
many,
I
just
I
just
focused
on
one
problem.
So
let
me
give
you
an
update
on
on
where
we
are
and
actually
this
update.
I
prepared
it
almost
last
minute
because
sorry,
you
get
chairs
for
being
late,
but
because
we
had
a
lot
of
discussion
on
the
draft
very
recently.
So
I
tried
to
accommodate
some
of
that.
I
could
not
accommodate
all
because
we
got
iot
review
like
two
days
ago
and
it's
very
big
review
by
tourist.
So
I
can't
thank
torlas
enough.
F
So
many
many
thanks.
It's
not
that
will
to
listen,
but
so
I
started
accounting
for
that
and
that's
the
reason
why
I
did
not
publish
20.
and
I
saw
dominic
thanks
so
much
that
you,
you
made
a
review
on
19,
but
there
were
a
lot
of
changes
due
to
adan's,
review,
etc
from
19
to
20..
So
I'll
see
how
I
can
apply
the
divs,
but
it
will
probably
not
be
as
easy
as
I
would
like
it
to
be
okay
anyway.
F
So
next
slide,
please
so
yes,
17
to
19
so
three
versions
since
lasting
train,
which
was
six
months
ago,
I
guess
january-
was
it
and
20
is.
I
should
have
published
20
after
adam's
review,
but
that's
when
tallest
review
came
in
and
sadly
because
you
should
really
have
done
it
because
you
did
your
review
19..
F
So
the
we
clarified
how
you
find
the
the
sibling
address,
which
was
missing,
and
so
now
we
have
more
dependency
on
9505
and
we
try
to
simplify
again
and
one
big
simplification
we
discussed
was.
Who
can
send
the
pdr
and
related
is
what's
the
name
space
for
the
track
id?
You
know
the
track
id
is
the
pair
of
an
ip
address
which
is
also
destination
of
the
packets.
F
So
it's
the
tracking
grass
on
the
track,
rice,
basically
and
a
number,
which
is
a
local
instance
id
in
ripple
terms.
So
it's
64
bits.
Basically,
so
you
you
have
that
that
space
to
to
express
yourself,
and
so
the
simplification
is
the
the
pdow
request,
which
is
you
know
the
request
by
node
in
in
the
field
to
to
go
to
the
root
and
say
please
build
the
track
for
me
now.
F
It
can
only
come
from
the
tracking
grass,
which
will
be
the
root
of
the
small
diode
id
small
diode,
and
so
it
will
be
quote
unquote
the
diode
id,
and
it
will
also
be
the
name
space
associated
to
the
track
it
to
the
ripple
instance
id
to
form
the
track
id.
So
so
that
makes
things
very
simple,
so
basically,
not
b
cannot
say.
I
want
to
track
from
a
to
c
only
a
can
say
I
want
to
track
from
a
to
whatever.
F
F
A
lot
of
work
on
maintenance.
I
mean
anand
really
raised
the
question
of
what
happens
when
basically
there
are
breakages,
etc.
So
I
that
will
be
my
some
slides
today
and
I
I
just
show
how
it
works.
It
doesn't
involve
any
new
stuff
new
function.
It's
just
that
the
text
was
not
really
there
to
to
explain
how
it
works
and
what
happens,
and
so
it
was
kind
of
implicit.
Now,
it's
more
explicit
what
I
did
as
I
did.
F
That
is,
I
added
the
concept
of
leg,
because
that
term
was
missing.
When
you
do
a
segment,
a
segment
is
a
story
mode,
strict
sequence
of
notes
and
that's
basically
between
two
loose
nodes.
For
instance,
when
you
you,
you
have
the
main
geodag
and
you
want
to
make
your
source
rotator
loose,
sparse
between
two
hops
in
the
source
rat
header.
You
need
a
segment
which
will
allow
one
hop
in
the
source
rotator
to
reach
the
next
half
in
the
source
rotator.
F
So
that's
what
that's
the
story,
mode,
strict
list
of
nodes
between
one
hub
and
the
next
hub
of
the
loose
source.
So
that's
what
the
segment
is.
It's
a
story
mode
thing
now,
when
you
don't
use
the
mendeo
dag
for
doing
your,
your
your
rotting
headers,
you
want
a
non-stirring
geoduck
for
being
the
track.
F
What
we
can
build
today
with
the
the
draft
is
a
loose
sequence
of
nodes
between
the
ingress
and
egress.
So
so
you
need
to
see
it
as
several
lines,
more
or
less
parallel
between
the
source
and
the
destination
they
can
cross.
But
it's
mostly
like
several
lines
between
source
and
destination:
it's
not
really
a
geoduck.
That
will
be
the
big
question
that
I
want
to
discuss
today.
What
we
can
build
is
not
really
a
deodag.
F
What
we
can
build
is
really
a
number
of
parallel
lines,
so
I
call
them
leg
to
clarify
that
and
again
those
legs
can
cross.
They
can
two
two
of
them.
They
can
make
you
eight
instead
of
two
parallel
lines,
but
still
it's
from
source
to
to
increase
to
egress
sequence
of
nodes,
and
so,
if
we
really
want
to
to
do
deodags,
probably
we
want
to
add
some
stuff,
but
this
is
already
very
good
because
you
can
do
oneplus
one
blah
blah
blah.
F
Also,
I
clarified
that
everything
policies
is
out
of
scope.
It's
not
part
of
this
document
against
simplification,
because
people
would
see
that,
as
you
know,
segment
rotting
or
something
where
you
have
this
packet
and
you
want
to
decide.
Should
I
use
the
main
gear
dag
to
fold,
or
should
I
inject
it
in
the
truck?
So
I'm
the
tracking
grass
I've
got
a
packet
destination,
is
ra
can
be
routed
through
the
tracking
grass
okay?
So
I
have.
F
I
have
the
speedo
which
allow
me
to
get
to
the
track
you
guys
directly,
but
they
could
still
reach
through
the
route
if
I'm
not
storing
or
through
the
normal,
storing
mode
diode
so
which
one
should
I
use.
Is
there
a
policy?
No,
there
is
no
policy.
If
people
want
to
do
policies,
it's
going
to
be
done
somewhere
else.
F
F
F
The
draft
on
the
github
already
covers
what
anand
said
and
I'm
working
on
tara's
discussion,
and
it
takes
time
it's
very
long
and
very
interesting
review,
so
so
yeah.
I
think
I
will
go
through
tourist
review,
publish
what
I
get
as
20
and
then
with
taurus.
We
will
fix
the
bugs
left
and
then
we'll
have
to
address
this
deodorant
story
that
we'll
discuss
today
next
slide,
please
so
announce
review.
F
Basically,
one
of
his
main
points
was
to
you
know:
how
can
the
root
control
the
the
dodge
if
the
path
of
inside
the
track,
if
he
cannot
reach
the
nodes?
And
so
we
clarified
that
a
node
which
belongs
to
a
truck
should
should
have
multiple
parrots
and,
and
so
send
you
know,
is
down
to
the
root,
indicates
indicating
multiple
transit
and
and
so
that
you
know
recursively,
hopefully
that
that
gives
us
more
than
one
source
right
path
from
the
root.
F
So
if
the
root
has
to
retry
a
pidao,
it
should
retry
on
a
different
source
right
path.
So
so
we
we
basically
clarified
that
to
improve
the
reliability
of
the
control,
but
at
the
same
time
we
don't
want
to
build
track
between
the
route
to
the
track
member,
because
then,
who
would
control
those
tracks
right?
F
You
know
who
grounds
the
guardians.
Basically,
so
we
don't
want
to
get
into
a
recursive
problem.
We
just
want
to
make
it
quite
relatable,
and
if
there
is
enough
redundancy
in
in
the
track
by
having
multiple
parallel
legs,
then
you
know
if
something
is
broken.
Even
if
the
root
is
not
connecting
to
all
the
nodes,
it
can
start
repairing.
F
But
during
that
time
we
we
can
use
what's
left
to
to
still
transfer
the
packets
using
the
redundancy
to
survive
before
the
root
can
do
everything
so
clarified,
which
was
already
there
that
the
no
path
dao
is
how
we
indicate
that
we
remove
something-
and
this
indicates
it's
recognized
by
a
lifetime
of
zero,
and
we
also
documented
that
in
storing
mode.
So
when
we
build
segments,
we
can
just
change
a
section
of
the
segment.
F
So
when
you
create
a
segment,
for
instance,
a
to
h
here,
you
have
to
signal
in
one
vio,
all
the
all
the
members
of
the
segment.
So
you
see
this
strict
list
of
nodes
and
the
pdow
arrives
at
h
comes
across
over
upstream.
Basically,
all
the
way
to
a
and
a
does
the
acknowledgement
so
for
the
first
p
dial,
which
creates
the
segments
you
need
to
have
every
one
of
them.
But
when
you
repair
you
see
this
broken,
I
mean
maybe
c2d
because
of
interference
and
maybe
d2g
well.
F
F
F
The
only
loss
that
you'll
encounter
is
is
the
one
which
were
caused
by
the
interference
itself
and
which
triggered
possibly
the
the
repair,
but
the
the
process
itself
will
not
break
and
make
it's
actually
you
make
before
break
so
so
you
don't
lose
packets
because
of
the
process
itself,
and
so
I'm
explaining
why
in
the
next
slide
for
a
segment.
But
when
you
look
at
the
whole
track,
which
has
multiple
segments
joined
by
sex
source,
routing
non-story
you'll
see
that
the
same
story
works
as
well.
F
F
So
when
the
root
is
aware
of
that,
it
will
sound
pidao.
So
we
are
in
story
mode
here
we
are
talking
about
the
segment,
so
the
pw
goes
to
the
end
of
the
repaired
section.
So
that's
g,
so
the
the
beginning
and
the
end
of
the
reaper,
the
repair
section
must
you
know
they
must
be
still
attached
to.
They
must
not
be
broken.
Basically,
you
fix
what's
between
them,
but
those
ones
are
stay
attached
where
they
were
either
upstream
for
c
or
downstream
4g.
F
F
E
F
F
Okay,
okay,
so
just
look
at
the
picture
and
you
figure
that
as
the
pdow
progresses,
the
pack,
the
the
the
packets,
still
follow
the
old
path
and
see
if
the
old
pass
is
still
operating
not
as
well,
but
separating
the
packets
are
not
lost
and
when
the
p
double
reaches
c
c
commutes,
the
the
because
it
is
the
new
segment
sequence.
It
comes
to
the
upstream
path
and
you
see
it's
already
built
all
the
way
to
the
end.
F
So
there
is
no
packet
loss
and
then
there
could
be
another
pdaw
to
just
clean
d
separately
with
a
lifetime
of
zero.
So
next
slide,
please
you
think
about
it,
but
you
see
it's
not
working,
so
we
need
to
skip
that
was
discussing
a
track.
What
I'm
saying
in
this
slide?
Basically,
is
we
only
build
multi-legged
tracks?
We
don't
build
geodex,
and
this
is
an
example
of
a
multi-leg
dag
well
track
with
two
legs.
F
You
know
the
first
source,
rod
path
and
the
top
second
source
rod
path
is
on
the
bottom,
and
each
of
the
segment
is
a
storing
mode
vio.
So
what
we
see
is
we
can
take
path
a
or
psb.
If
there
is
a
breakage,
you
can
see
the
two
legs,
but
but
really
it's
not
a
geoduck
as
we're
used
to
and
the
question
is:
do
we
want
to
to
build
real
deal
dax
next
slide.
F
By
the
way,
the
other
thing
we
don't
have
which
exist
in
row
is,
we
don't
have
no
south
segments
with,
because
we
are
working
on
ripple.
We
we
only
build
the
dags,
so
there
will
never
be
bi-directional
segments.
They
will
go.
They
always
go
east
well
left
to
right,
really,
which
is
west
to
east
side.
A
little
bit
always
go
left
to
right.
F
Okay,
this
is
the
goal
we
would
like
to
be
able
to
to
to
have
node
a
or
not
c
decide
if
they
go
to
e
or
or
down
like,
should
c
use
segment
one
or
should
you
should
see
use
segment
seven
or
should
you
should
c
replicate
over
segment
one
and
segment?
Seven!
That's!
If
we
build
the
geoduck,
that's
a
real
deal
that
we
would
like
to
build,
but
with
with
the
vios
which
are
sequence
of
nodes,
it's
very
hard
to
build.
You
cannot
build
that
next
line.
F
F
F
It
makes
the
ingress
code
more
complex
because
it
becomes
a
root,
but
it
also
enables
much
more
topologies.
So
if
we,
if,
if
our
nodes
are
capable
to
do
what
the
root
does
then
this
proposal
on
the
table,
you
could
build
real
dodge
as
opposed
to
just
parallel
legs,
which
is
a
lot
easier
by
the
way.
Okay.
So
any
discussion
on
that
and
that's
my
last
slide.
F
If
I
don't
get
comments,
I
will
just
insist
on
one
thing:
building
real
deal,
dags
the
road
activity
here
is
a
lot
more
complex
than
the
parallel
legs
that
we
have
for
the
route
so
for
the
ingress,
but
it
enables
raw
it
enables
much
more
capabilities.
So
for
me,
it's
really
a
another
mode
for
what
we
are
doing,
because
if
you
look
at
the
parallel
legs,
what
is
signaled
to
the
ingress
is
basically
almost
you
know
the
rotting
header
that
is
going
to
put
in
the
packets
very
easy
it
just
takes.
F
What's
in
the
dio
puts
it
in
front
of
the
packet
as
an
encapsulation
and
the
packets
fly.
There
is
no
computation.
There
is
nothing
very
easy
if
we
do
what
I'm
proposing
here
or
if
we
standardize
it.
Yes,
we
know
it
works
because
that
emulates
exactly
what
we
do
today
in
non-storing,
but
that
makes
the
ingress
as
complex
as
the
normal
route
to
compute.
You
know
the
source
rotator
that
you
want
to
use
at
this
time.
That's
what
raw
wants.
F
F
F
F
Well,
the
implementation
is
more
room
and
it
needs
more
computation
to
be
able
to
operate
because
it's
gonna
get
what
the
root
gets
today.
You
know
those
those
packs
or
of
this
child
as
those
parents,
and
so
it
needs
to
reconstruct
the
geoduck
in
his
mind
when
he
wants
to
go
to
the
egress.
He
needs
to
select
a
path
in
that
diode
put
it
in
a
source
rotator,
and
now
we
can
send
with
what
we
have
in
view.
The
the
source
rotator
is
is
pre-built
in
the
dio.
F
I'm
sorry
in
the
pillow,
it's
pre-built
it
just
picks
it
copies
it
in
the
packet
bang.
It
goes
over
that
leg.
So
so
the
the
ingress
needs
a
lot
more
code,
but
the
capabilities
are
you
go
from?
You
know
plain
serial
routing?
Well,
you
know
just
a
shortcut
in
a
repo
but
really
similar
to
ripples
today
to
something
which
is
capable
of
doing
raw
death
nets.
You
know
so
you
know
replication,
elimination,
basically
and
all
those
games.
So
I'm
not
saying
people
should
implement
that
today.
F
F
B
D
C
I
was
going
to
say
pascal
I
I
followed
along.
I
don't
have
a
strong
feelings
about
alternatives
to
your
proposal
about
but
read
about
about
the
about
how
to
pack
them,
and
I
have
to
think
a
little
bit
more
about
the
question
about
track,
ids
and
their
scope,
but
I
think
you're
banging
on
on
that
point,
though,
probably.
F
F
You
know
the
action
is
deported
to
the
ingress,
but
the
source
rat
is
pre-digested
by
the
main
route,
and
this
proposal
here
is,
for
you
know
the
next
step,
where
the
root
the
real
root,
instead
of
putting
the
the
legs
pre-digested
just
gives
the
geode
itself
to
to
the
tracking
grass
and
the
tracking
grass
is
free
to
to
design
source
rod
pass
inside
that
diode.
So
it's
more
complexity
in
the
ingress,
but
it
gives
it
opens
to
to
row
and
all
that
stuff.
F
C
Okay,
well
then,
maybe
it's
not
worth
the
document,
then
my
only
thought
was
that
if
a
lot
of
thought
think
about
it,
then
then
we
might
people
might
want
to
have
a
lot
longer
opportunity
to
to
figure
out
what
to
do
and
there
might
be
multiple
options
and
that
we
wouldn't
want
to
stop
hold
up
document.
But
if
it's
that
short,
then
okay,
never
mind.
F
F
So
so
that's
basically
the
proposal
on
the
table
now
so
so
we
know
it
works.
It's
it's
not
many
words.
It's
just
one
more
capability
for
this
draft
versus
writing.
Another
draft
we've
seen
with
ripple
that
doing
a
v2.
It
can
take
very
long
and
we
don't
even
know
if
it's
going
to
come.
So
that's
why
I
want
to
pack
this
in
inside
this
one,
but
maybe
it's
too
much
and
somebody
with
a
good
advice
will
team
will
tell
me
you
need
to
stop
somewhere
and
we're.