►
From YouTube: IETF94-ISIS-20151105-1300.webm
Description
ISIS meeting session at IETF94
2015/11/05 1300
A
B
A
C
A
A
A
A
B
B
B
And
ok,
no
Jabbar
starve
again
all
right.
This
is
the
note
well
by
participating
with
the
IETF.
You
agree
to
the
following:
IETF
process
and
policies.
If
you're
aware
that
any
contributions,
something
written
said
or
discussed
in
any
IETF
context,
is
covered
by
patents
or
patent
application,
you
must
disclose
that
back
or
not
participate
in
the
discussion.
You
understand
the
meetings
might
be
recorded
at
broadcast
audio
or
video
photograph
and
publicly
archived
and
there's
some
BCPs.
You
can
go
look
at
I.
B
Ok,
ok,
no
changes
moving
right
along,
so
this
is
a
document
status
update.
These
are
the
working
group
docks
that
are
in
flight
that
we've
got
to
that
have
cleared
a
last
call
they've
been
sitting
here,
a
while
they're
also
blocking
things,
and
they
will
be
submitted
very
soon.
They're
Inanna's
q
I'll
take
them
over
next
week,
I
PR
polling,
so
these
two
have
write-ups
done
the
noted,
min
and
prefix
attributes.
D
So
just
RFC
6822,
which
is
the
DMI.
There
are
a
few
errata
that
have
been
filed.
We're
going
to
respond
to
those
there's,
also
a
possibility,
based
on
some
discussions
outside
that
in
the
process
of
doing
abyss,
to
address
the
arata.
That
will
consider
some
extensions
that
might
not
be
backwards
compatible.
So
I
would
really
like
to
know
who
has
an
mi
implementation,
so
we
can
determine
whether
we're
going
to
have
a
negative
impact
on
interoperability.
D
B
Yep
I
would
prefer
public
just
because
it
might
affect
whether
we
take
on
the
changes.
One
of
the
changes
we're
looking
at
is
possibly
key.
Changes
in
the
mi
mean
that
there
would
be
some
big
changes.
So
if
people
are
aware
of
implementations,
if
they're
aware
of
deployments,
this
would
be
in
peaceful
information
for
for
what
kind
of
changes
we
might
take
on
so
moving
right
along.
B
These
are
the
updated
ID
since
the
last
I
EF
and
again
the
bold
will
be
presented
today.
There
was
a
call
by
David
I
leave
on
the
source,
deaths
routing
a
call
for
adoption
on
the
list.
I
guess
it's
probably
too
bad.
We
didn't
have
a
presentation
on
that,
but
this
is
some
interesting
stuff
discuss
discussions.
It
seems
like
it's
becoming
a
little
bit
more
solid,
no
look
alley
up,
but
you're
looking
at
me.
Strangely
sorry.
E
Alice
I'm
not
I,
think
it's
a
little
pretty
much
ready
to
have
some
discussions
to
understand
what
should
have
the
possible
solutions
to
the
general
problem
and
so
I
think
it's
really
good
to
have
people
look
at
the
source,
just
crowding
and
understand
and
think
about
the
implications
and
so
on.
It's
not
clear
that
it
solves
all
of
the
problem
that
is
related.
That's
all.
F
E
Would
never
presume
to
judge
what
unbe,
six
ops
and
I
totally
heard
the
consensus
opinion
on
the
email,
which
was
not
that
we
should
routing,
should
then
rush
and
go
to
source
desk
routing,
though
it
that,
but
rather
this
is
a
problem.
This
is
stopping
v6
deployment
and
I,
hear
that
and
v6
Ops
is
are
the
people
who
know
that,
and
so
I
hear
loud
and
clear
that
message
and
I
think
and
I'm.
E
Looking
on
learning
more
in
formulating
more
of
a
good
opinion,
source
test
routing
may
be
part
of
the
solution,
but
I
think
we
need
to
understand
fully
the
parameters
of
the
problem.
That
said,
I
think
it's
really
valuable
on
the
really
really
pleased
valuable
side
of
things
for
people
in
this
working
group
to
go
off
and
look
at
source
testing
and
to
think
about
the
implications
of
it
when
it's
targeted
towards
the
smaller
larger
enterprise.
That's
doing
PA
addressing
so.
B
Can
I
ask
you
a
question
David
before
you
leave
the
this
also
has
a
companion
draft
in
the
routing
working
group.
Is
that
crack
and
I
would
sort
of
expect
the
ice
ice
12
trail
that
one,
if,
if
not
by
a
lot
but
I
mean
so,
did
you
or
did
that
already
meet
that?
No
that's
today,
that's
after
this
one.
So.
B
That
was
the
question,
so
you
have
adopted
yes,
whatever
docked
at
it
and
that's
not
interests
and
there's
problem.
We
recognize
her
definitely
to
work
on
it
right.
So
if
that's
working
group
item
a
document
it
you
can't
really
do
much
without
the
I
GPS
right,
you
never
can
do
it
right,
so
so
that
so
that
so
that's
sort
of
an
interesting
question,
then
right
we
have
it,
as
the
routing
working
group
has
adopted
it
as
official
work,
but
they
can't
do
anything
with
that
work
without
our
I'm.
E
Not
saying
is
is
should
adopt
it
by
any
stretch,
right
I'm,
saying
that
I
don't
think
we
have
a
knee-jerk
reaction
to
adopt
it
based
upon
the
email
from
v6,
ops,
I
and
I
also
think
that
into
the
until
this
point
and
the
context
in
which
Archie
gwg
looked
at
the
use
cases
which
are
much
narrower
and
were
more
bluntly
focused
on
the
home,
as
opposed
to
the
smaller
larger
enterprise,
there's
a
very
different
market
segments
that
can
come
in
and
care
and
that
changes
some
of
the
context.
That's
all
okay,.
A
A
All
right,
whoever
doesn't
see
me
there.
Okay,
one
view
graph
to
show
us
lever
short
as
ever
so
we
update
die
size
extensions
because
in
beer
architecture
are
the
discussion
started
whether
we
will
be
converting
bit
string
lengths
or
not
when
the
stuff
is
forwarded.
So
I
added
a
sub
sub
POV,
we're
not
can
indicate
whether
it
supports
beats,
twigleg,
conversions
or
not,
which
violates
directed
architecture
document.
But
I
have
discussion
with
that.
Our
architecture,
people
of
which
I'm
one
yeah
right,
yeah
and
that's
about
it.
G
B
B
G
G
Actually,
it
works
okay,
good,
so
that's
much
cleaner,
so
status.
So
far,
we
got
very
minor
comments
on
the
draft
itself.
Basically
whether
need
to
make
a
small
changes
here
and
there.
I
think
the
couple
of
comments
were
regarding
making
references
to
the
I
tricky
like
standard,
which
we
won't
have
a
problem.
If
you
want
to
incorporate
them.
The
main
points
of
discussion
is:
why
do
we
need
that
draft?
And
there
were
a
couple
of
other
alternative
proposals,
so
I've
covered
the
first
point
and
then
I'll
go
a
little
bit
deeper
on
the
alternative
proposals.
G
G
But
he,
if
you
want
to
do
traffic
engineering
or
steering,
then
we
can
still
do
it
now.
Discussion
about
the
alternative
proposals.
There
were
three
alternative
proposals
and,
and
to
be
honest,
I
would
go
over
each
one
of
them
quickly
and
I'll
tell
you
other
some
of
them.
It's
what
not
very
clear
to
me,
but
I
just
listed
them
here
to
be
objective
and
to
be
fair,
I
mean
people
have
proposed
something
we
have
to
discuss
them.
G
So
first
proposal
was
the
use
of
BG
pls.
That
part
was
not
really
clear
to
me
not
to
less
not
to
anybody.
We
think
that
BTW
pls
is
a
companion
is
a
complementary,
but
not
leader
on
alternative.
If
I'm
running
is,
is
just
to
do,
traffic
engineering
should
should
I
deploy
btls
everywhere.
It
wasn't
very
clear,
but
I
just
put
it
there.
The
second
option
was
to
instead
of
having
layer,
two
bundles,
make
everything
unnumbered
and
advertise
them,
as
they
are
three.
G
The
third
option
was
to
that
idea
wasn't
very
clear
to
me,
but
I
just
copied
this
from
the
email.
The
idea
is
to
have
their
own
IP
address
on
the
l2
bundle
as
well
as
each
member
again
again.
I
just
put
it
there
again
to
be
fair,
whoever
sent
it
basically
by
I
deserve
its
that's
an
obligation
on
me
to
present
it
to
be
objective.
Actually,
I
thought
I
would
do
some
sort
of
grading
that
may
be
slightly
objective
subjective.
G
You
guys
are
most
welcome
to
to
disagree
with
it,
but
I
listed
all
proposals,
starting
with
the
draft
and
then
the
three
other
proposals
and
I
kind
of
gave
grading
to
each
one
of
them
based
what
I
think
is
reasonable,
so
the
first
factor
is
scalability
in
the
current
proposal.
Pretty
much
there
is
no
scalable
I
mean
I,
mean
we're
advertising
the
whole
new
TLC,
and
somebody
doesn't
understand
it.
They
can
just
skip
it.
It
does
not
impact
SPF
does
not
impact
anything.
It's
just
one
additional
tlv.
G
The
bt
pls
assumed
that
I
understood
what
what
the
objective
was
would
still
be
the
same
thing,
because
we
will
be
deploying
something
new,
so
the
basic
is:
is
operations
not
affect
affected?
Having
unnumbered
interface,
we
think
is
too
much
because
suddenly,
instead
of
having
one
link
between
me
and
my
neighbor
suddenly
became
16
or
32,
so
the
SPF
of
everyone,
even
an
old
router
that
doesn't
understand
this
new
tlv,
suddenly
becomes
impacted.
G
The
the
next
one,
which
is
having
an
IP
address
on
the
bundle,
as
well
as
the
members
even
worse,
because
now
I
have
to
deal
with
the
huge
number
of
IP
addresses
suddenly,
instead
of
having
an
IP
address
on
each
side
of
the
bundle,
I
have
16
or
32.
So,
in
addition
to
having
a
large
number
of
things,
I
have
even
a
large
number
of
prefixes
and
based
on
this
I
gave
kind
of
kind
of
this
rating.
G
But
again
we
will
most
welcome
to
to
disagree.
Deploy
a
protocol
not
deployed
before,
of
course
I
have
is,
is
I,
don't
have
to
deploy
anything
or
obviously,
if
I
want
I
deploy
BG
TLS,
then
it's
something
new,
so
operation,
little
overhead
or
third
option
impact
on
basic
routing.
This
is
minimal.
I
mean
this.
One
is
also
minimal,
because
for
this
one
I'm
not
adding
to
go
to
the
next
eight.
That
is
it's
something
duty.
At
least
that
is
not
used
in
the
SPF
in
BG
pls,
it's
a
whole
new
protocol.
G
So
again
it
has
no
impact
on
the
SPF
itself.
This
one
and
this
one
are
very
large
because
suddenly
again
the
number
of
things
have
been
x,
16,
32
64.
This
one
is
even
worse,
because
not
only
the
number
of
links,
it's
the
number
of
prefixes,
this
one
works
for
both
point
to
point
and
line.
Yes,
of
course,
I
mean
I'm,
just
advertising
a
link.
This
one
also
multiplies
in
a
link,
unnumbered
interface
on
point
to
point
on
point
to
multipoint
how
this
is
done.
G
I
haven't
seen
it
done
before
for
this
one,
it
is
simple.
Basically,
it
can
still
work
for
point-to-point
or
lens
using
the
same
protocol
for
everything,
yes
on
the
proposed
draft
and
yes
on
the
unnumbered
and
yes
on
the
numbered,
but
for
the
BG
pls
I
have
to
deploy
a
new
one,
exposing
l2
info
in
the
l3
protocol.
Yes,
we
will
be
doing
here
and
that's
precisely
what
we
want
to
do.
I
mean
this
is
what
we
are
saying
we
will
do.
I
will
advertise
l2
information
inside
is
is
for
BG
pls.
G
If
I
understood
correctly.
Yes,
we
will
be
advertising
l2
members
into
BG
pls.
How
is
that
going
to
be
done?
I
frankly,
don't
know
for
this
one,
no
I
converted
the
l2
members
into
l3
and,
to
be
honest,
I
think
this
is
cheating
and
if
I
they
intended.
Originally,
they
were
l2
l2
numbers
now,
I,
converted
them
12,
31,
ok,
I,
just
rename
them,
but
I
did
the
exposition.
G
Protocol
change,
yes,
I,
do
need
to
change
protocols
in
the
draft
that
is
being
proposed
and
the
BG
pls,
because
I
need
to
have
a
new
mu,
ta
type
of
TLD
and
the
other
two
proposals.
No,
I
don't
I
mean
we
already
support
our
number
than
we
support
numbered
links.
There
is
this
one
is:
there
is
no
impact
on
baseline
functionality.
Baseline
functionality
for
the
routing
weather
is
currently.
There
is
no
impact.
It's
a
new
tlv.
G
Somebody
might
say
some
a
big
deal.
That's
fine!
These
two!
Just
suddenly.
My
link
state
database
again
got
x
a
very
large
number,
so
my
montant
monitoring
tools,
my
if
I
have
SDN
controller.
My
own
routing
engines
would
suddenly
have
to
deal
with
a
much
larger
amount
of
data
provisioning
overhead.
This
one
is
small.
You
just
have
to
type
a
configuration
on
the
routers.
What
you
want
this
feature
to
be
enabled
this
one
is
medium
because
I
have
to
enable
BTW
pls.
I
have
to
basically
configure
BTW
pls
on
each
on
each
router.
G
This
one
is
significant.
I
used
to
have
one
bundle
with
one
IP
address
suddenly
now,
I
have
a
lot
of
unnumbered
interfaces
that
all
needs
to
be
a
number
two
something
this
one
is
even
worse
because
in
addition
to
having
new
links,
I
need
to
have
new
IP
addresses.
So
it's
a
huge
provisioning
over
head
coach
change.
Yes,
we
do
need
to
have
coaches
and
I
need
to
write
some
code.
Bg
pls,
yes,
I
need
to
write
some
code.
This
one,
no
I
mean
everybody
supports
having
parallel
links,
implementation,
wise.
G
If
my
number
of
modern
links
is
16
or
32
I
don't
need
to
modify
my
is.
Is
this
one
see
you
can
look
at
it
in
tools?
I
I
have
some
some
processes
and
stuff
running
on
the
routing
protocol.
It
can
deal
with
a
certain
number
of
prefixes.
Suddenly,
this
number
of
prefixes
dot
x
64
do
I
need
to
look
good
to
all
of
them.
Probably
no
I
mean
I'm
bgp
I.
Don't
need
to
look
to
all
about
all
of
these
prefixes
I.
Don't
care
about
them!
Do
I
have
to
make
changing
the
code.
G
I
think
this
is
the
last
slide
pair.
This
works
with
RSVP
without
modification,
no
I
think
we
need
to
make
some
modification
to
be
honest.
I
haven't
I,
haven't
given
given
much
thought
about
this
part,
but
probably
we
need
to
do
some,
some
others
giving
modification,
maybe
not,
maybe
not
so
as
they
be
the
the
so
as
the
BG
pls.
G
Yes,
we
do
able
to
make
some
modification
for
this
one
making
that
number
interfaces
has
been
working
with
RSVP
for
years
and
years,
so
I
am
basically
having
a
large
number
of
unnumbered
are
on
the
interfaces
or
part
of
the
links
in
work
with
RSVP.
This
one
I
as
I
said:
I,
don't
understand
it.
Maybe
yes,
maybe
no.
G
How
do
I
tell
RSVP
that
this
this
member
that
has
IP
address
is
actually
a
member
of
abundant
ones
like
it's
a
new
hierarchy?
I
am
not
sure
of
RSVP
supports
something
like
that
or
not,
but
most
likely
we
do
need
to
tell
RSVP
that
this
interface
is
even
at
zero
interface.
It's
actually
a
member
of
the
bond
and
interface.
Hence,
if
you
have
some
traffic
flowing
on
the
mundum,
be
careful
that
part
of
it
would
actually
maybe
flowing
on
this
member,
even
though
it
appears
that
it
is
a
different
interface
to
wait.
G
Connectivity
I
frankly,
don't
understand
how
it
is
applicable.
Here
we
don't
make
two-way
connectivity
on
individual
members.
It
doesn't
make
sense,
but
but
in
the
draft
we
allow
any
tlv
on
any
in
sub
tlv
of
tea,
a
v-22
to
be
advertised
and
this
new
tlv
so
the
to
a
connectivity
Albie's.
Whatever
tell
ms,
I
forgot
the
number
that
the
sub
tlv
number
that
is
useful
to
a
connectivity.
G
You
can
do
it
here,
but
does
it
make
sense
to
the
honest
I
I
I'm
not
sure
if
it
makes
sense
or
not
BTW
pls
to
a
connectivity,
I'm
not
sure
also
if
it
makes
sense
or
not.
I
don't
know
what
does
that
mean
these?
Do
this
simple?
It's!
Basically,
there
are
three
link
that
you
can
do
to
a
connectivity
on
in.
There
is
no
real.
There
is
no
real
issue
here.
The
last
thing
you
must
Deacon
figure
and
reconfigure
your
elk
abundance.
G
If
you
use
the
proposed
draft
and
BTW
pls
even
have
to
cut
your
config
abundance,
if
you
have
to
make
the
layers
to
bond
and
suddenly
break
it
up
into
layers
three
interfaces,
you
do
have
to
Deacon
figure
your
bundle
interfaces
and
pretty
much
that's
it
so
I'm
giving
basically
a
status
update
on
what
we
have.
We
think
that,
basically,
this
solution
is
will
deliver.
What
is
required
would
solve
the
use
case
and
we'd
have
minimal
impact
on
the
current
operation
of
the
protocol
as
well
as,
even
as
as
the
future,
pretty
much
that's
it.
H
H
G
H
G
H
The
whole
point,
so
that's
not
a
third
controls
in
so
any
controller
who
wants
really
or
network
operations
center,
can
actually
go
and
programs
labels
against
that.
You
know
particular
link
that
will
take
the
packet
only
right
across
the
member
link
and
because
the
Contra,
the
NOC,
has
actually
used
that
assigned
that
label.
He
can
actually
build
probes
using
that
label
from
the
NOC
right
and
then
some
most
year,
the
traffic
to
that
node
using
some
others
segment,
note
segment
and
then
put
this
level
next
and
exercise.
That
least.
H
H
A
A
G
That's
what
I'm
saying
I
know
that
they
reduce
cases.
We
know
actually
the
operators
who
won
this.
That's
all!
So
that's
the
answer.
So
any
other
questions.
So
if
the
question
is
that
nobody
wants,
this
I
think
he
got
the
response.
If
you
look
at
the
co-authors,
there
is
a
response
right
there.
So
I'm
I'm
not
sure
what
people
are
saying.
That
is,
nobody
wants
it.
A
D
D
D
D
This
is
the
new
text.
Let's
look
at
the
two
pieces
that
are
in
the
new
text.
The
first
part
says:
okay,
if
you
don't
have
an
ipv4
router
ID,
then
you
must
put
all
zeros
in
the
router
ID.
Then
you
must
use
the
ipv6
te
router
ID
sub
tlv,
which
already
exists.
It's
already
been
defined
to
provide
a
router
ID
for
the
source.
D
The
router
ID
in
ice
is
must
be
a
reachable
address.
It's
not
just
a
32-bit
number.
This
is
as
per
li,
the
rfcs
that
define
those
two
LVS.
So
today
the
only
choice
for
people
is
to
actually
enable
ipv4,
at
least
to
eliminate
extent,
find
an
ipv4
a
router
ID.
There
was
some
discussion
on
the
list
about
backwards,
compatibility
issues.
I,
don't
believe
there
are
any
backwards
compatibility
issues
for
the
boxes
today
that
are
quote
unquote,
ipv6
only
and
need
to
send
the
router
capability
tlv.
D
The
second
clarification
we
made
there
was
no
discussion
in
the
original
RFC
as
to
what
value
this
this
ipv4
router
ID
should
be.
Should
it
be
the
same
as
tlv
134
the
TE
router
ID,
or
should
it
be
something
else
from
our
standpoint?
There's
no
reason
for
it
to
be
any
other
address,
so
we're
just
putting
clarifying
language
in
here
that
says,
if
you
are
putting
in
a
and
ipv4
router
ID,
it
must
be
the
same
as
the
router
ID
you
advertise
in
tlv,
134.
D
Yes
should
thank
you
and
we'd
like
to
request
request
working
group.
Adoption
I
would
mention,
as
an
aside
there's
a
sort
of
a
companion
draft
for
the
VIP
knee
6te
RFC
5316,
which
was
presented
earlier
today
in
tease.
It
has
a
similar
problem
because
it
has
a
similar
format.
We're
going
to
bring
that
draft
into
is
is,
and
it
essentially
has
the
same
solution.
D
This
is
based
upon
a
real
world
problem.
This
problem
was
actually
encountered
in.
This
draft
defines
a
solution
to
it.
The
original
problem,
I
believe,
was
presented
at
last
ITF
thanks
to
Bruno
and
all
the
people
who
presented
that
and
in
showed
exactly
what
can
and
actually
has
happened
in
a
real
network.
D
This
potentially
can
cause
premature
aging
of
the
LSP
and
can
cause
flooding,
storms
and
temporary
loss
of
network
connectivity.
So
this
is
what
the
header
of
an
LSP
looks
like.
The
portions
in
green
are
protected
by
cryptographic,
authentication
the
the
key
field.
Here,
that's
in
red
is
remaining
lifetime,
which
is
unprotected.
The
portions
that
are
in
blue
are
protected
both
by
the
standard
checksum
and
by
cryptographic.
D
Authentication,
if
you
have
it
enabled
so
what
happens
if
the
remaining
lifetime
does
get
corrupted,
there's
a
number
of
possibilities
here
if
the
lifetime
becomes
larger
than
it
was
supposed
to
be.
This
is
a
pretty
benign
issue,
because
the
source
of
the
LSP
is
going
to
update
it
before
the
original
lifetime
expires
or
he's
going
to
purge
it
if
he
no
longer
needs
it
anymore.
So
the
only
consequence
of
this
is
if
the
source
of
the
LSP
dies
and
becomes
unreachable.
D
You
have
an
LSP
that
stays
in
your
link
state
database
longer
than
necessary,
but
because
you
can't
reach
that
source,
you
don't
use
it.
So
it's
it's
a
benign
issue.
The
real
problem
is:
what
happens
if
the
lifetime
becomes
smaller
than
its
supposed
to
be?
What
this
means
is
the
LSP
will
age
out
on
at
least
some
routers
in
the
network
prematurely.
D
So,
instead
of
waiting
for
the
source
of
the
LSP
to
refresh
it
or
or
update
it,
as
the
case
may
be,
if
he's
got
changes
to
the
content,
somebody
else
in
the
network
will
age
it
will.
The
lifetime
will
expire
and
he'll
purchase.
The
purge
will
eventually
find
its
way
back
to
the
originator,
but
in
the
time
that
it
takes
for
that
to
happen,
you're
going
to
lose
network
connectivity,
you're,
obviously
going
to
cause
another
round
of
LSP
flooding,
and
this
can,
if
this
is
persistent,
it
can
create
LSP
flooding,
storms.
D
The
third
possibility
is
the
remaining
lifetime
becomes
zero.
This
again
is
if
you
have
cryptographic,
authentication
and
able-
and
you
use
RFC
6233,
which
clearly
defines
what
TL
v's
are
allowed
in
a
perch.
Then
an
LSP
that
comes
with
a
zero
meaning
lifetime,
but
the
the
body
of
the
LSP
has
not
actually
been
modified.
To
look
like
a
purge,
it
will
be
rejected.
So
that's
again
not
an
issue.
D
What
are
some
causes?
Wow?
We
could
have
a
hardware
failure
who
have
bits
being
flipped.
You
could
have
a
bug
in
the
software
I
think
the
the
the
issue
were
more
concerned
about
we're
concerned
about
all
of
these,
but
we're
more
concerned
about
the
possibility
that
you
know
some
something:
a
layer
to
switch
in
the
middle.
If
you've
got
an
attacker,
has
the
potential
to
simply
set
the
lifetime
to
a
fairly
small
value?
D
D
If
the
LSP
that
you
received
is
newer,
then
you
install
it
in
the
database.
What's
the
definition
of
a
newer
LSP,
you
have
either
it's
a
brand-new
LSP.
You
don't
have
it
in
your
database
at
all,
or
you
have
a
copy
of
that
LSP,
but
the
sequence
number
that
you
have
in
your
database
is
smaller
than
the
sequence
number
of
the
LSP
you've
received,
or
you
have
the
same
sequence
number,
but
the
remaining
lifetime
in
the
received
LSP
is
0
indicating
it's
a
purge.
D
Lsps
are
normally
refreshed
by
the
originator,
so
in
normal
operation
we
don't
expect
that
an
LSP
is
purged
by
somebody
other
than
the
owner.
It
can
be
purged
if
they
believe
the
lifetime
has
expired.
That's
not
the
normal
operation
again.
Remember
that
retaining
an
LSP
in
your
database
longer
than
necessary
is
a
benign
event
takes
up.
A
little
bit
of
memory
does
not
cause
any
problems
in
terms
of
the
correctness
of
your
routing
calculation,
so
purging
is
actually
an
optimization.
You
could
design
a
protocol
without
the
ability
to
purge
it.
All.
D
The
only
problem
you
would
have
is
you'd
end
up
with
lots
of
stale
LSPs
in
your
database,
but
your
routing
calculation
would
still
be
correct.
So
this
is
the
backdrop
for
the
solution
today
when
we
receive
an
LSB.
If
it's
the
first
time
we've
received
that
version
of
an
LSP
we
stored
in
our
database,
whatever
the
remaining
lifetime
is
in
the
LSP
that
we
received
that's
the
lifetime,
we
store
in
our
database
and
then
we
start
decrementing
it
as
time
ticks
off.
D
The
new
behavior
is
if
the
remaining
lifetime
of
the
new
LSP
that
you
receive
and
again
emphasis.
This
is
a
new
copy,
not
just
a
copy
of
something
you
already
have
in
your
database
if
the
lifetime
is
less
than
max
age.
Okay,
what
is
max
aah
max
age
is
the
locally
configured
value
for
the
maximum
remaining
life
time
that
you
put
in
in
LSB.
This
is
what
you
put
in
an
Alice
B
when
you
generate
a
new
version
of
it.
If
it's
less
than
that
value,
then
you
set
it
to
max
age.
D
This
is
a
backwards.
Compatible
change
causes
no
change
to
the
update
process.
That
ISS
runs
updating
its
LSP
database,
no
changes
to
how
LSPs
are
purged.
If
the
remaining
life
time
expires,
you
purge
it.
The
only
change
in
behavior
is
that
you
may
retain
an
LSP
in
your
database
longer
than
necessary.
This
will
only
happen
in
the
case
where
the
source
of
the
LSP
does
not
refresh
that
LSB.
Why
would
he
not
refresh
that
else
be
because
he's
become
unreachable?
Either
he's
crashed
or
some
links
have
gone
down.
D
D
There's
a
few
deployment
considerations
in
the
original
in
the
base.
Spec
for
ice
is
10.
589
max-age
is
an
architectural
constant
of
1200
seconds,
but
in
practice
most
implementations
have
made
it
a
configurable
value.
People
frequently
set
this
to
the
maximum.
It's
a
16-bit
number
so
65,000
seconds,
which
is
roughly
18
hours.
So
it's
possible
that
if
you
don't
configure
max
age
to
be
a
consistent
value
on
every
router
in
your
network
that
you
may
get,
you
may
get
a
corrupted
remaining
lifetime.
The
originator
of
the
RSP
had
lifetime
set
to
65,000.
D
You
have
lifetime
set
to
1200.
You
get
a
corrupted
value
which
is
500.
You
set
it
1200.
This
is
still
going
to
cause
the
LSP
to
be
aged
sooner
than
the
originator
wanted
it
to
be.
So
you
may
want
to
set
a
different
number
than
your
locally
configured
max
age,
for
the
value
that
you
want
to
insert
in
the
LSPs
that
you
received
from
somebody
else.
I
think
this
is
only
necessary
if
you
don't
configure
a
consistent
remaining
a
max-age
on
every
router
in
your
network.
D
Clearly,
it's
useful
to
log
cases
where
you
believe
you
have
received
lifetime
that
is
potentially
corrupted.
You
can't
know
for
certain
than
what
you've
received
is
corrupted,
but
if
it's
a
pretty
small
value,
it's
quite
likely,
but
it
is
corrupted
because
typically,
people
do
not
set
remaining
life
to
our
max
age
to
you
know
20
seconds
or
something
like
that.
So
if
you're
receiving
a
new
copy-
and
it
has
a
pretty
small
value-
it's
pretty
likely
that
it
has
been
corrupted.
D
It
may
also
be
useful
when
you
show
your
database
now
that
you've
actually
modified
the
remaining
lifetime
from
what
you
actually
received.
You
might
want
to
add
something
in
the
display
that
says
well,
this
is
the
value
I've
stored,
but
this
is
the
value
I
actually
received
that
may
help
you
diagnose
the
problem
and
that's
it
we'd
like
to
have
working
group
adoption.
Any
questions.
D
D
Well,
if
you
go
by
the
bay
spect,
the
base
effect
says
the
content
should
be
empty,
but
obviously,
when
we
add
an
authentication
we
had
to
allow
authentication,
then
we
introduced
the
purge
tlv
to
say
I'm,
the
guy,
who
originated
the
purge
to
help
locate
where
the
purge
originated
from
I
think
we
also
added
the
ability
to
have
dynamic
host
name
in
there
as
an
aid
to
find
out,
but
there's
a
very
limited
set
of
tvs
that
are
allowed.
We.
B
A
D
B
D
A
B
D
No,
so
the
purchase
tlv
was
defined,
I
think
about
34
years
ago.
You
know
not
everybody
supports
it,
but
that's
the
solution
as
if
you
have
this
problem,
your
network
and
you're
seeing
corrupted
remaining
lifetime
and
it
turns
out
to
be
0
because
of
whatever
reason
the
solution
already
exists.
You
just
have
to
get
your
vendor
to
support
it.
Yep.
B
D
B
A
D
B
Okay,
so
there
was
other
words
I
think
all
three
of
these
were
requested
to
be
working
group
documents
of
so
I
need
to
run
back
through
them.
The
LT
bundles,
who
has
read
the
l,
two
bundles
draft
okay
and
who
thinks
it
should
be
working
your
document,
okay,
that
was
almost
the
same
hands
good,
so
for
the
the
ok
so
the
best
draft.
We
need
to
update
that.
Does
anyone
object
to
the
best
draft
being
about
it?
I
I
This
job
to
was
first
presented
in
ITF
ragam
ET
amending
we
have
us.
There
are
three
concerns.
The
first
is
ice
ice
is
not
defined
as
an
ITF
pc
to
see
protocol,
so
we
removed
bgp
mps
with
ian
use
cases
in
now.
It
only
keeps
campus
network
use
case.
Second,
what
happens
if
multi-core
auto-injector
filter
component?
I
Actually
this
the
description
had
already
defined
the
in
section
4
4.1
point:
what
the
order
of
applying
the
traffic
filter
roles
is
the
same
as
defined
you
I've
seen
5575
sir,
how
to
limit
any
the
fellows
back
roads
in
the
lot
in
common.
Actually
in
the
new
or
flows
back
and
reach
irritability,
are
we
redefined?
We
define
a
flag
set
if
the
flag
is
said
this
this
year,
we
should
be
four,
should
it
be
flooded
across
the
entire
routing
that
may
otherwise,
which
must
not
be
liquid
or
between
levels?
I
I
Now
we
only
keep
the
canvas
Network
a
use
case.
Other
we
can
see
from
this
figure
in
in
the
campus
network.
Iss
is
used
so
you,
it
is
expanded
expected
that
you
extend
iodized
to
distribute
philosophy
controls
this
year
down
on
use
case
now,
you
document
a
new
Ice
stl.
We,
that
is
the
first
very
much
ability
are
we
defining
in
the
document.
It
include
a
type
lens
flag
and
the
floss
beggar
entries
a
flag
is
defined
as
the
leaking
in
never
pitch.
I
We
just
blend
in
with
a
pair
satellite
that
if
this
flag
in
state
the
this
year,
we
should
be
flat
flag,
video
across
the
entire
wrote
in
the
mail.
Otherwise
it
must
not
believe
it
between
levels
and
the
full
spec
entry.
Each
of
the
log
spank
entry
consists
of
philosophy,
futures
and
the
cross
bonding
floor.
Speaker
action
for
the
details
of
you
can
can
look
look
into
the
document.
B
I
F
Jim
cunado
similar
comment
to
AC
as
I
wondering
how
many
actual
networks
are
based
on
campus
boss,
avoiding
the
use
of
PGP
for
AAS
interconnection
and
using
ISAs
I'm,
not
ospf.
This
seems
like
rather
carry
oriented
igp,
where
pgp
is
commonly
used
to
prospect
would
be
GP
based
so
I'm
wondering
about
the
actual
number
of
relevant
networks
to
this
proposal.
F
A
I
B
Do
you
understand
that
the
main
thing
that
the
main
question
is
that
is
it's
it's
hard
to
believe
that
there's
people
using
is,
is
and
not
bgp,
and
if
there
are
people
are
using
the
bgp?
That's
the
butter
solution
for
flows.
Back
then
is
is
so
so
I
mean
that's
the
real
I
think
that's
if
you're
going
to
run
into
any
kind
of.
If
you
actually
have
some
use
cases,
some
people
who
come
onto
the
list
and
save
this
and
we
here's
an
example
where
we're
running
is:
is
we're
not
running
bgp?
B
A
C
The
most
significant
technical
changes
we
added
a
start-up
mode
will
the
see
some
ID
duplication
happens.
If
the
rotor
in
the
study
mode,
then
it
should
be
the
study
mode,
startup
mode
water,
to
change
its
system
ID.
And
if
the
duplicate
nodes
are
both
in
stubborn
mode,
then
they
follow
the
normal
comparison
method
and
accordingly,
we
need
to
add
a
start-up
mode
flag
in
the
fingerprint
ERV
to
indicate
this
water
is
in
stock
hard
mode
or
not.
C
And
we
also
took
into
account
the
duplication
between
livers.
The
male
behavior
for
the
Nazis
to
the
master
include
fingerprint
IV
in
Hallows
Eve.
The
duplication
detected
in
hollows,
then
the
not
want
from
any
agency
in
otherwise
we
remove
the
clear
test,
password,
authentication
mode.
This
is
originally
for
distinguish
between
an
auto
coffee
and
now
the
complaint,
but
you
we
already
have
the.
C
The
flag,
then
the
starboard,
especially
the
startup,
not
then
it
is
not
read
it
again
so,
but
for
authentication
we
added
a
usage
of
the
most
sophisticated
security
mechanism
like
the
H
Mack,
md5
authentication
mode,
and
it
is
suggested
by
is
easy
in
Las
idea
and
less
contribute
a
lot
in
the
maneuvering
to
improve
the
quality
of
the
crowd.
So
we
added
him
as
a
Nuke
order.
C
A
B
B
B
A
F
F
The
topology
that
we
are
presenting
in
is
is
and
put
metrics
on
the
particular
relation
between
two
participants
on
that
motives
are
broadcast
network
instead
of
just
between
a
participant
and
the
pseudonym.
So
what
we?
What
you
present
the
last
time,
was
a
de-
pediatr.
We
did
move
away
from
that
or
based
on
feedback
from
les.
F
This
is
now
using
the
point-to-point,
hello,
being
multi
casted
on
the
network,
with
a
Down,
freeway
adjacency
state
and
as
a
result
from
that
which
is
used
for
discovery,
we
move
to
point-to-point
areas
which
are
unicast
on
the
layer
tube
to
the
individual
participant,
and
we
proceed
with
the
normal
p2p
state
machine
on
that,
and
that
is
already
this
presentation.
So
we
haven't
changed
much
really.
The
idea
is
pretty
simple:
I'm
hoping
to
get
feedback
and
we're
continuing
to
work
on
this.
B
B
B
I
guess
I
have
one
more
comment
on
that,
since
I
became
go
out
there,
I
should
make
a
comment
on
it.
The
this
this
was
originally
driven.
Just
for
the
just
for
the
guy
I
mean
it
was
kind
of
prodded
forward
by
homenet,
which
we
may
not
be
a
part
of
anymore,
but
I
think
it's
still
useful
work
to
look
at
because
it
does
actually,
you
know
present
a
couple
of
nice.