►
From YouTube: IETF-ROLL-20220627-1400
Description
ROLL meeting session at IETF
2022/06/27 1400
https://datatracker.ietf.org/meeting//proceedings/
B
D
A
A
A
A
C
A
D
A
D
A
B
D
D
Okay,
okay,
this
meeting
is
aligned
with
it,
not
well
the
next
slide,
so
we
will
not
read
it
but
be
aware
of
these
topics.
Next
slide:
okay,
the
meeting
materials
please
volunteer
to
for
the
menu
stickers.
You
can
find
the
link
on
the
top
right
corner
next
slide
and
okay.
This
is
our
agenda.
We're
going
to
have
a
working
group
status,
then
charlie
will
present
the
advance
in
audeber
ripple.
D
D
We
are
going
to
have
a
discussion
today
and
is
currently
well
in
the
working
group.
Last
call
we
have
not
got
any
input
on
that,
but
we
would
like
to
know
your
opinion
and
then
enrollment
priority.
I
think
there
are
open
issues
and
they
say:
okay.
It
will
not
be
discussed
today,
but
well
discussed
today,
like
in
the
term
of
their
open
issues
in
github,
and
I
think
there
are
some
items
in
the
mailing
list
as
well.
That
need
to
be
addresses
to
continue
this
work.
D
D
If
you
agree
and
then
we
we
will
discuss
as
well
how
to
proceed
with
the
fast
border.
Router
class
detection
in
ripple-
and
this
is
the
new
work
update
by
the
work
group-
then
we
have
inactive
interest
drafts
these
modifications
and
the
apr
multicast
that
they
are
sleeping,
but
they
should
as
well.
We
need
to
decide
what
to
do
with
this
next
slide
and
then
the
milestones
were
updated.
D
D
Next
slide,
please!
Oh
okay,
sorry
for
the
resolution,
but
we
have
open
tickets
in
the
german
priority,
however
ripple
I
think,
charlie
it's
working
to
close
in
those
issues.
A
new
version
14
was
supposed
to
address
all
these
tickets
next
slide
rebel
observations
says
we
have
tickets
to
know
what
to
work
on
and
the
bobex.
D
A
F
A
E
B
B
A
B
A
B
A
B
B
B
This
slide
came
from
well
over
a
year
ago
during
an
ietf
presentation,
but
I
made
just
some
very
minor
updates,
but
basically
what
it
shows
is
that
it,
the
route,
request
and
route
reply
are
now
ripple
options
and
when
they
are
disseminated
through
the
network,
they
create
two
dodec's
ones
rooted
at
the
origin,
originating
node
or
rh
node
and
the
other
one
is
rooted
at
the
target.
Node
or
target
node
and
aodv
can
create
asymmetric
and
symmetric
routes.
B
Both
and
one
fairly
major
change
recently
was
that
a
renew
multicast
group
has
been
requested.
All
aodb
ripple
nodes.
It
used
to
just
use
all
ripple
nodes,
but
there
was
turns
out
that
the
ripple
specification
does
something
that
I
didn't
expect
and
and
it
that
required
that
we
get
a
new
multicast
group.
B
That
was
developed
in
man
a
and
this
is
called
gratuitous,
r
rep
and
basically
the
idea
there
is
that
if
a
if
a
route
request
gets
to
an
intermediate
node,
let's
just
say
that
one,
and
that
one
already
has
a
nice
symmetric
route
to
the
target
node.
Then
it
can
advertise
back
already
and
their
originating
node
will
get
the
route
reply
faster.
B
However,
as
was
in
the
point
of
discussion
on
the
mailing
list
and
and
in
comments
submitted,
that
does
not
necessarily
mean
that
our
rig
node,
it
does
not
mean
that
the
originating
node
has
the
instance
id
of
the
dodec,
that's
rooted
at
target
node,
and
so
that
required
some
careful
explanation
in
in
the
draft
which
has
been
done
all
right.
So
next
slide.
B
So,
first
of
all
local
instance
id
the
ripple
instance
ids
that
are
used
by
aodv
ripple
are
local
ripple
instance
ids
and
when,
when
our
node
has
oh,
so
first
of
all
it's
a
little
bit
of
a.
I
was
a
little
or
originally
confused,
because
it
turns
out
that
the
instance
id
does
not
uniquely
identify
the
instance,
and
so
the
name
is
not
not
correct.
I
mean,
if
it's
an
instance
id,
then
it
should
identify
the
instance,
but
it
doesn't.
F
Yeah,
I
just
wanted
to
say
when
you
have
an
identification,
an
id,
it
has
a
domain
in
which
it
is
effectively
identifying
something
and
a
local
instance.
Id
is
unique
within
the
domain
of
the
local
source,
node
or
destination
node
in
the
backend.
So
it's
still
an
id.
It's
just
that
you're.
Assuming
that
any
is
global.
It's
not!
I
mean
this.
One
is
local.
My
name.
B
Well,
I
I
I
understand,
pascal,
but
I'm
just
saying
that
somebody
that
didn't
read
every
word.
They
might
assume
that
an
instance
id
identifies
the
instance
and
for
my
purposes
it
did
not.
But
I
do
understand
what
you're
saying
okay,
so
so
one
thing
about
the
instance
ids
is
that
the
originating
node
needs
to
pair
their
its
instance.
That's
rooted
at
the
rs
node
with
the
route
reply.
B
Instance
that's
rooted
at
the
target
node
and
when
it
does
that,
when
it
pairs
that,
then
it
doesn't
have
to
continue
with
the
route
discovery,
because
it's
got
the
routes
in
both
directions
and
one
one
factor
that
has
to
be
accounted
for
is
that
it
is
theoretically
possible.
Although
I
but
hope
it
doesn't
happen
all
the
time,
but
it's
possible
that
you
might
need
two
routes
between
originating
node
and
targe
node
that
have
different
objective
functions.
B
B
B
B
Okay,
all
right!
So
then
I
made
a
relatively
complete
list
of
all
the
changes
from
the
last
draft
until
version
14,
which
was
I
just
sent
out
a
few
days
ago-
and
there
was
some
discussion
about
the
claim
was
made-
that
odb
ripple
is
a
natural
choice
for
a
writing
protocol.
In
some
circumstances,
so
I
put
in
language
into
the
draft
describing
about
the
scenarios
that
what
would
lead
one
to
choose,
aodb
ripple
and
there
was
suggested
to
include
some
informative
references,
which
this
suggestion
was
much
appreciated.
B
That
described
the
value,
that's
provided
by
peer-to-peer
routing
and
then
we
requested
a
new
protocol.
I
mean
a
new
multicast
group
and
I
want
to
explain
a
little
bit
about
this,
the
original
design
of
odb
ripple.
We
thought
that
it
would
be
just
fine
just
to
have
some
different
option
numbers
assigned
to
the
to
the
route
request
and
route
reply
option
and
the
art
option
and
then,
since
the
option,
numbers
would
not
be
recognized
by
the
intermediate
nodes
that
didn't
implement
aodb
ripple
as
since
they
didn't
recognize
them.
B
They
just
wouldn't
process
them
and
drop
them,
but
turns
out
that
ripple
specifies
that
you
don't
drop
them.
You
just
send
them
on,
and
so
from
my
understanding,
it's
difficult
for
me
to
really
imagine
a
reliable
operation
of
aodv
if
an
intermediate
node,
that's
unaware
of
the
purpose
of
it,
would
just
forward
it
to
the
same
multicast
group
so
that
basically
would
break
the
protocol
and
in
order
to
maintain
the
correct
operation
of
the
protocol
in
the
face
of
this
specification
from
base
ripple,
it's
I
think
it's
just.
B
B
B
Oops
wait
a
minute:
okay,
continued
okay,
so
we
it
was
noted
that
I,
the
terminology
in
the
aodv
ripple
document,
said
it
had
a
complete
source
route.
Well,
in
a
way,
that's
not
really
true.
It
just
has
the
addresses
in
this
address
vector
that
are
needed
to
go
from
top
by
hub
back
from
to
from
the
source
to
the
destination.
B
So
that's
that's
all
we
needed
to
say
and
we
didn't
need
to
say
complete,
so
I
changed
the
definition
of
source
routing
for
that
and
then
there's
a
figure.
Four
shows
the
border
router
and
that
without
any
further
description
it
is
illustrative,
but
it
might
give
somebody
the
impression
that
aodb
requires
a
border
router
which
it
does
not.
So
I
explicitly
put
in
language
that
the
figure
does
not
imply
that
odb
requires
a
border
router.
B
There
was
some
discussion
about.
How
do
you
select
a
value
for
the
l
field,
and
so
I
put
that
almost
directly
from
the
discussion
on
the
mailing
list
and
so
for
storing
mode.
It's
pretty
easy
to
imagine
that
people
are
the
routers,
keep
track
of
the
next
hop
information
and
so
on
and
the
rank,
but
for
non-story
mode.
B
The
address
of
the
interface
that
the
route
request
comes
in
on
is
possibly
different
than
the
address
of
the
interface
that
the
route
reply
comes
in
on,
and
so
both
of
those
are
needed
for
for
for
for
getting
the
address
vector,
correct,
it
was
requested
that
we
produce
some
interesting
reading.
Material
for
details
about
evaluating
link
of
symmetry
does
many
different
ways
that
links
can
be
asymmetric
and
and
evaluating,
determining
that
is,
in
some
cases
non-trivial.
A
A
F
Okay,
neat
so
yeah,
so
this
is
about
the
projected
dow
draft,
which
is
called
root,
initiated
routing
state.
It
really
means
that
the
root
is
in
control
of
establishing,
I
would
say,
t
e
path
inside
the
ripple
domain.
Now
it
might
be
that
the
root
is
doing
that
on
behalf
of
a
controller
of
any
sort,
but
we
are
using
ripple
and
a
very
similar
protocol
to
normal
ripple
operations.
F
So
as
a
reminder,
the
different
objects
that
we
are
manipulating.
There
are
two
main
objects.
One
of
them
is
what
we
call
a
truck
and
the
truck
is
a
non-storing
dotted
line
multi-path.
So
it's
a
it's
a
deal
dag
but
expressed
as
as
a
non-strict
source
routing.
So
it's
dotted
line
and
the
the
hops
between
two
dots
in
the
dotted
line
are
a
segment.
F
So
we
expect
the
main
deal
deck
to
be
non-story
and
we
can
already
make
that
main
geodag
quote-unquote
dotted
line
so
that
in
the
source
rotator
you
have
just
a
loose
indication
of
the
hops,
in
which
case
you
already
need
segments,
but
for
this
main
geode.
So
that's
one
way
of
using
the
draft
to
basically
enable
to
compress
the
source,
routing
header
in
non-storing
mode
by
installing
very
local,
storing
mode
segments
which
would
basically
complete
the
dots
the
other
way
to
use
it
is
to
install.
F
I
would
call
that
overlays,
so
so
local
geodags,
if
you
like,
so
it's
not
a
odb,
it's
another
way
of
installing
them.
These
are
geodex
that
are
within
the
main
geodac
just
for
a
shortcut
between
a
and
b
quote
unquote,
and
so
again
you
can
use
it.
You
can
use
non-storing
mode
to
install
the
the
track,
so
the
dotted
line
multipath
and
then
complete
the
dotted
line
with
source
with
storing
mode
segments.
F
So
this
is
pretty
much
what
we
we
showing
here.
The
signaling
is
very,
very
similar
to
the
normal
repo,
a
track
which
is
not
the
main
geodag
is
still
a
ripple
instance.
It's
just
a
local
instance
which
is
owned
by
the
ingress,
but
once
you're
inside
this
instance,
this
overlay,
you
can
figure
that
it's
the
mostly
the
ripple
operation,
as
you
know
them
which
happen.
F
F
F
We
basically
reorganized
the
document
quite
a
bit,
and
that
was
the
the
biggest
of
tallest
comments.
Obviously
there
are
technical
comments,
etc,
but
the
big
thing
he
told
us
is:
oh,
please
made
it
more
readable
for
somebody
who
is
not
really
within
the
group
all
the
time
and
so
do
things
in
certain
order.
So
people
read
serially
from
beginning
to
end
can
understand.
F
F
F
F
F
Tio
to
transit
information
option,
then
you
get
a
vr,
so
it's
you
can
see
it
as
a
multi-hop
transit.
It's
really
a
good
way
of
saying
it
and
finally
ramos
provided
me
the
the
dfs
for
for
a
number
of
typos.
So
thank
you
so
much
ramos
for
that
and,
as
the
chair
said,
the
the
document
is
undergoing
group.
Let's
go
if
you've
not
done
your
markup
last
call.
Yet
your
review
please
consider
in
particular,
if
we're
missing
status
codes.
F
You
know
your
flows
that
you
know
you
would
think
should
be
documented
stuff,
like
that
flows,
that
you
should.
We
should
document
things
like
that
and
yes,
I
I
really
welcome
more
more
reviews,
but
I
already
acknowledged
that
we
had
a
good
number
of
them
and
that's
pretty
much.
It
purchased,
I'm
very
sorry
not
to
be
at
the
atf.
It
cost
me
a
lot
and
just
not
this
not
just
role
but,
as
you
know,
six
low.
We
have
this.
F
F
C
E
F
Yeah
just
asking:
if
it's
too
late,
then
a
review
is
always
good
conrad
for
the
one
thing,
even
if,
if
we
are
in
the
asg
space
I
mean
you
can
always
give
me
a
review
to
the
mailing
list,
but
I
don't
believe
that
we
can
hold
the
document
for
three
months.
It
doesn't
mean
that
we're
not
account
for
your
review.
Please
review
the
latest,
which
is
published
when
we
when
we
go
through
asg.
F
What
I
do
usually
is
I
publish
every
time
I
get
reviews,
so
the
next
reviewer
will
always
review
based
on
the
previous
reviewer
reviewers
work.
So
I
don't
republish
bank
bank
bank,
and
so,
if
you
just
if
the
day
you
want
to
review
just
pick
the
latest
one
and
if
you
have
questions,
please
use
the
main
mailing
list
and
I
will
appreciate.
E
E
A
E
D
Okay
conrad
says
our
turn
to
present
when
the
slides
are,
and,
in
the
meantime,
the
about
the
sixth
law.
Multicast
document
is
going
to
be
deal
in
the
sixth
law,
but
it's
going
to
be
as
well
last
call
share
withdrawal
so
have
to
pass
role
a
probation
basically
to
be
able
to
be
published,
so
just
be
having
consideration
this,
that
we're
going
to
do
like
joint
working
group
class
call
for
circle
multicast.
E
E
E
So,
first
of
all,
why
why
why
consider
rbr
crashes?
They
play
central
role
in
low
power
and
lossy
networks.
Typically,
the
hardware
that
is
used
and
also
the
software
is
typically
more
involved
than
that
of
a
constraint
node
and
usually
they
require
a
tethered
power
supply
which
is
hard
to
provision
many
deployments,
at
least
from
my
experience.
E
E
E
E
What
happens
in
practice?
So
if
you
take
a
look
at
implementations,
open
source
ones,
also,
some
of
them
have
still
major
bugs
and
upon
a
failure
of
a
dota
code.
They
enter
some
chaotic
state
with
an
explosion
of
control
traffic.
Some
are
better
in
a
sense
that
they
may
not
detect
bugs,
but
at
least
they
the
protocol
doesn't
get
any
worse
than
it
was
before.
The
failure
and
some
some
are
correct,
but
and
in
fact,
ripo
correctly
handles
the
group,
assuming
that
it
has
like
a
working
label
discovery
protocol.
E
But
this
procedure
takes
time
and
traffic
and
it
happens
because
this
happens
because
all
links
to
the
depth
border
router
have
to
be
detected.
Even
if
there
is
one
link
that
is
considered
to
be
up,
then
the
neighbor
will
advertise
across
the
border.
Router
and
other
nodes
may
not
choose
this
neighbor
as
an
ancestor
with
product
which
will
still
have
some
root
advertised.
E
The
another
problem
is
that
the
detection
of
crashed
links
is
typically
reactive
to
safe
traffic
energy
whatever.
So
this
means
that
it
may
take
a
while
in
principle,
you
have
to
use
that
leak
in
order
to
detect
that
it
has
failed.
It
has
crashed
and
learning
that
actually
all
links
to
the
rules
have
are
down
is
also
slow,
because
what
happens
is
that
the
nodes
will
try
to
do
local
repair,
so
they
will
try
to
switch
parents
and
so
on
the
process,
because
they
have
inconsistent
knowledge.
E
E
E
The
situation,
changes
and
the
protocol,
the
algorithm
in
general,
tries
to
maximize
the
independence
of
rupees.
This
was
the
original.
Both
it
may
be
questioned,
but
but
this
was
the
original,
so
the
basic
idea
is
that
there
are
two
types
of
nodes.
Some
sentiments
that
there
are
some
of
the
roots
neighbors
can
be
all
selected
must
basically
monitor
the
status
of
their
links
to
the
root
and
acceptors
or
any
other
nodes
in
the
algorithm.
E
So
here
you
can
see
that
these
are
the
possible
sentiments.
Not
all
of
them
have
to
actually
use
anything
else,
and
the
algorithm,
just
from
from
from
a
very
high
level
perspective,
works
in
a
way
that
individual
sentinels
detect
crashes
of
their
links
with
the
background,
and
then
they
exchange
this
information
in
a
new
option.
It's
rnd
option
through
this
link:
local
repeat
messages,
online
dials,
possibly
the
iss
and
then
based
on
the
number
of
sentiments
that
believe
and
the
links
to
the
root
to
be
down
a
consensus
is
made.
E
E
E
It
may
be
changed,
so
my
question
is
now
how
it
should
be
changed
if
at
all
or
how
to
approach
making
the
project
mature
michael
made
a
suggestion
that
we
could
adopt
the
draft
of
this
experimental
draft
and
perhaps
work
on
this
later
and
pascal
earlier,
had
some
remarks
about
about
using
the
dota
crude
itself
for,
in
fact
monitoring
itself.
So
we
could
talk
about
this
more
but
well.
E
F
Well
that
we
really
would
need
a
a
white
ball,
but
it
might
be
that
the
network
is
not
broadcast
between
different
first
half
developers
from
from
the
root,
in
which
case
it
might
be
that
they
might
even
the
worst
case.
It's
a
hub
and
spoke
thing
where
none
of
the
first
hops
see
any
other
first
half,
and
so
it's
very
hard
for
them
to
get
to
a
byzantine,
general
agreement.
If
they
don't
see
enough
of
the
peers
to
make
any
decision.
E
But
the
decision
is
made
not
by
the
first
hops
it's
made
by
the
other
nodes.
So
if
there
is
any
any
path
between
this
first
hop,
so,
for
instance,
you
have
a
star
that
is
somehow
connected
at
the
very
let's
say
edges,
then
then
you
will
still
have
consensus.
So
only
if
you
have
like
really
disjoint
paths,
disjoint
subtrees,
essentially
these
joint
networks-
that
are
that,
whose
only
connection
is
the
dodak
root.
Then
this
algorithm
won't
work.
F
E
If
there
is
just
one
connection,
so
this
is
just
a
probabilistic
algorithm
right,
so
if
you
have
like
say
thousand
nodes
and
say
thousand
one
hot
neighbors
or
100
one
hot
neighbors
and
just
one
neighbor
has
a
link
to
the
dodak
root.
Then
yeah.
This
algorithm
will
actually
kill
the
dodge,
but
I
would
agree.
E
I
would
argue
that
this
case
is
quite
desirable,
because
if,
let's
say
99
of
let's
say
root's
former
children
lost
their
links
to
the
root,
then
the
dota
should
probably
be
reconstructed
from
scratch,
because
it
looks
now
completely
differently,
so
killing
it
and
issuing
a
new
dark
version,
because
in
the
protocol
the
dota
crude
would
notice
that
it's
alive
and
has
some
link
to
some
other
note.
So
it
will
introduce
some
some
new
deluxe
version
and
the
version
will
be
built,
hopefully
according
to
the
new
links.
E
F
That
and
like
you
know,
as
if
the
the
first
top
can
talk
to
one
another
and
see
that
the
root
is
still
there,
even
if
their
children
think
it's
not,
I
mean
if
they,
if
they
can
still
talk
through
the
root,
it
means
the
root
is
still
there.
So
it's
like
it's
it's
like
deciding
that
somebody
is
dead
without
asking
him,
and
if
you
ask
the
guy,
are
you
dead
and
he
says
no?
Well,
that's
probably
true.
F
E
F
B
B
F
E
E
F
E
A
F
A
I
need
to
the
work,
and
so
we
are
over
time.
What
I
gather
is
that
we
have
food
for
the
thoughts
for
further
technical
discussions
and
I'd
love
to
be
able
to
discuss
live.
However,
I
understand
the
idf
114
is
not
going
to
be
the
right
opportunity
for
that.
So
let's
try
to
have
this
discussion
on
the
mailing
list
as
much
as
possible,
and
then
we
have
an
interim
meeting
that
will
take
place
end
of
august
or
early
september.
D
Yeah,
I
agree
with
that.
I
think
I
think
it's
an
interesting
topic
to
for
the
millionaires
and
even
if
the
presenters
cannot
be
into
the
idea,
we
just
can
write
the
topic.
If
some
additional
people
can
comment
on
this,
when
we
decide
that
attack
is
harsh
even
when
they
have
connections
with
another
sentinels,
so
yeah,
it's
good
good
topic
and,
yes,
I
think
the
the
the
entering
could
be
in
september
after
summer,
so
people
can
take
vacations.