►
From YouTube: IETF111-IDR-20210727-2300
Description
IDR meeting session at IETF111
2021/07/27 2300
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
A
So
take
a
look
at
it.
It's
wonderful
reading,
we'll
go
on
to
the
next
slide,
the
quicker
I
do
this,
the
more
time
the
slides
and
the
status
are
online.
That's
nicely
it's
not
presenting
well,
but
it
it
works
for
everyone
else.
It's
great
jeff!
If
you
need
the
status,
I
send
it
out
ahead
of
time.
So
we
don't
worry
about
it.
You
can
see
it
on
our
wiki.
A
A
A
I
have
also
put
out
a
flow
spec
v2
spec,
it's
a
drafty
draft,
but
since
we're
moving
toward
flowspec,
I've
garnered
another
editor
and
we
may
get
add
a
third
one
in
christoph
loeb
who
did
the
first
v-spec
v1
spec?
If
he
has
time
the
next
two,
we
may
we're
whole
I'm
giving
you
some
dates,
we'll
hold
open
in
case
we
have
some
of
the
other
issues.
A
These
interims
prove
to
be
useful
during
the
summer
on
flow
spec
and
bp,
auto
configuration
so
we're
going
to
these
up
in
the
fall.
If
we
find,
we
don't
need
those
dates,
we'll
let
you
know
if
there's
any
problem
with
these
dates
or
if
you
have
a
topic,
please
let
me
know
otherwise
we'll
ask
the
ads
to
reserve
some
of
these
dates
again.
This
is
more
of
our
efforts
to
try
to
progress
our
work
as
quickly
as
possible.
A
A
This
talked
about
the
interims
that
we
had.
There
was
one
on
the
seventh
on
bgp
flowspec.
We
found
out
that
people
really
wanted
us
to
focus
ddos
applications
in
v1
and
all
else
in
v2
on
the
wiki.
You
will
find
out
if
you
had
a
draft,
whether
it's
in
v1
or
v2,
I
won't
walk
through
it
and
I
will
assume
that
authors
will
go
see
it
on
the
on
the
wiki,
the
auto
configuration.
A
We've
not
heard
much.
I
think
that's
because
we
heard
all
of
the
feedback
during
the
interim.
So
unless
there
is
a
problem
the
chairs
will
adopt
this,
I
realize
it's
got
an
itf
name
that
was
initially
erroneous,
but
we're
going
to
go
ahead
and
drop
this
to
working
cube
draft,
since
it
does
encapsulate
what
we've
heard
in
the
interims.
A
B
That's
fine
so
as
part
of
the
work
that
is
happening
by
a
spring
about
you
know
some
flavor
of
what
was
originally
labeled
as
either
classful
transfer
transport,
or
you
know,
color
aware
routes
motivated
mostly
by
work,
that's
happening
in
spring,
since
we
have
two
bgp
solutions
that
are,
you
know
currently
out
as
proposals,
we
asked
the
authors
of
the
existing
protocol
drafts.
You
know
four
questions
that
we'd
like
to
have
them
discuss
as
part
of
their
presentation.
B
The
question
one
is:
basically:
where
does
your
mechanism
carry
the
intent
question
two
when
the
intent
needs
to
go
from
one
domain
to
another?
How
do
you
handle
that
question
three?
How
does
route
selection
impact
your
mechanism
at
pinch
points
and
question
four?
How
are
you
carrying
the
forwarding
semantics
now
as
an
example,
labels
or
sets.
B
A
B
C
B
C
B
C
C
C
So
the
status
on
the
dash
11
version
of
the
draft
we
went
and
restructured
the
model
not
only
to
reduce
the
number
of
sub-modules.
There
were
some
really
small
ones.
That
really
didn't
need
to
exist
at
separate
modules,
but
also
looked
at
it
structurally
to
make
sure
that
that
the
model
was
extensible
could
be.
The
groupings
within
the
model
could
be
used
by
other
models
that
wanted
to
extend
the
bgp
model
and
with
all
that
cleanup
and
the
poster
dash
11
version.
C
It
also
has
examples
that
show
how
to
add
a
new
happy,
a
slightly
more
extensive
example,
so
that
should
allow
authors,
other
authors
to
be
able
to
see
that
example
and
extend
there's
also
an
example
to
add
new
attributes
set
in
the
appendix
that
people
can
take
a
look
at
and
we
did
address
and
incorporate
most
of
the
comments
from
yang
doctor's
review.
Thanks
ac
for
doing
the
review,
we
still
have
a
few
issues
to
resolve
and
next
slide.
Please.
C
So
the
issues
are
being
tracked
at
this
github
location,
and
so,
if
anyone
wants
to
see
what
is
still
outstanding
or
wants
to
file
new
issues,
it
would
be
a
good
place
to
go
and
do
that.
There
are
two
major
issues
that
we
do
want
to
discuss
in.
This
meeting
today
relate
to
extended
communities
and
large
pgp
communities
that
I
am
going
to.
Actually
let
jeff
talk
about
so
back
to
you.
B
Okay,
thank
you.
So,
very
briefly,
I
do
encourage
anybody
that
is
following
this
work
and
interested
to.
Please
take
a
look
at
the
github
issues.
We
are
trying
to
follow
itf
process,
even
though
this
is
not
necessarily
in
an
ietf
github
at
this
point,
given
the
history
of
the
documents
and
we're
trying
to
track
known
issues
there,
the
two
largest
issues
that
we
have
to
be
done
at
this
point
is
working
in
reverse
order.
B
Large
bgb
communities
has
become
since
we
adopted
the
work,
a
well-deployed
and
sort
of
pervasive
feature,
and
we
want
to
make
sure
that
it's
included
as
part
of
the
base
model.
At
this
point,
it's
not
necessarily
difficult
work,
but
it's
not
small,
so
it
is
not
currently
in
the
version
that
has
been
pushed
itf.
B
The
second
issue
and,
to
some
extent
what
mahesh
was
hitting
at
in
the
prior
slides,
a
big
portion
of
the
exercise
we've
been
going
through,
is
making
sure
that
we
are
capable
of
extending
the
model
and
maintaining
it,
and
we
found
a
couple
of
small
issues
that
caused
us
to
do
some
of
our
reorg
one
of
the
issues.
That's
going
to
be
problematic
and
we'll
also
hit
other
working
groups
as
well
is
what
they
do
about
things
that
are
in
the
form
of
a
yang
type.
Def
type
defs
currently
cannot
be
augmented.
B
They
have
to
be
effectively
replaced.
We're
going
to
go
forward
with
you
know,
trying
to
code
up
a
solution
for
this
that
effectively
moves
the
extended
communities
into
a
iana
maintained
module.
What
this
will
mean
is
that
anything
that
wants
to
add
extended
communities
would
effectively
need
to
coordinate
through
idr,
and
we
would
maintain
the
module
in
iana
as
our
way
of
taking
care
of
this.
C
C
B
B
Okay,
if
you
have
no
questions,
the
request
is
for
you
to
please
take
a
look
at
the
work
in
progress
along
with
the
open
issues.
If
you
have
time-
and
you
know
something
about
yang
and
github,
please
feel
free
to
take
an
issue
and
you
know
supply
a
patch
for
it.
If
you
think
that
you
have
a
solution
for
things,
otherwise
the
authors
will
continue.
Iterating
and
you
know
target-
is
to
try
to
have
things
largely
done
by
next
ietf.
D
B
E
E
Quick
recap:
bgp
car
extends
hop
by
hop
bgp
routing
to
set
up
you
know
an
intent
aware
path
across
multiple
network
domains.
It
directly
adopts
the
color
construct
that
has
already
been
defined
in
the
idf
to
represent
intent
and
supported
by
multiple
protocols.
Next
slide,
please
it's
a
quick
illustration
of
the
basic
flow
of
both
the
transport,
where
you
know
a
bgp
car
route,
propagates
off
by
hop
across
the
domains
to
an
ingress
b
and
subsequently
the
automated
steering
of
a
colored
service
route.
E
E
E
You
know
and
the
mapping
to
be
consistent
across
a
set
of
devices
that
can
span
multiple
network
domains,
but
they
all
fall
within
a
single.
You
know
administrative
authority,
so
a
so
called
color
domain
next
slide.
Please
why
this
model?
It
is
the
simplest
data
model
that
you
know
addresses
both
the
uniqueness
and
intent
requirements.
E
Hence
it
provides
the
you
know,
the
familiarity
and
the
simplicity
for
both
the
implementation,
but,
more
importantly,
operationally
there
are
no
complex
procedures
involving
vpn.
You
know
our
import,
export
or
rde
manipulations.
Here
it
also
provides
inherently,
you
know
automatic
multipathing
and
fast
convergence
as
we'll
see
in
the
next
slide
next
side.
Please.
E
So
this
example
shows
both
the
path
availability.
You
know,
as
requested
by
the
chairs,
as
well
as
the
the
local
convergence.
You
know,
property.
You
have
two
abrs
two
three
one
and
two
three:
two
originating
a
bgp
car
route,
e3
c1
for
an
usb
e3,
because
you
taken
the
mpls
example.
The
labels
allocated
are
different.
Now
at
a
transport
rr
within
the
domain,
add
path
would
be
enabled
to
ensure
both
these
paths
are
distributed
to
the
ingress
bar
routers
in
the
domain.
E
You
know
the
node
allocates
a
single
local
label
and
then,
when
it
has
to
propagate
this
route
up
stream,
it
advertises
that
local
label
with
the
next
stop
as
itself
and
this
process
repeats
this.
All
of
this
is
identical
to
what
happens
with
bgplu
today
and
to
see
one
of
the
benefits
when
the
egress
abr
that
is
231
fails
that
failure
is
detected
locally
within
the
domain
via
igp.
So
that's
fast
and
the
you
know
the
handling
is
local.
E
E
E
An
optional
extended
community
called
the
local
color
mapping
community
is
defined.
It
only
gets
used
if
the
routes
go
across
the
color
domain
in
a
boundary
and
it's
used
to
remap
and
rewrite
the
color
into
the
receiving
domains
color
at
the
domain
boundary
again
at
a
peering
session.
Typically,
likewise,
the
color
extended
community,
which
also
you
know,
which
would
be
sent
with
the
service
route
and
would
also
go
across
such
a
color
boundary,
would
get
a
similar
kind
of
remap,
and
you
know
rewrite
you
know,
operation.
E
One
thing
to
note
is
the
nlri
itself
or
does
not
get
rewritten.
It
is
preserved,
end
to
end
providing
visibility
as
well
as
being
used
for
you
know
a
resolution
at
an
ingress
pe,
the
the
endpoint
ip
is
unique
in
the
transport.
You
know
it
represents
a
node
in
the
transport.
Hence
this
makes
the
nlri
the
e
comma
c
tuple.
You
know
unique.
Even
if
you
know
the
color
is
local
to
a
color
domain.
E
Next
slide,
please,
with
regard
to
the
question
about
how
forwarding
information
is
signaled,
it
is
signaled.
You
know,
along
with
the
route
information
such
as
labels,
or
you
know,
sids,
they
are
signaled
with
the
route
as
non-key
data
again.
This
is
conceptually
similar
to
what
happens
with,
for
example,
bgplu,
where
the
label
is,
you
know,
non-key,
you
know
data.
What
we
have
done
here,
though,
is
we
have
introduced,
because
this
is
a
new
safety.
We
have
introduced
a
well-defined
structure
such
as
a
tlv
to
encode
this
information.
E
Now
this
this
model
then
provides
one
additional
benefit,
which
is
not
necessarily,
you
know
to
be
used,
but
it
provides
that
flexibility,
which
is
one,
can
signal
a
different
so-called
label.
You
know
value
for
our
different
encapsulations
current.
You
know
labels,
implementation,
definitions,
allow
only
a
single
label,
and
that
has
four,
you
know
proven
to
be
constrained
when
multiple
encapsulations
have
been.
You
know,
introduced
and
needed
to
be
supported
for
migration
and
interworking.
E
E
The
what
we
saw
in
the
previous
slide
was
an
example
or
in
one
instance,
but
we
have
taken
this
approach
of
defining
an
extensible
future
proof
encoding
for
in
general
for
the
nlri.
Since
this
is
a
new
safy,
there
isn't
a
need
to
inherit
all
the
constraints
that
exist
with
current.
You
know
level
or
equivalent
saffies
I
mean
we
have
gone
through.
You
know
the
different
extensions
before
so
I
will
skip
it
in
the
interest
of
time,
but
it's
documented
in
the
next
slide.
Please.
E
E
E
E
E
This
is
just
an
illustration
of
the
vpn
car.
You
know
model
that
I
just
described.
I
think
in
the
interest
of
time
I'll
you
know
skip
past
it
next
slide.
Please
other
minor
updates.
We
added
you
know
some
description
of
how
any
cast
it
gets
leveraged
with
the
you
know,
car
for
the
some
of
the
scaling
designs
and
we
also
added
jimmy
shad
as
a
co-author.
E
Next
slide,
please
so
finally
yeah
so
we
you
know,
we
plan
to
continue
to
address
the
use
cases
and
requirements
that
were
listed
in
the
problem
statement.
As
usual,
you
know,
request
collaboration
and
review
from
the
working
group.
One
thing
to
note
is
there
is,
as
mentioned
by
jeff,
there
is
work
on
going
regarding
merging
the
two
problem
statement
drafts
at
the
best
of
the
various
working
group
chairs.
E
B
F
F
E
E
F
Okay,
all
right,
second
question
that
I
want
to
bring
up
is:
this
is
a
good
thing
that
we're
introducing
the
key
and
the
non-key,
but
I
had
raised
this
question
on
the
on
the
mailer.
It's
probably
a
question
more
to
you
and
then
the
entire
idea.
This
is
probably
something
that
the
base
bgp
spec
talked
about.
Nlri
and
the
attributes.
Now
we
are
going
to
be
looking
at
some
of
the
attributes
will
get
into
the
nlra
structure
of
being
a
non-key.
F
We
may
want
to
have
some
checks
to
see
how
the
nlri
can
grow
with
the
key
and
the
non-key.
Otherwise
we
may
end
up,
then.
The
question
is
in
the
next
time:
when
we
want
to
introduce
an
attribute,
should
we
get
into
the
attribute
section
or
should
we
get
into
the
non-key?
That
will
be
a
question
we'll
be
asked
every
time
we
introduce
a
new
one,
so
something
that
we
might
want
to
think
through.
E
I
think
I
think
we
agree
with
you
there.
I
think
you
know,
and
I
think,
even
when
we,
if
you
see
how
what
has
you
know
what
we've
used
it
for
it
has
been
used
to
signal
you
know
per
route.
You
know
information,
not
any
generic
attribute,
and
we
expect
that,
since
these
are
all
named
or
numbered,
you
know,
well-defined,
you
know
tlb's.
Whenever
anything
gets
defined,
there
will
be,
you
know
it
will
undergo
a
working
group.
B
H
E
Not
sure
I
mean
understand
the
question
fully
because
the
correctness
community
is,
you
know
it
indicates,
you
know
more
of
the
the
request
for
an
intent.
If
you
will
so
it's
you
know,
we
want
to
overload
it
for
the
purpose
of
indicating
the
intent
too,
but
maybe
this
is
something
we
can.
You
know
take
up
on
the
list
as
well.
B
I
Yeah,
so
I'm
going
to
give
an
update
on
bgpct,
it's
a
quick
agenda,
we'll
just
recap
the
problem
solution
and
also
explain
the
mechanics
of
ct,
with
focus
on
the
key
questions
that
the
workgroup
she
has
asked
and
share
the
changes
and
current
status
next
weeks,
and
while
I
go
through
this
presentation,
I'll
also
clarify
the
misunderstanding
that
the
previous
author
had
on
how
the
convergence
works
in
ct.
So
it
is
not.
It
does
not
propagate
end-to-end
I'll,
explain
how
that
works.
I
So
the
question
is,
the
problem
is
simple:
it's
basically,
any
domain
has
tunnels,
it's
just
like
you
call
it
entire
tunnels
and
they
are
varying
t
characteristics
and
there
could
be
multiple
tunnels
to
the
same
destination,
different
running
protocols,
providing
those
tunnels,
and
we
may
need
to
extend
that
those
tunnels
preserving
their
characteristics
end-to-end
across
the
option.
C
domain
and
different
routes.
Services
want
to
resolve
over
them
in
an
inter
intra-airs
or
inter-areas
scenario.
So
the
intent
is
basically
just
to
do.
I
Service
mapping
and
internet
driven
source
mapping,
or
you
can
say,
constraint,
based
service
marketing
and
the
solution
should
be
agnostic
to
whichever
transport
protocol
is
in
play
in
each
domain
and
what
service
layers
are
there
service
layer
routes,
and
one
thing
that's
not
mentioned
here-
is
it's
good?
If
you
just
separate
out
transport
layer,
entities
and
service
layer
entities
in
different
families,
you
don't
mix
them
together
because
they
have
different
requirements.
Different
scales,
different
speeds.
I
So
these
are
the
main
concepts
of
bgbct.
Basically,
we
have
a
transport
class
which
is
a
construct
that
collects
tunnels
of
the
same
characteristics
and
it
has
an
identifier
which
is
32-bit
with
the
color
and
it's
just
a
new
transfer
transport
layer
address
family
which
follows
4364
procedures
and
8277
encodings,
which
basically,
it
uses
the
existing
route
distinguisher.
Just
as
a
identifier,
it's
a
testing
user
to
carry
the
prefix
across
path,
hiding
scenarios
and
it
can
be
stripped
off
and
possibly
can
be
done
on
it.
I
Whenever
we
require
and
there's
a
transport
class
now
target,
it's
just
a
new
route
target
which
carries
the
transport
class
or
the
color.
So
color,
as
the
word
is
an
adjective.
So
it
better
is
described
as
a
attribute
than
in
the
name
and
it
extends
the
tunnels
across
multiple
domain
boundaries
by
following
option
c
style
procedures
and
depositing
mpls.0
swap
routes
on
the
border
routers
and
it
collects
it.
I
It
basically
connects
the
tunnels
of
the
tracing
transport
class
in
the
hsn
domains
and
the
intent
of
the
route
where
to
how
to
what
kind
of
tunnel
to
take
that's
that
is
carried
as
a
mapping.
Community
and
it
maps
to
a
resolution
scheme
and
the
season
scheme
is
what
gives
the
intent.
Basically,
I
I
want
to
take
a
tunnel
off
a
certain
class
with
a
certain
fallback
option
next
time,
please.
I
So
in
this
slide
we
have
just
noted
the
questions
of
the
answers
from
the
chairs.
So
where
does
the
intent
get
carried?
The
intent
get
carried
on
the
as
a
mapping
community,
which
is
nothing
but
a
regular
community
on
a
visibility
route
and,
for
example,
the
vgp
city
routes,
the
transport
target
it
it
becomes
the
marketing
community
and
it
says
strictly
resolve
over
the
tunnels
of
the
same
type
and
for
service
routes.
They
may
want
fallback.
I
So,
for
example,
color
extended
community
is
view
the
marketing
community
on
the
service
route
and,
it
would
say,
resolve
over
color
and
routes
with
far
back
on
best
offer
tunnels
and
for
anything
else.
That
is
like
more
creative.
We
can
have
other
communities
any
visit
community,
it
can
be
defined
as
a
mapping
community
and
it
can
define
the
fallbacks
as
maybe
go
over
gold
if
it
is
not
that
go
old,
bronze
and
any
other
mix
that
the
operator
wants
and
when
the
route
needs
to
be
sent
from
one
intern
domain
to
another.
I
How
does
the
translation
happens
if
they
don't
agree
on
the
value
of
what
represents
that
intent?
So
that's
basically
just
community.
We
write-
and
we
can
see
that
even
today,
at
this
layer,
because
color
community
is
the
marketing
community
and
this
mechanism
is
just
backward
compatible
to
that.
So
we
would
do
the
same
kind
of
community
rewrite
for
even
conor
community
on
the
service
house.
So
even
on
the
transport
route,
we
are
doing
the
same
community
rewrites
and
route
our
battery
rights,
as
we
do
in
sdv
networks
today.
I
So
these
procedures
are
very
familiar
to
operators
and
how
do
we
distinguish
during
pinch
points?
It's
just
rd
as
we
and
just
talked
about
rd
and
in
addition
to
rd
we
also
have
add
path.
So
it
just
uniquely
identifies
the
originating
pe
helpful
for
troubleshooting,
but
we
can
also
strip
the
rd
and
do
path
selection
and
how
the
forwarding
semantics
is
associated
with
the
intended
intent
carried
in
the
mechanism.
So
it's
it
does
not
mention
any
changes
to
how
it
is
carried.
I
So
basically,
labels
as
8277
or
states
in
the
prefix
set
or
in
future,
like
multi-net,
stop
attribute,
proposes
to
carry
labels
or
other
forwarding
information
as
part
of
the
next
stop,
because
these
are
like
the
though
label
is
going
in
the
prefix.
It
is
actually
a
desktop
attribute.
So
in
my
opinion,
it
is
better
to
go
with
new,
newer
mechanisms
which
move
those
forwarding
properties
to
the
next
one
and
any
of
those
mechanisms
that
are
newly
get
defined
if
they
are
backward
compatible
to
the
existing
machine
mechanism.
I
Yeah,
so
this
is
an
example.
Using
this
diagram,
I'll,
explain
the
question
or
I'll
refute
the
statement
by
the
ninja
that
in
ct
we
cannot
do
what
he
claimed.
So
basically,
let's
say
we
have
pe
one
one.
So
the
two
ways
the
ct
rounds
can
be
originated
either
rd
colon
pe
one,
one
pe
one
one
can
originate
and
in
which
case
the
rdu
column,
p1
one
route
asbr21
will
know
there
is
multiple
paths
towards
spr13
svf14.
Similarly,
avr-23
will
know.
I
If
asbr
13
originates
the
route
for
pe
one,
one
and
a
half
14
originates
a
route
for
pe
one
one
so
at
each
of
the
abrs
or
the
asbrs
with
these
routes
are
collected
in
the
transporter
and
the
label
allocation
is
done
on
a
per
prefix
basis,
where
the
prefix
is
after
stripping
the
rd
in
the
context
of
the
transporter.
So
that
makes
shows
that
the
label
value
does
not
change
and
the
repair
happens
locally.
So
I
think
they
did
not
understand
it
right.
I
We
have
talked
about
most
of
this
already,
so
one
thing
we
I
want
to
reiterate
here
is
say:
it
protects
the
investments
of
operators
that
are
made
that
they
are
made
in
operational
training,
tooling
procedures,
because
they
already
know
lgbt
and
now
that
same
vpn
machinery,
the
route
targets
rd,
is
going
to
play
at
a
new
layer.
So
that's
the
major
advantage
of
using
this
and
also
interoperable
device.
I
I
Yeah
next
so
update
since
the
last
idf.
We
just
added
the
clarification
that
5549
type
x
and
network
capability
is
not
required
because
it's
a
new
family,
so
we
can
state
that
we
we
can
derive
the
next
object
based
on
the
next
half
length
and
we
added
reference
to
the
rsvp
sub
color
and
added
srv6
support
section
and
corrected
some
typos
exactly
so.
I
The
current
status
is
so
basically
the
draft
has
been
there
for
five
or
eight
five
or
eight
years
now,
and
there
have
been
discussions
on
the
working
group
feedback
and
we
gathered
support
organically
by
these
discussions
on
the
working
group
areas.
So
thank
you
for
all
the
discussion.
Support
and
the
implementation
is
available
since
junos
21.1
and
it
uses
india
allotted
code
points,
and
this
is
the
point
I
want
to
make
in
the
previous
slide.
I
So
basically,
we
don't
propose
any
new
major
extensions
in
here,
so
we
are
reusing,
whatever
mechanisms
already
work
with
new
in
the
allotted
points,
so
the
benefit
of
already
existing
mechanisms.
I
think
we
need
to
try
without
inventing
new
things
just
for
fun,
how
we
can
use
existing
mechanisms,
and
we
have
to
consider
what
what
does
what
is
that
it
does
not
solve
so
because
this
is
doing
it
in
an
eloquent
manner.
That
is
why
I
think
that
we
have
many
interested
customers
who
are
trying
it
out
without
that.
J
I
So
flex
algorithm
is
one
of
the
transport
protocols
in
the
intra-is
like
flex,
algo
rsvpsrt,
and
each
of
these
transfer
protocols
are
taught
how
what
their
color
is.
But
beautificity
is
when
you're
going
into
intel
domain,
and
then
we
carry
the
color
as
the
route
target
and
your
first
question
about
whether
the
color
is
consistent
on
each
of
the
nodes.
So
in
one
domain
the
color
is
usually
consistent,
but
it
doesn't.
B
I
I
I
B
K
Hello,
yes,
so
question
is
regarding
what
you
mentioned
about
the
local
convergence,
as
you
mentioned
the
rds
of
convenience.
So
when
you
receive
two
different
rd
routes,
though
they
are
pointing
to
the
same
endpoint
on
an
abr
when
you
remove
the
rd,
so
that
means
you
have
to
still
map
the
transport
target.
K
That
means
you
have
to
do
an
import,
and
then
your
that
means
you
are
doing
the
import
procedure
on
your
aspr
and
second
part
is
once
you
allocate
a
label,
you
are
allocating
a
label
for
an
ip
prefix
now,
not
for
not
for
the
rd,
comma
endpoint
and
therefore
the
local
label
would
be
same
now.
Even
though.
B
K
Are
advertising
two
routes
to
the
upstream?
They
are
going
with
the
same
label,
it's
the
same
lsp,
so
I
don't
see
advantage
of
advertising
two
routes,
even
though
they
are
carrying
the
same
lsp
information.
So
to
me
this
looks
like
a
hack
to
just
make
a
local
convergence
work.
I
don't
think
this
is
a.
This
is
a
with
the
vpn.
This
is
not
the
way
it
worked.
You
just
made
it
because
you
require
local
tools
now.
Otherwise
I
don't
see
that.
I
L
I
I
No,
I
won't
see
it
that
way.
Let
me
respond,
so
basically,
we
collect
the
routes
in
a
transport
trip
for
two
reasons,
for
the
main
reason
is
because
we
need
to
do
the
service
mapping
information
where
we
need
to
resolve
the
routes
over
tunnels
of
a
certain
kind
and
ct
already
collects
them
in
a
transport
rip
and
gives
you
and
in
in
car.
I
think
that
point
is
just
left
out.
It
is
up
to
the
implementation.
Now
they
organize
it
and
there
is
no
way
the
protocol
itself
organizes
it.
Let
me
just.
K
K
K
K
I
K
K
B
I
B
G
Okay:
okay,
okay,
okay,
my
question
is
that
now
the
vpn
rules
use
the
next
hope
and
the
color
to
match
tunnels,
but
the
ct
is
the
key
another
key,
the
rd
and
the
prefix.
So
we
must
support
the
vpn
row
to
to
steering
to
the
tunnel.
So
we
also
need
to
generate
the
ct
roads
to
make
tunnel
use
the
prefix
and
color.
So
I
think
it
it's
like
the
keys
are
not
not
exactly
a
match.
I
think
it
may
cause
some
kind
of
conclusion.
I
I
So
the
way
the
resolution
works
is
the
service
route.
It
asks
for
resolution
using
resolution
scheme
which
says,
let's
say,
give
me
a
tunnel
of
color
gold
or
best
effect.
So
if
he
has
a
tunnel
of
color
code
that
could
be
either
an
intra
domain
tunnel
like
flexel
go
rsvp
srt
or
it
could
be
an
inter-domain
tunnel
which
is
a
ct
ct
route,
and
if
it
is
there,
it
will
resolve
over
that.
Otherwise
it
will
go
over
a
best
effort
tunnel
and
the
best
of
a
tunnel
could
also
be
an
intra
is
or
interiors.
I
B
A
A
B
A
I
I
So
whenever
you
have
a
seamless
mpls
network
like
vgp
and
new
network
and
the
number
of
mpls
forwarding
routes
and
next
hops
on
any
border,
node
or
service,
node
is
proportional
to
the
number
of
nodes
in
the
network,
as
well
as
the
number
of
ecmp
next
stops.
So
that
is
the
scaling
problem,
and
the
convergence
problem
is
that
we,
when
a
pe
goes
down
and
that
reachability
withdrawal
has
to
be
propagated
until
the
other
end
of
the
network
before
pick
or
any
any
such
mechanism
can
happen.
I
I
I
I
I
We
have,
you
can
say,
label
vrs,
and
this
is
done
to
be
able
to
do
upstream
allocation
of
labels
in
mpls
forwarding
context
at
a
receiving
node.
So
this
family
needs
to
be
negotiated
just
between
the
rr
and
the
border
nodes
of
a
particular
region,
and
that
will
help
the
whole
network
scale
up
and
the
convergence
to
be
faster.
So
the
way
it
happens
is
maybe
we
can
go
to
the
next
slide
and
I'll
explain
it
along
with
that.
I
So
this
one
region
is
identified
with
a
context
protocol
next
top
and
we
hide
the
actual
protocol
next
stops
from
getting
advertised
towards
the
other
regions
in
the
service
clouds.
So
when
the
rr
re-advertises
the
service
routes
to
the
other
regions,
it
rewrites
the
next
stop
to
the
context
protocol
next
top
and
it
can
allocate
new
labels
and
install
them
in
the
context
tables
at
bn1
and
bn2
and
the
way
it
installs
those
labels.
I
In
these
context,
tables
is
where
this
new
bjp
family
is
plays
a
role
and
now
because
the
rr
is
deciding
what
labels
to
use
rr
can
use
target
labels,
predictable
labels
or
anything
that
it
can
basically
do
anything
and
we
are
increasing
the
label
space
that
is
available
in
the
network.
So
here
what
happens
is
now
the
right
side
of
the
network
or
the
remaining
regions.
They
don't
see
these
hundred
loopbacks,
but
they
only
see
one
contest
protocol
next.
I
I
Pe
two
prime
does
not
even
know
about
it
because
the
failure
action
is
taken
by
vn1
and
bn2,
which
is
like
in
the
same
region.
So
the
failure
is
very
quick.
So,
as
you
can
see
in
this
diagram,
the
private
label
plc
e1,
it
is
having
active
and
backup
towards
pe1
and
pe2,
and
when
pe
one
goes
down,
vm1
and
vn2
will
just
do
a
repair,
as
shown
in
the
next
fight.
I
Please
and
the
traffic
will
be
repaired
towards
pe
2.,
so
the
withdrawal
does
not
have
to
travel
until
pe
to
try
because
the
failure
is
taken
care
of
locally
and
similarly,
even
if
bn1
fails
in
the
next
slide,
because
the
labels
have
been
mirrored
in
these
context
tables
at
the
end
of
bn2.
So
once
be2
prime
sends
traffic
towards
the
cpn
h1
it
will
reach
either
bmw
or
bn2,
based
on
the
local
repair
or
local
region.
I
I
Next
at
least
so.
This
is
like
a
new
kind
of
option,
interiors
option,
which
is
like
a
combination
of
option
b
and
option
c.
So
we
are
getting
option,
bb
a
forwarding
behavior
with
some
additional
advantages
of
label
mirroring
and
which
gives
us
the
scaling
advantage
and
the
convergence
advantages
that
we
see
and,
as
I
already
mentioned,
pick
and
equals
protection
like
convergence
features,
they
work
in
this
model
for
any
kind
of
service
routes,
so
ps
and
other
the
ps
don't
need
to
support
anything.
I
I
K
I
I
K
K
I
K
B
K
B
K
Just
look
like
an
option
b
on
the
rr.
You
will
start
doing
an
option
b:
control
plane
where
you
start
allocating
a
label
for
an
rd,
comma
prefix,
and
then
you
downloading
that
label
table
to
an
bn
router
and
on
bn,
router
you're,
allocating
a
cpnh
label
just
to
come
to
that
table.
Whatever
table,
you
have
exactly.
K
K
I
wouldn't
like
an
rr,
because
rr
carries
so
many
address
families.
I
would
have
loved
to
do
this
thing
on
the
bn
itself.
It's
an
option
b,
it's
an
existing
profile.
The
only
thing
is,
you
are
creating
a
hierarchy
where,
if
you
want
to
go
to
a
table,
I
will
advertise
a
cpanel.
Now
the
question
comes:
how
many
such
tables?
Will
it
help
you?
If
they're
100
ps
there
were
100
loopbacks
you
advertising
now,
with
thousand
worth,
we
realized
thousands
of
cpn
edge.
Are
you
still
optimizing
there?
No.
I
B
K
B
N
Yeah,
hello,
everyone,
my
name
is
reshma
and
I
will
be
presenting
the
generic
metric
tlb
for
aigp
draft
on
behalf
of
all
the
authors
listed
next
slide
please
today,
today,
I
will
be
talking
about
the
draft
problems.
We
are
addressing
an
interpretation
of
rfc
7311,
the
new
generic
metric
tlv
updates
to
the
best
path
selection,
followed
by
an
example.
So
let's
begin
next
slide,
please
for,
inter
domain
path,
selection,
we
use
the
igp
cost
to
get
the
end
to
end
best
path.
N
N
N
N
N
N
Rfc73111
also
says
that
the
igp
attribute
must
not
be
considered
to
be
malformed
because
it
contains
more
than
one
tlb
of
a
given
type
or
because
it
contains
tlbs
of
unknown
type.
So
here
the
rfc
clearly
states
that
if
you
recognize
the
tle
type
process
and
update
it,
if
the
tlv
is
unrecognized,
it
does
not
clearly
state
how
it
should
be
processed.
It
just
states
that
unrecognized
tailv
should
not
be
treated
as
malformed
next
slide.
Please.
N
N
All
right
see,
the
origination
is
similar
to
rsc
73.1
advertised.
Only
if
it's
configured
to
advertise
agp
attribute
if
the
domain
uses
any
metric
other
than
igp
cause
then
use
the
new
generic
metric
tlv
with
a
metric
type
filled
according
to
the
igp
metric
type
registry
and
the
generic
metric
value
indicating
latency
or
bandwidth
to
reach
the
prefix
being
advertised
on
the
receiving
end.
We
act
again
according
to
rfc
7311,
like
that,
we
should
be
unable
to
receive
a
gpa
attribute
from
the
sender,
among
other
things,
on
receiving.
N
N
N
So
so
the
best
part
selection
is
similar
to
the
rfc
7311.
A
path
with
a
generic
metric
tlv
is
preferred
over
parts.
Without
a
generic
muted
tlv
say
we
have
route
r
with
t
as
the
received
generic
metric
value.
If
the
received
metric
type
matches
the
metric
type
to
the
next
stop
say
n,
then
the
enhanced
aigp
metric
is
t
plus
n.
N
N
So
taking
an
example,
so,
let's
just
for
our
example,
let
us
assume
that
within
the
domain,
everyone
has
the
same
metric
type.
So
here
in
this
example,
domain
four
and
three
has
delay
as
the
metric
and
domain
one
and
two
use
igp
cost.
So
when
advertising
route
from
domain
4
svf
41
advertises
the
generic
metric
tlv
with
metric
type
as
delay
for
in
the
igp
metric
registry,
it
is
1
2,
spr
22
and
in
sbr
32
and
sbf
42
advertises
the
same
to
as
we
are
32.
N
N
It
can
just
simply
add
and
then
advertise
it
out
to
domain
one
on
domain,
two,
as
is
at
as
we
are
21
the
cost
to
reach
the
next
stop
is
by
22,
is
represented
by
igb
cos,
so
we
need
to
normalize
this
say
if
delay
is
not
like
a
significant
factor
within
domain
two,
then
the
then
you
can
add
zero
to
the
received
generic
metric
value
and
advertise
it.
So
the
metric
type
is
normalized
to
the
one
set
by
the
originator.
K
You
are
saying
the
metric
type
is
decided
by
the
originating
domain,
but,
as
you
see,
bgpct
or
bgp
car,
the
intent
is
carried
in
the
certain
community
or
in
a
car.
It's
carrying
the
nlri,
so
metric
type
looks
very
it's
it's
weird
that
you
were
decided
by
the
original
domain.
What
metric
type
to
carry
right?
It's
it's
an
interesting
one,
some
more
guarantee
or
some
more
important
things
to
look
into
before
that,
because
your
intent
is
carried
in
the
transport
target
or
in
the
color.
K
K
K
D
Yeah
so
so
I
think
sadish's
question
is
why
why
do
you
need
my
different
metric
types?
So
if
you're
advertising
two
routes,
one
one
for
low
cost
another
for
low
latency,
so
you
just
carry
the
low
cost
in
in
the
eigp
for
the
first
round
and
you
carry
the
latency
in
the
second
round.
So
the
problem
here
is
what
we're
trying
to
do
here
is
match
the
metric
types,
because
you
need
to
add.
D
So
let's
say
you
have
multiple
domain,
you
need
to
add
the
delay
metric
for
the
route
which
is
carrying
delay
metric.
You
need
to
add
the
delay
metric
along
the
path
and
for
the
route
carrying
igp
metric.
You
have
to
add
igp
metric
along
the
path,
and
it
may
also
happen
that
in
some
domains
there
is
no
delay
metric
for
the
route.
No
delay
metric
at
all,
no
delay
metric
paths
at
all,
so
you're
falling
back
on
best
effort.
D
You
have
to
make
that
distinction,
what
metric
type
you're
carrying
and
whether
you
want
to
add
it
or
not,
and
that
is
easily
done
by
having
the
same
the
metric
type
match
on
to
the
igp
metric
types.
So
that
you
know
what
metric
type
is
being
carried
and
you
look
at
what
what
you're
resolving
on
and
then
make
a
decision,
whether
to
add
directly
or
normalize
the
metric
and
then
add
it
so.
D
K
Is
just
part
of
the
intent
intended
just
super
said?
I
completely
agree,
but
I'm
just
trying
to
bring
out
a
point
where
you
are
carrying.
I
agree
they
are
carrying
a
metric
type,
but
there's
a
disadvantage.
I
can't
see
still
because
you
are
you
have
to
normalize
that
information
when
you
go
over
some
of
the
different
types.
So
why
not
carrying
a
aigp
only
what
we
have
today?
Why,
if
with
something
what
you're
proposing
I
don't
I
haven't
seen
the
advantage
yet
of
it.
Correct
aig
tlv
will
give
exactly
same
thing.
K
O
O
Yeah
just
a
few
words
about
background
and
motivation,
so
I
feed
refers
to
data
playing
on
pod
telemetry,
including
c2rm,
and
grab
the
reference
document
that
is
last
call
and
alternate
marking,
and
you
see
the
tube
to
reference
lfcs
in
general.
You
know
that
an
add-in
may
be
informed
about
gandhi
path
for
an
sr
policy
by
using
bgp,
and
there
is
the
document
in
working
group
plus
code.
O
O
O
O
Please,
and
this
is
the
type
five
about
the
alternate
marking
subtle.
We
also
added
two
new
flags
to
indicating
that
the
measurement
is
up
by
operant.
One
next
slide-
I
guess,
is
last
one
yeah
yeah,
so
in
short,
this
document
simply
complements
the
sr
policy
operations,
as
described
in
the
companion
document
on
segment,
drawing
t
policy
by
handing
the
I
feet
attribute.
O
O
P
Perfect,
so
I'm
gonna
try
to
make
this
presentation
shorter.
I'm
sure
some
of
the
folks
here
have
heard
this
in
the
best.
I
don't
want
to
board
anybody,
but
the
entire
purpose
behind
this
point-to-multiplying
policy
was
to
come
up
with
a
bgp
operation.
If
you
will
to
download
point-to-multipoint
lsps
to
from
the
pce
to
the
pcc,
we
wanted
to
keep
it
in
part
with
the
point-to-point
srte,
some
of
the
vendors
out.
P
P
So
these
are
some
of
the
drafts
that
you
folks
can
go
through
and
have
a
read
on.
With
regard
to
the
point
to
multi-point
policy,
there's
a
replication
segment,
that's
basically
the
forwarding
entity,
and
then
there
is
the
policy
itself
which
the
candidate
paths
and
patent
instances
reside
under
the
policy
I
will
go
through
them
later
on.
P
So
what
a
point
to
multiplying
policy
is
a
point
to
multiplying
policy
really
contains
the
root
and
a
set
of
leaps.
It
contains
a
set
of
replication
segments
as
well.
The
replication
segments,
as
I
mentioned,
are
the
forwarding
entities
that
are
programmed
into
the
data
path,
basically
incoming
seat
and
a
bunch
of
outgoing
interfaces.
When
you
want
to
do
the
replication,
your
outgoing
interfaces
can
be
obviously
different
interfaces,
and
then
there
is
a
swap
that
swaps,
the
incoming
seat
for
mpls,
of
course,
with
the
outgoing
seat
toward
the
down
screen.
P
P
So
the
policy
itself
contains
a
bunch
of
canada
packs.
The
canad
pads
are
a
little
bit
different
than
unicast.
In
our
case,
there
is
an
active
candidate
path
based
on
the
preference,
and
then
there
is
a
bunch
of
standby
or
backup
candidate
paths.
If
you
will
and
basically
in
this
draft,
we
change
that
a
little
bit.
I
know
that
in
the
unicast
srte
there
is
a
concept
of
ecmp
and
weight
and
we
did
introduce
that
concept
in
this
draft
as
well.
P
So
you
could
have
two
candidate
paths
in
this
graph
that
are
of
the
same
preference
and
can
be
used
for
easy
ecmp.
It's
completely
optional.
It
doesn't
need
to
be
there,
but
there
is
that
option
if
you
want
to.
If
you
want
to
use
and
then
there's
a
concept
of
the
path
instances,
so
each
candidate
pad
can
contain
two
path.
Instance.
The
path
instance
is
really
the
point
to
multi-point
lsp
itself.
P
It
is
the
tree,
it
is
what
is
programmed
on
the
data
path
and
the
reason
that
we
have
two
path
instances
is
because
of
global
optimization.
So
if,
for
whatever
reason,
igp
change
or
any
underlying
network
change,
you
want
to
optimize
your
tree.
You
create
a
second
path,
instance,
and
you
do
make
before
break
procedures,
to
go
from
the
previous
pad
instance
to
the
new
past
instance,
with
without
losing
too
much
traffic
nexus
slide,
please.
P
So
the
replication
segment,
as
I
explained
previously,
is
the
forwarding
entities
it.
It
contains
the
incoming
seat.
It
contains
a
bunch
of
outgoing
interfaces.
It
can
even
contain
fast
reroute
information
protection
information
which,
for
each
one
of
those
outgoing
interfaces,
you
could
actually
create
a
fast
reroute,
a
protection
lsp
via
the
replication
segment
itself.
So
that's
possible.
P
Usually
we
you
can
do
that
with
unicast
sr,
because
two
replication
segments
can
be
connected
via
unicast
sr
or
even
if
they're
connected
back
to
back
one
of
the
replication
segment
can
be
steered
out
out
of
the
node
via
an
adjacency
seat.
So
really
you
can
use
the
unicast
segment
routing
lfa,
ti
lfa
remote
lfa
for
that
protection.
P
So
this
is
why
each
instance
id
is
going
to
have
its
own
set
of
replication
paths
now.
One
thing
I
want
to
point
out
here-
and
this
is
a
very
strong
concept-
is
the
fact
that
two
replication
segments
they
can
be
connected
via
unicast
sr,
so
you
could
have
ingress
replication
or
you
can
even
put
your
replication
segment
into
places
in
the
network
when
there
is
only
replication,
needs
and
connect.
This
replication
multi-hops
away
via
a
unicast
sr
policy,
and
when
you
are
in
the
unicast
domain,
all
the
goodies
of
segment
routing
unicast
segment.
P
P
The
only
thing
I
want
to
talk
about
here
is
that,
as
you
can
see,
node
a
and
c,
that's
where
the
replication
policy
residing
and
node
b
is
a
node
that
cannot
support
replication
policy
and
when
you're,
going
out
of
the
node
a
via
that
outgoing
interface,
you
can
steer
your
traffic
into
a
unicast
segment,
routing
policy,
and
that
will
take
you
to
the
next
replication
segment,
which
is
the
node
c.
At
all
points.
P
The
replication
segment
needs
to
be
present
at
the
bottom
of
the
stack,
so
it
doesn't
matter
how
many
segments
you
push
on
top
of
that,
because
you're
going
into
a
unicast
domain,
but
that
replication
segment
needs
to
be
at
the
bottom
of
the
stack.
So
the
next
replication
point
can
identify
that
packet
to
be
a
point,
multiplying
policy
nexus
like
please
now
again,
when
it
comes
to
the.
If
you
will
srte
point
to
multi-point
policy,
we
tried
to
keep
it
very
much
in
line
with
the
unicast
big
brother.
P
The
rod
types
are
basically
one
for
the
point
to
multiply
policy
that
I
explained
that
previously
the
point
of
multiplying
policy
contains
the
candidate
path
and
the
pad
instances,
and
then
the
other
one
is
for
the
replication
segment,
which
actually
is
the
forwarding
information
after
calculating
the
point
to
multipoint
three.
They
get
downloaded
to
the
to
the
pcc,
via
this
latter
nexus
live
press.
P
So
when
it
comes
to
the
point
of
multi-point
policy
route
type
again
exactly
like
unicast,
it
downloads
the
candidate
paths,
it
can
download
a
leaf
list.
As
I
explained,
you
could
have
a
route
reflector
which
listens
to
the
ad
routes
on
the
pce
and
builds
that
tree,
and
if
that's
the
case
for
a
debuggability,
you
can
download
the
remote
endpoints
or
the
leaf
list
to
the
pcc.
Again,
it's
not
necessary.
That's
why
it's
optional,
but
just
because
there
is
no
northbound
direction,
just
in
case
on
the
pcc.
P
If
you
want
to
see
what
is
your
leaf
list,
the
pce
can
download
this
via.
We
are
the
tlv's
that
you're
looking
at
right
now
and
there
are
the
patterns
and,
as
I
explained,
there
are
two
path
instances
with
one
path,
instance
being
active
at
all
time.
Next
slide,
please
again
replication
segment
same
idea
as
unicast.
There
is
a
segment
list.
You
list
the
segments
under
that
segment
list.
Each
segment
list
can
be
a
oif
outgoing
interface.
P
There
is
a
concept
of
ecmp
via
the
bait
tlv
sub
tlv,
which
is
optional,
and
we
also
added
the
protection
segment
list
which
you
can
see
at
the
bottom
of
the
screen.
That
is
optional
too.
The
way
that
the
protection
segment
list
works
is
that
we
we
provide
a
protection
id
for
that
segment
list
which
can
be
used
by
the
primary
segment
list.
It
actually,
multiple
primary
segment
list
can
use
a
single
protection
segment
list
to
bypass
a
failure
throughout
the
network.
P
So
if
you
can
go
to
a
slides
now,
so
we
presented
this
in
best
again,
we
are
presenting
it
in
idr2.
One
point
I
want
to
put
into
on
the
table
is
that
this
is
transport.
This
is
underlay,
it
has
nothing
to
do
with
the
overlay.
You
are
just
trying
to
build
a
point
to
multipoint
three
via
this
draft,
so
this
is
why
we
thought
idr
is
the
best
place
to
home
this
draft,
and
obviously
we
are
looking
for
adaptation.
Q
G
M
P
The
replication
segments
can
be
connected
via
unicast
sr,
which
is
the
most
cases
that
will
be
the
case.
There
will
be
some
cases
that
the
replication
segments
are
connected,
hop
by
hop
node
by
node,
and
in
that
case,
obviously
you
need
to
have
this
pgp
session
to
every
router
that
wants
to
listen
to
this
nlri
and
there
are
times
for
replication
segment.
So
that's
another
thing
I
missed
in
in
the
in
the
presentation.
I
do
apologize,
the
point
of
multi-point
policy
with
the
canada
paths.
P
That's
only
on
the
original
on
the
head
endnote,
the
replication
segments,
which
are
the
forwarding
entities,
those
are
the
ones
that
need
to
be
downloaded
on
the
transit
note
and
on
the
leaf
node
and
on
the
root
node.
So
yes,
if
you
want
to
have
replication
segment
hop
by
hub,
then
obviously
you
need
to
have
bgp
session
to
every
one
of
those
pccs.
P
Yes,
definitely
slv6
is
there,
as
we
have
introduced
it
into
the
main
drafts
into
the
architectural
drafts,
the
replication
segment
and
point
to
multiplan
and
with
regard
to
the
interiors,
I
don't
see
why
not.
Obviously,
if
the
controller
has
the
view
of
the
entire
network,
then
you
can
go
over
enter
ies.
P
L
P
B
Thank
you.
Thank
you.
I
apologize
we're
going
to
cut
the
microphone
for
the
next
presentation.
Thank
you
for
presentation.
I
think
I'll
emphasize
from
the
presentation
that
we
just
had.
We
did
have
this
discussed
in
bess.
There
is
some
discussion
you
know
also
including
jeffrey
zhang,
with
an
overlapping
proposal,
and
that
content
is
definitely
worth
idr
listing
too,
because
it's
relevant
to
what
work
is
going
to
be
adopted
in
which
groups
and
exactly
how
the
work
overlaps.
R
R
R
R
R
Similarly,
the
this
document
describe
a
mechanism
to
distribute
the
information
of
isr-based
returns
to
the
network
controller
using
bgpls
with
multi
topology.
This
mechanism
describes
how
to
distribute
the
vt
topology
and
resource
attributes
to
network
controller
addition.
The
inter
domain,
topology
and
t
attributes
of
vtn
are
also
considered
this
draft
next
slide.
Please.
R
R
R
R
R
R
R
B
B
B
Q
Q
Q
If
one
is
aware
of
the
issue
and
aware
of
the
solution,
it
can
be
very
frustrating
in
network
operation,
as
I
had
if
you
are
not
aware
of
the
issue
and
at
because
this
random
is
non-deterministic,
so
that
the
the
issue
is
this,
we
have
basically,
in
our
you
know,
non-deterministic
behavior,
when
we
redistribute
a
backup
rod
into
pdp
the
back
eye,
the
primary
at
backup.
Of
course,
from
the
rudders
point
of
view,
it's
or
from
the
routing
table,
phipps
point
wheel
is
based
on
the
admin
distance.
Q
When
you
compare
different
rods
from
different
protocols,
you
use
admin
distance.
So
when
you
pro,
when
you
redistribute
this
rod,
it's
supposed
to
be
a
backup
when
it's
redistributing
to
bdp
it
depends
on
the
ordering
which
might
arise
first.
So
you
are
comparing
a
local
rod
versus
pdp
which
one
arrives.
First,
then
it
can
result
in
non-deterministic
past
election.
Q
So
basically
it's
a
the
the
root
causes.
Is
we
basically
have
one
conceptually?
There
are
two
tables
right,
one
is
the
rib
or
we
call
the
rotting
table,
which
is
where
you
group
rods
from
different
protocols,
and
you
use
admin
distance
as
a
tie.
Breaker,
and
then
you
have
a
pdp
table.
It
has
its
own
path.
Selection
address
as
we
are
all
familiar.
It
basically
starts.
We
look
with
the
local
breath,
there's
also
weight
that
is
sort
of
for
that
is
vendor
specific,
and
it's
also
there.
So
you
have
a
weight.
Q
Q
It's
it's
based
on
admin
distance.
It's
configured
back
up
once
it's
arise.
First,
you
know
before
the
bgp
rod
arrives,
it
gets
into
the
pdp
table.
Now
you
get,
you
are
going
to
compare
with
the
local
press,
with
asp
and
with
rgp
metric
and
also
in
a
lot
of
implementation.
You
have
a
local
rod
is
more
preferred
than
pdp
was
in
the
bdp
path
selection.
Q
Q
Q
Q
Basically,
certainly
we
know
the
admin
distance
deterministic.
We
know
that,
let's
start
with
by
basically
introduce
admin
distance
in
the
bdp
right
selection,
at
the
first
step
prior
to
the
local
prep
comparison
right.
What
about
what?
If
you
have
id
rbdp
lot
right?
This
is
a
bit
sort
of
I
described
we
described
as
the
network-wide
long-deterministic
behavior.
You
have
a
primary
and
one
location
on
one
router.
You
have
a
backup,
yeah
or
another
on
a
different
rod.
Q
So
this
is
where,
obviously
you
know
we
we
do
not
current.
We
do
not
have
any
way
to
actually
to
convey
the
admin
distance
or
the
sort
of
that
their
preference
directly
across
the
network.
Right
then,
we
basically,
but
we
have
something
else
in
bdp
that
is
called
local
pref
right,
so
we
can
use
local
pref
to
have
a
to
have
a
network
by
the
influence.
Q
So
the
I
the
proposal
here
is
that
when
you
redistribute
a
backup
right,
basically
you
make
sure
you
also
lower
the
local
breath
so
that
when
it's
propagated
through
bdp
now
it
will
have
a
network-wide
impact
so
that
sort
of
indirectly
you
will
have
the
primary.
You
will
have
backup
intentions,
be
owners
right
so
when
we
can
actually
do
one
step
further,
we
basically
it's
really
here.
Q
You
know
you
can
do
the
configuration.
Certainly,
if
you
ask
that
the
issue
you
add
standard
solution,
you
guys,
when
you
redistribute
you
can
set
your
weight,
you
can
set
your
local
frame.
You
can
do
all
these
things,
certainly,
but
here
most
people
really
this
kind
of
non-deterministic
behavior.
I
think
it's
actually
not
not
it's
it's
it's!
It's
it's
hard
to
understand
it's
hard
to
figure
out.
Why
why
you
know
we
can
do
better?
Certainly
I
think
the
default.
If
you
talk
about
the
default
behavior,
you
actually
can
calculate
the
local
press
automatically.
Q
Basically,
the
way
hear
the
aggregate
he's
a
pro.
It's
basically
proposed
in
the
draft
you.
Basically
when
you
you,
like
some
you,
like
the
the
back
of
your
network,
you
say:
okay,
this
is
my
secondary.
This
is
my
territory.
Typically,
you
don't
go
beyond
that,
but
also
algorithm
can
work
even
with
the
fourth
one.
You
basically
say:
okay,
you,
like
some
now
you
assign
a
offset
offset,
could
be
a
1020.
Q
It
doesn't
really
matter.
Then
you
basically
say
how
do
I
do
my
admin
distance?
This
is
something
you
have
to
do
elevate
because
you
have
to
compare
your
admin
distance
of
locally
the
local
rod
versus
the
one
that's
received
through
rbdp.
You
have
to
do
that
led.
You
know
to
provide
the
backup
capability
right,
so
you
basically
write
something.
You
basically
say
when
I
assign
my
admin
distance
for
the
background
for
the
backup
routes,
you,
basically
it's
the
admin
distance
plus
the
offset
offset
you
will
be
racked.
You
rank
some,
your
secondary
tertiary.
Q
You
are
something
that's
20,
10,
20
30,
for
example,
and
then
automatically
we
can
calculate.
You
know
admin
distance
right.
This
could
be.
They
don't
have
to
be
the
same.
It's
basically
in
a
multi-vendor
environment.
The
admin
distance
can
vary
from
one
router
to
another
rod.
It
doesn't
really
matter
as
long
as
you
follow
the
algorithm
there.
It's
going
to
be
whatever
admin
distance
for
ibdp.
I
have
on
this
router
you
apply
offset.
That
is,
that
is
administration
for
your
backup
right
then
you
basically
local
prep
is
local
press.
Q
Q
Q
Q
From
bgp
implementers,
basically
about
your
particular
implementation,
because
we
want
to
make
the
algorithm
sort
of
because
this
is
a
you
know,
it's
a
generic
problem.
We
want
to
make
the
solution
generic
as
well
right,
so
we,
some
of
the
comments,
are
not
reflected
in
the
other
two
versions,
so
we
may
expect
you
know
to
to
come
up
with
a
basically
a
revised
version,
03
with
further
clarification
and
editorial
changes.
B
Okay,
thank
you,
unfortunately,
we're
very
shy
on
time.
We
have
to
move
on
to
our
last
presentation.
I
do
urge
the
working
group
to
please
give
this
good
attention
changes
and
things
that
impact
route
selection,
such
as
local
pref,
you
know
being
set,
has
very
strong
impacts
on
route
selection
across
the
network,
and
we
want
to
make
sure
that
we
don't
have
unintentional
side
effects.
L
L
So
those
are
all
the
variety
of
use
cases
that
are
available
with
this
with
this
solution.
What
what?
What
sets
this
solution?
Aside?
That
from
what
exists
today
related
to
and
the
motivation
behind,
this
draft
is
being
able
to
filter
at
the
rv
level
versus
the
rt
at
the
rt
level,
where
we
have
an
offending
pe
that
has
that's
flooding
routes
and
being
able
to
have
that
granularity
to
filter
routes.
Just
from
that
particular
routes,
particular
pe.
That's
that
is
flooding
source
in
the
route.
L
So
what
this
this
solution
does
it
provides
that
mechanism
for
for
filtering
those
prefixes?
Something
that
doesn't
exist
today
would
so
when
just
to
highlight
against
existing
solutions
to
help
with
flooding
of
routes
that
it
goes
today
and
and
and
and
eyes,
are
recommended
in
the
draft,
and
we
have
them
listed
in
the
draft.
The
first
one
is
like
that's
a
pc
filtering
with
a
maximum
prefix
or
we're
doing
a
maximum
prefix
pervert
for
rtc,
and
those
are
all
recommendations
to
you
know
to
be
configured.
L
So
the
basic
framework
behind
this
with
this
raft
and
really
what
what
what
makes
this
solution
fairly
simple,
we've
discussed
this
on
this
quite
a
bit,
but
just
want
to
highlight
kind
of
the
solution
so
when
when
when
a
flood
happened,
the
flood
around.
So
let's
say
we
have
pe3
in
this
example
in
this
in
this.
L
In
this
scenario,
so
in
this
case
we
have,
we
have
the
common
rd
we've
configured
for
all
v
for
the
vpn
between
all
the
pe's
and
we
get
a
flood
of
routes
with
route
distinguished
three
one.
So
what
happens?
Is
pe
one
receives
that
and
it
has
multiple
verbs
dpn's
on
configured
on
him
and
he's
getting
a
flood
around.
So
what
he?
What
he'll
do
here?
L
If
you
have
multiple
vpns
and
certain,
you
can't
need
to
import
that
you
need
those
already
routes.
So
in
this
particular
case,
where
we
have
vpns
highlighted
in
its
and
it
can,
it
doesn't
require
the
the
route,
the
rd
routes,
even
even
by
filtering
it,
because
it's
it's
being
overloaded,
but
having
this
vpn
2
on
on
there
as
well
filtering
you're,
doing
an
rdrf
outbound
from
pe
one
towards
row.
Reflector,
it
doesn't
impact
vpn
2,
since
it
does
not
need
to
commute.
It
doesn't
need
the
routes
coming
from
rd31.
L
So
that's
a
real
and
that's
something
that
we
have
discussed
on
this.
So
it's
really
local
context
as
far
as
configuration
of
whether
when
to
use
it
and
when
not
to
use
it
on
the
bottom.
Here
we
have
vp,
we
have
pe
two
and
he
and
he
has
the
same
rt3
rt1
with
rd31
it's
being
imported
into
both
vpn
one
and
vpn.
So
all
the
vpns
are
all
the
vpns
on
pd2
are
being
flooded.
L
This
scenario
is
exactly
the
same
as
the
first
one,
basically
to
say
same
same
concept
that
you
have
a
flood
of
routes
coming
from
rd31.
In
this
case
it's
a
unique
rv.
So
it's
a
different
rd
per
pe,
but
to
say
same
concept
happens
that
you
hit
a
threshold
similar
to
a
maximum
prefix
threshold
on
p2.
It
actually
detects
the
the
triggers
the
rd
rf
outbound
and
then
the
round
reflector,
that's
installed
in
the
adjacency
gray
ballot
towards
pe
two
next
slide.
L
In
in
this,
in
this
scenario
as
well,
so
this
is
in
trias
with
a
universal
party,
so
you
have
this
same
rd
configured
between
all
different
rds
configured
between
all
the
pe's.
So
in
this
case
what
happens
is
vpn
on
pe
one?
I'm
sorry
on
p2.
It
just
has
one
vpn
on
it
and
he's
importing
the
the
offending
defending
rv
from
p3
rd1
related
to
rt1.
So
he
ends
up
installing.
L
He
ends
up
sending
into
a
rdr
afterwards
around
flector
and
then
the
route
reflector
installs,
the
adjacency
grip
out
towards
b2.
However
pe
one
it
only
has
it
has
vpn
one
configured,
but
it
also
has
another
vpn
that
requires
required
routes.
So
pe
one
does
not
send
an
adjacency
red
valve.
To
is
sorry
sending
does
not
send
an
rdrf
toward
the
right
reflector.
So
so
the
local
local
context
of
the
configuration
is
really
dependent
and
that's
part
of
the
operating
discretion.
L
P2
all
the
vpns
are
being
flooded,
but
pe
one,
only
two
of
the
three
vpns
are
being
flooded,
but
vpn
2,
it's
not
being
flooded,
but
it
it.
It
doesn't
need
to
communicate
with
with
rd31.
So,
even
if
rd31
is
dropped,
it's
not
going
to
impact
vpn
2..
So
here
both
pe
1
and
p3.
They
both
p2.
They
both
send
an
rd
rf
outbound
to
the
asbr,
and
now
the
asbr
he's
taking
the
next
step.
Since
all
the
downstream
pes
do
not.
L
So
they
already
our
message.
It
follows
the
following
condition.
So
what
we've
talked
about
it's
on
the
pe
as
long
as
all
the
verbs
you
know
do
not
require
the
round
distinguished
the
pe,
that's
actually
flooding
the
routes,
then
we
send
the
rdrf
outbound
and
then
on
the
route.
Reflector
same
goes
that
as
long
as
all
the
bdp
clients
don't
need
to
process
that
probably
the
rd
defending
rd
and
then
the
sbr.
The
same
thing
does
the
sbr
all
the
bgp
peers
within
the
as
don't
need
to
receive
it.
L
Then
it's
then
it
propagates
it.
So
in
that
scenario
that
we
that
we
went
through
on
the
previous
slide
once
all
the
p
as
long
as
all
the
pe's,
within
that
local
ais
do
not
need
to
receive
the
defending
rd
that
aren't,
that
rdrf
is
the
via
the
route
refresh
is
propagated
from
from
one
as
to
the
other
to
be
installed
only
on
the
adjacent
asbr
within
the
mother.
As
the
removal
withdrawal
process,
it's
manual
just
to
promote,
avoid
any
possible
flopping
issues.
That
could
possibly
happen
next
slide.
L
So
I
think
the
the
goal
of
this
for
the
presentation
today
was
really
we've
had
a
lot
of
discussions
on
lists
and
I'm
hoping
that
during
today's
discussion
just
going
over
the
draft,
I
clarified
any
misconceptions
and
I
think
any
gaps
that
exist
with
this
draft
and
if
there
are
any
we'd
like
to
address
those,
but
we
feel
the
alters.
We
feel
that
this
draft
is
has
matured.
We've
provided
a
lot
of
updates
to
draft,
and
we
feel
that
it's
all
ready
for
adoption.
Thank
you.
B
B
L
I
am
good,
thank
you.
Thank
you,
jeff
jeffrey,
you
know
on
the
next
call.
I
know
I
had
one
more.
That
was,
I
think,
wasn't
it.
I
wasn't
able
to
discuss
because
we
ran
out
of
time.
Do
you
think
on
the
next
session
we
may
have
some
time.
I
guess
if
we
do,
if
I
can,
you
know,
discuss
that
last
item
that
we
weren't
able
to
discuss
that
yeah.