►
From YouTube: IETF108-LSR-20200730-1410
Description
LSR meeting session at IETF108
2020/07/30 1410
https://datatracker.ietf.org/meeting/108/proceedings/
A
Time
thinks
it's
10
10
now
so,
let's
get
started.
This
is
the
well.
You
know
what
this
is.
This
is
lsr
and
we
have
100
minutes
the
virtual
108
meeting
the
agenda.
We
moved
the
agenda
around
a
little,
so
this
is
the
agenda
bashing
section.
If
anybody
has
a
problem,
nobody's
time
was
changed.
I
don't
think
ron
chen.
I
moved
your
presentations
to
the
end.
A
The
primary
reason
is,
I
think,
there'll,
be
some
discussion
on
some
of
the
other,
the
other
presentations,
and
I
don't
want
to
miss
that
discussion
and
those
final
two
presentations.
There
are
for
infrastructure
documents
on
technology.
That's
you
know
being
newly
presented
in
teas
right.
So
while
it's
important
that
lsr,
you
know,
reviews
the
you,
the
suggested
use
of
the
igps,
it's
a
little
early
still
in
the
process
to
be
talking
about
extensions
until
the
technology
is
at
least
you
know
moves
a
little
bit
in
the
the
base
working
group.
A
B
B
B
We
have
two
more
drafts
on
on
the
rfc
crew
queue.
These
were
contentious
at
first.
There
were
some
long
time
drafts
and
I
think,
with
all
these
with
the
first
two,
the
application
specific
link
attributes
drafts
for
ospf
and
isis.
I
think
with
those
and
there's
there's
going
to
be
another
one
as
well.
It's
it's
on
our
cq
we've
completed
all
the
working
group
documents
that
were
pre-merged
of
the
ospf
and
isis
working
groups.
B
B
B
And
these
two,
these
two
elc
drafts
isis
and
ospf
for
advertising
in
the
in
the
igps.
We
we
had
some
discussions
on
this.
It
simplified
it.
We
incorporated
some
some
bgpls
and
new
offers,
but
these
are
both
on
our
are
on
rfc
they're,
not
they're,
on
the
cube,
but
they
have
missed
references.
So
these
are
the
last
two
that
weren't
lsr
drafts
working
group
drafts.
I
think
that
are
still
hanging
out,
so
we're
all
done
with
those.
That's
that's
that's
good!
B
A
Yeah,
no,
I
I
I
would
just
say
that
you
know
we're
just
waiting
for
it
to
clear
which
it
has
cleared
the
appeal.
I
think
it's
still
working
its
way
through.
I
don't
know
you
know
through
the
regular
process.
Now
right,
I
don't
know
if
it's
been
the
network.
The
network
programming,
I'm
talking
about
by
the
way
whether
that
has
cleared
like
ietf
last
call
but
peter's
in
the
queue.
So
I'm
gonna,
I'm
gonna,
accept
your
audio
here.
A
E
Yeah,
I
can
speak
to
that
sorry
took
me
some
time
to
figure
out
the
right
buttons
to
push.
Yes,
it's
in
my
hands,
I'm
about
to
press
the
button
to
go
to
ietf
last
call,
and
that
should
happen
by
the
end
of
the
week.
I
was
expecting
to
do
that
last
week,
but
it
was
off
in
fact
yeah.
It
could
be
a
contentious
working.
Sorry
ietf
last
call,
but
I
don't
think
it's
a
good
thing
to
bet
on
that
either
way.
E
E
A
Yeah
I
mean
my
concern
primarily.
Is
that
most
of
the
objections
were
I
mean
a
lot
of
the
objections
seem
to
be
around
like
penultimate
pop
right,
and
you
know
that
directly
affects
the
tlv
space
right.
I
mean
those
things,
so
I
mean
we're.
We
are
in
the
last
call,
it's
not
like.
I
don't
think
we're
gonna
be
holding
anything
up
right
like
I
I
think
you
know
yeah.
We
could
I
mean
we
could
submit
this.
You
know
to
the
so
yeah
iest.
A
E
E
E
C
E
A
I
think
we
should
count
on
progressing
this
between
now
and
the
next
ietf.
I
don't
you
know
I
I
don't.
I
don't
see
a
reason
to
stop
sharing
my
screen.
I
don't
see
a
reason
to
hold
it
up
much
longer,
but
you
know
look.
Maybe
let's
you
do
the
itf
last
call
we'll
see
if
anything,
crazy,
pops
out
right
away.
E
E
B
We
need
a
chance.
Okay,
so
we're
gonna
have
prefix
original
covered
today,
a
couple
more
yang
models
that
I
think
were
they
only
cover.
I
think
they're
ready
for
last
call.
I'm
I'm
on
those
we'll
we'll
take
a
look
at
those,
and
we
have
this
yang
extension
for
reverse
metric.
I
think
that's
ready
and
then
we
have
yeah.
I
think
that's
ready
for
last
call
too.
I
looked
at
that.
That's
pretty
close
to
ready
and
next
slide.
B
B
Dropped
hierarchy
because
it's
one
of
those
things
you'd,
really
you
don't
want
to
standardize
with
if
it's,
if
nobody's
going
to
implement
it
because
it
is
sort
of.
Although
it's
not
that
long,
a
draft,
it
is
kind
of
radical
the
offers
can
take
that
offline.
If
you
want
to
bring
it
forward,
we
can
discuss,
but
since
nobody's
going
to
implement
it,
I
think
we
can
put
that
on
hold
next
slide.
B
And
then
we
got
these
new
working
group
drafts.
There's
a
lot
of
discussion
about
the
first
two
and
this
this
first
then
we
then
we
also
had
the
flooding
topology
minimum
degree
algorithm,
which
will
be
covered
today.
If
the
ttt
discussion
allows
time
for
it
and
that's
it,
I
think
I
might
have
one
more
screen
yeah.
I
don't
need
to
cover
these.
A
B
A
B
D
D
D
D
It
talks
about
how
someone
decides
to
have
a
single
place
or
a
single
area
from
which
it
wants
to
source
it,
how
it
can
be
leaked
between
the
areas
in
isis
and
ospf?
Again,
there
is
nothing
new
everything
has
been
specified
in
in
the
in
the
other
sections.
This
is
more
like
a
place
where
we
sum
it
up
and
give
people
some
guidelines
how
they
can
decide
and
use
this
information.
D
D
You
want
to
make
sure
that
you
know
there's
no
srlg,
which
would
affect
both
of
the
stream
at
the
same
time
both
of
the
streams
at
the
same
time,
so
you
basically
avoid
the
certain
srlg's
in
one
plugs,
algo
and
and
the
other
I
started
using
the
other
flags
I'll.
Go
that
way.
You
can
make
sure
that
the
single
failure
would
not
happen
would
not
affect
you
know
multiple
flex,
algos
again.
D
This
is
this
can
be
done
with
the
affinities,
but
people
already
had
strategy
in
place
and
there
has
been
an
interest
in
from
the
field.
Let's
use
them,
we
don't
want
to
provision
affinities.
You
know
for
the
same
thing,
so
that's
what
the
the
short
section
talks
about
next
slide.
Please-
and
there
is
a
there-
is
some
section
about
max
metric
consideration.
D
D
So
basically,
what
we
say
is
that
if
you
want
to
make
the
link
unreachable
for
all
the
flex
algos
that
are
using
link,
delay
or
te
metric,
you
basically
omit
that
metric
from
the
link,
and
that
has
been
already
specified
that,
if
the
link
which
is
which
flex
algo
is
using,
is
not
being
advertised
for
the
link,
the
link
must
not
be
used.
So
we
just
clarify
that
if
people
want
to
do
the
max
metric
type
of
thing
for
these
metrics,
this
is
how
they
do
it
next
slide.
Please.
D
And
also
we
clarified
how
we
can
make
the
link
the
type
of
last
resort,
basically
by
setting
the
either
the
delay
or
the
te
metric
that
are
advertised
in
the
asla
for
the
flex
algo
as
a
max
value
and
depending
on
the
protocol,
especially
for
a
te.
We
have
different
different
values
that
are
supporting
the
protocols
again,
nothing
new.
We
set
the
metric
to
max
or
we
don't
include
the
metric
to
have
the
you
know
unreachable
type
of
behavior.
D
Okay,
next
slide,
please!
So
that's
all
the
changes
again,
nothing
new,
more
just
clarification
to
make
things
clear
and
easy
for
people
to
understand.
The
document
has
been
there
for
three
years.
We
have
it
in
the
working
group
for
like
more
than
two
years,
multiple
implementations
are
there.
There
has
been
interrupt
testing
done.
This
has
been
stable
for
quite
some
time.
Basically,
we
are
asking
for
the
working
group
last
call
at
this
point.
D
A
I
yeah,
I
think
that
this
is
reasonable.
We
don't
have
like
somebody
suggested
the
way
to
raise
hands.
You
know
because
instead
of
using
hum
would
be
to
have
people
get
in
the
queue,
but
not
actually
select
them
to
talk.
Does
anybody
have
an
objection
to
moving
this
into
working?
Your
last
call,
you
know
just
put
yourself
in
the
queue.
If
you
object,
I
guess
we
could
also
ask
you
what
your
objection
was
once
you
get
there.
A
A
B
I
I
recently
I
read
this
draft
this
week.
You
know
as
part
of
it.
I
have
some
editorial
comments,
I'll
send
them.
I
I
didn't
take
them
down.
I
just
read
the
draft
over
less
than
an
hour.
I
need
to
take
a
little
bit
more
during
the
working
group
last
call
period
and
capture
them
and
send
them
to
you.
F
G
G
G
G
G
G
As
a
sub
tlp
of
the
ospf
extended
prefix
tlb
of
the
ospf
extended
prefix,
opaque
lsas
for
ospf
v3.
This
was
the
extended
lsas.
You
know
using
the
extended
lsa
prefix
dlvs
of
different
types,
intra
inter
external
nssa.
You
know
it's
applicable
to
those,
so
it
was,
it
carries
the
ospf
router
id
now.
Ospf
router
id
is
not
necessarily
reachable
address
of
the
originating
router
in
case
of
osf
3
v3.
It
is
just
a
number.
G
G
The
difference
here
is
that
it
would
carry
a
unique
and
reachable
ip
address
of
the
ospf
v2
or
v3
router.
That
originated
the
prefix
advertisement,
so
for
a
v4
prefix
it
would
be
an
ipv4
address
for
a
v6
prefix.
It
would
be
an
ipv6
address,
and
normally
this
would
be
something
like
a
te
router
id
of
the
originating
node.
G
This
would
be
for
topology
learning
or
identification
use
cases
that
were
there
that
are
expressed
in
the
draft,
while
the
new
one,
the
prefix
originator,
provides
a
reachable
address
and
that
can
have
use
cases
for
traffic
engineering,
for
example.
It
lets
a
receiving
router
know,
for
example,
what
would
be
the
segment
routing
node
said
of
that
or
you
know,
determine
what
is
the
segment
routing
node
set
for
that
router
right
and,
as
we
mentioned
on
the
previous
slide,
you
know
it
allows
propagation
for
redistributed
external
prefixes
across
domains.
G
G
There
have
been
other
updates,
so
the
clarification
on
the
use
cases.
The
draft
had
references
to
the
elc
use
case,
but
that's
been
now
removed
because
the
working
group
decided
to
has
decided
to
work
or
advertise
the
elc
as
a
prefix
option.
Therefore,
there
is
no
more
need
for
identification
of
the
originating
router.
G
G
There
was
some
text
related
to
the
use
case
of
building
inter
area
and
inter
as
topology
based
on
prefix
advertisement.
There
has
been
some
discussion
on
the
list
and
some
feedback
on
it.
All
of
that,
some
remaining
text
has
been
moved
now
into
the
informative,
appendix
section
and
security
considerations
were
added
and
more
detailed
procedures
for
advertisement
have
been
explained
and
covered
in
this
version.
G
B
Yeah
ac,
linda
as
a
as
a
co-author
first
yeah.
We
made
a
lot
of
changes
to
this,
so
I
think
we'd
like
to
delay
a
little
while
get
some
people
all
the
people
to
read
the
new
version,
even
though
it
was
when
we
were
initially
just
advertising
the
one
tlv
and
it
was
and
it
looked
like
it
was
just
advertising
it
and
and
then
it
would
go
into
bgpls
advertising
it
through
the
domain
and
then
it
would
go
into
bgpls
as
well.
B
A
A
F
H
And
this
work
is
inspired
by
two
drafts
and
the
first
is
the
last
draft.
It
lists
a
few
things
that
we
can
do
to
reduce
flooding
and
it
proposes
a
flow
control
mechanism
and
that
uses
the
psnp
as
an
indicator
and
to
the
the
receiver
state.
So
the
basic
idea
is
and
we
can
reduce
the
lsp
transmission
speed
if
the
receiver
is
found
overwhelmed.
H
H
Here's
the
setup
we
have
four
routers,
they
are
connected
like
this
or
by
p2p
links.
So
in
the
experiment,
we
first
bring
down
the
adjacency
between
router,
3
and
router
4
and
the
bottom
two
routers,
and
we
injected
two
thousand
new
else
piece
to
router
four,
and
then
we
bring
up
the
adjacency
between
router,
three
and
router
four.
We
expect
that
route
four
will
flooded
the
2000
lsp
to
router
3..
H
H
H
So
in
this
experiment
we'll
focus
on
two
parameters.
Sorry,
previous
slides,
I
I
just
want
to
say
that
there
are
two
basic
parameters:
one
is
the
lsp
transmit
time
and
the
other
is
psnp
interval
and
the
lsptx
interval
determines
how
fast
we
send
their
speeds
and
the
psnp
interval
determines
how
fast
we
acknowledge
the
lsps
and
next
slides
please.
H
H
However,
if
you
look
at
the
third
column
and
the
number
of
re-transmissions,
we
are
seeing
a
lot
of
re-transmissions.
So
when
the
else
ptx
interval
is
set
to
one
millisecond,
the
number
of
root
transmission
is
huge.
More
than
half
of
the
lsps
are
retransmitted
and
the
flooding
duration
is
more
than
10
seconds.
H
So
will
tx
flow
control
help
here,
so
let's
propose
an
algorithm
and
to
reduce
the
lsp
txb.
If
the
number
of
acknowledged
lsps
is
big,
I
tried,
but
I
didn't
get
the
good
results.
First,
the
echo
zone
has
so
many
parameters
to
set.
I
don't
know
where
to
start
so
I
picked
some
set
of
parameters,
but
they
don't
work
well
in
terms
of
flooding
duration,
then
I
think
about
why.
H
H
So
next
thing
I
tried
accelerating
the
psps
on
the
receiver
side,
trying
to
reduce
the
number
of
re-transmissions
and
actually
bro.
Both
drafts
mention
the
need
of
prompt
psnps
and
here's
the
the
paragraph
in
last
draft
and
it
lists
the
trade-off
of
setting
the
psnp
intervals,
but
we
don't
know
how
much
delay
it
should
be
and
next
slide
piece
and
here's
what
stays
in
bruno's
draft,
so
it
mentions
improvements,
drop
that
proposes
actually
send
the
psnps
and
when
the
number
of
unacknowledged
lsps
exceed
a
certain
threshold.
This
is
the
second
approach
listed
here.
H
H
H
H
H
I
H
H
H
So
one
is
the
extreme
case
of
sending
a
psnp
for
every
received
lsp
and
the
15
is,
I
think,
the
maximum
number
of
lsp
entries
that
can
be
included
in
one
tlv
and
the
90
is
the
maximum
number
of
lsp
entries
can
be
included
in
one
psnp
from
the
result.
We
can
see
that
any
number
before
90
looks
okay,
the
the
performance
there's
not
much
performance
difference.
H
However,
again,
if
the
lp
update
is
infrequent,
then
we
it
might
take
up
a
long
time
for
the
number
of
an
acknowledged
lsps
to
reach
the
preset
threshold.
So
it's
gonna
take
a
long
time
to
send
the
psnp
back.
If
the
update
is
infrequent
so,
ideally
we'd
like
to
have
some
delays
to
send
psnps,
where
else
the
update
is
infrequent
but
very
fast,
pn
speeds
when
we
have
a
burst
of
else
piece
like
in
this
experiment
scenario.
H
So
when
the
lsp
updates
are
not
frequent,
then
the
threshold
will
not
be
reached,
so
the
time
based
approach
will
apply
and
for
a
burst
tlsp
like
in
this
experiment
scenario,
the
threshold
will
be
triggered
before
the
psp
interval
expires.
So
we
think
that
these
two
psps
approaches
can
coexist
nicely.
H
H
H
H
H
H
H
H
We
can
have
sloping
speeds
when
lsp
updates
are
infrequent
and
fast
pn
speeds
when
there's
a
burst,
so
our
experiment
also
suggests
that,
with
the
prompt
psn
piece
at
the
receiver,
the
sender
can
reduce
the
ta
lsp
tx
interval
more
aggressively
during
the
flooding,
that's
it
and
this
yeah.
I
just
talked
about
some
difficulty
in
implementing
the
tx
flow
control
algorithm
and
without
knowledge
of
the
receiver's
psp
pattern.
A
Thank
you.
This
is
fantastic,
it's
really
what
we
would
ask
for
during
the
interim.
I
think-
and
it's
very
useful
to
have
done
this
before
I
get
to
the
queue
I
I
guess
I
I
do
have
a
quick
question.
I
put
it
in
the
no
in
the
minutes,
but
is
the
is
the
simulation?
Is
the?
Is
there
a
simulation
code?
That's
available
to
to
you
know,
because
I
have
all
these
questions
about
like
did
you
try
this
value?
A
H
A
K
L
M
Okay,
yes
yeah
yeah.
Thanks
for
starter,
I
would
like
to
say
big
thanks
for
good
research.
It's
very
good!
My
question
is:
what
was
the
application?
I
mean
in
real
production.
Ss
typically
have
some
signature
for
security
reasons,
something
like
hmac,
mg5
or
whatever,
because
each
mod
by
itself
will
led
something
like
at
least
100
or
probably
200
milliseconds
to
every
lsp
check,
and
this
additional
latency
in
the
loop
will
greatly
influence
all
results.
Do
you
have
any
hmoc
for
authentication
purposes.
B
M
No,
no!
No!
It's
a
it's
a
it's!
Definitely
so
long
because
it's
by
definition,
if
you
would
like
to
have
a
really
good
security
protection
for
hmac,
you
have
to
have
higher
computation
to
be
to
be
really
sure
that
nobody
could
take
and
get
your
graphical
graphical
user
card
and
and
do
brute
force
it's
against
brute
force.
It's
on
purpose,
it's
very
long
on
purpose,
against
brute
force.
M
N
You
know
again
thanks
for
the
presentation.
My
comments
are
that
it's
nice
to
see
these
things.
The
results
are
somewhat
similar
to
what
we
tend
to
see
when
we're
doing
tcp
performance
tuning
for
things
like
bgp
tony
lee
did
confirm
in
the
chat
that
you've
tried
this
against
real
hardware
as
well.
My
comment
is
that
these
are
great,
optimistic
numbers,
but
given
the
way
we
don't
really
have
the
flow
control.
N
In
the
same
way,
we
would
have
something
like
tcp
that
the
aggressive
numbers
on
a
real
piece
of
hardware
and
less
than
optimistic
stereos
might
start
self-sabotaging
and
that's
mostly
because
of
how
routers
end
up
implementing
different
queuing
and
have
different
host
path.
Issues
to
get
to
you
know
the
central
cpu
for
doing
the
work
here,
so
my
request
for
future
work
is
start
putting
in
machinery
to
start
perturbing,
how
quickly
or
how,
how
often
things
might
get
dropped
in
bursts,
and
I
suspect
that
would
simulate
the
real
world
situation
a
little
bit
better.
H
O
O
O
Having
said
that,
I
think
the
suggestion
to
put
an
algorithm
for
the
psnp
with
the
fast
start
that
then
speeds
up
is
actually
excellent,
and
I
think
that
the
combination
of
this,
what
you
call
hybrid
psnp,
plus
the
transmit
ramping
up
and
going
back
on
retransmissions,
should
solve
probably
99
of
the
problem.
That's
my
gut
feeling.
So
that's
my
input
thanks!
Thank
you.
P
P
H
P
Okay,
so
the
the
one
comment
that
I'd
like
to
make-
and
again
I
emphasize
this-
is
great
work.
I
think
the
the
hybrid
psnp
approach
is
is
a
great
addition
to
the
discussion
of
the
solutions,
given
that
the
testing
does
not
involve
a
dynamic
adjustment
of
either
flavor,
you
know
in
either
draft
I
think
it's
kind
of
a
non-sequitur
to
draw
a
conclusion
from
this
data.
As
to
whether
you
know
the
rx
based
approach
or
the
tx
based
approach
might
be
the
best
one.
H
D
I
H
Q
I
just
have
one
question
of
feedback.
I
guess
you're
using
the
same
implementation
on
hardware
between
the
sender
and
the
receiver.
If
you
do
more
tests,
I
would
be
interested
in
having
the
test
between
a
stronger
sender
or
on
a
weaker
receiver,
because
this
is
the
case
where
you
really
need
flow
controller.
Q
H
A
O
Originally
originally
we
have
a
ttz
draft
which
contains
solution
for
abstract
zone
to
a
single
virtual
load,
so
it
will
include
iss,
extension
or
extension,
so
we
also
have
solutions
for
smoothly
transfer
a
zone
to
a
virtual
node
and
then
move
back.
So
this
solution
also
have
extensions
in
iss
and
the
ospf.
O
So
in
this
matrix
version,
so
we
remove
ospf
extensions
and
also
we
have
some
kind
of
editorial
changes
so
regarding
to
a
smooth
transfer
between
a
zoom
and
a
virtual
node.
So
I
just
want
to
talk
about
a
little
bit
more.
I
think
this
one
without
this
smooth
transfer
solution,
so
we
will
have
more
traffic
in
interruptions.
O
So
without
any
smooth
transfer
solution,
and
then
we
did
some
testings
and
then
we
have
traffic
interruptions
so
with
a
solution
for
transfer
from
a
jung
to
a
virtual
entity
which
is
a
ages
jones
ages,
food
connection,
so
we
almost
know
servicing
interruptions.
That
means
that
solution
for
smooth
transfer
between
tone
and
virtual
entity
or
virtual
node
will
reduce
the
surface
interruptions.
I
think
this
is
a.
We
verify
that
so
next
page.
O
So
I
just
want
to
brief
the
progress
of
this
draft
setting.
We
submit
a
third
version
which
include
the
solutions
for
abstracting
a
zone
to
a
single
version.
Node.
That
zone
is
a
piece
of
property
of
an
area
of
local
variants,
so
this
is,
I
think
this
is
the
first
drop
into
this
kind
of
abstraction
and
then
in
2018
we
have
a
second
draft
regarding
to
abstraction,
which
is
a
area
proxy.
O
O
O
O
O
O
O
O
The
solution
for
this
transfer
is
very
low
because
we
put
a
lot
of
effort
on
this
problem
and
also
we
have
done
some
experimental
implementations
about
transfer
and
then
we
know
it's
very
challenging,
but
we
have
a
confidence
that
we
can
have
some
kind
of
good
enough
solutions,
and
another
set
of
reasons
for
objection
is
that
they
don't
they
just
don't
want
this
kind
of
easy
additions.
So
that's
roughly
from
my
point
of
view
I
get
from
release.
O
O
So
at
this
stage
I
would
so
what
should
we
move
forward
merged
or
adopted
as
an
experimental,
because
already
have
two
draft
has
been
adopted
as
a
experimental,
I
think
it
was
circle
has
a
good
rental.
I
think
it
should
be
okay
and
we
do
do
some
experimental
implementation
and
then
maybe-
and
finally,
we
come
to
emerge
into
one
draft.
A
A
A
I
the
other
chair
comment
I
have
is
you
know
what
you
said
most
people
think
it's
good
right.
I
don't
know
that.
That's
the
case
I
mean.
I
know
there
was
a
lot
of
people
that
put
plus
ones
up
there,
but
you
know
are
the
how
many
different
operators
said.
It
was
a
good
idea
and
how
many
different
vendors
said
they
want
to
implement
it
right.
A
I'm
not
saying
that
that's
a
that
should
be
a
barrier
to
adoption,
but
I'm
not
sure
that
you
can
claim
most
and
on
the
flip
side
of
that,
what
I
saw
was
a
lot
of
experts
that
have
a
lot
of
industry
knowledge
right.
A
lot
of
people
who
have
actually
implemented
isis
deployed
isis
in
the
field
dealt
with
complex
code
having
bugs,
and
then
you
know
that
bringing
down
operators
networks.
A
So
I
mean
I'm
just
summarizing
what
I
read
on
the
list
right
and
so
as
from
the
chair
point
of
view,
if
we
move
forward
with
this
as
a
working
group
document
you're
going
to
have
a
lot
of
industrial
knowledge
and
and
wisdom,
that's
not
going
to
take
partake
in
this
right.
So
they're,
not
gonna!
I
mean
people
are
not.
If
they're,
not,
they
don't
think
it's
a
good
idea.
They're
not
gonna,
sit
around
and
review
and
give
you
feedback
right.
A
So
you're
gonna
progress
without
that
and
ultimately,
if
it
does
get
into
a
submission
to
the
iesg,
that's
going
to
have
to
go
in
the
into
the
report.
It's
going
to
have
to
be
that
we
had
a
very
rough
consensus
on
this
work
and
that
you
know
many
experts
in
the
group
did
not
agree
with
it
so
that
that's
that's
for
with
the
chair
hat
on.
I
just
want
you
to
be
aware
of
that.
I
B
So
it's
not
really
the
same,
and
then
it
became-
and
I
don't
know
if
I
I
don't
know
what
it
was-
why
it
was
changed
in
2013
to
get
rid
of
the
single
node
abstraction,
but
that
wasn't
the
initial
one
and
then
it
morphed
last
october
to
be
more
like
the
area
proxy.
In
terms
of
that
so
and
I'd
also
go
with.
I
Chris,
I
saw
that
it
had
a
lot
of.
There
were
a
lot
of
plus
ones.
I
wonder
how
many
people
had
actually
read
the
draft
that
did
the
plus
ones.
Probably
some
of
them
actually
did
read
it,
but
besides
that,
that's
speaking
as
a
chair
now
speaking
as
a
working
group
member,
the
other
two
drafts
that
were
adopted
are
just
much
I
mean
granted.
They
may
not
be
as
ambitious,
but.
B
They're
just
much
better
specified
and
I
too
share
the
concern
with
the
distributed
algorithm.
Maybe
you
have
something
a
lot
of
stuff
when
you
did
experiments
to
do
the
transition,
but
those
distributed
algorithms,
these
things
don't
all
happen
at
once,
without
handshaking
across
the
whole,
the
whole
routing
domain
of
the
zone,
so
I
don't
think
it's
best.
B
The
transition
is,
is
adequately
specified
to
really
be
as
seamless
as
is
claimed
in
the
draft
I
mean
you
can
try
and
sell
that
you
haven't
sold
it
to
me
and
that's
all
I
mean
we
can
take
for
this
offline
and
what
what
we
do
with
it.
But
I
don't
think
it's
I
don't
think
it's.
I
don't
think
it
reaches
the
quality
of
the
other
two
drafts,
even
though
it
has
higher
higher
higher
goals.
O
So
regarding
to
ac's
comments,
so
in
2013
in
the
draft,
the
draft
con
contains
two
solutions.
One
solution
is
to
abstract
a
zoom
to
a
single
node
through
select
jung,
dr,
which
is
equivalent
to
a
zoom
leader
that
theater
generator
sp
for
the
virtual
virtualizer
load,
single
node.
That's
one
solution.
O
J
O
A
Well,
you
know,
I
the
I
don't
I'm
not.
I
don't
think
you
you
don't
have
to
defend
the
changes
too
much.
It's
an
individual
draft
and
you
know
and
putting
it
forward
and
trying
out
different
things
is
fine.
I
I
think
personally,
I'm
not
sure
it
the
working
group
to
just
debate
that,
but
you
know-
and
that
goes
for
ac's
comment
too.
I
guess
I
mean
it.
A
You
know
what
matters
where
we're
at
and
what
so,
as
a
working
group
member,
I
I
read
through
it
and
it
kind
of
feels
like
throwing
pasta
at
the
fridge
right
and
seeing
what
sticks
I
mean.
There's
you've
got
two
different:
you've
got
a
node
and
you've
got
a
mesh
of
edges
and
then
even
for
transitions.
You
have
like
just
do
the
transition.
A
You
know
have
two
adjacencies
on
the
link
at
one
time,
although
it
doesn't
specify
how
that
works
and
point
to
point
since
that
wouldn't
work,
and
then
you
have
the
you
know
the
the
mechanisms
with
the
new
tlvs
to
do
the
transition.
You
know
anyway,
it
it
doesn't
feel
finished.
It
doesn't
mean
that
it
can't
be
finished,
but
you
know
there's
a
lot
of
like
different
options
right
and
we
don't
want
to
end
up
there
right.
We
don't
want,
like
the
pearl
thing
going
on,
where
you
can
do
things
10
different
ways.
A
We've
never
wanted
that
in
this
working
group.
I
don't
think
right.
We
and
we
also
try
to
go
for
kiss
solutions
right,
keep
it
simple
silly
or
something
else
right,
but
I
mean
it's,
and
I
think
this
is
running
up
against
that
it's.
It
doesn't
seem
like
we're,
keeping
it
simple
with
all
these
options
and
stuff.
O
O
O
So
before
we
have
smooth
transfer
solution
there,
we
have
surfacing
interruptions
so
after
we
implement
that
one
and
then
we
can
see,
we
can
check
there's
no
routing
interruptions
so
similar
for
this
one.
We,
if
we
don't
do
anything
for
the
most
transfer,
we
will
have
surfacing
interruption
because
those
we
have
when
we
abstract
a
zoom
area
to
a
single
node.
O
A
Nobody's
arguing
that
I
don't
think
anybody's
arguing
that
I
I
the
only
thing
that
I
see
arguing
is
that
nobody
cares
about
the
service
interruption,
because
it's
not
going
to
happen.
That
often
I
mean
routers
come
up
and
down
right.
So
in
any
case,
I
think
we
need
to
take
this
list
for
way
over
time
at
this
point,
and
I
think
we
also
ac
what
do
you
want
to
do?
I
think
we
went
through
the
flooding
minimum
degree
which
has
worked.
A
B
S
B
I
I
said
that
I
I
anticipated
that
we'd
have
discussion
on
ttz
and
I
thought
that
one
could
be
optional,
because
there
wasn't
much
other
than
adopting
satisfying
my
comment
comments
and
changing
the
name.
So
it's
really
that
and
it's
a
it's,
it's
a
it's
a
working
group
document.
I
don't
know
that
we
since
we're
behind.
I
don't
know
that
we
need
to
present
it.
K
K
K
Sr4
vpn
plus,
is
defined
in
drop
down
spring
as
our
boat
enhanced
the
weekend
and
that
surface
src's,
with
different
set
of
network
resources
for
packet
processing
and
the
resource
aware
system
can
be
used
to
build
resource
guaranteed
star
virtual
networks
and
this
document.
This
requests
the
mt-based
control
plane
playing
for
sr
written.
K
K
K
K
Please
updates
in
this
version
is
as
follows.
First,
we
add
a
description
about
the
advertisement
of
topology
specific
link
bandwidth
to
purchase
your
cpc
max
link.
Bandwidth
is
used
to
advertise
the
subset
of
and
with
reserved
for
a
particular
return,
and
the
advertisement
of
r30
attributes
at
per
topology
level
is
for
further
study
and
second,
we
will
remove
the
text
about
associating.
S
K
T
T
A
U
D
R
R
U
D
A
A
F
F
F
The
main
idea
is
to
associate
services
which
says
to
achieve
service
function,
changing
network
in
srv6
and
sr
amps
networks,
there's
already
a
draft
about
the
bgps
extensions
to
dispute
to
distribute
the
services
information,
and
this
draft
defines
igp
extensions
for
service
segments.
So
if
the
service
functions
are
deployed
in
itp
domains,
the
service
information
can
be
distributed
along
with
the
sys
definitions
of
many
fields
in
igb
extensions
are
the
same
as
the
bgp
os
draft
by
themselves.
There
are
still
some
differences.
F
Although
most
types
of
sl
proxy
define
now
associated
with
network
programming
functions
which
can
be
advertised
with
endpoint
behaviors,
the
p
flag
is
still
useful
if
the
pro,
if
the
proxy
of
certain
type
can
cannot
be
associated
with
the
network
function
or
if
the
user
want
to
define
new
type
of
proxy
for
private
use,
there's
no
need
to
apply
for
a
new
endpoint
behavior
next
slide.
Please.
F
So
the
second
sub-sub-tv
is
opaque
metadata
tv.
It
is
used
to
carry
the
vendor
specific
information
and
it
is
the
same
as
the
bgps
draft
and
the
ospf
version
2
and
version
3
extensions
are
similar,
so
we
are
not
going
to
describe
it
in
detail
here
on
next
slide.
Please,
and
we
request
feedbacks
and
comments.
Thank
you.
B
Yeah,
I
don't
see
him
in
the
queue,
but
you
saw
my
comment
that
I
don't
see
why
this
has
to
go
in
it's
not
the
information
isn't
associated
with
a
prefix,
that's
already
in
igp.
I
don't
see
how
this
has
to
go
in
the
igp
it
can,
if
it's,
if
the
sole
purpose
is
to
just
get
it
into
to
a
router
that
has
a
bgpls
address
family
session.
With
the
controller
you
could
have
use
bgp
to
communicate
with
those.
I
don't
that's
what
that
does
my
comment.
F
Yet
we-
and
we
think
that
then
the
in
the
case
that
if
yes,
if,
if
you,
if
you
run
bgp
on
the
order
service
function
for
the
nodes,
you
can
just
simply
go
use
the
bgp.
But
if
the
service
function
for
orders
are
deployed
in
igb
domain,
so
I
think
then
we
can
use
igp
to
distribute
the
service
function.
Information
into
the
is
so.
A
Yeah,
the
basically
the
the
feedback,
though
I
think
this
is
me
as
a
working
group
member,
the
igps
are
very
special
and
we
don't
like
to
destabilize
them
right
with
extra
information
that
doesn't
need
to
be
there.
That's,
for
example,
there's
a
gen
app
extension
for
isis
so
that
you
could
run
a
different
version
of
isis
that
could
be
destabilized
with.
You
know
extra
info
like
this.
A
F
A
But
you're
using
bg
you're
using
bgp
using
the
igp
as
a
transport,
and
that's
really
super
frowned
on
right.
Instead
of
having
multiple
bgpls
speakers,
you're
saying
well,
we'll
just
transport
the
information
in
the
igp
to
the
final
bgp,
ls
speaker
right
and
anyway,
I
I
think
we
have
to
move
on,
but
we
can
carry
this
out
on
the
list
right.
We
have
more.
A
R
R
I
R
R
A
R
A
J
A
B
A
V
V
What
about
the
little
is
the
word
we
remove
the
outer
bundles
member
yet
tenses,
and
we
use
outbound
members
to
build
the
tree
softer
way
with
traditional
administrative
group
staff
tr.
We
are
attended
administrative
groups
of
trua
based
on
discussing
our
ios,
our
mail
list.
We
attend
the
document
to
informational
because
with
the
remote
removal
of
unnecessary
activities
of
tlv,
the
document
no
longer
has
anything
to
standard
dice,
but
how
to
create
a
flex.
V
V
V
J
T
A
No,
no,
we
haven't
had
enough
time
with
your
audio.
If
you
try
to
transfer
video
over
it,
it
probably
would
be
even
worse.
Everyone
else
can
see
your
slides,
I'm
bringing
them
up
right
now.
I
can
tell
you
what
side
you're
on,
if
you'd
like
as
long
as
we're
able
to
hear
you,
okay,
I'm
sharing
the
motivation
slide.
Can
you
see
that.
R
Sorry,
yeah,
okay,
so
so
the
this
is
the
scenario
for
the
for
poa.
You
know:
normally
the
abr
will
do
the
summary
work
and
only
the
summary
of
this
will
be
announced
to
another
area,
but
one
node
or
link
failure.
Rotary
other
area
will
not
be
notified,
so
I
think
every
institution
will
be
exacerbated
for
srv6
based
vpn
solution.
So
next
slide.
A
A
B
A
R
S
Yeah,
I
just
have
a
couple
of
basic
questions
on
the
proposed
changes
to
ospf
ls
update
this
prefix
unreachable,
how
different
it
is
with
the
already
existing
mechanism
to
withdraw
a
route.
You
already
have
lsa
summary
lsa,
where
you
can
fill
max
age
right
in
order
to
flash.
Does
it
mean
only
in
case
of
summarization?
This
comes
and
rescues
for
the
specific
prefix.
S
B
B
Also
see,
there's
a
lot
of
things,
there's
a
lot
of
ways
to
solve
this
problem.
Speaking
as
a
working
group
member,
I
should
qualify
that
there's
a
lot
of
ways
to
solve
this
problem
and
there's
a
lot
of
questions
on
this
draft.
There's
a
long
thing
I
haven't
read
any
of
them.
I
got
like
60
emails
in
my
since
I
started
watching
meetings
today
or
more
than
that.
70
emails
there's
a
lot
of
ways
to
solve
this.
B
B
S
S
A
Chris
chris,
thank
you
for
jumping
in.
I
was
just
about
to
say
the
same
thing,
which
is
we
need
to
take
this
to
the
list
june
is
asking
for
that,
and
I
think
that's
the
only
fair
thing
to
do
at
this
point.
I
mean
it's
all
negative
right.
I
want
if
somebody
else
was
going
to
jump
forward.
There
are
people
that
support
this
on
the
working
group
mailing
list
and
have
chimed
in
so
I
don't
think
it's
fair
to
present
it
as
a
single-sided
thing
right
there.
There
are
other
people
that
support
this.
A
A
B
A
Yeah,
okay,
great
all
right,
so
it
mostly
came
off
without
too
many
hiccups.
We,
our
time
management,
was
a
little
bit
off,
but
thank
you
everybody
for
coming
the
ttz.
We
need
to
discuss
a
little
bit
more.
I
guess,
and
then
I
guess
the
chairs
just
have
to
make
a
decision
about.
You
know
I
mean
I
I
think
I
think
we're
gonna
have
to
probably
do
this
as
a
call
for
adoption
to
see
what
people
support
it
right,
but
we've
already
had
people
chiming
in
by
the
way.
A
It
was
one
sort
of
process
thing.
You
know
we,
the
chairs,
actually
call
for
the
adoption,
but
I
mean
I
guess
people
did
want
to
say
they
supported
that,
but
anyway,
so
we'll
be
making
a
decision
on
that
soon
and
on
the
other
things,
let's
go
see
everybody
in
the
list
and
probably
next
time
virtually
as
well.