►
From YouTube: IETF92-GROW-20150325-1520
Description
GROW meeting session at IETF92
2015/03/25 1520
A
Good
afternoon
happy
Wednesday
afternoon
to
you
this
is
the
grow
leading
at
IETF
92.
If
you
think
you're
in
a
different
meeting,
you
should
leave
if
you'd
like
to
stay
for
grow.
That's
great
too
we're
gonna
get
started
in
just
a
minute.
There's
blue
sheets
going
around.
Please
take
the
time
to
sign
the
blue
sheets.
Do
it
three
times,
so
we
get
a
bigger
room
next
time.
No,
don't
just
once
is
fine.
A
We
have
four
presentations
a
little
bit
update
about
current
drafts
and
things
in
progress
and
then
ever
to
be
able
to
go
home.
Well,
I
mean
back
to
wherever
you
were
before
here
all
right.
This!
Oh
sorry,
that's
the
note!
Well
slide.
It's
an
eye
chart
intentionally,
I'm
sure
you've
seen
it
several
times.
I
changed
one
word
in
there.
You
have
to
go,
find
it,
so
anybody
else
have
anything
to
add
to
the
agenda
going
once
going
twice:
okay,
good
quick
draft
status.
A
We
have
four
actually
I
think
there's
six
things
that
are
currently
flying
around
in
mid
process.
The
filtering
threats
was
updated
in
February,
I,
think
actually
maybe
yeah
februari,
the
air-handling
document
I
think
actually
Rob.
You
sent
a
update
for
this
in
recently,
or
is
it
yeah,
not
the
November
but
like
in
last
week
or
two
or
no
oh
gee?
We.
A
B
A
C
A
Peter
putted
last
call
in
for
the
growing
threats
last
night,
the
air-handling
document
was
refreshed
by
Rob
and
he's
looking
to
get
last
called
and
out
the
door.
Hopefully
after
this
meeting
provided
there's
no
substantial
comments.
I'm
like
today,
the
route
leak
problem
definition
shriram
had
an
update,
but
we
can
half
ago
and
he's
going
to
say
a
bunch
stuff
about
it
a
little
bit
later
today.
Thanks
then
there's
some
expired
stuff
grow,
bgp
shut.
I
think
that
this
might
actually
be
waiting
on
something
from
the
chairs.
A
I
have
to
talk
to
the
authors
and
unless
there's
one
of
them
around
the
grow,
RP
sale
via
also
expired,
and
so
did
the
leak
attack.
No
help
b.tech
note
bgp
sec,
no
help
that
expired
in
favor
of
shrooms
draft.
I
believe
so.
Unless
somebody
wants
to
argue
about
that,
we'll
leave
that
one
go
next,
there's
a
two
that
are
in
processing
the
route
policy
considerations
is
in
iesg
processing,
don't
remember
what
the
extech
exact
status
for
that
is,
and
then
the
route
server
operations
it's
in
the
editor
q.
A
D
D
E
E
So
the
motivation
is
that
the
we
are
saving
route
routing
table
in
route
of
use,
project
and
right
NECC,
mainly,
and
there
is
saved
as
a
file.
So
this
is
the
new
tool
to
read
those
routing
tables.
It
is
a
beneficial
if
we
analyze
those
full
routing
table
to
the
health
health
check
and
or
the
molded
in
the
future
round
table
shape.
E
So
as
an
ISP
I
belong
to.
That
is
all
I
wanted
to
know
that
how
we
are
doing
by
comparing
the
BGP
route
and
also
I
in
doing
so
I
wanted
to
modify
something
so
that
so
I
developed
it
from
the
scratch.
So
this
is
the
kind
of
you
know,
but
the
rube
dump
files,
how
we
save
them
like
the
this
is
the
Kota
and
target
AS
is
called
a
rod,
monitor
or
the
target
is
a
busy
Pacifica
is
called
Rob
monitor
and
we
call
it
as
appear
in
the
ripp
file.
E
So
there
is
a
DS
list
of
existing
tools,
but
I
created
a
new
one.
Yes,
and
it
meets
a
goal.
I
succeeded
the
support
the
GDP
so
that
we
can
read
the
right,
sorry
right,
real
file
as
well
in
using
this
tool.
So
what's
good
in
this
is
just
this
is
the
simple
example
of
the
simple
display
and
we
can.
We
have
a
partial
compatible
mode
with
the
zip
it
up.
E
E
If
we
specify
two
peers
and
if
the
route
is
the
prefix
is
only
found
in
the
left
beer,
then
it's
going
to
be
minus
sign
and
if
perfect's
is
only
the
right
side,
then
it's
going
to
be
plus
and
but
when
we
see
this
I'll
show
you
the
next
question
come
up
we'll
be
there
yeah.
We
don't
have
these
prefix
in
the
left.
Pier,
but
should
short
I
mean
should
shoulder
length.
Prefix
covers
this
range
so
that
it
locked
up
in
the
left
side
left
hands
pier.
E
E
My
tool
can
construct
the
routing
table
using
publish
yeah
and
like
if
we
are
specifying
pier,
19
and
look
up
for
one
address.
Then
it's
going
to
be
like
this
and
we
can
help
we
can
specify
as
a
file
like
the
file
contains
the
full
address.
Then
look
up
one
by
one,
then
some
of
the
prophets
address
is
not
found
in
the
relative.
E
So
what
we
can
do
is
now
we
can
compare
the
rich
ability
if
the
left-hand
side
Pierre
actually
blocks
the
readability
all
mode.
We
can
consult
so
I
extended.
The
marks
like
if
the
plus
is
appear,
then
it
is
reachable,
but
it's
only
in
the
right
Pierre
kind
of
like
that,
and
if
the
prefix
is
in
left
and
have
not
found
in
the
right
side,
then
it's
going
to
be.
E
E
E
Filtering
the
missing
missing
route,
like
the
left
side
left
hand.
Side
is
our
route
and
right
hand
is
older,
other
peers
that
is
existing
in
this
file.
So
the
this
is
to
compare
the
entity's
route
with
each
of
other
ISPs
rod.
That
is
what
I
wanted
to
do,
and
these
are
the
missing
in
the
entity.
The
prefix
missing
in
the
MTT
routing
table
like
the
there
was
kind
of
60
peers
in
the
file.
Some
of
them
were
empty,
but
the
38
of
those
peers
have
this
perfect,
but
the
entity
doesn't
have
so
it
might
be.
E
E
And
also
the
Sun,
as
for
the
voxel
t
in
from
Romania,
some
of
the
asian
network
doesn't
have
a
reach
ability
to
the
voxel
t,
even
though
the
NTDs
global
routing
table
have
it
because
they
set
the
community
tag
which
that
means
do
not
advertise
in
asia.
So
I'm
wondering
this
is
not
the
original
intention
of
that
vogue
city
itself
to
set
these
tags
not
to
provide
a
rich
ability
to
that
rgr
network.
So
we
might
need
to
contact
the
boxes.
These
operators
about
this.
E
And
there
are
some
other
nice
features
like.
If
we
are
concerning
about
the
number
of
roads
in
the
full
routing
table,
we
can
have
easily.
We
can
show
the
number
of
routes
in
many
rebel
files
like
if
we
are
specifying
multiple
files.
Then
it's
going
to
be
shown
like
this
one
line
per
rip
file,
so
that
and
timestamp
is
the
first
one-
and
this
is
the
pa1
disappear
to
disappear
three,
so
that
we
can
easily
create
this
kind
of
figure
like
this
is
a
ph
0.
This
is
a
PR
1
and
so
on.
No.
E
We
we
compare
the
two
rib
files
from
a
different
time
and
for
that
the
same
pier
we
compare
the
difference
of
the
distribution
in
prefix
length,
so
the
like
in
from
August
12
and
to
august
13
/
16
is
decreased,
47,
x,
47
and
/
23
increase
in
66.
This
is
like
that
and
yeah.
This
is
another
from
August
13
to
August
14.
E
E
E
This
is
the
implementation
issue
of
the
quagga
I
think,
but
if
we
are
searching
for
entity
in
the
file
for
ya,
this
is
the
output
from
the
three
rave
files.
One
is
the
2020
and
PR
20
and
pier
21
is
the
entity,
but
sometimes
21,
22
19
20.
So
in
this
case
it's
going
to
be
more
harder
to
create
those
minor
features
and
as
a
discussion,
the
first
line
is
the
the
same.
E
The
pier
number
is
changing
and
in
doing
the
full
route
rolling
table,
you
know
I
run
into
some
philosophical
question
like
what
is
the
BGP
routing
table,
even
in
one
isp,
there
is
a
version
of
depending
on
the
area
or
region.
So
maybe
the
common
set
of
the
a
mini
version
of
the
is
from
the
ISP
or
the
among
the
ISPs
might
be
interesting.
I
thought
in
the
random
thought
and.
E
E
This
is
good
what
this
is,
but
for
this
kind
of
thing
and
I
think
the
this
tool
is
already
contributing
in
some
sense,
like
we
triggered
us
for
our
specific
debugging
for
specific
routes
from
the
out
of
this
tool,
so
that
I
think
the
tool
is
already
10.
Official
I
think
features
to
be
added
is
like
really
regular
expression
in
a
spa
and
also
regular
expression,
possibly
on
next
ops.
This
is
suggested
by
mr.
E
E
E
D
D
Have
been
configured,
they
get
insert
the
the
numbering,
india
and
the
dump
files
is
always
sequential.
So
if
a
peer
is
down
or
one
who's
been
removed,
then
it's
going
to
reorder
itself.
Were
you
seeing
this
in
situations
where
the
same
number
of
peers
were
always
in
the
index
table?
Were
you
seeing
the
pier
move
around
with
the
same
set
of
peers,
I.
E
B
Since
then,
we've
kind
of
talked
through
a
bunch
those
requirements-
we've
talked
through
a
lot
in
IDR
we've
reached
a
point
of
consensus
around
the
set
of
drafts,
their
solutions,
but
still
we
haven't
managed
to
entirely
finish
off
the
requirements
draft
and
partially.
That's
me
and
partially.
That's
that's
the
fact
that
there's
been
a
lot
of
debate,
and
especially
some
of
the
debate,
has
been
around
implementation
issues
from
people
for
comment.
I.
She
build
build
the
features
so
next
slide.
B
B
When
we've
also
been
through
a
working
group,
last
call
we
went
into
ITF
last
call
for
this,
and
one
of
the
feedbacks
was
the
document
wasn't
very
clear,
so
I
see
since
then
have
also
done
a
complete
rewrite
of
the
document
to
make
it
a
lot
clearer
and
it
kind
of
suffered
somewhat
from.
We
had
a
bunch
of
ideas
and
then
we
wrote
those
down
and
then
they
had
got
added
to
and
taken
away
and
the
document
it
wasn't
necessarily
easily
consumable
anymore.
B
The
main
clarifications
were
mainly
thanks
to
Bruno
I
think,
which
is
around
defining
more
clearly
where
the
different
scopes
of
errors
that
we
we
had
we're
around
is
it
an
attribute.
Error
is
a
message,
level
error
as
a
session
level
error
and
then
I've
so
taken
those
and
linked
them
back
to
the
two
kinds
of
error,
handling
behaviors,
which
are
the
non-critical
and
critical
ones
that
we
we
had
before
next
slide.
Please,
the
other
thing
that
we
added
in
later
revisions
was
there's
some
debate
around.
B
What
should
an
operator
do
when
you
have
a
really
long
lived
error
that
you
can't
really
do
anything
about,
especially
when
it's
remote
to
you?
Do
you
just
live
with,
and
especially
when
that's
also
a
critical
error,
so
the
session
is
continually
being
torn
down,
so
we've
added
into
two
different
potential
solutions
that
there
seems
like
there's
some
operational
support
for
from
the
various
discussions.
B
One
is
the
longleaf
equation,
restart
which
was
called
persistence
before
and
then
the
other
is
a
method
of
last
resort
where
it
is
possible
to
say
I
know
that
there
is
a
problem
on
this
session.
I
can't
do
anything
about
it,
and
I
would
like
like
it
to
stay
up
as
a
as
a
knob
to
be
used
in
emergencies
such
that
you
can
at
least
retain
some
form
of
connectivity
when
something
can't
be
filtered
next
slide.
Please
so
I
think
I've
addressed
all
the
comments
that
there
were
further
06
version
in
the
or
7
version.
B
There's
one,
my
editorial
set
of
changes
that
need
to
be
made,
as
I
said
before,
we've
been
through
working
great
last
call
on
this
I
think,
there's
consensus
here.
If
I
were
to
call
it
could
sense
based
on
the
fact
that
no
one
really
shouts
in
more
which,
which
is
that
was
really
the
big
problem
before
so.
The
lack
of
shouting
I'm,
assuming
is
people
being
happier
out
than
people
not
caring
anymore,
and
if
that's
not
the
case,
then
I
would
like
to
be
corrected.
B
B
To
me
that
we
have
solutions
published
without
the
requirements
which
kind
of
motivated
them
necessarily
reaching
the
same
level
of
maturity.
So
if
you
don't
think
this
should
be
published,
then
I
would
really
like
its
shell
to
be
now.
If
you
think
this
should
be
problems,
I'd
also
like
you
to
shout,
when
does
it
last
call
so
that
we
can?
We
can
progress
it
so
I
think
this
is
some
good
output
for
this
working
there's
been
a
lot
of
input
to
this
document
from
a
lot
of
different
people.
B
C
Because
it
has
had
a
major
revision
and
not
many
people
re-reviewed
exciting.
They
agreed
with
the
original
one
and
the
organs,
probably
better
yeah
yeah,
Joel,
yay
glee,
yeah
I,
mean
I,
think
we'll
probably
try
and
get
some
early
feedback
from
well
I
shouldn't,
say
early
because
it
should
have
been
about
two
years
ago,
but
I
early
feedback
from
the
routing,
a
DS.
When
you
get
when
you
get
to
the
point
of
calling
it
a
working
group
last
call
so
that
we
can
get
square
with
the
other
sort
of
communities
of
interest
on
this.
C
Yeah
and
I
expect
you
to
do
the
routing
area
review
on
your
own
document
to,
but
you
know
we
will
cross
this
bridge
when
we
get
to
it,
but
I,
don't
think
it
will
be
a
huge
problem.
It's
just.
We
have
some
work
to
do
there
thanks
I,
think
yeah.
It
will
probably
put
it
out
for
last
call
and
see
make
sure
some
people
review
it
for
last
call
and
go
from
there.
Thank
you.
D
F
Okay,
so
let's
go
so.
This
talk
is
about
doing
some
time,
stamping
with
in
BGP.
So
this
is
a
work
that
we
started
in
idea,
so
the
first
version
was
presented
in
Toronto
and
I
was
presenting
yesterday,
some
updates,
but
I'm
pretty
convinced
that
I
at
least
some
part
of
this
work
is
really
kind
of
operations
of
of
PGP.
So
some
it's,
it's
really
important
to
present
it
here
also.
So
what
is
the
problem
that
we
are
targeting
to
solve?
F
Today?
We
are
sending
some
paths
within
the
BGP
control
planes,
and
sometimes
we
have
our
propagating
are
propagated
quite
quickly,
sometimes
not,
and
we
don't
have
any
machinery
that
is
able
to
monitor
this
kind
of
performance
of
the
BGP
control
plane.
So
what
we
are
trying
to
do
here
is
to
provide
some
kind
of
time,
stamping
within
the
BGP
control
plane
and
let
so
we
are
creating
sort
of
time
stamp
vector
with
in
BGP.
F
It
depends
on
shore
service,
for
example.
If
you
have
some
will
chicas
VPN,
you
need
to
send
something
to
be
able
to
join
the
tree
and
you
need
to
be
able
to
send
it
very
quickly.
This
is
a
well
of
a
use
case,
as
you
have
some
layer
free
VPN
and
you
are
relying
on
convergence
because
you
at
least
your
essay
is
not
too
much
critical,
so
you
can
rely
on
it.
F
Your
bgp
update
must
not
take
at
least
hours
or
minutes
to
be
received
by
the
receiver.
Node,
don't
smile,
it's
happening,
so
we
are
clearly
facing
some
issue
in
operational
networker
life
at
large
scale
with
bgp
propagation
time.
So
it
sounds
really
important
for
us
to
to
be
able
to
monetize
it's
becoming
more
and
more
critical,
because
we
are
more
and
more
services
that
are
using
bgp.
So
we
are
before
we
have
we
had
only
internet,
then
we
add
a
layer
free
VPN.
F
Now
we
are
doing
layer
to
VPN
VPN,
multicast
VPN,
using
bgp
and
from
an
operational
point
of
view
as
operator,
we
would
need
to
be
able
to
mix
all
of
them
in
the
same
boxes
for
capex
reason,
an
optimal
cost
optimization.
So
it's
really
important
to
to
ensure
that
by
mixing
this
all
is
still
working.
Fine,
because
all
the
different
services,
as
have
different
priorities
on
a
critical
some
are
less
critical.
So
we
need
some
tool
to
be
able
to
monitor.
F
Is
so
the
good
behavior
of
the
control
plane
next
slide
solve
the
requirements,
so
we
need
something
to
be
able
to
monitor
performance
in
term
of
I
would
say
orchestration.
I
will
need
something
that
is
really
simple:
I
don't
need
I,
don't
want
to
establish
multiple
session
to
each
bgp,
pier
and
then
try
to
correlate
information
by
okay.
I
know
my
topology
I
know
that
this
is
a
first-half.
Effectiveness
is
a
second
one.
So
this
one
need
to
receive
the
information
first
and
via
ye.
F
It's
really
complex
its
complex
within
an
IAS,
and
if
you
want
to
do
it
in
in
TI
es
nada,
it's
even
more
complex.
So
what
I
want
is
ok,
I'm
triggering
some
pub
at
the
point
of
a
network,
and
I
want
to
receive
the
informations
at
some
different
point
of
listening
and
then
being
able
to
analyze
what's
happening
in
the
past
propagation.
F
So
a
single
point
of
listening
is
something
that
is
sounds
really
important.
The
other
point
is
I
need
to,
as
I
said,
be
able
to
gather
information
about
what
is
happening
in
between
so
at
each
bgp
speaker
and
for
sure.
We
need
a
solution
that
is
quite
accurate
in
terms
of
being
able
to
measure
of
this
time.
Tempe
next
slide.
F
So
as
you
look
at
the
diagram
here,
so,
for
example,
see
one
is
sending
a
bgp
update
for
specific
prefix,
it's
adding
some
bgp
timestamp
information
and
then
each
speaker
in
between
so
originator.
On
the
listening
point,
we'll
add
a
subsequent
information
within
a
witch
in
the
vector
next
slide,
please
so
for
sure
the
scope
we
are
targeting
is
not
to
timestamp
everything,
at
least
in
my
opinion,
this
is
not
necessary.
F
So
we
want
social
solution,
is
retarget
to
to
be
done
on
some
very
specific
prefixes
that
really
a
send
on
which
one
and
something
sounds
too
to
be
a
good
solution
for
for
the
measurement.
So
next
slide.
So
for
sure
we
want
something
that
is
the
go
to
run
into
a
yes,
because,
for
example,
in
our
use
case
with
owning
multiple
a
a
season,
we
want
to
be
able
to
multiply
propagation
time
between
aces.
F
We
considered
some
kind
of
my.
If
I
don't
know,
if
I
can
say
with
security
issue,
but
sometimes
you
may
issue
are
talking
to
a
partner.
For
example,
you
don't
want
to
expose
your
internal
topology
on
your
internal
time
stamp,
so
we
are
providing
some
ability
to
drop
the
timestamp
information
or
aggregate
the
information
to
say.
Okay,
the
time
stamp
with
in
my
network
is
just
the
entry
point
and
the
last
point
on
you
are
hiding
something
all
that
is
in
between
so
since
something
that
we
are
currently
considering.
F
So,
depending
of
the
use
case,
it's
useful
or
not.
This
is
something
that
we
can.
We
can
discuss
next
slide,
please
so
the
next
step,
so
at
least
as
a
service
provider
wishing
that
is.
This
is
something
that
is
really
necessary
to
be
able
to
monitor
his
performance
in
term
of
solution.
We
are
proposing
a
solution.
F
Is
it
a
good
solution
or
not?
Service
is
something
that
we
can.
We
can
discuss
it,
maybe
some
some
pros
and
cons.
So
we
are
clearly
welcoming
your
feedback
about
this,
an
interim
of
work.
The
question
is:
do
we
still
need
to
continue
this
work
on
idea?
Only
do
we
need
to
own
at
least
maybe
the
problem
statement
and
requirements
in
this
working
loop
and
split
with
solution
and
encouraging?
Maybe
in
idea
personally
I
don't
care,
so
this
can
be
discussed.
F
E
F
G
F
C
D
H
I'm
straight
am
from
list,
so
the
problem
definition
document
in
Honolulu
be
presented
a
individual
draft
version
of
it
and,
subsequent
to
that
in
grow,
its
it's
been
accepted
as
a
working
group,
/
draft.
So
the
this
is
the
work
working
group
group
dropped
version
next
slide,
please
so
compared
to
the
previous
version,
the
diffs
are.
H
H
If
that
that
list
is
complete
or
something
could
still
be
added-
and
we
have
also
added
several
relevant
new
references
next
like
this,
so
we
had
types
1
through
5,
which
I
talked
about
and
described
in
Honolulu
and
since
then
56
and
57
odd,
new,
again
motivated
by
comments
from
Andrea
and
Brian
type
6.
We
can
I
guess
go
to
the
next
slide.
This
is
my
last
slide
just
to
give
you
what
is
new
in
the
in
the
new
version
of
the
draft
type.
6
is
a
leak
of
provided
prefixes
to
peer.
H
So
this
is
this
happens
when
an
offending
a
a
sleeker
prefix
routes
learned
from
its
parameter
provider,
to
lack
to
a
lateral,
peer
and
type
7,
is
a
leak
of
peer
prefixes
to
a
provider.
So
typically,
the
the
prefix
has
originated
from
a
customer.
Cone
goes
to
an
ISP
and
the
ISP
gives
it
to
appear
and
then
that
here
shouldn't
be
transmitting
it
upward
toward
towards
the
provider.
So
so
so
these
two
types
have
been
added
and
just
like,
we
had
real
real
world.
The
incident
examples
for
each
of
the
previous
five
types.
H
There
are
such
examples
for
these
as
well
so
type
6,
what
Jarrod
Mar
chops,
where
he
sees
three
ISPs
in
a
sequence
in
the
a
s
path.
So
some
of
those
are
type
6
kind
of
leaks
and
type
7.
If
you
take,
for
example,
the
dodo
Telstra
example,
the
prefixes
that
a
whole
bunch
of
thousands
or
hundreds
of
thousands
of
prefixes
that
dodo
passed
on
to
Telstra,
they
included
not
only
the
prefixes
that
we
had
learnt
from
providers,
but
also
from
from
peers.
H
So
if
you
have
I
mean
I'm
sure
there
can
be
other
definitions
of
route
leaks,
leaks
which
are
not
included
here,
but
we
thought
that
these
are
critical.
They
have
made
news
every
now
and
then-
and
so
so,
based
on
that
we
have
this
this
classification
for
now
and
if
you
have
feedback
that
to
add
to
this
or
I'll
make
any
improvements
in
the
draft.
Its
most
welcome.
H
H
H
H
I
H
G
H
G
If
the
actual
prefix
that's
being
announced
changes,
this
is
not
leaking
of
a
route
that
somewhere,
it
is
actually
many.
It's
actually
manufactured
and
well,
okay,
that
it
actually
copies
parts
and
modifies
parts
of
announcements
that
are
there.
Mm-Hmm
does
not
really
match
my
definition
of
League,
ok,.
H
Yeah
I
mean
that
could
be
malicious
leagues,
and
if,
if
you,
if
a
malicious
t
equal
to
happen,
you
could
modify,
you
could
pretend
that
the
whatever
come
in
here
you
could.
You
could
change
this
up
prefix
to
a
sub
prefix,
so
it
could
be
intentional
just
to
make
the
traffic
flow
through
your
a
as
in
which
case,
in
which
case
the
traffic
does
indeed
go
through
the
a
s.
So
it
has
the
same
effect
as
a
regular
leak
with
a
full
prefix.
So
so
you
could
have.
H
You
could
have
intentional
or
malicious
leaks,
and
that's
where
that's
where
the
sub
prefix
at
the
type
to
comes
in,
and
then
we
talked
about
the
prefix
hijacks
right
where
that
the
reverse
path
to
the
legitimate
destination
is
still
available.
As
so
there
again,
there
have
been
like
examples
like
Bell
dress
and
Iceland,
where
the
whole,
the
prefix
with
the
whole
path,
was
leaked.
Not
so
not
sure
it
was
hijacked,
but
then
in
China
Telecom
as
well.
So
it
was.
A
A
A
H
A
E
H
It
was
not
our
intention
to
try
and
capture
everything
that
somebody
may
think
of
as
a
route
leak,
but
we
looked
at
a
whole
bunch
of
incidents
in.
If
you
look
in
the
references
there
are
maybe
approaching
30
references
which,
which
talk
about
different
types
of
incidents
that
have
been
called
route
leaks,
and
so
we
looked
at
all
those.
And
then
we
try
to
come
up
with
categories
that
that
describe
those
my.
H
H
C
H
So
yesterday
we
presented
the
the
mitigation
detection
mitigation
draft
in
IDR,
and
so
so
the
solution
that
we
had
we
were
able
to
extend
it
to
tau
clicks
of
type
6
and
7
as
well.
So
that's
that's
the
status
of
the
things.
Please
do
let
us
know
I
mean
if
I
mean,
if
you
have
some,
if
you
feel
strongly
about
any
of
these
classification
put
it
will.
Please
send
us
a
message
for
posting,
an
email
on
the
list
and
we'll
be
happy
to
discuss
that.