►
From YouTube: IETF-IDR-20210823-1400
Description
IDR interim meeting session
2021/08/23 1400
A
A
A
This
is
a
note.
Well,
you
should
note
the
information
if
you've
not
had
been
to
an
idr
meeting
or
another
meeting
in
itf,
you
should
realize
that
we
all
work
under
the
note.
Well
at
that
point,
the
agenda
is
on
the
web
page
and
I'm
going
to
go
directly
to
sharing
our
first
presentation
by
june,
which
is
an
update
and
a
discussion
now
as
an
interim
we're
trying
to
have
a
good
discussion,
there's
a
a
great
deal
of
time
set
out
for
discussion.
A
D
D
D
D
D
D
D
D
D
The
difference
is
at
the
excess
of
vpn
route
is
from
one
key
that
located
in
another
s,
this
excessive
vpn
load
will
be
distributed
by
the
sbr
and
the
input
p
in
another
s,
so
based
on
the
previous
procedure
after
this,
if
we
take
the
example
for
the
excessive
vpn
from
p3,
that
is
from
the
vpn
and
vpn
2.
and
the
based
on
the
previous
describe
the
procedure,
the
p1
will
send
the
rtos
message
with
rd
said
rt31
and
the
p2
will
send
two
rd
of
message.
D
D
D
D
We
have
made
the
get
the
conclusion.
The
rd
information
is
enough
for
starting
mechanism.
We
need
not
to
include
the
rt
information
within
the
control
message,
because
the
same
rta
may
be
imported
by
several
vrs
and
really
one
key
device.
Rt
cannot,
uniquely,
I
identify
one
vpn,
but
rd
can
accomplish
this.
D
C
C
So
the
big
problem
that
we've
seen
in
the
discussion
about
this
problem
in
solution
space-
I
I
think
the
problem
space
is
understood
pretty
well
at
this
point,
the
desire
is
that
when
a
pe
is
overloaded,
it
wants
some
way
to
basically
tell
the
network
stop
sending
me
stuff.
I
will
not
be
able
to
process
where
we
have
a
breakdown
in
the
problem
versus
the
solution,
so
here
in
scenario
one
we
have
a
solution
that
I
think
it
works
out.
C
Okay,
it's
possible
for
a
pe
to
tell
the
router
that's
sending
it
that
locally,
it
can't
handle,
know
some
set
of
vpn
routes.
That's
coming
in!
Please
stop
sending
me
these
for
now.
I
think
this
piece
is
easy
and
understood
where
we
start
running
into
problems
and
each
of
the
layers,
as
we
start
moving
further
and
further
towards
trying
to
propagate
this
source
is
two
issues.
C
They
don't
have
any
stickiness
aside
from
that,
and
that
means
that
trying
to
trigger
these
things
in
a
transitive
fashion
can
leave
us
with
problems
about
you
know
how
do
we
choose
the
graph
that
we
distribute
this
along?
This
is
a
point
that
I've
pressed
on
a
few
times,
and
the
scenario
before
that
you
show,
as
an
example,
has
a
very
simple
network
without
any
loops,
so
just
trying
to
figure
out
how
does
the
distribution
actually
happen
in
a
safe
fashion
is
going
to
be
one
of
the
challenges
and
this
ties
into
you
know.
C
The
request
in
the
proposal
do
not
clear
these
things
without
manual
clears.
How
do
you
start
distinguishing
a
manual
clear
condition
for
the
originating
device
for
the
rf
versus
somewhere
in
the
middle?
So
there's
some
concern
about
getting
us
stuck
into
a
state
where
we
really
can't
clear
an
rf,
because
it's
not
tied
to
routing
state
of
some
sort.
D
C
C
D
A
F
Even
before
we
look
at
the
solution
of
rdo
rf,
I
want
to
know
how
do
we
determine
that
this
route
that
we
receive
from
p4
excessive
route
is
excessive
or
is
not
needed,
and
therefore
we
should
send
the
rdo
rf
what
if
we
had
heard
a
prefix
unwanted
prefix
early
on
that
made
us
fill
up
our
number
to
reach
the
maximum
limit
and
therefore
are
we
is
the
mechanism
being
built
to
detect
the
right
problem?
So
I
want
this
is
my
question.
D
F
Your
voices
got
a
little,
you
know
couldn't
be
wasn't
clear
towards
the
end,
but
I
think
I
got
the
gist.
I
still
have
a
question,
so
what
problems
are
we
trying
to
solve
again?
This
is
more
of
a
clarification
question.
If
I
have
a
policy
on
the
on
the
local
router,
which
will
look
for
the
maximum
number
of
prefixes
and
therefore
I
won't
exit
beyond
the
number.
F
A
D
A
D
E
C
E
G
Okay,
I
have
a
two
comments.
The
first
comment
is
it's.
Basically,
I
would
like
to
echo
what
srihari
and
kyo
just
said.
Basically,
I
I
feel
that
it
is
okay,
if
you
want
to
define
a
vpn
based
on
the
rte
in
one
network,
one
domain,
but
it's
very
difficult
to
do
to
to
do
the
coordination
when
one
specific
such
definition
stands
for
multiple
networks.
That
is
multiple
ess,
so
that
you
know
some.
Sometimes
this
the
effort
for
coordination
may
not
be
practical.
G
Second
question
is
this:
I
think
in
general,
I
think
guys
we
have
learned
and
also
established
the
con.
The
the
concept
has
been
established
for
many
years
in
general,
we
can
apply
early
policy
across
the
epdp
boundary,
but
it
is
in
general
not
safe
to
apply
policy
the
filters
across
rbdp
because
in
general
ibtp
needs
to
be
consistent
right
here.
So
that's
the
general
question.
That's
why
it's
a
general
comment.
That's
why
it's
always
very
difficult.
G
If
you
say
you
know,
due
to
memory,
always
resource
constraints,
you
want
to
filter
some
rods.
You
know
accept
some
but
reject
others
or
rbtp
boundaries.
That
has
been
very
difficult
to
do,
regardless,
whether
you
use
vi,
you
use
oif
or
you
use
some
any
other
type
of
filtering.
It's
really
a
it's
a
very
challenging
problem.
I
so
far
I
can.
I
really
see
a
good
solution
say
you
know,
filtering
or
at
least
say:
okay.
G
It
is
safe
to
filter
ibdp
boundaries
because
in
this
particular
case,
when
I
look
at
the
diagram
you
say
the
p1
is
actually
interested
in
the
rush.
You
know
that
belong
to
particular
vpn.
It's
it's
different
from
the
case
say:
okay,
this!
This
p1
has
no
overlapping
raw
target.
It's
not
interested!
That's
why
it's!
They
don't
want
it
if
they
don't
want
it
in
the
first
place,
then
it's
okay
to
to
to
basically
filter
them
out.
D
D
You
know,
so
we
cannot
use
the
rtc
mechanism
because
rtc
mechanism
all
will
filter
the.
I
increase
the
vpn
based
on
the
business,
the
the
overall
plan,
so
the
rdo
message
is
to
filter
the
accessible
but
interested
vpn
yeah.
But
if
we
do
not
control
such
excessive
increased
vpn,
then
the
process
of
such
load
will
influence
the
performance,
rv
rvi
on
the
assembly,
70
device
or
some
sdr
device
under
the
the
accessible
vpn
load.
D
A
A
D
D
D
So
it
will
send
out
safely
the
rdf
message
to
sbr2
with
rtc2
rd
c1
but,
for
example,
for
the
rt
tool
only
p2
send
out
such
message
and
on
our
pure
ib
gpr,
for
example.
Piva
does
not
send
out
such
message,
so
sbr
will
filter
the
vpn
router
that
with
rd7rd
tool
locally
and
you
it
will
not
send
out
rd
of
message
with
rgb72rd72
rd2,
it's
clear
for
the
to
describe
the
mechanism.
D
A
G
So
my
my
question:
oh
my
comment
is
really
it's
more
general.
It's
a
general
question.
It's
not
about
specific.
This
wire
based
mechanism
is
in
the.
In
this
case
I
mean
you
guys
must
have
remembered
discussion
about
the
max
prefix
feature
right
across
the
epdp
boundary,
although
it's
a
safe
to
apply
policy
say
to
drop
the
update
for
early
prefixes
or
elemental,
but
in
practice,
actually
it's
it's
very
difficult
to
design,
because
then
it's
a
the
issue
is
this
which
one
which
one
in
some
cases
you
know
not
all
the
right.
G
Rather
I
are
equal
in
some
cases.
It's
the
one
right
is
more
important
than
the
others.
Now
then,
it
comes
to
the
discussion
of
okay.
Really
when
you,
when
you
exceed
the
maximum
prefix,
which
one
do
you
drop?
Obviously
you
want
to
drop
the
one
that
is
less
important
to
you
right,
but
that
varies
from
one
customer
to
another
right.
G
So
that's
that's,
although
in
general,
it's
safe
from
protocol's
point
of
view
from
the
correct
listed
point
of
view
correctly,
it's
of
the
protocol
operation-
it's
you
know
it's
safe
to
do
across
the
ebdp
boundary
to
do
the
max
prefix,
and
but
it's
it's
it's
not
easy.
It's
not
the
easy,
there's,
no
easy
solution
to
say
which
one
to
drop.
On
top
of
that,
I
think
that
that
that
question
that
issue
exists
in
this
particular
case
as
well.
G
In
addition,
here
we
are
talking
about
applying
policies
to
rdtp,
to
filter
out
some
of
us
that
this
local
rather
is
actually
interested.
So
that's
another.
I
think
a
big
question
for
me:
it's
not
clear
how
you
can
do
it
safely
in
general.
It's
not
it's
not
about,
say,
okay.
Why?
If
this
is
how
I
will
treat
it?
It's
really.
G
I
think
the
first,
perhaps
the
first
as
as
true
as
who
was
alluded
to
it's
really
the
definition
say:
okay,
the
marking
comes
next
at
the
second
step,
but
the
first
step
is
the
definition.
How
do
you
decide
which
rdo,
which
vi
of
runs
to
drop
right?
That's
not
easy!
It's
it's!
Just
like
the
case
when
we
are
short
on
memory,
or
rather
what
do
you
do?
C
A
H
H
Yes-
and
there
are
some-
there
are
some
basic
terms
and
mechanisms
should
be
declared
at
first,
the
draft
itft's
enhanced
vpn
specifies
the
framework
of
enhanced
vpn
and
describes
the
candidate
components
technologies
in
different
panels
and
layers.
The
definition
of
vtn
is
introduced
in
this
draft.
Ovtn
is
a
virtual
android
network
that
connects
his
customer
age
point
with
capability
of
providing
isolation
and
performance
characteristics
required
by
an
enhanced
vpn
customer.
H
H
H
H
H
The
shortest
path
computation,
the
centralized
network
controller,
needs
to
distribute
the
resource
of
viruses
and
the
and
the
and
and
the
results
attribute
in
the
control
plan.
So
so
so
bgpis
is
used
to
describe,
distribute
the
introductory
topology,
the
inter
domain
topology
and
the
associated
key
attributes
of
the
vts
to
the
network
controller
next
slide.
H
Mechanisms
are
introduced
in
this
document.
The
first
one
is
mtid.
It
is
reused
by
the
control
plan,
identifier
of
vtn.
It
is
assumed
that
each
return
is
associated
with
a
unique
logical,
topology.
The
second,
the
second
mechanism
is
the
intradomain
topology
mtid
trwa
is
carried
in
bgpls,
linked
link
in
our
I
prefix
roi
to
advertise.
The
per
vtan
topology
information,
topology
specific
src's
are
advertised
using
bgplis
srsrv6
extensions.
H
The
third
one
is
the
inter
domain.
Topology
advertised
mechanism,
mtidtly
with
bgpls
ep,
is
used
to
advertise
the
pro
btn
intradomain
connectivity
and
the
topology
specific
peers,
adjacency
piano
acid
and
pierce
acid
mtid
needs
to
be
unified
plan
to
ensure
the
consistency
both
in
each
domain
and
on
the
inter
domain
links
next
slide.
H
H
Certainly,
some
scalability
considerations
are
included
in
this
document.
Each
video
is
associated
with
a
unique
logical,
topology,
independent
topology
or
root
computation
for
each
return
is
needed
when
a
link
of
prefix
participating,
muted,
topologies,
separate
allies
need
to
be
generated
to
advertise.
H
The
link
called
prefix
in
each
topology,
together
with
the
topology
specific
seeds
and
t
attribute.
Therefore,
this
this
may
increase
the
number
of
bgp
updates
advertised
to
the
controller.
As
a
result,
the
empty
based
sr
waiting
mechanism
is
applicable
to
the
network
scenarios
where
we're
a
limited
number
of
atms
as
needed.
H
H
H
A
C
C
A
A
A
I
A
A
A
Okay,
thank
you
if
you
would
send
a
note
to
the
chairs
or
actually,
more
importantly,
send
a
note
to
the
list.
So
we
can
understand
why,
before
we
do
a
working
group
adoption,
okay,
okay,
okay,
thank
you
and
if
you
think
an
answer
is
you
can
provide
a
quick
answer.
While
we
set
up
for
the
next
presentation,
please
go
ahead
anchor.
You
will
be
next
in
just
a
moment.
A
A
G
G
G
It
turned
out
to
be
partial,
but
for
one
reason
or
another
we
didn't
basically
follow
up
for
for
a
long
time
and
recently,
this
from
from
time
to
time,
the
issue
would
show
up
show
up
in
the
field
and
would
see
by
the
customers
and
the
recently
is
this
what
another
incident
say?
Okay,
this
is
not
working.
This
is
a
backup,
static
rod.
So
what
happened?
Then?
I
realized.
Okay,
I
mean
I
did
a
very
poor
job
didn't
finish
the
work
and
the
issue
of
the
issue
actually
has
not
been
addressed
so
the
so.
G
G
So
these
this
the
problem
statement
right,
it's
the
if
you
look
at
currently,
we
have
the,
as
I
think,
conceptually
and
also
I
think,
a
lot
of
implementation
follow
this.
Follow
this
the
idea
as
well.
Basically,
you
have
a
you.
Have
a
rare
writing
information
table
that
severity
aggregates
the
laws
from
different
protocols.
Then
we
have
pdp,
they
do
they
interact
with
each
other,
but
currently,
as
far
as
the
pdp's,
it's
it's
considered,
pgp
spec
is
concerned.
G
We
do
not
actually
there's
no
provision
for
the
correlation
of
the
right
selection,
accuracy
between
rib
and
bdp
rib,
as
everybody
know,
is
basically
you
see
admin
distance,
but
as
a
tie
breaker,
when
you
have
a
when
you
receive
rods
from
different
protocols-
and
I
think
in
some
cases
the
kd
and
juniper
uses
the
protocol
preference
they
are.
Basically,
I
think
they
are
pretty
much
equivalent,
but
admin
distance,
I
think,
is
more
commonly
used
as
a
terminology.
G
G
So
here
the
issue
is
that
when
you
redistribute
the
backup
rod
back
up
radius,
all
right,
it's
determined
by
admin,
distance,
say
one
is
more
preferred
than
the
other.
The
other
becomes
a
backup
right,
and
so,
when
you
redistribute
backup
rather
that
into
bdp,
then
the
long
deterministic
behavior
would
show
up.
Deeply
really
depends
on
the
order
of
the
arrival
of
the
past.
Usually
the
the
past
arrives.
The
first
would
win
and
will
stay
as
as
the
best
versus
you
know.
That
certainly
is
so
it's
it's
inconsistent
with
that.
G
It's
with
the
design
with
the
writing
design
to
treat
it
as
a
backup
right,
and
they
saw
this
in
the
draft.
I
think
this
is
a
basically
the
example.
These
are
really
simple
examples
you
have,
the
the
behavior
would
show
up
all
not
only
a
single
router,
as
it
also
shows
up
when
it's
going
to
when
you
on
single.
Rather
basically,
you
have
the
case
so
for
certainly
you
have
the
you
have
ebdp
rods,
ebdp
rather
or
study.
For
example,
these
two
would
compete
with
each
other.
G
One
is
the
primary
the
other
backup
and
deployed
on
the
ordering.
You
have
income,
you
have
non-deterministic
area
and
they
are
multiple
routers,
certainly
all
multiple
roddies,
more
it's
more
common.
Basically,
you
have
the
primary
pass
on
one
router
and
you
want
to
the
backup
is
on
another
route.
That's
that's
a
typical
case.
It's
the
primary
backup
again
keeping
the
ordering
of
the
past
arrival
and
either
why
water
or
multiple
routers
in
the
network
would
would
end
up
with,
can
end
up
with
a
different
watch
elections.
G
G
So
in
this
esp
in
particular,
I
think
in
the
second
case
the
network-wide
behavior,
when
you
have
a
large
reflector
or
configuration
involved,
the
problem
now
becomes
can
become
more
obvious
right.
So
these
are
basic.
These
are
the
one
issues
it's
because
we
have
one.
I
think
this
in
this
case.
I
would
classify
and
classify
it
as
a
you
know.
We,
when
we
design
protocols,
there's
always
stack
over
specification.
Other
specifications
are
the
right
specification
in
this
case.
It
I
think,
enforced
into
the
category
for
other
space
specifications.
G
G
The
issue
does
not
exist
in
all
the
implementations.
I
think,
as
you
point
out,
the
kd
and
the
junos
or
the
kd
derivatives
yeah.
They
actually
have
taken
care
of
this.
I
think
it's
a
single
router
issue,
because
that's
where
basically,
the
the
admin
distance
or
the
protocol
preference
is
actually
considered
as
very
early
before
you
do
the
and
all
the
other
comparisons
in
pdp,
such
as
local
pref.
So
that
is
that
that's
really
good
news.
That's
consistent
with.
G
So
the
solution
right,
I
think,
the
so
basically,
if
you
can
see
so
for
I
think
that
two
portions
of
solution,
one,
is
on
a
single
router.
So
may,
even
basically,
the
idea
is
to
make
it
consistent
among
all
the
paths
with
no
admin
distance
so
which
are
these,
which
are
these
rods,
or
this
path
basically
is
for
locally
redistributed
one.
G
We
certainly
know,
and
also
for
epgp
learned
and
also
locally
aggregate,
because
the
the
basic
when
we
download
them
into
the
rip
populate
from
pdp
into
repo
we
know
and
or
if
it
comes
it
will
redistribute
us.
It
comes
from.
We
also
know
so
this
basically
we
deterministically
know.
So
in
that
case
it's
just
a
comparison.
G
The
admin
distance
pick
the
basically
most
the
preferred
one
in
bdp
lot
selection.
This
would
be
the
before
the
local
craft.
Comparison
right.
That
way
you
make
it
you
make
sure
bdpi
live,
are
consistent
in
terms
of
locally
originated
locally
sourced
lots
right.
This
is
basically
this
has
been
taken
care
of
by,
I
guess,
from
the
kdr
juno's
derivatives.
G
That's
good!
There's
no
conflict!
I
don't
see
any
conflict
there.
So
it's
the
approach
is
the
same,
so
what
they
that
should
take
care
of
the
single
world.
What
about
this
sort
of
primary
backup
on
two
different
routers
right?
It's
so
this
is
basically
involved
ibtp
rights.
You
really
do
not
know
the
when
you
receive
ibdp.
Rather,
you
really
do
not
know
what
is
the
real
anatomy
distance
of
that
guy
because
it's
already
lost
right.
So
what
do
we
have?
Is
really
the
local
press?
You
know
you
you.
G
Influence
because
this
is
already
available
in
bdp
and
it's
it's
the
best-
it's
propagated
right,
so
we
basically,
if
we,
if
you
know
this,
is
a
backup
plus
it
is
this.
Local
rod
is
supposed
to
be
a
backup
to
another
another
path
from
ibdp,
then
the
local
prep
value
should
be
normal
for
redistributed
backup
right.
So
that's
the
idea
here.
If
you
say
you
have
a
primary
and
backup
two
paths
in
the
network.
That's
pretty
easy!
G
You
lower
it
that
should
take
care
of.
But
the
question
is
this:
is
that
generic
enough?
What
about?
If
you
have
a
primary?
If
you
have
three
paths
in
the
network,
you
have
the
primary
secondary
tertiary.
What
is
the
simple
solution?
So
the
solution
is
still
here.
Basically,
we
propose
in
traffic.
Basically
you
rank
some.
You
say:
okay,
this
is
a
this
is
my
primary
secondary
tertiary
and
you,
then
you
have
applied
offset
to
the
admin
distance
right
because
the
admin
distance,
I
think
several
people
point
out.
It
can't
vary.
G
You
know
multi
the
default
admin
distance
can
vary.
You
know
multiple
in
the
environment
and
that's
okay.
So
what
here
suggest?
The
idea
is,
basically
you,
you
write
some
the
primary
second
tertiary,
the
offset
you
apply,
assign
a
sort
of
log
conceptually
you
assign
offset
secondary,
you
say
offset
is
10.
Tertia
is
20,
for
example,
and
then
you
basically
say
you
assign
the
admin
distance
to
use
whatever
administrations
on
that
rather
locally,
then
plus
offset.
That
would
be
adding
distance
for
that
backup
plot.
And
then
you
got
you.
G
You
can
basically
calculate
your
local
press.
It's
a
default.
You
have
a
default
local
prep,
that's
typically
that
is
common
in
the
network.
Then
this
local
prep
for
this
backup
right
back
up
right.
There
will
be
the
default
minus
the
offset
right.
That
way,
you
order
you
basically
now
the
local
you.
Basically,
this
local
craft
will
reflect
your
intention
for
this.
You
know
secondary
tertiary,
the
past
the
configuration
option
right.
Certainly
it
is
there.
I
think
some
people
are
using
today.
It
can
be
used
to
overwrite
the
automatic
set
next
slide.
G
G
It's
all
about
that.
I
think
there.
It
is
not
clear.
I
want
to
emphasize
really
about
the
default
behavior.
So
that's
why
we
basically
say
we
recommend
the
implementation
of
the
simple
address.
You
basically
make
the
detail,
make
the
default
behavior
deterministic.
I
just
make
it
work
that
way
you
actually
can.
Actually,
in
most
cases
we
will
be
able
to
avoid
the
the
configuration
that
would
simplify
the
network
operation
for
the
for
for
our
operators
right
and
here.
Actually
I
want
to
refresh
the
second
point.
This
slide
differently
use
a
config.
G
You
can
always
use
the
config
right
use
the
config
if,
before
this,
the
address
in
is
implementing
your
software
right
to
achieve
the
desired
desired,
desired,
behavior
and
so
basically
the
he
was
manually,
set
the
weight,
if
applicable,
for
some
implementation.
That
is
the
first
as
a
step
you
move
for
the
local
press,
they
wrestle
in
right
selection
for
some
implementations
actually
for
a
lot
of
implementations
and
also
the
local
press.
That
way,
it's
a
you!
G
If
you
have
a
more
sophisticated
policy,
you
can
always
use
the
user
config
to
override
the
automatic
settings.
So
these
are
coexist
here.
Basically
they
are.
I
want
to
go
a
little
bit
further
because
I
think
we
have
a
little
bit
time.
So,
basically,
if
you
have
an
existing
deployment,
if
you
already
have
a
config,
there's
no
conflict,
because
here
even
if,
let's
say
software
right
now,
software
implement
this
algorithm
and
then
whatever
setting.
We
do,
I
think
it's
a
you
know
as
we
all
know
that,
then
the
configuration
always
overrides
default
behavior.
G
So
if
you
for
existing
deployment,
if
you
use
today,
if
you
for
current,
if
you
use
a
configuration
to
do
the
setting,
there's
no
problem,
there's
no
conflict,
because
the
config
will
will
still
take
over
right.
It's
a
if,
if,
today
you
resell
config-
and
you
are
not
aware
of
this
issue-
it
sometimes
it
works.
Sometimes
it
does
not
it's
non-deterministic.
Now
with
whether
it's
the
aggregates
implement
sulfur,
it
will
just
work,
it
will
become
deterministic.
G
The
fact
you
don't
have
a
config
that
does
not
really
matter
in
this
case
right
and
for
future
deployment.
Let's
say
for
new
deployment
right
once
your
your.
So
rather
software
has
the
implementation.
Then
you
basically
now
become
simpler.
You
don't
need
to
you.
Don't
need
to
set
the
way
to
say
that
the
local
prep
for
for
the
for
the
backup
rod
that
had
been
redistributed.
G
It
will
just
work
right.
So,
if
you
want
to,
if
you,
if
you,
if,
if
you,
if
you
feel
more
comfortable,
you
think
confused,
that's
fine
and
I
say:
there's
no
conflict.
Config
always
you
know
overrides
the
default
behavior
in
the
software,
so
the
flow
right.
The
flow
of
this,
this
rivalry
distribution
right
when
you
apply
policies-
basically,
for
example
local
prep
setting
or
weight
or
this
is
basically
software-
has
a
has
a
setting
default
setting
in
the
implementation.
I
think
the
second
step
right.
The
flow
is
second
step.
G
Is
you
apply
the
configuration?
So
if
you
have
any
configuration
or
you
don't
use
any
configuration,
there's
no
problem.
There's
no
conflict
right!
I
think
that's!
One
of
the
questions
I
think
sue
was
asking
me
before
so
there's
no
conflict,
that's
what
you
can
continue
to
use
config,
if
that's
you
you
prefer,
but
for
for
people,
basically,
who
are
not
aware
of
this
issue
or
who
wants
to
basically
want
to
reduce
configuration.
G
C
The
the
thing
I
think
you're
going
to
run
into
is
an
interesting
problem
is
that
you
know
these
knobs
that
we
have
for
admin
distance
across
all.
The
implementations
have
values
that
been
in
there
for
a
lot
of
years,
and
people
tweak
them
sometimes
a
little
bit.
Sometimes
they
go
through
radical
changes
and
the
critical
thing
is
people
have
made
choices
that
have
consequences
already
in
their
network.
C
C
I
think
what
you're
going
to
find
out
is
a
lot
of
the
current
operators
are
not
happy
with
the
results
they
can
get
from.
What
seems
like
the
obvious
solution-
and
I
think
that's
going
to
push
you
very
rapidly
towards
a
simple
mapping
operation.
You
did
mention
that,
where,
instead
of
doing
math
on
things
you
you
have
map
ability
of
on
this
router,
this
distance
means
that
it
maps
to
you
know
one
of
the
following
values
for
local
pref.
C
G
G
G
G
Yes,
okay,
so
here,
if
you
look
at
it
right,
so
the
these
are
the
goals
right.
It's
really
the
the
behavior
is
not
it's
yeah.
As
I
said
it's
a
partially
addressed
by
some
implementations,
but
it's
not
well
documented,
and
it's
not
also
it's
it's
not
a
well-known.
It's
not
well-known,
and
second
thing
is
this.
Next
slide
is
true.
G
It's
if
you
look
at
basically
because
here
you
know
to
address
it
right,
like
what
kd
and
two
notes
is
done
for
the
single
router
case.
Actually,
that's,
basically,
that
is
the
change
in
the
bdp
based
path,
right,
selection,
accuracy,
it's
really
it's.
If
you
look
at
bdp
spec,
it
does
not
cover
that.
G
So
I
think
one
of
the
jeff's
question
was
why
not
it's
wrong.
My
understanding
is
that
the
moment
touches
ptp
past
selection.
If
you
want
to
do
enhancement,
it
has
to
be
earlier,
so
it's
also.
I
I
used
to
think
I
think
previously
also.
I
think
we
want
to
make
it
informational,
but
it
was
point
people
point
out
say
that
you
know
no,
no,
that's
a
no!
You
cannot
make
it
informational
if
you
want
to
change,
enhance
the
pgp
pass
election
right.
G
The
second
thing
that
is
there
there
are
really
two
poi
two
parts
to
the
to
the
solution.
Why
is
you
say,
making
deterministic
or
a
single
order
just
using
admin,
distance
for
locally
sourced
rust
right
like
what
has
been
done
in
kde
or
in
the
in
junos?
You
basically
say:
okay,
I'm
going
to
look
at
my
admin,
distance
or
protocol
preference
before
compare
local
print.
That's
exactly
what
what
it
is.
I
think
my
understanding
is
that
the
iq1
right,
that's
the
first
part.
Second
part
is
the
network
white
network.
G
As
I
said
today,
if
you
use,
if
you
already
apply
policies,
there's
no
problem.
Okay,
you
will
continue
apply
policy,
but
we
will
just
make
the
default.
I
think
goal
is
basically
make
a
default
work.
Make
default
be
very
deterministic
and
if
you
apply
policy,
your
policy
will
always
take
over.
So
I
I
think
I
have
to.
I
would
like
to
ask
that
a
little
bit
better
from
different
implementations
to
see
the
simple,
the
simple
matching,
why
the
simple
mapping
would
cause
a
problem
right.
G
It's
basically
say:
okay,
based
on
my
admin
testing,
when
I
redistribute,
I
know
it's
a
backup
to
rbdp,
then
the
when
I
basically
convert
that
into
the
local
value
is
there?
Is
there
really
problem
so
for
so
far?
It's
I
think
I
have
not
really
received.
I
have
not
heard
the
example
say
this
will
not
work,
but
I
think
this
will
become.
Of
course
we
have
not.
There
has
not
been
enough
time
for
the
discussion
and
for
the
feedback.
I
think
that's
that's
that's
the
area.
G
G
So
here
what
we
are
proposing
is
really
about
the
default
before
we
make
the
difference
before
we
work
that
you
know
so,
people
that
do
not
need
to
deal
with
this
subtle,
this
kind
of
wanted
to
miss
behavior.
It's
not
always
easy.
You
see
it's
as
I
think.
A
lot
of
us
experience
either
something
works
or
does
not
work.
It's
that's
the
eye.
The
the
work
is
good.
If
we
in
not
working,
that's,
also
easier
to
deal
with
easier
to
fix.
G
C
C
C
A
Yeah:
okay,
what
I
understand
from
jeff
and
anchor
is
they're
going
to
take
up
this
interesting
application
to
the
list.
Is
there
any
other
questions
that
you
want
to
ask
of
anchor
before
the
jeff
and
anchor
continued
the
discussion
on
the
list
I'll
give
a
few
minutes
for
people
in
case
you'd
like
to
chat.
A
Okay,
we're
going
to
take
a
little
bit
of
a
re
spin
on
our
discussion.
I
felt
it
was
extremely
important
today
to
go
through
a
longer
discussion
on
the
rdo
rf
solution
with
pgp
bgpc
solution.
I've,
given
you
enough
information
to
help
prove
through
this
pce
solution,
is
really
matches
our
some
of
our
auto
configurations.
A
I'm
gonna
have
to
move
this
to
the
end
of
the
presentation
list.
If
it
falls
off
the
end,
it
will
go
on
the
interim
on
bgp
auto
configuration
because
it
does
do
bgp
auto
configuration.
So
I
recommend
people
to
to
read
the
drafts,
but
we
may
need
to
pick
that
up
in
a
different
interim
we're
going
to
switch
over
to
jeffrey
zhang
jeffrey.
If
you
would
prepare
to
get
ready
for
your
presentation,
I
will
bring
your
presentation
up
next.
A
J
J
J
J
If
you
consider
that
you
have
a
vpn
that
has
say
10,
ps
or
20,
that
does
not
matter,
and
for
that
vpn
we
use
a
raw
target.
Let's
call
it
rt1.
The
raw
target
is
an
extended
community,
and
then
we
call
it
ec1
that
has
a
subtype
0x2
in
this
case.
Rt1
and
ec1
are
exactly
the
same,
but
when
we
say
route
targets
we
emphasize
that
it
is
a
special
extended
community
that
is
used
to
control
the
propagation
and
importation
of
routes.
J
J
So
to
to
do
that,
we
need
to
attach
a
new
route
target.
Let's
call
it
rt2
to
that
route
so
that
owning
the
intended
target
pe
will
import
that
route
and
now
to
associate
that
route
with
that
vpn.
We
need
to
attach
another
in
intended
community
now,
in
this
case,
rg2
and
ec2
are
not
the
same,
and
it's
not
the
same
as
rt1
either.
J
So,
additionally,
the
the
ec2
that
is
used
to
to
indicate
that
it's
associated
with
the
vpn
it
can
be
an
arbitrary,
extended
community
configured
on
the
sending
and
receiving
keys
as
long
as
both
know
that
it's
related
to
that
vpn,
it
will
work,
but
it
would
be
nice
to
be
able
to
to
derive
that
ec2
just
from
the
rt1.
So
you
have
the
rt1
from
for
the
vpn
as
a
raw
target.
J
J
So
for
that
purpose
we
define
this
way
to
derive
it
basically
for
any
rt.
You
just
change
the
subtype,
to
a
new
value
and,
and
then,
and
for
that
derived
extended
community,
you
can
attach
it
to
the
route
and
because
it
does
not
have
the
raw
target
subtype.
Then
it's
not
going
to
be
used
to
control
the
propagation
and
and
the
importation
of
the
routes,
and
so
it
can
be
used
to,
but
it
can
be
used
to
associate
the
route
with
the
intended
vpn.
J
So
just
want
to
share
this
idea
with
everyone
here,
and
so
that's
if
you
have
a
similar
use
case
this
this
is
available
for
use
next
time.
Please
here
I
need
you,
some
specific
use
cases
that
basically
follow
that
falls
into
that
general
use
case
bucket.
I
I
don't
think
I
I
I
need
to
go
through
the
specific
use
case,
so
we're
going
to
discuss
on
on
that
general
use
case.
J
A
J
C
C
The
relevant
observation
from
there
is
that's
another
example
of
taking
one
extended
community,
changing
it
into
another,
so
some
other
component,
the
network
can
deal
with
it
in
a
slightly
different
fashion.
So
the
idea
is
not
new.
I
think
jeffrey's
example
something
that's
just
a
little
bit
more
generic
than
the
specific
rtc
case.
A
A
A
J
J
Rather,
it
is
to
to
steal
the
traffic
after
it
had
reached
the
tunnel
endpoints.
In
this
example,
we
have
the
core
and
then
we
have
side
one
and
side,
two,
the
the
border
router
one.
We
got
that
tunnel
investigation
attribute
attached
to
the
two
routes
and
is
send
the
traffic
to
about
voter
router
two
and
after
border
route,
two
well,
the
then
the
when
the
br
one's
in
the
package
it
actually
attached
impose
a
label
stack
that
is
going
to
be
used
by
br2
to
steer
traffic
through
site
2..
J
J
So
if
we
want
to
do
that,
we
can
define
a
new
sub
tree
this
time.
We
don't
call
it
mpos
labels
there,
but
we
just
call
it
tunnel
label
stack
or
any
other
or
better
name,
that
sub
trv
is
to
encode
the
label
stack
that
is
used
to
steer
traffic
to
the
tunnel
endpoints,
not
after
it
reached
the
tunnel
endpoints.
J
J
J
Yes,
you
can
you,
you
can
use
a
sr
policy,
use
idea
and
use
a
different
subject
for
that
purpose.
But
if
you
have
a
network
that
that
does
not
use
sr
and
they
did
notice
that
this
is
purely
mpls
without
mentioning
the
sr
at
all.
So
it's
just
a
another
way
to
to
to
do
things
without
requiring
a
segment
routing.
J
J
J
A
And
I
do
not
see
anything
else
robert
says
could
could
be
inferior
metrics
that
beth's
path
selection
uses
any
that's
just
from
the
chat,
and
I
may
have
that
on
the
wrong
place:
okay,
jeffrey,
if
there's
nothing
further
or
no
one
else,
we'll
go
on
and
we're
going
to
pick
up
at
this
point,
we're
going
to
pick
up
guy
and
you're
gonna
have
a
few
minutes
since
you
got
short
cut
last
time.
So
please
be
ready.
A
A
A
A
A
Let
me
get
to
the
right
place
where
the
pce
controller
is
actually
configuring.
This
particular
set
of
routes,
maybe
as
an
rr,
that's
configuring,
r1
and
3,
so
the
path
can
go
first.
So
it's
really
one
of
our
auto
configurations
in
interest
of
time.
Could
you
go
through
this?
These
two
scenarios
and
we'll
hope
dhruv
can
give
us
a
moment
of
where
it
is
in
pce's
syndrome.
A
A
D
D
I
D
A
And
thank
you
one
of
the
the.
As
you
mentioned,
the
key
part
is
here
that
this
is
an
example
of
a
bgp
auto
configuration
where
the
pce
controller
is
being
used
to
configure
peering
sessions
between
two
bgp
piers,
r1,
r5
or,
and
that
our,
if
the
our
our
pce
controller,
is
also
being
able
to
configure
r7.
A
So
it's
a
it's
a
bgp,
auto
configuration
the
pce
folks
have
particular
language
which
using
pce
sets
up
the
same
information
we've
defined
in
the
bgp,
auto
configuration
so
part
of
the
feedback
that
we
have
is
both
the
mechanisms
and
descriptions,
but
also
it's
configuring,
ip
address
and
as
information
it
the
and
that
seems
to
be
all
so.
I
think
it
fits
within
our
bgp
auto
configuration
work.
A
A
A
Working
group
adoption
linda,
is
the
main
author,
robert
and
kasich
are
here
as
well
with
myself.
So
first,
let
me
tell
you
how
we
got
into
this.
One
of
the
things
in
the
tunnels
we
had
initially
was
tunnels
of
with
ipsec
and
ipsec
has
been
a
tunnel
discussion
for
a
long
time.
The
earliest
of
vpn
drafts
had
tunnels.
A
A
A
So
folks,
that's
what
the
tlv
is.
That's
the
reason.
The
reason
the
draft
has
quite
a
bit
of
explanation
is
because
it's
difficult
to
tease
apart
the
use
case
from
the
draft,
so
part
of
what
the
authors
would
like
is.
Is
this
a
good
starting
point
for
this
draft
and
do
you
think
we
should
pull
out
any
of
the
text?
A
A
With
that
brief
overlay,
a
different
overlay
than
a
description
than
linda
has
given
maybe
it'll,
give
some
of
you
some
insight
into.
Why
we're
looking
at
this
I'll.
Take
questions
and
kassick
will
help
me
answer
any
questions
that
I
might
miss
as
he's
actually
doing.
Some
of
the
coding
for
the
implementations.
A
A
A
Okay,
if
there's
no
discussion
on
this,
we'll
consider
our
discussion
closed.
This
draft
has
got
several
interests
carriage
the
shepherd.
Please
send
your
comments
to
care.
The
authors
would
like
to
know:
should
this
draft
split
the
mechanisms
and
a
description
there
are
descriptions
adopted
for
sd-wan
case
in
best,
if
there's
something
that
should
be
informational
about
the
mechanisms.
A
If
you
tell
us
that
if
we
we
see
that
there's
lots
of
interest
again,
that's
with
my
individual
contributors
at
with
my
taking
off
my
individual
contributors
hat
and
putting
on
my
idr
shepard's
hat,
we
are
I'm
interested
to
see
if
we
can
continue
to
follow
up
on
the
ipsec
based
work.
The
best
work
has
not
progressed
rapidly
in
that
area.
There
was
a
best
draft
based
in
evpn.
So
that's
where
it
is.
We
also
had
another
ipsec
without
any
other
application.
A
I
look
forward
if
you
have
those
drafts
as
the
chair
trying
to
shepherd
these
through
to
try
to
push
this
through.
There
are
many
many
implementations
of
ipsec
in
the
internet
and,
as
we
switch
to
the
tunnel
attribute,
I
hope
that
people
will
come
forward
with
them
and
I've
been
trying
to
shepherd
them
along
and
find
the
use
cases
and
see
if
we
can
take
that
through.
That
was
my
part
of
the
tunnel
draft.
When
john
and
I
divvied
up
the
work
any
other
questions
for
this
interim.