►
From YouTube: IETF114-SNAC-20220725-1400
Description
SNAC meeting session at IETF114
2022/07/25 1400
https://datatracker.ietf.org/meeting/114/proceedings/
A
A
Thank
you
very
much
everybody
for
coming
to
the
snack
bath,
and
so
this
is
working
group
forming
buff
and
we'll
kind
of
share
our
goals
before
going
forward
and
there's
quite
a
bit
of
remote
participants.
So
when
you
talk,
please
state
your
name
or,
like
you
know,
go
use
your
app
to
sign
on
to
the
queue
and
next
slide
go
to
the
notepad
yeah.
So
this
meeting
is
bound
by
the
noteworld.
So
we're
not
expected
to
read
all
the
text.
A
A
A
So
what
we're
trying
to
do
is
since
it's
like
a
bath,
we
are
trying
to
focus
a
lot
on
the
problem
statement
itself
and
see
if
we
need
to
work
on
this
and
we're
going
to
spend
the
bulk
of
the
time
of
the
meeting
discussing
the
problems
and
not
really
the
solutions.
A
So
if
you
have
questions
about
anything
that
people
talked
about,
please
feel
free
to
invoke
them
and
say,
like
hey,
I
had
a
question
on
whatever,
which
is
not
a
clarifying
question,
why
this
is
necessary
and
so
on.
So
you
can
ask
those
questions
later
and
then
we
have
a
few
questions
before
we
start
discussing.
A
A
So
this
is
like
verbatim
from
like
rfc
5434.
So
what
are
we
trying
to
do
here
right?
So
we
want
to
figure
out
if
this,
I
don't
know
if
it's
like
too
difficult
to
read,
but
it's
pretty
much
summarizing
what
I
was
saying
before,
like
whether
there's
a
problem
with
solving
and
is
ietf
the
right
place
to
solve
it.
That's
like
a
high
level
goal
of
what
we're
trying
to
do
here
so
and
that's
what
we're
shooting
towards.
A
So,
if
you
see
us
cutting
you
off
or
like
cutting
the
mic
line
at
some
point,
this
is
really
the
goal,
because
we
want
to
get
to
a
solution
at
the
end
of
the
day
today.
Thank
you
and
that's
it.
I
think
we
can
swap
over
to
ted's
presentation.
So
if
you
have
any
questions
about
the
agenda,
now
would
be
a
good
time
to
ask.
B
Okay,
yeah:
I
might
want
to
do
that
because
we've
got
all
these
charts
now,
so
we
want
to
flip
back
and
forth
all
right,
so
I'm
gonna!
Just
let's
see,
can
you
guys
hear
me
back
there?
B
Okay,
great,
we
got
some
instruction
from
karsten
about
how
to
use
the
mic.
So
I'm
gonna
talk
a
bit
about
the
the
stub
networks
problem
that
that
we
saw
and
that
we'd
like
to
to
discuss
in
the
itf.
D
E
B
Well,
if,
let's,
let's
just
point
this
at
me,
I
can
read-
I
can
read
that
okay,
so
yeah,
so
the
problem
statement.
Basically,
we
already
have
this
ability
that
we've
developed
in
the
ietf
over
the
last.
However
many
years
that
if
you
have
like
a
some
kind
of
host-
and
you
want
to
connect
it
to
your
network-
you
can
just
connect
it
to
the
network.
B
B
Okay,
yay,
okay,
so
I'm
gonna
try
and
stand
right
in
front
of
the
mic
and
hopefully
we'll
be
able
to
see
the
slides.
B
C
B
F
C
H
B
So
the
problem
we're
trying
to
talk
about
here
is
we
we
are.
We
already
know
how
to
connect
hosts
to
networks
pretty
much
automatically
like
you
know,
you
might
have
to
punch
in
some
authentication
information
or
something
like
that.
But
but
it's
an
understood
problem.
We
know
how
to
do
it.
You
can
connect
your
your
phone
or
your
laptop
or
whatever
to
any
network
that
you
need
to
and
the
infrastructure
to
do.
B
That
is
there,
but
the
problem
we
have
is
that
we
don't
have
that
same
ability
in
the
case
of
a
stub
network,
and
so
this
became
an
issue
for
it
was.
It
was
an
issue
that
was
high
on
our
radar
at
apple,
because
we
wanted
to
be
able
to
connect
iot
networks
to
infrastructure
and
infrastructure,
meaning.
I
B
Your
home
wi-fi-
and
we
need
to
do
that
automatically
we
didn't
want
to
have
we
didn't
want.
We
didn't
want
the
end
user
to
have
to
be
an
expert
to
make
it
work
so
and
just
to
talk
about
like
the
problem
that
we're
trying
to
solve
here.
We
want
hosts
that
are
on
these
stub
networks,
stub
network,
just
to
just
to
talk
about
that.
A
little
bit
is
a
is
a
network,
that's
attached
to
another
network
dependent
on
that
network
and
doesn't
provide
routing.
B
So
so
we
wanted
to
be
able
to
attach
that
kind
of
network
to
an
infrastructure
network.
We
wanted
mutual
reachability
between
hosts
on
the
infrastructure
and
hosts
on
the
stub
network
and
mutual
discoverability
so
like.
If
you've
got
a
light
bulb
on
the
stub
network,
you
want
to
be
able
to
control
that
light
bulb
from
a
device.
That's
on
the
infrastructure
network,
so
see.
Is
there
anything
else
to
say
about
this
yeah?
B
B
And
you
know,
we've
seen:
we've
we've
seen
solutions
to
this.
That
sort
of
happen
accidentally
to
show
you
the
topology
here.
Basically
home
network,
you
plug
another
ce
router
into
your
home
network.
Suddenly
you
have
two
networks,
but
it
doesn't
work
that
well.
B
This
doesn't
really
solve
our
problem.
We
in
theory
devices
on
the
interlink
can
reach
the
outer
devices
on
the
outer
link,
but
there's
no
reachability
in
the
other
direction
and
there's
no
service
discovery
between
links-
and
you
know,
devices
on
both
links
can
reach
the
internet,
and
so
you
actually
see
these
networks
fairly
frequently
in
people's
homes
accidentally,
they
didn't
intend
to
set
up
a
network
like
this,
but
they've
set
one
up,
and
then
they
have
all
these
problems.
B
So,
just
to
talk
about
goals,
the
primary
goal
that
that
I
had
for
this
work
and
that
I
I
hope
is
of
interest
to
the
itf-
is
enabling
mutual
reachability
between
stub
hosts
and
infrastructure
network
hosts
enabling
mutual
discoverability.
So
the
ability
to
like
suppose
you
want
to
find
a
printer
on
the
stub
network.
You
can,
even
if
you're
on
the
infrastructure
network
and
vice
versa,
and
also
the
ability
to
do
things
like
firmware
downloads
for
hosts
that
are
on
the
stub
network.
B
It
would
also
be
nice
to
be
able
to
actually
integrate
the
stub
network
into
the
into
the
routing
infrastructure
of
the
network.
That's
capable
of
doing
that,
and
it
would
be
nice
to
be
able
to
infrastruct
to
integrate
the
discovery
infrastructure
on
the
stub
network
into
the
infrastructure
on
the
main
network,
so
that
devices
that
are
on
the
stub
network
can
be
discovered
not
only
from
the
adjacent
infrastructure
link
but
from
any
link
on
the
network.
J
B
C
B
So
some
constraints,
we
can't
change
the
existing
network.
This
is
a
huge
problem
right
like
we,
we
actually
looked
at
this
problem
in
homenet
and
came
up
with
a
solution,
but
the
solution
required
a
complete
change
to
how
the
devices
on
the
on
the
home
network
worked.
F
B
That
just
didn't
fly
we
never!
That
was
a
failure.
We
never.
We
never
managed
to
get
any
home
routers
that
anybody's
shipping
to
implement
that.
So
basically,
this
has
to
work
without
anything
changing
without
the
user
having
to
buy
a
special
router
for
their
home
network
that
supports
it
and
also
like.
We
can't
really
require
changes
to
host
on
the
infrastructure,
because
once
again
you.
B
Already
bought
those
hosts,
it
just
has
to
work
for
devices
that
are
connected
to
the
stub
network.
There's
kind
of
two
two
scenarios,
one
is
you've,
got
a
a
green
field
network.
Where
you
know
you
don't
already
have
an
existing
way
that
devices
on
that
network
behave,
and
so
it's
okay
to
say
how
they
behave,
and
you
know
the
example
would
be.
You
know
an
iot
network
where,
right
now
the
iot
network
doesn't
support
ip
routing
and
so
how
it's
going
to
support
ip
routing
is
something
that
we
can
define.
B
Another
example
would
be
like
the
double
nat,
except
you,
you
don't
wanna,
you
wanna
actually
have
mutual
discoverability
and
all
that
nice
stuff
and,
in
that
case,
hosts
just
have
to
work
so
and
then
just
some
topology
constraints
to
keep
the
problem
small.
We
don't
want
to
do
routing
so
stub
networks
are
not
transit
networks.
B
It's
possible!
There
were
some
questions
that
came
up
on
the
mailing
list,
so
I
just
kind
of
kind
of
represented
these
here.
It's
it's
totally
possible
for
there
to
be
more
than
one
stub
router
connected
to
the
stub
network
that
has
to
work.
It's
possible
because
we're
the
users
are
just
going
to
connect
these
to
the
networks
right
like
like.
B
B
So
you
know
the
obvious
simple
topology
is
just
you
have
a
c
router.
You
have
a
homeland,
you
have
a
stub
network,
you
have
a
single
stub
router,
very
simple,
but
we
also
need
to
support
this
use
case
where
you
just
happen
to
have
two
or
n
stub
routers
that
are
all
connected
to
the
same
stub
network
and
that's
a
topology
that
could
cause
some
problems.
Where
you
have.
B
B
That's
got
to
work,
or
at
least
not
fail,
some
assumptions
about
how
we
might
solve
this
problem.
We
don't
really
want
to
get
into
solutions,
but
but
we'll
talk
a
little
bit
about
the
solution
that
we've
already
done,
which
you
know
may
or
may
not
be
what
the
working
group
decides
to
to
work
on,
but
that
solution
uses
ipv6.
It
uses
routing
and
it
uses
dns
service
discovery
to
provide
addressability,
routability
and
discoverability
mutually
between
this.
The
the
stub
network
and
the
infrastructure
network.
B
B
So
that's
the
service
discovery
technology
that
that
we've
been
talking
about
and
using,
and
then
just
okay
yeah.
So
this
is
the
last
slide.
So
so,
assuming
that
this
is
work
that
the
ietf
wants
to
work
on,
I
think
that
there
are
some
documents
that
we
need
to
write.
One
of
them
would
just
be
the
basic
solution
that,
like
you,
know,
delivers
the
minimum
viable
product.
B
I
don't
think
there's
any
point
in
having
two
documents
for
the
minimum
minimum
viable
product,
because
it's
not
doesn't
seem
like
it's
that
complicated.
We
could
have
like
a
discovery
document
and
a
routing
document,
but
I
don't
know
that
that's
necessary
and
it's
probably
useful
to
have
them
together,
but
then
we
can
also.
You
know
if
that's
a
success.
If
we
decide
to
work
on
that
and
we
succeed
in
producing
it,
there
are
some
other
things
we
could
do.
B
We
could
talk
about
the
sort
of
stretch
goals,
integrating
with
the
actual
routing
infrastructure,
using
real
g
ways
on
the
stub
network
instead
of
ulas.
If
we,
if
we
go
that
way-
and
you
know
integrating
dnssd
stuff,
so
that's
basically
the
the
the
problem
statement.
A
K
B
I
mean
in
a
sense
like
we're
here
a
little
bit
late
and
the
reason
we're
here
and
not
just
saying
you
know,
screw
publish
a
document
somewhere
else
is
because
this
is
really
the
meat
and
bones
of
like
ietf
stuff.
Like
itf
does
service
discovery,
itf
does
ip
addressing
and
routing,
and
so
it
doesn't
make
sense
in
my
mind,
to
publish
a
document,
that's
specific
to
a
particular,
a
particular
type
of
of
networking
stuff,
a
particular
type
of
stub
network.
B
I'd
like
to
have
us
I'd
like
us
to
document
how
to
make
any
sort
of
sub
network
work.
So
we've
already
needed
this
to
connect
an
iot
network
to
an
infrastructure
network,
and
so
we've
already
done
a
bunch
of
work
on
this
and
jonathan
is
going
to
be
presenting
on
that.
So
that's
kind
of
where
this
is
coming
from.
That's
that's
what
motivated
us
originally,
we
were.
We
were
really
interested
in
getting
this.
B
This
sort
of
802.15.4
mesh
technology
connected
to
home
networks-
and
we
just
didn't,
have
a
way
to
do
it,
but
we
had
all
the
building
blocks,
and
so
we
just
put
the
building
blocks
together
and
we
kind
of
made
it
work,
but
it'd
be
nice
to
have
a
standard
that
says
how
that
happens.
K
B
Well,
so
the
solution
that
we
that
we've
implemented
is
to
use
router
advertisements
both
to
provide
reachability
because
remember
we're.
This
is
a
constrained
problem.
We're
not
solving
the
whole
problem
of
like
the
home
that
tried
to
solve
we're
just
trying
to
solve
the
stub
network
problem
and
for
a
stub
network.
B
B
You
just
use
router
advertisements
for
that
and
then
for
dnssd
we've
been
doing
a
bunch
of
work
in
the
dns
ssd
working
group,
and
so
there's
this
concept
of
an
advertising
proxy
and
there's
this
concept
of
service
registration
and
so
devices
in
the
constraint
network
that
we're
talking
about
use
the
service
registration
protocol,
which
is
a
unicast
dns
update
protocol
to
update
an
authoritative
database
and
then
that
authoritative
database
is
advertised
on
the
infrastructure
link
using
multicast
dns.
So
you'll
hear
more
about
that.
Jonathan's
presentation,
okay,.
A
Thank
you.
Thank
you,
sri
carlos
go
next,
but
before
anybody
joins
a
line,
can
you
also
join
the
line
and
the
meet
echo?
I
know
michael
right,
carlos
is
not,
and
the
line
is
in
a
different
order
than
this.
So
like
yeah,
I
think
we'll
go
with
the
room
line
and
we'll
go
after
that.
Please
join
the
mythical
queue
as
well.
Thank
you.
E
I
was
trying
to
join
the
queue,
was
not
successful,
quick
question
in
the
topology
that
you
presented
did
you
consider
the
possibility
of
like
those
multi-link
topologies
like
changes
on
the
topology
dynamically,
so
the
start
network
connects
through
one
link
and
then
to
through
the
other
theme.
This
is
in
scope.
B
Yeah
this
is
this-
is
this
all
has
to
work
when
things
change?
So
you
know
these
think
about
the
stub
network
router
as
being
essentially
like
a
from
the
from
the
user's
point
of
view.
It's
just
a
it's
just
a
home
device
like
they
don't
know
that
it's
a
stub
network,
router
specifically,
I
mean
they
kind
of
do.
But,
oh
sorry,
I'm
waving
my
hand,
and
so
the
mic
is
pointing
away
and
back
yeah.
B
G
Okay,
so
this
slide
surprised
me
ted,
so
you
said
to
us:
it
has
to
either
work
or
not
break,
and
so,
since
I
have
some
knowledge
of
your
proposed
solution,
I'm
not
sure
how
this
network
either
works
or
doesn't
break
right.
Actually,
could
you
could
you
distinguish
those
those
two
things,
those
two
statements
of
work
versus
not
break.
B
Right,
that's
a
really
good
question,
and,
and
so
the
issue
here,
this
is
a
problem
we
that
we've
run
into
that.
You
know
you
have
devices
that
are
connected
to
multiple
networks
and
to
the
stub
network
and
if
you
just
implement
the
stub
network,
as
you
know,
router
advertisements
pointing
in
two
directions
that
kind
of
works,
but
you
have
some
issues
with
the
addressability
on
the
home
home
networks,
but
the
big
problem
is
for
a
constrained
network.
B
You
need
service
discovery,
mutual
service
discovery
and
doing
mutual
service
discovery
on
two
different
networks
where
there
isn't
necessarily
so
in
this.
In
this
model,
here
I've
been
kind
of
generous
and
sort
of
implied
that
there's
an
internal
router,
that's
doing
the
right
thing,
but
actually
in
practice,
if
this
is
happening
in
someone's
home,
most
likely,
it's
a
double
net,
and
so
so
devices
that
are
connected
to
the
garage
land,
probably
can't
communicate
with
devices
that
are
connected
the
homeland.
B
B
Onto
the
mic
yeah,
so
michael
is
saying
that
he's
asking
whether
it's
really
true
that
the
devices
can't
communicate
back
and
forth
so
in
this
in
this
scenario,
with
the
garage
land
in
the
homeland.
If
you
assume
that
the
internal
router
is
a
double
nat,
a
second
nat
I
should
say,
then
there
should
be
connectivity
in
one
direction
or
the
other,
and
so
one
way
to
solve
the
the
problem
of
communicating
between
devices
like
this.
So
this
stub
router.
B
If
this
is
a
constrained
network,
we
don't
want
to
be
doing
any
kind
of
heavy
data
transfer
across
the
stub
network,
for
example,
to
replicate
the
the
authoritative
zone
that
we're
maintaining
with
srp,
and
so
in
order
to
prevent
that
from
happening
either
we
want
to
go
around
so
we
want
to
use
the
internal
router
as
a
way
to
communicate
between
the
stub,
this
stub
router
and
this
stub
router,
so
as
to
maintain
that
database
or.
B
We
want
to
just
not
have
that
service
available
on
one
link
so
that
the
end
user,
realizes
that
they've
screwed
up
and
and
unplugs
a
device
and
moves
it
around
so
so,
basically,
this
is
not
a
solved
problem
like
we
didn't
come
here
with.
We
did
come
here
with
some
solved.
Some
somewhat
solve
problems.
We
think
we
have
a
decent
solution.
B
It'd
be
really
great
if
the
itf
could
tell
us
if
it's
a
bad
solution
in
some
way,
but
this
particular
problem
is
not
actually
solved
and,
as
I
said,
there's
basically
two
ways
to
solve
it.
B
L
I'm
stuart
cheshire
from
apple
ted,
presented
a
fairly
generic
overview
of
the
problem
statement,
which
is
appropriate
for
this
ietf
work,
but
some
people
like
me,
get
the
head
around
things
better.
If
we
have
a
concrete
example,
so.
C
L
I'm
going
to
try
giving
a
concrete
example,
which
is
the
genuine
reason
we're
here
today
we
have
been
working
on
home
automation
with
homekits
and
now
the
mata
protocol
from
csa
we've
also
been
working
with
thread,
which
is
a
low
power,
low-speed
wireless
network
suitable
for
battery-powered
devices.
L
And
if
you
look
at
how
home
networks
have
evolved,
we
started
off
with
a
pc
with
a
modem
and
then
we
had
wi-fi-
and
we
had
you
know-
maybe
a
pc
and
a
laptop
and
at
every
stage
the
easiest
solution
is
just
to
add.
One
more
device
to
the
wi-fi
network
and
the
whole
home
is
a
big
flat
broadcast
domain.
L
And
last
time
I
checked,
I
have
a
little
over
100
devices
on
my
wi-fi
network
and
they're
all
talking
to
each
other
with
multicast
dns,
which
means
all
these
devices
are
being
bothered
by
multicast
packets.
Saying:
are
you
the
printer?
No
I'm,
not
the
printer,
stop
asking
me
and
as
the
inventor
of
multicast
dns,
you
might
be
surprised
to
hear
me
standing
here
saying
that,
but
multicast
dns
was
designed
20
years
ago,
when
you
had
a
dozen
things
on
a
home
network.
L
L
When
we
wanted
thread
which
is
much
lower
power
and
much
more
appropriate
for
battery
devices,
do
we
want
to
do
the
same
thing?
Do
we
just
want
to
bridge
the
broadcast
domains
and
flood
all
the
traffic
in
both
directions?
Well,
thread
is
a
quarter
megabit
network
and
wi-fi
is
hundreds
of
megabits
continuing
to
make
a
bigger
and
bigger
broadcast
domain
in
the
house
is
not
scalable.
So
that's.
What
led
us
to
this
work
is
we're
the
ietf.
L
We
do
routing
we.
We
have
an
internetwork
protocol,
not
a
lan
protocol.
This
is
not
netbios.
This
is
not
novell
network.
We
actually
have
structured
ip
addresses
and
routers
that
forward.
Packets
and
most
home
users
are
making
no
use
of
that.
So
can
we
make
products
that
can
be
sold
into
people's
homes
that
will
work
99.9
of
the
time,
so
they
don't
generate
expensive
product
returns
without
assuming
that
the
customer
changes
their
home,
wi-fi
changes,
the
home
gateway
understands
anything
they
just
plug
these
things
in
and
they
automatically
configure.
L
We
have
done
some
work
in
that
direction
and
we
have
some
solutions,
but
the
reason
we're
here
is
we
don't
know
for
sure
those
are
the
best
solutions.
L
We
think
the
work
we've
done
has
broader
applicability
than
just
this
narrow
use
case
of
thread
and,
at
the
same
time,
the
expertise
at
the
itf
can
help
us
spot
mistakes
and
do
something
that
works
better
for
all
of
these
scenarios.
So
if
anybody
thinks
that
this
is
some
abstract
academic
exercise,
we're
doing
it
really
isn't
it's
trying
to
clear
the
way
for
companies
to
make
products
that
they
can
sell
and
not
lose
money
on
the
returns
and
have
happy
customers.
M
All
eric
line
alleria
so
staying
on
the
slide,
but
referring
to
something
you
were
talking
about
earlier
it
the
universe
of
things
that
any
work,
a
a
chartered
working
group
might
do
that.
That's
out
of
scope
is
changing.
Anything
that's
in
the
home.
You're
saying
is
everything
on
the
table
for
the
stub
rooter.
Can
we
specify
that
it
must
have
a
satellite
interconnection
or
something
I
mean,
I'm
being
I'm
being?
I.
M
B
So
I
I
don't
think
you
know
I.
I
would
be
a
little
bit
surprised
if
we,
if
we
wandered
far
from
the
solution
that
we
already
have.
But
if
we
did,
I
would
hope
that
it
would
be
for
good
reason,
and
so
that
would
imply
that
that
what
we're
producing
is
better
than
the
solution
that
we
came
up
with
on
our
own
and.
B
M
B
Like
I
mean
speaking
with
my
mdns
hat
on
I'd,
say
hell
no,
but
but
yeah
yeah
in
principle
like.
I
would
not
be
participating
in
that
particular
consensus:
okay,
all
right,
but
but
yeah
so.
A
N
Mentioned
a
lot
did
the
iot
and
effectively.
This
is
a
kind
of
situation
that
we've
been
discussing
for
many
many
years
in
the
iot
working
groups
like
cisco
and
earth,
sislow
and
raw,
and
for
most
of
the
case
we've
been
looking
at.
We
need
either
water.
If
we
go
rotting,
if
we
go
deep
and
that's
not
what
you're
after
or
we
did,
if
it's
just
one
hop
or
two
hops,
but
we
have
a
clear
structure,
we
did
nd
proxy
and
what
we
did
not
do.
It
was
create
more
than
one
prefix.
N
B
Right
so
we
looked
at
that.
That
was,
that
was
definitely
an
option
right
because
we
there
was
already-
and
I,
when
we
started
this
work,
there
was
already
an
ietf
document
that
described
a
backbone
router
that
used
nd
proxy,
so
so
we're
totally
familiar
with
that
work.
The
reason
we
chose
not
to
do
that
is
because
it's
not
scalable,
at
least
that
was.
That
was
our
belief.
So
the
nice
thing
about
routing
is
you
just
you
advertise
a
route
and
it's
very
simple:
the
nasty
thing
about
nd
so
consider,
for
example,
this
topology.
B
B
They
have
to
somehow
maintain
that
common
neighbor
table
and
we
need
to
be
careful
that
we
don't
do
a
lot
of
excess
multicasts,
so
we
want
to
because
they're
so
I
mean
we're
talking
about
devices
like
the
devices
that
you
can
currently
buy,
that
do
this
are
things
like
homepod,
minis
and
apple
tvs,
and
I
know
google
has
a
couple
of
wi-fi
routers
that
do
it,
and
euro
has
some
wi-fi
routers
that
do
it
and
also
there's
there's
a
company.
I
know
of
that,
I
think,
has
it
in
their
light
bulb.
B
So
so
that
means
you
could
have
actually
quite
a
few
of
these
stub
routers,
and
so
we
need
a
technology.
That's
going
to
work
in
that
situation.
You
know
one
option
would
be
to
just
say:
well,
okay,
all
the
stub
routers
will
elect
a
stub
router.
That
will
actually
do
the
routing
that
sort
of
solves
the
problem.
But
then
you
don't
have
redundancy.
B
You
could
do
that
and
then
that
makes
the
neighbor
discovery
problem
a
little
bit
simpler.
But
it's
it's
still
got
scalability
issues,
and
you
know
I
think,
for
like
a
a
network
with
30
devices.
It's
it's
probably
an
okay
solution,
but
we
were
trying
to
think
like
what
do
we
want
to
have
happen
in
the
long
term
as
opposed
to
what
do
we
want
to
happen
in
the
short
term?
B
And
so
that's
why
we
went
with
the
routing
approach
as
opposed
to
the
nd
proxy
approach,
but
but
certainly
the
nd
proxy
like
like
it,
could
be
that
the
working
group
gets
together
and
is
like
oh
well.
Actually,
indie
proxy
was
really
the
right
solution,
in
which
case
you
know,
we'll
wonder
often
and
that'll
be
what
gets
published
and-
and
we
probably
won't
implement
that,
but
but
but
that
doesn't
mean
it's
the
wrong
answer.
So
so
I
certainly
encourage
you
to
to
advocate
that
use
case.
A
Thank
you
thanks
chet
go
ahead
and
then
we'll
take
gmy
from
the
remote.
I
My
question
is:
you
must
know
these
google
wi-fi
boxes.
So
if
you
have
a
large,
I
don't
have
a
large
house,
but
if
you
have
a
large
house,
why
don't
you
buy
several
of
them?
You
put
one
also
in
the
garage
right
and
doesn't
that
solve
the
problem.
B
Yes,
yes
exactly
so
so
I
mean
the
good
news
about
this
topology
as
as
you're
pointing
out
as
best
I
was
pointing
out.
The
good
news
about
this
topology
is
that
it
usually
doesn't
happen
anymore,
because
normally
nowadays,
people
have
mesh
routers
and
so,
for
example,
I
have
this
exact
topology
in
my
house,
except
that
the
internal
router
in
this
case
is
an
ero,
and
so
it's
just
bridging
between
the
homeland
and
the
garage
land,
and
so
those
are
two.
B
Those
are
a
single
land,
and
so
we
just
don't
have
an
issue
with
with
this
particular
problem.
This
this
particular
use
case
really
in
in
my
home.
It's
actually
this
use
case
because,
because
the
homeland
is,
is
yes,
it's
more
than
one
there's
more
than
one
wi-fi
access
point,
but
they're
all
in
the
same
broadcast
domain.
A
D
B
Basically
it
what's
going
to
what's
going
to
determine
whether
whether
the
manufacturer
implements
these
changes
is
whether
they
benefit
from
implementing
these
changes
right.
So
in
the
constraint
network
example
we're
talking
about
a
totally
different
network
environment
with
new
devices
that
haven't
been
sold
on
the
market
before
and
so
yeah.
It's
exactly
the
same
amount
of
work
to
add
this
new
functionality
to
those
devices.
It
would
be
to
add
them
to
the
to
like
an
iphone
or
something
like
that.
B
But
the
difference
is
that
the
manufacturer
of
the
device
that's
going
to
connect
to
this
greenfield
network
is
motivated
to
do
that
and
the
manufacturer
of
the
device
that's
going
to
connect
to
the
ordinary
network
is
not
motivated
to
do
that.
And
so
that's
why.
I
say
that
that
in
the
greenfield
example,
we
can
require
changes
to
the
host,
whereas
in
the
ordinary
example,
we
can't
it's
not
because
it's
easier
in
one
case
than
in
the
other.
G
So
I
think
that
that
also
that
question
and
eric
asked
that
question:
can
we
assume
that
the
routers
can
do
that?
Stub
routers
are
greenfield
and
I
think
the
answer
is
yes
and
you
you
had
some
some.
You
know
well
maybe
blah
blah
blah,
but
I
think
that
we
can
assume
that
we
can.
We
can
do
anything
we
like,
as
eric
said,
including
adding
a
a
satellite
or
a
loon
connection
to
them
right.
If
that's,
if
that's
what
the
working
group
consensus
is
yeah.
G
But
I
want
you
to
go
back
to
your
your
slide
with
the
double
stub
that
that
one
yeah,
no
no
yeah,
no,
that
one
yes
yeah!
So
so
I
actually
think
that
it's
quite
reasonable
that
we
do
do
some
kind
of
election
on
them
as
long
as
we
do
it
on
the
stub
network,
not
in
the
other
network,
and
I
I
think
that
should
be
something
that
we
should
think
about.
G
But-
and
I
know
you
know
this,
so
the
situation
where
people
would
put
this
kind
of
scenario
is
one
where
they
have
a
smart
speaker
and
they
want
to
have
one
in
several
rooms
and
they
don't
always
have
connectivity
from
the
upstairs
to
the
downstairs,
and
sometimes
they
do,
and
sometimes
they
close,
that
metal
door
or
the
door
that
has
metal
in
it
and
the
stub
network
partitions
right,
okay,
and
so
those
partitions
are
completely
random
right.
You
know
you
let
the
cat
out
the
door
up
and
down.
G
Reconverges
for
three
and
a
half
seconds
and
then
partitions
again
yep
right
and
sometimes
you
leave
the
door
open
all
day.
I
G
C
G
Of
things
and
that's
why
people
want
to
put
multiple
stub
routers
is
so
that
they
can
have
connectivity
to
all
these
other
low-power
devices
and
they
want
to
use
the
homeland
as
a
backhaul
right.
Much
like
like
pascal
has
described,
and
so
you
know,
there's
a
bunch
of
different
options,
but
basically
we're
just
we're
trying
to
just
keep
the
network
going
yeah.
That's
what
it
really
amounts
to
right.
O
Hi,
philip
diesel,
so
if
we
are
talking
about
scoping
of
the
of
this
potential
working
group,
my
question
would
be
what
network
technologies
do
you
think
of
in
the
stub
network?
So
if
you're
thinking
that
it
it's
it's
ethernet
like
most
networks
today
this
this
is
certainly
easier
if
you
as
if
you
envisioned
something
like
six
lopan
on
a
stop
network,
and
so
is
there
already
an
idea
how
we
want
to
scope
that.
O
A
Like
philip,
that's
like
really
open
to
discussion
right,
so
that's
something
we
can
like.
There
is
like
a
proposal
for
a
charter
that,
like
ted
put
up,
but
that's
something
that's
open
to
discussion
today
and
like
further
on
the
mailing
list
as
well.
So
that's
we
should
be
flexible
on
that.
Thank
you,
yeah
thanks.
So
thanks
a
lot
ted,
I
think
the
the
exhausted
the
mic
line
and
thank
you
very
much
for
doing
this.
Well.
Jonathan,
please.
B
No
and
thank
you
for
bringing
that
up
because
you
know.
Unfortunately,
I
made
these
slides
in
more
of
a
hurry
than
I
intended
to,
and
I
didn't
think
to
hit
that
particular
point
yeah.
So
it
would
be
really
nice
if
this
were
just
like
rfc
7084
for
stub
networks.
B
I
don't
think
that
we
can
quite
do
that,
but
definitely
you
know
certainly
when
we
did
the
the
thread
border,
router
implementation,
and
I
think
you
know
my
hope
for
this
working
group
would
be
that
this
is
the
case
there
is
here
as
well,
is
that
we
didn't
want
to
invent
a
whole
new
protocol
suite
right.
B
The
goal
here
is
not
to
create
something
like
hncp
for
stub
networks,
it's
more
to
say,
like
here's,
what
you
need
to
do
with
ras
to
make
this
piece
work,
here's
what
you
need
to
do
with
with
neighbor
discovery,
to
make
this
piece
work.
That's
what
I
think
we're
going
to
wind
up
doing.
B
That's
that's
what
we
did
with
the
thread
border
router,
whether
I'm
correct
about
that
is
something
that
we
need
to
talk
about
so
and-
and
you
know
I
said,
deliverables
was
just
the
solution,
but
actually
you
raise
a
really
good
point,
which
is:
maybe
we
actually
should
have
some
just
some
some
more
analysis
before
we
do
the
the
the
solution
document.
A
Thanks
ryan,
like
can,
I
just
add
something,
so
there
is
like
a
proposed
charter
that
was
discussed
on
the
mailing
list,
so
we
just
threw
it
up
so
in
a
roundabout
way.
It
covers
like
what
you
want
to
cover,
but
maybe
it
can
be
made
more
crisp.
What
it
says
is
like
these
are
the
functionalities
that
are
required,
like
so
that
in
the
stub
router,
that's
in
the
charter
and
the
deliverable
and
there's
a
non-goal
in
the
charter.
A
It
says,
like
we're:
gonna
try
to
use
existing
protocols
as
much
as
possible
right,
so
both
of
these
together
read
into
what
you
say,
but
maybe
we
can
make
it
a
little
bit
more
explicit,
saying
that
hey,
we
are
trying
to
not
reinvent
the
wheel
as
much
as
possible
here.
C
Q
Right
can
people
hear
me?
Okay,
there
we
go
yeah,
so
I'm
jonathan
hui,
for
those
of
you
don't
know
me
affiliated
with
google,
I'm
here
to
present
the
use,
a
concrete
use
case
of
the
work
that
we're
trying
to
drive
forward
here
within
the
itf
which
both
stuart
and
ted
have
already
kind
of
highlighted
or
previewed
in
a
few
times
already,
but
just
to
make
it
more
concrete
for
people
here,
especially
those
that
are
not
involved
with
thread
next
slide,
please.
So
what
is
thread
next
claim?
Q
So
I
think
stuart
already
mentioned
this.
We
like
to
think
of
thread
as
a
low
power
alternative
to
wi-fi
one
of
its
target
application
layers
that
it's
supporting
is
this
protocol
called
matter
matter
is
an
ipv6
based
application
layer,
and
it's
intended
at
least
in
its
initial
version,
to
work
across
both
wi-fi
and
thread
thread.
Q
You
know
supporting
low
power
battery
operated
devices
and
the
intent
there
is,
for
matter
to
work
seamlessly
end
to
end
right,
just
using
ipv6
whether
it's
wi-fi
or
threat
next
slide
about
this
data
is
about
six
months
old
now,
but
this
is
the
last
time
they've
publicly
provided
any
data
on
the
number
of
devices
that
are,
you
know
coming
out
with
matter
by
the
end
of
this
year
or
early
next
year,
but
there
is
134
devices
that
are
currently
implementing
matter
and
going
through
testing
from
about
53
different
companies.
Q
But
even
though
I
am
talking
a
lot
about
matter,
I
want
to
stress
that
thread
is
a
generic
ipv6
transport
right.
The
the
goal
here
is
to
provide
you
know,
ipv6
connectivity
to
any
set
of
application
layers
and
having
them
run
simultaneously
right.
We
really
do
believe
in
that
vision
where
ip
is
the
convergence
of
a
multi-service
network.
Q
Homekit,
as
was
already
mentioned,
is
already
shipping
with
thread
as
a
link
technology
and
then
looking
forward
a
little
bit
matter.
I
already
talked
about
knx
is
a
building
building,
automation,
communication
technology
and
then
dolly
is
a
commercial
lighting
communication
technology
which
have
also
both
announced
that
they
will
be
bringing
thread
to
their
solutions
in
later
this
year.
Next
slide
yeah,
just
real
quick.
The
key
points
to
call
out
with
thread
is
that
it
is
based
on
ieee
8215.4,
the
same
radio
that's
used
in
zigbee.
Q
The
phi
is
the
oqpsk
2.4
gigahertz
quarter,
megabit
per
second
data
rate.
The
other
thing
to
call
out
is
the
frame.
Mtu
is
127
bytes
right.
So
when
you
talk
about
the
mac
overhead,
you
know
media
access.
This
link
really
is
only
providing
about
tens
of
kilobits
per
second
right
data
rate.
It
is
six
low
pan
base.
So
four
nine
four
four
and
six
two
eight
two
using
those
technologies
to
transport,
ipv6,
datagrams
next
slide.
Q
And
then
there
is
a
lot
of
stuff
going
on
within
thread,
but
I
just
wanted
to
call
out
some
of
the
high
level
properties
of
it
and
gets
into
something
that
was
already
mentioned
earlier
in
this
session.
But
thread
is
a
mesh
topology
thread
devices
form
discover
routes,
multiple
hops,
if
they're
not
directly
within
range
and
next
slide
thread
devices
connect
into
other
link
technologies
like
wi-fi
through
devices.
Q
What
we
call
border,
routers,
right
and
thread
was
designed
to
be
no
single
point
of
failure,
and
so
a
thread
topology
can
have
multiple
border
routers
active
simultaneously,
providing
connectivity
between
thread
networks
and
non-threat
networks
and
to
really
this
this
is
a
concrete
problem
right.
These
are
products
that
are
shipping
today
they
have
been
shipping
in
some
cases
for
multiple
years.
Q
I
you
know,
I
think
best
answer
is
in
that
we
have
about
tens
of
millions
of
these
devices
total
deployed
already
in
market
that
have
15.4
radios
in
them
and
have
had
announcements
that
they
will
be
upgraded
to
thread
the
latest
version
of
thread
to
support
better,
but
in
many
of
these
cases,
they're
already
running
some
version
of
thread.
Q
You
know
already
next
slide
so
yeah
we
talked
about.
What's
the
topology
look
like
from
a
stub
networking
perspective,
so
even
if
you
look
at
a
single
thread
network
right
as
michael
talked
about
that
thread,
network
may
appear
as
a
single
cohesive
topology
may
appear
as
separate.
You
know
physically
connected
topologies,
because
you
know
just
the
way
the
radio
connectivity
works,
and
so
it
could
be
that
you
know
the
border.
Q
Routers
are
servicing
the
same
mesh
topology
and
are
connected
through
the
stub
network,
or
it
could
be
that
they're
only
connected
through
the
infrastructure
network
itself,
and
this
is
dynamic
right.
This
device
may
come
and
go
there
may
be
other.
You
know
the
steel
door
opening
and
shutting
that
is
affecting
this
connectivity
next
slide.
Q
Yeah
so
dynamic
merging
right.
If,
if
connectivity
comes
back,
then
the
those
those
stub
networks
can
combine
into
a
single
stub
network
next
slide
next
slide.
Please
thanks
all
right
next
slide.
So
stewart
mentioned
this
a
little
bit
already
with
the
home
network
that
we're
used
to
today,
it's
a
single
broadcast
domain.
All
devices
connected
you
know
within
a
single
ip
hop
next
slide,
but
when
we
look
to
attaching
a
thread
network,
we
don't
want
to
just
bridge
that
network
right.
It's.
It
is
a
highly
constrained
low
data
rate
network.
Q
We
we
really
do
want
to
isolate
all
of
the
multicast
and
other
traffic.
That's
happening
on
the
wi-fi
from
the
thread
network
and
that's
why
you
know
with
thread
so
far,
we've
chosen
to
have
that
connected
in
as
a
separate
as
a
separate
network.
A
Jonathan,
I
think
ran,
has
like
a
clarifying
question.
Oh.
C
Q
A
No,
so
jonathan
can
I
just
repeat,
because
I
think
there
might
be
some
audio
issue.
So
if
I
can
summarize
rand's
question
quickly
so
rana's
asking
this
purple
pentagon,
that's
in
the
picture,
why
doesn't
it
have
a
zigbee
radio
would
would
that
be?
A
fair
summary
of
your
question
ryan
ran
is
shaking
his
head
for
the
people
who
are
remote.
Thank
you.
Yeah.
Q
That's
fair,
so
I'll
just
bring
it
back
to
this
sorry,
I
lost
it
I'll
bring
it
back
to
this
slide.
So
the
answer
is
it
can
right
so
the
these
products
here?
This
is
a
google
wi-fi
access
point.
These
are
euro
access,
wi-fi
access
points,
they
do
include
thread
radios
right.
Not
every
access.
Q
Point
includes
a
thread
radio
today,
maybe
tomorrow,
if
thread
becomes
pervasive,
but
we
have
to
assume
that
in
some
networks
they
do
include
a
thread
radio
and
in
some
networks
they
don't,
and
so
you
do
see
a
lot
of
other
products
that
are
not
your
wi-fi
access
points
right
that
are
that
allow
users
to
easily
add
thread
to
their
home
without
having
to
swap
out
their
wi-fi
access
points.
Q
L
B
L
Why
doesn't
the
home
gateway?
Have
this
one
dollar
radio
in
it?
My
question
to
you
is:
does
yours
at
home
right
now
you
want
to
buy
a
five
dollar
light
bulb,
which
you're
told
you
can
control
remotely
you
take
that
light
bulb
home.
Does
your
home
gateway
have
a
zigbee
radio?
Okay?
Is
that
a
safe
assumption
for
a
product
maker
that
every
customer
they
might
sell
to
has
a
home
gateway?
That
does
that.
P
I'm
suggesting
that
there
are
more
topologies
than
have
been
shown
here,
and
one
of
the
obvious
long-term
topologies
is
that
the
zigbee
radio
goes
into
the
cable
modem
or
the
dsl
modem
or
the
whatever.
That
is
also
the
ip
router.
That
is
also
the
wi-fi
thing
I
think
that's
an
inevitability,
that's
not
a
short-term
fix,
but
it's
a
topology
that
the
group
as
a
whole
ought
to
be
thinking
about
right
right.
There
are
going
to
be
a
lot
of
topologies,
but
that's
one
of
them.
That's.
B
Yeah,
so
something
that
michael
said
earlier,
which
I
think
really
speaks
to
rand's
question,
is
even
if
your
router
has
that
device
in
it.
That
doesn't
fully
solve
your
problem,
because
what,
if
some
of
your
mesh
devices
are
not
close
enough
to
that
router
and
not
close
enough
to
any
other
mesh
device
that
they
can
reach
that
router
through
either
through
a
mesh
device
or
directly?
B
And
if
the
answer
to
that
is
no,
then
you
probably
need
more
mesh
routers
than
just
that
one,
and
so
that's
that's
you
know
part
of
the
idea
with
the
with
the
thread.
Mesh
certainly,
is
that
it's
a
self-healing
self-managing
network
that
works,
even
if
you
have
gaps
in
physical
connectivity
as
long
as
you
have
devices
connected
to
the
backbone
that
are
also
connected
to
the
thread
network.
A
Michael
richardson
said
even
if
you're
having
a
dispute
with
the
isp
for
the
people
or
remote.
Thank
you.
L
So
I
do
want
to
be
clear
that
I'm
not
disagreeing
with
ran
that
it
would
be
lovely
if
that
purple
pentagon,
the
the
home
gateway
that
the
the
customer
already
has
their
cable
modem
whatever.
It
is,
be
wonderful,
if
that
had
a
thread.
Radio
in
it,
as
well
rand
says
his
already
has
and
I'd
love
to
hear
from
you
afterwards
what
product
is
using
because
I'm
not
aware
of
any
such
products.
That
would
be
wonderful,
but
that
does
not.
L
It
is
not
the
reality
today
and
it's
not
going
to
magically
happen
overnight,
because
if
nobody
can
sell
thread
light
bulbs
because
no
customer
can
use
them,
then
there's
no
market
for
that.
If
there's
no
market
for
that,
why
would
any
cable
modem
vendor?
Add
this
capability
that
no
customers
asking
for
this
is
always
the
problem
in
networking
is
the
chicken
and
egg
problem,
so
we
need
a
transition
that
gets
us
to
this
glorious
future
where
every
home
gateway
has
threat.
J
Morrow
some
of
the
problem
here
is
that
there
are
multiple
different
transport
layers
and
they
may
or
may
not
exist
and
that
a
single
device
may
have
more
than
one
transport
link
and
it
doesn't
matter
what
the
transport
is
really
anyway.
It's
the
upper
layer
protocol
that
you
care
about
so
I
think,
describing
the
problem
in
that
sort
of
in
that
way,
as
opposed
to
letting
people
infer
it.
I
think
rand's
comment
about
like
oh,
why
does
it
just
have
the
right,
radio?
Okay,
I
have
a
new
radio.
Does
it
have
that
one?
No
right!
Q
J
Q
All
right,
so
the
next
set
of
slides
here
I
just
wanted
to
give
a
little
bit
of
preview,
and
this
is
really
talking
to
some
of
the
stuff
that
ted
and
stuart
were
mentioning
into.
You
know
this.
This
stuff
is
shipping
today
right
and
so
what
do
we
decide
to
do
right
now
right?
So
one
is
you
know
how
do
we
provide
ipv6
reachability
in
thread
border
routers,
so
the
first
step
really
is
to
configure
the
networks
with
the
appropriate
scope.
Ipv6
addresses
right.
We
link.
Q
It's
not
sufficient
for
wi-fi
devices
to
talk
to
thread
devices
and
vice
versa
right.
So
one
of
the
actions
of
the
border,
router
really
is
to
one
discover
whether
or
not
there
is
a
usable
prefix
available
on
that
link.
Q
And
if
they're
not
is
not
one,
then
it
has
to
go
ahead
and
configure
that
and
how
does
it
do
that?
Well,
router
advertisements
with
prefix
information
options
right
on
the
wi-fi
side,
but
thread
has
kind
of
a
analogous
mechanism,
but
we
don't
need
to
get
into
the
details
of
that
there,
but
you
can
think
about
it
as
just
configuring,
a
prefix
with
the
appropriate
scope,
and
it
is
a
ula
right.
So
it
locally
generates
that
at
random
and
then
advertises
that
in.
Q
Now,
once
it
has
appropriate
scoped
addressing,
then
it
has
to
also
advertise
the
routes
so
that
devices
on
the
wi-fi
side
know
how
to
access
devices
on
thread
and
vice
versa,
and
so
how
does
it
do
that?
Well,
it
uses
router
advertisements
with
route
info
options
inside
of
it
right,
so
all
existing
als.
You
know
encodings
that
are
already
defined
in
rfcs,
but
you
know,
as
ted
mentioned,
I
think
some
of
the
behaviors
of
how
do
I
detect
whether
there's
a
usable
prefix.
When
do
I
generate
a
prefix?
Q
If
I
have
multiple
border
routers,
how
do
they,
you
know,
coordinate,
or
you
know,
figure
out
rather
than
having
everyone
generate
their
own
prefix
at
the
same
time
right
so
some
of
that
behavior
is
not
really
defined
today,
right
and
that's
kind
of
some
of
the
stuff
that
we
had
to
do
in
the
thread
border
routers.
For
this
to
to
be
scalable
now
we
also
talked
about
dns
service
discovery,
so
this
is
really
just
pulling
on
a
lot
of
the
work
in
the
the
dns
sd
working
group
right.
Q
I
Q
How
do
thread
devices
publish
services
that
they
offer,
so
we
in
thread
we
use
srp
and
in
srp
it's
just
a
unicast
update
to
a
thread:
border
router,
that's
border
router,
implementing
an
srp
registrar
and
the
thread
border
router
uses
that
srp
database,
along
with
an
advertising
proxy
to
make
those
services
available
discoverable
on
the
wi-fi
infrastructure
link
right,
and
so
in
that
case,
the
wi-fi
devices
continue
to
use
mdns
to
discover
services
published
by
thread,
but
that
multicast
stops
at
the
border
router
and
doesn't
go
into
the
thread
network.
Q
So
how
do
thread
devices
discover
services
on
the
wi-fi
side
rather
than
using
mdns
directly?
They
can
send
a
unicast
dns
query
to
a
thread:
border
router
and
then
the
border
router
implements
a
discovery
proxy,
which
translates
that
into
an
mdns
query.
On
the
wi-fi
side,
you
know,
gets
the
response
and
then
provides
that
in
a
unicast
response
to
the
thread
device
so
again
avoiding
all
of
the
multicast
overhead.
That's
on
the
thread
side,
great,
so
yeah.
Q
It
was
intended
to
be
really
quick,
but
also
provide
some
more
concrete
kind
of
background
on
on
thread
and
why
this
work
is
important
to
thread.
A
Thanks
a
lot,
thank
you
very
much
for
coming
and
sharing
the
three
use
case.
Thanks
a
lot
michael,
I
know
you're
ready.
A
Nope
they're
going
to
fix
it
after
they're.
G
Going
to
fix
it
afterwards:
okay,
hi,
my
name
is
michael
richardson
and.
A
Michael
just
pascal
did
you
have
a
question
for
jonathan
or
if
you
have
a
question.
Yes,
thank
you.
N
Yes,
one
question:
is
it
okay
that
I
ask
it
yeah
go
ahead,
yeah,
okay!
So
I'm
john
great
to
see
you
again,
it's
been
a
while
so
very
happy
to
see
you
there.
My
question
was
about
the
the
networks
joining
and
splitting
that
you've
shown
on
one
slide
and
remember:
there
was
one
where
you,
you
could
see
two
groups,
and
this
is
little
guy
in
the
middle.
I
don't
know
if
you
can
bring
back
this
slide.
N
Maybe
it's
too
late,
but
basically
what
you've,
what
you've
done
for
service
discovery
is
exactly
the
way
we
do
as
well
for
nd
proxy,
because
I
mentioned
in
the
proxy
earlier,
so
this
exact
system
that
you
you
explained
for
service
registration
is
the
way
six
le
pen
does
also
for
addresses.
So
that's
how
we
maintain
a
single
prefix
across
the
wi-fi
backbone
and
the
multiple,
not
thread
but
multiple
iot
networks
and
the
reason
we've
been
doing
that
is
because
of
joining
and
splitting
of
the
network.
So
there
is
another
slide.
N
N
And
and
my
question
here
is
basically
yes,
basically
this
scenario
it
is.
It
is
the
one
that
that
we
looked
at
at
six
low
for
large
factories,
with
thousands
of
nodes
around
multiple
of
those
gateways
and
the
nodes
possibly
moving
inside
the
factory,
and
we
did
not
want
them
to
remember,
and
so
so
that's
why
we
ended
up
doing
the
nd
proxy
ac
tell
this
year
we
ended
up
doing
the
nd
proxy
and
routing
inside
the
steps
and
you're
well
aware
of
of
that
to
nothing.
N
I'm
just
wondering
if
you,
if
you're
doing
a
different
writing
in
in
well,
not
different
writing
but
different
dressing
in
the
two
steps,
when
the
drawing
splits
and
do
the
node
have
to
form
new
ipv6
addresses,
depending
on
reachability
to
gateways,
I
mean.
How
does
that
happen?.
N
Oh
okay,
so
so
I
was
saying
in
in
a
case
like
this.
The
reason
why
we
did
proxy
we
discussed
earlier
is
because
we
did
not
want
the
devices
to
remember.
That's
really
the
reason
why,
and
so
there
is
in
in
the
usual
six-layer
networks,
there
is
a
single
prefix
for
the
whole
thing,
so
the
guys
can
move
to
the
left,
to
the
right,
etc
and
the
question
to
jonathan,
since
in
thread
they
are
apparently
creating
a
new
prefix
inside
each
step.
N
B
Yeah,
so
so
indeed,
if
there's
a
network
partition,
then
renumbering
is
gonna
have
to
happen.
N
And
and
not
moving
right,
I
mean
it's
not
I
mean
partition
is
one
thing,
but
basically
nodes
moving,
say
this
is
a
big
factory
and
there
are
robots
throughout
the
factory
and
and
they
are
moving
with
their
devices
crossing
going
left
or
right,
and
the
shortest
path
to
the
wi-fi
infrastructure
is
sometimes
for
one
gateway,
sometimes
for
another
and
having
to
remember
is
kind
of
impractical.
In
that
space
I
mean
that
that's
that's.
That
was
well.
B
Pascal,
this
is
ted
lemon
by
the
way,
pascal,
that
that
particular
question
that
you're
asking
I
don't
think,
is
actually
as
interesting
a
question
as
you're
as
you're
suggesting
it
is
and
the
reason
I
say
that
is
because
what
you
in
a
in
a
mesh
network,
it's
just
gonna,
it's
just
going
to
it's
gonna,
it's
gonna,
the
mesh
topology
is
going
to
change
as
the
robot's
moving
around
which
isn't
ideal
actually,
but
but
you
you
can't
really
avoid
that,
and
so
in
that
case
the
robot's
not
going
to
renumber
it's
just
it's
going
to
keep
the
same
ip
address
the
whole
time.
C
A
Want
we
can
discuss
this
a
little
bit
later,
but
I
kind
of
want
to
have
michael
talk
about
it,
so
we'll
have
some
time
for
this
question
at
the
end.
Thank
you.
Thank
you.
Thank
you
thanks,
pascal,
if
you
have
like
undersold
questions,
we
can
take
it
up
in
the
discussion
time.
Okay,
thank
you.
A
G
Okay,
so
hi,
my
name
is
michael
richardson,
so
I'm
going
to
talk
a
little
bit
like
what
about
a
kind
of
alternate
use
case
that
and
I'm
going
to
say
we
came
to
it
backwards
where
we
were
looking
at
the
solution
and
going.
I
wonder
if
it
would
work
here
and
then
so
we
decided,
we
better
explain
what
here
was
and.
G
The
other
interesting
thing
about
this
was
that
some
of
the
requests
that
came
internally
were
some
of
it
got
lost
in
translation
and
we
got
went
back
and
forth
a
bit
and
finally
realized
what
their
actual
problem
was,
and
I
then
they
actually
said
internally,
they
said
well,
actually,
you
know
this
was
what
it
was.
Not
the
thing
we
were
thinking
about.
You
know
several
months
ago,
so
that
was
kind
of
a
a
weird
learning
process.
G
So,
basically,
what
we're
talking
about
is
buildings,
and
I
kept
wanting
to
put
in
die
hard
pictures
in
the
middle
of
this,
because
you
know
it's
one
of
those
cases
where
what
was
science
fiction
scenarios
from
a
movie
and
you
suddenly
realize
you're
implementing
it
right,
it
kind
of
seems
silly.
So
imagine
you
know
you
have
these
buildings
and
they
have
a
number
of
different
systems
and
they
all
converge
in
one
of
those.
G
You
know
security
rooms,
which
is
where,
of
course,
you
take
over
if
you're
going
to
take
over
the
building.
You
take
over
that
room
first
and
they
have
all
these.
You
know
different
systems,
and
one
of
the
reasons
why
they
have
different
systems
is
because
they
bought
them
from
different
vendors
over
many
different
years
and
they
can't
get
any
of
their
vendors
to
talk
to
each
other
regularly.
G
So
they
have
all
these
different
networks
and
they
all
come
back
and
essentially
there's
an
application
layer
firewall
between
all
of
them,
which
is
the
human
that
pokes
things
right
there.
So
everything's
great
and.
I
G
Have
a
lot
of
wiring
a
lot
of
expenses
until
that
part
of
the
network
goes
down
right
due
to
malfeasance
fire
or
just
incompetence.
And
so
then
you
know
there's
a
problem
and
there's
false
alarm
issues
and
other
kinds
of
things.
And
yet
all
equipment
is
out
there
and
the
people
would
like
to
maybe
be
told
if
they
should
go
up
a
floor
or
down
a
floor
or
where's
the
fire.
Or
is
there
a
fire
and
it
wouldn't
be
lovely?
G
If,
instead,
you
know
the
devices
could
talk
to
each
other,
we
could
have
some
kind
of
a
converged
network
that
would
work
even
in
the
absence
of
of
a
brain
right,
and
so
in
that
sense
it
looks
very
much
like
the
home
network
situation,
because
in
this
case
the
brain
is
the
isp
who
runs
the
home
router.
And
it's
the
rand's
question.
G
It's
because
I
don't
want
to
use
that
router
because
it
belongs
the
isp
and
when
they
replace
it,
I
lose
all
access
to
all
my
light
bulbs
and
that's
why
I
don't
want
to
do
that.
But
so
the
isp
has
no
brain
and
they
won't
participate
in
this
network
that
I
want
to
build,
and
I
want
to
own
and
that's
why
we
need
gateway
to
gateway
communication
and
then
building
it's
a
similar
thing.
G
G
And
so
this
is
the
kind
of
thing
that
we
we're
having
a
conversation
about
so
built
a
little
bit
of
a
diagram
of
how
I
would
build
a
network
in
a
multi-story
building
and
I've
had
a
couple
conversations
with
people
that
do
building
automation
and
it's
interesting
that
a
number
of
people
when
I
asked
them
about
the
physical
network
things
they
said.
Well,
that's
a
really
good
question.
G
I
have
no
idea
how
it's
actually
physically
deployed
and-
and
I
went
really
that's
really
startling-
you
think
that
would
be
a
critical
part
of
the
security
posture
to
know
what
the
resilience
is,
and
they
said
you
know.
That's
a
really
good
point.
Why
don't?
I
know
this
question
and
I
hope
we'll
have
more
information
in
the
future.
This
is
what
I
would
do
right.
G
I
would
put
a
four
port
router
on
every
floor.
I
wouldn't
want
to
wire
it
all
back
to
the
to
the
thing
you
have
ethernet.
You
know
length
limitations,
there's
a
lot
of.
If
you
think
about
a
you
know,
a
40
story,
building
or
even
this
hotel
is
about
23
stories
right.
The
distance
from
the
top
floor
to
the
bottom
is
way
beyond
copper
ethernet
length.
G
So
that's
silly,
so
you
put
it
together
and
what
do
you
do?
Well,
you
could
run
a
routing
protocol.
We
have
a
whole
bunch
of
them.
We
actually
think
ripple
actually
would
be
really
good,
but
I
think
you
could
do
with
ospf.
I
think
it
would
be
annoying
because
you'd
have
you'd.
Have
to
think
about
exactly
what
you're
doing
with
the
areas.
G
I
think
that
if
you
threw
this
at
a
typical
vendor,
they
would
say:
oh,
let's
do
an
l2
metro,
ethernet
solution,
put
it
all
in
one
l2,
that's
the
home,
wi-fi
network
everything's
bridged,
and
then
they
would
think.
Okay.
But
now
I
have
all
this
sensor
network
behind
each
one
which
is
probably
802.15.4.
It
might
not
be
thread,
it
might
be
bacnet
as
well,
depending
what
devices
in
the
age
of
the
building
and
then
they
would
say.
G
Okay,
but
now
I
don't
have
ethernet
on
both
sides,
so
I
have
to
do
routing,
so
it
suddenly
looks
exactly
like
the
diagrams.
We
just
said
we
have
these
gateways
they're
connected
together
by
a
complicated
topology,
and
they
would
like
to
do
things
particularly.
You
would
like
to
have
sensors
on
one
floor
or
actuators
on
one
floor
talk
to
sensors
on
the
adjacent
floors.
Right,
don't
open
this
door
up
or
down
stairwells,
if
the
one
above
it
or
below
it
is
full
of
smoke
right.
That
would
be
a
bad
thing.
G
G
So
you
know
something
goes
bad.
Some
floors
are
on
fire.
What
are
you
gonna
do?
Okay,
so
there's
some
differences,
though,
between
the
this
network
and
the
home
network.
One
of
them
is
that
there
is
an
operator
they're
just
absentee
at
this
time,
so
they
could
set
up
credentials
and
they
could
set
up
configurations
and
they
could
allocate
prefixes.
G
But
when
the
network
event
happens,
they
you
can't.
You
can't
do
anything
else.
Those
machines
are
not
accessible,
they
have
to
have
their
own
intelligence
and
we're
not
necessarily
talking
about
you
know:
ai
vision
systems
that
may
just
be
stupid.
Things
like,
as
I
said,
don't
open
the
door
if
there's
smoke
on
the
other
side,
but
you
know
those
things
have
to
run
that
way.
G
So
it's
a
little
bit
advantageous
versus
the
home
and
that
someone
can
actually
do
something
intelligent
beforehand,
but
they
can't
do
anything
intelligent
during
that's
really
it
so
this
is
neither
here
there
there.
It
feels
like
a
solution
that
could
use
the
same
solution.
That
ted
has
proposed.
G
On
the
other
hand,
there's
a
lot
of
other
things
that
we
could
do,
and
I've
only
really
talked
about
the
l3
part.
The
layer
3
part
of
it
there's
a
layer
4
to
layer,
9
problem
and
we're
having
a
side
meeting
tomorrow
evening
and
then
we're
going
to
walk
over
to
the
social
event
and
come
if
you
want
to
talk
more
about
that.
Thanks.
A
Thanks
a
lot
michael,
we
don't
see
anybody
at
the
queue,
so
we
can
just
like
move
on
to
the
open
mic
discussions.
So
anything
that's
been
presented
till
now
is
fair
game
and
doesn't
necessarily
have
to
be
clarifying
questions
pretty
much
anything
so.
L
Yeah,
I'm
stuart
cheshire.
Just
a
quick
comment
on
the
thing
that's
been
raised
a
couple
of
times
about
proxy
nd.
Certainly
that
can
work.
L
The
thing
that
makes
me
uneasy
about
that
solution
is,
it
seems
like
the
very
easy
solution
when
you
just
want
to
add
one
more
thing
to
the
network:
just
make
the
broadcast
domain
bigger
and
bigger
and
bigger,
and
it's
like
the
the
silly
example
people
give
of
boiling
a
frog.
Just
you,
you
incrementally
add
things
until
the
thing
doesn't
scale
when
people
talk
and
the
at
its
heart
what
nate,
what
proxy
nd
is
doing
is
making
it
look
like
all
these
devices
are
on
a
single
ethernet,
and
that
is
great
for
the
ieee.
L
But
this
is
the
internet
engineering
task
force,
not
the
lan
engineering
task
force
and
something
feels
wrong
if
we're
rejecting
everything
about
internetwork
protocols
and
building
everything
using
a
sort
of
1980s
land
style
mindset
like
let's
just
build
the
land,
and
one
of
the
examples
was
given
like
what,
if
you
have
an
enormous
factory,
if
I
have
an
enormous
factory,
having
that
be
a
single
lan
seems
like
a
terrible
idea.
It's
rejecting
the
whole
insights
of
of
having
an
internetwork
protocol,
not
just
a
land
protocol.
N
Yeah,
there
is
a
big
misconception
here
as
to
what
I
I'd
love
to
speak
with
you
offline.
We
don't,
we
explicitly
break
the
broadcast
domains
right.
The
goal
of
doing
in
the
proxy
is
to
do
separate,
broadcast
domain
and
the
whole
work
at
six
low
for
more
than
10
years.
Pretty
much
15
has
to
be
has
been
to
avoid
the
broadcast
so
effectively.
N
We've
designed
the
routing
protocol
when
we
need
a
routing
protocol
and
we
are
doing
in
the
proxy
when
we
need
nd
proxy,
it's
a
matter
of
having
all
the
tools
in
your
toolbox
and
finding
the
tool
that
you
want,
but
all
the
tools
separate
the
broadcast
domain.
There
is
never
this
conception
of
a
single
broadcast
domain.
The
way
you
I
kind
of
understood
you
presented
it.
This
is
this
is
this
is
the
thing
that
we
want
to
avoid,
so
so
on
that
we
agree.
N
Basically,
what
you've
seen
jenna
jonathan
presenting
about
service
discovery
is
the
way
we
do
indeed
as
well,
both
service
and
md.
Everything
is
done
that
way.
You
we
don't
have
a
choice.
We
don't
have
broadcast.
B
B
Yeah
so
I'll
just
speak
to
pascal's
point
because
I
happen
to
be
here,
but
that
wasn't
what
I
came
up
to
talk
about
the
the
the
problem.
So
if
you
look
at
dnssd
which,
which
is
what
we're
talking
about
here
what's
nice
about
dnssd,
that
is
not
true
of
neighbor
discovery-
is
that
proxy
neighbor
discover,
I
should
say,
is
that
we
can
replace
multicast
dns
with
unicast
dns.
B
So
so
you
know
it's
it's
certainly
true,
and
I
I
don't
think
that
anybody
here
is
criticizing
the
solution
that
you've
generated
for
the
factory
floor,
but
we
were
trying
to
come
up
with
a
solution
that
that
didn't
have
the
scalability
issue
that
you're,
that
that
I
see
in
your
solution
at
all,
and
I
do
see
that
there's
a
scalability
solution
as
as
the
number
of
neighbors
on
the
network
grows.
There's
that's
clearly
a
scalability
issue,
whether
it's
a
big
issue
or
not,
is
a
matter.
B
We
could
debate,
but
it's
definitely
an
issue
so
so
the
point
is
that
our
sort
of
you
know
in
the
dns
sd
working
group,
our
path
forward
is,
is
to
try
to
get
as
much
away
from
multicast
as
possible,
and
that
creates
efficiencies
that
you
just
can't
get
with
with,
if
you're
doing
everything
with
multicast.
B
So
that
was
an
answer
to
pascal's
point,
which
I
you
know.
I
think
I
think
that
that's
a
good
thing
to
discuss,
but
the
thing
that
I
actually
came
up
to
do
was
relay
something
from
somebody
who
sent
me.
Some
private
email
from
from
ero
who
was
just
asking
like.
Does
the
stub
network's
problem
relate
to
virtual
networks?
So
if
you
have
virtualization
on
a
device,
could
snack
provide
a
way
for
virtualized
devices
to
access
a
a
a
an
infrastructure
link
or
or
the
internet?
B
A
S
Sure
hi,
I
I'm
matt
richards,
I'm
at
euro
subsidiary
amazon.
I
just
wanted
to
just
talk
a
little
bit
about
you
know.
Euro
or
amazon
through
euro
has
been
kind
of
participating
in
some
of
the
thread
and
matter
work.
We
brought
up
thread
on
our
hero,
home,
wi-fi
routers
and
just
you
know
we're
very
interested
in
kind
of
seeing
where
this
snack
snack
working
group
goes.
S
S
Very
excited
to
see
us
not
make
some
of
the
same
mistakes-
I
guess
specifically
around
large
multicast
domains,
so
just
hopefully
just
kind
of
excited
for
this.
This
problem
statement
to
really
get
a
thorough
investigation
and
see
what
comes
out
of
this.
Thank
you.
T
Do
we
see
snack
trying
to
full
get
these
things
to
fool
themselves,
to
work
out
how
to
get
through
that
sort
of
security?
Zoning
like
pinholing
through
or
do
we
want
to
see
them
auto,
detect
and
it's
now
no
longer
land
and
when
it's
it's
trusted
and
trusted
on
both
sides,
or
how
do
you
kind
of
foresee
that.
B
That's
a
great
question,
so
I
mean
clearly
you
know
if
we,
if
we
say
that
hosts
on
the
on
the
stub
network
need
to
have
equivalent
functionality
to
hosts
on
the
on
the
the
infrastructure
network,
then
our
expectation
would
be
that
the
the
router,
the
customer
edge
router
would
be
responsible
for
doing
you
know
rfc
7084
style,
firewalling
and
I
think
that's
sort
of
the
the
lazy
answer
to
your
question.
I
think
that
there's
some
interesting
work
to
do
there.
B
I
think
if
we,
if
we
thought
it's
worthwhile,
because
clearly
there
are
cases
where
it
makes
sense
to
isolate
things
right,
you
don't
want
necessarily
to
have
every
device
be
able
to
talk
to
every
other
device
on
your
home
network,
because
you
know
we've
seen
examples
like
with
the
mirai
botnet,
where
that
was
really
bad
and
so
so
being
able
to
to
control.
That
might
be
interesting.
N
I
just
wanted
to
reply
to
ted
because
he
was
talking
a
lot
about
multicast
and
large
multicast
et
cetera.
I
mean
again
that's
the
thing
that
sexler
avoids
right,
I
mean
so
you
need
to
look
at
how
we
did
things.
We
built
networks
with
tens
of
thousands
of
nodes
on
the
same
64..
We
build
them,
we
deploy
them.
N
Sometimes
we
have
20
hubs
in
those
networks
and
they
work
over
the
exact
same
radios
that
are
not
exactly
the
same
but
very
close
to
the
one
that
jonathan
has
been
talking
about
and
we
combine
effectively,
writing
and
and
and
and
unicast
nd,
because
the
whole
idea
is
on
unicast,
apart
from
from
either
arrest
or
ira
at
the
beginning.
So
so
it's
it's
you.
You
have
to
look
at
beyond
the
nd.
The
way
you
knew
it
20
years
ago.
That's
pretty
much
my
answer.
N
B
B
B
If
you
have
a
mechanism
for
avoiding
that
by
doing
those
neighbor
discoveries
with
with
unicast,
then
that
addresses
that
problem
and
certainly
the
six
low
solution
where,
on
the
six
law
network
you're
not
doing
multicast
addresses
that
problem
on
the
six
low
network.
But
you
know,
for
example,
in
the
thread
use
case
that
we're
talking
about.
We
also
don't
do
multicast
on
the
on
the
802.15.4
network.
That's
that's
all
done
with
well.
Actually
I
shouldn't
say
that
jonathan
might
correct
me
on
that.
B
But
but
the
point
is
we're
certainly
not
doing
individual
nd
type
multicast
on
the
on
the
thread
network,
and
so
so
that
eliminates
the
problem
of
of
you
know:
excess
multicast
in
that
constrain
network.
But
the
concern
the
re,
the
scalability
concern
that
I
had
was
more
for
the
for
the.
I
B
Adjacent
infrastructure
link
where
you
know
having
all
of
that
multicast
on
the
adjacent
infrastructure
link
can
be
problematic
in
a
number
of
ways.
One
of
them
is
the
amount
of
multicast
traffic,
and
the
other
is
just
that.
Multicast
traffic
is
not
reliable.
If
you
have
a
wi-fi
mesh
network,
it's
often
the
case
that
multicast
traffic
from
one
access
point
isn't
necessarily
100
reliably
replicated
to
all
access
points,
and
in
that
case
you
wind
up
not
being
able
to
reach
devices,
and
so
relying
on
that
kind
of
multicast
isn't
ideal.
N
N
A
I
I
think
we're
kind
of
staying
out
of
solution
space
for
now,
but
I
think
it's
really
good
to
have
that
discussion
right,
but
I
think,
as
long
as
we
agree
on
the
goal
of
reducing
multicast
on
the
infra
network
is
good
enough.
I
think
we
can
talk
about
the
solutions
after
right,
so
that'll
be
good
like.
A
So,
if
you
have
time
at
the
end
of
the
meeting,
we
can
do
that
or
we
can
do
it
on
the
mailing
list,
or
we
can
probably
do
another
like
interim
meeting
or
something
just
to
tackle
that,
and
so
that's
certainly
fair
game,
because
we
are
not
presupposing
a
solution
here
right.
We
are
talking
about
the
problem.
Space.
A
Thanks
go
ahead.
L
A
Yeah
thanks
and
I
think,
like
one
of
the
things
that
I
think
both
stewart
and
ted
stated
it's
like
hey.
If
there's
a
better
solution,
we
want
to
find
it
right.
So
this
is
not
like
just
trying
to
rubber
stamp
a
solution
or
anything
like
I
think
it's
everything
is
fair
game
now.
Pascal.
Thank
you,
philip
thanks.
O
So,
as
we
discussed
a
little
bit
about
whether
this
could
also
be
applicable
for
virtualized
infrastructures,
another
question
came
up
to
me
is:
do
we
have
to
think
in
this
working
group
about
limitations
and
scalability
based
on
the
addressing,
so
in
virtualized
infrastructures?
You
easily
come
up
with
situations
where
you
end
up
with
saying:
okay
is
64
per
link.
B
Lemon
yeah,
so
that's
actually
a
question
that
that
jared
was
talking
about
a
couple
probably
a
month
ago,
when
the
snack
stuff
first
got
discussed,
and
you
know
one
of
the
things
that
he
suggested
would
be
really
interesting
would
be
to
make
it
possible
to
get
multiple
prefix
delegations
from
the
isp.
So
you
know
there
are.
There
are
things
we
could
talk
about
there.
I
think
that
there's
a
risk
here
of
boiling
the
ocean
and
the
first
first
first
version
of
this
process.
B
There's
you
know
if
we,
if
we
come
to
a
conclusion
that
we
actually
need
to
do
that
work.
I
think
that
we
could
probably
charter
it,
but
I
don't
think
that
we
need
to
start
with
that,
and
I
think
if
we,
if
we
start
with
too
many
difficult
things,
then
that
like
it
would
be
good
just
to
like.
B
Actually
you
know,
we
should
be
careful
not
to
have
a
solution
that
that
we
know
will
prevent
us
from
doing
something
like
that
right,
but
at
the
same
time
you
know
we
we
shouldn't
try
to
solve
every
problem
all
at
once.
So
I
you
know.
A
And
and
to
be
fair
to
ted,
like
ted,
did
actually
put
up
like
a
like
getting
multiple
prefixes
in
the
original
charter
that
he
kind
of
wrote
and
we
kind
of
scoped
it
down,
because
the
idea
is
to
get
something:
that's
more
tightly
scoped
to
start
the
work
on
and
then
we
can
add
deliver.
I
think,
like
I
like.
If
eric
approves
right,
we
can,
if
there's
a
working
group
and
like
we
can
add
a
deliverable
pretty
quickly
with
a
milestone
right.
A
But
the
idea
is
like
get
something:
that's
off
like
that's
useful
and
tightly
scoped
right.
That's
usually
how
we
start
off
right
instead
of
trying
to
do
everything
at
once.
So
that's
certainly
something
so
we
can
actually
add
text
to
the
charter
like
to
say
like
hey.
We
should
be
thinking
of
this
and
if
there's
interest
we
can
actually
add
a
deliverable
too,
but
that's
kind
of
something
we
can
discuss
like
in
the
chatter
discussion
itself.
Right.
O
Yeah
so
for
this
is
explicit
question
I
think
so
for
the
cloud
use
cases,
I
think
many
people
thinking
about
that
ended
up,
saying:
okay,
we
we
sacrificed
another
holy
cow
and
we
scoped
down
the
stop
networks
to
something
smaller
than
slash
64.,
and
so
this
is
also
something
that
might
be
worth
thinking
of
in
this
context,
because
it
might
be
easier
than
getting
larger,
prefix
delegations
and
updating
the
prefix
delegation
mechanism.
A
So
philippe
like,
I
think
we
can
certainly
discuss
that
there
is
some
issues
with
slack
on
non
slash,
64s
right.
So
I
I
think,
like
you
know,
jen
six-man
chair
is
sitting
here,
so
I
I
think,
they're
probably
trading
on
some
very
dangerous
territory
if
we
start
specifying
it,
but
it's
certainly
something
we
can
discuss
and
probably
throw
off
to
six
man
at
some
point.
A
B
You
so
just
to
be
clear
what
I
thought
the
interesting
virtualization
problem
was.
Was
you
have
a
copy
of
vmware
and
you
want
your?
You
want
your
vmware
host
to
be
able
to
communicate
equally
on
the
on
the
link
with
other
hosts,
without
necessarily
using
bridging,
not
solving
the
whole
like
cloud
virtualization
problem,
which
is
a
huge
problem.
C
B
So
well,
you
know
and
and
that's
not
to
say
that
we
can't
go
in
that
direction
if
it
makes
sense.
But
but
I
think,
there's
a
there's
a
there's
a
very
tightly
scoped
stub
network
use
case
for
something
like
vmware
that
and
you
know
not
necessarily
vmware,
but
that
kind
of
thing
that
is
interesting
and
that
might
might
well
be
in
scope
like
right
away
or
soon.
A
Okay,
so
now
we
are
at
the
interesting
part
of
the
meeting
where,
like
you
know,
people
are
gonna,
try
to
add
things
delete
things
to
the
charter,
so
thanks
ted
for
like
getting
the
discussion
kicked
off,
so
we
had
quite
a
bit
of
discussion
on
the
mailing
list
and
we
hope
to
have
more
discussion
on
this
today.
The
idea
would
be
to
for
people
to
have
a
general
idea
of
what
we're
trying
to
solve
here.
A
A
A
G
Michael
richardson,
so
the
third
paragraph
so
hidden
inside
of
this
third
paragraph,
and
I
don't
know
whether
we
should
change
this
or
not
hidden
inside
of
this
is
essentially
the
statement
that
if
the
host
can
connect
out,
that
is
implying
that
actually
you
know
double
that
is
a
it
would
otherwise
be
a
workable
solution.
If
all
we
needed
to
do
is
have
the
host
connect
out.
G
I
don't
know
if
we
should,
if
we
should
say
that
more
clearly,
if
we
really
need
to
hit
people
over
the
head
that
this
is
exactly
what
we're
trying
to
avoid,
or
you
know
whether
that's
understood
by
everyone
or
needs
to
be
understood
by
everyone.
I
don't
know
right.
L
H
B
Thanks
for
noticing
that
so
so
we're
talking
about
the
sentence
where
it
says
but
hosts
on
the
infrastructure
network,
so
it
cannot
be
the
case
that
hosts
on
the
stub
network
can
connect
out,
but
hosts
on
the
infrastructure
network
can't
discover
connect
to
hosts
on
the
infrast
on
the
stub
network
right
yeah,
so
it
should
be,
it
should
say
stub
network
in
the
second,
that
second
infrastructure
should
be
stubbed.
Are
you
editing
this
or
do
you
want
to.
A
I
think
ted,
if
you
can
join
from
meet
echo
like
the
full
client
and
yeah.
You
have
the
editable
version
of
this
right.
Yeah.
B
A
Do
if
you
can
do
that,
that'll
be
good.
Thank
you,
juan
carlos
go
ahead.
Q
R
Go
ahead:
okay,
thanks,
I
guess!
R
Well
I
I
understand
that
the
the
this
covering
problem
and
the
splitting
and
the
dynamics
of
the
network,
what
I'm
still
not
sure
I
I
understand
and-
and
that
was
probably
an
answer-
but
I
couldn't
hear
well
from
richard's
question
before-
is
whether
we
want
to
also
consider
the
onboarding
part,
or
are
we
just
dealing
with
the
network
when
it's
already
set
up
and-
and
we
just
want
to
make
sure
that
it
works
or
we
are,
we
dealing
also
with
the
onboarding
of
new
the
devices
authorization
all
that.
B
Ted
lemon
here
I
think,
that's
a
really
interesting
problem,
but
it's
also
probably
specific
to
the
individual
type
of
stub
network,
and
so
you
know
we
could
maybe
do
something
like
that,
but
I
don't
know
that
it's
necessarily
in
scope,
certainly
for
the
thread
use
case.
We
already
have
a
solution
for
that,
and
so
we
wouldn't
need
the
ietf
to
solve
that
problem
for
us,
but
there
might
be
a
use
case
where
that
does
matter,
but
you
know
we
already
have
onboarding
for
wi-fi
networks,
you
type
in
the
password,
so.
U
Hi
there
tom
hill
bt,
having
read
now
through
the
proposed
charter,
and
I
think
in
follow-up
to
richard's
question
previously
around
security.
U
I
think
it's
incumbent
upon
us
actually
when
we're
it
seems
like
feature
creep.
I
think
in
some
cases,
but
I
think
it's
incumbent
upon
us
to
at
least
consider
basic
security
as
a
remit
of
this
charter
of
snack,
on
the
basis
that
if
we
don't
consider
basic
security
at
the
the
borders
between
stub
networks
and
and
infrastructure
networks,
for
example,
in
particular,
on
a
per
sub
network
basis
at
the
very
minimum,
then
it
will
be
down
to
each
individual
vendor
to
come
up
with
what
they
think.
U
That
should
do
we're
in
danger
here,
a
little
bit
of
noting
that
we
are
moving
away
from
double
nat
as
a
as
a
method,
but
also
ignoring
the
fact
that
we
today,
as
an
industry,
rely
quite
heavily
on
the
obfuscation
of
double
net
and
and
and
that
in
general.
We
really
should,
I
think,
be
more
prescriptive.
U
A
U
Because
I'm
trying
to
like
that's
one
example,
I
think
it's.
The
two
points
here
are
that
leaving
it
undefined
means
that
it
will
potentially
not
be
done
very
well,
and
it
is
incumbent
upon
all
of
us
in
2022
to
think
very
hard
about
security
with
everything
we
do.
U
Hence
we
end
up
with
more.
You
know,
mirai
bots
or
you
know
the
next.
The
next
horrible
great
big
ddos
exploit
that
that
comes
along.
So
I
think
it's
very
very
important
that
we
we
start
with
security
baked
in
at
least
at
a
very
basic
level.
B
Oh
yeah,
he
motioned
me
forward,
so
I'm
I'm
obeying
yeah,
so
the
the
question
that
I
would
have
for
you
is:
do
you
want
the
equivalent
control
over
individual
devices
that
connect
to
the
infrastructure
network?
B
I
mean
that's,
I
see
someone
over
there
nodding.
I
happen
to
agree
with
him,
but
but
that's
that's
really.
That's
really.
What
you're
talking
about
and
that's
why
that's
where
I
said
you
know,
that's
actually
an
interesting
problem.
That's
not
a
trivial
problem
and-
and
it's
also
probably
it
probably
is
a
different
problem
depending
on
the
particular
type
of
network,
so
yeah
yeah,
of
course,.
U
Tom
hill,
again
perfect,
is
the
enemy
of
good,
and
I
think,
if
we
focus
too
hard
on
individual
devices,
every
single
light
bulb
and
trying
to
worry
about
the
security
of
each
one.
We
will
get
too
far
into
the
minutiae
of
security.
I
think
there's
there's.
Definitely
some.
B
So
the
reason
that
I'm
pushing
back
on
this
a
little
bit
is
because
I
think
that
your
model
of
what
a
stub
network
is
is
incorrect.
A
stub
network
is
essentially
equivalent
to
a
bridge,
and
that
doesn't
mean
that
we
don't
want
this.
We
don't
want
to
solve
this
problem,
but
but
so
the
reason
that
I
say
I
agree
with
you
on
this
is
because,
when
we
went
at
apple
to
implement
this,
our
first
cut
at
this
was
to
say
we're
not
doing
that.
B
So
so,
basically,
and
and
by
the
way
we
don't
support,
dhcp
v6
guas,
and
so
your
devices
on
the
stub
network
cannot
communicate
with
the
internet
at
all
period.
However,
that
turns
out
not
to
be
generalizable.
That's
interesting
for
the
case
of
of
apple,
because
apple's
devices
are
all
that
way
right.
B
But
when
we
start
talking
about
matter-
or
you
know
some
of
these
other
ecosystems
they're
expecting
to
be
able
to
connect
to
the
cloud,
and
so
so
that
model
didn't
work
and
the,
and
so
what
we
came
up
with
as
a
model
is
that
the
ce
router
is
probably
the
place
where
this
should
be
done.
Not
the
stub
router,
because
the
stub
router
is
basically
a
dumb
device
right.
It's
not
managed.
U
U
It
should
be
able
to
set
at
least
some
form
of
security
policy.
General
policy
for
that
holistic
group
of
devices.
H
Okay,
irrigating
the
id
for
this
buff,
I'm
just
concerned
by
the
time
the
paragraph
they
are
describing
kind
of
the
purpose,
but
we
don't
see
what
the
work
items
are
and
we
need
to
discuss.
A
O
A
Okay,
so
now
looking
at
the
deliverables,
so
there's
four
proposed
deliverables.
So
looking
at
the
first
one,
I
don't
know
if
you
can
see
the
highlight
so
the
it's
a
document
describing
basic
set
of
functionality
of
a
stub
network
router
that
enables
mutual
discoverability
and
mutual
reachability
between
stub
network
hosts
and
infrastructure
hosts.
So
does
anybody
have
questions
about
what
this
means.
C
A
So,
instead
of
me,
reading
through
I'll
just
like
switch
to
a
different
set
of
slides
to
ask
if
people
understood
all
these
things,
because
you
have
some
time
to
read
this
charter
in
the
beginning,.
A
G
I
didn't
hear
any
clear
result
from
that
security
discussion
as
to
whether
there
was
a
charter
statement
about
security
that
was
being
asked
for
or
was
missing,
or
so
I
don't
know
if
I
don't
know
if
that
conversation
that
conversation
didn't
seem
to
end
with
a
charter.
Amendment.
A
U
Tom
hill
from
bt
again,
my
hope
was
that
the
charter
could
be
security.
Aspirations
could
be
clarified
in
the
charter.
I
think
they're
skimmed
over
at
the
moment.
Okay,.
A
L
A
Okay,
so
so
there's
like,
I
think,
like
two
issues
that
kind
of
have
we
have
to
resolve,
so
one
of
them
is
the
security
related
questions
and
the
other
one
that
came
up
is
eric's
point
about
network
partitioning
and
healing
and
so
on.
So
I
think
ted.
If
you
can
kind
of
make
a
note
like
I
know,
you're
taking
notes
at
the
end
of
the
charter
on
the
google
doc.
But
if
you
can
kind
of
like
try
to
close
the
loop
on
that
after
the
meeting.
A
A
Sounds
good
so
other
than
that?
Is
there
any
questions
about
the
clarity
of
what's
written?
So,
like
you
know,
two
things
came
up.
That's
not
like
there
in
in
the
text
right
now,
but
do
you
have
any
questions
about
the
clarity
of
what's
actually
in
there.
F
Assumption,
yes,
I
have
a
question
about
clarity.
I'm
not
sure
what
the
difference
is
between
the
second
and
third
deliverable.
I
see
that
the
third
one
is
more
general
and
includes
the
second
one,
so
I'm
not
sure
why
the
second
one
exists.
Unless
the
point
is
to
the
second
one
might
be
a
simpler
one
to
address
initially,
and
maybe
the
third
one
would
be
dropped
if
it's
more
general,
so
yeah,
please
clarify
it
was
a
relationship
between
the
second
and
third
thanks.
B
So
I'll
clarify
that
in
the
document,
but
just
to
be
just
to
answer
your
question
briefly,
the
difference
is
connecting
the
internet
is
sort
of
like
cloud
connectivity
connecting
to
adjacent
links
could
mean
connecting
within
like
a
corporate
network
or
something
like
that,
and
the
problems
are
slightly
different,
because
one
of
them
involves
using
a
default
route
and
one
of
them
possibly
involves
more
complicated
routing.
That's
basically
the
distinction.
C
A
Thank
you.
So
we
did
talk
about
scope,
so
there
is
two
issues
that
came
up
with
the
scope,
so
we'll
try
to
address
it
on
the
mailing
list
after
this,
and
does
anybody
think
this
is
like
too
ambitious
to
solve?
If
you
have
any
concerns
hum
or
come
to
the
mic,
anything.
A
Okay,
so
now
eddie,
if
you
want
to
come
up
here
like
so,
we
can
see
the
response.
So
now
we
are
going
through
with
like
a
set
of
questions
which
is
like
typical
for
any
working
group
farming
buff.
So
the
first
question
is:
who
are
here
or
if
you're
online,
please
like
raise
your
hand
for
this.
A
Otherwise,
like
who's
willing
to
author
documents,
contributor
documents
and
edit
documents
in
this
problem
space,
please
raise
your
hand.
A
So
the
count
of
the
room
is
about
like
15
people
doesn't
matter
what
the
number
is
and
remotely
we
have
one
person
who's
like
interested.
In
doing
that,
so
I
would
say:
there's
like
fair
interest
in
doing
that
who's
willing
to
review
documents.
You
can
hum.
A
A
few
people
on
the
online
as
well
is
there
support
to
form
a
working
group
with
the
proposed
charter,
assuming
that
the
clarification
questions
that
gabriel
asked
and
two
scope
questions
that
eric
and
the
gentleman
from
bt,
I
didn't
get
your
name
fully
brought
up
if
they
are
resolved.
Are
you
opposed
to
forming
a
working
group?
So
are
you
willing
to
support
a
working
group
with
the
charter?
A
So
that's
the
question
pending
the
edits
to
the
charter,
so
that
this
is
not
like
binding
until
the
edits
are
done
on
the
mailing
list
and
agreed
upon
okay.
So
the
question
is:
is
it
support
a
form
of
working
group
with
this
proposed
charter
with
the
pending
changes?
If
you
are,
if
the
answer
is
yes,
please
hum.
A
Thank
you.
Is
there
anybody
in
the
room
who
feels
that
a
working
group
should
not
be
formed
in
the
space
hum?
If
you
do,
if
you
do
not
believe
that
a
working
group
needs
to
be
found,
don't
hear
anything
remote.
If
you
have
any
concerns
with
the
group
being
formed,
please
join
the
mic
line.
A
Not
seeing
anything
so
there
is,
I
would
say,
indication
of
support
to
form
a
working
group
and
we'll
take
up
the
further
discussion
on
the
list
for
the
proposed
charter,
and
summarize
the
discussion
towards
our
ad
and
eddie
can
have
the
last
word.
H
A
Thank
you.
Thank
you
very
much.
I'm
into
that
as
people
say.
Thank
you.
So
any
last
comments
from
anybody.
Who's,
remote.
A
Thank
you.
So
the
summary
is
like
there
seems
to
be
indication
to
form
a
working
group
with
this
chatter
in
this
problem.
Space
and
the
charter
needs
to
be
finalized
on
the
mailing
list,
with
some
further
discussion
required,
at
least
on
two,
I
would
say
kind
of
major
topics
and
to
kind
of
tighten
down
the
scope.
So
that's
a
summary,
so
thank
you
very
much
thanks
all
for
coming
and
have
a
great
lunch
thanks.