►
From YouTube: IETF110-LSR-20210308-1600
Description
LSR meeting session at IETF110
2021/03/08 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
Yeah
hi
everybody.
Well,
this
is
the
lsr
working
group,
and
this
is
christian.
Hopps
and
ac
is
with
me.
I
don't
know
if
alvaro
is
in
but
john
is
here
and
on
wednesday
he'll
be
our
new
ad
and
we
have
a
minute
taker
and
john's
said
he
can
do
the
jabra
scribe
duties,
they're
pretty
minimal.
Now,
with
the
virtual
setup
at
least
I
think
that's
it.
We
have
a
pretty
full
schedule.
We
don't
have
an
agenda,
do
we
we
don't
have
an
agenda
slide?
A
A
So
here's
our
agenda
does
anybody
have
any
bash
bashing
to
do
on
this
agenda?
Any
changes.
A
We
did
make
a
a
slight
change.
I
don't
know
if
people
noticed,
but
we
moved
bandwidth
constraints
to
the
third
slot.
B
Oh,
I
think
I
missed.
Did
you
miss
one?
No,
you
didn't
miss
one.
Oh
the
yang
models.
Yeah.
I
tried.
I
tracked
down
the
yang
models,
thanks
john,
for
help
out
on
the
tunnel
end
cap
and
getting
that
through
so
we'll
we'll
we'll
the
the
top
draft.
The
tunnel
encapsulations
router
information
draft
will
be
published
along
with
the
tunnel
encounters
draft,
but
on
the
yang
models.
I
tracked
that
down
and
it's
a
reference
what's
blocking
us
is
a
reference
in
bfd
to
the
tease
yang
model.
Now
the
teas
yang
model.
B
So
maybe,
if
we
can't
resolve
this,
we
might
ask
the
bf
d
people
to
separate
the
mpls
module
into
a
different
draft,
because
it
has
a
number
of
modules
in
the
in
the
model
and
that
one
could
be
in
a
different
draft.
We'll
see
how
long
this
draws
out
and
we'll
discuss
this
outside
of
this
meeting
next.
B
B
B
The
rfc
5316
bisque
draft
is
just
some
protocol
maintenance.
It
went
from
working
group
document
to
last
call
rather
quickly,
because
it's
just
removing
the
restriction
that
you
need
that
you
can't
use
an
ip6
only
network
and
prefix
originator.
B
I
know
who's
got
the
pen
in
that
we're.
We
also
gotta
satisfy.
I
mean,
have
revised
id
for
alvaro's
comments.
The
next
slide.
A
I'll
just
throw
out
there
quick,
the
the
the
rfc
53
16.
This
is
a
dual
working
blast
call,
but
the
primary
comments
are
running
in
an
artwork
here.
All.
B
Yes,
as
always
happens
with
a
biz
document,
you
get
comments
outside
of
cleanup
comments
outside
of
what
the
document
was
rewritten
to
remedy
and
we're
taking
at
least
at
least
for
the
editorial
ones
the
offers
are
taking
care
of
those
as
well.
B
These
ones
were
waiting
for
the
first
first
one
worst
metric
waiting
for
ad
review,
flexible
algorithm,
that's
gonna,
be
covered
today.
We're
we're
gonna,
probably
do
another.
We're
definitely
gonna.
Do
another
working
group
last
call
next
slide.
B
B
Slide
dynamic
flooding
this
has
been
around
for
a
while
hasn't
been
any
changes.
I
know
there's
at
least
there's
been
a
lot
of
discussion.
I
think
there's
some
implementations
proceeding,
we
could
discuss
be
nice
with
offers.
Would
the
offers
can
tell
us
when,
if
they
think
it's
ready
for
working
group
last
call?
B
D
Very
brave
question:
can
you
hear
me
clearly,
yes,.
E
D
B
D
A
F
F
B
Okay,
go
to
the
next
slide
now
this
next
one,
the
ospf
v3
extensions
for
srv6.
I
think
this.
Hopefully
we
can
get
some
priority
on
this
because
for
one
there's
a
normative
reference
to
it
in
the
flex,
algorithm
draft
and
number
two
alvaro
when
he
did
the
isis.
He
said:
okay,
where's,
the
osvf,
and
I
it
I
agree-
it
would
be.
B
You
know,
from
a
efficiency
standpoint
would
be
better
to
get
them
done,
simultaneous
or
at
least
close
to
one
another.
So
it's
fresh
in
everybody's
mind.
B
B
B
Okay,
we
had
a
few
new
working
group
documents,
the
second
one
ipflex
tool
and
that
algorithms
generated
a
lot
of
discussion.
Hopefully,
that'll
proceed
the
tags
draft
sort.
This
is
somewhat
of
a
protocol
maintenance
that
we
never
had
anything
more
than
tags
for
external
routes
and
ospf
until
we
got
to
tlv
based-
and
this
is
going
back
and
allowing
tags
for
non-external
routes
just
like
we
do
for
external
routes
in
ospf,
just
like
we
do
for
isis
next.
B
Slide
these
are
adoption,
people,
people
have
requested,
adoption
calls
and
we
think
it's
reasonable
at
least
somewhat
reasonable.
We
have
the
flooding
speed.
I
think
we'll
have
more
discussion
on
that
in
the
next.
There's
been
actually
been
some
discussion
between
the
chairs
and
the
office,
and
I
think,
there's
work
going
on
both
for
this
one
and
the
transmit
based
one
there's
testing
work
going
on,
so
I
I
imagine
there'll
be
some.
B
I
hope
there'd
be
some
discussion
on
that
on
the
list
and
some
new
testing
results
as
well.
A
G
H
Okay,
could
you
go
back
a
couple
slides
to
the
dense,
flooding
and
dense
graphs.
H
H
B
A
Where,
where
where,
where
are
we
gonna,
go
okay
yeah?
So
we've
been
asked
by
bruno
a
while
ago
to
maybe
do
an
adoption
on
the
flooding
speed,
but
there's
a
lot
of
testing
and
stuff
going
on,
and
you
know
there's
still
sort
of
two
drafts
out
there
that
are
talking
about
you
know
the
problem
is
trying
to
be
solved
here,
which
is
really
kind
of
a
flow
control
problem,
and
so
you
know
so
we're
we
feel
it.
A
You
know
it
makes
sense
to
just
the
work's
progressing
right
and
there
are
different
drafts,
so
I
don't
know
that
we
need
to
rush
to
adopt
one
of
them
or
even
both
of
them.
Until
we
get
more
experience,
you
know
which
is
valuable
and
and
happening.
So
that's
our
that's
our
thinking
on
that
one
right
now,
as
a
working
group
member,
I
also
think
that
it
would
be
very
cool
since
we
are
talking
about
flow
control.
Both
of
these
solutions
are
trying
to
work
within
they're
trying
to
work
within
the
mechanisms.
A
A
B
D
D
B
Yeah,
what
was
that
draft?
That
was
it
karidi
that
had
the
draft
on?
It
will
happen
next
next
ietf
or
next
next,
I
can't
remember
it'll,
I
it's
on
the
priority
list
of
the
adoption,
so
it
it's
nearing
the
top
of
the
list
and
it's
not
a
controversial
draft.
I
don't
think
I
I
think
we
should.
I
think
we
should
adopt
these.
As
for
protocol.
B
Okay-
and
this
is
just
pointers
to
these
these
documents
that
are
igp
documents,
lsr
documents
that
are
on
their
working
groups-
I
pointed
out
the
the
second
one,
the
yang
model
for
ms
mpls
msd,
because
we
moved
that
out
of
the
sr
yang
and
into
a
separate
mpls
document,
because
msd
is
independent
of
sr
and
that's
it.
Let's
go
to
the
first.
I
guess
ying
zing
ying
zhang
ninjan
I'll
get
it
right.
Do
you
want
to
alvaro.
I
Yeah,
hey
hello,
thunder,
wrote
andy
just
a
quick
thing
before
you
go
into
the
actual
work.
I
want
to
welcome
john
scutter
as
the
new
ad
for
lsr.
I
think
all
of
you
should
probably
know
that
he
was
just
selected
a.d
recently
he's
taken
over
this
week.
I
I
I
also
want
to
say
thank
you
to
the
working
group,
because,
when
I
took
over,
lsr
was
when
we
first
merged
isis
and
ospf,
and
I
think
it
has
been
working
very
well.
Ac
had
sent
me
a
list
the
other
day
of
that
I
don't
have
with
me.
I
thought
you
guys
might
project
it
here
of
all
the
things
that
have
been
done
in
the
last.
I
think
about
three
or
four
years
since
lsr
has
existed
and
it
is
a
lot
of
work.
I
It
is
really
good
work
for
the
chairs
for
your
shepherding
all
this
work.
It
is
great
that
to
see
the
working
group
engaged,
and
I
think,
even
better-
that
we
have
been
able
to
pull
out
the
two
protocols
working
as
not
as
one
but
but
you
know
close
close
to
each
other
and
that
we
see
things
progressing
in
both
of
them.
So
thank
you
for
that,
and
welcome
to
john
he's
already
doing
a
lot
more
than
I
did
he's
already
the
jabber
scribe.
This
is
great.
Thank
you.
So
much.
A
B
J
L
Okay,
so
this
is
indian,
I'm
going
to
present
an
update
of
ospf
transport
instance
next
slides,
please
so
what's
ospf
transport
instance,
it's
a
separate
ospf
instance
for
non-routing
information
dissemination.
L
L
That's
just
a
memory
refresh
for
what's
ospf
transport
instance
yeah.
So
in
this
new
version
of
the
draft
we
added
detailed
encoding
for
ospf
v2.
We
propose
a
new
transport
instance:
information,
opaque
rsa.
This
slide
shows
the
package
for
might
of
this.
Tii
rsa
depends
on
the
application.
L
L
I
M
L
L
M
B
O
Hi
hi,
I
say:
thanks.
Can
you
hear
me?
Okay?
Yes,
yes,
yeah
yeah,
so
I
was
looking
into
the
draft
and
a
possible
use
cases.
Section
mic
use
case
is
listed,
but
you
know
I
really
couldn't
understand
how
network
resources
can
be
given
to
5g
ue.
O
So
it's
very
unclear
it's
I
I
I
don't
see,
there's
a
possibility
at
all
that
need
to
be
corrected.
Frankly,
and
the
second
thing
is:
there
are
situations
where
the
5g
code
nodes
and
you
know
on
the
pe-
can
be
together
like
in
4g
cases,
se
gateway.
O
O
A
L
One
ospf
is
going
to
disseminate
the
net
routing
information
inside
ospf
network
for
sure
right
so
for
the
file
ck
ceo,
how
your
upf
interact
with
an
opf
with
an
ospf
router,
you
can
run
a
worldview
os
virtual
machine
on
your
I
mean
like
a
docker
process,
ospf
process
or
something
like
that
or
use
some
other
interface
to
interact
with
ospf.
That's
out
of
scope
of
this
document,
yeah.
H
K
L
That
that's
why
we
are
using
a
transport
instance.
This
one
is
designed
for
non-routine
information
dissemination,
it
doesn't
do
any
job
calculation
and
the
basic
routing
protocol
is
still
run
in
the
bazel
spf
instance.
A
K
K
G
Second
slide
yeah
here
you
you
mentioned
that
using
the
ospf
transport
instance,
you
can
transfer
information
by
the
non-routine.
G
C
G
L
So
I'll,
just
I'm
saying
quick
so
basically
means
the
transfer
instance
can
use
a
different
topology
from
the
base,
the
routing
process,
the
routing
instance.
K
A
P
P
Alright,
so
a
bit
of
a
context,
the
working
group
last
call
for
this
trust,
for
this
draft
was
done.
The
publication
was
requested
october
last
year.
We
even
have
the
routing
directorate
preview,
which
is
marked
as
a
complete
at
the
moment.
Well,
the
original
the
problem
was
that
the
original
implementations
were
mostly
isis.
Now
couple
of
vendors
started
to
work
on
the
ospf
part
and,
interestingly
enough.
In
about
the
same
time,
I
both
discovered
that
there
is
a
missing
piece
in
the
usb
on
the
ospf
side.
P
So
what
we
would
like
to
do
here
is
we
we
added
the
missing
pieces
on
the
ospf
side,
because
otherwise
the
the
basic
spec
would
basically
not
be
complete.
We
were
thinking
about
adding
this,
maybe
potentially
to
a
different
document,
but
then
we
said
well.
This
is
a
basic
stuff.
It
belongs
here.
So
let's
go
back
to
the
working
group,
so
we
added
these
missing
parts.
We
would
like
to
ask
the
working
group
to
review
and
we
can
do
another
working
blast
call.
There
is
nothing
changed
from
the
perspective
of
the
flex
operation
or
anything.
P
P
So
couple
of
things
which
has
been
added
so
first
one
in
ospf,
we
have
bunch
of
metric
types
in
terms
of
the
external
information,
so
the
external
prefixes
can
have
type
one
or
type
2
metrics,
something
which
is
specific
to
spf
and
when
we
define
the
flex
algorithm
prefix
metrics
of
trv,
the
subtle
which
is
achieved,
the
end-to-end
inter
area
or
intel
domain
optimality
on
the
flex
algo
metric.
P
We
added
it,
but
we
didn't
really
think
about
the
the
type
of
a
metric
which
is
being
supported
in
ospf.
So
we,
what
we
did
is
we
added
another
field,
one
byte
field
which
flag
field
basically
recovered
from
the
reserved
field.
So
there's
no
backward
compatibility
issue
in
terms
of
the
tlb
layout
and
when
the
bit
is
set
that
the
metric
type
is
two.
So
this
is
basically
the
same
functionality
that
the
basic
rfc
specification
mentions
in
the
section
that
is
mentioned
here
in
the
rfc
2c28.
P
K
P
All
right
and
the
second
a
bit
bigger
piece
is
that
again
related
to
the
prefix
flex,
algo
specific
prefix
metric
when
we
define
this
again
define
everything
properly
for
the
prefixes.
But
what
we
forgot
is
that
in
ospf,
inter
area
between
the
areas,
we
also
advertise
the
reachability
of
the
asbr's
and
it's
a
type
4
summary.
Let's
say
as
we
call
it
in
the
ospf
specification
in
skv2
and-
and
we
completely-
you
know,
missed
this
part.
P
So
what
we
define
is
we
needed
to
have
a
way
for
these
summary
advertisements
to
to
provide
a
flex
algo
specific
metric,
so
what
we
defined
for
ospf
v2,
we
defined
the
extended
inter
area
isbrlsa,
which
is
very
similar
to
what
we
defined
for
the
prefixes.
You
know
years
back
and
has
the
same
semantics
as
a
type
four
summary.
P
Let's
say
in
the
base
of
spf
v2,
then
we
defined
the
tlv
in
this
lsa,
which
is
being
used
to
advertise
the
reflexology,
specific
or
well
extended
information
about
the
the
isbr,
and
then
we
define
that
the
subtle
which
advertises
the
flex
august
specific
metric.
It
can
advertise
to
flex
all
the
specific
metric
for
the
single
isbr
in
multiple
flex
algos,
and
this
is
being
sent
in
two
parent
tlvs.
One
is
the
one
which
is
defined
here,
the
second
one,
the
extended
inter
area
is
vrtov
or
for
ospv3.
P
This
tlv
is
also
available
in
the
usb
receptor
area,
intel
area
around
router
tlv,
which
is
defined
in
rfc
8362..
P
Next
slide,
please,
and
then
basically,
the
there
has
been
some
text
added
about
processing
and
advertisements
of
this
inter
area,
asbr,
lsa
and
also
the
section
13.1,
which
is
the
inter
area.
A
multi-domain
section
has
been
extended
with
some
text
that
talks
about
when
to
advertise
this
and
how
to
process
this.
P
And
the
last
part,
obviously
there
are
some
allocations
which
are
needed,
so
we
updated
the
intersection
and
once
the
working
group
kind
of
agree
on
this
edit
text,
we
will
ask
the
ana
for
the
allocation
for
this
new
lsa
tlv
subtle
right
next
slide,
please!
So
again,
this
was
a
mistake
from
our
side.
You
know
we
we
somehow
forgot
the
specific
osbfps
here.
P
B
Q
A
I
I
Lot
of
time
around
80.
yeah,
so
I
just
wanted
to
say
that
I'm
really
glad
that
you
guys
caught
that
and
not
me,
because
this
was
next
in
my
queue.
So
what
I'm
going
to
do
is
since
we're
going
to
go
for
another
last
call,
and
this
seems
to
be
a
significant
change-
is
I'm
going
to
bump
the
document
back
to
the
working
group
and
then
you
can
put
it
in
javascript
whatever?
This
is
done.
J
N
N
R
Hi
everyone-
this
is
william
plato,
so
today
we'll
talk
about
the
new
draft
for
flex,
algo
bandwidth
constraints,
next
slide,
please
yeah!
So
first
we
will
talk
about
why
a
bandwidth-based
flex
server
is
useful,
and
then
we
look
at
the
additional
fad
constraints
that
will
be
needed
to
define
this
flux
circle
and
then
we
look
at
some
generic
fat
constraints
which
can
be
applied
on
on
any
flux
algal.
R
So
it
is
a
very
easy
and
efficient
way
where
a
single
definition
can
dictate
how
the
topology
looks
like
and
each
node
which
agrees
to
that
can
participate
and
a
participating
node
can
look
at
the
topology
in
the
same
manner,
and
this
draft
introduces
a
few
additional
constraints
and
a
new
metric
type
to
define
a
bandwidth
based
flex.
Variable
next
slide.
Please.
R
R
So
when
we
floated
this
draft
for
review,
we
received
some
feedback
asking
whether
can
we
make
this
a
generic
metric
so
that
in
future,
if
you
want
a
flexilgo
specific
metric
or
if
you
have
a
new
metric
type
coming
up
and
if
you
want
to
reuse
the
same
tlb
for
that,
so
we
are
open
to
that
idea.
R
We
would
like
to
listen
to
the
feedback
from
the
working
group
for
that
now,
for
the
bandwidth
based
flexor
go,
we
define
a
few
additional
constraints
which
defines
the
parameters
to
compute
the
automatic
metric,
and
this
left
also
introduces
a
couple
of
additional
constraints
which
can
be
used
by
any
flexible
next
slide.
Please.
R
R
R
So
this
is
useful
in
any
flex.
Argo,
where
you
want
to
say
that
this
is
particularly
useful
in
a
bandwidth
basics
algo,
where
you
want
to
exclude
certain
links
which
don't
have
the
enough
capacity
that
you
that
you
want,
and
the
next
constraint
is
an
exclude
maximum
link.
Delay
constraint
so
in
rfc
8570
dictates
defines
the
unidirectional
or
min
unidirectional
link
delay.
So
this
is
based
on
that.
R
If
any
link
whose
advertised
minimum
unidirectional
delay
is
greater
than
the
delay
specified
by
this
constraint,
those
links
should
be
excluded
from
the
flip
server.
So
this
is
mostly
should
be
useful
in
flex
argos
which
do
not
use
link
delay
as
the
metric
type,
so
in
any
other
flex
server.
If
you
want
to
use
this
as
a
constraint
to
remove
some
things
which
are
very
bad
so,
which
has
a
very
large
delay,
this
might
be
useful.
A
Next
slide
so
bill
speaking
of
minimum
bandwidth,
your
your
clipping,
your
audio,
is
clipping
in
and
out.
Could
you
turn
off
the
your
video
there's
a
way
to
turn
your
video
off?
Maybe
that'll
help.
A
R
R
So
this
is
applicable
only
for
the
flux
servos,
whose
metric
type
is
bandwidth
metric
and
this
automatic
metric
calculation
will
be
done
or
should
be
done
only
on
the
links
which
do
not
advertise
the
bandwidth
metrics
update,
so
the
the
entire
aromatic
bandwidth
symmetry
calculations
are
based
on
the
maximum
link
bandwidth
already
advertised
per
link.
So
we
define
two
modes
of
automatic
bandwidth
metric
calculations,
one
is
called
simple
mode
and
the
next
one
is
called
interface
group
mode.
We'll
look
that
in
detail
in
the
next
slides
next
slide.
Please.
R
All
right
so
in
the
simple
mode,
it's
probably
useful
for
suitable
for
deployments
using
layer,
two
bundles
for
for
all
the
parallel
links
between
two
nodes.
The
maximum
linked
android
advertised
per
link
is
used
to
derive
the
input
metric
next
slide.
Please.
R
Right
so
in
automatic
bandwidth,
metric
flex
server
has
additional
work.
Basically,
flex.
Argo
will
have
to
identify
and
group
the
pattern,
links
participating
in
that
flex
level.
So
look
at
the
is
neighbor
the
link
advertisements
and
look
at
the
neighbors
and
group,
the
all
the
link
attributes
which
are
pointing
to
the
same
neighbor
and
then
the
sum
of
the
maximum
link
bandwidth
advertised
by
each
of
those
parallel
links
is
used
to
derive
the
bandwidth
metric
applicable
for
all
those
links,
so
the
derived
metric
is
then
assigned
to
each
parallel
link.
R
R
Right
so
so
we
have
two
methods,
as
we
said,
the
simple
mode
and
interface
group
mode,
and
now
we
look
at
how
two
different
types
of
methods
to
derive
the
automatic
bandwidth
metric.
So
these
are
again
additional
parameters
which
dictates
or
defines
a
different
difference
which
a
flux
argo
defines
to
compute
the
bandwidth
metric.
So
you
have
two
methods:
a
reference,
bandwidth
based
method
and
a
bandwidth
threshold
based
method.
R
Okay,
so
in
the
reference
bandwidth
method,
basically,
the
flexilgo
defines
a
reference
bandwidth
which
can
be
used
by
each
participating
node
to
derive
the
bandwidth
metric.
So
this
is
done
by
advertising
a
fad
subtly
called
reference
bandwidth
sub
tv.
It
has
a
flag
to
indicate.
R
The
symbol
or
interface
group
mode-
and
it
has
the
reference
bandwidth
which
is
useful
to
derive
the
metric,
and
it
also
has
a
round
off
bandwidth,
so
the
round
off
bandit.
Basically,
it
helps
to
round
off
the
link
bandwidths
by
each
link
into
a
multiple
of
that
value
so
that
you
have
more
uniform
kind
of
metric
or
stepwise
metrics
across
the
topology
and
the
algorithm
of
the
formula
to
derive
the
metric
is
shown
here.
So
you
define
the
reference
bandwidth
by
the
link
bandwidth,
which
is
a
multiple
of
round
off
bandwidth.
R
Yeah,
so
this
is
one
of
the
examples
where
the
reference
value
is
defined
as
1
tbps,
and
you
have
a
round
off
bandwidth
of
20
gbps.
So
the
benefit
is
that
if
the
link
bandwidth
is
somewhere
in
the
range
of
100
to
120,
for
example,
the
metric
would
be
10..
So
if
the
link
is
an
aggregate
internet
link
or
a
later
bundle,
if
there
are
member
links
going
down,
so
even
if
the
bandwidth
doesn't
change
by
much
the
metric
wouldn't
change
as
well.
R
So
this
is
the
last
method
called
the
bandwidth
thresholds
method.
This
is
basically
when
the
the
the
reference
bandwidth
method
basically
has
a
proportional
or
inversely
proportional
metric,
where
the
metric
is
almost
directly
inversely
proportional
to
the
reference
bandwidth
that
is
defined.
R
If
the
operator
wants
to
have
a
different
set
of
metrics
for
a
different
set
of
range
of
bandwidths,
you
can
have.
You
can
use
this
method,
so
the
bandwidth
threshold
subtle,
will
have
a
staircase
model
where
certain
thresholds
are
defined
and
the
corresponding
metric
is
defined.
We
can
look
at
the
example
in
the
next
slide.
R
Please
go
to
the
next
slide
right,
so
here
we
have
an
example
where
you
defined
thresholds,
like
you,
have
the
bandwidth
threshold
1
min
as
5
gigabits,
which
basically
says
that
anything
less
than
5
g
bandwidth
should
be
given
the
maximum
metric
and
any
bandwidths,
which
is
any
of
the
linked
bandwidths,
which
is
between
5
to
50.
Gbps
gets
a
metric
of
5000
and
anything
between
50
and
100
gets
a
metric
of
50
and
anything.
Similarly
between
anything
above
100
gbps
gets
a
metric
of
25
next
slide.
Please.
R
Right
so,
based
on
the
review
comments,
we
can
we'd
like
to
call
for
working
group
adoption
questions.
B
Hey
this
is
ac,
more
or
less
speaking
as
a
working
group
member.
I
think
this
is
a
good
example
of
how
flex
algorithm
can
be
used,
that
you
know
this.
This
new
algorithm
defined,
which
is
you
know,
with
different
metrics
and
constraints.
I
think
this
is
really
really
good.
I
had
one
more
comment.
I
noticed
there's
a
lot
of
you
know.
B
Whenever
we
talk
about
delays
and
things,
there's
discussion
on
the
measurement
of
these
things,
which
is
kind
of
out
of
scope,
I
mean
you
should
provide
precisely
define
it,
but
how
to
measure
it.
I
don't
know
that
you
need
to,
but
you,
but
it
would
be
good
to
to
provide
guidance
on
how
often
it
is
and
how
frequently
it's
updated
thanks.
J
Q
Much
yes,
I
had
a
question
about
so
you
know
from
the
list.
I
guess
the
discussion
about
the
metric
so
and,
and
the
use
of
I
guess
real-time
bandwidths-
to
to
update,
I
guess
the
the
metric
that's
used
in
the
fad
calculation
and
and
static,
I
guess
versus
dynamic
values,
and
I
guess
also
the
discussion
related
to
possibly
like
instability
with
the
metric
changing.
I
guess
that
was
one
of
the
concerns,
so
just
wondering
I
guess.
Q
Let's
say
you
have
thresholds
that
are
set
up
and
based
on
that
you
can
include,
or
you
can
exclude
different
links
similar
to
like,
like
a
like,
an
rcpt,
exclude
type
function
which
makes
sense,
but
I
think
they,
the
bigger
question,
I
guess
related
to
instability,
and
maybe
you
can
talk
about
that.
Just
how
using
these
dynamic
measurements,
I
guess
to
to
update
the
metric
and
how
how
that
will
not
prevent
you
know,
cause
any
type
of
instability
with
the
igp.
Thank
you.
R
Right
now,
thanks
yeah,
so
the
exclude
constraints
which
have
been
introduced
by
this
draft.
We
expect
that
the
operators
use
them
with
caution.
R
So
in
most
deployments,
when
you
want
and
want
to
bring
down
a
link
if
the
constraints
are
not
met,
it
is
very
likely
that
you
have
alternate
paths
available
so
yeah.
So
when
you
use
that
constraints,
you
have
to
define
the
thresholds
as
well
and
make
sure
that
the
topology
is
safe.
For
that
one.
One
more
thing
regarding
bandwidth
is
that
the
bandwidth
when
you
said
dynamic
bandwidth,
it's
again
the
link
bandwidth
which
changes
only
when
member
link
can
go
down.
A
So
we
are
unfortunately
with
one
minute
left
in
this
presentation
is
next
in
the
queue
I
don't
think
we're
gonna
get
through
everybody
else.
I
don't
know
have
any
way
to
cut.
You
know
to
end
the
queue
in
the
interface
so,
and
I
didn't
want
to
interrupt
so
go
ahead.
Uma.
O
Okay,
that's
thanks
thanks
chris,
it's
very
useful
draft
and
in
some
cases
very
useful,
but
you
know
one
thing
I
would
like
to
see
in
this
draft
is
discussion
about
the
changing
metrics.
What
is
the
impact
of
the
packet
reordering
right?
So
not
everything
really
changing
right.
So
if
that
is
discussed,
that'll
be
good.
R
A
E
The
interesting
topic
and
I've
seen
a
lot
of
discussion
on
the
main
list.
I
have
maybe
two
comments.
The
first
one
is
the
imaginative
bandwidth
metric.
The
new
metric
on
the
bandwidth
is
it
tightly
coupled
with
flash
algo
or
it's
just
a
generic
new
metric
tle.
R
Right
so
the
bandwidth
metric
subtle,
which
we
have
introduced
in
the
draft
right
now,
it's
generic,
it's
applicable.
It
can
be
used
by
any
application
as
well.
R
E
It's
a
better
to
clarify
that
this
can
be
used
in
more
general
cases
and
the
second
one
is
the
latency
and
bandwidth
constraints.
I'm
not
sure
whether
they
can
be
treated
in
the
similar
way
because
latency,
you
need
to
count
the
accumulated
latency
for
enter
and
pass.
If
you
just
use
a
constraint
as
a
maximum
latency
on
a
particular
link.
Is
that
really?
R
R
Right
so,
as
I
said
you,
if
you
want
a
link,
delay
based
traffic,
you
are
most
likely
to
use
link
delay
as
the
metric
type,
but
in
a
any
other
flexor
goes
if
you
want
to
have
define
very
high
link,
delay
value
where
you
want
to
say
that
if
a
single
link
is
performing
very
badly,
you
want
to
exclude
that
link
from
flex
sergo.
So
this
constraint
can
be
used
in
such
cases.
So
it's
it's,
definitely
not
inter
interrupt
it's
not
interfering
or
doesn't
have
a
say
in
the
metric
value.
R
A
Shadow,
you
go
ahead
and
then
I
I
don't
know
we
can't
do
whoever's.
Last
yeah.
S
So
if
the
measurement
is
static,
then
we
really
don't
need
to
use
come
up
with
new
constraints
because
link
colors
can
already,
you
know,
do
what
what
is
required.
So
this
is
specifically
to
improve.
You
know
operations
when
these
link
bandwidths
are
changing
dynamically,
especially
when
in
case
of
l2
bundles,
the
bandwidth
changes
dynamically
and
similarly,
when
dynamic
delay
measurement
is
used.
The
latency
of
the
link
changes
dynamically
so
with
respect
to
actual
measurements
and
how
often
that
is
flooded.
S
The
delays
are
delays,
get
flooded
that
is
kind
of
out
of
scope
for
this
document.
So
it's
it's
mainly
saying
you
know,
providing
an
ability
to
advertise
a
constraint
that
says
exclude
a
certain
link
which
is
having
you
know
certain
threshold
delay
value.
So
that's
that's
pretty
much.
It
is
doing
so.
I
just
wanted
to
clarify
that
and
yeah.
S
We
will
add
the
text
about
the
clarifications
that
william
provided
on
with
respect
to
like
if
the
area
partitions,
because
of
you
know
this
dynamically
changing
values,
either
bandwidth
or
delay
and
and
what
operate,
how
operators
need
to
care
for
that.
Thank
you.
T
I'm
team
from
time
telecom
my
presentation
is
using
flex
argo
for
the
routine
based
vtn,
the
last
meeting
we
have.
We
did
the
presentation
about
the
first
one,
the
drafts
through
rsi,
as
it
is
srvtn
flat.
Argo
version
one
this
time
we
did.
We
revised
the
draft
and
did
this
presentation
next
step.
Please.
T
T
Enhanced
vp,
as
the
underlay
of
vpn
plus
services,
as
I
saw
based
vt,
has
described
that
in
draft
itf
spring
sr4
enhanced
the
vp
vpn
this
pro
it
provides
the
mechanism
and
the
procedures
to
build
as
a
beast
vt
using
resources
and
this
resource.
Where
a
well
aware
thing,
and
in
some
scenarios
each
srv
team
can
be
associated
with
a
unique
flight
argument.
T
This
document
describes
the
flash
argo
based
control
plan
control
plan
mechanism
for
distributing
the
topology
and
the
resource
information
of
isr
bts.
Next.
For
us
please
next
slide,
please,
let's
look
at
the
vector,
plus
algorithm
is
developed
at
the
control
plane
identifiers
above
routine,
but
in
this
part
we
used
flat
argo
to
describe
the
topology
constraints
for
rvtn
and
use
ada's
sr
to
advise
our
algorithm
specific
prefix
is
or
as
availa
a
six
locators.
T
T
In
in
this
in
in
this
in,
in
this
this
slide,
we
can
you
can
see,
that's
the
flag
intake
in
this.
The
membranes
are
watching
that's
their
fit
with
the
current
earth
region.
Fist,
each
cv
team
is
associated
with
one
water
or
special
bamboo
link
in
the
bundle
we
use
the
main
group,
that
is
the
color
of
two
colored
car
colors
that
carries
the
flower
and
the
membrane.
T
That's
the
last
meeting.
We
present
version
one
this
this
this
time
we
opted
in,
we
do
some
little
modified
modification
in
its
version.
That
is
we.
We
clarify
the
limited
limitations
in
the
usage
of
atomic
group
concepts
in
flex,
argo
definition
where
flex
algorith
is
used
to
added
identify
rbt
each
online
include
any
admin
group
rule
can
be
used
and
other
these
preferences
about
the
user
of
the
v
flag.
T
U
Hi,
this
is
tariq
from
juniper.
My
question
is
related
to
the
use
of
flex
algo
to
achieve
what
you're
trying
to
do.
U
As
we
know,
flex
algo
comes
with
overhead
of
advertising,
the
definition
and
then
knows
consuming
the
definition
and
and
doing
spf
with
the
respective
algorithm.
U
A
E
The
answer
that
I
think
regarding
the
scalability
in
this
draft
there's
a
section
about
the
scalability
considerations
which
talks
about
the
possible
limitations
using
the
flat
circle
id
as
the
identifier
of
the
vta
in
the
control
plane
for
better
scalability.
We
also
have
other
drafts
which
can
support
multiple
vtns
share
the
same
topology
and
that
one
requires
some
more
extensions
to
the
control
plane.
But
maybe
we
can
have
some
further
discussion
about
that
topic
later.
Yeah.
E
Yeah
we
have
another
draft
about
the
scalability
considerations
in
teas
and
because
we
can
see
different
scenarios
can
have
different
requirements
on
the
scalability
and
we
mean-
and
each
mechanism
has
this
pros
and
cons
in
terms
of
the
complexity.
The
changes
to
the
protocol
and
the
scalability
is
just
one
aspect
of
that.
A
P
P
P
I
don't
think
that's
the
right
way
of
encoding
the
things.
This
is
a
very
error
prone
and
I
I
would
not
prefer
people
doing
that.
I
mean
if
you
want
to
advertise
a
beating
specific
stuff,
define
a
bitching,
specific
information
and
put
it
there
and
don't
hijack
the
existing
ones
and
then
map
it
via
some.
You
know
set
by
the
value.
A
So,
as
a
working
group
member
I
when
I
read
this
draft,
when
I
saw
the
admin
color
use,
I
was
hoping
to
see
that
this
was
just
going
to
be
able
to
be
informational
right.
So
when
I
see
admin
color
being
used
a
lot
of
times,
it's
because
we're
going
to
reuse
mechanisms
without
having
to
do
any
normative
changes.
A
A
E
Robin
okay,
maybe
it
wasn't
okay
before
robin
can
talk.
I
can
I
briefly
answer
peter's
comments
and
the
way
we
choose
to
reuse
the
admin
group
and
to
correlate
with
the
flux
algo
id
is
based
on
the
existing
flux,
organ
mechanism,
to
correlate
a
link
with
the
flight
cycle
definition.
This
is
to
minimize
the
changes
to
the
protocol.
If
we
introduce
a
dedicated
identifier
for
atm,
that
is
another
approach
that
will
require
more
protocol
extensions,
and
we
can.
We
can
also
consider
about
that.
E
If
people
think
the
flash
algo
base,
the
correlation
is
error
prone,
and
that
is
what
flat
algo
is
defined.
A
A
Yes,
thank
you.
Next
up
is
the
l2
bundles.
V
V
V
V
If
we
want
to
advertise
unique,
extended
administrative
total
group
values
for
each
bundle,
a
member,
we
can
use
multiple
l
to
bundle
attribute
crafters,
which
is
specified
a
single
bundle.
Members
no
extensions
is
needed,
and
the
lsr
ospf
bundles
draft
also
defined
how
to
members
attribute
subtree
for
ospf
or
spf
worsens
3
to
advertise.
The
link
attribute
of
l2
bundle
members
and
mentioned
that
the
traditional
main
other
main
choice,
administrative
group,
sub,
troa
and
extended
and
minus
20
group
sub
tier
way,
may
be
content
in
our
bundle.
V
Members
attributes
of
troy,
because
there
is
l2
about
no
member
attribute
subtrov
for
l2
bundle
member.
It
is
also
a
sufficient
to
construct
flash
aggro
plan
to
select
how
to
link
resource,
but
is
this
draft?
We
only
extend
flash
argo
definition
flags
we
obtained
a
new
flag
of.
Is
this
a
flight
circle
definition
of
flight
sub
troy
and
the
ospf
of
id
flight
subtle
away
to
let
each
node
to
check
out
members
link
resources
of
interface
bundle?
Dual
reflex
algorithm
past
calculus.
V
V
At
the
second
days
we
yield,
which
we
use
l2
boundary
members
attribute
tre
subtly
with
traditional
administrative
group,
sub-tree
and
extended
administrative
groups
of
troa,
based
on
this
class
on
iosa
a
minute
and
the
washing
zero
three
and
zero
four.
We
add
the
flashlight
go
out
to
bundles
use
cases
and
add
the
fad
flex
expenses
in
version
zero.
Five,
we
add
co,
also
yum
ting
from
china
telecom
and
some
more
editorial
changes.
V
C
P
Okay,
so
my
very
basic
comment
here
is:
I
mean,
as
one
of
the
co-authors
of
the
of
the
flex
algo
specification.
P
Calculations,
I'm
I'm
basically
asking
what
is
this
something
we
want
to
do?
I
guess
the
right
solution,
for
this
is
an
srte
where
the
srte
can
use
all
sorts
of
information
to
do
the
constraint
based
spf.
P
V
Thank
you
peter.
Thank
you
very
much.
Thanks
for
your
comments.
Yes,
you
have
seen
some
mails
and
we
have.
We
have
discussed
it,
but
I
still
think
the
problem
that
flash
ago
uses
for
outbundles
needs
to
be
solved.
V
A
Yeah,
it
might
be
good
if
people
there's
already
been
some
discussion
on
the
list,
but
if
you
have
strong
opinions
about
this,
please
post
them
on
the
list.
All
right.
Good
luck!
Thank.
V
V
A
J
V
Most
recent
algorithm
identifier
is
often
included
as
part
of
a
prefix
state
advertisement
that
may
be
not
satisfy
some
scenarios
where
multiple
algorithms,
here
the
same
link
results.
This
document
complement
that
the
algorithm
identifier
can
be
also
included
as
part
of
agency
advertisement.
V
V
Obviously,
8667
describes
the
existences
that
need
need
to
be
introduced
for
the
resulting
operating
on
a
mpi
state
plan
at
a
defined
agency
said
sub-tre
underlying
agency
sub-troa.
According
this
draft,
defense
defines
two
new
optional
subtitle
base.
Is
this
agency
for
algorithms
of
tree,
and
is
this
lan
at
this
adjacent
seat
for
algorithms
of
tree?
V
This
is
the
exists.
As
you
see,
the
algorithm
subtlety
has
the
volume
format.
The
algorithm
field
contains
the
identifier
of
the
algorithm,
the
router
uses
to
apply
algorithms,
specific
cues
policy,
config
agency
and
the
seed
label
index
and
the
weight
fields
refer
to
the
audiences.
It
stopped
your
way
and
the
payload
below
is
the
format
of
the
live
agency
seat
it
it.
It
also
extends
a
flat
algorithm
field
next
place.
A
So
can
we
if
these
are
just
replications
for
the
three
protocols,
can
we
go
past
them?
Are
they
the
same
tlb
right.
V
K
Thank
you.
So
you
know
we
already
have
ample
mechanisms
within
flex
algo
for
doing
link
assignment
to
an
algorithm,
such
as
administrative
coloring.
Why
do
we
need.
A
V
Yeah,
yes,
in
the
most
recent
house,
reduced
that
algorithm
identifier
is
often
included
as
part
of
a
prefix
seed
advantage,
but
not
satisfied
some
scenarios
where
multiple
algorithms
use
the
same
link
resources.
So
we
extend
this
draft.
B
Well,
why
don't
you
post
that?
I
mean,
if
you
don't
mind,
why
don't
you
raise
that
a
question
again,
so
I
can
have
more
discussion.
Tony.
V
U
Make
up
some
time
yeah
tariq,
stark
everybody!
My
name
is
tarek
saad
and
I'm
going
to
talk
to
you
about
some
extensions
for
segment,
routing
sids
that
are
advertised
in
igp
to
associate
them
with
slice
aggregates
this.
Hopefully
this
is
going
to
be
very
quick
presentation,
so
please
move
to
the
next
slide.
U
So
I'll
talk
a
little
bit
I'll,
give
pointers
in
fact
about
the
overview
and
then
the
encodings
very
quickly
and
then
I'll
mention
the
next
steps.
The
next
slide
please.
U
So
in
the
first
draft
ns
packet,
we
are
introducing
two
new
concepts:
the
the
a
slice
policy
which
is
used
in
instantiate
resources
for
a
slice
aggregate
and
a
slice
aggregate
is
a
collection
of
packets
that
get
the
same
forwarding
treatment
on
a
on
a
on
a
shared
resource.
U
This
this
draft
will
be
presented
on
tuesday
in
the
tees
working
group.
In
case
you
want
to
follow
that.
The
second
draft
is
the
scalable
ns.
It's
it's
a
spring
working
group.
Sorry,
it's
a
spring
draft.
It
will
hopefully
become
a
working
group
draft,
but
it's
a
it's
proposing.
U
How
do
we
create
or
instantiate
these
slice
aggregates
in
an
sr
network,
and
one
of
the
options
proposed
is
to
allocate
different
sets
for
the
same
topological
element
and
associate
it
with
a
slice
aggregate
and
again
packets
forwarded
with
that
a
specific
sid
associated
with
the
slice
aggregate?
It
gets
the
forwarding
treatment
that
was
allocated
or
yeah
allocated
for
that
slice.
U
Aggregate
on
on
the
path
next
slide,
please
so
for
this
we
need
to
in
an
rfc
8667,
the
encodings
for
the
sids,
prefixed
and
jccc
sets
are
defined.
U
We
need
to
carry
a
new
identifier
and,
and
those
tlvs
for
the
prefix
said
and
adjacency
said
it's
a
32-bit
identifier
that
we
are
proposing
to
carry
in
the
advertisement
and
using
this
we
can
advertise
different
indices
for
the
same
prefix,
and
then
that
will
result
in
srmpls
to
different
labels
resolved
in
the
srgb.
U
U
U
So
the
objective,
a
very
high
level,
is
to
associate
a
sid
with
a
slice
aggregate
using
this
32-bit
identifier
and
the
specific
treatment
is
defined
using
a
slice
policy
which
is
outside
the
scope
of
this
draft,
and
I
think
that's
about
it
of
what
I
wanted
to
technically
present
in
terms
of
next
steps.
U
U
And
any
questions
you're
welcome.
B
I
don't
have
any
questions
just
as
a
working
group
chair.
I
I
I
think
that
the
whole
slice
egg,
the
slice
slice
e-
would
need
to
be
adopted
in
keys
first
right,
you're
targeting
that
and
this
concept,
and
whether
or
not
this
concept
of
a
splice
aggregate
is
the
right
one
to
satisfy
the
requirements.
That's
before
we
just
jump
to
the
encodings.
U
Yeah
we
definitely
we
are
going
to
push
for
adoption
of
the
the
draft
that
we're
presenting
in
teas
and
for
the
slice,
aggregate
definition
and
and
slice
policy.
Those
we
are
going
to
work
with
the
people
driving
the
framework
for
slicing
and
try
to
include
those
terms
in
there
as
well.
P
Peter,
so
so
how
many
of
these
slice
aggregates?
Are
we
talking
about?
Because
you
just
mentioned
that
flex
algae
doesn't
scale
it's
if
we
wanted
too
many
of
the
slices,
which
you
know
I
tend
to
agree,
it's
not
400
of
them.
So
how
many
of
these
slice
aggregates?
Are
you
expecting
to
have.
U
We
have
to
be
realistic,
we're
shooting
something
in
the
order
of
you
know
more
order
of
hundreds
to
a
thousand
slice
aggregates
within
the
transport
network.
The
the
point
that
we're
the
our
proposal.
We
want
to
decouple
the
computation,
as,
as
you
saw
the
you
know,
I
did
not
mention
any
flex
I'll
go
it's
it's
yeah.
U
U
It
could
be
hundreds
of
sisa
ids,
so
you'll
have
yeah,
that's
what
not
prefix
sids
will
be
bigger
than
that
right
depends
on
the
size
of
the
network.
P
Yeah,
okay!
Well,
I
guess
you
know
we
understand
each
other.
U
U
Just
yeah
yeah
I
just
I-
I
want
to
complete
it
off,
but
by
mentioning
that
the
proposal
we
have
in
spring
has
two
options.
One
does
not
dictate
this
igp
extension
at
all.
It's
a
data
plane.
You
know
we
carry
the
slice.
Aggregate
id
in
the
label,
stack
for
example,
or
is
separately
in
the
packet
it's
carried
in
the
packet,
but
people
are
you
know
there.
There
are
implications,
obviously,
for
hardware
to
inspect
this
specific
extension
for
carrying
in
the
packet
for
those
we
are
proposing.
This
type
of
extension.
U
E
N
Okay
last
comment:.
O
So
the
question
is,
like
you
know,
I've
said
hundreds
of
thousands
of
slice
aggregates.
Why
are
we
putting
a
little
bit
identifier
here?
No
sounds
great.
I
didn't
mention
hundred
thousand,
I
said
hundred
to
a
thousand
yeah
hundred
two
thousand,
but
you
put
32-bit
essay
id
here.
O
Yes,
I
got
that
I
got
that,
but
then
what
do
you
represent?
The
essay?
I
did
32
bits
point,
but
you
know
just
think
about
it.
U
Yeah,
okay,
it's
a
good
comment.
Yeah.
We
will
think
about
that
in
fact,
yeah
we're
open
to
crunching
that
if,
if
we,
if
we
need
to.
A
A
M
A
M
Good
good,
okay,
so
here
we
want
to
present
the
ospf
extension
for
the
5g
edge
computing
services,
even
though
this
is
the
first
time
we
present
at
this
our
lsr
group.
We
have
got
quite
a
few
comments
and
we
have
changed
the
draft.
According
to
those
two
addresses
comments.
Next
slide,
please.
M
M
M
There
are
many
use
cases
for
those
mission,
critical
applications
and
the
basic
network
assumption
is
all
those
servers
are
attached
to
those
routers
directly
in
the
mini
data
center.
The
distance
from
those
equals
router
to
the
application
server
are
very
little
minimal.
They
are
co-located,
so
we're
not
considered
in
this
environment.
The
dissident.
N
A
M
Okay,
so
let's
continue
on
this
page
more
and
more
often
anycast
has
been
used
for
many
applications.
There
are
many
advantages
of
anycast.
First,
for
all,
is
the
anycast
allow
basically
leverage
the
network.
Proximity
allow
the
traffic
to
be
forwarded
to
the
optimal
destination,
with
network
condition
in
mind.
M
Second,
eliminate
the
single
point
of
failure,
like
you
may
have
application
load
balancer
if
it
just
if
the
network
reachability
to
the
load,
balancer
fail
or
congested
the
traffic
performance
services
deteriorate
with
any
cast
the
network
itself
being
able
to
leverage
the
information
and
be
able
to
forward
it
to
the
optimal
destinations.
It's
truly.
The
network
help
the
application
to
perform
better
and
also
avoid
some
ue
or
client
using
the
stealth
addresses
in
the
cache
instead
of
a
query
dns
for
the
refresh
addresses
okay,
but
they
also
have
problems.
M
The
problem
with
anycast
in
the
5gh
computing
environment
is
the
routing
distance
to
multiple
edge.
Servers
are
very
small
and
there
could
be
unbalanced
distribution
because
of
ue
mobility
moving
from
one
cell
station
to
another.
It
could
be
many
ues
attached
to
one
cell
tower
or
try
to
access
the
same
server.
M
M
Okay,
so
for
the
anycast
in
the
5g
edge
computing
environment
to
select
optimal
server
optical
anycast
server,
we
kind
of
narrow
it
down
to
selecting
the
egress
router,
because
the
distance
from
e-waste
router
to
the
anycast
server
is
minimal.
It's
negligent
so
that
from
network
perspective,
the
criteria
is
really
to
finding
the
the
matrix
like,
for
example,
round
trip
time
to
the
egress
router,
and
on
top
of
that
there
will
be
other
factors
in
determining
the
optimal
egress
router.
One
is
the
capacity
for
example.
M
At
for
the
server
anycast
server
attached
to
router
r1
can
be
higher
capacity
than
the
anycast
server
attached
to
r2,
simply
because
there's
could
be
thousands
or
hundreds
of
servers
attached
behind
a
load
balancer
from
network
perspective.
We
only
see
the
network
load
balancer
the
front
end,
and
so
it
is
preferred
to
be
able
to
forward
the
traffic
to
a
location
where
the
capacity
is
higher.
M
M
So
here
we
want
to
show
that
in
the
lsr
in
ospf,
if
all
the
egress
routers
are
from
from
same
vendor
or
from
under
the
same
management
system,
that
they
can
have
the
consistent
algorithm
to
calculate
the
aggregated
cost,
meaning
the
cost,
including
the
round-trip
delay
and
the
cat,
the
site
capacity,
the
site
preference
they
can
be
making
it
together
a
consistent
value.
Then
there's
nothing
need
to
be
changed
for
the
error
for
the
ospf.
M
We
can
use
existing,
that's
subtle,
existing
encoding
and
be
able
to
for
ipv4
and
ipv6
data
frame
right
and
network.
So
we
basically
in
the
ipv4.
We
just
include
the
encoded
in
the
matrix
field
of
the
stop,
stop
link
as
lsa
for
the
ipv6.
M
A
We're
running
short
on
time
is,
it
is,
are
there
going
to
be
a
lot
of
tlvs?
Can
we
skip
forward.
M
Okay,
so
just
three
more
two
more
tlbs,
well
yeah,
two
more
okay,
so
but
for
environment.
Where
that
not
the
not
all,
egress
router
can
have
a
consistent
algorithm
to
calculate
aggregate
cost
or
some
environment
where
some
routers
need
more
detailed
information,
and
then
we
need
a
special
sub
trv
to
carry
the
information
which
include
load
measurement
capacity
index
and
site
preference,
and
we,
this
is
based
on
the
email
middle,
is
discussion
that
we're
using
this
extended
prefix
opaque
lsa
to
carry
those
information.
Carry
those
subjects.
M
A
So
I
put
myself
in
first
because
I
I
definitely
looked
through
this
there's
a
lot
of
phyllis.
This
is
a
working
group
member
not
as
chair,
but
there's
a
lot
of
philosophy
going
on
here.
I
don't
have
time
to
go
into,
but
the
fundamentally,
it
seems
like
what
you're
trying
to
do
is
push
application
load
balancing
into
and
have
routing
do
that
job
right,
you're
asking
routing
to
do
the
application
load,
balancing!
That's
a
pretty
big
ask
and
a
pretty
big
change.
A
You're
having
to
add
this
information,
because
any
cast
is
there
to
solve
this
sort
of
simple
problem
right.
I've
got
a
bunch
of
servers
and
I
need
to
go
there
and
anycast
works
for
that,
but
it
doesn't
work
for
you
because
you
want
to
do
a
lot
more
with
it
right
and
so
you're
having
to
add
all
this
stuff,
I
think
you're
going
to
get
some
pushback
on
the
whole
idea,
because
I
don't
think
people
are
going
to
be
happy
with
trying
to
use
the
routing
system
as
an
application
load
balancer.
M
Okay,
actually,
in
a
3gbp
there's
a
project
called
edge
computing
over
there.
Anycast
is
proposed
as
a
way
to
balance
the
traffic.
This
is
not
try
to
replace
the
load.
Balancer
load
balancer
still
could
be
there
in
any
of
the
mini
data
center.
When
you
have
multiple
servers
or
you
have
a
load,
balancer
application
load,
balancer
among
multiple
locations,
you
could
have
a
low
balance
application
layer
load
balancer
there.
This
anycast
is
really
for
the
environment,
where
you
have
multiple
load
balancers
in
the
network,
not
just
one.
A
Understand
but
you're
basically
saying
I
want
to
use
any
cast,
but
if
I
if,
but
I
don't
want
it
to
just
pick
any
cast
based
on
routing,
so
I'm
going
to
add
all
this
extra
information
right,
so
you're
not
happy
with
any
cast
you're
expanding
the
concept.
That's
a
big
thing
right!
That's
all
I'm
saying
I'm
not
saying
good
or
bad!
I'm
just
saying
it's
a
big
ask!
I
I
don't
want
to
be
the
only
one
that
talks
go
ahead:
ac,
okay,
I'm.
B
Gonna
take
mine
to
the
list,
I'm
just
gonna
say
I'm
happy
that
you
I
see
today,
you
you,
you
fixed
the
encodings
in
the
draft,
because
I
that
was
going
to
be
one
of
my
comments
and
I
and
I
looked
at
the
latest
version
and
it
matches
your
slides
all
right.
So
I'll
put
the
I'll
have
the
rest
of
the
comments.
The
list
thanks.
Q
Hi,
my
name
is
gion
mishra
with
verizon
and
I'd
like
to
go
over
the
draft
prefix
unreachability
announcement
next
slide.
Q
There
we
go
thank
you,
so
we
we
went
over
this
draft
on
the
last
last
ietf
and
from
the
feedback
from
the
work
group
as
well
mailing
list,
as
well
as
the
last
ietf.
Q
We
we've
done
a
revamp
on
the
draft
and
really
really
hone
again
on
the
issue.
No,
that
the
reuse
case
that
this
solution
would
solve.
With
this
prefix
and
reachability
announcement
and
really
cleaning
up,
you
know
all
the
other
related
thing
items
within
the
draft.
So
really
just
a
single
issue
problem-
and
you
know,
with
this
motivation
problem
statement
and
then
a
solution
kind
of
marrying
the
solution
to
that
problem
statement.
Q
So
with
that,
so
the
motivation
behind
this
draft
is
it's
based
on
either
a
mpls
exact
match
on
a
host
route
effect
binding
or
an
srv6
bgp
service
overlay
using
traditional
unicast
u-rib
longest
prefix
match
in
a
scenario
where
the
igp
domain
is
carved
up
into
multiple
ospf
areas
or
isis
levels
and
summarization
is
unified,
so
that
that's
really
the
key
use
case
where
we're
honing
in
so.
Q
In
this
use
case,
the
summarization
of
inner
area
routes
are
propagated
into
the
backbone
area
for
flood
reduction
and
made
up
of
component
prefixes
and,
in
this
use
case,
we'll
go
over
in
a
further
slide
or
really
the
net
bgp
next
hops
that
would
that
are
being
flooded
so
with
this
so
with
the
summarization.
What
happens
is
these
components
of
the
summary
are
now
are
now
masked
and
just
sent
as
a
summary.
Q
So
what
this
feature
does
with
this
prefix
unreachability
announcement
it
it's
it's
these
prefixes
that
we're
now
able
to
track
and
prevent
a
an
outage
or
black
hole
above
routes.
The
dead
end
on
navy
are
when
a
failure
occurs.
Q
So,
as
I
said,
we've
we've
completely
revamped.
The
draft,
if
you
haven't,
had
a
chance
to
look
at
it,
we'll
we'll
discuss
more
on
the
mailing
list
following
this
atf
call,
but
the
the
updates
of
the
drafts
is
really
just
hunting
on
this
one
use
case.
That's
that's
related
to
summarization.
It's
a
bgp
next
top
tracking
of
vpn
overview
services.
Next
slide.
Q
So
the
scenario
at
a
high
level.
I
think
of
what
would
happen
in
this
particular
use
case.
So
let's
say
you
have
you
have
a
router
r2
and
r4
they're
they're,
generating
a
summary
route
so
on
the
right
side
within
the
area,
zero
you're,
sending
a
summary
over
to
area
zero
area
one
and
then
you
have.
You
have
a
vpn
overlay.
So
you
have
you
have
a
vpn
routes
that
are
being
learned
between
s2
and
t2,
s2
on
the
left
and
t2
on
the
right.
Q
So
when
there's
a
failure,
that
happens,
let's
say
a
node
failure.
So
t2
goes
down.
You
still
have
a
summary,
that's
being
advertised
from
r2
and
r4
back
over
to
our
r1
and
r3.
Q
So
when
that
lsp
gets
built
across
the
area
it
gets
built,
it
ends
up
dead,
ending
right
on
the
right
on
the
abr
on
r2
and
they're,
basically
back
back
you're,
basically
black
hole
black
hole
in
traffic
going
to
t2
this,
the
convergence
doesn't
happen,
the
fit
the
failover,
because
the
the
component
prefixes
that
that
they're
represented
by
that
summary
address,
are
not
there.
This
this
and
so
this
feature
related
summarization
with
mpls.
It's
related
to
rfc
5283
with
the
inter
area,
ldp
extension,
this
this
same
concept
and
we'll
go
through
it.
Q
It
actually
applies
as
well
to
srv6
where
you're
doing
longest
prefix
matching
as
well
with
it.
So
with
mpls
with
the
ldp
rfc
5283
you
you
are
you
end
up
doing
as
long
as
prefix
match,
because
you're
creating
a
summary,
but
but
now
with
the
component
routes,
not
not
without
being
present
with
the
summary
you're
not
able
to
track
it,
and
thus
you're
you're,
just
really
black
holding
right
on
that
apr.
Q
C
Q
Q
The
same
use
case
we
can
go
over
to
the
next
slide,
thanks
great,
so
so
upon
receiving
a
link
or
note
failure
with
the
pua
mechanism,
it
uses
a
isis
ipv4
v6,
a
source
router
id
sub
tlv
described
in
rc779
or
with
lspf
the
prefix
originator,
sub
t
I'll
be
described
in
the
lsr
ospf
prefix
originator.
Q
So
with
that,
it
actually
creates
a
that.
It's
advertised
the
the
source
router
sub
tlb,
of
where
the
of
the
failure
is
advertised
and
flooded
through
the
domain
using
normal,
so
using
standard,
ospf
and
isis
procedures
vote.
But
now,
with
the
next
with
the
originator,
information
set
to
null
next
slide.
Q
So
when
there
was
a
scenario
with
the
node
one
failure,
when
the
node
within
the
area
receives
a
pua
message,
it
plugs
into
all
the
aprs
I
guess
within
within
the
area,
and
so
that
that
triggers
when
that,
when
that,
when
that,
when
the
the
failure
happens,
the
that
type,
the
the
tlv
is
that
has
flooded
through
the
area
and
now
with
that
next
would
be
next
hop
set
to
null
zero
on
the
field
linker
node
and
that
triggers
the
control
plane
to
fail
over
from
the
active
lsb
to
the
backup,
lsp
and
the
same
same
same
situation
with
the
lincoln
node
failure.
Q
So,
as
I
had
described
earlier
so
this
scenario,
so
it's
it's!
Q
It's
related
to
the
crux
of
it
is
if
and
using
instead
of
having
this
flood,
all
of
your
your
loot
backs
or
be
your
bgp
next
half
attribute
like
throughout
a
domain,
especially
where
you're
carved
up,
and
you
want
to
save
on
your
on
your
control
plane
and
you
want
to
be
able
to
use
summarization
using,
let's
say
the
rfc
5283
in
the
mpl
scenario,
inter
area
extension,
and
you
want
to
make
that
viable
or
if
you're,
in
an
srv6
scenario
where
you're
up
you
still,
you
want
to
do
that
as
well,
but
you're
still
doing
the
longest
you're
doing
longest
prefix
match,
but
you,
but
you
want
to
be
able
to
track
those
component.
Q
Prefixes
related
to
that
next
hop
attribute
where
that
linker
node
failure
happened
and
now
you've
got
a
you're.
You've
got
a
dead
end
right
on
right
on
the
apr
during
the
summarization.
So
with
this
solution,
it
basically
provides
that
negative
pua
that
can
get
sent
out
to
track
that
next
hop
that's
down
and
and
and
force
the
control
plane
to
converge
from
the
from
that
longest
prefix
match
that
went
down
now
to
this
now
to
the
backup
path
so
still
forcing
that
immediate
control,
plane
convergence
next
slide.
Q
So
this
slide
is
really
describing
the
scalability,
so
this
is
you're
making
this
the
being
able
to
utilize
summarization,
where
you
have
thousands
of
pes
and
imagine
you're
flooding
your
next
top
attribute
throughout
the
domain.
It's
a
eating
up,
control,
plane,
resources.
So
now,
with
with
this,
you
you're
able
to
really
take
advantage
of
summarization
and
you
don't
have
to
flood
your
host
routes
throughout
the
network,
and
now
you
can
converge
when
those
component
routes
go
away.
Now
you
have
this
negative
pre-negative
advertisement
that
goes
out
to
track
track.
Q
Q
So
one
of
the
considerations
with
the
pua
feature
is
a
is
a
as
a
concept
of
a
maximum
maximum.
A
Q
B
C
Q
Would
protect
any
so
with
that?
The
originator
subtly,
as
long
as
the
prefix
is
working.
B
C
The
extra
the
you're.
B
You're,
assuming
that
you
know
about
the
prefix
and
then
it
goes
away,
you're
not
going
to
protect
something.
That's
going
away
that
that
you
want
to
protect
that
you
don't
know
about
when
you
come
up,
because
it's
stately
right.
Q
B
Know
about
so
it's
somewhat
timing.
It's
somewhat
timing
based
it's
kind
of
a
it's
kind
of
broken
in
that
way,
the
other
one
I
had
that
a
question
is-
and
I
made
this
before-
is
the
way
you're
encoding
it.
If
not
everybody
in
the
main
supports
it.
You're
gonna
actually
attract
traffic
towards
the
black
hole
and
the
prefix
originator
is
just
the
wrong
method
for
this.
Q
G
M
Thank
you
thank
you
and
let's
see
yeah
and
I
think
the
time
limited
so
do
you
meant
to
go
to
the
third
page
directly
same
case
talk
about
the
motivation.
It
goes.
N
M
Yeah
yeah
yeah,
thank
you
and
first
of
all,
we
can
find
that,
with
with
the
increasing
use
of
the
existing
to
disseminate
types
of
application,
information,
much
more
burden
are
generated
in
isis
protocol.
M
So,
in
addition,
advertisements
of
such
additional
information
not
directly
related
to
isis,
may
potentially
impact
the
routing
coverage
and
the
stability.
So
we
found
that
and
it
lasting
to
be
named
generation
information.
Is
it
fine
to
just
disseminate
application
information,
and
but
we
found
that
the
advertisements
of
general
general
information
must
occur
in
the
numeral
instance
of
the
iss
protocol?
Hence
we
hence,
we
found
their
requirements
that,
in
information
carried
in
generic
information,
tv
should
be
associated
with
another
information
carried
in
other
iss
instance.
M
So
in
less
draft
we
try
to
eliminate
the
potential
impact
on
the
routing
conver,
covered
convergence
and
stability,
as
well
as
avoid
the
association
issue.
So
we
present
a,
I
mean
an
optional
solution
to
separate
separate
dissemination
of
rotting
topology
and
traffic
engineering,
information
and
other
types
of
application,
information
into
multiple
flooding
process,
using
the
zero
instance
of
the
isis
protocol.
M
So
I
think
that's
just
why
we
we
we
try
to
clarify
it's
important
to
propose,
because
it's
private,
private
and
optional
solution
to
isolate
the
effect
of
flooding
and
the
processing
of
non-doubting
information
on
the
on
routing
stability
and
listen,
listen,
less
solution
can
minimize
the
complexity
of
implementation
and
the
cost
of
adjacency
is
maternity
due
to
less
mechanism.
We
share
a
common
agency
and
a
single
link
state
database
next
slide
please.
M
So
here
we
give
an
a
simple
example
here
to
clarify
the
update
process
operation.
We
have
defined
extension
in
less
draft
and
you
can
find
that
and
the
level
issues
in
the
table
means
that
each
level
link
states,
pdu,
carries
flooding
information
and
belongs
to
a
specified
mfi
and
yes
in
each
nfi.
Update
parameters
can
be
customized
in
depending
on
the
requirements
on
the
flooding
rate
of
different
information.
M
M
I
think
the
time
is
limited
and
yeah
yeah
here
we
have
a
conclusion
and
come
here
reaching
with
the
multi
instance,
and
we
think
we
have
more
discussing
in
the
meninist
between
these
two
draft.
But
we
need
to
point
out.
The
multi
flooding
instance
is
is
a
different
solution
to
isolate
the
non-routing
information,
flooding
and-
and
we
can
see
that
this-
it's
different
in
in
the
aspects
of
the
number
of
protocol
instances,
the
number
of
adjacency
and
the
number
of
the
link
state
database.
M
A
B
M
B
B
I
I
guess,
I'm
the
first
one
on
the
queue
this
is
ac.
Speaking
as
a
working
group
member,
I
was
just
gonna
say
you
said
it's
easier
to
implement.
You've
implemented
this.
B
B
A
B
A
Well,
I
think
we
had
some
interesting
stuff
come
up.
It's
too
bad.
We
don't
have
you
know
the
lounge
or
whatever
to
go
to.
I
guess
there's
gather,
but
in
any
case
I'll
see
you
guys
on
the
list.
Well,
we'll
see
you
on
the
list
and
in
probably
not
in
san
francisco,
but
virtually.