►
From YouTube: IETF108-IDR-20200731-1410
Description
IDR meeting session at IETF108
2020/07/31 1410
https://datatracker.ietf.org/meeting/108/proceedings/
B
A
A
I
was
just
gonna
say
we'll
start
with
the
the
notewell
which
all
of
us
have
have
seen,
of
course,
but
you
know
it's
important
that
you
have
reviewed
this
at
some
point
and
that
you
are
reminded
right
now
that
by
participating
in
this
meeting,
you
are
deemed
by
the
ietf
to
have
agreed
to
all
of
this
stuff.
If
you
don't
know
what
it
means,
maybe
you
should
talk
to
your
attorney
about
it.
They
can
advise
you,
I
sure
can't.
B
B
If
you
ask
for
a
working
group,
last
call
I'll
try
to
catch
her
in
the
notes
and
I'll
send
out
a
list
immediately
after
the
meeting
to
the
list.
Send
me
a
note.
The
only
important
big
document
is
bgp
yang
document
is
starting
working
group
last
call
it's
going
to
the
yang
doctors
first
and
the
ipr.
Is
there
look
we're
going
to
be
short
on
time
today.
So
I'll
be
brief,
we're
going
to
need
interims
for
several
of
our
discussions.
B
B
B
B
If
we
don't,
if
you
couldn't
make
a
comment,
vm
video
use
the
chat,
we'll
copy
the
chat
blog
and
send
it
to
the
list.
If
you
couldn't
hear
the
presenter,
try
the
youtube
video,
if
you
could
not
help
with
the
meeting
minutes.
Well,
that's
not
r
I'd
love
to
help
you
the
next
time
for
the
intra
minutes.
That's
a
bit
of
a
news,
flash
there's
a
channel,
that's
it!
We
have
a
short
meeting
first,
I.
B
D
D
D
D
Oh
okay,
in
the
scenario
shown
in
the
figure
p,
is
established.
Ibgp
sessions
with
rr
to
ensure
the
use
can
be
transmitted
within
as100,
where
p1
to
p4,
maintain
vpn,
routine
information
and
rr.
Don't
maintain
any
vrf's
one's
aware
of
vpn
one
in
p2
overflows
do
2,
p2
and
other
pes
are
not
ipgp
neighbors
bgp.
Maximum
prefix
features
cannot
work,
so
the
problem
on
p2
cannot
be
known
next
slide.
A
D
D
D
When
r
receives
the
message,
it
checks
whether
it
receives
the
latest
entry
or
not.
If
not
r
will
discard
the
entry,
otherwise
r
will
add
it
into
is
adj
reap
out
r
determines
whether
this
rdrf
entry
should
be
sent
to
p3
locally.
If
necessary,
rr
will
regenerate
a
bgp
root,
refresh
message
to
send
this
entry
to
p3.
D
D
D
E
Could
you
hear
me
yes,
so
john?
Could
you
go
to
slide
number
five?
I
just
a
single
domain
case.
I
quickly
want
to
ask
a
question
today,
so
we
here
you're
saying
when
pe
one
is
in
overflowing
situation,
it
is
going
to
send
a
message
to
rr
and
rr
will
further
send
it
to
source
pe3
right,
but
when
pe3
initially
injects
a
vpn
prefix,
that
is
also
meant
for
pe2
and
pe
one.
But
pe
two
is
not
overflowing
right.
E
D
E
A
F
Yeah
good
morning,
folks
I'll
make
it
very
quick,
two
comments,
one,
the
back
pressure.
All
the
way
to
the
pe
may
not
be
required.
Rrs
these
days
have
infinite
memory
and
cpu.
You
don't
need
to
back
pressure
it.
The
second
thing
is:
there's
a
reason
why
we
do
attribute
based
filtering
using
route
targets,
because
that
brings
some
level
of
common
commonality,
which
is
not
always
guaranteed
by
looking
at
at
the
rds
and
the
prefix
level.
Filtering
is
always
proven
more
expensive,
so
I
don't
know
if
this
is
a
good
idea.
G
G
We
already
presented
this
draft
in
during
the
last
interview
meeting
and
just
a
quick
review
of
the
background
and
motivation.
So
we
see
to
flow
information.
Telemetry
refers
to
network
applications,
the
most
popular
are
imbando
im
in
c2rm
and
alternate
marking,
and
you
can
see
the
reference
documents
for
for
these
on
path:
telemetry
techniques.
G
G
We
got
some
feedback,
but
on
during
the
that
presentation,
but
also
offline
regarding
the
companion
document
in
pc,
in
particular
the
main
questions
about
the
applicability.
So
we
clarified
that
this
bgp
extension
allows
justification
capabilities
together
with
dsr
policy,
so
regarding
the
flexibility
of
dynamicity
or
and
closed
loops,
closed,
look
things.
These
are
out
of
scope
because
we
may
use
additional
function
on
the
controller
and
network
nodes
like
young
models
and
so
on,
to
address
this
kind
of
flexibility
and
dynamics.
G
This
it
attribute
can
be
extended
and
generalized
also
as
stop
tld
to
for
other
sap
and
nla,
but
just
to
make
just
to
be
clear
that
now
we
are
focusing
on
sr
policy,
since
the
compat
telemetry
techniques
are
becoming
mature
for
this
kind
of
technology
like
a
segment
routing
srv6,
so
you
can
see
the
reference
document
that
are
all
adopted
document
and
also
the
relevant
document
for
the
control
plane.
So
that's
why
we
focused
only
on
sr
policy.
G
G
G
Yeah
here
we
can
see
the
details.
Are
the
sub
the
different
subtle
d,
the
so
the
I
am
pre-allocated
threes
option,
the
incremental
trace
option,
the
directly
export
option
and
the
h2
edge
option.
This
came
from
the
the
inband,
I
am
document,
so
it
just.
We
take
the
information
and
we
build
this
subtle
v
from
the
relevant
document
of
the
inventory
next
yeah.
The
same
applies
to
alternate
marking,
so
you
can
see
the
relevant
field
from
rfc8321
and
multipoint
ultimate
draft,
and
also
in
this
case
we
are
defining
the
subtle
b.
G
Next
slide,
I
think,
is
the
last
one
and
yeah
we
want
to
collect
feedbacks
about
about
this
draft.
We
also
asked
the
group
to
evaluate
the
adoption,
consider
the
anchor
adopted
work
both
in
in
this
working
group
and
also
the
related
working
group
on
telemetry
and,
of
course,
the
questions
and
comments
are
welcome.
H
H
The
idea
is
that
two
big
mass
raw
targets
match
if
the
result
of
logical
end
operation
of
the
bitmaster
is
not
zero
and
that
match
is
used
to
control
route,
importation
and
also
route
propagation.
When
you're
using
the
raw
target
constraint
mechanism
I'll
quickly
talk
about
the
use
case.
For
for
these
neural
targets
there
there
could
be
other
use
cases,
but
this
is
the
one
we
we
have
for
now.
So
flexible
algorithm
is
a
way
to
do
a
multi,
topology
or
network
slicing.
H
H
H
We
put
into
this
bitmap
without
target
and
let's
say,
say
that
you
have
a
link
that
has
a
red
and
blue
link
color
configured
and
then
the
raw
target
will
have
the
two
bits
corresponding
to
red
and
blue
set
in
that
raw
target.
And
then,
if,
let's
say,
if
a
router
cares
about
that
red
and
blue
link
attribute
of
that
particular
link,
then
you
would
have
a
local
bit
mask
raw
target
configured
with
those
bit
sets
with
that
and
with
the
semantics
of
b
must
well
target.
H
H
H
We
would
introduce
a
new
type
of
the
community
container
for
our
big
mass
rail
targets.
We
also
added
a
global
administrator
and
local
administrator
and
those
would
need
to
match
as
well
so
there
there
will
be
a
google
global
administrator
type
and
the
lens
so
that
you
can
use
as
based
or
ipv
address
space
or
with
six
address
based
things
like
that,
and
a
local
administrator
is
just
like
what
we
had
before,
with
regular
extended
community
based
raw
targets
and
then
followed,
but
following
that
is
the
bid
mask
next
slide
please.
H
So
we
mentioned
that
the
bitmap
route
targets
would
make
use
of
the
raw
target
constraint,
infrastructure
and
obviously
because
of
this
new
community
container-based
new
raw
targets.
We
need
to
extend
the
rtc
mechanism
and
in
fact
that
is
already
there
was
already
a
spec
about
extending
it
to
ipv6,
address
specific
raw
target
constraint.
H
The
idea
is
that
the
if
the
we
just
put
the
oh
okay
I'll
I'll,
skip
the
idea,
the
the
prop
that
there
existing
problem
with
that
solution,
that
if
the
prefix
in
the
rtc
membership
roi,
is
not
more
than
12
octanes.
Now
you
cannot
tell
if
the
raw
target
part
is
a
partial
ip
address,
address,
specific
rail
target
or
a4
or
partial,
as
or
ipv4
address
specific
raw
target.
H
In
fact,
for
that
solution,
if
we
you
could
use
if
we
use
the
fe
number
two,
that
problem
could
have
been
solved,
but
even
with
that,
it
would
not
work
with
the
new
types
of
raw
targets
got
it
yeah.
So
the
proposed
solution
is
that
we
define
a
new
selfie
for
a
general
rtc
membership.
Next
slide,
please
so
with
this
new
sephie
that
the
nri
format
will
be
compared
to
before
we
have.
H
Next
slide,
please
so
we
I
just
presented
a
general
idea.
We
seek
the
comments
and
also
I
want
to
point
out
that,
while
the
new
safety
also
work
for
ipv6
address
specific
rtc,
it
is
not
the
intention
to
replace
the
existing
spec.
I
because
it's
current
status
and
possible
implementation
and
deployments.
H
We
do
want
to
say
that
we
basically
have
two
ways
to
to
to
to
do
the
ip
v6
address,
specific
rtc
and
but
I
do
have.
We
do
have
a
quest
side
question
for.
Why
could
we
just
use
fe
number
two,
but
that's
ipv6,
address
specifically
I'll
type,
your
constraint
so
I'll
open
for
questions
and
comments.
Now.
C
H
C
H
C
I
H
I
Covering
current
prefix
or
if
because
that
of
e10
extension,
is
not
use
a
new
selfie,
so
why
do
I
want
to
know
why
not
to
use
that
way?
Because
now
I
see
your
attention
that
you
also
don't
have
the
the
the
roads,
don't
have
efi
and
exactly
for
specified
road.
So
the
receiver
received
the
road
target
roads.
He
don't
know
which
agile
family
want
to
use
the
the
road
to
that.
Let's,
let's,
let's
send
the
send
roads.
H
J
J
He
has
vpn
as
defend
in
draft
itfts.
Enhanced
vpn
aims
to
provide
enhanced
vpn
service
to
support
applications,
needs
of
enhanced
isolation
and
stringent
performance
requirements.
Vtn
is
introduced
in
as
virtual
underlying
network
with
required.
Topology
and
resource
characteristics
drop
down,
idr
bgpr
sr,
enhanced
vpn
defense,
the
bgpis
extension
to
distribute
the
information
of
segment
routine
based
ratings
to
external
entities
such
as
the
network
controllers
resource
awarenesses,
are
introd
introduced
to
build
resource
guaranteed
as
our
virtual
networks.
J
J
J
I
enhanced
vpn
service
is
a
vpn
service
with
additional
commitments
such
as
resource
isolation
and
performance
guarantee.
It
supports
the
needs
of
a
new
applications
that
cannot
be
provided
with
traditional
overlay.
Vpns
virtual
network
virtual
transport
networks
is
a
virtual
network
which
has
a
customized,
topology
and
a
site
of
network
resources
allocated
from
underlying
network
to
meet
the
requirement
of
enhanced
vpn
services.
A
number
of
virtual
transport
networks
needs
to
be
created
and
we
team
provides
the
required
underlay
characteristics
for
one
or
a
group
of
vpn
plus
services.
J
Please
there
are
three
bgprs
mechanism
in
this
draft.
The
first
one
is
intro
domain
topology
advertisement
mt
mtid
tla
is
used
in
bgpi's
link,
descriptor,
node,
descriptor
and
bgpr's
attributes
to
identify
the
topology
of
the
link
state
information
advertised
topology
specific
seeds
can
be
advertised
using
bgpr
sr
or
srv6
extensions
mechanism.
J
Mtid
needs
to
be
constantly
used
in
each
domain
and
on
interdominic.
The
third
one
is
advertisement
of
per
topology
key
attributes.
One
link
can
participate
in
multiple
topologies
how
to
advertise
topology
specific
t
attributes
is
specified
in
this
document.
As
we
know,
the
information
of
network
resources
associated
with
a
vtn
can
be
specified
by
carrying
the
linkedin
attributes
here
with
which
defined
in
rfc
7752
in
bgpr's
attribute
with
the
associated
mtid
current.
J
J
Skip
scalability
considerations
were
included
in
this
draft
ads
will
ring
a
link
or
a
prefix
participate
in
multiple
topologies.
Multiple
in
our
eyes
need
to
be
generated
to
report
all
the
topologies
that
a
link
of
prefix
participating
together
with
the
topology
of
specific
segment
routing
information.
J
J
J
H
H
The
the
ts
draft
that
someone
mentioned
earlier
when
I
did
my
presentation,
is
actually
designed
to
solve
some
of
the
problems
we
pointed
out
and
the
bitmaster
attacker
is
used
to
to
help
with
that
with
that
as
well.
So
I
think
we
can.
We
can
talk
offline
further
on
on
possible
collaboration
consolidation
here.
A
B
K
K
Exercise
slider,
please,
okay
and
firstly,
useful
spec
for
traffic
stereo
now
is
used
more
and
more
especially
into
dorman
scenario
for
the
channel
mobile
network.
We
faced
a
problem
that
the
traffic
of
game
services
is
very
sensitive
to
the
network.
Valencia
and
the
the
problem
is
that
on
how
to
still
move
traffic
into
the
sr
research
policy,
so
this
drive
to
propose
a
solution
to
do
so.
K
K
K
K
K
L
Hey
this
is
jeff
highs,
juniper
networks.
I
need
to
look
through
your
draft,
but
as
one
of
the
authors
on
the
redirect
ip
internet
draft,
one
of
our
pieces
of
experience
where
this
is
a
little
challenging
to
be
well
specified,
is
that
you're
specifying
more
than
one
community
in
combination
causing
the
actions
to
happen.
You
need
to
be
very
clear
how
this
interacts
with
all
the
other
various
redirect
features.
That
flowspec
has
that's
my
comment.
Thank
you.
M
B
K
A
A
N
Hi
this
is
shooping.
I
am
going
to
present
this
big
prs
extensions
for
advertising
next
slice
piece
and
first
about
the
motivations
and
the
in
mprs,
and
we
know
the
past.
Mtu
can
be
signaled
where
the
protocols
like
r3pte,
but
in
isr
networks.
There
is
no
such
negotiation
mechanisms
for
the
past
mtu
and
basically
in
the
isr
network.
That's
our
information
is
reported
by
the
bgprs
and
then
the
isdn
controller
can
calculate.
N
That
is
our
path
based
on
those
information,
and
we
also
know
that
when
we
start
pushing
the
seed
either
label
or
ipv6
addresses
into
a
packet.
The
package
size
is
going
to
be
increased
and
once
the
packet
size
exceeded
the
path
mtu,
the
packet
is
going
to
be
dropped
in
ipv6
or
fragmented
and
from
the
operators.
N
N
N
N
So
it
already
defines
the
trv
that
map
the
link
state
information
to
the
bgprs
and
our
now
ri
and
attributes.
So
in
this
document
we
will
define
a
new
subtree
for
the
link,
mpu
and
then
added
to
the
link
attribute.
Trv
is
the
format
is
like
this
and
we
actually
reuse
it
and
then
so.
Whenever
there
is
a
change
in
the
mtu
value
and
the
bgprs
will
put
the
new
value
into
this
drv
and
then
the
con,
the
controller
can
recalculate
the
path.
Mdu
masterpiece.
B
N
For
collecting
the
link
mtu
and
in
this
version-
and
we
we
change
it
to
so.
Actually
we
refer
to
this
existing
rfc
and
7176
to
specify
the
easiest
extensions
for
this
link,
mq
next
piece
so
next
step.
So
basically
it's
all
about
this
diagram
at
the
bottom,
and
so
the
link
mtu
are
generally
collected
via
the
ez's
or
igp
mechanisms,
and
then
it
will
be
delivered
to
the
controller
via
the
bgprs.
N
So
after
the
calculation
inset
controller,
the
pass
mtu
will
be
delivered
to
the
network
headend.
So
here
correspondingly
and
so
for
delivering
the
past
mtu.
We
have
the
draft
it's
already
adopted
in
the
idr,
so
that
is
for
the
to
define
the
extensions
to
bgp
and
to
distribute
the
past
mtu
information
within
the
isr
policy.
And
here
the
draft
we
are
presenting
actually
specifies
the
extensions
to
bdprs
to
carry
the
link
mtu
so
here,
and
we
would
like
to
call
for
adoptions
for
this
draft.
Thank
you.
That's
all
any
questions.
O
N
N
Yes,
that
is
true
and
for
the
second
question
is
here
the
mtu
and
basically
we
meant
for
the
link
mtu
and
in
the
existing
rfcs,
so,
for
example,
to
rc8201
and
there
there
is
already
the
link
came
to
you.
The
definition
for
this
link
mtu.
That
is,
the
the
minimum,
the
the
maximum
pack
size
that
can
be
carried
within
the
over
the
link
so,
and
that
has
actually
depends
on
the
package
size
so
and
then
for
different
data
plane.
N
It
has
different
meanings
and
for
the
sr
srmprs
and
srv6
there
will
be
different
way
to
calculate
so
for
the
amperes.
There
is
another
draft,
so
we
can
refer
to
because
that
will
plus
the
so
ip
header,
plus
the
payload
and
then
the
label,
so
they
have
different
ways
to
calculate
and
in
the
rfc
existing
rfc.
The
link
mtu
generally
in
iatf
means
the
ipmpu,
okay
hope.
So
I
we
realized
that
there
will
be
it
needs
to
clarify.
N
N
B
A
O
A
M
M
Yeah,
so
what
is
the
problem
being
solved?
So
any
network
which
is
a
bgp
free
core?
It
has
multiple
domains
and
a
domain
has
intra-is
tunnels
and
those
tunnels
could
be
classified
into
varying
d
characteristics
based
on
what
are
their
properties.
We
can
just
call
them
gold,
silver,
bronze,
and
these
tunnels
could
be
between
multiple
destinations.
They
could
be
multiple
tunnels
to
the
same
destination
and
different
protocols
could
be
creating
these
tunnels,
and
these
tunnels
could
also
be
extending
multiple
domains.
M
They
could
be
inter-domain
tunnels,
and
it
would
be
good
if
we
can
preserve
the
t.
Characteristics
end
to
end
for
the
inter-domain
tunnel
and
irrespective
of
whether
my
service
endpoint,
is
in
the
same
domain
as
I
am,
or
it
is
in
the
adjacent
or
a
domain
beyond
it.
If
the
service
routes
are
able
to
resolve
or
put
traffic
over,
these
tunnels
offer
certainty
characteristics
such
that
the
t
characteristic
is
present,
preserved
end-to-end.
M
That
will
be
good,
so
the
service
routes
want
this
behavior,
where
they
want
to
be
able
to
resolve
over
a
tunnel
of
a
certainty
characteristic
with
option
of
falling
back
to,
let's
say
a
best
of
our
tunnel.
So
these
are
the
requirements.
And
how
do
we
achieve
this?
How
do
we
extend
bgp
to
signal
these
piece
of
information
so
that
it
can
get
done
in
the
intra
ies
case
and
the
intel
as
case?
So
that's
a
problem
statement.
M
So
here
we
show
you
an
inter-domain
network
which
has
like
three
domains
and
each
domain
is
classified
by
where
we
do
bgp
next
top
cells.
So
we
show
two
asses
as1,
as2
and
as2
has
two
regions
inside
and
at
abr
two
two.
We
are
doing
bgp
next
top
stuff,
and
this
is
like
a
bgplu
network.
It's
like
a
classic
option
c,
and
we
see
that
in
each
intra
airs
domain
we
have
gold
and
bronze
lsps,
the
lsp1
and
lsp2,
and
there
is
a
best
of
internal
lsp3.
M
M
So
how
do
we
solve
this
and
what
are
the
constructs?
We
are
introducing
in
bgpct
to
solve
this.
So
when
we
say
we
are
grouping
the
tunnels
using
t
characteristics
so
that
we
are
calling
it
as
a
transport
class,
so
any
tunnel
can
be
classified
as
belonging
to
a
certain
transport
class
and
these
tunnels
could
be
signaled
by
rsvp
or
srt
or
flex
algo
or
any
different
tunneling
mechanism,
and
we
identify
the
transport
class
on
the
wire
using
a
route
target.
It's
called
the
transport
class
route
target.
M
M
So
it's
a
way
of
advertising
the
routes
to
the
other
domains
and
saying
these
tunnels
belong
to
this
particular
transport
class
and
for
the
for
the
case
of
there
could
be
multiple
tunnels
to
the
same
destination.
We
just
use
the
road
distinguisher
to
distinguish
them
and
to
advertise
them
without
path,
hiding
and
also
allowing
identifying
the
originating
pe,
and
so
these
are
like
mechanisms
of
4364.
M
That's
plain
bgp
vpns.
We
are
reusing
it
at
the
transport
layer
here
and
for
extending
the
tunnel
to
other
domains
while
preserving
the
same
transport
class
end
to
end.
We
need
to
do
two
things.
One
is
option
c
style
procedures
to
do
the
label
swap
and
we
need
to
resolve
the
protocol
next
top
of
the
received
route
using
a
set
of
routes
which
belong
to
the
same
transport
class.
M
So,
basically,
today
what
we
would
do
is
we
would
resolve
it
over
any
tunnels
that
are
available
so
which
will
include
best
of
our
tunnels,
gold,
tunnels
and
bronze
tunnels.
So
here,
because
we
are
giving
an
identification
of
these
tunnels
belong
to
a
certain
transport
class,
so
the
receiving
speaker,
he
organizes
the
tunnels
of
a
certain
transport
class
in
a
separate
database
and
for
resolving
routes,
transport
routes
which
are
received
using
that
transport
class
route
target.
M
He
uses
only
these
tunnels,
so
this
allows
to
preserve
the
transport
class
end-to-end
across
domains,
and
this
information
is
being
used
in
the
new
bjp
family,
which
is
nothing
but
a
new
safi.
It's
safety,
76
called
class,
full
transport,
and
this
this
address
family.
It
follows
4364
procedures
and
there
will
be
ipv4
and
ipv6
versions
of
this
so
that
we
can
carry
v4
tunnels
and
also
v6
tunnels
in
the
same
way
and
the
service
routes.
So
so
far,
what
we
talked
about
was
at
the
transport
layer.
M
Now,
with
the
service
routes,
the
service
dogs
want
to
resolve
using
a
concert
called
a
resolution
scheme.
What
is
a
resolution
scheme?
It's
basically
saying
that
we
want
to
resolve
over
certain
transport
laps
with
an
option
to
fall
back
to
a
different
transport
class.
So
what
a
resolution
scheme
means
it's
a
kind
of
local
definition
of
the
speaker,
but
the
service
route
carries
something
called
a
mapping
community,
which
indicates
which
resolution
scheme
that
service
route
wants.
M
So
those
community
gold
and
community
brands
are
the
mapping
communities
and
they
will
resolve
over
respective
the
gold,
lsps
or
bronze
lsps,
and
the
reachability
to
the
gold
lsps
are
bronze
lsps.
Basically,
the
lsp
in
the
first
domain
in
as1
is
advertised
up
to
pe
to
one
using
the
right
transport
class
route
target
so
that
they
are
visible
to
pe
to
one
with
the
right
transport
class.
M
So
this
is
just
a
sneak
peek
of
the
pcap,
so
you
can
see
that
it
is
very
similar
to
an
l3
vpn
update.
You
have
the
rd,
you
have
the
route
target
and
it
just
instead
of
one
slash
128,
it's
just
one
slash
76.
So
it's
just
to
show
how
we
are
reusing,
l3,
vpn,
family
and
everything
else
will
follow
next
slide.
Please.
M
So
the
advantage
is
here,
so
we
see
that
each
intras
domain
there
could
be
various
different
running
protocols.
It
works
with
any
of
them
and
also
at
the
service
layer.
It
works
with
any
of
the
service
families
for
v4,
v6,
l3,
vpn,
even
flow
spec,
so
flow
spec.
Also,
we
can
consider
it
as
when
we
receive
the
redirect
ip
next
stop
with
external
color
community.
M
A
A
M
Yeah,
I
just
have
one
more
slide:
maybe
I'll
finish
that
and
wait
for
the
question
so
of
using
the
route
target
constraint.
We
could
have
a
mechanism
such
that
the
ingress
pe
when
he
receives
the
service
routes,
l3
vpn
routes
he
can
discover
which
protocol
next
hop
he
wants
and
what
are
the
transport
classes
he
wants,
and
he
can
request
the
next
rtc
routes
for
those
next
stops,
so
that
now
he
gets
the
ct
route
for
only
those
next
stops.
M
M
B
M
L3Vpn,
even
so,
the
main
thing
was
like
color
is
an
adjective:
it's
not
a
noun
so
carrying
it
as
an
attribute
made
more
sense
and
the
route
target
already
in
the
l3
vpn
world.
We
use
it
like
colors,
it's
like
membership,
so
that
is
why
we
modeled
the
transport
class
as
route
target
and
rd
is
the
right
route
of
distinguisher
a
distinguisher
end
to
end
at
path.
Id
is
like
per
session
scope.
M
It's
like
rd
is
having
a
different
rd,
will
cause
a
new
label
getting
allocated,
but
at
path
id
is
an
like
a
end
result.
If
you
have
a
new
label
to
advertise,
then
we
use
a
new
add
path
id.
So
I
think
both
of
them
are
required
of
in
this
mechanism
either.
One
of
them
is
not
enough,
so
we
use
the
rds
identifier
and
whenever
we
cross
as
boundaries,
where
you
have
multiple
abrs,
just
like
the
option
b,
l3
vpn
case,
we
use
at
path.
B
M
To
carry
the
transport
routes
and
to
point
to
be
noted,
that
is
even
today
we
do
that
when
we
use
careers
career
in
careers,
career
deployments,
we
carry
transport
routes
in
health,
review
and
family,
but
it
then
figured
out
it
may
be
operationally
simple
and
required
to
actually
have
a
different
l3
vpn
like
family,
which
is
playing
in
the
same
level
as
lu.
So
the
reasons
are
because
the
route
propagation
path
for
transport
routes
is
different
from
service
routes.
They
have
to
do
hub
by
hop
instead
of
going
on
a
multi-hop
ebgp
session.
M
So
separating
them
out
in
a
different
family
is
good.
Also
behaviors,
like
per
prefix
label,
can
be
given
for
transport
routes
which
are
like
lower
scale.
So
if
we
separate
out
these
transport
routes
in
the
new
family,
it's
a
good
in
that
sense
also.
So
thus
we
have
this
new
safi
76,
it's
just
a
transport
family
that
can
signal
transport
class
also,
so
it
will
kind
of
have
all
the
properties
of
bgplu
and
a
little
more.
M
B
John
I'm
reading
robert's
question.
Today
a
transport
class
can
be
embedded
in
the
sid
here
we
are
opening
up
to
explicit
signaling.
I
understand
you
may
want
to
support
our
rsvpe,
but
I'm
not
sure
if
this
extra
complexity
is
really
needed.
Second
question:
I
like
the
new
sapphi
separation.
If
we
go
for
that,
I
recall
that
bgp
3107
had
discussions
about
it
too,
just
not
sure
if
we
need
it
if
we
are
up
to
sr
everywhere
paradigm,
that's
his
comments.
Hopefully
that
was
helpful.
Robert.
M
About
the
thing
about
sr
everywhere,
so
I
don't
know
we
just
want
to
create
technologies
which
work
with
any
tunneling.
It
doesn't
have
an
assumption
of
a
particular
type
of
tunnel,
so
it
works
with
sr
also,
but
it
works
with
other
deploy
technology
that
we
have
today
or
even
new
type
of
tunnels
that
may
come
in
future.
So
that
way,
I
think
it
is
good
to
have
a
layer
which
is
not
having
assumptions
about
any
specific
transport
tunnel
or
a
service
family
and
about
three
about
the
3107
new
family.
M
C
M
A
Okay,
anything
further,
okay,
well
through
some
miracle,
and
by
miracle
I
mean
thank
you
speakers
for
all
sticking
to
your
time
slots.
It
worked
really
well,
we
do
have
some
extra
time.
We
have
one
request
for
a
presentation
that
we
couldn't
fit
in
and
it
seems
that
we
can
so
jeffrey.
Please
put
yourself
in
the.
H
H
H
H
Now
for
multicast
we're
proposing
some
extensions
to
the
tea
and
in
particular,
when
a
tea
is
attached
to
a
multicast
route,
then
the
matching
traffic
will
be
replicated
out
of
the
listed
tunnels.
It's
not
that
you
will
be
sending
traffic
either
one
of
the
tunnels
you're
sending
the
traffic
out
of
all
the
lists
with
the
tunnels.
H
H
The
first
new
tunnel
type
is
any
encapsulation
panel.
Today,
all
the
tunnel
types
are
associated
with
the
encapsulation
type,
for
example
ipip
or
mpos
or
whatever,
and
now
this
new
one
just
means
that
I
don't
care
what
kind
of
time
it
is.
I
only
need
that
way
to
get
to
the
remote
endpoint
address
that
is
listed
in
the
in
the
sub-glp.
H
H
Each
tunnel
will
have
the
downstream
interface
address,
encoding,
remote
endpoint,
address
remote
endpoint
address
sub
glb,
and
then,
when
you
send
that
route
with
that
pa
to
the
upstream
router,
the
upstream
router
will
go
through
the
tunnel,
will
know
that.
Okay,
I'm
I
I
can
send,
I
need
to
replicate
traffic
to
out
of
these
specific
interfaces.
H
Well,
no,
I
shouldn't
say
I
yeah
in
the
ip
multicast
case.
That
will
be
the
interface
address
so
now
another
situation
is
laid
for
both
native
and
labeled
multicast
forwarding,
where
traffic
needs
to
be
tunneled
from
upstream,
though
now
edges
and
downstream
nodes.
But
again
it
does
not
care
which
tunnel
you
use
any
available
tunnel,
be
the
mpos
or
srte
or
or
gre
whatever,
so
any
tunnel
type
or
tunnel
instance
can
be
used.
So
that's
where
this
new
talent
type
comes
into
play
next
slide.
H
Please
another
title
type:
we
call
the
load
balancing
tunnel
consider
this
situation.
You
have
m
ways
to
reach
a
downstream
node
from
the
upstream
node,
and
the
controller
says
that
out
of
those
m
ways,
I
want
you
to
use
of
the
n
ways
to
to
send
it
to
downstream
node.
Now,
in
this
case,
you
cannot
use
any
in-cap
tunnel,
because
if
you
do
so,
then
all
m
weights
could
be
used.
H
So
for
that
purpose
we
will
use
this
low
balancing
tunnel.
The
low
balance
internal
also
lists
a
few
tunnels,
just
like
the
ta
itself.
So
this
low
basin
tunnel
itself
is
a
member
of
a
tea
that
is
attached
to
the
multicast
route.
So
now,
when
the
traffic
comes
in
and
matches
the
particular
routes
with
this
gea,
the
traffic
will
be
replicated,
although
all
the
member
tunnels
of
the
ta,
while
the
member
tunnels
could
be
a
low
balancing
tunnel.
H
So
this
is
a
new
sub-tree
we're
proposing.
So
if
you
consider
unique
unidirectional,
multicast
traffic,
the
folding
state
will
include
the
upstream
and
advance
your
downstream
and
including
downstream
in
the
timing.
Encapsulation
attribute
is
quite
natural,
but
it
turns
out
that
including
encoding
upstream
information
in
the
ta,
it's
now
is
also
quite
reasonable
and
convenient
to
do
so.
All
you
need
to
do
is
just
to
add
a
subtitle
that
means
that
this
tunnel
in
this
ta
is
actually
for
upstream
and
for
incoming
traffic.
H
So
even
though
we
started
with
unica
unidirectional
multicast
traffic,
this
is
also
applicable
to
bi-directional
case.
In
the
back
directional
case,
the
boarding
states
or
for
each
tunnel
will
include.
Oh,
the
potency
was
still
in
involvable,
upstream
node
and
bunch
of
downstream
nodes,
even
though
you
would
receive
both
receive
and
send
traffic
from
any
of
those
upstream
or
downstream
nodes.
Still,
we
can
one
of
the
tunnels
will
carry
up
rpf
sub
trv,
indicating
that
that
tunnel
is
for
upstream
purpose
next
slide.
H
Please
and
then
come
to
mp
to
mp
mpos
support.
So
today
an
an
npos
tunnel
can
include
the
labor
stacks
of
trv
for
sending
outgoing
traffic.
Now,
when
it
comes
to
mp2mp
mpos
tunnel,
we
would
need
another
labor
stack
for
incoming
traffic,
so
we
defined
this
new
sub
tr.
We
called
income
enables
us
stack,
it's
just
like
the
existing
label
stack
sub
trv,
but
with
a
different
type.
H
H
So
we
started
with
mp2mp,
but
now
we
can
go
back
to
p2
and
p.
This
new
sub
glv
is
also
used
for
p2mp
for
the
upstream,
because
in
the
p2mp
case,
the
upstream
time
panel
for
the
upstream
node
to
the
downstream
we
we,
you
would
also
need
to
to
know
the
information
on
how
to
receive
traffic.
So
that's
where
the
income
labour
stack
is
used
in
a
tunnel
with
the
rpf
sub
trv.
H
H
So
the
tree
identifying
label
is
important
so
that
the
downstream
node
knows
that
which
tree
it
is
for
and
the
transport
labels
are
used
to
get
to
the
downstream
nodes.
So,
but
if
you,
if
you
use
mpos
tunnel
that
that
that
that
works,
but
what,
if
you
want
to
use
any
encapsulation
tunnel,
you
say
you
say
that
I
want
to
get
to
this
downstream
nodes.
H
I
want
to
specify
this
tree
label,
but
I
don't
care
what
transfer
labels
that
you
want
to
use.
The
controller
does
not
specify
that.
So
in
that
case,
we
will
just
put
these
three
labels
up
here.
Now
the
the
receiving
router
of
the
will
construct
the
outgoing
labor
stack
as
following
the
first.
You
push
the
tree
label.
If
the
sub
grv
is
present,
the
subject
of
the
treatable
is
is
present
and
then
you
put
the
transfer
label
stack.
The
transfer
label
stack
can
come
from
two
ways.
H
One
is
that
you
have
outgoing
label
stacks
up
here
with
the
tunnel.
So
that's
the
latest
step
transportable
staff
you
use-
or
if
you
don't
have-
that
they
will
stack
up
glv
and
then
you
can
just
do
a
lookup
of
the
remote
endpoint
address
that
will
give
you
algo
enables
that
for
transfer
purpose.
Now
you
put
you:
have
the
entire
label
stack
for
both
tree
label
and
transport
label
next
slide,
please.
H
A
Okay,
thanks
yeah,
so
I'm
putting
myself
in
the
queue
and
anybody
else
who
wants
to
make
a
comment.
Please
go
ahead
and
add
yourself
to
the
queue.
So
I
got
a
few
things
very
interesting.
Thank
you.
So
one
thing
is
kind
of
just
an
observation
which
is
the
it
seems
to
me
like
the
any
mcat
is
if,
if
there
were
such
a
thing
as
a
vgp
route
with
a
with
multiple
next
hops,
would
you
be
able
to
use
that
just
as
well.
A
H
A
H
A
You
got
it
yeah.
Sorry,
I
mixed
up
a
couple
things
so
yeah.
The
the
first
observation
is
just
geo
is:
if
we,
if
we
did
have,
which
we
don't
if
we
did
have
a
way
to
represent,
you
know
20
different
next
hops.
Probably
you
would
have
used
that
instead
of
the
tea
attribute,
but
it's
I
mean
I
mean
it's
not
a
criticism.
It's
just
an
observation.
A
H
Correct
it's
just
that
today,
the
ta
itself
is
already
the
low
balancing
concept.
It's
best,
you
you,
you
well
not
necessarily
low
balancing,
but
it's
basically
absolutely
to
the
ascending
router
to
decide
which
tunnel
to
use
based
on
the
situation
so
that
that
the
the
low
balancing
concept
introdu
it
was.
It
is
introduced
for
multicast
purpose.
A
Right
and
then
my
final
point
is
the
the
thing
you
said
about
programming
incoming
packet
handling
slightly
freaked
me
out
in
that
the
the
whole
model
that
tunneling
caps
mainly
follows.
Is
I'm
sending
you
I
I'm
sending
it
to
the
head
end
of
the
tunnel,
not
the
tail
end
of
the
tunnel
like
there
there's
no
concept
of
sending
a
tunnel
in
half
to
the
tail
end
of
a
tunnel.
So
it's
a
little
weird,
I'm
not
saying
it
won't
work,
but
it's
it's
not
the
not
really
the
model
that
the
the
spec
uses.
A
H
H
H
No,
so
this
is
actually
getting
into
the
context
of
comes
beyond
the
tunnel
encapsulation
attributes.
I
can
try
to
say
this
way,
so
the
label
that
identifies
the
tree
there
it
could
be
the
two
situations.
One
is
that
the
label
itself
is
downstream.
Well,
it's
because
we
are
talking
about
controller
signaling,
so
that
label
is
is
determined
by
the
on
the
controller.
H
H
Right
right
right,
another
situation
is
that
somehow
the
the
controller
learns
that
every
router's
address
space
that
reserved
for
for
modica's
purpose
and
they
could
just
allocate
a
label
from
that
every
route
at
that
relevant
router's
local
address
labor
space.
It's
it
depends
on
what
the
controller
does.
H
M
H
Actually,
I
have
a
whole
lot
of
comments
about
your
that
approach.
Instead
of
using
multiple
networks,
could
we
just
use
tunnel
encapsulation
attribute
for
that
purpose,
so
you
you
attach
the
tunnel
encapsulation
attribute
and
in
that
there
you
you
basically
just
list
a
multiple
tunnels,
one
for
each
desktop
address.
You
want
to
to
use.
M
One
for
each
channel
next
stop
address
so
tunnel
captures
an
attribute.
The
way
I
see
it.
It
is
about
saying
to
a
particular
next
hop.
How
do
you
want
to
go
so
it's
like
giving
additional
in-cap
information
and
etc
about
next
house
that
you
already
know
so.
The
multi-deck
stop
attribute
is
just
giving
you
a
way
of
carrying
multiple
next
stops,
and
it
may
say
things
like
this
is
the
way
I
want
to
do
like
load
balancing
like
or
unequal
cost
load
balancing,
or
this
is
your
fr
leg.
M
These
are
the
order
of
fr
that
you
want
to
do
so.
It's
a
it's
a
slightly
different.
You
can
use
turn
captions
attribute
in
conjunction
with
that
multi-stop
attribute,
where
you
can
say
each
of
the
next
house
specified
in
the
multi-next
type
attribute.
How
do
you
want
to
reach
what
tunneling,
whether
you
want
to
restrict
the
tunneling
to
gre
or
mpls
or.