►
From YouTube: IETF103-BABEL-20181107-1540
Description
BABEL meeting session at IETF103
2018/11/07 1540
https://datatracker.ietf.org/meeting/103/proceedings/
A
A
Thank
you,
hey
Julius,
while
we're
getting
ready
to
get
started,
I
see
her
there.
Could
we
check
your
audio
real,
quick
to
see
if
we
can
get
that
working?
If
you
could
like
step
up
to
the
mic,
if
you're
listening.
A
Okay,
Julius
had
audio
issues
in
home.
D
D
D
A
A
So
who's
going
to
jabber
and
who's
going
to
take
minutes
and
I,
don't
mean
the
type
of
jabbering
you
two
are
doing
right
now.
Oh
there
we
go
okay.
Well,
we
know
that
that
are
you
willing
describe?
Okay,
it's
through
anyone,
who's
going
to
take
minutes
and
I
can
certainly
get
on
and
take
minute
and
I
see.
Gabrielle
and
Gabrielle
usually
helps
take
minutes.
If
we
can
talk
to
these
people.
F
F
F
Okay:
okay!
H
I
I
F
Can
move
forward
move
backwards?
Okay,
oh
it's!
Are
you
second
I
try
using
the
control?
Okay,
sorry
about
that?
No
well!
You've
probably
seen
this
before
you're
operating
under
the
ietf
IPR
rule.
So
you
see
you
contribute
if
you're
aware
of
IPR
and
so
forth,
you
need
to
disclose
that
and
it's
basically
need
to
go.
Look
at
these
PCPs
to
get
the
full
rules
need
us
to
say.
This
meeting
is
being
recorded
also.
F
F
Where
are
the
beginning
to
get
things
set
up
and
over
status
and
milestones
the
babble
information
model,
the
yang
model,
which
we
have
plumeria
a
model
changes
to
the
available
level,
DTLS
graph
recently
and
the
general
level
protocol
status
and
then
to
wrap
up
at
the
end?
Does
anybody
have
a
problem
with
this
agenda?
I
want
to
add
or
delete
things
or
change
things
around?
F
F
So
document
status
we
have
as
applicability
graft,
which
does
have
working
been
generous,
have
working
group
consensus
and
I
just
did
a
Shepards
review
of
it.
It's
a
very
short
craft
and
I
didn't
find
a
typo
that
was
introduced
by
the
update
from
zero.
That
show
three
international
four,
so
ice
posted
a
message.
I
think
as
soon
as
we
have
that
fixed
I
can
request
publication
for
that.
A
F
F
The
baby,
heal
us
and
Mabel
H
Mac
grafts
reference,
the
RFC
6120
six
bits
so
that
sort
of
a
package.
So
one
question
is
whether
people
think
that
these
two
graphs,
the
VPLS
M
available
H
Mac,
are
ready
for
a
working
group.
Last
call
we
have
an
agenda
item
on
the
DTLS
one,
so
I
guess
we
could
talk
about
that.
Then
it's
people
have
opinions
on
whether
the
people
H
Mac
graft,
is
ready
for
working
group.
Last
call.
F
J
F
Gonna
be
presented,
so
we
can
talk
about
that
at
that
point
and
since
this
the
way
I
did
this
surgery
catch
is
anything
with
vehicle
in
it.
There
is
a
home
that
graft,
which
is
in
the
RFC
atatürk.
You
currently
mine,
miss
ref,
I,
believe
waiting
on
61
26
bits,
so
we're
sort
of
holding
up
a
document
in
another
working
group
pending
getting
our
main
Protocol
draft
through.
F
F
F
B
I
F
A
Sorry,
okay,
so
just
I've
sent
email
to
the
list
before
about
this,
but
I
have
moved
kind
of
my
working
editors
draft
over
onto
github
and
in
order
to
experiment
with
that
and
carsten
the
wonderful
person
that
he
is
helped
to
change
it
from
xml
to
md,
which
actually
is
much
easier
for
me
to
edit
and,
of
course
the
there
is
a
lovely
HTML
rendition
and
you
better
get
used
to
this
new
type
of
HTML
format,
because,
as
we
learned
in
working
group
chairs
we're
all
going
to
be
going
over
to
new
HTML
formats
and
things
anyway
and
over,
there
is
also
the
TR
181,
just
the
babble
stuff
William
in
case
you're
wondering
parts
of
what
I've
put
together
from
the
information
model.
A
A
A
The
Ayana
registry
for
link
types
I
have
an
issue
about
that,
one
just
because
I
need
people
to
look
at
it
to
see
if
they
like
it,
and
we
have
some
other
questions
on
that.
Ok,
so
the
open
issues,
please
review
the
Ayana
consideration
section,
because
I
did
create
a
link
type
registry,
as
we
discussed
in
the
last
Montreal
face-to-face
I,
did
receive
a
comment
from
Carsten
asking
me.
So
why
is
what?
Why
did
you
make
the
bullets
normative
and
not
the
a
B
and
F?
A
And
so,
if
anyone
else
has
thoughts
on
this,
please
feel
free
to
and
I'll
probably
take
these
issues
to
the
list
as
well
one
by
one
to
see
if
we
can
get
some
closure
on
them
now.
The
other
question
I
had
in
looking
at
the
lovely
work
Mahesh
did,
was
whether
we
need
to
go
ahead
and
add
more
link
types
now
for
things
like
mocha
and
G,
dot,
h
and
and
all
sorts
of
other
types.
A
G
A
J
A
E
A
F
E
G
K
I
G
Afraid
that
you're
trying
to
export
in
the
information
model,
something
that
the
implementation
does
not
need
to
know
about
the
details
between
the
different
kinds
of
power,
a
power
line,
Ethernet
and
so
on-
are
just
not
relevant
to
the
implementation.
So
I'm
a
little
bit
cautious
about
adding
so
many
different
link
types
unless
they
actually
appear
as
needed
from
an
implementation
point
of
view.
K
Mahesh
aeternum
Donny
striding
the
yang
model,
I,
don't
know
if
that
would
be
considered
implementation
or
not,
but
anyway
the
the
model
does
allow
for
extensibility
of
the
link
types
which
I
guess
would
be
good
news.
But
the
question
of
I
didn't
quite
understand
Julius
when
you
said
that
it's
not
the
definition
of
those
link
types
is
not
relevant
for
implementation.
K
G
G
Babel
does
not
need
to
know
whether
what
exact
kind
of
interface
it
is.
It
needs
to
know
whether
it's
a
tunnel,
whether
it's
a
wireless
interface
or
a
wired
interface.
So
are
we
here
trying
to
put
more
information
in
the
information
model
or
in
the
yang
model,
then
Babel
actually
needs
to
have
in
order
to
the
proper
routing,
okay,
I'd,
be
in
favor
of
having
the
information
model
reflected
Babel
already
knows
and
needs
to
know
so.
E
Exactly
David's
Ganassi
Google,
so
not
a
very
strong
opinion.
I,
don't
feel
strongly
either
way,
but
having
that
information
available,
two
things
that
query
it,
even
though
it
doesn't
impact
the
bottom
protocol,
isn't
absurd
to
me
so
having
it
in
there
as
an
optional
thing,
doesn't
hurt
my
mind,
but
I
really
don't
feel
strongly
about
this.
K
Mahesh
again,
so,
if
there
is
no,
if
the
link
type
is
not
actually
used
by
Bible
itself,
the
question,
in
my
mind,
is
in
the
information
model.
We
have
this
parameter
that
says
on
this
interface.
This
is
the
link
type
that
is
defined.
So
are
we
suggesting
that
that's
optional
to
set
and
that
it's
okay,
if
it's
not
set,
is
that
B?
No.
A
L
In
one
forum,
sorry
I
haven't
read
the
draft,
but
actually,
following
on
from
what
you
just
said,
Barbara
I
mean
when,
when
Julius
explained,
what
the
link
types
used
for
it
made
me
think
that
what
really
is
maybe
needed
in
the
model
is
not
really
a
link
type.
But
some
sort
of
enumeration
indicates
the
you
know
the
input
to
the
algorithm
that
doesn't
necessarily
have
to
be
directly
associated
with
the
link
type
well.
L
To
the
point
about
actually
needing
to
know
what
the
specific
link
type
is,
surely
that
information
is
available
somewhere
in
the
model
on
the
device
I
mean
it
seems
to
me
the
actual
physical
link
type
is
a
sort
of
a
layer,
two
concept
that
probably,
if
it
was
put
explicitly
into
the
the
babble
information
model,
would
actually
be
duplicate.
Information
I
mean
like
you've,
you've
got
an
empty
you've
got
an
interface
stack
you.
Surely
the
interface
stack
one
if
you've
got
to
give
an
interface.
A
G
Think
this
one
Barbara.
So
actually
what
is
underlying
the
algorithm
or
a
number
of
parameters
like
whether
you're
doing
link
quality
estimation,
whether
you're
doing
RTD,
sensitive
routing
and
so
on.
But
what
we
have
found
is
that
those
are
not
understandable
by
the
users.
So
we
are
actually
encapsulating
a
set
of
Alderon
parameters
into
the
link
type,
because
that's
something
that
the
users
understand.
A
So
let
me
summarize,
we
do
use
the
link
type
and
therefore
it's
good
to
be
able
to
report
the
link
type,
but
the
link
type
is
not
necessarily
the
same
as
the
physical
link
type
which,
since
we
have
a
reference
to
the
interface,
we
know
the
physical
nature
based
on
the
information,
the
the
interface
modeling
that
exists
elsewhere.
A
So
that's
already
known
in
what
we
really
just
need
is
what
Babel
considers
to
be
this
gross
high
level
link
type
that
it
associates
with
this
particular
interface
and
so
kind
of
what
we
have
right
now
with
the
four
enumerated.
Values
is
good
and
we
should
leave
it
there
until
we
discover
we
find
something
else.
We
need.
A
A
Okay
and
I'm
gonna
take
the
a
B
and
F
question
to
the
list,
because
that
kind
of
came
from
Carsten
who's,
not
here
int
yeah.
So
what
the
current
information
model
thing
is
too
fuzzy.
I've
noticed
that
everything
we
have,
that
is
an
int,
is
actually
a
16-bit
unsigned,
integer
and
so
I'm
going
to
suggest
that
we
change
into
an
unsigned
integer
datatype
and
the
question
I
have
is:
should
we
all
so
while
we're
at
it,
restrict
it
to
16
bits,
or
does
that
even
matter
at
the
information
like
model
level?
Because
if
we
well?
K
So,
from
my
perspective,
I
think
it's
helpful
to
be
as
precise
as
possible.
In
this
case,
I
would
like
to
be
specified
that
it's
you
and
16
that
we
are
trying
to
specify
all
for
all
those
parameters.
Then
the
data
model
has
no
confusion
in
terms
of
the
size
as
far
as
I'm
mentioning
the
max
I.
Think.
A
A
M
A
A
A
K
G
K
K
F
Think
the
H
max
definition,
don't
look
at
me
that
way:
RFC
2014
or
whatever
it
is
21:04.
It's
clear
enough
on
that.
But
the
thing
is
that
H
Mac
is
based
on
a
Mac
algorithm,
so
you
need
a
key.
He
which
is
a
byte
string
and
you
need
AMAC
out
with
a
to
specify
what
you're
doing
so
today,
it's
Julie,
that's
what
Julie
was
asking
if
we
need
a
registry
of
yeah
each
max,
which
really
boils
down
to
a
registry
of
Mac
of
a
hash.
E
There
is
Canal
Z,
Google
I,
don't
think
there
is
such
a
registry.
Each
protocol
that
uses
H
Mac
as
far
as
I
know
defines
its
own
registry
or
each
protocol
that
uses
hash
functions.
For
example,
TLS
has
a
registry
of
hash
functions.
Ike
v2
has
register
functions,
I,
don't
think.
There's
they're
arbitrary
one.
So
in
this
case,
in
order
to
configure
this
yeah,
you
will
need
the
pair
of
hash
function,
comma,
key
and
so
I
think
I
agree
with
Julius.
A
E
E
F
A
F
E
A
E
E
E
B
K
A
A
A
K
E
A
Okay,
I'm,
gonna,
try
and
put
that
in
logs
is
the
last
thing
in
Mahesh
and
I
actually
had
a
discussion
about
logs,
since
we
kind
of
do
logs
differently
in
yang
versus
TR
181,
and
we're
going
to
try
to
work
it
out
amongst
ourselves,
but
basically
I
really
dislike
the
way.
We
currently
have
the
logs,
modeled
and
I'm
going
to
change
it,
because
what
we
have
is
this
weird
thing
where
it's
actually
in
the
information
model
in
any
way.
A
Right,
okay,
so
my
next
step,
I'm
gonna,
update
revision
and
some
of
these
I
need
to
send
out
to
the
list
like
the
a
B
and
F
question,
we're
gonna
be
updating
the
data
models
and
then
the
next
question
is:
when
will
we
start
wgl,
C
and
I'm
thinking?
Maybe
in
the
new
year?
Maybe
if
we
could
do
it,
maybe
February
ish,
well,
I.
G
A
A
K
K
Well.
The
motivation
mainly
idea
warrants
the
yang
model
for
pretty
much
any
protocol,
that's
defined,
so
this
particular
version
after
model
was
based
on
0
2
0
3
was
published
after
this
traffic
had
already
been
posted,
so
maybe
one
of
the
first
things
I'll
be
doing
is
bringing
it
up
to
date
to
the
0
3
worries.
K
It
is
a
yang
1.1
model
which
may
not
mean
much,
but
I
just
mentioned
it,
and
the
next
statement
is
also
not
going
to
make
too
much
sense,
but
it's
nmda
compatible,
which
essentially
means
that
it
should
work
with
all
the
modern
NMDA
based
management
systems.
If
you
have
any
questions
about,
it
feel
free
to
ping
me.
K
So
the
tree
diagram,
which
is
how
yang
hierarchy
is
generally
represented-
this
is
subject
to
change,
as
I
said,
I
think,
Barbara
and
I
have
a
few
things.
We
need
to
sort
out
so,
but
what
you
basically
are
seeing
is
a
structure,
that's
very,
very
similar
to
the
information
model,
so
they
are,
of
course,
in
the
base
container.
K
The
first
thing
is
interfaces,
so
the
interfaces
under
the
model
are
interface
type
defined
in
RFC
83
43,
which
is
the
base,
which
is
an
interface
yang
model,
and
there
are
different
interface
types
that
it
that
that
model
supports.
So
if
there
is
an
interface
type,
that
is
not
that
babel
needs
to
support.
We
may
need
to
add
that
in
the
list
of
interface
types,
but
I
I
would
imagine
that
almost
every
type
of
interface
is
already
there.
So
the
question
is:
does
the
interface
type
need
to
be
restricted
to
a
certain
set
of
interfaces?
E
David's
Ganassi
Jewess
can
correct
me
if
I'm
wrong,
but
I
think
his
one
of
his
goals
were
Babel
and
are
girls
in
the
working
group.
Continuing
in
that
work
is
to
make
it
applicable
anywhere,
it
might
work.
As
Julius
said,
it's
a
routing
protocol,
it
routes,
so
I,
don't
think
we
need
any
kind
of
restriction.
I
think
just
using
the
standard,
if,
like
the
yang
model,
has
definitions
for
all
the
interface
types
in
existence.
Let's
just
use
that
okay.
L
L
K
L
That
shouldn't
even
many
layer
restriction
in
terms
of
what
type
of
interface
you
might
register
just
just
confirming
because
I
mean
I
think
from
the
point
of
view
of
yanking
backwards
compatibility,
it's
best
to
start
as
narrow
as
possible
and
then
in
augmentation
in
future
versions
you
can
expand.
This
is
the
when,
if
you
put
a
when
right,
if
you
put
a
win
on
there,
then
from
the
point,
the
yang
rules,
you
can
always
support
additional
interface
types
later.
L
K
L
K
L
L
E
It's
pretty
much
what
it
is
right
now,
just
to
clarify
what
you
mean
by
layer.
Babel
does
have
a
requirement
today
in
that
it
routes
IP.
So
what
I
meant
is
all
IP
interfaces
in
existence.
Well,
sorry,
I
am
very
not
knowledgeable
in
this
world,
so
maybe
we
restrict
it
to
IP
interfaces.
E
Maybe
so
well
that
then
I
guess
let's
stick
to
get
a
quick
step
back
into
what
we're
trying
to
get
out
of
this,
because
if
I
have
a
babel,
router
and
I
want
to
manage
it
remotely
and
get
some
information.
I
do
want
to
know,
let's
say,
for
example,
that
on
this
side,
its
Ethernet
and
on
that
side,
its
Wi-Fi
at
the
end
of
the
day,
those
both
of
those
carry
IP
and
what
conceptually
from
the
label,
yes
their
IP
interfaces.
E
A
So
both
the
a
and
T
are
181
have
layered
interfaces
for
every
interface.
You
happen
to
know
like
if
it's
an
IP
interface,
you
know
what
802
3
interfaces.
If
it's
you
know,
on
top
of
an
Ethernet
MAC,
is
below
that
and
then
below
that
it
would
be
maybe
your
physical
interface.
If
it's
tunneled,
you
may
have
additional.
A
K
Weak
and
I'm
currently
mind
saying
is
you
cannot
there's
nothing
defined
as
IP
interface,
only
I
mean
their
interface
types,
which
is
where
it's
a
tunnel
type
or
itself
I.
Don't
know.
If
I
remember
of
the
interface
types
that
are
indiana
registry,
I
think
there's
even
an
iron.
There
is
305
types,
I,
don't
think.
So.
That
is
something
which
says
it's
I
be
type.
L
Well,
William
looked
but
I
mean
if
there's
a
missing
interface
type,
then
one
can
ask
if
there
really
is
a
missing
interface
type,
one
can
ask
for
it
to
be
added,
but
but
I've
I
mean
the
way
that
the
interface
that
the
eye
you
know
the
eighty
3:43
stuff
works,
I
always
have
to
go
back
and
check.
I
mean
it
is
an
identity
hierarchy.
So
there
may
be
ways
of
doing
this
that
don't
actually
require
the
reference
specifically
to
an
eye
on.
L
Oh
I,
have
type
I
think
there
may
be
a
way
of
doing
this
using
more
of
a
you
know,
an
appropriate
point
in
the
identity
hierarchy,
but
that
would
require
list
on
my
part.
Research
to
you
know,
I
can't
give
an
answer.
I'm
just
but
I
do
think
that
if
one's
worried
about
future
extensibility,
it's
good
to
start
narrow
in
the
sense
of
what
I
mean
it's
really
constraining.
Interface
starts
because
pervy,
whatever
it
is
section
11
rules
in
7950.
L
L
J
K
So,
unless
someone
wants
to
bring
up
any
more
clarifications,
I
did
have
a
private
conversation
that
Barbara
on
this
and
I
think
I'm
kind
of
clear
on
how
the
link
type
is
going
to
be
used.
I
think
the
same
is
true
for
the
metric
computation
algorithm
and
the
security
supported.
The
last,
of
course,
is
going
to
change
substantially.
F
K
F
K
K
K
Right
so
yeah
to
try
to
answer
that
so
Chris
I'm
not
going
to
try
ask
you
know.
The
question
is
because
the
information
model
has
block
four
routes
today
and
I.
Don't
think
so,
there's
anything
for
it.
But
if
we
choose
not
to
then
we
are
kind
of
fragmenting
the
routing
table
in
some
sense,
between
Babel
and
all
the
other
protocols
that
might
be
running
so
I'm
guessing
the
answer
is
yes.
We
need
to
augment
the
base
routing
protocol
model.
A
K
G
G
E
David
scatter
Z
I,
so
there
was
talk
of
delaying
the
babel
work
because
of
the
yang
ball,
which
which
slightly
changed
the
Charter
for
that.
So,
if
we
will
this
ends
up
in
miss
ref
state
I
feel
very
strongly
that
it
should
not
delay
6126
bits
if
this
document
is
administra
for
a
little
bit
longer
that
that's
okay,
but
I
really
want
to
get
6126
bits
out
the
door.
So
for
that
chairs
an
ad
as
long
as
6126
bits
isn't
blocked
on
this,
that's
okay,
but
if
it
is
blocked,
then
I
would.
F
G
K
Okay,
actually
I
should
have
gone
to
the
backup
slides
for
each
one
of
these
questions
right.
Okay,
so
the
last
one
is:
does
babble
need
to
support
ordering
policy
and
for
that
I'll?
Sorry,
oh
I,
guess
I
don't
have
the
latest
lights
here,
but
in
here
so
it
provides
a
generic
policy
framework.
And
if
we
need
that
capability,
then
I
would
need
a
plan.
I.
F
F
H
K
F
E
So
David's
conocí
yeah,
so
especially
skewing
that
this
isn't
Charter.
This
is
useful
and
so
I
wanted
to
state
like.
Thank
you
so
much
for
doing
this,
because
I
do
not
understand
yang
and
I'm,
really
glad
that
we're
doing
it
like
I'm
not
doing
yet.
So.
Thank
you.
So
much
and
I
fully
support
adoption
of
us
and
us
moving
forward
with
it.
Yeah
does.
F
E
E
The
idea
is,
you
use
multicast
hellos
to
discover
neighbors
once
you've
discovered
a
neighbor,
you
establish
the
GTRs
connection,
then
you
run
everything
else
inside
be
TLS
and
it's
safe
yay.
So
the
idea
is,
we
have
so
two
security
systems
for
Babel
one
is
H
Magnum
GT
LS.
This
one
is
has
more
dependencies,
especially.
You
need
a
DTLS
library
which
isn't
always
easy
on
very
constrained
devices,
but
it
also
has
more
features
the
two
main
fee
that
the
main
feature
is
granularity
of
trust.
You
have
different
keys,
meaning
you
can
have
like
a
symmetric
keys.
E
So,
for
example,
in
our
home
net-like
scenario,
you
can
have
a
circ
with
a
private
key
on
each
router
and
then
you
can
revoke
a
given
router
from
your
system,
but
you
can't
do
it
H
Mac.
So
in
those
kind
of
deployments
we
recommend
DTLS,
but
for
everything
simple,
we
recommend
HVAC,
and
that
was
the
motivation.
Great
another
benefit.
You
get
is
that
the
traffic
is
encrypted,
so
someone
who
doesn't
have
the
keys
can't
see
the
topology
of
your
network,
so
we
just
published
Daschle
one
before
the
deadline.
E
Now
there
was
an
open
question
which
we
solved
is
that
DT,
the
DTS
uses
a
separate
port
that
we're
gonna
ask
from
I
Anna
as
the
destination
port,
and
then
the
connections
are
initiated
from
an
ephemeral,
client
port
like
any
other
use
of
the
DTS
protocol.
Another
slight
change
is
now
I
heard.
Yous
need
to
be
inside
DTS
they're
not
allowed
outside
in
the
clear,
and
that
really
simplifies
the
security
boundary
of
the
protocol.
E
The
only
thing
you
can
see
outside
is
hellos,
so
you
cannot
establish
bi-directional
reach
ability
with
someone
who
doesn't
have
keys
thought
simpler.
One
slight
change
that
Julius
pointed
out
is
that
if
you're
using
the
RTT
extension,
then
you
need
to
send
unicast
hellos
inside
the
DTLS
as
well.
So
that
way
you
can
do
the
rtt
and
we
did
some
edit
or
changes
to
clarify
the
motivation.
Thanks
to
20
peas
with
you
and
that's
it.
We
think
the
document
is
in
good
shape
and
we'd
like
to
motion
for
a
working
group.
Last
call.
J
G
So
first
I'd
like
to
say
that
I
support
the
change
of
requiring
I
accuse
to
be
protected,
and
the
argument
that
convinced
me
is
the
fact
that
it
means
that
it
makes
it
easy
to
convince
yourselves
that
the
protocol
IPSec
is
secure.
If
I
each
use
need
to
be
protected,
then
you
never
create
a
symmetric
association
with
somebody
who
doesn't
have
the
key
okay.
So
that
makes
it
easy
to
convince
yourself
that
the
protocol
is
secure.
G
The
other
point,
I
think,
is
important
to
mention
the
other
reason
you
want
have
DTLS
in
addition
to
H
Mac.
In
addition
to
your
two
points,
is
in
case
you
run
into
trouble
because
people
are
telling
you
you
don't
want
to
do
your
own
crypto.
Okay.
There
is
this
point
of
view
that
one
should
not
be
doing
their
own
crypto
code.
I,
don't
necessarily
agree
about,
but
some
people
might
be
in
this
kind
of
environment
and
DTLS
sells
quite
nicely.
The
problem
of
delegating
the
crypto
to
DTLS
I.
F
E
G
F
A
G
G
There
are
quite
a
few
loosen
ends
because
over
the
years
we
have
understood
that
what
I
had
done
in
the
original
six
one
two
six
was
overly
restrictive
and
we
understand
now
that
there
are
things
that
we
can
do,
which
we
didn't
understand
them
and
we
have
deliberately
refrained
from
adding
new
features
unless
we
actually
use
them.
We've
just
add
improved
neighbor
discovery
and
link
sensing,
so
it
turns
out
that
the
algorithm
itself
works
pretty
well
and
usually,
when
people
run
in
trouble,
it's
because
of
neighbor
discovery
and
link
sensing.
G
So
we've
added
unicast
hello
that
was
David's
and
toki's
work,
we've
added
unscheduled
hellos
and
we
have
a
more
extensive
built
packet
format
and
it's
receptio
DS,
and
we
now
have
a
packet
trailer
and
that's
Newton,
oh
six,
and
it
would
be
really
good
if
people
review
it
next,
please
so
unicast
hellos
that
was
done
by
David,
so
I
don't
feel
very
comfortable
speaking
about
it.
But
in
six
one
two
six
LTL
fees
can
be
sent
either
over
unicast
or
multicast,
except
hello's,
which
must
be
sent
over
multicast
in
six
one.
G
If
you
need
to
carry
a
subtly
that
can
only
be
stuck
on
a
hello
in
a
unicast
packet
and
the
obvious
example
the
only
such
shield
sub
KL
v.
We
have
right
now
is
the
time
stamps
of
TLD,
which
David
mentioned
in
his
talk
and
other
than
for
the
hello
sub
TLD
unicast
hellos
are
not
required
by
the
DTLS
extension,
which
protects
everything
except
hellos.
Next,
please,
there
are
unscheduled
hellos.
So
in
six
one,
two:
six,
every
hello,
resets
the
link
quality
Tyner.
So
it's
difficult
to
send
a
Hello
at
an
arbitrary
time.
G
In
six
one,
two,
six
bits:
we
have
a
notion
of
an
unscheduled
hello
which
is
just
like
a
Hello,
but
it
doesn't
reset
any
timers.
So
that's
something
that
doesn't
cost
much.
It's
a
small
extension
to
the
protocol
and
it
simplifies
the
implementation
somewhat.
If
you
need
to
send
unscheduled,
tell
us
next,
please
the
big
change
in
six
one,
two
six
bits-
and
that
is
mostly
due
to
Gwendolyn
chuan,
who
harassed
me
for
weeks
until
I
agreed
to
add
it
to
the
protocol
and
she
was
right,
is
the
mandatory
subshell
V.
G
And
if
you
don't
understand
the
sub
TLD,
you
ignore
the
sub
TLD,
but
you
still
honor
the
rest
of
the
TLV
and
in
six
one
two
six
bits:
we
added
mandatory
subsidies,
so
a
mandatory
septa
LD
if
it
is
unknown
or
miss
Parsifal
or
any
reason
it
called
causes
the
whole
enclosing
TLV
to
be
ignored.
So
that
is
a
dramatic
simplification
to
protocol
extensions.
We've
seen
into
a
source
specific,
it's
shrunk
by
half
when
we
got
mandatory
safety.
All
these,
they
are
a
little
bit
more
complicated
to
implement.
G
G
One
two
sin:
zero
six
is
the
packet
trailer,
so
a
Babel
packet
has
three
parts:
there's
a
fixed
size
packet
header
of
four
bytes,
there's
the
packet
baldie,
which
is
a
sequence
of
TL
visa
and
after
the
body
there
is
a
trailer
which
I
defined
an
original
six
one.
Two,
six
and
I
said
it
silently
ignored.
We
don't
know
what
to
do.
G
Is
it,
but
it
natural
came
up
and
the
intent
of
that
was
to
have
carried
cryptographic
signatures
now
in
six
one,
two:
six
bits
in
there:
zero
six
with
extended
the
packet
format
to
have
to
define
the
packet
trailer,
which
is
now
a
sequence
of
gles.
You
can
reuse
the
same
parser
as
for
the
packet
building
and
it's
only
used
by
the
H
Mac
extension,
the
H
max
that
cover
the
packet
body
are
carried
in
the
trailer.
G
So
what
happens
here
is
that
you
avoid
the
dance
you
know
of
having
to
erase
the
H
Mac
before
you
compute
the
H
Mac,
because
the
H
Mac
does
not
cover
itself,
because
the
H
Mac
is
in
the
trailer.
So
there's
a
trade-off
here.
We
have
complicated
the
specification
and
what
we
got
in
exchange
was
that
the
implementation
is
much
simpler.
Toki
who
did
the
other
implementation
of
H
Mac
agrees
with
me.
It's
well
worth
the
trade-off.
G
Now
it
used
to
be
an
appendix
at
the
H
mag
draft
in
0-6,
I've
put
it
in
the
body,
and
the
only
review
I
had
were
from
Toki,
who
said
that
my
English
is
absolutely
horrible
and
that
I
have
to
rewrite
them,
but
he
agreed
with
the
contents.
So
please
review
this.
This
is
new
stuff
and
we'll
be
stuck
with
it
if
we
get
too
drunk,
please
okay,
so
just
a
quick
note
about
compatibility
with
six
one,
two:
six
unicast
Hellas
and
mandatory
sub
T.
G
All
these
are
incompatible
extensions,
so
understanding
them
is
some
20
lines
of
code
that
we
need
to
add
it
to
all
implementations
before
we
can
start
sending
them.
The
current
status
is
that
we've
done
the
work
and
double
D
invert
in
s,
barbel,
T
and
then
David's
top-secret
implementation
and
not
allowed
to
tell
you
about.
We
haven't
done
it
in
FRR,
and
there
is
one
that
I've
missed
here.
G
F
So
I
have
a
server
question
which
I
think
Martin
might
want
to
attention.
So
we
have
this
RFC
21
6126,
this
main
graft
and
I
haven't
looked
at
recently.
I
actually
probably
should
have.
We
have
these
two
security
drafts,
two
security
mechanisms
DTLS
and
H
Mac.
So
what
does
6126
this
currently
say
about
the
implementation
requirement
level
for
these
security
ones
is
the
should
neither
one
or
both
be
mandatory
to
implement
or
recommended
or
whatever
so.
G
Here
I
have
this
like
this
agreement
was
not
respectable
co-author,
so
I
believe
that
we
should
be
strongly
recommending
H,
Mac
and
keeping
DTLS
optional
and
I.
Don't
think
we
should
put
H
Mac
as
TI.
So
if
there
is
strong
pressure
to
make
H
Mak
MTI
I'm
not
going
to
object
because
I
think
it's
a
clean
and
simple
extension
that
it
is
reasonable
to
require,
but
I
would
not
prefer
it
to
be
simply
strongly
recommended
and
not
empty
I
hear.
E
It's
Ganassi
so
to
reply
to
our
respectable
co-authors
na
I.
Agree,
that's
perfectly
fine
by
me!
What's
empty
or
not,
I,
don't
really
have
a
strong
feeling.
So
here's
a
proposal
for
a
strategy
moving
forward.
We
have
normative
references
in
the
document
to
both
security
mechanisms,
saying
what
I
was
saying
earlier,
that
we
recommend
H
Mak
unless
you
need
the
other
features
that
H
Mac
doesn't
have,
and
we
try
to
move
this
forward
to
publish
it.