►
From YouTube: IETF110-ROLL-20210311-1430
Description
ROLL meeting session at IETF110
2021/03/11 1430
https://datatracker.ietf.org/meeting/110/proceedings/
A
Please
be
aware
that
this
meeting
is
aligned
with
the
note.
Well,
we
are
not
going
to
read
it,
but
you
have
to
follow
in
order
to
attend
this
meeting.
So
please
help
us
with
the
kodi
md.
A
So
today
we're
going
to
discuss
about
capabilities,
style,
projection,
enrollment,
priority
and
mopex
has
was
mentioned
before,
and
ncs
text
extension
was
submitted
to
the
isg
presently
and
the
audv
it's
in
a
still
area.
Evaluation
ripple
observation
is
working
progress
and
this
modification
is
standby,
so
related
internet
draft
for
storing
root
act.
We
had
the
card
for
adoption
issued
january
26,
but
we
have
not
got
any
any
feedback.
A
A
So
our
milestones-
these
are
done.
Turn
off
in
our
leave:
okay,
audible
repair
was
submitted,
but
there
still
is
a
correcting
feedback
and
use
of
ripple
info
submitted
in
video
as
well,
and
then
we
have,
the
toastmasters
is
still
active,
probably
yeah.
We
will
have
to
update
the
dates
here.
A
And
the
tickets
we
have
mainly
the
tickets-
are
in
github
for
ripple
observations,
though,
projections
efficient,
routing
validation
and
capabilities,
but
that's
where
we
keep
some
track
in
the
old
system
for
odb
ripple,
maybe
mainly
under
the
projection.
But
the
adult
projection
are
a
move
to
the
cheat
hub.
A
B
Okay,
I'm
sorry
there
was
double
mute
on
my
pc
and
maybe
I
can
share
the
video.
I
don't
know
if
people
are
constrained
with
video
today.
So
do
you
want
me
to
share
my
slides?
Oh.
B
Please
go
ahead.
I
will
ask
you
to
switch
right
so
yeah.
So
what
can
I
say
about
this?
There
was
two
important
and
big
changes:
publication
of
the
dow
projection
draft
15
and
16,
and
the
intent
was
to
first
do
things
that
that
we
said
we
would
at
the
previous
atf,
but
also-
and
mostly,
we
wanted
to
simplify
because
it
was
getting
complicated.
I
was
getting
feedback,
that's
complex
and
we
wanted
to
to
make
it
more
streamlined.
B
More
everything
is,
is
the
same
and
to
do
that,
what
we
did
is
we
realigned
the
operation
of
a
track
to
the
operation
of
the
main,
dag
everything
in
a
track.
Smells
looks
like
a
the
main
dag
in
non-storing
mode,
just
that
it's
a
local
instance
for
a
truck
and
the
global
instance
for
the
main
geodag,
but
otherwise
all
the
concepts
and
and
things
that
you
know
and
how,
in
particular,
you
use
use
of
ripple
info
to
encapsulate,
etc.
B
All
that
you
knew
and
understood
with
the
main
non-storing
geodag
will
apply
to
the
track,
which
is
a
non-storing
instance,
so
that
that's
for
that
we
had
to
do
some
changes
like
we
made.
The
the
root
of
the
track,
the
tracking
grass,
it
used
to
be
the
christ
for
a
number
of
reasons,
but
now
which
so
that
you
have
a
single
destination.
That
was
the
main
reason.
Now
we
turned
it
into
the
root,
is
the
tracking
grass
meaning
that
the
truck
can
lead
from
one
place
to
multiple
place?
B
If
you
really
like
it
too,
just
like
the
main
geodag
or
you
can
make
it
converging
like
one
ingress
and
one
egress
and
multiple
paths
in
between,
if
you
like
as
well,
so
we
imposed
that
the
main
geoduck
is
non-storing
and
the
reason
for
that
is
that
gives
us
an
idea
of
the
topology
using
the
non-storing
signaling,
and
we
also
imposed
that
the
track
itself
is
non-story.
B
So
you
know
who's
the
root.
You
know
all
the
steps,
etc.
In
both
cases
we
can
use
storing
mode
to
install
segments
so
that
the
non-storing
signaling
now
can
be
loose.
So
if
you
want
to
go
from
abcdef,
you
can
have
non-storing,
which
which
have
a
sorcerer
together,
which
says
a
d
f
and
have
source
routed
segments
which
are
bcd
and
def.
B
If
you
like
it
that
way,
so
that
makes
it
so
that
you
have
the
best
of
both
worlds,
some
state,
but
not
too
much
and
the
root
can
control.
How
much
that
you
get
installed
in
the
nodes
and
then
a
loose
routing
editor
so
that
the
size
of
the
packet
doesn't
grow
too
big.
B
Now
you'll
find
there
is
an
exception
when
it
would
be
kind
of
silly
to
have
a
non-storing
track
with
just
one
segment
in
it,
then
the
segment
implicitly
defines
the
track,
but
otherwise
we
have
a
strict
naming
and
convention
that
a
truck
is
a
non-stirring
deodag
and
the
segment
is
a
strict
sequence
of
nodes
that
you
can
have
between
loose
hops
in
the
track,
and
you
can
apply
that
to
the
main
geodag
and
you
can
apply
that
notion
of
segment
to
a
track
as
well.
So
everything
has
been
simplified
to
a
single
model.
B
You
have
basically
a
skeleton
in
non-storing
mode.
That
can
be
the
main
geoduck
that
can
be
the
track
and
the
skeleton
can
now
be
loose,
meaning
that
you
don't
have
to
have
the
strict
list
list
of
hops,
because
between
two
loose
hops
you
can
have
a
storing
mode
segment.
B
Now
you
could,
if
you
really
wanted
to
also
have
this
loose
hop
signaled
as
another
track,
which
means
that
when
you
are
inside
the
loose
hub,
you
encapsulate
in
another
track,
so
you
have
source
routing
inside
source
routing,
if
you
really
wanted
to.
You
could
do
that,
but
the
the
more
attractive
model
is
when
the
skeleton
on
the
loose
structure
is
non-stirring
and
just
when
you
want
to
save
you
have
storing
mod
segments
and
another
thing
that
we
did
to
simplify.
B
The
draft
is
that
we
will
see
that
later,
but
we
split
the
possible
things
you
can
implement
in
six
mo
six
modes,
basically
just
like
in
the
main
repo
we
have
story
mode,
non-storing,
etc.
We
we
actually
split
the
power
projection
support
in
six
profiles.
B
You
will
see
that
they
all
inherit
from
this
same
overall
design
that
the
track
is
a
non-stirring
loose
thing
and
the
segments
join.
The
loose
hops
of
the
track
using
storing
mode
this
is
this
is
pervading,
but
you
can
actually
build
different
things
as
I
said,
and
we
made
that
different
mode.
So
if
you
have
a,
for
instance,
nixon
start
body
like
not
thread
because
they're
not
using
ripple
but
maybe
ysun
or
weather,
wants
to
use
repo
in
just
a
certain
one
specific
of
those
modes.
B
Then
they
will
have
the
clear
explanation
in
the
draft
and
how
this
mode
works,
how
you
do
the
encapsulation
etc.
So
we
did
a
lot
of
most
big
addition,
also
giving
an
example
for
each
mode
of
how
the
packet
gets
encapsulated,
how
the
track
gets,
signaled,
etc.
So
now
you
know
exactly
how
you
do
things
next
slide.
Please.
B
Okay,
another
thing
that
happened
is
we
found
that
it
was
probably
useful
when
you're
forwarding
a
packet
and
that's
from
an
early
implementation,
that
a
group
at
cisco
did
we
found
that
it
could
be
useful
to
signal
in
the
packet
that
it's
being
forwarded
along
a
period.
It's
already
clear
that
it's
being
forwarded
along
a
local
ripple
instance,
because
the
ripple
instance
id
has
one
bit
which
says
it's
a
local
risk
instance.
B
But
they
thought
that
you
know
for
the
code
path.
It
was
more
clear
to
signal
as
well
that
the
packet
is
following
a
projected
route.
So
we
said
hey.
There
is
a
free
bit
in
the
hop
by
hub
header
in
the
non-compressed
format.
So,
let's,
let's
use
it
to
signal
that
we
are
following
a
pure
out,
but
something
we
discussed
on
the
mailing
list.
B
But
then
that
causes
another
prime,
which
is
that
8138,
the
compression
of
ripple
signaling
for
the
data
path
that
did
not
have
room
for
this
extra
bit
and
actually
what
it
had
room
for
things.
We
don't
need
like
the
loop
avoidance
mechanism,
which
is
not
used
here,
because
you
signal
the
path.
B
So
what
we
did
in
this
draft
is
create
a
new
six
lower
range
which,
when
you
you
forward
along
the
track,
the
suggestion
is,
do
not
use
the
normal
rpi
six
leverage
but
use
the
projected
rpi
six
leverage,
and
for
this
projected
rpi
six
rh.
We
provided
both
an
elective
and
a
non-elective
form.
So
if
you
have
a
source
route
either
way
you
can
live
without
completely.
B
No,
not
knowing
that
it's
a
peer
route,
then
you
can
still
put
the
the
prpi
into
into
the
packet
and
a
node
which
doesn't
understand
it,
but
doesn't
need
to
know
would
know
that
it
can
skip
it
because
it's
an
elective.
B
But
if
you,
if
you,
if
your
operation
depends
on
the
fact
that
every
node
understands
the
projected
route,
then
you
use
the
non-negative
form
and,
and
then,
if
a
node
in
the
way
does
not
understand
the
period,
then
it
will
actually
drop
the
packet
next
slide.
Please.
B
Okay,
so
we
kind
of
simplified
as
well
the
rules
for
the
projected
dial
construction,
because
you
could
add
you
have
a
lot
of
elasticity
in
whether
you
have
one
or
more
targets,
one
or
more
transit
and
actually
the
transit
in
in
the
pdaw
is
not
the
tio
as
you
knew
it.
It's
the
vio.
B
If
you
remember
what
a
transit
information
is
it's
basically
how
you
signal
your
parent
in
non-storing
mode,
with
a
little
bit
more
information
like
lifetimes.
But
here
you
don't
signal
a
parent.
You
signal
a
full
path,
but
you
still
can
think
of
a
pidao
as
a
dao
where,
instead
of
having
a
tio
for
signaling,
just
a
parrot,
you
have
a
vio
for
signaling
a
full
path.
B
The
target
is
still
the
same.
That's
where
you
go
so
the
vio
is
the
via
how
you
get
there
and
the
target
option
is
where
you're
going
as
it
was
before.
Like
I
said,
we
are
trying
to
make
it
very,
very
homogeneous
between
what
we
are
doing
in
pidao
and
what
you
already
knew
in
non-storing
mode.
A
track
is
just
one
other
non-storing
mode.
B
Do
that
another
simplification
that
we
made
is
in
the
naming
instead
of
having
this
root
projection
option
this
rpo
concept,
which
was
yet
another
acronym
to
live
with.
We
said
no,
no,
no!
Let's,
let's
get
rid
of
that.
Let's
just
say
we
have
this:
the
stateful
vio
for
storing
mode,
and
we
have
the
source
routing
vio
for
non-storing
mode.
B
Like
I
said
earlier,
the
non-storing
mode
signals
the
skeleton
of
the
track,
the
structure
of
it
from
where
you
go,
where
you're
going
and
if
you
have
segments
in
between
that
are
loose,
then
you
use
sfvios
state
four
vios
to
set
a
state
in
every
node
along
that
segment
and
by
the
way,
the
track
id
etc
in
the
sfvio.
For
that
segment
of
that
track
will
have
the
same
track
id
into
it
as
the
main
skeleton.
So
you
can
relate
the
segment
with
the
main
skeleton.
B
Oh
there
is
a
typo
here,
it's
not
taken
from
the
tracking
grass
it's
taken
from
the
track
ingress.
Sorry
for
that.
So
like
I
said
to
simplify
implementation
and
documentation
and
also
standards
which
would
import
just
one
profile.
We
split.
We
described
six
profiles,
we
choose
the
same
basic
structures,
but
use
them
differently.
So
if
you
need
to
do
this,
then
you
will
apply
profile
blood.
If
you
need
to
do
that,
then
you
will
pick
another
profile.
B
And
also
like,
I
said
earlier,
but
they
insist
on
it.
Everything
new
about
use
of
ripple
info
applies,
meaning
that
if
the
packet
is
coming
from
the
outside
of
the
track
and
needs
to
be
transported
in
the
track,
like
think
about
earth
it
like
if
it
was
a
tunnel,
it's
it's
more
than
a
tunnel,
but
you
could
think
about
it
as
a
tunnel
for
a
while.
B
Then
any
packet
which
is
coming
from
the
outside
has
to
be
encapsulated
same
thing,
any
packet,
which
is
trust
traversing
the
track,
may
be
injected
by
the
root
or
nj
or
coming
from
the
outside,
and
that
is
to
be
delivered
to
a
node
which
is
outside
the
track,
like
the
target
in
the
tio
is
a
neighbor
of
the
egress.
But
it's
not
the
aggressor
itself.
It's
one
of
its
neighbors.
B
So
you
need
to
think
we
are
building
a
geoduck
with
the
projected
route
inside
the
main
geoduck,
but
it's
still
a
deodag
everything
that
is
in
the
main
geodag,
but
not
inside.
This
smaller
geoduck
is
external
to
this
small
diode,
so
it
has
to
be
processed
like
a
ripple
and
a
wall
if
you
like,
like
any
external
destination,
it's
not
part
of
this
track,
it's
an
external
destination.
B
So
yes,
when
we
encapsulate
the
source
of
the
autorider,
is
the
tracking
grass
so
think
of
it.
As
a
packet
coming
from
the
internet
and
being
transported
over
a
ripple
domain,
we
the
route,
has
to
encapsulate
it
same
thing,
but
here
it's
going
to
be
source,
the
deodor
group,
so
the
ingress
of
the
track
rpi,
the
the
local
instance
id
for
for
this
particular
track,
and
it
can
be
compressed
with
the
prpi
six
leverage
and
the
destination
whatever.
B
B
We
also
made
this
change,
and
I
also
already
introduced
that
at
the
interim,
but
it's
good
to
say
to
the
more
global
instance
global
population,
the
we
we
encode,
the
srvio
in
the
dow,
exactly
like
it
will
be
in
the
packet
if
you
are
using
8138.
B
That
means
that
the
node,
which
will
place
that
in
the
packet
to
do
the
encapsulation,
will
do
a
strict
copy
from
what
it
got
from
the
root
into
the
packet
and
that's
important,
because
using
the
compressed
form
is
easy
computing.
The
best
way
you
do,
the
compressed
form
is
a
bit
more
complex.
It's
something
that
the
root
already
does.
B
If
you
implement
8138
the
root
already
does
this
compression,
but
now
since
it
knows
how
to
do
it,
we
decided
to
to
just
let
the
root
always
do
it
and
put
the
compressed
form
verbatim
into
the
the
pidao.
So
so
the
now
the
local
route,
the
track
ingress.
We
just
picked
from
the
dao,
the
source,
routing,
six
lower
range
and
copied
verbatim.
B
Also,
an
important
thing,
which
was
there
from
the
very
beginning
of
this
e40,
is
when
you
use
a
stat
for
vio,
so
so
the
the
non-stop
the
storing
mode,
I'm
sorry
one
intent
is
to
use
it
in
the
main
geodag.
So
for
specific
path
in
the
main
geodag,
you
can
actually
use
storing
mode
just
there
to
make
the
source
routing
editor
smaller
right,
because
you
don't
have
to
to
have
the
strict
list
of
hopes.
But
now
you
can
have
a
loose
list
of
hopes
now
to
to
to
to
be
very
clear
on.
B
This
is
a
segment
which
applies
to
this
track,
or
this
is
a
segment
which
applies
to
the
main
geodag.
Then
the
p
dial
for
the
segment
has
the
same
track
id
information
which
could
be
the
main
geode
actually
as
the
source
routing
thing.
So
you
can
really
say.
Oh,
I
have
this
loose
packet
going
down
this
this
either
main
geodag
or
going
along
a
track.
B
Let
me
find
if
I
have
a
segment
expressed
in
storing
mode
which
actually
has
the
same
track:
id
information
main
diode
or
this
track,
and
if
I
have
that,
then
I
can
forward
to
the
next
loose
hop
using
this
segment.
So
you
have
to
do
this
matching
of
the
loose
source,
routing
and
the
segment
in
storing
mode
that
goes
between
the
loose
hops.
B
Now
there
was
a
question
on
the
mailing
list:
could
we
have
a
track
in
which
we
inject
not
all
the
packets
for
the
target,
but
only
a
subset
of
the
packet
with
some
flow
information
like
if
you
know
it's,
this
flow
flow
label
or
this
five
top
or
anything
like
this?
So
the
the
question
is
still
open.
I
mean
I've
not
seen
much
expression
of
the
need
for
doing
this.
B
Now,
I'm
not
very
clear
if
it
has
to
be
something
which
is
specific
to
ripple
and
that
we
have
to
indicate
their
own
rfcs
or
if
it's
just
something
that
will,
when
you
deploy
a
protocol,
a
global
thing
like
ysun
that
incorporates
3.6
lapad
and
many
other
things.
Maybe
they
could
say?
Oh
basically,
you
need
to
have
a
match
and-
and
you
could
use
a
segment
routing
policy
or
something
like
that,
and
then
we
don't
need
to
define
anything.
B
B
B
Okay,
thank
you
dominique,
so
yeah.
I
already
presented
the
slides
at
the
interim,
but
it's
worth
I
guess
it's
worth,
showing
them
again
to
the
wider
audience
and
and
even
for
those
who
already
saw
them.
Probably
it's
not
fully
obvious
how
things
are
done.
B
B
One
is
actually
the
one
thing
that
I
promised
we
would
be
doing
when
I
suggested
this
work
to
the
to
the
royal
working
group
and
the
idea
was
not
to
build
track
at
all.
B
The
idea
was
just
in
the
main,
non-storing
deodag,
to
enable
a
hybrid,
storing,
non-stirring
world,
where,
if
the
root
knows
how
much
state
can
be
used
for
rotting
in
the
in
the
nodes,
then
it
could
actually
go
and
program
the
nodes
for
just
at
the
maximum
that
amount
of
state,
but
no
more
and
use
that
at
the
best
possible
place
to
save
source
routing
headers
so
to
save
bandwidth
and
frame
size
in
the
packets.
B
So,
for
instance,
if
you
have
a
very
long
line
to
get
somewhere,
you
want
to
express
it
as
a
loose
hub
in
the
source
rotator.
But
then
you,
along
this
long
line
you
want.
You
have
to
install
a
storing
mode
wrapped,
which
will
enable
to
to
join
the
loose
hops.
B
In
this
example,
I
have
two
such
loose
hops.
One
is
a
to
c.
We
want
to
save
the
signaling
of
b,
and
then
we
have
c
d
e
f.
We
want
to
save
the
signaling
of
d,
okay,
and
we
could
also
well
you
will
you'll
see
there
are
little
alternates,
whether
you
want
the
destination
to
be
the
track,
egress
or
the
destination
to
be
a
neighbor
just
after
the
track
egress.
So
so,
and
actually
I
show
in
this
diagram,
I
show
both
cases.
B
I
guess
I
do
okay.
So
the
first
thing
that
that
we
have
to
do
is
build
this
track,
but
in
profile
one
the
track
is
the
main
geodag
profile
one.
You
don't
have
the
concept
of
a
shorter
path
inside
the
geodag
using
a
track.
It's
just.
We
have
the
main
geodag
we
have.
We
have
all
this
graph
that
that
that
may
have
those
long
lines,
and
we
basically
want
to
do
some
compression
here
and
there
by
hybriding
and
with
some
story
mode
and
so
to
do
this.
B
In
this
example,
we
need
two
p
dials
p,
o
one
and
p
d,
o
two
p
d,
o
one
enables
the
compression
of
the
cde
path.
B
Okay,
so
it
can
be
now
just
a
loose,
hop
c
e
and
we
also
want
to
compress
abc
and
just
signal
ac
in
the
packet.
So
now
the
the
source,
rod
header
from
the
root
to
f
would
be
basically
signaling,
a
c
e
and
finally
f,
which
could
be
in
the
inner
packet,
which
could
be
anywhere,
but
it
really
depends
on
what
you're
sending.
But
basically
the
important
thing
I
want
to
say
is
the
loose
information.
Now
in
the
srh
is
a
c
e.
B
We
have
skipped
b,
we
have
skip
d,
and
that
could
be
many
more
right.
You
don't
have
to
skip
any
one
half
you
can
skip
five
of
them.
If
you
want
to-
and
we
do
that
two
times,
we
don't
necessarily
do
that.
As
a
single
line.
You
see
we
skip
b
separately
from
skipping
d,
which
means
that
if
you
have
a
b
c
c
d,
e
and
c
d,
prime
e
prime,
the
compression
of
b
doesn't
have
to
be
done
twice.
I
mean
the
the
hop
abc
has
been
compressed
with
pdo2.
B
It
works
wherever
you
go
from
from
c
right.
So
that's
that's
one
good
reason
for
doing
it
in
two
shots,
so
pdl1
is
sent
by
the
root
to
remember.
We
send
the
pdaw
in
storing
mode
to
the
exit,
so
we
send
it
to
the
egress,
which
is
e,
so
p
r1
flies
to
e
and
it
it
the
target
of
e
doesn't
signal
in
this.
In
this
example,
it
doesn't
signal
any
other
target.
B
B
So
basically
the
svio
says
cde
so
d
will
e
will
pass
it
to
d
d,
will
pass
it
to
c
all
of
them
along
the
path
will
set
up
a
route
to
the
target,
so
c
and
d
will
have
a
route
to
e
okay
and
the
the
interesting
thing
that
we've
built
here
is
really
c
having
a
route
to
d
to
evrd.
B
You
will
find
the
draft,
so
it's
all
explained
with
tables
and
all
you
will
see
who
installs
what,
because
you
have
the
neighbor
entries
and
you
have
the
the
routing
entries.
So
the
only
routing
entries
that
is
really
set
by
this
pw1
is
c
now
as
a
route
to
e
via
d,
okay,
and
so,
when
the
pilot
reaches
c,
it
installs
that
route
and
it
sends
the
the
pidawak
to
the
root.
So
now
the
root
knows
that
c
knows
how
to
get
to
e
without
signaling
the
segment.
B
The
source
routing
either
same
thing
for
b,
but
you
see
that
I
could
have
set
the
p
down.
1
to
c
c
would
have
done,
would
have
terminated
the
the
first
sequence
and
and
started
the
second,
but
we
can
also-
and
which
is.
This
is
what
I
do
here.
We
could
also
consider
that
the
segment
ends
at
d
because
b
knows
about
c
being
your
neighbor,
so
you
don't
need
really
to
do
what
I
did
on
the
right,
which
is
send
the
p
dow
to
d
to
e
on
the
right.
B
I
send
the
p
out
to
e,
which
sends
it
to
d,
and
the
only
thing
that
d
learns
from
this
p
pdo
is
that
it
can
reach
evie,
it's
something
it's
really
new,
so
I
just
show
that
it's
possible,
but
probably
the
best
thing
to
do
in
this
case
is
to
send
the
the
pedal.
What
I
do
to
be
to
be
directly
like
1
could
have
been
sent
to
e
p.
02
is
effectively
sent
to
b.
B
So
with
this
b
says:
okay,
the
targets
are
myself
fine
and
c.
Okay,
do
I
have
c
as
a
neighbor?
Yes,
so
this
p
dio
is
valid.
I
can
reach
c.
I
can
reach
myself,
I'm
a
validity
grasp
for
this
segment.
B
What
are
what
is
the
sfvio
a
b
okay?
So
I
need
to
pass
it
to
the
guy
before
me,
which
is
a
so
b
passes
the
p
dao
2
to
to
a
a
looks
at
the
p.
Dao
says:
okay,
what
do
I
see
in
there?
First,
the
targets
are
b
and
c.
Okay.
Let's
let
me
look
at
my
routing
table
b.
I
knew
already
how
to
reach
him
right
he's
my
neighbor,
but
I
can
reach
c
via
b.
Let
me
install
cvrb
in
my
routing
table.
B
So
at
this
point
we
see
as
e
via
d
and
a
as
c
via
b
and
a
is
actually
the
first
in
the
sevier
list,
so
it
it
sends
the
arc
to
the
root.
B
B
Okay,
so
in
this
case
the
track,
as
I
said,
is
the
main
diode
just
same
thing:
it's
just
that
the
main
jag
is
a
global
instance
and
another
track
that
we'll
see
in
the
other
profiles
are
local
instances.
But
it's
exactly
the
same
game.
A
packet
comes
in
the
root.
The
root
has
to
encapsulate
it
for
the
track,
which
is
the
main
geodag.
So
it
will
put
the
rpi
of
the
media,
dag.
It
will
put
a
source
routing
editor,
but
now
it
can
be
compressed
and
the
source
routing.
B
Okay,
so
that's
profile
one
and
that's
what
was
originally
promised
for
the
work
in
in
pidao
next
slide,
please
so
so
the
first
thing
that
that
I
got
as
a
request
from
the
working
group
when
we
started
this
work
is
hey.
Could
you
please
do
the
same
thing
that
expressing
quote
unquote
the
segments
as
non-storing
mode
as
well?
B
B
It
really
means
a
okay,
a
has
a
loose
source,
routing
packet
to
get
to
c,
but
but
it
needs
to
send
it
via
b,
and
so
it
needs
to
encapsulate
it
with
a
routing
error
which
will
express
how
to
get
to
c,
because
now
everything
is
a
routing
editor.
So
it's
you.
You
end
up
with
a
double
encapsulation.
The
root
takes
the
packet
from
the
outside
of
the
diode,
encapsulates
it
with
rpi,
zero
and
now
a
has
to
encapsulate
it
to
c,
via
b.
B
So
the
the
bottom
line
is
when
we're
using
non-storing
mode
to
signal
intermediate
hops
between
the
loose
thing,
you're
actually
re-encapsulating
the
packet
in
another
track,
whether
it's
the
main
geodag
or
that
that
was
the
outer
thing.
Well,
the
the
first
encapsulation.
The
second
encapsulation
is
a
new
track.
That's
one
of
the
realizations
we
ended
up
doing
in
the
process
of
of
defining
pidao
is
as
soon
as
you
use
rotting
headers.
You
have
to
re-encapsulate,
which
means
really
another
track
so
to
make
this
work
in
non-storing
mode
same
thing
as
before.
B
So
it's
easier
in
terms
of
signaling,
because
the
pdo
in
non-storing
mode,
so
the
the
the
sr
the
pida
vio
is,
is
really
passed
to
to
only
the
ingress
the
ingress
gets.
It
gets
the
source.
Writing
header
just
answers
immediately,
so
you
see
p01
being
sent
to
c
and
c
answering
and
p
double
2
being
sent
to
a
and
a
answering
okay.
So
it's
easier
for
signaling.
B
Okay
and
like
before
you
could,
you
could
end
up
in
in
d
just
like
we
end
up
in
b.
It's
that's
why
I
say
there
are
two
way
of
expressing
roughly
the
same
thing:
it's
just
that
in
this
case,
it's
more
obvious
that
b
will
decapsulate
and
forward
the
packet,
which
is
still
forwarded
along
the
main
geodag,
with
rpi
zero
in
the
outer
rider.
Now,
from
b
to
c,
that's
the
same
packet
that
was
from
the
root
to
a
because
b,
has
encapsulated
reaches
c
c
needs
to
send
it
to
to
e.
B
C
C
B
Yes,
I'm
sure,
okay,
so
no!
No,
no
worries
I
mean.
Actually
everything
is
expressed
in
in
the
the
draft
anyway,
with
examples
etc,
and
you
see
that
the
profiles
are
mostly
expressing
the
same
thing,
but
instead
of
having
the
main
deal,
the
egg
now
you're
trying
to
do
a
shortcut,
because
that's
the
second
thing
that
the
group
asked
me.
After
doing
this,
the
non-storing
mode
segments
which
really
are
tracks
here's,
how
can
we
do
shortcuts
inside
the
geoduck
so
not
just
along
the
main
geoduck
but
inside
the
geodex?
B
3
is
the
case
where
the
track
I
mentioned
that
earlier,
but
the
track
is
implicit
because
all
you're
doing
is
giving
me
a
list
of
hops.
So
you're
saying
oh,
I
want
to
get
from
a
node
which
is
next
to
a
to
a
destination
f
and
to
get
to
the
destination
f,
which
is
a
neighbor
of
e.
All
I
want
to
do
is
go
a
b
c
d
e,
so
you
can
express
that
as
a
non
as
a
storing
mode
path,
which
is
just
represented
by
this
p
one.
B
But
you
don't
really
need
to
do
an
encapsulation,
well,
calculation,
you
you
do
need
to
do
encapsulation,
but
to
signal
a
track
which
would
have
the
exact
same
information
and
saying
ingress
a
egress
e.
I
mean
that
would
be
an
addition
on
p
dial
for
just
nothing
match.
B
So
when
you
signal
p01
as
expressed
here,
you
can
think
that
implicitly
comes
with
it.
A
non-storing
pidao,
an
sr
vio,
which
says
ae
right,
ingress,
egress,
it's
implicit!
You
you!
You
have
signaled
by
by
this
segment.
I
have
also
signaled
implicitly
a
track.
So
that's
that's
profile.
Three!
That's
how
you
can
do
a
next
slide,
please,
let's
see
how
we
can
do
the
the
simple
segment,
which
is
a
track
by
itself.
B
So
so
three,
four
five
six
I
forgot
to
say
because
you're
doing
left
or
right,
you
need
sibling
information
option
for
one
two.
You
don't
need
the
new
option
that
we
have
in
the
pdf
draft,
but
for
two
three,
four:
five:
six:
we
we
need
the
the
sibling
information,
so
the
root
can
know
actually
what
the
neighbors
are.
B
In
this
case,
we
are
using
a
storing
mode
track
to
signal
the
the
same
path
as
before.
But
now
we
we
are.
We
have
a
straight.
B
I
just
I
don't
say
why
I
say
loose
hop
one,
because
it's
really
straight,
I
mean
it's,
it's
it's
so
sorry
for
the
typo.
The
hops
are
not
loose
anymore.
In
this
case
the
orbs
are
straight,
and
it's
basically,
you
signal
this
exact
same
case
as
three,
but
using
a
non-storing
mode.
Next
slide,
please.
B
So
here
we
are
so
every
odd
number
is
using
storing
mode.
Every
even
number
is
using
non-storing
mode.
So
what
we've
done
here
is
pretty
much
the
same
thing
as
we
did
in
pro
in
the
first
profile
in
profile
one.
But
now
you
realize
that
the
the
main
diode
is
replaced
by
a
track
and
profile.
Six
is
the
same
thing,
but
using
track
within
track
and
that's
pretty
much
it
okay.
So
so
there
are
some
questions
which
were
really
already
asked
during
the
interim.
I
don't
have
much
time,
but
I
would
like.
B
Yes,
I'm
done,
I'm
saying
I
just
want
to
to
to
address
those
questions
on
on
the
mailing
list.
So
do
we
need
to
do
more
on
loop
avoidance?
That's
the
last
slide
that
you
have
here
when
we
have
the
packet,
the
pedal
request
who
sends
it
so
so
those
questions
that
you
can
read.
I
would
like
damage
rest
on
the
mailing
list
to
to
solve
it
and
pretty
much.
We
are
done
after
that.
That's
my
conclusion.
C
C
B
Yes,
exactly
I
I
need
to
to
to
to
discuss
those
items
that
you
can
see
in
front
of
you
and
get
feedback
from
the
from
the
group.
There
was
the
question
of
whether
we
do
flow
filtering
and
then
whether
we
want
to
do
more
on
loop
avoidance,
whether
we
want
to
extend
the
capability
to
send
a
pid
out
request.
So
that's
a
message
which
says:
please
build
me
this
track.
For
now,
only
the
traffic
rights
can
do
it.
Do
we
want
more?
How
do
we
maintain
the
the
neighbor
state?
B
You
know
we
now
have
the
sibling
information
option.
How
do
we
maintain
the
state
of
the
sibling?
Do
we
say
oh
use
nd
or
something
it's
not
it's
not
really
detailed
and,
and
the
last
one
is
already
done.
I
mean
we.
We
already
see
now
pretty
clearly
you'll
find
the
draft
that,
depending
if
you're,
using
srv
your
svio,
basically
implicitly,
the
egress
is
a
target
when
you're
using
non-storing
mode.
But
it's
not.
You
have
to
signal
it
in
story
mode
same
thing
for
the
ingress:
it's
signaling
in
storing
mode,
it's
not
signaling
non-story.
E
A
F
Yes,
thank
you
hi.
All
thanks
for
the
great
presentation
I'd
like
to
ask.
If
there
is
any
profile
that
I
I
was
looking
at,
searching
for
a
profile
that
we
send
the
pdao
to
all
of
the
intermediate
hubs
and
not
only
their
ingress
or
address
that
would
have
some
benefits.
Obviously
it
would
also
have
some
disadvantages
like
scalability.
B
So
though
we
have
not
designed
for
it,
I
mean
yeah
you're,
the
first
one
asking
for
this
in
sixties.
When
we
looked
at
how
we
could
establish
a
path
we
considered
it,
we
called
it
the
shower
model
compared
to
the
basically
usual
usual
voice,
call
model
that
that
we
used
for
rsvp,
for
instance,
but
we
we
found
that
it
was
consuming.
B
If
you
have
a
big
deal,
dag
and
the
nodes
are
deep
into
doing
what
you're
asking
could
be
very
costly
and
then,
if
any
of
those
doesn't
work,
then
you
have
to
undo
everything,
and
so
we
thought
it's
a
bit
harder
from
the
root
to
control
everything
when
things
work
it's
much
easier
to
just
send
to
the
egress
and
let
it
forward
to
the
ingress.
We
did
that
for
economy.
Now,
if
you
you,
we
can
do
this
on
the
mailing
list.
B
B
G
Okay,
so
yeah
so
status
of
this
document,
so
we
adopted
it
after
sitting
around
for
a
while
in
march
of
2020,
there
were
some
revisions
to
it
last
year
and
then
we
have
this
document
from
human.
Do
I
say
is
not
right.
Name
right,
I
hope
so
on
the
this
dodag
metric
for
joining
based
upon
the
size
of
the
dodag,
and
so
the
suggestion
in
the
january
virtual
interim
was
that
we
merged
this
into
this
document,
and
so
next
slide
please.
G
G
This
is
essentially
the
core
of
the
thing.
You'll
see
that
there
is
a
new
dodag
size,
a
16-bit,
sorry,
it's
a
16-bit
number.
No,
it's
not
16-bit!
It's
a
it's
a
16
bits
with
an
exponent
and
a
mantissa
there
and.
G
That's
essentially,
that
gives
us
the
the
size
value
and
then
there
has
been
some
discussion.
I'm
sorry,
I
didn't
write
a
point
about
this
between
pascal
and
newman
and
some
others
about
exactly
what
are
we
measuring
and
with
pascal
suggesting
that
the
thing
that
we
actually
can
know
about
in
the
case
of
particularly
non-storing
mode,
the
root
knows
the
number
of
roots
that
he
has
not
necessarily
the
number
of
nodes
that
there
are.
G
I'm
found
at
difficulty
to
figure
out
are
there
situations
where
we
have
more
nodes
and
we
have
roots
for
for
them
or
if
we
have
fewer
roots
than
we
have
sorry
if
we
have
more
roots
than
we
have
nodes.
So
when
would
those
numbers
not
be
the
same,
and
I
don't
have
an
answer
to
that
question
and
pascal
probably
answered
in
the
queue
just
give
me
a
moment.
B
G
B
That's
right,
so
the
only
thing
you
see
is
number
of
addresses,
so
it
might
be
that
this
node
is
slipping,
doesn't
need
to
contact
the
network
for
two
hours
and
decided
not
to
send
a
dowel.
He
will
send
the
dowel
in
two
hours
when
he
wants
to
be
reachable.
In
this
case
you
don't
have
an
entry
for
him,
but
he's
there
yeah
and
the
opposite
case
is
this
node,
which
wants
to
have
two
addresses
for
its
own
needs.
B
I
don't
know
why
maybe
one
for
management,
one
for
other
purposes
and
having
two
addresses
two
entries
in
in
the
routing
table,
but
a
single
node.
So
it's
just
two
examples
where
the
number
of
routes
doesn't
match
the
number
of
nodes.
Now
in
storing
in
non-storing
mode,
you
have
a
little
bit
more
information.
At
least
you
know
the
number
of
parents,
but
at
the
last
half
you
still
don't
know.
What's
going
on.
G
Yeah,
so
it
seems
reasonable
that
you
know
this
is
an
estimate,
and
I
have
a
feeling,
based
upon
the
and
based
upon
the
discussion
that
we
had
around
the
six
tisch
draft
that
is
related
to
this,
that
there
that
there
may
be
some
desire
to
explain
what
it
is.
We're
gonna
do
with
these
numbers
down
down
the
down
the
tree,
and
some
of
this
is
a
a
little
bit
of
of.
G
We
want
the
standardized
containers
with
the
standardized
meanings,
but
we
don't
actually
know
necessarily
what
we're
going
to
do
with
them
precisely
until
people
do
some
experimenting,
and
I
don't
know
how
to
capture
that
intelligently
into
the
draft.
Maybe
the
whole
thing
should
be
marked
experimental.
Maybe
that's
the
right
answer,
but
anyway,
at
this
point
I
I
think
this
is
a
a
welcome
and
simple
change
and
we
should
just
proceed
with
it
and
that's
about
it.
I
think
that's
the
last
slide,
you
know,
is
it.
A
Okay,
yeah,
you
have
two
minutes
more.
G
That
was
the
only
question
yeah
at
this
point.
I
think
we
should
just.
We
should
just
proceed
to
reviews
and
publications,
and
I
would
love
to
have
and
figure
out
the
question
of
do.
We
have
to
specify
the
semantics
of
what
you
do
with
all
of
this
or
not,
and
if
we
do
then
we're
gonna
have
to
have
a
longer
conversation,
and
I
think
that
we
need
to
have
some
implementation
experience
with
this.
First.
A
B
Yeah
the
question,
though,
it's
not
really
a
question:
it's
just.
Basically,
there
is
the
wise
son.
You
know
why
son
is
kind
of
important
for
ripple.
They
have
deployed
millions
of
ripple
nodes
and
they
they
needed
this
information
of
having
a
rough
idea
of
the
size
of
the
deodag.
In
that
case,
it's
one
address
per
node
blah
blah
blah.
So
then
they
actually
match
us.
Intuitively
michael
does
as
well
the
number
of
rods
with
the
number
of
nodes,
and
they
they
needed
this
to
balance
geodex.
B
G
Okay,
okay,
so
that
would
be
great
to
hear
I
guess
directly
from
my
son
about
that-
and
I
know
that's
your
cisco
has
a
lot
of
have
connection
but
it'd
be
great
to
hear
from
some
other
people
on
that.
D
I
hope
everyone
can
hear
me:
okay,
yeah
I've
got
a
status
for
two
drafts.
One
is
the
capabilities.
Draft
and
other
is
the
mopex
draft
for
the
capabilities
the
there
had
been
an
update
before
the
last
winterim,
primarily
based
on
dominic's
feedback,
extensive
review
done
by
dominic.
Thank
you
atomic.
But
after
that
there
has
been
no
changes.
D
I
would
like
to
summarize
what
the
document
does
here.
Can
you
go
to
the
previous
slide
pcr?
So
it
basically
talks
about
the
capability
options.
Format.
So
capabilities
is
something
that
a
node
might
possess
and
might
want
to
handshake
with
other
other
nodes.
A
node
might
want
to
know
some
of
the
capabilities
for
the
other
nodes
adjoining
nodes
or
nodes,
not
necessarily
at
joining
nodes,
but
any
other
node
a
route
might
want.
D
Capabilities
of
a
newly
joined
node,
you
know
so
all
these
all
these
use
cases
are
covered
by
this
document.
There
are
two
specific
capabilities
which
are
instantiated
as
part
of
the
document.
One
is
the
capability
indicators
flags.
These
are
single,
beat
single
bit
capabilities.
One
of
the
capabilities
which
is
already
defined
is
about
six
language.
Whether
the
node
supports
six
large
compression
or
not.
D
And
then
we
have
query
and
response
signal
which
came
up
later
in
the
document
post,
the
working
group
feedback
and
there
are
guidelines
for
defining
new
capabilities.
So
there
are
certain
flags
in
the
capabilities
options
and
how
one
should
be
defining
those
products
or
using
those
flags
has
been
defined
in
the
in
the
document.
There's
only
one.
One
important
must
that
I
need
to
bring
to
the
notice
of
this
working
group.
D
It's
that
the
capabilities
will
be
mandatory
in
the
world
if
the
network
uses
more
packs,
essentially
mop
greater
than
or
equal
to,
seven
next
slide
piece-
and
this
gives
you
a
very
high
level
of
view
of
the
messaging
format.
We
have
a
new
capabilities
options
and
then
there's
a
there
are
tlps
nested.
C
D
The
jic
flags,
those
are
the
flags
which
are
actually
defined
by
the
mopx
draft
and,
as
I
had
mentioned
before,
that
there
is
capability
indicators,
the
two
capabilities
which
are
already
defined.
One
is
the
capability
indicators
and
the
other
is
the
optimal
source.
D
And
then
there
there
are.
There
is
a
way
for
the
capability
query
and
response
model.
There
is
a
way
to
request
a
capability
set
or
you
know,
send
the
response
for
that
particular
capability
set
and
there
are
several
scenarios.
D
So
that's
the
only
complicated
piece
I
would
say
in
the
whole
draft,
but
otherwise
it's
a
pretty
straightforward,
read
it.
I
should
say
next
slide,
please,
and
here
I'm
giving
some
details
about
how
the
query
and
response
model
works.
Basically,
the
primary
challenge
is,
you
know
you
might
have
capabilities
sent
across.
You
know
multiple
messages.
Is
it
possible?
So
if
you're
sending
back
the
responses
saying
I
have
all
these
capabilities,
it
might
so
happen
over
a
period
of
time
that
this
capability
message
might
exceed
the
entity
size
and
how
to
handle
that.
D
D
And
that's
pretty
much
about
the
capability
status.
Now
I'm
going
to
talk
about
mopex
status.
Well,
the
document
what
it
does
is.
This
is
a
very
straightforward
document
in
the
sense
that
it
doesn't
have
any
any
new
messaging
involved.
It's
it
defines
some
opex
the
base
mop
is
equal
to
7.
D
Then
you
basically
use
the
mop
from
the
extended
mopex
option:
control
option:
that's
that's
the
core
of
the
document,
it
explains
various
conditions
and
it
basically
tells
you
know
what
happens
if
you
know
base
mob
is
so
and
if
the
extent
nmop
is
present
or
if
the
base
move
is
seven
and
what
happens
if
the
expected,
if
the
m
op
x,
is
not
present
how
to
handle
all
the
scenarios
in
the
past
itf
session?
One
of
the
point
that
was
discussed
was
you
know.
D
D
Can
we
handle
the
backup
compatibility
issues
in
a
graceful
manner
and
that's
where
the
third
point
comes
into
picture,
which
is
extending
the
rpl
control
options
which
we
decided
to
merge
in
this
particular
document
and
I'll
talk
about
that
particular
point
in
detail
in
the
next
slides
next
slide.
Please
so
extending
the
rpl
control
options
we
needed
few
bits.
D
Currently
we
have
an
option
type
if
the
first
bit
of
that
option
type
is
set,
which
means,
essentially
it's
an
extended
control
control
option.
If
it's
an
extended
control
options,
there
are
additionally
optional
flags
which
could
be
set
and
in
the
optional
flags
you
could
see
that
three
flags
are
already
defined
j
ic.
D
D
D
C
bit
is
a
copy
bit,
which
is
which
is
you
know
you
copy
the
control
options
as
it
is
in
the
in
the
in
the
message
and
let
the
upstream
or
downstream
note
design
you
just
act
as
a
relay,
so
this
is
very
much
similar
to
cast
and
gave
a
feedback,
and
I
had
it
look
at
you
know.
D
Coupe
has
similar
co-op
has
similar
bits
and
I
had
a
look
and
you
know
I
tried
to
take
some
inspiration
from
those
bits
as
well.
Oh,
I
I
think
pascal
has
a
question,
is
the
hand
raised.
I
can.
B
It's
a
very
quick
one.
Thank
you
for
the
presentation,
the
and
hope
everything
is
good
with
you,
I'm
just
thinking
hey.
B
I
already
had
the
problem
of
thinking
about
it,
but
that
could
be
a
cases
where,
if
this
guy
does
not
support
the
option,
it
should
not
join
at
all,
and
since
you
have
four
possibilities
and
you're
only
using
three,
I
was
wondering
if
you
know
you
could
play
with
the
g
and
c
bit
when
when
j
is
one
with
based
on
the
c
bit,
you
could
say
or
you
you
join
us
a
leaf
or
you
don't
join
at
all,
because
could
it
be
that,
for
instance,
the
bit
says
you
must
compress
just
an
example.
B
You
must
compress
and
if
the
node
doesn't
know
to
compress
there
should
be
a
way
to
say
you
don't
join
at
all
so
here
it's
not
that
it's
understanding
an
option,
but
if
the
option
could
be
to
say
to
compress.
Actually,
I
don't
know
it's
not
the
right
example,
but
you
see
the
point.
Maybe
there's
a
case
where
you
don't
want
to
join,
and
since
your
c
is
not
reused,
why
don't
we
say
a
c
j,
one
c
zero?
You
can
join
us
j,
one
c
one.
D
Okay,
that
makes
sense.
I
think
I
think
we
should.
D
Let
me
think
more
about
this.
Pascal
point
noted.
Thank
you
very
much
for
the
feedback.
I
have
lost
the
slides.
Can
you
hear
me
still?
Okay,
I'm
done
with
my
presentation.
Just
the
next
slide,
please
in
this
okay.
So
there
are
no
tickets
open
by
the
way
for
any
capabilities
or
the
mopex
draft.
All
the
tickets
have
been
taken
care
of.
You
know
before
the
last
interim
itself.
I
saw
that
you
know
unless
you
mentioned
in
this
summary
status
before
that
the
six
capability
issues
open,
I
just
verified.
D
There
are
no
issues
open
in
the
context
of
capabilities
or
mopeds
all
right
yeah.
So
I
I
mean,
especially
for
mob
x.
There
is
no
complex
handling
involved
for
capabilities.
There
is
a
complex
handling
involved
because
I
mean
some
sort
of
complex
handling.
I
would
say
just
because
of
the
addition
of
new
messaging
mopex
is
basically
a
precursor
for
capabilities,
because
capabilities
would
be
enabled
only
from
if,
if
mob
x
is
supported.
D
A
That
would
be
great,
please
review
this
last
version
of
my
bike,
so
we
can
go
proceed
with
the
last
call.
E
A
So,
thank
you
very
much.
We
have
one
minute
over
the
time,
but
I
think
we
have
action
points
that
we
are
going
to
send
to
the
mainly
list.
So
thank
you
very
much
to
everyone
dominic.
You
want
to
add
something.
C
Well,
congratulations
for
achieving
here.
You
know
unlocking
these
four
drafts
that
we
are
sitting
and
I
know
that
many
people
are
going
to
be
happy
that
c,
if
we
when
c318
is
out-
and
so
that's
a
great
achievement,
congratulations
to
him
and
then
we
can.
We
can
focus
on
the
next
drafts
and
we
have
a
lot
of
work
ahead
of
us.
A
A
A
Okay,
thank
you
very
much
paul
and
have
a
nice
day.