►
From YouTube: IETF114-6LO-20220725-1730
Description
6LO meeting session at IETF114
2022/07/25 1730
https://datatracker.ietf.org/meeting/114/proceedings/
B
B
B
B
Okay,
anyway,
recall
that
we
are
taking
minutes
by
using
hedge
dock,
so
this
is
a
collaborative
process
and
everyone
is
welcome
to
join
and
contribute
to
the
process
of
taking
minutes,
and
thank
you
in
advance
and
also
we
might
need
a
jabber
or
perhaps
today,
a
zulip
scribe
as
well.
So
if
anyone
would
like
to
volunteer,
please
let
us
know
okay
and
also
on
the
agenda.
You
can
find
a
couple
of
pointers.
B
B
So
this
is
the
second
itf
meeting
that
has
an
in-person
component
since
the
start
of
the
copied
endemic.
So
there
are
a
few
meeting
tips
to
keep
in
mind,
so
basically
they
are
the
same.
As
for
the
last
itf
for
in-person
participants,
please
make
sure
to
sign
into
the
session
by
using
meet
echo.
For
example,
you
may
use
the
on-site
tool,
which
is
available
from
the
data
tracker
agenda,
and
the
very
important
point
is
that
actually
we're
going
to
use
miteco
to
manage
the
cube.
B
So
if
you
want
to
join
the
queue,
please
do
that
through
miteco
as
there
is
a
single
unified
q
handle
in
this
way,
and
also
blue
sheets
are
automatically
generated
from
miteco.
So
please,
if
you
are
in
the
room,
please
make
sure
that
you
join
me
technically
and
for
remote
participants.
Just
keep
in
mind
that
you
need
to
keep
your
audio
video
off
unless
you
are
presenting
next.
Please.
B
B
B
B
So
the
first
document
that
we
have
on
the
table
is
again
the
ipv6
over
nfc
draft
which,
as
you
may
recall,
was
evaluated
by
the
asg.
Then
it
was
updated
after
that
and
now
it
has
been
stuck
for
two
years
now.
So
perhaps
eric,
if
you
can,
let
us
know
about
details
about
the
next
steps.
Any
plans
for
that.
A
A
A
We
can
demonstrate
that
everybody
who
had
access
to
this,
who
needed
to
have
access
to
the
spec,
had
access
to
it
and
also
that
those
that
did
not
it's
not
terribly
different
from
other
wireless
standards
and
certainly
not
from
an
ipv6
interface
definition.
So
I
think,
there's
a
small
there's.
Some
clarifying
text
to
the
security
considerations
we
might
we
might
make-
and
probably
the
right
thing
to
do-
is
to
maybe
bring
it
back
to
the
isg.
B
B
D
B
B
A
A
B
Fair
okay,
thank
you.
So
the
next
document
is
ipv6
over
plc.
You
may
recall
that
all
the
discussed
ballots
have
been
cleared.
The
authors
updated
the
draft
after
that
incorporating
the
last
remaining
set
of
comments
as
well.
So,
however,
if
I
understand
it
correctly,
eric
there
has
been
some
changes
in
isg
membership,
so
new
isg
members
need
to
provide
also
some
ballots
right.
A
That's
correct:
we
lost
some
ballot
positions
during
the
changeover
and
I
failed
to
advance
it
prior
to
that
and
so
I've
sent
email
to
their
remaining
and
to
the
to
the
new
into
the
to
those
with
no
record
ballot
to
ask
if
we
could
get
two
more
reviews.
I
think
we
only
need
two
more
at
this
point
and
then
or
two
more
no
objection
or
yes
ballots.
B
Great,
thank
you,
then.
The
next
one
is
six
low
use
cases
draft.
It
has
been
evaluated
by
the
security
area
directorate
and
the
general
area,
and
it
has
been
updated
as
a
result,
and
there
will
be
a
presentation
later
today
on
this
draft
and
well
perhaps
I
don't
know
the
next
step,
maybe
but
after
that
it
will
be
ready
for
telechat
anyway,
yeah
eric.
A
B
Thank
you
and
finally,
the
multicast
address
listener.
Registration
document
has
been
updated
several
times
since
the
last
atf,
thanks
to
michael
richardson
and
rahul
yan,
have
for
reviewing
the
draft
thanks
a
lot
and
also
there
has
been
an
update
after
an
ayanna
review,
so
this
will
be
presented
and
discussed
later
today.
B
C
Okay,
nice
to
meet
you.
My
name
is
hong
I'll
present,
the
sixth
row
of
ability
and
the
use
case
document
next
page.
Please,
okay,
thank
you.
Yes,
this
is
history
and
status
of
2018,
the
first
vocabulary
score
and
the
second
working
group
last
call
was
2720
october,
and
this
year
february
ed
submitted
to
isg,
and
this
is
the
certain
revision.
Okay,
please
yeah.
So
after
our
last
meeting
we
got
two
a
comment
from
security
director
robert
spark
and
the
other
is
to
peter
e
or
general
art.
C
C
Okay,
I
talked
about
the
comment
from
robot
spark.
The
first
one
is
the
security
consideration.
Originally,
this
document
is
the
usual
document.
So
if
you
see
the
section
7
security
construction,
there
is
all
two
sentences.
Security
construction
are
not
directly
applicable
to
the
document
for
the
use
cases.
The
security
requirement
describes
in
the
protocol
section
of
line,
but
he
says
that
the
text
of
this
draft
has
several
plays.
That
rightly
call
out,
like
the
implication
of
privacy.
C
It
is
also
required
to
provide
secure
data
transmission,
even
though
the
six-row
stack
do
not
address
curate
at
the
network
layer.
It
is
required
to
provide
l2
level
security
and
the
application
level.
Security
is
highly
desirable,
but
after
a
submission
of
this
division
of
document,
I
got
a
response
from
robert
spark,
but
he
does
not
satisfy
so
I
need
to
enhance
more
in
the
next
revision.
C
Yeah
and
another
is
also
security,
so
if
you
thought
table
two
or
there
are
some
the
law
for
which
is
regarding
to
security
requirement
for
because
which
g-wave
period,
security,
msdp
and
nfc
and
plc,
but
he
suggests
that
on
content
is
not
clear,
so
I
think
that
it
is
better
to
remove
the
role
itself
so
in
the
update
revision.
I
treated
this
part
next
page.
Please.
C
C
Yeah
in
appendix
a
on
design,
speed
dimension
for
six
rupee
deployment.
There
are
some
descriptions
of
deployment
photo
strapping
topology
l2
mesh
wireless
remesh,
multilingual
survey,
data
radar,
blah
blah
blah.
So
this
is
not
directly
related
to
sixth
row,
while
sixth
row
open
technology,
but
it
is
helpful
to
understand
and
help
people
to
design
for
the
network.
So,
yes,
could
you
back
to
one
page.
Please.
C
Yeah
so
he
says
that
appendix
a
is
neither
introduced
nor
reference
from
the
body
of
the
document.
Yes,
it
is
true,
so
you
know
in
itf
106
meeting.
They
recommend
that
this
document
is
a
little
too
long,
so
it
must
be
short
and
it
narrow
down
and
focus
something
so
reflect
the
command.
The
this
section
was
originally
section
5.1,
but
it
was
moved
to
appendix
a,
but
now
the
relationship
from
the
main
body
is
not
exist.
So
I
would
like
to
ask
how
to
handle
the
appendix
say.
C
Yeah,
the
final
comment
from
robert
spark
is
that
this
document
has
some
misuse
of
canal
description
and
marketing
words,
for
example
superior
range,
so
he
suggests
to
change
to
better
than
or
goes
further.
So
I
agree
that
because
this
trap
has
some
parts
which
are
recognized
at
the
marketing
world,
because
we
invited
some
expert,
for
example,
double
threat
or
electricity
or
white
sun,
etc.
So
there
are
some
use
of
the
marketing
world,
so
I
try
to
change
the
marketing
words
to
technology
words
in
this
revision.
C
B
Okay,
so
one
comment
by
the
way
as
author
of
the
document
regarding
appendix
there
is
a
paragraph
introduction
which
says
that
the
document
covers
design
dimensions
and
so
on.
So
removing
the
appendix
maybe
one
approach.
But
another
approach
is
to
to
add
a
forward
reference
from
the
last
paragraph
to
this
appendix
a
and
also,
if
I'm
not
mistaken,
I
think
that
there's
a
comparison
table
where
each
row
in
the
table
is
based
on
the
different
design
space
dimensions.
B
E
Yeah,
I
do
agree
with
carlos.
I
I
do
apologize.
I
didn't
read
the
appendix,
but
I
don't
think
that
just
removing
it
without
just
for
an
editorial
issue
makes
sense.
The
first
question
is:
is
there
any
information
that
is
useful?
If,
yes,
then,
the
solution
of
cardless
is
the
best
way
forward.
In
my
opinion,.
A
I'll
insert
myself
in
the
queue
here
and
say
on
the
security
considerations,
stuff,
there's,
there's
plenty
of
text
that
we
can
point
to
from
rfc
8200
security,
section
and
8200
has
links
to
other
security
documents
for
ipv6
neighbor
discovery,
security
considerations.
So
I
don't
know
if
that
would
satisfy
robert's
concern,
but
we
could
certainly
point
to
all
the
other
security
sections
and
all
the
other
things
it's
basically
because
I
there's
nothing.
There
are
no
new
conservative
security
considerations
per
se.
D
B
G
Locales,
can
you
hear
me?
Okay,
yes,
perfect,
so
sorry
not
to
be
here
with
you
guys.
So,
yes,
we
are.
We
are
now
deep
into
the
the
process
of
the
multicast
registration
document,
so
this
document
was
stimulated
by
work,
which
happened
effectively
in
an
alliance
in
three
alliance
called
white
sand.
That
was
just
mentioned
where
they
use
six
low
and
raw
rfcs
to
be
on
the
solution
for
mostly
for
the
smart
grid
over
i2.15.
G
So
that
was
the
question
I
mean:
how
could
we
do
the
equivalent
of
mld,
but
in
a
way
that
is
a
pull
from
the
device
as
opposed
to
to
from
the
router?
Basically,
the
the
or
push
call
it
the
push
from
the
device
as
opposed
to
a
pull
from
the
router,
so
the
device
would
not
have
to
be
listening
to
paradigm
ld
reports.
G
So
next
slide
please
so
we
we
started
with
this
and
we
ended
up
also
looking
at
the
way
the
multicast
is
distributed
in
ripple
and
since,
as
you
know,
most
of
the
iot
cases
of
repo
are
using
non-storing
mode.
We
figured
that
there
was
a
need
as
well
to
enable
the
multicast
across
the
non-storing
mode
network,
and
so
we
we
did
that
as
well,
so
the
draft
actually
ends
up
doing
work
for
six
law,
but
also
work
for
raw.
G
G
So
we
clarified
that
the
tid
is
not
checked,
and
so
the
state
actually
disappears
with
a
lifetime
timeout.
So
that's
why
it's
important
that
the
lifetime
is
chosen
correctly
and
we,
the
the
big
change,
is
basically
a
command.
I
think
it
was
from
newcastle,
I'm
not
too
sure
anymore,
but
the
basically.
The
question
was
how
you
know
if
the
writer
reboots,
how
do
we
know
that
it
needs
to
to
fetch
some
state,
and
so
we
did
two
things.
G
The
first
thing,
which
really
addresses
the
low
power
devices,
is
a
multicast
arrow
status
that
can
be
sent
a
synchronous
line
and
the
name
sh
any
cast
or
multicast,
which
will
basically
say,
hey
any
state
that
I
would
have
had.
I
could
have
lost,
and
so
please
refresh
and
since
this
is
a
pull
by
the
router
again,
it's
something
that
the
low
power
devices
might
miss.
G
G
And
finally,
I
had
some
comments.
Some
only
comments
by
amanda
barber
about
the
ayada
section.
So
I
cleaned
you
know
the
wording
of
the
irs
section
to
to
make
it
fit
the
way
I
now
wants
it
written.
So
that's
already
done
that
will
save
us
time
on
the
publication
process.
Now.
What
is
this
new
node
uptime
option?
It
is
something
that
was
needed
in
rfc8505.
G
That
was
not
there,
because
at
the
time
we
we
didn't
really
care
about
going
to
a
network
where
that
there
would
not
be
enough
reliability
on
the
routers
basically,
and
so
now
we
figured
that
it
was
actually
a
mess.
It
was
a
command
that
we
got
a
number
of
times,
and
so
we
kind
of
leveraged
this
specification
and
the
particular
discussion
we
had
on
dna
with
this
new
status.
To
effectively
add
the
option
in
arrays,
so
it's
it
is
something
that
will
require
six-man
visibility.
G
So
now
I'm
talking
to
eric,
since
I
see
you
here,
we
are
proposing
a
new
option
in
the
array
to
basically
tell
well
for
the
array
to
say
how
long
this
router
has
been
up,
it's
basically
the
sequence
and
a
a
time,
and
so
the
the
time
I
is
split
in
two
fields.
One
is
an
exponent
and
then
there
is
mantissa.
This
allows
to
express
very
short
and
very
long
times,
depending
on
what
the
exponent
is
with
two
bytes.
G
So
we
we
kept
it
short
because
you
know
there
are
many
things
in
arrays,
and
so
that's
why
we
compressed
the
value
this
basically
says
in
the
agnostic
fashion.
You
know
this
router
has
been
up
for
this
time,
and
so,
if
you
registered,
if
the
node
uses
that
to
register
at
the
registered
or
in
longer
before
basically
the
beginning
of
the
new
life
of
this
router,
then
the
device
can
figure
that
the
router
is
not
aware
of
the
registration
status
of
this
device
and
this
device
should
re-register.
G
G
G
So
I
understand
that
you
know
that
this
is
a
cross
area
discussion.
We
have
some
work
which
interests
roles
which
which
interests
role,
someone
which,
which
interests
six
law.
We
decided
to
package
that
together
to
have
a
consistent
story,
so
people
would
see
exactly
what's
going
on
for
multicast
and
with
this
I
will
leave
you
know
for
questions
and
then,
if
the
chairs
want
to
say
something
about
next
steps,.
B
Okay,
so
if
if
there
are
no
questions,
basically
we
discussed
with
the
raw
chairs
and
we
informed
our
respective
ads
about
the
plan.
So
the
plan
would
be
that
if
there
is
no
significant
issue
raised
in
this
meeting,
then
we
plan
to
launch
a
coordinated
working
glass
call
which
will
happen
in
both
six
low
and
role
working
groups
and
well.
On
the
other
hand,
sixth
law
will
remain
as
the
home
working
group
regarding
shepherding
making
decisions
and
so
on.
But
anyway,
the
process
will
be
coordinated
with
growth.
G
F
F
I
don't
think
the
whole
organ
group
needs
to
look
at
it,
but
I
think
you
probably
want
to
check
in
I'm.
Guessing
pin
is
the
last
or
m
bone
would
be
either.
One
of
those
would
be
popped
into.
My
brain
is
just
having
them
look
at
this
and
from
a
multicast
perspective,
but
yeah
six
man.
I
don't
think
it's
on
the
agenda,
but
I
think
you
should
run
it
by
the
working
group
for
sure
because
of
the
options.
G
Yeah
that
that's
interesting,
we
are
effectively
the
team.
We
actually
got
that
remark
long
ago
at
the
beginning
of
this
document
about
multicast
and
as
it
goes,
what
you
need
to
see
is
there
is
no.
There
is
multicast
in
the
original
repo
using
the
preferred
parent
tree
inside
the
ripple,
but
that's
for
storing
mode,
and
here
this
is
kind
of
specific
we
are
doing
non-story.
G
G
G
A
G
A
G
G
A
G
Guess
there
is,
but
I
can
take
all
that
text
of
this
document.
I
mean
it's
it's
more
of
a
you
know
almost
last-minute
edition,
and
you
know
the
requirement
that
I
you
know
we
we
make
this
rfc
with
a
certain
set
of
requirements
in
mind
and
we
for
the
sort
of
requirements
that
we
have
in
mind.
There
is
effectively
your
multicast
channels
and
in
most
of
the
iot
networks,
I'm
aware
of
they
have
a
multicast
channel.
G
They
don't
want
it's,
not
fat
right,
you
can't
use
it
often,
but
it
exists,
and
so
we
can
use
dna
with
the
new
status
and
that's
enough,
for
instance,
for
y
sub.
So
it's
okay
for
me
to
remove
that
option
and
put
it
in
a
separate
document.
We
still
have
a
consistent
solution,
but
we
only
have
dna.
We
don't
have
the
array.
A
G
G
But
if
your
recommendation
is
effectively
to
do
yet
another
rfc,
then
then
just
to
keep
things
separate,
then
we
do
it.
We
kind
of
package
the
full
soyuz
in
one
rfc.
In
this
case
we
have
six
low.
We
have
raw,
and
so
we
would
have
had
a
little
bit
of
six
men
as
well,
but
if
that's
not
the
proper
way
for
six
men,
then
we
can
take
that
off.
G
A
G
Yeah
yeah
with
eric
and
the
six-man
chairs,
I'm
completely
open,
so
yeah
and
I
will
update
the
document
based
on
that
conclusion
and
then
we
can
launch
the
work
group.
Let's
go
on
buff
sites.
I
guess
we
can
do
the
one
goodness
calls
with
the
current
document,
but
if
the
chess
prefer,
I
can
take
it
off
just
let
you
know.
B
G
Whatever
they
conclude
right,
so
if
if
they
decide
that
they
should
remove,
that
section,
make
it
separate,
then
they'll
do
it
and
then
we
can
launch
work
up.
Let's
go
if
they
say
it's:
okay,
let's
just
circulate
it
by
six
man,
then
we'll
we'll
do
that
as
well.
So
so,
basically
we
will
be
holding
that's.
How
I
understand
right,
we'll
be
holding
the
word
group.
Let's
go
till
eric
gives
us
the
green
light
and
and
the
the
action
to
be
taken.
G
B
B
So,
basically,
here
there
are
some
numbers.
This
is
about
the
motivation
for
the
draft.
The
idea
is
that
with
chic,
in
some
cases,
we
are
able
to
achieve
greater
heavy
compression
ratio
than
with
traditional
six
low,
pan
header
compression,
especially
if
we
consider
also
compression
of
application
layer
protocols
like
co-op.
B
B
A
A
B
A
B
B
So
yeah
on
the
updates
in
the
draft,
you
may
recall
that
there
was
a
problem
with
how
we
are
going
to
compress
ipv6
addresses
and
udp
ports
by
using
chic,
so
sheik
uses
dev
and
up
terms
in
its
specification
that
corresponds
to
a
constraint
device
on
the
left
in
the
figure.
App
corresponds
to
a
network
site
infrastructure,
not
constrained
on
the
right
and
the
shift
specification.
B
So
here
the
point
is
that,
because
an
entity
knows
in
advance
whether
it
corresponds
to
debian
in
chic,
then
this
allows
some
optimization,
because
a
single
compression
rule
allows
it
to
be
usable
in
both
directions,
as
expressed
in
terms
of
level.
However,
well,
the
point
is
that
in
some
15.4
scenarios
we
can
still
use
this
optimization,
as
is,
for
example,
in
star
topology
networks.
B
However,
if
you
go
to
slide
number
five
next
slide,
please
there
are
some
other
scenarios
in
15.4
where
we
cannot
just
use
the
same
approach
as
this
because,
for
example,
two
peers
within
a
mesh
topology
might
be
candidates
to
be
considered
depth.
So
then,
who
is
that?
Who
is
up?
So
this
is
the
problem.
B
We
now
state
that
the
chic
compression
decompression
entity
needs
to
know,
which
is
the
role
developed
for
each
one
of
the
rules
that
are
going
to
be
used
in
communication,
and
actually
this
needs
to
be
known
in
advance
before
communication
happens
and
well,
knowing
the
role
in
advance
makes
sense,
because
the
rules
also
need
to
be
written
beforehand
in
advance
before
communication
happens.
Also
now
in
zero
three,
we
reference
the
lp1
architecture
draft.
So
this
has
some
additions.
It
will
be
discussed
by
the
way
the
architecture
draft
in
the
lp1
working
group.
B
B
So
we've
added
a
new
section
of
title
multi-hop
communication,
where
we
explain
that
we
can
use
routeover,
which
means
that
routing
is
performed
at
the
ip
layer.
There
is
one
straightforward
approach
that
may
be
used
to
transmit
compressed
packets
in
this
case,
which,
however,
requires
all
nodes
to
store
all
the
rules
in
using
the
network.
So
this
presents
some
challenges
in
terms
of
scalability
in
terms
of
network
size
memory
and
so
on.
B
So
an
alternative
is
that
if
ripple
is
used
as
the
routing
protocol,
then,
as
suggested
by
pascal,
we
can
exploit
ripple
on
story
mode
and
use
rfc
138
to
make
it
efficient,
and
in
this
case
an
endpoint
must
only
store
the
rules
for
the
communications
it
is
involved
in.
So
this
is
some
idea
that
we
plan
to
develop
and
elaborate
in
subsequent
versions
of
the
draft,
and
then
we
can
also
use
mesh
handler
in
this
case.
There
is
no
particular
challenge
to
enable
the
transmission
of
g-compress
packets.
B
G
Yes,
sorry
for
the
gory
details,
but
in
non-stop
we
can
use
non-stirring
mode
in
ripple,
even
if
the
main
diode
is
storing
mode,
and
we
do
that
for
low
power
devices
which
are
not
ripple
aware,
and
we
can
expect
that
a
device
that
needs
chic
is
probably
not
ripple
aware.
It's
probably
one
of
those
low
power
devices.
So
it
makes
a
lot
of
sense
to
to
not
contribute
to
not
that
straight
to
ripple,
use
the
ripple,
underwear
leaf
mode,
in
which
case
it's
always
reported
on
story.
G
So
when
it's
reborn
on
storing
there
is
a
tunnel
between
the
first
router
and
the
the
the
root.
So
basically
the
root
would
have
to
know
the
rules
for
everybody
and
the
leaf
would
just
need
their
own
set
of
rules.
So
so
it's
not
with
every
communication
I
mean
the
wording
is
not
entirely
crisp.
It's
not
the
communication
between
twin
points.
It's
every
end
point
communicating
to
the
root
the
root
will
decapsulate.
The
encapsulate
may
will
decompress
may
recompress
if
the
destination
inside
the
dag
or
it
will
just
send
to
to
whatever
up
there.
G
And
yeah
we
we
need
basically
the
6lr.
We
would
need
to
spend
some
time
explaining
exactly
how
it
works,
but
that's
that's
what
would
happen.
Basically,
the
session
would
be
oriented.
You
know
the
hub
would
be
the
roots.
There
is
enough
discussion
on
lp1
specification
that
when
there
is
a
habit
spokes
the
hub
is
effectively
the
node
that
has
rule
for
every
spark
and
it
is
the
it
is
up.
Basically,
it
is
the
upside,
so
yes,
kind
of
lines.
D
D
G
We
use
it,
who
is
it?
It
is
the
app
and
the
doubt
it's
completely
consistent
with
the
architecture.
It's
just
that
the
question
was:
who
has
to
have
the
rules
and
the
route
must
have
the
rules
to
every
ripple
number
nice
right,
because
there
will
be
a
tunnel
between
the
reaper
and
the
wall
if
and
the
rule
the
route,
but
the
reaper
and
valiant
just
need
its
own
set
of
fruit
of
rules,
and
it
doesn't
need
the
set
of
rules
of
anybody
else,
because
the
root
will
decompress
and
recompress
if
needed.
B
B
E
Okay,
so
I
have
shrinked
my
presentation
from
20
minutes
to
to
10
less
than
10..
The
first
presentation
is
a
very
quick
update
on
the
nsa,
the
native
short
addressing.
So
we
did
an
update
in
june
fixing
the
the
last
concerns
that
were
licensed.
Okay,
we
did
again,
as
usual,
the
the
typos
hunting
with
the
one
main
change
is
about
reliability,
and
I
will
come
back
to
this
in
a
couple
of
slides.
We
added
the
clarification
about
the
checksum
calculation
for
the
transport
layer.
That
was
important
and
minor
changes.
E
So
we
took
out
an
old
section
that
was
called
benefits
of
native
short,
addressing
which
anyway
was
partially
talking
about
the
reliability,
and
we
added
a
small
reliability,
consideration
section
where
what
we
do.
Basically,
we
discuss
our
routing
versus
stateless
for
welding,
because
at
the
end
of
the
day,
what
we
do
with
nsa
is
is
stateless
forwarding.
F
E
Has
been
done,
we
said
we're
gonna
issue,
revision,
three
after
one
one
three,
we
did.
Okay
again,
we
have
these
small
things
to
be
added,
but
it's
very
minor
note.
So
we
think
really
that
the
the
document
is
pretty
stable
and
unless
there
are
main
concerns
that
someone
has,
we
think
we
we
can
go
forward
for
working
group
adoption.
I
mean
we.
We
were
kind
of
hinting
on
this
on
the
113,
but
we
had
some
some
work
to
do
now
is
done
and
we
we
consider
that
is
relatively
stable.
E
B
B
B
B
E
E
E
Okay,
okay,
so
this
is
now
new
draft
that
we
we
build
in
order
to
to
tackle
this
issue
about
reliability.
This
is
very
important,
so
the
main,
the
main
point
is
that
there
are
several
solution
classes
of
solution
that
we
can
use
the
most
important
one.
Let
me
go
is
the
fact
that
obviously
we
need
some
prerequisites,
so
the
fact
that
actually
we
have
redundant
links
now.
The
question
then
is
you
can
build
multiple
topology
using
multiple
addresses
or
you
you
just
decide
which
link
do
you
use?
E
You
use
one
single
address
address
for
each
node
and
you
try
to
remember
which
link
is
active,
which
one
is
not
used?
Okay,
so,
basically,
in
the
multiple
addresses
solution.
What
you
do
is
you
build
several
topologies,
which
means?
Basically,
if
you
remember
nsa,
is
based
on
a
tree
topology.
So
you
have
a
second
route
and
you
add
a
secondary
address
for
the
nodes.
E
So
by
doing
so,
you
have
two
completely
orthogonal
topologies
and
you
one
you
use
it
as
a
primary
topology
and
then
you
have
to
decide
when
to
switch
to
the
second
one
when
there
is
a
failure.
Now,
here
there
is
such
an
example
where
that
cross
obviously
is
a
failure.
What
happens
is
a
node
can
can
send
through
an
the
secondary
topology,
an
icmp
message
to
the
main
route
to
say:
look,
this
branch
of
the
tree
subtree
is
not
reachable
anymore,
because
I
I
see
a
failure.
E
Okay,
and
this
way
the
root
can
can
store
this.
This
information
and
redirected
the
traffic
when
needed
same
thing
when
we
have
a
link
that
is
broken,
you
have
to
do
the
same
thing
from
both
sides
so
that
you
redirect
in
the
right
in
the
right
way.
Okay,
so
that
you
still
have
a
rich
ability
all
the
time.
H
E
Yes,
it's
not
a
word.
What
happens
if,
if
he
sends
traffic
upward
is
100
that
redirects
the
traffic
doesn't
need
to
be.
The
there
is
just
one
thing
is
meaningful.
What
you
said
is
you
can
consider
optional
to
send,
I
say
an
icmp
downwards
and
you
say
you
may
consider
to
use
your
secondary
address
in
order
to
bypass
or
all
of
this.
Okay.
G
You
have
no
choice
because
100
will
not
get
the
traffic
I
mean
you
would
have.
One
would
have
to
figure
out
that
along
the
path
there
is
a
breakage
and
then
it
needs
to
take
the
bypass,
and
instead
of
my
bottom
line,
is
you're
starting
to
doing
to
do
a
routing
protocol.
As
soon
as
you
start
doing
this,
your
your
you
put
your
your
hands
on
europe
and
the
pandora
box.
After
writing.
Protocol.
G
E
E
This
goes
back
to
routing,
indeed,
and
in
a
certain
way.
So
the
other
solution
goes
along
what
you
are
saying,
because
we
use
still
redundant
links,
but
we
use
just
one
single
addressing
space.
So
so
we
we
every
node,
has
one
single
address,
but
he
has
to
store
alternate
neighbors
like
an
alternate
patent,
a
parent,
different
childs
and
so
to
make
a
decision
when
there
is
a
a
failure.
E
Here
the
point
is
with
what
we
discussed
in
this
document
is:
if
you
use
multiple
addresses
the
the
the
in
the
root,
you
have
very
low
state,
because
this
really
depends
how
how
many
failures
do
you
have?
Okay,
and
also
the
the
state
that
you
put
into
the
nodes,
is
pretty
low,
but
because
everything
is
done
locally
in
a
certain
way
and
there
is
no
coordination
at
all
the
more
failures
you
you
have.
E
I
mean
the
more
messy
you
you
you
end
up
and
there
is
less
guarantee
that
there
is
a
feasible
path.
Okay,
when
the
single
address
solution,
okay,
in
the
root
in
a
certain
way,
it
has
to
have
a
a
good
knowledge
of
the
topology
hold
the
topology.
So
the
the
state
is
higher.
Okay
on
the
single
node,
we
we
still
have
low
state
because
it's
basically
neighborhood,
okay
and
but
the
robustness
is
higher.