►
From YouTube: IETF-IDR-20210607-1400
Description
IDR interim meeting
2021/06/07 1400
B
B
C
B
A
D
E
A
F
B
A
A
The
format
of
the
interim
is
basically
going
to
be
a
quick
set
of
discussion.
Basically
as
a
here's,
where
we
were.
Please
feel
free
to
ask
questions
during
this,
but
my
recommendation
is,
I
have
maybe
less
than
10
minutes
worth
of
slides,
and
the
majority
of
the
point
for
this
interim
is
discussion
about
what
we
think
we
should
do.
Unfortunately,
robert
dreschook
is
not
going
to
be
showing
and
he
was
one
of
the
people
that
was
very
opinionated
about
what
we
did.
A
Started:
okay,
seeing
nobody's
seizing
the
microphone,
so
the
current
state
of
things
flow,
spec,
v2,
so
did
a
quick
draft.
You
know
almost
five
years
ago
now
covering
some
of
the
things
that
we
could
not
do
with
lowspec
at
the
time
that
were
being
considered
important
for
next
generation,
flowspec,
probably
the
most
interesting
thing
that
was
one
of
the
bigger
pieces
of
fallout
from
the
work
that
gave
us
89.55.
A
A
So,
as
a
consequence
of
that,
we
did
end
up
removing
the
opaqueness
from
8955,
which
left
us
with
the
interesting
problem
of
what
they
do
about
it
for
full
spec
v2.
Now
one
of
the
options
is
to
move
to
a
full
tlv
format
psep
when
they
were
implementing
their
ability
to
flow
matching
as
part
of
their
mechanism
brownflow
spec
encodings,
but
they
also
made
sure
that
each
you
know
flow
spec
component
type
was
put
into
a
separate
tlv
field
bgp.
Why
is
this?
This
is
an
interesting
situation.
A
If
we
move
to
this
type
of
behavior,
barring
a
bit
of
terminology
from
seabor,
now
we
have
a
possibility
for
a
well-formed.
Now
this
is
a
valid
tlv,
but
invalid
in
case
the
contents
are
not
taken
care
of.
So
this
will
be
a
thing
we'll
have
to
discuss
and
potentially
impacts
things
like
beech
beer
handling
from
our
c-7606.
A
Several
the
flow
spec
use
cases
that
we
had
pop
up
in
the
prior
years
depended
on
rule
ordering,
and
you
know
today,
flowspec
does
a
default
sort
order
that
is
reasonably
well
set
for
distributed
denial
of
service
mitigation,
it's
not
terribly
good
for
generic
firewall
behaviors
and
even
for
the
ddos
node
situations.
There
are
some
combinations
of
rules
that
the
field
has
noticed
that
simply
don't
optimize
very
well
for
various
implementations
and,
of
course,
that's
implementation
issue,
but
it
does
it's
a
thing
that
actually
needs
to
be
dealt
with.
A
A
One
of
the
things
that
sort
of
cropped
up
as
part
of
each
of
these
pieces
of
work
was
that
how
do
these
things
interact
with
each
other?
What's
the
precedence?
What's
the
priority?
How
do
they
stack
together?
Those
specific
examples
the
redirect
features
had
to
spell
out
very
specifically,
if
you
had
more
than
one
copy
of
the
rule,
what
is
it
intended
to
do?
A
We
also
have
an
interesting
thing
that
flow
spec
interface
set
provided
a
feature
that
probably
would
go
into
nri
in
terms
of
matching
purposes,
but
no,
it
was
a
behavior
that
needed
to
be
able
to
change
on
a
potentially
as
by
s
or
maybe
even
a
hop
by
hop
basis,
and
that
you
know
couldn't
be
done.
If
you
stuck
into
the
nlri
and.
A
Now
we
ended
up
with
a
lot
of
very
good
discussion
on
the
mailing
list.
As
part
of
this,
the
two
separate
features
was
basically
a
capability
bits
which
allows
us
to
say
how
does
one
implementation
talk
to
another
handle
being
able
to
parse
things,
and
this
deals
with
the
opaqueness
problem
that
we
had
before
the
flowspec
v2
format
is
definitely
on
the
cleaner
side
of
things,
but
part
of
the
discussion
point
that
the
capability
bits
also
brought
us.
A
Is
you
know
what
you
do
when
you
don't
understand
things
as
a
new
component
and
we'll
be
talking
about
that
momentarily
in
an
upcoming
slide
term,
ordering
ended
up
being
a
relatively
easy
thing
to
wedge
into
the
existing
flowspec
v1
plumbing,
without
any
problems.
As
long
as
you
have
something
like
the
capability
bits
to
allow
it
to
be
sent.
A
G
A
A
So
the
discussion
that
we
had
about
the
capability
bits
seeded
the
discussion
about
what
we
should
do
about
incrementally
deploying
new
features,
and
we
we
had
some
very
good
discussions
there
and
some
of
these
things
are
separable.
So,
for
example,
you
know
being
able
to
parse
a
new
component
you.
What
do
you
do
in
terms
of
being
able
to
handle
the
parsing
for
that
with
the
capability
bits?
A
You
provide
at
least
the
indication
that
you
theoretically
can
parse
a
thing
if
it's
opaquely
held
in
a
tlv
that
you
may
or
may
not
understand,
either
the
adjacent
top
or
further
in
your
network
via
route
reflector.
Well,
we
now
have
some
additional
air
handling
components.
This
is
sort
of
the
damage
from
afar
that
rfc
7606
was
trying
to
mitigate.
A
That
ties
very
much
into
incremental
new
features
is
what
do
you
do
when
you
don't
understand
something
and
you
can't
install
it
full
spec
basically
says
you,
don't
just
simply
don't
install
the
rule
chain
that
is
compiled
from
it,
but
the
problem
you
have
with
that
is:
if
the
rules
are
not
independent,
you
could
end
up
with
holes
in
the
rule
set
and
depending
on
what
the
intent
of
those
rules
may
be.
You
may
end
up
with
misfiltering.
A
So
that's
an
interesting
deployment
challenge
and,
to
some
extent,
these
things
as
a
collection
highlight
that
we
have
a
not
well-defined
flow
spec
domain.
Now,
here's
a
set
of
routers
that
participate
in
flow
spec
that
may
understand
specific
features
and
may
have
nobility,
even
if
they
understand
them,
you
know
to
deploy
them
or
not
deploy
them.
So
that
impacts
the
discussion
as
well.
A
One
of
the
things
that
was
not
discussed
but
is
equally
important,
is
component
ids
in
our
default
sort,
determine
where
they
go
in
the
sorting
order.
This
means
that,
as
we
add
new
features,
we
have
to
decide.
You
know
what
component
id
they
get
and
this
potentially
can
impact.
How
they
actually
get
installed
in
a
default
sort
order
once
we
have
a
feature
that
can
explicitly
do
the
term
orders,
it's
less
important.
A
One
of
the
biggest
challenges
we're
going
to
have,
even
once,
we've
decided
what
the
extension
mechanisms
look
like
is.
How
do
things
interact
with
a
completely
boring?
You
know,
in-plane,
you
know
89
55
compliant
flow,
spec,
v1,
so
operationally
the
motivation
for
discussing
this
is
really.
What
do
you
do
about
term
ordering?
A
A
A
A
A
B
B
B
B
B
B
H
H
Some
solution
use
the
flows
back
to
adjust
the
traffic,
so
so,
when
we
do
that,
we
also
want
to
send
the
floor
rule
to
specify
rotor.
So
so,
if
so,
it
will
not.
The
roads
were
not
actually
effective
on
all
roads.
It
only
effects
effects
on
some
specified
router,
so
some
loaders,
like
rotary
slasher,
don't
support
the
new
component.
I
think
it's
also
okay,
but
it
just
needed
to
extend
the
flow
route
to
the
correct
router.
I
think
that
then
your
landlord
can
be
effective.
E
A
Correct,
okay,
you've
lost
the
mic
queue
again
so
I'll
give
an
example
of
a
rule.
Dependence-
and
you
know,
maybe
make
it
an
easy
thing
to
see
so
even
without
having
any
new
flow.
Spec
features
think
about
what
happens
if
you
accidentally
filter
a
flow
spec
route.
Now
consider
the
case
where
you
have
a
rule
that
matches
a
destination.
A
A
A
If,
for
some
reason
you
end
up
losing
the
more
specific
rule
based
on
the
sword,
ordering
you'll
end
up
with
misfiltering
and
in
cases
for
new
features,
we
see
something
very
similar.
If
you
don't
understand
a
given
feature,
you
may
end
up
doing
misfiltering
there
so
that
that's
what's
intended
about
the
the
problems
for
independent
rules.
A
I
think
the
second
piece
of
question
I
heard
from
you
was
the
partial
deployment
problem
and
part
of
what
we
have
is
tools
for
flow
spec
distribution
of
routes
is,
there
are
two
common
ways
that
routes
are
distributed
in
full
spec
domains.
Right
now,
in
my
experience,
first
one
is
that
there
is
a
route
reflector
plane
that
is
set
up
for
distributing
the
flow
spec
routes,
so
all
of
the
routers
currently
get
a
consistent
set
of
rules
within
you
know
that
route
reflector
plane,
the
second
one
is
routes,
are
basically
targeted.
A
So
a
firewall
controller,
for
example,
may
send
a
flowspec
route
to
a
specific
router
and
it
contains
the
bgp
no
advertise
attribute
in
there.
So
that
does
not
propagate
any
further,
so
the
targeted
one
is
obviously
an
easy
way
for
us
to
incrementally
deploy
new
features,
especially
if
we
have
something
like
a
capability,
whether
it's
the
bits,
one
that
I'm
suggesting
or
something
else
that
gives
the
supported
functionality,
it
becomes
possible,
for
you
know,
bgp
session
to
you
know,
for
at
least
that
router
by
router
basis
decide
whether
to
distribute
things.
A
If
we
have
no
non-matching
capabilities,
certainly
features
like
the
flow
spec
bits
can
sort
of
cause
an
appropriate
pruning
to
happen
within
the
domain,
but
it
may
suggest
that,
for
certain
combinations
of
features
that
we
may
end
up
needing
multiple
planes
and
we're
already
sort
of
seeing
a
push
towards
that
paradigm.
Anyway,
as
an
example,
the
l2vpn
flowspec
is
a
different
safy.
Now,
there's
no
reason
that
a
set
of
bjp
speakers
that
speak
l2vpn
no
flowspec
have
to
be
the
same
set
of
routers.
That
support
know
some
other
extension
as
an
example.
H
J
Can
you
hear
me
now
make
an
interview?
Okay,
yeah?
I
I
agree
that
incremental
deployment
of
the
new
flossback
features
is
a
new
important
capability,
and
there
we
have
some
observations
about
the
deployment
of
the
flows
back
in
my
understanding
that
usually
the
scope
of
the
flows
back
announcement
is
within
a
single
domain
or
under
earth
control
of
a
single
administrator.
J
J
J
A
Okay,
thank
you.
So
a
few
comments
on
that.
Certainly
one
of
the
problems
that
we
have
is
just
simply
understanding
what
devices
support
being
able
to
parse
something
and
once
parsing
has
been
handled,
whether
the
device
is
capable
of
implementing
it.
So
your
point
is
no
valid
that
it
may
not
be
required
in
many
cases,
for
every
single
device
to
know
how
to
implement
a
specific
thing.
A
A
But
that
sort
of
goes
to
your
second
point,
where,
if
you
actually
have
a
flow
spec
domain,
where
for
some
reason
you
can't
inconsistently
apply
filters,
then
you
may
or
may
not
have
a
problem
based
on
that,
so
the
main
challenge
is
being
able
to
figure
out
whether
something
is
safe
and
even
if
it
is
under
a
single
administrator
control,
you
know.
Can
your
tooling
tell
whether
something
is
no
safe
to
build
a
specific
role
set.
A
It
may
depend
this
is
one
of
those
it
gave
the
example
of
even
a
simple
filter.
You
know
for
existing
flow
spec
if
you're
designing
your
flow
spec
rules
for
specific
purposes.
You
know
as
an
example,
just
ddos
you're
less
likely
to
run
into
these
sorts
of
problems,
but,
as
you
start
doing,
things
that
are
closer
to
standard
firewall
behaviors,
where
rule
ordering
becomes
much
more
important,
it
became
much
more
of
a
problem.
A
F
F
F
A
I
agree,
then,
you
know
being
a
coder
for
one
of
the
implementations
that
sort
of
rudely
will
accept
one
flow
spec
route
and
change
it
into
a
second
flowspec
route.
You
know
this.
This
can
be
an
interesting
problem,
and
certainly
that's
worth
discussing
is
a
thing
that
we
can
do
for
v2.
Since
you
know,
if
we
actually
do
a
major
revision,
that's
a
perfect
place
to
do
it.
A
F
A
I
Hi
yeah,
so
I
I
make
a
very
high
level,
maybe
slightly
radical
comment,
but
I
just
sort
of
wonder
these
various
things
that
can
be
done
incrementally,
which
are
all
steps
and
the
clear
improvements
and
things
like
that.
It
seems
to
me
they.
They
tend
to
necessarily
be
a
little
bit
of
a
compromise
with
what
you
would
like
to
do.
If
you
had
a
clean
slate
and
a
little
more
complicated
and
we
interact
more
than
they
should,
with
other
other
features
and
other
potential
additions.
I
I
So
to
speak,
and
you
know
some
speakers
would
to
speak
one
of
the
old
and
one
some
would
speak
the
new
and
I
think
you
can
you
can
manage
that
because
otherwise,
you
have
some
speakers
speak
the
old
and
some
speakers
also
speak
chain
delta,
one
to
the
old
and
some
speakers
also
speak
delta.
Two
to
the
old
and
some
speakers
also
speak
delta,
three
to
the
old
and
that's
actually
worse
than
some
just
speak.
The
old
and
some
speak
the
new
in
some
ways
and
yeah.
I
guess
going
on
a
little
bit
further.
I
I
think
that
it's
interesting
to
hear
what
everybody
thinks.
I
will
welcome
comments
from
everybody
else,
but
I
I
think
probably
we
need
to
have
some
some
crafts,
so
it's
going
to
say
competing
grass.
They
don't
have
to
be
cool
cooperative
drafts.
Whatever
I
don't
know,
we
need
multiple
graphs.
I
think
that
can
be
kind
of
you
know
put
together
after
discussion
or
pieces
from
each
or
whatever
to
to
really
end
up
with
a
conclusion
for
this.
I
I
B
B
Do
the
operators
really
want
a
v2
that
skips
or
do
they
want
to
just
roll
things
forward,
and
so
we
were
hoping
we'd
get
comments
from
implementers
from
operators
on
what
made
sense
you
know
the
the
adage
in
in
would
work
is
measured
twice
cut
once
I
think
that's
what
we're
asking
is
we're
about
to
undertake
this
work.
Is
it?
B
A
So
donald
took
himself
out
of
the
micro
funk
you
but
respond
to
you
donald
one
of
the
things
that
this
conversation
is
partially
about
is
exactly
what
you're
talking
about.
Do
we
go
for
clean
slate?
No
second
saffy
take
all
the
good
ideas
that
we
had
and
enable
things
to
go
more
radical
or
do
we
you
know
just
creep
ahead.
You
know
one
incremental
feature
at
a
time
and
I
think
that's
a
fair
question.
That's
no
big
portion
of
what
we're
trying
to
motivate
when
we
originally
did
the
v2
draft.
A
We
knew
that
minimally.
That
term
ordering
was
the
thing
that
we
really
wanted,
that
just
simply
couldn't
be
done
in
the
existing
mechanism
and
well
we
have
a
possible
option
for
it.
At
the
very
least
one
of
the
other
things
I
think
you
know,
impacts
everybody.
You
know
so
like
spec,
nvo3
and
l2vpn
as
examples.
A
A
A
I
I
think
the
comment
I
would
lead
with
is
that
bgp
has
been
at
bgb4
for
some
number
of
years,
because
you
know
we
found
useful
and
clever
ways
to
incrementally
expand
things
without
having
to
do
forklift,
upgrades
and
stuff
we're
going
to
run
into.
I
think
the
incremental
deployment
problem
is
really
the
use
case
that
sort
of
settles
us
one
way
or
the
other.
B
One
of
the
things
donald
and
huevo
and
christoph-
and
I
hope,
jim's
listening
to
us
as
well
and
other
folks.
The
real
question
is
whether
you
know
should
we
do
a
clean
state.
We
initially
said
two
years
ago.
We
do
a
clean
slate
and
we
thought
it'd
come
right
after
if
you,
if
you
really
can't
decide
yet
if,
if
jeff's
strawmen
proposals
that
he
put
in
there
are
not
enough
to
convince
you
one
way
or
the
other
will
gladly
take
proposals
on
both
sides
of
the
flow
spec
v2
versus
v1.
A
Implementers
and
I
think
one
of
the
conversations
we're
also
going
to
be
having
as
part
of
this
and
it.
Let
me
attempt
to
you
know
fairly
channel
one
of
robert
roushik's
comments.
You
know
he
he
really
wants
all
this
stuff
to
be
done
in
the
flow
spec.
V2
he's
not
terribly
forthcoming
about.
You
know
a
lot
of
his
motivations
for
why,
but
I
think
to
sort
of
fairly
summarize
at
least
one
of
his
positions
is
what
we
have
works:
fine,
don't
break
it.
A
A
I
try
to
make
sure
that,
as
part
of
the
capability
bits
that
we
discussed
at
least
one
portion
of
that
problem
and
part
of
the
discussion,
I
was
hoping
to
motivate
during
this
interim.
Was
you
know
what
really
changes
if
you
have
a
different
format
or
if
it's
in
the
same,
you
know
you
know
safy
that
just
happens
to
have
new
features.
A
A
B
B
B
B
A
F
Say
it's
actually.
What
we're
using
here
in
the
network
is
basically
basically
that
rate
limit
of
weight
limit
to
some
some
diff
to
some
specific
rate
until
yeah
this
card
completely
assigned
to
a
different
quality
of
service
queue
like
is
it
called?
I
don't
remember
the
name
for
this
action
and
third
thing
is:
send
the
traffic
off
into
a
different
vrf.
Basically,
it's
the
three
actions.
Basically,
isn't
that
all
of
them?
No
there's
one
more.
I
think,
but
all
those
actions
can
inter-operate
without
any
problem,
usually
because
it
doesn't
depend.
F
F
But
I
think
that
some
of
the
features
that
we
that,
like
that
that
are
out
there,
like
these
new
drafts,
that
are
they
don't
address
the
current
use
case,
which
is
mostly
ddos
mitigation,
so
maybe
winky.
We,
it
makes
sense
to
keep
flow
spec
version
one
somehow
in
place
and
use
flow.
Spec
v2
for
for
different
set
of
use
cases,
so
I
think
that
that
there
will
be
some
both
flow
spec.
B
A
H
Hello
first,
I
just
want
to
ask
you
the
questions
as
the
providers
I
have
discussed
the
most
tactically
action
is
this
card.
You
can
mark
the
sap
under
the
sip
this
this
three
I
have
discarded
when
the
credit
has
user
and
then
another
about
the
term
order.
As
I
as
we
that
some
some
providers
have
submitted
some
requirements
to
us,
we
want
to
the
term
order
to
to
order
the
rules
not
not
for
component
and
fraction
right
now,
and
also
I
have
saw
that
jeff
have
submitted
jobs
like
this.
B
E
Yep
got
very
little
to
add
other
than
plus
lots
to
what
christoph
said,
and
this
is
commonly
used
when
people
are
under
dos
and
they
want
to
send
stuff
to
scrubbers,
or
you
know,
sometimes
change
change
qos
so
that
important
stuff
gets
through
and
less
important
stuff.
Doesn't
so
not
a
particularly
useful
comment
other
than
plus
one.
G
G
We
can
hear
you
okay,
perfect.
So
sorry,
I
missed
your
callout
earlier,
so
I
I
just
want
to
say
two
things
here.
So
in
my
opinion,
we
still
doing
a
very
major
change
if,
regardless
of
how
we
proceed
with
changing
reversion
one
or
in
introducing
a
version
two,
and
while
it's
true
you
say,
if
we
adopt
the
capability
bits,
we
can
do
it
in
relatively
safe
manner.
G
Some
of
the
p
devices
will
be
from
a
different
set
of
vendors
and
so
on
and
so
forth,
and
my
second
point
is
more
a
philosophical
one
is
basically,
we
introduce
a
second
version
of
flow
spec
regardless
because
just
of
amount,
new
features
which
will
be
adopted
and
work
drafts
which
we
currently
have
in
queue.
It's
only
the
beginning
hand,
I'm
pretty
sure
a
lot
of
other
ideas
of
how
to
use
and
abuse
flows
back.
B
B
A
So
I'd
like
to
ask
further
detail
in
that
question,
based
on
how
you
responded
to
the
adoption
poll,
so
I
I
understand
the
distribution
point
for
passing
the
routes
through
a
route
reflector.
You
know
that
that's
probably
one
of
the
easiest
use
cases
for
flowspec
v2,
but
the
the
one
that
I
keep
work.
My
way
back
to
is
once
that's
been
dealt
with.
I,
your
larger
challenge
is
all
of
these
interactions,
with
new
features
based
on
inconsistent
support
within
a
flowspec
domain.
A
Yes,
so
we
we
understand
that
one
of
the
nice
things
about
a
flowspec
v2
is
that
its
route
reflector
clean
up
front
now,
so
it's
easy
to
deploy,
but
that's
a
mostly
a
minor
encoding
problem
once
that's
been
dealt
with.
The
bigger
problem
is
inconsistent,
feature
support
for
new
components
in
a
domain.
Did
you
have
any
thoughts
about
that?
How
does
flowspec
v2
make
that
piece
easier.
G
A
G
Yeah,
so
I'm
not
saying
the
format
which
was
proposed
earlier
definitely
solves
all
the
challenges
or
is
strictly
better
than
what
we
have
now.
I
just
want
my
my.
My
main
motivation
is
just
to
avoid
fuser
fragmentation.
This
version
one
and
we
already
have
plenty
of
fragmentation
between
different
supported
capabilities
and
for
some
operators.
It
was
a
major
pain
point
for
quite
a
while.
B
G
Well,
from
my
experience
from
what
I
have
seen
deployed
in
the
field,
where
were
two
kinds
of
issues,
the
first
kind
was
just
because
of
inconsistent
implementation
of
closed
battery,
one
on
different
platforms
in
different
vendors
and
the
first
pain
point
is
just
a
different
capabilities
in
terms
of
what
each
vendor
does
support
from
version
one.
So
even
the
basic
things
like
what
fields
can
you
use
in
the
filtering
it?
It's
not
consistent
across
different
ecosystems,.
A
B
Well
that
we
really
are
trying
to
listen
to
feedback
before
we
go
into
the
next
round
of
flows
back,
let
me
ask
for
one
out
of
one
one:
is
there
anything
based
on
your
background
that
our
problems
that
we
haven't
addressed
with
the
three
variants
of
flow
spec?
We
put
forward
to
the
isg,
the
oid,
the
v6
and
the.
B
A
F
Well,
I
I
wonder
if,
because
I
was
thinking
about
this,
this
use
cases
currently
we
do
have
this
ipv4
ipv6
ddos
mitigation
use
case,
either
in
in
in
like
in
the
in
a
global
routing
table
or
in
vrf
most
of
the
drafts.
If
I'm
through
those
drafts
are
addressed
in
like
different
use,
cases
like
l2,
vpn
and
vxlan.
I
F
F
So
if
we
get
like
some
explicit
term
ordering-
and
we
may
not
need
any
any
other
additional
match
types,
so
is
it
fair
to
say
we
can
use
flow
spec
v2,
maybe
for
for
new
use
cases
and
keep
these
flow
spec
version,
one
as
it
is
in
place
and
add.
Maybe
some
minor
features
that
are
needed
without
breaking
the,
as
as
robert
suggested,
without
breaking
too
much.
B
That
is
a
potential.
That's
the
feedback,
that's
the
feedback
that
we
can
specifically
ask
to
the
working
group
both
on
the
list
and
at
the
next
itf.
We
were
trying.
This
term
was
to
just
provide
an
open
door
for
people
to
to
have
long
discussions,
as
you
all
realize,
once
we
get
to
an
itf
with
the
vertical
its
our
time
is
very
limited,
so
that's
a
possibility
and
jeff.
I
guess
we'll
take
an
action
item
to
ask
that
question
to
the
list.
B
D
D
You
can
hear
me
now:
jeff
we
can
okay.
Thank
you.
Yeah.
Sorry,
earlier
I
had
two
levels
of
un
muting
and
I
had
to
do
two
levels
of
unmuting
and
I
forgot
one
of
them.
So
thanks
for
the
question
sue,
I
I
think
you're
referring
to
the
nist
security
recommendations,
that
special
publication
800-189
that
I
and
doug
montgomery
wrote
about
a
year
and
a
half
back,
and
at
that
time
we
included
some
of
the
security
recommendations
there
that
make
use
of
flowspec
for
ddos
mitigation.
D
So
since
then
we
I
have
not
gone
back
to
that
draft
to
update
it.
We
we
will
update
it
periodically
once
every
maybe
two
or
three
years,
but
and
also
I
need
to
catch
up
on
lots
of
things
related
to
flowspec
the
more
recent
developments.
So
yes,
I
do
not
have
anything
new
to
add
there.
With
regard
to
your
question
about
the
security
considerations,
but
I'll
keep
my
eyes
open.
A
D
A
That's
still
a
thing
to
be
addressed,
although,
as
we
sort
of
work
through
the
discussion
points
about
the
current
actions
that
people
actually
make
use
of,
we
don't
really
have
a
very
large
number
of
these
things.
Although
I
think
that
the
you
know
the
nvo3
and
l2vpn
use
cases
motivate
things,
I
think
a
little
bit
differently.
So
as
an
example,
I
know
this
is
a
place
where
donald,
I
think
can
supply
us
with
a
little
bit
of
thinking.
A
So
while
I
don't
personally
expect
to
see
a
large
number
of
additional
new
actions
show
up,
because
these
are
things
that
would
need
to
be
widely
supported
in
terms
of
firewall
functionality,
I
think
those
documents
do
make
some
suggestions
that
we're
going
to
start
seeing.
You
know
further
interactions
with
you
know,
even
those
base
functionalities
as
an
example.
A
A
D
A
Thanks
so
I
do
want
to
come
back
to
kristoff's
point
taking
taking
the
perspective
that
we're
trying
to
keep
flow,
spec
v1
effectively
focused
on
the
ddos.
You
know
cases
and
maybe
not
worry
about
anything,
that's
a
fancy
use
case
and
we
don't
have
a
huge
number
of
documents
that
have
been
proposing
additional
features.
A
As
an
example,
I've
seen
you
know,
juniper
has
one
specifically
for
interacting
with
firewall
matching
based
on
payload,
regular
expressions.
Now
this
is
a
common
feature
implemented
by
certain
types
of
ddos
mitigation
tunnel.
Endpoint
devices,
I've
seen
a
proposal
for
interaction
with
service
function,
chaining.
A
The
first
one
is
that
people
have
avoided
proposing
new
things,
because
we've
told
them
the
doors
are
locked
and
there's
no
way
for
them
to
do
things.
So
there
is
a
possibility
that
once
we
say
there
is
a
flowspec
v2
and
we
provide
some
well-thought-through
scenarios
about
how
they
can
interact
with
flowspec
v1.
A
A
A
A
A
B
B
B
B
J
F
A
J
C
And
just
regarding
to
what
you
mentioned,
that
there's
no
new
ways
being
proposed
for
using
closed
tech.
We
have
a
draft.
An
rtg
working
group
specify
a
new
way
of
using
flowspack
for
passing
the
policy
between
the
application
controller
to
the
ingress
of
connecting
to
the
5g
upf
upf
node.
And
I
just
want
to
point
that
out.
We
do
have
a
new
way
to
use.
C
You
know
what
maybe
you
will
propose
that
send
back
to
the
idea
working
group
mailing
list,
because,
right
now
it's
just
a
document
in
the
rtg
working
group.
We
have
multiple
ways
of
doing
the
same
thing
and
compare
them,
so
we
will
study
it
and
then
see
if
the
close
fact
one
is
v1
is
enough
or
not
so
put
up
on
the
main
list.
I
just
want
to
point
that
out.
A
B
The
distribution,
incomplete
distribution
in
the
route
reflector
and
I
thought
also
the
targeted
information
did.
Did
you
have
that
in
your
action
item?
That's
one
action
item.
The
other
action
item
is
to
query
the
working
group
for
use
cases
and
see
the
use
cases.
People
want
to
see
in
v1
and
v2
and
the
third
one
was
shuram
was
going
to
post
information
on
security
that
he
got
from
his
previous
research.
Those
are
the
three
things
I
had
as
far
as
things
we
needed
to
follow
up
with
we're
still.
B
B
B
B
B
So
the
interim
is
a
time
in
a
place
where,
if
you
have
a
draft
or
if
you
have
something
you
want
to
discuss
regarding
that
we're
going
to
talk
about
requirements,
but
if
you
think
a
draft
is
going
to
help
us
get
to
requirements
or
something
like
that,
go
ahead
and
at
least
send
it
to
the
chairs.
These
interims
are
our
only
place
to
do
a
lot,
lengthy
discussion,
since
when
we
get
to
the
itf
meetings,
our
time
is
very
limited
for
each
draft.
B
So
we're
going
to
try
to
get
the
discussion
into
these
points.
If
you
have
something
that
you'd
like
to
propose
for
the
interim,
go
ahead
and
send
the
idr
chairs
your
proposal
and
we'll
see
if
we
can
fit
it
in,
but
we're
trying
to
close
off
on
these
two
topics
topic,
one
from
this
interim
is
flow.
Spec
topic
two
from
interim
two
weeks
is
the
bgp
auto
configuration
and
we
thank
you
for
joining
us
care
or
jeff.
Any
final
comments.