►
From YouTube: IETF99-BABEL-20170717-1740
Description
BABEL meeting session at IETF99
2017/07/17 1740
https://datatracker.ietf.org/meeting/99/proceedings/
B
This
is
the
area
director
she's,
not
here
right
now,
so
the
basic
information
these
slides
are
all
available
for
download
people
should
note
the
note,
well
IPR
requirements
like
to
request
people
to
review
documents
when
we
call
for
that,
so
that
will
get
higher
quality
documents
and
if
you
have
knocketh
you
have
that
you
want
to
get
through.
It's
always
helpful
to
review
other
people's
documents
and
then
probably
they'll
review
your
documents.
So
this
is
the
current
agenda.
B
B
D
B
Okay,
so
just
gonna
just
talk
about
the
status
a
little
bit
and
milestones
and
then
go
through
with
a.
We
have
a
final
presentation,
so
this
stuff
adds
up
to
about
an
hour,
so
we
can't
generally
go
over
on
one
thing:
we'll
have
to
go
under
it,
something
else.
Generally
speaking,
mandatory
sub
general
protocol
from
Julius
UNIX,
you
guys
fellows
information
model,
beer
and
Babel,
and
it's
or
specific
routing
anybody
want
to
change
something
or
an
island
or
add,
or
delete
or
reorder
or
anything.
B
B
B
It's
basically
a
couple
of
working
group
drafts.
The
table
applicability
graph
is
actually
expired.
It
came
up
for
expiration
during
the
refractory
period
when
you
couldn't
can't
post
before
the
IETF
meeting
and
there's
the
main
Protocol
draft
RFC
62
6126
biz,
so
the
applicability
draft
has
actually
been
in
we're.
Gonna
blast
call
for
a
while,
and
they
really
weren't
hardly
any
comments,
and
there
was
a
review
that
review
needs
to
be
responded
to
so
Cera's
have
decided
we'll
just
declare
that
to
have
not
passed.
B
This
working
group
last
call
needs
to
be
revised
and
reposted
and
we'll
do
a
working
group
last
call
on
it
in
the
future,
possibly
at
the
same
time
as
we
do
it
on
an
RFC
6120
six
bits
we'll
see
what
the
discussions
on
the
Main
Protocol
draft
revealed
at
this
meeting.
There
is
a
home
net,
Babel
profile
draft
and
there's
a
series
of
personal
graphs
at
the
bottom
here,
so
no
be
there
are
presentations.
Actually,
this
is
out
of
date.
The
yes,
the
the
Babel
Information
model
draft
is
a
working
group
graphed.
E
E
F
Basically,
the
protocol
remains
the
same
six
one.
Two
six
bits
is
the
same
protocol
at
six
one,
two
six
you
did
like
Babel
you'll,
probably
still
like
six
one,
two
six,
this
we've
made
for
substantial
changes
to
the
protocol.
A
lot
of
editorial
changes.
Documents
reads:
I
think
much
better
than
the
old
documents,
but
we've
made
for
substantial
changes.
Now,
let's
reset
the
theories
which
have
been
implemented,
which
I
feel
very
comfortable
with
which
are
a
incompatible
extension
and
that's
what
this
talk
is
about.
F
G
F
There
are
two
places
where
I've
significantly
relaxed
the
protocol
given
much
more
freedom
to
the
implementer
in
both
cases,
I've
been
careful
to
make
sure
that
if
you
obey
the
old
specification,
you're
still
compliant
that's
route
acquisition
and
that's
been
implemented
for
ages.
Actually,
the
reference
implementation
was
optionally
with
the
right
flag
violating
the
old
protocol.
So
now
I
want
to
make
this
behavior
the
default.
That's
perfectly
compatible
and
I
would
like
people
to
help
reviewing
that.
F
F
It
was
unimplemented
when
I
wrote
this
slide
and
since
then
I've
met
met
you
in
a
corridor
who
told
me
by
the
way
it's
implemented
now,
but
I
don't
know
if
it
compiles.
So
we
hope
we're
going
to
check
it
soon,
and
that
is
an
important
extension
for
reasons.
I
won't
have
time
to
get
into
please
review
and
implement
and
tell
me
if
it
makes
any
sense,
and
you
see
that
there
are
two
big
red
incompatible
here,
I'm
going
to
come
back
to
that
later.
F
Next,
please,
okay,
so
to
remind
you,
bable
bable
packet
contains
a
bunch
of
tea.
Ellie's
gles
have
a
type
a
length
and
a
body
and
six
one,
two
six
says:
if
you
see
some
extra
at
the
end
of
the
body,
please
ignore
it
just
make
pretend
that
didn't
exist
and
that
place
was
for
extensions
at
the
time.
I
didn't
know
what
extensions
would
look
like
and
then
75-67
I
designed
once
they
have
been
implemented.
What
extensions
look
like
safety
Ellie's
could
have
a
type
a
lens
and
a
body.
F
They
have
exactly
the
same
structure
as
the
LEDs
at
the
end
of
the
TLD
after
the
body,
and
if
there
is
a
sub
TLD,
you
don't
know
about
you,
just
pretend
it
wasn't
that
neck.
Please
now
sometimes,
if
extension
data
is
not
understood,
you
want
the
whole
TLV,
not
just
the
extension
data
to
be
ignored,
and
you
cannot
do
that
with
75
57
sub
gles
and
so
to
avoid
this
issue.
F
The
source
specific
extension,
which
I
think
is
the
most
important
extension
of
Babel,
which
is
due
to
Mathieu
booty,
who
is
sitting
over
there,
uses
three
new
TLDs
which
mirror
the
update
the
request
and
the
sectional
requests,
which
are
called
the
source
pacific
update
the
sources
that
it
required.
The
South
Pacific
SEC,
no
requests
so
that
the
whole
TLD
will
be
ignored
by
implementations
that
don't
understand
the
extensions
next,
please
not,
so
you
cannot
do
that
with
subdial
visa
and
what
I
suggest
that
I
think
it
was
Chicago
was
to
use
a
new
address
encoding.
F
Can
you
address
family
to
that
new
code
ease
and
Babel
R
and
a
new
ie
will
be
silently
ignored
by
existing
implementations
and
that
the
working
group
was
polite,
because
this
is
a
polite
working
group
and
they
received
the
idea.
I
would
say
somewhat
cautiously
and
so
to
prove
that
I
was
right.
I
have
met
you
and
Wendling
chuan,
who
is
not
here
today
to
show
that
I
was
right
by
implementing
source,
specific
routing
and
TOS
specific
route
in
respectively,
using
a
new
AE
and
the
problem.
F
F
So
what
Mattoon
Gwendoline
convinced
me
off?
How
that
I
was
kicking
and
screaming
was
that
we
need
a
mandatory
bit.
So
in
six
one,
two,
six,
this
innocent
TLC
has
a
heartbeat
with
the
most
significant
bit
sets.
That
is
a
tie
between
128
and
205
255.
It
is
mandatory
and
if
you
see
an
unknown
mandatory
TLD,
you
draw
a
sub
T
LV.
Sorry,
you
drop
the
hull
and
closing
eld
and
Curt
motton
Gondolin
has
shown
that
that
works,
beautifully
force
or
specific
routing
and
for
gos
specific
routine
and
both
extensions
are
implemented.
F
They
have
been
tested
and
they
have
been
written
down
in
internet
drafts.
Next,
please
now
there
is
one
technical
difficulty,
which
is
that
Babel
uses
attack
a
stateful
parser
when
you
versatility,
you
retain
some
data
and
later
on,
until
we
can
refer
to
this
data,
it's
a
very
it's
a
fairly
simple
procedure
that
allows
saving,
in
the
case
of
ipv6
networks,
a
good
eight
octaves
for
prefix,
and
so
that's
very
useful
and
unfortunately,
because
you
have
the
state
you
have
to
maintain
the
state,
so
we
don't
entirely
ignore
it.
F
Lv
that
has
been
suppressed
due
to
an
unknown
mandatory
subtlety.
You
still
update
your
parser
state.
In
other
terms,
parsing
does
not
depend
on
which
extensions
you
implement.
A
packet
always
gets
parsed
in
the
same
manner
and
if
you're
not
convinced,
that's
essential,
think
about
TCP
dump,
it's
not
defined
what
kinds
of
extension
TCP
dump
they
found
implements,
and
you
still
want
TCP
them
to
be
able
to
parse
a
Babel
packet,
please,
okay!
So
what
complexity
does
it
end?
Add
to
the
implementation.
F
These
is
s
Babel
D,
the
S
stands
for
stub
are
simple
or
stupid
or
whatever,
and
this
is
a
very
a
an
implementation
that
was
written
just
to
show
how
small
an
implementation
of
Babel
can
be,
and
this
implementation,
when
I
implemented
mandatory
bits
in
it,
grew
by
38
lines
of
C.
That's
basically
30
lines
of
the
TLV
parser
and
the
shoe
calls
to
it
and
the
binary
size
increased
by
fifty
six
bytes
that
Deitz
right
next,
please,
okay,
but
mandatory
bits
are
incompatible
with
RFC
six
one.
F
Two
six
old
implementations
will
not
ignore
tlvs
that
contain
unknown
mandatory
safety
LDS
and
in
principle
this
could
break
your
network
if
you're
not
ignoring
the
TLD
that
you
don't
understand.
The
same
is
true
of
unicast
hellos,
and
now
we
need
to
make
a
choice.
One
possibility
is
to
say
well,
if
nixing,
six,
one
two
six
routers
with
the
new
extensions
breaks
the
network.
Just
don't
do
that.
F
Okay,
so
before
you
insert
the
tos
specific
route
or
a
source
specific
route
or
into
your
network,
make
sure
that
all
of
your
routers
have
been
upgraded
to
the
new
version
of
the
specification.
The
other
possibility
is
to
bump
the
protocol
version
on
packets
that
contain
method
to
bump
the
protocol
version.
F
The
protocol
version
is
currently
we
could
bump
it
to
three,
and
that-
and
the
problem
is
that,
for
many
of
our
users,
a
flag
day
is
just
not
possible,
so
this
could
be
done
without
imposing
a
flag
day
by
simply
saying
continue
sending
packets
of
version
two.
But
if
you
send
a
packet
that
contains
any
mandatory
bits,
then
this
particular
packet
must
be
version
three.
In
other
words,
you
will
still
be
sending
packets
of
version
two
in
just
an
occasional
your
deployed,
the
new
extension
sending
packets
with
version
three.
I
F
H
At
certain
point,
I'm
ruined
the
guys
who
don't
understand
the
news
version
number.
If
you
stick
a
new
TLV,
they
will
just
ignore
the
TLV
and
the
new
guys
will
understand.
Oh
the
capability
means
if
this
guy
doesn't
advertise
it
with
this
capability.
I
have
to
avoid
him
because
he
does
not
speak
the
version.
If
there
is
a
subtle
difference,
then
yeah
there
is
a
difference.
F
So
then
there
there
is
the
wording
that
I'm
proposing.
If
we
decide
to
do
that,
perhaps
I
will
conclude,
because
the
next
one
is
my
conclusion
slide,
so
mandatory
subdial.
These
are
a
simple
elegant
feature
that
drastically
simplifies
at
least
two
extensions
to
the
protocol,
at
least
one
of
which
is
actually
something
that
people
want
to
use.
They
are
incompatible
with
the
old
spec.
They
can
break
your
network
if
you
enable
the
new
extension
without
upgrading
your
old
reuters,
and
this
could
potentially
be
avoided
by
bumping
the
protocol
version.
Thank
you
for
attention.
G
Thanks
joyous
david's
canaussie,
I
really
really
dislike
the
option
of
bumping
the
protocol
version.
So
first
point
is
I.
Disagree
that
we
need
a
flag
day.
You
can
have
two
separate
ones,
as
you
actually
discussed.
If
memory
calls
in
Chicago
first,
you
do
a
way
of
where
everything
supports
the
mandatory
bits
and
just
drops
those
and
also
supports
unicast
hellos
and
drops
those.
And
then
many
months
later
you
can
update
the
routers
one
by
one
to
send
start
sending
these.
So
that
is
one
solution.
G
G
If
you
could
go
back
one
slide,
please
you
propose
two
solutions,
so
the
first
one
I
think
could
be
doable
if
we
have
those
two
separate
days.
The
second
one
well,
there's
also
a
third
possibility,
which
is
all
RFC.
6120
six
is
version
three
period,
I,
don't
like
it
either,
and
it's
still
a
possibility
that
is
still
doable.
G
F
Invade
it's
actually
much
simpler
than
that,
but
this
fax
has
is
that
you
must
accept
packets
of
their
both
versions.
So,
where
you
have
your
version
different
front
to
you
put
in
version
different
from
both
two
and
three
so
in
reception,
you
just
have
two
versions
that
you
accept
on
sending
you're
allowed
to
always
entry,
but
what
is
recommended
is
that
you
send
to
unless
you've
got
a
mandatory
bit
somewhere.
So
it's
actually
much
simpler
than
you
make
it.
J
K
I
I'm,
just
basically
gonna
agree
with
David,
but
I'm
gonna
point
out
that
on
unless
RFC
6120
six,
not
this.
The
original
says
that
what
you're
supposed
to
do,
if
you
get
a
higher
version
numbers
throw
out
that
packet
and
do
nothing
at
all
to
the
state
of
that
that
Pierre
I
don't
know
if
we
know
if
existing
implementations,
when
they
got
a
version
three
suddenly
and
they
only
implement
version
two
from
a
peer.
Are
they
gonna
just
keep
it
state.
K
E
Goal
or
chitosan
so
I'm
not
really
soozee
astok
about
the
version
3
version
to
stuff
what
happens
in
version
4.
It's
a
silently
ignored
right.
What
happens
to
all
the
so
so
just
be
clear,
so
we
need
to
keep
around
carrying
around
all
the
I
must
send
her
version
to
code.
If
I
don't
have
any
mandatory
sub
t,
lves
I
should
send
as
version
2
right.
So
what
happens
when
we
go
from
3
to
4?
Do
we
still
send
us
version
2
and
everyone
keeps
all
their
version
2
parsing
code
around
yeah?
E
That's
why
I
don't
like
it!
So
that's
the
reason,
and
so
I
think
that
figure,
something
else
that
that's
what
I
would
say:
yeah,
maybe
like
the
business
of
you've,
heard
a
version
3
packet
from
or
you've
heard,
880
LV
that
says,
I
speak
subtil
tlvs
and
therefore
I'll
send
them
from
from
another
device.
That's
as
good
to
me
as
anything
else.
E
A
Tokyo
named
Joe,
Johnson
and
I
agree
with
all
the
people
who
say
that
they
don't,
but
this
is
annoying
and
too
complex,
but
I'm
also
not
sure
whether
or
not
it
solves
the
problem,
because
we
have
widely
or
relatively
wildly
deployed
extensions
that
may
exist
in
two
different
versions.
So
a
best
for
cannabis
up
so
specific
extension
exists
in
a
version
that
would
be
compatible
with
version
2
and
one
that
Penson
sake
of
ease.
A
B
B
G
This
is
a
very
cramped
ping
box.
Again
all
right,
hi
everyone,
my
name
is
steve
kennedy.
I
work
at
Apple
and
I've
been
playing
with
Babel
for
a
few
years
now,
or
maybe
at
least
a
year
anyway,
I'm
here
to
talk
about
unicast
hellos,
so
this
is
work
in
collaboration
with
mainly
Toki
and
Julius,
to
spend
a
lot
of
time
like
either
writing
code
at
their
dock,
but
also
with
a
bunch
of
other
people
that,
contrary
to
the
document
or
on
the
mailing
list,
apologies
if
I
forgot
anyone.
G
G
So
the
main
reason
I
got
interested
in
this
is
when
I
wrote
my
first
implementation
of
Babel,
one
of
the
links
it
was
running
over
was
some
custom
wireless
link
that
would
TDMA
between
frequencies,
and
one
of
the
properties
of
that
is
that
multicast
was
a
disaster
unicast.
You
would
get
reliably
because
you
knew
when
the
other
pier
was
listening.
Multicast
yeah,
not
so
much,
and
so
I
was
kind
of
in
this
case.
This
wasn't
my
implementation.
G
It
was
the
original
one
and
it
was
just
she
kept
falling
over,
so
I
went
and
dug
up
into
it
and
figured
out
there
was
because
of
the
multicast,
so
he
got
me
thinking
can
I
send
them
unicast.
Oh
no,
that
spec
says
no
in
a
big
red
must
so
because
in
Babel,
hello's
did
two
things.
One
was
discovery
of
the
piers
which
really
needs
to
be
multicast
and
the
other
was
link
quality
estimation
pure
liveliness
and
Traverse
reach
ability,
detection
well,
the
fourth
part
of
that
anyway,
so
I
was
thinking.
G
G
Do
some
out-of-band
mechanism,
so
that's
kind
of
where
this
started,
and
then
this
is
applicable
only
so
two
links
where
multicast
sucks
two
links
where
there
is
no
mult
and
also
too,
if
we
start
wanting
to
build
security
and
a
lot
of
the
security
mechanisms
that
exist
today,
don't
play
nicely
with
multicast,
so
one-to-one
relationship
and
the
keys
are
often
that
way.
In
that
case,
it
makes
it
a
lot
easier
to
do
everything
over
a
unicast.
So
that's
kind
of
the
general
idea
on
why
I
think
this
is
work
is
important.
G
Next
slide,
please
so
problem
statement
and
the
reason
that
the
original
spec
doesn't
so
all
says
that
you
must
send
hellos
multicast
is
that
they
have
sequence,
number
and
interval
that
correspond
to
all
the
neighbors
on
the
link.
So
anytime
you
send
a
hello,
you
need
to
increase
the
sequence
number.
You
can't
just
send
it
to
one.
Then
bad
things
will
happen.
So
that's
the
hello
T
of
ease
for
those
that
have
forgotten,
but
the
great
news
is
there
are
16
bits
of
reserve
that
could
always
come
in
handy
in
here.
G
So
next
slide,
please
the
way
we
built
the
solution
is
to
just
rename
this
reserved
field
two
flags
and
take
the
first
one
as
the
unicast
flag,
and
then
what
this
means
is
that,
instead
of
having
a
sequence
well,
what
the
flag
means
is,
if
it's
not
set,
this
is
the
multicast
hello'.
If
the
flag
is
set,
this
is
a
unicast
elope.
So
multicast
hellos
are
exactly
like
the
previous
ones.
They're
backwards
compatible.
They
work
fine
and
they
sequence
number
that
they
carry
applies
to
this
link.
G
Sorry,
so
you're
sending
it
to
all
neighbors
on
this
link,
and
the
interval
is
a
promise
that
before
that
time
expires,
you
will
send
another
one.
The
unicast
flag,
on
contrast,
means
that
this
is
a
unique,
a
solo.
So
conceptually
it
is
designed
to
you
specifically,
and
the
sequence
number
is
specific
to
you.
So
then
I
can
send
one
to
neighbor
a
and
one
to
neighbor
B
and
they
can
have
different
clocks.
G
They
can
increment
at
different
intervals,
so
add
a
recurrence
at
different
speeds,
they're,
completely
independent
and
yeah,
so
both
psycho
and
the
interface
stick
to
those
next
slide.
Please
in
terms
of
what
this
means
for
interoperability,
if
you
only
send
the
multicast
hellos
we're
still
in
spec
161
26.
What
is
necessary
for
this
to
not
break
the
network,
because
Jose
was
saying
earlier,
is
that
nodes
need
to
understand
the
unicast
flag,
the
bomb
that
arises?
G
So
what
we
mandate
is
that
if
you
see
a
unicast
flag,
you
need
to
understand
it.
So
one
that
simple
solution
is
to
you
see
a
unicast
flag.
You
drop
that
hello,
and
that
makes
it
very
similar
to
the
previous
behavior,
or
at
least,
if
you
don't
know
what
that
neighbor
is
saying,
you
will
kind
of
completely
ignore
him
and
not
establish
neighbor
relationship.
So
at
least
you
avoid
other
problems.
G
Also,
it's
not
mandated
mandated
to
send
both
so
implementations
that
today
just
send
the
multicast
ones
or
stones
back
but
implementations
that,
for
reasons
of
what
links
are
using,
whatever
only
want
to
send
the
unicast
once
that's
still,
okay,
you
could
end
up
his
case
where
some
nodes
that
only
do
send
unicast
and
so
knows
that
only
send
multicast
on
the
same
network.
Those
will
still
interoperate
if
they
both
understand
both
next
slide.
Please.
So
what
do
you
need
to
actually
implement
this?
It
was
a
surprisingly
short
once
I
actually
got
back
into
it.
G
So
in
the
for
the
multicast
hellos,
you
need
a
sequence
number
for
yourself
for
interface
and
an
interval
as
well,
and
then
for
each
neighbor.
You
need
the
sequence
number
and
the
interval
from
that
neighbor
in
the
neighbor
table.
What
this
adds
is
now
in
the
neighbor
to
go.
You
also
have
your
outgoing
sequence
number
unicast
to
them,
and
the
incoming
unicast
sequence
and
interval
from
them.
That's
all
you
need
to
add,
and
also
when
you're
computing,
the
cost.
G
You
can
react
differently,
whether
it
came
over
unicast
or
multicast,
because,
like
key
TX,
for
example,
was
designed
for
the
multicast
properties
of
Farrow
211
next
slide,
please,
and
that's
mostly
it
for
unicast
flows.
One
interesting
problem
that
came
up
was
there
cases
where
you
want
to
send
most
of
your
hellos
using
one
methodology.
G
Let's
say
you
want
to
send
most
of
them
using
multicast,
but
every
so
often
you
want
to
send
one
unicast
in
the
previous
back.
If
you
did
that,
you
had
to
send
one
with
a
very
long
interval
and
then
keep
sending
them.
So
in
order
to
make
that
a
lot
easier,
we
introduced
what
we
call
unscheduled
hellos
and
what
those
our
hellos
with
an
interval
of
0.
G
When
you
send
those
you
still
increment
the
sequence
number,
though,
in
some
of
these
cases
it
actually
doesn't
matter
because,
if
you're
just
using
it,
for
let's
say
the
RTT
information
for
the
RTT
extension,
you
don't
need
it,
but
it
still.
That
was
a
vision
we
could
have
gone
either
way.
We
just
had
to
go
with
this
one
and
the
unscheduled
hellos,
which
you
shouldn't
necessarily
use
them
for
the
neighbor
acquisition,
because
you
have
no
way
of
telling
if
the
neighbor
went
away.
G
G
Absolutely
fair
what
I
read
the
document
does,
though,
I
think
unless
we
edited
that
afterwards,
what
it
did
say
at
some
point
was
that
what
did
you
document
said
before?
Is
that
if
you
don't
see
any
hellos
from
a
neighbor
for
a
while,
you
must
set
the
cost
to
infinity
and
forget
it
and
I
think
that
what
the
doctrine
says
now
is
that
if
you
don't
see
any
schedule
too
low
for
a
while,
you
do
the
same
thing.
So
if
you
only
ever
received
on
schedule
too
low,
that's
not
good
enough
to
stay
established
neighbor.
G
D
L
L
Bus
quick
question
so
on
the
so,
presumably
when
you're
multi
casting
hellos
new
neighbors
could
arrive
at
any
time
and
therefore
you
should
never
really
stop.
Certainly
podcast
ellos.
If
you
sent
a
unicast
hello
in
somebody
responds.
Does
that
mean
that
they're
dropping
that
hello
is
then
done
and
you
stopped
sending
hellos.
Apart
from
your
unscheduled
thing
that
you
said
just
now,
it
depends
what
you're.
G
L
G
I,
don't
get
your
question
because
you
keep
sending
hellos
periodically
in
Babel.
Okay,
it's
not
a
one-time
thing.
You
keep
to
have
a
neighbor,
you
need
to
keep
receiving
hellos
from
them
and
when
you
receive
flows
from
them,
you
need
to
reply
with
I
heard
yous.
So
if
you
keep
hearing
close
and
I
heard
you
from
a
neighbor,
you
know
they're
there,
it's
not
a
yeah,
maybe
hello!
It's
not
the
right.
L
F
F
This
says
that
multicast
hellos
must
be
sent
to
all
neighbors,
either
over
multicast
or
over
an
exhaustive
set
of
unicast,
and
given
that
I'm
not
quite
convinced
that
just
this
observation
is
not
enough
to
solve
the
your
problem
and
so
I
keep
wondering
I've
lost
a
lot
of
sleep
staring
at
the
text.
While
we
were
editing
it
and
apologies
to
everyone
who
was
fed
up
with
our
spamming.
As
we
were
discussing
sexual
details,
I
spent
a
lot
of
time.
Thinking
do
we
actually?
Is
it
worth
the
complexity?
In
this
case?
F
The
other
comment
I'd
like
to
make,
which
makes
me
a
little
bit
uneasy,
is
that
we
are
contradicting
ourselves.
There
is
tag
that
belongs
to
you.
That
says
that
you
wrote
that
says
that
you
must
force
both
kinds
of
hellos
and
texts
from
me.
That's
in
the
mallow
manner
says.
Actually,
if
you
really
insist,
you
can
ignore
unicast
hellos
we're
not
contradicting
ourselves
technically,
because
what
that
means
is
that
you
must
parse
the
unicast,
hello
and
you're
only
allowed
to
drop
it
after
you've
passed.
It.
G
Like
a
good
idea
today,
cool
yes,
that
gets
organized,
please
email,
the
or
whoever
once
organized
that
Julius
Europe
to
organize
this
meeting.
So
we
discussed
this
week.
You
know
please
email
the
list.
So
anyone
because.
G
Whole
yes
to
answer
your
first
point:
that
is
absolutely
true.
One
of
that's
when
I
first
came
up
or
sorry
when
I
first
wrote
up
the
proposal
for
unicast
flows,
I
called
them
instead
of
unicast
multicast,
I
called
them
personal
and
public,
precisely
because
they
don't
need
to
be
sent
over
recasting
multitask,
but
that
was
gloriously
shot
down
on
the
mailing
list.
So
we
went
back
to
this,
but
there
is
that
a
big
woody,
absolutely
one
of
the
other
benefits
of
unicast
allows,
is
to
allow
you
to
have
different
intervals
per
neighbor,
which,
depending.
K
M
B
Think
we're
going
to
have
a
blind
description
and
stuff
of
this
site.
One
oh
yeah,
filly's,
what's
going
on
as
the
talks
are
mostly
people
are
talking
for
the
length
of
time
allocated.
Then
the
questions
are
expanding
it
a
lot
so
we're
kind
of
running
short
on
time.
The
next
is
table
information
model
by
Barbara
and
if
you
could
run
under
time,
that
would
be
good,
but.
I
Okay,
so
we
agreed
at
the
last
meeting
in
Chicago
that
we
would
make
this
a
working
group
thing
so
I
at
the
very
last
minute,
remember
to
upload
a
working
group
draft
with
just
a
couple
of
minor
changes
from
Chicago
I
know
you
didn't
oh
I'm,
sorry
next
slide
pretty
minor
stuff
and
then
I
added
an
open
issues
appendix
next
slide,
and
this
is
what
I've
currently
gotten
the
open
issues,
mainly
from
discussion
and
from
comments
from
Julius.
Of
course.
I
I
There's
some
other
things
that
are
pretty
detailed
and
you
know
maybe
Julius
will
get
some
time
to
think
about
whether
he
really
cares.
The
statistics
and
log
stuff
I
think
probably
is
important,
and
so
in
my
next
drive,
I'm
actually
gonna
start
looking
through
and
maybe
suggest
some
possible
statistics
that
could
be
collected.
F
I
F
N
Ok,
so
just
a
few
backgrounds,
the
so
specific
routine,
is
a
routing
polygon
which
x10
next
up
voting
and
well.
The
routing
decision
depends
bus
all
the
source
and
the
destination
address
of
the
packet,
so
routing
tables
maps,
pairs
of
fresh
figs
to
next
dot
and
its
main
use
cases
for
suis
forum
cost
centric
mutual
me
so
we're
using
prefix
of
a
like
a
table
addresses.
N
So
the
natural
solution
for
Bible
is
to
add
the
source
prefix
to
any
data
structure
and
also
to
message,
but
the
most
is.
The
most
important
problem
is
that
the
source
prefixed
cannot
be
just
dropped
for
an
update.
Otherwise
you
may
have
routing
loops.
So
the
typical
example
is
that
when
you
have
a
specific
footer,
which
has
a
specific
route
legacy
water,
if
we
drop
the
sauce,
prefix
will
announce
a
different
route
and
then
you
will
have
the
rottenness
necklace.
N
Elvis
and
this
new
draft
introduced,
and
only
one
subdial
visa
sauce,
prefix
sub
govt,
and
you
see
that
it's
a
very
simpler
next
twist,
of
course,
6126
doesn't
hinder
mandatory
subsidies
and
so
cast
Lagasse.
Barber
water
will
drop
the
subtly
and
we
have
the
example
seen
before
and
causing
the
routing
loop.
So
this
extension
is
incompatible
with
6126
nextly,
so
about
implementation
status,
it's
implemented,
it
works
and
it
shows
currently
an
experiment
was
set
jelly
next
to
it.
N
So
one
of
the
main
remaining
problems
is
about
white
out
requests.
So
6126
says
that
requests
white
cut,
requests
for
routing
table
dump,
but
the
program
is
what
exactly
means
a
wild-card
request:
I
mean
in
6126,
so
a
legacy
water
only
those
routes
which
are
not
so
specific.
So
when
you
say
says,
give
me
a
for
routing
table
dump
the
only
request
for
legacy
routes.
So
the
question
is:
does
it
if
we
send
our
routes
included,
source
or
specific
phone?
N
Those
will
break
the
semantics
or
not,
and
if
we
send
one
of
the
four
Emmys,
if
we
send
more
routes,
is
there
a
big
waste
of
the
bandwidth
so
and
the
salt
point
is
a
technical
detail
which
will
see
afterwards
next,
please
so
there
are
has
been
many
proposal
and
there
is
for
that
kind
of
propose.
Also.
The
first
is
okay,
we
request
a
food
and
we
send
the
food
and
the
second
is
to
say
we
will
request
exactly
what
we
want
and
we
will
receive
exactly
what
we
want.
N
The
second
is
a
slightly
is
a
compromise.
We
each
we
only
say
periods
here,
how
my
extensions-
and
we
receive
perhaps
some
waste
wood,
but
normally
not
a
lot,
and
the
last
proposition
was
to
duplicate
market
request.
Next,
please
next,
which
I
will
skip
this
this
side
and
we
can
come
back.
It's
the
detail
of
our
or
proposal.
N
So
another
thing
was
about
white
card
updates.
So
of
archived
updates
is
in
fact
a
workout
reflection.
So
it's
not
the
same
program
because
typically
it's
when
a
rotor
shutdown
isn't
a
wire
cutter
attraction.
So,
of
course,
so
specific
booster
must
be
retracted.
To
so
I
think
there
is
concerns
is
that
there
is
no
need
force
or
specific
workout
retraction
next
bit.
N
So
as
a
conclusion,
so
thanks
to
men
that
resub
theories,
because
the
extension
is
really
simpler,
but
the
code
and
the
statute,
it's
implemented,
it
works,
and
now
there
is
something
to
to
fix
so
first
to
choose
a
subtlety
number
so,
for
example,
128
and
also
chose
a
proposal
for
so
specific
request,
I
personally
personally,
like
the
simpler
one
which
is
sending
for
damp
and
finally,
I
would
like
to
request
the
working
group
adoption
for
this
draft.
Thanks
for
your
attention.
G
David's
gonna
see
so
first
off
great
work.
I
really
think
the
working
group
should
adopt
this.
It
makes
sense
in
the
Charter.
In
my
mind,
I
was
one
of
the
ones
loudly
complaining
about
the
full
route
dump,
and
now
that
I've
come
to
look
at
the
solutions
and
how
none
of
them
are
like
greatly
satisfying
I
can
totally
the
for
if
the
full
dump.
It's
probably
not
that
bad.
B
B
B
F
O
You
know
to
maintain
an
imperfect
low
stage
so
and
windows
that
appear
technology,
splitted
networking
into
three
levels
and
the
first
level
is
overlays
and
the
peer
transport
level
and
underling,
and
we
know
that
in
order
to
forward
peer
encapsulated
package
must
be
transferring
the
network
after
the
network
was
able
protocol.
It's
the
under
it
routing
protocol,
and
we
can
use
Babel
is
our
soldier
under
protocol
appear
so
banging
beer.
O
Key
parameters
can
be
Kuwait
by
able
protocol
and
widows
archivo
device
is
distance-vector
routing
protocol
that
operates
in
a
robust
and
efficient,
efficient
posting
ordinary
world,
as
well
as
the
various
networks
and
the
steps
URIs.
For
that
chilled,
he
introduced
stopped
your
V
of
our
extension,
so
we
can
use
a
new
sub
Q
V
for
beer
information,
transport,
transportation.
O
K
O
Information
and
based
Aaron
Islam
and
this
information
can
carry
the
Bible
update
message
through
the
new
beer
infrastructure
V
and
the
the
military
beach.
You
know,
latter
its
new
Beijing
Bible
protocol,
so
Manito
repeat
of
a
PR
subtlety
should
be
said.
If
you
charcoal
only
return
as
a
subtly,
the
suture
must
seem
to
not
understand
theory,
and
so
we
know
that
job
we
can
use
paper
protocol
a
protocol,
your
technology
and
beer
can
use
peer
computers.
O
The
forwarding
plane,
according
to
the
information,
is
that
conveyed
by
your
a
protocol,
and
this
is
under
a
protocol
of
beer
technologies
and
also
we
can
use
be
MLD,
took
away
the
notice
the
information
between
H
nodes.
Then
this
is
then
the
multicast
flows
can
be
forwarded
from
numerous
nodes
to
eat
egress
nodes.
The
PRT
is
a
new
virtual
groups.
M
O
Group
next,
please,
let's
see
the
form
art,
we
know
that
we
can
define
a
new
type
of
beer.
Somebody
loved
me
Oh
your
information
in
bevel,
but
we
still
have
to
associate
some
some
Yogi's,
but
there
is
no
substantial
piece
in
bevel
protocol.
So
how
can
we
achieve
the
destination?
O
And
so
the
two
sub
sub
Yogi's
are
carried?
Is
payload
so
well.
The
who
sub
sub
T
o
P
will
be
encoded
in
the
payload
of
beer
sub
choppy
and
the
so
the
list
of
perceptual.
We
will
include
the
list
of
the
peers
of
T
or
V
itself
and
as
a
potential
ins
of
the
two
stops
of
journeys,
so
we
can
Kawai
the
also
a
pair
information
news
network.
O
And
we
know
that
fu
there
is
many
Network,
because
that
was
a
different
dynamic
protocols
such
as
you
see,
is
pf1,
BP
and
also
level.
So
there
is
all
writing
EC
sauce,
pf4
PDP
extensions
yeah.
So
so
so
the
three
protocols
can
be
used,
its
underlay
of
peer
technology
and
also
we
think
that
paper
can
be
uses
under
a
protocol.
O
Enemy
knows
our
chipiya
architecture
does
not
relate
all
that
are
seeing
other
men
performing
if
our
procedures,
so
how
to
support
tunnels
that
will
allow
to
turn
appear
across
the
sutras
in
Babel
is
for
further
study.
We,
because,
according
to
the
previous
slides,
we
know
that
if
we
counterpart
the
P
R
sub,
Jovi,
Norwich
and
Imperial
pumped
transported
to
the
other
route
are
seeing
the
battle
walk.
So
it
may
be
the
beer
already
playing
computer.
You
in
several
notes,
so
it
may
be
questioned,
but
we
suggest
that
we
can
use.
O
We
can
update
all
the
returns
to
support,
is
extradition
and
also
the
beer
technology.
So
the
letter
S
will
not
be
a
problem.
I
think
and
this
position
has
been
implemented,
implemented
lemonade
then,
so
you
can
find
the
information
and
the
holding
is
based
on
the
update
version,
o
FC
61,
fantastic
space,
King
on
July,
dry
night,
I,
think
June,
9
I
think
it's
based
on
the
coding
version
of
that.
So
you
can,
as
it's
working.
O
P
Oh
yeah,
this
so
I
believe
that
this
document
should
be
in
Babel
if
there's
interest
for
it.
The
other
IGP
is
there's
wide
knowledge
of
how
to
safely
extend
those
OSPF
and
is,
and
we
have
a
good
decade
couple.
We
won't
talk
about
how
long
we
have
an
experience
for
extending
OSPF
and
I,
as
is
but
I,
think
that
Babel
it's
still
been
moving
and
that
knowledge
is
not
as
broad
plus
I
think
that
the
set
of
people
who
will
be
interested
in
consider
implementing
it
are
here.
F
So
first
I
think
that's
some
very
interesting
work
from
so
it's
not
necessarily
interested
from
the
point
of
view
of
the
applications.
My
understanding
of
beer
is
a
deer
functions
in
a
deer
domain
which
intuitively
speaking
and
I'm
afraid,
because
there
are
people
in
the
back
of
the
room,
I'm
afraid
of
but
roughly
speaking,
would
be
a
data
center
and
or
in
a
ferret.
F
Our
network
and
I,
don't
think
Babel
has
been
much
deployed
in
this
kind
of
environments,
on
the
other
hand,
is
very
interesting
is
to
see
how
difficult
it
is
to
implement
to
implement
beer
with
a
distance
vector
protocol.
If
you
look
at
the
basis
at
the
basic
beer
specifications,
they
assume
that
you're
doing
SPF
and,
as
you
pointed
out,
there
is
the
example
of
a
thematic
Tunnel
creation
that
really
assumes
that
you
have
full
topology.
So
how
much
of
beer
can
you
do
when
you
only
have
the
partial
view
that
Babel
gives
you?
F
B
F
I'll
finish
quickly,
so
I
think
it's
very
interesting
work.
There
is
one
thing
that
makes
me
uncomfortable
is
your
use
of
sub
sub
tlvs,
so
we
would
need
to
decide
what
to
do.
Is
that
as
to
adoption?
I
am
Not
sure
there
are
a
few
extensions
that
we
have,
that
are
mature
extensions,
notably
the
RTT
extension
is
deployed,
quite
is
deployed,
is
being
deployed
quite
widely
and
it
still
hasn't
been
adopted
because
in
this
working
group
we
have
been
concentrating
on
getting
the
base
protocol
specification.
F
B
B
M
Just
one
comment:
I
hope:
quick
looked
through
the
repository,
that's,
why
do
the
one
on
github
and
investor
poetry?
All
of
the
previous
history
has
been
replaced
with
the
initial
commit
I
think
it
would
help
to
preserve
their
commit
history
of
them
of
the
work
that
it's
based
upon.
So
you
can
either
see
what
was
in
the
source
code
and
what
was
a
leader
to
implement
their
extension?