►
From YouTube: IETF99-ISIS-20170717-1330
Description
ISIS meeting session at IETF99
2017/07/17 1330
https://datatracker.ietf.org/meeting/99/proceedings/
A
You
you
take
notes
in
either
pants
I
can.
B
C
E
A
A
So
here's
the
note
well
I,
guess
part
in
bold
I'm
supposed
to
read
like
you're
participating
with
the
ITF.
You
agree
to
the
following
idea
of
process
and
policies.
If
you're
aware
that
any
contribution
is
something
written,
Saturday
closing
IETF
context
is
provided
by
Heather
covered
by
patents
or
patent
applications.
You
must
disclose
the
fact
or
not
participate
in
the
discussion.
You
understand
that
meetings
might
be
recorded
or
broadcast
audio/video
photographed
and
public,
archived
and
other
details
are
covered
in
this
okay.
A
So
the
agenda
bashing
well,
I,
have
one
item
on
this:
Russ
White
was
going
to
predict
was
going
to
present
the
open
fabric
is.
Is
he
also
just
did
that
in
routing
working
group?
So
I'm
curious?
What
the
number
of
people
that
were
just
in
writing
working?
You
saw
that
presentation
raise
your
hands
and
who
has
not
seen
that
presentation.
Okay,
rust!
You
got
no
there's
two
to
four
and
a
lot
seen
it
so
I
think
your
last.
So
everyone
else.
A
F
A
Okay,
so
the
document
status
portion,
so
we
have
to
RFC's
that
went
forward,
auto
configuration
and
multi
instance
the
biz
adaption
there
that
allows
for
multi
instance
well,
multi
topology
in
multi
instance
I
size
and
also
my
little
tool
kicked
out.
Five
three,
oh
nine
and
I
was
like
didn't
think
that
that
was
a
new
RFC
and
I
had
to
ponder
why
that
was
there.
It
was
there
because
we
had
a
rata
publish
on
it.
G
A
A
I
A
A
A
H
A
The
ADEs
want
to
combine
the
iGPS
well
I'm,
sorry,
I'm
not
allowed
to
refer
to
them
as
the
IGP
is
the
link
state,
IG,
peas
and
go
ahead
go
to
the
next.
So
the
I
asked
the
you
know
for
clarification.
Why
do
you
want
to
do
this?
What
problems
are
we
solving
and
we
came
up
with
these
couple
problems,
so
it
gives
it
an
exposure
to
more
experts
like
where
there
isn't
overlap.
A
We
get
some
new
blood
into
both
groups
and
and
both
in
more
people.
Looking
at
the
problems
faces
that
they
face,
there's
less
duplicated
overlap,
work,
I,
think
it's
the
one
that
kind
of
drives
this,
as
everyone
seems
like
the
segment
routing
extensions
drafts
that
are
literally
duplicated,
almost
copy
and
pasted
into
both
protocols.
Specs,
we
didn't
you
last
time
this
came
up.
We
didn't
have
that
as
much.
A
We
had
a
lot
of
the
trill
work
going
on
and
we
had
so
when
I'd
ran
the
sort
of
stats
on
that
we
were
only
overlapping
like
20%,
like
I.
Haven't
done
that
yet
for
this
time
around
I
will
I
suspect
the
number
of
overlaps
are
higher,
so
it
does
I.
Guess
it's
useful
to
look
at
it
again.
The
issues
that
I
saw
with
this
that
I
put
in
here
and
are
the
groups,
have
different
audiences,
typically
OSPF.
That
covers
a
lot
much
larger
audience
and
a
number
of
people
are
a
number
of
uses.
A
You
know.
Tier
one
is
yes,
I
mean
the
how
you
adopt
changes
and
how
quick
you
can
make
changes.
Things
like
that
are
maybe
a
little
different
and
also
it
may
influence
the
choices
to
be
the
same
so,
whereas
in
before
it
might
have
been
easier
to
pick
a
different
route
for
the
the
protocols
or
because
we
operate
in
these
different
spaces.
I
think
that
that's
gonna
be
less
doable.
A
If
we're
in
a
combined
group
and
I
think
it's
good
want
is
gonna
be
come
up
with
a
single
solution
for
both
I
think,
that's
gonna
be
the
the
general
intention.
Most
of
the
time
it
may
be
harder
to
get
one
work
done.
Trying
to
convince
the
other
side.
I
mean
some
people.
Some
people
are
I
as
I
spoke,
some
fellows
get
folks
and
they
think
about
things
differently,
and
we
make
into
these
arguments
that
we
wouldn't
have
gotten
into
before,
and
there
are
for
some
people.
A
They
don't
go
to
both
groups
right
they're,
not
interested
in
both
protocols.
So
this
does
create
more
work.
We
can
do
I've
got
time
in
for
talk.
So
let
me
just
finish
this
last
slide
so
buy
more
work.
You
can
see
that
that's
already
going
to
start,
because
the
proposal
that
I
negotiated
with
Dahlia
was
that
we
would
run
a
joint
session
next
time
and
that
we
would
combine
the
mailing
lists.
A
A
I
So
low
and
aresome
can
you
go
back?
One
slide.
I
want
to
actually
challenge
the
let's
duplicated
overlap
work
because
you
are
extending
the
protocol
separately,
so
you
actually
do
the
same
amount
of
work.
Now
we
do
it
in
two
working
groups.
The
yonk
working
group
would
have
to
do
it
in
two
separate
documents
and
it's
not
a
given
that
that
is
actually
less
work,
because
the
confusion
between
the
two
graphs
is
potentially.
I
Getting
more
confusion
between
the
documents,
if
you
have
notice
aimed
at
the
table
at
the
same
time
so
and
especially
the
TE
extension,
we
have
seen
quite
nice
work
between
the
gmpls
MPLS
working
groups
and
the
separate
protocol
world,
but
for
working
groups.
So
I'm,
not
everything
else,
I
think
it's
fine,
but
the
training,
less
duplicated,
work,
I,
don't
think
it's
a
good.
A
I
think
you're,
suggesting
it's
more
subtle
than
that
there
there
is
there's
still
gonna,
be
some
overlap,
because
we
can
publish
one
draft
and
have
two
sections
eyes
eyes
and
OSPF
in
it
with
any
kind
of
duplicated
work
or
descriptions
above
it
the
benefit
there.
I
do
see
I'm,
not
all
for
this
idea,
but
but
the
benefit
there
is
that
you
do
have
one
place
of
the
high-level
description
of
what
you're
trying
to
do
right
and
then
you
literally
keep
the
mechanics
down
to
just
the
mechanics,
putting.
I
J
A
J
K
So
I
would
like
to
point
out
there's
a
single
instance.
I'm
aware
of
of
a
common
draft
between
OSPF
knives
is,
which
is
the
point-to-point
over
Ethernet
broadcast
thingy
I.
Think
that's
both
a
positive
thing
in
telling
us
that
it's
possible,
but
also
ordinary
on
that
simple,
like
it
needs
to
be
that
simple
to
be
possible,
but
also
I,
think
there's
a
misunderstood
in
terms
of
areas,
because
my
personal
experience
with
operators
is
that
it
doesn't
matter
what
the
use
case
is
to
decide
what
protocol
they
use.
K
It
matters
what
they
as
a
person
really
started
with
and
are
comfortable
of
it
and
I
know
a
lot
of
people
who
run
eius,
eius
and
smaller
networks.
It's
not
not
a
large
chunk,
but
still
I.
Don't
think
this
is
valid
to
make
us
an
assumption
that
protocols
are
this
clearly
delineated
in
usage
space.
Well,.
A
That
is
so
David
I
I
I
hear
what
you're
saying,
but
those
the
small
groups,
I
think
are
enthusiasts
right.
I
mean
they
they're,
not
people
that
are
coming
to
IETF
and
doing
routing
protocol
urging
console
I'm,
not
saying
they're,
not
important,
but
OSPF
I
think
has
a
wider
scope
of
users
different
types
of
users
so.
K
B
E
A
I
I
don't
think
that
it's
a
just
that
that
would
be
in
the
the
Charter
work
and
I.
Don't
think
that
we
would
charter
ourselves
with
the
goal
of
making
the
protocols
feature
that
paired
reaching
parity
and
all
features
and
not
in
doing
gap,
analysis
and
stuff
I
think
it
would
just
literally
be
running
them
together.
So.
E
L
L
Granted
we're
gonna
have
enhancements
like
all
the
data
center
flooding
optimizations
that
maybe
maybe
I
mean
I,
think
it
might
be
make
sense
to
do
them
in
one
protocol
first
and
then,
if
they're
successful
and
adopted,
then
you
know
do
it
in
the
next
protocol,
but
I
I,
don't
think
in
terms
of
things
you
can
do.
I
think
you
can
do
you'll.
Do
it
in
a
different
way,
but
you
can
do
any
anything.
You
needed
protocol
okay,.
M
I
definitely
support
this
idea
of
merging
the
working
groups.
Of
course
there
is
some
not
fully
aligned
audience
between
them,
but
it's
not
a
first
group
which
would
have
people
terrorists
in
some
topics
and
not
others.
I've
been
in
attending
teas
for
some
time.
For
some
of
the
topics,
not
all
there
are
people
involved
in
LDP
in
MPLS,
not
in
their
SDP.
There
are
various
working
group
already
current
multiple
protocols
with
missile
audience.
It's
not
an
issue
at
all.
On
the
other
hand,
it
could
also
be
beneficial
because
sometimes
people
get
lazy.
M
M
A
F
G
E
J
On
a
per
application
basis,
which
links
have
advertisements
that
are
to
be
to
be
used
by
a
particular
application,
note
that
this
is
not
enabling
an
application.
It's
not
an
indication
of
whether
the
application
is
enabled
on
the
link.
It's
an
indication
of
whether
the
advertisements
are
to
be
used
by
a
particular
application.
J
We
want
to
be
able
to
advertise
per
application
values.
We
want
to
have
efficient
encoding,
so
there
are
certainly
deployment
cases
where
the
same
values
on
a
given
link
can
be
used
by
multiple
applications.
We
don't
want
to
have
to
a.
Needless
when
you
advertise
the
same
value
twice,
we
want
to
be
able
to
support
incongruent
apologies,
meaning
that
there's
a
subset
of
the
links
in
the
given
topologies,
where
a
particular
application
wants
to
use
the
advertised
values
and
another
application.
They
want
to
use
the
values
advertised
on
a
different
set
of
links.
J
We
want
this
to
be
easily
extensible.
We
have
three
applications,
standard
applications
defined
at
the
moment,
perhaps
a
few
years
from
now
we'll
have
five
or
six.
Who
knows
we
don't
want
to
have
to
revise
the
protocol?
When
that
happens,
we
want
to
be
able
to
support
partial
deployment
and
have
this
be
backwards
compatible.
J
So
this
is
covering
mostly
the
changes
that
have
occurred
since
the
last
ITF.
We
got
a
bunch
of
comments
that
said,
in
addition
to
standard
applications,
we'd
like
to
be
able
to
support
user-defined
applications,
so
we've
redone
the
format
of
the
TLV,
and
we
now
have
a
standard
application
pit
mask
the
user-defined
application
pit
mask
and
the
lengths
of
each
mask
before
we
actually
advertise
the
the
applications
themselves.
J
J
J
J
J
If
you
have
multiple
applications,
one
of
them
as
rsvp-te-
and
you
have
common
attributes
and
comment-
apologies
for
both
applications.
Then
you
use
the
legacy
advertisements.
You
advertise
the
new
sub
TLD,
with
the
set
of
applications
to
which
those
advertisements
link
attribute
advertisements
apply,
and
you
indicate
that
you
there's
a
bit
in
there
that
you
indicate
I
want
to
use
the
legacy
advertisements.
J
A
J
A
J
J
A
A
J
You'll
see
that
in
the
application
identifier,
we
have
the
length
with
a
flag,
so
it
gives
you
the
length
of
what
are
these.
Let's
say
the
standard
applications,
whether
you
use
defining
application.
How
many
bits
are
you
advertising
and
you
have
a
flag
that
says:
I'm
not
going
to
actually
advertise
any
link
attribute
specific
to
these
applications.
I
want
you
to
use
the
legacy
you.
A
Know
I
understand
that,
but
that's
not
what
I
was
saying.
What
I
was
saying
was
that
if
you,
if,
if
the
default
is
to
use
the
legacy,
then
you
all
you
need
to
be
able
to
do
is
say
what
doesn't
use
the
default
right,
because
if
you
don't
say
what
doesn't
use
the
default,
so
everything
uses
the
default.
Unless
you
tell
it
not
to
yeah
yeah
and
that's
a
fundamental
difference
between.
J
D
Feeling
from
Cisco
so
I
guess
the
difference
is
that
we
always
specify
the
set
of
attributes
that
you
want
to
use.
We
never
fall
back
right
unless
you
say
Elbit,
which
means
everybody
is
default,
but
if
you
advertise
something
for
a
specific
set
of
applications
or
for
an
application,
and
you
have
to
specify
all
dealing
attributes.
J
Have
a
paradise
meant
not
the
negative
one
unless
you
have
explicit
indication
of
which
for
each
application,
whatever
ties
mints
are
to
use
whether
their
legacy,
advertisements
or
the
new
advertisements,
then
you
have
no
way
of
saying
gee.
I
have
a
bunch
of
legacy
advertisements
on
this
length
and
I
do
not
want
this.
Is
this
application
to
use
them?
Do.
A
J
A
J
A
J
Yeah,
one
of
the
keys
is
to
understand
number
one,
we're
not
talking
about
enablement,
we're
talking
about
using
a
set
of
advertisements
and
we're
saying
for
a
new
application.
We
are
not
making
the
assumption
that
your
your
all
of
the
links
for
which
rsvp-te
advertisements
are
being
made
are
also
useful
for
this
new
application.
J
J
G
G
J
Know
we
could
deviate
on
this
for
a
good
while
I.
Don't
think
that
description
is
accurate.
One
of
the
reasons
that
the
extended
reach
ability
tlvs
were
indented
was
because
the
old-style
metrics
were
too
limited.
You
know,
1
to
63
was
just
not
enough
range
for
us
and
how
you
migrated
is
one
thing,
but
the
eventual
goal
of
migration
was
now
I.
Have
a
much
bigger
metric
space
to
play
around
with
the
goal
wasn't
to
stay
within
63,
so
I,
don't.
G
G
J
Would
say
that
the
the
scenario
you
are
describing
is
not
at
all
analogous
okay,
we're
talking
about
two
different
applications,
we're
talking
in
this.
If
we
use
the
examples
of
our
CPG
in
srte,
there
is
no
requirement
that
says
you
must
run
both
of
these
on
the
same
set
of
wings.
That's
completely
different
than
running
is
is,
and
advertising
reach
ability
in
two
different
ways.
So.
J
J
So
the
easiest
way
to
understand
this
is
to
use
the
example
of
LFA
I
advertise
link,
attributes
for
use
by
LFA.
Maybe
some
note
five
hops
away,
based
on
what
I
advertise
decides
which
LFA
he
prefers.
That
says
nothing
about
whether
locally
I'm
using
that
link
for
repair.
That's
based
on
a
completely
different
configuration.
J
J
Ok,
so
again,
this
is
the
deployment
case.
You
have
two
applications.
They
are
using
the
same
set
of
advertisements.
What
you
do
is
you
use
the
legacy
advertisements,
because
one
of
the
applications
is
RTP
te
and
you
include
this
new
sub
TLD.
That
says
your
srte
is
using
the
legacy
advertisements
on
this
link.
You
do
not
have
to
duplicate
the
actual
link
attribute
advertisements
themselves,
which
is
what
takes
up
all
the
space
there's
a
case
where
you
have
multiple
applications
and
at
least
some
of
the
attributes
are
not
shared
with
rsvp-te
and/or.
J
There
are
some
links
that
you
want
to
use
for
the
new
application.
You
don't
want
to
use
that
link
for
our
CP
te.
You
again,
you
use
the
legacy
advertisements
for
our
CP
te.
You
use
the
new
advertisements
in
this
case
you
set
the
L
bit
as
clear,
meaning
I'm,
not
using
the
legacy
advertisements
for
the
new
application
and
in
those
cases
where
your
link
attributes
are
the
same
on
a
particular
length,
you
do
have
some
duplication.
J
These
are
a
few
examples
of
use
cases
that
hasn't
changed.
There
is
an
alternative
proposal
and
Chris
is
going
to
speak
to
that
way
back
at
IETF
97.
We
at
least
all
did
agree
that
we
want
one
solution,
we're
talking
about
this,
both
in
OSPF
NIS
is
and
whatever
we
decide.
We
want
both
working
groups
to
follow
the
same
solution.
J
M
J
So
this
is
the
comparison
between
the
solution
described
both
in
in
the
Ginsburg
draft
and
the
Senate
draft,
and
the
comparison
against
the
there's,
a
pair
of
eius
eius
drafts
for
the
equivalent.
The
second
draft,
the
T
attribute
set
draft
just
came
out
pretty
recently
there
isn't
an
equivalent
in
OSPF
yet
but
I'm
assuming
you
would
do
the
same
thing.
You
know
SPF
if
you
are
moving
ahead,
so
this
is
sort
of
a
comparison
of
again.
J
J
J
J
And
then
we
get
into
the
backwards
compatibility
and
partial
deployment.
In
the
case
of
our
draft,
there
are
no
backwards
compatibility
issues.
You
can
do
partial
deployments.
You
have
to
do
absolutely
nothing
on
the
legacy.
Routers,
there's
no
configuration
changes.
You
do
have
to
be
careful
on
the
new
routers
as
to
how
you
advertise
things
given
examples
of
that,
but
for
the
legacy,
routers
is
absolutely
no
changes
required
whatsoever.
In
the
case
of
the
alternatives.
J
J
The
other
important
point
relates
to
BGP
LS
controller
support.
Part
of
the
alternative
solution
is
to
get
away
from
standard
knits
assignments
for
applications
and
to
have
this
all
defined
at
runtime
via
configuration,
which
makes
it
very
difficult
indeed
for
bt
pls
to
support
this.
So
with
that
I,
don't
know
how
you
want
to
run
this
yeah.
A
N
O
H
H
N
I'm,
not
worrying
error,
Zippity
mm-hmm,
so
I
don't
have
any
issue
with
inconsistency
between
LF.
They
advertisement
or
RC
BT
advertisement
right
and
with
this
proposition.
Do
we
have
to
be?
Would
I
have
any
interrupts
issue
or
new
things
to
advertise
in
the
deep
AGP,
or
can
I
still
advertise
the
t's,
a
regular
or
historic
tea
advertisement.
J
If
you're
start,
if
you
have
a
deployment,
for
example,
where
let's
say
year,
you
fully
deployed
Sr
you're
using
srte,
but
because
today
we
have
no
way
to
advertise
link
attributes
other
than
the
legacy.
All
of
your
boxes
are
using
legacy
advertisements
for
SRTP,
yes,
okay,
so
in
this
case,
if
you
have
partial
deployment,
if
you
upgrade
party
or
network
to
support
the
new,
then
you
have
two
choices.
J
One
is
you
can
continue
to
use
the
legacy
advertisements
everywhere
and
you
can
set
the
legacy
bit
for
the
new
applicant
for
the
new
boxes
to
say,
use
the
legacy
advertisements
and
you
only
advertise
legacy
or
you
can
sort
of
prepare
for
the
your
eventual
migration
to
completely
upgraded
set
of
routers,
and
you
can
advertise.
You
can
duplicate
the
advertisements
with
the
new
advertisements
and
the
legacy
you
have.
You
have
both
of
those
choices
available
to
you.
A
M
A
J
B
Yes,
so
this
is
the
draft
that
we
first
published
in
fall
of
last
year
and
we
presented
in
Seoul.
It
deals
with
this
one
sort
of
very
clear
use
case
that
that
les
has
referred
to,
but-
and
it
does
so
in
a
very
straightforward
manner-
by
advertising
the
protocols
that
enable
are
enabled
on
a
link,
so
it
aroud.
This
is
the
same
use
case
that
we
described
in
the
draft
and
we've
described
before,
but
I'll
review
it
again
because
it's
been
talked
about
quite
a
bit.
B
So
the
actual
use
case
that
that
drove
this
was
this
proposal
is
where
you
have
a
centralized
SR
controller
for
doing
traffic
engineering
and
it's
learning
about
the
network
either
via
the
IGP
or
bt
pls
learning
from
the
IGP,
and
it
needs
to
know
the
configured
bandwidth
on
the
network.
The
maximum
link
bandwidth
attribute
so,
which
is
quite
reasonable.
They're
all
shown
there.
This
advertisement
from
from
Y
says:
ok,
the
link
from
why
does
he
has
30
gigs
of
bandwidth
now.
B
Thank
you.
If
it's
just
an
SR,
only
network,
there's
there's
no
issues.
If
there's
an
RSVP
only
network,
there's
no
issues,
even
if
you
have
an
RS
and
SR
and
an
RSVP
Network,
where
they're
congruent,
essentially
SR
and
RSVP,
are
all
enabled
on
the
same
links.
There's
there's
no
issue,
however,
if
you
have
SR
on
some
links
and
RSVP
on
other
links,
then
you
can
can
run
into
a
problem,
because
if
you
also
have
RSVP
running,
how
does
our
SV
existing
RSVP
ingress
routers?
B
Do
I
decide
to
include
this
link
in
the
SI
SPF
computation
for
computing,
our
CP
signal
LSPs,
and
so
this
is
the
set
of
implementations
with
their
origins
obscured,
and
it
turns
out
that
you
know
we
weren't
lucky
here
that
people
decided
on
different
things,
and
so
you
know
you
can't
just
say
well,
you've
never
defined,
but
everyone
did
the
same
thing.
There
is
no
de
facto
standard
here.
B
You
know
it
will
fail
the
signaling
and
then
they'll
figure
out
and
try
something
else,
but
that
extra
signaling
is
is
not
good.
So
we
wanted
a
very
direct
indication
of
what
protocols
are
enabled
on
that
link,
in
particular,
if
RSVP
is
enabled
on
that
link.
Sort
of
clear
up
this.
This
lack
of
a
standard
way
of
deciding
that
so
there's
a
short-term
workaround,
which
is
pretty
straightforward,
which
is
using
admin
groups.
Basically,
in
this
example,
you
know
suppose
that
RSVP
is
not
enabled
on
all
those
links
on
the
left
and
red.
B
B
You
include
that
in
your
constraints
for
a
CSP
F,
which
is
straightforward
to
do
and
in
all
implementations
that
I
know
of
and
that
will
solve
this
problem
in
the
short
term
in
the
long
term,
straightforward
te
protocol
sub
TLB
seems
to
make
the
most
sense
for
this
use
case.
We
specifically
say
we.
We
introduced
this
new
te
protocol
sub
TLB,
which
has
a
bit
that
says:
RSVP
is
not
enabled
or
RSVP
is
enabled,
and
then
we
don't
have
to
worry
about
these
different
implementations
so
long
term.
B
This
seems
like
a
reasonable
approach
to
having
a
link
advertised
exactly
what
it
is
capable
of
supporting
it
can,
in
this
case
it
can
support
RSVP
signaling
to
address
this
use
case
proposed
encodings
are
pretty
straightforward:
it's
a
new
sub
TLB
inside
of
TLB
22
and
the
appropriate
v6
and
MTA
multi-chip
ology
versions,
and
it
basically
at
this
point
defines
two
flags:
an
RSVP
flag
and
a
segment
routing
flag.
Now,
we've
gotten
some
feedback
on
this
proposal
about
the
precise
interpretation
of
the
segment
routing
protocol
flag.
B
B
So
that
seems
like
a
valid
concern.
We
think
there's
a
valid
use
case
for
this
segment
routing
flag,
since
it
can
be
useful
for
an
ingress,
router
or
a
centralized
application
to
know
whether
or
not
it
should
actually
be
expected
to
be
able
to
forward
traffic
over
over
a
link
using
labels
distributed
with
sr.
So
it's
useful
information
so
to
address
this
concern.
We're
proposing
to
describe
this
valid
use
case
and
also
explicitly
say
that
the
presence
or
absence
of
this
sr
protocol
flag
doesn't
affect
the
SR
topology.
B
In
particular,
it
doesn't
affect
the
shortest
paths
computed
on
the
topology.
So,
with
the
original
version
of
lesses
te
app
draft
I
thought
these
two
are
actually
in
in
conflict.
That
is,
but
the
latest
versions
have
made
clear
that
he
doesn't
want
to.
His
draft.
Does
not
the
the
advertisements
don't
say
anything
about
enablement?
B
This
is
a
clear,
so
I,
don't
think
these
two
graphs
actually
conflict.
The
following
draft
is
in
conflict
with
lesses
and
I.
Think
is
a
an
alternative
proposal,
but
but
this
draft
isn't
in
conflict
with
lesses
I
believe
so
as
a
step
forward,
we'd
like
to
publish
the
updated
version
with
the
text
that
addresses
these
concerns
about
the
SR
flag
and
request
the
chairs
to
start
a
working
group,
adoption
poll
so
that
that's
it
on
the
te
protocols
bit
basically.
Q
B
P
B
You
can
prune
the
topology
and
I
mean
that's
done
all
the
time,
but
different
implementations
so
back
in
this
in
this
version
here.
So
so
in
this
slide
here,
it's
RSVP
is
on
those
those
links
that
aren't
read.
Okay
and
RSVP
supports
that
segment.
Routing,
really
the
segment
routing
topology
and
the
IGBT
apology
are
are
congruent
so.
P
Congruence
and
coloring
you,
what
we
are
talking
about
is
multiplication
attributes
for
a
single
link
and
how
you
music,
for
your
computation,
is
a
different
matter,
but
you
are
fundamentally
looks
like
descript
or
conflict
is
really
about.
How
do
we
make
support
income
grow
and
topologies?
But
it
is
not
a
problem.
So
there's.
B
P
B
P
B
B
J
This
is
something
we
agree
on.
What
all
of
these
drafts
are
talking
about
is
a
particular
set
of
applications.
We
use
traffic
engineering
in
particular
we're
not
talking
at
all
about
modifying
the
base,
IGP
topology
and
how
the
the
standard
IGP
SPF
has
calculated.
That's
not
in
scope
for
any
of
these
drafts.
I
hope
we're
in
agreement
on
that.
Yes,.
B
L
Acey
Linda
and
for
4sr,
if
you're
using
the
base
algorithm
the
base,
it
is
the
IGP
topology,
you
know,
I
mean
I
mean
there's,
there's
there's
tweaks
you
can
make,
but
if
you're
just
doing
base
segment
routing
the
that
the
base
algorithm
includes
everything.
That's
tonight
defeat
apology,
correct,
correct.
Q
How
do
you
see
that
so
previous,
like.
Q
G
H
Q
B
Depends
on
on
the
customer-
and
you
know,
there's
a
lot
of
extra
configuration
involved
long
term.
They
would
rather
not
have
to
worry
about
it.
It's
you
know
things
that
are
transitional,
often
end
up
lasting
for
a
long
time
and
so
kind
of
leaving.
This
festering
might
not
be
such
a
such
a
good
idea
and.
Q
B
B
So
actually
a
a
scenario
is
what
you
had
a
link
that
never
had
RSVP
on
it
that,
but
you
wanted
to
get
RSVP
in
some
part
of
your
network,
get
a
link
that
never
had
RSVP
on
it,
and
you
wanted
to
be
able
to
advertise
the
bandwidth
for
that
link
that
that's
kind
of
a
problem
where
this
this
solution
is.
The
workaround
is
sort
of
less
desirable.
G
B
G
B
B
So
at
this
point
you
know
the
most
concrete
use
case
for
the
ability
to
advertise
different
values
of
the
same
link
attribute
in
such
a
way
that
different
applications
can
use
those
different
values
on
the
same
link.
At
this
point,
the
most
concrete
use
case
that
I
can
identify
from
a
real
customer
network
is
allowing
applications
to
use
different
sets
of
S
or
LG's.
B
So
we,
my
co-authors
and
I,
adopted
the
you
know,
took
a
look
at
les
as
draft
and
see
some
issues
with
the
way
that
it
is
the
encoding
sort
of
require
you
to
eventually
deprecated
the
existing
te
link
attribute
advertisements,
and
we
think
that
the
use
cases
so
far
presented
for
this
and
identified
for
this
really
don't
justify
that
approach.
So
we
came
up
with
a
different
approach
that
doesn't
require
deprecating
the
existing
advertisements
and
it
fits
in
nicely
with
the
existing
framework.
B
B
B
So
we
actually
treat
te
attributes
and
SR
LG's
using
the
same
basic
mechanism,
but
but
they're
slightly
different
because
of
the
way
that
SR
LG's
are
kind
of
an
additive
attribute.
Typically,
you
want
many
SR
LG
is
associated
with
a
link
and
whereas
the
te
attributes
for
a
given
T
key
attribute,
there
is
one
value:
there's
not
multiple
values.
B
So
that's
the
TE
attribute
set
with
ID
0
you'll,
see
that
this
is
very
similar
to
the
kind
of
encoding
used
with
multi
topology
routing
its
not
multi,
follow
G
routing
but
multi.
Apology,
routing
had
a
nice
feature
that
you
effective.
Even
if
you
never
deployed
multi
topology,
you
were
effectively
using
the
default.
Multi
topology
ID
equals
zero
in
the
existing
advertisements.
So
we
we
adopt
the
same
approach
that
basically
your
already
existing
routers
are
already
advertising
attributes
in
the
default
attribute
set
and
then
new.
B
We
introduced
a
new
link
attribute
set
sub
TLV,
also
in
TLB
22.
It's
used
to
associate
any
non-zero
te
attribute,
set
IDs
with
the
link
attributes
in
the
new
link
attribute
sub
sub
TLP,
so
the
actual
and
coatings
we
borrowed
heavily
from
for
Miles's
draft
because
there
they're
good
encodings,
but
we
use
them
in
a
different
manner.
B
B
This
is
showing
how
the
tte
attribute
set
gets
used.
So
basically,
this
is
your
existing
TLD
22
advertisement
with
also
sub
TLB,
three
for
admin
group
and
sub
Tod,
nine
for
maximum
link,
bandwidth
and
so
right
here
we're
actually
advertising
no
additional
additional
values,
we're
not
using
any
of
the
new
advertisements
but
we're
implicitly
advertising.
All
of
the
these
attributes
with
te
attribute
set
ID
equals
zero.
The
default
te
attribute
set
so
in
this
case
all
of
these
applications,
and
these
could
be
RSVP
SR.
B
Any
application,
RSVP
fast
reroute,
SRT,
LFA
or
sr
centralized
control
there
they're
all
able
to
use
these
existing
advertisements,
so
only
in
the
case
where
we
need
a
value
for
an
attribute.
That
is
where
an
app
one
application
needs
to
use
a
value
for
an
attribute.
That's
different
from
these
default
values.
Do
we
employ
the
new
encoding?
So
we
have
this
link
attribute,
set
sub
TLV,
which
carries
the
T
attribute,
set
ID
of
1,
and
then
it
we
put
in
this
extra
value
of
the
maximum
link
bandwidth,
which
is
this
case,
is
22.
B
B
So
so
we
feel
like
this
approach
really
avoids
deprecating
the
existing
advertisements.
It
puts
the
sort
of
complexity
on
the
you
know,
the
networks
that
need
this
advanced
functionality.
Ok,
they
have
to
worry
about
these
new
and
codings,
but
take
for
example,
Bruno's
question
about
his
use
case.
It
continues
to
function
exactly
as
it
is,
even
as
he
upgrades
the
software.
He
never
needs
to
worry
about
this
new
encoding
because
he
never
needs
to
deploy
the
new
encoding.
B
So
the
the
SR
LG
sets
work
similarly,
but
they
have
a
slightly
different
semantics
because
of
the
nature
of
SR
LG's.
You
typically
take
a
union
of
all
the
SR
LG's
on
a
link
you
want
to
have
you
know
an
arbitrary
number
of
SR
LG's
or
a
list
or
set
basically,
and
so
again
we
use
the
approach
that
the
existing
TLB
1:38
advertisements
are
in
the
default.
Sr
LG
set
s
r
LG
set
ID
equals
zero.
B
That's
only
allowed
to
advertise
non
zero
values
of
the
SR
LG
set
similar
to
mt
ID,
and
that's
how
we,
you
know,
associate
how
we
advertise
sr
LG's
with
non
zero
values.
So,
similarly,
existing
applications
can
be
grandfathered
into
this
framework.
There
they
start
out.
Once
we
approve
this,
this
approach
or
a
similar
approach.
They
start
out.
B
You
know
already:
advertising
SR
LG
set
ID
equals
zero
advertisements
when
we
need
to
for
an
application
or
a
network
that
needs
a
different
value
of
semester.
Lg's
for
the
same
link,
then
we
use
this
new
advertisement
now.
The
semantics
for
this
is
that
by
default,
if
you
are
using
for
the
SR
LG's,
we
have
no
mechanism
to
sort
of
override
a
default
SR
LG
advertisement.
B
So
we
basically
just
say:
okay,
if
you
want
the
when
you
use
an
SR
LG
set,
if
you
say
okay,
I'm
going
to
use
SR
LG
set
one,
you
don't
include
by
default.
Sr
LG
set
0
because
you'd
end
up
there's
no
way
to
cancel
out
the
existing
SR
LG's
in
the
default
SR
LG
set.
But
that
seems
like
a
reasonable
sort
of
compromise.
B
So
in
this
case,
we
want
application
X
to
take
into
account
all
three
types
of
SR
LG's.
While
application,
why
should
only
take
into
account
intercity
and
intercontinental
sr
LG's,
so
they
get
advertised
using
the
sets
jumble?
Oh
one,
two
and
three
and
the
application
takes
the
union
of
one
two
and
three
for
application
x
and
y.
Just
takes
the
union
of
two
three
as
the
SR
LG's
that
it's
going
to
consider
as
constraints
and
use
use
them.
However,
it
will,
when
you
want
to
add
another
application.
B
Applications
II
in
this
case,
which
is
only
supposed
to
take
into
account
intercity
and
intercity
SR
LG's
it.
You
know
you
don't
need
to
touch
the
the
routers
that
are
advertising
these
s
or
LG's.
It's
already
advertising
the
appropriate
information,
and
this
is
especially
the
case
when
you
have
a
centralized
te
controller.
B
A
B
Four
okay,
so
draft
Ginsberg
proposes
to
eventually
deprecated
the
existing
te
link
attributes
in
TLB
twenty-two.
The
use
cases
presented
so
far,
I
don't
think
justify
doing
that
better
to
use
an
approach
that
has
built
in
backwards.
Compatibility
I
think
the
proposed
encodings
limit,
the
attributes
to
particular
applications
and
I
think
that
approach
actually
restricts
application
development.
B
It's
better
for
routers
to
advertise
properties
and
applications,
decide
how
to
use
those
properties,
and
it's
also
not
clear
what
the
definition
of
each
of
the
standard
applications
should
be
I'm,
going
to
jump
to
that
one,
because
I
haven't
really
addressed
it.
So
at
this
point
we
actually
have
eight
seven
or
eight
applications
that
are
using
these
T
attributes
and
s
or
LG's.
B
We
have
distributed
RSVP
traffic
engineering,
centralized
RSVP
traffic
engineering,
RSVP
based
fast
reroute
at
the
PLR
RSVP
base,
just
disjoint
paths
from
the
ingress
router
LDP
based
fast
reroute,
centralized
SR
based
traffic
engineering
and
s
are
based
fast
reroute
at
a
PLR
or
TI
LFA.
I
think
these
are
all
different
which
are
using
these.
So
in
this
case,
are
we
going
to
define
a
standard
application
for
each
of
these
and
what
about?
B
A
A
We
can
address
questions
from
the
audience.
I
have
a
I
have
a
sort
of
clarifying
question
in
that
you
know
I
just
reread
things
today
and
they
just
kept
a
cup
hitting,
and
so
this
seems
like
I
understand
it's
more
than
just
a
simple
and
caps
TLB
format.
You
know
encapsulated
we're
in
an
encapsulation
encoding.
H
A
You
it's
a
you
know.
It
seems
like
an
encoding
difference.
What
the
problems
are
kind
of
solved
the
same.
The
solutions
are
very
similar,
and
it's
just.
How
do
you?
How
do
you
encode
that
solution?
I
see
like
there's
a
more
like
you're
addressing
the
defining?
The
applications
are
not
the
stuff.
I
was
talking
to
less
earlier
about
having
the
default
be
more
non-disruptive.
It's
just
like
these
things,
I'm
looking
to
get
less
as
a
draft
that
is
working
group.
Adoption
call
right
and
he's
correct.
A
Even
those
numbers
weren't
that
the
rough
consensus
is
generally
was
less
traffic.
I.
Think
Chris
has
some
good
points,
I'm
wondering
if
we
can
move
forward
with
adopting
the
draft,
but
not
abandoning
the
ideas,
because
at
that
point
it
ceases
to
be
less
as
draft
right
and
it
becomes
is
ice,
working
groups
draft
and
we're
allowed
to
do
whatever
we
want
with
it
as
working
right.
So
it's
not
if
I'm
not
crushing
any
ideas
here,
and
so
what
am
I
curious?
Things
are
Chris
if
we
were
to
follow
that
path.
A
B
I
think
that
enable
meant
what
does
enable
with
me
I
wouldn't
want
to
come
back
to
oh
well.
You
know
these
are
the
requirements
that
the
working
group
adopted,
because
even
those
requirements
I
think
are,
are
pretty
pretty
rough.
So
if,
if
this
is
a
starting
point
for
working
group,
work
on
it,
I'm,
okay
with
that,
but
if
we
get
down
to
be
party
agreed
on
XY
and
Z
and.
A
Right
well
so
working
group
adoption
is
not
working
for
black
all
right,
yeah
and
that's
that's
kind
of
the
point
I'm
trying
to
get
across
is
because
we
want
to
move
this
forward
and
I
feel
like
you.
Guys
have
worked
together
and
you
come
to
a
head
on
certain
points,
and
maybe
the
working
group
can
work
through
those.
B
J
About
that
more
so
there
there
are
two
significant
issues
to
me
in
terms
of
what
the
two
drafts
provide
solutions
for
one
issue
is:
there's
there's
no
way.
Yes,
as
far
as
I
can
tell
and
I've
read
your
draft,
there's
no
way
to
say:
I
have
legacy
advertisements
on
a
given
link
and
I
do
not
want
a
new
application,
I,
don't
care
whether
it's
standard
or
user
defined
or
whatever
I
don't
want
a
user
application
to
use
these.
You
don't
have
a
way
to
do
that.
J
The
second
issue,
which
I
think
is
far
more
important
actually
and
it
hasn't
I-
don't
think
that
either
presentation
has
at
the
time
to
make
this
as
clear,
perhaps
as
as
we
could
have
is
with
Chris's
proposal.
You
do
not
have
any
standard
dis
assignments,
so
all
of
your
mapping
between
a
given
application
and
the
value,
whether
it's
a
bit
value
or
whether
it's
a
scalar
value,
is
done
by
dynamic
configuration.
And
if
you
do
this,
then
I
don't
know
how
you
pass
this
information
via
bgp
LS
to
a
controller.
J
B
A
A
J
B
A
A
A
So
I'm
thinking
it
from
the
from
the
trying
to
move
forward
case
of
you
know,
once
it's
out
of
authors,
hands
and
into
working
groups
hands,
we
can
start
making
changes
and
make
things
clarified.
And
if
one
of
the
things
is
we
do
want
to
cover
enablement
or
you
don't
want
to
cover
the
angle.
And
if
we
don't,
we
decide
not
to
cover
an.
A
R
Tony
P
juniper,
like
Chris
frankly,
looking
at
the
stuff
I'll
put
them
into
a
room,
give
them
pizza
and
start
to
slowly
suck
out
oxygen
until
they
agree
on
a
common
set
of
requirements.
We.
R
So
you
didn't,
do
it
well
enough
I
think
adopting
one
draft
without
in
the
requirements
being
met?
Where
everybody
agrees
on
you
just
you
just
have
it
no
a
different
set
of
conflict,
so
I
would
force
them
to
come
with
a
little
requirements
they
agree
on
and
if
they
disagree
set
of
requirements
which
are
orthogonal
and
then
solve
it
with
two
drugs,
otherwise,
we'll
just
direct
the
stuff
on
it
will
become
more
and
more
of
a
festering
thing.
Suggestion.
G
Nice
gorilla,
Artie
break,
one
of
those
I
would
say,
habits
that
you
get
used
to
for
working
to
along
with
Yakov
was
asking
first.
Can
it
be
done
using
existing
protocols
right
and
it
looks
to
me
both
of
you
you're
trying
to
reinvent
multi
topology
routing,
albeit
in
a
te
context.
Right
so
may
I
ask
you
one
thing
in
the
te
topology
registry
we
have
probably
99%
unutilized,
as
per
today,
is
IANA
table.
G
J
J
G
C
L
Iii
just
gonna
comment:
if
you
go
down
the
multi
topologies
I
mean
granted,
we're
gonna
have
some
differences
in
coding
in
OSPF.
We're
not
gonna.
Go
that
way.
I
mean
we
don't
have
it
implemented.
So
we
are
not
going
to
just
to
support
multiple
applications,
so
that
would
mean
divergence
I'm.
Speaking
as
where
we
are
today.
R
A
Okay,
so
I
don't
I
feel
like
we
resolved
this
conflict,
but
I
do
like
Tony
peas,
idea
that,
let's
make
sure
we're
working,
the
requirements
are
very
clear:
I
don't
want
a
requirements
document.
We
can
just
do
it
on
the
list
and
we'll
make
sure
that
we're
trying
to
solve
the
same
problems
and
if
we
are
I
think
we.
B
B
J
B
A
J
A
B
And
again
volunteered
to
edit
a
document
on
use
cases
and
requirements
whatever
we
want
that
got
shut
down
by
you
know,
basically
an
argument
from
less
on
the
list
without
any
real
response
to
that.
So
I
still
think
that's
the
right
approach.
You
know
people
I'm
sure
less
will
claim
that
I'm
just
trying
to
slow
this
down,
but
this
is
going
to
go
nowhere
without
actual
use
cases.
J
B
S
M
S
M
Yeah
I'm
not
helping
in
progressing
we're
just
trying
to
answer
last
question:
Hannah's
mentioned
multi
topology,
which
does
allow
to
support
different
advertisement
for
a
given
topology.
There
is
no
startup
core
point
for
that,
but
I
could
under
a
to
using
multi
topology.
So
there
is
thought-out
way
to
do
it
already.
J
So
I
think
I
think
there's
a
there's,
a
big
difference
between
stating
an
idea
and
looking
at
what
the
current
encoding
actually
supports
and
I
don't
think
what
Hannes
is
proposing
is
fundamentally
different
from
what
either
of
our
drafts
proposed.
You
can
define
different
bits.
You
can
define
a
different
code.
J
B
J
H
J
A
I've
literally
eaten
out:
that's
all
the
slop
and
everything
else,
including
the
time
of
Ross's
presentation
that
we
recovered
we're
gonna,
do
reverse
and
then
we're
gonna
do
fine
leaf
and
I'm
putting
flexi
at
the
end
because
it's
being
presented
in
another
NC
camp.
So
in
case
we
run
out
of
time.
It
still
will
be
presenting
something.
So.
E
E
E
You
can
read
here
the
remove
this
bit
link
overload,
link
cap
attribute
and
so
on
and
yeah.
Here
it
was
first
presented
in
as
I,
then,
if
a
draft
him
ITF
79
in
Beijing-
and
this
is
November
2010,
so
the
use
cases
are
note
and
link
isolation
so
that
you
can
remove
yourself
from
a
LAN
and
everybody
else.
Don't
can
still
use
it
as
before
and
it's
also
but
like
when
there
is
work
going
on
on
a
line
card,
and
you
know:
when
do
you
send
you
of
the
ports
on
on
that
line
card?
E
E
E
You
can
configure
this
locally
to
overwrite
the
the
signal
from
neighbor.
This
is
work
so
both
on
land
Sun,
which
point
support
of
T
metric
and
subtly
for
C
SPF
calculation
and
on
the
land.
That
dis
note
is
it's
doing
the
the
worker
for
changing
the
metric
from
the
pseudonym
and
on
point
point
you
just
tell
the
other
guy
to
add
to
the
already
existing
mature.
There
is
work
here
about
OSPF
and
I'm.
E
Not
a
no
SPFs
for
expert
I
took
the
AC
yesterday
to
understand,
but
it
was
doing
here,
but
it
has
similar
there's
part
of
the
sole
solution,
spacer
that
it's
being
done
in
those
gaps
well
and
as
far
as
I
know
we
did.
This
is
quite
stable.
We
have
just
a
lot
of
you,
know,
comments
and
so
on,
and
we
requested
requesting
plastified
I.
A
Don't
know
if
you
covered
this
in
the
use
cases,
but
the
one
that
Peter
Lawford
recently
came
up
with.
He
came
up
with
a
different
solution
and
the
reverse
metric
actually
solved
it,
which
was,
if
you're
getting
a
lot
if
you're
getting
a
crappy
signal
on
your
fiber
right
on
your
end,
you
know
that
it's
bad,
so
you
can
advertise
the
metric
the
up.
You
know
that
the
fact
that
it
shouldn't
come
for
it
so.
E
There's
the
whole
thing
about:
if,
if
you
are
close
to
your,
like
prefect
limit,
we're
going
to
start
getting
bit
errors,
you
can
say:
okay,
when
this
happens,
I
want
the
metric
to
be
increased
so
that
there
is
no,
and
so
you
increase
the
metric
you're
announcing
and
you're
telling
another
guy
to
do
that
as
well,
and
so
you
can
set
like
trade
optical,
triggering
sale
signals.
If
your
and
me
you
can
have
error,
counters
trigger
this,
and
so
on
then
did
this
is
so
yeah
the.
A
A
L
E
G
A
A
Yeah
but
but
I'm
saying
the
case
Peters
interested
in,
which
is
the
interesting
case,
is
that
you
have
two
fibers
right
there
unidirectional
and
you've
got
you've
got
bi-directional
concavity,
but
you
might
only
have
crap
on
one
direction
right,
so
I
don't
want
to
take
the
link
out
of
service
because
it
works
perfectly
fine
that
way.
Okay
and
it's
bad
this
way,
yes,.
E
A
A
A
J
J
We
introduced
a
new
version
in
March
which
introduced
the
leaf
set
advertisement
to
to
allow
leaf
nodes
to
direct
traffic
away
from
the
spine
notes
from
a
particular
spy
node
when
you
don't
have
full
connectivity,
you'll
see
more
a
clear
example
of
that.
Later.
In
the
presentation
we
published
a
new
version
in
June
borrowing,
some
ideas
from
Russ's
fabric
path.
M
J
The
the
lines
in
blue
are
sent
by
the
leaf
nodes,
so
a
leaf
node
will
indicate
with
the
bit
that
I
am
a
leaf
node
and
it
will.
It
also
can
optionally
indicate
for
an
east-west
path
that
it
can
serve
as
a
backup
default
gateway.
Again,
that's
optional
and
the
green
is
sent
by
the
spine
nodes.
So,
as
my
node
can
indicate
that
I
can
be
used
as
a
default
gateway.
J
J
This
is
sent
in
both
directions.
Potentially
the
spine
node
send
it.
I
can
look
this
way
when
the
spine
notes
ended.
They
advertised
the
list
of
the
system,
IDs
of
all
the
leaf
nodes
to
which
they
currently
have
connectivity
and
the
leaf
nodes
can
send
use
the
CSL
LSP
to
send
a
request.
This
is
used
by
default.
The
leaf
nodes
will
use
any
spy
node
that
it
wants
as
a
default
gateway.
J
Ok,
the
extension
basics,
so
we
start
out
with
2
layers
at
the
aggregation
layer.
We're
just
doing
normal
is,
is
normal
flooding,
normal
exchange
of
PDUs,
the
leaf
node?
Will
send
a
hello
to
the
spine
and
it
will
indicate
that
it's
at
tier,
0
and
it'll
set
the
the
bit
that
says
on
the
leaf
node.
It
will
flood
its
own
LSPs
to
the
spine
and
optionally.
You
can
use
a
circuit,
scoped
LSP,
to
send
an
info
request
to
the
spine
note.
J
The
spines
will
include
an
indication
in
their
hellos
that
G,
you
can
use
me
as
the
fault,
but
they
will
not
flood
LSPs
to
the
leaf
nodes
by
default.
There's
a
way
to
turn
that
off
and
they
can
use
the
circuit
scope
del
SB
to
indicate
here's
the
set
of
leaf
nodes
to
which
I
currently
have
connectivity.
J
So
here's
an
example
of
what
happens
when
in
a
link
and
or
node
goes
down
and
you
have
no
east-west
links
so
again,
we're
flooding
normal
is,
is
between
at
the
upper
tiers
and
the
leaf
nodes
are
indicating
that
they
are
at
tier
zero.
They
send
their
own
LS
B's
to
the
spine,
but
nothing
else.
So
we
have
a
link
failure
with
because
we
have
s
for.
H
J
J
Yeah
yeah,
okay
anyways,
the
general
idea
here
and
I
apologize
for
the
confusion
here
is
that
we've
introduced
a
way
to
since
we've
reduced
the
flooding.
The
leaf
nodes
no
longer
have
the
full
link
state
database.
So
by
default
they
just
go
to
any
spine
node
for
any
destination
they
want
to
reach.
But
in
those
cases
where
you
don't
have
full
connectivity
rather
than
flood
the
entire
LSP
database
to
the
leaves
to
cover
that
case,
we
provide
selective
advertisements
so
that
the
leaf
nodes
can
know.
Okay,
this
by
node
can't
reach
the
set
of
destinations.
J
J
So
what
are
we
trying
to
achieve
here?
We're
trying
to
achieve
extensions
that
are
specific
to
datacenter
requirements?
Flooding
is
the
big
issue
there,
because
one
topology
change
can
literally
turn
into
hundreds,
if
not
thousands,
of
duplicate,
LSP
updates
we're
doing
this
with
the
well-known
IGP,
so
we're
not
requiring
an
Additional
Protocol
and
we
have
available
to
us
all
of
the
existing
features
that
are
available
in
the
protocol.
J
J
This
is
again
from
the
open
fabric
draft.
We
incorporated
this.
This
helps
with
Auto
configuration
so
that
you
do
not
have
to
actually
go
into
each
node
and
configure
what
what
tier
they're
at
Russ
has
some
additional
extensions.
The
only
thing
we've
put
in
here
is:
you
have
to
configure
the
leaf
nodes
and
say
you're
a
leaf
node,
but
all
the
nodes
that,
above
the
leaf
nodes,
can
figure
out
what
tier
they're
at
basically
by
using
Russell's
original
idea
of
figuring
out
how
many
hops
away
they
are
from
the
leaf
nodes.
B
T
T
T
Yeah
flex
is
really
short
flexi.
It's
a
technology
that
can
support
a
variety
of
you
know
it
right
now.
You
can
either
migrate
that
may
not
may
or
may
not
correspond
to
you
the
same
fair
rate.
This
is
achieved
by
detecting
the
you
know,
even
your
fire
rate
and
mac
rate,
so
flexi
has
three
major
features.
First,
one
is
pounding
just
like
lack.
Multiple
interfaces
can
be
bounded
into
a
single
pipe
to
form
or
nurture,
and
foster.
T
Interface
is
to
provide
a
mobile
ways,
and
this
is
how
flexi
support
McCreight
quick
than
faded,
great
and
the
sub
rating
and
channelization
are
two
technologies
that
can
be
used
to
support.
My
crate,
listen
physic
great,
but
they
are
the
reason
to
address
different
use
cases.
Flexi
also
introduced
a
concept
of
slot
based
on
our
calendar.
It
can
be
an
effective
and
the
israel
ethernet
floor
can
be
dispatched
to
chris
pound,
snot
and
xcode.
T
T
It's
a
boundary
interface
that
is
can
consist
of
1
to
254
1
gigabit
interfaces
and
flex
interface
can
be
generalized
into
molecules
of
interfaces
and
a
link
that
connect
to
text
interface
is
called
text
link,
yeah,
ok,
so
a
links
that
connect
to
taxi
sub
interface
is
called
flexi
sub-link
mark.
Would
it
be
a
good
analogy.
T
It's
a
just
kiss
for
taxi,
it
can
be.
You
can
use
text
you
to
do
interface
on
language.
Network
slicing,
for
example,
can
actually
link
can
be
sliced
into
multiple
sub
links.
A
trunk
and
the
city
of
taxi
links
can
be
allocated
to
a
user
or
service
to
form,
arm
slice
network
that
have
dedicated
resources
and
the
earth
feeds
off
a
user
or
service
can
be
established
over
those
link
and,
for
example,
through
the
RCP,
our
CPP
signaling,
or
by
always.
T
Similarly,
with
this
measure,
we
can
provide
interface
a
link
based
a
level
isolation.
It's
better
than
no
traditional
example.
Tv
based
a
solution
so
actually,
but
I'd
prefer
the
advertisement
actually
there
to
type
of
limbs.
First,
one
flexi,
link
and
and
other
one
is
like
three
siblings
from
four
flex
healing.
It's
it's
same
like
it's
just
like
a
to
advertise,
our
normal
healing,
but
we
need
to
introduce
more
link
attributes.
For
example,
first
one
is
great
granularity
and,
and
the
second
ones
how
many
available
slot
attending
can
support.
T
This
information
can
be
used
by
you
know,
keep
on
that
path,
we're
taking
entity
to
computer
path
and
other
gaits
relevant
fun
ways
to
PHP,
and
so
that
affects
his
sibling
that
actually
there
are
two
options
for
advertisement.
First,
one
or
something
can
be
advertiser
as
an
individual
link,
so
there's
no
that
no
requirement
to
do
something
to
do
a
parking
extension,
but
with
this
matter
it
required
to
configure
IP
address
and
to
running
I'd
be
particle
or
a
link.
T
If
this
is
sometimes
considered,
not
scalable,
because
there
may
be
a
lot
of
saplings
per
flex,
CD.
So
another
way
to
do
faxes,
sapling
advertisement
used
to
to
advertise
saplings
as
a
members
link
of
taxi
link.
So
with
this
way,
we
don't
need
to
configure
the
IP
address
and
and
running
protocol
over
the
link.
T
So
here's
a
example
how
this
kind
of
information
can
be
advertised
to
use
the
based
on
and
investing
a
tier
VIII
cherries,
the
left
and
the
left
side
is
a
sub
theory
that
is
used
to
describe
switching
capability
of
an
interface
so
for
the
factory
we
just
different
new
subtly
to
describe
flexing
interface
to
include
information
as
a
set
before
you
know
previous
sites
granularities
and
the
available
time
starts
and
this
camp.
This
information
can
be
used
by
to
compute
our
PRT
thoughts
and
yes
and
next
step.
T
T
T
T
M
Even
a
marriage,
so
my
first
comment
you
already
mentioned
it-
is
to
discuss
gmpls
extensions
within
jim
penetrated
groups,
explicitly
tease
on
or
see
camp
my
other
feedback
which
could
have
been
waited
further
presentation.
But
since
you
there
I'm
raising
this
right
now
the
is
CD
in
GPRS.
Is
men
mainly
to
identify
the
technology
layer
you
switching
so
as
to
identify
the
type
of
label?
You
are
going
to
use
to
create
your
speeds,
which
is
not
this
use
case
you're
trying
to
address
here
so
clearly.
M
There
is
a
strong
mismatch
between
the
you
proposed
from
the
protocol
perspective.
With
respect
to
the
program
you
trying
to
rest
so
clearly
you
need
to
split
them.
There
may
be
some
work
related
to
your
use
case,
some
flexi
within
Jim
P
lash,
which
I
think
it's
already
tackled
somewhere
else.
Also,
but
I
don't
see
them
clearly
matching
their
yeah.