►
From YouTube: IETF113-LSR-20220324-1330
Description
LSR meeting session at IETF113
2022/03/24 1330
https://datatracker.ietf.org/meeting/113/proceedings/
B
B
Yeah,
okay!
Well,
I
think
we're
ready
to
start.
Let
me
go
back
to
the
slides,
okay
yeah.
We
shouldn't
wait
for
the
room
to
fill
up.
I
don't
think
it's
going
to
yeah
all
right,
everyone,
so
you're
in
the
lsr
working
group.
It's
pretty
hard
to
get
that
wrong
online.
So
only
those
two
other
people
in
the
room
hope
you're
there.
For
that
and
yeah.
I
t
113
hybrid
meeting.
B
B
Okay,
it
doesn't,
we
don't
have
an
agenda
slide
so
I'll
just
quickly
mention
our
agenda
is
fairly
full,
so
we
will
try
to
keep
people
to
their
things.
I
think
somebody
else
said
that
it's
ridiculously
full
or
something
like
that
so
I
had
to
I
I
feel
that
was
unfair.
We
we
left
like
five
minutes
slop
at
the
end,
so
hopefully
we
don't.
We
don't
run
to
the
very
end
and
with
that
I
think
ac
is
going
to
run
the
status
so
I'll
I'll
click
ac
talk.
D
D
D
D
D
D
D
D
D
Oh,
this
is
one
the
offers
of.
I
don't
have
the
pen
on
these.
I
guess
I'm
an
offer
on
one
of
them.
I
got
I
got
to
get
these
were
accepted
by
the
working
group,
but
the
offers
never
updated
them.
With
the
I
mean
they
were,
they
were
adopted,
but
the
offers
never
republished
them,
so
they
should
we
should.
Oh.
D
I
noticed
that
when
going
through
this
the
existing
documents,
I'm
going
to
get
a
hold
of
them
to
do
that
next
slide
and
we
had
a
bunch
of
adoption
requests,
not
a
bunch
but
a
bunch
of
highly
a
couple
of
highly
contentious
ones,
and
they
did
not.
They
were
not
adopted,
and
I
imagine
I
imagine
some
of
the
documents
that
we
have
today
will
be
asked
for
adoption.
Okay,
that's
it
again!
I
encourage
you.
I
didn't
want
to
spend
a
lot
of
time
because
we
have
a
real
full
agenda
on
working
group
status.
D
So
this
started
out
actually
a
couple
years
ago,
both
the
ietf
and
a
lot
of
the
large
companies
ibm
and
cisco,
notably
wanted
to
change
these
standards.
So
we
can
update
our
documentation
to
have
inclusive
language,
specifically
in
ospf,
getting
rid
of
the
master
slave
terminology
in
the
ospf
database
exchange,
so
mike
from
ibm,
contacted,
alvaro
me
and
alvaro
and
tried
to
get
oh,
and
we
kicked
off
this
effort
this.
This
is
a
draft
that
just
updates
the
current
and
let's
go
to
the
next
slide.
D
I'm
going
to
try
and
do
this
one
fairly
quickly
too
so
alvaro
did
the
initial
work
on
this.
I
agree
with
them.
We
replaced
master
slave
with
leader
follower
in
in
all
the
in
all
this
sections.
We
don't
actually
do
it.
We
don't
actually
do
a
biz
draft
on
rfc
2328,
but
we
have
a
document
that
that
that
updates
it
and
notes
the
sections.
This
draft
notes
the
sections
that
will
be
changed.
D
D
D
D
This
is
where
the
majority
of
the
changes
are
in
rfc
2328,
which
is
the
internet
standard
document
for
the
osvfv2,
also
in
appendix
3,
there's
a
figure
including
the
database
description
packet,
and
that's
where
the
ms
bit
is
going
to
be
changed
to
the
change.
The
l
bit
again.
This
document
just
updates
it
by
making
the
reference
it
doesn't
actually
replace
it
update
2328.
D
So
I
elboro
did
and
mike
both
noted
that
this
document
need
to
be
updated.
I
went
through
the
other
documents
and
looked
for
references
next
slide
to
master
slave.
Oh
and
I
found
ospf
b3.
Luckily,
since
ospf
v3
builds
on
v2,
the
only
reference
was
in
the
ipv6
figure,
with
the
database
exchange
packet
next
slide.
D
And
we
have
a
few
of
these.
There
was
one
example
reference
in
rfc,
four,
four,
four,
two,
four,
two,
two
two:
two:
it's
going
to
update
that
the
outer
bound
synchronization
we
might
wanna.
We
probably
want
to
do
a
biz
on
this
one
anyway,
but
this
updates
it
there's
a
there's,
a
picture
of
the
packet
and
some
annotation
in
that
one
too,
because
it
allows
the
reason
we
want
to
do
this.
One
over
is
because
dynamic.
Well,
isis
has
a
way
to
do.
D
Out-Of-Bands
synchronization,
today,
ospf
doesn't
and
the
dynamic
flooding
has
situations
where
you
get
into
a
problem.
That
problem
where
you've
done
flooding
reduction,
and
you
want
to
make
sure
you're
in
sync.
So
you
know
how
ospf
connect.
I
mean
how
isis
can
ask
for
complete
c
c
s:
m
p,
p
use
ospf
needs
to
be
able
to
do
the
database
exchange
out
of
say
out
of
band
as
well,
and
then
there
was
a
richard
algeria.
Did
this
informational
draft
there's
a
couple
just
ancillary
references?
D
E
D
Address
fan
or
ipv
different
address
families,
and
I
in
ospfv3
there
was
an
mtu
consideration,
so
it
just
had
a
picture
of
the
snippet
of
the
database
description
packet,
where
you
would
have
the
flags
and
that
had
it
as
well.
So
this
up
this
graph
updates
them
as
well
and
the
final
slide
now
I
want
to
say
something
really.
One
really
good
thing
about
this,
unlike
vrp,
where
it
was
all
over,
is
that
the
mib
and
the
yang
model
did
not
have
any
references.
D
Those
things
actually
take
deprecation
and
functional
code
changes
or
you
know,
implementation
changes
to
support
ospf
doesn't
have
any
of
those
where
you
really.
You
know
where
you
were,
where
you
need
to
deprecate
tables
and
do
it
the
old
way.
So
luckily,
the
next
step
would
be.
There
might
be
some
discussion.
We've
kind
of
discussed
this
among
ourselves.
We
think
this
is
a
natural
choice.
It's
really
nice
that
we
have
an
l
bit
rather
than
an
ms
bit.
D
The
reason
it
was
the
ms
bid
is
the
database
exchange
already
had
the
more
bit
to
say
when
you
were
done
sending
database
exchange
packets.
So
this
l
bit
makes
it
more
concise
in
the
figure
we
like
I'd,
say,
don't
just
say:
oh,
why
don't
you
make
this
primary
secondary
or
some
things
like
that
unless
you
have
a
real
good
reason?
Why
I
mean
there's,
there's
all
sorts
of
all
sorts
of
word
smithing
that
goes
on,
but
I
don't.
I
don't
think
I
think
this
is
a
this.
D
This
and
I'll
credit
alvaro
for
coming
up
with
this
choice.
I
think
this
is
a
really
good
choice,
leader
and
follower,
because
it's
analysis
to
what's
actually
happening
in
the
database
exchange
and,
finally,
I
think
we
need
to
you
know
we
talked
about
biz
work
on
just
on
these
documents.
Anyway,
I
think
we
need
to
do
this
in
the
interim
because,
like
I
said
my
company
and
ibm
and
others
really
want
to
update
our
documentation
as
soon
as
possible.
B
Yeah,
I
think
I
I
think
I
might
have
put
in
the
list
the
idea
about
the
about
doing,
abyss
and
grabbing
I
I'd
like
to.
We
don't
have
to
do
it
for
this
rev,
but
I
think
I
think
it's
worthwhile
since
we
do
have
errata
and
I
and
what
was
on
the
list
is
people
think
that
well,
it's
gonna
you're
gonna
open
it
up
to
open
up
a
can
of
worms
right,
like
I
don't
think
we
have
to.
B
B
Yeah,
I
mean
my
only
I'm
thinking.
I
guess
this
is
enough
for
companies,
but
if
I
was,
you
know
actually
looking
for
the
documentation
on
ospf
right,
I'm
still
going
to
pull
2328
whether
you
have
an
updated
thing
out
there
saying
you
know,
use
this
new
language,
it's
still
there
right,
so
I
don't
know
anyway.
It
seems
like
to
me
this
is
better,
but
we
can
probably
talk
about
this
forever
and
no
one
else
is
in
the
queue.
C
B
F
John
yeah,
I
was
debating
whether
to
say
anything,
but
since
he
brought
it
up
yeah
I
had
kind
of
the
first.
You
know
initial
reaction.
You
did
chris,
which
is
you
know.
You
already
said
it
all
already,
but
then,
as
ac
was
going
through
a
slide
deck
he
was
like,
and
this
rfc
is
impacted.
Then
this
rfc
is
impacted
and
this
rfc
is
impact.
That's
a
lot
of
rfcs.
F
So
like
I,
I
do
see
the
value
of
publishing.
One
short
document
that
you
know
says
what
the
updates
are
to
all
of
them,
but
I
I
would
hope
that
you
know
you
would
at
least
consider
then
subsequently
you
know,
as
as
you
get
around
to
it,
visiting
those
to
like
actually
take
care
of
rolling
in
the
changes,
because
I
do
think
for
the
reason
you
said
chris,
like
in
in
my
opinion,
is
really
just
an
individual
contributor
here,
but
I
think
it's
it's
better
to
have
it
in
the
spec
itself.
Thanks.
B
B
B
G
G
G
I
have
no
expertise
in
pub
sub
architectures,
so
apologies
if
I've
messed
something
up
contributions
most
welcome,
and
this
is
intended
to
be
more
general
than
just
liveness.
Despite
the
title,
I've
already
heard
a
proposal
that
we
stuff
a
bunch
of
capabilities
into
this,
and
that
would
be
most
welcome.
G
G
G
G
G
G
All
right,
all
the
rest
of
this
is
just
boring.
Tlv
definitions,
I'm
not
going
to
talk
through
them
in
growing
detail.
There's
registration
message,
then,
within
a
registration
message,
message:
there's
a
subtle
saying:
liveness
for
this
prefix
there's
a
notification
message
and
it
carries
some
tlvs
and
it
carries
liveness
notifications
for
a
prefix.
I
I
G
G
I
G
I
J
G
J
K
J
L
L
Tony,
have
you
considered
multihop
ipbfd?
I
have
not
read
your
draft,
so
maybe
you
have
lot
more
than
just
the
liveliness
check,
but
it
seems
like
you
are
also
propagating
the
failure
check
based
on
whoever
has
registered
like,
for
instance,
a
has
also
registered
to
be
notified.
If
the
c
has
gone
down
is
that,
even
though
the
session
is
between
a
and
b
liveliness
check,.
G
N
N
I
have
a
different
question
for
you:
you're
inventing
a
new
application
or
service
if
you
will
which
operators
are
going
to
have
to
configure
and
maintain
and
troubleshoot
and
the
source
of
all
this
information
comes
from
the
igbs
that
they're
already
running
and
know
how
to
configure
and
manage
so
forth.
Do
you
have
any
feedback
from
operators
as
to
how
they
feel
about
this?
Are
they
are
they
interested?
Are
they
scared
of.
O
G
N
N
D
He's
nearing
the
cisco
systems
that,
thanks
speaking
as
working,
remember
thanks
for
a
very
readable
draft.
It
was
very
easy
to
easy
to
read
through
this.
The
the
thing
I
was
going
to
point
out
is:
I
realize
it's
not
limited
to
this,
but
if,
if
you
put
all
your
loopbacks
in
one
hierarchical
prefix,
I'm
going
to
go
on
the
record
as
saying
I
don't
think
10
20
000
advertisements
of
loopbacks
and
ospf,
is
that
many?
D
I
don't
really.
I
really
don't
think,
especially,
maybe
because,
because
they're
real
small,
you
know
they're
little
small
lsas,
it's
not
a
big
deal
that
you
have
these
and
the
granularity
and
if
they
they
don't
go
up
and
down
that
often
you
know
it's
not
it's
not!
That's,
not
a
big
deal
to
me.
So
if
you
put
them
all
in
a
separate
prefix
anyway,
you
could
just
not
summarize
those
that
would
be.
My
first
comment,
my
other
one.
How
did
you
come
up
with
o
and
n
for
ipv4
and
ipv6?
That's
it.
D
D
B
P
O
G
B
Q
Q
Q
B
B
F
B
Q
Q
We
can
also
allow
multiple
vtn
to
share
the
same
set
of
network
resources
on
some
of
the
network
segments.
This
brings
flexibility
in
the
resource,
isolation
or
sharing,
and
the
third
one
is.
We
can
introduce
a
network-wide
v18
id
in
the
data
plane
so
that
we
can
avoid
allocation
of
the
distribution
of
additional
provition
segments
for
the
sr-based
vaping
plus
note
that
we
are
in
the
progress
of
an
alarm
to
align
the
terminology
of
vtn
and
nrp
in
a
set
of
documents.
So
here
we
just
keep
using
the
waiting
in
the
following
slides.
Q
Okay,
so
here
are
the
extensions
to
the
iss.
First,
is
that
we
defined
a
new
routine
definition
subtle.
It
is
used
to
advertise
the
associated
topology
and
other
attributes
of
the
vtn,
and
it
can
be
used
under
the
iss
launcher
capability.
To
do
you
see
the
format
is
shown
here.
Basically,
it
contains
the
waiting
id
which
is
a
network-wide
and
an
empty
id
to
identify
the
topology
associated
with
vtn
and
algorithm
id
to
identify
the
algorithm
associated,
which
can
be
a
normal
algorithm
or
a
flux
algorithm.
Q
Q
Then
flash
argo
can
be
used
to
specify
the
metric
type
and
the
topology
constraints
which
are
applied
on
the
specific
topology.
I
know
that
multiple
vitamins
can
be
associated
with
the
same
topology
algorithm
table
for
the
segment
routine.
The
extensions
in
igp
protocols
can
also
provide
the
distribution
of
their
topology
algorithm,
typos,
srcs
and
srv6
locators.
Q
Q
Q
Here
we
need
to
introduce
a
new
sub
tlv
to
define
to
advertise
the
set
of
link
resource
and
the
other
t
attributes
for
one
or
a
group
of
atms.
Here.
The
waiting
id
sub
sub
tree
is
used
to
specify
the
list
of
18
ids
and
other
sub
sub
tlvs
can
include
the
t
attributes
of
trvs
like
the
vtm
bandwidth
of
tlv
other
t
attributes
which
are
associated
with
a
set
of
vtns.
Q
B
Q
This
is,
I
think,
the
last
almost
the
last
one
yeah.
It's
obvious
technology
is
to
use
the
dedicated
waiting
id
instead,
so
we
can
save
this
overhead
of
the
controller
distribution.
Okay,
here's
the
next
step.
We
will
work
on
the
terminology
alignment
and
we
would
like
to
hear
comments
feedbacks
from
the
looking
group.
Then
we
consider
adoption
of
this
document.
Thank.
B
You
yeah.
The
reason
I
was
I
was
trying
to
cut
you
short
a
little
bit
was
because
I
wanted
to
give
a
little
bit
of
time
to
discuss
this
I'll.
I
guess
I'll
throw
my
comments
out
since
I
get
to,
and
that
is
that
right
now,
the
we're
looking
at
a
standard
track
modification
to
the
protocol
based
on
informational.
They
have.
You
are
basing
part
of
this
on
adopted
drafts
and
teas,
but
they're
adopted
as
informational.
B
Q
B
H
H
There
are
at
least
two
drafts
that
we
presented
one
of
them
back
in
ief
110.,
so
I
agree
with
chris.
We
need
to
still
you
know
what
you're
proposing
is
it's
early
for
adoption
at
the
moment?
Maybe
we
should
collaborate
and
complete
the
alignment.
As
you
mentioned,
he
still
referenced
vtn
when
he
has
already
converged
on
the
term
nrp,
so
that
that's
what
I
wanted
to
draw
your
attention
to
thanks.
S
This
this
pawn
earlier,
I
was
on
mute
earlier
speaking
as
such
as
the
t
is
working
with
chair
you're
right.
We
have
had
some
discussion
with
regards
to
vtn
versus
nrp
in
the
tease
working
group.
The
guidance
from
the
ts
chairs
at
this
point
is
to
use
the
term
nrp
in
documents
that
discuss
generic
usage
of
resource
partitions
and
refer
to
vtn
in
only
in
documents
that
are
specific
to
enhanced
vpn.
S
So
if
there
are
any
protocol
fields
or
data
model
lease
that
you
need
to
refer
to
an
identifier
for
resource
partition,
the
expectation
is
that
you
would
use
nrpid
in
those
scenarios,
so
we
would
have
to.
We
may
end
up
looking
at
each
document
in
the
space
across
working
groups
and
make
a
call,
but
that's
the
guidance
for
now.
Then
this
document
seems
to
be
a
good
candidate
where
nrp
should
be
used.
B
T
T
We
have
presented
this
draft
in
spring
working
group
many
times
and
we
receive
lots
of
value
comments
and
suggestions
from
bruno
ac
peter.
Unless,
just
before
the
working
group
adoption
for
this
draft,
we
will
suggest
to
move
the
igp
extension
to
a
new
draft.
So
that's
the
new
draft
I'm
going
to
present
focusing
on
igp
extensions.
T
T
A
binding
segment
consists
of
a
binding
sheet
and
a
list
of
segments
a
node
may
have
multiple
binding
segments.
Data
node
will
advertise
its
binding
segments
to
its
labels
for
advertising
proxy
forwarding
capability
and
note
p.
If
he
has
the
capability
for
peace
labels,
he
will
advertise
the
capability
in
the
domain.
T
There
are
two
options
for
a
node
p
to
advertise
its
capabilities.
One
option
is
that
p.
In
order
to
provide
protection,
no
the
p
may
use
mirror
id
for
its
label.
N
node
p.
Will
advertise
mirror
id
for
node
n
for
protection,
so
in
this
case
we
can
just
use
mirror
id
as
an
indication
of
the
capability.
T
T
B
T
B
Right
right
so
I
mean
I
think
this
is
the
same
comment
I
gave
to
the
last
presenter.
You
know
these
obviously
come
after
the
base
document
would
be
adopted.
I
mean
you're,
not
even
asking
for
adoption
here,
so
I
just
thought
I
would
put
that
out
there.
You
know
we'll
probably
follow
along
behind
the
base
document.
B
U
U
U
No,
no,
no!
No!
Well.
Actually,
there
are
two
two
subjects,
so
one
is
different.
We're
getting
that
one.
One
of
the
comment
is
that
it
is
functionally
equivalent
to
the
I
don't
remember
the
name
in
the
isis
binding
seat.
We
have
some
kind
of
anycast,
which
is
mirror
seeder.
We
have
mirror
seed
in
existing
in
isis,
sr
extension
and
it
seemed
proxy
forwarding
seems
functionally
equivalent.
So
the
question
was:
why
do
we
need
a
new
igp
extension
instead
of
reusing
the
mirror
seed?
B
U
I
T
T
T
D
Yeah
ac
linden,
cisco
systems,
speaking
as
working
group,
remember,
I
I
think
the
document
here
you
know
you
know,
even
even
irrespective
of
the
issue
that
bruno
brought
up,
it
could
be
a
lot
clearer
as
to
who
advertises
what
you
know
the
failed
mode
and
when
they
advertise
it
in
relation
to
the
failure,
the
duration
and
everything.
I
really
I
even
though
I'd
seen
this
before
I
really
had
to
go
to
the
spring
document,
then
I
had
to
actually
the
spring
document
didn't
help
me.
Until
I
looked
at
the
example.
D
You
know
you
can
kind
of
guess
you
can
kind
of
guess
how
it
would
work,
but
it
should
specify
exactly
when
the
capabilities
are
advertised
and
for
how
long
and
then
you
should
advertise-
I
mean,
because
there
was
a
there-
was
a
implying
that
it
was
only
for
a
certain
period
of
time
or
something
it
wasn't
all,
and
I
thought
wow
I
think,
you'd
tell
I
thought
you'd
tell
the
no.
You
were
protecting
you'd
tell
it
as
soon
as
the
adjacency
came
up,
but
anyway,
I
think
that
needs
to
be
added
to
the
draft.
B
V
V
In
fact,
there
was
some
some
disagreement,
also
on
our
on
the
way
of
doing
it,
because
the
draft,
at
least
as
a
way
to
other
when
the
adoption
call
was
done
in
spring,
was
proposing
to
to
force
to,
for
instance,
advertise
this
capability
just
for
a
couple
of
neighbors,
but
in
this
case
this
is
creating
some
potentially
some
an
your
path
or
issues,
and
so
on
so
so
there
was
also
some
disagreement
on
the
way
of
of
doing
it.
So
so
the
fact
is
really.
V
T
Yeah,
I
think
the
capability
is
very
clear:
it's
a
normal
practice
right.
We
we
have
a
capability
in
some
routes
and
then
routers
and
then
some
nodes
that
don't
have
that
capability
and
then
we
need
to
have
some
kind
of
incremental
deployment
and
also
we
have
backward
compatibility.
That's
normal
practice
to
improve
the
network,
stability
right
and
also
I
reply
that
one
in
the
spring
working
group.
B
T
S
B
M
Yeah
this
is
the
motivations
architecture,
defines
the
close
goals
of
determining
rooting,
bonded
legit,
bonded
loss
ratio
and
bonded
out
of
audit
denuclearing.
It
uses
resource
reservation
explicit,
routine
and
service
protection.
To
achieve
these
goals,
a
deterministic
path
is
typically,
but
another
doesn't
mean
a
traffic
engineer.
Pass
with
explanation.
Routine,
calculated
by
a
controller
full
cycle
provides
an
alternate
way
to
compute
the
consumption
based
parts.
M
Okay,
this
is
for
yeah.
The
latency
is
a
repeated.
A
first
arc
already
supports
the
mean
delay.
Magic
type
data
considers
link
delay,
but
another
node
killing,
including
cool
delays,
delay
equals
to
another
delay,
plus
transmission
delay
to
obtain
a
deterministic
path.
The
node
delay
must
be
considered.
M
M
M
Yeah,
how
so
how
to
provide
full
circle?
Deterministic,
routine.
Three
aspects
are
considered
under
the
guidance
of
internet
architecture
for
the
resource
resolution
aspect,
deterministic
link
is
introduced
which
has
the
deterministic
node
delay
attributes
for
the
explicit
routing
aspect
we
introduced
flex
argo
pass
calculated
with
deterministic
dilemmas,
type
for
the
serviceable
technician
aspect.
M
M
Okay,
this
is
about
deterministic
link
attributes
advertised,
including
link
transmission
delay.
That
means
the
average
machine
link
transmission,
delay,
value,
infinite,
forwarding
delay.
That
means
the
latency
of
our
packet
of
volume
resolution
and
the
incoming
port
all
generated
from
the
control
plane
to
king
and
the
outgoing
board.
M
M
M
M
The
falling
figure
illustrates
an
example
of
deterministic
delay
routine
in
the
physical
network.
Determining
determining
significant
linkers
are
generated
and
the
attributes
provided
by
decent
linkers
are
interned.
Accordingly,
five
microseconds,
you
can
notice
gradient
delay
from
one
to
60,
microseconds
and
link
transmission
delay.
As
indicated
in
the
figure,
then
full
circle
188
is
created
to
include
these
deterministic
links
and
the
scheduling
delay
10
microseconds.
M
M
B
A
Gonna
walk
with
you.
Now
the
granularity
of
measurement
doesn't
match.
The
advertisement
is
per
topology
per
adjacency.
The
delay
is
per
traffic
class.
You
cannot
advertise
one
traffic
class
in
especially
on
vaq
system.
There's
huge
difference
between
different
traffic
classes
in
the
way
they
defined.
So
I'm
not
sure
how
you
can
do
it.
W
Hi,
can
you
hear
me
well,
yes,
joseon
from
huawei
one
comment
for
this
document:
a
stable
pass
is
very
important
for
deterministic
latency,
which
is
called
explicit,
passing
that
networking
group.
So
I
think
we
should
be
very
careful
if
we
choose
a
distributed
path,
computation
mechanisms
for
that
net,
because
if
the
paths
change
the
the
latency
and
the
jitter
will
also
change
accordingly,
so
maybe
we
should
have
more
discussion
to
to
to
decide
whether
we
should
go
this
way,
especially
using
flex
ego.
Thank
you.
D
Speaking
as
working
with
chair,
I
think
we
really
should
get
yeah
input
before
we
do
anything
on
this
from
the
the
that
net
working
group
as
well.
The
one
comment
I
think
you
one
thing
you
need
is
a
discussion
of
the.
How
often
you
change
these
things
and
how
often
you
advertise
them,
because
I
must
admit,
I'm
not
I'm
not
an
expert,
but
it
looked
like
it.
Looked
like
these.
D
B
X
Okay,
hi
everyone.
This
is
monk
sorton
from
new
h3c
technologies.
This
presentation
is
on
the
advertisement
of
dedicated
metrics
for
flexible
algorithm
in
igp.
This
is
an
0-0
version
in
the
visual
draft.
By
the
way,
the
words
in
the
title,
dedication
metric
for
flexible
algorithm
may
bring
confusions,
so
we
will
use
algorithm,
specific
link
metric
in
the
slides
and
the
future
version
of
the
draft.
X
Ok,
this
is
the
background
of
this
draft
flex.
Algorithm
allows
igp
to
compute
constraint
based
passes.
Links
can
be
pruned
by
using
eag
rules
to
create
different
topologies
for
different
algorithms.
However,
if
a
link
is
included
by
multiple
algorithms
of
the
same
metric
type,
these
algorithms
can
only
share
the
same
metric
value.
X
E
X
X
Network
resources
are
reserved
along
the
primary
passes
for
slices,
for
example,
on
link
a
b
and
bd
bandwidth
of
100
mbps
is
reserved
for
slice
one
and
on
link
ac
and
cd.
Bandwidth
is
reserved
for
slice
2.
on
the
backup
path.
No
dedicated
resources
are
reserved
and
the
bandwidth
will
be
shared
with
best
effort,
traffic
flex,
algorithm
128
is
used
to
steal
the
traffic
of
slice
1
and
the
flex
algorithm
129
is
used
for
size,
2.,
locators
and
seeds
belonging
to
these
flex.
X
X
X
X
X
K
K
X
X
This
is
the
extension
of
algorithm
specific
link
metrics
of
trv
for
easies.
It
is
carried
in
the
application
specific
link
attribute
for
flex
algorithm
if
the
metric
type
and
algorithm
fields
are
consistent
with
fad,
setflex
algorithm
should
use
a
metric
in
the
new
defined
trv
during
pass
calculation.
X
X
X
B
G
G
If
you
take
a
look
at
the
flex,
algo
definition
there's
already
a
metric
type
that
it
defines
and
it
allows
user
to
find
metric
types
and
then
you
can
attach
a
metric
type
to
a
metric
on
a
link,
and
that
is
all
you
needed.
So
we
already
have
this
mechanism
it's
redundant
with
the
other
generic
metric
proposal.
X
Okay,
thank
you,
but
I
think
the
metric
type
based
metric
is
different
from
the
algorithm
based
metric.
So
our
problem
here
is
to
use
different
link
metric
value
for
same
metric
type,
but
different
flex.
Algo
using
multiple
user
defined
metric
type
may
be
a
solution
that
can
avoid
our
problem,
but
I'm
afraid
that
it
may
bring
complexity
in
the
same
time
as
we
need
to
define
many
private
metric
types
for
every
flex,
algorithm
and
advertise
them
for
every
link.
X
B
E
B
B
Yeah,
okay,
nice
comment.
Thank
you.
We
have
to
move
on
now.
Sorry,
everyone.
So
next
up
is
shrada.
The
application
specific
link
attribute
this
one
may
generate
some
commentary.
That's
why
I've
been
kind
of
pushing
people
go
ahead.
If
you
can
pull
the
presentation
in,
we
have
15
minutes
allocated
here.
So
if
you
could
get
it
done
quicker,
we'll
have
more
time
for
discussion.
Y
Y
So
asla
allows
for
attribute
advertisement
where
link
attributes
are
applicable
to
one
application
or
some
applications,
and
there
is
a
limited
provision
to
advertise
attributes
that
are
applicable
to
any
application
that
is
currently
defined
or
going
to
be
defined
in
future.
It's
limited
because
it
says
it
does
not
allow
application
to
use
attributes
from
zero
length
bitmask
when
any
other
attribute
is
advertised
with
an
application
bit
set.
Y
So
they
have
no
application,
specific
values,
so
all
deployed
applications
are
all
using
same
values
for
all
these
applications.
So
a
new
application
is
defined,
let's
say
as
part
of
network
evolution.
A
new
application
y
is
to
be
deployed
and
it
uses
a
specific
value
for
one
of
the
attributes.
So
I
had
taken
the
subtle
v10
and
less
pointed
out
that
that's
not
the
right
example.
So,
let's,
let's
just
take
one
of
the
attributes,
maybe
admin
groups
that
it.
E
Y
Application
that
has
a
application,
specific
value
for
certain
attribute.
We
would
just
set
advertise
a
new
asylum
tlv
with
any
bit
with
the
y
bit
set,
and
then
we
would
advertise
the
attribute
that
requires
specific
value.
The
previous
advertisement
would
remain
same,
no
change
the
preview
to
the
previous,
as
less
appeared.
Y
Y
So
one
option
is
the
moment
you
advertise,
because
you
can
advertise
with
sabm
0
length,
which
means
all
any
application
can
use
it.
So,
to
start
with,
you
would
be
advertising
with
0
bit
mask
and
then
all
the
attributes
and
when
the
new
application
has
to
be
introduced,
you
would
advertise
another
s
up.
Tlv
set
the
y
bit
the,
which
is
the
new
application
and
then
add
the
subtle
that
has
application
specific
value.
You
would
all
you
would
also
have
to
repeat
all
other,
because
that
application
also
wants
to
use
all
other
attributes.
Y
Y
So,
and
also
what
what
we're
suggesting
is
that
it's,
the
it's
an
efficient
encoding
and
it's
very
intuitive
encoding
when
there
are
attributes
that
have
application,
specific
values
and
some
attributes
that
don't
have
applications
that
have
specific
application,
specific
values
and
other
attributes
that
do
not
have
application
specific
values.
And
it's
it's
intuitive
encoding,
as
well
as
very
straightforward
to
implement.
Y
Y
I
mean
any
bit,
ensures
that
if,
if
there
is
an
advertisement
with,
of
course,
if
you
want
to
deploy
this
asla
with
any
bit,
so
all
the
nodes
in
your
domain
have
to
understand
this
any
bit
so
an
existing
deployment
that
has
already
deployed
asla
with
existing
mechanism
that
I
mean
there
is
no
force.
I
mean
there
is
no
enforcement
to
change
to
any
application
right.
They
can
do
that
whenever
the
time
comes.
Y
That
is
when
a
new
application
comes
in,
where
it's
more
appropriate
to
use
any
they
can
migrate
during
that
time.
There's
no
there's
no
need
to
switch
to
any
app
immediately.
They
can
do
that
whenever
there
is
really
need
for
that,
but
those
deployments
which
are
going
to
deploy
s
line
future
and
they
have
these
specific
require.
I
mean
this:
they
they
believe
the
their
network
is
going
to
evolve
the
way
described
in
these
examples.
They
can
go
with
any
bit
if
we,
if
we,
if
we
allow
this
protocol
extension.
N
N
There
are
no
significant
advantages
when
you
look
at
the
spectrum
of
of
the
various
combinations
of
cases,
deployment
cases
and
there's
a
lot
of
cost
in
terms
of
implementation,
complexity
and
deployment,
complexity
that
comes
along
with
this
and
we're
really
not
getting
any
benefit
for
it.
So
my
opinion
is
that
there's
just
no
justification
to
move
forward
with
this.
Y
Okay,
so
less
I
I
I
think
you
mentioned
that
in
in
terms
of
encoding
efficiency,
there's
very
little
that
is
getting
saved,
but
this
example
was
just
an
example
right.
You
can
imagine
if
there
are
more
attributes
that
new
application
requires
application,
specific
values.
All
those
will
have
to
be
repeated
in
that
option
too,
that
that
I
discussed
so.
N
Well,
I've
I
mean
I
went
through
three
different
examples
with
with
varying
combinations,
and
you
know
the
example
you
provided
there's
some
savings
in
the
other
two
examples:
there's
either
no
savings
or
the
all
is
slightly
better.
So
I
I
really
think
the
quantification
of
this
efficiencies
is,
you
know,
even
if
you
get
a
little
bit,
it's
it's
very
small
and
it's
overwhelmed
by
the
complexity
that
you're
adding
to
implementations
into
deployments.
B
Y
So
chris,
this
is
so
the
comment
that
I
have
is
if,
if,
if,
if
we
are
going
to
make
as
a
going
ahead,
if
we
want
to
make
that
as
a
de
facto
standard
where
the
link
attributes
have
to
be
advertised,
it
has
to
be
flexible
and
we
have
to
let
it
evolve
and
we
have
to
think
of
future
where
new
applications
can
come
and
how
easy
it
is.
The
existing
extensions.
How
easy
it
is.
Y
B
Y
Z
Application
specific
link
attributes
in
general.
I
think
the
fact
that
we
have
this
kind
of
discussion
shows
that
the
concept
of
application,
specific
link
attributes
is
just
too
complex.
I
know
who
really
needs
it.
I
from
my
point
of
view
it's
overly
complex,
but
here
we
are.
I
hope
we
resolve
this
issue
or
this
discussion
as
soon
as
possible.
B
D
B
AA
H
B
AA
I
had
sent
an
email
to
the
mailing
list
about
this
and
there
were
some
replies.
Sorry,
I
didn't
get
the
replies,
but
I'm
going
to
attempt
and
answer
the
comments
from
there
today.
I
only
have
five
slides,
so
please,
you
know
hold
all
the
other
comments
until
I
finish
and
hopefully
address
your
your
slides
or
your
comments
next.
AA
We
have-
and
this
is
something
that
we
left
off
the
draft
because
we
wanted
it
to
be
not
specific
to
an
application
or
the
implementation,
the
deployment
that
we
have
but
more
general.
So
what
we
have
the
specific
application
that
we
have
is
we
have
a
mobile
network
and
this
mobile
network
is
going
to
from
time
to
time,
come
in
contact
with
what
we're
calling
a
a
monitor.
Node
over
a
point-to-point
radio
link,
so
it's
very
specific
to
a
point-to-point
implementation.
AA
What
we
want
is,
of
course,
to
be
able
to
interface
with
this
node.
We
want
to
authenticate
it.
We
want
this
node
to
be
non-transit,
as
has
been
pointed
out
on
the
list,
but
we
also
want
the
node
to
not
be
able
to
influence
our
network,
meaning
if
it
decides
to
send
stuff
to
us
right
to
become
not
just
listen
only
but
to
send
lsas
or
anything
else.
AA
This
will
also
not
only
achieve
stability
in
the
network,
because,
if
we're
just
flooding
a
bunch
of
lsas
which
may
or
may
not
be
just
the
local
lsas
for
that
monitor,
node,
this
node
could
inject
you
know
whatever
they
want,
and
we
don't
want
that
to
create
anything
inside
the
network.
The
same
thing
with
the
link,
if
the
link
flaps
or
anything
else,
it
could
cause
some
stability
in
there.
AA
So
what
the
draft
says
is
it
gives
two
options,
one
in
section:
three,
that
we
call
a
monitoring
interface,
so
basically
we're
defining
two
interface
configurable
parameters.
These
are
you
know
the
same
type
that
are
defined
in
2328
and
I
think
it's
appendix
c2
and
there
are
some
in
ospf
v3
as
well.
AA
So
what
these
do
is
they're,
relatively
simple.
The
names
are
very
straightforward:
do
not
advertise
link,
which
means
don't
advertise
the
link
where
you
configure
this
again
in
our
application.
It's
a
point-to-point
link,
but
it
could
also
work
in
a
multi-access
link
and
the
other
one
is
do
not
request
and
ignore
lsas.
AA
So
what
this
lets
it
do?
Let's
do
is
the
goals
that
I
mentioned
before
you
can
authenticate
the
node.
It
won't
be
transit
because
there's
no
information
going
out
from
them,
there's
no
direct
traffic
to
them
either.
There's
no
lsa
propagation,
we're
not
advertising
the
link,
and,
yes,
we
need
to
clarify
a
little
bit
more.
What
does
it
mean
to
not
be
eligible
for
the
rmpdr?
AA
AA
AA
So,
in
this
option
we're
saying
the
monitor,
node
would
advertise
a
bit
in
lls,
saying:
hey,
I'm
a
monitor,
and
what
that
would
do
is
it
would
cause
the
other
routers
on
the
link,
the
ones
that
are.
You
know
real
routers,
to
do
pretty
much
the
same
thing
that
the
local
configuration
would
do
ignore
any
received.
Lsas,
don't
request
any
other
saves
during
the
database
exchange
and
consider
that
node
ineligible
for
dr
or
bdr.
AA
So
again.
By
doing
this,
we
achieve
the
same
goals:
authentication,
non-transcendental,
traffic,
no,
let's
say
propagation,
no,
dr
eligibility.
Yes,
we
need
to
specify
that
more
and
no
link
advertisement.
They
put
a
little
asterisk
there,
because
that
would
work
in
a
point-to-point
link
where
one
of
the
routers
emphasizes
that
it's
a
monitor.
So
I
me,
as
the
other
router,
won't
advertise
link
in
a
multi-access
interface.
AA
Of
course
we
would
advertise
the
link
because
there
are
other
routers
in
there,
so
that's
pretty
much
it
for
the
draft
in
the
list
there
was
a
mention
of
other
possible
solutions
next
slide,
and
so
I
did
a
quick
table
of
these
two
solutions
at
the
very
beginning
and
some
of
the
others
towards
the
end.
Ac
mentioned
this
isp
that
we
have
all
worked
with,
and
I
won't
even
say
where
they
are,
which
had
proposed
at
some
point
maintaining
stuff
in
exchange.
AA
For
a
long
time
sure
we
could
do
that
that
doesn't
achieve
everything
that
we
want,
because
we
could
still
get
direct
traffic.
We
could
still,
we
are
still
probably
in
the
lsa.
If
we
don't
get
full,
we
don't
necessarily
propagate
the
the
link.
So
that's
a
good
thing,
both
the
orbit
and
the
h-bit
for
s3
and
s3v2
pretty
much
do
the
same
thing.
They
don't
allow
transit,
which
is
a
good
thing,
but
they
still
allow
their
traffic.
They
still
allow
propagation
of
the
lsas.
They
still
allow.
AA
AA
We
do
get
direct
traffic,
we
yeah,
we
can
get
direct
traffic
and,
of
course
it
doesn't
prevent
we're.
Gonna
avoid
I'm
sorry.
We
can
avoid
direct
traffic,
because
if
we
hide
the
links,
then
we
can't
you
know
get
to
that
link,
but
it
doesn't
prevent
transit
right
because
we're
hiding
the
transit
link.
E
AA
Needs
that
we
have
again
the
big
one
here
is
protection,
not
just
non-transit
and
not
directing
traffic,
but
also
trying
to
protect
the
network
from
a
possible
misbehaving,
monitor
node,
I'm
going
to
note
that,
except
for
the
first,
the
monitoring
interface
column,
where
the
receiving
router
the
router
say
in
the
network
has
control
over
what
happens.
Everything
else
depends
on
the
monitoring
node,
to
say
something
to
indicate
with
a
bit
that
it
wants
to
do
something
and,
of
course,
there's
always
the
risk
that
that
bit
won't
be
set.
D
Okay,
go
ahead:
ac,
okay,
ac
lindem
speaking
as
a
working
group,
member
yeah,
I
I
I
wasn't
suggesting
that
we
go
back
to
that.
I
was
saying
that
was
the
worst
way
to
do
it.
The
way
that
isp
did
it,
because
we
actually
had
to
change
code
to
because
we
had
all
this
code
to
get
rid
of
adjacencies
that
weren't
making
progress
and
bring
it
up
and
down.
D
I
read
this
again.
I
was
pretty
said
you
could
do
everything
you
wanted
without
this,
but
after
I
read
it
again,
I
see
that
I
think
the
one
thing
you
can't
do
without
some
extension
is
that
is
get
rid
of
the
adjacency
and
any
flapping
of
it
on
the
side
of
the
non-monitoring
mode.
So
I
don't
mind
that,
but
I
just
suggest
that
for
all
these
things
you
put
the
burn
it
on
the
new
guy,
the
monitoring
mode.
D
Then
you
get
the
best
backward
compatibility,
even
if
they
don't
support
it
like,
for
instance,
you
don't
have
to
advertise
a
router
lsa,
you
don't
need
to.
You
know
we
already
have
a
way
to
keep
from
becoming
dr
you,
dr
priority
of
zero
that'll.
Do
it
you
don't
really
need
to
specify
that
the
other
nodes
do
anything
special,
so
you
could
really
do
this
just
put
the
burden
on
the
monitoring
node
and
really
have
these
options
just
for
what
the
node
you're
connecting
to
puts
in
his
lsa.
D
C
R
AA
D
B
AA
Yeah,
so
really
quick.
The
only
thing
the
other
slide
said
is
that
yeah
we
need
to
update
with
some
of
the
considerations
and
you'll
get
more
feedback,
and
that's
after
we
do
that.
We'll
probably
want
to
have
this
considered
for
adoption,
but
you
know
just
like
everyone
else
says
at
the
last
slide.
Thank
you
all.
B
P
P
The
purpose
of
this
is
that
there
is
this
use
case
where,
when
you
need
to
send
traffic
to
any
of
a
set
of
devices
that
own
that
anycast
address,
typically,
you
just
send
use
the
anycast
address
as
your
destination
address
and
then
the
closest
one
will
get
get
the
package
and
if
you
happen
to
have
ecmp
to
some
of
those,
then
the
you
get
a
little
balancing
and
some.
But
if
you
don't
have
ecmp
oil
is
always
the
closest
one
that
gets
the
traffic.
P
P
So
this
slides
actually
describe
the
specific
use
cases
use
case
that
that
I
just
talked
about,
but
I'm
going
to
skip
the
skip
it
next
one
please.
So
this
is
n
flag
come
to
the
picture.
That
flag
is
set
when
the
prefix
identifies
an
advertising
router.
So
one
may
think
that
what
if
you
said
and
flag
on
on
the
those
affiliate
addresses,
then-
but
that's
not
enough,
because
it
only
the
m
flag.
Only
says
that
this
list
address
belongs
to
this
router.
It
does
not
carry
other
semantics.
P
So
there
are
four
reasons
I
listed
here
just
because
a
node
advertised
two
local
addresses
a
and
b.
It
does
not
mean
that
they
are
always
exchangeable
as
reason
number
one
and
number
two
is
that
affiliation
may
have
to
be
one
way.
Traffic
that's
destined
to
any
cash
address,
may
use
an
affiliated
address,
but
the
other
way
may
not
be
desired
or
should
not
be
allowed
at
all.
P
That
way
then
number
three,
a
node
may
have
a
different
anycast
addresses
each
with
a
different
set
of
affiliate
addresses
and
finding
number
four,
even
when
other
those
addresses
are
reachable,
you
may
want
to
withdraw
the
affiliation
advertisement
because
you
don't
want
the
the
anycast
address
to
be
replaced
with
a
affiliate
affiliated
address
next
slide.
Please.
P
P
P
J
J
We
use
the
flex
algorithm
to
identify
the
topology,
where
this
information
is
relevant
applicable
because
this
finding
of
any
cache
to
the
unicast
address,
doesn't
have
to
be
touched
intercepted
by
every
every
node
in
the
in
the
domain.
What
do
you
think
about
that
approach?
Maybe
we
can
talk
offline
on
that.
P
I
I
guess
we'll
have
to
talk
about
it
offline,
because
here
in
this
room,
it's
very
difficult
for
me
to
to
hear
clearly
the
audio
yeah.
It's
it's
not
that
the
volume
is
not
enough,
but
somehow
it's
it's
not
very
clear,
but
I
think
we
can
follow
up
offline
and
as
long
as
everyone
else
can
hear
it,
we
should
still.
D
K
D
D
P
So
because
it's
igp-
and
you
have
once
you
advertise
that
information
it's
everywhere
anyway,
so
in
theory
a
transit
rather
could
do,
could
change
that
if
an
operator
or
allows
that.
Indeed,
if
you
really
do
that,
then
once
you
change
it
to
a
affiliated
address,
you
should
not
change
it
back.
That's
one
of
the
reasons
I
mentioned
earlier.
If
you
change
back
and
forth,
you
may
get
into
routing
loops.
N
P
N
B
Jeffrey
will
we're
not
jeffrey
anyway
yeah,
okay,
so
that's
it.
We
ran
out
of
time
we're
over
time,
but
we're
the
last
people.
I
guess
that's,
okay,
to
run
a
couple
minutes
over
thanks
everybody
for
coming
and
we'll
maybe
next
time
we'll
keep
10
minutes
at
the
end.
Instead
of
five
minutes,
since
we've
been
growing
out
again
and
hopefully
see
everybody
in
philadelphia,
philly
or
pennsylvania,
yeah.