►
From YouTube: IETF115-LSR-20221109-0930
Description
LSR meeting session at IETF115
2022/11/09 0930
https://datatracker.ietf.org/meeting/115/proceedings/
B
A
D
A
E
F
A
B
A
Okay,
so
has
anybody
else
chaired
a
meeting
yet
does
the
thing
on?
Does
your
laptop
on
the
right
actually
work
to
do
anything?
No.
A
F
F
Now
here
we
got
all
these
drafts.
Not
only
John
did
a
lot
of
work,
excellent
work,
I
mean
it
was.
F
It
was
getting
all
these
and
getting
and
Peter
and
drove
and
well
even
even
the
viz
document.
There
were
some
that
lasted.
We
got
all
these
not
only
through
the
80
review,
but
through
all
the
directorate
reviews
and
through
the
isg
and
they're
on
the
RFC
Q.
This
is
significant:
the
flex
algae
algorithms
That's
the
basis
for
a
lot
of
the
draft
working
group
graphs.
We
got
today
next.
E
F
We
still
have
this,
but
once
Flex
algorithm
is
I,
guess
it'll
be
published
as
a
cluster.
F
I
probably
should
have
updated
this,
because
Flex
algorithm
is
now
an
rfcq
next
slide
and
we
got
the
flood
reflection.
John
and
Peter
actually
got
got
through
the
A.D
review
on
that
the
director,
because
that's
going
to
be
in
the
telechat
early
next
month,
the
post
extension
says:
rv6
correspond
to
the
Isis
ones.
There's
some.
F
We
went
through
a
few
iterations
with
that
and
we
just
finished
the
ospf
terminology
has
publication
requested.
It
does
no
longer
need
a
routing
director
review.
Sue
Harris
did
that
and
it's
it's
ready
for
ad
review
as
well.
F
We
we
covered
this
this
on
the
list,
this
one
where
this
is
the
one
where
I'm
talking
to
some
of
the
implementers
ospf
V3,
to
make
sure
that
the
24-bit
metric,
it's
all
right
to
use
that
to
make
the
base
a
prefix
unreachable
in
the
base
topology
for
inter
tra
area
routes.
Currently
it's
used
for
inter
and
external
routes,
but
we're
we
want
to
extend
that.
This
will
really
be
useful.
It'll,
be
just
the
same
for
all
the
route
types
next.
B
F
Fast
flooding
I
think
we're
pretty
much
there
we're
gonna.
That
was,
that
draft
generated
a
lot
of
a
lot
of
interest
and
we've
had
some
implementations.
It's
not
something
that
you
know.
You
have
to
standardize
what
you
do
internally,
but
we've
gotten
Bruno
did
some
good
work
on
the
the
signaling
to
signal
just
the
right
amount
of
information
between
neighbors
so
that
the
flooding
can
adjust
to
the
conditions
of
the
router
receiving
them
and
I.
Don't
know
if
you
followed
it.
F
F
F
I'll
say
the
ospf
generalized
transport,
that's
been
renamed
I'm
gonna
I'm
gonna
have
a
you're
gonna,
get
to
hear
me
talk
again
today.
So
let's
cover
that
next
slide.
I,
don't
think
I
need
to
say
anything
about
any
of
these
other
ones,
the
extended
hierarchy.
That
was
a
lot
of
good
work,
but
we
thought
that
it
was
a.
It
was
enough
of
a
significant
change
to
Isis
we'd
really
want
to
let
it
Park
Until
somebody
implemented
it
and
the
the
main
offer.
Tony
Lee
has
said
that
there's
no,
the
the.
A
F
F
Okay,
I
know
we
have
some
documents
that
people
are
wanting
working
group
class.
Calls
on
I
didn't
cover
this,
but
please
remind
us
on
the
lists
or
send
us.
You
know
you
know.
I
know
we
have
some
at
least
a
couple.
Adoption
call
requests
from
offers
of
other
graphs.
A
F
A
B
I
Good
morning,
everyone
this
is
yinchen
I'm,
going
to
do
an
update
of
the
SSR
young
models,
so
I'm
now
going
to
follow
you
with
other
model
details.
So
this
one
is
mainly
a
joke
map
of
all
the
SR
RSI
young
models.
So
next
slide,
please,
okay,
so
we
finally
published
the
assets
and
ospf
based
model,
also
rxc
9134,
the
young
model
for
Isis
reverse
metric.
I
So
last
time
I
did
a
young
update
was
at
the
ATF
in
Singapore
three
years
ago.
That's
the
time
when
we
were,
we
were
happy.
The
both
space
models
were
in
the
RFC
editor
Cube.
So,
three
years
later
we
made
it
we
finally
published,
and
so
with
those
two
base
model
published
and
that
made
all
the
protocol
extension
modules
augmenting.
Those
two
base
models.
I
So
the
next
few
models
we
want
to
publish
like
the
both
ospf
and
the
ISS
Israel
model.
So
these
two
were
pretty
much
ready
and
the
Isis
Sr
model
actually
already
finished.
The
young
doctor
last
call
reveal
and
we
need
to
do
the
same
thing
for
ospf
SRM
and
the
ospf
V3
Sr
young.
So
all
these
three
are
for
mprs
data
plane
and
that
one
will
actually
sort
of
forgot
it.
I
A
I
I
F
As
Murphy's
Law
would
have
it
there's
actually
somebody
during
the
last
three
four
months
that
is
working
on
in
an
open
source
implementation
of
the
ospf
Yang
model,
the
the
standard,
one,
not
the
open,
Kit
the
standard
one,
and
so
we
got
a
lot
of
late
comments
from
him.
I
think
once
he
he's
not
ready
yet,
but
we're
gonna
ask
him
to
come
in
and
present
his
open
source,
this
open
source
code.
If
we
you
know
on
the
agenda
and
a
future
IIT
I,
think
that'd
be
good.
E
Jeff
has
very
quick
comment
just
for
the
notes,
so
absolutely
correct.
Bfd
did
hold
things
up
because
we
found
a
bug.
What
was
sort
of
the
interesting
bit
of
the
process
is
that
we
found
out
that
for
effectively
four
lines
of
you
know
fixing
ITF.
It
could
be
eight
months
to
get
it
through
as
a
young
module
update,
and
you
know
as
much
as
it
was
our
fault
as
you're
saying
you
had
all
these
last
minute
things
that
Krypton
after
last
call
during
RFC
process.
E
I
F
Yeah
I
just
want
to
say
one
more
thing
about
these
two
models:
the
SR
models
once
we
publish
these
These
are
the
last
working
group
documents
from
before
the
merge
of
the
ospf
and
Isis
working
group.
So
it'll
be
good
to
publish
these
as
well,
because
then
you'll
be
able
to
do
a
search
in
the
in
the
data
tracker
for
hyphen,
LSR
hyphen
and
get
all
the
working
group
documents
or
all
the
and
and
all
the
drafts
that
people
are
purpose,
meaning.
I
Next
slide,
please,
okay,
this
one.
We
also
want
to
get
a
published
soon,
because
this
is
the
ospf3
extended
RSA.
It
also
lays
the
foundation
of
all
of
some
of
new
feature
extensions
based
on
ospf.
Please
read,
send
it
out
I
say
so.
We
need
the
working
group
chair
to
start.
The
young
doctor
request
the
real
Doctor
review
and
joking
directory
review
same
as
the
previous
two
next
slide.
Please,
okay,
ospf
admin
tax.
I
This
is
the
experimental
draft.
We
are
doing
not
experimental
comparative
standards,
rxc
ones,
but
this
is
the
one
we
try
to
put
the
young
model
inside
the
draft
itself.
We
choose
this
one,
because
this
one
is
very.
The
exportable
extensions
itself
is
very
clear
and
straightforward,
and
we
just
thought
we
we
may
want
to
try
this,
but
for
some
features,
that's
more
complicated
like
a
flexible
or
application
specific
attribute.
That's
probably
we
want
to
keep
the
module
separate,
but
this
sort
of
extensions
are,
we
think,
are
the
candidates.
G
A
A
It
doesn't
I,
just
don't
think
it
holds
anything
up
to
put
it
in
there.
Unless
you
don't
have
the
person
who
knows
how
to
do
it.
That
was
the
big
complaint.
When
we
brought
this
up
the
first
time
was
the
person
doing
the
protocol
extension
work,
didn't
understand,
Yang
well
enough,
and
they
didn't
want
to
have
to
be
required
to
do
the
work
to
get
their
protocol
extension,
but.
F
Yeah
and
the
ospf
and
Isis
Yang
models
are
quite
involved
after
a
number
of
people.
You
know
if
we
have
like
examples
like
this
it'll.
B
I
Yeah,
so
if
you
have
a
draft,
that's
small
protocol
extensions,
you
want
to
have
this
sort
of
draft.
Have
the
your
model
put
together
and
you
don't
want
to
write
the
young
module
yourself
and
just
talk
to
us.
Any
of
us
will
try
to
help.
I
So
then
we
have
the
ospf
module
augmentation
for
additional
features
version
one
and
we
have
the
same
thing
for
ISS.
So
these
are
the
modules
that
you
make
together
with
the
draft,
so
we
have
them
put
all
together.
I
So
we
just
keep
adding
different
new
features,
I
think
after
the
we
published
the
SR
module
and
the
extended
out
RSA
module,
then
we
Pro.
This
will
be
the
next
best
suppose
the
ospf
and
the
Isis.
So
we
will
cut
a
stop
there
and
then
start
our
version
too,
so
that
this
is
the
list
of
features
so
far
we
covered.
If
you
think
we
missed
something.
Just
let
us
know
next.
I
Yeah,
this
is
the
same
thing
for
Isis.
That's
the
list
of
features
covered
in
the
Isis
model.
Next
slide,
please,
and
then
we
have
the
ospf
and
ISS
Sr
young
module.
These
are
just
sitting
in
the
back
corner
for
now
will
be
the
after
the
base
draft
published
we'll
look
at
this
one
next
slide,
please
so
just
a
summary:
you
can
see
the
different
colors
and
they
miss
different,
probably
go
as
patches
how
we
want
to
progress
them.
I
I
A
Yeah
I
mean
I,
because
I
I
kind
of
think
I'd
like
to
get
a
I
know
you
guys
like
the
the
chunking,
but
it
sure
would
be
nice
to
just
get
the
people
that
are
proposing
new
things
to
do
it.
You
know
so
that
we
don't
have
because,
like
you
said
the
problem,
is
you
keep
adding
things
to
it
right
and
and,
as
Jeff
said,
that
resets,
the
timer
yeah.
A
I
J
A
I
mean,
but
the
thing
nobody's
gonna
complain
about
the
Yang
model.
I
guess
right:
they
might
complain
about
the
product,
but
the
you
know
the
operational
State
describing
it
I,
don't
think
it's
going
to
cause
any
it's
just
it's
just
a
I'm
just
trying
to
figure
out
a
way
to
get
this
stuff
to
go
faster
right.
A
F
F
Also
skipped
the
experimentals,
especially
the
ones
that
haven't
taken
off
right
like
there
were
three
different,
monets
and
I
know.
One
of
them
has
very
limited
deployment,
but
the
other
two
I,
don't
I,
don't
believe
they're
deployed,
and
so
actually
those
those
would
have
added
significant
augmentations
would
have
been
a
lot
of
work.
There
were
some
other
experimental
ones.
We
skipped
we
didn't
do
Isis,
ttz
anything
experimental.
We
skipped
as.
A
A
Yes,
yeah
yeah,
it's
okay,
all
right!
What's
up
next
thanks,
yeah
I
believe
that
you're
up
in
the
house.
F
Okay,
this
is
the
ospf
generalized
transport.
Now
the
most
work
we
did
on
this
was
coming
up
with
a
new
name.
It
used
to
be
it
used
to
be
transport
instance,
but
we
decided
that
it
didn't
really
give
it
the
gravitas
that
it
required.
So
we
came
up
with
this
new
name:
the
ospf
GT
Grand,
Touring,
no
generalized
transport
next
slide.
F
Right,
as
you
know,
we
have
we
have
a
lot
of
drafts
I'm
going
to
go
into
this,
that
use
ospf
to
distribute
information,
so
this
is
this
is
really
using.
Ospf
is
very
and
and
Isis
as
well.
This
proved
very
useful
for
disseminating
information
throughout
the
igp
domains,
ospf
domain
and
in
Isis
they
have
a
RFC
I
forget
the
number
of
it
called
gen
app
where
you
can
have
a
another
instance
well
for
ospf.
F
F
Now
this
is
the
biggest
thing
besides,
besides
having
a
separate
instance
in
which
you're
gonna
you're
gonna
flood
non-routing
information,
you
can
have
sparse
topologies
what
I
mean
by
a
sparse
topology
is
that
the
instance
only
talks
to
those
ospf
routers
that
require
the
information
also,
because,
because
we're
not
Computing
hop
by
hop
routing,
you
still
have
a
topology,
but
it's
an
over.
It
can
be
an
overlay
topology.
F
Next
next
slide,
here's
just
an
example:
you
see
you
have
the
ospf
routing
domain
there
and
you
can
see
that
all
the
routers
inside
the
domain
they
don't.
They
only
do
unicast
routing
in
the
base
instance
zero,
and
you
have
routers
on
the
edge
that
are
maybe
doing
some
sort
of
services
that
they
need
to
have
some
information
disseminated
to,
and
they
have
multiple
instances.
So
you
establish
the
adjacencies
across
the
across
the
domain
and
you
just
use
normal
ospf
flooding
mechanisms
to
exchange
the
information.
F
One
of
the
you
know.
One
of
the
main
things
reasons
we
don't
like
to
use.
Ospf
and
Isis
to
disseminate
information
is
because
a
lot
of
times
it's
to
maybe
one
or
two
other
routers
in
the
whole
domain
that
are
doing
something
and
they
don't
need
it
and
everybody
in
the
whole
domain
gets
it
next
slide.
F
Well
one
another
thing
with
this:
now
a
lot
of
a
lot
of
people
have
said:
okay,
you
can
put
it
in
the
base,
ospf
instance,
and
you
can
still
prior
prioritize
the
unicast
routing
information
or
whatever
over
any
other
information
you're
distributed.
That's
very
hard
to
do.
I
mean
we
already
have
all
this
stuff
in
here
where
we,
where
we
throw
away
hellos
packet
processing,
we
make
sure
that's
done,
because
if
you
lose
an
adjacency,
it
starts
on
next.
F
F
Think
Murphy's
law
has
helped
us
a
lot,
but
in
the
early
2000s
we
had
a
lot
of
bigger
networks
that
were
just
getting
into
melting
due
to
topology
changes
and
flooding,
so
putting
it
in
a
separate
instance,
especially
since
most
most
platforms
are
running
and
people
are
running,
you
know
routing
protocols.
On
top
of
Linux,
it's
much
easier
to
prioritize
a
process
to
keep
things
separate.
F
You
can
you
can
you
can
use
what
I
was
going
to
say?
Ospf
V3
supports
the
instance
in
the
packet
directly.
We
have
an
extension,
an
RFC
for
ospf
I.
Don't
think
it's
been
implemented
much,
but
you
you
can
do
instances
in
ospfp2
as
well
with
using.
F
The
in
the
packet
and
like
I
said
once
for
the
packets.
You
can
use
different
present.
Ip,
precedences
or
I
forget
what
it's
called
in
ospf
in
IPv6,
but
you
could
use
the
analogy
to
IEP
preference
in
OS
in
IPv6
to
Pro
private
prioritize.
The
unicast
packets
over
the
I
mean
the
ospf
packets
for
unicast
apology
over
the
ones
for
transport
instance,
and
here
it
just
shows
a
new
tlb.
F
Basically
Isis
had
already
gotten
a
registry
for
Gen
app
for
the
different
applications,
so
we'll
use
that
same
registry
to
for
any
applications
and
we're
able
to
for
ospfp
2
we're
going
to
put
the
have
a
new
ospf,
opaque,
LSA
type,
with
a
new
function
code
for
ospf
V3,
we'll
just
use
the
new
OS
LS
LSA
type.
F
And
the
first,
the
first
we
only
have
one
other
new
tlv
in
that
that's
a
top
level
tlv,
so
we're
figuring
with
this
will
identify
the
application
type
and
then
the
the
applications
will
specify
the
encodings
underneath
this
top
level.
Tle
next
slide.
F
Okay,
this
is
this
is
talking
about
applications.
Now
we
didn't
attempt
to
Define
these
the
applications
themselves
and
any
draft.
Let's
say
this:
this
becomes
assuming
this
becomes
a
standard
at
some
point,
anything
that
uses
it
would
need
to
Define
the
adherence
to
the
condition
of
reachability.
In
other
words,
over
this
sparse
topology,
are
you
you'd,
normally
only
be
able
to
use
information
for
from
a
router
that
was
reachable
over
the
sparse
topology
and
whatever
your
internal
apis
you'd?
Let
people
you
know
you'd
Rift
broad.
F
F
There
was
a
lot
of
discussion
on
IDR
and
LSR
about
the
ongoing
effort
to
keep
bgpls
in
line
with
with
with
igps
now
what
this
would
do,
at
least
for
ospf.
You
could
just
you
could
just
put
a
wrap
around
this
and
you
could
just
transport
the
lsas
between
routers
over
the
sparse
topology
without
any
re-encoding
and
then
do
whatever
you
want
with
them.
F
I
mean
I
know
we
got
a
lot
invested,
a
lot
of
controllers
I,
don't
think
this
will
happen,
I
think
we'll
just
stay
with
BLS
and
that's
my
that's
my
original.
That's
my
thinking,
but
this
is
one.
Another
thing
is
now
we're
talking
about
putting
all
these
flow
specs,
depending
on
how
much
you
can
put
those
into
this
management
information
and
there's
a
5G
application
in
the
draft.
F
K
Or
not
need
to
be
further
discussed.
Here
is
my
my
point,
I
think
originally
select
or
you
select
the
ospf
as
the
delivery
protocol.
You
can
provide
the
reliable
and
variety
mechanism,
but
for
the
non-looking
information
we
don't
need
the
front
end
character.
We
just
need
the
reliable
character
of
the
OTL
protocol
so
and
based
on
this
assumption.
The
reason
that
is
you
know
there
are
various
reliability,
reliable,
teleport
protocol
in
the
current
IIT
iitfo
standard.
K
So
the
reason
that
we
still
select
the
oipf
as
the
24
portal
I
think
it
is
maybe
the
search
information
may
be
related
to
the
routine
information.
But
but
in
your
draft
you
just
omit
the
interaction
of
the
ospf
for
root
resistance
and
the
application
instance.
I
think
this
is
the
most
important
important
part.
If,
if
you
consider
consider
the
interaction
of
these
two
different
kind
of
variety,
of
instance,
I
think
the
situation
will
be
complex
and
the
there
are
another
point
that
you
just
put
the
complex
to
the
operator.
K
You
know
for
the
different
top
instance
with
the
operating
Master
deploy
the
different
set
of
the
labor
okay.
There
are
a
lot
of
redundant
configuration
and
management
for
the
overall
network
operations,
so
I
I
thought
whether
the
support
is
the
best
approach,
and
we
can.
We
can
see
from
the
history
of
the
another
related
draft.
Let's
see
your
helmets
and
generally
generally,
and
currently
there
are,
there
are
I
think
there
is
no
deployment
for
such
solution.
So
I
think
this
is
the
indication
for
the
similar
similar
approaches,
not
maybe
not
the
best
approach.
Okay,.
F
Yeah
I,
definitely
it
definitely
the
draft.
That's
one
thing:
I
think
we
need
I
need
to
add
to
the
draft
is
the
manageability
considerations
and
it
definitely
will
require
you
know
more
configuration
than
if
we
just
had
a
knob
to
stuff
everything
into
the
base
instance.
F
F
K
There
are
one
of
the
your
use
case
either
for
the
MP
mec
mec
deployment
for
MEC
Department.
What
do
you
want
to
achieve
is
the
companies
of
the
network,
information
and
the
server
information.
So
we
expected
such
information.
We
did
be
Transportation
unique
instance,
not
the
different
instance.
Okay,
foreign.
F
Look
at
that
application
that
application.
Let's
say
that
I
know
there
was
a
lot
of
comments
on
on
on
using
that.
Maybe
that
doesn't
belong
in
the
transport
in
in
the
in
ospf
GT,
because
that
would
affect
routing
that
is
a
routing
routing
draft
I'll.
Take
a
I'll.
Take
a
look
at
that
exactly
what
we're
talking
about
for
the
5G.
J
Okay,
I'm
Peter
I'm,
going
to
present
an
update
on
the
prefix
unreachable
draft.
J
It's
better,
probably,
okay,
next
slide,
please
all
right,
so
this
has
been
presented
at
the
last
ITF
I'm,
not
going
to
do
the
same
presentation,
I'm
just
going
to
do
a
quick
update
here.
So
what
is
the
draft?
Does
it
proposes
Backward
Compatible
mechanism
to
advertise
a
unreachable
prefixes?
J
J
J
So
we
updated
the
draft
based
on
some
of
the
comments
that
we
got.
We
explicitly
specify
in
the
draft
which
Isis
tlvs
are
supposed
to
use
the
UPA.
We
did
the
same
for
SPF,
V2
and
V3.
We
specify
the
lsas
and
tlvs
where
you
pay
is
applicable.
J
We
got
a
comment
saying
that
what
we
do
when
we
propagate
the
UPI
is
not
what
the
base
specification
of
the
protocol
do.
So
we
put
some
text
in
the
draft
describing
that
you
cannot
use
the
reachability
for
propagation,
which
is
what
is
being
done
in
the
protocols
for
the
regular,
reachable
prefixes.
It's
contrary
you
you,
you
must
not
use
the
reachability,
you
basically
propagate
unreachable
and
you
don't
have
the
prefix
reachable.
So
that
is
a
deviation
from
the
basic
specification.
J
J
So,
in
terms
of
the
intended
status,
the
draft
is
published
as
it
is
as
an
informational.
Some
people
feel
that,
because
of
the
propagation
specification,
we
have
some
normative
language
there.
We
should
change
this
into
the
standard
track.
I
leave
that
up
to
the
working
group
to
decide
and
find
both
ways,
but
probably
would
make
a
sense
to
make
it
a
standard
track
because
of
that
change.
J
Next
slide,
please
yeah
and
the
biggest
discussion
that
has
been
going
on
on
the
list
is,
you
know
either
using
the
unreachable
metric
that
is
already
defined
in
the
protocols
versus
having
an
explicit
signaling
for
unreachability,
so
some
people
feel
we
should
have
an
explicit
mechanism.
J
Well,
the
problem
with
that
is
that
it
would
make
the
the
change
known
by
quad
compatible.
So
to
deploy
this,
you
would
need
to
update
every
single
router
in
the
network.
Otherwise
the
routers
would
keep
thinking
that
this
prefix
is
actually
reachable,
so
that
would
significantly
complicate
the
deployment
of
this
extension.
J
J
So
we
are
welcoming
any
comments
on
discussion
on
the
working
group.
It
looks
like
there
is
sufficient
interest
in
this.
There
is
an
implementation.
At
least
one
I
know
the
second
one
is
being
done
or
will
be
done
soon.
K
K
Curry's
detail
perfect,
so
this
is
I
think
this
is
the
right
use
usage
of
the
ls
infinity
and
the
second
point
is
there
are
several
other
usage
for
this
value,
so
we
I
think
we
cannot.
We
need
not
a
complex
the
situation
by
we
use
or
they
Define
the
ls
Infinity
media.
For
for
the
pretty
unreachable
usage
and
I.
Think
Peter
Hill
mentioned
the
foreign.
K
Expression
there
are
I
think
the
situation
will
be
more
complex.
You
know
it
will
bring
more
limitation
for
the
deployment
of
the
such
solution.
You
know
I
think
from
one
from
one
from
the
implementation
of
device,
the
easy
to
implement
implemented,
but
for
the
deployment
of
the
overall
source
of
operator,
I
think
it
is
complex.
So
we
think
we
should
simplify
the
situation
and
need
the
explicit
indication
for
the
perfect
unreachability.
Okay.
J
Right,
so
let
me
try
to
answer
your
comments,
so
the
definition
of
you
are
talking
mostly
about
the
OSP
adults,
Infinity
I.
Guess
that's
clear:
it's
obvious
that
it
means
unreachability,
whether
you
like
it
or
not.
It
is
unreachable
and
we
can
use
it
in
terms
of
using
this
metric
for
other
purposes,
you're,
probably
referring
to
IPR
flex
algor,
and
things
like
that.
We
have
defined
explicitly
that
these
metrics
are
Infinity
metrics
in
that
context
as
well.
So
honestly,
I
don't
see
any
complexity,
but
you
know
we
can
argue
forever.
F
Okay
speaking
as
working
group
member,
the
first
thing,
I
gotta,
say
I
think
it
needs
to
be
standards
track
because
the
avrs
need
to
have
a
different
behavior
of
propagating
it.
I
think
you
mentioned
that
I,
don't
know,
I,
don't
know
for
everybody
and
I.
I
really
think
this
is.
This
is
the
best
from
Backward
Compatible
standpoint.
I,
don't
think
that's
picking.
F
So
also
speaking
as
a
working
group
member,
if
you
know,
there's
implementations,
I,
think
the
other,
the
the
one
thing
that
I
didn't
get
way
back
about
a
year
ago
we
started
talking
about
this
was
this
is
a
temporary
if,
like
an
ephemeral
notification
in
this,
at
least
this
draft,
it's
meant
to
go
to
routers
that
are
going
to
redo
the
recursive
resolution.
So
it's
it's
also
also
from
deployment
standpoint.
It's
not
it's
actually
better
from
a
deployment
standpoint,
manability
standpoint,
because
you
only
have
the
routers
that
need
to
do
it.
J
F
G
Okay,
just
speaking
as
a
contributor
here-
and
it
just
occurred
to
me
because
AC
presented
like
just
before
you
or
you
know
a
couple
before
you
is
like-
isn't
this
potentially
an
application
for
the
Gran
Turismo
version
of
ospf
that
AC
just
presented
because
there's
like
a
whole
bunch
of
routers
in
the
you
know
that
just
don't
need
to
know
about
this
stuff?
Thank
you.
I.
J
J
You're
writing
terms
of
that.
Not
everybody
needs
this,
so
we
flooded
because
this
is
just
slide
as
a
standard,
prefix
reachability
with
a
specific
metric.
The
processing
is
up
to
the
receiver,
but
it
acts
on
it
or
not.
C
Hello,
this
is,
and
I
have
two
comments.
Now,
first,
is
the
if
we
use
our
cemented,
so
we
just.
We
also
need
to
consider
the
conversion,
because
in
the
network
we
deployed
some
nodes
yeah,
but
they
didn't
think
the
they
didn't
know.
The
new
behavior
of
the
of
what
you
want
to
to
do
and
like
when,
like
the
I,
was
imprinted
Now
new.
J
C
C
See
them,
but
for
the
new
term
for
the
auditor,
this
is
a
command
when
we
use
this
command
that
we
we
that
has
metric
root,
I'll,
say
and
the
the
only
use
is
to
define
the
untributed.
But
in
your
structure
you
know
document
as
a
behavior
is
to
Define.
Maybe
you
have
some
new
Behavior
I
think
so,
even
in
this
situation,
I
think
the
old
device
can't
do
that.
So.
J
J
What
we
do
here
is
that
we
are
advertising
and
reachable
for
something
which
never
was
reachable,
because
it's
part
of
the
summary,
but
at
the
end
of
the
day,
what
you
want
at
the
edge
device
is
to
act
on
the
loss
of
the
reachability.
So
I
don't
see
a
conflict,
but
I
think
we
can
talk
about
it.
Okay,.
A
L
Now
look
at
Cisco,
so
this
is
mainly
about
the
ls
Infinity
use.
I
just
want
to
a
code
that
this
has
been
there
in
the
protocols
since
decades.
There
is
nothing
changed
there
from
its
meaning
or
semantics
purposes.
Probably
what's
added
is
really
the
processing
at
the
receiver
to
treat
it.
As
you
know,
an
indication
so
I
really
don't
understand
or
follow
the
debate
about
the
ls
Infinity
part.
M
I
think
this
is
a
Hot
Topic,
because
we
had
quite
a
few
jobs
working
on
this
one
right.
So
this
one
looks
like
a
for.
The
infinity
Matrix
looks
like
is
for
unreachable.
Right
also
is
used
for
aging
out
for
some
other
day
which
to
message
that
will
be
also
consider
this
one
either
one
parameter
for
each
out
right.
Oh.
M
Also,
this
is
the
Matrix,
so
if
some
link
metric
or
whatever
metric
is
close
to
this
value,
all
is
considered
also
on
infinity
unreachable,
some
big
metric
I
mean
yeah.
J
So
I'm
not
sure
I
understand
so
you're
saying
how
do
we
distinguish
this
between
the
the
Aging
out
of
the
LSA?
No,
no.
M
Yeah
I
know
I
know,
that's
a
considered
one
parameter
for
each
out
in
RC.
If
we
check
that
one
another
thing
is
for
the
ninja
Matrix
for
magic
is
close
to
Infinity
of
the
handle.
This
case
is
reachable,
but
the
metric
is
very
big
is
close
to
Infinity,
so
you
consider
is
also
unreachable
or
reachable
well.
J
M
I'm
going
to
consider
those
are
different
Solutions,
so
this
one,
you
claim
is
the
back
order,
compatible
I.
Think
the
other
solution
can
also
make
a
pack
of
convertible,
but
I
don't
know
if
there's
a
different
number.
N
Tony
P
Juniper
jumping
into
the
slot,
so
as
metaphorane,
we
shouldn't
forget
that
this
is
inflected
Upon
Us
by
technologies
that
were,
you
know,
fashionable
but
forgot
that
oam
is
part
of
a
you
know,
decently,
run
network
and
we're
solving
it
in
arguably
the
wrong
protocol
of
all
the
bad
ideas
to
go
about
this
thing.
This
is
by
far
the
best
one
right,
so
it
has
a
validity.
Okay.
N
What
my
comment
is
I
would
not
put
it
on
the
standards
track,
because
this
does
fundamentally
doesn't
scale.
We
all
know
that
right
use
that
stuff,
as
and
in
the
right
amount,
as
a
spice
can
stop.
M
G
N
We
put
it
on
the
standards
track,
everybody
and
our
customers
and
their
dogs
will
demand
for
the
staff
to
be
implemented,
and
they
will
feel
that
this
thing
is
something
they
should
be
rolling
and
before
we
know
we
have
to
stop
the
large
scale
and
deployment,
so
I
would
keep
it
on
informational
as
something
you
know
that
you
have
in
your
toolbox,
a
toolbox
and
you
pull
out,
and
if
you
use
it
correctly,
it's
not
a
bad
mechanism.
I
would
not
signal
that
I.
Think
it's
completely
Superfluous
I
mean
the
beauty
of
this
thing.
N
Is
that
you
actually
without
signaling
into
your
work?
You
can
mix
it
and
it
will
work
fine
if
we
really
really
push
for
the
standards
track.
I
think
the
operational
concern
is
something
that
will
be
steering
straight
into
your
face,
like
a
really
big
operational
section,
saying
like
you're,
peeling,
off
stickers
and
you'll
get
hurt
most
likely
or
maybe
a
separate
operational
document,
but
this
will
get
lost
right.
So
that's
kind
of
my
meta
comment,
but
still
from
all
the
stuff
sloshing
around.
N
By
far
the
best
thing,
if
you
want
to
solve
in
the
protocol
and
no
signaling
I
mean
that
will
just
ramp
up
complexity
to
the
max
yeah.
J
So
I
agree
with
everything
you
said,
even
with
the
the
best
of
the
bad
things,
but
you
know
we
have
to
solve
the
problem
in
in
a
certain
way.
So
in
terms
of
the
standard
track,
I
wish
we
can
keep
it
informational.
The
only
thing
is
that
we
are
changing
the
ABR
behavior
in
terms
of
propagation.
There
is
a
normative
language
there,
I
don't
know.
If
we
can
do
that
in
the
information,
if
you
can
I'm
not
for
it,
we.
N
Gonna
have
to
this
is
very
subtle.
We
do
not
change
APR,
behavior
and
I.
Explain
why?
Because
the
only
thing
we
mandate
is
the
behavior
of
Notes
on
The
Wire,
that's
it.
The
whole
idea
of
interoperability
means
that
we
Define
the
observable
behavior
on
the
wire.
As
long
as
you
comply,
you
comply
to
the
specs.
Everything
else
is
kind
of
obviously.
N
J
G
J
Propagate
prefixes
between
the
levels
or
areas
and
that
that
talks
about
reachability
look
I
I
really
would
like
to
keep
this
informational.
To
be
honest,
this
is
the
only
thing
if
we
can
do
this
with
information
track,
I'm
all
for
it.
I'm
busy.
F
A
Thanks
Tony
I
do
you're
up
next,
but
can
you
please
go
quick?
We've
got
two
other
people
before
we
got
to
cut
the
cue.
K
K
Think
the
there
are
there
there
are
already
the
usage
of
the
lse
infinity
Network
or
in
the
in
future.
So
if
you
define
a
tool
or
more
meaning
for
for
them,
for
it,
I
think
zero
definitely
will
be
exist
to
the
all
ops,
obscure
scenario,
as
the
receiver
cannot
judge
if
it
is
okay,
so.
J
A
D
Okay,
so
when,
when
we
summarize
a
prefix,
it
loses
a
bunch
of
information
right
details,
so
one
is
the
untreachability
information.
Similarly,
you
also
lose
the
metric
information,
so
one
of
the
very
common
techniques
that
is
used
to
drain
the
traffic
from
nodes
is
to
set
the
node
to
overload
and
then
advertise
High
metric
which
which
informs
the
other
PE
that
to
remove
that
node
and
choose
another
PE
to
send
the
traffic.
D
So
this
functionality
is
also
lost
when
you
summarize,
because
you
can
no
longer
send
the
metric
for
this
particular
higher
metric
for
this
particular
PE
C.
So
what
I'm
going
to
say
is
there
are
more
use
cases
which
arise
out
of
the
summarization
that
today
or
in
future,
will
need
to
be
solved,
and-
and
we
also
need
to
look
at
how
we
are
going
to
solve
those
when
you
know
so-
have
a
single
mechanism
to
solve
all
these
kind
of
use
cases
instead
of
looking
at
them
one
by
one.
J
D
Oh
yeah,
so
there
is
a
difference
right.
A
planned
maintenance
is
different
from
you
know,
unreachability.
If
you
are,
if
the
node
really
goes
down,
you
probably
want
to
trigger
bgp
pick,
but
if
it's
a
planned
maintenance,
all
you
want
to
do
is
in
your
bgp
best
part
selection.
You
just
want
to
cost
out
this
particular
PE
right.
So
there
is
a
difference.
It's
not
the
same!.
J
Okay:
well,
if
you
have
a
any
idea:
I'm
I'm,
All,
For
You,
that's
a
generic
solution.
I
we
are
here.
We
are
really
trying
to
fix
a
particular
use
case.
You're
right.
If
you
have
a
like
something
more
generic
that
we
can
use
I'm
all
for
it.
A
Yeah
and
that
was
Tony
Tony
P's
Point
as
well
right,
it's
like
it'd
be
nice.
If
we
could
solve
this
kind
of
the
right
way
right,
instead
of
just
well
anyway,.
J
A
B
J
Be
better
to
no
really?
No!
No,
if
you
go
over
the
draft,
there
are
sections
from
the
Bose
spherical
specification.
A
J
Time
all
right,
so
this
is
just
a
very
quick
update
on
the
reverse
affinity
on
behalf
of
the
quarters.
So
it's
the
next
slide,
so
this
has
been
presented
in
the
interim
I
guess.
During
that
time
the
I
actually
got
the
feeling
that
people
kind
of
acknowledge
that
it's
really
the
useful
use
case
that
we
are
trying
to
solve.
J
It's
a
very
simple
extension:
adding
the
exclude
include
and
include
all
Rivers
Affinity
sub
tlb
to
the
fat
and
then,
accordingly,
the
rules
in
the
in
the
calculation,
where
we
are
basically
doing
exactly
the
same
thing
as
we
do
with
the
regular
affinities
in
the
forwarding
Direction
next
slide,
so
I
haven't
received
any
other
comments
or
we
haven't
received
any
other
comments
on
the
list.
They're
always
welcome.
For
me,
this
is
a
very
straightforward
extension
and
we
can
just
adopt
it
and
work
on
it.
I
really
don't
see
why
we
need
to
wait.
A
Yeah,
maybe
I
was
overly
worried
all
right.
Thanks
Peter,
it
doesn't
look
like
anybody's
getting
in
the
queue
so
yeah.
M
A
Please
read
the
document
and
I
guess
we'll
have
to
decide
if
we
do
an
adoption
call
or
not
right.
F
Speaking
is
working
group
chair,
we
have
some
I
know
we
have
some
Doc
I
know
a
lot
of
you
were
in
the
interim
that
we
had
between
IET
F1,
14
and
115.
We
have
some
adoption
calls
from
that.
A
O
O
Next,
please,
this
is
a
syllabus
for
today's
presentation.
Okay,
next
test
slide.
O
Next
place
as
Dynamic
routing
particles
highs
as
an
ospf
are
widely
used
on
live
networks.
Motor
route,
import
between
igp
instance
is
often
involved
in
networking
Solutions.
However,.
O
Restrict
auditing
policy
and
always
needed
it
for
this
scenario,
for
example,
the
figure
show
in
the
in
the
slide
when
military
root
import
happens
among
more
than
two
ADP
instance
shown
in
as
the
picture
there
will
be
multiple
routers
as
router
C
and
router
G.
They
will
import
the
same
prefix
1.1.1,
for
example,
from
two
different
igp
instance,
which
is
easy
one,
and
it
is
three
they
both
import.
The
prefix
to
the
to
the
ass
to
precise.
O
O
Otherwise,
you
know
human
almost
make
this
when
the
routing
policy
configured
wrong,
the
routing
Loop
may
occur
and
the
cost
critical
network
problems.
So
we
make
this
draft
to
learn
away,
help
LGB
interns
to
find
out
whether
a
prefix
it
will
import
from
other
instances
is
already
being
advertised
or
redistributed
by
itself.
Another
slight
place.
O
If
the
ADP
instance
could
recognize,
the
route
has
already
been
redistributed
by
itself
when
it
tried
to
import
a
route
from
others.
The
root
will
knows
that
there
might
be
routine
Loops,
because
you
consider
instance,
report
prefix
again
and
therefore
we
propose
a
new
sub-service
in
the
draft
to
support
a
advertised,
IP
version,
4
and
I
believe
6
prefix
extend
attribute
flags
and
a
list
of
source
root.
Id
of
the
routers,
which
has
redistributed
the
prefix
net
slide.
O
Foreign
as
the
slide,
we
named
this
sub
Theory
as
prefix
redistribute
list
sub
Theory,
and
it
will
be
advertised
as
an
optional
sub
Poe
of
towers,
135
to
35
to
36
and
237
in
is
ISS
LSP
shown
us
the
show
and
the
trophy
feature,
the
prefix.
The
type
value
of
this
sub
tailway
will
be
10
and
the
length
of
the
type
field
and
lens
field
are
both
one
batch.
The
value
field
start
with
one
bad
prefix
is
turned
attribute
Flags.
O
O
That
means
plan
how
the
flag
is
for
a
given
sub
theory
in
one
eyes
as
LSP
when
the
S
black
is
set,
the
prefix
has
been
redistributed
by
the
router,
which
generated
the
LSP,
that's
the
meaning.
When
the
r
flag
is
said,
the
prefix
has
been
redistributed
by
other
routers
other
than
the
router,
which
generates
the
LSP
and
after
one
bad
flag,
a
list
of
root
ID
will
be
presented.
Each
other
ID
will
be
6
by
ISS
system
ID
and
all
the
router
ID.
O
We
make
some
explain
and-
and
we
will
address
it
here-
we
received
some
comments-
say
that
root
important,
not
only
between
Isis
instance,
but
also
between
ISS
and
ospf.
O
It
may
be
changed
for
further
extensions
to
to
be
more
extendable.
It
can
be
any
it
can
be
the
root
ID
from
any
protocol
to
to
solve
much
more
scenario,
problems
Nest
a
Nestor
slide.
Please,
and
also
we
denote
Aid
ospf
session
in
the
draft.
O
N
Tony
PG
repair
Zach
can
make
it
one
sentence.
We
should
very
most
definitely
not
do
it,
and
if
you
want
two
more
minutes,
then
I
can
give
some
clue
dispensing.
Otherwise
it's
you
know
the
comments
like
kill
it
as
quick
as
possible.
A
Yeah
that
was
also
expressed
by
Less
on
the
list.
N
N
Dispense
so
it's
just
exceedingly
bad
Network
design
in
99.9
of
the
cases.
So
if
you
need
those
prefixes
to
be
around
you'll
build
a
hierarchical
igp
and
if
you
run
out
of
hierarchical
igp,
then
in
99.9
of
the
cases
you
should
go
and
segment
it
via
bgp,
okay,
yes,
you
should
well.
Otherwise
you
start
to
build
a
distance
Vector
protocol.
On
top
of
this
whole
thing,
you
know
I
develop
if
IDR
lets
us
do
that,
and
then
we
start
to
invent.
N
N
So
we
are
piling
an
enormous
amount
of
complexity
into
the
protocol,
okay,
which
will
have
a
very
hard
time
to
standardize,
and
it
will
be
almost
impossible
to
deploy
right
because
there's
no
way
any
of
the
stuff
will
be
backwards
compatible
with
all
the
routers
and
buggy
versions
will
lead
us
down
the
bgp
path
right,
20
years
of
trying
to
you
know,
maneuver
the
whole
distance,
Vector
or
actually
you
know,
will
drag
the
attributes
around
with
us
on
top
very
quickly.
Okay,
all.
F
Speaking
as
working
group
member,
this
I
agree
with
everything
Tony
said
and
I
just
wanted
to
say
that
you
know
this.
Is
this
the
way
the
giraffe
is
written?
It
doesn't,
you
know,
routers,
don't
work
that
way.
You
distribute
routes
through
the
Rev
and
only
the
active
routes
get
leaked
between
protocols.
You
don't
have
any
direct
instance
to
instance
product
that
would
be
broken
to
do
that.
F
Right
now,
I
have
I,
have
had
networks,
not
with
one
end,
not
with
three
instances
in
a
row,
but
with
two
instances
when
we've
had
ospf
networks
due
to
acquisition
or
combined
and
at
the
boundaries,
there
is
already
a
tag.
It's
in
all
the
Yang
model.
I,
don't
think
it's
it
was.
It
was
it's
mainly
a
bgp
I
guess
it
is
in
the
protocols
as
well.
F
It's
in
all
the
protocols
there's
already
a
tag,
that's
advertised
and
what
you
do
is
you
use
that
tag
to
keep
to
keep
the
mutual
redistribution
working
from
from
redistributing
routes
that
have
come
from
one
instance
into
another?
That's
commonly
known.
It
works
not
only
between
protocols.
It
works
between
I
mean
between
Protocols
of
the
same
the
same
type.
It
works
between
all
types
of
protocols
and
static
routes
or
whatever
that
are
our
average
re-advertised
in
igp.
O
Right,
but
we
try
to
solve,
is
when
routine
Loop
happens.
I
B
A
J
So
I'm
just
going
to
probably
repeat,
redistribution
happens:
Tony
I
wish
it
doesn't.
People
use
it.
I
I
agree,
but
it
does
happen.
So
the
problem
is
valid,
but
the
solutions
are
there
that
are
existing.
We
have
mechanics
and
protocols
and
on
implementations,
I.
Don't
think
we
need
this
stuff.
Thank
you.
E
A
A
H
Okay,
thank
you
hi.
This
is
Leanne
from
Channel
mobile
I'm,
going
through
talking
about
the
topic
of
advertising
unreachable
links
in
our
spive
next,
please.
H
And
this
is
the
zero
zero
version
of
the
draft,
but
the
requirement
has
been
discussed
in
the
interim
meeting
in
September
and
as
discussed
in
the
interim
meeting.
There
are
some
requirements
to
Edward,
Heights
and
reachable
links
in
the
base
algorithm
of
igp
to
avoid
the
building
the
normal
shortest
path
tree
and
for
ospi,
for
the
current
executing
mechanisms
cannot
meet
this
requirement.
H
A
H
Okay-
and
this
is
the
initial
scenario
of
the
problem-
since
it's
not
only
related
with
the
flex
algo,
but
here
is
just
a
typical
example
when
the
flux
Echo
is
applied
to
the
network
slice
solution
from
this
topology
based
on
the
default
algorithm,
the
right
links,
which
is
the
sub
interface
with
dedicated
bandwidth
resources,
it
is
used
by
the
flex
algo128
and
it's
newly
deployed
for
Network
slides.
H
H
And
this
is
the
current
situation
of
the
maximum
link
metric
in
ospf
for
the
hours
they
one,
two
four
seven
defines
that
it
is
unreachable,
but
when
the
I
would
say
one
five,
eight
three
updates
that
is
reachable
and
from
the
current
implementation
of
most
devices,
and
they
are
based
on
the
version
of
the
RFC
2328
and
a
link
with
the
maximum
link
metric
is
treated
as
the
literature
book.
So
to
reduce
this
problem,
extensions
or
updates
for
SPF
is
required.
H
This
structure
proposed
the
two
solutions
for
the
problem.
This
is
the
first
solution
solution,
a
it
leverage
the
existing
mechanism
as
much
as
possible,
treat
the
maximum
link
metric
as
unreachable.
H
Using
this
solution,
the
backwards
compatibility
should
be
guaranteed,
or
else
there
will
be
routine
Loops.
For
example,
the
metric
for
each
link
is
is
shown
as
the
falling
figures
and
the
router
a
trade,
the
link
d2i4
as
reachable,
but
the
router
B
treated
as
unreachable,
so
there
will
be
routine
Loop
between
a
and
b
next.
Please.
H
To
avoid
the
loop,
all
the
routers,
Through
The
Negotiator
function,
functional
capabilities,
so
a
new
picture
is
proposed
based
on
the
current
mechanism,
which
is
describe
the
in
the
RFC
7770,
so
the
new
beta.
We
just
call
it
m
to
Ambit,
and
it
is
newly
added
to
indicator
that
the
routers
support
the
new
filter
and
the
maximum
link
metric
should
be
treated
as
unreachable
during
normal
sphere
of
computations.
H
If
there
is
any
router,
that's
not
as
voltage.
So
all
the
routers
should
recalculator
the
SPF
to
trade.
The
maximum
link
metric
as
reachable
this
describes.
The
maximum
link
metric
can
be
extended
to
the
following:
tra
or
lsas.
The
router
LC
and
ospre2
extended
link
Tri
and
the
router
link,
Trio
or
splvis
3
utility.
H
F
As
working
group
member
I
thought
about
this
and
I
guess,
either
solution
would
work
as
long
as
we
have
the
capability
and
don't
use
it.
The
it
would
be
nice
if
we
use
the
capability
just
to
use
the
same
thing
that
isis
uses
with
the
max
Network
I
know.
If
you
didn't
have
the
capability,
you
can't
just
start
using
it,
because
many
implementations
use
the
reference
bandwidth
to
compute
the
network
network.
So
if
there's
an
outlier
link,
that's
very
slow,
it's
going
to
have
Max
metric
and
all
of
a
sudden.
F
These
would,
if
we
change
this
without
the
capability.
All
of
a
sudden,
these
links
would
start
actually
that's
a
reason
not
to
use
it
even
if
they
support
it,
because
these
links
are
these
links
are
going
to
be
Auto
configured
to
Max
metric
just
the
way
again
it
was.
It
was
done
for
convenience,
but
anyway,
I
think
I.
Think
if
we
were
to
use
max
metric,
we
need
to
put
a
note
in
there
that
you
should
not
ever
use
max
metric
when
using
reference
bandwidth.
That's
all
I
was
going
to
say.
F
G
As
a
working
group
participant
yeah
I
mean
I
I
got
that
it's
like.
If,
if
you
use
max
metric
for
this
signaling,
then
you,
if
you
actually
want
to
Signal
a
metric,
it
has
to
be
topped
out
at
Max
metric
minus
one,
which
I
think.
Basically,
it's
like
the
the
two
solutions.
Either
one
would
work
it's
sort
of
unfortunate.
G
We
have
to
go
there,
but
you
know,
given
that
there's
one
solution
that
requires
you
to
treat
Max
metric
in
this
new
and
special
way
and
the
other
solution
just
creates
a
distinguished,
don't
use
this
link
and
it
doesn't
try
to
reuse
an
existing
field.
You
might
as
well
go
with
the
one
that
has
fewer
knock-on
effects,
so
meaning
solution.
Number
two
seems
like
less
of
a
pain
to
me.
Thank.
L
So
I
I
had
a
comment
about
the
capability.
Part
I
would
suggest
the
authors
to
look
at
RFC
the
ospf
host
bit
RFC,
it's
8770
on
how
to
handle
this
kind
of
things
which
affect
the
SPF
and
I
I.
Think
the
draft
needs
work
in
that
direction.
Rfc
8770
thanks.
E
D
I
was
just
thinking
there
could
be
alternate
ways
that
can
be
done
locally
right,
I
mean
because
you
don't
want
to
use
it
in
the
default
topology
you
advertise
maximum
trick
for
the
in
the
default
topology,
so
the
traffic
would
always
use
alternate
paths
which
are
lower
metric
and
if
there
are
no
alternate
paths,
traffic
would
still
get
steered
to
this
node.
Through
this
link,
and
which
I
mean
you
can
have
local
rules
on
that
router
to
drop
the
traffic,
because
if
there
are
no
other
paths,
you
simply
want
to
drop
right.
D
H
H
So
if
the
cost
is
much
more
smaller
than
the
default
topology,
the
traffic
will
be
zero
to
this
step
interface
better.
D
Yeah
I
I
get
you
get
your
case.
I
mean
the
the
flex
I'll
go
can
can
use
a
different
metric
type
right
which,
which
will
have
a
lower
metric
for
this
these
links
and
then
traffic
will
get
the
flex
I'll
go.
Traffic
would
get
steered
on
these
links,
whereas
the
default
you
can
default
will
use
igp
metric
right.
You
keep
igp
metric
High
metric
on
these.
H
D
H
C
C
Okay,
while
we
extension
rgp
for
the
flow
Sparkle
flow
server
is,
as
you
know,
is
used
for
the
traffic
filter
and
details
and
digitals
like
this
to
protect
the
network.
Normally
EGP
is
used
to
just
manage
the
flows
background,
and
this
should
protocol
rules
between
the
PE
and
and
but
for
some
in
some
scanner.
The
attacker
is
to
the
attack
to
the
attack
to
other
C.
So
if
we
close
to
the
source
patch
the
production
and
block
the
traffic
as
early
as
possible,
it's
better
okay!
C
Next
and
another
scenario-
is
in
some
Network
there's
no
PDP
deployment,
so
just
actually
is
used
like
the
campus
Network,
so
but
in
this
network,
so
the
attacker
is
also
exist,
so
RTP.
It
needs
to
distribute
the
first
packages
to
the
other
routers
and
to
protect
the
network.
Okay.
Next
and
also
in
this
scenario,
the
traffic
analysis
is.
C
The
attacker
is
in
time
to
say
yes,
so
people
use
EP,
we
need
to
just
can
distribute
the
flows
background
to
the
P2,
but
the
C2
Hunter
got
the
information.
So
if
we
use
the
IDP,
the
rules
can
distribute
to
the
C2
and
we
can.
We
can
and
block
the
attacker
at
the
C2.
Okay.
So
that's
why
we,
you
mentioned
the
igp
of
the
Earth.
C
So
when
you
spending
the
ospf
for
an
easys
for
the
first
pack
for
this,
we
Define
a
new
job.
That's
the
First
Bank
distribution,
and
this
skill
will
have
the
format
of
the
of
the
mental
way
of
the
disease
and
we
add
a
flag.
Io
is
to
to
identify
as
a
control
lithium
between
the
levels
of
this
Cuba,
and
this
theory
has
have
two
subject
of
it
and
some
something
always
in
the
flat.
C
One
is
the
prospective
filter,
and
why
is
the
flow
spot
action
also
the
same
as
defined
in
five
five
percent,
seven
five,
and
also
as
a
result,
information
I
would
say
we
add
the
flow
spark
habit
through
other
advances.
C
Of
the
router
okay,
all
right
next
so
also
V3,
we
maybe
we
will
Define
a
new
outside
to
carry
the
prospect
of
it,
and
this
Theory
also
have
two
sub
theory
of
our
filter,
spark,
filter
and
Prospect
action
and
the
same
as
fc575,
and
also
the
flash
for
Community
we
used
and
for
us.
Therefore,
maybe
we
can
transport
this
information
or
use
the
also
GT
like
this?
Okay,
that's,
oh
I
have
registered
all
right.
A
C
A
This
will
be
me
speaking
as
working
group
member.
This
is
you're
configuring,
your
firewalls
with
your
igp
I
I
mean
this
is
just
not
something
that
we
should
be
using
our
routing
protocol.
For
you
know
you
have
a
traffic
analyzer.
It
should
be
using
your
network
management
tools
to
configure
your
routers
right.
I
mean
the
I
understand
that
bgp
is
a
dump
truck
and
everything
goes
in
it
and
I
also
understand.
A
There
might
actually
be
a
reason
for
it,
because
you
know
you
might
want
to
be
giving
this
information
to
another
administrative
domain.
But
that's
not
the
case
here.
This
we're
talking
igps,
it's
the
same
administrative
domain,
yeah.
So
there's
there's
no
point
of
that.
You
did
bring
up
this
ce1
to
ce2
case,
but
that's
insane
right,
I
mean
no.
No
provider
is
no
cost.
You
don't
have
Microsoft
configuring,
Google's
routers
right,
that's
just
not
gonna
happen.
A
Yeah
I
yeah
I
should
have
just
picked
two
better
competitors
but
yeah
like
anyway,
that
that's
my
comment
as
a
as
a
working
group
member
I'll.
Let
some
other
folks
talk
now
less.
P
Yeah
so
I
agree
with
Chris
I
think
this
does
not
belong
in
the
igps,
I
think
from
a
presentation
point
of
view.
It's.
It
was
very
nice
that
we
that
we
started
with
the
ospf
generalized
transport
and
ended
with
this
flow
spec,
because
if
you
were
going
to
put
this
in
the
igp
at
all
the
the
generalized
transport
or
in
the
case
of
Isis
gen
app
would
be
the
only
way
to
do
it.
I'm
not
real,
enthusiastic
about
that
either,
but
this
certainly
doesn't
belong
in
the
rubbing
instance
of
the
igps
thanks.
A
Thanks
class
Jeff.
E
Has
so
I
agree
with
the
other
discussion
points
about
this
probably
belongs
and
something
like
the
generalized
transport
just
to
get
it
out
of
the
igp
I've
looked
at
the
encodings
I
spend
a
very
large
amount
of
time
working
through
flow
spec,
both
in
IDR
and
in
Juniper's
implementation.
Your
encodings
are
clean.
This
would
work.
The
one
point
I
ask
you
to
consider.
You
know,
have
further
discussion
specifically
in
the
igp
context.
Aside
from
the
use
cases.
M
E
E
My
impression
is
that
you
really
don't
want
to
put
two
to
three
k
worth
of
State
into
an
LSA
yeah.
It
gets
a
little
cranky.
C
F
Linda
speaking
as
a
working
group
member,
the
one
thing
I'm
wondering
let's
say
we
were
to
do
this
in
gen,
app
and
generalized
transport,
and
we
were
to
do
this.
Could
we
just
get
away
with
not
having
to
redefine
the
the
flow
spec
and
to
just
use
the
vgp
definitions
rather
than
you?
You
cannot,
okay,.
E
Jeff
has
again
so
the
the
document
you
have
is
very
close
to
the
bgp
flow
spec.
That's
great
you're,
actually
taking
some
of
the
lessons.
I
have
to
look
at
the
codings,
make
sure
that
psept
did
when
they
decided
to
do
something
very
similar
and
use
flow.
Spec
encoding
rules
to
carry
flow
specs
into
psap.
E
There
are
bugs
in
the
existing
RFC
for
refer
for
flow
spec
for
extensibility
I.
Think
you
may
have
avoided
it
by
using
something
close
to
psip.
I
have
to
double
check.
E
I
urge
you
to
pay
attention
to
the
flow
spec
V2
work,
that's
going
to
be
happening
in
IDR,
we're
picking
up
heavy
steam
right
now,
because
that's
going
to
change
a
number
of
things
about
how
flow
spec
works,
so
you're
you're
chasing
the
try
to
get
up
to
what
flow
spec
currently
can
do,
rather
than
potentially
where
it
should
be
going.
But
in
terms
of
encoding,
your
flexibility
is
about
where
it
needs
to
be
the
changes
to
get
to
safety.
That
psap
has,
if
you
haven't
done
them
already,
is
very
small.
G
A
You
yeah:
let's
talk
about
I'll
just
mention
we
do.
We
did
have
an
item
that
we
were
thinking
about
putting
on
here,
which
was
the
multi-part
tlv
discussions
that
have
been
going
on
and
and
Tony
and
and
Les.
Both
have
a
you
know,
I
think
they
might
have
worked
on
some
slides,
but
I
think
we're
going
to
do
an
interim
on
that.
A
We're
gonna
also
I'd
like
to
get
more
solutions
based
I
I
mean
just
personally
as
a
working
group,
member
I
I've
got
an
idea
of
what
we
should
do
and
I
you
know
me
and
AC
were
just
talking
on
the
side
and
I'd
like
to
get
that
out
on
the
list,
and
then
you
know
and
then
have
a
meeting
to
sort
of
find
finalize
the
decision
on
what
we
should
do
there
I,
don't
I,
don't
want
to
be
unfair
and
present
my
position
since
we
didn't
give
the
other
people.
F
Speaking
is
work
speaking
this
working
group,
member
yeah,
I'm,
really
I'm,
really
hesitant
since
I.
You
know
much
more,
have
much
more
experience
with
ospf
than
Isis
to
inject
what
how
I
think
it
should
work.
In
the
meantime,
we
have
found.
There's
lots
more
deployed,
implementations
than
we
originally
I
may
not.
I've
talked
to
other
other
people
and
they
they
yeah.
A
A
I
have
yes,
okay,
all
right,
so
it
would
have
been
nice,
like
I
was
really
hoping
that
those
vendors
would
have
spoken
up
on
the
list.
If
you
still
could
like
I
I
mean
this,
isn't
a
secret
right,
we're
talking
about
making
the
internet
work
right,
it'd
be
nice
to
know
who's
implemented
a
network
breaking
functionality.
A
You
know,
and
you
wouldn't
be
the
first,
so
I
don't
know.
Maybe
you
don't
want
to
admit
it
anyway?
That's
it.
Unless
anybody
else
has
some
open,
an
open
topic
they
want
to
discuss.
We
do
have
a
few
minutes
left.