►
From YouTube: IETF114-LSR-20220729-1400
Description
LSR meeting session at IETF114
2022/07/29 1400
https://datatracker.ietf.org/meeting/114/proceedings/
C
D
B
B
C
C
C
These
are
the
giraffes
completed.
Last
call
we
really
need
the
flex
algo
done,
because
not
only
is
there
references
to
it
in
a
lot
of
the
sr
drafts,
there's
also
a
lot
of
our
fault
you'll
see
that
today,
a
lot
of
the
working
group
documents
that
we
have
are
based
on
this.
So
this
is
really
a
foundational
work
that
we
need
to
get
to
the
isg
and
published
next
slide.
C
This
this
extensions
for
srv6
this
is
ready.
I've
reviewed
it
once
they
incorporated
my
comments,
we're
going.
If
there's
an,
I
think,
at
least
I'm
pretty
sure.
I
think
I've
heard
I've
heard
it
second
party,
but
I've
heard
huawei
has
implementations
of
this
draft,
so
we're
going
to
do
a
last
call
shortly
after
the
ietf114.
C
Next
slide:
oh
no
stay
stay
here.
Oh
all,
right,
dynamic,
flooding
for
dense
graphs.
The
working
group
did
a
lot
of
work
on
this.
It's
I
I
say,
implementations
proceeding.
This
is
kind
of
slowed
down
and
there's
been
a
lot
for
one
reason
or
another.
The
implementations
there's
one
implementation
of
it.
We
talked
about
the
offers
and
we're
thinking
of
targeting
experimental
and
publishing
it.
Now.
C
A
lot
of
drafts
in
lsr-
and
this
is
this
phenomenon-
is
not
unique
to
the
lsr
working
group,
but
a
lot
of
drafts
in
ls
and
lsr
nobody's
really
interested
in
them,
but
the
offers
this
was.
This
was
one
of
those
exceptions.
We
had
a
lot
of
interest
across
the
whole
working
group
for
the
dynamic
flooding
and
I
think.
A
C
C
Fast
flooding
is
another
one
where
we
add
interest
across
the
working
group,
I'm
going
to
be
talking
to
the
or
chris
and
I'll
be
talking
to
the
offers
and
seeing
when
they
feel
that
rich
ready
for
a
working
group
last
call.
I
know
that
bruno
just
did
another
very
incremental
update
and
I
will
it
would
be
good
if
people
would
look
at
that
again
next
slide.
C
Okay,
we're
targeting
interim
around
september
7th
that
drafts
don't
make
the
for
drafts
that
didn't
make
the
agenda
now.
One
thing
about
this:
we
have
these
drafts
now
and
I've
seen
some
discussion
on
some
of
these
drafts
and
it
looks
like
some
of
these
rafts
may
be
unnecessary,
so
we're
not
going
to
have
presentations
we're
going
to
try
and
at
least
read
these
drafts
or
dra
or
presentations
on
drafts
that
are
definitely
unnecessary
anyway,
but
that's
the
time
we're
targeting.
B
B
B
B
B
E
B
F
F
My
my
q
is
pretty
severely
backlogged.
I'm
have
taken
several
steps
to,
let
me
get
through
it
faster.
It
will
take
a
while
for
those
to
actually
show
up
on
your
dashboards
and
in
terms
of
results.
I'm
not
generally
a
person
that
likes
making
excuses.
I
like
showing
results
instead,
but
it
will
take
a
while
for
the
results
to
actually
start
appearing
in
terms
of
what
you
can
do
to
help.
F
C
No
here
here's
a
here's,
a
real,
quick,
quick
one
from
me
speaking
as
working
with
chair.
I
think
that
a
timely
review
would
be
that
is
less
extensive
would
be
preferred
to
one
like
four
months
out.
That's
my
or
four
to
six
months
out,
and
I
believe
you
know
it's
already
been
through
the
working
group.
We
have
the
people
in
this
working
group
who
have
implemented
these
protocols.
C
F
That
is
fair.
One
of
the
things
that
I
try
to
focus
on
when
I'm
doing
a
review
is
hitting
things
that
I'm
fairly
sure
that
will
you
know,
are
going
to
trigger
other
iesg
members
anyway,
so
I'd
rather
they
trigger
me
than
trigger.
You
know
a
disgust
from
somebody
else
down
the
line,
but
yes,
quick
and
timely
and
then
getting
through
the
discussions
might
be
preferable
to
waiting
forever.
I
hear
you.
B
B
E
We
got
some
additional
comments
from
bruno
and
shraddha
beyond
what
had
been
written
in
the
errata
we've
incorporated
those
this
is
not
a
complete
set
of
diffs.
This
is
just
a
quick
summary
of
the
significant
changes
we
specified.
We
clarified
that
for
the
srte
application
that
this
is
data,
point
independent.
It
applies
to
srm
pls
and
srv6.
E
That
was
input
from
shrada.
We
clarified
the
use
of
the
zero
length
abms
the
l
bit.
These
are
essentially
things
that
came
out
of
the
original
errata
and
we
also
clarified
that.
Would
we
have
legacy
routers
in
the
network,
who
are
only
going
to
be
using
legacy
advertisements
that
we
must
not
only
continue
to
advertise
legacy,
but
we
must
not
advertise
asla,
because
the
legacy
routers
will
not
be
looking
at
those.
There
was
another
request
from
shraddha.
E
So
next
steps,
there's
no
substantive
changes
here,
there's
only
clarifications,
so
I
would
really
like
to
fast
track
this-
and
I
haven't
discussed
this
with
the
working
group
chairs,
but
this
is
the
plan
that
I
have
in
mind.
I'd
like
to
see
these
both
bits
drafts
immediately
adopted
I'd
like
to
get
last
call
within
one
ietf
cycle
by
the
next
meeting,
and
I
know
john-
has
graciously
volunteered
to
try
to
speed
the
isg
review
by
constraining
it
just
to
the
changes
not
to
reviewing
the
entire
contents
of
the
original
rfcs
and
john
I'll.
B
B
B
B
F
B
G
B
F
H
B
H
I
H
H
Isis
multi
topology
routing
is
used
to
create
a
dependent
topology
in
my
network,
so
empty-based
trvas
are
introduced
to
carry
topology
specific
link
state
information.
This
provides
the
capability
of
specific
specifying
the
customized
attributes
of
each
topology
when
each
type
of
reaching
is
associated
with
the
dependent
network.
Topology
mit
id
multiple
id
could
be
used
as
a
identifier
of
vtn
control
planes,
so
I'm
empty
routing
can
be
used
with
isr-based
display.
H
You
want
to
perform
a
construct-based
path,
computation
for
each
beating
on
the
network,
controller
of
the
increased
nodes,
the
network
resource
attributes
and
other
attributes
associated
with
utility
can
be
a
little
bit
highest
for
multi
topology
network
topology
specific
as
a
mpsc
osr
v6
location
can
be
advertised
based
on
assets
eisen
as
a
basic
intentions,
specific
link,
binaries
advertised
all
four
different
ratings.
Other
idt
attributes
may
also
be
advertised
in
topology,
specific
manner.
H
Since
this
document
was
adopted
last
year,
several
updates
have
been
made
for
the
comments
received.
We
clarified
that
both
results
aware
say
that
normal
state
can
be
used
with
this
mechanism
to
build
srbs
retains,
and
then
we
also
publish
the
text
about
the
forwarding
plane's
operations
in
the
we
describe.
The
scalability
considerations
and
the
target
network
scenarios
and
also
and
ethereum
chain,
has
also
been
made.
E
C
Yes,
ac
linum,
cisco
systems.
I
think
that
why
would
we
take
this
to
working
group
glass
call
when
the
drafts
it's
depended
on,
because
this
is
kind
of
an
after
the
fact
the
resource
aware
sids
and
the
tease
draft
aren't
in
working
group.
Last
call
I
mean
I
don't
know
why
we
jump
this
up,
just
because
it's
a
very
simple
draft,
when
those
aren't
when
when,
when
those
things
aren't,
aren't
done.
B
C
I
B
I
Yep
yeah
yeah.
I
just
like
to
say
that,
firstly,
this
is
a
informational
document
and
as
we
follow
the
suggestions
after
the
adoption
we
have
made,
the
resource
awareness
is
optional
for
this
document,
so
that
we
can
allow
both
resource
versus
and
normalcy's
to
to
be
used
within
this
mechanism
to
build
the
srbs
vtns.
C
I
I
B
A
A
B
J
J
I
J
It's
an
architect,
it's
an
architecture,
it's
more
architecture,
description
which
is
similar
to
this.
There
is
just
architecture
and
description,
just
informational,
you
can
just
roll
the
sections
in
into
that,
and
I
guess,
but
I
mean
I'll
leave
it
to
the
chairs
as
well,
but
just
a
second
yeah
I
mean
I
mean.
C
B
B
I
I
I
I
K
I
I
So
this
can,
with
this
mechanism
we
can
make
some
simplification
to
the
control
plane
and
the
data
plane
so
that
we
can
reuse
something
existed
already.
So
this
is
the
purpose
of
this
draft
and
I
think
that
the
draft
also
it
describes
the
scalability
itself.
So
maybe
you
can
also
check
the
content
of
the
draft
hope
I
can.
I
have
clarified
this
okay.
I
will
continue
with
this.
So
for
the
to
advertise,
the
t
attributes
of
each
median
alto
bundle
is
extended
a
bit
because
outer
bundle
can
be
used.
I
As
a
bundle
of
the
layer
2
physical
or
virtual
membranes,
and
here
each
of
the
member
link
can
be
associated
with
a
separate
region,
and
here
we
define
a
new
flag
called
exclusive
flag
and
to
indicate
whether
these
member
links
can
be
used
for
sharing
load,
balancing
or
the
age.
Member
link
is
used
exclusively
for
the
associated
media
and
for
the
correlation
between
a
flash
ago
and
the
layer
to
member
links.
I
This
is
based
on
the
extended
I
mean
group
or
color.
Basically,
each
length
member
link
are
configured
with
a
unique
color
which
is
used
as
an
include
rule
in
the
corresponding
fad
and
admin
group
of
the
parent
list.
Reading
is
set
to
the
union
of
all
the
colors
of
its
little
two
member
links
with
this
mechanism.
We
can
ensure
that
each
flash
algo
is
associated
with
the
parent
layer
link
and
the
forwarding
plane.
I
I
D
To
pick
up
china,
so
I
found
the
solution
that
you
are
proposing
rather
hacky,
by
trying
to
mess
up
with
the
affinities
of
the
l2
members
and
then
being
a
union
of
the
l3
member
and
all
that
stuff.
You
are
doing
this
for
a
very,
very
specific
case
where
you
have
l2
bundle
members.
This
is
not
a
generic
solution.
I
think-
and
I
believe
there
are
other
and
better
solutions
have
to
solve
this.
L
B
I
Yeah,
I
agree.
Maybe
maybe
one
solution
will
be
more
scalable,
but
this
two
solution
has
their
own
applicabilities,
such
as
like.
Even
if
we
have
defined
the
multi
topology,
we
still
have
the
flat
circle
defined
to
provide
some
similarity
similar
functionality.
That
is
why
we
propose
two
solutions:
one
based
on
mta,
one
based
on
flash
up,
because
both
are
adopted
mechanisms
in
the
working
group.
C
Yeah,
I
got
a
quick
one
gee.
I
think
that's
a
circular
circular
argument.
I
hope
you
know
what
that
is.
I'm
saying
we
have
to
because
we
want
to
have
two
and
let
people
use
it.
I
think
I
think
what
you're
the
reason
you
you
flex
algorithm
is
because
it's
less
data
plane
resource
and
that
should
say
that,
because
certainly
you
wouldn't
want
this
hacky
solution
with
flex
algo,
if
you
could
use
mt,
I
mean
mt,
is
just
so
much
simpler.
I
I
M
M
M
M
M
A
M
M
Type
22
tlvs
you've
got
a
seven
octets
of
system
id
and
pseudonode
number
and
there's
a
metric,
and
do
you
replicate
that
or
not
that's
discussed
to
be
discussed,
so
you
need
to
figure
out
what
the
key
is
and
we
need
to
agree
on
what
that
key
is.
So
all
implementations
concur,
but
we
are
trying
not
to
be
normative
about
discussing
the
key,
the
problem
with
being
normative
about
talking
about.
That
is
that,
then
we
become
a
catalog
of
every
tlv
and
we
don't
want
to
do
that.
M
J
M
So
the
intent
here
was
there's
a
concern
that
doing
multi-part
tlvs
could
cause
some
legacy.
Implementations
indigestion.
What
happens
if
you
see
two
tlv22s
and
you're,
not
quite
ready
for
it.
If
your
code
doesn't
do
that,
you
could
do
lots
of
different
things
in
the
extreme
situation
you
could
crash,
you
could
only
retain
the
first
part.
You
could
only
retain
the
second
part.
M
J
B
You
know.
Have
we
gone
through
and
and
said?
Well
this
this
is,
you
know
this
is
a
tlb,
that's
obviously
a
multi-part,
they
didn't
talk
about
it,
I
mean.
Would
it
especially
with
the
capability
thing
I
kind
of
like
it
feels
like
if
you
put
the
capability
thing
and
you
really
want
to
go
back
through
all
the
old
tlbs
and
say
here
are
the
keys
you
know,
or
this
doesn't
need
a
key
or
you
know
or
something
like
that.
M
B
E
E
I
think
we
should
wait
until
the
next
version
of
the
draft
is
out
if
the
capability
is
still
there.
We
will
also,
you
know,
be
addressing
you
know
some
of
the
net.
You
know
concerns
about
how
to
use
this.
Then
we
can
have
a
more
meaningful
discussion.
I'd
really
suggest
tabling
this
discussion
for
a
bit.
M
C
Easy
so
I'll
reiterate
my
comment
and
list.
If
you
in
your
discussions,
you
decide
that
you
won't
advertise.
If
not
everybody
advertises
the
capability
won't
advertise
the
multi-part.
You
have
to
specify
what
you
do
with
this
additional
information.
If
you
just
don't
advertise
it
or
how
you
choose,
there
has
to
be
some
statement
there.
B
J
Okay,
so
just
a
quick
follow
up
on
that.
How
does
how
does
how
do
routers
decide,
which
information
not
to
advertise
right
and
what,
if
router,
a
in
implementation,
a
decides
to
advertise,
tlb,
let's
say
10
and
the
other
router
decides
to
order
tlu-12
right,
then
I
mean
probably
nothing
will
work.
A
lot
of
stuff
will
get
broken
so.
J
J
J
N
N
M
N
M
M
N
E
B
B
M
B
O
O
All
right
now
in
rockstar
mode
good,
so
this
has
been
going
on
for
a
while.
You
can
see
there's
another.
You
know
flavor
of
this
flood
reduction
stuff.
It
does
a
little
bit
more,
the
shrut
on
it
white
and
me
please,
flip
on
I
joined
because
I
know
I
work
on
the
draft
now
for
a
little
bit
influence
it
next,
one,
please,
okay,
so
history
and
what
is
it?
The
next
steps?
Next
one
please.
O
So
the
history
for
a
few,
so
the
whole
idea
is
basically
based
on
work.
That's
been
done
before
and
money.
You
know
like
published
rfcs
the
five
series,
the
variant
of
that
is
actually
already
as
well
implemented.
You
know,
and
we
have
it
well
debugged
and
running
forward
with
it
in
rift.
So
in
a
sense
you
know
it's
nothing
earth
shattering
here.
We
just
took
it
forward,
so
new
modified
algorithm,
basically
based
on
the
mana
principle.
We
don't
do
not
need
any
kind
of
signaling.
You
know
or
protocol
extensions.
O
O
Why
it's
important
to
have-
and
you
know,
drafting
rfcs,
because
if
you
drop
people
doing
that
they
all
have
to
do
the
same
thing
right,
it's
kind
of
a
distributed
hashing
table
everybody
has
has
to
run
the
same
algorithm
completely
distributed.
Nothing
centralized
again,
no
signaling
right,
no
indication
that
stuff
is
even
running,
so
the
staff
is
kind
of
a
further
development
of
open
fabric,
which
was
the
stuff
that
came
out
of
linkedin
and
has
been
actually
implemented
in
fr,
but
that
used
kind
of
ling,
local
flooding.
It
was
early
version.
O
We
kind
of
you
know
tuned
that
stuff
further
and
we
do
also
something
above
which
is
not
only
flood
reduction
but
also
kind
of
distribution
of
the
flood
load
across
the
topology
and
not
only
just
following
a
single
tree
or
two
trees.
So
this
fr
has
this
early
implementation
and
now
there's
an
implementation,
but
an
unnamed
obvious
vendor
right
and
we
tested
it
works.
Well
I
mean
it's
not
deployed
yet,
but
you
know
we're
pretty
confident
we
have
numbers
and
so
on
next
one,
please
seven
minutes.
O
Okay,
so
I'll
go
in
one
ugly
picture,
a
bunch
of
cars.
I
hope
you
can
follow
me
so
at
the
very
bottom.
Is
the
originator
of
the
lsp
right,
so
somebody
originates
it
and
obviously
the
first
hop
you
have
to
flood
it
to
everyone,
there's
nothing
to
be
done
and
then
in
the
middle.
If
you
read
it
on
the
left,
a
transmitting
neighbor.
This
is
the
note
that
sends
you,
the
lsp
right
and
the
black
guy.
O
O
So
you
have
to
compute
that
from
the
view
of
the
transmitting
neighbor,
and
then
you
compute,
basically
two
things
and
some
colors
something
has
been
cut
off,
so
you
compute
this
yellow
front,
which
are
all
the
intermediate
immediate
neighbors
of
the
transmitting
neighbor
right.
So
that
kind
of
gives
you
like
the
one
hope
thing
and
from
there
on
right
and
you
there
is
a
lot
of
optimization.
O
I'm
a
meeting
you
know
like
you
can
kick
out
all
these
guys
that
are
on
the
shortest
path
through
the
originator,
because
you
know
that
that's
all
the
propagation
front
and
then
you
compute
the
two
hop
neighbors
the
thl.
So
from
this
point
of
view
of
this
first
hop
neighbors,
you
take
the
next
after
those
right.
So
this
is
impressive.
Basically
his
view
of
the
propagation
front
and
you're
just
somewhere
in
it
right.
O
He
propagates
through
its
intermediate
neighbors
into
two
hop
neighbors
and
you
somewhere
in
here,
and
you
have
to
know
whether
you
are
one
of
these
guys
that
is
responsible
to
cover
the
two
hop
neighbors
right.
So
so
the
logic
is
until
you
make
this
mental
step
that
you're
really
computing.
On
behalf
the
guy
transmitting
towards
you,
you'll,
not
understand
the
moment.
O
If
you're,
one
of
those
you
have
to
retransmit,
then
if
you're,
not
you
just
shut
up,
because
you
know
that
other
people
already
covered
the
two
hop
neighbors
all
right
and
the
rest
is
just
mechanics
and
there's
a
lot
of
optimization
like
if
you
know
that
the
two
hope
neighbor
is
actually
only
one
hop
away
from
the
originator,
can
cut
it
out
and
so
on
and
so
on.
But
that
is
pretty
much
the
whole
thing.
So
for
people
who
are
less
visual
oriented,
you
know
and
can
follow
my
you
know
da
vinci
quality
picture.
O
You
know
early
da
vinci
next
one
I
give
you
the
stuff,
you
know
for
the
algorithmic
thing,
so
you
co,
you
assume
all
metrics
run
on
the
graph
overload
is
of
course
ignored
because
your
flat
on
overload,
then
you
build
the
shortest
path
tree
from
the
origin
or
to
the
transmitting
node
right.
And
then
you
build
the
rnl
d
agents.
This
one
hop
into
hop
from
the
view
of
transmitting
the
airports
towards
you.
O
Different
people
are
picked
from
the
first
hop
to
propagate,
to
the
second
hop
all
right.
That
is
subtle
this
year,
I
completely
admit,
but
that
basically
gives
you
a
flat
balancing
across
the
graph.
So
it's
not
like
a
single
tree
where
everything
goes
you
know
through.
It
is
depending
on
which
lsps
are
flooded.
They
will
pick
up
kind
of
different
trees.
O
You
can
imagine
it's
a
simplified
picture,
but
it,
but
it's
sufficient,
so
you
reduce
the
volume
by
what
we
find
is
about
70
percent,
but
not
by
choking
on
you
know
a
bunch
of
links,
the
whole
flooding,
but
basically
balancing
us
across
the
whole
graph
and
for
people
who
say
well.
This
is
like
way
too
much
computation
under
stable
topology.
O
You
know
you
compute
only
on
demand
right.
These
things,
depending
from
whom
you
see
the
lsps
which
lsps
you
see
and
you
can
cache
all
these
results
stable
because
they
only
depend
on
the
topology
and
on
the
originator
on
the
lsp
id
right,
no
sequence
number
nothing.
So
once
you
kind
of
cache
these
things
out,
stuff
doesn't
need
any
computation,
and
the
experience
from
the
implementation
is
actually
the
load
to
compute
those
things
directly
relative
in
your
school
okay.
Well,
yeah
I
mean
I
had
my
concern.
So
read
the
draft.
O
There's
a
lot
of
consideration
there.
You
know
the
lsp
id
and
so
on
and
so
on
right,
so
you
don't
do
it
per
lsp
id
you
do
it
on
some
hashing
functions.
The
very
you
know
you
you
been
bucket,
those
guys
and
so
on.
But
that's
you
know,
rita
draft
contribute
have
an
opinion.
I
mean
I
don't
want
to
swap
you.
You
know
swamp
you
with
this
stuff
next
one.
O
So
what
happens
if
the
whole
thing
partitions
right,
like
things
are
great
when
things
are
great
when
something
breaks
and
somebody
forgets
to
send
something
so
the
way
we
fix
it
is
that
we
keep
the
list
of
whom
did
we
omit
doing
all
these
optimizations
right
and
we
run
some
small
timers
and
don't
forget
psnp,
so
you
know
it's
very
dense
package.
You
can
describe
a
couple
of
these
lsps
just
by
their
signature
and
basically
periodically.
So
if
these
guys
go
to
stuff,
they
will
all
deter
some
other
way.
O
They
may
possibly
tell
you,
oh
you
know,
do
you
have
this
thing
and
you
already
have
it
right?
So
you
add
kids,
a
lot
of
this
stuff
cancels
out
already,
but
if
these
guys
didn't
update
you
yet
that
they
have
it,
you
basically
bucket
those
things
and
you
throw
it
at
them
and
go
like
here's
the
version.
If
they
have
it,
nothing
happens,
you
get
ack
minimal
or
otherwise
they
will
request
it
and
repair
the
graph
right.
O
So
things
go:
pear
shaped
apple
apple-shaped,
whatever
you
will
have
some
small
hiccup
right
until
the
timer
catches,
up
and
kind
of
you
know
puts
the
stuff
through
what
is
not
really
the
the
mean,
the
minimal
graft
that
you
computed
and
then
hopefully
you
know
the
whole
thing
settles
again
and
and
and
chucks
happily,
and
this
does
not
change
any
of
this
psnp,
you
know
sent
or
received
procedures
right.
You
don't
need
to.
O
We
operate
just
on
the
standard,
psnp
stuff.
We
just
play
this
little
trick
that
we
only
send
them
or
you
know
where
we
know
we
didn't
send
stuff
to
make
sure
that
the
guy
has
it
in
case
he
didn't
set
us
yet
the
psnp
or
csnps
or
whatever.
Next
one,
oh
yeah,
I'm
also.
This
is
the
last
one.
Next
one
I'm
still
five
minutes
man.
What
will
I
do
sing
a
song?
I
don't
know.
O
Oh
thanks
yeah,
so
I
won't
sing
the
song.
Nobody
got
properly
scared
when
I
said
that,
but
it's
okay.
So
right,
please
look
at
the
stuff.
Embarrassingly
simple
osp
version
would
be
valuable.
You
know
fairly
obvious.
I
mean
all
the
same
mechanism
and
schwarz
jumped
to
shark
a
little
bit
here.
Put
the
work
group
adoption
on
it
but
yeah.
You
know
stuff's
straightforward.
O
If
you
think
through
it
took
us
after
a
couple
of
round
optimization.
I
influenced
the
draft
not
another
another,
but
the
stuff
is
largely
in
place.
It's
implemented
it
kind
of
works
and
important
to
say
this
works
for
arbitrary
topologies.
Obviously
this
is
not
any.
You
know,
club,
optimization
or
anything
like
that.
C
This
I
like
this
version
in
order
to
order
a
magnitude
better
than
the
original
version.
I
like
this
version
that
it
does
and,
and
it
is
close
to
the
you
know-
I
mean
it's
it's
different,
but
it
has
a
lot
of
the
same
using
the
two
hop
neighbors
and
covering
all
the
two
hop
neighbors
and
doing
that
dynamically
is
a
lot
like
the
draft.
You
mentioned
the
cds
that
richard
algiere
did
for
monet.
It's
really
it's
really
good.
The
one
question
I
had
is
you
know
all
those
other
ones.
O
O
Well,
not
really
like
a
hash
of
it,
so
you
don't
have
too
many
buckets.
You
start
somewhere
in
the
middle
or
you
know
whatever
for
every
lsp,
so
you
use
different
guys
and
while
you're
taking
these
guys
off
the
list
in
a
sense
you
are
looking
which
of
the
two
hope
neighbors
does
this
guy
cover
and
the
moment
you
have
full
coverage
of
the
two
hope
neighbors
you
go
like
okay,
I'm
done
right.
Those
are
all
the
guys
that
are
really
re-flooding.
O
Now
right,
nothing
prevents
you
and
every
node
can
do
it
differently
to
from
generating
a
double
coverage.
You
go
like
I'm
taking
these
neighbors
off
the
list
and
I'm
counting
the
two
hope
neighbors
whether
they
have
been
covered
twice.
That's
what
rift
does
and
all
three
times
so
whatever
it
can
be.
A
local
configuration
right
and
each
guy
can
actually
do
it
independently.
Some
guys
can
cover
once
some
guys
can
cover
twice.
It
does
not
really
matter,
it
will
just
generate
additional
copies.
O
O
I
didn't
think
through
that.
Well,
don't
forget
that
you
load
balance
right,
so
an
lsp
will
go
to
a
if
you
did
not
reflot
this
specific
lsp,
then
you
say
like
okay,
all
the
two
hope
neighbors.
I
didn't
reflect
this
lsp.
I
have
to
psnp
them,
but
don't
forget
it
balancing
always
on
lsps,
so
you
will
omit
some
fraction
of
the
flooding
and
that
will
be
used
to
generate
this
psnp
saying
you
know.
I
omitted
this
lsp
to
you
guys,
so
it
is
a
fraction.
O
C
C
O
B
L
Hi
ben
madison
work
online,
a
couple
of
questions
and
my
apologies.
If
these
are
in
the
draft,
I
haven't
read
it.
The
first
is,
it
seems
like
there
are
topologies
where
running
this
algorithm
would
save
you
more
work
than
others,
and
there
are
probably
you
know,
probably
the
more
regular,
the
topology,
the
more
work
you
save
and
in
a
lot
of
service
providers,
the
network
I
run,
I
I'd.
Imagine
you
probably
don't
save
a
lot
of
work
by
doing
all
of
the
extra
computational
work.
O
Look
at
the
average
fan
out
on
your
network,
the
higher
the
fanout,
the
more
you
save,
that's
pretty
much
the
output
you
know,
so
the
claw,
of
course,
will
save
a
lot.
If
you
have
a
very
sparse
network,
there
are
very
few
flooding
paths
and
like
what
the
hell
do
you
want
to
cut
out
right
most
most.
The
generate
case
is
something
which
is
you
know,
hamiltonian
path
or
you
know,
minimal
cut.
You
know
I
was
like
yeah
there's
one
way
to
flood
it.
So
what
do
we
optimize.
L
O
O
And
as
to
the
computation,
we
were
concerned,
but
don't
forget
you
only
compute
when
the
stuff
hits
you
the
first
time
on
demand,
so
you
of
course
you
have
the
spanning
tree
of
the
originator
right
and
then,
when
it
hits
you
with
lspid
with
fits
in
a
bucket
new
bucket,
then
yeah.
You
have
to
recompute
those
lists,
but
that's
why
I
put
it
in
the
draft
and
you
take
the
lspid
and
you
run
a
very
strong
hash.
So
from
the
same
originator,
you
will
only
build
maybe
two
buckets
right.
O
So
the
same
originator
will
kind
of
use
two
trees.
Maybe
double
coverage
yeah
right
and
if
you
have
a
million
origin
in
the
network
yeah
I
wish
isis
right.
I
mean
you
were
bound
by
relatively
few
nodes.
So
you
know
worst
case
like
go
wild
and
say:
okay,
I
have
whatever
5k
notes
and
times
2
for
the
lspid
buckets.
You
have
10k
of
those
things
to
pre-compute
and
they're,
relatively
small
they're
like
minimalist
right
and
once
they're
in
place
they're
in
place.
If
you.
L
Yeah,
I
I
operate
a
network
in
a
part
of
the
world
where
the
sparsest
parts
of
the
network
tend
to
be
the
most
unstable,
so
I
I'm
I
would
be
hesitant
to
without
quite
a
good
reason,
introducing
more
computation
work
to
places
in
the
network
that
already
have
transient
like
moments
of
hell
of
a
lot
of
work
to
do.
But
I
I
think,
you've
answered
my
question.
O
C
L
O
E
O
A
O
O
E
Yeah
I'll
take
a
closer
look.
The
second
quick
comment
is
you
use
the
term
up-to-date
psnps,
as
as
your
remediation
mechanism,
I
have
no
idea
how
you
would
how
you
would
determine
that
a
psnp
is
quote
unquote
up
to
date
because,
unlike
a
csnp,
a
psmp
doesn't
have
a
range
in
it.
So
you
can't
tell
that
oh
yeah,
this
covers
everything
between
you
know
system
id
x.
Although.
O
D
E
A
O
Yeah,
you
can't,
you
can't
know
what
you
don't
know,
but
we
don't
have
this
problem.
You
know
I
I
was
thinking
about
what
you
call
it
whatever
you
know
the
distributed
system
stuff
right.
No,
I
thought
through
this
stuff.
We
don't
have
this
problem.
Unless
you
convince
me
we
do,
then
it
will
become
interesting.
Yeah,
okay,
okay,.
B
O
C
B
D
So
the
problem
statement-
the
summarization-
is
a
reality.
People
do
summarize,
unlike
with
mpls
networks,
where
it
was
hard
to
do
due
to
the
requirements
of
the
n2
and
lsp
with
other
technologies.
These
days,
summarization
is
possible,
networks
are
growing,
the
number
of
routers
is
growing
significantly
and
summarization
helps,
I
think,
that's
the
fact
arguing
about
it
doesn't
make
much
sense.
In
my
opinion,
obviously,
summarization
is
not
only
good,
it
create
problems,
and
one
of
the
problems
is
that
it
hides
information.
It
hides
the
reachability
of
the
individual,
routers
or
prefixes.
D
So
the
problem
that
we
are
trying
to
solve
here
is
to
be
able
to
summarize
and
still
be
able
to
signal
that
something
has
been
lost
and
that
can
be
used
by
various
applications.
Here
we
are
mainly
talking
bgp
peak,
but
it
can
be
used
by
any
other.
You
know
applications
what
this
draft
talks
about
is.
It
gives
a
backward
compatibility
solution
without
any
need
to
extend
the
protocols,
so
it
only
only
defines
why
we
are
doing
it
basically
next
slide,
please.
D
So
if
you
look
at
the
rfc,
5305
and
5308,
it
basically
gives
you
a
way
to
advertise
a
prefix
as
an
unreachable
prefix.
There
is
a
range
of
metrics
that
if
you
advertise
the
tlb
with
that
metric
it
basically
the
rfc
says
this
prefix
is
unreachable
from
the
traditional
computation.
You
can
use
this
for
other
purposes.
That's
the
language
that
the
rfc
is
using
and
all
we
do.
We
are
defining
a
new
purpose
here.
Next
slide,
please!
D
So
what
will?
And
how
will
this
work,
the
existing
nodes
which
will
receive
this
will,
just
you
know,
flood
this
propagate,
but
don't
use
it.
That's
the
behavior
that
the
current
specs
are
mandating
the
recognition
of
this
advertisement
and
the
usage
is
only
needed
on
the
nodes
that
want
to
use
this
information.
So
typically,
this
would
be
the
pes
if
they
are
interested.
They
can
be
configured
to
use
this
information
and
pass
it
to
whatever
applications
may
be
interested
in
it.
D
The
l1
l2
routers.
They
would
not
propagate
this
today.
So
that's
the
change
in
the
behavior
of
the
protocol.
That
probably,
is
the
good
reason
why
this
trap
exists.
In
the
first
place
is
because
we
need
to
propagate
this
information
between
the
area,
so
if
an
l1l2
router
attached
to
area
x
advertises
this
up
advertisement,
it
goes
across
the
l2
and
another
l1
l2
router,
which
attaches
to
area
y,
may
need
to
leak
this
information
down.
D
D
D
So
you
can
either
flash
the
lsa
or
you
can
advertise
it
with
this
metric.
It
has
the
same
meaning.
Basically,
it's
unreachable
next
slide,
please
and
then
again.
Similarly
to
what
has
been
said
for
isis,
the
nodes
will
propagate
this
data.
It
will
not
use
or
install
these
prefixes
because
it
they
are
unreachable
if
they
follow
the
spec.
D
So
couple
of
implementation
or
recommendations
that
are
worth
mentioning
is
obviously
we
don't
want
to
advertise
tons
of
these.
If
there
is
a
catastrophic
failure,
an
abr
or
an
n1
l2
router
loses
connectivity
to
everything
doesn't
make
sense
to
advertise
all
the
specific
prefixes
as
a
as
an
unreachable,
so
there
should
be
a
bound.
D
The
the
use
case
for
this
is
when
a
pe
fails
when
not
when
the
area
partitions
or
some
catastrophic
failure
happens,
and
we
don't
need
to
keep
this
advertisement
for
a
long
time.
We
need
this
advertisement
basically
for
time
needed
to
propagate
them
and
plus
some
buffer,
obviously,
and
then
we
can
basically,
we
throw
them
at
the
source.
D
O
It's
a
courtesy
draft.
I
mean
it's
completely
valid
standard
protocol
behavior.
You
know
that
you
kind
of
use
for
other
purposes,
I'm
not
overly
concerned,
because
if
you
pull
up
all
the
abrs,
even
if
the
router
is
in
the
middle,
the
crazy
stuff
and
forward
I
mean
you-
will
kill
the
stuff
on
the
abr
right,
because
the
style
you
know
that
stuff
is
unreachable,
so
yeah.
If
we
want
to
do
it
this
way,
you
know
it's
a
list
of
all
possible
evils
to
abuse.
The
protocol.
Do
this
to
do
this
kind
of
stuff
thanks.
B
O
O
D
O
G
D
I
believe
we
can
safely
use
ls
infinity
to
indicate
this.
If
you
read
the
specification
very,
very
you
know
thoroughly,
you
will
realize
we
can
do
that
in
terms
of
adding
a
very
specific
or
you
know
explicit
signaling
for
unreachability.
On
top
of
this,
I
still
haven't
heard
any
technical
argument
that
would
convince
me
beneath
I
know
couple
of
poor
few
people
have
suggested
that
if
they
come
up
with
the
feasible
technical
argument,
I'm
all
for
it-
I
haven't
heard
any
so
far.
D
G
I
Hello
yeah.
Actually
I
send
the
mail
to
the
list.
I
also
read
the
similar
comments
as
itunes
because
reading
the
rfcs
it
shows
that
this
rs
infinity
metric
is
just
to
ask
the
receiver
now
to
install
this
prefix
on
you
not
to
consider
this
prefix
in
the
computation
and
now
to
remove
it
from
another
prefix
which
may
cover
this
prefix
right.
This
is
so.
This
is
a
new
behavior.
Comparing
to
the
previous
statement
in
rc.
D
And
for
ipflex
algo,
what
we
defined,
if
I
recall
correctly,
is
that
we
advertise
the
the
base
tlv
within
infinity
metric
and
include
the
metric
of
the
flex
algo
inside.
So
obviously
the
metric
for
the
base,
algo
or
algozio
in
this
advertisement
is
never
used,
so
it
cannot
be
interpreted
as
unreachable.
It's
just
the
field
that
we
put
there,
because
we
are
not
advertising
algo0
in
that
base
tlv,
so
that
metric
is
always
ignored
and
it
obviously
has
no
relation
to
algo0.
A
B
C
Completely
with
peter
this
and
the
beauty
of
this
is
we
use
the
same
mechanism
used
for
backward
compatibility
for
the
signaling
now,
obviously,
only
the
routers
that
support
the
specification
will
act
on
the
event
notification,
but
I
mean
that
would
be
it
no
matter
how
you
solve
this
problem.
That
would
be
the
case.
So
it's
the
two,
the
two
usages
don't
are
are
complementary.
A
B
D
B
D
B
D
B
G
A
G
A
G
How
to
so
here
is
a
history
of
the
proper,
the
solution
we
probe.
We
propose
first
and
20
20
19
october,
in
in
singapore,
in
idea
for
106
and
also
after
several
several
item
meetings,
and
we
also
discussed
the
the
solution
intensely
on
the
lsr
list,
and
previously
we
focused
on
both
on
the
control
plane
and
the
data
plane,
convergence
and
after
discussion.
G
We
we
converted
to
the
focus
on
the
controversy
switchover
and
we
also
discussed
the
intensely
for
the
use
case
of
the
such
information,
and
I
think
kindly
we
all
and
will
understand.
There
are
several
several
use
cases
need
such
useful
information
and
online
discussion.
There
are
also
other
alternative
solution,
for
example,
btp-based,
pulse
and
nlp,
and
the
upa
just
is
introduced
by
peter,
and
we
we
think
the
solution
on
converging
for
the
pure
and
the
ups
solution.
Now.
G
G
So
we
think
the
pfd
based
solution
and
the
other
to
also-
and
it's
not
as
recent
for
the
for
the
problem,
so
we
think
the
it-based
solution
may
be
more
suitable
and
the
root
cause
of
the
proper
solution
is
the
following,
and
that
is
the
samurais
advertisement
hide
the
unnecessary
unreachable
eligibility
of
its
current
prefix,
but
the
service
that,
based
on
the
detailed
precipitate
the
prefix
near
to
now
the
invisibility
of
this
prefix
to
to
switch
over
promptly
to
other
alternative
endpoint.
This
is
the
root
cause
of
the
propelled
solution
and
for
resolution.
G
We
need
to
also
confine
the
negative
advertisement
to
avoid
in
the
igp
flooding
tour.
So
I
think
many
person
may
worry
about
the
side
effect
of
the
such
a
notification,
so
any
any
applications
to
the
so
consider
this
this
carefully
and
the
we
updated.
The
our
solution
is
the
the
the.
The
message
will
must
declare
the
explicitly
the
associative.
Prefix
is
unreachable,
with
its
prefix
original
certain
law
and
the
order
to
avoid
the
avoided
the
traditional
router
or
unsupported
misbehavior.
G
G
If,
if
the
method
is
of
the
lsa,
is
ls
infinity
and
then
the
spf
for
calculation
will
bypass,
the
bypass
will
bypass
the
such
lsa,
so
the
unsupported
node
will
not
misbehave
so,
and
we
also
define
the
capability
bit
for
the
negotiation
of
the
static
ability.
So
if
all
nodes
support
the
pa
capability,
the
ls
infinity
is
unnecessary.
G
G
So
the
abr
account
which
the
prefix
should
advertise
the
one
specific
route
to
the
to
the
mission,
the
prefix.
So
this
advertisement
will
let
the
traffic
divert
to
the
api
that
can
reach
the
prefix,
and
we
also
mentioned
the
switch
over
service.
Switchover
must
take
place
only
while
all
the
adr
advertises
the
same
message.
G
We
also
make
some
update
for
the
implementation
consideration.
You
know.
As
I
have
mentioned
the
papers.
We
must
control
the
advertisement
of
such
message
within
the
area,
so
we
define
the
maxim
maxi
maxi
address
announcement
shareholder
to
control
the
advertisement
of
the
pua
and
the
similar
tests.
G
So
if
the
number
of
the
unreachable
prefix
is
less
than
maa,
then
adr
can
should
advertise
the
summaries
and
the
poi.
If
reachable
odds
is
less
than
ma.
The
abr
should
advertise
the
detailed
reach
about
this.
Only
and
if
both
of
the
rich
band
unreachable,
prefix
exit
the
ma,
then
the
and
the
abr
should
advertise
the
ma,
unreachable,
prefix
and
also
set
the
same
address
with
max
metrics
and
at
that
time.
At
the
same
time,
the
vr's
avr
should
notify
the
operator
that
there
are
several
isn't
occur
within
the
network.
G
And
so
I
think
this
stuff
that
has
been
discussed
discussed
about
two
years
in
the
meeting
on
the
main
list,
so
I
think
countries
there
are
enough
enough
experts
in
switched
this
topic,
so
we
think
it
is
time
to
move
forward
this
document
and
we
are
glad
to
cooperate
with
peter
to
to
make
the
make
the
overall
overall
solution
to
solve
this
problem,
and
we
are
also
welcome
either
closer
to
this,
this
loss
and
the
document.
Okay,
that's
all.
B
Okay,
so
me
and
the
queue
as
a
working
group
member
or
not,
I'm
sorry
back
that
up
as
a
chair
some
of
the
comments
I
read
on
the
list
and
maybe
a
little
bit
of
the
feeling
in
a
couple
of
these
slides,
it's
been
worked
on
for
a
long
time.
Yes,
because
you
know
there
hasn't
been
consensus
and
there
was
a
particular
comment
I
saw
that
said.
G
D
B
So
I
mean
you,
you
definitely
we're
there
early
on
with
this
right
that,
and
that
is
something
that
should
not
go
unnoticed,
but
that
doesn't
yeah
that,
doesn't
you
know,
favor
your
solution
over
a
different
solution.
Just
because
you,
you
know,
you
recognize
the
problem
first.
So
that
was
that's
a
chair
comment.
I
I
guess
this
is
also
you
know
the.
So
it's
good
that
you
want
to
work
with
other
people,
and
I
don't
know
if
again,
if
just
because
you
started,
I
don't
know.
B
G
B
G
G
You
know,
but
this
is,
as
I
saw,
this
is
just
a
part
of
the
solution
and
we,
our
solution,
also
cover
other,
and
you
know
this.
This
is
the
point-
are
discussed
within
the
maintenance
intensity.
So
we
hope
that
the
traffic
to
include
them-
I
think
the
this
is.
This
is
the
main
reason
that
we
want
to
four.
This
is
solution.
Okay,.
B
D
I
don't
understand
why
you
are
still
having
that
in
your
draft
and
the
second
comment
I'm
going
to
make
when
we
started
the
draft.
I
invited
you-
and
I
acknowledge
that
you
came
up
with
the
problems,
but
you
know
with
the
problem
space
as
a
first,
I
invited
you
to
join
the
upa
draft,
what
you
did.
Instead,
you
took
and
put
the
unreachability
metric
to
your
draft
and
still
keeping
your
source
or
originator
zero
there.
G
Yeah
yeah,
the
the
we.
We
also
studied
the
possibility
to
use
the
newly
defined
flag
to
indicate
the
eligible
information,
and
I
I
also
point
out
in
the
main
list
that
for
ospf
of
h3
there
are
limited
space
to
to
use
to
use
in
the
flag.
If
we
rely
on
the
flag,
we
must
extend
the
ospf
v3
flag
first
and
then
define
the
define
the
one
bit
to
single
the
eligibility
you
know.
So,
if.
G
D
All
you
need
is
to
signal
unreachability.
You
need
a
mechanism
to
that.
You
put
the
unreachable
metric.
You
still
want
some
explicit
one.
The
question
whether
we
need
an
explicit
one
or
not
is
something
that
we
need
to
decide
as
a
working
group.
If
we
are
going
to
decide,
we
want
to
find
another
one,
not
the
one
that
you
use
for
sure.
I'm
still
not
convinced
we
need
it,
but
let's
keep
that
as
a
as
an
option.
But
then
what
is
left
in
your
draft
right?
D
G
G
G
C
I'm
just
going
to
break
in
because
it
seems
to
be
a
circular
discussion
here
back
and
forth.
Let's
take
the
the
point
of
whether
or
not
explicit
is
needed.
I
just
wanted
to
point
out
that
our
agent
said
something
wrong
about
ospf
v3.
If
you're
you
weren't,
we
wouldn't
use
the
lsa
options
anyway.
We'd
use
some
other
flags
and
there
are
other
flags
that
are
extendable
anyway.
B
G
So
here
I
want
to
describe
why
we
want
to
what
is
the
proper
one
to
solve.
You
know
here.
I
just
describe
a
swiss
scenario
at
the
way
when
we
are
in
we
are
encountered
in
our
network.
The
first
is
the
interest
interest
connections.
You
know
in
such
scenario,
the
sdr
will
build
the
pgp
session
with
your
low
back
of
this,
and
there
are.
There
are
several
interest
link
competition
ram,
so
we
want
to
recover
the
interest
topology
within
the
the
2s.
G
The
second
scenario
is
for
the
internet
exchange
center.
You
know
there
are
maybe
maybe
several
ways
connect
within
by
the
line
interface
and
we
want
to
also
discover
the
cover
the
interconnect
topology
within
them.
The
third
scenario
is
for
the
any
cost,
any
customer
service.
Now
you
know
some
several
servers
with
the
same
address
may
be
connected
in
the
different
network.
While
the
stop
links.
G
So
we
want
to
define
one
container
to
transfer
the
characteristic
of
the
stop
links
in
about
snails
and
to
solve
the
2090
interest
topology
cover,
for
example,
in
the
ptas,
and
the
oman
is,
and
also
we
want
to
do
some
traffic
engineering
to
different
servers
based
on
the
stubbling
characteristics
and
at
the
main
list
point
out.
The
robot,
and
there
are
also
other
other
scenarios
that
may
help
make
it
can
use
such
information
to
select
the
best
bgb
pgp
next
hub.
G
G
I'll
pick
as
as
a
comment
from
the
from
captain,
we
will
we
may
change
the
container
for
for
for
this
newly
defined
tlv
to
more
general
lsa,
and
here
we
want
to
point
out
clearly
that
the
prefix
of
trv
is
not
the
identifier
of
the
stub
link.
It
is
just
one
kind
of
the
sub
link
attribute
same
as
other
already
defined
stably
already
defined
sub
sub
tlv
for
the
link
attribute.
G
G
G
The
first
is
not
efficient
for
every
interest,
stub
link
to
include
the
redundant
information,
and
it
is
not
possible
to
describe
the
line
establishing
is
and
for
the
for
any
cast
server
scenario
we
need.
We
need
some
logical
information
to
describe
the
stub
link
between
s
and
the
edge
server
and
also
point
out
by
academy
in
the
main
list,
such
as
unnecessary
information
will
be
populated
and
unnecessary.
G
So
I
think
this
is
overlook
our
solution
for
the
problem
and
also
this
solution
helped
pm
what
making
working
adoption
for
the
first
time
under
there.
I
think
the
update
contend
has
addressed
the
comment
for
gillian
from
the
first
adoption
call
and
if
there
is
no
other
no
other
comment
occasion,
we
can
we
ask
to
the
working
group
to
fold
it
again.
Okay,.
E
B
B
B
B
I
even
asked
you
know,
please
you
know
be
very
mindful
before
you
bring
this
draft
back.
You
know
the
working
group
had
given
you
an
answer
and
the
rough
consensus
was
not
to
adopt
and
you
know,
then
we
had
more
mailing,
you
put
out
new
versions
and
we
had
more
mailing
lists
and
you
still
hadn't
convinced
people.
We
still
don't
have
rough
consensus
and
we're
still
spending
working
group
resources
on
it.
G
Yeah
correctly,
listen
chris,
I
think
I
want
to
explain
you
know
the
the
the
failure
of
the
first
topic
is
that
there
are
some
technical
problem
needs
to
solve,
and
it's
not
not
not
because
it
is
unnecessary.
So
I
think
the
reason
we
want
to
adopt
someone
properly,
that
it
can
be
used
in
the
network,
and
I
I
think
it
is
common
commons
so
now
that
some
working
some
document
be
adopted
several
times
based
on
the
command
from
the
from
the
adoption
code
process.
G
H
B
Yeah,
I
think
that
I
think
we
need
to
consider
letting
this
one
go,
because
it's
there
are
it's
like
you're
trying
to
come
up
with
a
better
solution.
That
is,
you
know,
prettier
or
something,
and
you
know
I
appreciate
that,
but,
like
you
keep
talking
about
here,
there's
a
way
to
do
it
this
way
and
there's
a
way
to
solve
this
other
problem.
This
way,
in
other
words,
solutions
exist
right
and
you
you're
trying
to
make
a
better,
cleaner
solution,
but
people
aren't
biting
right.
They
don't
they
don't
think
it's
worth
doing.