►
From YouTube: IETF111-INTAREA-20210730-2300
Description
INTAREA meeting session at IETF111
2021/07/30 2300
https://datatracker.ietf.org/meeting/111/proceedings/
A
Hi
everyone
welcome
to
interior
to
the
very
last
session.
A
B
A
A
So
we're
going
to
start
by
the
usual.
Please
join
the
cube
before
participating
to
make
it
easier
for
everyone
and
be
kind
to
mute.
Your
mic
unless
you're
you
are
speaking,
preferably
turn
off
your
video.
If
you're
presenting
you
want
to
turn
on
your
video,
that's
fine!
A
If
you
have
questions
or
any
doubts
about
how
to
operate
meta
code,
you
have
the
links
there
on
the
screen,
the
node.
Well,
this
is
a
regular
itf
meetings.
So
please
be
aware
of
the
the
rules
by
participating.
You
agree
to
follow
the
process
and
policies
if
you're,
aware
of
any
patent
that
covers
any
contribution
or
something
that
has
been
said
here.
Please
disclose
it
and
then,
as
a
participant,
you
are
acknowledging
that
this
written
audio
video
records
may
be
used
and
may
be
made
public.
A
A
The
usual
blue
sheets,
when
you
log
into
the
data
tracker,
we're
going
to
ask
please
to
help
us
with
the
minutes
by
clicking.
A
A
So
the
agenda,
we
have
called
a
heavy
agenda.
We
are
going
to
start
by
giving
you
an
update
on
the
working
group
status.
Then
myself,
I'm
going
to
provide
an
update
of
the
madina's
buff
that
we
had
on
on
wednesday,
followed
by
that
chatura.
We'll
talk
about
the
tactile
internet.
A
Then
we
have
functional
addressing
from
turlos,
then
problems
and
requirements
of
satellite
constellation
for
internet
lin,
han
challenging
scenarios
and
problems
in
internet
addressing
from
iho
jia,
followed
by
gap,
analysis
and
internet
addressing
from
him
as
well
requirements
and
scenarios
for
industry,
internet
addressing
kiran
and
finally,
a
transmission
of
ib
packets
over
overlay
multi-link
network.
The
only
interfaces
by
thread
is
there
any
bashing
or
questions
about
the
agenda.
E
A
Can
someone
help
us
with
within
minutes,
of
course
we're
going
to
be
also
taking
minutes,
but
if
can
we
have
someone
describing.
E
It
can
be
done
after
by
listening
to
the
recording,
of
course,
but
it's
way
better
if
somebody
not
record
everything,
but
only
the
questions
and
the
answers
in
the
commit
it
is
the
top
icon
with
the
square
and
the
pen
on
it
doesn't
need
to
be
accurate.
We
might
try
because
everyone
can
fix
it
later,
but
we
need
to
get
one.
E
E
A
Would
be
much
appreciated,
so
luigi
says
that
he
can
do
it
better
later,
based
on
the
on
the
recording,
do
you
mean
helping
us
with
the
notes?
If
so.
G
Yes,
I
just
wanted
to
say
I
can
help
with
minutes.
I
mean
I
usually
like
to
do
it
listening
to
the
recordings.
If
that
helps,
I
can
do
it.
H
G
You're
most
welcome.
Let's
start
great.
A
Thank
you
so
indeed,
let's
move
on
quick
status,
update
for
the
generic
udp
encapsulation.
This
is
draft
idf
interior
gui,
zero,
nine
that
was
submitted
to
esg
and
it's
been
there
for
quite
a
while
close
to
a
year.
A
So
I
guess
this:
if,
if
there's
no
interest
in
advancing
this
document,
it
will
just
die
soon.
I
don't
know
eric.
Do
you
want
to
say
something
about
it?.
E
Yeah
I
mean
it's.
The
latest
version
is
mostly
two
years
ago
I
submitted
after
my
ad
review
comments
on
the
mailing
list
about
a
year
ago.
In
october
it
would
be
one
year.
My
plan
is
that,
and
the
authors
are
not
here
either
so
in
october
2021.
I
will
declare
this
document
dead,
meaning
it
doesn't
progress.
It's
no
more
part
of
the
working
group
working
continually,
of
course
right,
but
we
need
to
restart
from
the
working
group
adoption.
A
In
this
case,
the
idea
is
for
the
group
to
work
on
the
problem
statement,
the
use
cases
and
the
effects
of
mac
address
randomization
on
different
network
services,
with
the
idea
that
the
group
will
only
work
on
informational
documents
in
the
beginning,
but
also,
and
very
importantly,
will
help,
with
liaison
with
other
seos
and
working
groups
on
this
topic.
A
E
Yeah
and
just
to
be
clear
on
the
process,
as
many
of
us
knows
not
yet
formally
create
it.
I
personally
have
good
feeling
about
it.
After
the
buff
and
the
the
energy
which
is
behind
and
the
draft
charter,
it
will
be
decided
next
week
by
the
iab
and
the
isc
whether
this
working
group
may
proceed
by
the
chartering,
but
I'm
quite
confident
it
will
be
so
stay
tuned
on
this
one
and,
of
course,
collaborate
on
the
chatter
revision.
At
some
point
of
time,
when
we
discussing
with
the
community.
A
Great
okay,
so
thank
you
very
much
with
that.
We
are
going
to
move
to
the
next
presentation,
so
we
have
katura,
please
if
you
want
to
share
your
slides,
it's
your
time.
F
F
C
F
D
F
Right:
okay,
sorry
about
that
guys,
I
am
chatra
chandra
and
I'm
going
to
present
a
draft
that
we've
recently
submitted
on
requirements
for
tactile
internet,
which
I
have
quoted
with
morteza,
which
I
believe
also
online
and
also
mona.
F
F
The
main
goal
of
this
draft
is
to
present
tactile,
internet
or
tr
use
cases
and
then
potential
requirements
that
can
be
addressed
within
ietf
or
ihtf
groups.
This
is
purely
an
informational
draft
that
is
meant
to
address
discussions
in
this
area.
F
So
what
is
tactile
internet
tactile
internet
is
a
new
ict
paradigm
which
can
provide
ultra
low
latency,
ultra
reliability
and
real
time
communications
services
to
emerging
applications
such
as
teleoperation,
immersive,
vr
and
haptic
communication,
which,
which
involves
closed
loop
human
in
the
loop
interactions.
F
Time,
although
there
are
various
existing
related
efforts
in
standards
to
address
some
of
the
requirements,
for
example,
the
work
in
5g
urlc
in
3gpp,
a
more
holistic
approach
could
be
taken
to
support
all
ti
requirements
for
efficiently
supporting
ti
applications.
F
There
is
also
a
working
group
on
tactile
internet
in
israeli
1918.1,
which
looks
at
aspects
such
as
applications,
architecture
and
haptic
encoding.
F
Ti
applications
often
involves
bi-directional
communication,
as
can
be
seen
in
the
figure
which
shows
a
teleoperation
system.
In
one
side,
you,
you
can
see
a
human
operator
which
controls
a
robot
in
remote
task
environment.
F
This
is
done
by
providing
control
input
by
the
human
operator
while
receiving
various
feedback
related
to
the
environment.
In
the
remote
task
environment
there
are
various
end
devices
or
terminals
or
tactile
devices
such
as
sensors
and
actuators,
and
either
side
of
the
both
side
of
the
figure.
So,
usually
you
know
you
could
you
can
imagine
so
these
sensors
are
often
used
for
capturing
doors,
multimodal
information,
while
actuators
are
used
for
executing
the
instructions,
for
example,
provided
by
the
human
operator,
the
tactile
internet.
F
So,
let's
look
at
some
use
cases.
Remote
operations,
automation,
smart
factory,
are
key
industry
use
cases
that
are
enabled
by
ti,
for
example,
ti
enables
remote
repairing
and
maintenance
of
machines.
This
could
be
in
hybrid
scenarios
where
it
might
be
too
dangerous
for
persons
to
go
or
when
it's
too
not
possible
for
an
expert
to
be
physically
present.
At
the
time.
F
Healthcare
is
also
quite
an
attractive
use
case
for
ti,
which
includes
tele
surgery,
tele-diagnosis
tele,
rehabilitation,
telementoring,
for
example,
telesurgery
allows
specialist
surgeons
to
perform
operations,
remotely
even
surgical
robots
that
are
being
used
today.
Although
the
operators
operated
locally,
the
forms
highly
precise
operations,
while
minimizing
the
invasiveness
of
of
the
operation
being
performed
tactile
internet
detector
communication
is
very
important
here.
F
Also
as
tactile
feedback
is
crucial
when
performing
highly
precise
operations,
as
also
mentioned
in
the
previous
use
case,
based
on
an
article
published
in,
I
believe,
2019,
a
surgeon
has
performed
a
remote
operation
using
5g
technology
on
an
animal
from
30
miles
away,
and
this
is
considered
a
world
first
as
well.
F
Entertainment,
one
might
argue
that
is
an
obvious
scenario
where
haptic
feedback
and
communication
can
be
incorporated,
for
example,
by
providing
haptic
feedback
for
vr
gaming.
We
have
tourism
via
applications
or
even
existing
explorations
for
elevating
the
user
experience
as
a
software
of
these
applications.
F
However,
in
collaborative
applications
added
haptic
feedback
will
improve
the
user
experience
to
that
of
or
close
to
to,
the
real
physical
interactions.
F
Audio
again
here
as
well,
audio
video
or
audio
visual
tactile
enabled
learning
experiences,
provide
learning
environments
that
are
closest
closer
to
face-to-face
environments
and
collaborative
learning.
Experi
learning
applications
can
also
be
beneficial,
such
as
military
military
applications
or
sports
applications
where,
where
it
requires
learners
to
solve
problems
in
a
collaborative
manner
where
multi-sensory
interactions
are
key.
F
In
fact,
there
is
a
specific
draft
discussing
this
specific
fact
in
in
dispatch
working
groups
just
referenced
here.
F
So
ultra
low
latency
is
is
quite
an
important
requirement
for
tactile
internet
applications
because
real
time,
haptic
interactions
demand
for
one
millisecond
alteral
latency,
as
can
be
seen
on
the
example
provided
in
the
figure,
and
we
extracted
this
figure
from
a
itu
technical
report
on
tactile.
Internet
timely
delivery
of
messages
is
crucial
for
tactile.
Internet
applications
such
as
remote
maintenance
in
industry
and
telesurgery
in
healthcare
like
low
latency
ultra
high
reliability,
is
a
crucial
requirement
for
tactile.
Internet
applications
as
well
as
you
can
imagine,
hindering
the
reliability
of
communication.
F
Consequences
all
multi-modal
systems
belonging
to
the
same
application.
F
Sorry,
all
multimodal
streams
belongs
to
the
same.
Application
must
be
paid
back
to
the
user
in
a
synchronous
manner.
Otherwise
this
can
lead
to
reduced
quality
of
experience
and
issues
such
as
cyber
sickness
multi-modal,
for
example,
audio
video
haptic
streams
of
the
same
application
may
be
distributed
even
among
multiple
tactile
or
terminal
devices.
For
example,
you
know
these
days.
F
F
It
is
also
important
to
have
mechanisms
for
coordinating
communication.
Such
coordination
mechanisms
may
allow
various
networks
and
network
conditions
to
be
intelligently
handled.
For
example,
there
might
be
scenarios
where
data
where
data
package
scheduling
across
multiple
terminals
or
access
networks
are
required,
especially
in
the
in
scenarios
such
as
multi-device
scenarios,
where
you
might
have
multiple
devices
and
those
devices
connected
through
different
access
networks.
F
F
Tia
tactile
internet
applications
can
be
highly
dynamic,
for
example,
in
a
in
multi-user
scenario,
especially
when
user
profiles,
user,
dynamic
relations
and
interactions
are
present
and
multi-modal
information
corresponded
to
each
individual
user,
especially
related
to
the
user.
Perception
can
be
distinct,
for
example,
a
vr
environment,
where
multi-users
act
on
the
same
environment
perceptions
like
individual
viewpoint.
F
The
operations
were
formed,
tasks
being
performed
type
tools
may
be
used
type
of
objects
that
these
using
interact
with
with
the
information
corresponding
to
each
individual
user
may
differ
and
throughout
the
whole
execution
of
the
application
as
well,
and
therefore
multi-modal
data,
that's
been
transferred
using
separate
streams
to
to
users
may
be
personalized
accordingly.
F
Well,
one
change:
we've
changed
the
term
from
service
requirements
to
application
requirements
to
sort
of
better
reflect
what
we
present
in
the
here
and
to
avoid
ambiguity
and
confusions
as
well,
and
that's
pretty
much
it
for
for
this
presentation
and
questions
comments,
suggestions
are
very
welcome
and
also,
if
you
you
know,
if
there
are
any
suggestions
or
other
suitable
groups
that
might
be
interested
in
the
draft
they're
highly
welcome
as
well.
We've
had
this
discussion
also
on
mailings.
F
H
H
Okay,
so
so
I
I
I
was,
I
sort
of
put
my
question
out
back
when
I
saw
the
the
latency
requirement
about
one
millisecond,
and
I
mean
I
was
wondering
if
you
could
speak
a
little
bit
more
to
why
it's
that
low,
when
humans
are
in
the
loop,
because
I
think
there's
been
a
few
other
people
too,
that
that
seemed
probably
faster
than
was
needed
for
anything
that
involved
human
interaction,
which
presumably
says
this
is
tactile,
we're
all
talking
about
a
human
being
in
the
loop
at
some
point,
and
I
get
the
point
for
the
synchronization
and
the
low
income,
I'm
just
trying
to
push
on
how
low
a
latency
we
do.
H
H
F
Thanks,
thank
you
with
regards
to
the
amount
one
millisecond
requirement.
My
understanding
is
that
it
is.
It
depends
on
the
type
of
application,
for
example,
if
it
that's
why
it's
specifically
worded
as
interactions,
maybe
where
it
it
is,
you
know
it
has
to
be
sort
of
an
online
interaction.
If
you
are,
I
guess
you
know
just
transferring
that
of
you
know.
F
F
F
Even
so,
not
even
you
know
less
of
solution,
but
even
these
problems
are
clear,
but
but
that's
some
of
the
requirements
we
try
to
sort
of
list,
but
yeah,
so
this
is
still
up
for
discussion.
Thank
you.
I
Hello,
my
question
about
this
presentation
is
it's:
it's
not
a
surprise
to
anybody
at
the
ietf
that
we
would
like
a
network
that
is
high,
throughput
and
low,
latency
and
reliable.
I
don't
think
anybody
would
fall
off
their
chair
and
think
that
was
an
amazing
insight,
they'd
never
heard
of
before.
I
So
the
fact
that
we
want
this
is
not
a
surprise.
Is
there
any
proposal
for
how
to
do
this?
Is
this
talking
about
fq,
caddle,
pi
l4s,
something
else?
What
is
the
proposal
for
how
we
would
get
from
where
we
are
today
to
something
better.
F
Thanks,
stuart
yeah,
you
you're
right,
I
mean
yes,
so
always
we
try
to,
you
know
been
trying
to
to
reduce
the
latencies
and
provide
higher
bandwidths
and
etc.
I
so
you
know
exactly
to
ask
to
a
proposal
as
to
how
to
sort
of
solve
this.
I
do
not
particularly
have
fully
solved
the
whole.
You
know
problem
to
meet
all
requirements.
F
I
do
not
have
an
exact
answer,
but
I
believe,
maybe
you
know
addressing
some
of
the
requirements
in
in
different
areas
such
as
your
llc
and
various
other
areas.
I
think
eventually,
that's
that's!
That's
where
we
are
moving
towards.
F
Ultimately,
I
think
also
on
top
of
these
low
latency
and
high
reliability
requirements.
There's
also
this
added
modality
of
communication
there
as
well,
which
is
haptic
communication.
F
I
guess
the
question
for
the
network
community
is
that
do
we
need
or
do
we
need
to
handle
those
traffic
differently
to
the
other
ones
as
well
as,
as
I
mentioned,
there's
already,
a
discussion
on
you
know
having
haptics
as
a
top-level
media
type
as
well,
so
so
that's
sort
of
other
aspects
that
brings
these
applications
into
the
sort
of
picture.
I
Okay,
so
my
suggestion,
if
you
want
to
move
this
work
forwards,
is
propose
ways
to
solve
these
problems,
because
I
think
the
existence
of
the
problems
themselves
is
already
known.
The
question
is
what
to
do
about
it.
A
Thanks,
jordan,
yeah.
J
J
And
yet,
if
we
look
at
the
past
20
years,
then
I
think
it
would
be
fair
to
say
that,
for
anything
that
provides
better
than
best
effort,
ieee
with
efforts
ending
up
in
tsn
have
really
eaten
our
lunch,
and
you
know
we're
struggling
to
with
for
a
comeback
with
tsn,
and
maybe
there
is
a
more
generic
question
of
how
the
community
could
be
more
inviting
to
you
know:
application
use
cases,
industries
that
are
having
more
stringent
requirements
like
this
one.
A
J
If
you
can
accept
my
request
for
sharing
slides.
J
Good,
okay,
terrible
name,
you
know
we'll
pay
pizza
and
so
for
a
better
name.
No,
it's
like
not
moving
what
happens.
J
Yeah
right
so
right
so
so
there
have
been
you
know
recently,
proposals
in
in
area
and
also
you
know,
outside
of
ind
area,
in
more
with
research
focus
about
what
we
can
do
with
addresses
different
semantics
and
so
on.
So
I
started
to
think
about
one
type
of
problem
space
that
I
think
we
haven't
well
explored,
which
is
in
the
title,
independent
address
spaces
and
I've
presented
on
iot
ops.
J
So
the
problem
statement
might
be
something
to
take
out
of
this
work
and
work
in
maybe
an
operational
group,
and
I
specifically
the
solution
proposed
solves
other
problem.
I
think
that
are
much
more
shorter
term
and
much
more
obvious
to
people
in
a
better
shape
than
the
existing
solutions,
but
I
wanted
to
focus
really
on
what
might
be
the
most
offensive
option
that
is
in
here.
Given
how
we've
kind
of
said
this
is
not
a
good
thing
to
do
so.
J
Let's
say
the
generic
issue
that
I
see
is
that
in
our
network
layer,
product
called
ipv6
we've
pretty
much
focused
on
the
one
core
problem
we
needed
to
solve
in
the
90s,
which
is
the
internet
and
forgetting
a
little
bit
that
we
need
to
have
a
network
layer
that
doesn't
only
serve
these
10
of
the
ietf
deployment
iceberg,
which
is
90
percent
under
the
water
line.
J
Since
87
99
we're
calling
this
limited
domains-
and
it
includes
everything
from
embedded
iot
devices
over
to
a
lot
of
other
iot
and
ot
energy
sector,
manufacturing
oil
and
gas
transportation,
nationwide
networks
and
obviously
not
to
the
last
service
provider
networks
with
mpls,
which
all
have
nothing
to
do
with
the
internet.
And
if
you
look
then
at
what
support
do
we
have
in
ipv6
addressing
for
these?
It's
just
a
terrible.
You
know
set
of
limitations
and
challenges.
I
wrote
some
of
them.
J
On
the
left
hand,
side
read
the
document
for
more
and
certainly
a
lot
more
to
go
on
that.
So
the
independent
address
space
is
something
that
you
see
very
often
in
these
type
of
iot
environments
with
larger
networks.
Starting
with
them.
You
know
simple
hierarchically
built
environments
like
you,
build
a
simple
machinery
out
of
an
ethernet
with
attached,
sensors
actors
controllers,
and
then
you
plug
them
together
for
a
larger
machinery
with
another
level
of
networking
and
then
yet
another
one.
And
ultimately
these
things
become
assembly
lines.
And
then
you
look
at
an
overall.
J
Complex
networks,
where
really
the
last
thing
you
want
to
have
is
having
to
bother
about
a
single
global
address
space
into
which
you
would,
according
to
the
end,
to
end
internet
principle
of
ipv6,
have
to
address
everything
in
these
networks
into
so,
and
the
the
one
typical
example
from
ipv4,
which
also
is
why
a
lot
of
these
things
are
still
heavily
built
with
ipv4
and
rfc
1980
in
address
space
is
exactly
such
a
machinery.
J
100X
are
the
fixed
addresses
assigned
to
every
instance
of
the
product
that
is
being
built
in
deployment,
the
gateway
which
is
an
ethernet
switch.
If
you
ever
wonder
why
industrial
ethernet
switches
have
crazy
net
this,
is
it
right,
you're,
basically
mapping,
let's
say
with
the
standard
mechanism
the
third
byte
of
the
address
to
the
orange
ethernet,
so
that
multiple
of
these
type
of
machineries
can
be
disambiguated
in
their
address
and
then
to
the
green
one
another
layer
with
the
second
byte
of
the
address.
J
Maybe
you
can
go
into
ipv6
for
larger
scale,
but
obviously
this
is
not
part
of
the
standard
architecture
of
ip.
It's
an
afterthought
that
people
got
out
of
rfc,
1918
and
ipv6
with
ula
is
actually
worse
and
doesn't
even
offer
any
more
bits
of
you
know
address
that
you
can
munch
with
it's
the
same
16
bit
that
you
have
free
as
an
ipd4.
J
So
with
that
being
said,
let's
take
a
look
at
a
simple
example
scenario:
explaining
how
variable
length
addresses
with
the
semantic
I
think
is
easy
to
implement,
would
be
able
to
solve
that
all
our
addresses
are
written
as
simple
hexa
decimal
addresses,
separated
by
optional
dots.
Just
to
show
you
know
where
the
address
is
segmented
has
no
other.
You
know
functional
at
the
everything
is
modular
four.
So
that
you
know
every
structure
also,
it
prefixes,
for
example,
just
module
four
addresses
lengths,
modulo
four,
so
we
don't
cut
into
a
single
digit.
J
Now
the
important
part
of
the
address
allocation
within
a
particular
network
is
that
every
node
gets
assigned
a
prefix
that
is
not
overlapping
with
any
other
nodes
prefix
and
then
you
just
use
normal
igp
routing.
These
are
all
let's
say,
like
loopback
addresses
routed
so
that
they're
fixed
permanently
assigned
in
a
network.
We've
got
a
lot
of
experience
in
that
with
service
providers,
so
very
easy
to
do
so
now.
What
do
we
start?
J
So
somebody
builds
a
network
from
a
template
like
an
industry
standard
like
I've
seen
it
to
you
know,
and
then
even
you
know
using
addresses
that
people
were
recommending,
which
is
fine,
very
simple.
These
are
all
just
you
know.
What
is
it
eight
bit
long
addresses
so
very
short,
and
then
somebody
else
comes
along
and
builds
a
second
network
exactly
the
same
thing.
Maybe
these
two
are
machineries
and
of
course
you
know
topology
might
be
different
addresses
in
this
case.
You
know
even
totally
overlapping,
but
whatever
the
overlap
is.
J
So
how
do
you
now
interconnect
them,
and
this
is
basically
where
the
proposal
comes
in?
J
What
you're
doing
is
one
network
is
interested
to
connect
to
the
other,
in
this
case,
it's
the
blue
network
on
the
left
wanting
to
connect
to
the
network
on
the
right,
so
it
basically
asks
for
two
links
into
the
network
and
obviously
from
the
right
network.
It's
been
given
two
address
prefixes
one
for
each
of
the
links
they're
getting
configured,
and
so
we
basically
have
a
blue
network
now
two
edge
routers
between
two
independent
address
spaces
that
are
overlapping.
J
So
are
we
sending
packets,
and
this
is
the
the
core
of
the
forwarding.
So,
as
you
can
see
in
the
first
line
here,
52
on
the
left
hand,
side
wants
to
send
a
packet
to
35
on
the
right
hand,
side
the
address
it's
sending
to
is
2
to
135.
J
What
that
means
is
within
the
blue
network.
The
packet
is
forwarded
purely
on
the
destination
address
prefix
two
once
it
arrives
at
two.
The
next
two
digits
have
the
first
one
two
saying
well,
this
is
a
function
of
the
rest
of
the
address
is
telling
you
which
link
you're
going
to
send
it.
So,
let's
say,
link
1
is
exactly
the
link
from
ra
into
network
2..
So
what
then
happens
is
r8.
The
only
thing
it
needs
to
do
is
actually
this
12
bit
lookup
2
to
1
it
strips
that
prefix.
J
You
prepend
the
prefix
to
return
through
ra
before
you
forward
the
packet
into
network
two,
so
you
have
symmetrical
traffic
forwarding
back
and
obviously
this
scheme
can
be
expanded
to
arbitrary
topologies
of
networks
with
independent
address
spaces,
so
very
simple
forwarding,
except
for
the
standard
prefix
lookup
that
we're
already
doing
we
have
a
strip
address
and
prepend
address
function
that
we
would
need
at
edge
routers
between
two
two
networks
with
independent
address
spaces.
J
Now,
if
we
generalize
this
to
show
how
this
type
of
very
simple
semantic
approach
for
building
functional
addresses-
let's
say
an
address
is
a
sequence
of
functions.
Functions
could
either
be
you
know
a
new
other
semantic
or
it
could
be,
as
shown
here,
a
node
prefix.
And
then
it's
followed
by
a
function
code
and
parameters
function
code.
We
had
function
code,
two,
which
is
this.
You
know
inter-network
routing,
but
it's
easy
to
come
up
with
other
function.
J
Codes
use
the
control
plane,
like
we've
learned
in
mpls,
to
assign
semantics
so,
let's
say
function
code
0
could
just
be
followed
by
a
parameter
that
is
the
transport
protocol
and
function
code.
0
means
well
hunted
up.
The
transport
stack,
and
here
is
your
transport
protocol,
so
we'll
eliminate
another
currently
special
next
product
called
field
in
the
packet
header
or
we're
just
doing
the
packet
steering
that
we're
doing
with
msr,
mpls
or
srv6
right.
J
So
pretty
much
the
same
thing:
you're,
removing
the
prefix
but
you're
not
doing
anything
more
very
much
the
same
as
we
would
do
with
function2,
and
then
all
this
srv6
programming
obviously
would
also
very
easy
to
add
into
the
address
as
new
as
new
functions
with
parameters,
and
it
wouldn't
be
a
fixed
64-bit
like
we've
got
in
srv6
now,
but
it
could
be.
You
know
no
wasted
bits.
J
So
there
is
a
lot
that
could
be
said
about
naming
and
address
resolution.
So
how
do
you
know
where
you
go
to?
What's
the
name
of
it?
In
the
first
place,
the
addresses
are,
to
a
good
extent,
names
already,
and
a
lot
of
network
deployments
like
industrial
and
others,
where
you
don't
need
another
namespace
like
dns.
But
if
you
want
to
do
it,
we
have
a
lot
of
experience
with
that
as
well.
There
is
a
very
interesting
21
year
old
enterprise
net
multi-homing
solution
from
yakov
that
I
have
in
the
references.
J
So
all
these
naming
and
everything
things
I
think
we
know
how
to
solve-
maybe
last
just
to
see
how
simple
this
can
become
in
the
forwarding
plane.
Let's
say
we
actually
do
ever
want
to
go
beyond
ipv6
in
the
backward
compatible
fashion.
We
could
build
a
header
that
is
simplified,
removing
all
the
stuff
we
don't
need.
In
most
of
the
cases
just
got
variable
length,
source
destination
addresses
with
their
lens
indication.
We
still
need
hop
limit,
ecn,
new
version,
obviously
so
that
it's
not
over.
J
You
know
changing
with
the
v6
header
as
it
is,
but
then
all
the
qs
stuff,
for
example,
could
go
into
an
extension
editor.
So
simplification
with
more
flexible
functionality,
many
add-on
functions,
we
have
an
extension
center,
could
simply
go
in
the
address
right.
So
here
is
the
boring
summary
here
is
the
hopefully
more
entertaining
summary
for
the
end
of
the
presentation,
and
I
think
we
really
you
know,
have
gone
through
an
evolution
of
domesticating
addressing
and
I
think
we
should
be
ready
to
take
the
next
step
right.
So
this
all
started
with
net
and
ipv4.
J
Then
we
went
through
a
lot
of
experience
with
26
ipv4
to
v6
transition
solutions,
most
of
which
we
would
probably
not
like
and
feel
it's
wild
beasts,
but
some
of
them
actually
are
better.
We
have
good,
you
know
functional
structure
using
v6,
especially
with
multicast.
We
learned
a
lot
and
know
how
to
do
better
with
the
address,
processing
and
mpls
and
source
routing
in
sr
mpls
and
srh.
J
So
you
know,
I
think,
with
a
proposal
like
this,
we
would
make
exactly
all
these
things
that
we've
done
in
the
past
10
years,
especially
in
in
very
you
know,
ad
hoc
fashions,
based
on
a
you
know,
20
year
old
or
50
year,
old
long
address,
ipv6
product
called
a
lot
better.
If
we
would,
you
know,
allow
us
to
think
experimenting
with
a
new
bay
saver
and
I
think
that's
it.
Thank
you
very
much.
F
G
Hi,
just
a
quick
clarification
question
in
so
in
your
schema
or
of
the
addresses
you
have
a
way
to
to
encode
the
function
of
something
at
some
point,
you
made
an
example
where
code
two
identifies
a
link,
which
means
that
now
you
have
an
identifier
or
an
address
or
something
that
allows
you
to
identify
a
link
and
in
the
example
example
that
you
gave
is
about
interac.
J
Now
effectively,
this
is
this,
is
this
is
just
a
path
identifier
right,
so
you're,
basically
saying
go
to
this
edge
router
that
edge
router
removes
its
own
prefix
then
looks
at
what
comes
afterward,
which
he
has
locally
defined
to
be.
Let's
say
you
know
the
digit
two
means
the
next
digit
is.
You
know
one
out
of
16
links
into
different
networks.
I
could
go
to
and
that's
just
all
part
of
what
could
be
done
in
the
control
plane
doesn't
have
to
be
hard
coded
in
any.
You
know,
forwarding
plane,
spec.
E
J
I
I
never
know
what
quote
the
internet
is
to
me.
The
internet
is
a
best
effort,
only
overlay
service.
On
top
of
you
know
thousands
of
underlay
networks,
right
service
providers,
enterprises,
you
know
what
have
you
and
I
think
you
know.
Obviously
everything
needs
to
start
small
in
underlays,
and
you
know
we
haven't
gotten
anything
new
into
quote
the
internet,
not
since
1995,
when
it
commercialized
right,
we
didn't
get
diffserv
into
it.
We
didn't
get
multicast
into
it
right,
the
we
we've
been
struggling
for
15
years
with
ecn.
J
E
J
E
J
No,
no,
I
think
this
this
part,
especially
if
you,
if
you
think
about
what
what
is
the
single
domain
right.
So
if
I
build
a
manufacturing
floor,
the
responsibility
for
the
components
inside
of
it
will
lie
with
the
vendor
of
that
equipment.
Right.
It's
maybe
plugged
together
by
a
fabric
owner,
but
the
fabric
owner
or
the
the
manufacturing
plant
owner,
plugs
together
equipment
that
you
know
which
hierarchically
has
ownership
from
people
who
are
selling
it
as
a
service
and
so
on.
So
but
it's
not
your
internet
interdomain
between
service
provider
with
bgp.
K
Hi,
I'm
very
interested,
however,
question
following
up
extraordinary
question,
so
I
am
quite
surprised
to
see
the
variable
length
header
on
your
slide.
After
all
these
discussions,
we
have
in
every
atf
about
oh,
my
god,
ipv6
extension
headers
are
so
hard
because
they're
variable
lengths
and
we
don't
know
how
to
process
them.
So
what
do
you
think
about
that
conflict?.
J
Yeah
exactly
so,
I
was
been
trying
to
strip
down
the
complexity
in
the
forwarding
plane
because
you
know
going
through
a
chain
of
extension,
headers
and
I
said
through
six
men,
which
was
very
enlightening
right.
I
don't
want
to
have
this,
so
I'm
trying
to
figure
out
how
we
can
make
it
as
simple
as
possible,
and
I
think
we
could
learn
a
lot
from
mpls.
I
think
this
proposal
does
that,
because
if
you
look
at
it,
you
know,
you
see
exactly
the
forwarding
steps
right.
J
The
forwarding
step
was
just
longest
match,
prefix
lookup,
then
one
rewrite
then
recirculation
again
for
this
function.
Right,
if
you
take
the
other
function
which
is
steering
through
the
network,
it
would
be
equally
or
cheaper
than
let's
say,
srh
header
processing
right
equal
to,
I
think,
mpls
forwarding.
J
Okay,
we
need
prefix
lookup
instead
of
fixed
20
bit
address
lookups
right,
but
yeah.
I
think
you
know
bring
it
on
right.
Let's,
let's
have
the
battle
of
comparison
of
the
actual
forwarding,
plane,
processing,
complexity.
That's
I
think
a
good
topic
and
you
know
we
did
two
years
ago.
We
were
talking
about
that
as
well.
In
terms
of
let's
understand
more,
what
forwarding
planes
can
do
these
days
in
the
mpls
design
team?
There
are
a
lot
of
people
standing
up
telling
us
we
can
do
more
now.
A
B
C
Can
you
see
it?
Yes,
okay,
so
my
presentation
is
about
problems
and
the
requirements
of
satellite
constellation
for
internet,
and
this
is
a
only
informational
draft
since
there's
no
dedicated
research
group
or
working
group
for
a
satellite,
and
so
we
bring
this
to
a
internet
area
for
a
presentation.
C
and
starlink
has
provided
a
beta
service
which
proved
that
it
has
some
competitive
quality
over
traditional
isp
and
now
the
starlink
has
launched
about
1500
satellites
and
over
10
thousand
subscribers
and
elements
predicted
will
reach
500,
000
and
quickly,
but
the
deployment
of
the
service
of
satellite
styling
satellite
networking
is
pretty
pretty
preliminary.
C
This
is
information
from
the
reddit,
because
there
are
a
lot
of
technical
discussing
in
that
group.
So
we
can
predict
what
is
the
kind
of
technology
the
starlink
is
using
and
also
this
can
be
a
predict
from
the
service
starting
has
provided
it
only
can
provide
service
in
very
limited
area
and
also
the
quality
is
not
good.
It
needs
a
long
provisioning.
C
So,
besides
starting
more
countries
and
the
more
companies
plan
to
launch
air,
u
and
the
vru,
so
we
will
see
that
what
is
the
kind
of
problem
in
current
starting
accounts-
satellite
motivation,
satellite
network,
so
motivations?
So
this
draft
just
to
analyze
the
issues
and
try
to
draw
attention
from
the
coming
and
it
probably
will
drive
better
solution
in
the
future
yeah
right
now.
C
The
analysis
will
just
give
the
estimation
from
the
orbit
coverage
and
the
communication
time
from
for
the
ground
station
to
satellite
and
between
satellites,
then
analyze
the
feasible
operation
model
for
start
for
satellite
constellation.
C
Finally,
we
will
list
the
problems
we
we
think
it
should
be
resolved
and
as
an
ietf
draft,
we
only
focus
on
on
the
layer
to
and
above
for
example,
mobility,
loading
and
switching
technology.
We
don't
touch
the
radio
or
spectrum
or
those
kind
of
physical
layer
issues.
C
First,
the
the
satellite
orbit
elements
and
the
position.
This
is
a
general
logic
of
astronomy
and
they
have
many
parameters,
but
fortunately
for
the
lu
and
the
vio.
C
One
is
the
inclination,
another
is
the
longitude
of
the
ascending
nodes
which
will
describe
what
is
the
the
the
the
angle
of
this
object
turn
in
this
direction.
Also.
Third,
one
is
the
altitude
of
course,
because
it's
a
circular
orbit.
We
don't
use
this,
which
is
related
to
the
eclipse
of
it
and
also
these.
C
L
C
D
C
Which
is
doesn't
have
population
so
in.
C
C
So
basically,
the
only
known
parameter
right
now
for
the
orbit
is
altitude
and
from
the
starlink
practice
they
give.
The
this
called
the
beta
angle,
which
is
elevation
angle,
means
that
this
is
a
when
the
angle
less
than
this,
the
satellite
is
invisible
and
the
communication
is
not
possible.
So
from
this
we
can
calculate
this
anchor
length.
C
Then,
from
this
similar
as
a
cellular
computation,
we
can
easily
calculate
how
how
many
satellites
needed
to
cover
the
whole
earth
and
also
we
can
estimate
the
maximum
communication
time
for
any
ground
station.
For
example,
if
a
satellite
is
moving
from
here
to
here,
then
the
whole
from
here
to
here.
That
means
that
the
the
diameter
is
the
longest
part.
The
cell
satellite
can
move
for
one
ground
station.
That
distance
can
be
used
as
an
estimation
for
a
how
long
time
the
communication
can
be
lost
so.
C
We
have
calculated
this
is
a
altitude
of
satellites,
vlulu
and
different
altitudes
for
lu.
Normally,
the
altitude
will
be
below
1500
kilometers
and
the
we
are.
You
were
below
500
problems
from
the
practice
of
starlink.
It
seems
like
right
now.
The
the
current
technology
is
still
not
working
very
well
for
air.
U
means
that
the
distance
or
altitude
too
high
right
now.
The
styling
has
moved
a
lot
of
satellite
before
planned,
to
launch
at
air.
U
to
vr.
C
M
K
M
C
Angle,
we
calculated
and
from
that
we
can
calculate
the
the
radio
of
the
coverage
we
can
see.
The
radius
of
coverage
is
from
a
couple
of
hundred
kilometers
to
over
a
thousand
kilometers,
and
this
is
the
minimum
number
required
to
cover
the
whole
earth.
But
this
estimation
is
using
inclination,
angle,
90
degree.
If
the
angle
is
less
than
that,
the
estimation
will
be
similar,
but
it's
not
important
because
right
now
the
rear
deployment
will
have
much
more
density
than
this
requirement.
C
So
here
we
can
estimate
the
communication
time
maximum
communication
time,
and
this
is
for
the
different
altitude
of
satellites.
We
can
see
maximum
communication
time
for
every
ru,
for
example.
This
is
only
300
kilometers
only
about
200
seconds,
even
for
air.
U
only
about
400
seconds,
which
is
less
than
5
minutes.
Remember.
This
is
maximum
communication
time,
so
normally
the
communication
time
will
be
less
than
this.
C
Here.
We
also
estimate
for
the
inter
satellite
communication
how
long
time
the
communication
can
last
so,
for
example,
we
have
a
different
intersection
angle
if
the
zero
means
that
satellite
moving
with
the
same
direction
for
different
altitude
of
the
satellite-
and
we
can
see
even
with
the
same
angle,
if
the
the
the
with
the
same
direction,
if
the
speed
are
different
in
the
draft,
we
have
more
data
here.
This
table
is
not
complete.
C
Will
talk
about
the
satellite
networking?
This
is
not
about
the
issue
of
individual
satellites.
This
is
about
satellite
constellation,
so
the
issue
will
be
much
more
complicated
and
first
we
we
can
figure
out.
What
is
the
possible
operation
model
right
now?
We
can
easily
think
about
two
models.
One
is
called
a
satellite
rayleigh
cell
really
means
that
a
single
will
be
bounced
between
satellite
and
the
ground
station,
either
by
one
satellite
or
by
multiple
satellites.
C
The
second
one
will
be
a
a
single
will
go
through
the
into
satellite
link
between
satellites,
but
this
technology
is
still
not
mature
and
the
styling
has
started
to
experiment
some,
but
definitely
is
not
used
right
now,
as
we
can
predict
only
this
large
is
used.
C
C
The
maximum
time
of
communication
can
only
last
probably
less
than
five
minutes,
and
if
we
bring
the
in
the
inter
satellite
communication
to
the
picture,
then
the
communication
between
satellite
will
be
also
not
very
steady.
Not
like
a
current
service
provider
network,
it
will
keep
changing
every
day,
for
example.
C
So
common
issues
first
is
a
mobility,
for
example.
Right
now
we
have
already
have
many
mobility
technologies
there,
but
the
current
mobility
technology
may
not
be
helpful
for
this
spatial
scenario,
for
example
right
now
all
mobility
technologies,
based
on
the
assumption
that
mobile
and
communication
mobile
and
communication
node,
plus
the
static
base
station
and
provider
network.
C
So,
for
example,
the
3gpp
wireless,
the
cell
phone
is
moving
base
station
is
not
moving
mobile
car
is
not
moving
service
provider
network,
also,
not
moving,
so
we
have
an
intel
or
intel
defense
over
there.
The
the
scheme
is
relatively
easy
because
the
mobility
is
very
limited
in
very
limited
devices,
and
also
itf
introduced
the
mobile
ip
mobile
v6,
proxy
mobile
iqv6
and
lisp,
and
in
the
recent
presentation
I
saw
the
atm
also
come
to
picture,
but
it's
still
based
on
all
these
existing
technologies.
C
Even
it
is
used
for
the
airplane
and
the
cell
line.
Mobility
is
different.
We
will
have
a
and
the
communication
node
static.
For
example,
if
you
use
the
satellite
for
home
access,
your
your
ground
station
is
static,
but
the
provider
network
is
moving
right
now,
if
you're
using
the
satellite
as
a
provider
network,
it
will
be
keep
moving
and
also
the
moving
speed
is
fast,
as
I
show
that
the
communication
time
is
very
short.
C
Second
things
we
have
to
consider
is
that
in
satellite,
the
parking
supply
is
very
constrained
because
of
this
then
packet
loss
falling
should
consider
this
limitation.
C
Also,
the
link
speed
is
limited,
for
example,
in
from
the
current
research,
even
we
use
a
laser
for
in
the
satellite
link.
Probably
the
link
speed
is
still
below
the
10
gig
from
the
current
technology.
C
Here
I
will
show
some
issues
for
the
different
operation
model
and
I
don't
list
all
the
requirements
and
the
problems
because
some
other
problem,
I
think
we
have
solution
and
it
is
listed
in
the
draft,
because
traffic
has
over
30
pages.
I
don't
want
missed
some
less
important
issues
here.
I
just
want.
H
C
What
is
the
critical
one,
for
example,
if
we
only
use
one
satellite
to
do
the
communication,
it
will
be
same
situation
as
we
use
the
gso
currently,
for
example,
geosynchronous
orbit
satellites
it
just
physically
reflecting
the
single
between
ground
station
and
the
satellite.
It
will
be
easy,
but
if
we
have
multiple
satellite
really
come
to
picture,
it
is
not
that
simple.
Why?
Because
the
the
real
satellite
constellation
will
have
a
lot
of
ground
stations
so,
for
example,
from
styling
requests
from
fcc
right.
C
They
request
over
one
million
ground
station,
one
million
grand
station
in
which
they
have
three
types.
One
is
the
end
for
end
user
second,
is
that
the
ground
station
can
connect
to
internet.
Third,
one
is
a
ground
station
is
a
is
a
core
gateway
ground
station.
These
two
could
get
regrown
station,
but
some
gateway
ground
stations
not
connect
to
internet
and
from
current
data
in
united
states.
C
There
are
about
already
about
more
than
100
grand
station
here,
so
we
so
many
ground
station
and
the
number
of
satellites
and
the
the
scenes
will
become
competitive,
for
example,
even
between
two
ground
stations
right,
they
may
have
multiple
satellites.
Come
above
and
all
satellite
can
provide
a
service
then,
which
one
we
you
will
choose.
C
It's
not
a
simple
issue.
Second,
is
that
what
is
the
ground
station?
You
will
choose
to
reflect
your
signal.
For
example,
you
have
multiple
satellites,
you
have
multiple
ground
station
and
which
one
you
will
be
pure
for
your
co-pass,
for
example.
This
is
a
final.
We
we
can
reflect
a
single
between
a
multiple
ground
station
and
satellite
to
reach
one
ground
station
which
is
connect
to
internet
then
which
possibly
choose
you.
You
may
have
a
different
process
so.
C
Typical
issues
involving
the
multiple
satellite
relay
and,
of
course,
for
all
these,
we
have
to
think
about
the
the
how
to
solve
it
in
terms
of
protocol
or
technology.
A
C
C
Okay,
so
next
is
about
interstellar
communication
used
for
satellite
networking.
This
is
the
most
compelling
and
it
will
become
a
compilation
of
sl
link
and
the
satellite
random
station
link
ground
station
could
be
isolated
or
interconnected
right
now.
The
technology
is
not
mature
and
the
two
key
issues
one
is
the
inter-satellite
communication.
C
This
is
not
the
direct
concern.
We're
only
concerned
about
the
rotting
and
the
switch
here
is
the
issues
all
satellite
consolidation
is
moving
and
according
to
traditional
technology,
we
should
use
igp,
for
example,
ebgp
between
the
internet
and
the
ground
station,
and
also
ebgp
between
the
local
internet.
And
this,
then,
if
there
are
so
many
ground
stations
and
so
many
network,
and
if
the
qualities
keep
moving,
definitely
the
current
technology
cannot
handle
it.
For
example,
we
have
massive
igp
flooding
and
the
bgp
convergence
will
come
to.
A
Thank
you
very
much,
so
let
me
jump
here
in
the
queue
I'm
curious
about
whether
you
are
proposing
to
solve
this
at
layer
three,
because
the
the
problem
has
existed
for
a
while,
since
the
like
late
90s,
when
the
telethis
network
was
first
planned,
they
were
already
solving
it
at
layer,
two
within
their
satellite
links,
and
then
the
internet
was
running
on.
On
top
of
that,
so
is
your
problem.
Yes,.
C
Yeah,
as
I
said
right
now,
the
the
the
historic
work
is
only
focusing
either
fiscal
layer
or
just
using
the
individual
or
very
few
satellites
to
do
the
communication
by
right.
Now,
if
the
satellite
becomes
the
number
become
big
and
the
ground
station
number
become
big,
the
issue
will
be
different.
C
No
networking
issue
was
involved
before
right
now.
The
definite
networking
issues
involved,
for
example
the
starting
customer,
think
about
it,
deploy
a
provider
service
in
the
ocean
when
in
the
ocean,
then
there's
no
ground
station
can
connect
internet.
You
have
to
use
multiple
ground
stations,
then
how
to
do
it
in
that
from
the
networking
manner
is
a
challenge
we
don't
have
solution
right
now.
We
just
want
your
attention
for
this
typical
issue.
C
We
just
have
some
sort,
but
it's
very
preliminary
and
we,
I
think
we
there
may
have
a
different
technology
involved.
Then
maybe
more
solution
will
come
to
come
to
the
community.
A
All
right
well,
thanks,
then,
we'll
continue
on
the
list.
Well,
we
have
eric
on
the
line
and
then
we
can
move
on
to
dirk
eric.
L
Yeah,
I
just
was
gonna
repeat
a
comment
I
made
in
the
in
the
chat.
I
think
that,
because
the
satellites
are
their
motion
is
highly
predictable,
you
don't
need
a
routing
protocol
to
like
deal
with
a
bunch
of
dynamic
updates,
except
in
the
case
of
inter-satellite
link
failures.
L
C
N
Yes,
thanks
yeah,
I'm
going
to
present
the
next
two
drafts.
I
know
they
are
listed
as
two
separate
items,
but
we
combined
them
because
the
work
is
kind
of
like
building
on
onto
each
other.
So
this
is
about
the
internet,
addressing
problem
statement
and
the
gaap
analysis.
We
present
the
problem
statement
initially
in
the
last
itf
and
as
presented
there,
the
the
plan
to
continue.
N
Since
so,
I'm
going
to
provide
an
update
on
the
problem
statement
and
then
go
into
the
cab
analysis
yeah,
it
is
so
I
mean
told
us,
provided
quite
a
bit
of
the
background
where
we're
also
building
on
internet.
Addressing
is
the
core
method
and
allows
me
to
direct
packets
in
the
global
internet,
but
but
as
similar
to
tools
observation.
We
can
see
that
a
lot
of
the
over
communication
system,
actually,
you
know,
lies
in
limited
domains
as
described
in
rc
87.99
and
those
limited
domains.
N
Define
requirements.
Note
behaviors,
address
semantics
packet,
forwarding
that
may
be
significantly
different
from
the
internet,
addressing
paradigm
while
still
potentially
interconnecting
or
connecting
to
the
the
internet
or
interconnecting
over
the
internet.
That
very
often
requires
that
there
are
additional
adaptation
technologies
involved
that
realize
the
distinguishing
requirements
of
these
scenarios.
So
that's
the
the
background
and
the
observation
from
which
we
started
the
work
in
the
in
the
problem
statement
draft.
N
You
know,
and
should
that
be
a
key
focus
for
the
involved
internet,
addressing
that's
the
kind
of
key
key
question
that
we
ask
in
the
problem
statement
draft
for
that
we
formulated
the
problem
statement
draft
by
providing
examples
for
communication
scenarios,
where
the
existing
internet
addressing
structure
may
be
a
potential
hindrance
and
then
provide
a
first
gap
analysis.
So
we've
done
this
already
in
the
last
idea.
N
Haven't
updated
this
since
and
we
then
provided
a
first
gab
analysis
in
which
we
provide
an
overview
over
the
many
recognized
extensions
to
the
core
internet,
addressing
properties
as
we
can
find
them.
So
generally.
Our
intention
for
these
two
drafts
is
to
stimulate
discussion
on
the
emerging
needs
for
addressing
really
to
you
know
to
get
to
a
point
where
we
would
want
to
fundamentally
rethink
the
addressing
in
the
internet
beyond
what
what
ip
physiques
and
the
current
objective
give
us
at
the
moment
we
do
recognize.
N
There
are
a
number
of
proposals
that
fix
aspects
or
claim
to
fix
aspects.
We're
not
the
trumps
are
not
about
promoting
one
over
the
other.
This
is
really
about.
You
know
the
need
to
identify
sorry
to
recognize
the
need,
work
towards
an
architectural
approach
and
think
about
extensibility
and
evolution
of
internet
addressing
in
you
know
to
start
with.
N
So
what
are
the
updates
on
the
problem
statement?
As
I
mentioned,
we
provided
first
draft
in
the
last
itf.
We
since
then
added
two
new
quarters
to
the
to
the
problem
statement.
Transfer
provided
input
into
a
number
of
communication
scenarios
yamala
from
rochester
institute
in
paulo
from
airbus.
N
We
simplified
the
the
the
structure
of
the
problem
statement
draft.
In
the
light
of
the
gap
analysis,
we
moved
a
lot
of
the
in
particular
section.
Three
was
significantly
updated.
First,
we
updated
the
scenarios
based
on
the
input
that
were
provided
by
our
new
co-authors,
as
I
mentioned
before,
and
then
the
the
issues
were
simplified
in
the
light
of
the
separate
gab
analysis.
So
so
the
the
section
is
actually
significantly
shorter
now
as
it
used
to
be
before,
and
some
of
the
things
were
then
moved
into
the
gap.
N
Analysis
draft,
even
though
we
added
fragility
and
extensibility
as
additional
concerns
that
were
previously
not
listed
as
issues
in
addressing
them
and
then
again
finishing
with
the
actual
problem
statement.
So
these
are
the
updates
on
that
draft,
the
for
the
gavin
understaffed,
so
the
main
flow
of
the
document.
N
N
A
number
of
extensions
have
been
that
have
been
defined
and
we
position
them
as
attempts
to
fill
identified,
gaps
and
properties
through
these
point
solutions,
as
we
identified
them
to
overcome
those
identified,
apps
gaps
so
the
so
the
the
the
logic
is
that
these
extensions
have
been
developed
to
address
something
that
that
those
who
develop
the
extensions
have
have
perceived
as
a
gap
in
internet
addressing.
N
N
The
second
part,
the
extension
in
section
three
and
the
issues
in
section
five
section
fours
and
is-
is
an
overview
table
which
you
can
see
here
so
in
overall,
we
identified
20
plus
extensions
that
we
described
and
referenced
and
we're
very
happy
to
receive
pointers
to
more
approaches.
So
this
is
obviously
a
first
run.
N
This
is
a
first
version
of
the
gav
analysis,
so
you
may
appreciate
that
we
have
overlooked
a
number
of
extensions,
obviously,
but
we've
taken
that
initial
list
already
as
I
as
a
as
an
evidence
of
shortcomings
to
internet
addressing
properties,
as
as
you
know
in
in
the
way
of
these
extensions
having
you
know,
having
addressed
particular
aspects
that
the
the
developers
or
authors,
we
also
included
some
research
work
and
and
as
well
as
existing
standards.
N
So
there's
a
mix,
a
healthy
mix
of
of
aspects
and
extensions
that
are
described
in
in
that
section,
and
we
took
this
as
evidence
that
those
do
you
know
the
developers.
Extensions
have
you
know,
seen
shortcomings
of
the
internet
addressing
as
a
reason
for
developing
them
send
us
we
as
a
summary
of
the
issues
we
identified
in
in
in
red
here,
and
the
table
is
also
in
in
the
draft,
are
issues
that
lead
to
limiting
the
outer
semantics.
N
Because
of
you
know
certain
ways
with
which
the
extensions
were
fitted
into,
for
instance,
ipv6
and
needed
to
deal
with
the
limitations
that
were
given
through
that
issues,
around
complexity
and
efficiency,
issues
around
security
and
fragility.
Complexity
and
efficiency
includes
aspects
like
repetitive
encapsulation,
compounding
issues
with
header
compression,
introducing
path
stretch
or
or
making
traffic
engineering
more
complicated
and,
and
then
we
assigned,
as
you
can
see
in
the
table.
Obviously
in
more
words,
this
is
just
the
summary
table.
What
the
various
issues
are
and
then
which
of
the
approaches
experienced
or
those
particular
issues.
N
So
these
identified
extensions
provided
evidence
that
are,
there
are
gaps
remaining
if
you
will,
because
the
the
the
issues
or
some
of
the
issues
either
still
existed
or
other
issues
were
simply
introduced
through
the
solution.
N
N
We
also
have
identified
that
the
community
has
recognized
that
shortcomings
do
exist
to
the
original
properties
and
thus
developed
point
extensions
where
you
attempt
to
fix
them
right.
So
we're
not
the
only
one
that
recognizes
shortcomings.
The
internet
community
overall
has
recognized
that
it's
been
working
around
those
shortcomings
for
a
very
very
long
time.
N
We
also
identified
that
there
are
a
number
of
compounding
issues
with
those
extensions
that
particularly
increase
the
fragility.
When
you
consider
point
extensions
of
coexistence,
we
have
a
separate
subsection
in
the
gap,
analysis
graph
that
that
addresses
that
particular
aspect
and
and
and
while
we
we
we,
we
may
see
the
idea
of
doing
point
extension
to
addressing
here.
If
I
have
an
issue,
I
just
do
my
own
extension
over,
possibly
any
existing
or
even
a
new
header
field
as
the
powerful
tool
for
extending
the
internet
itself.
N
What
we
have
described
in
the
craft
is
that
by
doing
so,
you
know
you,
you
start
creating
a
whole
tale
of
further
issues
that
may
just
you
know,
roll
off
that
point
extension
and
it
it
most
importantly,
it
may
increase
the
complexity
as
well
as
the
fragility
of
the
overall
system.
So,
yes,
it
may
be
a
very,
very
powerful
tool,
but
it's
not
one
that
comes
without
problems
on
its
own.
N
So,
what's
the
expectation
that
we
have
for
going
forward?
Well,
as
I
said
mentioned
before,
we
want
to
promote
a
discussion
to
develop
an
architectural
but,
more
importantly,
a
sustainable
approach
to
make
internet
addressing
extensible.
So
we
can
capture
the
many
new
use
cases
that
we
may
identify
and
then
looking
back
at
the
a
very
first
presentation
from
chatura,
you
know
question
that
could
be
asked
in
in
in
in
his
particular
area.
N
He
presented
whether
or
not
there
were
there
would
be
any
addressing
issues
that
one
may
identify
for
these
particular
type
of
new
new
use
cases
he
had
in
mind.
I
think
I
asked
a
similar
question
on
the
mailing
list
when
he
sent
the
draft
around.
N
We
also
believe
that
any
inaction
on
our
side
will
only
compound
the
issues
we
identified.
It
doesn't
make
it
better,
they
won't
go
away
and
we
feel
that
eventually
it
will
hamper
the
future
internet's
readiness
to
address
those
and
then
support
those
new
use
cases,
and
not
only
the
one
that
we
mentioned,
and
there
are
many
others
that
also
taught
us
pointed
out
in
his
presentation
with
the
iceberg
quite
nicely.
N
So
what
are
the
next
steps
that
we
have
in
mind?
Well
for
the
problem
draft?
We
we
would
like
to
expand
on
possibly
missing
communication
scenarios.
The
same
way,
we've
done
this
after
110
to
reach
out
to
potential
contributors
to
either
extend
or
add
communication
scenarios
that
we
may
have
missed
we're
very
interested
in
that.
N
Obviously,
for
the
gab
analysis,
the
the
the
extension
we've
identified
are
only
the
beginning,
even
though
they're
20,
plus
at
missing
extension
that
are
addressing
in
order
to
elaborate
on
the
issues
through
more
evidence
and
evidence
and
references
that
we
can
find
right.
The
more
extension
we
find
the
more
we
believe
you
find
evidence
that
in
particular,
they
are
compounding
issues
with.
N
What's
developing
those
extensions
for
that
we
seek
new
co-authors
and
contributors,
even
you
know
would
like
to
identify
the
right
partners
organization
to
work
with
you
know,
maybe
even
in
the
form
of
liaison
like
like
the
one
being
proposed
by
the
iec,
for
instance,
on
underwater
networks
as
an
example
that
that
came
to
our
attention
that
one
could
use
to
maybe
work
with
other
organizations,
in
particular
those
that
are
that
are
bringing
these
new
requirements
into
or
towards
the
itf
goal.
N
Ultimately,
for
us
is
the
adoption
of
the
documents
for
future
work
in
the
in
the
area
to
go,
to
extend
the
gap,
analysis,
to
move
to
a
discussion
on
requirements
and
as
to
what
the
requirements
of
future
solution
may
be
before
we
start
looking
into
potential
approaches
to
solve
these
issues.
N
The
questions
we
have
to
the
community
is
whether
or
not
the
extensions
have
shown
that
gaps
to
addressing
have
you
know
have
been
identified
is
the
logic
we
apply
the
right
one.
Are
they
identified
issues
worth
thinking
of
different
approaches,
or
are
we
just
you
know
fine
with
doing
those?
Do
we
think
we
can
avoid
the
issues
or
you
know
just
uncover
others?
N
Does
the
community
believe
that
or
agree
that
an
architectural
approach
is
required
that
make
extensibility
of
addressing
a
key
principle
to
future
addressing,
or
can
we
just
continue
doing
what
we've
done
so
far
with
all
the
issues
that
we
found
in
the
gab
analysis
and
may
find
in
future
extensions,
and
obviously
the
the
question
for
us
going
forward-
contributes
to
the
discussion
want
to
work
with
us
and
push
the
discussion
and
the
material
further
through
extending
the
drafts
and
working
in
future
drafts
thanks.
That's
it
for
my
site,
questions
and
comments.
A
N
A
Community,
okay!
Well,
if
we
don't
have
any
questions
right
now,
I
think
that
it's
a
topic
that
I
invite
you
to
bring
to
the
to
the
list,
especially
if
you're
seeking
to
to
get
some
work
in
this
area
in
interior.
We
need
to
see
some
some
support
reviews
on
from
the
from
the
group,
so
I
encourage
you
to
bring
the
discussion
to
the
mailing.
A
D
A
On
we
have.
A
A
M
Yeah,
so
sorry
about
that,
my
name
is
kiran,
and
this
draft
was
first
presented
in
iot
ops
group
on
monday.
So
what
we
are
trying
to
do
here
is
bring
in
the
scenarios
and
some
of
the
challenges
which
are
related
to
industry
control
networks.
Since
an
itf
we
have
talked
a
lot
about
constrained
devices
or
iot.
M
So
since
we
discussed
most
of
the
stuff
there,
I
just
want
to
introduce
this
topic
a
little
bit
and
we'll
just
introduce
a
little
bit
of
industry
control
networks,
some
of
the
scenarios
and
challenges
we
are
looking
at
and
what
are
the
possible
functional
areas
that
could
possibly
overlap
between
area
and
iot
ops
work.
M
And
if
you
look
in
deeper
into
what
are
the
different
properties
of
devices
in
the
process
control?
First
of
all,
they
are
wired
devices.
They
are
not
wireless
devices,
so
they
do
not
have
specific
requirements
for
saving
on
energy
or
how
you
can
use
them
or
things
which
we
have
already
discussed
in
the
iot
six
slope
and
and
those
type
of
technologies
and
protocols.
M
But
these
are
the
critical
factors
are
that
they
have
direct
process
control
loops
the
process
in
the
sense
that
you
have
to
have
time
constrained
networks,
and
since
that
work
is
already
done
in
that
net.
We
were
not
really
focused
on
that
part,
but
the
communication
pattern,
security
and
the
location
how
the
devices
move
on
the
factory
flows.
M
All
these
things
are
very
well
planned,
so
you
have
some
sort
of
deterministic
view
of
your
network
that
how
it
is
going
to
behave
and
because
of
that
operators
of
those
networks
they
very
carefully
engineer
and
design
their
network
in
the
sense
that
they
are
stingy
about
what
kind
of
network
resources
or
how
much
of
network
resources
they
are
deploying
on
those
factory
floors,
because
their
focus
is
on
the
operations.
Part
first
and
the
communication
patterns
are
very
different.
M
You
don't
have
a
large
package
sizes
up
until
now
you
it
is
mostly
a
command-based
system.
You
will
have
a
register
in
the
command
and
a
register.
You
just
you
want
to
send
a
two
byte
or
a
one,
byte
command
for
a
machine
to
move
in
a
specific
direction
or
with
a
specific
pressure
applied
onto
it,
but
with
automation.
These
things
are
changing
so
with.
M
When
we
start
talking
about
itut
conversions,
the
decision
to
move
it
servers
on
factory
floors
will
become
one
of
the
biggest
questions
so
right
now,
your
factory
floors
are
very
focused
on
ot,
related
technology
operations,
technology
and
when
you
start
talking
about
industry
protocols
ib
and
if
you
want
to
take
ip
all
the
way
down
to
the
devices,
it
is
going
to
be
an
overhead.
M
Another
scenario
which
is
evolving
is
virtualization
in
this
case.
M
Right
now
so
far
we
have
physical
plcs
on
the
factory
floors,
but
with
virtualization
they
are
talking
about
virtual
plc's,
and
that
brings
a
question
that,
where
would
you
log,
we
would
want
to
place
that
software
will
that
be
on
the
factory
floor
or
on
the
edge
or
somewhere
in
the
cloud
and
very
much
related
to
that
is
sophisticated
compute
platform?
M
M
There
are
also
implications
on
data
growth
and
the
reason
for
that
is
so
right
now
everything
was
like
a
push
you
want
to
put
a
comma.
You
want
to
send
a
command
down
to
a
specific
machine
on
the
factory
floor,
but
now
in
order
to
collect
lot
of
telemetry,
additional
sensors
are
being
installed
and
those
sensors
will
continuously
send
the
data
up
to
wherever
you
have
some
kind
of
statistics
or
telemetry
telemetry
control
system,
and
you
want
to
feed
that
into
your
business
logic,
to
see
how
your
inventory
is
doing.
M
When
do
you
want
to
start
the
process
or
when
do
you
want
to
finish
the
process?
What
will
be
a
good
time
to
start
a
particular
manufacturing
cycle?
So
in
order
to
make
all
those
decisions,
you
need
to
collect
lot
of
sensory
data
and
that
will
cause
the
data
growth
and
the
fourth
aspect,
which
normally
people
generally
do
not
discuss,
is
that
even
on
the
factory
floor,
there
are
different
kinds
of
infrastructure
interplaying
with
each
other.
M
You
could
have
a
building
automation
system
where
you
want
to
control
air
conditioning,
cooling
and
lighting
of
the
plant,
and
you
could
also
have
some
kind
of
security
system
intruder
detection
that
was
coming
in
or
out
of
the
factory.
You
would
also
have
additional
cameras
installed
just
for
the
quality,
control
and
inspection.
M
All
these
are
different
applications,
specific
networks
serving
different
kind
of
purposes
and
from
the
automation
perspective,
to
have
a
single
view
of
your
system.
You
would
want
to
integrate
those
things
together
and
we
want
to
study
how
idf
based
protocols
or
id
technologies
can
play
a
part
there
and
from
the
from
from
a
high
level,
we
looked
at
two
key
challenges:
one
is
the
heterogeneity.
We
talked
about
that
there
are
different
infrastructures
on
the
same
factory
floor
and
actually
there
are
around
100
different
protocols,
fieldbus
related.
M
They
are
modbus,
profibus,
building,
automation
and
whatnot,
and
within
them
there
are
different
variations
based
on
vendors
or
some
small
group
of
companies
standardizing
a
particular
protocol
just
among
themselves,
and
then
there
are
a
lot
of
what
that
means
is
to.
In
order
to
absorb
that
heterogeneity.
There
are
multiple
stateful
gateways
install
are
required
on
the
factory
floor,
you're,
always
translating
from
one
protocol
to
the
other
protocol,
which
is
not
really
an
efficient
and
scalable
way,
especially
when
you're.
When
you
start
adding
a
lot
of
sensors
and
more
number
of
devices.
M
Sorry,
you
have
one
minute
left,
okay,
so
automation.
I
already
talked
about
that.
How
do
you
go
from
device
to
all
the
way
to
the
cloud?
What
are
the
mechanisms
that
we
need
to
install
in
order
to
make
that
happen,
and
when
we
were
looking
at
these
things?
Obviously
addressing
came
as
one
of
the
key
differentiator.
M
And
how
could
we
simplify
these
things?
On
the
left-hand
side?
Is
the
current
state
of
work
where
you
have
state
in
the
industry
where
you
have
different
protocols
stacks
and
what
we
think
is
that
if
we
had
some
kind
of
asymmetric,
addressing
mechanism
where
you
were
your
address,
formats
for
the
source
and
destination
were
different,
but
you
could
still
do
a
communication
between
them.
M
That
will
really
simplify
your
network
architecture
on
a
factory
floor,
and
so
these
are
the
potential
work
areas
you
could
look
at
it
from
the
device
perspective
in
the
industry
on
the
factory
floor
from
the
network
layer
perspective
and
some
additional
stuff
on
the
network,
that
how
can
you
make
encapsulation
free
communication
between
devices
and
the
cloud?
M
So
we'll
continue
to
have
these
discussions
in
the
iot
ops
and
come
up
with
a
very
comprehensive
document
on
scenarios
and
the
requirements
and
possibly
go
deeper
into
the
addressing
aspects
of
it.
So
we
just
wanted
to
share
this
with
interior
group
and
see
if
there
is
any
interest
here
and
if
you
would
like
to
have
discussions
on
interior
group
I'll
definitely
bring
this
work
there.
A
All
right,
seeing
none
if
anyone
has
any
other
comment,
please
bring
it
up
to
the
to
the
list
and
provide
your
feedback
there.
D
D
D
D
The
work
is
also
very
closely
related
to
but
separate
from
a
draft
that
was
an
interior
called
interior
tunnels.
That
apparently,
has
been
expired
for
the
past
several
months.
D
So
talking
about
arrow
and
omni
in
a
single
inner
network
example,
we
have
client
nodes
that
connect
to
access
network
sub-networks
via
one
or
more
data
links.
D
Those
sub-networks
then
connect
to
the
internetwork
via
proxy
servers
as
sub-network
edge
nodes
and
those
proxy
servers
act
as
ipv6
routers
or
ipv6
neighbor
discovery
proxies
bridges
within
the
within
this
in
the
internet.
Work
establish
a
spanning
tree
over
the
internet,
work
using
ipv6,
unique
local
addresses
ulas
and
the
omni
adaptation
layer
in
all
nodes
that
configure
omni
interfaces,
use
ipv6
encapsulation
and
see
this
spanning
tree
as
a
layer,
2
service,
the
same
as
if
it
was
a
bridge
campus
land.
D
Some
examples
of
internet
working
segments
would
include
the
ipv4
internet,
the
ipv6
internet,
corporate
enterprise
networks,
cellular
operator
networks,
aeronautical
telecommunications,
service
provider
networks,
and
one
thing
to
note
is
that
the
clients
may
also
connect
to
multiple
distinct
segments.
At
the
same
time,
it's
not
shown
in
this
diagram
to
reduce
complexity,
but
in
the
big
picture
we
can
have
arbitrarily
many
segments
in
networking
segments
connected
together
into
a
single
nbma
link
using
encapsulation
at
the
ol
layer.
D
D
So
if
you
see
the
diagram
in
the
upper
left,
you
have
the
iplayer
in
the
end
system
configured
over
and
on
the
interface
within
the
omni
interface,
the
omni
adaptation
layer
maps,
the
ip
layer
to
the
underlying
interfaces
that
are
shown
here
as
l2
if1,
if2
and
ifn,
and
so
forth.
D
The
omni
interface
uses
ipv6
encapsulation
to
span
the
entire
concatenated
internetworking
path
in
a
single
nbma
layer,
3
hop
and
all
arrow
and
omni
nodes
are
seen
as
neighbors
on
the
link,
as
is
shown
in
the
right
hand,
diagram.
So
the
omni
link
is
an
overlay
over
arbitrarily
many
inner
networks,
with
all
nodes
on
the
omni
link
that
configure
omni
interfaces.
That
is
seen
as
neighbors
on
the
link,
so
omni
client
underlying
interfaces
can
be
coordinated
with
their
proxy
services
in
one
of
several
ways.
D
First,
we
have
direct
connect,
otherwise
known
as
point-to-point
client
underlying
interfaces
and
these
connect
directly
to
the
proxy
server
at
layer
2
over
point-to-point
media
without
traversing
any
layer,
3
hops,
then,
with
vpns.
The
client's
underlying
interface
uses
network
layer
security
to
establish
a
virtual
link
to
the
proxy
server
over
one
or
more
l3
hops
at
the
layer
below
the
vpn,
that
is,
access.
Network
interfaces
are
in
which
clients
underline
interfaces
connect
to
a
secured
access
network,
such
as
an
enterprise
or
operator
network
that
have
layer,
two
or
layer.
D
But
the
point
is
that
clients
may
have
diverse
underlying
interface
types,
which
connect
to
multiple
distinct
inner
networks,
as
opposed
to
all
via
the
same
internet
work.
For
example,
an
inter
net
interface
connect
to
a
public
internet,
an
internet
interface
connected
to
a
cellular
operator
network,
a
direct
interface
connected
to
a
dedicated
enterprise
network,
proxy
server,
etc.
They're
all
possible,
within
the
same
omni
interface,
to
have
multiple
different,
distinct
types
of
underlying
interface
connections.
D
So
then,
what
it
looks
like
in
terms
of
the
stack
is,
if
you
see
the
the
stack
orientation
on
the
left
hand
side
you
have
the
network
layer,
which
is
where
original
ip
packets
come
from
are
presented
to
the
omni
interface
within
the
omni
interface.
We
have
many
different
encapsulation
sub-layer
possibilities
before
the
packets
are
then
mapped
to
the
outgoing
underlying
interfaces.
D
So
in
terms
of
arrow
and
omni,
addressing
some
of
the
earlier
talks,
we're
talking
about
variable
length,
addressing
we're
we're
looking
strictly
here
at
the
standard,
ipv6
and
ipv4
addressing
architectures,
not
assuming
any
kind
of
variable
length
addressing
so
we
would
say
that
each
client
would
have
an
ip
global
unit
cast
address,
prefix,
whether
it
would
be
ipv4
or
ipv6.
D
D
and
again
end
user
network
applications
use
mobile
network
prefix
addresses
as
the
source
and
destination
addresses
of
original
ip
packets
each
aero
omni
node
configures
a
ipv6
linked
local
address.
That's
for
use
in
ipv6,
neighbor
discovery,
messaging
clients,
configure
mobile
network
prefix
link
local
addresses
so,
for
example,
for
the
delegated
prefix,
2001,
dba,
1,
2
colon
colon
64.
The
mobile
network,
prefix
link
local
address
is
fe80
link
local,
followed
by
the
interface
identifier,
2001
db812.
D
Now,
meanwhile,
proxy
servers
and
bridges,
which
are
fixed
infrastructure
elements,
configure
administrative
link,
local
addresses
with
the
least
significant
32-bit
set
according
to
the
segment
routing
topology
node
number
in
your
subnet
range.
So,
for
example,
if
the
segment
ryan
technology
sub
subnet
was
2001
colon
1000,
then
the
administrative
link
local
addresses
when
that
within
that
subnet
are
assigned
as
fe80
colon,
colon
2001,
1001,
1002,
1003
and
so
forth.
Their
administratively
assigned
addresses
assigned
to
fixed
infrastructure
elements.
D
I
think
I'll
skip
this
part
talking
about
any
cast
addresses
because
it's
not
really
relevant
to
the
omni
discussion
and
the
also
the
aero
and
omni
routing
system.
What's
being
shown
here
is
the
spanning
tree.
I
referred
to
earlier
in
the
green
segments
that
span
the
connect
interconnected
internet
working
segments.
D
This
is
there's
a
secured
spanning
tree
in
which
the
spanning
tree
is
configured
over
ipsec,
wireguard,
etc
at
layer
2
and
the
unsecured
spanning
tree,
which
travels
with
the
same
hop.
But
there
are
no
secure
lt
security
provisions
provided
control
messages
cover
always
travel
over
the
secured
spanning
tree
data
messages
travel
over
the
unsecured
spanning
tree
so
that
any
kind
of
routing
that
gets
established
is
through
secured
neighbor
discovery
messages
that
are
carried
over
the
secured
spanning
tree.
D
The
oil
oil
source
has
an
omni
interface,
as
shown
in
the
stack
stack
diagram
here
and
it
it.
It
performs,
what's
known
as
oil
encapsulation,
which
inserts
an
ipv6
encapsulation
header
and
a
a
trailer
trailer
checksum
the
after
after
the
encapsulations,
are
included.
The
the
oil
then
fragments
the
packet,
if
necessary,
to
create
carrier
packets
that
are
guaranteed
small
enough
to
traverse
all
paths.
D
D
D
So
that's
what
we
know
without
any
advanced
information,
but
if
we
know
that
that
the
path
can
carry
or
larger,
then
we
can
fragment
to
a
larger
size,
for
example
1500
bytes.
D
So
again,
the
oil
source
and
final
destination
are
in
different
internet
work,
segments
the
other
source
produces
carrier,
packets
and
the
oil
destination,
reassembles
them,
and
the
oil
intermediate
nodes,
which
are
also
known
as
bridges
join
the
network
segments
in
a
spanning
tree,
and
we
have
support
for
global
mobility
and
route,
optimization
with
dynamic
mtu
tuning
and
again.
This
is
a
lossless
path,
mtu
discovery
with
a
mt
and
a
short
mtu
of
9180
bytes.
D
Now
we
use
on
the
omni
interface,
ipv6,
neighbor
discovery
messaging
for
neighbor
coordination
and
for
establishing
layer,
2
routing
information
across
the
the
the
concatenated
internet
works,
the
ipv6
neighborhood
discovery
messages
include
an
omni
option
and
the
purpose
of
the
omni
option
is
to
assert
protocol
conformance
to
synchronize
windows
between
omnipeers
and
to
exchange
configuration
information.
D
So
on
the
right
you
see
what
this
omni
option
looks
like
this
is
a
new
ipv6
neighbor
discovery
option
type.
The
type
field
has
the
new,
the
new
type
that
we'll
be
getting
from
iana.
The
length
is
obviously
from
tlv
format,
and
then
we
have
information,
including
the
sequence,
number
acknowledgement,
number
and
window
size
for
synchronizing
identification,
sequence,
numbers
between
the
omni
source
and
the
ol
destination.
D
We
have
dhcp
hip
on
pim,
sparse
mode
messages
that
combine
the
functions
with
the
ipv6
neighbor
discovery
as
a
wrapper,
and
then
we
have
reassembly
limit
fragmentation
report,
icmp
error,
etc
to
provide
omni
destination
feedback
to
the
source.
So
these
are
the
sub
options
that
can
occur
within
the
omni
option.
D
D
D
So
now,
in
terms
of
the
mtu
hardin
software,
as
I
was
referring
to
rfcs
1191
and
821-
provide
icmp
packet
to
big
error
messages
that
always
report
packet
loss
due
to
a
size
restriction
or
a
hard
error.
Whenever
one
of
these
packet,
too,
big
messages
comes
back,
it's
always
because
a
packet
was
dropped
because
of
a
size
restriction,
but
what
omni
is
asking
for
is
a
new
packet
big
code
to
indicate
a
soft
error.
D
It
could
be
that
some
flows
will
have
a
better
packet
size
of
say,
4k
bytes,
other
flows
might
prefer
a
packet
size
of
1500
bytes
still,
others
might
prefer
a
packet
size
of
9180
bytes
and
they
can
all
be
dynamically
tuned
through
soft
errors.
Instead
of
p
packet
to
big
hard
errors
when
the
source
and
target
clients
underline
interfaces
connect
to
be
in
an
open,
an
internet
where
there's
a
very
good
chance,
they
may
be
located
behind
one
or
more
network
address
translators.
D
Each
client
naturally
establishes
nap
mappings
when
it
performs
an
rsri
exchange
with
its
first
stop
proxy
server,
but
these
mappings
are
generally
not
viable
for
client
exchanges
with
other
error.
Omni
nodes
besides
that,
first
time
proxy
server,
so
that
when
an
error,
omni
route,
optimization
is
applied
route.
Optimization
peers
must
perform
neighbor
solicitation,
neighbor
advertisement
messages
and
bubble
exchanges
to
establish
nap
mappings
for
itself
in
the
gnats
on
the
path
to
the
target
client
and
these
nat
traversal
procedures
are
conducted
in
the
same
manner
as
for
rcs,
4380
and
6081..
D
So
then,
for
signaling
other
things
that
are
going
on
in
the
omni
link,
ipv6
neighbor
discovery
message,
unsolicited
neighbor
advertisement,
messages
are
used
hub,
proxy
servers,
announce
client
state
changes
such
as
mobility,
related
address
changes,
link,
quality
changes,
traffic,
selector
changes
and
other
other
factors.
By
sending
unsolicited
amber
advertisement
messages
to
all
nodes
that
has
recently
sent
a
neighbor
advertisement
for
address
resolution
message
to
so
when
the
nodes
that
receive
these
unsolicited
neighbor
advertisements,
they
can
update
their
state
information
for
the
client,
which
may
require
new
nsna
nod
pass
state
exchanges.
D
When
the
source
node
receives
these
unas,
it
retransmits
to
the
requested
fragments,
if
it
still
has
them
in
its
re-transmission
cache
and
the
re-transmission
window
should
be
brief,
and
that
determines
the
link
persistence.
It's
not
true.
End-To-End
reliability,
it's
it's!
It's
opportunistic
and
best
effort,
link,
persistence
and
link
retransmissions.
D
A
Thanksgiving
indeed,
we
are
at
the
end
of
the
hour,
but
we
might
drag
for
a
couple
of
minutes
if
people
have
any
questions
right
now.
Otherwise,
please
bring
it
to
the
list,
but
we
can
take
a
couple
of
questions
if
people
want
to.
A
A
Okay
seems
like
it's
getting
like
for
people
right
now,
but
thanks
a
lot,
detailed
presentation-
and
indeed
I
think,
if
you,
if
you're
looking
to
to
get
and
ask
for
adoption,
we
should
get
a
little
more
support
from
the
group.
So
please
bring
the
the
discussion
to
the
list
so
that
we
can
judge.
If
this
is
something
that
the
group
would
like
to
adopt.
C
A
All
right
so
thanks
everyone,
the
presenters,
was
in
eric
for
attending.
Thank
you.
Hopefully,
you
had
a
fruitful
and
interesting
meeting
and
we
look
forward
to
seeing
you
virtually
physically
at
the
next
meeting.