►
From YouTube: IETF100-MANET-20171116-1810
Description
MANET meeting session at IETF100
2017/11/16 1810
https://datatracker.ietf.org/meeting/100/proceedings/
A
B
C
C
C
C
C
C
C
C
I'll
start
first,
as
chair
I
think
moving
D
left
to
a
different
area.
If
we
can
get
more
interaction,
would
be
fantastic,
a
different
working
group,
maybe
even
a
standalone
working
group
or
in
another
working
group
that
it's
appropriate
to
move
it
to
I.
Think
that
the
energy
from
D
lap,
if
it
were
moved
out
of
the
working
group,
would
make
this
working
group
kind
of
go
into
hiatus
and
I.
Think
what's
left
is
the
multicast
work
which
we
don't
have
the
energy
to
do
right
now
and
Willis
our
maintenance
stuff.
E
D
F
Point
number
one
is
that
Stan
Ratliff
is
also
is,
is
very
keen
in
seeing
the
deal
of
work
going
forwards.
He
can't
make
it
for
personal
reasons.
He's
gonna
hopefully
check
the
minutes,
so
that's
a
one
extra
person
in
the
room
who
isn't
visible
at
the
moment.
The
other
point
was
about
SMF
I
was
certain
nd
mbone
him
meeting
on
Monday
morning
and
they're
just
about
to
start
looking
at
things
that
SMF
souls.
So
there
is
a
place
for
that
SMF
work
if
Manny
was
to
boil
off
in
some
way.
F
So
there's
a
home
for
that,
and
the
third
thing
was
a
plus
one
to
lose
comment
about.
Industry
really
wants
deal
apt
to
happen.
So,
although
they're
not
here,
I
bet,
half
of
them
at
a
or
in
the
audio
stream
and
B
they're.
Just
constantly
coming
to
people
sat
in
this
room,
saying
how's
it
looking
when's,
this
extension
happening
when's
that
happening.
Is
it
done
yet?
Is
it
done
yet?
Is
it
done
yet
so.
F
D
D
So
it's
great
I
mean
the
elope
needs
to
happen,
and
now
that
we
have,
you
know,
probably
other
synergies,
because
you
know
there
were
probably
people
there
who
listened
and
said.
Oh,
that's,
probably
cool.
Maybe
they
didn't
come
here
for
a
reason,
but
you
know
I'm
hoping
that
we
would
maybe
get
to
ten
in
the
room.
Babel.
H
D
C
C
D
Yeah
they
look.
Nice
continue,
I,
agree
that
just
changing
the
name
and
saying
this
is
now
the
deal
of
working
group
Republican
end
up
in
the
same
place.
Well,
okay,
that
may
be
one
one
option.
The
other
option
is
to
put
it
somewhere
else
and
maybe
babble
yeah.
They
are
using
it
I,
don't
know.
They
said
today
that
they're
finishing
their
main
draft
I,
don't
know
that
would
work.
The
other
option
is,
of
course,
to
say
are
TWG.
I
H
One
thing
is:
is
that
we've
actually
had
when
we
met
we've
had
hugely
productive
meetings
because
we
have
were
so
focused.
So
one
thing
if
we
moved
it
into
C
camp
instead
of
having
an
hour
of
really
good
high
volume
exchange
and
making
progress,
we
would
get
like
10
or
15
minutes.
Make
a
report,
so
I'd
be
a
little
concerned
about
that.
So
that's.
F
H
C
I
would
like
to
suggest:
maybe
we
try
it
for
moving
it
to
C
camp
for
a
session,
have
a
joint
session
to
see
how
it
would
work
to
see
if
people
are
interested
to
see
if
that
work
would
be
something
that
they
would
want
to
take
on.
And
if
we
want
to,
as
a
working
group
would
want
to
move
it
there
and
not
make
it
a
permanent
thing
to
start
but
move
it
over
there
and
see
how
that
works
as
a
joint
session.
F
Going
back
to
the
the
point
of
my
presentation
in
the
open
meeting
was
that
dilip
has
applicability
outside
of
manet
and
my
reservation
for
keeping
it
under
the
MANET
umbrella
is
people
who
want
to
use
it
and
say
but
I'm,
not
a
man,
a
I
care
about
data
center,
where
I
I
think
it
has
use
names,
are
important.
I
know
it's
very
easy
to
forget
that
actually
they
are
important.
Ok,.
I
Concerned
about
the
mission
creep
with
the
event
it's
going
way
beyond
what
it
was
originally
intended
for,
so
I
would
like
to
see
it
used
in
the
context
of
money.
Primarily
I
was
also
hoping
for
the
multi
cost
work
to
in
money.
It
hasn't
happen
so
far.
Although
I
know
I've
heard
rumors
that
there's
something
going
on
at
several
places,
but
it's
not
being
brought.
I
C
That
that's
kind
of
Justin
Dean
chair.
We
have
progress
on
our
end.
We
have
software
working,
we
have
some
minor
things
written,
but
our
problem
is
getting
it
released
and
I
mean
I,
can't
it
it's
a
frustrating
position
to
be
in,
but
it's
I
can't
really
say
we
have
anything
because
we
can't
bring
anything
at
this
time.
So
with
that
in
mind,
if
somebody
else
can,
that
would
be
fine,
but
we
don't
have
the
cycles
right
now
or
not
the
cycles.
We
don't
have
the
ability
to
bring
forward
the
work
which
is
unfortunate.
I
D
Don't
want
to
stretch
this
too
long
if
we
have
no
other
work
right,
so
yeah
I'm
happy
to
do
one
more
cycle
and
meet
together
and
see
what
happens
there
and
maybe
between
here
and
there
we
make
some
progress
on
these
drafts,
you
know,
etc
after
the
next
meeting
or
right
before
you
know,
coming
around
there,
we
make
the
decision
of
what
we're
gonna
do
with
many
yes
itself
right
and
after
the
joy
meeting
we
can
make
a
decision.
Do
we
spin
it
off?
Now
we
have
enough
interest,
we
move
it
seek
a
meal.
H
We're
back
to
one
mic:
it
does
mean
that
we're
going
to
lose
this
sort
of
smaller
high
volume
exchanges
moving
to
another
working
group
and
that
that's
a
management
call
of
whether
or
not
we
as
an
organization
whether
the
isg
wants
to
have
a
small
group.
That
cares
about
one
particular
thing,
but
it's
really
nice
not
to
be
in
these
big
meetings.
H
Is
the
chair
the
glue
I
used
to
chair
the
group
I
mean
there
were
times
where
we
had
slots
that
were
seven
and
eight
minutes,
because
we
just
had
so
much
stuff
on
the
agenda?
And
you
know
it
was
brief
reports
on
here's
where
we
are
and
here's
what
we're
doing
and
we'll
talk
about
it
next
time-
and
you
know
okay.
D
D
C
C
F
Exactly
what
they
said
on
the
mic
was
really
caring
about
the
link,
their
properties,
specifically
looking
at
802
11
to
start
with,
but
I
had
the
real
feeling
they
were
about
to
start
reinventing
SMF
from
the
ground
up.
You
know
they
were
really
looking
at
the
RF
properties
of
the
links
and
I
was
just
sitting
thinking.
This
is
this:
is
the
SMF
work
and
there
and
there
was
real
energy
in
the
room
to
get
it
done,
and
that
worried
me
slightly.
I
G
D
H
I
H
I
C
So
I'd
like
to
kind
of
wrap
this
discussion
up,
so
we
can
get
to
the
presentation.
So
we
can
talk
about
technical
issues.
I
guess.
The
way
forward.
Right
now
is
we're.
Gonna
look
for
a
joint
session,
I'll
talk
with
our
arrow
and
Stan
and
come
up
with
some
suggestions.
If
you
guys
have
other
suggestions,
write
them
on
the
mailing
list
and
we'll
try
to
do
that
for
next
go-around
general
consensus,
I'm,
seeing
it
yeah
it's
a
management
thing,
but
I'd
like
to
have
feedback
as
well.
I
got
your
Lou's
feedback.
F
Rick
Taylor
again
I
think
something
has
to
change
I,
don't
know
what
but
I'm
in
favor
of
changing
something
because
I
take
Lou's
point
about
a
small
focus
group
is
Grace
I
can
under
private
design
team
meeting
but
and
yeah.
It's
really
productive.
But
it's
purely
focused
on
the
minutiae
of
dilip
at
the
moment
and
is
that
what
MANET
is
about
so
I,
don't
know
what
the
solution
is,
but
I'm
for
some
change
in
some
way.
E
H
Okay
with
doing
an
experiment,
I
don't
want
to
come
off
of
saying,
don't
do
anything!
My
question
is
is
do
we
do
two
experiments
because
it
sounds
like
the
routing
pieces,
there's
good
synergy
and
with
one
group,
while
the
D
lab,
maybe
a
different
group,
so
you
might
want
to
think
about
doing
two
experiment:
an
experiment
with
two
parts.
Yeah.
D
H
From
Henning
multicast
routing
is
hard
because
we
lack
good
OS
support
for
may
be
joining
the
PIM
joining
with
PIM
might
be
a
way
to
tackle
this,
so
I
think
this
is
going.
This
is
similar
to
the
same
comment
about
working
with
two
different
groups
and
Henning.
You
can
come
in
if
you
have
a
mic
you
can
just
draw
in
through
me
deco.
B
E
H
H
H
So
we
pushed
out
an
update.
There
were
a
bunch
of
comments.
We
then
did
a
quick
update
to
address.
Try
to
capture
all
the
comments.
I
feel
like
there
was
one
cop.
Oh
yes,
there
was
one
comment
that
hasn't
been
addressed,
but
it's
actually
actually
discussed
in
the
slides
so
we'll
cover
that
one
as
a
reminder
there's
actually
code
out
there
and
you
know-
we've
been
talking
about
open
source
so.
F
H
H
H
So
to
speak.
You
know
so.
I
still
think
it
doesn't
make
sense.
I
think
it
makes
sense
to
do
a
latency.
Sorry,
a
metric
range
on
a
per
data
item
basis,
rather
than
have
a
generic
field
which
then
had
another
field
inside
it.
That
said
that
the
data
the
metric
type,
we
just
have
the
data
item
type
say
what
type
of
metric
it
is.
So
this
same
range
approach
could
be
taken
for
any
metric
and
when,
when
doing
so,
we're
gonna
share
we're
gonna
share.
F
Okay,
Rick
Tyler.
You
have
convinced
me
to
go
in
this
direction,
but
I
think
your
logic
is
wrong.
If
there
was
a
sub
data
item
type
in
the
range
extension,
then
there'd
be
a
single
data
item
type
at
the
top
level
saying
this
is
a
metric
min
max
tre
data
item.
Sorry
and
the
the
sub
code
would
be
the
same
code
as
defined
by
the
metric.
So
and
I
can't
remember
the
numbers
off
my
top
of
my
head,
but
whatever
CDR
data
item
type
is
its,
so
you
there
wouldn't
be
an
explosion
in
number
space.
F
You'd
have
where
m
is
the
number
of
metric
data
items?
You'd
have
m
plus
1,
because
you're
adding
one
extra
data
item
type,
whereas
in
your
example
for
every
data
item
type
that
you
want
a
min
and
a
max
you
think
of
two
M
because
you're
having
to
add
a
second
data
item
type,
so
I
think
that
logics
flawed
but
I
can
see
where
you're
coming
from
I
think.
H
We're
somehow
talking
past
each
other,
but
violently
agreeing
so
I
think
we're
okay.
The
one
thing
about
what
you're
saying
is
is
that
you
would
have
to
consider.
How
do
you
indicate
the
support
and
you
would
end
up
still
with
an
additional
extension,
so
you
really
haven't
bought
much
so
I
I
think
we've
ended
up
in
the
same
place,
even
if
our
logic
is
identical
and
we
just
talking
past
each
other
or
for
completely
different
reasons,
we're
in
agreement.
That's
the
diet
or
high
order
bit.
H
H
G
You
mean
well
ooh,
okay,
it
was
just
me
misusing
the
program,
and
the
point
is
that
this
min
Max
is
some
kind
of
statistics
over
the
offer,
an
existing
metric
type
and
there
are
other
important
or
maybe
even
interesting,
forms
of
Statistics.
The
radio
could
supply.
So
we
have
this
type
explosion
we
have
at
the
moment.
If
we
do
min
maxing
for
all
metrics,
we
would
have
to
M
metrics.
G
If
we
say
yeah,
we
want
to
have
the
variance,
because
variance
is
something
important
we
want
to
know
if
this
value
is
stable
of
it's
fluctuating
back
and
Falls,
or
on
this
normal
average.
We
know,
then
we
have
assert
for
each
metric.
So
the
idea,
having
some
kind
of
generic
statistics
here,
B's
that
refer
back
to
an
existing
metric
type
and
say
yes,
I,
providing
minimum
maximum
boundary
for
this
metric
I'm,
providing
a
very
calculated
variance
or
moving
average
for
some
kind
of
metric.
G
H
We
do
have
to
the
16
values
available,
so
we
have
enough
space
and
if
we
are
defining
these
each
in
their
own
thing,
then
we're
going
to
need
an
extension
for
each.
So,
even
if
we
don't
have
we're
not
filling
up
our
data
item
space,
we
will
be
filling
up
our
extension
space,
which
I
think
is
also
to
the
16,
so
I'm
not
sure
we're
really
buying
anything
by
doing
the
this
second-level
index.
H
F
Tailor
the
the
reason
I
came
around
to
liking
this
as
a
single
data
item
type
was
actually
nothing
to
do
with
the
explosion
in
number
space.
It
was
to
do
with
the
fact
that,
as
you
start
to
dip
into
statistical
data
on
a
variation
of
metrics,
you
start
to
lead
away
from
the
delet
model
of
timely
information
about
the
change
of
metrics,
and
you
start
to
go
into
oh
well.
I
can
just
tell
you
for
the
lifetime
of
this
session.
It's
gonna
be
min
this
next.
F
That
standard
deviation
of
this
and
not
get
that
real-time
reporting
and
I
think
it
could
lead
to
a
precedent
of
that's
a
correct
way
to
implement
your
deal
app.
It's
become
aware,
it's
become
obvious
to
me
over
time
talking
to
implementers
that
guidance
on
how
to
do.
This
properly
is
very
important,
because
there's
there's
always
a
bit
of
wiggle
room
in
in
a
protocol,
and
we
have
to
be
careful
particularly
with
metric
reporting,
though
we
don't
allow
people
to
use
it
in
ways
we
didn't
want
them
to.
H
H
H
Because
there
are
a
few
points
that
I
think
are
really
important:
that
I
want
to
make
sure
to
get
to.
So
one
is
I'm
gonna.
Do
this
really
quickly?
How
many
think
we
should
stick
with
nanoseconds?
How
many
think
we
should
stick
with
microseconds?
This
isn't
voting.
This
is
just
to
get
a
feel
for
whether
people
have
opinions.
H
F
Only
objection
to
nanoseconds
Rick
Taylor
is
that
the
rule
latency
metric
is
in
microseconds
and
then
someone
will
say:
oh
I
can
use
this
because
I
want
a
nanosecond.
Latency
is
that,
okay
with
people,
because
I
can
bet
someone
will
say,
I
need
nanosecond,
so
I'll
set
the
min
and
Max
to
the
same
value.
So.
H
Presumably
Hennig
and
you
can
speak
up
if
you
disagree,
you
like
nanoseconds,
because
you
want
to
propose
it
who
sort
of
likes
again
just
getting
a
feel
who
likes
nanoseconds
nano
nano
so
heading.
Do
you
do
you
like
nano
or
do
you?
Are
you
just
thinking
about
it?
You
you
just
left,
you
could
have
just
started
talking.
G
Okay,
I'm
not
I,
suggest
that
nanoseconds,
because
we
have
a
huge
of
64
bits.
I
think
64,
bits
in
nanoseconds
is
still
a
three
digit
year
so
enough
for
even
interstellar
communication
and
I
see
radios
where
the
timing
already
slipped
into
the
sub
microsecond
area.
Where
we
say
yes,
we
see
LTE
and
the
success
of
80
in
this
day
are
talking
about.
Yet
they
want
to
guarantee
one
MA,
one
millisecond
range
and
it's
microsecond,
and
they
have
some
timings
that
are
already
sub
microsecond.
So
do
we
really
want
to
say
that
all
these
timings?
G
They
are
just
one
in
our
metric,
because
we
cannot
encode
them
and
we
don't
need
the
upper
16
bits
of
the
value
we
are
transmitting
anyways,
so
we
are
wasting.
We
can
afford
to
waste
a
few
bytes
in
D
lab.
That's,
not
a
problem,
but
we
don't
lose
much
by
by
defining
a
value
like
latency
in
nanoseconds.
We
still
have
all
the
range
we
need
and
we
will
not
be
in
a
trouble
when
60,
gigahertz
or
120
gigahertz
radio
coming.
G
F
H
So
we've
had
a
point
that
we
have
reserved
fields
because
they
look
nice
on
paper.
Who
cares
we
can
do?
We
are
over
TCP
that
we
really
need
them
and
I
think
that's
fine
to
strip
them
out,
I.
Think
I
already
did
it
actually
so
yeah?
Let's
kill
those,
and
there
was
also
a
correction
on
what
message
type
to
carry
it
in
I.
Think
I
already
made
that
change.
I
might
have
actually
published
this
with
the
with
that
removed
I.
Just
it's
been
a
long
week.
H
I
did
it
on
Monday
morning,
so
we'll
strip
that
so
control
playing
base
pause.
We
remember
what
this
this
was
all
about.
It's
it's
a
way
of
on
a
per
dscp
basis.
To
say:
hey,
stop,
don't
send
the
reason
we're
doing
this
versus
let's
say
something
like
Ethernet,
pause
or
PFC
is
that
you
can
pause
on
a
destination
basis.
H
H
We've
had
some
discussion
on
the
list.
One
thing
was:
do
we
need
both
pause
and
credit?
My
view
is,
these
are
different
use
cases.
We
have
some
simple
systems
and
some
complex
systems,
and
so
based
on
that
scenario,
we
would
have
a
radio
or
modem
that
would
support
one
or
the
other.
Don't
really
expect
a
system
never
do
both
can.
G
H
H
The
the
the
I
think
the
big
difference
is
sort
of
the
complexity
around
managing
a
credit
window
from
an
effective
from
the
bandwidth
on
the
wire
it'll
be
the
same.
The
big
difference
from
a
theoretical
standpoint
is
credit
should
be
work
conserving,
while
pause
is
not
so
pause.
You
basically
say
there
may
be
gaps
on
your
wire
on
your
media
with
pause,
but
it's
really
simple
to
implement
so
that
I
can
understand
why
you'd
want
to
do
credit
over
pause,
but
I
also
understand
the
complexity
of
pause
complexity
of
credit.
Well,.
C
And
I
would
I
would
comment.
Justin,
Dean
I
would
comment
that
having
two
separate
drafts.
If
somebody
were
to
implement
something-
and
they
wanted
something
simple,
they
would
not
do
the
credit
and
they
might
do
the
pause
extension
so
that
in
terms
of
getting
it
out
there
and
getting
people
who
want
to
say
hey,
can
you
can
you
do
this
for
me
and
they
they
say
yes,
I
can
I
support
this
RFC
I
support
this
feature
versus
I
support
credit,
but
only
with
one
window.
That's
a
little
you're,
not
gonna.
Ask
anyone
to
do
that.
G
Question
about
pause
and
credit:
can
we
have
a
text
that
describes
how
to
implement
pause
with
the
credit
tier
bees
saying
this
is
a
valid,
simple
approach
using
the
v's
they
to
define
something
like
Paul's,
because
this
whole
credit
window
is
too
complicated.
We
want
the
more
binary
stuff.
I
must
write.
H
Completely
rather,
there
is
a
crafter,
as
opposed
proposal,
try
to
unify
the
mechanisms
as
much
as
possible.
We've
done
that
we
haven't
I,
have
a
proposal
how
to
do
that
and
that's
what's
on
the
screen.
It's
not
quite
what
you
just
said,
because
it's
not
a
zero
credit
or
a
small
credit.
That's
still
requires
full
full
mechanism
implementation.
H
Rather
than
do
that,
we
can
use
some
commonality
of
a
common
traffic
classification
data
item,
which
is
the
same
thing
that
we
already
have
in
the
other
document,
where
we
have
a
classification
identifier,
we
have
the
diffserv
identifier
and
then
we
have
this
thing
called
a
flow
identifier
which
is
common,
which
is
which
really
helps
give
you
the
the
information
that
we're
doing
pause
instead
of
credit,
and
so
we
can
unify
it.
It
is
a
little
bit
more
complex,
it
does
increase
the
complexity
of
pause,
but
it
also
means
there's
commonality.
H
So
if
you
were
writing
a
common
stack,
it's
nice,
if
you're,
trying
to
understand
both
it's
nice,
if
you're
only
doing
pause,
you've
made
it
more
complex.
So
the
simple
case
is
a
little
more
complex
to
understand.
Reality
is
I.
Don't
know
so
I
I
personally
am
fine.
With
this.
It's
I,
it
works
pretty
nicely.
I
didn't,
go
and
change
the
draft
to
do
this.
I
thought
it
was
important
to
discuss
it,
but
you
know
it's
certainly
very
doable.
F
Rick
Taylor
again
I
was
really
hoping
you
were
going
to
do.
This
I
was
going
to
ask
you
if
you
had
thought
about
doing
this,
because
I
could
see
so
much
commonality
between
the
two
and
some
of
the
dis
list
discussions
with
Henning
about
well
s.
Can
we
start
talking
about
flow
IDs
in
terms
of
metrics,
and
so
it
all
starts
to
drop
out
of
this.
The
question
might
be,
and
this
is
one
for
the
chairs
is:
do
we
want
to
talk
about
flow
IDs
in
their
own
document
to
just
talk
about
flow
IDs?
C
H
Would
be
fine
having
a
base
document
and
other
ones
referring
to
sorry
a
common
document,
another
referring
or
one
that
says,
go
use
this
information
element
from
this
other
document,
so
either
approach
works.
For
me
you
just
have
to
decide,
but
let's
get
the
technical
details,
work
and
then
the
right
and
then
decide
how
to
break
it.
Apart.
G
One
comment
about
these
drafts,
which
might
also
support
from
pushing
the
flow
ID
stuff
out
of
the
draft.
The
problem
that
I
noticed
is
that
dscp
might
be
IPSec
protected,
so
it
ma
it
might
it
cannot
be
the
radio
that
says.
Oh,
you
have
to
use
these
DHCP
values
to
address
mic
use.
It
must
be
the
router
to
tell
the
radio.
H
Disagree
with
that
statement,
but
there
is
really
there's
a
related
comment
that
supports
the
same
conclusion,
which
is
what
happens
if
I
want
to
do
my
traffic
classification
using
some
other
fields
and
by
having
a
common
thing
that
you
can
refer
to,
we
will
reuse
the
same
components
the
the
way
the
credit
is
currently
designed,
and
that's
what
my
nice
animation
is
all
about,
got
to
go.
Look
at
that
slide.
H
11
I
like
that
animation,
but
it
is
basically
saying
that
our
credit
control
is
now
completely
separated
from
our
traffic
control
and
that
you
can
reuse
the
identical
traffic
control
mechanisms.
When
we
use
a
when
we
use
a
new
traffic
classification,
we
use
new
identifier
z'
of
the
the
traffic,
so
we
could
certainly
break
this
apart
actually
into
four
documents
if
they
want
so
at
some
point,
we're
gonna
have
to
decide
how
many
documents,
let's
get
the
details
right,
I,
think
credit
window
is
in
much
better
shape
than
it
was
the
last
time.
H
I
think
it
implements
everything
except
it
doesn't
have
this
new
name
yo,
but
the
items
in
blue
is
that
are
the
new
names
right
now
that
they're
called
see
IDs
and
I'll
just
change
them
to
flow
IDs
so
that
that's
that'll
be
a
change
that
I'll
do
afterwards
and
then
we
can
decide
whether
or
not
we're
ready
to
go
the
one
thing
there.
We
still
have
an
open
issue.
I
really
wanted
to
discuss
this.
We
don't
have
time
so
we'll
have
to
take
the
list.
So
please
look.
It's
slide.
H
F
Taylor
very
quick
response
to
Henning
Henning
your
comment
about
the
route
of
being
able
to
tell
the
modem
what
queues,
to
assign
I,
consider
that
management
and
configuration
and
out
of
the
scope
of
deal
app
I.
Think
the
the
radio
should
report
back
to
the
route
or
what
it
has
been
configured
to
do.
A
deed
up
is
never
a
management
protocol
and
we
need
to
push
back
against
suggestions
to
put
management
in
well.
H
F
Okay,
I'll
keep
it
quick
because
I'm
probably
short
on
time,
develop,
link
identifier
so
try
to
try
the
clicker
if
it
works.
Yes,
it
does
okay.
So
what's
the
problem,
the
problem
is
that
Dena
as
it
currently
stands,
requires
a
contiguous
layer
to
domain
okay.
So
your
MAC
address
is
used
as
your
identifier
for
your
develop
destination
and
it
has
to
be
a
valid
MAC
address,
which
is
good
in
general,
but
there
are
an
increasing
number
of
use
cases
where
this
is
a
problem
number
one
layer,
3
radios,
they
exist.
F
F
The
other
example
is
also
interesting,
which
is
where
you've
got
a
wireless
link
to
some
sort
of
infrastructure.
So
your
your
radio
link,
isn't.
Is
it
in
an
access
point
mode,
so
you're,
either
on
the
far
end
of
a
3G,
LTE
style
connection
where
there
isn't
another
end,
delet
router,
but
there's
definitely
a
link.
F
You
want
some
information
about,
or
agit
or
11
access
point,
so
the
solution
to
this
I
propose
is
a
new
identifier
that
goes
alongside
the
MAC
address
data
right
and
those
who
read
the
earlier
draft
I
was
replacing
the
MAC
address
data
item.
I
was
convinced
that
was
a
silly
idea.
So
there
is
a
new
data
item
that
effectively
parameter
eise's,
that
mac
to
say
beyond
the
MAC
address.
In
this
message
there
are
one
or
more
links
that
have
different
capabilities,
so
those
are
just
good
link.
Ids
key
points
are,
they
are
opaque.
F
H
Your
original
proposal
had
variable
like
yeah
with
variable
length.
You
can
do
a
whole
lot
of
things.
Yeah
I
would
suggest
that
either
you
put
a
maximum
length
or
go
with
one
of
the
proposals.
Alternative
proposed
alternatives
on
the
list,
which
was
to
have
a
per
session
value.
It
was
basically
it's
based
on
the
implementation.
The
day.
H
F
H
F
H
There
are
many
examples
in
routing
where
we
use
the
routing
protocol
to
distribute
some
information
that
comes
from
that's
that's
learned
from
an
attach
station
or
has
learned
from
something
else,
and
it's
distributed
through
a
routing
protocol.
Some
to
some
degree
develop
is
a
simplified
routing
protocol.
So
careful.
F
F
G
F
If
you're
using
the
layer
to
deter
items,
you've
got
to
include
some
layer,
2
information,
otherwise
they're
entirely
useless.
So
you
must
have
an
IP
address
or
a
subnet,
it's
quite
conceivable
to
advertise.
Where
your
default
route
lives,
you
can
say:
I
only
have
one
destination
and
it's
the
internet,
so
I
have
the
MAC
address
of
the
last
hop
in
the
layer,
2
and
a
single
lead
which
could
be
value
0
and
an
attached
subnet
data
item
of
zeros
are
Sara,
are.