►
From YouTube: IETF110-IDR-20210309-1200
Description
IDR meeting session at IETF110
2021/03/09 1200
https://datatracker.ietf.org/meeting/110/proceedings/
C
B
A
C
Of
course,
you've
reduced
the
contract.
A
A
A
C
A
C
C
C
E
C
And
again,
since
we're
waiting
on
everybody
to
finish
joining,
this
is
a
good
time
if
you
want
to
run
a
quick
microphone
check
for
you
to
do.
C
A
Okay,
why
don't
we
go
with
that?
There's
always
fun
with
backup.
My
my
problem
was
tried,
a
second
connection:
bad
choice.
Okay,
folks,
I
will
go
with
the
slides.
Did
john
get
a
chance
to
say
hello
for
his
last
moment
as
idr
chair?
A
Jeff
you
find
that
we
have
two
new
co-chairs,
jeff
and
care.
There's
handsome
pictures
for
both
of
those
and
alvaro
wanted
a
few
minutes
so
alvaro
you're
in
the
queue.
H
Oh
sorry,
I
was
on
double
mute
good
morning
to
everyone
or
actually
good
afternoon,
because
we're
supposed
to
be
in
prague
this
week,
as
sue
said,
I
want
to
also
welcome
the
new
co-chair.
Some
of
you
should
know
by
now
or
know
already
by
now
that
john
has
been
selected
as
the
new
routing
id,
even
though
he's
still
listed
here
in
munich
as
idr
chair,
his
official
function
started
yesterday
as
as
ad.
H
The
official
turnover,
of
course
happens
on
wednesday.
So
this
is
the
last
time
that
we're
going
to
see
him
as
our
chair,
john,
I
think
you're
all
going
to
agree,
has
done
a
great
job
over
the
last
few
years
as
idr
chair
he
had
some
big
choose
to
fill
in.
He
surpassed
any
expectation
that
anyone
ever
had
and
so
much
so
that,
of
course,
idr
and
bgp
have
grown
so
much
with
him
and
sue
in
charge
of
the
working
group.
H
We
have
four
or
five
different
working
groups
working
on
on
bgp,
and
now
we
decided
to
add
two
new
chairs
so
that
we
can
handle
the
amount
of
work.
Idr
is
the
busiest
working
group
in
the
ietf.
H
That
means
it
has
the
most
number
of
drafts
active
and
in
all
kinds
of
states,
there's
a
big
list
that
you
saw
this
week.
That
is
just
a
small
part
of
what
we're
going
to
discuss
this
week.
So
I
want
to
again
thank
john
for
all
his
work.
H
D
Welcome
thanks
very
much,
I
won't
say
a
whole
lot
except
to
say
thank
you
for
being
such
a
great
working
group
and
to
sue
for
being
the
best
coach
here.
I
could
possibly
ask
for
it's
been
one
of
the
highlights
of
my
career.
A
So,
just
in
case
you
all
have
jeff
if
you
go
to
the
next
slide,
just
in
case
next
slide
jeff.
If
you
get
next
slide
just
in
case,
you
want
to
make
something
fun,
john,
the
we're
sending
you
off
with
a
little
idr
gift,
which
is
for
your
tea
or
other
beverages.
There'll,
be
a
high-tech
coffee
cup
delivered
to
you,
but
going
for
that
to
fit
on
the
bottom
of
that
cup.
A
It
plugs
in
it's
one
of
my
husband's
fun
cups
and
the
battery
tells
you,
when
the
cup
will
stop
providing
automatic
heat,
we're
going
to
make
little
cup
caddies
for
john's
cup,
so
I've
ordered
a
whole
bunch,
and
I
have
a
friend
who'll
put
little
vinyl
pieces.
So
if
you
want
to
send
a
message,
otherwise
john
will
get
something
inspiring
for
me,
such
as
thanks
as
being
a
co-chair
or
some
of
the
rfcs
that
he's
joyfully
either
written
or
provided
shepherding
for.
A
So,
if
you
have
one
just
send
me
a
note,
I'll
put
your
message
here
and
we
just
re
just
a
way
of
sending
john
into
his
a.d
sleepless
nights
with
coffee
and
our
concerns.
Jefferson.
Thank.
A
Yes,
that's
the
point.
My
husband
likes
it
as
he
goes
on,
so
the
notewell
is
something
you
should
notice.
If
you
haven't
read
it
take
time
to
read
it
or
go
to
the
itf
page
next
one
and
we
should
go
with
our
first
presenters
as
I'm
still
a
few
minutes,
late,
jeff
you're,
the
first
presenter.
C
Thank
you
sue,
so
I'll
try
to
actually
keep
things
moving
at
a
fair
pace
for
the
first
two
presentations.
So
in
this
respect,
I
am
speaking
as
one
of
the
members
of
the
ietf
idr.
You
know,
php
auto
configuration
design
team
is
warned
helpfully
put
in
a
slide
view.
That's
a
long
name,
so
the
design
team
was
kicked
off
during
ietf
106,
basically
over
breakfast
to
talk
about
what
are
we
going
to
do
about
auto
configuration?
You
know
for
bgp.
C
The
topic
has
been
sort
of
a
hot
one
in
some
circles,
specifically
in
the
context
of
trying
to
actually
make
data
center
bgp
a
lot
easier
to
run.
The
working
group
was
the
design
team
was
spun
up
in
january
2020
to
put
together
the
requirements
in
solution
space.
This
was
partially
in
response
to
a
number
of
drafts.
People
had
put
out
covering
different
aspects
of
auto
configuration,
and
the
design
team's
charter
is
to
figure
out.
What
do
we?
C
C
C
You
know
as
an
example
for
pec
controllers
or
for
asbrs
or
for
talking
to
route
reflectors,
but
to
make
sure
that,
if
we're
going
to
pick
something
that
is
useful
for
data
center
purposes,
if
it's
extensible
for
other
purposes,
that
can
be
done
so
and
now
our
determinations
largely
match
that,
for
the
most
part,
the
contents
of
auto
configuration
that
the
design
team
discussed
is
that
we
do
need
support
for
v4
v6,
potentially
both
potentially
neither
it
depends
on
exactly
how
you
want
to
do
your
bgp,
the
example
four
over
six,
except
for
et
cetera.
C
C
C
Ipsec
things
like
gtsm
are
configuration
parameters
that
are
needed
for
tsp
to
come
up
appropriately
for
these
things
and
for
some
implementations,
bfd
configuration
needs
to
be
clear
and
set
up
before
the
session
ends
up
being
able
to
come
up
now.
Obviously,
there's
information
that
bgp
also
needs
to
carry
around.
So
it
has
things
like
the
as
number
the
affysafis.
C
C
C
C
So
this
allows,
in
many
cases,
validation
of
no
expectations
versus
configuration
and
just,
as
importantly,
allows
people
to
override
auto
configuration
if
it
doesn't
make
sense,
one
of
the
more
extensive
conversations
which
does
impact
what
idr
decides
to
do
next
in
terms
of
selecting
protocols
is
where
does
the
protocol
actually
run
layer,
two
or
layer?
Three,
there
are
use
cases
for
both
of
them.
C
There's
a
good
chance
that
you
know
your
broadcast
domain
or
multicast
domain
in
this
case
is
actually
larger
than
you're
expecting
and
sometimes
the
expectation
is
you
really
just
want
to
peer
at
the
thing?
That's
on
the
other
side
of
the
port,
if
you're
doing
something
that
resembles
multicast
or
broadcast,
potentially
that's
much
further
across
the
fabric
than
you're
really
expecting.
C
So
this
does
mean
that
there
may
be
cases
for
restricted.
You
know
layer,
two
unicast
or
multicast.
C
C
Once
we've
actually
gone
through
an
iterative
cycle
to
figure
out,
did
we
actually
do
our
job
correctly?
The
job
of
idr
is
to
discuss
what
the
next
steps
are
for
actually
either
picking
one
of
the
existing
proposed
solutions
and
filling
in
the
holes
that
the
design
team
has
identified.
C
C
L
C
That's
the
critical
thing
that
we
were
doing
our
work,
for
it
was
our
determination
that
we
could
probably
support
other
non-data
centers
non-data
center
scenarios
with
the
same
machinery.
L
Okay,
but
even
for
the
data
center
network,
you
also
have
some
the
specific
limitation
or
some
of
this
constraint.
I
mean
that
means
that
the
spine
level
architecture,
data
center
network,
or
maybe
other
data
center
network
with
different
topology.
C
Certainly,
the
main
scenario
that
we
were
thinking
about
was
the
standard,
clo
fabric
type
topologies,
but
in
other
type
topologies,
such
as
butterfly,
etc.
C
You
know
it's
our
belief
that
the
bgp
state
that
needs
to
be
passed
drawn
by
the
discovery
protocol
probably
will
be
the
same,
very
likely
the
role
information
as
to
how
you
discover
what
your
you
know,
adjacent
neighbors
should
be
in
the
topology
would
potentially
go
in
there
and
you
know:
that's
that's
where
the
next
steps
are.
Did
we
get
the
state
necessary
in
the
protocol
correct,
and
we
have
enough
information
to
support
the
more
general
fashion
discovery
for
various
topologies.
L
C
Well,
to
pick
an
example,
a
lot
of
layer,
three
ports
that
you
may
plug
into
may
be
actually
carrying
information
from
one
port
to
another
across
something
like
evpn
as
an
example.
So
since
there
is
really
many
extra
devices
in
the
middle,
what
is
your
trust
level
about
ip
multicast
in
those
types
of
environments?
C
It's
the
experience
of
several
people
on
the
design
team
that
multicast
for
ip
across
various
types
of
switching
technologies
sometimes
ends
up
being
a
little
bit
strange.
So
we
wanted
to
make
sure
that
for
circumstances
that
you
want
to
talk
to
a
known
device
that
is
directly
on
the
other
side
of
the
port
that
a
layer,
2
option
is
present,
and
we
have
two
drafts
that
are
discussed
in
the
design
team
requirements
that
have
been
published
that
talk
about
layer.
Two
solutions.
C
Depending
on
what
you're
looking
to
use
auto
configuration
for
I'm
sorry,
I
get
a
little
bit
of
feedback
from
your
microphone.
As
you
know,
if
you
could
do
please
yeah
when
you,
when
you're
getting
auto
configuration
being
done,
it
depends
on
what
you're
using
auto
configuration
for.
In
some
cases,
people
are
looking
to
just
avoid.
Having
to
do
ip
address
configuration
is
one
of
their
use
cases,
but
in
other.
K
C
C
A
port
into
another
device
and
it
just
automatically
joins
you
know
at
the
appropriate
place
in
the
topology,
so
you're
correct
that
you
can
use
this
for
very
lightweight
just
for
avoiding
ip
address
configuration
and
managing
all
the
tcp
properties,
all
the
way
to
devices
coming
out
of
the
box.
That
know
exactly
what
they're
supposed
to
do.
M
I
I
think,
if
we,
if
we,
if
the
auto
configuration
work,
account
auto
configure
all
religious
information,
for
example
the
the
s
number
on
the
pure
address,
and
then
I
I
think
it
kind
of
is
the
deployment
of
the
pdp
in
the
video
data
center.
If
we
either
need
to
configure
all
these
scenes,
then
I
think
the
most
most
part
of
work
has
been
finished.
C
The
I
joined
your
microphone
cut
off,
but
to
talk
about
why?
I
think
what
you're
heading
towards
is
the
design
team
document
is
not
intended
to
address.
You
know
100
of
the
picture
for
configuring,
a
device
that
speaks
bgb,
so
this
is
auto
configuration
for
bringing
up
a
session
you're
correct
that
if
a
device
needs
to
learn
its
own
properties,
things
like
as
numbers,
etc.
I
Hi,
can
you
hear
me
jeff?
We
can
hear
you
yeah,
so
I
just
a
question.
I
guess
most
vendors
I
get.
I
guess,
have
some
type
of
audit
provisioning.
Well,
not
not
necessarily
provision
provisioning,
but
a
zero
touch
programmability,
I
guess
built
into
their
into
their
architecture.
So
I'm
guessing
this.
This
mechanism
would
be
something
that
would
play
into
that,
but
it
would
be
like
something
that
you
could
put
a
box
out
and
just
be
able
to
provision
but
work
in
conjunction
with
a
banter.
C
Absolutely
so
you
know
one
way
to
visualize.
This
is
that
your
ztp
mechanism
for
bootstrapping,
the
box
programs,
things
like
as
numbers
what
the
role
is
supposed
to
be,
but
in
even
in
those
environments,
you're
expecting
that
you
need
to
hear
something
from
the
other
side
of
the
wire
to
know
what
you're
talking
to
is
an
acceptable
device
to
peer
with,
before
you
bring
up
your
peering
session.
I
Gotcha,
so
it's
probably
that
first
layer,
I
guess
that
happens
really
that
discovery
layer
which
is
probably
the
more
complicated
and
the
logic
related
to
the
discovery.
I
guess
that's,
that's
the
you
know
the
key
part
of
the
audit
provisioning.
How
do
you
discover
what
what
I
should
be
and
what
my
role
is?
I
guess-
and
that's
that's
probably
the
biggest
one
once
it
discovers
it,
and
then
it
can
actually
go
through
the
next
layers,
so
probably
to
help
with
that
first
layer.
I
The
discovery
layer
of
the
vendor,
auto
provisioning,
I
guess
makes
makes
sense.
That
makes
sense
and,
as
you
said,
I
think
this
is
probably
first
application
of
data
center,
but
there's
no
reason
why
you
couldn't
use
this
in
really
any
application.
I
would
think.
C
Thank
you
again
and
what
we
are
likely
to
do
as
a
follow-up
is
depending
on
interest
that
we
see
on
the
mailing
list
and
discussion.
The
chairs
have
discussed
that.
Perhaps
we
will
have
a
interim
set
aside
for
taking
this
work
forward
so
and
just
looking
ourselves
continuing
back
on
time.
C
I'm
gonna
move
to
the
next
presentation,
so
this
is
moving
us
into
the
flow
spec
portion
of
you
know
today's
presentation,
I'm
taking
the
first
one
I'm
going
to
be
talking
about
some
flow
spec
extensibility
issues
in
general
and
a
proposal
maybe
to
address
some
of
the
deficiencies
we
have
today.
C
So
we've
just
gotten
done
a
huge
amount
of
work
taking
5575
to
rfc
89
55..
You
know
thank
you
to
christoph
for
driving
that
perk.
You
know
this
was
kristoff's,
no
first
heavy
piece
of
work
in
ietf
as
best
I
know,
and
certainly
took
longer
than
I
think
he
was
expecting.
C
The
format
that
the
the
authors
chose
at
the
time
was
largely
type
value
and
for
anything
that
was
some
flavor
of
variable
linked
list,
the
length
portion
is
implied
rather
than
explicitly
you
know
made
known.
So
the
analogy
is
like
just
like:
mpls
label
stacks,
you
don't
know
how
long
the
label
stack
necessarily
is
you
just
know
that
it
a
stack
bit
with
flow
spec
components
in
any
case,
there's
some
flavor
of
end
of
list
that
you
know
for
the
operator.
C
This
does
have
a
negative
consequence
that
you
really
can't
safely.
Parse
floats
back.
You
know
for
an
unknown
component
without
you
know
having
to
take
guesses
of
whether
or
not
supporting
this
behavior
or
not.
So
this
means
that
we
haven't
been
able
to
safely
deploy
new
features
because
implementation
simply
no
don't
know.
What's
going
on
there.
C
C
We've
started
the
work
initially
2016
for
discussing
what
a
flow
spec
v2
would
be
minimally.
The
flow
spec
v2
would
be.
You
know
a
more
strict
format
for
tlvs,
which
would
allow
us
to
actually
work
around
this
incremental
deployment
problem,
but
flowspec
v2
potentially
went
into
much
deeper
work,
for
example,
taking
the
implicit
rule
ordering
out
of
the
system,
and
you
know
enabling
use
cases
where
explicit,
no
reordering
could
happen.
C
So
that's
a
potentially
large
piece
of
work,
and
so
I
think
we'll
be
discussing
at
some
point
how
we
carry
that
forward.
C
But
meanwhile
we're
sort
of
stuck-
and
you
know
what
I
have
for
the
working
group-
is
a
proposal
that,
since
with
the
current
flowspec
format,
we
can't
deal
with
unknown
component
types
where
a
speaker
can't
actually
announce
a
nlri
that
the
receiver
couldn't
parse
well,
the
answer
can
be
now.
The
receiver
uses
some
sort
of
capability
to
tell
the
sender
what
it's
willing
to
deal
with,
and
that's
an
important
distinction
from
you
know.
What's
willing
to
deal
with
from
what
it
is
willing
able
to
understand.
C
C
So
in
terms
of
how
do
you
actually
encode
this
type
of
behavior?
Now
the
easy
answer
is
a
bit
string.
So
what
you're,
seeing
in
front
of
you
is
now
from
the
draft.
You
know
simple
bit
string,
you
know
currently
bits
1
through
14
are
actually
supported
for
5575
as
a
base,
and
you
know
the
v6
extension
adds
on
no
one
additional
bit.
Sorry
1
through
13
and
14
comes
from
5575
for
v6,
so
in
this
case
we're
just
showing
a
bit
vector
that
you
know
all
bits
are
being
set.
C
C
That
said,
other
implementations
are
not
fond
of
this
format
because
they
want
to
have
it
in
machine
order.
The
problem
we're
going
to
have
here
is
that
being
up
to
255
bits,
it's
never
going
to
be
something
that
will
fit
into
a
single
machine
word.
So
I
suspect
this
will
be
the
main
contentious
point
for
you
know
this
proposal.
C
C
Is
that
what
this
effectively
becomes
is
a
filtering
mechanism
where
some
flow
spec
routes
do
not
get
propagated,
because
the
speaker
is
not
willing
to
accept
them
and
since
missing
flow,
spec
routes
based
on
the
ordering
considerations,
if
you
have
dependent
rules
where
one
rule
expects
another
rule
to
be
present
in
the
system,
you
can
end
up
with
unexpected.
You
know
filtering
behaviors,
and
the
consequence
of
that
is
that
you
may
be
mis
addressing
things
you
may
be
sending
them
the
wrong
orders,
etc.
K
C
So
in
terms
of
what
next
some
flavor
of
this
type
of
feature,
you
know,
being
a
very
small
bit
of
incremental
work
could
allow
you
know
all
these
flow
spec
features
to
be
able
to
be
deployed,
so
the
working
group
should
consider
doesn't
want
to
maybe
adopt
this
draft
or
maybe
spin
something
very
similar,
and
clearly
we
do
need
to
continue
the
55
75
as
the
8955
work
in
flow
spec,
v2,
and
even
in
that
case,
some
mechanism
like
this
may
actually
be
a
necessary
thing.
C
N
Okay,
I
have
two
questions
that
the
first
one
is:
what
about
for
r,
if
we
do
this
one,
when
we
are
done
for
some
some
capability,
so
the
road
will
not
send
to
our
land,
it
will
not
reflect
to
other
voters.
N
Okay,
okay.
The
second
question
is
that,
because
at
first
the
rfc
5575
defined
the
prefix
with
unknown
component
type,
we
all
will
treat
as
unknown
unknown
prefix,
so
in
so
in
in
that
in
that
implementation.
N
N
So
so
I
think
it
may
not
cause
some
error,
but
I
saw
that
the
new
rfc
modify
it
and
like
to
treat
it
as
a
more
formed
attribute.
K
G
All
right,
can
you
hear
me
we
can
hear
you
awesome
thanks,
dev,
all
right,
so
I'm
going
to
present
the
bgp
flowspec
payload
match,
which
is
basically
a
new
flowspec
component,
so
moving
on
to
the
next
slide,
all
right.
G
So
what
are
the
background
and
motivation
so
so
today
we
have
bgp
flowspec,
which
is
used
for
doing
n-tuple
filtering
using
layer,
3
and
layer,
4,
header
fields
such
as
iprs
or
port
number,
and
we
have
had
a
recent
advancement
to
ip
routing
for
weddingplane,
which
is
allowing
to
match
at
an
arbitrary
location
a
given
pattern.
G
G
So
this
is
an
ip
for
a
packet
structure,
and
this
is
just
to
illustrate
what
I
was
mentioning
before.
So
this
new
flowspec
component
type
will
be
allowing
the
operator
to
match
a
pattern
within
the
ip
header
layer,
3
or
layer,
4
header
or
within
the
data
payload
of
the
packet
itself.
G
So
with
this,
like
I
mentioned,
one
of
the
main
use
case
is
really
a
ddos
attack
mitigation,
but
it
can
also
be
used
to
match
a
pattern
within
a
header
field
that
within
the
ip
or
udp
or
tcp
header,
that
would
not
be
supported
in
in
flow
spec.
Today,
that's
that's
a
possible
other
use
case.
G
So
the
way
we
are
defining
this
new
match
criteria
within
the
draft
is
using
a
traditional,
encoding,
so
type
length
value
with
the
value
which
is
basically
meant
made
of
two
parts
which
is
the
offset
and
the
pattern
itself.
So
the
offset
is
going
to
allow
us
to
say
where,
in
the
packet
header
or
within
the
data
we
are
trying
to
match,
and
then
the
pattern
is
going
to
be.
What
is
the
the
value
that
we
are
trying
to
match
on?
So,
moving
on
to
the
next
slide,.
G
Right
so
we
have
the
the
offset.
The
draft
is
defining
two
things
which
are
for
the
offset
the
offset
type
and
then
the
offset
value
so
the
offset
type
as
at
the
moment,
three
values
zero.
One
and
two.
This
is
a
convenience
for
for
the
operator
and
for
the
ddos
controller
that
may
want
to
program.
Forwarding
rules
and
filtering
rules
which
is
offset
0
is
the
start
of
the
ip
header
offset
type.
G
G
Offset
having
a
connection
issue,
we
can
hear
you
again.
Okay,
I
could
see
reconnecting
to
the
audio
okay,
all
right
so
another
example
is
offset
type
2
for
a
payload,
tcp
udp
and
offset
value
10,
so
we
would
define
an
offset
which
is
10
bytes
after
the
beginning
of
the
tcp
or
udp
data
all
right,
so
this
is
only
to
define
where
we
are
going
to
match
that
particular
pattern.
So,
moving
on
to
the
next
slide,.
G
Okay,
so
that's
the
pattern,
so
the
pattern
may
come
into
a
different
form.
The
most
common
form
for
iteration
router
will
be
the
bitmask
match,
which
is
going
to
match
a
set
of
bits
and
with
a
mask
and
then
the
pattern
type
which,
which
is
pattern,
type,
zero
and
then
python
type,
one
or
two
are
for
regular
expression,
and
this
would
be
more
dedicated
for
a
software
based
forwarding
planes
or
appliances
that
would
apply
this
type
of
filtering
rule.
G
The
prefix
is
the
bit
string
that
we
are
trying
to
match
on
and
we
would
end
this
with
the
mask
value,
so
this
allows
to
match
bytes
or
bits
within
within
a
particular
prefix
pattern.
G
All
right,
so
this
is
a
practical
example,
so
here
you
can
see
a
udp
ntp
packet
and
so
assuming
that
the
goal
was
to
match
on
the
ntp
request
code
that
you
can
find
that
you
can
see
in
in
this
packet,
which
is
a
value
42
here
in
decimal
and
0x2a.
G
This
is
a
ud
packet
and
then
this
new
flow
spec
component,
which
is
a
type
tbd
and
with
the
the
criteria
that
are
mentioned
here,
so
we
will
use
an
offset
type
2,
which
is
for
tcp
or
adp
payload
an
offset
value
of
3,
which
means
3
bytes
after
the
beginning
of
the
tcp,
slash
db
data,
so
in
this
case
udp
a
pattern,
type
0
for
a
bitmask
and
then
matching
on
0x2a
as
the
value
and
the
mask
in
this
case
will
be
0xff.
G
So
this
was
to
to
give
a
practical
example,
so
we're
on
to
the
next
slide
all
right.
So
this
was
a
this
is.
This
is
what
I
want
to
present
about
this
new
flowspec
component
and
opening
the
discussion
for
comments
and
feedback
and
depending
on
feedback.
What
I'm
wondering
is
if
there
is
a
option
to
pre-register
new
component
types
for
early
implementation,.
C
Okay,
I'm
unable
to
track
the
the
queue
at
the
moment.
Sorry,
the
agenda
time
so
sue,
please
let
us
know
for
still
on
schedule.
A
Schedule
he
has
about
three
to
four
minutes
to
discuss
things.
N
N
N
B
C
C
C
O
I
will
covered
a
little
of
this
and
asking
you
know:
will
this
increase
the
complexity
of
of
systems,
I'm
wondering
what
the
benefit
is
of
having
two
different,
regular
expression
systems?
How
will
you
choose
which
one
to
use
in
which
context
and
will
will
implementations
have
to
implement
both.
G
So
so
for
the
regular
expression,
this
was
a
suggestion
for
a
software-based
forwarding,
planes
and
appliances,
so
the
driver
there
was
that,
apparently
those
devices
today
uses
either
one
of
those
two
as
their
most
common,
regular
expression,
but
I
would
have
to
get
back
to
you
if
you
have
further
questions
on
this.
L
Okay,
okay,
I
think
this
is
the
interesting
interesting
solution.
You
select
use
the
bdp
to
implement
p4,
but
I
wonder
if
we
implemented
like
this
one
to
match
some
of
this,
the
preload
have
you
taken
into
account
the
security
issue.
I
mean
that
if
there's
the
mismatch,
they
may
cause
some
this.
The
this
drop
of
the
packet
with
the.
G
Area,
yeah
yeah
for
sure,
so
so
so
in
in,
like
a
a
real
deployment,
you
would
typically
have
a
ddos
controller
and
an
analytic
platform,
and
that
analytic
platform
would
be
the
one
that
would
program
the
filtering
rule
and
that
would
be
based
on
what
it
sees
from
the
traffic
from
from
the
network
right
so
but
but
like
like
in
any
filtering
case,
there
could
be
cases
of
false
positive,
but
the
idea
here
is
to
reduce
false
positive
compared
to
just
doing
layer.
Three
and
therefore.
C
C
So
next
up,
I
believe,
is
yao
lu.
K
K
Please
entropy
labels
are
used
in
the
mpls
that
are
planned
to
provide
entropy
for
load,
balancing
and
rfc
8662
proposes
to
use
entropy
labels
or
empires
networks,
as
described
in
this
rfc
determining
the
past
place
for
eoi,
and
your
powers
may
not
be
an
easy
decision
and
multiple
criteria
may
be
considered,
such
as
the
eild
and
msd
of
the
node
along
the
path
and
elimination
limitations
like
segment
type
or
maxim
maximizing
number
of
lsrs
that
we
all
balance
may
also
be
considered,
and
an
external
controller
can
be
used
to
program
the
label
step.
K
And
this
figure
shows
an
angel
demand
scenario.
The
end-to-end
parts,
when
node
a
to
node
e,
is
calculated
by
a
centralized
controller
along
this
path.
No
balance
is
needed,
for
example,
between
a
b
and
c
and
cn
cnx
and
dne,
and
here
gives
an
example
of
the
label
step
with
actual
labels,
and
in
this
scenario
the
ingress
node
is
not
aware
of
the
eoid
and
msd
info
of
the
nodes
in
command
2..
K
It
is
a
bit
applicable
to
srmpr
settlement
types
and
the
ingress
node,
who
receives
an
extra
policy
and
arrives
with
the
segment
list.
The
sub
to
v.
The
summary
sub
crv
contains
multiple
segments
of
tvs,
for
example,
abcde
and
the
e
flag
of
b
and
d
are
set.
K
It
indicates
that
if
load,
balancing
and
entropy
labels
is
high
required
and
two
eoi
and
ear
poles
should
be
inserted
into
the
label
step,
respect
right
after
the
label
for
b
and
the
label
for
e
and
the
value
of
the
contribute
labels
is
supplemented
by
the
ingress
node.
According
to
the
load,
balance
function
of
the
appropriate
keys
exactly
from
the
given
packet
and
whether
to
insert
the
your
post
is
decided
by
the
english
note,
and
next
like
this.
K
Yeah
a
welcome
feedbacks
comments.
That's.
L
L
L
Hello,
hello,
y'all,
my
my
question
is
that
one
I
think
that's
because
you
mentioned
that
the
sr,
so
I
wonder
why
is
it
necessary
to
indicate
the
position
of
the
entropy
label?
In
fact,
several
years
we
do
this
work.
We
can
directly
calculate
the
entropy
label
in
the
controller.
So
when
downloaded,
this
is
the
segment
list
for
the
sr
policy.
It
can
be
directly
to
insert
the
entry
label
to
the
say
the
least.
I
think
that
will
be.
L
I
think
that
will
be
easy
to
implement
and
also
because
you
know
that
the
entropy
label
can
be
calculated
correctly
for
the
better
load
balance.
K
I
see
and
in
this
draft
we
prefer
that
to
the
controller,
just
calculation
and
the
ingress
of
the
node
kept
its
function
to
inspect
the
flow
and
the
incas
inverse
node
is
responsible
to
calculate
the
value
and
the
universal
adjuster.
Don't
know
where
to
put
this
entropy
label,
but
I
can,
if
you
can
stand
the
draft
I
can.
I
can
read
it
and
compare
and
do
some
priority
classification
more.
L
L
B
P
Hello,
everyone:
this
is
jedo,
I'm
going
to
give
a
presentation
about
bgprs
extensions
for
the
second
routine,
based
enhanced
vpn
on
behalf
of
the
co-authors.
Okay,
next
slide,
please.
P
Okay,
this
is
a
little
bit
about
the
background.
The
has
vpn
or
vpn
plus
framework
is
described
in
the
enhancement
being
draft
in
this
working
group.
It
provides
a
layered
architecture
and
the
technologies
to
provide
enhanced,
vpn
or
vpn
plus
services
and
network
slicing
can
be
seen
as
a
use
case
of
the
weapon
plus
service
and
for
vaping
plus
service.
It
is
enabled
by
integrating
the
overlay
vpns
and
the
underlaying
vtns,
as
shown
in
this
figure.
P
It
describes
the
mechanism
and
procedures
to
build
the
sr
based
return
using
the
resource,
aware
segments
and
for
the
igp
extensions
to
distribute,
distribute
the
srvt
information.
There
are
several
drafts
and
the
discussion
in
our
sr
areas,
our
working
group
and
both
multi-topology
or
flux.
Algo
can
be
reused
or
combined
with
necessary
extensions
for
this
purpose.
P
For
this
draft
it
defines
a
corresponding
bgpls
extensions,
so,
as
this
srv
information
can
be
distributed
to
a
network
controller,
okay
next
slide.
P
P
Okay,
this
is
the
design
principle
of
this
draft
as
showing
this
figure
or
vtn
may
cover
one
or
multiple
areas
or
domains,
and
also
the
inter
domain
links
and
in
each
area
of
domain
we
can
use
multi
topology
of
las
algo
to
advertise.
The
topology
attributes
of
the
hvtn
and
in
different
domains
then
can
use
the
same
or
different
topology
or
algorithm
ids
for
the
same
vtn
and
within
each
domain.
P
Slide
here
are
the
extensions
to
bgprs.
Basically,
there
are
three
different:
two
new
trvs
defined.
The
first
one
is
called
vtn
definition
toa.
It
is
used
to
specify
the
association
between
the
topology
id
algorithm
id
and
the
reading,
and
so
that
multiple
vts
could
refer
to
the
same
topology
or
algorithm
id
so
that
they
can
share
the
topology
advertisement
and
can
share
the
topology
computation.
P
This
tlv
can
also
be
extended
for
further
attributes.
The
second
tl
way
is
called
written
idtlv.
It
is
used
to
identify
a
set
of
vtns.
An
intra-domain
or
inter-domain
belongs
to
then.
The
third
one
is
called
link
attribute
flex
tlv.
This
one
is
correspond
to
the
isis
link
attribute
subtlety
and
in
this.
C
P
You
don't
hear
me,
we
can
hear
you
again:
okay,
yeah!
I
got
lost
for
a
moment,
so
I
think
I
finished
the
waiting
idtlv
right
right.
Okay
for
the
third
one
is
called
link
attribute
flux,
tle.
It
is
used
to
advertise
the
link
attributes
for
a
particular
link.
Actually
introducing
or
interdomaining
we
introduce
a
new
flag
v
is
to
indicate
whether
the
link
is
a
virtual
link
or
a
physical
link.
Okay,
next
page.
P
P
P
The
second
option
is,
we
can
use
bgprs
with
flux
algo,
so
we
use
a
bgprs
flash
algo
definition
to
describe
the
topological
constraints
on
a
particular
topology
and
the
algorithm-specific
cs
can
be
carried
in
the
bgpls
attributes
for
srv6
is
similar.
Srv6
locators
and
cs
can
also
be
algorithm
specific.
P
These
are
just
two
options:
they
can
be
used
in
a
one
or
multiple
areas
of
domains
which
builds
the
inter-domain
vtn
and
with
either
option
the
topology
information
that
the
policy-specific
computation
could
be
shared
by
multiple
vts.
This
is
how
we
can
improve
the
scalability.
P
This
is
about
inter-domain
topology
advertisement.
Basically,
it
is
based
on
you
know
the
bgprs
epe,
with
a
new
18
idtl,
to
specify
the
retain
specific
inter-domain
connectivity
and
based
on
the
granularity
of
the
information
you
need
to
describe
for
the
multi-domain
vtn.
There
are
three
different
medium-specific
b2p
appearances
like
the
bjp,
adjacencies
b2b
peer
knows
it.
Pgp
recesses
can
be
advertised
with
the
btn
identifier
tle,
to
specify
the
inter
domain
link
for
a
specific
return.
P
Something
more
is
we
need
some
identifiers
of
this
vtn
in
the
data
plane.
It
is
used
to
steer
the
package
to
the
set
of
resources
allocated
to
a
vtn
with
different
data
planes.
We
have
different
tlvs
for
smpls.
We
have
the
tlvs
for
meeting
specific
prefixes
and
adjacencies
for
srv6.
We
introduced
a
new
tlv
for
the
vtin
specific
services
locators.
P
The
third
option
is,
we
may
also
have
the
a
dedicated
waiting
id
in
the
data
plane
so
that
we
can
save
the
overhead
of
introducing
new
tlv
for
carrying
this
vtn
specific
data
point
identifier.
P
Okay
for
this
document,
we
know
that
the
bgpls
extensions
may
need
to
align
with
igp
extensions,
so
for
at
this
current
stage,
we
need.
We
just
need
to
just
like
to
solicit,
solicit
feedbacks
and
comments
on
this
document
so
that
we
can
refine
it
accordingly
and
to
move
along
with
the
igp
extensions.
P
C
L
Hello,
hi,
hi,
joby,
okay,
so
in
fact,
for
this
draft
we
would
like
to
add
one
point.
In
fact,
when,
for
the
network
slicing
work,
the
most
important
design
is
the
scalability.
L
We
think
that
here
this
is
the
introduce
the
bgp
links,
the
extension
to
report,
this
network
slice
information
from
the
device
to
the
controller,
but
on
the
other
hand,
because
we
know
that
in
the
network
side
we
also
need
the
idp
to
advertise
this.
The
network
slice
information,
but
this
for
the
idp
flooding
there's
a
studio,
has
a
challenge,
so
we
propose
the
draft.
This
is
the
pdp
spf
extension
to
advertise
this.
The
network
slice
information
here
I
just
remind
you
about
this
draft,
which
also
related
with
the
pdp
and
also
this.
L
A
G
for
bringing
us
five
minutes
back.
Q
Hi
jeff
hi.
We
can
hear
you
okay,
good,
hi,
everyone,
I'm
going
to
present
bgp
class
4
transport
planes
again.
So
last
presentation
was
an
idea
of
108,
and
this
is
the
next
presentation.
Let's
try
please
so.
Basically,
legendary
is
it's
a
short
agenda.
So
I'm
going
to
recap
the
bgbcd
problem
statement,
solution
advantages
and
share
some
changes
to
the
draft
and
some
tidbits
learnings
from
the
implementation
qualifications
so
far
and
introduce
the
later
drafts
and
next
steps
next
side.
Please.
Q
So
these
are
like
tunnels
from
different
transport
protocols
and
they
can
be
tunnels
to
between
those
multiple
tunnels
between
the
same
set
of
destinations
and
they
would
have
different
t
characteristics
and
service
routes
may
want
to
put
traffic
on
them
based
on
their
needs,
and
these
tunnels
may
be
may
need
to
be
extended
into
domain
while
preserving
the
same
key
characteristics
end-to-end
and
such
a
way
that
the
service
hours
are
able
to
map
traffic
onto
them
without
worrying
about
whether
it
is
an
intra-external
or
inter-installer.
Q
The
mechanism
works
the
same
way
and
and
service
out
may
also
want
to
have
an
option
to
fall
back
to
tunnels
of
a
different
t
characteristic,
including
best
effort
tunnels.
So
the
problem
was
how
to
extend
bgp,
to
signal
this
piece
of
information
and
get
the
job
done
and
it's
best
if
the
solution
is
agnostic
of
protocols
or
components
in
the
transport
layer
or
component
the
service
layer,
so
that
it
works
with
any
set
of
these
protocol
components
in
each
layer.
Q
So
the
solution
constructs
in
bgpct.
Basically,
we
just
talked
about
the
different
tunnels
of
different
key
characteristics,
so
we
just
have
a
transport
class
construct
which
collects
tunnels
of
the
similar
characteristics.
So
it
doesn't
think
about
what
type
of
tunnel
it
is
or
which
end
point.
It
is
going
to
adjust
the
transport
class,
which
is
a
type
of
terminal,
so
operators
can
classify
the
tunnels
in
the
network
to
say
these
are
like
my
gold
tunnel.
These
are
silver
tunnels
and
they
have
an
identifier.
Q
The
transport
class
also
has
a
32-bit
color,
that's
an
identifier
and
we
use
bgpct
there's
a
new
bjp
address
family
which
plays
at
the
transport
layer.
So
when
I
say
transport
layer,
it
just
means
that
it
carries
prefixes
which
are
used
as
protocol
next
stops
in
bgp
updates,
and
this
is
a
safety
76.
It's
called
class
4
transport
and
it
follows
rfc
4364
procedures,
which
is
basically
bgp
mps
vpns.
Q
So
this
what
it
does
is
it
just
collects
the
tunnel
endpoints,
the
ingredients
that
we
have
in
the
network
and
disseminates
across
bgp
speakers
to
other
domains
and
collects
them
in
transport
trips.
For
that
transport
class,
and
so
that
service
outs,
when
they
want
to
resolve
over
a
certain
transport
class-
let's
say
gold,
so
they
will
just
confine
their
next
stop
selection
from
the
trans
routes
that
are
collected
in
the
transporter.
Q
So
it's
as
simple
as
that
and
the
english
source
collected
in
a
transport
cluster
advertising
bgpct
family
to
other
speakers
with
the
very
familiar
encoding
like
we
use
rd
colon
terminal
endpoint
as
the
nlri
and
the
transport
cluster
target
that
identifies
that
it
belongs
to.
Q
So
this
is
just
like
a
l3
vpn
update
where
we
are
just
using
rd
to
as
a
distinguisher,
and
we
are
using
a
new
type
of
target,
and
this
is
just
so
that
we
don't
have
any
collision
with
the
service
plane,
route
targets
and
so
bgpct
extends
these
tunnels
across
the
domain
boundaries.
By
doing
the
resolution
confined
to
the
transport
class,
just
like
I
explained,
and
it
follows
the
option
c
style
procedures
when
the
route
bgb
city
route
is
advertised
across
a
bgp
speaker
with
next
top
shelf.
Q
It
just
creates
a
swap
route
with
which
basically
connects
the
two
gold
lsb's
in
the
two
different
domains
and
those
lsps
could
be
belonging
to
different
transport
protocols,
and
so
it
should
be
said
that
this
also
works
with
in
conjunction
with
option
a
and
option
b
scenarios
and-
and
it
also
works
with
scenarios
where
you
have
a
single
domain
and
it
has
an
abr
in
the
middle.
So
it's
like
two
reasons
and
the
service
routes.
The
way
they
resolve
over.
These
is
using
a
consent
called
a
resolution
scheme.
Q
So
the
resolution
scheme
is
nothing,
but
it
says
you
resolve
over
a
certain
transport
class
with
an
option
to
fall
back
to
a
best
effort
or
another
transport
class,
and
these
resolution
schemes
are
like
local
constructs
on
a
receiving
box
and
the
way
the
egress,
router
or
bgp
route
that
is
received
on
an
ingress
router
communicates
its
resolution
scheme
intended
resolution
scheme
is
using
a
mapping
community
on
the
pgp
route.
So
this
mapping
community
can
be
any
community
for
that
matter.
Q
For
example,
the
colorectal
community
that
is
already
widely
in
use
to
map
services,
so
they
can
be
used
on
the
service
route
to
say
that
please
map
over
the
color
n
tunnels
with
a
fallback
fall
back
on
best
of
our
tunnels.
That's
the
default
mode
and
bgbct
routes,
because
they
want
to
confine
to
only
tunnels
on
that
transport
class
without
having
any
fallback
they.
Q
The
transport
route
target
is
used
as
a
mapping
community
on
those
routes
and
it
resolves
strictly
over
the
color
internals,
and
if
users
want
different
resolution
schemes
saying
I
want
a
primary
path
through
gold
versus
a
backup
path
from
silver,
so
those
can
be
separate
resolution
schemes
that
can
be
configured
on
the
box
next
slide.
Please.
Q
So
this
is
just
a
p
cap
to
show
how
similar
the
update
looks
like
just
like
s3
vpn.
So
we
just
have
the
route
target
transport
cluster
target
and
instead
of
1
128,
it
is
just
1
76
and
it
will
be
276
for
v6
and
we
have
the
article
at
the
end
point
next
eye.
Please.
Q
So
this
this
picture
just
recaps,
whatever
we
just
talked
about,
so
it
just
shows
an
example.
Two
asses
the
left
side.
As2
is
strict
into
two
domains
and
we
have
the
border
nodes
in
this
ass,
which
are
like
abr
and
the
asbrs.
Q
So
the
bgbct
routes
they
can
be
either
originated
at
be11
or
they
can
be
originated
at
asbr
one
one
at
asbr,
one
one.
They
will
be
redistributing
the
rsvp
or
srte
or
flex
routes
into
bgbct,
and
they
will
create
the
swap
routes
at
asbr,
one
one
and
they
will
get
further
redistributed
by
asbr-23
across
to
abr
two
two
across
to
pe21
and
at
each
of
these
border
nodes,
where
it
is
doing
the
stop
self,
it
will
just
emit
the
mpls
forwarding
entries
which
connects
these
lsps
of
the
same
color
and
at
be21.
Q
We
can
just
map
the
service
routes
that
are
coming
with
the
mapping
community
of
gold
or
bronze.
To
say
that
I
want
to
map
the
service
traffic
to
the
code
so
end
to
end.
We
get
the
service
traffic,
taking
the
gold,
lsb
and,
needless
to
say,
asbr.
One
one
could
also
have
service
routes
received
which
can
resolve
over
the
same
gold
lsp
in
the
same
way.
Q
So
I
wanted
to
take
a
moment
to
recap
the
advantages
of
using
4364
encoding,
so
we
use
the
route
distinct
user
to
allow
the
multiple
distinguishing
between
the
multiple
tunnels
to
the
same
destination,
so
it
avoids
using
multiple
loopbacks
to
the
agrespe
primarily
and
it
avoids
path
hiding
when
press
transiting
through
the
rrs
or
than
asbr's
allows
unambiguously
identifying
the
originating
pe.
It's
good
for
debugging,
and
it
also
supports
tunnel
endpoint
being
in
any
cast
address,
participating
in
multiple
domains,
for
example,
and
it
allows
path.
Q
Selection
for
the
tunnel
end
point
after
stripping
the
rd
when
necessary.
So
this
is
helpful
for
faster
convergence.
So,
basically
rd
is
an
identifier
of
convenience.
We
can
use
it
when
needed
to
go
through
rs
and
avoid
path
hiding
and
we
can
strip
it
when
it
is
not
needed
and
it
is
preserved
end
to
end.
So
there
is
no
ambiguity
there
and
using
the
4364
style
route
target
to
propagate
transport
class,
so
that
allows
forming
venn
diagrams
of
color
domains
as
desired.
Q
It's
it's
basically
directly
maps
to
the
l3
vpn
like
vpns
that
we
have
and
we
can
have.
We
can
support
different
models
where
you
can.
You
have
core
networks
having
more
fine-grained
colors,
and
the
access
networks
may
not
have
that
many
colors,
so
those
can
also
be
represented
in
this
model
just
by
using
multiple
route
targets
on
a
route
or
a
different
kind
of
the
core
domains
having
a
different
target
import
and
the
access
domains
having
a
different
authority,
input
and
other
creative
use.
Q
Cases
can't
be
possible,
as
we
have
seen
with
the
l3
vpn
in
general,
and
treating
color
as
an
attribute-
that's
an
adjective
rather
than
part
of
the
nlri.
It
helps
in
cases
where
domains
have
different
numbering
of
color
values
attribute.
Rewrites
is
easier
than
rewriting
and
larry,
and
there
is
no
ambiguity
of.
Where
is
my
color.
It's
always
as
an
attribute
as
part
of
the
row
target
and
because
of
reusing
4364.
We
can
also
reuse
our
target
constraint
procedures
to
do
on-demand
next
up
and
they
they
there
is.
Q
Q
What
transport
class
routes
we
want
and
the
access
nodes
can
just
request
an
rtf
for
those
transport
class
routes
enabling
them
to
receive
only
the
pgpt
route
that
they
need
and
it
basically
reuses
the
time-tested,
well-deployed
vpn
machinery
and
that
cut
downs,
implementation,
time,
testing
time
and
improves
real
reliability,
and
I
would
also
I
mean
I'm
a
big
fan
of
rfc
1925
and
one
of
the
points
that
I
like
that
is
in
protocol
design.
Q
Q
So
these
are
the
updates
since
ietf108.
So
we
just
added
some
illustration
with
a
topology
with
which
helps
understand
the
procedures
described
before
in
the
previous
sections
added
mpls,
om,
section
and
documented
case,
updated
and
abs
doing
next
top
self,
basically
rs
with
next
upsell.
Whenever
there
is,
they
do
forwarding
this.
This
problem
can
happen
and
it
found
surprisingly,
it's
not
recorded
anywhere.
We
just
took
the
opportunity
to
record
it
in
this
draft.
Q
We
will
look
at
it
in
detail
in
the
next
two
slides
and
we
added
scaling
consideration
section.
I
recommend
rfc8218212
as
a
default
behavior
for
city
family,
which
basically
says
don't
export
anything
to
be
pgpos
without
having
an
explicit
export
policy
and
raw
target
filtering
can
be
used
for
vgpct
to
provide
odn
and
mdls
namespaces.
This
is
a
new
concept
that
can
be
applied
not
only
to
cd,
but
also
to
bgplu
networks,
to
deal
with
scaling
and
in
seamless
mpls
networks.
Q
So
there
may
be
a
presentation
for
this
topic
in
best
working
group
if
time
permits-
and
we
also
added
the
applicability
network
slicing
section,
because
it
was
brought
to
us
notice
that
the
transport
class
part
of
this
solution,
it
fits
nicely
to
the
it
represents
a
topology
slice,
part
of
transport
slice.
Q
So
a
transport
slice
in
network
slice
is
a
topology
slice
added
with
some
resources
to
it.
So,
the
time
that
the
transport
class
neatly
provides
a
topology
slice
that
the
service
routes
can
bind
to
and
since
ietf108
we
have
also
had
good
discussions
on
the
mailing
list
and
we
have.
We
are
very
pleased
to
welcome
co-authors
from
verizon
cox,
alibaba.
Google.
Q
Thank
you
for
your
support
and
we
have
working
code
next
time.
Please.
Q
Okay,
so
this
is
just
I
mean
case
of
redundant
abs
in
a
bgp
network
where
they're
doing
next
top
self
and
they
can
be
looped,
that's
formed
in
between
them.
Can
you
go
to
the
next
site?
Please
I'll
just
explain
using
the
topology.
Q
So
here
we
have
redundant
abrs,
which
are
basically
rs
with
next
top
self.
And
if
you
look
at
this
picture,
abr
23
will
be
receiving
the
routes
with
abr
22
as
the
next
stop,
as
well
as
the
asbs
as
the
next
stop,
and
it
may
so
happen
that,
because
of
igp
metric
abr,
23
may
choose
ebr22
as
the
best
path
and
api
22
may
do
the
same
and
there's
another
gacha
with
rr
rfc,
where
it
considers
cluster
list
path.
Q
Selection
after
doctor
id-
and
that
is
also
another
thing
because
based
on
the
router
id
it
they
may
select
each
other
so
network
planners
have
to
carefully
select
the
igp
metrics
so
make
sure
that
the
abs
select
the
asbr
instead
of
the
pr
abrs,
but
with
ct
we
have
even
better
alternative
deployment
wise.
If
you
don't
provision
the
color
tunnels
between
abrs,
they
will
never
select
each
other.
As
the
next
stop,
so
that
avoids
a
traffic
loop,
that's
just
what
I
wanted
to
point
out
exactly.
Q
Okay,
so
these
are
just
the
related
wraps,
so
the
first
draft
is
extending
a
piece
up
to
carry
a
color
for
rsvp
tunnels,
so
I
think
we
already
have
a
piece
of
graph
for
srt
tunnels,
but
this
is
what
this
is
doing
for
rsvp,
so
that
it
just
completes
the
solution
and
seamless,
ssr
use
cases.
This
is
a
draft
that's
already
existing.
You
may
be
familiar
with
it.
Q
It
just
explains
the
various
use
cases
possible
using
bgpct,
and
there
is
this
draft
that
we
are
working
on
to
provide
and
drop
between
srv6
and
mpls,
and
the
fps
name
spaces
that
we
just
talked
about
and
the
generic
rtc
is
an
extension
to
target
filtering
to
make
it
work
with
the
wider
row
targets.
So
it's
just
the
other
draft
that
are
there
to
complete
the
whole
solution,
and
I
think
that's
the
end
of
my
presentation
and
on
behalf
of
others.
Q
So
I
we
feel
that
we
are
at
a
stage
where
we
can
request
for
the
group
adoption
of
this
draft,
so
we
will
make
that
request
formally
to
the
chairs
to
consider
it.
A
K
R
S
Kowski
speaking
as
do
you
hear
me,
does
it
work?
Agreeing
oh
okay,
good
yeah,
stefan
kowski
speaking
as
a
best
co-chair,
I
think,
before
adopting
the
document
which
you
should
also
clarify
to
which
working
group
this
document
belongs,
because
there
are
a
lot
of
things
that
are
related
to
vpn,
semantics
and
so
on,
and
this
is
more
something
which
is
related
to
to
base.
S
So
we
should
also
have
a
discussion
on
between
the
shares
on
where
this
is
what
is
a
good
home
for
for
this
work
whatever
it
is.
This
is
a
placeful
transport
document,
but
there
are
also
other
documents
that
are
related
to
the
same.
N
Hello,
hello,
okay.
I
have
a
question
that
I
think
this
this
chapter
defined
a
new.
K
N
This
stuff,
you
will
use
the
rd
plus
prefix
and
also
as
a
key
and
also
use
a
transport
class
that
can
community.
So
there
are,
the
this
method
include
import
two
or
two
new
value:
one
is
the
id's
and
the
other
is
the
transfer
class.
So
I
think
it
may
cause
the
user
to
plan
plan
the
network
more
flexible.
So
so
is
it
you
is
it
suitable
to
use
the
new
value
or
or
otherwise
we
may
use?
Only
one
value
you
know
is
enough.
Q
So
the
safety
is
a
new
to
make
it
a
new
fsafe
so
that
it
doesn't
collide
with
any
other
service
families.
So
that's
separate
from
the
road
target
you
type
of
road
target,
that's
a
new
format
of
route
target,
in
fact
new
format
of
external
committee-
that's
transport
class.
So
there
are
two
different
things.
C
I'm
sorry
actually,
apologies
sue
says
that
we
have
to
cut
the
line
now.
A
We
need
to
have
ajung
go
next
on
his
presentation.
The
car
presenter
is
running
into
trouble.
So
assume,
could
you
go
next,
please
this?
This
is
jeffy
only
to
go
forward.
I
Hi,
this
is
guillaume
with
verizon
and
I
will
be
presenting
the
analysis
of
vpn
routes
controlled
at
a
shared
vgp
session.
So
this
this
is
for
the
rdrf
solution.
I
guess
on
the
mailing
list,
as
was
discussed,
to
present
and
review
the
analysis
of
filtering
the
vpn
routes
and
coming
to
any
consensus
before
we
move
on
to
the
solution.
I
So
the
motivation
of
this
draft
describes
a
scenario
where
we
need
to
control
vpn
routes
on
a
shared
session,
pgp
session
between
the
pe
and
rr,
where
we
have,
where
a
flood
of
routes
get
advertised
between
the
from
a
source
pe
to
a
downstream
receiver.
Pe
the
goal
is
to
reach
consensus
on
the
problem,
analysis
and
solution
requirements
and
then
nostalgic
based
base
for
the
to
forward
into
the
updated
solution.
I
I
Slide
so
we'll
start
with
the
simplest
scenario,
so
this
is
intra
intra,
as
so.
In
the
entry
is
scenario
we
have
a
case
a
case,
one
where
we
have
an
art.
We
have
already
allocated
per
vpn,
slash
pe,
so
unique
rd
per
pe,
and
only
one
rt
is
associated
with
such
vpn
routes.
So
in
this
case
the
pe3.
It
sends
an
excess
routes
for
v
for
vpn,
with
the
route
target
of
one.
So
so
the
the
vpn,
the
p3
source,
p
with
vpn
one
rd3,
is
the
offending
one.
I
I
The
second
use
case
is
a
scenario
where
you
have
you
have
the
unique
rd
per
pe,
but
then
you
have
multiple
rt's
that
are
associated
with
vpn,
so
this
is
critical
to
take
into
account
where
you
have,
because
there
are
multiple
rts
that
are
being
that
are
associated
with
the
vpn.
In
this
case,
it's
rt1
and
rt2.
I
Both
rt1
and
rt2
are
imported
on
pe
1,
but
vpn
1
is
the
one
that's
obviously
receiving
the
flood
of
the
routes
where
vpn
2
has
rt-2.
But
it's
not
it's.
It's
also
imported
imported
into
vpn
2,
but
it's
not
being
being
flooded,
so
that
is
something
to
take
into
account
in
the
solution,
for
the
intra
is
as
well
as
this
comes
into
play
as
well
in
the
enter
a
scenario.
I
I
Slide
in
the
interior
scenario,
the
same
same
situation
exists
where,
where
you
have
a
single,
a
single
rt
for
a
particular
vpn
or
multiple
rt's
imported
for
a
particular
vpn,
so
for
the
nra
scenario,
options
b,
a
b
and
c
yeah
yeah,
we
have
a
bgp
session,
that's
shared
between
the
asb
r1asbr2,
the
vpn
ipv4
ipv6
session
between
the
sdrs
and
then
between
the
pe
and
asbr.
I
You
have
a
session
so
so
the
possibility
exists
that
you
could
have
an
excess
of
vpn
routes
advertised
same
way
that
we
have
with
indian
tria
scenario
so
the
overall
route,
so
the
flood
of
routes
coming
from
the
source
p
from
the
as
on
the
right
pe
three
here
we
have
vpn
one
rd-331
is
sourcing
the
flood
of
routes
and
that
that
vpn,
if
it
is
being
imported
by
p1,
the
receiver
p,
which
is
being
impacted
so
in
this
scenario,
having
a
way
to
control
the
vpn
routes
that
are
originating
from
the
source
source
rd-31,
that's
flooding,
vpn
one
in
this
scenario
as
well,
there's
also
the
scenario
where
you
have
multiple
rts
that
are
associated
that
are
being
imported
on
the
on
the
source
pe,
but
to
take
into
account
that
only
to
filter
only
to
filter
the
routes
between
the
sbr
and
pe
one.
I
So
so
vpn
routes
up
in
this.
In
this
scenario
we
have
we
have
vpn
routes
that
are
being.
We
have
the
common
lp
to
our
session.
That's
shared
vpn
vpnp
for
ipv4
ipv6
routes
that
are
being
advertised
down
to
the
pe
and
we
have
a
source
pe.
That's
advertising,
a
flutter
balance,
so
the
pe
one,
that's
being
impacted
by
the
flood
of
routes
from
a
from
a
source.
P.
That's
advertising
for
a
particular
source
rd
we
need
to.
I
The
p
should
have
the
capability
of
controlling
that
distribution
of
vpn
routes
with
some
type
of
mechanism,
but
the
key
here
is
only
when,
when
the
the
the
vpn
that
that
has
a
flood
is
is
associated
with
this
is
the
impact.
That's
impacted
that
all
vpn,
all
vpns,
that
are
associated
with
that
rt
are
impacted,
and
that
is
the
only
time
where
the
routes
would
be
filtered
between
the
pe
and
the
rr.
I
If
there's
a
single,
if,
if
there
is
a
more
than
one
vpn
that
exists,
that
are
importing
multiple
that
are
importing
the
same
route
target
multiple,
you
know
in
the
case
where
there's
multiple
rt's
associated
with
the
vpn.
That
is
something
we
would
take
into
account
and
that's
where
we
would
not
send.
We
would
not
filter
the
routes
between
the
p
and
the
rr
next
slide.
I
So
solutions,
so
potential
solutions
would
have
to
meet
the
following
requirements.
So
the
control
messages
on
the
for
the
specific
vpn
routes
will
be
triggered
automatically
upon
hitting
an
excess
vpn
route
limit.
So
the
maximum
prefix
limit
on
the
on
the
vpn
hitting
a
certain
threshold
and
with
that
trigger,
there's,
there's
certain
criteria
for
the
control
message
to
be
sent
out
to
to
block
the
the
source
pe
that's
flooding
for
a
particular
rd,
so
at
the
pe
layer,
when
all
the
vrs
on
it
don't
want
to
process
it.
I
The
control
message
would
simply
sent
out
at
the
pe
layer
at
the
rr
layer
upstream
when,
when
all
of
its
vgp
clients
don't
want
to
process
the
the
the
flutter
routes,
then
the
then
the
control
message
would
be
sent
upstream
to
to
block
the
flood
arounds
and
then
at
the
asbr
layer
as
well.
When
all
of
its
downstream
peers.
Within
that,
as
don't
want
to
process
the
routes,
then
it
would
be
sent
interac
to
the
other
adjacent
sbr
and
then
and
then.
I
Lastly,
if
all
if
all,
if
all
of
the
above
you
know
don't
want
to
process
the
process,
the
vpn
routes
that
that
the
that
the
control
message
would
be
sent
upstream.
So
this
this
would
be
an
automatic
control
message
that
would
be
sent
out
based
on
the
trigger
that
happens,
based
on
a
maximum
prefix
or
other
type
trigger
that
would
trigger.
I
It
would
send
the
control
message
to
step
b
with
a
step
c
manual,
removal
of
the
control
message
just
to
prevent
any
possible
instability
of
flapping
that
could
possibly
occur
next
slide.
I
So
we'd
like
to
get
comments
on
questions
and
comments
related
to
the
the
problem
statement
and
then
and
then
and
then
the
goal
is
to
have
a
clear
definition
of
the
problem
and
be
able
to
move
on
to
the
solutions
and
requirements
for
the
solution
and
start
on
updating
the
solutions.
Draft
next
slide.
A
I
I
All
right,
thank
you,
so
potential
solution,
potential
and
proposed
solution.
So
once
we
receive
the
consensus,
consensus
and
we'll
we'll
take
this
to
the
mailing
list
as
well,
just
to
make
sure
you
know,
everyone
is
in
consensus
on
the
problem
statement
and
then
we'll
we'll
move
forward
and
go
on
to
the
solution
up
so
now,
we'll
proceed
to
the
next
slide.
Next
slide,
all
right.
I
So
as
far
as
the
solution,
starting
with
the
simplest
intra-as
scenario,
so
in
this
case
number
one.
So
once
so.
In
this
scenario,
we
have
a
source
pe
p3
with
a
vpn
one.
So
there's
a
single
round
target.
I
That's
has,
has
the
that's
sourcing,
the
flood
of
routes
related
to
our
rd
rd31
and
we
have
a
receiver
pe
pe1,
that's
receiving
the
flood
of
routes
or
rd
ferrari,
one
one,
that's
being
impacted
so
once
so
here
in
this
first
case,
once
p1
detects
vpn
one
the
vr
has
overflown,
he
has
a
few
checks
that
he
goes
through.
He
will
check
to
see
if
the
vpn
routes
are
that
he
has
our
rd31
that
are
that
are
causing
the
access
routes
coming
from
from
rt1
for
rt1.
I
That
are
being
imported
and
then
our
rd
checks
for
the
rd31
source
of
the
flutter
routes,
and
then
he
ensures
that
no
other,
no
other
vrs
are
importing
the
vpn
routes
for
rt1
before
before.
A
the
mechanism
for
the
trigger
connect
can
happen.
I
C
I
Okay,
so
let
me
just
back
up
a
little
bit
so
pe
one
triggers
an
rd
rf
message
to
a
to
our
2r1
with
the
rd
field
set
to
rd31
r1
withdraws
and
stops
advertising
the
message:
advertising
the
pre
access
vpn
routes
to
pe
one.
I
So
once
once
vpn
service
and
p,
the
pe
one
will
will
continue
operate.
So
all
the
other
vp.
All
the
other
route
targets
are
not
impacted,
it's
just
it's
just
the
rt1
and
it's
really
in
the
rd31.
I
I
In
the
in
the
case
on
the
right
so
case
use
case
number
two
on
p1
we
detect
vpn
one
beat
the
vr
if
it's
overflown,
so
this
is
for
vpn
one
rd31
rt1
is
a
source
p
on
p3,
so
pd3,
that's
has
rdd
rt1
sourcing,
the
flood
of
routes
and
in
this
case
p1
he
has
the
import
of
vpn
vpn
one
importing
rt1,
but
in
this
case
there's
two
rts
where
the
rt1
and
rt2
are
being
imported
by
two
different
verbs,
vpn,
1
and
vpn
2.
I
epn1
is
impacted,
but
vpn
2
is
not
so
in
this
case
the
pe
one
because
of
all
all
vpns
there's
multiple
vpns
are
importing.
The
rt
p1
would
not
send
out
an
rd
rf
back
towards
r1.
So
this
is
a
careful
consideration
in
its
local
configuration
as
part
of
the
specification
that
we
would
only
send
the
rdo
rf
for
all
the
vpns
that
are
attached
to
the
pe
or
not
or
are
importing
the
that
are
importing
the
round
target
that
are
being
flooded.
I
So
in
this
case,
if
because
there's
multiple
rts
are
imported
by
multiple
vpns,
but
the
other
vpns
are
not
impacted,
we
would
not
send
the
rdrf
up
to
the
armor
next.
One.
I
Thank
you,
okay.
So
this
is.
This
is
the
nras
scenario.
So
if
so,
in
this
scenario,
we
have
the
same
consideration
that
happens
if
the
excess
vpn
routes
are
vpn,
one
or
two.
So
in
this
case
we
have
vpn
one
rd31
is
the
source
rd,
that's
being
that's,
being
advertised,
that's
being
flooded
over
from
the
as
on
the
right
to
the
as
on
the
left,
it's
being
imported
by
pe1.
I
So
so
here
in
this
case,
if
there
are
no
other
vpn
vpn
to
import
the
rt
than
the
xfcc
few
routes,
the
cad
so
p1
will
trigger
an
rdrf
with
the
field
set
to
rd31
or
rd32
and
it'll,
send
it
up
to
the
sbr.
So
as
long
as
there's
no
other
vpns
that
are
input
that
are
importing
that
that
rt
or
rt1,
that's
the
impacted
one.
I
So
when
is
when
the
asbr
one
receives
the
such
an
rdrf
message,
they'll
check
if
all
its
downstream
peers
have
sent
the
same
message
or
and
that
to
process
the
vpn
routes
with
the
access
capability
it'll,
send
it
up
it'll,
send
the
message
upstream
to
sbr2,
so
it'll
they'll
do
the
check
and
make
sure
all
the
downstream
peers
have
sent
an
rdrf
and
then
it
would
send
it
send
the
rdrf
upstream,
so
p1
and
p2
is
receives
the
rdrf
from
both
sets
with
the
arduino
set,
with
the
field
set
to
already
three
and
then
the
sbr
one
will
send.
A
Your
url
stream-
yes,
I'm
I'm
really
sorry.
We
have
to
stop
the
presentation
at
this
time
in
order
to
give
the
next
presenter
a
potential.
Could
you
just
wrap
up
your
slide?
Please?
Yes,.
I
Sure
so
I
think
at
this
point
I
think
we
could
we
can
take
questions
if
anyone
has
any
questions
or
comments
and
then
we
can
take
it
to
the
mailing
list,
any
any
kind
of
questions
or
comments
on
the
problem
statement
or
the
solution.
C
I
I
think
we're
going
to
defer
those
to
mailing
list
or
to
chat
okay,
all
right.
Thank
you.
Thanks
for
the
presentation.
T
Yeah
hi,
I
will
present
yes.
T
Ahead,
yeah
hi,
so
this
is
a
this
is
about
bgp
colorway,
routing
problem
statement,
and
these
are
the
authors
and
the
co-authors
that
we
are
working
for.
This
problem
document
can
go
to
the
next
slide,
so
bgp
colorway
routing
is
about
providing
an
end
to
end
intent,
aware
path
in
the
multi-domain
service
provider
network
and
by
intent.
What
we
mean
is
like
low
latency
or
to
avoid
certain
link
or
even
the
even
avoiding
certain
domains.
That's
a
what
want
to
create
an
end
to
intent,
aware
parts
next
slide.
T
So
there's
a
reminder
for
deployed
solution.
We
know
today
there's
a
srt
based
solution
in
which
the
which
is
defined
in
the
spring
already
with
iit
of
spring
segment,
routing
policy
document,
it's
mature,
widely
deployed,
and
it
has
multiple
implementations
and
it
it
has
a
notion
of
color
to
represent
the
intent
and
in
the
bgp
car
solution.
We
will
just
extend
that
notion
of
color
to
represent
the
intent
mentioned
in
the
initial
slide.
T
So
the
way
it
works
today
is
existing
solution
would
be
we
as
we
are
showing
in
this
picture.
We
have
a
e3
which
is
which
is
advertising.
The
vpn
prefixes
through
service
rr
to
e1
and
e1
and
e3
are
your
ps
and
now
what
is
important
is
a
vpn
service.
That
means
in
this
v
v
is
requesting
a
colored,
a
color
service.
T
T
T
So
automated
steering
evolution
now
we
want
to
provide
same
facility
whatever
we
are
done
in
the
state
of
our
today
by
via
srpc.
Now
we
want
to
do
through
bgp.
So
what
we
want
to
do
is
we
want
to
advertise
the
reachability
to
e3
with
a
certain
intent
and
that
intent
that
intent
provides
the
using
the
inter
domain
intents
like
flex,
algo
sr
policy,
so
we
want
to
advertise
the
e3
reachability.
T
T
T
They
should
be
interworking
off
between
these
two
solutions,
because
this
is
a
well
deployed
solutions
to
provide
intent,
aware
path
in
multi-domain
network,
and
we
want
to
keep
the
constrain
concept
of
color.
It's
it's
a
it's
a
built-in
color
which
which
provides
the
automated
steering
today
and
the
scope
is
not
just
about
transport.
The
scope
is
about
also
intent,
aware,
vpn
layer,
because
we
know
a
ce
may
also
want
to
go
through
a
transport
network
which
provides
that
intent,
not
just
a
pe,
and
so
we
want
to
integrate
with
the
nfv.
T
So
this
solution,
like
sr
srt
solution,
already
integrates
with
the
nfv
we
can
put
the
segments
of
nv.
This
solution
should
try
to
provide
that
intent
away
parts
also,
so
the
clarity
on
the
scale
requirement
and
constraint.
What
we
are
talking
about
here
is
now
advertising.
The
transport
addresses
the
pe
loopbacks
with
the
intent,
so
the
today
we
just
advertise
the
best
effort.
If
you're
trying
to
advertise
the
intent
with
bgp,
our
scale
will
increase.
T
So
we
have
for
this
problem
statement.
We
have
been
collaborating
with
lead
operators,
the
vendors
on
the
analysis,
and
we
would
like
to
acknowledge
the
contribution
to
this
stuff
by
many
such
operators
and
the
vendors,
and
we
recognize
the
prior
work
in
this
area,
which
is
seamless
sr
and
the
class
full
transport
that
is
already
presented.
T
T
No,
I
am
fine,
so
I
will
move
to
the
next
slide,
which
is
about
the
bgp
actual
bgp
solution.
The
first
one
was
a
problem
statement,
so
this
is
a
bgp
colorway
routing
solution
document
we
have
published.
T
Yeah
so
since
we
just
discussed
in
the
problem
statement,
we
have
to
advertise
the
reachability,
with
the
multiple
intents
now
to
reach
a
certain
pe
or
the
end
point.
We
need
to
advertise
the
same
prefix
with
the
different
intents,
so
we
need
a
ability.
So
that
means
we
need
a
new
safi
in
which
we
can.
T
We
need
ability
to
signal
the
multiple
instances
of
the
same
prefixes
for
each
of
the
colors
for
each
of
the
intents,
the
requirement
and
the
solution
draft
discusses
the
following
aspect:
the
desired
data
model,
because
we
know
it's
a
new
safi
and
we
have
to
advertise
the
multiple
instance
of
the
prefix
and
what
we
support
is
the
multiple
encapsulations.
We
have
to
support
mpls
srv6
ip
different
types
of
encapsulation,
their
signaling
as
well
as
validation.
So
we
should
also
validate
that
the
encapsulation
is
programming
the
hardware
we
have
to
also
go.
T
We
also
go
into
the
aspect
of
route
resolution:
how
to
resolve
these
bgp
car
routes
over
the
intradomain
tunnels,
which,
which
would
be
which
and
the
intent
can
be
provided
by
the
sr
policy
or
through
the
igpfa
or
through
even
it
can
be.
Also
supported
by
rsvpt
or
sr
mpls
or
ldp
for
the
fallback
cases,
and
also
the
steering
mechanism.
T
As
we
discussed,
the
steering,
the
notion
of
color
is
central
for
the
steering
of
steering
of
the
vpn
services
into
these
bgp
color,
aware
routes
also,
it
has
to
be,
as
we
provide
the
scale
characterization,
because
we
know
for
best
effort.
We
advertise
only
a
single
bg
prefix,
but
now
with
the
intent
we
are,
we
are
multiplying
that
number
its
number
of
p's
into
number
of
intents.
You
provide
in
a
network,
so
the
scale
characterization
is
very
important
to
see
this
transport
network
can
scale
to
the
requirement,
and
that
brings
the
next
next
aspects.
T
Route
filtering
route
filtering
is
to
make
sure
I
will
go
in
that
just
to
we
filter
what
we.
What
you
are
interested
in
the
next
slide.
T
So
the
data
model
is,
we
have
to
advertise
the
pe
ipv
for
loopback
or
ipvc's
loopback.
So
that's
the
is
in
the
global
space.
That's
the
prefix
in
the
data
model
color,
as
we
discussed,
distinguishes
different
instances
of
the
prefix
and
also
it
indicates
the
service
or
intent
associated
with
the
route.
What
it's,
whether
it's
a
low
latency
prefix
or
it's
a
it's,
providing
a
avoiding
certain
links
or
avoiding
certain
domain.
So
that's
the
intent
that
color
provides
the
next
stop.
T
Bgp
next
stop
is,
as
usual,
it
provides
the
reachability
verification
in
the
control
plane,
the
encapsulation.
We
have
to
support
different
technologies
that
is
existing
mpls
srvcc
or
the
ip.
We
should
also
support
the
multiple
encapsulations
and
reason
is
for
migrations
and
coexistence
cases
in
the
same
network.
T
T
So
the
proposal
for
the
car
is
the
nlri
key
is
e.
Is
our
end
point
the
pe
loopback
address
most
likely
in
this
case,
so
it's
an
ipv
for
an
ip6,
endpoint
prefix
and
we
have
to
understand
this
is
network
wide
unique,
so
e
provides
that
uniqueness
and
color
is
the
ways
to
advertise
it
and
also
the
intent
as
we
discussed
so
color
color
is
consistent
across
the
devices
within
the
color
domain.
So
that
means
the
color
mapping
is
in
a
domain
is
consistent.
All
the
device
understand
a
specific
color
for
specific
intent.
T
T
And
next
is
a
prefix
is
unique,
is
unique.
In
the
inter
domain
transport
network
example,
p
makes
e
comma
c
unique,
even
if
c
is
local
to
a
color
domain.
So
that
means
if
the
color
mapping
changes
and
if
you
advertise
this
nlri
to
a
different
color
to
a
different
domain,
where
there's
a
color
mapping
is
not
consistent,
then
also
e,
comma
c
makes
it
the
nlr
unique
next
slide.
Please.
T
So
there's
also
a
local
color
mapping
extended
community
introduced
in
a
trough.
It's
optional,
it's
used
only
if
we
go
across
the
color
domain
boundary.
So
if
you,
if
there
is
not
a
consistent
mapping
of
the
color,
we
will,
we
will
attach
this
extended
community
and
that
would
be
a
map
locally
in
the
domain
into
the
domain.
Understanding
of
that
color,
so
the
nlri
does
not
get,
is
not
re
written
at
such
inconsistent
mapping
of
the
colors.
It's
preserved
end
to
end
next
slide.
Please.
T
So
encapsulation
it's
very
important
that
since
it's
a
new
safety,
we
are
adding,
we
have
to
make
sure
we
don't
take
the
baggage
of
the
pass.
So
we
don't
want
the
to
be
our
new
safety,
be
constrained
by
the
24-bit
mpls
that
we
have
in
today
in
our
different
types
whenever
we
encaps
the
label,
so
it's
an
opportunity
to
have
a
more
cleaner
design.
T
Also,
we
have
to
make
sure
the
the
nlri
carries
the
variable
part
of
the
encapsulation
for
the
packing
efficiencies
and
that's
what
is
already
in
the
in
our
proposal
and
also
validate
the
data
plane
for
the
encapsulation
availability
before
we
use
before
we
make
a
bgp
best
partition.
We
also
may
make
sure
that
the,
since
we
will
like
to
support
multiple
encapsulation,
you
have
to
make
sure
those
encapsulations
are
programmed
in
the
forwarding
before
you
make
those
decisions.
T
So
scale
considerations
as
discussed.
We
are
talking
about
bgp
transport
and
that
transport
is
now
advertising
the
intent
also,
which
can
it
could
be
four
to
five
intense
or
more
than
that
in
a
network.
So
there's
a.
We
have
to
make
sure
that
our
current
mpls
limitation
of
one
million
labels,
we
can
still
make
the
things
work
and
for
that
we
need
a
higher
design
and
this,
what
we'll
make
sure
is
our
core
routers.
T
That
means
something
which
is
in
our
core
or
core
doesn't
learn
all
the
pep
addresses.
They
only
learn
the
addresses
for
from
the
for
of
the
border
routers
and
but
that
becomes
that
brings
the
recursion,
as
well
as
the
data
blink
complexity
at
the
ps
and
vr.
T
So
those
are
discussed
in
the
document
and
the
most
important
aspect
is
the
filtering
because
of
the
scale
as
p
as
the
ps
learn
the
service
route,
we
should
make
sure
that
pe
only
get
the
intent
of
a
bgp
car
routes
for
which
it
is
interested.
It
only
learns
the
end
points
and
its
intents
for
which
the
for
which
the
service
are
talking
to
each
other.
T
So
that
brings
the
filtering
mechanism
that
is
introduced
in
this
document
that
we
make
sure
we
only
learn
the
ps
for
which
the
pe
or
even
ingress
beer,
be
a
border
route,
has
an
interest
so
that,
in
the
pr
also
doesn't
have
to
scale
to
the
label
skill
required.
T
T
So
next,
so
we
want
a
working
group
to
review
this
document.
Thank
you.
A
It's
over
time.
Thank
you
for
your
time.
The
authors
may
take
questions,
but
pretty
much
within
two
or
three
minutes.
C
So
my
suggestion
is
the
official
meetings
over
at
top
of
our.
We
have
basically
a
few
minutes
until
the
meet
echo
service
simply
terminates
the
session
without
warning.
So
if
somebody
wants
to
be
brave
enough
to
ask
a
question
and
the
chance
of
being
cut
off,
I
would
say:
go
for
it.
Please.
V
I
have
a
question
about
different
distance
instance
over.
I
thought
we
already
have
raw
distinguisher
to
distinguish
different
prefix.
So
what
does
that
different
instance
mean
here
in.
T
Your
slides
so
today,
today
in
the
global
in
the
transport
network,
there
is
no
route
distinguisher.
This
is
something
it's
a
new
office.
Coffee
we
are
introducing.
Oh,
we
are
still
a
distinguisher.
We
are
thinking
would
be
a
color.
As
we
know,
the
notion
of
the
color
is
the
is
to
carry
the
intent
from
the
from
the
past
by
srt
mechanism.
So
we
want
to
use
the
same
notion
of
color
to
advertise
the
different
ways
to
reach
a
particular
prefix.
In
this
case
a
particular
pe
or
a
low
back
of
it
e.
V
V
T
V
C
A
Not
I
believe
we
are
done
up,
there's
one
coming
in.
Q
C
Q
T
T
Can
you
repeat
that
kali
I
didn't
follow.
Q
So,
are
you
saying
that
srt
is
not
extendable
enough,
that
it
can
be
reused
between
pgp
speakers?
It's
only
between
a
controller
and
a
speaker,
and
we
need
a
new
family
between
a
bgp
speakers.
T
Yes,
so
there
is
no
mechanism
for
the
srts
with
a
pc
way,
not
through
bgp.
There
is
a
sr
policy
which
can
be
downloaded.
It's
a
it's
a
policy
that
download
the
header.
In
this
case,
we
want
to
advertise
distributed
way
up
at
endpoint
address
through
the
hop
by
hop
mechanisms.
T
So
there's
no
such
mechanisms
today
and
as
we
are
talking
about
this
pro,
as
we
saw
the
problem
statement
and
the
solution
for
it,
we
we
just
want
to
use
the
semantics
about
ed
point
and
the
color
as
it
was
used
by
srt,
so
that
no
notion
remains
exactly
same
as
we
already
discussed
it's
about
going
over
particular
intent,
aware
path
which
was
which
today,
which
is
well
deployed,
it's
exactly.
We
want
our
services
that
steered
exactly
same
way
it
just
now.
It's
another
solution
is
using
bgp
card
and
they
should
interwork
and
should
work.
U
I
think
it's
important
to
analyze
this
space
in
its
totality
and
see
how
we
better
best
address
that
solution
to
the
problem.
I
think
that
would
be
my
recommendation
is
that
we
would
look
at
the
different
aspects
on
what
we
want
to
achieve
and
then
see
how
we
best
solve
it,
given
the
capabilities
that
we
already
have
developed.
U
So
I
think
it's
important
that
we,
I
think
I
what
I
understood
is
that
there
is
already
a
discussion
between
the
different
I,
the
people
from
the
different
proposals,
because
there
are
a
bit
of
competing
proposal
that
we
work
together
and
try
to
find
out
the
common
ground
going
forward.
I
think
that's
important.
T
A
Then
start
tomorrow
we
have
a
session
on
wednesday.
A
Well,
go
ahead,
we'll
see
you
tomorrow,
I
believe
we're
at
the
second
session
tomorrow.
Thank
you.
A
W
I
believe
we
have
the
same
same
time.
I
believe
soon.
A
That
is
correct.
Thank
you
very
much
all
have
thank
you
for
the
excellent
discussions
we'll
see
you
tomorrow
at
14,
30.
A
I
hope
you
have
a
good
rest
of
the
day,
virtually
on
frog
time.
C
A
Where
do
you
go
for
the
test
sequence.
C
I
I
would
have
to
check
my
mailing
list
archives,
but
I
think
the
mail
was
sent
to
the
working
group
chairs
at
some
point
prior
to
the
session.
A
A
A
I
have
I
tried
the
application
sharing
and
that
didn't
work.
Okay,
what
do
you
think?
Do
you
see
the
application
hold
on
we'll
grab
the
pdf
okay?
So
now
I'm
actually
seeing
a
word.
A
A
B
W
A
W
A
W
But
sue
for
the
next
session,
either
jeff
or
me,
or
one
of
us-
can
always
share
the
screen.
If
you
want.
A
A
I'm
gonna
go
try
to
talk
to
the
medical
guys
and
figure
out
why
I
tried
last
time
I
used
nuance
pdf
shower,
but
that
I
I
thought
the
acrobat
would
be
more
commonly
used.
So
so
I
don't
know.