►
From YouTube: IETF115-ROLL-20221108-1500
Description
ROLL meeting session at IETF115
2022/11/08 1500
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
Meeting
tips
please
remember,
to
register
to
that
session.
If
you're
remote,
you
have
joined
already
through
miteko.
If
you
are
in
the
room,
join
through
the
on-site
version
of
the
tool
and
if
by
any
mistake
you
register
you
joined
through
the
the
full
tool,
make
sure
your
sound
is
turned
off
so
that
we
don't
have
local
Eco
here
if
you're
remote,
please
and
and
want
to
speak,
make
sure
you
use
a
headset.
Otherwise
we
would
get
ego
as
well,
most
likely.
A
A
Yeah
yeah
I,
don't
know
we
are
taking
notes
on
code
EMD.
The
link
is
here
on
the
second
line.
Please
join
taking
notes.
We
have
a
micron
Ivan
already
committed
to
take
notes
but
feel
free
to
join
and
help,
especially
if
you
say
something
ask
questions,
go
back
into
the
notes
and
make
sure
the
your
question
was
correctly
understood
and
your
happy
with
the
way
it
is
represented.
A
We
have
a
chat
on
zulip
as
well,
and
yes,
if
you
want
to
edit
the
minutes,
you
need
to
be
logged
in
through
the
data
tracker
and
that
will
serve
to
log
into
the
the
minutes
as
well.
B
Give
a
working
group
a
status
then
we
are
going
to
provide
some
more
details
in
current
documents
like
NSA
audio
variable
normal
priority
mopex
are
in
FD,
then
Pascal.
We
provide
the
update
on
the
projection
with
the
shipper
document
is
in
progress
then
Pascal
we
provide
as
well.
They
work
on
six
long,
multicast
registration
and
then
we
have
open
floor
for
further
comments.
A
We
have
a
message
on
the
main
display
here
in
front
of
us
that
says:
shut
down.
Yes,
no
I,
don't
know
how
to
say.
No.
So.
C
D
C
B
A
B
Okay
about
the
jello
draft,
we
are
going
to
provide
some
more
details
and
about
the
blue.
Double
projections
is
going
to
be
discussed
today.
Yep.
B
So
for
the
milestones
we
are
a
bit
delayed
with
the
double
projection,
so
we
will
need
to
ship
it
as
soon
as
possible
and
then
for
the
jello
ones.
We
need
to
put
the
efforts
on
completely
those
works
too.
A
Okay,
so
we're
going
we're
going
through
the
list
of
a
few
drafts
that
we
have
in
the
group-
and
we
don't
have
the
offers
here
to
talk
on
so
we
have
an
X
NSA
extension
just
to
remind
everybody.
This
is
a
draft
that
proposes
a
new
objective
function
and
a
new
metric
container
extension
to
carry
the
set
of
parents
of
a
node
in
a
Dio,
and
that
allows
a
node
that
receives
the
diode
to
know
its
potential
grandparents.
A
And
so
we
had
the
adverse
review
in
March
asking
a
few
questions
providing
comments.
20
of
those
about
20
of
those
who
are
noted
as
major
comments
and
well
yeah,
the
authors
are
still
working
on
them,
so
please
yeah
I'll.
We
keep
bugging
them,
but
we
really
want
to
move
this
forward.
We
need
a
revised
draft
before
we
can
send
to
our
ESG.
So
that's
NSA
extension
that
we
have
in
the
works.
B
B
B
How
can
you
detect
when
you
have
a
lot
of
audible,
Ripples
and
connections?
How
can
you
the
intermediate
routines,
identify
the
objective
function,
so
the
authors
propose
to
use
a
triple
origin.
Note
Target
note
and
ripple
instance
ID
okay.
They
proposed
that.
But
there
was
not
the
comments
on
the
main
list,
so
we
believe
that
this
is
accepted
as
it
is.
B
Yeah
then,
okay,
a
new
version,
was
published
on
the
version.
15
was
published
on
September.
Basically,
this
version
address
the
ticket,
one,
the
discuss
of
John
scooter.
Basically,
the
comments
were
to
improve
readability
then
address
as
well.
We
believe
the
address
ticket
to
bend
discussion
discuss
to.
Basically
the
discuss
provide
comments
to
improve
the
protocol.
B
The
outdoors,
we
believe,
I,
have
addressed
all
the
comments
they
have
replayed
to
them,
but
we
have
not
heard
back
from
them,
of
course,
because
he
changed
position.
So
we
believe
that
those
tickets
as
well
are
addressed.
B
Then
we
have
as
well
Pascal
review,
but
this
one
is
the
ticket
number
three.
There
is
some
comments
that
you
did
Pascal
that
still
are
in
the
in
the
document.
They
were
not
fixed
in
the
version
15..
So
do
you
do
you
know
if
the
version
15
addressed
your
comments?
B
Okay,
okay,
so
we
will
take
us
an
action
point.
But
yes,
there
are
some
comments
that
you
did
that
there
were
not
others.
They
were
still
the
fifth
version
15
with
these
errors.
So
then,
the
review
by
contract,
it
was
addressed
and
we
got
comments
in
the
Middle
East
in
October.
B
E
Michael
Richardson,
so
this
document's
kind
of
come
and
gone
for
seems
like
several
years
to
me.
E
E
So
I'd
really
like
to
see
these
others.
Authors
maybe
could
get
more
involved
and
finish
this
document
and
get
it
out.
Otherwise
it
just
it.
It's
I
think
very
hard
for
all
the
reviewers
to
hold
on
to
review
for
sometimes
years
and
then
figure
out.
What's
going
on
so
I,
don't
know,
I
think
the
working
group.
We
should
just
kind
of
put
a
bit
of
a
deadline
on
on
this
and
if
we
can't
move
it
forward
by,
you
know
January
1st
or
something
that
we
should
just
take
it
off
our
list.
E
B
Thank
you,
Michael
yeah,
well,
Charlie
replied
that
he
will
work
in
last
weeks
and
in
a
few
weeks.
But
yes,
we
need
to
put
a
deadline
for
to
get
this
closed.
B
Then
foreign
priority.
Well,
we
have
these
seven
issues
open,
so
I
think
Michael.
You
will
work
on
that
when
you
have
time
right
based
on
we
understood.
B
Okay,
thank
you
very
much,
then
mopex.
A
Just
introducing
for
those
who
are
new
to
the
group,
The
Ripple
operates
in
multiple
modes
and
we
have
a
mode
of
operation
field
in
the
instance
that
describes
the
mood
of
operation
so
that
no
no,
if
and
how
they
want
to
join
that
instance,
and
we've
run
we.
We
are
running
out
of
the
the
values
in
that
field.
So
this
draft
is
about
extending
that
field
mode
of
operation.
Hence
the
name
model,
preparation
extension.
A
B
You
then
fast
forward
rotary
class
detection
in
Ripple,
so
this
work
was
at.
The
working
group
is
proposed
as
an
extension
of
Ripple
introduced
a
root
note
for
detection
options
that
is
carried
in
dios
and
this.
This
document
is
well
proposed.
Two
roles,
acceptor
and
Sentinels
antennas
are
the
ones
that
are
neighbors
of
the
road
and
then
taking
monitoring
the
route
and
as
well.
They
have
introduced
a
counter
conflict-free
replicated
counter.
B
Then
it
was
present
in
the
last
interim
meeting
and
there
was
a
new
version
published
recently.
Basically
with
the
editorial
comments,
then
the
questions
here
basically
were
based
on
the
discussion
how
the
Sentinels
can
detect
if
the
root
is
alive
or
not
so,
for
example,
yeah
what
happens
when
the
Sentinels
don't
hear
each
others,
those
the
algorithms
still
detect
the
crash
of
the
road?
Yes,
then,
what?
If
most
of
the
direct
links
to
the
root
fall,
but
the
root
is
is
in
fact
alive.
B
The
root
knows
when
there's
something
else
are
full
and
then,
if
it's,
how
the
root
get
back
to
us
that
status
up
basically
to
get
a
new
DOTA
version,
then
there
are
some
other
questions
that
they
still
need
to
kind
of
contribution
of
the
working
group,
for
example,
and
where
the
counter
is
located,
and
it's
a
it's
a
for
example,
in
the
option
tie
option
and
as
well,
for
example,
the
when,
if
the
several
Sentinels
have
different
threshold
in
order
to
detect
if
the
root
crash,
how
you
which
one
you
take
into
considerations
well,
actually
you
take
the
one
that
has
the
lowest
threshold
but
I
think
I
as
well
have
to
be
explained
a
bit
more
into
the
document.
B
So
these
are
basically
the
last
questions
that
were
present
in
the
mailing
list.
I
need
more
of
the
discussion
or
contributions
and
reviews
and
as
well
I
think
we
get
the
document
Shepard
Michael.
Do
you
want?
Yes,
thank
you.
So
Michael
is
the
documentable
of
this
document
and
probably
if
all
these
issues
are
addressed,
we
just
can't
move
forward
with
this
document.
B
F
F
This
is
about
the
right
projection
draft
for
repo,
so
just
to
give
a
sense
of
positioning
a
sense
of
History.
We
basically
have
a
main
Ripple
specification,
which
is
an
average
purpose,
distance
Vector
protocol,
where
we
save
energy
by
optimizing
routes
from
and
to
a
route
as
opposed
to
any
20.
F
F
The
first
extreme
solution
is
to
go
fully
into
the
Malay
world,
and
this
is
what
the
aodv
specification
does.
The
one
that
we
just
discussed
and
the
Charlie
is,
is
editing.
So
this
is
a
completely
reactive
protocol,
where
a
device
that
wants
to
speak
to
another
device
will
flood
the
network
with
a
route
request
message
which
is
effectively
transported
by
Ripple.
Now
the
the
other
complete
extreme
is
when
the
East-West
path
between
two
iot
devices
is
computed
by
a
central
controller,
which
is
more
the
traffic
engineering
space
and
you
would
say,
hey.
F
F
So
there
is
a
complement
between
what
we
do
here,
which
is
below
the
controller
to
set
up
the
traffic
engineered
path
that
we
call
a
truck
and
a
row
where
we'll
effectively
use
that
track,
but
just
the
subset
of
the
Dual
dag
between
source
and
destination.
That
is
enough
to
guarantee
the
level
of
reliability
that
we
want
for
for
the
flow
we're
talking
about
so
see.
B
F
So,
basically,
what
that's
exactly
what
Dow
projection
is?
It's
a
centralized,
Rod
computation
method
whereby
a
controller
which
is
kind
of
hidden
behind
the
root
will
set
up
geodags
within
a
geodeck.
So
typically,
you
will
build
a
main
geodag
that
connects
to
the
root
which
has
enough
redundancy
Etc.
It's
going
to
be
a
non-storring
mode,
Leo
deck.
Why
do
we
want
that?
F
F
So
once
you
start
doing
this,
the
first
usage
that
you
can
have
is,
within
the
main
deal
dag.
You
may
decide
that
your
Source
route
path
now
can
be
loose
as
opposed
to
strict.
So
you
know
with
repo
non-storring
mode.
You
have
this
situation
where
you
have
to
to
put
all
the
Hops
down
the
geodag
inside
every
packet,
and
that
might
be
a
long
list
when
you
want
to
compress
that
list.
F
So
now
your
routing
header
can
become
loose
and
it's
up
to
the
controller
to
decide
which
specific
routes
will
be
optimized
because,
as
you
know,
the
main
reason
why
we
are
not
operating
storing
mode
for
most
cases
is
because
we
don't
know
that
we
have
enough
memory
in
the
devices
to
store
all
the
non-storring
mode
to
store
all
the
storing
mode
rods.
Here
it
will
be
the
controller,
the
root
which
will
know
the
capabilities
of
the
devices
and
only
install
as
many
routes
as
a
device
can
actually
support.
F
So
it
will
be
up
to
the
controller
to
decide.
Hey
here
are
the
path,
The
Source,
right
path
that
are
used
extensively.
Let
me
compress
these
ones,
it's
more
interesting
to
save
energy
within
the
capabilities
of
the
nodes
along
this
path.
So
that's
what
the
segments
are.
A
segment
can
be
connecting
the
dots
in
the
main
geodag
or
in
what
we
call
a
truck
so
track.
Is
this
East-West
path?
F
That
is
also
a
ripple
geodag
that
is
also
installed
in
non-storring
mode,
just
like
the
main
tier
deck,
and
then
again
there
can
be
segments
to
connect
the
dots
okay.
So
the
track
is
loose
structure
where
that
basically
gives
you
the
skeleton
of
the
geodag
and
how
to
go
between
one
node
and
the
next
node
in
that
skeleton
is
using
again
a
segment,
but
this
time
a
segment
in
that
track,
as
opposed
to
a
segment
of
the
main
geodag.
F
So
you
can
see
the
domain
deal.
Dag
is
just
like
the
track.
Zero
and
the
optimized
path
between
A
and
B
are
geodes
as
well,
just
like
the
main
track.
Next
slide,
please.
F
F
It
goes
to
the
egress
of
the
truck
of
the
segment
I'm,
sorry
and
it
will
fly
to
the
Ingress
of
the
segment
and
the
increase
of
the
segment
answers.
If
you
look
at
it,
that's
the
way
that
works.
A
story
mode,
though,
starts
at
the
end
of
the
path
and
flows
towards
the
root,
which
is
the
Ingress
of
that
path.
Well
same
thing:
you
flow
from
the
end
to
the
beginning
of
the
segment,
so
it's
just
a
normal
pedial.
It's
just
that,
instead
of
being
generated
by
the
destination
like
we
do
in
normal
Ripple.
F
So
what
happens
to
build?
It
is
a
single
non-storring
pidau
that
goes
to
the
Ingress
and
the
Ingress
will
reply,
because
the
Ingress
is
the
one
which
will
have
the
full
topology
of
that
track.
It
will
not
know
the
segments,
but
it
knows
all
the
relays
so
a
b
and
egress
and
how
you
go
from
A
to
B.
Well,
that
could
be
through
another
track,
which
means
which
means
an
underlay
inside
the
underlay
or
it
could
be
through
a
segment
like
we
do
between
relay
A
and
A
Class
E.
F
It's
all
known
from
the
controller,
so
the
controller
in
order
to
ensure
a
certain
amount
of
reliability
will
provide
enough
redundancy
in
the
possible
path
in
that
Geotech
and
then,
as
I
said
row,
we'll
use
that
dynamically
to
optimize
spectrum
and
energy.
So
you
see
in
this
slide,
two
main
lags.
Basically,
one
is
on
the
North
and
one's
on
the
south.
We
call
them
legs
and
then
we
interconnect
the
legs
with
not
exactly
north
south
segment
but
East-West,
but
up
down
segments
in
row.
F
F
Please
so
draft
status
we
started
the
work
group,
let's
go
at
29
for
all
I
know
the
all
the
issues
are
resolved
with
the
latest
version,
which
happens
to
be
29,
and
it
is
my
belief
that
we
are
ready
for
publication
next
slide,
so
just
to
give
a
hint
of
what
happened.
So
during
IHF
28,
we
discussed
a
number
of
things
that
could
be
improved
or
clarified
in
the
document.
F
In
particular,
we
needed
to
clarify
that
each
Ripple
instance
each
track
is
effectively
its
own
rib
and
that's
why,
as
you
know,
we
have
what
we
call
the
RPI
the
Ripple
packet
information
in
the
repo
packet.
It's
effectively
the
topology
indication
which
will
tell
you
which
rib
you're
talking
about
indefinite
terms
because
I
see
some
net
members
it.
It
is
also
the
that
net
path,
if
you
like
that
you're
talking
about
it's
signaled
by
the
Ripple
packet
information,
which
is
a
hubby
Hub
header.
F
Now
there
was
this
this
long-standing
question
about.
How
do
you
avoid
Loops
when
you
can
have
topologies
within
topologies,
when
you
have
dotted
line
tracks
that
are
joined
by
segments?
And
then
you
have
neighbors
of
two
hubs:
neighbors.
How
do
you
ensure
that
you
don't
end
up
looping
looping
and
to
ensure
that
the
Dow
projection
draft
had
two
methods
and
we
refine
or
added
text,
to
clarify
that
at
the
very
beginning
of
the
document?
There
are
two
things
which
must
happen.
F
The
first
thing
is
kind
of
classical
for
those
who
participate
to
to
multi-topology
writing
efforts
in
the
past.
The
the
the
the
main
thing
is
the
topology.
If
you
can
go
from
topology
a
to
topology,
B
by
say,
injecting
a
packet
in
an
underlay,
then
you
can
never
go
from
topology
B
to
topology
a
again,
because
you
could
create
a
such
a
path
that
you
end
up.
Looping
from
one
topology,
You
Go,
reverse
versus
the
other
topology,
and
you
end
up
looping.
F
So
what
you
can
do
with
something
like
that
is
you
can
take
a
package
from
the
main
geodag
put
it
in
a
truck,
but
then
it
has
to
go
all
the
way
to
the
destination
within
that
track
or
an
inner
track,
which
tells
you
that
there
must
be
a
partial
order,
a
geodag
of
tracks.
If
you
like
that,
there
cannot
be
a
loop
in
the
way
the
tracks
are
ordered.
You
can
always
go
from
a
certain
underlay
to
a
lower
underlay,
but
never
to
an
iron
delay
which
could
which
could
take
you
back.
F
So
that's
the
first
thing,
I
think
this
partial
order
of
underlays
now
the
other
thing
that
that
we
have,
because
we
have
different
methods,
we
have
the
truck.
We
have
the
segments,
we
have
the
neighbors,
we
have
the
two
hops
Neighbors
is
we
enforce,
and
that
was
the
text
that
whole
has
started
long
ago.
F
We
enforce
a
strict
preference
into
which
type
of
Rod
you're
using.
So
if
you
have
a
track
route,
a
segment
route,
a
two-hub
neighbor
and
a
one-hub
neighbor,
you
always
favor
the
one-hub
neighbor.
If
you
don't
have
a
one-hub
neighbor,
but
you
have
a
two
hop
neighbor,
then
you
will
use
that.
If,
if
you
don't
have
that
you
have
a
segment,
you
always
use
the
segment.
If
you
don't
have
a
segment,
the
only
thing
you
have
is
a
track
route.
F
Then
you
will
use
the
truck
route
and
then
again,
this
is
how
we
ensure
that
we
don't
Loop.
Otherwise
there
was
some
tags
which
looked
back
to
the
reader,
which
really
happens
when
you
have
this
track.
So
this
is
this
complex,
complex
path,
if
you
like
between
the
source
and
the
destination
and
two
segments
could
cross.
So
you
go
from
this
point
to
this
point
or
this
point
to
that
point,
but
in
the
middle
there
is
a
same
note,
so
you
see
which
sees
the
packet
with
the
same
RPI
information
same
topology.
F
F
The
multicast
dial
is
not
your
usual,
though
it
is
like
a
broadcast
over
the
radio
medium
whereby
a
node
can
say,
hey
I'm
here
here
are
my
IP
addresses.
If
you
want
to
talk
to
me,
don't
look
at
your
repo
database.
Just
pass
me:
the
packet
I'm,
your
neighbor
okay,
so
it's
just
a
way
to
advertise
self
as
a
direct
neighbor
to
the
other
guys
around.
F
F
Since
we
have
we
in
placed
our
siblings
in
the
Dao.
We
also
have
it
in
the
multicast
dial,
meaning
that
when
I
say,
hey
I'm
here
I've
got
a
type
address.
I'm
also
saying
here
on
here's
my
list
of
neighbor
and
for
the
many
guys
I
mean
you
will
recognize
your
next
operating
next
operator
or
something
I
mean
the
you
know,
the
guy,
which
is
behind
your
neighbor,
and
with
this
you
can
get
to
those
two
Hub
guys
without
the
loop.
F
F
And
that's
pretty
much
it
there.
There
were
some
typos.
As
always,
you
know
when
you
push
the
the
draft
when
I
push
the
draft
and
I
look
at
the
GFI
fan,
so
there
was
a
like
main,
which
went
a
lowercase
in
subtitles.
I!
Guess
it's
still
there
I
would
have
to
fix
it.
That's
when
our
maintenance,
that's
when
I
I
removed
the
uppercase
m
in
main
geodag,
because
it
was
written
uppercase
main
all
the
time
and
it
seemed
that
the
uppercase
was
not
appropriate.
F
B
F
F
G
I
can
see
that
the
new
section
essentially
goes
into
details
about
stating
a
lot
of
things
explicitly
for
Providence
and
I've
already
reviewed
section
3.2
and
it
makes
sense
to
me,
certainly
addresses
the
comments
you
know
I'm
just
trying
to
check
whether
it
has
impact
on
any
other
section,
more
or
less
I.
Don't
you
know
I,
don't
have
any
outstanding
comments
as
of
now.
So
thank
you.
Thank
you
very
much.
B
F
A
A
Yeah
I
just
so.
F
I
left
in
that
presentation
a
whole
history
of
drawings
that
were
presented
during
the
elaboration
of
the
protocol,
so
that,
if
you
guys,
for
some
reason,
want
to
to
explain
what
the
projection
is,
you
can
dig
those
slides
and
and
get
them
foreign.
A
F
The
the
other
thing
I
wanted
to
to
present
to
you
guys
today
is
work
which
is
happening
at
six
low
for
now,
but
which
impacts,
Ripple
and
raw
as
well,
and
what
it's
doing
is
extending
RFC
9010,
which
is
a
ripple
unaware
leaf
for
different
types
of
addresses.
So
the
first
draft
that
you're,
probably
all
aware
of,
is
the
one
that
avoids
using
MLD
in
an
lln.
F
As
you
know,
mlds
like
traditional
ND,
it's
using
a
lot
of
multicast,
unless
you
know
multicast
is
on
for
when
you
want
to
preserve
energy
so
or
broadcast
really
so
the
same
way
that
we
can
avoid
Broadcasting
nsna
message
is
using
a
six
slope
nnd.
We
can
also
get
rid
of
the
multicast
in
MLD,
the
the
report
Thing
by
proactively
installing
the
multicast
and
any
cast
addresses
the
same
way.
We
installed
the
unicast
addresses
using
six
slope
and
ND
so
using
rfch
505.
F
So
what
we
are
doing
here
is
extending
the
work
that
we
have
with
our
fc8505
and
RFC
9010
to
multicast
and
any
cast
address
now
as
if
that
was
not
enough.
There
is
a
new
piece
of
work
where
we
want
to
redistribute
into
Ripple
external
destinations,
which
are
not
necessarily
hosts,
but
can
also
be
prefixes.
So
how
can
you
inject
in
repo
a
step
prefix?
F
But
what
we
didn't
have
is
a
way
to
install
stubs
into
repo
by
a
node
which
does
not
support
Ripple,
so
what
we
can
do
with
hosts,
injecting
their
addresses
with
six
slope
and
ND.
You
know
protocol
abstract
fashion
we
didn't
have
for
prefixes.
So
that's
why
we
are
now
having
this
new
prefix
registration
extension
that
allows
a
node
which
is
Ripple
unaware
to
talk
to
a
ripple,
router
and
say:
hey
I.
Have
this
step
prefix,
please
inject
it
in
repo
next
slide.
Please.
F
And
by
the
way,
I
will
be
presenting
that
at
six
flow
and
That
Snack
as
well,
because
it
kind
of
solves
some
snack
scenarios
as
well.
So
now
that
the
six
slope
and
ND
it
starts
to
be
a
a
an
interesting
family.
So
we
started
with
6775,
which
was
the
well
the
starting
point
and
and
working
on
it
and
deploying
it.
We
found
that
the
number
of
issues,
so
we
ended
up
solving
them
and
8505,
is
the
second
and
I'll
say
final
version
of
the
address
registration
mechanism
in
ND.
F
Then
we
produced
8928
to
secure
that.
So
that
gives
you
something
like
sound,
but
probably
better,
because
sand
is
limited
in
the
size
of
the
cryptographic.
Token
at
928
is
not,
and
we
probably
are
provided
8929,
which
is
the
first
time.
The
aware
and
address
that
is
registered
through
855
is
effectively
redistributed
somewhere.
In
this
case
it
was
redistributed
in
in
ND
itself.
F
That
would
what
happened
with
Wi-Fi,
because
the
MAC
address
are
breachable,
in
which
case
the
the
basically
the
router
would
defend
the
AP
being
a
router
would
defend
the
address
of
the
stay
using
the
MAC
address
of
the
stay,
so
the
packets
will
be
bridged
directly
to
the
stay
by
the
access
point,
or
it
could
be
a
rotting
bridge,
in
which
case
on
the
ethernet
backbone.
The
router
again
exiting
as
access
point
would
present
its
own
IP
address.
F
Well,
it
would
present
its
own
Mac
address
for
the
IP
address
of
the
state,
meaning
that
the
MAC
address
of
the
state
would
not
be
visible
on
the
ethernet
fabric.
The
cool
thing
about
that
is
is
the
layer.
2
is
becomes
very,
very
stable,
so
that's
the
the
rotting
proxy.
In
that
case
you
can
have
devices
which
are
not
only
brigidable
breachable
Max
like
Wi-Fi,
but
also
non-bridgeable
Max
like
a22.154.
F
F
There
is
a
draft
for
ivpn
I
mean
as
soon
as
you
have
the
information
that
the
the
IP
address
is
there
and
with
H5
the
host
can
signal
a
please
write
to
me,
then
the
router
doing
any
protocol
can
inject
that
IP
address
inside
that
protocol,
but,
like
like
I,
said
it
was
for
only
for
IP
unicast
address.
Now
the
six
load
multicast
registration
allows
the
host
to
proactively,
say:
hey
I'm.
Listening
to
this
multi-cast
address,
please
inject
it
in
Ripple
as
well
or
if
you're,
using
meeple
or
something
else.
F
C
David
lumpater,
so
I
just
wanted
to
note
that
the
Wi-Fi
setups
when
they
are
bridgeable
they
are
not
actually
mesh
networks.
So
you
cannot
have
a
bridgeable
Wi-Fi
mesh
setup,
so
those
are
different
types
of
80211
operation,
so
I'm
not
sure,
okay,
yeah
the.
F
Well,
once
you
reach
the
router
yes
effectively,
if
you
have
a
layer
to
mesh,
we
don't
really
see
it
right.
So
so
we
just
see
the
MAC
address
of
the
destination.
If,
if
we
want
and
that's
what
we
do
with
Ripple
we'll
be
at
the
mesh
at
layer
three
and
that's
what
we
call
rot
over.
F
And
then
there
is
this
new
work.
I
just
hinted,
which
is
the
prefix
registration
and
I
will
come
back
on
that
a
bit
later
next
slide.
Please.
F
Multicast
registration,
you,
as
you
know,
it's
being
expected
by
the
wise
and
Alliance
it's
covering
their
needs,
so
we
we
move
quickly
on
it
and
we
get
support
from
why
some
people.
At
the
same
time,
we
have
beefed
up
the
update
rsc6515
quite
a
bit,
so
we
explained
things
like
how
we
use
the
the
Rover
and
the
lifetime
when
you
get
the
same
information
from
multiple
listeners
of
the
same
multicast
address.
How
do
you
merge
the
rod,
ownership,
verifier
and
the
OU
which
lifetime
you
pick?
F
We
talked
about
freshness.
Unless
you
know
the
freshness
is
what
allows
you
to
detect
to
to
Route
when
there
is
movement.
So
when
there
is
movement,
the
host
indicates
in
six
open,
NDS
sequence
counter.
So
you
know
the
most.
The
freshest
location,
that's
9010
and
the
the
Ripple
carries
that
sequence
and
only
retains
the
rods
which
has
the
freshest
sequence
and
that's
basically,
the
way
when
they
protocols,
work
and
ripple
is
just
designed
the
same
way
when
you
have
multiple
listeners
listening
to
the
same
multicaster
drives.
F
You
cannot
compare
the
freshness
information
from
that
different
sources,
but
if
you
know
the
different
that
will
come
from
the
same
Source
through
different
paths,
then
you
can
still
compare
and
that's
what
we
explain.
So
the
Rover
basically
indicates
what
the
source
is
and
as
long
as
you
can,
you
see
different
dialcomings
from
different
from
the
same
Source.
You
can
still
compare
the
lifetime
other
one.
Otherwise
you
can't
the
sequence
counter.
I'm,
sorry
and-
and
we
have
these.
F
This
something
we
want
to
in
Ng
messages,
array
and
others,
and
we
have
we
had
that
open
question
with
six
men.
Basically,
should
we
export
that
option
outside
of
this
specification
or
keep
it
in
there
and
they
recline
at
the
the
point,
and
they
have
not
seen
really
a
definitive
answer
so
for
now?
It's
still
it's
still
in
this
document.
Basically,
the
goal
here
is
when
you
register
something
to
your
router.
F
You
want
to
know
if
the
router
has
rebooted
and
has
lost
the
state
that
you
have
registered
to
it
and
it's
true
along
the
Ripple
path.
If
your
parent
reboots,
you
want
to
know
so
you
need
to
send
your
dials
again
next
line,
so
the
probably
the
most
meaningful,
meaningful
change
that
happened
is
there
were
two
bits
in
the
the
error
option
and
then
the
message
is
the
dark
message
and
the
repo
Target
option
message
which
would
indicate
well
if
the
bits
are
zero,
then
it's
a
unicast
address.
F
If
the
first
bit
is
arms
multicast,
it
can
be
designed
it's
any
cast,
and
if
we
do
that,
we
we
have
this
value
3,
which
is
kind
of
unassigned
and
wasted.
But
since
now
we
want
to
register
prefixes.
Why
waste
this
value?
So,
instead
of
saying
it's
two
flags,
we
turned
it
into
it's
a
two-bit
field
which
we
call
the
P
field
as
opposed
to
the
a
foreign
Flags.
We
turn
that
into
a
two-bit
field,
so
we
can
use
the
value
3
and
we'll
use
it
in
the
other
specs
of
prefixes.
F
So
now
in
this
P
flag
that
you
can
find
in
Arrow
in
Dar
an
inertia
if
it's
zero,
it's
a
unique
asset
address.
If
it's
one,
it's
a
multicast
address.
If
it's
two
it's
in
any
Caster
trash,
if
it's
three,
it's
a
prefix
next
slide,
oh
by
the
way
in
this
particular
slot.
If
a
document,
the
multicast
we
say
unassigned
and
it's
the
other
document,
which
is
the
prefix
registration
which
reassigns
it
now,
this
is
extra
burden
for
the
Ina.
F
So
if,
if
that
you
know
we,
we
adopt
the
document,
maybe
we
we
could
assign
everything
there
and
avoid
having
a
Yana
registration
registry
for
for
just
the
P
field.
F
Okay,
so
yes,
so
please
go
down
okay,
so
that's
the
other
draft
as
we.
Yes,
we
need
to
previous
slide
action
because
that's
intro
for
us
okay,
so
this
is
RFC
9010
and
what
it
allows
is
me
to
take
the
mic.
F
It
allows
a
device
that
doesn't
speak
Ripple
to
register
through
rfc8505,
proven
by
rfc8928
an
address
to
a
router
which
is
Ripple
router
and
the
Ripple
router
will
redistribute
will
inject
that
route
that
host
route
into
the
Ripple
domain.
Okay,
we
can
do
it
for
host
the
protocol
is
six
dependent
D.
It
is
independent
of
the
routing
protocol
that
happens
above
we
have
these
for
addresses
next
slide.
F
Please
let
me
and
now
what
we
want
to
do
with
the
new
prefix
registration
is
to
do
the
same
thing
for
external
destinations,
which
happen
to
be
not
rods
or
host
rods,
but
prefix
rods,
steps.
F
So
so
so,
if
you're
doing
normal
repo,
you
can
always
inject
prefixes.
Ripple
is
not
just
for
host
addresses,
it
is
a
routing
protocol.
It's
a
classical
distance
Vector
protocol
just
happens
to
be
an
isotropic,
but
we
can
only
use
Ripple
to
advertise
prefixes.
If
we
have
next
slide
please,
if
we
have
a
non-repo
device
which
happens
to
own
a
prefix
say
it
connects
to
a
step
or
it's
even
a
prefix
which
is
inside
that
device.
F
F
F
This
prefix
can
be
obtained
by
this
guy
because
it's
within
a
larger
aggregation,
which
we
own
or
something
like
that,
so
we'll
have
to
have
some
policies
which
replace
that
that
is
an
exact
match
of
the
full
address
wants
to
auto-conf
a
prefix
or
claim
a
prefix.
We
will
have
to
check
that
it's
a
load
to
claim
that
prefix
and
there
will
be
policies,
but
that
would
eventually
allow
a
device
to
Auto
confer
prefix,
just
like
we're
talking
for
addresses
next
slide.
F
Now
a
question
that
is
to
be
discussed
with
the
group
is:
should
we
still
use
NS
with
the
error
option
in
there
or
should
we
call
that
an
errors?
Should
that
be
an
RS
array
as
opposed
to
an
nsna
or
anything
else,
because
I'm
getting
a
lot
of
trouble
just
because
we
are
using
NS
for
the
registration
so
freely.
We
need
to
invent
a
new
message
when
that's
still
possible
next
slide
and
as
I
interview,
we
are
extending
the
P
field.
So
now
the
value
1
1
are
supposed
to
be
a.
F
What
is
that,
when
these
are
two
flags
now,
it
really
means
registration
for
a
prefix
next
slide,
and
there
is
basically
the
flow
that
you
would
get
with
RSC
eight
nine
to
eight.
So
you
send
a
host
Auto
configuration
address
on
our
prefix.
It's
it
would
send
an
NS
with
the
arrow.
F
F
A
F
H
H
D
F
E
B
Okay,
maybe
we
can
think
to
the
many
list.
It's
like.
B
A
Well,
so
this
is
an
open
floor.
Any
comments
from
the
group
you
know
is
what
we
should
be
doing.
As
I
said
at
the
beginning,
we
want
to
ship
a
few
documents
that
are
in
our
way
and
have
been
sitting
for
a
long
time,
and
then
we
can
open
open
up.
New
I
have
news
for
work.
So,
as
in
this
mentioned,
we
want
to
address
the
management
issue
of.
G
A
Routers
we
also
one
thing
that
we've
been
considering
for
a
while
is
putting
together
the
Ripple
V2
specification,
so
pruning
some
stuff
that
is
not
used
and
nobody
seems
to
be
interested
in
and
merging
in
the
various
options.
Various
additions,
extensions
that
we've
produced
over
the
last
10
years.
A
F
For
those
who
care
I
made
the
exercise
of
turning
the
original
Ripple
specification
6550
in
XML
V3,
so
that
was
not
a
small
Endeavor,
but
but
I
I
made
it.
So
if
you
want
to
see
the
original
Ripple
formatted
like
XML
to
RFC
V3
can
do
it's
effectively
available.
The
draft
is
expired,
but
it's
been
published.
So
there
is
effectively
if
in
the
Raw
you
know
Library
Ripple
V2,
if
you
like
draft
under
my
name,
which
is
for
version
zero,
zero,
the
exact
copy
of
the
RFC,
but
in
XML
to
our
FC
V2.
A
C
H
Is
hand
okay
start
about
the
Ripple
protocol.
I
just
want
to
clarify
the
terminologies,
because
this
group
is
using
the
lln
nodes
and
the
six
slope
and
ND
they
are
calling
the
six
low
nodes
and
another
RFC
by
the
I
think
Bremen
Kristen
Bremen
from
Germany.
He
wrote
that
constrained
nodes,
so
I
discussed
with
him.
Can
you
speak
closer.
A
H
H
They
are
calling
the
constant
nodes,
so
why
not?
We
call
this
whole
stack
that
having
these
protocols
like
RPL,
6.5
and
D6
low
band
like
we,
we
call
the
nurse
like
six
load,
then
categorize
later
into
6lr
or
6
lbr.
A
Okay
yeah.
Thank
you
for
the
suggestion
that
we
harmonize
a
notation
between
the
various
groups
there
yeah
jumping
they
are
not
actually
quite
the
same,
but
we
can
make
an
effort
in
that
way.
Yes,.
F
The
point
is,
6lm
is
a
logical
function;
s
not
really
a
physical
node
so
agree
foreign.
No,
this
is
very
vague,
because
when
we
started
this
we
didn't
have
the
70
to
28.
It
came
after,
but
for
the
six
island
thing
that
really
means
a
node
which
can
play
RFC
8505
right.
So
so
it's
a
logical
function.
A
repo
rudder
Can
effectively
is
expected
to
be
a
six
letter
and
it's
probably
a
6lr
as
well,
but
it's
a
logical
function
so
doing
ripple
doing
six
up
ND.