►
From YouTube: IETF-IDR-20220124-1500
Description
IDR meeting session at IETF
2022/01/24 1500
https://datatracker.ietf.org/meeting//proceedings/
B
C
B
B
A
B
B
As
with
any
iatf
meeting,
the
ietf
note
well
applies.
You
are
all
have
expected
to
have
read
this
by
this
point
and
you
are
bound
by
it.
Even
if
you
have
not
a
relatively
new
point
that
has
been
on
here
is
a
request
in
that
last
portion
of
the
reminder
section.
That
is
a
participant.
You
know,
please,
you
know
work
respectfully
with
all
the
other
participants.
This
is
generally
not
a
problem
in
idr,
but
we've
been
asked
by
the
isg
to
help
remind
people
of
this.
B
So
in
terms
of
our
general
agenda,
we
have
three
large
topics
that
we're
looking
to
cover
we'll
be
spending
the
first
portion
of
our
interim
discussing
the
topic
of
bgp
routes
with
color
and
we're
allocating
about
an
hour
for
this
half
an
hour
towards
the
bhp
auto
configuration
topic.
It
will
probably
be
somewhat
shorter
than
that
and
then
half
an
hour
towards
the
bhp
flowspec
v2
work
that
is
going
to
be
driven
mostly
by
sue
and
donald.
B
B
B
The
general
structure
we're
asking
for
on
each
of
these
topics,
since
none
of
these
things
are
due.
These
are
all
works
that
are
in
progress.
Is
that
we'll
be
giving
a
brief
reprise
on
the
pro
proposals?
For
you
know
the
protocol
extensions
of
bgp
we'll
be
discussing
the
changes
that
we've
seen
since
last
presentation.
Typically
since
the
last
ietf
in
most
cases,
be
leaving
open
time
after
the
presentations
to
discuss
the
details
of
the
proposals-
and
you
know
my
recommendation
is
each
of
the
presenters.
B
Once
we've
actually
had
some
discussion
we'll
be
beginning
our
discussion
about
you
know
what
do
we
want
to
adopt
as
a
working
group
now?
Clearly,
the
core
business
of
the
working
group
is
always
done
in
the
mailing
list,
so
the
actual
adoption
calls
would
go
out
there,
but
you
know
given
a
number
of
the
topics
I
have
more
than
one
proposal.
You
know
that
solves
the
problem
you
know
discussing
about.
B
So
that
said,
the
first
topic
that
we'll
be
presenting
from
is
bjp
routes
with
color,
and
I
wanted
to
take
a
mild
moment
since
we
have
people
who
english
is
not
a
first
language
to
make
a
small
bit
of
commentary
typically
a
way
that
this
is
often
stated
is
colored
routes.
This
sometimes
becomes
culturally
problematic
among
english
speakers,
so
I've
chosen
the
term
routes
with
color.
Certainly
you're
welcome
to
use
as
you
will,
but
this
is
a
recommendation
so,
as
part
of
our
presentations
here,
we'll
be
again
covering
the
problem
space.
B
We
are
going
to
be
having
a
brief
update
from
joel
halpern
who's.
One
of
the
spring
chairs
on
the
related
problem
statement
work
that's
happening
in
the
spring
working
group
as
part
of
the
proposals.
You
know,
the
authors
are
strongly
encouraged
to
highlight
the
functional
impacts
of
your
encodings
you're
encouraged.
B
These
two
proposals
may
not
be
solving
exactly
the
same
problem,
so
part
of
our
discussion
points
are
going
to
be.
You
know
what
problems
do
we
think
we're
solving
where
the
overlaps-
and
you
know
particular
discussions
about
the
encoding
impacts,
we'll
drive
our
discussion
eventually
towards
you
know
what
what
makes
sense
to
adopt.
So
as
we
move
towards
adoption,
you
know,
ietf
documents
become
the
work
of
the
working
group
itself.
B
B
Okay,
so
I
do
have
one
question
prior
to
handing
the
microphone
over,
the
joel
will
give
us
the
update
from
spring.
There
is
no
preferential
order
for
no
ct
versus
car
for
our
presentations.
Do
the
authors
have
a
specific
order?
They'd
prefer
do.
One
of
you
want
to
go
first
feel
free
to
use
the
chat
if
you'd
like.
A
C
Dj
yeah
generally,
I
would
have
said
I'm
good
with
either
too,
but
I
you
know,
happened
to
look
at
the
the
ct.
You
know,
presentation,
slides
and
they
seem
to
make
a
lot
of
comments
on
the
car
proposal.
So,
given
that
it
may
make
sense
to,
you
know
start
with
the
ct
proposal.
First-
and
you
know
you
know,
have
the
car
discussion
later.
B
D
D
D
So
we
asked
the
participants
to
form
a
design
team
to
agree
on
the
content
for
a
problem
statement
with
the
intent
of
then
handling
that
part
in
spring.
That
would
not
handle
protocol
encodings
protocol
mechanisms,
that's
idrs,
and
they
did
form
and
have
formed
and
are
working
on
a
design
team.
I
am
observing
their
calls.
I
am
on
they
copy
me
on
emails.
I
listen
to
the
calls.
I
am
not
a
participant.
D
I
am
trying
very
hard
not
to
express
a
preference
on
which
solutions
might
work
which
pieces
of
problem
are
more
important,
whatever
they're
trying
to
reach
agreement
on
the
problem
and
that's
what
we
need,
they
have
been
meeting
regularly,
sometimes
twice
a
week,
sometimes
once
a
week
they
sometimes
miss
a
week.
It
happens
but
they've
been
trying
to
meet
frequently
they've
been
trying
to
progress.
D
They
have
a
a
number
of
important
issues
that
they
have
not
yet
agreed
on
and
they
are
trying
to
progress.
Those
issues
I
am
hoping
they
will
get
to
being
able
to
at
least
have
a
draft
that
they
can
circulate
soon,
but
they
we
really
appreciate
the
effort
they
are
putting
in
to
try
to
get
to
a
common
problem
statement.
D
B
B
D
D
A
Thank
you
jeff.
I
hope
I'm
coming
out
clear,
so
I'm
going
to
present
bgpct
once
again
to
the
idea
working
group-
and
this
will
be
mostly
a
recap
of
the
problem
statement
and
the
solution
as
it
stands
and
because
this
interim
is
for
deciding
between
the
two
proposals,
ctn
car.
We
have
also
listed
some
commentary
or
comparison
between
the
two
proposals
next
site.
Please
yeah
next
slide,
please
so
the
problem
statement.
A
So
basically
the
ct
draft
itself
kind
of
summarizes
a
problem
statement
in
a
independent
unit,
so
it
it's
like
looking
at
a
generic
sense.
Any
network
has
services
and
transports
tunnels
and
the
network
could
be
intra-is
or
inter-as
intra-dominated
domain
and
the
intra-airs
domain
has
tunnels
of
varying
key
characteristics.
A
They
can
be
just
categorized
into
gold,
silver,
bronze
and
these
tunnels
could
be
from
various
different
protocols
and
there
could
be
multiple
tunnels
between
the
same
pair
of
endpoints,
so
the
custom
the
operator
could
classify
the
tunnels
into
various
t,
characteristics
and
services
may
need
to
resolve
over
it.
So
services
may
want
to
go
over
a
specific
type
of
tunnel
with
an
option
to
fall
back
over
a
tunnel
with
a
different
color
or
even
a
terminal
with
the
best
effort
transport
class,
so
intent
given
service
mapping.
A
We
can
say
that
is
the
problem
and
also
bgp
encoding
wise.
How
do
we
extend
the
bgp
encoding
so
that
we
can
transmit
this
transport
class
information
of
the
tunnels
to
other
domains
in
bgp,
so
that
the
service
mapping
can
happen
exactly
the
same
way
on
the
other
domain?
Also,
the
ingress
domain,
so
ingress
node
can
map
service
to
a
transport
terminal
endpoint,
irrespective
of
the
tunneling
point,
is
in
the
same
domain
or
it
is
in
a
different
domain.
A
A
So
the
solution
constructs
so
basically
we
define
a
transport
class
construct
which
collects
the
tunnels
with
the
same
t
characteristics.
It's
just
an
abstract
entity
which
has
an
identifier.
It's
a
32-bit.
It's
also
called
color,
and
so
bgbct
is
a
new
transport
layer
at
this
family
with
rp
ina
allocated
it's
76
and
it
follows
rfc,
4364
and
8277
encodings,
so
we're
just
repurposing
existing
well-known
technologies
which
have
good
deployment
experience
at
a
new
layer.
A
A
A
So
with
the
agresp,
it
can
originate
at
vgpct
routes
with
its
own
lo
zero.
That's
the
tunnel
end
point
and
to
go
across
the
path.
Selection
pinch
points
we
just
use
the
rd
in
the
nlri
just
like
l3
vpn,
and
we
use
the
transport
cluster
target
that
identifies
the
transport
class.
This
route
belongs
to
so
we
are
just
reusing
the
l3
vpn
machinery,
but
in
the
transport
layer,
so
that
we
get
the
transport
ribs
populated
with
the
transport
endpoints
of
the
proper
color.
A
So
in
essence,
this
draft
has
two
parts:
one
is
informational
part
which
tells
how
to
organize
transport
reachability
information
in
multiple
transport
trips.
Each
transport
trap
belongs
to
one
transport
class
such
that
the
service
routes
can
resolve
over
those
transport
trips
with
a
fall
back
on
other
transport
trips.
So
this
is
important
because
from
experience
the
pla
implementation
deployment
experience,
we
have
found
that
if
you
have
the
transport
prefix
as
ipa
address
colon,
color
or
color
colon
ip
address,
it
doesn't
fit
all
the
cases.
A
For
example,
ip
address
colon
color
will
be
able
to
give
you
fallback,
but
it
cannot
accommodate
tunnel
end
points
which
are
like
non-host
prefix.
If
it
is
a
slash,
24,
slash
16,
then
there's
a
hole
in
the
middle,
and
if
it
is
like
color
colon
ip
address,
then
of
course
it
doesn't
work
for
cases
where
you
want
to
do
fallback.
So
this
kind
of
organization
works
for
all
different
cases
and
it
works.
A
Yeah,
so
this
is
just
a
diagram
which
you
can
go
over
later.
It
just
shows
how
the
transport
information
is
populated
on
all
the
border,
nodes
and
service
nodes
and
how
the
service
outs
and
transport
routes
go
across
the
network,
and
this
is
a
building
block
of
network
slicing.
So
in
network
slicing
we
have
a
topology
slice
concept,
so
topology
slice
can
be
achieved
using
the
transport,
ribs
and
bgpct
infrastructure
next
slide.
Please.
A
Yeah
so
protocol
observations
like
we
already
talked
so
the
desired
intent
is
signaled
via
the
mapping
community
and
the
nlri
just
has
the
identifier
distinguisher
the
route
distinguisher,
which
allows
the
routes
to
go
across
path.
Selection,
pinch
points
and
where
required,
ad
path
is
also
used
along
with
the
rd,
but
rd
gives
a
a
proper
way
to
identify
which
node
is
actually
originating
this
route
and
which
is
helpful
for
debugging
and
because
of
having
the
transport
class
mentioned
as
a
route
target.
A
So
we
have
other
drafts
that
share
that
idea
where
we
can
even
advertise
multiple
next
stops
in
the
same
route
or
we
can
advertise
labels
for
labels
in
the
next.
Stop
for
routes
which
are
like
can
be
added,
unicast
can
be
flow
spec,
so
there
can
be
multiple
use
cases
that
can
be
achieved
if
we
go
in
that
direction,
so
I
think
we
should
go
in
the
direction
of
removing
metadata
from
nlri
and
putting
it
as
an
attribute
as
an
external
and
because
it
ct
uses
route
targets.
A
So
I
think
we
already
discussed
what
the
advantages
of
reusing
the
4364
machinery
is,
and
the
main
thing
I
want
to
point
out
is
that
it
reduces
a
lot
of
operational
new
training
and
we
can
utilize
a
lot
of
existing
tooling
and
the
working
groups,
the
vendors,
the
customers.
Everybody
has
spent
a
lot
of
time
and
energy
in
in
making
things
work
with
the
4364
infrastructure,
and
I
think
this
is
like.
A
A
A
Your
current
status
is
like:
we
have
implementation
shipping,
since
junos
21.1
and
with
ina
allotted
code
points,
so
customers
are
interested
to
deploy,
but
they're
also
willing.
They
also
desire
other
vendors
to
implement
it.
So
that
is
where
the
support
in
the
working
group
to
adopt
bjpct
as
a
working
document
will
help
next
slide.
Please.
A
A
That's
well
known
the
others
realize
it,
but
they
cannot
do
much
about
it,
basically,
whether
it's
the
prefix
or
in
the
lcm
attribute-
and
we
will
discuss
about
this
on
more
on
the
next
slide-
why
this
is
a
problem
but
effectively
there's
an
ambiguity
and
that
will
be
complicated
to
implement,
to
deploy
and
administer
and
rtc
cannot
be
used
with
car
routes
really
because
it
does
not
use
route
targets.
If
rtc
is
extended
to
used.
A
A
We
may
have
a
ways
to
deal
with
it,
but
if
you
think
about
it,
there
is
in
the
network.
The
rr
is
a
very
significant
resource
and
it
would
be
very
valuable
if
we
can
have
some
features
where
the
rr
is
address:
family
agnostic
and
that
is
possible
to
implement
if
the
nlri
does
not
have
non-key
fields.
So
today,
so
far,
some
enlarges
do
have
non-key
fields.
A
So
bgp
has
that
elements
from
the
beginning,
but
because
of
non-key
fields
in
lra,
it's
not
possible
to
deploy
that
those
kind
of
solutions.
So
I
would
encourage
the
working
group
to
go
with
not
including
a
lot
of
non-key
fields
in
their
lobby,
and
we
also
see
some
proposals
saying
vpn
car,
just
just
we.
We
have
something
called
vpn
car,
which
is
a
service
side
of
car
and
in
the
vpn
car
deployment.
We
see
that
the
car
safety
is
used
as
a
transport.
A
Its
car
is
normally
used
as
transport
family
between
the
pes,
but
in
the
vpn
car
proposal
it
is
used
as
the
cp
between
the
p
and
c
so
the
same
safi
being
used
at
both
the
ce
side
in
one
deployment
and
between
the
ps
and
another
deployment.
That
seems
to
be
confusing.
I'm
not
sure
whether
they
have
thought
through
how
these
both
use
cases
work
in
the
work
together
and
also
just
like
similar
to
vpn
car.
Will
there
be
a
new
vp,
alaska
or
evpn
car,
etc
version
for
each
service
family.
A
A
Yeah,
so
here
this
is,
for
example,
you
see
these
routes
where
the
first
route
has
an
endpoint
of
one
one
one
one
color
is
hundred,
so
the
color
of
this
route
is
hundred
and
the
second
route
has
color
200,
but
it
has
an
lcm
of
100,
so
the
color
is
effective.
Color
is
100,
so
the
route
3
the
lcm
is
400,
so
the
effective
color
is
400
and
route
4.
The
color
is
400
and
the
same
as
100..
A
A
What
do
you
say:
prefix
ip
colon,
color
or
color
colon
ip
kind
of
variance
of
resolution,
and
we
know
what
are
the
problems
that
come
with
that,
so
understanding
all
that.
I
think
we
are
at
a
stage
where
we
can
come
up
with
a
better
proposal
and
ct
looks
like
giving
that
proposal
and
yeah.
So
in
essence,
what
car
provides
is
an
unorganized
set
of
transport
reachability
data
with
an
ambiguous
hint
on
where
the
color
is
or
what
the
color
is.
A
A
Yeah
and
car
also
requires
enabling
ad
path
on
evgp
pairing,
which
is
not
deployed
so
far.
It
has
some
sharp
sharp
edges
and
also
it
requires
advertising
non-bgp
outputs
parts
in
ad
path
which
most
implementation
may
not
support
and
add
path
id,
as
we
already
discussed,
is
not
good
for
troubleshooting
rd
is
better
because
it
identifies
the
original
originator
and
the
scaling
method
proposed
in
car
draft,
which
is
a
hierarchical
transport.
A
So
we
also
understand
how
it
works,
because
we
have
spent
some
time
thinking
about
in
the
past
and
it
increases
the
recursive
resolution
and
ecmp
next
upload
on
the
english
speeds,
which
may
actually
be
low
end
legacy
devices.
So
it's
not
very
practical
in
our
view,
so
the
scaling
method
that
cd
pro
proposes,
that
is
mpls
name
spaces.
It
works
with
no
changes
on
the
ingress
pe's.
Only
the
border
nodes
and
the
service
helpers
need
to
be
upgraded
and
the
whole
network
gets
the
advantage
of
hiding
the
pe
loopbacks
across
the
domain.
A
So
this
reduces
the
next
top
resources
across
the
board
and
especially
for
the
ingress
pes
which
may
not
be
high-end
devices,
so
customers
are
liking.
This
approach
also
very
much
and
this
mpls
namespace
it
works
with
city
resolution
also,
so
I
think
that's
a
better
way
of
solving
scaling
issue
in
the
seamless
mps
network
and
that's
like
an
independent
thing
which
can
be
used
with
or
without
cd
and
because
city
has
a
car.
A
Has
this
new
and
larry
and
a
new
way
of
doing
things,
the
ironing
of
the
interop
issues
will
take
its
own
sweet
time
again.
That's
higher
cost,
so
overall
operational
complexity,
implementation
complexity,
retaining
costs.
It
looks
like
it's
going
to
be
higher,
so
the
question
really
needs
to
be
asked:
what
is
the
advantage
for
this
highest
higher
cost
when
existing
vpn
machinery,
which
ctd
uses
solves
all
these
problems
in
a
very
elegant
and
more
efficient
way?
A
C
C
Now
there
were
there's
a
bunch
of
you
know,
observations
made
about
car,
you
know
just
in
the
last
couple
of
slides,
and
I
mean
there
was
a
statement
made.
You
know
as
far
as
we
understand,
and
I
think
I
would
say
that
the
comments
actually
do
reflect
that
there
is
a
lack
of
understanding
about
the
car
solution.
C
I
just
responded
to
them.
Yesterday.
I'd
see
a
bunch
of
them
here
and
you
know
some
more
so
I
think
I
think
these
statements
do
need
to
be.
You
know
taken
with
a
pinch
of
salt
and
I
think
we'll
probably
need
a
lot
more
time
to
go
through
each
of
them.
So
most
likely
they
would
be
sorted
out
on
the
on
the
list.
C
Yeah,
let
me
just
finish
the
second
point.
You
know
the.
The
second
comment
is
you
know
on
an
aspect
of
you
know
the
ct
draft
itself
I
mean,
what's
being
said,
is
you
know,
because
we
are
able
to
reuse
the
ip
vpn
model
that
there
are?
You
know
benefits
now.
There
are
some
aspects
that
can
be
reused,
but
one
has
to
question
whether
the
complexity
of
using
the
ipvpn
model
with
its
vpn
import
and
export
you
know,
is
actually
needed
at
the
underlay
layer
where
vgplu
has
been
used.
C
C
C
Right
to
you
know
describe
you
know
one
once
more,
just
the
fact
that
when,
if
there
are
like
two
abrs,
you
know
originating
a
route
for
a
local
pe,
you
know
via
redistribution
from
an
igp,
for
example,
the
presence
of
the
rd
prevents
the
use
of
you
know,
multipath
at
within
that
local
domain
at
the
ingress
border
nodes
of
that
domain
right,
you
cannot
merge
the
paths
because
the
rds
in
you
know
by
default
end
up
being.
You
know,
you
know
creating
different
routes
and
that's
been
said
to
be
beneficial.
C
The
you
know,
because
apparently
it
helps
with
troubleshooting
or
in
some
cases
provides
diversity
at
the
ingress
pe,
but
what
it
does
is
break
a
very
fundamental
functionality
that
we
have
gotten
with
bgplu,
which
is
you
get
local
convergence
when
there
is
a
you
know,
failure
of
the
that
egress
abr,
which
now
you
know,
does
not
happen
with
you
know
the
default
processing
with
ct.
The
failure
of
the
abr
needs
to
get
propagated
all
the
way
to
the
english
pes
of
the
other
domains.
C
C
You
have
two
routes:
mapping
to
the
same
data
plane
lsp,
which
one
do
you
propagate
upstream,
one
or
the
other,
or
both
either
way.
It's
you
know,
they're
all
problematic
and
just
hacky
workarounds
to
solve.
You
know
a
very
basic
problem
in
the
design.
Car
does
not
have
this.
You
know
issue.
You
know
similar
to
bgplu.
C
Of
course,
l3
vpn
does
vpn
multipath,
where
it's
needed,
which
is
on
the
pe.
Here
we
are
talking
about
hop
by
hop
transit
behavior,
where
you're
trying
to
impose
the
same.
You
know
design
it.
The
the
two
are
not
equivalent
and
that's
the
problem
of
model.
That
is
not.
You
know
that
was
designed
for
a
different
use
case
and
it
doesn't
naturally
just
fall
into.
You
know
the
requirements
of
the
underlay.
A
Well,
all
I'm
saying
is
rd
is
meant
for
that,
where
you
use
it
to
go,
go
across
the
path,
pinch
point
pinch
points
and
then
in
the
vrx
we
strip
the
rd
and
do
multipath
calculation.
That's
following
the
thing
of
course:
it's
not
a
hack
and
the
other
point
is
you
are
taking
the
case
where
the
deployment
is
based
on
asbr's
redistributing
the
bgpct
routes,
but
there
is
also
a
possibility,
just
like
lu
or
egress.
Pe
originates
bgpc
routes,
and
in
that
case
you
will
not
even
see
this
problem
right.
B
B
F
Hello,
can
you
hear
me
we
can
okay,
all
right,
I'm
just
trying
to
respond
to
back
to
you
dj.
Thank
you
for
responding
to
the
email
on
the
mailing
list,
but
you
made
a
comment
that
you
responded
about
it
there
you
go,
but
I
still
see
some
of
the
questions
still
not
completely
answered.
So
I'm
waiting
for
your
presentation,
so
my
email,
as
well
as
what
kali
raj
presented,
has
similar
concerns
about
the
overall
proposal.
C
B
B
A
B
C
C
C
C
C
One
is
the
color
aware
route
itself,
you
know
it's
nothing,
but
a
bgp
route
right
that
could
be
originated
at
the
be
in
an
egress
be
or
it
could
be
originated
at
you
know
a
device
such
as
an
abr,
where
you
know
the
reachability
to
a
particular
pe.
In
this
example,
e3
is,
you
know,
proper,
originated
and
injected
into
the
network,
and
then
it
propagates
hub
by
hop
where
at
every
hop
we
have
bgp
best
path.
C
Selection,
you
know
selecting
a
path
and
just
like
default,
you
know,
you
know
routing
or
with
bgp
or
bgplu.
You
do
have.
You
know
despatch
selection,
that
in
this
case,
because
it's
for
a
specific
intent
may
make
use
of
you
know
some
specific
parameters.
Maybe
you
know
in
some
cases
a
metric
that
represents
a
particular
intent.
You
know
like
delay
and
propagated
using
aigp.
In
other
cases,
it
may
influence
some
policy.
You
know
to
you,
know,
achieve
the
intent,
but
the
end
result
is
an
end-to-end.
C
You
know
path
that
is
that
can
be
made
use
of
at
an
ingress
node
in
a
across
a
multi-domain
network.
You
know
such
as
e1
now
on
that
ingress,
p
e1,
you
have
the
the
bgp
in
a
route.
In
this
case
you
know
for
a
specific,
you
know,
intent
and
then
now
a
service
route.
You
know
in
this
example,
you
know
shown
by
a
vpn.
You
know
route
that,
in
addition
to
the
next
hop,
also
carries
you
know
the
color
not
gets
you
know,
resolved
and
steered
automatically
via
this.
C
C
So,
as
as
part
of
the
refresher
you
know
we'll
cover,
you
know
these
various
aspects
of
that
are,
you
know
described
in
the
in
the
draft,
but
I
will
try
to
you
know,
spend
time
on
on
some
of
the
the
motivations
and
and
how
you
know
certain
decisions
you
know
have
been
taken
like
what
are
the
the
motivations
to
do
that,
and
you
know
what
are
the
you
know,
the
design.
You
know,
considerations
next
line,
excite
leagues.
C
When
you
look
at
the
top,
which
is
bgp
car,
we
see
it's.
It's
essentially.
You
know
that
same
notion.
You
know,
but
now,
with
the
addition
that
we
we
do
want
to
have
more
than
one.
You
know,
instance
of
a
route
for
for
each
intent,
because
the
path
computed
you
know
would
be
different.
For
different
intents
now,
this
could
have
been
achieved
by
just
using
bgplu.
C
You
know,
but
assigning
different
ip
addresses,
for
you
know
to
represent
a
different
intents,
but
operators
have,
you
know,
told
us
that
you
know
they
do
want
to
be
able
to.
You
know,
stick
to
using
you
know
single
ip
for
for
for
for
pes
pe's,
you
know
another
nodes
in
their
network,
but
still
achieve
these.
C
C
The
motivation
to
you
know
define
a
new
safei,
but
in
a
moderate
following
the
semantics
already,
you
know
used
in
deployments
with
bgplu
and
this
as
we
see
in
the
draft
and
in
you
know,
hopefully
in
the
presentation
that
is
actually
sufficient
to
address
the
requirement
you
would
not
need
to
use.
You
know
vpn
notions
such
as
import
and
export
to
to
achieve
this
next
slide.
Please.
C
So,
okay,
so
now
that
you
know
we
have
a
new
safy,
you
know
to
support
the
new
nlri.
What
what
is
the
nlri?
Look
like
it's
it's,
as
I
said
the
you
know
the
regular
endpoint,
ipv4
or
ipv6
prefix.
That's
now
extended
with
with
the
color.
You
know,
which
is
the
32-bit
value.
As
mentioned
earlier.
The
the
color
now
serves
two
purposes
here.
One
is
if
it
provides
the
necessary
distinction
for
for
a
bgb
route
right.
C
So
now
you
have,
you
know,
per
intent,
crowds
you
know
for
the
same
prefix
or
endpoint,
and
it
also
serves
to
indicate
the
intent
provided
by
the
route
and
that's
you
know
sufficient
to
you
know
you
will
be
used
both
for
the
route
distribution,
the
you
know,
the
best
path,
selection,
next,
stop
resolution
etc.
As
we,
you
know
see
in
subsequent
slides.
C
This
color,
you
know,
is
intended
or
expected
to
be
consistent
across
all
the
devices
within
a
so-called
color
domain.
That
is,
you
know,
maybe
one
or
more
network
domains,
but
who
have
the
same
color
mapping
and
what
what
we
have
heard
from
operators
is.
Obviously
you
know.
As
far
as
you
know,
they
can
achieve
it,
they
want
to
have
the
same
color
mapping
across
you
know
their
multi-domain
network.
C
So
that's
the
you
know
the
base
assumption
they
start
off
with
there's,
obviously
exceptions
and
those
need
to
be
handled
and-
and
you
know
we'll
talk
about
how
we
handle
it
in
a
subsequent
slide.
But
given
this
is
the
most
common
you
know
expected
deployment,
we
optimize
the
the
nlri,
you
know
definition
and
and
the
procedures
for
the
for
the
common
case
next
slide.
Please.
C
C
It
allows
for
efficient
route,
processing
and
storage,
because
you
know
you
you,
you
see
the
the
route
you
process
it.
You
know
you
store
it,
your
invest
path.
You
install
the
routes
in
the
color
of
our
rib
and
so
on
again,
there's
no
need.
We
don't
see
a
need
for
doing
any
kind
of
vpn
import
export
at
every
hop.
C
A
significant
benefit
that
I
you
know
you
know
mentioned
earlier
as
well-
is
that
the
this
data
model
inherently
provides.
You
know,
ecmp
aware
you
know
multi-path
or
backup
parts
at
every
bgp
hop
it
allows,
for
you
know
fast,
localized
convergence.
You
know
when
there's
a
failure
and
we'll
see
this
in
a
you
know
in
a
illustration,
in
a
slide
or
two,
as
I
you
know
pointed
out
earlier,
the
the
ct
proposal
requires
special
procedures.
C
C
Another
important
aspect,
you
know
we
are,
you
know
targeting
deployments
where
there's
a
massive
scale
of
devices.
So
even
when
it
comes
to
propagation
of
these
routes,
we
want
to.
You
know,
support
a
subscription-based
model
where
you
know
the
end.
Devices
only
receive
the
routes
that
they
you
know
care
about.
The
the
e-commerce
model
you
know
allows
us
to
be.
You
know,
building
the
most
efficient
subscription
model
with
a
direct
lookup
for
the
for
the
specific
route.
C
C
C
You
know
based
srt
model
where
which
you
know
provides
for
automated
steering
of
you
know,
service
routes.
You
know,
via
the
ecommerce
model,
the
the
bgp
car
you
know
follows
the
same
model
from
an
operational
consistency
as
well
as
from
a
protocol.
In
a
processing
point
of
view,
you
you
get
the
you
know
the
common,
you
know
function
and
and
consistency-
and
this
is
true
for
you
know-
and
this
is
important
because
again
there
are
a
number
of
operators
who
have
told
us
that
they
expect.
C
C
They
would
have
multiple,
and
you
know
they
may
use
certain
technologies
for
certain
routes
in
some
cases
for
the
same
route,
you
may
end
up,
you
know
using
multiple
technologies
which
provide
you
know,
backup
functionality
for
each
other.
So
you
need
to
have
this
consistency.
You
know
in
in
the
in
the
design
and
the
approach.
C
C
C
You
know
originating
the
route
on
behalf
of
e3
so
which
is
you
know
the
e3
comma
c1
route
with
their
you
know
next
respective
next
stops
and
the
local
labels.
Now
at
the
transport
r,
you
enable
add
path,
as
is
the
case
today
with
vgplu,
so
that
you
know
both
the
paths
are
or.
However
many
such
paths
are,
you
know
made
available
to
the
ingress
board
routers
of
this
in
our
domain.
There
you,
you
know
automatically
get.
C
You
know
the
path
merge
and
you
get
multipath
whether
in
the
case
of
ecmp
or
you
know,
active
backup,
what's
what's
propagated
upstream
is
you
know
just
a
single?
You
know
route
with
the
respective
border
nodes.
You
know
two
one
two
in
this
one
example
and
two
and
one
you
know,
above
as
the
next
stop,
with
their
own
locally
allocated
labels.
C
There
is
no
churn,
you
know,
or
you
know,
slower
convergence
due
to
any
kind
of
propagation
that
needs
to
go
all
the
way
on
to
the
into
the
ingress
pe.
So
this
is,
I
mean
it's
a
very
basic,
you
know
scenario,
but
you
know
be:
it's
been
deployed
heavily
with
bgp.
You
know,
bgplu
bgp
card
is
the
same,
but
we
don't
see
this
with.
You
know,
bgpct
other.
Without
additional.
You
know,
mechanisms
that
are
complex
and
still
don't
solve
the
problem
next
slide.
Please.
C
So
so
I
think
so
far
what
we've
really
seen
is
just
you
know
an
illustration
of
how
bgp
car
is.
Essentially,
you
know
the
same
or
similar
to
bgplu
and
that
that's
been,
you
know
a
key
motivation
for
defining
it.
The
way
we've
done
it,
but
now
we
come
to
a
couple
of
other
aspects
which
again
have
been
you
know
raised
as
being
problematic
or
fundamental
changes.
C
You
know
to
bgp,
and
that
is
you
know
the
the
the
nlri
definition
that
we
have
you
know
and
we
obviously
had
a
choice
not
to
you
know
just
to
stick
to
the
rfc
3107
or
you
know
similar
encoding,
wherein
you
just
had
a
label
or
a
label
stack
to
be
supported
as
part
of
the
nlri,
and
you
know
other
things
that
needed
to
be
signaled.
You
know
whether
it
was
the
prefix
said
or
or
srv6
sids
for
srv6.
C
C
But
the
point
here
is:
we
are
now
at
the
point
where
we're
defining
a
new
safety
and
we
are
expecting
you
know.
Operators
to
you
know
enable
this
new
safety
in
their
network.
You
know
in
in
place
of
what
they
used
till
now,
which
is
bgplu,
so
it
is.
We
think
it
is
incumbent
at
that
point
to
really
plan
for
a
better
nlri
design.
C
Try
to
solve
some
of
the
problems
we've
seen
and
we
tried
to
accommodate
through
workarounds,
which
are
you
know,
not
never
simple
themselves
and
tried
to
do
things
better
for
this
new
safi
and
then
that's
the
approach
we
have
taken
and
again
the
the
kind
of
extensions
we
put
in.
They
are
not
really
fundamental
because
again,
there
has
been
plenty
of
precedent
for
the
changes
we've
proposed,
which
in
in
existing
surface
that
have
been
deployed.
C
For
instance,
we
have
the
the
route
type,
there
are
other
already
existing
bgp
safety's,
which
user
route
type
it's,
whether
it's
mvp
and
evpn
or
and
so
on.
We've
introduced
the
key
length
for
you
know.
You
know
transparent
transitivity
through
you
know,
rrs
we
defined
tlbs
for
carrying
some
of
the
non-key
data,
such
as
label
sets
and
prefixes.
C
We
have
multiple
implementations.
The
the
points
about
these
changes
being
complex
are
really
not
valid
in
our,
in
our
opinion,
the
and
the
other
thing
we
do
is
by
in
terms
of
how
we
define
these.
You
know
extensions.
We
ensure
the
most
efficient
design
you
know
for
for
the
bgp
protocol
processing
as
well.
You
know,
including
you
know,
packing
efficiency
of
bgp
updates
as
well
as
other.
You
know,
efficiencies
that
I'll
you
know
describe
in
the
next
slide.
C
Okay,
so
now
you
know
we
come
to
what
are
we
signaling
in
these
non-key
tlbs?
The
the
fact
is,
we
you
know
day
one.
You
know
we
need
to
be
able
to
support
multiple
transport
encapsulations.
You
know
for
a
car
route,
because
we
are
already
seeing
this
in
deployments.
You
know
today
now
what
we've
decided
to
do
is
signal
things
like
the
label
in
a
bill
index
or
srv6
sets
as
as
non-key
tlbs.
C
This
allows
us
to
do
a
couple
of
things
it.
It
solves
one
of
the
problems
which
we've
seen
with
existing
selfies,
where,
if
you
you
know
just
had
a
single
value
that
you
could
signal
and
you
still
wanted
to
support
different
encapsulations,
then
you're
constrained
to
having
that
one
value
be
applicable
across
multiple
encapsulations
and
which
is
not
necessarily,
you
know
the
case.
C
So
we
want
the
flexibility
to
signal
different
label
values,
so
called
label.
You
know
values
for
different
encapsulations.
Secondly,
you
do
want
to
be
able
to
support
multiple
encapsulations
and
sometimes
simultaneously
for
coexistence
and
migration.
Now,
if
you,
if
you
don't,
have
the
flexibility
to
signal
a
different,
you
know
encapsulations
with
different
values.
You
are
again
forced
to
solve
that
through
operational
complexity
by
originating
addition,
multiple
routes,
you
know
one
for
each
encapsulation
and
then
to
keep
the
state
separate.
You
need.
C
You
know,
different
rr
sessions,
there's
a
whole
lot
of
operation,
complex
complexity,
which
comes
with
that
you
you
have
already.
You
have
double
the
number
of
routes
in
the
network
for
the
time
that
you're
doing
you
know
the
migration
we
here
we
have
the
opportunity
to
address
the
scenarios
and
we
have
taken
that
you
know
we
now
have
the
ability
to
signal
multiple,
encapsulations
and
different
forwarding.
You
know
information
for
different
encapsulations
simultaneously
in
a
single.
You
know,
bgp
update,
and
it's
done
in
a
manner
that
it
is
extensible
in
future.
C
Coming
to
you
know
the
next
top
resolution
this.
This
is
fundamentally
no
different
than
the
kind
of
resolution
you
know
that's
done
in
routing,
but
except
that
here
the
recursion
is
also
color,
aware
right
and
the
the
next
hop
you
know,
reachability
for
a
given
color
may
be
provided
by
any
color
aware
mechanism,
whether
it
be
sr
policy.
You
know
igp
flex,
algo,
bgp,
car,
you
know,
and
so
on
resolution
does
support.
You
know
fall
back
to
alternative
colors
in
the
eventuality.
You
don't
have.
C
You
know
a
path
in
the
same
color
or
ultimately
went
to
a
best
effort,
and
we
use
this
to
also
support
scenarios
where
you
know
an
end-to-end
path
may
traverse
domains
which
don't
have
the
same
diversity
of
intent
or
or
to
support.
You
know
transport
or
legacy
islands
where
you
don't
have
any
color
awareness
at
all.
C
C
Now
now
we
come
to
the
aspect
of
how
do
we
address
the
case
where
you
know
the
route
may
traverse
across
domains
where
the
color
to
intent,
mappings
differ,
and
this
can
happen.
You
know,
despite
the
best
intentions,
when
you
have
independent
domains,
that
you
know
had
their
own
color
mappings
and
then
you
know
which
come
together.
C
We
have
addressed
that.
You
know
just
like
how
you
address
similar
scenarios
in
most,
inter
you
know,
domain
or
inter
provider.
You
know
cases
by
by
you
know
establishing
a
mapping
right
here.
We
have
a
local
color
mapping
extended
community,
which
you
know
is
to
be
used.
Only
if
you
know
a
car
route
does
go
across
a
domain
color
domain
boundary
that
is
into
a
domain
where
the
color
mappings
actually
differ
a
very
similar
to
how,
in
an
interest
option,
bvpn
scenario,
you
would
do
an
rt,
you
know
mapping
or
even
regular
communities.
C
C
Similarly,
you
know
this
is
accompanied
by
a
similar
rewrite
of
the
color
extended
community,
which
would
have
been
sent
along
with
the
service
route.
I
mean
this
is
something
which
would
already
happen
today.
If
you
know
there
were
deployments
where
you
know
domains
with
different
color
mappings
were
you
know
you
know,
deployed
together
now,
in
all
these
cases,
the
nlri
does
not
change.
So
just
how
you
have
the
you
know
the
the
prefix,
which
is
the
p
you
know
address
or
endpoint
that
does
not
change
end
to
end.
C
C
Color
is,
and
that
can
be
for
tracking.
You
know,
troubleshooting
the
fact
that
you
know
the
route
did
traverse
across
domains
where
the
color
mappings
change
does
not
really
create
confusion,
because
the
color
is
always
scoped
by
the
you
know
the
prefix,
since
the
endpoint
is
unique
in
the
inter
domain
network.
That
makes
the
e
comma
c
also
unique.
Even
if
the
you
know
the
color
mapping
changes
next
slide.
Please.
C
Okay,
so
now
now
we,
you
know
there
was
a
comment
about
vpn
car
and
what
it
means.
I
think,
as
we've
seen
or
as
I
described
in
the
earlier
slides
when
you
have
car
in
the
base
car,
that's
enabled
you
know
just
at
the
transport
layer,
you
have
all
manner
of
services,
existing
service
officer
fees,
just
resolving
or
you
know,
and
getting
steered
via.
You
know,
bgp
car
routes.
Just
like
how
they've
been
you
know
getting
resolved
by
you
know,
srt
paths
or
in
you
know,
general.
C
You
know
next
top
resolution
over
best
effort
paths.
What
we
are
talking
about
here
is
something
different
so
far.
You
know
we
talked
about
having
the
intent
awareness
at
you
know
within
the
provider
domain
you
know
so
that's
you
know,
b
to
b
and
then,
of
course
you
have
steering
of
you
know,
customer
traffic,
you
know
ce
traffic,
you
know
between
the
bees.
Why
are
those
you
know
intent
aware
parts?
But
there
are
you
know
cases
where
the
ce
itself
is
providing
intent,
aware.
C
You
know
functionality
to
you,
know,
networks
or
devices,
you
know
behind
it
and
there
is
options
or
there's.
You
know
the
possibility
of
having
you
know,
different
capabilities
in
you
know
in
between
the
p
and
the
ce
or
and
that's
what
you
know
is
getting
signaled
in.
You
know
with
the
vpn
car
extension
you
know
for
not
just
from
from
the
c
to
the
p,
but
then
also,
you
know
end
to
end.
You
know
across
the
vpn
core,
so
you
can
actually
build
an
intent
about
path.
C
C
C
Yeah
so
yeah
I
mean
most
of
these
aspects.
You
know
have
been
diff,
you
know
described
in
the
draft.
You
know
you
I
try
to
be
careful
in.
You
know
how
we
do
the
updates
to
the
drafts.
You
know
going
step
by
step,
and
so
this,
just
you
know
we're
just
covering
or
describing
the
updates
we've
done
in.
C
C
C
C
C
C
Yeah,
so
I
think
we're
continuing
to
go.
You
know
in
a
systematic
way
and
you
know
adding
functionality
to
the
base.
You
know
car
solution
based
on
the
use
cases
and
requirements
that
you
know
we'd
listed
in
the
in
the
in
the
problem
statement,
which
itself
was
done.
You
know,
in
collaboration
with
a
lot
of
lead
operators,
and
you
know
other
vendors.
C
You
know
and
we
continue
to
request
collaboration
review.
We've
had
some
really
good,
you
know
collaboration
and
feedback.
So
far,
we
you
know
want
to
continue
to
keep
that
going
as
joel
described
that
you
know
we're
also
engaged
in
an
effort
to
get
a
common.
You
know
problem
statement
draft
you
know
in
place
and
you
know
that
effort
is
is
ongoing,
but
we
obviously
in
parallel
made.
You
know
progress.
C
We
have
two,
you
know
implementations
you
know
of
the
bgp
car
solution,
that's
helped
to
iron
out
some
of
the
you
know
concepts
you
know.
Actually
we
validate,
you
know
the
the
principles
and
the
enter
design
that
we
put
in
place.
We
are
you
know,
working
on
interrupt
between
the
implementations,
so
in
general
we
think
the
bayes.
You
know
solution
is
stable,
we
think
it's
ready
for
you
know
working
group
adoption
and
we
definitely
like
to
you
know,
move
forward
with
the
working
group
adoption
at
this
time.
B
B
Sue
has
also
confirmed
that
her
presentation
will
be
on
the
shorter
side
of
things.
So
I
think
we
can
spare
easily
15
to
20
minutes
of
good
discussion
for
here.
There's
been
a
lot
of
discussion
in
the
chat
we
will
as
part
of
taking
the
minutes,
try
to
ensure
that
this
gets
distilled
down
and
proxy
back
to
the
working
group
as
part
of
the
minutes,
and
also
as
discussion
points
and
in
fairness
to
the
presenters
they're
not
expected
to
have
necessarily
been
following
the
chat.
B
C
B
Okay
and
well,
we've
done
that.
So
a
very
brief
comment
about
adoption,
like
two
of
your
prior
slides,
make
note
of
adding
additional
authors.
I
believe
car
is
actually
up
to
12
authors
right
now.
So
a
comment
to
both
author
sets,
the
isg's
rfc
procedure
at
this
point
really
is
that
you
should
have
five
authors
as
part
of
your
rfc
document,
so
my
recommendation
spend
a
little
bit
time
thinking
about
how
you
want
that
to
reconcile
as
part
of
the
adoption
process
srihari,
you
have
the
microphone.
F
Yes,
so
dj
in
this.
In
this
example,
the
two
two
one
one
advertises
the
one
prefix
with
e3
c1
correct
and
then
will
it
be
able
to
choose
which
intent
path
it
wants
to
choose
whether
it
goes
to
231
or
232,
because
in
this
example
it
seems
211
will
7231.
But
what?
If
what?
If
the
packet
needs
to
be
sent
to
either
one
of
the
media?
So
how
would
211
advertise
back
to
email,
e1.
C
F
F
C
I
mean
the
path
computation
is
for
a
given
intent
right,
so
this
is
for
a
route
for
a
particular
intent.
So
that's
the
e3,
comma
c1
router
right,
so
so
the
end
to
end
path.
That
is,
you
know,
set
up.
You
know
from
say
at
the
end,
from
e1
towards
e3
is
for
a
given
intent
right
now
within
that
intent,
I
mean
you
know
for
that
intent.
Obviously
you
have
you
know,
and
you
know
in
the
case,
if
you
take
in
in
this
case
it's
mpls.
C
C
I
I
think,
maybe
I
think
what
you're
saying
is.
If
you
had
a
different
intent,
what
would
we
do?
I
mean
if
you
had
a
different
intent,
that
would
be
a
different
route
right,
so
that
would
be
say:
e3,
comma
c2,
for
example,
right
that
that's
a
route
for
a
different.
You
know
intent,
and
that
would
you
know
you
know,
have
its
own
path
computation.
F
B
F
C
Yeah
quickly,
yes,
I
mean
any
part
needs
to.
Have
I
mean
any
end-to-end
path
needs
to
have.
How
do
I
put
it?
Availability
and
you
know
reliability
built
in
right.
So
if
there
is
a
failure
of
a
you
know,
any
single
node,
you
need
to
have
an
alternative
path,
so
that
computation
is
always
local
right.
Of
course,
you
can
have
multiple
end-to-end
paths
that
you
know
a
service.
B
B
B
Yes,
yes,
that
is
going
to
check
it.
Okay,
and
I
think
that's
potentially
the
point
of
confusion
so
for
for
networks
that
wish
to
do
the
desktop
self
resetting.
At
this
point,
certainly,
you
know
we
can
have
this
type
of
behavior
if
the
in,
if
the
idea
instead
was
that
122
may
want
to
actually
have
both
sets
of
diverse
paths
for
local
steering
as
an
example,
that
would
require
add
paths
at
212
as
well
correct.
C
I
think
that's
up
to
the
operator.
As
I
said,
I
mean
it
depends
on
what
the
you
know.
The
intent
is
if
the
intent
was
to
provide
you
know,
maybe
an
end
to
end
lsb,
all
the
way
to
say
231,
you
know
versus
232
and
have
that
be
available
at
the
ingress
pe,
such
as
e1.
Then
that
would
be,
you
know,
implemented.
C
G
Very
clear
intent
is
to
go
to
e3
wire,
231
or
232,
and
that
control
should
be
left
to
e1.
So
it
should
be
two
different
color
routes
that
should
be
reaching,
even
in
that
case,
because
your
intent
is
that
way.
So
we
should
not
try
to
mix
that
using
an
rd,
that's
what
being
proposed.
So
I
don't
think
that's
the
right
approach.
B
Right
and
you're
actually
hitting
the
point
that
I
I
think's
a
relevant
discussion
point
for
contrasting
the
two
solutions,
so
perception
of
what
what
color
means
in
terms
of
how
it
routes
across
the
entirety
of
the
domain.
You,
I
think,
you've
just
given
a
key
point
that
highlights
the
differences
between
the
two
proposals.
B
G
You
cannot
say
I
will
carry
two
rd
routes
from
231
and
232,
which
will
carry
a
same
intent
and
on
e1
service
drive
route
will
do
some
special
job
to
figure
out
231
22
that
doesn't
work
so
better
would
be
service
route
being
colored
by
two.
I
want
to
go
by
two
wire
231.
It
would
be
a
color
c1
and
the
other
color
c2
will
say.
G
B
F
This
has
a
follow-up
question
for
that,
so
so,
which
basically
means
that
you're
gonna
you're
now
gonna
be
assuming
that
sitting
at
e1
a
provider
will
be
knowing
what
all
exit
points
it
needs
to
go
through
and
therefore
choose
the
intent.
So
it's
really
mapping
the
entire
topology
across
the
various
domains
and
then
coming
up
with
the
intent.
No,
that's.
G
The
requirement-
that's
the
in
no
sorry,
that's
the
intent.
You
ask
that
I'm
not
bringing
that
you
are.
You
wanted
to
go
via
231
or
232.
It's
not,
and
you
want
to
do
it
at
the
service
level.
Service
wants
to
choose
that.
I
don't
want
a
core
router
like
two
one,
one
or
two
one,
two
choosing
it
right.
How
do
you
know
at
the
core
router
it's
a
requirement
that
you
are
bringing
I'm
not
asking,
I'm
not
bringing
that.
I
don't
even
see.
Bgplu
didn't
even
have
any
such
thing.
G
You
are
bringing
that
as
a
functional
requirement
and
therefore
I
think
what
we
are
trying
to
say
is
how
you
will
achieve
it
if
needed.
But
I'm
not
saying
this
is
a
requirement.
How
will
why
are
service
traffic
coming
from
e1,
which
we
don't
know
which
service
traffic
I'll
put
to
211
saying
go
to
231
and
212,
saying
22.2?
G
F
That
is,
that
is
the
problem
that
I
have,
because
you
know
if
you're,
comparing
with
bgpl
your
bgp,
is
fairly
very
straightforward,
because
it
just
provides
you
the
reachability
of
a
particular
endpoint.
Whereas
now
we
are
bringing
in
the
intent
now
intent
and
then
now
we
are
talking
about
intent
for
domain
that
can
be
changed
or
that
can
be
mapped
to
different
color
value,
so,
which
also
means
that
now
sitting
at
even,
I
will
have
to
have
an
entire
visibility
of
multiple
domains.
For
no.
G
G
G
Cannot
provide
a
local
convergence
if
you,
if
you
are
with
our
problem,
is
with
the
rd
model
with
the
opaqueness
that
you
have
brought
to
a
tunnel
endpoint
to
a
e3
route
by
putting
an
rd
which
is
an
opaque
entity.
It's
just
a
route
distinction
in
vpn
that
made
sense
because
I'm
carrying
the
same
I'm
carrying
the
same
ip
addresses
which
has
different
meaning
in
the
verbs.
So
you
have
to
carry
a
route
distinction,
because
it's
an
opaque
information,
but
in
the
case
of
transport,
e3,
comma
c
is
not
opaque.
G
G
G
A
A
G
Yes,
now
now
that
means
you
have
come
with
the
same
rd.
There's
nothing
different.
The
question
about
going
to
two.
Third
one
goes
away
once
you
put
it
the
same
audio
right
from
the
e3
that
question
that
the
question
that
you're
bringing
about
color
out
is
completely
gone
away.
You
also
have
the
same
problem
there,
I'm
not.
A
G
G
A
G
A
G
A
G
I
have
is
just
one
point
I
want
to
raise
is
putting
an
rd
in
front.
You
yourself
mentions
if
I'm
originating
from
231
and
232,
it
would
be
unique
rds
and
now,
as
we
have
already
said,
it's
a
very
basic
broken
model
that
local
convergence
cannot
be
taken
care.
You
have
to
carry
those
unique
rd
routes
to
e1.
D
B
B
Swedish,
so
the
the
relevant
point
that
is
still
out
of
this
particular
piece
of
discussion
is
where
the
route
is
being
originated.
Matters
and
each
of
the
solutions
seems
to
have
different
ideas
around
that.
So
that's
going
to
be
a
good
piece
of
clarifying
discussion
point
that
I
strongly
suggest
we
take
to
the
mailing
list,
so
we've
reached
the
end
of
the
time
slot
that
we
have
available
as
easy
overflow
right
now
without
stepping
on
the
other
presenters.
B
In
the
absence
of
some
more
unifying
document
is
just
as
critical
to
make
no
comparisons,
because
in
the
absence
of
that
now
each
site
is
clearly
taking.
No,
this
is
good.
This
is
bad.
You
know
based
on
their
presumptions,
so
this
is
helping
us
effectively,
lay
those
out
so
kare.
Do
you
have
a
final
point
before
we
move
on
to
the
next
presentation
set.
A
Yes,
real
quick.
This
is
this
is
probably
a
note
for
dj
in
sudesh.
As
the
conversations
progress
can
you
please
actually
have
a
text
in
the
draft,
also
for
the
benefit
of
rest
of
the
group
that
clarifies
the
the
concept
of
intent
here,
because
that,
like
jeff
said
earlier,
was
a
key
point,
and
hopefully
it
will
help
clarify
a
lot
of
conversations
or
dis
issues
that
were
there
earlier
and
maybe
progress
the
conversations
in
a
much
more
better
manner,
moving
forward.
Thank
you.
E
B
So
our
second
topic
set
that
we'll
be
going
with
and
we
you
know
again.
We
have
two
and
a
half
hours
for
the
total
interim.
If
we
have
time
at
the
end
of
the
interval,
we
should
resume
a
discussion
on
this.
That
is
totally
an
option.
If
you
know
people
are
still
present,
our
next
presentation
set
is
going
to
be
a
continuation
on
the
pgp.
Auto
configuration
topics.
Go
back
to
the
chair,
slides
momentarily.
B
B
B
The
second
one
is
going
to
be
from
draftminto,
which
is
a
php
layer,
3
multicast
solution,
and
then
you
know
the
desired
discussion
about.
This
is
basically
two
sets
of
things
at
this
point.
The
proposals
that
we
have
being
submitted
for
evaluation
effectively
are
the
lldp
one,
the
l3dl1
and
draftminto
for
l3
multicast,
and
we
would
like
to
discuss
what's
the
scoping
that
we're
looking
to
solve,
if
we
effectively
have
two
proposals
for
layer,
two
discovery
and
one
for
layer.
B
Three-
and
you
know
the
the
related
point-
is
what
is
going
to
be
our
selection
criteria
for
a
auto
discovery.
You
know
mechanism,
and
this
will
drive
our
adoption
discussion
and
you
know
perhaps
we
can
get
some
back
and
forth
in
terms
of
what
what
does
idr
as
a
whole
want
out
of
a
discovery
protocol.
B
Do
we
basically
pick
things
down
to
the
extreme
case,
exactly
one
in
one
of
the
domains,
maybe
one
for
each
of
the
layer,
two
layer,
three
domains
or
is
there?
No,
given
that
we've
actually
done
our
work
to
try
to
make
sure
that
we
have
unification
about
the
requirements
and
how
they
actually
be
done?
Do
we
simply
allow
the
various
proposals
to
each
go
through
because
they
solve
a
distinct
problem
for
a
specific
environment,
and
we
realize
that
the
environment
is
going
to
be
a
very
strong
discussion
point
for
each
of
these
presentations.
B
B
As
any
of
you
who
are
on
the
operator?
Side
of
things
are
very
well
aware
of.
Address
configuration
is
probably
one
of
the
bigger
pain
points
for
building
fabrics
out
of
bgp,
and
the
desire
was
try
to
use
auto
discovery
to
reduce
the
amount
of
work
and
potentially
troubleshooting
necessary.
For
you
know
this
type
of
common
scenario.
B
We
ended
up
with
a
design
team
to
work
through
the
various
requirements
and
the
design
team
draft
is
available
for
review.
It
was
updated
as
a
refresh
for
a
couple
of
days
ago,
and
as
I
mentioned,
we
have
effectively
three
current
proposals
that
are
viable
at
this
point,
covering
data
center
use
cases,
and
we
have
several
proposals
that
discuss
discovery
in
non-data
center
contexts,
and
I
urge
the
breaking
group
to
go
ahead
and
review
those
additional
proposals.
B
B
C
A
A
And
this
is
a
tlb
based
protocol
and
the
tlbs
are
grouped
with
the
messages
right.
The
the
messaging
and
the
grouping
of
messages
will
provide
a
layering
in
the
protocol
right,
so
you
have
a
base
base
layering,
where
it
mainly
for
the
protocol
and
this
next
set
of
layering,
that
is,
to
authorize
the
client's
client
information
such
as
bgpp
transport
information.
A
E
A
Own
lifetime,
based
on
their
scaling,
scaling
characteristics
right,
so
this
kind
of
asymmetric
lifetime
advertisement
driven
by
the
standard,
will
provide
a
provide,
a
greater
number
of
scaling
to
the
to
provide
a
greater
number
of
scaling
right.
So
you,
so
you
know
in
a
network
segment
right
one
one
one
one
node
could
advertise
900.
Second,
another
node
could
add
what
is
a
three
three
thirty
seconds
based
on
their
scaling
and
other
configurations
in
the
box.
Right.
A
So
so
that
so
the
advertisement
center
also
can
refresh
refresh
not
only
that
when
the
timer
expires,
it's
also
refreshed
during
the
interesting
events
such
as
it
during
some
new
neighbor
coming
up
or
there
is,
or
certain
link
changes
right.
This
will
help
to
help
to
quickly
discover
during
the
during
the
coming
up
or
the
or
some
of
the
interesting
events
happen
right.
A
A
Protocol
or
the
ph
the
video
types
are,
are
grouped
in
a
group
in
the
three
couple
of
layers
right,
so
one
is
the
top-level
pdu
header
that
will
identify
that
identify
the
who
are
sending
this
and
the
version
and
video
length
right.
This
is
overall
the
pdu
right,
then
the
pdu,
you
have
have
a
message
right
and
the
message
have
a
tlb
right
in
here.
The
the
identifier
is
basically
identify
the
sender
across
a
link.
A
So
let's
say
you
have
a
parallel
links
and
you
want
to
identify
who
is
sending
it
out
right,
and
this
identifier
will
be
helpful
to
identify
it
right
and
the
identifier
can
be
either
router
id
or
the
pgp
id
the
the
it's.
Not
it's
in
the
the
protocol
recommend
the
router
id
and
but
it
can.
The
bgp
id
also
can
be
used
here.
A
A
This
is
of
the
message
right,
so
the
one
or
one
octet
or
one
byte
for
the
type
right
hand,
two
bytes
for
the
length
and
the
message
id
is
mainly
for
the
debugging
purpose
right.
So
if
you
had
some
issues,
then
it
will
help
for
the
logging
purpose
it
is.
This
is
a
this
is
a
grouping
of
that
tlvs
thanks
and
excite.
Please
tlb
is
a
typical
right,
so
one
one
byte
for
the
type
and
the
length
is
again
two
bytes
and
the
and
then
value
followed
from
there
right.
A
A
A
A
So
this
will
be
useful
when
the
the
process
restarted
and
it
want
to
get
quickly
figure
out.
What
is
the
remote
and
information,
then
it
can
attach
this
reference
request
so
so
that
receiver
will
send
out
that
information,
and
this
will
help
to
quickly
again
rediscover
this
rediscover
that
we
are.
This
was
this
land
during
our
implementation
and
that
some
some
of.
A
They
remove
the
a
remote
and
may
not
be
able
to
identify
that
there's
a
new
new
new
pair
is
coming
up.
That's
the
reason
for
this.
That's
the
reason
for
this
refresh
request
thanks
the
next
slide,
please
so
so
there's
no
changes
in
the
security,
tlb
or
authentication
or
tcp,
mrs
daily,
that's
all
remain
same,
but
we
removed
the
transport
preference,
the
transfer
preference
information.
Now
we
encoded
with
the
address,
address
information
so
which
we
changed.
A
A
The
flag
will
indicate
that
that
the
addresses
address
the
local
address
is
a
loop
back
or
not.
That
is
only
only
flag
defined
with
the
version
version.
One
right,
the
preference
is
a
four
bit
four
bit
value
that
that
so
so
that
that
sender
can
put
it
on
the
value
and
the
lowest
value
will
be
probably
used
in
the
receiver.
A
To
figure
out
what
is
the
preference
of
the
sander,
and
this
also
have
a
two-
both
v4
and
v6
have
a
two
different,
two
different
dlv
type
to
accommodate
that
address
list
right.
There's
a
change
in
the
link
address
also
so
so
earlier
version
only
added
the
v4
and
v6
address.
This
versions
also
are
the
mac
address,
along
with
that,
this
will
be
useful
in
the
case
of
non-separated
network
in
place
and
along
with
the
along
with
the
loopback
based.
Creating
sessions
are
established
right.
B
B
H
H
We
started
with
these
basic
requirements,
mainly
as
jeff
alluded
to
towards
the
data
center.
We
want
to
support
bgp
router
discovery
and
we
want
to
support
both
appearing
on
local
and
loop
addresses,
and
we
want
to
discover
authentication
mechanisms
that
the
peers
support,
so
you
won't
have
to
retry,
and
things
like
that.
You
think
about
there's
a
lot
of
the
bgp
negotiation
is
done
through
the
capabilities.
H
It
uses
lldp
link
local
discovery
protocol
from
ieee.
This
is
from
the
whole
I
protocol
suite,
and
we
looked
at
it
or
I
I
mean
I
originally
looked
at
this
and
I
found
out
that
ayanna
already
has
and
organizational
ieee
already
has
an
organized
organizational
unique
identifier
for
the
ietf,
and
this
will
allow
us
to
put
our
bgp
discovery,
tlvs
and
advertise
them
in
the
lldp
advertisements
or
pdus.
H
We
allow
multiple
different
peering
addresses
for
different
sassy,
so
you
could
support
the
bgp.
I
forget
what
rfc
to
do
if
you
want
to
have
different
different
sessions
on
different
addresses
for
different
sasses,
the
local
ais
as
the
bgp
identifier,
a
bbgp
group
id
now
so
far
we
haven't
tried
to
standardize
these.
We
might.
H
We
also
have
all
the
authentication
supports
and
we
have
the
three
main.
You
know
the
md5,
tcp
and
tcpao,
and
the
use
of
the
time
to
live
with
the
gtsm
support
a
keychain
name
also
for
there's
a
lot
of
implementations
of
support,
key
chains
so
that
you
could
not
only
say
what
kind
of
authentication
you
use
but
say
which
key
chain
to
use
for
that
authentication,
and
we
allow
that.
H
A
local
address
for
next
hops
for
other
families
other
than
the
peering,
as
so,
let's
say:
you're
doing,
ipv
advertising
ipv6
over
an
ipv4
session
or
the
latter.
We
allow
another
address
to
be
specified
in
the
discovery
mechanism
and
this
config
state
version.
This
indicates
that
there's
a
change
that
the
people
that
are
listening
to
these
ldp
advertisements,
which
I
might
add
or
it's
lltp
I
didn't
go
through-
that
it's
a
period
periodic
broadcast
at
layer
two
so
and
it's
and
pretty
much.
H
H
There
we
didn't
try
and
add
any
authentication,
either
authentication
which
or
encryption
we
are
allow
on
maxec,
which
is
also
part
of
the
ieee
802
suite,
and
we
there
as
I
as
some
of
you
know,
who
are
involved
or
at
least
have
heard
the
other
presentation.
You
know
that
we've
had
presentations
in
lsvr
on
ll
p,
v,
two,
which
is
an
iteration
of
this
that's
happening
on.
H
I
mean
a
new
version
of
ll
link
local
discovery
protocol,
that's
happening
in
the
ieee
now
we
could
certainly
benefit
from
this
both
from
it
allows
incremental
advertisement
of
changed
information.
So
we
wouldn't
be
replacing
it
every
time
and
it
also
allows
the
information
to
go
over
multiple
pdus.
So
you
can
you
can
advertise
more
than
what
will
fit
in
one
pdu,
so
we
definitely
benefit
fit
for
it,
but
we
wouldn't
want
to.
H
Okay,
as
jeff
mentioned,
the
the
the
autocomp
design
team
document
that
he
recently
updated.
I
so
it's
not
just
expired
anymore.
It's
been
updated
since
I
made
these
slides
and
we
really
require.
We
really
satisfy
all
the
requirements
in
the
draft,
with
the
exceptions
of
it
requires
authentication.
We
don't
provide
alphagenication
in
this
lldp
discovery
protocol,
but
instead
rely
on
the
other
ieee
maxsec
protocol.
H
Additionally,
we
don't
we
allow
peering
on
like
a
loopback
address.
We
don't,
but
we
don't
explicitly
say:
okay,
if
you
get
a
loopback
address,
you
have
you
don't
have
a
route
add
a
route
over
the
interface
on
which
you
didn't
you
received
it,
we're
not
doing
this,
but
I
don't
see
that
we
don't
meet
the
requirement
because
you
could
advertise
a
loopback
address.
H
Then
the
client
of
the
discovery
mechanism,
which,
probably
if
it's
a
routing
protocol
like
bgp,
it's
already
a
rib
client
anyway,
it
could
add
the
address
and
be
the
owner
of
that
route
rather
than
making
the
discovery
mechanism
itself.
A
rib
client,
which
that
was
a
better
trade-off
and
I
think
the
last
slide.
H
Yeah
I
was
gonna
see
like
jeff
also
mentioned.
We
got
maybe
depending
on
how
you
do
it.
I
think
we
got
if
you
I
think
we
got
four
different
major.
You
know
different
proposals,
including
the
randy's
protocol.
That's
being
standardized
in
his
link
state
discovery,
a
bg
protocol,
I'm
drawing
a
blank.
I
can't
remember
what
he
calls
it
again:
l3dl
l3dl.
H
Yes,
we
got
that
so
we
got
four
different
proposals
for
doing
bgp,
auto
discovery
right
now,
and
I
also
gonna
mention
that
no
nokia
has
a
rudimentary
implementation.
Well,
I'm
saying
they
don't
they
don't
support
everything
in
the
draft,
but
they
had
kind
of
independently
thought.
Well,
we
have
ld,
we
have
lldp
on
our
switches.
H
H
B
And
adding,
as
your
presentation
juniper
had
done,
a
non-shipping
prototype
of
lldp
discovery
as
well
and
for
the
most
part
it
did
work
as
well.
A
a
point
that
I
think
is
worth
discussing
about
lodp
partially.
As
a
contrasting
point,
that's
explicitly
raised
over
in
draft
minto
lifetime
of
the
lodp
discovery.
Messages
is
effectively.
You
know
for
the
length
of
the.
E
B
H
H
I
think
I
think
we
should
put
that
in
the
draft
about
because
it
because
it
was
it,
wasn't
obvious.
We
should
update
the
draft
with
that
point
after
discussion
about
how
to
how
to
if
you
want
to
withdraw
information,
whether
it's
a
complete,
relate
replacement
and-
and
I
won't
try
and
say
exactly,
but
I
think
I
had
always
envisioned
it-
you
just
wouldn't
advertise
it
and
because
it's
in
every
there's,
no,
you
know
lldt,
you
advertise
everything
every
time
at
least
version.
A
C
A
Interval
configuration
for
for
the
for
for
the
discovery,
the
first
question.
The
second
question
is:
should
the
keychain
name
should
be
same
across
the
all
the
devices
right,
the
third
one
be
the
loopback
address,
peering
detection
right
so
with
the
voice
p
of
our
other
routing
protocol.
Do
you
see
that
any
such
a
deployment
scenario
thanks.
H
And
for
the
second
question,
the
keychain
name
would
definitely
have
to
be
would
definitely
be
the
same
because
you,
if
you
or
because
you
don't
know
who
is
receiving
this
because
it's
you
know
it's
just
if
if
you
knew
who's
receiving
it,
it
was
discovery.
So
you'd
have
like
common
key
chains
for
common
authentication.
H
H
H
A
H
It's
not
it's
not
you
could
you
could
actually
have
any
you
could
either
you
could
have
anybody
who's.
A
client
of
you
know
bgp
could
add
the
route
to
the
loopback
address
based
on
interface.
You
know
what
what
interface
it
was
received
on
could
add
an
interface
route
to
the
loopback
address
for
appearing
I'm
just
saying:
I'm
not
we're
not
making
that
a
part
of
the
discovery
mechanism.
B
B
G
B
Or
l3,
or
do
we
actually
find
that
this
is
likely
to
be
something
that
we
would
want
a
solution
per
domain?
The
one
personal
piece
of
input,
I'd,
give
you
know
based
on
the
requirements.
Discussions
that
we
had
is
that
l2
discovery
sometimes
is
problematic.
Depending
on
what
you
know,
the
link
happens
to
be
if
there's
a
switch
in
the
middle
as
an
example
that
makes
things
challenging.
B
B
H
I
mean,
I
think
there
are
other
applications
of
lldp
that
have
to
deal
with
a
switch
in
the
middle
I
mean
I
could
check
with
somebody
who's
more
of
an
expert
on
that.
So
I
don't
think
that's
a
problem.
You
know
I
wouldn't
wouldn't
be
on
an
offer
on
it,
if
I
didn't
think
the
simplicity
of
it
made
of
the
lodp
solution
and
the
fact
that
everybody
already
has
lldp
and
you
just
need.
You
know
a
signaling,
the
internal
internal
linkage
between
the
different
subsystems
to
support
this.
It
makes
it
look
pretty.
B
B
Okay,
I'm
just
going
to
zoom
it's
open
microphone
so,
given
that
we're
a
little
tight
on
time
for
the
last
presentation,
we're
going
to
move
the
discussion
for
adoption
and
which
of
the
solutions
we
want
to
adopt
to
the
mailing
list,
we're
likely
to
send
out
the
inquiries
after
the
idr
chairs
have
had
a
chance
to
have
our
usual
weekly
meeting
on
friday.
So.
G
B
G
B
So
for
flow
spec,
v2
again
a
brief
reminder
of
what
we're
actually
needing
to
do
here
and
sue
and
donald
will
be
giving
us
a
update
on
where
the
work
is
right
now-
and
you
know
they
may
have
working
group
specific
discussion
that
they're
looking
to
drive
and
actually
I'm
going
to
leave
it
to
the
authors
to
describe
the
journal
problem
space
because
I
believe,
that's
part
of
their
update.
So
I'll
just
resume
their
presentation.
There.
I
The
addition,
since
o3
we've
added
a
ttl
filter
that
was
a
proposal
to
the
working
group
in
the
mpls
filter
and
an
mps
label.
The
mpls
label
actions
were
part
of
an
idr
draft.
I've
been
trying,
donald
and
I've
been
trying
to
get
a
consistent
set
of
filters
and
actions,
and
thanks
to
donald
we've
done
quite
a
lot
of
good
editorial
work
at
a
70
page
document,
there's
probably
still
more
to
go.
I
We
do
have
a
couple
questions,
one
that
donald
keeps
asking
and
jeff
keeps
acting.
We
have
base
functionality
of
v1
and
v2
ships
in
the
night
interactions,
we've
discussed
filters
and
actions,
we've
discussed
and
user
ordering
of
filters
and
actions.
All
this
was
part
of
our
work
that
we
proposed
that
we
wanted
a
v2
that
was
different
than
v1
one.
I
And
now
we
come
to
the
questions
that
we
haven't
been
able
to
really
tie
down
and
they
have
to
do
with
partial
deployments
and,
as
john
has
been
putting
key
non-key
information,
and
so
there
are
always
two
implementations.
Just
as
a
reminder
to
allow
partial
implementations,
you
can
simply
say
in
a
document
that
we're
going
to
allow
partial
implementations
and
leave
it
up
to
the
implementers.
I
I
We
have
the
partial
implementations
and
we
have
an
action
in
there
where
we've
put
a
key.
The
nri
for
the
flow
spec
tied
to
an
action
of
die
die
worm
because
some
people
said
I
really
want
to
make
sure
if
I've
got
a
terribly
caustic
worm
that
it
dies
go
to
the
next.
Let
them
give
the
example
of
the
partial
implementations
and
then
the
die
die
worm.
I
Okay
in
the
partial
implementation.
What
happens
if
peer
a
does
all
the
functions
in
the
current
draft?
It
does
all
the
filtering.
It
does
all
the
actions
but
pure
c
supports
dbv2,
but
really
doesn't
support
mpls,
it's
just
playing
an
ip
transit
and
and
does
svc
okay,
because
there
is
an
spc
flow
spec
and
pure
e
does
everything
that
svc?
I
Those
are
reasonable,
cut
downs
to
the
full
functionality
based
on
the
fact
the
pgp
pier
is
not
associated
with
a
filtering
engine.
There
are
an
option
where
you
can
just
put
it
on
hold
in
your
flow
spec
rib,
and
if
it
doesn't
install
that's
fine,
but
it
does
leave
gaps
in
case
you
do
get
routes
in
there,
so
john's
jeff's,
original
work,
along
with
his
co-authors
on
his
original
draft,
was
to
try
to
send
around
capabilities
in
this
case.
I
If
you
have
functionalities
which
are
different,
maybe
you
just
keep
it
in
the
flow
spec.
That's
one
option,
but
it's
a
discussion.
We
need
to
have
about
partial
implantations,
even
if
you're
working
ships
in
the
night
with
db
with
v2
and
v1,
could
we
go
to
the
next
one
now
that
one,
I
I
think,
needs
a
lot
of
discussion.
Another
one
after
listening
to
the
color
discussion
is
what
I
call
die
die
worm.
I
Let's
say
peer
a
says:
I've
got
to
have
this
worm
die
so
badly
that
I'm
going
to
tie
as
I
put
it
in
there,
an
action
tlv
which
is
associated
with
the
mri
notice.
It's
an
nri
with
a
sort
of
action
glued
in
this
is
because
some
people
told
me
when
I
was
listening
that
that
had
to
happen,
but
let
me
give
you
the
problem
and
then
I
I
have
a
recommendation
me
personally
I'll.
Let
donald
comment
on
some
of
it,
but
he's
commented
on
the
text.
I
I
I
The
question
to
this
group
is:
do
I
pull
it
out
now
that
and
and
reform
the
tax
to
a
dash
05,
or
do
we
make
this
part
of
the
working
group?
Call
I
don't
know,
and
that's
sort
of
the
question
are
the
rest
of
it-
we're
pretty
down
to
go
ahead.
Jeff
to
the
rest.
To
looking
for
a
working
group
call,
the
document
has
a
steady
base,
I
think,
for
the
partial
capability.
I
I
I
I
A
I
I
I
I
don't
think
you're
talking
about
the
specific
worm
case
where
we're
trying
to
blew
it
as
an
embedded
idea.
I
think
go
back
to
more
jeff
that
you're
really
asking
me
about
the
links
two
more
toward
the
front.
Jeff
one
end
from
the
front,
you're
really
asking
me
about:
what's
what
sort
of
nlris
are
in
there?
All
of
the
nris
that
are
in
there
are
related
to
v
4
v
6
tlbs
in
those
formats,
mpls
labels
there's
a
separate
dress
for
vpn
labels.
I
So
I
think
this
is
a
fairly
complete
solution,
because
we've
gathered
all
the
flow
spec
good
work
from
everyone
else
and
sort
of
tried
to
be
editors
as
we
as
we
collected
it
as
to
actions
for
all
of
those
there's
pretty
much
an
action.
So
if
you
can
give
me
a
little
more
feedback,
we
can
do
that
before
or
maybe
we
should
just
take
it
offline,
which
is
best
for
you.
Yeah.
A
B
Right
and
yeah
take
prior
learnings
that
we
have
from
things.
So
we
have
the
interface
set,
which
document,
which
is
a
working
group
document,
but
it's
been
basically
in
zombieland
for
a
while.
We
need
to
actually
finish
that
off
and
incorporating
the
learnings
from
that
into
flowspec.
V2
is
part
of
the
stuff.
B
That's
in
charter,
the
the
challenge
that
that
document
had
when
the
authors
were
working
through
the
problem
space
there
is
that
interface
set
is
somewhat
similar
to
our
discussions
about
you
know,
what's
the
semantic
of
a
color
and
how
that
may
be
tied
to
a
given
domain,
the
same
thing's,
true
for
the
semantic
of
you
know,
interface
set,
which
is
just
basically
a
generic
identifier,
for
a
set
of
interfaces.
Now
that
are
tied
to
given
behaviors,
you
know
so
it
could
be
like
domain.
One
may
consider
value
one
to
be
customer
facing
interfaces.
B
B
B
B
It
also
means
that
we
have
to
figure
out
what
to
do
about
carrying
along
with
us.
Whether
that's
something
like
the
example
interface
set
is
a
extended
community,
whether
it
gets
encoded
in
something
like
the
new
multi.
Next
top
no
attribute
one
way
or
the
other.
You
know
it
can't
be
the
key
where
we
go
from
there
as
part
of
the
partial
deployment
now
conversation,
and
also,
how
do
you
actually
have
one
domain
talk
to
another.
I
Right
in
the
current
in
the
current
definition,
colorado,
the
there
are
two
ways
to
pass
it
after
I
rip
out
the
die
die
worm
case,
which
is
either
in
an
extended
community,
which
is
the
way
flo,
spec
v1
has
been,
or
in
a
wide
community,
since
we
are
probably
heading
rapidly
to
the
wide
community
working.
The
group
last
call
based
on
two
implementations,
the
why
community
could
be
used
to
have
a
more
extended
space
for
actions.
I
Okay,
so
there
are
two
ways:
those
two
ways
are
attached
to
an
nlri
and
not
a
part
of
the
key,
just
as
perhaps
another
attribute
could
be
defined
to
be
attached
to
the
nri.
If
you
think
there's
something
that
a
wide
based
community
might
not
fit.
It
would
also
be
good
to
give
me
that
information
having
additional
filters
that
might
handle.
I
Ct
or
color
are
also
appropriate
filters,
as
we
have
sr
segment
routing
filters
in
the
v2
draft.
The
v1
draft
was
closed.
So
we're
trying
to
put
new
by
working
group
decision
for
new
functionality
so
we're
putting
new
functionality
in
the
v2
draft.
So
jeff
did
I
hit
er
kalaraj.
Did
I
give
you
sort
of
the
context
of
how
this
is
looking
at
least
to
help
you
think
about
it?
Yes,.
A
I
G
I
B
We
have,
I
want
to
leave
people
with.
One
final
comment
specifically
about
this,
so
the
the
requirement
that
we
have
from
a
functional
level
is,
as
we
sort
of
discussed,
we
have
match
criteria
that
should
not
be
part
of
the
key
fields,
because
it
needs
to
be
able
to
transform,
and
that
means
be
able
to
be
bundled
along
with
the
bhp
route.
B
B
They
also
don't
have
any
defined
relationships
to
each
other,
and
one
of
the
things
that
we
found
is
we
started
specifying
new
action
types.
Things
like
redirect:
ip
redirect
defer,
etc
is
how
these
things
interact
with
each
other,
and
this
means
that
extended
communities
was
a
very
clumsy
way
to
try
to
actually
say
action.
One
happens,
then
action
two
happens,
so
it's
an
example
redirect
to
verb
and
then
inside
the
verb
for
it
to
a
given
next
top,
and
this
type
of
problem
is
just
going
to
compound.
B
If
we
stayed
with
the
existing
format
so
again,
some
way
to
encapsulate
a
set
of
actions,
potentially
with
orders,
potentially
with
conditional
logic
branching
depending
on
the
problem
cases
being
used,
is
an
necessary
thing.
Why
communities
is
certainly
a
place
this
could
go.
But
that
said,
we
have
a
functional
requirement.
Whether
or
not
white
communities
is
the
solution.
Implementation
is
an
open
discussion.
Point.
I
That's
true:
why
communities
presents
one
extended
communities
will
not
go
beyond
the
strict
ordering
to
a
user
ordering
because
there
simply
isn't
space
in,
but
it
will
go
to
the
strict
ordering
that
flowspec
v1
has
so
it'll
be
user-defined
ordering
and
then,
after
that,
strict
define
ordering.
Of
course,
as
many
people
do,
you
could
play
with
that
in
configuration.
But
that's
part
of
our
discussion
with
the
partial.
B
So,
finally,
thank
you,
everyone
for
attending
that
we
had
excellent
discussion
for
especially
the
ct
car
stuff.
We
are
going
to
endeavor
to
have
the
minutes
prepared
and
done
by
end
of
week
and
sent
out
to
the
mailing
list
and
we'll
appreciate
any
discussions
that
follow
up
from
that.
Clearly
ct
car
has
a
lot
of
interest,
and
you
know
it
may
make
sense
for
us
to
look
as
another
possible
interim
to
discuss
specific
points
that
we
hopefully
converge
a
little
bit
better
in
the
mailing
list.