►
From YouTube: IETF111-IDR-20210730-2130
Description
IDR meeting session at IETF111
2021/07/30 2130
https://datatracker.ietf.org/meeting/111/proceedings/
A
Not
yet
linda
excuse
me,
philip
philippe.
A
A
A
A
A
F
A
If
I'm
in
I'm
in
a
directly
attached
place,
okay
folks,
this
is
idr.
This
is
the
second
session
g
dong
has
been
kind
enough
to
upload
the
minutes
from
the
first
session.
Please
go
ahead
and
get
into
the
code
md
and
check
that
hit.
Our
recording
of
your
comments
is
correct.
If
not
please
check
it.
She's
also
posted
it.
This
is
the
notewell.
A
You
should
know
that
anything
that
you
discuss
in
idr
is
under
the
auspices
of
the
notewell,
which
means
it
has
legal
ipr
things.
Please
read
it.
If
you
haven't
seen
it
download
the
slides
and
read
it
up
close
with
that
said,
we're
going
to
pop
right
to
the
rest
of
the
presentation,
starting
with
bgp
over
quick
one,
that
I
thought
was
fun
hold
on
just
a
minute.
G
Okay,
hello,
susan,
can
you
hear
me.
G
G
G
This
is
because,
when
set
up
a
bdp
session,
a
three-way
handshake
is
a
of
the
tcp
had
to
be
adopted.
If
the
trs
is
used
for
the
security,
then
the
trs
handshake
authentication
is
also
performed.
So
the
tcp-
and
this
is
the
trs
handshake-
will
take
more
time
for
the
bdp
session
set
up.
The
second
one
is
the
head
of
line
block
issue,
that
is,
the
routine
information
of
the
different
address.
G
Families
can
be
sent
by
bdp
over
the
same
bdp
connection,
so
if
one
packet
is
blocked,
so
the
sending
of
the
roots
of
all
other
address
families
is
also
affected.
Third
one.
So
that's
for
the
incorporation
configuration
because
the
trs
configuration
and
now
is
a
poor
appear,
so
this
is
also
a
little
complex.
G
So
this
is
just
the
challenge
of
the
bdp
and
the
second
one.
I
think
that's
the
technical
trend
with
the
development
of
open
network
operating
systems,
so
the
now
bdp
is
gradually
being
integrated
into
the
I.t
world,
so
that
means
in
the
software's
software
right
device
or
the
cloudifier
device.
Bdp
is
being
widely
implemented.
G
So
that's
in
the
in
this
trend,
so
using
bdp
for
using
quick
for
bdp
is
becoming
a
possible
option
and
also
that's
because
now
there's
a
after
the
development
of
the
clouding
network
is
tablet
in
connection
between
the
cloudy
wired
device
and
the
physical
network.
Designs
is
becoming
popular,
so
this
also
proposes
a
higher
requirement
for
the
security
and
the
network
that
ability.
Okay,
next
speed.
G
Okay,
so
now
that's
the
user.
We
let's
talk
about
how
water
can
quick
bring
to
bdp.
So
this
is
a
process.
This
brief
for
the
introduction
about
the
quick,
so
there's
a
quick
user
udp
based
based
stream-based,
reliable
data
transmission
service.
G
This
is
similar
as
a
tcp
besides
this
one,
so
that's
by
integrating
with
the
trs
quick,
can
also
support
functions
such
as
establishing
connection
with
minimum
latency
and
providing
confidentiality
and
integrity,
protection
for
the
transmitted
data
and
also
there's
the
advantage
of
multi-stream
multiplexing
by
using
a
quick.
G
So
here
this
is
a
summarize
or
some
summary
of
the
quick
functions.
So
that's
the
first
reliable
data
transmission.
This
is
similar
to
tcp.
Second
one.
I
think
this
is
a
support,
low,
latency
connection
establishment,
so
the
third
one
so
there's
a
user
authentication
of
the
server
or
client
hotline.
G
So
that's
user
provided
the
higher
the
secularity
that
you
provide,
the
confidentiality
and
the
integrity
protection
for
the
transport
data,
the
faceless
you
support
the
streaming
multiplexing
mentioned
and
the
last
one
so
that
you
can
support
the
connection
and
migration
in
the
especially
in
the
mobility
environment.
G
So,
and
also
that's
a
you-
could
build
a
quick
for
the
bdp
so
that
the
configuration
of
the
trs
can
will
can
be
independent
from
the
proper
configuration.
So
you
can
directly
share
the
basic
configuration
on
the
quick
so
that
you
can
simplify
the
calculation
of
the
security
for
bdp.
Okay,
next
slice.
G
Okay,
so
here
that's
the
brief
introduction
about
quick
where
are
yrtt
and
the
dlo
rtt.
So
that's.
This
is
also
the
concept
of
the
quick.
That
means
when
both
the
communication
parties
initiate
a
communication
connection.
G
If
the
if
the
first
data
package
may
carry
valid
wise
service
data,
this
is
called
as
zero
rtt.
If
the
first
data
packet
can
does
not
carry
the
value
the
service
data,
so
this
is
called
as
the
one
rtt
so
here
so
now
we
can
see
there's
a
window
connection.
You
set
up
a
further
first
time
for
the
quick,
because
there's
another
trc
parameter
so
this
in
this
scenario,
one
rtt
has
to
be
used.
G
That
means
for
the
first
data
packet,
it
will
not
carry
any
valid
service
data,
but
you
could
give
the
quick
connection
is
not
a
setup
for
the
first
time,
because
the
trs
parameter
has
been
exchanged
in
the
first
connection.
So
that's
when
setup
is
the
connection
using
the
quick.
So
that's
the
data
packet
can
be
the
first.
The
data
packet
for
the
for
the
non-first
quicker
connection
either
can
directly
carry
the
value
the
service
date.
So
this
is
the
zero
rtt.
G
Okay,
so
that's
if
we
use
the
quick
for
the
quick
for
the
bdp
so
that
there
can
be
the
different
cases
for
the
bgp
using
the
zrrtt
or
the
one
rtt.
We
recommend
for
the
first
bgp
first
time
of
the
bdp
session
setup.
So
there's
a
one
rtt
is
used.
That
means
the
pdp
open
message
has
to
be
sent
after
the
quick
connection
is
set
up,
so
the
sedative
machine
is
the
same
as
the
existence.
G
There
is
a
machine
of
the
pdp,
but
if
the
bdp
session
is
not
set
up
at
the
first
time
so
that
we
can
use
the
zero
rtt
mode
for
the
bdp,
so
in
this
mode,
so
that
the
pdp
open
message
can
be
directly
sent
without
without
at
the
first
packet
of
the
quick
connection.
That
means
you
need
not
to
with
the
setup
of
the
quick
connection.
G
G
Okay,
so
second
is
the
used
case
for
the
streaming
multiplexing
for
the
pdp
to
solve
the
head
of
a
line
block
issue.
So
in
this
cases,
so
that's
because
of
the
quick
for
b
for
for
one
b
for
the
one
quick
connection
there
can
be
multiple
stream
so
that
the
bdp
can
take
the
use
of
the
stream
multiplexing
to
solve
this
kind
of
line
issues.
G
There
are
different
options
proposed
in
the
draft,
so
that's
the
the
option
included
as
the
mapping
stream
based
on
the
address
family
or
mapping
stream
based
on
vrf
or
the
mapping
based
on
the
prefix.
This
depends
on
the
choice
of
the
of
the
policy.
Okay,
next
page.
G
Okay,
so
this
is
a
also
this
user
changed
accordingly
for
the
event
of
the
sedation
machine,
because
now,
as
you
introduce
of
the
quick
so
there's
accordingly,
some
this
the
tcp
base
the
event
and
will
also
increase
increase
this
the
corresponding
the
quick
event
that's
used
for
the
sedation
machine.
G
Okay,
that's
the
page,
okay,
so
next
step,
we
think
that
the
pdp
oral
quick
has
much
effect
on
the
existing
bdp
and
this
now
that's
the
work
is
just
in
the
early
phase.
So
that's
this
job
is
just
a
starting
point.
We
would
like
to
solicit
comments
and
possible
causes
to
co-work
on
the
drought
and
the
solution,
and
then
we
can
have
some.
This
is
a
possible
open
source,
work,
implementation
and
verification.
G
So
that's
a
that's
all.
Okay,
thanks.
E
E
E
It
is
not
clear
actually
how
you're
gonna
do
it,
because
in
order
to
implement
this
bgp
over
quick
solution,
you
still
need
to
implement
certificate
management.
So
you
need
some
kind
of
pki
solution
and
a
way
to
distribute
certificates
between
bgp
speakers
and
I
think
in
general,
it's
not
a
trivial
task
and
on
top
of
it,
depending
for
example,
on
the
lifetime
of
your
certificates,
you
will
encounter
corner
cases
such
as
what
if
your
certificate
has
expired.
But
you
have
a
long
lived
bgp
session.
G
Okay:
okay,
thanks:
okay,
go
on
go
ahead!.
G
D
Okay,
thank
you
sue,
so
I
do
want
to
add
to
the
point
from
the
prior
speaker.
The
certificate
issues
are
going
to
make
this
a
very
interesting
problem,
along
with
how
the
encryption
is
going
to
interact
with
a
lot
of
different
types
of
accelerators
and
host
path,
implementations
so
well,
I
agree
that
there's
a
lot
of
interesting
challenges
here.
I
think
that
there's
potentially
a
lot
of
interesting,
good
work
that
can
come
out
of
this.
One
of
the
things
I
do
want
to
add
into
the
mix,
though,
is
well.
D
The
tls
is
going
to
give
us
some
level
of
integrity,
and
now
privacy
is
an
extra
feature.
It's
still
not
going
to
protect
your
transport
session
against
no
certain
types
of
attacks.
So
one
of
the
things
we
don't
see
over
implementations
right
now
for
tls
applications,
since
they're,
not
typically
long
lived
enough,
is
some
use
of
something
like
tcp
ao.
So
we're
probably
going
to
be
looking
at
that
for
bgb
applications
at
some
time.
D
G
I
started
so
I
think,
for
you
are
the
second
point,
so
that's
usually
related
with
the
implementation,
so
we
will
have
the
more
have
more
the
work.
As
for
your
information
thanks
for
information,
but
for
the
first
one
I
say
that
you
know
that.
There's
the
cases
that
mean
maybe
there's
a
huge
number
of
the
bgp
session
is
a
setup.
G
G
H
H
Oh
okay,
I'll
speak
louder,
okay,
so
next
10
minutes
I'm
going
to
give
some
explanation.
How
do
we
use
btp
flow
spec
to
achieve
this
transport?
Aware
mobility?
H
So
a
little
bit
background
on
this
for
the
5g
services,
3gpp
has
done
extensive
work
to
to
optimize
the
application
traffic,
assign
them
to
different
slices
and
assign
them
to
different
underlay
network,
but
primarily
most
of
the
work
between
the
b,
which
is
the
base
station
and
the
upf
and
over.
H
There
is
gtp
tunnel
gdp
tunnel
is
a
udp
based
tunnel
and
there's
a
draft
in
the
dmm
working
group
on
tn,
aware
mobility
so
mainly
to
basically
us
allocating
a
different
kind
of
traffic
to
different
kind
of
to
their
appropriate
underlay
network
using
the
udp
port
range,
because
that's
how
3dpp
classified
the
application
by
different
udp
range,
so
that
was
in
dmm
and
but
the
traffic
not
just
stopping
at
the
upf.
The
traffic
actually
goes
all
the
way
to
the
their
appropriate
destinations.
H
So
big
chunk
of
the
the
past
actually
is
within
the
data
network.
So
with
that,
there's
a
draft
in
the
rtg
working
group
on
how
do
we
extend
this
tn
aware
to
the
data
network
that
was
presented
in
rtg
working
group
yesterday
describing
multiple
methods
to
push
down
the
policies
to
the
ingress
node?
So
one
of
the
policy
is
using
the
flow
spec.
Actually
sue.
H
Can
you
go
back
one
page,
so
the
previous
page,
so
for
the
yeah
this
one
so
for
the
policy
to
the
ingress,
node,
there's
other
methods
like
pce
or
other
method,
srv6
policy,
specifically
there's
a
flow
spec
coming
down.
So
this
drive
is
just
extending
the
flows
back
aspect
of
the
policy
going
down
for
the
flows
back
the
back
back
one
is:
there
are
a
couple
of
drafts
already
in
idr.
H
One
is
to
redirect
paths
to
a
different
ip
target
and
the
one
we
are
very
interested
is
using
flows
back
to
do
the
pass
redirect
which
direct
to
different
ip
tunnels
and
also
there's
a
flows
back
for
hiv
6..
But
we
find
what
is
missing
is
really
there
could
be
tunnels
which
is
episac
associated,
so
we
think
we
need
a
way
to
tell
the
ingress
node
a
particular
flow
need
to
go
through
the
ipsec
tunnel,
which
is
already
pre-negotiated,
ipsec
tunnel.
So
that
is
what
this
strap
is
about.
H
Next
slide,
okay,
so
in
this
slide
we
just
try
to
show
that
to
assign
traffic
to
to
a
specific
ipsec
tunnel.
There'll
be
two
parts.
One
is
the
matching
condition.
One
is
the
action
for
the
matching
condition.
We
believe
the
current
existing
method
for
the
flow
spec
is
already
good
enough
for
the
action
part.
We
think
we
need
to
add
another
action,
which
is
the
redirect
into
the
interaction
id
for
ib
sac,
tunnellite
episode,
tunnels.
H
Please
so
here
this
slide
just
shows
an
example
for
the
matching
condition.
The
current
flows
back
and
roi
is
only
good
enough.
Specifically,
the
policy
could
be
based
on
source.
Address
could
be
based
on
the
destination
address
could
also
based
on
the
the
udp
udp
ports
or
tcp
ports.
So
I
think
this
is
just
an
example
showing
what
is
there
it's
already
enough.
The
flows
back
v1
is
in
a
second
page
next
page.
H
The
what
we
need
extra
is
because
this
policy
is
from
the
controller
to
the
ingress
node.
Therefore,
this
is
a
non-transitive
flows
back,
meaning
that
ingress
know
when
they
receive
the
flows
back
they're
not
supposed
to
send
it
to
other
nodes.
Therefore,
we
need
a
new
code
point
from
aina
for
the
non-transitive
flows
back
redirect
to
indirection
id
extended
community.
H
So
that's
one
thing
we
need
info
and
second,
one
is
for
the
subtype.
The
subtype
will
indicate
that
the
terminal
id
indicated
is
ipsec
tunnel
id
so
that
the
head-end
node,
knowing
that
they
need
to
associate
with
what
they
have
established
prior
to
that,
because
tunnel
ipsec
tunnel
requires
much
more
than
just
ipsec,
just
a
standalone
ip
tunnel.
It
would
require
a
key
re-key
and
a
bunch
of
algorithm
associated
with
that.
So
that's
the
new
subtype.
We
need
another
id
type
like
in
terms
of
tunnel
id.
H
We
should
need
different
kind
of,
for
example,
you
could
have
inner
encapsulation
being
gie
based
or
vxlan
based.
So
those
are
basics.
Three
iona
code
points.
One
is
the
type
non-transitive
flows
back
redirect
to
indirection
id
and
subtype
for
ipsac
and
ipsec
id
types.
So
those
are
three
things
we
need
from
info
and
that's
it
next
page.
H
A
Linda
ketan
reminded
me
to
encourage
draft
authors
of
flowspec
to
indicate
in
the
beginning
of
your
introduction
whether
you're
going.
A
H
D
V1
so
I'll
add
myself
to
the
queue
so
linda.
I
I
think
we're
going
to
say
two
things
that
you're
going
to
care
about
for
this
proposal.
The
first
one
is
that
the
indirection
id
you're
talking
about
is
a
flowspec
action
and,
for
the
most
part,
those
are
perfectly
compatible
with
existing
flowspec
v1
behaviors
authors
are
strongly
encouraged
to
talk
about
how
their
affording
action
extend
communities
and
other
behaviors
interact
with
other
documented
ones
that
we
have
out
today.
D
The
second
thing
I'd
encourage
you
to
think
about
is
that
your
application
for
the
match
criteria
in
flows
back
is
at
least
written
in
the
presentation
as
being
very
boring
flow,
spec
v1.
D
That
said,
I
I
think
that.
Well,
that's
a
good
feature.
D
One
thing
I'd
urge
you
to
consider
is
what
happens
if
you
have
a
device,
that's
receiving
these
rules
and
happens
to
be
getting
additional
rules
on
top
of
your
application
right
now,
the
flowspec
ordering
is
done
in
the
rfc,
specifically
by
a
sort
order,
that's
targeted
for
ddos
applications.
D
H
H
F
Okay,
it's
it's
in
one
of
the
slides,
it's
showing
a
picture
about
the
bgp
flows
back
for
the
ipsec
tunnel.
I
think
the
page
three
probably
you
mentioned
the
endpoint
is
like
a
upf
plus
pe
and
then
there
I
really
got
confused
like
upf
is
within
5g
part
and
the
pe
is
not
so.
The
first
question
is
from
your
pgp
controller,
to
which
endpoint
it's
going
to
send
its
control
information,
the
second
part,
and
how
how
I
got
going
to
through
the
5g
core
network
hi,
I'm
going
to
do
it.
H
Oh
okay
and
yeah:
that's
a
good
point
on
one
state
presentation
at
the
rtg
working
group.
We
have
actually
two
diagrams
for
this.
One
is
upf
integrated
with
pe
another
one
is
separate,
so
this
flows
back
controller
definitely
is
going
to
the
pe
p
being
a
function.
Maybe
within
one
box
one
box
probably
perform
both
upf
and
p
or
could
be
two
separate
boxes.
H
This
is
definitely
to
the
the
pe
part
and
in
terms
of
the
policy
coming
up
down.
We
assume
that,
in
on
wednesday
discussion
there
is
a
link
between
the
3gpp
controller
to
the
data
network
controller
there'll,
be
some
kind
of
information
exchange,
the
policies,
the
mapping
of
the
policy
like
what
kind
of
traffic
mapping
to
what
kind
of
characteristics.
I
Yeah,
maybe
I
can
just
add
it
here,
linda,
like
a
yes
like,
if
you
see
that
other
draft
we
have
presented
in
the
rtg,
so
that
draft
has
much
more
details
like
there
are
combinations
upf,
the
virtual
upf
could
be
present
part
of
the
ingress
p
node
or
it
could
be
separated.
It
doesn't
matter
at
the
end
like
a
when
that
kind
of
a
traffic
from
the
mobility
traffic
reaches
to
that
ingress,
node.
I
A
A
If
you
had
a
question,
could
you
please
send
it
to
the
email
list?
I'm
sh
we're
gonna
have
a
longer
discussion
on
any
flow
spec
drafts
at
an
interim
in
on
september,
30th
13th,
not
30th,
september
13th.
So
please
would
you
send
that
comment
to
the
list?
I'm
sure
that
it
would
help
the
authors
sure.
E
A
To
the
next
slides,
just
a.
A
A
B
B
All
right,
so
the
main
motivation
is
for
ddos
mitigation
using
ttl
values,
so
the
main
target
are
flow,
spec
v1,
compatible
routers
and
the
draft
is
fairly
simple,
so
it
defines
a
new
component
for
the
ttl
value,
reusing
existing
encoding
for
similar
ib
header
fields,
and
so,
if
you
look
at
the
recent
studies,
such
as
the
one
that
was
presented
at
nanog,
82
called
tracing
ddos
end
to
end
in
2021.
B
So
that
study
was
highlighting
how
filtering
traffic
based
on
detail
values
can
be
used
as
a
very
effective
mitigation
against
a
volumetric
ddos
attack.
So
moving
on
to
the
next
slide,.
B
So
here
I
have
extracted
two
snapshots
from
that
presentation.
I
would
highly
recommend,
if
you're
interested
to
to
go
through
that
presentation
at
nanog,
but
basically
the
authors
are
going
through
various
steps.
B
One
of
the
first
step
is
to
look
at
the
various
ddos
for
higher
services
are
sending
direct
attack
or
amplification
attacks
and
trying
to
identify
the
source
of
the
traffic
and
that's
one
part
of
their
study,
and
the
second
part
of
the
study
was
to
look
at
the
network
under
attack,
so
the
victim
and
when
looking
at
the
network
under
attack,
they
were
looking
at
the
ttl
distribution
for
the
attack
traffic
versus
the
regular
good
traffic
in
the
network,
and
that's
what
you
can
see
on
the
right
side
of
the
slide.
B
So
what
you
can
see
here
is
that
the
good
traffic
is
the
blue
on
blue.
Here,
you
see
in
blue
and
it's
highlighted
by
different
operating
systems
or
cloud
operators,
and
basically,
what
it
means
is
that
the
known
good
traffic
is
coming
from
very
few
hops
away
and
that's
something.
That's
a
that's
a
characteristics
of
the
networks
nowadays,
where
most
of
the
traffic
is
sourced.
B
From
very
few
es
and
cloud
providers,
and
not
coming
from
very
far
away
right,
whereas
the
ddos,
on
the
other
end
from
those
50
plus
ddos
for
higher
services,
that
distribution
was
basically
the
entire
ttl
space,
and
so
by
using
this
and
having
the
ttl
as
a
filter
match
criteria
at
the
edge
of
the
network
and
the
network
receiving
the
ddos.
B
B
So,
if
you're
moving
on
to
the
next
slide,
so
I
really
have
just
one
last
comment:
it's
a
there
was
a
comment
on
the
early
version
of
flowspec
5575bs
about
ttl.
So
the
comment
was
only
in
the
early
version
it
wasn't
under
in
the
draft.
There
was
something
along
the
line
of
the
ttl,
not
necessarily
being
potentially
a
meaningful
match
criteria,
because
it
changes
every
hop
right.
Indeed,
the
detail
values
is
the
decrease
that
every
hop.
B
However,
when
you're
looking
at
those
ddos
mitigation
studies,
and
especially
this
this
last
one,
actually,
the
detailed
values
can
be
used
as
an
effective
mitigation,
so
different
ip
router
at
the
edge
of
your
network,
so
typically
the
peering
edge
of
the
operator
network
under
attack
right.
They
can
use
that
ttl
values,
as
ranges
for
mitigating
the
attack
for
the
attack
traffic
goings
to
a
particular
target
or
multiple
subnets
within
their
own
network
that
are
under
attack.
B
So
in
summary,
the
ttl
value
is
available
in
multiple
router
vendors.
Today
it
is
just
not
present
in
a
flow
spec,
and
we
have
one
very
useful
additional
tool
for
the
operator
in
terms
of
editor's
mitigation
and
I'm
going
to
open
the
mic
for
our
questions.
B
A
That's
one
question:
first
again:
you're
proposing
this
for
v1
flows
back,
but
it
might
be
something
you
also
like
would
like
to
see
in
version
2
flow
spec
did
I
understand
that
well.
B
I
think
you're
right
so
yeah.
The
primary
target
is
for
the
existing
router
in
v1,
but
I
don't
see
why
it
will
be
excluded
from
v2.
Indeed,.
D
And
actually
interject
and
unfortunately,
based
on
the
consensus
from
the
working
group,
even
though
this
is
a
ddos
type
application,
this
doesn't
fit
into
the
v1
encoding
without
some
ability
to
carry
safe
capabilities
across
here.
You
know
with
session
notifications,
if
this
additional
components
present
on
implementations
that
received
it
and
didn't
understand
it.
So
the
current
consensus
is
this
probably
needs
to
go
to
v2.
D
Correct
so
I'll
go
ahead
and
paste
to
the
chat,
a
pointer
to
the
draft
that
I
had
started
for
the
flow
spec
capability
bits,
which
was
a
proposal
to
try
to
carry
new
things
in
v1.
It
describes
the
propagation
problems
that
the
current
flowspeck
protocol
has
for
carrying
new
reachability
for
new
component
types.
B
D
A
And
I'll
add
to
some
to
jeff
our
hope,
because
of
that
feedback
was
to
move
the
two
quickly
forward.
Hence
I've
created
a
prototype
draft
and
we
hope
to
move
quickly.
So
we'd
appreciate
your
feed.
A
B
E
A
Got
from
the
list
we're
always
and
from
the
interim,
so
we're
gonna
go
ahead
and
try
to
push
toward
quickly
toward
v2
anyone
else
for
philippe,
a
fascinating
presentation.
K
Jeffrey
it's
your
turn.
Please
go
ahead!
Thank
you.
So
this
is
a
simple
draft
about
label
stack
sub
trv
in
the
tunnel.
Encapsulation
attribute
next
slide,
please!
K
Its
semantics
is
that
that
labels
label
stack
is
specified
in
the
subtle
tlb
will
be
pushed
before
any
other
labels.
So
why
read
that
recently?
I
was
wondering
why,
before
if
we
want
to
push
the
steer
the
traffic
to
the
tunnel
endpoints,
should
we
push
that
label
stack
after
pushing
the
other
labels,
for
example
the
service
label?
K
So
that's
a
is
a
picture
here.
We
have
at
the
core
domain
and
we
have
side
one
and
side,
two
there's
a
border,
router
br1
and
another
one
br2
between
those
size
and
domains.
K
So
when
the
br
br1
gets
a
bgp
update
with
the
tunnel
encapsulation
attributes,
the
that
attribute
could
carry
a
mpls
label
stack,
sub
trv
and
the
br1
would
push
that
label
stack
first
and
push
other
labels
such
that
when
br2
gets
that
packet,
you
will
be
able
to
use
that
remaining
label
stack
to
steer
traffic
inside
site
2..
K
So
that
is
the
intended
use
case
for
that
sub
trv.
The
spec
was
not
clear
about
it,
so
we
thought
that
it's
good
to
clarify
that
the
intended
use
case.
But
then
another
question
is
what,
if
you
do
want
to
steer
the
traffic
from
the
br1
to
2
to
br
2,
which
is
the
tunnel
endpoints
right
now.
The
spec
does
not
have
a
way
to
do
that.
K
Next
slide.
Please!
So
to
to
to
achieve
that,
we
define
a
new
sub
tier.
We
now
record
tunnel
labels
stack
it's
basically
to
specify
a
label
stack
that
is
used
to
steer
traffic
to
the
tunnel
endpoint
for
comparison.
The
existing
one
is
so
for
steering
after
the
labor
after
the
tunnel
enterpoint.
Oh,
I
I
have
the
typo
in
there
it's
for
steering
traffic
after
the
tunnel
endpoint,
so
this
new
sub
tov
has
exactly
the
same
encoding
as
the
previous
one,
except
that
the
type
next
slide.
Please.
A
A
Jeffrey,
I
am
missing.
I
have
ampules
tables,
but
I
do
not
have
a
community
in
there
just
a
minute.
A
C
First,
we
have
a
overview
of
all
the
bgp
for
bte
plus,
and
then
we
have
a
first.
We
have
an
instruction
to
be
a
tea
for
blt,
so
in
a
b
b,
a
t
network
every
equal
nodes,
a
b
position.
For
example,
node
d,
has
b
to
the
position
one
node
a
has
b
to
position
five
for
every
link
in
the
network
on
each
side
of
the
link.
There
is
a
also
has
has
a
bit
bit
position
here,
for
example,
for
link
between
h
and
d.
C
So
the
idea
of
bgp
for
bt
pass
is
that
the
controller
will
have
connections
to
some
nodes
in
the
network.
The
controller
will
compute
a
bat
path
and
distribute
this
path
to
the
linguist
of
the
network,
and
then
the
linguist
node
can
use
this
path
for,
after
receiving
any
multicast
package
to
be
transported
by
by
the
pass.
C
For
example,
the
branch
from
a
to
h
is
encoded
by
b
position,
26
prime
20
prime
and
then
four,
so
the
controller
will
compute
the
pass
after
controller
has
bad
pass.
It
will
distribute
this
path
to
the
inverse
nodes
of
another
path,
so
linguist
node
can
use
this
path
to
distribute
multicast
package
along
the
path.
Next
page.
C
So
the
distribution
passed
to
ingreso
just
follow
the
normal
pgp
procedures,
so
we
we
have
two
different
cases
here.
Why
is
the
english
directly
connect
to
the
controller?
Another
case
is
not
directly
connected
to
the
controller,
so
basically
bgp
will
have
a
have
a
update
message.
This
message
will
contain
the
path
and
we
will
have
also
rt
and
then
controller
will
just
advertise.
C
C
So,
for
the
first
for
the
first
option,
so
we
just
those
attributes
will
contain-
will
contain
the
information
about
batt
pass.
So,
for
example,
the
information
includes
pass
id
and
then
the
real
path,
which
is
encoded
by
those
bit
positions.
So
this
part
b
at
those
real
paths,
we
can
represent
it
by
a
sub
cybertlv
and
then
we
can
also
contain
another
information
such
as,
possibly
so
next
page.
C
So
this
gives
just
give
a
sample
to
v
which
encodes
the
possibility
positions.
Basically,
this
trv
contains
the
bit
positions
for
a
bat
path,
so
next
page,
so
another
option
is
that
we
can.
We
define
a
new
terminal
type
for
bt
on
under
tunnel
encapsulation
attribute
so
in
this
attribute
will
contain
the
information
about
a
bit
path.
So
this
information
is
encoded
in
cyber
tlvs,
such
as
the
bit
possibility
precision,
subject
v,
as
I
mentioned
in
the
preview
page
and
the
password
mtlv.
C
A
Take
that
to
the
list.
One
thing
I'd
like
you
to
look
at
is
the
interaction
between
pmsi
tunnel
attribute
and
your
work
I'll
send
a
message
to
the
list
on
that.
With
that
we're
going
to
pick
up
jeffrey's
presentation
and
again,
I
apologize
for
the
delay.
C
A
A
Okay,
folks,
I'm
going
to
have
to
display
this
from
my
own
slides.
It
may
be
a
little
problematic
there.
It
is
maybe
I've
gotten
it
now.
A
A
A
K
Okay,
so
I'm
going
to
talk
about
deriving
extended
community
from
my
raw
targets.
K
K
K
K
K
To
do
that,
we
use
a
another
route
target
rt2
attached
to
the
route,
so
that
only
p1
will
import
it
now
to
associate
that
routes
with
vpn
one
with
the
vpn.
We
need
to
attach
another
extended
community.
K
That
community
will
allow
pe1
to
know
that
documented
ec2
is
related
to
the
vpn.
Now,
in
this
case
the
rt2
and
ec2
and
rt1,
they
are
not
the
same.
They
are
totally
different
now,
while
rt1
is
for
the
vpn
I
associate
with
with
the
vpn,
we
cannot
attach
rt1
to
that
route,
because
if
we
do
so,
then
that
route
will
be
imported
by
all
other
pes.
We
should.
We
do
not
want
to
so
now.
We
use
that
ec2
it
can.
It
can
be
any
arbitrary,
extended
community
configured
to
be
related
to
the
vpn.
K
Please.
So
to
do
that,
we
say
that
for
any
route
targets
we
can
derive
an
extended
community
from
it
simply
by
by
changing
the
subtype
to
a
new
value,
and
with
that
from
that
derived
extended
community,
you
can
also
recover
the
original
raw
target.
K
K
K
Let
me
rephrase
I
it's
not
the
intention
of
this
draft
to
change
the
behavior.
I'm
just
point
out
to
show
that
this
could
be
used
to
do
whatever
is
or
what
is
already
defined
in
that
existing
draft,
but
we're
not
changing
that.
Behavior
just
use
this
to
show
the
a
specific
use
case,
but
I
will
skip
it
next
slide
please.
K
So
this
is
a
simple
informational
draft.
The
whole
idea
is
the
purpose
is
to
share
this
idea
for
deriving
extended
community
from
a
raw
target.
I'm
sure
there
will
be
other
use
cases
that
people
can
use
this
for
I'm
seeking
comments
and
if
this
makes
sense,
I'd
like
to
have
the
one
group
adopting
it
adopting
it,
even
though
it's
informational
draft,
that's
it.
A
We're
all
at
6
31,
we
had
a
request
and
then
talked
on
that.
Would
you,
if
you'd
like
to
stay
around,
we
can
go
to
vintats
presentation
just
a
minute.
While
I
swap
back-
and
I
will
let
him
otherwise
than
not
we
can.
I
didn't
see
him
earlier-
is
vintant
here.
A
L
L
Hey
I
mean
I'm
presenting
the
bgpa
auto
discovery
proposal
on
behalf
of
shiva
and
myself
and
please
go
to
the
next
slide.
Thank
you.
L
The
scope
of
the
work
is
to
reduce
per
node
p
per
year,
bgp
specific
configuration
and
this-
and
this
will
be
scoped
for
the
single
single
of
layer,
single
hop
bgp
session.
This
also
in
this
also
includes
the
bgb
session
formed
between
the
formed
using
the
loopback
addresses
for
the
directly
connected
bgp
neighbors.
L
L
So
the
contents
in
this
in
this
protocol
advertised
using
using
the
tlb
based
there's
all
these
tlvs
or
grouped
with
the
messages
and
the
content,
the
the
content
of
that
the
transport
information
and
the
base
protocol
information
is
advertised
with
the
expiry
lifetime
and
that
information
is
periodically
refreshed
before
it
expire.
L
L
The
pdu,
the
pdo
layer,
has
a
as
usual
the
pd
header
and
the
set
of
messages,
and
each
messages
have
a
set
of
tlbs
right.
The
the
pd
header
is
like
any
other
protocol,
have
that
version
and
length,
along
with
the
identifier,
to
identify
that
the
sending
router
also,
this
version
will
define
a
two
messages.
L
L
The
remaining
lifetime
will
will
give
you
the
entire
content,
life
and,
and
it
and
it
will
and
the
lifetime
is
under
driven.
It
means
that
in
any
in
any
given
link
the
sender
could
drive
if
the
sender
could
detail
what
that,
when
the
content
will
expire
right.
The
other
other
couple
of
tlbs
on
the
one
is
authentication
of
the
config
sequence.
The
config
sequences
will
provide
you
with
any
interesting
local
conflict
changes
that
will
hint
the
remote
and
to
do
more
any
more
any
more
actions.
L
This
is
mainly
for
the
bgp,
a
bgp
transfer
parameter
this.
This
message
will
describe
the
what
are
the
the
transform
parameters
is
to
wish
to
or
why
should
what?
So,
there
are
a
couple
of
security
tlvs
that
the
tdl
and
the
authentication
other
than
the
authentication
and
the
local
address
tlv.
That
will
be
tell
what
is
my
local
transport
address?
L
That's
wish
to
form
a
session
and
that
transport
preference,
if
you
have
the
couple
of
if
you
have
both
v4
and
v6
transport,
it's
what
is
its
preference
to
form
the
session
in
the
cases
in
the
case
where
only
only
one
session
is
found,
one
only
trans
one
transfer
session
is
formed
right.
L
The
link
address
will
be
useful
in
the
case
it
will
provide
a
reachability
to
the
local
address
in
case
of
the
data
protocol
is
used
for
either
v4
or
v4
in
the
case
of
the
preferences
v6
and
the
v4
in
the
case
of
references
v6
and
the
tcp
msus
is
a
it's
on
the
tcp
parameter.
L
A
M
Us
off
stacey
lyndon
cisco
systems.
It's
just
a
comment.
This
is
really
similar
to
xiaohu's
draft,
which
really
emulated
the
ldp
discovery.
M
L
D
And
just
interject,
the
the
lack
of
the
state
machine
was
probably
the
biggest
change
versus
the
ldp-ish
one
that
xiaohu
did.
Xiaohu's
was
out
of
all
the
proposals
that
were
previously
published.
D
L
D
Hopefully,
we'll
start
thinning
them
out,
so
I
think
I
recommend
everybody
interested
in
this
work
across
the
board.
We're
we're
to
the
point
of
we've
agreed
in
the
design
team.
What
the
requirements
are.
We
know
what
the
contents
are,
we're
down
to
know
the
boring
details
about
making
the
pdus
look
like
something
that
our
implementations
are
happy
about.
So
if
we
have
specific
encodings
that
we
like
from
each
of
the
different
proposals,
you
know
throw
those
out
on
the
list.