►
From YouTube: IETF109-ROLL-20201119-0900
Description
ROLL meeting session at IETF109
2020/11/19 0900
https://datatracker.ietf.org/meeting/109/proceedings/
A
A
A
D
D
B
A
A
A
A
A
E
F
So
it
looks
like
that's
what
lorenzo
was
saying:
there
was
a
problem
with
the
jabber
itf
java
server.
So
it
looks
like
the
java
room
is
up,
I'm
there
as
well,
but
there's
no
connection
to
meet
echo.
B
A
A
A
F
Well,
yes,
so
sorry,
just
one
interruption,
real
quick!
If
you
reload
your
window,
just
reload
the
window.
I
just
did
that
on
my
mini
echo
window
and
now
I
can
see
the
jabber
posts
I
posted
on
my
jabra
and
it
showed
up
in
the
room.
A
A
Excellent
thanks
a
lot
that
works.
Do
we
have
innis
on
board?
No
she's
gone.
Okay,
probably
run
out
of
batteries
good
morning
good
afternoon,
good
night,
ladies
and
gentlemen,
wherever
you
are
oh
sharing
the
screen,
because
I
reloaded
sorry
about
that.
A
E
A
This
is
our
defender
working
group
stairs
from
the
chairs,
and
we
have
pascal
running
the
show
for
three
successive
presentations
and
rahul
for
his
root
hack
draft,
and
then
we
have
michael
presenting
the
status
of
the
ideas
for
65
50
bits
to
update
ripple,
trim
it
from
the
features
that
have
not
been
used
so
far,
and
ideas
for
improvement
that
we
want
to
put
together
as
an
update
to
6550
and
a
few
minutes
for
open
floor,
so
that
you
can
bring
up
any
other
discussion.
A
Okay,
regarding
the
milestones,
those
that
we
have
achieved
so
far,
turn
on
rc
8548
has
been
submitted
to
asg
unaware
leaves
been
submitted.
Aodv
ripple
has
been
submitted,
although
it's
not
moving
forward
that
much
and
the
office
are
a
bit
distracted
right
now
to
react
to
the
changes
requested.
A
Upcoming
milestones,
reading
from
the
bottom
to
the
top,
which
is
the
order
of
time,
the
nsa
extension
draft,
and
it's
in
my.
A
A
A
So
probably
this
shows
the
same
thing
again:
yellow
is
the
hot
ones,
the
ones
we
are
working
on
right
right
now
and
that
are
hot.
You
know
and
work
to
do.
The
green
are
those
who
are
steady,
progressing
moving
forward,
but
kind
of
behind
the
yellow
ones
and
blue
is
a
frozen.
We
don't
know
what's
going
on
or
it's
standby
consciously
and.
A
Ripple
observation:
yes,
work
in
progress
as
well.
We
have
two
drafts
that
have
expired,
meepleyang
beer
seacast-
and
this
was
actually
mostly
driven
by
peter
van
der
stark.
So
right
now
it's
they're
not
moving,
and
we
have
two
related
drafts
that
are
not
working
group
paths
yet
won
by
rahul,
that's
being
discussed
today
and
why,
by
pascal
that
we
will
act
on
as
we
get
more
bandwidth.
A
These
are
the
open
tickets.
I
don't
want
to
spend
time
going
through
each
of
them,
but
just
to
let
you
know
that
we're
using
the
issues
in
github
as
tickets
and
yep.
Here
we
go,
and
these
are
the
tickets
that
are
open
in
tracker
for
the
working
world
working
group
somewhat
overlapping,
the
other
ones,
and
with
that
I
don't,
unless
we
have
questions
for
the
working
group
on
that
any
questions.
A
Hearing
nothing
reading,
nothing
in
the
chat,
I'm
assuming
it's
your
turn
to
present.
C
Okay,
so,
as
we
said,
we,
I
have
three
drafts
to
present,
but
two
of
them
don't
need
so
much
time.
The
the
one
that
really
really
needs
discussion
is
the
dow
projection,
so
that
that's
kind
of
kind
of
cool
that
that
we
started
this
one
and
if
we
take
too
much
time,
then
we'll
just
tell
from
the
other
two,
because
they
don't
need
that
much
next
slide.
Please.
C
So
this
is
this
is
about
the
the
dow
projection
and,
as
you
know,
this
is
a
new
operation
in
ripple
that
makes
it
capable
of
sdn
type
of
operation
with
a
controller
that
will
will
lay
out
what
we
call
tracks,
which
are
possibly
complex
path
between
an
ingress
and
an
egress
node.
C
You
may
see
that
as
a
tunnel,
but
since
it
can
be
multi-path,
it's
a
bit
more
complex,
possibly
than
the
tunnel,
and
if
the
packets
have
to
go
between
the
ingress
and
the
egress,
there
is
no
need
for
tunneling
really
because
it's
you
just
insert
the
rpi,
as
you
normally
do
within
for
the
ripple
aware
nodes
inside
this
truck.
But
if
the
packet
is
injected
coming
from
the
outside
or
going
to
the
outside
of
the
truck,
then
there's
normally
a
need
for
encapsulation.
C
Just
like
you
would
do
in
normal
ripple
for
an
external
route.
So
what
changed?
A
lot
changed.
We've
been
working
very
hard,
I'm
aware
of
at
least
one
a
candidate
implementation
which
is
going
through.
I
hope
there's
more,
but
we
are
not
getting
much
feedback
on
on
the
mailing
list
and
that's
a
bit
sad.
But
if
people
are
trying
to
implement,
please
give
us
feedback,
because,
yes,
we
want
to
solve
the
problem,
we
want
to
work
on
it,
but
we
need
to
understand
what
the
problems
are.
C
The
first
thing
that
that
really
came
to
mind
is
the
fact
that
initially,
we
decided
to
separate
the
topological
information
from
the
laying
out
of
the
truck,
and
this
draft
was
supposed
to
be
only
laying
out
the
tracks
as
it
goes.
There
was
never
a
draft
which
would
give
topology
to
the
route
or
to
the
pc,
so
we
kind
of
decided
to
to
keep
that
into
this
document.
C
So
we
created
this
sibling
option
and
the
recent
changes
enforce
that
the
main
geodag
in
which
we
are
building
this
pidau
route
has
to
be
operated
in
non-storing
mode.
For
one
thing,
azkasten
usually
tells
us
it's
the
mode
that
is
the
most
used
and
for
the
other
thing
that
the
non-storage
is
the
mode
where
the
route
already
has
topological
information
about
the
geodag
itself.
So
the
only
thing
that
that
needs
to
be
added
is
the
sibling.
C
So
what
we
did
is
we
say
one
pedal
message:
installs
one
segment
and
then,
if
you
want
to
build
a
track,
then
you
you
that's
more
complex,
then
you
install
more
than
one
segment
and
you
correlate
them
all
with
a
track
id
so
that
that
kind
of
makes
it
easy
for
the
controller
to
handle
the
segments
separately
or
the
controller
holder
the
route
to
to
under
the
segment
separately,
and
that
can
be
decoupled
from
the
activation
or
deactivation
of
the
track.
C
Like
the
controller
may
decide
that
this
segment
is
not
operating
well,
it
might
enable
alternate
segments
and
disable
that
segment
in
runtime.
So
so
you
can
change
the
structure
of
the
track
in
runtime
by
changing
some
of
its
segments.
Without
necessarily
disabling
the
whole
truck,
there's
also
a
little
change
of
structure
that
happens
is
to
simplify
again,
we
say
in
one
pdi
message:
that's
that
can
only
be
one
list
of
hubs
so,
whether
it's
a
vio,
so
it's
it's
storing
mode
or
I
o,
which
is
a
non-storing
mode
source
routing,
either
way.
C
There
is
only
one
list:
that's
what
we
call
the
the
road
projection
option
so
vio,
honestly,
io,
and
but
still
there
can
be
multiple
targets.
So,
if
you
think
again
as
a
segment
or
a
track
as
a
tunnel,
then
the
tunnel
may
lead
just
to
the
tunnel
egress.
Obviously
it
leads
there,
but
it
could
also
lead
to
neighbors
of
the
tunnel
egress
and
those
neighbors
can
be
signaled
as
targets.
C
So
basically
the
pidao
tells
you.
Those
targets
are
reachable
over
this
tunnel
now
as
signal
today.
The
tunnel
is
between
the
requester
and
the
egress
and
we'll
see
in
the
question
that
maybe
we
we
can
do
better
than
that
that
we
can
ask
for
a
tunnel
between
nea
and
nab,
and
we
could
also
ask
for
autonomous
to
be
bidirectional.
C
C
The
track
can
be
made
of
multiple
segments,
they're
all
correlated
with
a
track
id,
and
we
need
to
figure
out
exactly
in
more
details
how
we
do
the
encapsulation
and
how
we,
when
we
do,
the
encapsulation,
how
we
do
it
and
what
exactly
gets
signaled
in
the
vr
option.
For
instance,
do
we
signal
the
ingress?
Do
we
signal
the
egress,
or
can
we
highlight
them?
So
that's
part
of
the
things
which
could
be
improved
and
tuned
in
this
document.
Next
slide,
please.
C
So,
as
I
said,
we,
we
now
include
the
topological
awareness.
We
signal
the
structures
through
non-storing
dials,
normal
of
the
main
geodag.
We
signal
the
siblings
through
the
sibling
information
option.
What
we
do
not
do
is
select
which
siblings
would
be
advertised.
C
C
So
it's
out
of
scope,
but
certainly
for
a
given
implementation
that
there
will
be
a
given
deployment.
There
will
be
a
need
for
some
logic,
some
some
intelligence
to
select
the
siblings
that
are
advertised
to
the
root,
knowing
that
what
the
root
knows
in
terms
of
sibling
is
what
it
can
use
to
build
path,
and
if
you
don't
advertise
the
sibling
to
the
root,
then
the
root
will
not
know
that
it
can
use
it
in
a
path.
C
There
can
only
be
one
vio
or
srvio
that's
for
simplification,
so
there's
only
one
act
to
be
to
be
sent
by
the
ingress
of
the
track.
C
Now
the
vio
is
sent
to
the
egress.
That's
was
always
the
case.
The
srvio
is
sent
to
the
ingress
in
the
case
of
a
vio.
The
message
is
propagating
along
the
reverse
path
to
the
ingress,
and
the
ingress
anyway
sends
that
yak.
As
I
said,
the
track
id
has
to
be
a
local
instance
id
for
now
it's
a
local
instance
id
of
the
egress,
so
the
track
is
really
a
form
of
dodge
that's
rooted
at
the
egress.
C
So
we
take
the
we
identify
the
track
by
a
local
instance
of
that
egress
and
the
fully
qualified
instance
id
is
the
ip
address
of
the
egress
plus
the
local
distance
id
in
the
namespace
of
that
egress.
C
C
So
there
was
a
little
bit
of
change
in
the
structure
of
the
pidao
option,
so
so
this
is
well
the
vio
or
the
slvio.
Actually,
so
the
the
big
challenge
is
we,
we
mandated
8138
compression
to
make
sure
that
it's
always
compressed.
Initially,
we
could
say
it's
compressed
or
it's
not
compressed
and
with
expressed
whether
it's
compressed
or
not,
and
since
the
srh6
layer
edge
is
self-descriptive
in
its
compression
and
one
of
the
compression
mode
is
actually
non-compression.
C
It
looked
easier
to
just
always
use
the
slg6
lower
edge
header
and
then
the
list
of
the
address
compressed
as
the
slh6
layer
h
would
indicate.
So
now
there
is
an
sr6
lower
header
in
the
pidao.
C
Normally,
if
you're
using
storing
mode,
you
need
to
have
a
strict
sequence
of
address,
because
each
each
next
address
must
be
a
neighbor
of
this
address.
So
you
can
always
forward
and
you'd
have
a
risk
of
a
loop.
Loop
avoidance
was
a
delicate
thing.
That
also
needs
to
be
considered
when
you
look
at
this
draft
and
if
you
make
a
review,
think
about
loop
avoidance,
what
we
did
to
avoid
loops
is
we
we
enforced
that
the
story
mode
is
always
tracked
for
non-storing
mode.
C
C
Something
like
that
and
then
you'll
see
why,
when
we
discuss
encapsulation,
but
it's
that
again
is
not
an
easy
discussion.
So
that's
why
we
that's
why
I
wanted
time
in
this
working
group
to
kind
of
explain
the
problems,
and
you
know
on
the
mailing
list
I'll
during
the
discussion,
get
feedback
on
how
to
do
things.
C
So
this
srh6
leverage
provides
you
the
compressed
list
of
the
via
addresses.
That's
a
strict
in
storing
mode,
that's
loose.
If
you
like
in
non-storing
mode
in
non-storing
mode.
If
rfc8138
is
effectively
deployed
in
the
network,
then
the
specification
adds
that
we
want
the
optimized
format
to
be
used
by
the
root
which
basically
makes
it
so
that
what
you
find
in
this
option
is
exactly
what
you
would
put
in
the
packet,
so
the
the
encapsulating
node
never
has
to
compute
the
compressed
form
of
the
srh6
lower
edge.
C
As
you
know,
in
in
normal
ripple,
the
only
node
which
computes
an
srh6
layer
h
is
the
root.
Let's
see
because
the
air
h
always
goes
from
the
root,
so
the
complexity
of
computing.
The
compressed
form
of
an
srh6
range
is
only
in
the
root,
and
we
want
to
conserve
that
feature
because
it's
a
complex
code
and
we
don't
want
it
distributed
in
the
nodes.
So
the
way
there
is,
we
use
the
srh6
large
format
here
so
that
the
root
basically
provides
the
pre-encoded
header
to
be
inserted
in
the
packet.
When
you
do
the
encapsulation.
C
Now
think
again,
when
you,
when
you
hear
this
of,
should
we
signal
the
ingress
in
this
list
and
should
we
signal
the
egress
in
this
list,
because
if
we
signal
the
ingress,
then
all
of
a
sudden
you
may
say
hey,
then
the
ingress
must
consume
the
first
address
when
you
actually
follow
the
packet,
because
that's
him,
if
you
don't
provide
the
ingress
in
this
list,
then
how
does
the
ingress
know
which
of
its
address?
C
It
should
use
that
that's
an
important
question,
because
the
compression
depends
always
on
the
previous
address
when
you
send
a
packet.
The
first,
the
sender
is
the
compression
reference.
So
if
a
node
encapsulates
and
adds
a
header
like
this,
the
source
address
that
is
going
to
use
is
the
reference
for
the
compression.
So
it
must
be
very
clear
which
address
is
used
to
ensure
that
we
get
the
compression
we
expect
so
so
this
is
kind
of
the
primes
we
have
and-
and
we
need
to
to
think
through
as
we
progress
this
document.
C
Do
we
signal
the
via
the
ingress
address,
in
which
case
the
the
ingress
node
needs
to
consume
it,
or
do
we
not
signal
it
and
then
how
do
we
select
it
exactly
next
slide?
Oh
another
thing
is,
as
I
said,
we
want
the
the
srh6
language
fully
comprised
by
the
root
if
rfc8138
is
in
use
in
the
network.
C
Well,
if
you
want
it
fully
compressed,
it
might
be
that
you
have
different
compression
like
two
bytes
and
then
four
bytes
and
with
rfc813h.
You
need
to
insert
more
than
one
sr6
lower
edge
in
that
case,
because
each
srh6
voltage
is
for
a
fixed
size.
So
if
you
go
from
two
bytes
to
four
bytes,
then
you
need
to
switch
as
a
register
excel
average.
C
C
So,
for
now
there
is
text
which
says
that
you
encapsulate
if
the,
if
you
are
not
in
the
case
where
the
source
is
the
ingress
and
the
destination,
is
the
egress.
Now
it's
it's.
What
the
text
says,
it's
not
fully
exact
and
we
need
to
to
to
reword
that
a
little
bit
first.
There
are
two
cases
to
keep
in
mind.
The
first
case
is,
I
want
to
complement
a
non-storing
node,
a
non-storing
mode
diode
with
storing
mode
p
dials
along
the
path
with
the
goal
to
compress
the
source
route
header.
C
C
So
if
you
look
at
it
when
you,
what
the
root
builds
is
a
loose
source
routing
and
between
two
hubs
of
the
loose
source
routing,
we
use
the
pdow
storing
mode
to
go
between
the
loose
hops
in
the
source
altimeter,
which
means
that
the
rpi
is
correct.
You
don't
need
to
encapsulate
between
the
loose
hops,
because
the
rpi
is
still
indicating
the
instance
id
of
the
main
diode.
C
So
actually,
if
the
the
path
is
non-star
is,
is
I'm
sorry
if
the
pdow
is
storing
mode
and
the
rpi
that
comes
in
is
already
correct?
Actually
you
don't
want
to
encapsulate
you
just
want
to
forward
along
the
storing
mode
pedal
between
the
loose
source
route
hops.
C
C
Same
thing
when
you
you
forward
the
long
segments
of
a
track.
Actually,
the
api
contains
normally
the
track
id.
So
even
for
a
given
segment,
you
don't
need
to
re-encapsulate,
you
don't
want
to
re-encapsulate.
You
want
the
track
id
to
be
seen
as
you
forward
along
the
segments
of
the
track.
C
The
other
thing
that
I
will
have
slides
next
is
when
you
use
a
source
routing
editor,
so
it's
non-storing,
pi
dial,
normally
to
insert
it.
You
need
to
encapsulate
so
each
time
you
forward
the
packet
along
the
segment.
You
would
need
to
encapsulate
to
to
place
the
routing
either
for
that
segment.
C
C
So
this
is
completely
acceptable.
The
draft
allows
to
put
a
track
in
another
track,
so
if
one
segment
is
considered
as
a
track,
for
instance,
with
a
strict
source
route
and
and
the
track
itself,
the
main
track
is
a
loose
source
route
that
goes
across
the
segments.
C
C
There
is
another
mode
whereby
we
kind
of
refill
the
routing
editors
segment
by
segment,
but
if
you
refill
the
routing
editor,
it
looks
a
lot
like
a
routing.
Editor
insertion,
it's
not,
but
it's
something
that
we
have
to
debate
because
it's
it
basically
looks
acceptable.
If
you
look
at
the
opposition
against
the
rotting
adder
insertion,
but
it's
still
not
fully
clean
because
it's
well.
C
I
will
show
you
in
picture
because
it's
kind
of
complex,
but
basically
the
the
thing
I
would
like
to
achieve
here
is
when
you
forward
a
packet
along
the
segments
of
a
truck.
Even
if
the
segments
themselves
are
source
routed,
you
don't
effectively
encapsulate
you
change
the
source.
You
change.
The
routing
editor
destination
stays
the
tracking
grass,
the
api
stays
taken
from
the
namespace
of
the
tracking
rest,
so
the
the
external
header
always
signals
the
main
track,
not
the
segment.
C
Is
you
have
a
tracking
grass?
You
have
a
number
of
hops,
you
have
the
tracky
grass
and
the
pidao
in
this
case
is
shown
in
non-storing
mode
in
storing
mode.
I'm
sorry,
so
the
pedal
is
is
sent
by
the
route
to
the
tracking
rest
and
it's
forwarded
along
the
reverse
path
to
the
tracking
grass
and
the
tracking
grass
sends
the
attachment
back
to
the
route.
C
C
Okay?
So
so
that's
classical
ripple
when
you
have
a
local
instance,
local
instance,
and
you
you
have
a
bit
in
the
api
which
says
the
name.
Space
is
taken
from
source
or
destination
in
this
case,
would
be
set
to
destination
and
the
track
id
is
the
local
ripple
instance
id
kind
of
simple
right.
It's
what
we
do
for
ripple
and
nowhere
leaf.
C
A
packet
coming
from
the
outside
has
to
be
encapsulated
to
place
the
rpi
in
the
packet,
and
it's
not
just
the
rpi,
but
also
to
set
the
destination
of
the
packet,
because
the
instance
is
local
to
the
destination,
so
it
to
be
fully
signaled.
You
need
both
the
destination
to
be
the
track
address
and
the
api
to
to
be
the
track
id.
C
C
Okay,
now
I
want
to
do
two
consecutive
segments
and
I'm
in
non-storing
mode.
C
There
are
two
ways
of
doing
this,
so
basically
the
track
itself,
the
end-to-end
track,
would
have
a
loose
hop.
One
then
lose
hop.
Two
then
lose
hub,
three,
meaning
that
there
are
hops
in
the
middle,
but
the
the
rotting
editor
that
is
shown
for
the
track
packet
and
the
encapsulation
that
is
done
at
the
ingress
of
the
track
says
rotting,
either
lh1
and
h2
h3.
C
So
that's
the
quote-unquote
inner
track
now,
because
you
have
to
go
across
the
loose
path
between
nh1
and
h2
and
that
loose
path
is
if
that
loose
path
is
non-starring,
in
which
case
my
arrow
with
the
pedal
is
kind
of
inexact,
because
it's
really
populated
in
the
lh1.
But
if
you
have
to
do
that,
then
basically,
you
would
need
to
re-encapsulate
the
packet
at
lh1
with
the
source
rotator
that
goes,
the
hops
between
h1
and
h2,
and
the
destination
being
nh2
and
a
track
id
which
is
taken
from
the
namespace
of
lh2.
C
So
the
main
track
is
now
placed
into
track,
one
which
is
which
goes,
which
is
the
first
segment
and
then
lh2
decapsulates
or
it
could
be
degress,
which
could
be
the
note
just
before
lh2
in
this
case.
What's
illustrated,
is
the
egress
is
the
the
the
node
just
before
h2,
so
the
the
the
node
just
before
lh2
neighbor
of
h2
dec
decapsulates,
the
packet?
It's,
the
tracking
grass,
finds
that
the
next
entry
in
the
loose
source
routing
either
is
lh2.
It's
one
of
my
neighbors
fine
and
I
seem
to
pass
him
the
packet.
C
C
C
Now
what
the
draft
allows
to
do
and
that's
the
big
discussion
is
to
say
hey
when
I
I
am
the
last
half
of
a
track.
C
Then
I
can
kind
of
remove
the
outer
header
and
place
a
new
one
which
has
the
same
destination,
which
is
the
final
destination
same
rpi,
because
it's
the
track,
but
just
change
the
source
and
the
sequence
of
hubs.
So
I
become
the
source.
That's
why
it's
not
a
header
insertion.
I
become
the
source,
I
add
the
list
of
of
hops
between
me
as
loose
up
to
say
and
loose
up
3.
C
C
So
if
you
do
this,
this
kind
of
weird
quote-unquote
editor
insertion,
then
you
don't
have
to
encapsulate
the
track
within
another
track.
You
just
kind
of
reload
the
routing
editor,
as
you
do
from
the
source
route
between
those
hubs.
You
just
reload
the
routing
editor
to
indicate
the
strict
hops
between
the
loose
hubs
that
allows
to
keep
signaling
the
the
main
track
if
you
have
to
do
cross
or
anything
based
on
the
track
id.
C
So
so
whether
we
want
to
do
that,
whether
we
can
do
that,
you
know,
for
you,
know
the
six-man
perspective,
that's
the
discussion,
but
the
good
thing,
if
we
we're
doing
this
kind
of
rotting
at
our
reload,
is
that
we
could
keep
signaling
the
track
id
in
the
authorizer
so
and
with
rfc-8138
is
very
easy
to
do
by
the
way.
Okay
next
slide.
C
Now
we
are
looking
at
the
same
picture
in
storing
motor
this
time.
The
the
pedal
arrows
are
correct.
They're
sent
you
know
from
the
segment
egress
to
the
segment
in
grass,
and
you
see
this
node.
I
call
relay
in
the
middle,
so
say
the
so.
The
track
is
is
indicated
by
the
the
final
destination
and
and
again
local
reaper
instance
id
from
the
final
destination
as
track
id
in
the
api.
C
If
you
take
the
position
of
the
relay,
the
relay
will
receive
a
packet
which
final
destination
is,
is
the
defender
destination
and
for
which
does
a
segment
a
track?
It
already
has
the
right
api
in
it,
so
it
doesn't
need
to
re-encapsulate.
We
are
pretty
much
in
the
same
case
as
the
one
I
made
very
at
the
very
beginning
of
this
discussion
when
we
use
a
non-stirring
main
geoduck,
and
we
use
projected
dowels
in
storing
mode
to
kind
of
shorten
the
rotting
header.
We
are
in
the
same
situation.
F
Sure,
hey
no
problem
so
in
in
slightly.
If
I
understood
you
correctly,
you
said
that
the
intent
is,
if
you
are
the
last
segment
or
the
last
hop
or
something
in
the
in
the
segment.
C
F
Then
you're
saying
you
can
remove
the
header,
so
I
don't
know
if
you
have
talked
about
this
at
six
man
and
I
know
many
of
you
follow
six
man.
C
I
do
follow
six
man,
I
have
followed
all
the
srv6
discussions
about
header
insertion
and
michael,
and
I
we
are
very
very
familiar
with
these
discussions.
C
Look
at
everything
that
happened.
Repeat
it
again.
You
want
this
thing
because
if
ross
says
we
don't
want
this
thing,
we're
happy
with
the
re-encapsulation
for
each
segment,
then
they
don't
even
bother
with
six
men.
Now,
if
the
group
finds
that
avoiding
the
re-encapsulation
and
doing
this
form
of
header
insertion,
which
is
not
the
one
that
six-man
did
not
like
it's
kind
of
different,
then
we
can
go
and
fight
at
six
men
or
decide
what
we
do.
The
the
main
difference
with
this
and
six
man
is
okay.
C
You
have
a
sequence
of
nodes,
but
the
the
routing
editor
would
basically
say
this
sequence
of
node
and
the
last
entry
in
the
routing
editor
would
be
the
destination
the
final
destination
of
the
track,
because
we
always
want
to
signal
the
track
by
being
the
final
destination
as
the
namespace
and
the
api
being
a
local,
replace
ripple
instance
id
in
that
space.
So
we
need
the
final
destination
that
is
the
final
destination,
the
guy
on
the
right
for
the
right
on
this
picture.
C
The
best
now,
when
lh2
and
at
this
point
for
this
drawing
lh2
would
need
to
be
the
egress
of
truck
one
so
not
to
neighbor
strictly
the
egress
nh2
gets
the
packet
and
all
the
routing
either
has
been
consumed,
but
him
right
I
mean
he
gets
the
packet,
so
it's
consuming
it,
and
next
there
is
the
best
final
test.
So
now
so
now
it's
loose
between
me
being
lh2
and
dust
and
the
operation
will
be
okay.
C
So
we
we
remove
a
writing,
a
header
and
we
add
a
new
one.
Instead,
it's
just
that
we
were
not
the
final
destination
of
that
of
that.
Writing
that
we
were
the
opinion.
Teammate
hub,
but
we
still
take
the
liberty
of
removing
the
outer
encapsulation,
placing
a
new
outer
encapsulation
with
the
same
destination,
ultimate
node,
but
now
lh2
a
source,
and
then
this
this
number
of
writing
editors.
So
that's
why
it's
not
the
header
insertion,
because
now
the
source
has
changed,
the
source
of
the
encapsulation
becomes
lh2.
C
So
all
those
discussions
at
six
man
saying
hey,
you
cannot
track.
Who
did
this
right
when
there
is
a
hidden
insertion?
You
it's
anonymous,
you
don't
know
who
did
it?
You
cannot
send
the
packet
back
to
that
originator.
If
there
is
a
prime,
that's
not
true,
we
we
changed
the
source,
we
know
who
did
it.
F
Right
so
the
discussion
six
man
with
spring
was
more
about
removal
of
the
header.
That's
why
I
was
asking
about
the
if
you
were
the
next
last
hop
or
if
you're
modifying
the
header
somewhere
else.
In
any
case,
the
important
thing
here
is
go
check
some
of
the
discussion
and
some
of
the
resolution
to
that
which
has
a
lot
to
do
with
how
you
can
or
not
interpret
8200,
but
any
case.
You
said,
the
important
thing
is:
let's
first
figure
out.
If
we
really
want
this
or
not.
C
C
If
you
do
that,
then
the
author
header
signals
the
segment,
not
the
track,
so
basically
a
track
within
the
track.
If
we
want
to
to
avoid
that,
then
we
would
need
to
do
this.
Pin
previous
last
routing
in
the
hop
re-encapsulation
game
that
I
was
just
discussing
next
slide,
please,
because
I
don't
have
much
more
time
so
so
what
I
was
saying
here
is
the
the
main
thing
is
the
the
the
relay
doesn't
need
to
change
the
api.
C
The
api
is
the
one
of
the
main
track,
so
it
doesn't
need
to
encapsulate
it's
just
forwarding.
You
just
have
a
routing
table
which
was
populated
by
p902,
whereas
along
the
segment
one
it
was
populated
by
pdi1,
but
the
routing
entries
from
tracking
grass
to
tracking
grass.
They
look
the
same.
It's
just
not
the
same
pedal
that
has
signaled
them.
C
C
C
Slide
yeah,
and
that
was
actually
the
slide
where
we
should
have
discussed
this
this
thing
with
alvaro
compared
to
two
slides
ago,
where
we
did
the
non-story
mode
with
tracking
track.
Now,
that's
where
I
discussed
this
srh
reload
operation,
where
you
you
re-bump
a
new
source
and
which
is
the
relay
and
a
new
sequence
of
writing
editors
with
the
same
final
distinction,
which
is
the
track
egress
next
slide.
C
Now
we
had
a
number
of
discussion
points
on
the
mainland
list.
The
first
one
is
the
lifetime
unit
to
show
so
right
now
we
are
saying:
ripple,
has
a
lifetime
and
a
lifetime
unit
in
the
configuration
option,
and
so
everybody
everything
is
kind
of
timed
with
this
lifetime
unit.
So
we
can
express
the
lifetime
in
a
more
concise
way,
because
you
cannot
multiply
it
by
the
lifetime
unit
and
women
as
an
implementer
says
you
know,
maybe
for
for
the
projected
path.
We
want
a
different
kind
of
unit.
C
Could
you
signal
it
in
the
pdr
request,
and
I
guess
that
can
be
done.
We
probably
would
need
to
change
the
pdow
format
as
well,
because
we
probably
would
also
want
so.
The
pdf
right
now
is
is
the
same
format
as
now,
but
do
we
want
to
to
express
a
lifetime
in
the
in
in
there?
That
would
be
different
form
that
that's
first
question.
I
have
nothing
against
it.
I
would
like
to
see
a
discussion
remaining.
Last.
C
Second
question
is,
since
the
track
id
is
really
a
ripple
instance
id.
How
do
we
differentiate
when
we
receive
a
packet
from
something
which
is
a
longer
pdio
versus
something
which
is
a
longer
local
ripple
instance?
C
And
I
don't
see
that
it
should
make
a
difference,
but
if
there
is
a
good
argument
that,
because
it's
the
same
thing
enough,
but
if
there
is
a
good
argument
that
it
should
make
a
difference,
then
maybe
we
we
would
need
something
in
the
api
to
signal
that
it's
it's
a
projected
path.
There
is
one
bit
left
in
the
api,
so
we
could,
if
we
wanted
to,
but
then
again
we'd
like
to
see
the
meaning.
This
react
to
this
main
problem.
C
The
main
thing
that
could
lead
to
big
changes
in
document
is
women
is
asking
us
if
we
could
make
this
the
track
or
segment
bi-directional,
and
this
impacts
a
lot
of
things,
in
particular
the
fact
that
we
signal
the
track
id
with
the
destination
of
the
packet.
C
If
we
make
it
bidirectional,
it
could
be
either
the
source
or
the
destination
of
the
packet
send
your
dag.
Basically,
if
you
want,
but
you
know
recognized
by
either
the
source
of
destination
repo
lows
that
so
for
the
packet
forwarding,
we
would
know-
because
there
is
this
bit
in
the
api
which
says
the
namespace
is
taken
from
the
source
or
the
destination
of
the
packet
for
local
reaper
instance.
C
It's
more
things
like
this,
this
other
change
that
I
said
we
actually
we
just
discussed
with
alvaro.
If
we
do
that
kind
of
change,
you
saw
that
the
source
of
the
packet
changes
now
if
the
source
of
the
packet
is
is
describing
the
track.
We
cannot
do
that
change
anymore.
C
So
that's
why
I
said
you
know
first,
let's
agree
on
what
we
want
and
then
we'll
go
to
six
man
to
get
it
if
we
can,
but
if,
for
instance,
if
you
want
to
signal
a
packet
going
forward
or
backward
along
a
track,
then
the
track
could
be
signaled
by
the
source
or
the
destination.
If
we
are
taking
that
path,
that
change
is
typically
this
aspect
of
being
able
to
stitch
or
to
reload,
rotting
headers
and
then
suggestion
to
add
a
flow
yeah.
C
A
clear
thing
is:
is
the
pida
and
pidawak
which
are
generated,
because
there
is
a
pdr
pack
pdr
request
message:
they
don't
live
on
the
same
time
that
was
clearly
expressed
thanks
to
discussions
we
had
the
route
is,
is
free
within
for
given
pdr,
which
is
a
contract
to
build
a
track.
It's
free
to
change
the
segments
use
lifetimes
for
the
segments
which
are
not
the
same
as
the
the
lifetime
that
is
granted
for
the
pdr.
C
Slide
so
need
help
need
help.
Loop
avoidance
needs
to
be
things
through.
There
was
also
this
request
that
the
pdr,
for
now
it's
always
the
source
of
the
ingress
of
the
track.
Could
we
send
a
pdr
for
which
we
are
the
destination,
or
could
we
send
the
pdr
for
which
we
are
neither
the
source
or
the
destination,
in
which
case
we
will
need
to
be
able
to
signal
both
in
the
pdr
which
we
can
today?
C
How
do
we
maintain
the
availability
of
the
siblings,
so
some
words
about
using
rfc855
or
something
or
you
know
ripple
says
you
can
use
nd
to
monitor
your
neighbors
kind
of
that's
missing
for
for
neighbor,
for
for
siblings
and,
as
I
said
earlier,
do
we
want
the
ingress
and
egress
to
be
listed
in
the
rpos?
C
Is
the
egress
an
implicit
destination
of
the
track?
There's
no
text
about
that,
but
we
we
need.
We
want
to
be
very,
very
specific
if
the
ingress
and
the
egress
are
listed
right
now.
The
text
says
they
are
like.
I
said
if
you,
if
you
want
to
be
on
the
full
rpo,
so
that
the
the
encapsulator
can
use
it
as
is,
and
the
ingress
is
in
there,
you
would
have
to
consume
it
before
it
actually
sends
the
packet
and
that's
pretty
much
it.
C
I
hope
you
see
that
there's
still
a
lot
of
work
to
be
done,
there's
there's
still
some
a
number
of
complexities,
and
I
would
like
to
ask
the
chairs
to
to
do
something
about.
You
know,
maybe
forming
a
team
or
something
to
complete
this
document,
because
I'm
reaching
the
limits
of
what
you
can
do
by
yourself
or
with
very
limited
feedback.
C
So
I
would
appreciate
to
to
have
a
a
stronger
team
to
complete
this
document.
C
B
Well,
I
guess
the
the
changes
to
p
dao
is
that
I
guess
I
don't
quite
didn't
quite
realize
they
were
happening.
So
I
think,
there's
probably
a
lot
of
quiet,
because
I
think
that
we're
sort
of
trying
to
approaches.
B
C
Yes,
I
could
improve
the
slides,
but
I
need
more
time.
Maybe
we
could
have
an
interim
that
would
be
like
where
and
I
would
build
more
slides
and
explain
more
what
goes
into
the
headers
and
things
while.
B
Explaining
like
well
because
that
worked
for
you,
I'm
trying
to
say
that
before
we
can
catch
up
and
ask
you
intelligent
questions,
I
think
we're
going
to
have
to
do
some
more
homework.
I
said
I
didn't
quite
realize
this
was
happening
to
the
document,
but
I
think
your
slides
are
quite
good.
I
just
need
to
absorb
it.
Probably
abs
I'll,
probably
walk
it
through
slowly
once
I
see
it
on
youtube
again
and
then
yeah.
We
do
need
to
have
an
interim
to
discuss
this.
I
agree.
C
It's
you
know
it
might
look
overly
complex,
but
if
you
think
at
it
we're
adding
a
new
form
of
repo,
we
have
aodv
repo,
which
is
like
reactive.
We
have
traditional
ripple,
which
is
proactive,
and
now
we
are,
we
have
sdn
ripple,
which
is
controller
and-
and
you
can
expect
that
there
is
complexity
in
this
document.
Just
like
there
is
complexity
in
repo.
What
we
want
to
to
simplify
that
to
the
maximum,
but
it's
kind
of
normal
that
it's
not
easy.
C
The
the
other
thing
is
initially,
it
was
a
serial
path
like
we
were
compressing
the
source
rotator
of
the
main
instance.
Now
we
are
pushing
tracks
in
the
network
and
as
we
do
this,
we
we
look
at
the
60s
architecture.
We
look
at
row,
and
so
we
want
to
do
something
which
is
a
lot
more
than
a
serial
path.
We
want
this
track
to
be
able
to
do
replication,
elimination
or
all
the
games,
and
that's
why
you
know
you
have
all
this
segment.
C
C
C
Raw,
I
guess
that's
it.
Your
chairs,
for
this
talk.
A
Okay,
you've
pretty
much
eaten
up
all
the
time
that
was
allocated
to
you
so.
C
Just
keep
through
this
yeah
yeah,
let's,
let's
just
keep
stroking
so
on
our
leaves
so
alvaro
is
with
us.
I
can
only
next
eyepiece.
I
can
only
thank
alvaro.
We've
been
through
excruciating
details
in
this
document
to
to
clean
it
up
and
alvaro
has
been,
has
been
doing
like
not
just
one
but
two
or
three
reviews
till
we
get
things
okay
and
then
the
main
discussion.
That's
still
there
is
the
one
that
we
share
with
user
free
info
and
with
turn
on
rfc8138,
which
is
how
do
we
exactly
word?
C
C
C
So,
oh
by
the
way
unawareness
that
you
mentioned
it
is
now
pushed
for
itf
score
or
something,
and
so
it
will
go
through
the
asg
rfc8138
turn
on
went
through
the
isg
next
slide.
Please!
C
So
through
the
shg
circle
we
made
like
nine
updates
and
the
the
only
thing
which
is
kind
of
I
think
it's
clarified
now,
but
I've
not
seen
benjamin
removing
his
discuss.
Is
this
mob
7
discussion
so
for
each
of
the
three
drafts?
So
that's
this
one,
that's
the
alif
and
that
user
free
info.
C
You
must
say
what
the
flag
becomes
for
map
seven,
because
we
say
if
if
the
map
field
is
set
to
or
once
then
the
definition
of
the
flags
does
not
apply,
which
means
that
you
have
to
tell
the
implementation
today
what
they
do
if
they
test
map
and
mop
equals
seven
for
this
particular
spec.
We
said
if
sixlapan
hc
is,
is
active
on
the
link.
Then
rfc8138
will
also
be
active
on
those
links
and
only
if
next
slide.
C
F
No,
I
think,
he's
just
waiting
to
see
the
actual
document
where
we
talk
about
mob
seven,
which
yes,
so
when
that
comes
in,
I
think
it's
gonna
clear.
So
we
should
be
okay,
okay,.
C
A
A
Nope
well
then,
I
haven't
seen
him
since
the
beginning
of
the
session,
so
I
don't
think
it'd
show
up.
I
suggest
we
just
go
through
the
slides
quickly,
just
to
refresh
everybody
and
what
the
topic
is
and
then.
A
So
the
the
topic
for
the
this
draft
and
the
motivation
for
this
to
have
I
understand,
is
to
get
the
confirmation
from
a
leaf
node
that
the
path
has
been
established
to
the
root,
even
in
storing
mode
in
non-storing
mode.
The
gao
goes
all
the
way
back
to
the
route
and
the
dao
arc
originates
at
the
route.
So
it's
safe
to
assume
that
the
route
has
established
a
routing
state
for
that
lyft
node
when
it
sends
a
geoack.
A
Therefore,
when
it
receives
the
dioxin
node
can
assume
that
communication
is
established
and
can
start
sending
application
traffic.
However,
in
storing
mode,
the
gao
goes
hop
by
help
across
the
the
chain
to
the
root
and
the
rs
rfc.
6550
currently
says
that
the
dork
is
issued
by
the
intermediate
router
back
to
the
node
and
between
intermediate
routers,
and
so
they
happen
in
sequence,
as
shown
at
the
bottom
right
of
the
slide,
and
therefore,
when
the
lymph
node
receives
a.
A
Even
following
that,
there
could
be
many
reasons
why
the
puff
establishment
will
fail
along
the
path
up
the
route
and
so
raul's
proposal
is
to
add
a
message
going
flying
back
from
the
root
to
the
lyft
node,
when
state
has
been
established
at
the
root,
meaning
that
the
path
is
now
fully
established,
and
I
think
that's
what
it
shows
here,
you
can
see
dio's
populating
up
the
structure
and
this
root
hack
message
going
back
unicast
to
the
nymph
node
from
the
route
and
in
order
to
request
that
final
acknowledgement,
raul's
proposal
is
to
add
a
flag
in
the
transit
information
option
that
goes
with
the
dro
requesting
for
that
flag
and
the
route
seeing
that
flag.
A
Would
there
then
generate
the
root
act
now,
there's
an
aggregation
that
can
take
place
on
the
way
up
to
the
root
by
intermediate
routers.
So
we
have
to
make
sure
how
this
is
handled
and
also
we
only.
We
request
the
device
only
to
send
one
key.
E
A
Well
answer,
I
think
it.
The
slight
sounds
of
that
yeah.
We
already
discussed
that
sorry,
I'm
trying
to
carry
on
through
the
presentation
and
then
we'll
have
the
discussion,
and
so
there's
an
issue
with
this
kbit.
We
said
that
the
leaf
will
only
will
only
request
once
after
reboot
for
that
root
act
and
not
with
the
subsequent
dros
that
it
uses
to
refresh
the
route.
A
Therefore,
that
state
that
has
to
be
remembered
by
the
intermediate
routers
for
each
of
these
lymph
nodes,
which
I
understand
is
pretty
much
the
way
the
e
flag
is
needs
to
be
processed
as
well,
but
I
may
get.
I
mean
it
helped
exactly
on
the
details
of
that
comparison.
A
So
that's
a
discussion
about
the
k
flag
and
how
it's
handled
and
and
now
the
situation
with
ripple
unaware
leaves,
and
so
the
in
this
case
the
gao
with
the
k
flag
will
be
sent
by
the
6
lr.
That
acts
on
behalf
of
the
rule
and
this
all
path
establishment
will
be
between
the
rule
sending
its
ns
and
the
6lr
sending
dna.
A
A
A
I
guess,
pascal
michael
you,
you
could
remind
us
of
the
reasons.
My
mind
is
blank
at
this
time,
michael
pascal,
anybody
wants
to
come
back
to
the
rescue.
B
B
A
C
Don't
know
questions
we
have
this
sorry
dominique.
We
have
this
this
question
of
taking
notes
for
ripple
v2.
I
realized
I
created
a
second
placeholder
where
there
was
already
one
and
I'm
perfectly
fine
to
merge
them,
but
that's
part
of
the
things
we
could
put
in
that
placeholder
is
to
make
sure
we
clarify
the
way
the
acknowledgements
are
said,
because
it
seems
that
the
original
ripple
could
be
misunderstood.
The
way
it
was
written.
A
C
Oh
I'm
sorry,
I
was
muted
again
yeah
yeah
I
have
my
own
github
and
and
ines
has
a
horn,
so
just
realized
there
was
a
collision
there.
So
we'll
just
merge
them.
It
was
all
disgusting.
Well,
maybe
it
was
private.
I
thought
it
was
the
main
invest.
A
Okay,
so
we'll
just
merge
them
so
michael,
I
think
you're
up
to
discuss
55
50
minutes.
B
Sure
next
slide
so
so
yeah.
So
I
guess
you
guys
created
this
placeholder
for
this.
That's
what
maybe
you're
talking
about
and
we're
supposed
to
dump
content
in
it.
This
is
a
github
to
either
open
issues,
or
I
guess
pascal
we're,
maybe
even
putting
the
beginnings
of
a
draft
in
there
as
we
go
forward,
and
I
guess
that
was
the
point
I
didn't
make.
This
slide
next
slide.
B
I
can't
right,
I
had
to
write
this
slide
anyway.
That's
the
contents
of
it
of
of
what
we're
putting
in
here
and
the
idea
is
that
this
is
some
of
the
points
that
are
going
into
it,
and
so
that's
great.
So
we
have
these
seven
points
of
the
different
pieces
that
could
be
into
this
part,
and
if
you
go
to
the
next
slide,
I
have
some
diagrams
that
I
thought
were.
B
B
The
whole
internet
would
make
more
sense
in
french.
We
should
do
it
that
way,
so
so
this
is
what
I
I
was
asked
to
add
some
stuff,
and
I
this
is
what
I
added
to
it.
So
there's
a
couple
different
concepts
of
what
we
could
be
doing
so
the
first
concept
is,
we
could
take
rfc
6550.
B
We
can
drop
off
that
red
stuff,
the
stuff
we
never
used,
such
as
the
secure
forms
of
the
dao
and
dis
and
all
this
stuff.
We
didn't
never
use
secure
forms
yet
because
they
don't
work
unless
you
do
asymmetric
crypto,
which
certainly
10
years
ago,
when
we
wrote
6550,
was
considered
way
too
expensive
to
do
on
constrained
devices.
B
In
that
time,
that's
no
longer
as
true
as
it
was
and
that's
its
consideration.
We
would
add
some
clarifications,
so
basically
the
discussion
would
be
which
pieces
we
have
good
interoperability
experience
with,
and
what
would
we
be
doing
is
we'd
be
trying
to
build
a
6550
which
would
now
be
an
internet
standard,
so
that
would
actually
require
some
evidence
of
interoperability
and
we
don't
actually
haven't
done
a
lot
of
interoperability.
I
think,
as
a
working
group.
B
So
that's
one
one
thing
we
could
do.
That's
that's
not
necessarily
what
we
should
do,
but
that's
one
thing
we
could
do
next
slide.
Please.
B
So
the
other
thing
we
can
do
is
we
can
do
an
rfc,
6550
bis.
We
can
open
up
the
document
that
we
have
take
the
stuff
that
we
used,
throw
it
into
this
pot.
B
Take
all
these
other
documents
that
we're
working
on
and
we'll
have
an
rfc
for
soon,
and
we
could
massage
all
that
text
together
so
that
we
wind
up
with
an
a
new
document
that
has
everything
that
we've
talked
about
so
far
into
it
and
we
would
essentially
be
we
would
be
cycling
at
a
proposed
standard
and
we'd
have
a
document
that
well
it's
probably
going
to
be
bigger.
But
hopefully
you
know
we
might
cut
some
stuff
out.
B
That's
that's
not
that
important
anymore
and
we
would
have
a
new
document
and
implementers
could
read
a
single
document
and
would
be,
I
hope,
elated,
to
only
have
to
to
track.
One
piece
down.
B
My
guesstimate
is
that
it's
probably
a
two
to
three
year
effort
to
do
that
and
it's
probably
in
terms
of
the
working
group,
elapsed
time
to
work
on
it,
and
it
probably
requires
something
something
approaching
a
one-third
fte
of
somebody's
time
to
during
a
good
part
of
that
to
actually
make
it
reasonably.
Do
a
lot
of
editing
a
lot
of
wrangling,
a
lot
of
going
back
and
forth
with
different
people
and
getting
a
lot
of
reviews.
B
So
I
don't
think
it's
something
we
should
jump
into
without
some
some
view
and
to
knowing
that
we
really
do
have
that
resource
out
there
who's
going
to
take
that
that
editorial
ship
onwards.
So
something
to
to
consider.
I
think
it
should
be
done
at
some
point
whether
we
want
to
start
this
in
2021
or
not,
is
an
open
question
to
there
so
next
slide.
B
So
we
could
do
something
else,
which
is
we
could
write
a
document
that
essentially
provides
a
bit
more
of
an
overview.
So
it's
of
the
documents
that
we
are
now
producing
and
I'm
sorry
if
I
forgot
a
document,
a
box
on
the
right
other.
There
may
be
another
document
that
I've
I've
misplaced
in
my
brain,
and
it
would
simply
say
you
do
that.
This
is
how
you
do
this.
This
is
how
this
part
fits
together.
This
is
how
this
part
fits
together.
B
It
would
point
back
to
6550
for
things
it
would
clarify
parts
of
6550,
so
this
would
essentially
be
a
uber
update,
6550
and
would
pull
in
all
the
other
other
pieces.
B
That
way,
and
so
we'd
have
a
document.
That
would
be
basically
the
start
here
document
for
for
ripple
and
but
it
wouldn't
necessarily
have
to
repeat
much
of
6550.
B
It
could
repeat
some
of
it
if
it
wanted
to
if
it
made
sense
editorially,
but
it
would
explain
how
the
different
pieces
go
together
and
what
it
means
to
have
ripple
implementation,
that
we
would
call
code
v2
and
the
the
the
the
part
of
of
the
whole
doing.
B
This
is
that
I
actually
don't
think
that
we're
actually
going
to
have
a
anything
that
we
call
v2,
but
rather
we're
going
to
say:
if
you
do
this
set
of
things,
and
you
have
implement
this
set
of
capabilities
and
you
can
discover
certain
things
then,
then
you
have
an
implementation
that
can
reasonably
expand
and
do
new
things
as
we
come
along.
We
won't
have
to
do
the
whole.
B
You
know
obsoleting
this
or
that
or
whatever,
and
this
is
something
that
would
really
be
a
mop,
equals
seven
kind
of
event
and
carson
says
in
the
channel:
it's
a
no-brainer.
This
is
what
you
want
to
do
and
of
course,
that's
because
engineers
always
present
the
best
option.
Last
right
and
marketing
people
put
the
best
option.
First,
that
way
so
discussion
pascal
go
ahead.
That's
the
last
slide.
C
Yes,
obviously,
that's
very
tempting
now
there's
kind
of
a
merge
of
those
two
which
is
do
the
internet
standard
based
on
6550
53
54
and
the
b8
138,
which
are
the
which
are
the
one
for
which
we
we
have
lasting
existence
and
then
and
call
that
ripple,
v1
internet
standard
and
then
build
the
v2
profile,
but
not
pointing
on.
Do
these
downloads,
pointing
on
the
internet
standard
for
6550
and
then
all
the
new
stuff.
B
So
we
would,
we
would
roll
a
few
of
the
documents
over
cutting
out
the
stuff.
We
don't
do,
but
not
all
of
them,
and
it
would
be
a
relatively
light
editing
editorial
process
of
mostly
removing
content
and
docum
or
documenting
for
ourselves
at
least
we
as
to
which
parts
have
really
interoperated.
Where
and
clarifying
when
there
was
a
problem.
What
happened?
That's
what
you're
saying
yes.
C
Yeah,
I
think
user
3.4
would
be
merged
into
it,
because
it's
really
about
the
the
existing
but
unaware,
if
would
be
out,
for
instance,
I
guess
now
that
would
be
the
discussion,
but
basically
still
provide
the
cleaned
up
version
of
650.
B
B
I
I
I
would
have
to
be
convinced
that
there
was
a
a
strong
interest
from
a
wide
variety
of
industrial
players
that
run
ripple,
but
don't
seem
to
come
to
our
meetings
that
often
that
this
was
a
valuable
thing
to
them.
B
Some
people
might
feel
well.
It
should
be
really
hard
to
to
do
implement
ripples
so
that
people
will
buy
my
product
instead,
but
I
don't
feel
that
way,
so
I
mean
given,
given
all
the
resources.
I
like
what
your
your
plan,
I
just
not
sure
that
we
would
have
anything
left
to
do
anything
else.
At
that
point,.
C
I
don't
know
I
I
mean
it's
not
much
harder
to
fix,
I
mean
just
say
you
just
fix
50
65.50,
removing
the
stuff.
You
don't
want
and
clarifying
the
things
which
are
not
clear,
yeah
just
that
piece
alone
is
not
humongous
and
it's
pretty
much
the
same
effort
as
writing.
The
the
profile
and
saying
do
this
and
don't
do
that.
Just
editing
it
in
in
the
original
document.
B
C
B
B
That
part
of
it
is
very
good
and,
having
done
that
part,
we
we
would,
we
would
reuse
it
anyway
for
ripple
v2
right,
yep,
okay,
so
we
would
now
have
a
have
a
document
that
would
be
much
much
cleaner
to
be
able
to
pull
some
of
the
other
pieces
into
it
now
alvaro.
Could
you
clarify
for
me?
If,
if
could
we
could
we
write
a
document
that
does
something
and
say
doesn't
change
unaware
leaves
at
all,
but
just
changes
its
status,
because
it's
now
interoperable
two
years
later.
B
Well,
let's
so,
let's
let's
say
we
publish
unaware,
leaves
and
and
use
of
rpl
info,
it's
rfc
blah
blah
blah
right
and
two
years
later,
there's
no
clarifications
needed
and
the
ripple.
B
V2
profile
comes
along
and
says,
and
it
depends
upon
these
other
other
documents
which
are
currently
at
internet
at
proposed
standard.
But
now
we've
shown
interoperability.
Can
we
do
a
status
change
up
to
propose
up
to
internet
standard
without
revising
the
document.
B
F
I
remember
right
so
I've
never
seen
that
done
because,
usually
you
know
there
are
some
changes
when
we're
going
to
entire
standard
and-
and
we
need
to
take
some
stuff
out
and
all
this
stuff.
F
F
B
F
B
You
know
everything
the
reason
we
never
used.
It
is
because
it
wasn't
well
designed
to
begin
with.
It
wasn't
well
explained
and
there's
and
there's
a
bunch
of
pieces
that
that
there's
a
bunch
of
pieces
that
could
never
work
regardless
of
how
fast,
regardless
of
what
magic,
crypto
fairy
dust
you
insert
right,
but
there's
some
stuff
that
was
that
was
undesirable
because
in
2010
it
was
just
too
slow.
You
couldn't
do
asynchronous
signing
of
of
dios
fast
enough
and
and
low
powered
enough
to
be
useful.
B
That
might
not
be
true
anymore
today,
and
we
certainly
see
lots
of
cases
where
people
ask
about
security
in
the
routing
protocol,
which
is
solvable
using
the
pieces
that
are
there
so
like.
I
would
rip
out
a
bunch
of
stuff.
I
would
absolutely
rip
out
all
the
symmetric,
crypto
authentication,
because
it's
meaningless
right.
Anyone
who
can
verify
the
anyone
who
can
verify
your
announcement
with
a
symmetric
key
can
forge
your
stuff.
B
So
what's
the
point
right
so,
but
the
asymmetric
stuff,
you
know
this
working
group
just
never
really
understood
that
it
had
to
be
asymmetric
and
we're
kind
of
being
sold
bait
and
switch.
I
think-
and
so
I
think
we're
the
isg
at
the
time.
So
what
would
we
do?
No
one's
implemented
it
so
that
stuff
can't
go
to
internet
standard
because
no
one's
implemented
it.
We
don't
have
interoperability
at
all.
F
Right
right,
so,
my
point
is
that
that,
at
some
point
some
security
id
is
going
to
ask
well
what
about
security
and
for
many
of
the
writing
protocols,
we've
sort
of
gotten
away
with
you
know
this
is
sort
of
a
limited
domain.
It's
inside.
You
know
this
thing.
If
you
can
get
into
my
network
and
look
at
my
routing
packets,
I
got
other
problems
right.
I
have
other
problems.
We
have
largely
gotten
away
with
that.
F
B
And
all
our
whole
whole
role,
security
threats
document
right,
explained
all
the
different
places
where
you
can
get
in
or
where
you
need
to
be
in
or
out
or
this
or
not,
and
we
went
on
the
applicability
documents
that
you
know
did
when
I
was
chair
were
partly
was
to
deal
with
that.
Make
everyone
happy
about
that
part.
But
you're.
Absolutely
right.
I
mean
you
know.
B
Stephen
farrell
was
never
happy
with
that
result
right,
and
neither
was
I
okay,
but
I
mean
people
haven't
implemented
it.
So
honestly
it
can't
go
to
internet
standard.
Of
course
we
don't
have
to.
We
don't
have
to
obsolete
the
the
code
points
right.
We
don't
have
to
say
that
6550
we
don't
have
to
rip
it
up
and
never
let
anyone
read
it
again.
B
Someone
could
come
along
and
implement
those
things
using
the
code
points
find
interoperability
and
then
you
know
we
have
to
do
something
in
a
document
to
advance
that
part
to
internet
standard,
but
that
would
be
a
new
document
right
right.
F
C
Can
I
yeah
we've
been
through
security
sections
of
many
documents
for
raw
since
right
and
we
have
kind
of
written
the
same
words
about
layer,
two
security.
But
it's
not
really.
C
The
one
thing
I
have
in
mind
is
that
there
is
some
a
lot
of
work
which
is
actually
be
done
to
secure
the
router
to
router
a
posture,
evaluation
and
they're
thinking
about
rats
and
I'm
thinking
about
an
email
and
those
things
are
not
dependent
on
exactly
which
routing
protocol
you're
using
it's.
They
just
prove
that
you're
talking
to
this
guy
with
this
identity
and
and
that
this
guy
is
not
compromised
and
blah,
and
that
establishes
a
degree
of
trust
that
you've
got
the
right
person
with
the
right
software
in
it.
C
And
if,
if
you
want
this
kind
of
security,
then
you
can
deploy
rats,
you
can
deploy
an
email
and
then
run
ripple
over
it.
It's
just
that
trying
to
to
put
that
degree
of
security
into
ripple
binds
things
together
in
a
way
that
I
would
not
want,
because
really,
the
degree
of
of,
for
instance,
rat
that
you
want
into
this
network
may
depend
on
your
use
case
and
tying
it
hard
coded
into
the
routing
protocol,
locks
it
to
a
certain
quality
and
locks
it
to
a
certain
capability.
B
I
I
think,
you're
absolutely
right
that
that
there's
a
space
there's
a
space
of
of
security,
of
that,
as
you
just
described
with
using
remote
attestation
with
doing
good
enrollment
before
you
hand
out
the
layer,
two
network
key.
That
all
makes
a
lot
of
sense
sense
to
me
and-
and
it
should
be
done
anyway,
but
the
stuff
we
never
used
part.
C
That
was
never
proven.
Actually
you
know
in
in
six
japan
we
have
just
produced
rfc
eight
nine
28,
which
provides
a
proof
of
ownership,
for
the
addresses
that
you
expose
over
6,
leopard
nd
and
with
noah
leaves.
We
are
actually
transporting
that
proof
of
ownership
inside
the
dios
and
now
that
can
effectively
be
used
to
provide
fraud,
ownership
validation,
but
the
existing
dao
would
not
do
that,
because
you
could
always
write
anything
into
your
dao.
You
prove
that
you're
sending
it
but
you've
never
proven
that
what
you're
sending
is
correct.
C
B
Yeah
you
need
to
secure
down
and
and
most
of
the
most
of
the
the
secure,
the
hex
eight
something
versions
of
those
things
they
weren't.
They
didn't
really
get
it
right
right,
and
that
was
part
of
the
debate
back
in
2012
or
something
like
this
and.
B
All
I'm
saying
is
no
and
no
one's
implemented
it
right,
so
I
think
we
could
do
a
better
job
if
we
started
over
the
the
question,
is
you
know
what
what
what
level
of
of
security
do
we
want
right?
So.
C
Yes,
tying
to
too
much
stuff,
which
is
not
related
to
ripple
into
this
spec
makes
no
sense
to
me
better.
You
know,
deploy
this
pack
plus
this
pack,
plus
this
pack
like
rats.
If
we,
if
we
need
something
special
to
prove
ownership
of
the
addresses
that
we
expose,
so
we
are
sure
that
those
guys
are
really
down
there.
C
Then
that's
when
we
can
effectively
modify
ripple
and
and
replace
this,
this
section
that
we
are
taking
off
by
a
new
rfc.
C
I
would
not
put
it
in
six
five
five
zero
base,
because
it
would
not
be
instant
standard
anymore,
but
I
would
probably
try
a
new
draft,
which
explains
how
the
rover
can
be
challenged
from
from
a
common
parent
up
there.
So
when,
when
you
see
it
coming
from
a
new
child,
which
means
the
guy
is
moved,
probably
you
want
to
be
able
to
challenge
that
the
dow
was
injected.
You
know
from
somebody
who
wants
it
wants
the
address.
C
B
Right
so
so,
right
now
we're
just
relying
on
layer,
two
security
to
make
sure
that
no
one
injects
incorrect,
a
bogus
routing
information
into
our
network
right
and
so
so
so.
The
point
of
the
stuff
that
was
there
was
to
be
able
to
validate
those
announcements
at
a
higher
level,
irrespective
of
whether
there's
malware
or
something
that
rats
would
deal
with
on
your
network
right.
B
So
obviously,
if
someone
has
the
layer
two
key
and
it
has
broken
code,
they
can
they're
inside
your
network
and
they
can
see
whatever
they
like.
So
that's
an
issue,
but
people
at
one
point
wanted
to
use
ripple
in
networks
that
where
not
all
the
nodes
were
trusted
the
same
way
or
that
the
network
was
not
encrypted
or
the
network
was
open
in
the
sense
of
open,
wi-fi
kind
of
thing
and
new
nodes
could
attach
and
announce
themselves
right
and
they
that
would
work
without
them
attacking
other
things.
B
In
essence,
to
bring
it
to
mailing
list,
I
would
agree.
I
I
think
that
I
I
I
think
we
need
to
figure
out
essentially.
In
some
sense,
we
need
to
figure
out
what
our
resources
are.
There
are
humans
that
are
willing
to
do
this.
I
think
that
that
well,
this
is
a
this,
perhaps
the
smallest
document
and
probably
when
we
can't
really
start
until
we,
we
can't
really
truly
start
until
we've
kind
of
gotten
some
of
these
other
things.
B
At
least
you
know
to
working
group
last
call,
maybe
not
all
of
them,
but
I
mean
at
least
some
of
them
are
in
the
queue
already,
but
we
need
to
figure
out
who's
willing
to
do
that.
Write
that
document,
even
if
it's
much
simpler
than
the
others,
others
or,
if
the
other
two
possibly
larger
documents
that
may
have
to
get
written.
A
So
in
this
suggests
to
write
and
describe
the
various
options
and
the
pros
and
cons
and
discuss
that
on
a
mailing
list.
Is
that
something
reasonable,
or
can
we
get
rid
of
one
of
the
options
right
now
based
on
the
discussion?
So
we
have
this
editorial
work
to
investigate
or
explain
each
of
the
options.
C
C
The
v2
can
can
really
bring
new
functionality.
The
base
is
more
like
fixing
bugs
if
we
agree
on
the
terminology
like
this,
it's
it's
kind
of
easier,
because
we've
seen
many
beasts
in
the
past
and
they
were
like
that.
I
mean
48.
61
is
the
beast
of
2461..
C
C
E
A
B
At
some
point,
we're
going
to
need
to
do
this,
but
you
know
it
may
be
a
6550
v2bis,
but
maybe
not
for
a
long
time,
and
you
know
we
may
discover
that
you
know
if
somebody
has
a
interest
in
a
resource
and
and
time
that
is
not
at
this
meeting
right
now
and
you
know
some
strategic,
you
know
next
generation
internet
grant
or
something
like
that
could
fund
such
a
thing
and
someone
could
do
some
interesting
work
that
way,
but
I
I
would
agree
that
it's
probably
unlikely
that
we'll
get
we'll
manage
to
do
this
so.
C
B
Probably
not
a
bad
idea
for
to
obtain
that
xml
from
the
rfc
editor
it's
available.
If
you
ask
nicely
and
throw
it
in
make
sure
that
it
compiles
and
we,
if
nothing
else,
we
may
want
to
copy
and
paste
from
it
for
other
things.
So
might
as
well.
Have
the
original
text
in
the
original
formatting.
C
No,
I
pressed
the
wrong
button.
I
wanted
to
remove
my
camera
uis.
A
Okay,
so
we'll
bring
that
to
me
and
just
describe
the
options
and
let's
see
who's
willing
and
available
for
the
various
options.
I
think
that
the
best
we
can
do
at
this
point.
A
B
C
B
The
if
we
were
to
do
that
you're
talking
about
doing
the
the
going
to
internet
standard.
B
Yeah,
so
so
I
I
I
would
like
to
discuss
how
much
like.
Maybe
we
don't
need
the
whole
document
when
we
go
to
internet
standard,
maybe
we
only
need
the
part
we
don't.
Maybe
we
don't
need
all
24
examples
or
any
of
them.
Maybe
maybe
we
only
need
the
the
beginning
parts
that
clarify
the
the
text,
because
the
document
still
exists
as
a
people
can
go
back
and
look
at
it.
So
I
don't
know
I
mean
I
just
don't
want
to
start
reformatting.
That
document
again,
no.
C
B
B
C
B
No,
we
should.
We
should
pull
the
text
that
that's
normative.
That
says
that
gives
you
the
instructions
of
when
and
how
to
use
it,
but
I'm
just
saying
that
we
don't
need
to
necessarily
pull
in
all
24
examples,
because
we
can
certainly
informatively
reference
that
other
document
and
say
if
you
need
more
detail
more
details
are
in
this
document.
Yeah
right.
G
B
A
C
F
B
I
worked
on
rfc
8415
because
the
roll
up
of
dhcb
v6
that
obsoleted
what
seven
documents
over
10
years
I'll
putting
it
into
one
document
and
couldn't
remember
it.
No
it
it
didn't
result
in
an
internet
standard
document.
It's
the
code
standard,
but
I
think
there
was
discussion
at
some
point
that
that
two
years
later
it
could
be
status
changed
up.
B
But
I
I
don't
remember
that
whether
that
was
really
the
case
or
not,
but
anyway
the
the
the
point
is
that's
an
example
of
I
would
say
more
of
the
melting
pot
activity
and
that
one
certainly
took
four
years
to
do
probably
could
have
been
done
in
three,
but
it
took
four
years
to
do.
A
A
A
Rahul
we
have
a
few
minutes.
If
you,
if
you
want,
we
can
put
your
slides
up.
I
went
through
them
very
quickly,
but
you
can
probably
go
through
the
updates
and
stuff
because
I
wasn't
too
sure
so
I
just
skipped
that.
G
So
why
don't
you,
can
you
hear
me
yeah,
peter
sorry,
dominic.
G
I
got
the
timezone
incorrect,
I
was,
we
thought
it
was
1630
utc.
So
if
we
have
how
much
time
do
we
have.
A
You
can
have
10
minutes,
12
minutes,
yeah,
okay,
all
right
and
I
went
through
the
basics.
You
know
the
first
few
slides.
I
don't
know
if
you.
G
So
these
slides
had
been
pre
presented
previously
a
couple
of
iitf
sessions
before
the
primary.
The
primary
rationale
is
to
is
to
is
to
provide
an
end-to-end
way
of
making
sure
that
the
node
nodes
connectivity
has
been
established
to
the
root.
G
Now
the
mechanism
that
has
been
described
in
the
draft
is
about
setting
a
k
flag
in
the
transmitted
transit
information
option
on
per
target
basis.
Such
that
root
would
know
whom
to
send
the
root
ad
back.
G
So
this
particular
slide
talks
about
you
know
how
the
k
flag
is
set
and
at
what
on
at
on
war
and
on
what
basis
the
root
can
decide
to
send
back
the
root
act
earlier
we
were
calling
it
dow
act,
but
then
there
was
a
lot
of
confusion
about
the
the
term
used
there.
So,
in
the
later
version
in
the
la
in
the
last
version
in
in
widget
one,
I
changed
it
to
calling
it
calling
it
as
root.
Add
next
slide,
please.
G
So
again,
this
is
this:
is
the
k
flag
one
one
of
the
discussions
that
happened
in
the
previous
call
was
with
regards
to
handling?
How
would
the
six
lrs
handle
this
k
flag
in
storing
mode
of
operations?
6Lrs
could
aggregate
multiple
taos
together
and
send
an
aggregated
target
to
to
the
upstream
nodes.
G
G
The
draft
has
been
updated
to
explain
the
different
scenarios
in
which
the
k
flag
can
be
handled
by
intermediate
six
and
six
cells
again,
and
the
handling
is
not
very
complicated.
It's
much
very
similar
to
e
flag.
But
then
you
know
what
happens
if
somehow
the
k
flag
is
still
the
intermediate
node
ends
up
sending
a
k
flag
because
the
path
has
changed.
So
all
all
those
things
have
been
mentioned
in
the
draft.
G
In
the
worst
case,
an
additional
root
act
might
be
sent
by
the
root
with
the
old,
with
an
old
path
sequence,
but
that's
the
worst
case
scenario.
G
There
was
one
more
thing
so
when
the
this
particular
draft
was
supposed
to
be
used
for
two
purposes,
one
was
a
root
node
or
any
other
node
could
basically
send
a
root
acknowledgement
to
the
end
node
to
the
target
node.
That
would
signal
that
the
application
traffic
can
now
begin
the
other
option.
The
other
use
case
was
to
query
the
capabilities
of
that
node,
but
then
in
the
latest
draft
in
the
latest
capability
draft
we
have
we,
we
now
have
its
own
messaging,
so
this
this
won't
be
needed
there.
G
So
that
particular
use
case
is
no
more
true
for
this
graph.
Now.
G
Okay,
an
extra
next
slide,
please
so
one
yeah
one
more
other
clarification
that
was
added.
Pascal
raises
raised
a
point
with
regards
to
how
to
handle
rules.
There
was
a
discussion
on
mailing
list
about
how
do
you
handle
rpl
unaware
leaves,
and
this
acknowledgement,
so
this
this
is
something
that
has
been
clarified
in
the
in
the
in
the
draft.
G
Basically,
one
thing
that
that
that
has
been
mentioned
in
the
draft
is:
if
a
ns
is
sent
by
the
rule,
then
then
the
6lr
generates
a
dao
on
basis
of
that
on
the
basis
of
the
rule
and
immediately
sends
an
na
now
that
any
can
be
sent
in
response
to
this
root
acknowledgement.
What
it
achieves
is
what
it
achieves
is
that
you
know
you
can
synchronously
send
only
when
the
end-to-end
path
is
established.
The
na
here
can
be
synchronously
sent.
G
Yeah
next
slide,
please
so
the
the
that,
that's
all
you
know,
those
are
the
major
updates.
There
have
been
major
updates
in
version
one.
There
has
been
implications
for
delay
that
now
been
added
in
the
draft
as
well.
It
just
mentioned
that
what
are
the
delayed
house
and
how
do?
How
do
you
handle
delay
now
timer.
G
A
Sure,
raul,
actually,
before
you
joined,
we
had
a
question
by
alvaro:
I'm
not
and
we're
a
bit
short
answering
it.
Why
don't
we
just
cascade
the
dows
up
and
the
dialogues
back
all
the
way
to
a
root?
This
was
discussed
a
few
years
ago
and
it
was
found
that
this
doesn't
work.
But
since
it's
probably
fresher
in
your
mind
than
it
knows,
can
you
go
through
that
again?
Yeah
yeah.
G
So
there
are
several
approaches
to
you
know
you
ensuring
this
end-to-end
dao
act
works
so
in
the
rpl
observations
draft
we
had,
we
had
talked
about
what
are
the
downsides
of
doing
this,
for
example,
one
one
of
the
point
that
usually
gets
raised
is,
if
d
sends
a
tao
b,
sends
a
dow
act
back
only
when
it
receives
dawah
back
from
a
this.
Has
certain
state
state
implications
again?
If
a
in
the
rpl
observations
draft,
we
have
given
a
detailed
problem
statement
about
what
are
the
problems
with
this
particular
approach?
G
Maybe
I
should
replicate
those
observations,
even
in
this
particular
draft
as
to
what
are
the
implications
on
state
handling
why
it
becomes
complicated
all
these
things.
You
know
again
those
those
observations
I
had
presented
in
several
sessions
in
several
idf
sessions
before
in
context
to
rpl
observations.
You
know
draft,
so
the
primary
one
of
the
primary
reason
is
the
state
handling
that
is
required
on
the
intermediate
6
lr's.
G
To
to
keep
that
dow
act
and
that
that's
one
of
the
major
problem,
what
happens
if
yeah
again,
you
know
that
there
are
two
or
three
reasons,
different
reasons
which
are
coated
in
the
actual
observations.
A
Okay,
fair
enough,
I
I
had
an
observation
reading
your
draft.
Since
we
have
a
few
minutes
you,
the
requirements.
Section
says
you
want
to
be
able
to
handle
gios
with
prefixes
target
options
with
prefixes.
A
G
Yeah
yeah,
so
for
the
for
the
prefixes.
What
we
are
saying
is
that,
if,
if
a
node,
we
are
taking
an
approach
where,
even
if
even
if
the
6lr
is
advertising
a
prefix,
it
should
still
send
the
full
ip
address
of
its
interface,
including
the
prefix.
We
take
the
same
approach
which
is
taken
for
sending.
G
But,
but
still
send
all
the
128
bits
this
I
need
to
clarify
in
the
draft
the
there
was
one
option
that
was
described
to
handle
this
particular
scenario,
but
I
I
guess
I
haven't
still
made
make
changes
in
the
draft
to
I
haven't
made
any
changes.
Detailed
changes
in
that
I
have
to
explain
this
scenario,
but
there
is
a
way
to
handle
the
prefixes
as
well.
G
I
guess
I'll
have
to
add
this.
This
is
more
detail.
C
In
the
dio,
even
here
and
that's
done,
actually,
we
we've
done
that.
I
think
it's
the
unaware
leaf
draft
that
we
made
this
change.
That's
why
we
update
650.
C
but
the
the
changes
we
put
the
full
address
and
we
have
a
flag,
and
so
I
guess
that
when
you
want
to
send
the
the
root
hack,
you
send
it
to
the
full
address.
So
so
it's
a
prefix.
You
have
a
prefix
length
which
is
not
128,
which
is
shorter,
but
still
you
put
128
bits
because
you
have
the
full
address
of
the
of
the
node.
That's
already
done
like
that
in
mobile
ip.
So
it's
just
like
using
the
same
thing.
I.