►
From YouTube: IETF103-LSR-20181106-0900
Description
LSR meeting session at IETF103
2018/11/06 0900
https://datatracker.ietf.org/meeting/103/proceedings/
A
Paige
I
added
a
link
to
it
as
well,
so
the
main
LS
are
working.
A
page
has
a
has
a
separate
link
to
the
status.
The
highlights,
at
least
you
you
all,
might
think
this
is
a
rather
parochial
view
of
this
of
the
highlights,
but
I
think
it's
because
I've
worked
on
in
some
capacity,
I've
worked
or
been
the
document
shepherd
for
these
documents.
I
think
one
thing
is:
we've
had
the
yang
models,
we're
gonna
go
forward
with
them.
Both
were
pretty
close
on
OSPF,
actually
I'm,
just
I
realized.
A
We
needed
one
more
IPR
call
and
we're
I'm
just
rounding
up
all
the
contributors.
The
officers
are
all
readily
we've
been
just
doing
the
design
meetings
and
is
is
coming
shortly.
We
got
some
yang
doctor
comments
and
we
had
admission
on
Oh
Stefan's
working
on
those
the
mpls
data
plane
s.
Our
documents
are
pretty
much
all
working
group
last
called,
and
you
know,
though,
or
on
or
waiting
on
Alvaro,
so
weird
some
other.
A
Those
are
multi-year
documents
that,
as
Shepherd
up
to
them,
I'm
glad
to
see
those
go
by
the
other
documents
that
I
think
are
really
interesting.
We
have
presentations
so
I'm,
not
gonna
waste
any
time
on
those,
let's
see
and
I
know,
we
have
some
a
lot
of
different
flooding
proposals.
We
may
have
an
interim
on
this
I'm
kind
of
I.
A
Don't
really
think
it's
a
good
idea
to
try
and
do
it
at
the
end
of
the
routing
working
group,
because
who
knows
you
know
exactly
when
it
is
and
we'll
probably
lose
people,
so
we
might
have
an
interim
to
talk
about
the
drafts
that
have
a
lot
of
overlap
and
that's
it
okay.
So
we
go
with
the
first
presentation.
You.
B
C
B
B
E
B
A
E
E
E
We
also
allowed
that
the
per
application,
TLV
or
sub
TLV
could
be
associated
with
the
l2
link,
bundle
TLV
in
Esaias,
and
we
moved
the
registry,
that's
defining
the
application
pit
identifiers
because
it's
being
shared
by
ISS
and
OSPF,
and
we
moved
it
to
the
to
the
IGP
parameters
registry
and
no
SPF
v3
support
was
added.
This
was
actually
presented
in
Montreal,
but
just
included
it
in
the
list.
E
We
feel
these
drafts
are
mature.
There's
been
a
lot
of
discussion
about
this.
These
have
been
three
years
in
the
evolution.
There
are
some
implementations,
so
we
feel
like
both
drafts
are
ready
for
last
call.
I
will
mention.
There's
one
minor
editorial
change
to
the
OSPF
draft,
that's
coming,
which
is
just
to
make
sure
that
the
length
of
the
application
good
identifiers
is
is
a
multiple
of
four
bytes
which
is
consistent
with
the
way
OSPF
does
encoding,
but
other
than
that
we'd
like
to
see
these
go
to
last
call.
A
Does
anybody
have
any
any
objections
to
this
call?
We're
gonna
make
we'll
make
on
lists,
I
guess
I'm
a
co-author
of
one
of
these
drafts,
but
and
like,
although
they're,
not
I,
don't
think
I,
don't
think
we
have
any
implementations
there,
at
least,
but
at
least
there's
been
a
test
of
people
actually
coding
to
it
and
testing
with
it.
Already
with
with
this,
with
these
encodings.
So.
I
E
E
So
this
is
a
really
a
modest
extension
to
the
existing
restart
protocol
for
for
restruck
functionality
for
ISS
and
in
the
absence
of
any
concerns
that
have
been
expressed.
We'd
like
to
move
forward
to
the
last
call
I
should
also
mention
this
functionality
is
equivalent
to
what's
been
in
OSPF
for
many
many
years.
B
E
E
It
particularly
addresses
the
flooding
problem
to
the
leaf
nodes.
In
most
cases,
there's
no
flooding
done
to
the
leaf
nodes,
but
we
do
have
extensions
to
allow
us
to
recover
when
there's
incomplete
connectivity
between
some
of
the
spine
nodes
and
the
leaf
nodes
so
that
we
don't
block
all
traffic
well,
then
we
can
advertise
essentially
the
routes
that
are
that
need
to
be
exceptions
from
the
default
route
that
you
would
otherwise
use
from
from
the
leaf
nodes.
E
E
We
made
a
few
modest
changes
since
the
last
ITF,
based
on
comments
we
had
received
largely
from
Tony
P.
Thanks
very
much
to
him.
We
had
support
for
the
horizontal
links
between
the
leaf
nodes
and
we
had
a
flag
that
would
indicate
that
the
leaf
node
could
be
used
as
an
alternate
default
route.
The
feedback
that
we
got
was
this
was
adding
unnecessary
complexity,
so
we
have
removed
that
and
essentially
we're
just
not
making
use
of
the
horizontal
links
between
leaf
nodes
and
if
they
exist.
E
We
also
clarified
that
in
these
cases,
where
some
of
the
spine
notes
don't
have
full
connectivity
to
the
leaf
nodes
that
you
might
have
multiple
link
down
events
and
therefore
you
might
have
to
exchange
some
of
the
protocol.
Extensions
to
multiple
spine
notes,
not
just
between
one
leaf
node
and
one
spine
note.
E
E
No,
so
with
the
spine
leaf
extensions,
essentially
the
the
leaf
nodes,
the
LSPs
and
the
leaf
nodes
are
not
part
of
the
flooding.
So
it's
big
we've.
You
know
yeah,
so
they're,
just
not
part.
So
you,
you
use
the
Denny
flooding
extensions
for
the
upper
tiers
and
now
Isis
pine
leaf
extensions,
basically
to
to
come
almost
completely
eliminate
the
flooding
to
the
leaves
so.
B
In
it,
I
mean
sort
of
it's
kind
of
like
overloaded
LSP
operation
for
the
Leafs
I
guess,
but
right
they
were
advertising
their
own
LSP
with
no
flooding
to
them.
No,
so
when
you
said
the
horizontal
I,
just
read
the
reread
the
draft
I,
don't
remember
that
being
talked
about.
Obviously
he
said
it
was
removed.
E
So
the
previous
versions
of
the
draft
we
allowed
that
there
was
a
B
bit
that
essentially
a
leaf
node
could
say
I'm
a
potentially
a
backup
path
for
the
default
route
instead
of
going
to
the
spine.
If
your
spine
is
compromised
just
by
neighbors
compromised,
you
could
come
to
me.
We,
the
feedback
that
we
got
was.
This
is
just
an
unnecessary
complexity.
B
E
Okay,
the
idea
that
you
is
that
you
don't
that
the
leaf
nodes
do
not
have
to
have
the
full
LSP
database.
They
just
need
to
know
hey
what
spine
is
gonna
use
for
the
default
route,
and
if
there
are
some
compromised
connectivity,
then
they
need
to
get
some
advertisements
from
the
spine
notes
to
say
well
for
this
set
of
prefixes.
B
I
understand
that
I'm
saying
what
I
didn't
see
anything
in
the
draft
that
talked
about
the
horizontal
links,
you're
saying
they
can't
be
there,
but
what
happens
when
they
are?
Does
it
flood
the
Leafs
flood?
Do
the
Leafs
flood
there
I
know
they're
only
doing
their
own
LSP
right
and
they're,
not
gonna
hold
on
down
the
other,
but
are
they
flooding
their
own
else
pieces
to
their
leaf?
C
K
C
A
Working
group,
member
speaking,
is
working.
Remember
a
cylinder,
Cisco
Systems
I
think
this
has
little
overlap
with
the
other
proposals,
so
I
think,
and
it's
like
it's
a
moderate,
a
very
modest
proposal.
If
there's
any
overlap
in
functionality,
it's
an
overlap.
It
does
a
small
subset
of
what
RIF
does
you
know,
but
it?
But
it's
you
know
so
I,
don't
I,
don't
think
it
has
overlap
with
the
remainder,
so
I
think
we
could
safely
working
group
working
group
adopt
shouldn't
call
this
one
without
worrying
about
overlap.
L
B
I
was
having
this
I
I
haven't
decided
yet
on
whether
I
I
think
you're
I
think
we're
closed
on
it
I.
Don't
think
that
the
the
work
is
I
mean
other
than
that.
What
I
just
mentioned
right,
I,
think
the
work
is
kind
of
done
right,
I,
don't
think
it's
just
a
question
of.
Do
we
push
it
forward
right
as
we're
about
to
sort
of
collapse?
Well,
I
think
we're
going
to
be
collapsing,
a
bunch
of
other
flooding
stuff.
A
C
E
M
P
troublemakers
incorporated
and
I
think
a
key
discussion
on
this
draft
so
like
independent
all
the
other
stuff
will
go
to
there.
What
is
it
7356
or
will
keep
the
stuff
on
the
hellos
and
frankly,
I
think
we
should
push
for
the
7356,
because
then
it
has
potential.
Then
you
can
grow
lots
of
other
stuff,
yeah
I
think.
E
E
E
B
A
Yeah-
and
we
disagree
on
this
point-
you
know
I
think
this
is,
it
doesn't
have
overlap,
so
the
fewer
things
we're
trying
to
call
s
in
the
interim
the
better-
and
this
just
is
we
might
as
we
can
do
this
as
a
you
know,
Roma
hansmann,
the
other
thing,
that's
interesting
about
this
work.
We
have
implementations
going
so
I
hate
to
delay
it.
What
we're
waiting
on
the
these
separate
this,
these
all
these
graphs
that
are
related
to
subsets
or
separate
flooding
topologies
from
the
total
routing
domain
topology
well,.
B
O
B
M
E
M
E
M
A
result
and
right,
yeah
and
and
the
other
one
I
I,
think
the
flooding
is
an
optional
optimization.
So
if
this
is
really
the
stumbling
stone,
you
can
just
shelve
it
for
the
moment
elegantly
right,
the
draft
works.
Nevertheless,
it's
an
optimization
and
that
when
things
comes
to
free,
you
figure
out
what
you
do
with
that
stuff.
M
E
M
But
that
is
independent,
I
mean
whoever
comes
up
with
any
solution.
I
mean
this.
Will
you
have
to
signalling
and
they,
like
you
say
they
have
to
properly
deal
with
it,
that
this
the
Leafs
cannot
flop
through
right,
I
mean
I'm
not
objecting,
but
I'm,
suggesting
to
ask
for
resolution
of
the
mechanism.
This
is
the
time
before
the
hex
propagate
okay,.
M
B
M
K
Let's
say
we
only
have
here:
zero
in
the
tier
1
and
above
tier
1.
There
is
a
rich
connections,
for
example,
there's
a
ring
among
other
spines
right.
So
in
this
particular
case,
the
only
thing
you
need
to
do
for
this
draft
is
signal.
I
do
not
want
the
flooding
back.
That's
all
so
for
this
simple
purpose:
if
there's
any
link
breakage
or
something
there
is
a
possible
to
reroute
in
the
upper
layer,
so
in
that
kind
of
condition,
I
was
thinking.
K
B
H
F
B
G
F
L
Q
L
F
B
F
N
O
N
R
Good
morning
ma'am,
my
name
is
Sara
turn
from
Arista
networks,
so
I
work
about
updates
on
dynamic
flooding
on
dense
graphs.
First,
a
quick
review.
The
basic
idea
of
dynamic
flooding
is
to
tekapo
up
relatively
sparse
flooding
topology
from
the
physical
topology,
and
this
draft
has
focused
on
extending
the
existing
link
state
protocols
to
support
dynamic
of
flooding,
imposed,
centralized
and
distributed
mode
without
any
restriction
on
the
physical
topology,
and
this
draft
doesn't
intend
to
define
the
arizim
for
computing,
the
flooding
topology.
R
These
are
the
theories
that
have
been
introduced
and
to
support
dynamic
flooding
where
the
ISS
and
OSPF
it
covers
the
air
leader,
selection
and
flooding
topology
encoding
since
last
meeting
and
there
many
editorial
changes
and
also
two
important
changes
are
made
to
this
draft.
We
introduced
new
protocol
elements
for
both
eyes
eyes
and
OSPF
and
I
will
also
discuss
the
treatment
of
topology
events
in
more
details.
In
particular,
we
introduced
the
concept
of
a
temporary
flooding.
R
The
basic
idea
is
to
allow
the
node
to
flood
on
the
link
that
does
not
belong
to
the
following
topology
I
will
talk
more
about
it
later
now.
I
cannot
go
through
the
new
protocol
elements
we
introduced
in
this
update.
First
are
the
ice
ice
theories.
We
introduced
the
a
dynamic
flooding
sub
TOB,
so
you've
a
note,
suppose
dynamic
flooding.
It
can
insert
this
sub
heavy.
It's
a
router
capability,
TLV
and
the
knowledge
of
which
notes,
support,
dynamic
flooding
can
help
optimize
the
flooding
topology
in
sub
trv.
R
R
R
Each
aerosol
filter
is
a
new
macro,
echo
identifier
in
the
range
of
0
to
255,
and
it
identifies
the
errors
and
used
to
calculating
the
flooding
topology,
and
we
can
have
multiple
algorithm
fields
here,
and
this
is
the
new
ice
ice
flooding
request,
govt
and
it
may
be
included
in
the
iih
in
the
p2p
mode,
there's
only
one
type
of
or
hello
so,
but
the
node
needs
to
tell
the
neighbor
which
level
it
wants,
the
temporary
flooding
to
happen.
So
here
we
added
a
circle
type
field.
R
The
orbit
and
the
scope
field
is
meant
for
the
notes
that
support
this
ifc
7356
our
not
going
to
details
very
similarly,
we
introduced
the
new
OSP
ft/lbs,
the
dynamic
of
flooding,
sub
govt,
which
were
being
the
router
information
era,
say
for
Post,
v2
and
v3
for
flooding
requests.
We
introduced
a
way
proposed
option
built
in
the
errors,
type
1,
extended
options
and
fields
field.
R
R
Okay,
so,
as
promised,
I
will
talk
more
about
the
temporary
flooding.
So
why
do
I
need
a
temporary
flooding?
I
would
go
through
one
example.
Let
me
go
through
the
first
case.
Let's
sing
her
a
new
link
comes
up,
then
the
two
nodes
were
formed:
the
adjacency
and
extinct.
There
are
link
state
database.
These
are
all
done
using
the
existing
protocol
mechanism.
R
In
the
normal
case,
both
suggest
Encinos
are
connected
to
the
flooding
topology,
and
this
new
link
states
have
update
will
be
flooded
on
the
flooding
topology.
But
in
some
case,
if
the
one
of
the
adjacency
node
is
not
connecting
to
the
flooding
of
flooding
topology,
then
this
guy
will
not
receive
any
links
that
updates
until
a
new
flood
in
topology
is
calculated
and
there
it
who
becomes
part
of
the
new
frogging
topology,
so
the
name
to
flooding
still
works,
but
it
will
slow
down
the
convergence
significantly.
R
So
we
propose
here
that
in
this
case
and
to
use
temporary
flooding,
it
works
like
this.
So
when
the
new
link
comes
up,
if
the
node
sinks
it's
not
connecting
to
any
flooding
topology,
then
it
enabled
the
flooding
locally
and
then
Center
our
request
to
flooding
front
to
the
neighbor
asking
for
the
faladi
temporary
flooding
the
neighbor.
Once
it
receives
the
flooding
request,
it
will
start
flooding
on
this
new
link.
The
temporary
flooding
will
continues
until
the
new
threatened
to
perigee
is
calculated
and
the
pose
adjacency
nodes
are
connected
to
this
new
two
topology.
R
R
But
here
we
do
not
recommend
that
this
know
the
primary
request.
Temporary
flooding
are
oh,
it's
links
because
this
my
overwhelmed
the
note
itself
and
caused
some
instability.
So
as
you
can
see
that
there's
trade
off
wing
during
the
design
of
dynamic
flooding
on
one
hand,
if
were
it's
excessive
flooding,
may
cost
control
plane
to
overload
and
lead
to
networker
in
stable,
on
the
other
hand,
to
less
flooding,
may
slow
down
the
convergence.
So
there's
no
quantitative
or
main
measure
of
how
much
flooding
is
optimal.
S
B
T
N
B
So
I
knew
this
was
gonna,
be
a
little
contentious,
so
I
went
back
and
I
I
looked
at
the
timelines
right
and
Tony
published
his
draft
of
which
was
about
a
central
controller
and
distributing
a
flooding
topology
in
January
7,
then
the
the
distributed
flooding
reduction
draft
was
published
in
March.
They
both
presented
at
IETF
101,
the
distributed
algorithm,
was
found
wanting
right.
There
was.
B
B
N
B
And
also
the
flooding
pathology,
district
distribution
is
very
much
a
kiss
solution
right,
it's
very
simple
and
when
I
went
it,
this
is
just
my
opinion.
As
a
member
of
the
working
group,
when
I
look
at
your
solution,
it
seems
a
lot
more
complex,
right
and
and
I'm
not
sure
what
the
win
is
there.
So
anyway,
that's
my
opinion
as
a
member
and
also
the
history
here,
so
I
don't
I
would
hope.
B
T
Think
a
cognitive
days,
I
think
there's
a
meeting
or
as
a
proposal
in
some
kind
of
or
I
think
Jeff
hosted
the
meeting
regarding
the
requirement
for
data
center
right.
So
you
from
that
point
and
then
people
walking
on
the
platter
reduction
and
then
today's
first
we
also
presented
the
Palatinate
action
on
ATF,
101
right
and
then
I
also
remember
that
some
of
people
think
the
tribute
of
why
the
more
practical
and
that's
the
different
opinions
right
and
also
I,
think
we
have
a
regarding
the
solution.
People
also
have
given
opinion
on
this
solution.
T
Is
that
hard?
It's
so
proven
you
simpler,
I
think
maybe
after
post
draft
presented
and
then
we
we
should
have
discussions
from
technical
review
for
whatever
point
of
view
and
then
I
don't
know
whether
we
can
have
discussion,
which
one
is
better,
which
one
is
the
simpler
will.
Maybe
combined
together,
maybe
can
improve
one
Java
or
another
and
have
a
whole
solution
is
a
much
better
I
think
for
those
different
approaches
or
options
with
me.
We
have
should
have
some
discussion
right.
Easter
is
a
centralized
one
one
craft
and
distributor
one
another.
A
So
I'm
I'm,
supportive
that
speaking
this
chair,
because
I
I
lived
through
the
monnet
three
drafts
as
I'll
borrowed
it
as
well,
and
we
don't
want
to
get,
we
don't
want
to
adopt
multiples
and
say:
okay,
let
the
best
man
win
it
because
sometimes
they
go
on.
You
know.
Beef
Els
was
another
thing,
I
mean
they're,
you
know
where
they
had
to
two
different
signaling
solutions
and,
and
they
both
went
on
and
what
it
did.
Is
it
diminished
the
value
of
both
of
them
and
in
a
Monet?
A
What
we
had
to
do
at
the
end
was
they
all
became
experimental
and
they
kind
of
fell
into
obscurity,
and
we
definitely
don't
want
to
lose
this
work
and
I
think
I'd
support
Chris's
straumann,
and
maybe
we
could
put
that
straw
man
and
discuss
this
from
Ian
he's
got
on
the
list
and
why
and
not
rarely
because
we
were
gonna
run
out
of
time.
All
up
I
think
that's
what
we
should
do.
Yeah.
T
U
D
I
Ok,
so
I
am
here
actually
to
speak
about
like
yet
another.
You
know
floating
reduction
technology
here.
It
is
something
that
you
know
comes
out
of
the
brain
of
Hank
Smith.
So
you
know
he
wanted
to
present
here,
but
he
no,
he
couldn't
actually
make
it.
So
this
is
something
we
started
to
work
upon
from
since
the
last.
You
know
ITF
in
Montreal,
and
we
were
actually
thinking
like
okay.
You
know
we
have
some
floating.
You
know
reduction
algorithm
already
out
there,
but
there
might
be
a
way
to
actually
not
make
it
even
more
simple.
I
You
know.
The
word
simple
was
already
mentioned
before
we
like
simple,
simple,
are
good
things
and
if
it
can
be
implemented
also
on
the
router
you
know
running
already
is
yes,
and
if
the
router
can
be
extended
with
like
something,
you
know
very
simple,
like
no
additional
SPFs,
no
complex
signaling,
something
that
just
follows.
The
traditional
routing
I
think
that
would
be
a
simple
solution.
So
that's
what
I
want
to
be
presenting
here.
So
what
are
we
gonna
be
doing
here?
I
We
would
like
to
have
like
one
of
the
links
between
two
box,
which
is
used
for
floating,
so
that
is
the
the
master
plan
and
to
actually
achieve
that.
We
use
like
the
LVS
just
like
in
the
previous
proposal,
and
we
also
use
something
you
know
so
one
TLV
is
going
to
be
used
to
identify
a
floating
anchor,
so
the
technology,
what
I'm
describing
here
is
based
upon
creating
a
floating
tree
and
the
tree.
The
root
of
the
tree
is
going
to
be
our
floating
anger,
so
that
is
gonna,
be
basically
like.
I
A
I
I
Are
good
I?
Don't
only
have
texted
pictures
also
so
I'm
like
super
advanced
here
so
and
then
the
other
extension
I
have.
Is
you
know
if
a
particular
router
determines
you
know
what
its
gonna
be?
Is
you
know
best
link
towards
the
fleeing
anchor?
So
that's
a
local
decision.
He
actually
needs
to
signal
it
upstream
towards
the
anchor
to
tell
the
other
guy
that
he
selected
that
particular
link
as
the
floating
link
itself.
So
to
do
that,
we
actually
you
know,
use
like
another
TLV
in
the
is
H,
so
I'm
gonna
be
skipping.
I
This
I'm
going
to
be
jumping
directly
to
pictures
okay,
because
people
like
pictures,
so
what
you
see
here
on
the
classic
floating?
Yes,
so
you
see
the
router
in
or
out
of
13
here
in
the
middle
sorry
router
23,
so
assume,
router
23
gets
like
a
new
LSP.
He
actually
ships
you
the
upstream
as
the
blue
arrow.
It
goes
to
the
router
on
top.
That's
rather,
actually
you
know
depending
on.
If
it
is
new
or
not,
it
will
actually
send
that
LSP,
you
know
to
everywhere,
and
then
the
everybody
will
send
LSP
is
back.
I
I
22
in
this
case,
I
miss
okay.
It
doesn't
really
matter
so
we're
out
to
22
because,
like
a
new
LSP,
it
chips
it
up
and
that
only
the
blue
lines
actually
are
part
of
our
floating
topology.
So
it
actually,
you
know,
routed
12
go
then
just
ship
it
over
towards
router
11
around
to
13
and
so
on
boards.
So
the
blue
lines
is
actually
a
minimal
floating
topology.
Now
the
big
question
is:
how
do
we
go
from
the
classic
thing
towards
a
minimal
floating
thing
and
that's
what
I'm?
I
I
Here,
for
example,
here
we
actually
say:
okay
on
this
interface,
I
would
like
to
do
floating
and
on
the
other
interfaces
actually
going
to
be
doing
footings
and
all
suppression.
Now
that
is
very
good.
If
this
guy
gets
another
speed
and
you
want
to
shake
it
up,
but
of
course,
if
there
is
another
speed
coming
from
somewhere
else
like
from
here,
it
needs
to
go
down
also.
So
the
upstream,
you
know
the
router
going
up
towards
the
anchor
needs
to
be
aware
about
which
is
the
footing.
I
You
know
the
floating
link,
so
that
is
why
we
use
the
iih.
You
know
TLV
extension,
so
that
this
router
is
link-local
can
signal
towards
that
guy
I'm
going
to
be
using
this
link
as
my
floating
link,
so
the
same
kind
of
principle
is
actually
happening.
You
know
know
consecutively
like
you
know
different
times,
and
that
is
what
what
you
see
actually
in
this
picture.
So
what
you
have
in
this
case
you
create,
from
your
very
you,
know
very
dense,
diverse
kind
of
topology,
a
topology
for
floating
just
for
the
control
plane.
Something
like
this.
I
What
you
see
here
and
all
of
the
control
plane
you
know
and
all
of
the
control
plane
information
will
actually
have
to
go
over
the
anchor.
You
can
actually
have
one
anchor
you
know,
but
if
that
actually
fails,
you
actually
fall
back
to
the
traditional
floating,
which
is
maybe
undesired.
You
can
actually,
you
know,
set
up
a
secondary
anchor.
You
know
for
resiliency
in
your
infrastructure,
so
actually
works
very
well.
So
what
you?
Actually?
You
know
what
we
are
doing
here.
I
Is
we
actually
you
know
in
essence,
if
you
look
into
it
the
way
we
actually
are
distributing
our
LSPs
and
control
plane
traffic
for
from
a
routing
perspective,
it
is
very
similar
to
what
you
actually
do
with
like
a
pin
sports
mode
tree
towards
the
round
of
your
point.
It's
only
used
for
controlling
packets,
not
for
data
forwarding
at
all.
You
don't
need
any
additional.
You
know
SPFs
or
anything
else.
Complex
signaling
is,
you
know
relatively
simple,
so
this
is
again
when
I
explained
for
having
a
more
robust.
I
You
know
topology,
so
I
also
added
to
like
a
bit
more
information
about
what
we
would
like
to
add
in
the
tlvs,
so
the
first
TLV
so
the
anchored
TV.
So
this
is
the
TLP
used
by
the
anchor
to
signal
everybody
else
in
the
infrastructure.
I
am
the
anchor.
So
the
first
thing
you
have
to
put
in
there
is
like
a
priority.
It's
a
priority
field.
You!
Actually
you
know.
I
I
I
So
again,
a
very
simple
you
know:
TLV
you're
gonna
put
like
you
know.
We
were
thinking
about
putting
three
different
values
in
there.
The
first
thing
would
be
like
you
know,
a
floating
suppression
indicator,
so
this
actually
would
be
the
adjacent
and
all
the
router
itself
determines,
which
is
going
to
be
this,
the
linked
pointing
towards
the
anchor
and
that
actually
you're
gonna
be
setting
in
there.
Okay,
this
is
gonna,
be
the
link.
It's
going
to
be
suppressed,
yes
or
no.
I
Another
field
would
be
you
know
in
in
there,
too,
actually
give
the
actual
suppression
itself.
The
actual
suppression
on
the
link
which
can
be
used
for
troubleshooting
cannot
perspective,
which
would
be
very
handy
and
then
a
third.
You
know
piece
of
information
which
is
in
there
is,
you
know
if
you
wanna
have
like
a
bit
more
advanced.
You
know
algorithm
or
whatever
in
there
like
in
the
number
of
active
floating
adjacency,
so
this
actually
can
even
be
used
to
optimize
your
floating
topology
based
upon
the
degree
of
connectivity.
So
there
is
something
we
can
do.
I
It's
also
fully
backward-compatible,
so
you
can
actually
introduce
this.
You
know
gradually.
If
you
desire
to
do
that
and
in
essence,
you
know
what
it
results
to
is
like
you
know.
If
router
doesn't
really
support
this
and
it
cannot
inject
the
iOS
a
you
know
the
the
hello
TLV.
Then
there
is
no
flippin
suppression
and
we
just
fall
back
to
you
know
classic
traditional
floating
at
the
node
itself
anyway,
so
we
actually
have
some.
You
know
additional
text
written
up
already.
You
know
if
you
actually
go
floating
between
trees.
I
In
essence,
you
know
the
you
will
have
to
make
the
eternal
trade-off,
a
trade-off
being
and
on
easy
to
go
for
high-speed
or
you
go
for
stability,
which
actually
means
you
go
a
little
bit
slower
and
that's
a
trade-off
because
you're
going
to
be
making
also
the
going
slower
will
be
based
upon
the
degree
of
connectivity,
so
I
think
I'm
gonna
be
leaving
it
over
there.
With
this
light
on
the
whole
thing,
because
I
see
a
sea,
you
know
almost
kicking
me.
I
It
computes
like
a
sparse
tree,
but
it
actually
just
like
around
emoticons
around
the
whole
point,
so
you
create
like
a
tree,
but
you
don't
do
it
based
upon
like
any
kind
of
SPF
or
whatever
you
use
the
information
of
what
you
have
available.
You
know
where
the
anchor
is
just
select,
the
link,
which
is
you
know,
most
close
to
it
and
that's
say.
E
I
I
see
that's
a
good
one,
so
the
reason
we
come.
No,
we
created
this
draft.
That
is
because
you
know
it's
actually.
If
you
look
into
it,
you
know
because
Hank
you
know
is
written
somewhere,
I
just
go
back
in
the
past.
You
know
we
actually,
you
know
envision
this
as
being
like
relatively
simple,
to
implement
on
an
existing
ideas.
Implementation.
Okay!
Now,
if
you
know
we
want
right
now,
the
idea
is
just
you
know:
existing
is
sort
of
like
being
created
how
to
move
this
forward.
I
A
S
Lee
arista
so
I'd
like
to
reiterate
some
comments
that
we
had
in
private
email,
but
just
you
know
the
benefits
of
the
working
group.
My
concerns
with
this
are
all
about
the
diameter
of
the
result
and
also
the
degree
the
diameter
is
key,
because
that
controls
the
speed
that
the
flooding
is
going
to
give
you
a
graph
with
a
very
large
diameter.
Your
LSP
flooding
is
going
to
have
to
take
many
hops
and
that's
going
to
impact
convergence.
S
I
Again,
Tony,
you
know.
That
is
why
you
know
the
well
I
mentioned
lucky,
the
next
version.
We
actually
have
some
some
text
above
which
was
like
inspired
by
your
comments.
You
know
and
that's
why
you
know
we
have
like
some
sort.
You
know
we.
Actually
we
have
a
solution
which
trades
up
speed
by
convergence.
Yes
and.
V
Crisp
errors,
as
so
I
just
wanted
to
point
out
that
I'm
very
supportive
of
this.
It
doesn't
really
seem
to
me
that
it
fits
into
the
framework
of
of
Tony's
draft
or
Tonio
dolls
draft,
in
that
it's
not
just
a
distributed
protocol,
but
it's
distributed
plus
some
signaling
with
these
tlvs.
So
it's
not
just
like
a
subset
of
that
I
believe
that
would
be
my
my
take
I
mean
it
would
I
think
it
could
be
made
to
be
one
overarching
thing,
but
I
think
there
would
have
to
be
work
to
to
accomplish
that.
U
Chris
Martin
I
just
wanted
to
say
one
thing
because
Chris
and
Chris
gave
Todd
I
gave
him
my
spot
back
to
Tony's
point
the
the
nature
of
the
naiton.
The
notion
of
a
flooding
tree
is
kind
of
I,
don't
want
to
say
it's
obvious
and
good.
There
I
don't
mean
this
in
a
bad
way,
so
we
could
have
I
mean.
Obviously
that's
the
first
step
you
would
take.
I
mean
it
doesn't
seem
to
be.
The
coverage
is
not
the
same.
I
think
the
resiliency
is
not
there
and
the
diameter
issues
are
there.
U
F
H
F
T
In
a
surger
inversion
journal,
so
we
focus
on
distribute
a
mode
for
fellating
reduction.
So
in
addition
to
that,
we
also
talk
about
centralized
the
mode
and
the
static
mode
for
flattened
reduction.
That's
in
the
our
surgery
operation.
So
in
our
one
version
we
made
extensions
so
in
we
allow
operators
to
select
a
mode,
they
can
select
the
trigger
mode,
centralizing
mode
or
static
mode.
T
T
So,
after
version
zero
one,
we
we
deliver
a
couple
of
versions
which
address
comments
from
the
list
and
from
the
the
IETF
meetings
and
then
right
now
we
have
a
zero
for
version.
So,
in
the
current
version
we
have
a
piece
of
stuff.
One
is
that
we
for
post
centralized
diversion
and
distributed
mode.
We
have
bike
hub
pass
which
can
be
used
to
back
up
a
lot
in
topologies
bleed,
so
force
centralizing
mode.
We
have
messages
for
formatting
topologies,
so
include
including
cup
of
topology
for
logging
operation.
T
T
So
these
for
Mike
Harper
for
for
Latin
what
ASA
bleed
so
when
we
can
construct
a
fraud
in
topology
Normandy
will
have
two
objectives.
One
objective
is
that
where
will
the
leg
of
half
for
LA
tène
topology
and
then
which
can
be
used
to
reduce
the
flooding
greatly?
So
in
this
case
we
should
have
a
saline
flat.
Entomology,
that's
one
objective.
At
the
same
time,
we
also
would
like
to
cut
off
for
a
bit
hibachi,
which
is
more,
is
kind
of
a
reliable
means,
tolerance
to
failures.
T
So
in
this
case
we
need
a
favor
for
one
property,
which
is
it's
very
fat.
So
this
is
a
contradictory
right.
So
you
know
is
very
hard,
so
you
want
to
get
around
this.
We
propose
a
backup
task
using
backup
at
pass
to
back
up
flooding
a
topic
split.
So
in
this
way
we
can
have
a
first
lien
top
flight
in
topology.
At
the
same
time,
we
can
also
achieve
for
the
tolerance
so,
for
example,
for
critical
node
on
the
flooded
homology.
T
So
using
this
way
we
can
also
achieve
for
the
tolerance
for
manual
failures.
So,
for
example,
you
may
have
a
multi
finish,
though
the
failures
or
link
failures.
So
in
this
case
we
can
use
back
a
purpose
for
this
failure
know
so
link
and
then
same
time
that
remaining
topologies.
So
we
can
flood
at
unique
state
using
remaining
flag
property
and
then
the
packet
pass.
So
in
this
way
link
state
can
quickly
distribute
to
every
life
load
in
the
topology.
T
So
this
is
the
message'
for
flood
the
flood
entomologist
for
centralized
mode.
So
we
know
for
flood
in
topology
which
can
be
represented
by
the
links
under
flood
in
topology.
So
those
links
we
can
very
easily
encode
it.
So
we
can
start
for
each
node.
We
know
there's
a
links
attached
to
that
a
node,
so
we
can
just
encode
the
data
node.
T
In
addition
to
that,
we
also
keep
the
size
of
data
note
index.
So
in
this
way
we
can
achieve
a
very
efficient,
efficient
encoding
of
the
links
for
here
we'll
give
an
example,
for
example,
for
we
consider
know
the
local
node
with
short
for
ln1,
so
we
have
three
links
under
flooding
for
G,
which
is
the
green
link
so
to
remote.
What
one
remember
to
remove
the
three
so
three
links
in
this
case.
T
We
have
to
encoding
for
local
node,
Ln
1,
and
then
we
encoded
the
remote
node,
which
is
the
three
node
node
one
Ramona
LuAnn
Ramona,
to
reminisce
3,
so
Suri
links
so
local,
now
the
index
and
then
plus
the
lamp
of
nodes,
and
then
this
3
Note
edge
index,
and
then
we
also
keep
the
side
indicates
on
both
sides
of
the
index.
So
in
this
way
we
we
have
a
very
simple
and
efficient
that
know
the
link
encodings.
So
next
page.
T
T
T
T
So
this
is
a
encoding
about
a
backup
of
path,
so
we
have
a
encoding
for
backup,
has
4
loaded
for
note,
and
then
this
is
the
first
image
just
we
have
for
encoding
for
the
past
by
load
index
right
and
then
for
you
to
node.
We
may
have
a
number
4
PI,
K
pathway.
We
may
have
multiple
paths,
backup
path
and
then
for
each
of
our
postulants
and
then
the
least
of
lausanne,
the
past.
T
So
for
this
backup
backup
path,
we
can
put
it
in
the
POV
and
then
this
govt
can
be
put
it
in
the
open
LJ's.
So
similarly,
we
can
do
that
for
the
4-pack
hopper
for
the
link,
so
so
this
is
only
for
user
for
centralized
mode.
So
right,
so
we
can
see
that
we
have
a
backup
path
for
flooding
to
participate.
So
in
this
way
we
can
chief
the
objective,
reduce
the
flood,
topology
flooding
severe
flooding
significantly
at
same
time.
We
achieve
the
photo
tolerance
and
also
we
have
a
the
encoding
for
the
Flavian
topology.
T
That
will
give
us
couple
ways,
options
and
then
I
think
this
one
is
also
first
single
and
inefficient.
I
think
also
so,
regarding
the
the
one
we
have
a
solution
for
centralized
one
mode
and
also
distribute
mode
I
think
this
one
is
also
comprehensive
solutions.
So,
regarding
this,
one
I
like
also
asked
with
options,
because
but
I
idea,
some
people
propose
emerge.
I
also
I
think
it's
a
good
way
to
merge
because
same
problem
and
then
maybe
people
are
solutions
and
then
come
for
different
ways
and
then
maybe
ok.
A
O
We
tried
to
get
it
on
a
couple
of
other
agendas,
but
didn't
quite
often
anyway.
This
is
a
problem
space
that
I
found
really
really
interesting,
and
there
was
stuff
from
something
I'd
done
in
a
past
life
that
I
thought
was
applicable,
so
I
thought
I'd
throw
my
hat
in
the
ring
or
shark
tank
or
whatever.
You
want
to
characterize
this
exercise
as
something
that
I
have
a
distributed
algorithm
for
the
constraints,
letting
abide,
GP
advertisements
and
it
kind
of
no,
not
that
one.
W
N
F
B
F
X
B
G
F
G
O
Okay,
so
Tony
brought
forward
this
of
a
general
problem
on
how
to
produce
a
constrained
flooding
topology
for
dense
graphs,
something
that
would
be
immune
to
single
failures
and
would
reduce
the
number
of
copies
of
an
LSA
that
that
would
be
continually
interrupting
a
control
plane.
What
this
draft
discusses
is
a
distributed
algorithm
for
computing.
O
The
flooding
topologies
with
desirable
properties
I
have
only
really
looked
at
it
for
bipartite
style
graphs,
which
actually
could
be
so
it's
with
multiple
hierarchies
and
the
modified
ones
with
intra
tier
links,
it
may
be
applicable
to
other
topologies,
but
that
would
be
for
further
study
my
understanding.
This
was
kind
of
the
problem
space
at
the
moment.
So
that's
what
I
focused
on
what
the
approach
is
is
to
do
use
two
diversely
routed
spanning
trees
such
that
each
node
in
the
dense
graph
is
by
connected
to
the
flooding
topologies.
O
These
spanning
trees
are
computed
by
each
node
or
that
each
node
figures
out
what
its
role
is
in
the
spanning
tree
by
computing
it
from
the
basis
of
information.
That's
in
the
IGP,
the
flooding
topology
itself
is
the
sum
of
the
spanning
trees.
So,
for
example,
the
first
copy
of
an
LSA
received
by
a
node,
it
doesn't
care
which
spanning
tree
had
got
it
from
it.
O
That's
the
one
that
propagates
and,
of
course
the
next
one
is
considered
to
be
redundant
and
thrown
away,
because
the
key
thing
here
is
is
I'm
trying
to
achieve
resiliency
with
nothing
being
able
to
think
so.
In
essence,
it's
a
one
plus
one
arrangement
for
flooding
and
everybody
gets
two
copies
of
everything.
The
actual
flooding
itself
is
split
horizon
between
upstream
and
downstream,
for
LSAs
received
from
an
upstream
interface,
and
that's
one
of
the
ways
we
explicitly
constrain
flooding
and,
like
I
said.
O
O
Out
of
the
deals
now,
the
actual
time
braking
itself
is,
is
you
take
the
algorithm
mask
you
XOR
it
with
the
lexicographically
sorted
list
of
node
IDs
in
the
path
you
rank,
those
and
select
the
either
the
lowest
to
the
highest,
depending
on
what
you're
doing,
and
that
is
your
tie.
Breaking
the
interesting
property
of
this
is
is
that
any
component
of
the
shortest
path
is
also
the
shortest
path,
and
what
that
means
is,
as
you're
traversing
a
graph,
you
can
ditch
an
awful
lot
of
options.
O
So
this
thing
is
n
log
n
in
complexity,
but
not
all
n
log
n
czar
would
be
my
observation,
and
this
one
is
really
really
quite
frugal
of
resources
to
give
you
a
visual
representation.
This
is
what
the
the
flooding
topology
would
look
like.
It's
based
on
one
spanning
tree
rooted
at
0,
which
is
the
red
one,
and
it's
constructed
using
the
low
tie,
breaker,
so
you'll
notice
all
the
transit
nodes.
Yet
at
any
given
distance.
N
O
That
route
is
the
low
node
ID
and
the
other
one
is
reader
down
55
and
it
is
using
the
high
ID.
So
all
the
transit
nodes
for
the
green
tree
end
up
transiting
the
high
ID
of
any
given
set
of
nodes.
It's
equidistant
from
it.
The
net
result
is,
is
that
everybody
is
bi
connected
to
the
flooding
topology.
N
O
They
will
receive
two
copies
now.
The
flooding
rules
themselves
are
really
quite
simple
if
an
LSA
is
received
from
an
upstream
adjacency
and
it's
the
first
copy
you've
received
flood
on
all
downstream
member
adjacencies,
and
if
you
are
also
connected
to
nodes
that
are
not
participating
in
the
flooding
topology,
you
use
normal
flooding
rules
for
those
particular
adjacencies.
O
So
there
is
no
protocol
changes
to
the
actual
LS,
a
flooding
itself
to
make
this
work
now
the
required
protocol
changes
I
need
the
ability
of
a
node
to
advertise
that
it
wants
to
participate
in
the
flooding
topology
in
the
IGP.
This
would
be
some
form
of
capability.
Tlv
and
I
would
need
knowledge
of
the
roots.
Ideally,
that
would
be
advertised
in
the
IGP,
or
there
would
have
to
be
sufficient
information
to
allow
some
form
of
distributed
route.
Election
I
don't
actually
solve
that
problem.
O
Now
that
probably
the
key
limitation
to
this
is
is
I,
do
not
bound
the
number
of
copies
that
a
node
needs
to
generate
I
bound
the
number
of
copies
and
node
will
receive,
but,
for
example,
if
I
look
at
node
55,
it
will
generate
what
is
it
8,
16
24
copy?
You
still
have
to
produce
to
send
it's
only
ever
going
to
receive
two
copies,
but
it
has
to
send
and,
and
that
is
a
function
of
the
physical
topology.
That's
not
something!
That's
artificially
constrained
intuitively.
The
only
way
I
can
constrain.
O
So
the
draft
contains
a
discussion
of
the
problem.
Space
provides
the
algorithms,
the
flooding
rules,
a
discussion
on
the
requirements
for
route
selection.
How
to
interact
with
non
participants
in
the
flooding.
Topology
has
some
discussion
about
abri,
optimization
right
now.
The
whole
idea
is
is
I'm
trying
to
maintain
a
fully
redundant
structure
at
all
times,
which
means
when
failures
are
occur.
At
some
point,
I'm
gonna
have
to
go
and
clean
it
up
afterwards
and
proceed
to
restore
a
full
full
one,
plus
one
failure
tolerance.
O
It
also
suggests
some
strategies
for
dealing
with
catastrophic,
multiple
failures
where,
for
example,
the
extreme
worse
case
would
be
losing
both
routes
simultaneously.
The
draft
doesn't
define
the
protocol
elements
at
this
particular
point
in
time.
It
simply
discusses
what
is
needed
and,
like
I
said
it
doesn't
define
selection
procedures.
It
only
provides
what
the
requirements
are
for
the
routes
relative
to
each
other.
O
So
distant
very
quickly,
summarize
the
characteristics
of
the
solution.
The
structure
of
the
flooding
topology
is
interconnected,
one
plus
one
multi-point
to
multi-point
trees.
The
protocol
changes
requirement
are
an
advertisement
of
the
two
routes,
an
advertisement
of
the
desire
and
the
capability
to
participate
in
the
flooding
topology.
The
computation
that
each
node
has
to
do
is
order
two
times:
n
log
n,
but,
like
I
said
that's
a
relatively
frugal
n
log
n
in
a
spectrum
of
n
log
ends
that
are
out
there.
O
M
Tony
P
goober
right
discussion,
open,
so
I
didn't
look
into
all
the
super
gritty
nitty-gritty
detail
of
the
algorithm
and
I
wasn't
actually
worried.
This
work
has
been
done
until
I
saw
you
draft
circulating,
so
I
basically
went
after
the
thing
in
a
more
by
gut
feeling
what
the
properties
of
this
thing
will
be,
and
one
thing
I'm
confused
about.
So
will
that
produce
the
lowest
diameter
tree
or
will
that
stabilize
on
an
unnecessarily
lowest
diameter?
M
M
O
O
M
A
B
J
Earth
on
a
row
each
is
the
question
for
you
guys
and
what's
gonna
happen
next,
so
there's
this
straw,
man
on
separating
the
algorithms
from
the
rest
of
the
work.
There
are
several
proposals.
You
said
that
maybe
there's
gonna
be
an
intro.
You
also
said
that
you're
going
to
discuss
the
proposal
on
the
list.
Is
that
going
to
happen
first
and
then
the
interim
we're
gonna,
discuss
everything
on
the
interim.
That
decision
of
we
only
you're
gonna
choose
one.
Is
that
part
of
the
proposal
just
sure
that
everyone
knows
what's
going
to
happen
so.
B
A
B
Mean
I
think
the
interim
is
most
useful
about
the
algorithms
yeah
I
mean
okay,
I
I
think
we
just
need
to
settle
this
two
drafts
covering
the
same
exact
technology.
Right
I
mean
that's,
we
don't
need
to
two
drafts.
Did
yes,
so
we
sell
that
and
then
then
it's
a
discussion
of
the
algorithms,
whether
its
centralized
or
distributed
all
right.
S
D
H
B
E
E
Things
such
as
LSP
is
being
rejected
because
they
were
unsupported,
tlvs
or
sub
TVs
in
a
particular
LSB
or
a
TLD
was
malformed.
The
purge
handling
has
gotten,
has
several
modes
because
of
past
work
and
there's
been
some
confusion
around
that
and
the
this
is.
This
leads
to
some
significant
operational
problems,
because
you
can
end
up
with
inconsistent,
LSP,
TBS
and
different
notes
on
the
network
and
then
clearly
your
routing
is
broken.
E
E
E
So
it's
critical
to
remember
that
the
units
of
update
for
Isis
is
an
LSP.
It's
a
PDU,
it's
not
a
TLV.
When
we
say
we
accept
the
the
flooding
update,
we're
not
saying
we
accept
every
TLV
or
we
understand
their
retail
v
inside
the
LSP.
We're
saying
that
the
LSP
itself
has
passed
the
validation
checks.
What
are
the
validation
checks?
There's
a
checksum,
there's
authentication
which
optionally
may
be
used
and
then,
of
course,
there's
a
rules
as
defining.
Is
this
LSP
newer
than
what
I
have
in
the
database?
E
If
it's
not,
then
I
need
to
descend
the
newer
copy?
If,
if
what
I
have
is
older
than
I
need
to
accept
it,
keypoint
TLV
content
is
not
relevant,
but
in
terms
of
accepting
the
LSB,
the
validation
checks
are
on
the
PDU
level,
not
on
the
TLV
level,
next
slide.
So
what
interoperability
issues
have
we
seen?
You
have
a
case
here
where
you
start
out
and
no
day
has
sent
an
LSP
with
sequence:
number
99
everybody's
happy,
then
it
generates
a
new
copy
puts
a
TLV
in
there.
E
That
is
in
some
way
bad
doesn't
follow
the
the
specification
in
some
way.
What
happens
B
follows
the
rules.
He
looks
at
the
LSB
and
says:
well,
the
checksum
is
fine.
The
authentication
is
fine.
I
will
accept
this.
Then
he
sends
it
to
C
and
C
go
see.
This
TLV
is
not
not
to
my
liking,
I'm,
not
going
to
accept
the
LSB.
So
what
do
we
end
up
with?
We
end
up
with
note
a
and
B
that
have
version
100
of
the
LSP
and
note
C
and
D
that
have
version
99.
E
Purges
get
to
be
a
little
more
complex
because
we
start
out
with
the
base
specification
10
5
89,
which
suggested
that
well,
if
I
go
to
purge
and
LSP,
there's
no
point
in
keeping
the
content,
the
TLDs
that
are
in
the
LSB,
but
it
didn't
actually
require
that
the
tlvs
be
removed
just
suggested
that
that
was
a
good
policy.
So,
if
I
get
a
purge
based
on
ten
589
rolls-
and
it
has
some
TVs
in
it-
I
can
still
accept
it.
If
it
has
no
TVs
in
it,
I
can
still
accept
it.
E
This
was
clearly
broken.
So
5304
stated:
okay,
if
you're
using
cryptographic,
authentication,
the
only
TLV
that
you
can
have
is
the
authentication,
TLV
and
53.
Oh
10
53:10
followed
suit.
When
the
purge
origination
TLV
was
introduced,
we
now
had
an
additional
case
because
we
needed
to
allow
a
new
TLV
in
purchase,
but
if
we
followed
5304
rules
strictly,
then
anybody
that's
following
that
was
saying.
Oh,
this
has
a
TLB
besides
authentication
I
cannot
accept
this,
so
this
was
not
backwards
compatible.
E
So
implementations
that
support
P,
oh
I,
have
to
have
some
way
of
allowing
the
operator
to
enable
or
disable
the
use
of
the
P.
Oh
I
TLV,
when
cryptographic
authentication
is
in
use.
Note
that
if
you're
not
using
cryptographic
authentication,
you
can
go
back
to
the
base.
10
589
rules
say
well.
Okay,
anybody
should
be
accepting
a
purge
regardless
of
the
TLV
content
next
slide.
E
E
If
what
what
we
then
did
as
part
of
the
this.p,
oh
I
support,
we
added
the
possibility
of
other
tlvs,
perhaps
being
allowed
in
purchase
in
the
future,
and
in
fact
that
has
happened.
We
now
have
40
of
these
that
are
allowed
in
purchase
and
that's
why
there's
a
column
in
the
code
points
registry
that
I
showed
on
the
first
slide
and
which
says
hey
this
TLV
is
allowed
in
aperture.
It's
not
allowed
in
the
purge
again
in
order
to
be
extensible.
E
If
I
add
a
new
TLV,
that's
allowed
in
a
purge,
but
you
somebody
else
out.
There
has
an
older
implementation
and
they
don't
understand
what
that
TLV
is.
I
could
have
an
interoperability
problem,
so
if
I
implement
Bo
I
support,
I
have
to
do
it
in
such
a
way
that
I
can
say:
okay,
there's
tlvs,
that
I
know
about,
and
there's
still
these
that
were
not
defined
when
I
wrote
my
implementation
and
I
don't
know
about,
though
the
ones
that
I
know
about
I
can
say
based
upon
the
state
of
the
registry.
E
When
I
wrote
my
implementation,
this
is
allowed
in
a
in
a
purge,
or
it's
not
a
lot
in
a
purge
to
tell
these
that
get
defined
later.
My
implementation
doesn't
understand
them.
I
cannot
predict
whether
they're
allowed
or
not
I
have
to
ignore
them
when
I
receive
a
perch
and
next
slide
is
an
example
of
the
interoperability
problems
that
happen
with
purchase.
I
think
maybe
in
the
interest
of
time.
E
Go
through
the
steps
again,
this
is
this
draft
is
written
for
clarification.
There
are
no
protocol
changes
introduced
by
any
of
what
the
draft
talks
about.
This
is
just
trying
to
make
things
clearer,
and
especially
so,
because
we
have
had
interoperability
issues
in
the
field
and
we
were
just
trying
to
make
sure
that
it's
less
likely
to
happen.
M
X
Interrupts
truck
great
work,
very
much
needed
and
hopefully,
foundation
for
really
security
framework.
That
could
be
a
formal
reference
any
time
you
write
new
draft
here
and
our
friend
from
security
asked
what
happens
when
I've
got
four
more
references.
This
tells
us
what
happens
when
the
great
stuff
and
looking
forward
to
OSPF
as
well.
Okay,
thank.
C
D
Abramson
having
been
bitten
by
this
kind
of
interest
ten
years
ago,
without
v6
enablement,
where
it
would
drop
the
entire,
you
know
a
package
just
because
it's
so
and
I
could
be
sixty
le
and
there
yeah.
Please
I
would
like
that
not
to
happen
again.
I
had
to
spin
up
a
second
I
GP
to
do
my
fifty
six
in
a
row
lot
for
two
years:
okay,.
B
D
Z
E
Saying
when
you
write,
you
have
version
n
of
your
implementation
at
that
point
in
time
you
understand
some
set
of
tlvs.
A
new
TLV
can
be
introduced
after
your
implementation
was
written.
Clearly
you
don't
know
whether
that
TLV
is
allowed
in
the
purge
or
not,
because
you
just
don't
understand
it.
So
you
have
to
accept
it.
Z
Y
Y
I
It's
allowed.
Yes,
it's
a
lot.
Okay,
so
this
thing,
actually,
you
know,
is
I,
don't
want
to
go
there.
Okay,
I,
don't
want
to
go
that
so
this
idea,
actually,
you
know,
is
something
you
know
what
I
believe
is
relatively
simple
and
I
know.
If
you
look
into
it
it's
kind
of
surprising
it
never
popped
up
before,
because
you
know
we
see,
like
a
lot
of
proposals
to
you,
know
improve
all
of
the
floating
things
to
improve
our
convergence
time.
I
But
there
is
like
another
component,
you
know
with
a
cheapy
routing
which
can
really
really
speed
up
convergence
significantly,
and
if
you
look
into
how
the
fluting
actually
is
operated
in
the
way
our
IGP
is
actually
do
the
pudding,
so
they
actually,
you
know,
take
care
of
the
packet
pacing.
It
take
care
of
reliability,
retransmission
and
so
onwards.
You
know,
and
it
actually
has
been
unchanged
since
you
know
the
original.
You
know
the
technology
itself
now
the
way
technology
progressed.
I
You
know
we
now
have
TCP
and
it
sort
of
made
us
wonder
like
okay,
you
know
why
do
we
actually
first
want
to?
You
know
improve
our
floating
topologies,
but
not
really
look
into
like
you
know
how
route
it
is,
do
the
floating
of
control
information
between
the
routers
themselves.
So
we
said:
okay,
maybe
that's
not
look
into
TCP
and
actually
you
know
external
use,
an
outsource
all
of
the
floating
stuff
into
TCP.
Let
ECB
take
care
of
the
retransmission
and
the
packet
pacing
and
then
reliability
and
all
those
kind
of
things.
I
So
that's
what
we're
doing
it.
So
you
know
so
the
proposal.
What
we
have
here
is
FRA.
As,
yes,
you
know,
I'm
pretty
sure
we
can
do
the
same
thing
for
SPF,
but
you
know
at
this
point
in
time.
You
know
we
believe.
At
least
you
know,
let's
look
at
ICS
first,
so
in
essence,
what
it
is
about
here
is
indeed
you
know
between
two
rappers
to
exchange
LSPs
and
to
use
TCP
as
a
communication
channel
for
that
now
to
actually
do
that,
the
two
routers
need
to
agree
between
each
other
that
they
actually
support.
I
You
know
exchanging.
You
know
all
of
the
you
know
floating
information
over
the
TCP
session
itself,
so
we
actually,
we
define
like
a
new
TLD
for
that
in
the
IOH
now,
at
the
same
time,
because
we
also
believe
BGP
is
like
ultra
cool
and
it
also
uses
TCP
and
and
it's
a
TCP
byte
stream,
we
also
in
BGP,
is
using
some
sort
of
like
I
can
see
in
our
synchronization
market
header.
I
You
know
in
the
TCP
we
actually
said,
like
you
know,
if
we
go
down
the
road
of
using
TCP
for
our
control
information,
we
should
do
the
same
thing
as
what
we
have
in
BGP,
so
we're
gonna
be
defining
also
like
a
small
marker
to
have
synchronization
in
the
byte
stream
very
similar
to
the
way
beach
is
using
it.
So
if
you
look
into
the
different
scaling,
factors
of
is
a
yes
yeah,
so
the
first
thing
we
have
is
like
a
cave.
You
know
each
router,
that's
like
a
number
of
adjacency
like
neighboring
routers.
I
We
cannot
really
do
that
much
about
it
to
reduce
it.
The
second
thing
we
can
look
at
you
know
to
improve
scalability.
Is
you
know?
How
do
we
deal
with
flooding?
So
if
we
improve
that,
then
we
actually
we
improve.
You
know
our
scaling.
You
know
capabilities
here,
so
one
way
is
to
actually
you
know
work
upon
new
flutings
apologies
in
other
ways.
I
Actually
you
know
we
look
into
how
flooding
itself
is
done
and
then
the
third
thing,
what
we
can
actually
look
at
it's
like
you
know
in
is
how
SPF
is
done
right
now
we
have
the
extra
text
rise.
You
know
quite
okay,
it's
not
too
complex
and
it's
probably
the
best
we
can
do
without
creating
too
much
additional
complexity.
I
It
also
means
that
if
you
have
like
a
really
big
network,
let's
say
about
like
a
thousand
notes:
yeah
that
actually
has
like
quite
an
impact,
because
a
thousand
notes
will
result
in
approximately
you
know
for
a
full
sink
going
from
zero
to
everything
in
about
like
thirty
seconds,
because
we
have
this
30
milliseconds
packets
between
the
LSPs.
That's
a
lot
of
time.
We
can
do
much
faster
than
that,
because
why
do
we
have
those
30
milliseconds?
I
So
each
you
know
LSP
needs
to
be
act
on
a
point-to-point,
so
that
actually
comes
with,
like
you
know,
acting
the
packet
itself
and
some
associated
timers.
You
know
with
it
and
then
the
third
element
here,
it's
like
a
Kady
and
the
reliability
of
the
complete
sequence
number
of
packets.
So
if
your
point
to
point
interface-
and
you
come
up-
you
know
with
the
two
routers
the
ease
exchange.
You
know
the
link
state
databases
using
CNN
piece
in
each
years
and
a
B
we
actually
we
can
stuff
in
like
about
like
91.
I
You
know
different,
you
know
LSP
descriptors.
If
you
would
lose
one,
it
actually
automatically.
You
know
multiplies
itself
by
you
know:
91
LSP
is
being
exchanged
between
each
other,
that's
quite
significant!
So
in
that's
actually,
why
we
say:
okay,
you
know.
Why
not
do
this
exchange
instead
of
like?
Let's
just
take
care
of
it,
you
know
set
up
a
TCP
session
and
actually
you
know
push
all
of
the
LS
piece
into
that
one.
Now,
of
course,
if
you
want
to
set
up
a
TCP
session,
you
need
to
know
the
IP
addresses
to
be
used.
I
V4
v6
and
you
need
to
know
the
port
numbers
on
which
each
of
the
routers
actually
is.
You
know
listening.
So
that
is
something
you
can
actually
signal
between
each
other
by
you
know
by
you
know,
creating
or
adding
like
a
new
TLV
in
the
is
H
in
which
actually
have
like
different
and
old
TVs
subdial
vid
itself
for
the
port
number
before
addresses,
address
or
addresses,
and
if
he
seeks
address
or
addresses
and
right
now,
at
this
point
in
time,
we
think
that
is
sufficient
at
this
inner
artist.
I
E
I
New
hatreds,
the
new
behavior
itself
is
to
actually
establish
the
floating.
So
in
essence,
you
know
when
the
link
actually
comes
up,
they
actually
exchanged
is
ages
and
each
router
will
sort
of
like
look
for
this
new
TLV
to
figure
out
the
IP
addresses.
You
know
what
is
used
it
to
also
figure
out
that
it's
a
B
port
number,
the
router
with
the
lowest
router
ID,
will
actually
initiate
TCP
session
and
set
it
up.
So
from
the
moment,
TCP
session
is
set
up.
I
You
actually
will
exchange
only
one
time,
the
NIH
over
the
TCP
session
itself
to
make
sure
that
no,
the
guy
you
see
on
the
other
side
is
actually
the
guy
you're
thinking.
Yes,
so
you
can
authenticate
and
make
sure
about
that.
So
only
one
time
you
will
send
you
know
the
ionisation
bar
it
the
for
the
rest
on
the
normal.
You
know
on
the
normal
link
between
the
two
routers
in
October
TCP,
so
the
neighbors
ship
and
our
establishment
is
still
being
done
by
exchanging
iOS
age
messages
on
the
link
itself.
I
So
nothing
really,
you
know,
changes
from
that
perspective,
so
it
all
stays
the
same,
which
is
very
good
because
if
you
have
like
a
control,
plane,
failover
or
one
of
the
ends,
you
don't
want
that
the
TCP
session
itself
creates
additional,
you
know,
dynamics
and
in
our
neighbor
ship
complexity.
You
know
from
from
where
we
are.
That
is
all
you
know
described
pretty.
Well,
you
know
in
in
our
draft.
I
So
the
nice
thing
is,
you
know
when
you
do
this
now,
what
will
you
win?
So
in
essence,
what
you
win
is
what
you
see
it
on
the
bottom
and
it's
like
no
more
retransmissions
of
LSPs
or
verifications.
You
know
using
sequence
number
of
packets,
because
everything
now
is
in
the
hands
of
TCP,
and
that
is
really
nice.
You
don't
have
those
30
milliseconds
anymore.
You
can
actually
send
us
quickly
as
possible
as
fast
as
your
neighbor.
I
It
actually
can
accept
and
TCP
will
take
care
of
the
windowing
and
about
you
know
everything
else,
and
then,
of
course
you
know
your
you
know.
We
also
have
like
you
know.
New
behavior,
like
you
know
during
you,
know
the
you
know
during
the
footing
itself,
so
a
few
small
things
actually
change,
but
in
essence
nothing
really.
You
know
super
dramatic.
So
if
you
receive
an
LSP,
you
know
I
need
the
same
version.
The
rather
really
doesn't
do
anything
at
all.
If
you
actually
receive
an
older
version
of
an
LSP,
then
basically
what
you
do.
I
H
I
Yeah
kind
of
finished
kind
of
like
so
you
know
some
some
additional
plans
and
considerations.
So
better
the
interest
of
time,
I'm,
gonna,
I'm
gonna
skip
them.
The
only
thing
what
I
want
is
I
think
the
drafts
right
now
is
in
a
reasonable
shape
and
it
would
be
nice
to
see
you
know
if
it
can
be.
Actually,
you
know
adopted
to
the
working
group,
yes
or
no.
B
A
One
thing
that
I
have
to
say
I'm
gonna
check
into
it
more.
There
is
a
Cisco
provisional
patent
that
has
TCP
flooding
of
the
iGPS
as
a
component
of
it.
I'm
not
sure
I'm
gonna
check
with
are
illegal
to
see
if
it's
applicable
or
not
doesn't
go
to.
It
doesn't
go
into
this
level
of
detail,
but
I'll
check
on
that.
F
P
I
think
two
minutes
should
be
in
Tacoma
curses,
so
this
draft
has
been
out
there
and
presented
a
number
of
times
it's
more
or
less
stable.
At
this
point,
and
just
a
couple
of
changes
which
were
added
in
the
recent
update
for
more
clarification,
one
of
it
was
clarifying.
That
is
our
algorithm
TLB,
which
was
there
in
the
ISS.
Extensions
for
asada
and
pls
are
also
applicable.
P
Here
is
our
v6
and
there
were
some
function,
behavior
points
and
dot,
DX
and
d
t6,
which
were
included
in
the
draft,
but
there
was
no
use
case
documentation
for
what
for
what
they
are
used
for,
and
so
we
have
removed
that
in
this
version.
So
really
that's
the
only
change
the
next
step.
You
know
there
are
implementations
of
this
draft
already
out
there,
and
we
would
like
to
ask
for
working
group
adoption
this
one.
How.
F
N
C
AA
AA
Technology,
okay,
good,
so
this
is
San
ID
to
basically
provide
discovery
of
secure
pcs
capable
of
supporting
things
like
TCP,
AO,
TLS,
TCP
md5,
so
that
the
path
computation
clients
PCC,
can
send
and
receive
information
related
to
path,
computations
securely,
it's
a
very
simple
document.
Essentially
we
have
one
sub
TLV
with
three
options
there.
They
are
specifically
advertising
what
type
of
security
the
PC
will
support.
So
essentially,
this
is
just
a
sub
TLB
for
the
IGP
and
we
would
like
the
working
group
to
look
at
the
document.
It's
a
relatively
recent
document.
AA
I
think
we
published
it
probably
about
six
weeks
ago.
I
think
ACS
already
made
a
comment
that
if
we
use
TCP
ao,
we
will
have
to
provide
some
shared
secret
information.
That's
not
currently
in
the
document.
There
are
some
your
potential
security
risks
with
that
that
we
need
to
discuss,
or
at
least
identify
and
disclose
in
the
document
and
yeah
I
think
that's.
It
really
I
think.
A
What
we
talked
about
was
just
using
like
an
essay
ID.
There's
we're
not
talking
about
putting
the
keys
in
there.
You
know
this
is
coming
from.
You
know.
Pce
uses
a
uses
that
I
GPS
as
a
tool.
This
has
qualify
as
is
and
OSPF,
and
they
are
coming
and
saying
that
this
is
a
good
thing
to
do.
I
can't
see
any
reason
why
we
wouldn't
have
topped
it.
Speaking
as
chair
yeah
I
mean
this
important.