►
From YouTube: IETF-IDR-20210927-1400
Description
IDR meeting session at IETF
2021/09/27 1400
https://datatracker.ietf.org/meeting//proceedings/
B
B
B
B
B
B
B
C
E
B
B
B
B
B
Huevo
will
present
draftly
idr
flowspec
srv6
and
we're
just
going
to
discuss
the
basically
the
issues
the
tlv
encodings
are
pretty
are
not
the
most
difficult
thing
in
this
presentation.
The
real
difficult
thing
is:
have
we
perceived
the
problem
from
the
operators?
Have
we
identified
the
right
solution?
Jeff
sent
out
several
drafts
this
last
year
that
were
extensions
of
low
spec
v1
everyone
desired
a
flow
spec
v2.
B
B
B
We
have
it
this.
The
discussion
that
we're
working
on
today
shows
you
the
basic
encodings,
the
basic
concepts.
If
we
won't
really
go
through
the
encodings
we're
just
going
to
go
through.
What's
in
them,
you
can
see
the
specifics
of
the
encoding
in
the
draft
again
see
the
pdf
on
this
presentation
and
when
we'll
present
the
one
draft,
what
what
do
we
need
input
on?
B
B
B
What's
also
not,
there
is
the
tunnel
drafts,
that's
the
next
level
of
complexity,
but
I
want
to
stay
with
the
base
problem
and
then
the
next
step
is
we're
moving
toward
flow
spec
v2,
because
we've
had
a
lot
of
discussion.
We
finally
got
through
the
rfcs,
and
so
after
you
see
this,
if
you
think
we've
covered
most
of
the
issues,
we'll
start
to
argue
whether
the
draft
is
ready
for
the
adoption
call.
B
B
So
let's
look
at
flow
spec
v2.
What
does
it
require?
It
requires
two
new
saffies,
because
we've
agreed
in
previous
things
that
we'll
add
two
new,
that
it'll
be
a
ships
in
the
night
approach
that
will
have
flow,
spec,
v2
and
then
we'll
have
flow
spec
v1.
So
it
will
require
two
new
safies
and
one
new
open
capability.
B
B
B
In
flow
spec
v2,
they
are
ordered
by
user
ordering,
so
you
can
say
number
one.
Please
put
these
matches
and
for
this
match.
If
something
happens,
here's
the
action-
and
here
are
the
orders
of
the
action.
Why
do
we
want
to
go
through
this?
Because
one
of
the
problems
we've
heard
is
that
deterministic
ordering
is
a
problem
in
flow
spec
v1
much
as
the
defined
ordering
works
in
many
cases
there
are
some
that
it
does
not
is
not
well
suited.
B
B
If
the
user
ordering
we'll
call
that
ud
order
it
matches,
then
we'll
order
by
flow,
spec
components.
Components
will
have
a
number
from
1
to
n.
If
the?
U
is
your
defined
order
and
the
flow
spec
components
are
the
same
then
we'll
match
by
values.
This
is
simply
an
extension
of
the
v
flow
spec
v1
concept.
B
Now
we're
going
to
go
through
in
a
little
bit
how
you
can
do
flow
spec,
1
and
flow
spec
v2
in
the
same
box.
Remember
for
idr
when
you
use
a
different,
f
safy
and
have
affy
safy
pairs,
then
their
ships
in
the
night
and
what's
the
other
major
change
when
the
action
chain
need
to
be
ordered,
you
can
define
your
user
order,
so
first
I
want
to
sample.
B
Then
I
want
to
redirect
the
traffic
to
this
particular
place,
and
then
I
want
to
limit
or
turn
off
this.
The
traffic
that
I
might
carry.
These
are
actions
now
again.
User
defined
action
has
an
ordering
that's
definitive
if
the
user
order
is
the
same,
then
test
the
action
type
in
order
by
number,
if
the
user
order
in
the
action
type
sends
then
by
value
and
that's
where
the
actions
have
to
define
it
so
folks,
this
is
a
very
simple
extension
based
on
many
of
jeff's
ordering
concepts
we're
using
new
appy
sappy.
B
B
B
B
B
Okay,
match
conditions.
The
match
conditions
are
pretty
much.
What
you'd
expect,
where
you're
ordering
the
components
via
flow
spec,
v1
rules
expanded
into
flow
spec,
v2,
the
rule
actions
are
again
either
user
order
and
change.
So
if
you
have
an
action,
you
would
say:
okay,
these
actions
go
to
this
user
order
and
then
you
might
say
some
others.
The
actions
will
be
ordered
in
the
user
fashion.
B
B
B
B
The
filter
db
rule
zero
permit
all
one
through
n
flow
spec
filters,
bgp
peers
with
flow
spec,
1
and
flow
spec
2
in
their
database
of
filters
need
to
consider
ordering.
So
if
you
have
flow,
spec
won't
be
one
you're
great.
If
you
have
flow
spec
v2
only
you're
great,
if
you
should
use
a
pure
b2,
which
has
both
of
those
there's
a
recommendation
in
here
that
you
order
your
filters
with
fil
order
based
filters.
B
First,
followed
by
non-order
base
filters,
so
flow
spec
v1
goes
1
to
n,
and
then
your
filters
for
flow
spec
v1
are
placed
above
that
y.
That
allows
us
to
deploy
all
the
filters
for
flow,
spec,
v2
and
all
their
actions
and
then
pick
up
the
ones
that
are
on
full
spec
v1
again.
If
you
have
either
one
it
won't
matter,
but
if
you're
ordering
your
filters
to
assume
if
you're
in
a
bgp
pier
with
v1
and
v2,
you
will
want
those
order
filters.
B
B
If
you
look
here
is
a
bgp
peer
and
it
could
be
appear
within
a
single
as
or
it
could
be
appear
within.
Multiple
answers
assume
for
excuse
me.
Multiple
aliases
that
might
be
within
an
as
confederation
is
probably
the
best
example.
The
ships
in
the
night
sent
the
databases
for
v2
and
v1
separately.
So
you
see
the
db
v1
in
yellow
and
the
dbv2
pure.
B
B
B
Does
pure
d's
data
flow
really
match,
and
those
are
the
questions
about
deployment
in
this.
Many
people
have
deployed
flow
spec
targeted.
They
either
send
it
via
route
reflectors
and
have
a
overall
a
s
description
or
they
send
it
to
targeted
nodes,
and
if
it
was
a
targeted
node,
maybe
peer
d
is
not
really
targeted.
B
B
The
reason
is
we're,
assuming
the
users
will
order
it
based
on
what
they
want,
and
this
tie
breaking
based
on
action
type
and
then
value
is
simply
a
failure
for
some
of
the
deployment
to
work
correctly.
However,
with
the
defined
actions,
hopefully,
life
is
deterministic,
it
does
this,
and
then
it
does
this
now.
One
of
the
things
we
have
to
consider
is
what
happens
when
actions
fail
to
complete
both
jeff.
I
and
many
people
have
worked
randy
and
many
people
on
the
list
have
have
worked
on.
B
Network
management,
which
has
a
reply
response
and
one
of
the
key
problems
that
netcup
rescumf
had,
is
what
happens
when
actions
fail
to
complete?
How
do
you
characterize
it?
Well,
that's
one
of
the
major
issues.
What
do
you
do?
Do
you
continue
on
a
best
effort?
Make
the
actions
you
can
do
you
stop?
B
Do
you
use
a
conditional
point
I'll
continue,
this
type
of
things
we
need
to
talk
about?
What's
necessary,
simple,
is,
if
you
don't
have
a,
if
you
have
a
failure,
you
simply
stop.
Does
that
mean
you
stop
and
roll
back?
That's
another
thing
that
the
that
comp
people
did
right
now,
it's
defined
as
hit
a
failure.
Stop
that's
a
failure
to
complete
the
action.
For
example,
if
you
were
to
sample
something
and
you
had
a
failure
in
sampling
with
that
failure
and
sample,
prevents
you
from
limiting
the
traffic
or
redirecting
the
traffic.
B
That's
something
we
need
to
talk
about.
Okay!
Now
there
are
some
other
issues
that
we
have
regarding
the
tight
binding
of
the
actions
with
a
particular
match.
For
example,
if
you
have
a
match-
and
you
have
a
community
associated
with
it
wide
or
extended,
you
may
strip
those
communities
at
the
edge
of
the
as
no
harm
devon
doesn't
stick
on
a
new
communities
and
we
anticipate
that's
the
way
that
most
of
this
will
happen.
B
However,
the
original
precept
was
operational
issues
regarding
denial
of
service,
where
you
might
have
the
die
die,
die
internet
worm
concept.
Does
that
take?
Does
that
mean
we
should
buying
certain
filters
to
a
die,
die,
die
internet
worm,
type
of
actions
and
never
let
them
be
moved
aside.
Jeff
and
I
in
making
this
discussion
said
that,
though,
that
sounds
like
a
good
proposal.
B
E
So
warren
has
a
comment
in
chat.
His
comment
is
surely
the
correct
behavior
and
failure
depends
on
the
purpose.
I'd
be
sad
if
the
default
is
deploy.
None
and
my
interface
is
now
wide
open.
It
might
equally
be
said
if
some
it
applies
to
some,
but
my
interface
doesn't
let
me
log
in
where
did
you
create
it.
C
That
about
sums
it
up
right,
like
certain
things,
fail
and
close.
Just
the
right
answer.
Certain
things
failing
open
is
the
right
answer.
I
think
what
many
people
do
is
they
apply.
You
know
a
set
of
policies
and
then
layer
this
on
top.
So
maybe
that's
not
the
end
of
the
world,
but
it
does
still
seem
like
the
correct
failure
is
very
much
dependent
on
if
it's
acting
as
a
firewall
or
a
sampler
or
a
you
know,
let's
log
some
stuff
or
what
the
purpose
of
the
policy
being
applied
is.
B
B
E
Right
and
if
I
could
interject
one
of
the
things
that
possibly
does
not
belong
in
the
protocol
text
worn
but
might
actually
be
good,
operational
text
is,
if
you
want
something
like
here's,
the
rule
that
allows
you
to
make
sure
that
you
can
still
ssh
into
all
of
your
routers.
Now
you
want
that
thing
to
obviously
be
a
higher
precedence
rule
than
most
of
the
stuff
flying
through
flowspec.
E
B
B
B
Implementation
team
and
say
give
me
one
that
works
in
all
networks.
Just
not
going
to
happen.
You
will
probably
be
able
to
define
various
scenarios
for
different
networks,
and
I
was
hoping
we'd
get
some
feedback
from
operators
to
see.
If
this,
the
assumption
I
just
made
is
true,
and
if
it
is
true
that
you
want
to
tailor
this,
then
it
would
be
good
to
have
a
few
use
cases.
B
Yep
jeff
had
hoped
nanog
and
some
of
the
other
operative
forms
might
open
up
again
for
live
discussions,
I'm
not
sure
when
kovitz
gonna,
let
that
happen,
but
we
really
do
need
the
the
operator
feedback
before
this
gets
out
in
the
wild
and
again
this
is
just
going
through.
The
action
chain
must
plan
for
failure.
E
So
it
just
to
pass
along
some
of
the
other
discussion
that
we've
had
amongst
ourselves
with
the
chairs.
The
the
headache
here
is
partially
touching
on
a
topic.
That's
very
lightly,
discussed
in
the
remainder
of
the
presentation
and
is
really
deserving
of
a
lot
more
discussion
later
on
of
how
do
we
handle
issues
from
incremental
deployments
so
with
the
match
conditions
that
sue's
shown
and
the
action
conditions
that
she's
discussing
right
now?
E
The
headache
we
have
is
what
happens
if
you
know
things
fail
to
install
not
only
just
from
a
problem
with
the
way
the
rules
are
architected,
but
perhaps
a
feature
is
being
requested.
That
simply
is
not
supported
on
the
local
box
and
as
warren
sort
of
points
out,
you
want
to
make
sure
that
you
know
your
intent
across
the
network
for
your
filtering
gets
respected.
E
But
if
it's
not
possible
to
actually
implement
that
intent,
you
need
to
do
something
same
and
that's
a
combination
of
you
know.
One
part
just
figuring
out
how
the
incremental
intent
you
know
would
or
not
get
applied,
based
on
a
support
or
lack
of
support
for
a
given
feature
and
making
sure
that
your
rule
ordering
is
designed
so
that,
if
you
do
have
some
sort
of
failure,
that
your
network
fails
open
or
closed
appropriately.
B
And
one
other
thing
that
that
we
have
been
discussing
is
idr
is
a
distribution
protocol
and
I'll
pick
this
up
in
a
couple
moments,
but
you
can
it's
a
great
distribution
protocol
to
send
lri
and
to
send
these
rules
out
quickly.
However,
it
is
not
a
reply
protocol
you
send
things
out
and
they
get
installed,
but
that's
it
if
you
have
a
failure
with
the
action.
B
The
only
thing
that
you
can
find
out
that
you
can
that
records.
That
is
some
sort
of
network
management
thing,
either
a
message
back
via
netconf
resconf
log
with
a
yang
module.
You
might
be
able
to
have
something
where
you
send
an
action
that
says,
if
I
get
any
of
these,
please
send
me
back
and
and
the
push
and
the
recording
piece
and
that
conf
now
allows
that
to
work
with
lots
of
filters.
B
B
The
place
that
that's
going
to
work
from
is
not
from
bgp
that
that
action
response
is
not
in
the
scaling
of
bgp.
That
action
response,
however,
does
scale
for
could
scale
very
well
in
the
in
a
network
management
there.
It
is.
I
didn't
turn
to
the
next
page,
so
when
bgp
delivers,
nlris
and
communities
with
good
scaling
properties,
you're
doing
great
you've
got
a
quick
multicast
or
a
good
web
burst
action
response
for
net
conference
cons
was
built
into
the
monitoring.
B
B
B
E
Sure
then,
this
is
some
of
the
metas
that
aren't
necessarily
covered
in
the
presentation,
so
you
discuss
this
sort
of
lightly
in
the
context
of
actions
and
the
current
encoding
that's
discussed
inside
of
first,
you
know
the
draft
version
three
of
the
flowspec
v2
is.
What
do
you
do
about
your
actions?
Are
they
part
of
the
nlri?
That's
what's
suggested
in
the
document
and
you
already
had
discussed.
E
Maybe
these
things
belong
in
the
under
eye,
and
maybe
these
things
belong
as
a
separate
thing
similar
to
what
we
have
today,
the
fundamental
issue
that
we
have
with
tucking
things
with
nlri.
Is
you
don't
really
get
a
chance
on
a
hot,
buy,
hop
basis
or
even
at
a
you
know,
asbr
as
an
example
to
be
able
to
change
things
so
in
circumstances
where
you're
expecting
to
need
to
alter
something
for
some
reason,
as
you
pass
stuff,
either
router
router
or
across
as
boundaries,
you
have
to
decide.
You
know
where
this
stuff
lives.
E
E
It's
really
a
match
criteria
and
the
vast
majority
of
the
match
criteria
currently
live
in
the
lri.
The
problem
is
that
an
interface
that
is
a
given
operators,
idea
of
what
a
domain
assignment
looks
like
for
your
interfaces.
So
if
you
know
number
100
matches
your
peers,
number
200
matches
your
customers
in
some
domain
and
that
changes
in
a
different
domain
either.
You
know
the
circumstance
where
you're
passing
a
customer
to
service
provider
filter
in
flow
spec
or
from
a
service
provider
to
a
peer
service
provider.
Filter
and
needs
a
change.
E
E
E
E
E
B
B
Change
scaling
properties
is
the
best
way
to
kindly
put
it
okay,
I
think
we've
covered
many
of
these,
but
I
will
go
through
the
issues
I
see.
We
need
to
have
some
good
discussion
on
just
so
that,
as
a
summary
on
some
of
the
things
jeff-
and
I
have
said
this-
may
be
your
first
time
looking
at
this
we're
gonna.
B
B
What
about
filters?
How
should
nodes
handle
unknown
filter
components
if
you're
just
going
with
d2,
because
part
of
v2
is
the
ability
to
say?
Okay,
I've
got
a
certain
set
of
filters
now
and
if
you
implement
the
v2
spec
I've
I've,
given
you
the
filters
from
the
past
and
the
ones
we've
agreed
on
as
idr
and
we'll
get
a
deployment
of
those
filters
and
we'll
send
it
forward
to
rfc,
but
then
there's
going
to
be
new
filters
because
there'll
be
new
worms,
there'll
be
new
technology.
B
How
do
we
handle
them?
What
happens
if
you
have
flow
spec
v2
and
you
get
a
new
filter
component?
Should
we
be
sending
out
you
know,
capabilities
jeff
gave
you
a
proposal
for
that
and
people
proposal
for
that
for
v1
and
people
roundly
said.
No,
I
didn't
really
want
to
do
that.
So
how
should
we
do
it?
B
B
Right
now,
we've,
given
you
our
view
of
the
flow
spec,
v2
and
v1
nodes
ships
in
the
night
transmission
filters
need
deterministic
order.
Why?
Because
many
of
the
problems
we've
heard
are
lack
of
deterministic
order,
where
one
implementation
chooses
one
order
and
another
implementation
chooses
another
order.
The
protocol
should
have
deterministic
if
the
implementations
that
put
in
non
that
make
it
non-deterministic
can't
fix
that.
That's
always
possible.
E
B
B
Because
bgp
lacks
another
technology
piece
to
put
into
it,
but
because
there
are
operational
issues,
so
what
operational
issues
have
we
left
out
or
are?
We
are
failing
to
saw
and
then
the
error
handling
is
another
embedded
error
handling
case
and
I've
tried
to
write
a
good
validation
error
handling.
B
Please
to
take
a
look
at
the
pdf.
You
can
print
that
if
you
have
any
comments,
let
me
know
this
week
next
monday
I
will
produce
the
o3
I've
gotten
lots
of
terrific
feedback,
and
if
you
sent
me
feedback-
and
I
didn't
in
all
the
changes,
I
didn't
correctly
handle
it
now.
Here's
our
discussion
point
topology.
B
Let's
say
that
we
have
peer
a
that
is
sending
out
a
flowspec
v2
features
and
pier
c
that
is
sending
out
flow,
spec,
b2
features
and
suddenly
pier
v
two
starts
to
send
out.
Let's
pick
a
an
sr,
v6
filter
and
us
a
new
filter
for
svc
and
what
these
filters
do
is
they
drop?
It
drop
a
particular
data
stream
into
either
the
s
vc
forwarding
in
a
particular
point,
or
they
drop
things
into
a
sr
segment,
routing
sequence.
B
B
B
B
B
E
So,
while
we're
waiting
for
other
people
to
find
their
unmute
button
to
raise
hand
button,
the
topology
here
is
also
a
good
discussion
point,
for
you
know
not
only
the
different
capabilities,
but
also
you
know
where
you
tend
to
send
your
rules.
So
we
gave
an
excellent
example
that
perhaps
some
portions
of
your
network
support
segment
routing
and
you
want
to
use
segment
routing
features
as
full
spec
components
either
for
matching
or
for
sending
for
your
actions.
E
Maybe
you
have
an
sfc
portion
of
your
network
that
wants
to
do
this
and
where
this
conversation
sort
of
moves
us
again
back
to
is
the
incremental
deployment
considerations,
and
this
was
part
of
our
discussion
about.
Could
we
put
most
of
the
missing
things
that
we
need?
No
or
at
least
the
easy
ones
back
into
flow
spec
v1
and
the
answer
people
kept
on
giving
is
well.
No.
We
want
this
for
spec
v2.
E
What
we're
sort
of
seeing
here
is
that
it
doesn't
really
change
the
equation.
You
know
it's
still
equally
as
hard
for
distribution.
We
have
to
figure
out
what
these
things
don't
mean,
and
you
know
how
do
the
actions
that
might
be
compatible
for
one
portion
of
your
network
get
passed
along
or
or
not
in
another
portion.
B
G
B
G
G
Sr
physics,
seats
and
then
another
another
type
is
for
part
of
seats.
So
some
people
offered
some
discussions
in
the
mailing
list,
so
I
think
the
itunes
one
suggests
we
may
combine
those
two
types
into
one
so
which
is
a
one
part,
because
some
parts
of
the
com
sees
includes
the
whole
seats.
So
that's
a
good
suggestion.
So
in
the
latest
version
we
combine
two
original
two
compo
coupon
commodities
into
one.
G
G
G
G
So
here
we
just
introduce
a
few
type,
so
this
field
type
will
indicate
which
field
or
which
part
of
seat
we're
going
to
match.
So
we
define
here
we
give
so
the
field
type.
If
we
zero
indicate
that
locate,
locator
part
of
the
seat,
one
is
the
function,
part
zero,
one,
zero
indicated
the
arguments
part
and
then
we
also
give
some
kind
of
combinations
so
because
the
combination
should
be
should
be
make
sense.
G
So
one
combination
is
a
locator
part
and
a
function,
part
adjacent.
So
the
other
combination
or
type
code
is
a
one,
zero,
zero,
which
indicates
a
function
and
argument
path
combined.
So
the
last
one
is
we
just
come:
we
we
are
going
to
match
all
water
paths,
which
is
whole
sweet,
so
this
is
a
so.
This
is
a
few
type
of
indicators
located
function
and
arguments.
So
if
we,
if
the
parts
of
a
seed
contains
a
water
path,
this
is
the
whole
whole
suite.
G
G
So
that
will
be
one
of
the
component
or
part
of
the
seat
match
this
one,
this
locator
and
then,
in
addition
to
much
dislocator.
We
also
also
give
another
much
confusion,
which
is
that
for
the
function
part
of
that
seat,
the
function
part
of
that
seat
must
be
indeed
in
a
range
from
one
or
100
to
300..
G
So
in
order
to
define
this
match
conditions,
so
we
just
use.
So
we
have
a
type
type,
is
a
a
new
component
type
and
then
we
define
we
indicated
the
structure
of
of
the
sheet.
So
here
is
the
locator
is
30b
as
a
locator
is
a
48
bit
so
in
code
in
here
it
is
30
in
in
a
in
x,
x,
0x
format
and
then
the
function
length
of
the
function,
type
apart,
which
is
16
bits
and
then
the
rest
is
argument.
Part
is
a
64
bits.
G
G
So
that's
the
located
value
and
then
we
also
have
a
match
condition,
which
is
indicated
that
the
function
part
of
the
fleet
must
be
greater
than
100
and
then
less
than
300.
So
this
is
also
defined
by
by
the
open
and
on
the
vertical
stuff,
which
is
which
is
similar
or
same
as
those
defined
in
rfc
8955.
G
G
Then
there's
some
subtle,
v's
subject
and
length
of
sample
p
and
the
subtrophies
in
this
sub-q
v,
which
is
contains
a
value
which
is
rp-savvy
and
then
component.
So
we,
the
new
component
for
srv6,
can
just
speed
here.
So
this
is
according
to
the
current
encoding
of
through
702
v2,
so
as
the
through
spec
flow
2
moving
forward,
if
they
change
its
format
or
whatever,
and
then
we
can
also
change
accordingly
to
make
our
document
or
lose
the
packet
for
s
office,
six,
two
feet
or
nine,
with
the
ongoing
changes.
B
The
action,
that's
the
action
encoding
his
field
encoding
should
be
fairly
standard.
So
this
is
his
example.
If
you
added
an
action,
so
I
I
I
had.
We
asked
waymo
to
present
this
because
there's
quite
a
bit
of
support
to
add
this
particular
draft
to
our
list
of
idr
drafts,
but
this
gives
you
an
example
of
how
it
might
provide
the
components
and
weymouth
has
done
a
wonderful
job
about
trying
to
give
the
pattern
and
the
destination
references
for
v6.
B
B
E
So
I
throw
myself
into
the
queue
and
cares
behind
me
so
amo.
I
would
like
to
use
your
presentation
as
a
discussion
point
about
incremental
deployment,
so
you're
intending
this
feature
to
be
used
for
networks
that
support
srv6
and
it's
possible
that
a
bgp
network
that
has
sr
support
may
not
have
sr
support
across
100
of
it.
E
G
G
E
G
A
Can
you
guys
hear
me,
you
have
the
mic?
Yes,
yep
super,
so
one
comment
jeff
all
questions.
You
asked
the
right
ones.
Maybe
I
am
little
off
and
it's
a
early
morning
in
california.
So
please
bear
with
me,
but
I
think
srv6
applies
on.
The
edge
has
necessary
function,
translation.
But
if
you
don't
understand
the
function
or
you
don't
understand
any
srvc
clear,
then
your
edges
will
not
simply
behave
and
execute
those
functions
well
and
it
will
treat
it
as
a
normal
ipv6
address,
blah
blah
blah
blah
more
details
to
follow.
A
G
A
E
If
you
recall
sue's
example,
topology
diagram,
one
way
to
sort
of
picture
that
is,
we
effectively
have
the
equivalent
of
no
flow
spec
flooding
domains
and
when
it's
strictly
affy
sapphis.
Now
we
know
exactly
what
that
looks
like
effectively
distinct
planes
that
are
bounded
by
a
point
of
distribution.
E
Now,
based
on
the
you
know,
affy
safes
that
have
been
negotiated,
that's
true
for
every
piece
of
bgp
we've
had
to
date
and
for
the
most
part,
if
it's
not,
you
know
the
standard
internet,
daffy
saffies,
you
know,
for
the
most
part,
that
does
define
a
a
region
of
no
support
for
a
given.
You
know
family,
where
we
have
an
interesting
headache.
Is
that,
if
we're
to
ignore
this
being
v,
one
v
two
flow
spec
for
affy
zaffi,
we're
looking
at
you
know
capability
graphs
effectively,
you
know.
Does
this
support
this
match
criteria?
E
The
first
one
is,
you
know,
a
route
reflection
plane
which
may
or
may
not
be
the
same
as
your
existing
ip
reflection
plane.
More
often
than
not,
it's
disjoint
from
that
and
a
route
reflector
takes
the
job
of
distributing
a
controller's
flow,
spec
routes
off
to
all
the
devices
that
can
receive
them
and
is
intended
to
process
them.
E
E
This
isn't
necessarily
a
new
problem
in
bgp,
or
especially
for
people
who
have
done
multicast
deployments
in
the
past,
but
it
does
change
the
way
that
flowspec
might
need
to
be
operated.
What
I'd
like
to
do
at
this
point
is
take
this
set
of
points
and
ask
especially
the
people
that
have
operational
experience.
You
know
what
what
is
your
thinking
about
this?
You
know:
how
does
this
impact,
how
you're
likely
to
want
to
use
flowspec.
E
And
given
our
silence
and
given
the
fact
that
I
see
at
least
a
couple
of
operators
on
the
list,
if
you're
simply
not
comfortable
with
you
know
the
thinking
at
this
point
and
you're
still
trying
to
figure
it
out.
If
you
wouldn't
mind
just
throwing
a
note
in
chat,
saying
that's
where
you're
at
that
would
also
be
helpful.
E
Now
we've
at
least
hit
the
point
where
nobody
seems
to
be
in
the
chatty
mood,
except
for
the
presenters.
I
guess
the
last
comment.
I'd
actually
want
to
leave
here
is
that
this
set
of
issues
isn't
necessarily
distinct
to
flow
spec
v2.
You
know
this
is
the
same
set
of
things
that
if
we
wanted
to
keep
things
on,
the
simpler
side
of
things
was
exactly
the
problem
we
had
with
low
spec,
v1
and
incremental
deployment
of
new
features,
so
v2
does
not
necessarily
make
this
any
better.
At
this
point,.
D
E
E
E
Okay,
let's
actually
supply
a
you
know
concrete
example,
and
maybe
that
would
be
useful
to
help
with
the
discussion.
So
one
of
the
optional
features
my
employer
has
some
people
on
a
draft
for
is
the
ability
to
do
payload
matching
inside
of
the
packets
and
you're,
seeing
a
slightly
different
flavor
of
this.
You
know,
perhaps
by
different
example
and
the
header
that
ymos
showing
us,
for
you,
know
srv6.
E
It's
probably
not
the
greatest
idea
in
most
of
those
cases
to
skip
over,
because
you
know
what
happens
if
you
skip
that
component
you're
effectively
matching
the
stuff
in
a
looser
fashion,
and
there
may
be
cases
you
know
both
for
and
against
that
you
know.
Maybe
you
know
want
to
say
in
the
portions
of
my
network
that
I
can
understand
these
things.
It's
actually
great
that
I'm,
you
know
further.
Restricting
you
know
how
much
damage
I'm
doing
to
stuff
that
I'm
inspecting
you
know.
E
E
Okay,
that
seems
like
a
reasonable
discussion
point
to
take
on
for
the
v2
encodings,
and
you
know
we
may
very
well
end
up
in
some
flavor
of
some
of
these
things
are,
you
know,
mandatories
and
must
be
supported
by
everybody
effectively.
The
flowspec
v1
components
are
very
widely
supported
across
the
majority
of
implementations
and
making
those
you
know
mandatory
bitwise.