►
From YouTube: IETF100-ISIS_OSPF-20171116-0930
Description
ISIS OSPF meeting session at IETF100
2017/11/16 0930
https://datatracker.ietf.org/meeting/100/proceedings/
A
B
C
D
F
D
D
A
A
All
right,
well
so
I
think
we've
got
an
agenda
up
here.
The
the
way
we
were
gonna
run.
It
is
we're
gonna.
Do
working
group
updates
for
both
working
groups,
one
after
the
other
and
then
we'll
get
into
the
presentations.
They
saw
that
we
just
did
the
two
OSPF
and
two
eius
eius.
There
were
some
thoughts,
oh
and
if
it's
not
obvious
or
running
a
joint
meeting,
I
Esiason
ospf.
A
This
time
everybody
should
have
been
receiving
mail,
maybe
that
you
didn't
receive
before,
because
the
mailing
lists,
the
mailing
lists
were
both
combined
the
eye
size
and
all
SPF
mailing
lists.
The
membership
lists
were,
and
we
you
know
if
we
had
a
lot
more,
maybe
we'd
mix
it
up.
The
idea
here
is
to
try
to
get
maybe
some
cross-pollination
between
the
two
very
similar
groups.
A
It's
also
to
reduce
the
replication
that
we
were
seeing
with
some
of
the
segments
routing
stuff-
and
you
know
in
the
past
there
hasn't
been
as
much
replication,
although
it
seemed
like
there
might
have
been
there
wasn't,
there's
been
more
lately,
so
a
Leo
who's,
not
here,
has
been
pushing
hard
for
this
I.
Think
I.
Don't
know
about
AC
I'm,
I'm
sort
of
either
way
kind
of
I
I
originally
didn't
like
the
idea
now
I'm
like
okay.
If
it
has
to
be
I,
there
are
I
think
there
are
reasons
not
to
do
it.
A
There
I
think
it
can
waste
people's
time.
You
know,
there's
people
like
gmpls
I,
don't
know.
There's,
there's,
there's
different
groups
of
people
that
are
not
interested
in
both
routing
protocols.
So
that's
a
big
reason.
I
think
not
to
do
it
all
so
I
don't
know
about
you.
Ac
I
haven't
really.
It
hasn't
made
me
paid
more
attention
to
OSPF
and
I
started
thinking
when
AC
missed
his
plane.
What
would
happen
if
I
had
to
run
the
group
myself
right
like?
Is
it
too
much
work
to
do
for
two
people?
C
A
year
ago,
the
first
time
they
asked
us
I
was
really
really
against
this,
but
now
in
OSPF
for
OSPF
III
we
have
the
extended
lsas
and
we
have
the
prefix
link
attribute
LSA
for
all
SPF
v2
and
we
have
the
OSPF
router
information.
L
SAS,
we
kind
of
opened
it
up
for
general
purpose,
use
it's
not
just
protocol
usage,
so
we're
basically
there's
going
to
be
optimizations,
like
you
saw
in
the
data
center
for
for
eius
eius
for
different
protocols
in
different
ways
of
doing
things.
C
G
Yeah
I'm
all
for
it
I
think
it's
a
good
idea
and
I
think
the
benefits
will
will
show
up
long
term.
More
I
mean
it's
difficult
to
say.
You
know
in
six
months,
they'll
be
solid
benefits,
but
over
two
years,
I
think
it'll
be
an
obviously
good
idea.
You
think
the
cross,
like
the
cross-pollination
and
and
just
just
the
lack
of
you,
know,
replication
of
work
unnecessarily
and,
and
things
will
then
start
to
align
better
like
a
C's
project.
G
H
G
F
F
E
I
C
We
have
an
na
RFC
since
the
last
IETF.
We
do
have
this
one.
The
tunnel
end
caps
is
all
done,
but
it's
waiting
on
RFC
Q
on
a
reference
to
IDR
tunnel
attributes.
So
hopefully
the
issues
without
and
iidr
will
be
resolved
and
we'll
get
that.
There's
there's
actually
a
lot
of
IDR
drafts
that
reference
that
too
so
I'm
hoping
hoping
that
gets
published
soon.
C
We
have
OSPF
be
two
segments
around
it
in
extensions,
we've
gone
through
a
number
of
comments
from
Illya
and
it's
addressed,
and
we
had
a
discussion
on
this
registry.
What
what
we're
going
to
do
with
algorithm?
We
decide
to
have
a
common
IGP
algorithm
registry
and
we're
going
to
also
have
a
higher-level
registry
category
right
now.
We
have
OSPF
parameters
and
eius
eius
parameters.
We're
gonna
have
a
higher
level
category
for
IGP
parameters
and
then,
as
a
sub
registry
of
that
this
new
one
anyway
and
I,
see
Elias
she's.
C
Extended
LSAs
we
just
completed
a
working
group.
Last
call
Peter
senic
has
agreed
to
be
document
shepherd,
so
we're
gonna
get
the
Shepards
report
and
send
it
to
alia
for
her
comments
soon.
As
you
know,
we
have
a
couple
implementations,
Nokia,
and
why
away
at
this
one
link
overload.
That's
my
next
one
I
think
we're
gonna
work
in
group
last
call
the
next
version
of
this.
One
change
we
made
or
we're
gonna
make
is
we're
going
to
put
the
reference
into
extended
LSA.
Is
it
one
time
we
weren't
putting
the
references
into
expended
LSA?
C
So
we
didn't
know
when
we
get
that
done.
We're
saying
this
will
be
handled
in
our
future
document.
We
don't
have
to
do
that
anymore.
Since
I,
that's
gonna,
be
a
real
priority.
To
get
extended,
LSA
is
published.
Get
this
one
work.
Class
called
there's
also
be
a
fee
to
H
bit.
This
comes
along
every
like
five
years.
I
think
we
had
to
just
finish
it.
This
is
the
this
is
the
one
for
you.
C
C
I
think
it
I
don't
know
if
it
comes
from
almost
bfd3
I
could
look
to
see
what
it
was.
I
can't
remember:
MSD,
signaling,
that's
maximum
segment,
death,
I,
think
this
one's
ready,
but
I'm
waiting
for
Jeff
and
the
other
Jeff
tensor
and
other
offers
to
request
it.
The
yang
model
I've
requested
a
early
review
of
this
I'm
an
offer
on
this
one
as
well.
This
OSPF
yang
model,
it's
quite
even
with
the
base
capabilities.
We
still
got.
We
still.
We
have
a
lot
of.
C
A
C
C
G
J
C
C
Ospf
v3
say
it
hasn't
been
a
priority
to
do
this,
yet
I
think
we
should
once
we
get
OSPF
extended
LSAs
and
hopefully
somebody
will
implement
this
I
think
I,
think
I,
guess
I,
guess
I,
guess,
Nokia
and
while
we
have
also
implemented
those
pop3
segments
routing,
so
we
should
push
that
along
te
attribute.
Reuse.
C
Lots
of
discussion
is
now
working
group
document,
OSPF
ll
s,
interface,
ID.
We
have
an
update
today
and
sr
yang
model.
We
broke
out
the
for
one
thing:
no
SPF
yang
mata
was
so
big
and
we
broke
out
SR
because
sr
seems
to
be
continued
to
change.
Even
after,
though
SPF
you
know
regular
OSPF
model,
since
the
NDMA
change,
the
regular
OSPF
yang
model
has
been
pretty
stable,
expired
I'm,
hoping
we
get
this
a
entropy
label,
one
back,
because
we
spent
a
lot
of
time
talking
about
how
it
should
be.
C
I
think
this
is
Stefan's
too.
Isn't
it
there's?
This?
Is
the
entropy
label?
Ospf
entropy
label?
Signaling?
That's
your
that's
your
draft
right,
oh
you're!
Not
in
here,
okay,
okay,
maybe
I'll
send
an
email
to
the
offers
see
if
I
can
get
asked.
What
the
deal
is
because
I
think
I
like
to
get
that
one
done,
especially
now
that
we
agreed
on
all
the
meaning
all
the
semantics
and
what
we're
advertising
so.
C
Here,
yes,
yes
and
flowspec,
I'm
gonna,
just
let
actually
I'm
an
offer
on
this.
One
I
asked
the
other
offers
said
they
had
a
use
case
for
this
and
they
were
going
to
implement
this
I.
We,
its
they've
kind
of
lost
interest
in
it,
I'm
not
going
to
do
flows
back
and
OSPF
unless
there's
somebody
who's,
gonna
use
it
so
we'll
just
let
that
one
die.
C
Datacenter
Bob-
these
are
these
by
other
working
group.
I
mean
documents
in
other
working
groups,
not
working
group
documents
that
I
didn't
cover.
We
have
beer,
I
I
know:
I
saw
not
too
many
people
reviewed
the
beer
draft
instead
of
me,
I'd
encourage
others,
I
think
it's.
Maybe
it's
I
think
it's
gone
to
the
ad.
Already,
though,
isn't
it
hasn't
it?
Oh
SPF
beer
in
draft
I.
L
L
No,
we
are
waiting
for
Alvaro
to
finish
up
on
the
segment
routing
documents
coming
out
of
spring
so
that
we
could
send
them
to
the
TSG,
as
a
bundle
unfortunately,
is
last
one
hasn't
made
that
timeline.
So
that's
annoying,
but
I
am
expecting
to
put
the
OSPF
one
on
the
telly
chat
either
this
time
our
next
time.
Oh
okay,.
C
M
A
M
F
C
E
C
E
A
We
didn't
do
it
no
well,
did
we
everyone,
no
one's
left
the
room
yet
so
I'm
only
me
and
AC
have
talked
well.
Chris
did
too,
but
no
well
I.
Think
I'm
supposed
to
read
out
the
boldface
stuff
start
participating
with
the
ITF.
You
agree
that
I
give
processing
policies
that
you
are
aware
that
any
kind
of
contribution
something
do
I,
really
have
to
read
this.
It's
covered
by
patents
or
patent
application.
Once
this
goes
back
and
not
participate
in
the
discussion.
A
A
Okay,
so
so
we
have
to
last
call
documents.
Actually
we
had
one
until
about
4:00
this
morning
and
then
I
last
called
the
reverse
metric.
So
that's
pretty
cool
that
one's
been
around
for
a
while
I
think
everyone's
had
a
really
good
chance
to
look
at
it,
so
I
don't
anticipate
any
problems
with
that.
The
other.
The
other
draft
is
the
eyes
eye
segment.
Routing
which
was
just
mentioned.
It
was
just
updated,
I,
don't
know,
is
I,
don't
actually
know.
A
G
When
the
update
was
made
in
June,
there
were
a
lot
of
changes
made
related
to
e
ro
s.
Right
I
pointed
out
that
something
was
removed,
which
wasn't
that
I
don't
agree
with
removing
and
I
didn't
get
any
technical
objections
to
putting
that
back
in
there's
been
no
update,
so
it
would
be
good
to
see
what
what
people
think
the
current
version
of
the
draft
is
well
right.
So
you.
A
G
A
A
G
A
G
M
L
A
L
So
I
asked
the
de
or
I
questioned
why
the
ero
pieces
were
in
the
document
because
they
did
not
relate
to
any
work
that
happened
in
the
spring
working
group
and
they
said
oh
yeah,
you
could
do
this
stuff,
but
it
was
like
wow
you
can.
You
could
spew
these
bits,
flooding
right,
you
can't
it
had
no
information
when
you
might
do
so.
What
the
architecture
or
semantics
and
handling
of
that
information
was,
and
obviously
we're
not
supposed
to
be
defining
specification.
You
know
mechanisms
in
the
iGPS
that
aren't
requested
from
the
spring
documents.
L
A
L
A
L
To
be
really
sure
that
they're,
both
aligned
and
I'd
like
to
get
the
bloody
things
done,
so
the
fact
that
authors
are
not
responsive
and
updating
the
document
in
five
months
is
not
an
indication
of
deep
activeness.
Even
though
we
all
know
the
stuff
is
out
there
being
implemented
and
deployed,
and
the
industry
is
kind
of
excited
about
it.
It
would
be
really
nice
to
get
it
like
done
through
the
IETF.
L
M
G
However,
well
so
that's
a
separate
issue
for
Jeff
to
take
up
as
far
as
I'm
I'm
concerned
for
this
particular
issue
about
basically
invalidating
a
you
know
up
until
draft
thirteen.
A
standardized
use
of
this
we're,
okay,
with
removing
it
from
OSPF
and
whatever's,
going
on
in
OSPF
I
believe
draw
that
you've
looked
at
that
and
that's
that's
fine.
It's
the
ice
is
draft
which
removes
something
which
we
don't.
A
C
M
Back
to
SPF
I
still
think
it
was
partially
misunderstanding:
removing
complete
binding
seats
rather
than
just
zero,
but
given
the
document,
it's
in
quite
advanced
state
and
I
think
we
discussed
with
AC
bindings.
It
could
be
published
just
very
small
or,
if
see
next
to
it,
just
bring
it
back
there
at
least
two
use
cases
where
bindings
it
could
be
used.
The
optical
use
case
and
the
sub
body.
J
N
Didn't
allow
liquor
Cisco
so
on
the
OSPF,
whatever
usage
of
bindings,
it
was
there
which
is
basically
the
ero.
They
are
the
underlying
TL
which
they
are
not
applicable
or
not
used
anymore.
So
there
was
no
need
to
retain
empty
container,
which
is
what
the
binding
said
would
have
been
and
that's
the
reason
we
have
removed
it,
and
there
is
really
no
push
or
to
do
that
now
in
the
spec.
So
we
should
take
okay,
no,
you
know
I,
we
discussed
it
and
I
think
we
are
going
to
do
it
in
a
separate
draft.
Yes,.
O
Juniper
Networks,
so
the
binding
said
binding
TL
we
from
OSPF
right
now.
There
are
no
implementations.
Nobody
objected
to
removing
of
this
and
of
course
it
will
be
useful
for
certain
use
cases
like
context
mirroring
and
such.
But
then
we
decided
there's
no
need
to
block
progress
of
OSPF,
a
segment
routing
document
for
this,
and
we
will
write
a
separate
document
with
its
very
specific
use
cases
and
describing
how
it's
going
to
be
used.
Cool.
A
C
A
A
We
have
an
adoption
call
for
the
advertising
TV
protocols,
the
enablement
Draft
as
it
were,
I
can
sort
of
give
an
update
on
that.
I
have
another
slot,
though
later
so
I'll
just
talk
about
it.
When
we
get
to
the
discussion
because
there's
been
some
there's
been
support
for
and
against
the
adoption.
So
we'll
talk
about
that
later,
oops
wow!
This
is
really
super
height,
sensitive,
okay,.
A
So
we
have
a
new
working
group
document
that
was
the
other
half
of
that
controversial
thing.
The
the
TE
AppData
draft
has
been
adopted
and
we
have
a
new
version
of
that
and
a
that's
being
presented.
That's
the
other
president
to
one
of
the
two
presentations.
We
have
some
updates
the
ice
ice
as
I
mentioned
earlier.
The
ice
is
benoit's
called
out
that
the
ice
ice
yang
model
does
not
is
not
an
MDA
compliant.
It
should
be
it's
going
to
be
AC
service.
So
that's
great.
A
A
We
have
a
bunch
of
updated
individual,
Docs,
I
haven't
even
read.
All
of
these
I
must
be
honest.
The
Baker
Baker
one
is
interesting
to
call
out
here,
though,
because
that
one
was
actually
in
an
adoption
call
almost
a
year
ago,
and
then
it
sort
of
went
dormant
and
David
lamp,
litter,
I
think
I
pronounced
his
name
wrong,
but
just
updated
it.
So
that's
how
it
got
into
that
and
I
think
there's
a
new
push
on
to
sort
of
visit.
This
work.
A
So
those
the
Flexi
I'm
not
sure
the
other
to
our
data
center
related
they're
just
sitting
there,
but
they
they
actually
were
talked
about
in
the
data
center.
That
happened
on
Wednesday
and
there's
a
docket
of
the
beer
ice
ice.
Extensions
is
actually
waiting
for
right
up
now
in
the
beer
working
good.
It
gots
it.
C
C
So
it's
it's!
This
is
very
early
on
and
what
we,
what
and
I
read
about
these
two
scenarios
where
grace
will
restart
wasn't
converging,
you
know
was
waiting
the
entire
gray
center
bolt
before
converging.
In
the
conversation
with
Vijay
and
anchor,
we
decided
went
back
and
forth
a
little
bit.
One
of
them
is
when
you
have
no
neighbors
on
an
interface,
in
other
words,
it's
a
stuff
interface
in
an
area
and
you
never
receive
your
pre
restart
LSA
to
check
against.
C
So
in
that
case
it'll,
you
know,
if
you
just
follow
the
spec,
it
will
prevent
you
from
converging.
I
mean
it
well,
it'll
won't
converge
and
you'll
wait.
The
entire
grace
interval,
which
the
default
I
believe
is
180
seconds.
So
what
this
enhancement
would
do
is,
if
you
have
an
interface,
you
don't
receive
any
OSPF
packets.
You
would
us,
within
the
dead
interval,
you'd
assume.
Okay,
this
is
a
stuff
interface
and
you
haven't
gotten
the
pre
l,
pre
restart
LSA,
any
other
interfaces.
You
would
just
say:
okay,
this,
this
area
is
converged
now.
C
What
we're
talking
about
now-
and
this
were
kind
of
early
on-
is
making
this
a
more
general
thing
where,
if
you
have
a
number
of
triggers-
and
you
don't
get
your
pre
restart
LSA
at
all
within
an
area,
then
you
would
assume
that
area
is
merged.
What
that
means
is
even
though
you're
getting
OSPF
packets
on
some
of
these
interfaces,
you
didn't
have
any
full
of
Jason
sees
you,
don't
have
any
routes
or
anything.
O
C
O
C
Yes,
we
have,
we
will
I,
have
some
ideas
on
this
kind
of
like
the
thing
about
when
you
can
get
rid
of
LSAs
that
are
maxed
aged
you,
never
get
rid
of
them
and
till
you
don't
have
any
neighbors
in
exchange
state,
so
you
could
use
some
rule.
We
haven't.
We
haven't
gone
through.
I
haven't
talked
to
the
co-authors
enough
to
generalize
this
case,
because.
C
O
C
The
second
one
is
the
situation
where
you
have
multi.
You
know
most
people,
although
the
the
the
two
RFC's
the
OSPF
and
v2
and
oh,
is
53
grace
for
restart
both
say
that
you
should
wait
that
you
should
terminate
graceful,
restart,
there's
any
topological,
topological
changes,
most
people
default
and
every
implementation
either
you
defaults
and
not
doing
strict
LSA
checking
well
in
this
case,
where
you're
not
doing
strict
al
is
a
checking
this
this
this
and
this.
This
would
we'll
have
some
more
discussion
on
this.
C
You
would
still
terminate
grace
for
restart
if
there
were
more
than
one
router
its
restarting
at
the
same
time,
because
there
are
situations
where
you
can
have
an
inconsistent
data
plane
and
that's
it
right
now.
This
is
just
an
informational
draft.
I,
don't
know
if
anybody
thinks
of
other
things
that
were
missed
from
the
other
from
the
original
OSPF
graceful
restart
drafts.
That
would
be
good
as
well.
Thanks.
N
Just
a
quick
update,
it's
actually
a
very
simple,
simple
extension
and
that's
really
using
the
LLS
to
send
an
interface
ID.
This
is
already
there.
This
similar
mechanism
is
already
there
in
OSP
of
v3
and
eyesize,
and
we
are
you
know,
proposing
to
do
similar
thing
for
OSP
of
v2
there.
There
were
some
concerns
raised
previously,
so
there
is
no
backward
compatibility
details
added
before
the
last
IETF,
that
is
with
RFC
4203.
N
C
Okay,
yeah
I'll,
say
I
was
just
gonna
say:
does
anybody
have
a
reason
why
we
shouldn't
request
I
ana
early
allocation?
Okay,
we'll
do
that
first,
I
mean
trying
gets
a
little
more
discussion.
Maybe
we've
had
enough
discussion,
but
there's
a
number
of
other
ones.
The
reason
I
wouldn't
work
last
call
I'm
really
trying
to
get
some
of
these.
This
older
work
done
first,
but.
C
F
F
A
P
M
O
Couple
of
AI
ATF's
ago
we
presented
separating
routing
planes
and
the
solution
we
used
was
to
use
the
algorithm
field
in
the
segment,
routing
seed
advertisements
and
advertise
separate
sets
for
each
algorithm
and
then
use
it
to
separate
routing
planes.
So
this
is
an
extension
and
this
this
has
the
generic
application,
where
we
are
trying
to
address
multiple
use
cases
using
a
similar
mechanism.
So
we
will
see
what
problem
space
we
are
trying
to
address.
O
O
So
the
high-level
solution
is
to
advertise
prefix
it's
based
on
algorithms,
so
this
algorithms,
the
specific
algorithms,
could
follow
different
metric
types
to
construct
paths,
for
example.
It
could,
you
could
use
te
metric
or
you
could
use
extended
te
metric,
so
algorithm
space
is
divided
into
two
separate
parts.
O
So
in
user-defined
algorithms
it
is
necessary
that
all
routers
must
consistently
define
these
user-defined
algorithms.
So
to
make
sure
that
in
case
there
is
a
configuration
mistake,
there's
a
possibility
of
loops
in
the
network
so
to
prevent
that
there
is
a
new
TLV
that
is
defined,
which
is
called
flexible,
algorithm
definition
TLV.
So
there
are
two
use
cases
uses
of
this
tlv1
you
can.
Every
node
can
advertise
this
sub
TLV
and
then
every
other
node
in
the
domain
can
compare
the
definitions
and
then
decide
if
there
is
a
conflict.
O
O
E
C
O
C
O
A
O
It's
just
giving
you
a
flexibility
of
defining,
not
making
it
standardized
like
I
can
say.
One
thirty
in
certain
network
can
say:
130
is
metric.
The
T
matrix
some
certain
other
domain,
like
certain
other
networks,
can
use
130,
which
metric
type
as
extended
te,
matrix
and
constraints
could
be
different.
So
so.
O
It's
not
only
metric
type,
you
can
also
vary
the
constraints,
so
there
is
also
sub
t
lv
for
constraints,
so,
like
130
can
say,
exclude
red
links,
whereas
131
can
say
say,
metric
type
and
131
can
say,
exclude
blue
links,
so
I
don't
know
if
you
can
call
it
as
two-dimensional.
But
if
it's
a
flexibility
you
know
I.
H
A
O
So
this
is
the
sub
TLV
of
floral
capability
TL.
We
wear
our
outer
advertisers.
It's
definition,
it's
its
configuration
and
here
are
the
details.
So
if
there's
an
algorithm
ID
and
this
metric
type
right
now,
only
these
three
metric
types,
SPF
or
externality,
metric
and
T
metric.
Only
three
values
are
supported
right
now
we
could
extend
it
as
in
then
there
is
a
lead
and
then
there
are
also
sub
T
Elvis
sub
T
Elvis,
we'll
see
later
in
the
later
slide.
They
are
mainly
used
for
defining
the
constraints.
N
Hi
this
is
drew
from
who
are
we?
Can
you
go
back
to
the
previously
yeah?
So
one
thing
when
I
was
reading
quickly
going
through
the
document
that
something
I
realized
that
in
Pisa
we
have
done
like
objective
functions
and
we
have
a
way
to
identify
the
metric
type.
So
I
would
say
that
if
you
could
refer
like
instead
of
redefining
those
things
because,
as
you
are
saying
constraints,
how
do
you
optimize
those
things
have
been
there
in
piece
up
for
a
while?
So
maybe
you
could
refer.
O
So
what
do
we
do
when
there
is
a
conflict?
So
let's
say
our
author
advertises
it's
a
flexible
algorithm
definition
TLV
on
the
other
router
and
it
receives
and
compares
this
algorithm
ID
with
the
with
with
other
routers,
and
there
is
a
conflict
then
it
should
not.
It
must
not
compute
an
install
path
for
that
algorithm,
and
it's
all
should
also
stop
advertising
support
for
that
algorithm
that
this
is
to
prevent
loops.
P
O
Explore
yeah
the
part
the
router
which
detects
the
conflict
will
stop
computing
for
this
Algar
see
the
basically.
The
idea
is
to
prevent
loops
and
mishandling
right.
I
mean
what,
if
one
router
does
some
mistake,
this
it's
it's
SPF,
computation
right
and
everything
can
go
wrong
if
one
router
doesn't.
C
N
O
The
issue
with
just
detecting
the
mistake
with
one
router,
so
you
so
there's
a
router
which
is
advertising.
You
have
to
compare
your
your
configuration
with
every
other
router
and
you
don't
really
know
which
all
routers
have
you
have
this
conflict
with
right.
So
whenever
you
you,
you
don't
know
whether
you
are
right
or
you
are
wrong
right.
So
so
the
moment
you
receive
you
find
something
flicked
and
you
just
stop
it
and
then
the
other
router
also
finds
the
conflict
and
he
will
stop
it.
O
O
O
So
the
another
possibility
is
advertising
flexible,
algorithm
definition
as
a
top-level
tle.
This
is
required
because
you
know
it's
laborious
to
go
and
define
this
algorithm
on
every
router
right.
If
you
have
constraints
to
go
and
configure
this
on,
every
router
is
lot
of
work.
To
avoid
that
you
have
this
centralized
controller
or
a
central
node,
where
you
can
do
the
configuration
once
and
advertise
it,
and
every
other
router
in
the
network
will
use
this
definition
to
compute
the
paths
for
that
algorithm.
So
in
that
case,
this
is
advertised
as
a
top-level
TLV.
O
This
flexible
algorithm
definition
TLB
nice
eyes,
so
there
could
be
local
definition
in
this
case
or
there
may
not
be
local
definition
in
case
there
is
a
local
definition.
It
is
going
to
compare
this
top-level
TLV
and
then
the
conflict
detection
would
happen,
but
if
there
is
no
local
definition,
then
the
receiving
node
just
accepts
this
configuration
and
uses
it
for
computation.
O
So
the
conflict
with
local
definition,
the
behavior
is
same
as
we
described
before,
and
then
there
is
this,
because
this
is
the
definition
that
is
being
pushed
on
to
the
routers.
We
need
this
to
be
leaked
across
levels
and
then
be
same
across
all
the
level,
so
the
leaking
behavior
is
computer
is
controlled
by
the
SMD
bits.
O
So
how
do
we
do
the
computation
for
flex
I'll
go
so
there
is
there's
going
to
be
a
separate
SPF
computation
for
each
algorithm
and
in
case
of
conflicts.
Then
we
should
not
compute
paths
for
that
particular
algorithm,
which
has
conflicts
the
way
we
do.
It
is
the
nodes,
so
every
node
advertises
what
algorithms
it
supports.
This
is
as
part
of
s
our
algorithm
TLV,
so
nodes
that
do
not
support
the
algorithm
are
pruned
from
the
topology
and
the
metric
pipe
that
is
specified
by
the
fa.
O
So
some
of
the
advantages
of
this
using
this
flex
algorithm
writes
it's
the
single
said
you
are
able
to
get
traffic
engineering
parts
within
your
network.
So
generally,
if
you
use
srte
you,
you
have
to
have
multiple
labels
and
build
up
a
stack
and
then
use
that
label
stack
to
forward
the
traffic.
This
mechanism
is
giving
you
a
single
label
which
can
be
used
to
get
traffic
engineered
paths.
O
So
there
is
inter
area
in
inter
level
support
with
IP
route
local
route
leaking
I
mean
you
can
easily
get
an
inter
area
or
inter
level
path,
using
flexible
algorithm
with
just
one
TLV.
Sorry,
one
label,
whereas
you
using
srte,
you
would
need
multiple
labels
and
if
you
want
to
use
RSVP
and
such
the
inter,
inter
area
or
inter
level,
would
be
a
difficult
thing
to
achieve.
Q
Yes,
so
in
theory
to
to
computer
a
bus,
you
need
a
suit
apologies,
for
example,
geometric
topology,
so
you're
extrude
Shelvey,
the
matrix
that
you
want
to
use
to
compute
under
so
the
algorithm
that
you're
going
to
use
them
on
with
SR.
We
as
a
field
of
algorithm
shortly
I
believe
we
have
to
SPF
strict
SPF.
Maybe
we
have
some
forum,
Artie
yeah
I,
don't
know,
but
maybe
what
is
missing
is
that
that
you
reintroduce
an
algorithm
field.
Q
O
So
we
don't
really
reuse
the
ones
which
are
standardized.
So
this
there
is
a.
There
are
two
categories
standard
base
to
0
to
127.
We
don't
use
those
for
user-defined
algorithm,
so
user-defined
will
be
only
from
128
to
255,
so
algorithm
ID
space
is
segregated
into
two
categories.
One
is
Ayana
standardized
and
the
second
one
is
a
user-defined,
so
we'll
use
only
the
user-defined
okay.
O
So
the
the
algorithm
ID
for
this
will
be
one
140,
maybe
you
say,
and
then
metric
type
will
be,
because
if
you
say
zero
metric
type
is
always
I
geometric.
And
if
you
want
to
use
te
metric,
you
have
to
say
you
are
going
to
use
an
algorithm
which
is
140
in
your
network
and
then
say
the
t
metric
type
for
this
algorithm
140
is
extended,
T
metric
or
whatever.
O
You
really
want
this
to
be
standardized,
then
that
is
possible
computation
and
other
things
will
remain
same,
but
you
have
to
go
to
Ayane
and
get
it
standardized
like
algorithm.
2
means
strict
SPF
with
metric
type
as
whatever
you
you
want,
my
as
a
metric
type
right,
like
maybe
extended
team
it.
If
you
wanted
standardized
you
really
it's
it's
not
going
to
affect
this
Draft
as
such
only
thing
is.
You
would
need
a
separate
draft
to
go,
standardize
that
that
values,
those
values.
It's.
N
Keith
ontological
Cisco,
so
what
you
say
is
possible
to
do
which
Plex,
algo
and
the
way
I
would
say
is
strict.
Spf
means
we
want
to
follow
the
SPF.
We
don't
want
to
do
any
author
out
or
IGP
shortcut.
So
by
definition
the
algorithm
follows
the
paths.
So
it's
not
going
to
go
over
something
like
author
out.
So
all
we
need
to
do
is,
let's
say:
I
pick
one
30
and
pick
T
metric,
and
there
is
no,
you
know
some
no
IGP
shortcut
or
no
author
out
coming
into
picture
or
these
flex
algorithms.
K
Q
O
O
K
K
G
K
Again,
to
come
back
to
what
drew
said,
I
think
it's
really
important,
as
we
are
defining
constraint
to
be
aligned
with
what
has
been
done
in
the
traffic
engineering
area.
Maybe
I
don't
know
if
it's
necessary
or
not.
It
is
just
an
idea.
Maybe
we
can
make
it
completely
flexible
to
be
able
to
add
existing
T
objects
or
something
that
are
reflecting
constraints.
E
C
Was
just
typing
some
of
the
minutes.
Odd
I
would
have
told
you
guys
before
but
I
read
it
on
the
plane,
I
thought
of
one
more
conflict.
You
need
to
handle
what,
if
you
have
a
multi-home
prefix
and
different
eius
eius
routers
advertise
it
with
different
algorithms,
and
so
you
can
compete
it
you're,
gonna
compute
it
multiple
times.
You'd
want
the
precedents,
a
precedence
of
these
algorithms
or
some
way
to
handle
this
case
where
the
multi-home
prefix
advertise
different
algorithms
buy
different
routers.
O
C
A
M
C
A
So
that
raises
an
interesting
question:
I
have
this
is
working
your
document
and
but
we're
talking
is
it?
Do
things
get
on
that
list?
I
can't
remember?
Was
it
I
Anna
allocated
or
no
yeah?
So
it's
being
added
into
the
working
group,
a
working
group
document,
even
though
it's
an
individual
work,
that's
an
end
drug.
C
C
C
It's
consistent
with
the
legacy.
It
maintains
the
same
model
as
today.
If
it's,
if
the
attributes
are
applicants
for
de
it
means
it's
enabled
for
the
other
applications,
it's
it
has
no
bearing
in
the
newer
applications.
Srte,
we
have
the
advertisement
of
attributes
for
that
application
doesn't
mean
it's
enabled
on
the
link
the
same
with
LFA
in
Flex
algorithm.
A
C
C
And
the
maximum
reservable
there
was
a
lot
of
discussion
and
decided
it
could
be
applicable
to
multiple
applications,
whereas
the
unreserved
bandwidth
could
not.
This
all
happened
within
the
last
month,
this
discussion
or
actually
the
last
three
weeks,
and
they
continue
the
discussion
and
hopefully
early
allocation
of
code
points.
A
It
so
the
next
the
next
slot
we're
doing
is
just
basically
discussing
the
enablement.
That's
that's
in
here,
so
we'll
I
think
we
can
discuss
the
general
aspect
of
enablement
there.
What
I
would
point
out
here
to
take
away
from
the
changes
related
to
that
is
that
this
new
version
is
proposing
to
use
what
we
had
before
with
RSVP,
but
in
a
well-defined
manner.
In
other
words,
the
presence
of
the
data
which
is
now
identified
with
the
application
is
going
to
implicitly
indicate
enablement
if
that's
required
by
the
protocol.
That's
the
solution
being
proposed
here.
A
The
other
solution
on
the
table-
that
is
an
adoption
call
right
now,
is
an
explicit
mechanism
that
decouples
the
data
from
the
enablement
right.
So
instead
of
having
the
data
imply
the
enablement,
we
would
have
a
TLV.
That
indicates
whether
something
is
enabled
or
not,
regardless
of
what
data
is,
is
available
for
that
application.
A
N
A
Okay,
so
all
right,
so
some
interesting
things
happened
right,
so
the
last
IETF
I'd
you
know
not
to
get
too
into
too
much
of
sausage.
Of
the
what
it
looks
like
what
watch
sausage
get
made,
we
had
all
the
authors
sit
down
and
there
was
a
real
cleared
agreement
that
we
weren't
going
to
do
in
ableman,
with
with
the
te
app
draft.
A
Everyone
in
the
room,
I
think
clearly
saw
that
we
could
continue
with
the
implicit
method,
but
they
we
agreed
to
not
do
that.
So
this
is
a
reversal
of
the
authors
on
the
that
draft.
It's
a
it's
a
flat-out
reversal
of
what
they
stated.
That's,
okay!
It
doesn't
have
to
be
pretty
in
the
mechanism
right
as
long
as
we
end
up
with
the
right
technical
answer
in
the
end
right
and
it
needs
to
be
pasted
on
the
technical
merit
of
the
solution
and
not
the
whatever
else.
A
A
Think
I
would
add
to
that.
Maybe
two
to
decouple
the
two.
The
data
and
the
enable
I
mean
that
kind
of
is
the
same
thing,
but
just
to
make
it
clear
and
the
case
against
that
has
been
mentioned
on
the
list
or
I've
gotten.
Some
private
email
was
that
we
just
continued
to
use
the
thing
that's
worked
so
far
worked
in
quotes,
but
now
we're
gonna
fix
the
problem
because
we're
labeling
the
data
specifically
for
RSVP.
So
now,
when
we
imply
the
RSVP
is
enabled
there's
no
confusion.
A
A
A
So
I
sort
of
had
three
questions
about
this.
I
think
we
need
to
ask
ourselves
is:
do
we
do
we
need?
Do
we
see
a
need
to
advertise
local
local,
locally
advertised
data
for
link
and
when-
and
we
don't
want
to
enable
on
that
link
right,
I
mean
if
we
have.
If
we
can
see
that
case,
then
we
need
this
draft
I
have.
C
A
A
The
LFA
is
it's
a
local
decision
right
so,
but
but
the
this
is
we're
thinking
about
right,
because
this
is
gets
to
the
crux
of
it
do
do
we
ever
need
these
things
to
be
separate
right
if
we
have
a
case
right
now,
the
decision
to
adopt
this
work
is
easy.
We
need
it
right.
If
we
don't
have
the
case,
then
the
question
is:
will
we
can
we
imagine
it?
Is
it
something
we
need
right
now?
A
A
One
I
can
imagine
that
because
I
guess
this
solves
this
problem
of
disambiguating
when
RSVP
is
enabled
or
not,
but
I
think
that
you
know
the
authors
of
the
autograph
would
say
hey,
but
we
need
to
identify
this
data
anyway
and
we
can
kill
two
birds
with
one
stone
with
our
Drive.
So
I
don't
know
so
I
think
you
know,
but
it's
it's
worth
thinking
about.
You
know
if
we,
if
you
could
imagine
deploying
one
only
or
only
needing
one
and
then
yeah
and
then
I
guess.
The
third
thing
is
this
has
been
very
controversial.
A
G
Can
you
imagine
deploying
only
one
of
the
drafts?
Yes,
I
can
certainly
imagine
only
deploying
the
te
protocols
draft,
because
there
is
no
good
demonstrated
use
cases
of
needing
the
same
value
for
the
same
link
for
different
applications.
At
this
point,
I've
tried
to
come
up
with
them.
You
might
be
able
to
come
up
with
something
related
to
srl
g's,
but
that
part
has
not
has
not
been
laid
out
here.
So
that's
that's
my
take
on
this.
So
stay.
A
There,
for
a
second,
so
in
this
case
we're
talking
about
sort
of
clearing
up
the
the
ambiguity
of
whether
RSVP
is
enabled
based
on
the
presence
of
the
values
they're
there
right,
because
the
like
in
your
in
your
K,
you
have
the
table
of
how
you
know
different
vendors,
make
that
determination
and
how
that's
it's
different
for
different
vendors
right.
A
G
We're
solving
that
problem,
which
is
a
demonstrated
problem.
That's
why
we
originally
published
that
draft.
It
is
perfect,
I
mean
that
draft
is
predicated
on
just
deploying
that
draft
and
it
solves
the
problem
and
the
multiple
values
for
the
same
link
for
different
applications
is
a
theoretical
problem.
At
this
point,
yeah.
L
L
L
L
And
that's
sorry
I'm
not
trying
not
they
were
not
making
a
big
point
of
it.
We
had
that
other
piece
of
discussion
I
just
want
to
make
sure
that
if
we're
talking
about
this
and
I
know
if
nobody's
interested
in
the
I
saw
the
same
stuff,
that's
happening
on
the
mailing
list
for
working
requests
for
a
working
group.
Adoption
calls
if
no
one
in
the
room
or
on
the
list
is
excited
about
it.
Then
that's
an
obvious
answer
and
it
doesn't
matter.
L
A
So
I
you
know,
maybe
we
can
reinterpret
the
the
second
question
because
and
I'll
give
you
the
thought
behind
where
my
brain
was
when
I
thought
it,
and
that
was
I
was
thinking
sort
of
as
a
vendor
in
that
case,
and
then
as
an
operator
right
so
like
which
one
of
these
drafts
is
actually
going
to
get
implemented
by
a
vendor
right
and
because
the
operators
say
we
need
this.
You
know
I
mean
I,
think
it's
worth
thinking
about
it
from
that
context.
A
Right
like
let's
do
useful
work,
because
the
honest
truth
is
that
both
methods
work
right,
I
mean
you.
Can
you
can
basic?
It
solves
the
both
both
methods
solve
the
problem.
There's
nothing
technically
wrong
with
or
technically
they
both
they
both
solve
the
problem
of
determining
whether
our
sweetie
is
enabled
on
the
link.
So
now,
as
a
working
group
chair,
I'm,
looking
and
saying,
okay
I've
got
a
fight
going
on
right
here.
A
I
got
people
fighting
with
each
other
over
which
solution
to
use
and
I'm
supposed
to
you
know,
get
the
working
group
to
make
a
technical
decision.
So
you
know
I
I.
They
both
technically
work.
So
I'm
a
little.
This
is
the
first
time
this
has
ever
really
kind
of
happened
to
me,
where
I've
had
two
people
fighting
both
had
technical
solutions
and
the
group
was
evenly
split.
N
A
Well,
so
that,
but
that
goes
to
the
my
question
of
you
know:
is
it
so?
Yes,
it's
a
problem
of
trying
to
solve
it,
operators
asking
for
this
or
is
it
problem
we've
identified?
That's
like
this
is
a
better
way
to
do
it
right,
like
I
said
if
them
I
wish
I
could
just
let
the
market
decide
on
this
one
right,
the
prow
with
doing
it.
That
way
is
that
then
I
would
say.
Okay,
let's
take
the
people
we
have
in
support
of
this.
A
Let's
adopt
this
work
and
let's
move
forward
with
both
with
the
you
know
the
enablement
being
solved
by
this
and
the
application
data
being
solved
by
the
other,
and
then
let
the
market
decide
which
one
or
both
right
the
problem
is,
is
that
now
we
have
the
first
draft.
Also
you
know
supplying
the
same
solution
or
a
solution
to
the
same
problem,
so
I
just.
C
I,
you
know
you
know
it
took
us
a
long
ways
to
get
to
this
and
there
were
a
lot
of
people
that
thought.
As
long
as
we
were
doing
this,
we
should
do
application-specific
values
and
there
were
use
cases.
Maybe
they
weren't.
You
know
pressing
that
they
need
the
problem
solved
right
now,
but
it's.
It
seems
a
little
bit
strange
to
read
a
question
that
requirements
given
where
we've
come
from.
Oh.
A
So
that
that
little
plant
grew
out
of
OSPF
right
and
into
is
is
oh
right,
because
you
guys
had
a
problem.
You
know
SPF
that
needed
solving
and
you
needed
to
separate
these
attributes
and
then
less
I
think
was
the
main
driver.
Saying
hey:
if
we're
going
to
do
it,
you
know
SPF
we
might
as
well
do
it
in
is
is
too
so
that's
how
we
got
here.
I
yeah.
C
A
N
Kate
internal
liquor
Cisco,
so
we
just
heard
about
flex,
algo,
right
and
I.
Think
as
that
idea
develops,
we
may
see
that
as
a
use
case
for
having
this
kind
of
power
application
signaling
there
was
some
come
and
all
that
so
I
really
think
the
working
group
draft
just
addresses
that
problem.
So
it's
good
to
yeah.
D
A
I
could
get
if
I
it
would
make
my
decision
really
easy.
If
the
answer
to
that
was
yes
right.
If
there
are
cases
where
we,
you
know,
we
needed
to
enable
something,
but
we
didn't
need
to
advertise
data
for
it.
That
makes
that
makes
this
a
really
easy
choice
right.
That
means
we
need
this
new
draft.
It's
new
work.
O
So
I
think
in
IETF
we
do
have
solutions,
different
solutions
to
the
same
problem
and
then
people
pick
and
choose
and
we
standardize
both
of
them
and
then
people
pick
and
choose
what
they
want
to
deploy
right.
I
mean.
If
the
people
are
really
interested
in
advertising
per
application
attributes,
then
you
have
a
solution
and
if
you
don't
want
to
do
that,
you
have
another
solution.
So
yeah.
A
O
O
G
Q
A
A
Q
We
know
the
kinda
range
I.
Like
your
second
question,
it's
useful,
so
advertising
application.
Specific
information
is
the
theoretical
requirement.
So
the
question
is:
are
we
going
to
have
a
really
real
implementation
and
widely
implementation?
If
not,
it
does
not
serve
as
a
problem
right
right.
If,
yes,
it's
it's,
it
looks
strange
to
have
a
wildly
implementation
of
something
with
the
reticle
requirement.
Q
A
K
A
G
Implementing
is
one
thing,
but
just
deploying
and
dealing
with
with
bugs
from
you
know,
Interop
is,
is
a
whole
other
issue.
So
I
yes
implementing
it's
it's
quite
straightforward:
either
either
approach,
but
actually
getting
it
out
in
the
field
and
and
working
in
production
is
all
other
thing.
Chris,
Powers,
juniper,
okay,.
A
So
if
moving
forward
I
I
think
we're
gonna
make
a
decision
on
this,
it's
gonna-
it's
not
going
to
be
now,
but
I
wanted
to
have
one
last
IETF
at
least
where
we
had
a
chance
where
people
give
to
the
mic.
That
might
not
mailing
list.
I
don't
know,
but
please
do
give
an
opinion
on
the
mailing
list.
If
you
have
one
and
especially
about
these
two
questions,
if
you
have
an
answer
to
these
two
questions,
that
would
be
useful.
I.
C
C
A
Okay,
I
think
I
think
that's
all
the
comments
that
I'm
gonna
get
you
weren't
here.
When
we
talked
about
the
merging
we
are
we
we
can
recover
that.
That's
all
that
we're
going
to
talk
about
other
than
reemerging
for
Allah's
sake
of
merging,
not
reemerging.
So
what
being
a
Zeebo
said
that
we,
and
previously
we
were
very
of
against
the
idea
and
now
we're
not
as
much
against
the
idea.
A
It'll
be
interesting
to
go
and
contemplate
what
happened
here
during
this
meeting
that
we
just
held
there
I
think
there
was
a
couple
dynamic
moments
where
it
was
useful
to
have
everyone
in
the
same
room
with
the
chairs
both
sitting
up
at
the
top
I,
also
expressed
that
if
I
had
drawn
the
OSPF
working
group
this
time,
because
AC
didn't
make
it
that
they
would
scare
me
and
what
that
implies.
Is
that
there's
a
lot
more
work
when
you
only
have
two
chairs
and
the
two
and
the
two
protocols
to
do
so.
L
Oh
yeah
Atlas,
yes,
I,
hear
you
on
the
chairing
work
and
that's
something
we
can
discuss
a
bit
offline,
there's
other
ways
of
handling
that
piece
as
well.
We
have
a
number
of
working
groups
that
actually
do
have
three
chairs,
for
instance,
and
there's
flexibility
there
there's
going
to
be
a
learning
curve
for
the
cross,
the
intersection,
but
it's
the
question
I
have
for
the
room
is
how
many
people
would
be
here.
If
this,
for
only
is,
is
sorry,
sorry,
the
question
is:
who
would
be
in
the
room
if
this
were
the
is?
L
L
A
It
was
less
that
was
less
than
the
number
of
people
that
raised
their
hand
for
who
would
be
both
in
the
same
room
right
so
to
that
and
even
I
didn't
you
know,
I'm
not
reading
all
the
OSPF
graphs
right
that
I
mean
I.
I
have
been
extra
busy
with
other
things
during
this
last
segment.
But
you
know
yeah
I,
wonder
how
many
people
would
how
many
people
out
there
would
only
be
reading
one
protocols
mailing
list,
so
something.
L
Okay,
so
I
think
and
we're
going
to
talk
about
it
and
figure
out.
Cuz
I
do
hear
you
on
the
chair
bandwidth
problem,
but
I
also
don't
see
the
room
being
overly
full
for
having
a
good
conversation
and
having
a
working
group
with
a
good
culture
is,
has
had
a
great
cultures
working
group
and
so
as
OSPF
and
I
think
that
most
of
you
are
used
to
participating
and
being
in
both
of
them.
R
A
L
But
I
obviously
care
deeply
that
it's
effective
for
the
protocols
I
mean
this
is
the
backbone
of
the
internet.
You
know
this
has
been
and
every
not
just
the
internet,
but
everyone's
networks
and
the
protocols
matter.
So
much
and
one
of
the
points
of
merging
the
two
working
groups
is
to
share
knowledge
and
expertise
and
to
grow
the
number
of
people
who
are
maybe
interested
in
participating
and
understanding.
L
L
C
A
A
L
L
I
mean
it
go
solution.
Is
how
many
syllables
do
you
want
to
have
to
pronounce?
Why
don't
I
what?
Why
don't
focus,
as
we
have
a
single
list?
Why
don't
send
suggestions
to
the
mailing
list
and
not
that
it's
going
to
bias
my
our
decisions
in
terms
of
what
acronyms
use,
but
if
you
have
a
preferred
bride
of
chocolate
versus
is
so
that
we
understand
the
cost
associated
with
the
acronym?
That
would
be
useful
to
leave.