►
From YouTube: IETF98-LWIG-20170327-1710
Description
LWIG meeting session at IETF98
2017/03/27 1710
A
D
C
B
That,
okay,
so
thank
you
so
much
enhance
week
and
I'm.
Sorry
that
I
cannot
make
the
car
go
this
time,
but
I
really
found
me.
A
co
is
a
multiple
actually
from
some
expertise,
even
better
than
I
appear
on
side,
because
I
can
be
on
screen,
and
it
seems
that
you
can
see
me
more
clearly
than
you
can
see
me
outside.
B
B
That's
one,
so
this
is
the
the
status
of
the
room
right
now
and
for
the
first
problem
entity
do
is
the
how
efficient
guidance
document,
so
we
have
CL
our
document,
Schaefer
designed
and
the
write
up
is
ready
and
they
will
move
during
and
after
this
session
and
for
the
second.
Why
is
the
crypto
drop?
B
This
drug
has
been
on
the
vu,
but
we
have
received
some
comments
and
we
are
waiting
for
some
decisions
on
the
Lister
to
clear
up
all
the
issues
with
and
and
the
sense
of
deep
end
this,
so
that
we
can
see
how
we
can
move
over
and
for
Coco
Everett
I.
This
is
some
ongoing
work
right
now,
because
this
one
has
actually
inspired
for
a
while,
but
I.
B
I
recently
goes
to
this
rotten
really
found
that
this
some
import,
important,
guidances
or
guidance
for
Dementors
I
think
this
is
something
that
school
the
whole
human
health
center
community
and
then
is
the
tcp
constituent
network
guidance
document
via
each
video
can
prevent
at
this
movie
Oh
next
one.
Please.
B
So
this
is
our
tender
today,
so
we
have
actually,
we
have
received
three
ox,
but
the
third
one
also
has
some
compliments.
I
consent
any
especially
so,
which
you
could
not
make
it
present
and
l
week
this
time,
so
we
actually
have
been
handed
talks,
a
first
why's,
the
PCP
over
konstantinos
network,
from
Connors
comments,
and
the
second
talk
is
the
labor
management
policy
and
the
guidance
for
the
low
power
and
but
which
is
so
work
dropped
from
wahoos.
My
mum
and
bikini.
D
E
E
Okay,
thank
you
next,
please,
okay.
So,
first
of
all,
let's
take
a
look
at
the
status
for
this
document.
The
initial
version
of
the
draft
was
presented
in
Berlin
in
both
awakened
eCPM
working
group
meetings.
So
after
publication
of
this
initial
version
of
the
draft,
there
was
a
lot
of
feedback
received
which
led
to
the
publication
of
version
01,
which
was
presented
in
Seoul.
So
after
that,
we
received
a
lot
of
very
good
comments
from
Michael
sharp
who's
the
CPM
co-chair.
E
So
the
last
date
of
the
document
is
dash
0
2,
which
I
am
presenting
today,
and
this
version
mostly
addresses
the
comments
kindly
provided
by
Michael,
explicit
okay.
So,
first
of
all,
let's
take
a
quick
look
at
the
motivation
for
the
draft,
so
today
we
have
that
there
are
several
application
layer
protocols
that
are
being
used
for
several
Internet
of
Things
scenarios,
so
we
have
constrained
application
protocol
co-op,
which
was
originally
designed.
/
UDP.
E
However,
there's
a
co-op
about
TCP
specification
in
progress,
the
main
reason
being
the
need
to
overcome
problems
with
middle
boxes,
which
are
not
so
friendly,
sometimes
to
UDP
traffic.
So
it
means
TCP
is
being
used
in
this
case.
Then
we
also
have
that
HTTP
to
and
even
HTTP
one
that
one
have
been
used
for
are
being
considered
for
several
IOT
scenarios.
So
TCP
is
used
here
again.
F
E
A
E
Okay,
then,
we
have
further
application
layer
protocols
such
as
XMPP,
which
are
sometimes
used
also
in
IOT
scenarios.
Then
exempli
also
relies
on
TCP
at
the
transport
layer
and
we
also
have
non
IDF
application
layer
protocol
such
as
MQTT,
which
also
use
TCP.
So
a
conclusion
here
is
that
TCP
is
being
used
or
will
be
used
in
many
IOT
scenarios.
However,
TCP
had
been
quite
neglected
for
IOT
scenarios,
at
least
here
in
the
ITF.
So
the
purpose
of
this
document
is
to
offer
simple
measures
for
suitable
TCP
implementation
and
operation
for
constrained.
E
Node
networks
excuse
ok,
so
let's
go
through
the
updates
in
this
version
of
the
document.
First
of
all,
the
intended
status
of
the
document
is
now
informational.
Actually,
this
is
something
that
had
been
agreed
earlier.
However,
the
change
has
been
a
plate
right
now,
so
it
means
that
the
purpose
of
the
document
is
to
report
to
explain
how
TCP
can
be
configured
in
a
suitable
way
for
the
scenarios
we
are
considering.
E
Then
one
section
of
the
document
that
has
been
updated
is
section
2,
which
is
entitled
characteristics
of
CNN's
relevant
participe.
Here
we
have
added
the
explicit
definition
of
constraint,
load
networks.
This
is
literally
taken
from
RFC
7228,
and
the
main
reason
for
this
is
the
fact
that
a
reader
might
have
the
question
the
doubt
about
whether
the
guidance
in
this
document
applies
only
to
6lowpan
or
six
low
networks
or
which
is
actually
the
scope.
So
the
scope
of
these
guidance
is
any
network
which
conforms
to
the
definition
of
constraint.
E
Node
networks,
then
another
section
we
have
updated,
is
the
one
about
the
TCP
maximum
segment
size.
So
in
previous
versions
of
the
document
there
was
there
were
some
recommendations
about
the
fact
that
some
6lowpan
or
six
low
links
define
an
MTU
of
twelve
hundred
and
eighty
bytes,
and
then
the
idea
is
to
avoid
IP
layer
fragmentation.
The
TCP
MSS
has
to
be
set
accordingly,
for
example,
avoiding
to
exceed
120
bytes.
E
However,
we
have
added,
in
this
version
of
the
document,
that
there
are
some
further
links
leading
technologies
which
are
used
in
the
constraint
mode
network
space
such
as,
for
instance,
m
stp,
able
to
dot
11
eh
or
no
roben
IOT,
to
name
a
few
which
support
greater
and
views.
So,
in
this
case,
the
TCP
MSS
may
be
set
to
greater
values
without
incurring
IP
layer
fragmentation,
although
of
course
we
have
to
be
careful
to
adjust
correctly
the
TCP
MSS
to
the
specific
value
for
each
link.
E
Next,
please
another
section:
we
have
updated,
discusses
the
window
size
of
TCP,
so
in
previous
versions
of
the
document
we
were
actually
stating
or
recommending
use
of
a
single
MSS
window
as
a
way
to
reduce
complexity
of
the
implementation.
However,
we
have
modified
the
the
approach-
the
writing
of
this,
and
now
what
we
say
is
we
just
explained
that
a
t-statistic
can
reduce
implementation
complexity
by
advertising
at
is
a
window
size
of
single
MSS
and
can
also
use
a
transmit
the
window
size
of
a
single
MSS,
and
we
explain
that.
E
This
also
opens
the
door
to
adapting
or
tuning
the
the
RTO
algorithm.
However,
this
has
to
be
done
carefully
because
there
exists
some
fundamental
trade-off
behind
the
RTO,
which
is
that
an
aggressive,
RTO
behavior
reduces
the
wait
times
before
retrace.
However,
it
also
increases
the
probability
of
incurring
serious
timeouts,
so
this
might
lead
to
unnecessarily
wasting
scarce
resources
such
as
energy
or
bandwidth,
which
is
something
that
we
need
to
take
care
about
next,
please.
E
So
still
in
the
same
section
about
RTO
estimation,
we
still
talked
briefly
about
the
Coco
RTO
algorithm.
However,
we
do
it
now.
As
a
related
note,
so
Coco
RTO
is
the
advanced
RTO
algorithm,
that's
being
defined
in
the
core
working
group
for
the
co-op
protocol.
That's
defined
for
operation
of
a
UDP,
so
the
text
here
is
now
just
as
a
related
note
for
informational
purposes.
E
However,
it's
probably
still
beneficial
for
a
reader
to
find
that
this
algorithm
has
been
evaluated
and
compared
actually
with
the
TCP
RTO
algorithm
and
also
some
state-of-the-art
TCP
based
RTO
variants,
and
because
Coco
has
been
specifically
designed
for
IOT
scenarios.
It
appears
to
outperform
these
other
algorithms.
E
Then
another
section
that
has
been
updated
is
the
one
about
delayed
acknowledgments.
So
now
we
explain
without
making
particular
assumptions
about
whether
some
scenarios
are
more
common
or
not
than
others.
We
explained
that
the
late
acknowledgments
are
not
recommended
for
scenarios
with
mostly
transactional
type
of
traffic,
with
transaction
size
of
at
most
one
MSS.
That's
because
the
later
knowledge
means
would
just
contribute
delay
here.
E
There
would
be
no
benefit
and,
on
the
other
hand,
delay
that
knowledge
months
could
be
useful
to
reduce
the
number
of
acknowledgments
sent
if
an
appropriate
window
size
is
used
in
scenarios
with
bulk
transfers.
So
this
could
be
positive
to
save
resources
such
as
energy
in
bandwidth
in
constraint,
not
networks.
So
one
of
the
changes
has
been
to
remove
any
particular
assumption
about
whether
these
scenarios
or
the
scenarios
are
more
common
than
others
or
not.
Next,
please.
E
We
have
also
added
text
to
the
security
considerations
section,
so
there
are
TCP
options
that
improve
security,
such
as,
for
instance,
and
the
five
signature
option
or
TCP
authentication
options.
The
city
ayo.
However,
security
comes
at
the
cost
of
increased
overhead
and
complexity,
so
we
need
to
be
aware
of
this
and,
for
example,
md5
adds
18,
bytes
or
TCP
segments
and
TC
dao
typically
has
a
size
of
16
to
20
bytes.
E
E
Finally,
the
document
has
an
annex
which
has
the
purpose
of
reporting
the
main
characteristics
of
lightweight
icity
implementations,
and
we
have
added,
in
this
version
this
table
that
you
can
see
in
the
slide
which
meadow
is
not
yet
complete.
This
is
in
progress,
but
you
can
see
that
the
purpose
is
to
allow
some
quick
identification
of
each
other
futures,
supported
or
not
by
different
lightweight
tcp
implementations,
and
also
they
would
be
to
to
collect
requirements
in
terms
of
memory
for
each
TCP
implementation.
E
As
you
can
see,
also
the
sections
about
riot
and
open
wsn
are
currently
empty,
so
we'd
also
like
to
to
make
a
call
to
the
working
group
so
that,
if
anyone
is
familiar
with
details
on
these
specific
specific
implementations
or
maybe
someone
considers
that
the
table
should
be
expanded
with
additional
light
with
TCP
implementations.
Please
get
in
touch
with
us
and,
let
us
know
xmas.
E
Not
sure
if
I
understood
correctly,
what
you
mean
so,
for
example,
we
mentioned
the
fo
as
a
way
to
solve
the
problem
that
you
may
have
little
boxes
in
the
end
to
end
communication.
So
the
idea
is
ok
to
describe
the
options
of
TCP
that
can
be
relevant
because
someone
will
have
to
implement
icity
in
a
lightweight
in
a
constraint
device.
E
So
there
are
several
options
in
TCP,
so
the
idea
would
be
to
report
the
the
main
ways
how
the
TCP
implementation
can
be
configured
in
a
suitable
way
for
some
specific
scenario,
which
comprises
the
characteristics
of
a
specific
device.
Characteristics
may
be
off
of
the
network
requirement
from
the
application,
so
they
would
be
to
collect
the
most
relevant
information,
at
least
from
the
main
options.
E
G
So
when
it
comes
to
TCP
pasco
open
option-
let's
talk
about
this
specifically.
So
what
what
is
the
draft
considering
here?
Are
we
trying
to
say
that
tcp
fast
option
as
token
option
might
be
more
relevant
towards
constrained
networks
because
sort
of
sense
the
data
along
with
the?
So
what
are
we
trying
to
conclude
there
and
that
well.
E
So
the
document
is
informational,
so
we
are
not
kind
of
mandating
anything.
That's
a
first
thing
to
consider.
So
the
purpose
is
to
explain
that
away
to
avoid
having
to
establish
a
new
tcp
connection.
Every
time
the
sensor
is
sending
some
data
is
to
use
TFO,
so
you
embed
data
within
the
same
packet.
So
that's
a
way
to
to
avoid
this
and
to
avoid
the
problem
with
the
middle
box
that
you
might
have
in
between.
G
E
F
If
you
do
security,
you
need
more
bites,
but
what's
the
guidance
here
like
should
I
do
this,
or
should
the
guidance
be
that
you
should
anyways
have
pls
or
object
security
or
scope
on
top
of
this,
and
doesn't
make
sense
to
do
this
at
this
layer?
I
I,
think
the
point
of
the
guidance
document
should
be
that
there
are
these
options.
You
don't
need
them
because
you
should
have
security
anyways
above,
but
just
the
fact
that
saying.
Oh,
if
you
do
this,
you
you
send
more
bites
on
the
network.
I.
E
Well,
thanks
for
the
suggestion,
so
I
think,
if
you
can
provide
input
on
this,
we
will
really
welcome
it.
And
yes,
so
the
idea
is
to
explain
okay,
which
are
the
different
options
available,
which
is
the
impact
and
of
course,
if
we
can
provide
options
about
okay,
if
you
use
something
else,
maybe
it's
better
make
it
reduces
the
per
head.
Then
that's,
of
course,
beneficial.
D
So
one
thing
I
want
to
add
more
it
like
to.
That
is
that
this
is
not
a
working
group
document
it
right
so
like
once
it
becomes
a
document.
Then
it's
up
to
the
working
group
like
it's
not
out
to
Carlos
anymore
I'd
like
really
to
to
see
if
the
there's
guidance,
neither
or
not
I
then
decides
it's
going
to
go
on.
That's
how
I
see
it
character.
H
Carolyn
so
Carlos
I,
really
thank
you
for
this
work.
I
think
it's
going
to
be
important
over
time.
I
was
the
author
of
the
ms2
p
draft
that
you
referenced
earlier,
that
has
the
MTU
of
1500
octets
I,
found
out
pretty
late
in
the
game.
That
and
Eric
can
correct
me
if
I'm
wrong,
but
if
a
node
supports
more
than
twelve
eighty,
then
it
must
be
able
to
do
path
MTU.
H
So
I
would
say
that
in
you
know
in
your
document
you
should
probably
provide
guidance
that
unless
your
application
really
has
a
strong
reason
to
have,
you
know
mt
use
longer
than
1280.
You
should
probably
stick
with
that
assumption,
because
it
wouldn't
be,
for
example,
to
say
here's
you
know
we're
making
a
lightweight
implementation
of
tcp,
but
it
just
pushes
you
know
the
complexity
somewhere
else.
So,
okay.
I
Robbie
Simpson
so
first
off.
Thank
you
I'm,
so
glad
to
see
work
on
tcp
on
constrained
networks.
So
have
you
considered
adding
anything
about
actual
congestion,
control,
algorithms
right
so
I
know
most
of
the
world
probably
looks
at
new
New,
Reno
and
stuff
like
that,
but
there's
a
lot
of
intricacies
when
it
comes
to
pinterest
and
control
algorithms
and
potential
guidance
we
could
give
for
constrained
networks
and
their
stuff
even
out
there
that
might
be
more
applicable
to
wireless,
etc,
etc.
So,.
E
The
answer
would
be
that
not
yet
so
at
this
moment
we
have
mainly
been
considering
a
quite
binary
approach
like
male
influence,
because
they
had
been
so
many
claims
about
this
even
complex,
and
so
on
that
okay,
we
said.
Well,
maybe
you
can
use
a
single
MSS
window
that
reduces
complexity,
and
that
has
some
impact
on
some
mechanisms
that
will
know
it
will
not
have
any
effect.
E
I
E
J
Know
my
name
is
michael
sharpen
speaking
as
gtpm
co-chairs
of
thanks
a
lot
for
this
work.
I
think
this
is
getting
really
useful.
The
TZ
p.m.
quad
chair
I
think
it's
appropriate
to
this
being
informational.
I
think
this
is
move
in
the
right
direction
and
I
also
want
to
remind
the
working
group.
I
mean
if
you
want
changes
in
TCP,
then
please
come
to
TC
p.m.
so
we
own
the
protocol,
but
of
course
we
welcome
informational
guidance
in
other
community,
so
that
might
be
deciding
is
adding
in
the
right
direction.
J
D
A
lot
Michael
an
aside
minutes
right
so
like
at
the
last
meeting,
so
I
took
an
action
item
on
myself
to
talk
to
the
transfer.
They
need
to
find
like
a
TCP
co-author,
for
this
and
and
thanks
to
Michael,
for
a
drink,
to
help
like
Alice
out
like
the
dis
document,
so
Michael
will
be
joining
as
a
quarter
and
help
out
on
the
template
pieces
of
it.
Thanks.
K
Eric
not
burnt
so
yeah,
in
addition
to
confirming
the
empty.
You
thing
right.
If
you
send
about
1280,
you
have
to
be
prepared
to
depart
MP
discovery
and
and
if
you
want
to
go
down
that
path,
I
don't
know
if
you
want
it,
but
but
whether
one
should
then
recommend
to
the
packetization
MTU
discovery
in
TCP,
as
opposed
to
relying
on
the
good
old.
You
know:
ICP
packet,
the
big
messages,
I,
think
that
you
know
so
you
in
getting
into.
K
The
number
is
title
is
packetization
layer,
and
do
you
discover
directly
so
that
I
think
would
be
good
to
pick
a
direction
in
that
space,
but
the
other
one?
That
sort
of
surprised
me
was
this:
the
there
seems
to
be
an
implicit
assumption
that
the
TCP
you're
talking
to
is
following
the
same
implementation
guidelines
when
it
comes
to
sending
with
a
single
packet
right
having
a
window
of
a
single
packet
only
make
sense.
If
you,
the
part
of
your
target,
it
doesn't
do
any
delay
Dax
and
by
default.
Tcp
implementation
do
delayed
outs.
K
K
Both
ends
are
not
implementing
the
same
thing:
they're
both
implementing
TCP
but
there's
a
wide
range
of
allowed
behaviors
in
TCP
and
enhances
and
most
likely,
the
pier
talking
they
will
be
implementing
not
implementing
the
L
vague
recommendations
but
implementing
standard
tcp
with
delayed
eyes.
So
I
think
that
deep,
if
you
only
care
about
sending
a
packet,
a
TCP
packet
once
a
day,
the
the
1
1
packet
offer
or
outstanding
packet
is
ok.
K
E
Yeah,
so
this
actually
last
slide
so
considering
that
the
document
is
at
least
that
the
structure
is
starting
to
become
stable
and
even
the
content
itself.
So
the
authors
of
the
document,
we
would
like
to
ask
to
the
working
group
whether
you
think
that
it
is
a
good
moment
to
adopt
the
document
as
a
working
group
document.
D
B
Yes,
I'm
I'm
here,
so
I
think
it's
a
based
on
the
feedback
from
the
audience
since
berline.
I
think
it's
a
good
time
to
ask
appealing
love
Lisa
to
or
some
confirmation,
but
what
one
one
thing
is
important
that,
as
a
michael
has
says,
speak
over
the
microphone
isa.
If
you
have
some
PCP
and
horses
also
joining
work,
so
that
we
can
make
sure
that
recommendations
in
the
drop
is
the
right
direction.
D
Yeah
Michael
is
going
to
help
out
right,
like
so
to
make
sure
like
it's.
It
doesn't
like
completely
go
far
away
from
tcp
right,
like
20
CP,
so
I
think
so
that
taken
care
of
it's
just
like
procedural
thing.
Do
you
want
to
do
this
now
or
just
on
the
list?
That
was
my
question
ready,
but
you
want
to
do
a
hum
first
and
then
come
from
a
list
or
do
you
want
to
just
go
on
the
list
and
do
it
after
I
think.
B
D
D
G
B
G
A
G
D
D
D
I
G
So
this
work
was
presented
in
I.t
of
97
in
Seoul,
and
the
the
idea
is
about
neighbor
management
policies
in
6lowpan
networks.
So
in
the
last
row
during
the
last
talked,
there
was
no
draft,
so
we
try
to
check
yet
a
general
feedback
from
the
working
group,
whether
it
makes
sense
to
work
on
this
problem
statement
and
we
got
an
enormous
response
post,
which
we
have
a
draft
now
a
working
truck.
We
have
an
individual
submission
here,
so.
H
G
H
G
What
has
changed
since
then,
so,
first
things
in
the
last
presentation
what
we
had
done
was
we
had
presented
a
policy,
a
neighbor
management
policy,
and
what
has
changed
since
then
is,
apart
from
the
policy,
the
signaling
considerations,
the
signaling
recommendations
as
to
how
to
bring
this
policy
into
effect
is
been
taken
care
of.
So
let
me
begin
some
of
the
slides
I'm
going
to
repeat
here
the
neighbor
management.
Why
neighbor
management
is
required,
so
in
case
of
6lowpan
networks
it
is.
G
It
is
difficult
to
anticipate
the
maximum
density
of
the
nodes
in
a
given
Network,
so
how
much
of
the
tablespace
do
you
allocate
for
the
neighbor
cache?
So
that
is
the
primary
question
that
has
been
so.
Whatever
take
cash?
Sighs
you
allocate
at
some
point
of
time
if
the
density
is
very
high,
it's
going
to
get
it's
going
to
overflow.
So
in
that
case,
how
are
you
going
to
handle
the?
What
are
the
entries?
G
Are
you
going
to
retain
in
that
neighbor
cash
now,
prioritization,
based
on
the
link
quality
estimation,
doesn't
always
work
in
some
cases
you
might
have
to
retain
the
cache
entries
which
are
more
relevant.
For
example,
it
might
not
be
advisable
to
evict
and
enter
based
on
the
direct
child,
a
routing
child.
So
because
what
happens
is
he
it?
It
has
a
ripple
effect
ripple
effect
in
terms
of
all
the
grand
child's
are
also
evicted.
So
there
is
a
there
are
some
implications
in
terms
of
which
entries
you
can
awake
from
the
table.
G
G
G
Expectation
takes.
The
final
expectation
of
this
neighbor
management
policy
is
that
it
should
result
in
a
stable
network.
So
when
I
say
stable
network,
the
routing
adjacencies
should
not
change
periodically
I
mean
it
without.
Without
such
a
neighbor
management
policy,
you
will
have
a
lot
of
churn
with
between
the
neighbors
and
you
won't
ever
get
a
stable
routing.
Adjacencies.
G
Another
thing
is
once
the
neighbor
is
accepted.
It
has
to
be
guaranteed
that
all
the
associated
resources
are
present
to
serve
that
neighbor,
so
so
a
one
of
so
in
the
adjoining
diagram.
If
you
see
there
what
is
mentioned
is
there
is
a
verily
hope
cited
network
in
the
first
place
and
with
the
neighbor
management
policy
sort
of
load
balances
the
overall
network.
G
Now
one
of
the
things
that
we
took
into
consideration
while,
while
while
while
putting
up
a
general
guideline,
says
this
guidelines
should
be
protocol
agnostic
as
far
as
possible,
we
didn't
consider
ripple
specifically
or
any
key
management
protocol
specifically,
but
we
had
to
take
some
example,
so
we
as
an
example
we
have
taken
ripple
and
both
of
its
mode
of
operations
and
pana
as
a
cue,
are
the
key
management
protocol
next
slide.
Please.
G
So
we
have
considered
a
holistic
approach
towards
neighbor
management
when
I
say
holistic.
Apart
from
the
routing
protocol,
we
also
consider
the
the
key
management,
the
initial
key
handshake
procedure.
Now
that
has
serious
implications
on
the
neighbor
cash
management.
So
that
is
why
it
has
to
be
taken
into
consideration.
So
in
the
sample
example
network
that
we
have
the
it
subpoena
based
key
authentication
protocol
key
management
protocol,
which
is
which
is
a
which
is
what
wisin
has
mandated.
G
The
draft
also
explains
the
different
network
management
when
it
comes
to
our
appeal:
what
are
the
different
options
available,
how
to
serve
the
different
mode
of
operations
for
ripple?
So
now,
what
are
the
cases
in
which
the
neighbor
table
update
happens?
So,
first
cases
during
initial
key
authentication,
the
relay
element
has
to
be
selected.
Now
there
is
a
relay
element
discovery
here
when
I
relay
Liam
in
discovering,
so
you
need
to
so
when
that
discovery
happens,
the
Cap'n
a
client
has
to
make
an
entry
on
behalf
of
the
pyaari.
G
The
theory
has
to
make
an
element
has
to
make
an
entry
on
behalf
of
the
Panetta
clan,
so
the
so.
This
is
the
this
is
the
signaling
that
is
in
war,
so
the
subsequently
once
the
authentication
is
finished,
then
the
rpi
ripple
comes
into
picture.
There's
a
DI
messaging.
There
will
be
a
parent
node
entry.
There
will
be
a
routing
direct
child
entry.
G
So
in
the
example
that
you've
seen
here,
if
you
see
the
p3,
the
node
n3
has
to
routing
direct
to
routing
parents
and
when
routing
child
and
one
authentication
session
in
progress,
one
more
one
more
important
thing,
while
working
on
this
draft
that
we
had
come
across
is
the
implicit
were
such
experiences.
Signaling.
What
I
mean
is
in
case
of
constraint,
network.
You
don't
want
to
add
additional
overhead
in
terms
of
NS
in
ipv6
ntp
procedures,
so
as
far
as
possible.
G
If
it
is
possible
for
you
to
add
the
neighbor
cache
entries
on
behalf
of
existing
signaling,
then
that
has
to
be
used.
So
this
is
what
this
is
the
signaling
recommendation
as
part
of
this
job.
So
when
I
see
implus
signaling,
what
I
mean
is
the
neighbor
cache
entries
can
be
added
as
part
of
variable,
signaling
or
as
part
of
pana
discovery
signaling.
In
certain
cases
it
is
not
possible,
for
example,
in
case
of
ripples
non
storing
mode.
G
It
is
not
possible
to
make
such
an
entries,
in
which
case
you
have
to
work
out
a
solution
based
on
ipv6
ntp,
ipv6,
NDP,
RFC,
656
sense
and
five
already
defines
a
procedure
wherein
you
can
send
an
NS
with
an
arrow
option.
You've
required
to
register
entry
to
register
the
neighbor
cache
entry
next
slide.
Please.
F
Just
a
quick
comment,
so
in
six
loader
is
work
on
new
neighbor
discovery
for
cut
shred
network,
so
it
would
be
good
to
see
how
this
relates
to
that
work.
There's
one
lightweight,
never
discovery
secure,
like
whatever
discovery,
I
think
it
will
be
presented
in
the
six
lo
session.
Is
it
tomorrow?
So
you
will
be
good
to
know
how
how
this
one
yeah.
G
So
this
so
there
two
considerations
for
this
draft
one
is
the
signaling
considerations.
Another
is
the
policy.
How
do
you
actually
populate
the
table
which
all
entries?
How
do
you
retain
the
increase
which
all
entries?
Do
you
give
the
priorities?
So
the
signaling
considerations?
We
are
not
adding
any
new
signaling
here.
We
are
as
far
as
possible,
depending
upon
the
existing
specifications
from
six
low
working
group
towards
doing
the
signaling,
but
in
certain
cases
we
are
recommending
certain
things,
for
example
in
case
of
ripple.
G
G
So
what
are
the
different
neighbor
management
operations?
So
there
are
three
primary
operations,
the
installation
eviction
and
the
reinforcement,
so
as
part
of
insertion,
if
there
is
a
simple
logic
as
in
if
the
table
space
is
available
inserts
now,
this
is
the
this
is
the
policy
that
is
by
default
using
by
most
of
the
operating
system.
G
So
the
major
problem
with
this
this
particular
policy,
is
that
in
case
of
ripple
there
is
a
multicast
di
o
that
is
sent
now,
if,
if,
if
all
the
nodes
are
going
to
add
a
neighbor
cache
entry
based
on
this
di,
oh
then
it's
going
to
overflow.
The
table
is
going
to
overflow
with
all
the
parent
entries.
Similarly,
if
the
same
parent
is
chosen
by
all
the
child
nodes,
then
the
same
parent
will
have
all
the
Dow
entries
coming
to
it,
and
the
neighbor
cache
entry
will
be
overloaded
with
the
routing
direct
child
entries.
G
Similarly,
for
PR,
it
is
curved.
It
is
the
same
procedure
procedure
just
that
the
stage
is
different
in
case
of
eviction
like
I
mentioned
in
case
of
eviction.
If
a
routing
child
is
evicted,
it
not
only
impacts
the
routing
child,
but
it
also
impacts
all
the
subsequent
grand
child's
because
in
case
of
storing
mode
every
all
the
child
go
to.
This
goes
via
the
same
parent,
so
it
not
only
impacts
that
impacts
that
child,
but
all
the
complete
subtree
behind
beneath
that
child.
G
Now
one
of
the
important
consideration
here
is,
if
you
see
the
point
where
everything
non-preferred
parent
and
see
now
everything
non-preferred
parent
neighbor
cache
entry
is
usually
possible
without
much
implications.
What
I
mean
here
is:
if
there
are
ten
parents
to
be
say
that
are
available
in
the
table,
neighbor
cache
entries,
then
it
is
possible
to
Evek
one
of
the
parent
entries
and
make
space
available
for
some
other
other
other.
So
my
point
is
you
can
easily
evict
a
non
non
preferred
parent
NC
and
make
the
spacer
will
go
something
else
now.
G
This
is
one
of
the
considerations
that
we
make
use
of
when
we
when
we
apply
the
policy.
Now
what
is
next,
the
reinforcement,
the
neighbor
cache
entries
up,
going
to
be
present
in
the
table
for
quite
some
time
so
the
this.
So
the
link
quality
estimation
has
to
be
done
on
the
periodic
basis.
The
doc
the
draft
does
not
make
any
the
drop,
does
not
define
any
specific
procedure
on
how
this
link
is.
Commission
is
going
to
be
done.
This
is
implementation-specific.
G
The
reinforcement
part
is
mentioned
here
just
for
making
sure
that
all
the
nodes
have
to.
Although
all
the
implementations
have
to
consider
some
sort
of
a
reinforcement
policy,
for
example,
it
might
be
a
passive
or
active
hearing,
or
it
might
be
explicit
probing
which
is
done
by
quantity,
for
example.
G
Now,
clearing
unused
navel
tapered
enter
is
now.
This
is
again
important
in
case
of
constraint,
node
interest.
This
is
constrained
load
networks.
This
is
especially
difficult
because
there
is
no
explicit
signaling
when,
when
a
route
changes,
for
example,
or
even
if
the
route
changes,
if
there
is
an
explicit
signaling
involved,
for
example,
in
the
form
of
in
Peter,
it
is
easy
to
get
I
mean
it
is
not
a
very
deterministic
way
of
clearing
up
the
entries.
G
So
the
point
here
is
route
in
validation
is
especially
important
and
it
if,
if
there
is
an
optimized
route
in
validation
procedure,
only
in
that
case,
you
will
be
able
to
clear
up
the
unused
nc's
in
case
of
non
storing
more
now,
as
this
is
especially
important
because
in
case
of
non
storing
mode,
there
is
no
NP
doubt
there
is
no,
no
part
ow
involved.
So
how
do
you
clear
the
entries?
G
In
this
case,
we
have
recommended
making
use
of
NS
with
lifetime
of
0,
which
is
as
per
out
of
6
cents
and
5
ipv6
ntp
procedures
in
case
of
p
re.
Now,
the
pier
is
a
theory
is
an
element
which
does
not
keep
any
state
information
on
behalf
of
panic
line.
So
how
do?
How
do
you
clear
the
entries?
So
there
is
no
way,
except
that
unless
and
until
there
are
some
clues
available
as
part
of
the
authentication
procedure,
but
since
PR
is
completely
stateless,
there
is
no
such
kind
of
clues
are
not
available.
G
G
This
is
one
of
part
of
the
recommendation
that
is
done
by
the
draft.
What
is
this,
what
is
the
signaling?
What
is
the
signaling
use
for
neighbor
to
neighbor
entry
management?
So,
if
you
see
there
are
three
flows
that
are
specified
here:
pra
discovery,
storing
mode
of
operation
and
non
storing
mode
of
operation,
yeah
I
think
you
need
to
wind
up
sorry,
okay,
so,
basically
what
it
says
is
that
there
is
a
way
to
do
an
implicit
signaling
as
well
as
explicit
signaling
in
case
of
non
showing
mode
of
operation.
G
There
is,
there
is
a
requirement
that
you
do
and
explicit
signaling
in
the
form
of
NS
with
aro
option,
while
in
case
of
launch
in
case
of
storing
mode
of
operation,
you
can
depend
upon
di,
oh
and
our
messaging.
In
case
of
PRA
discovery.
There
is
an
unsecure
Dennis
for
which
you
get
a
unsecured
na,
so
there
is
a
difference
between
you
know
what
kind
of
security
is
available
at
which
stage
X
life
is
so
the
sample
policy.
Now
this
is
the
one
of
the
critical
point
here.
G
The
sample
policy
is
based
on
reservation,
so
you
have
a
tablespace.
You
make
a
reservation
for
routing
direct
child's
as
well
as
pyaari
authentication
sessions.
Now,
if
the
parent
elements
can
be
occupy,
the
parent
elements
can
be
filled
up
in
all
the
places
because
it
is
possible
to
edit
those
entries
if
required.
So
the
point
is
that
the
table
space
will
be
properly
utilized
in
case
routing
childs
are
not
available
or
authentication
sessions
are
not
available.
G
One
of
the
things
that
is
mentioned
on
this
slide
is
about
the
graceful
rejection
of
Dow
and
panel
messages,
so
in
case
of
implicit
signaling,
it
is
important
that
there
has
to
be
some
sort
of
rejection
mechanism
available
in
the
signaling.
For
example,
if
you
send
a
Dow,
the
table
is
full.
There
is
a
Dow
with
negative
acknowledgement
present,
but
in
case
of,
but
similarly
in
case
of
penna
signaling,
such
a
negative
mechanism
is
not
available.
G
G
For
example,
if
a
parent
nodes,
neighbor
cache
is
full
and
it
sends
a
DI,
oh
there
is
a
good
chance
that
some
other
child
might
come
up
and
select
that
node
as
a
parent.
So
how
would
this
child
come
to
No
Child
load
come
to
know
that
the
parent
does
not
have
enough
space
available,
so
the
currently.
There
is
no
way
to
know
this,
because
this
is
a
currently
it's
a
reactive
policy.
So
what
we
are
recommending
here
is
there
might
be
some
solution
possible
based
on
a
proactive
approach.
G
G
The
NC
metric
has
to
be
advertised
as
part
of
di
o
messaging.
Now.
One
more
important
thing
here
is
that
this
proactive
approach
applies
to
not
only
the
ripple
protocol
but
as
well
to
the
Pinet
discovery
message
incredible
now.
The
metric
containers
that
are
available
with
the
ripple
has
to
be
shared
between
panel
discovery
messaging,
as
well
as
ripple
anyways,
currently
based
on
the
drab.
So
there
is
one
question
that
is
asked
here:
can
ripple
matrix
containers,
be
reused
by
another
protocol
and
I.
Don't
see
any
reason
why?
G
G
Yeah,
so
basically,
there
are
some
questions
that
we
have
asked
here.
Should
we
consider
a
signaling
extension
in
for
proactive
mode,
not
as
part
of
this
draft,
because
this
is
this
specifically
the
guidelines
and
policy
draft?
And
secondly,
we
have
a
question
regarding
how
do
other
implementations
take
care
of
finding
out
or
discovering
the?
How
would
the
parent
node
come
to
know
about
the
global
ipv6
address
of
the
child
load,
which
is
required
for
resolving
the
solid
cheddar?
So
these
are
some
questions
that
we
wanted
to
ask.
G
This
is
what
we
have
thought
about
it
and
please
check
if
it
makes
sense.
So
as
part
of
this
work,
we
are
considering
only
the
implementation
guidelines
and
if
there
are
any
extensions
that
have
to
be
done,
then
we
go
about
according
to
I
mean
whatever
the
working
group
relevant
working
group
is,
for
example,
in
case
of
you.
If,
if
the
proactive
approach
has
to
be
followed,
then
we
go
with
the
role
working
group
or
if
there
is
any
signaling
change
for
that
matter
somewhere
else,
then
we
go
accordingly
with
that
working
group.