►
From YouTube: IETF94-GROW-20151106-1520.webm
Description
GROW meeting session at IETF94
2015/11/06 1520
B
B
B
B
B
A
Afternoon,
that's
right
to
mike's
hong
hua
konichiwa.
It
is
this.
Is
the
grow
meeting
in
ITF
94?
If
you're
not
supposed
to
be
in
grow
you're
in
the
wrong
room,
you
should
change
or
stay,
you
know
might
be
fun.
Somebody
can
kick
the
door
closed
in
the
back.
That'd
be
great,
we'll
be
ready
to
go
in
just
a
minute.
A
We
just
had
to
update
our
slides
quickly
in
the
meantime,
for
those
that
have
to
stand
up
and
use
the
mic,
could
we
do
us
a
favor
and
keep
the
mic
close
to
your
mouth
and
keep
the
mic
in
front
of
your
face
doing
this
is
not
helpful
to
people
in
the
road.
Also
doing
this,
it's
not
helpful
to
people
in
the
room.
Please
keep
it
close
to
your
face.
Thank
you.
B
A
Okay,
here
come
all
the
threats.
First,
oh
there
we
go
there.
We
go
well
full
screen.
There's
the
meeting.
Here's
job
note
well,
I'm
sure
you've
read
at
least
once
already
today.
So
on
we
go.
We
had
some
late
late
agenda,
bashing
edition
of
things
we
forgot
to
ask
for
earlier
right,
so
the
filtering
threats
draft
is
sent
off
for
publication.
The
error
handling
draft
there's
a
set
of
comments
between
Wes
and
the
author.
That
needs
to
be
dealt
with.
It
reviewed,
updated.
A
The
route
leak
problem
shriram
has
addressed
all,
but
the
last
comment
I
think
there's
one
hanging
comment
which
is
in
flight
and
questions
and
answers
are
going
back
and
forth.
So
we'll
have
that
squared
away
shortly
and
sent
off
for
publication.
The
gchat
draft
is
expired,
as
it
always
is,
but
it's
waiting
on
on
some
reference
documents.
A
Our
routing
policy
considerations
as
an
editor
q.
So
the
route,
server
operations
and
BMP
is
fighting
its
way
through
some
discussed
comments.
I
think
mostly
John's,
not
here
so
mostly
that
got
squared
away
I
think
there's
a
couple
of
little
knits
to
deal
with,
but
it
should
be
off
on
its
way
soon.
That's
it
all
right!
So
now
we
have
our
presenters,
the
first
of
which
is
Thomas
notes.
Oh
yeah,
oh
yeah.
We
need
somewhere
to
take
notice
holy
crap.
We
went
so
far
for
no
one
has
notes
and
no
one
has
a
jabber
stuff.
A
I
totally
forgot,
like
West
George.
You
said
that
BMP
was
moving
through
a
discussed
comment.
Has
their
actually
been
motion
after
your
ranti
thing?
Yeah
we
hit
ya.
So
we
we,
we
cornered,
John
cornered
me
in
the
meeting,
the
all
be
welcoming
meeting
thing
we
cornered
Stephen
Farrell
and
had
some
progress.
We've
had
a
couple
of
offline
comments
about
the
direction
for
for
Stephen
issue.
I.
Think
that
also
probably
will
clear
up
Kathleen's
and
then
the
last
one
is
to
deal
with
ben
woz
yang.
A
A
E
Work,
it's
not
on
I
help,
so
it's
better
holy
yeah,
so
good
go
to.
My
name
is
Thomas
King
and
I'm,
talking
about
black
coffee
to
be
committee
for
black
holing
and
this
joint
work
together
with
my
other
name
on
the
list
and
all
the
feedback
we
got
next
slide.
Sex
and
I
will
give
a
little
bit
more
context
and
usual
because
I
have
been
given
a
15
minute
slot.
E
So
let
me
quickly
describe
what
this
traffic
talk
about,
though,
if
we
have
two
networks,
network
MP
and
they
do
p
with
each
other
and
there's
a
massive
ddos
attack
attacking
network,
be
it
could
be.
Thank
you.
It
could
be
the
case,
but
the
link
that
is
used
for
in
the
connection
gets
congested
based
on
the
message.
Dealers
attack
and
also
resources
within
the
network
of
be
could
be
overloaded
version
2.
E
So
a
solution
to
that
it's
black
holing
and
that's
all
around
for
a
couple
of
years.
So
that's
nothing
new.
What
network
be
done
to
get
get
rid
of
the
message
she
does
attack
or
the
consequences
of
that
is.
It
could
amount
to
more
specific
black
hole,
announcement
to
network
a
witch
might
report
that
feature
and
then
Network
a
starts,
a
black
holes,
a
little
dot
here
and
all
the
traffic
to
the
to
the
to
the
black
hole.
E
Ip
prefix
is
click
hold,
which
means
the
link
gets
freed
up
and
the
internal
resources
within
network
be
as
well.
So
next
slide,
please!
So
now
we
are
coming
to
the
internet
craft
our
after
providing
some
context.
The
other
idea
was
that
we
looked
into
how
black
holing
could
be
triggered,
how
it's
implemented
at
different
places,
and
we
realized
I'm
actually
from
from
an
IXP
provider.
E
We
realize
that
in
the
XP
world
there
are
different
implementations
of
how
to
trigger
back
hole,
and
we
have
things
like
black
hole,
IP
addresses
and
that
are
used
in
the
next
hop
in
the
next
top
or
s.
Next
top
IP
address
in
the
p2p
an
ointment,
and
we
have
things
like
like
all
communities
that
differ
from
my
experience,
I
XP.
E
The
thing
is
that
lamb
of
this
black
hole
communities
also
come
from
the
policy
control
community
space
that
is
used
a
trot
of
us,
usually
that
are
marked,
which
is
which
is
sweat,
or
you
call
that,
let's
sync,
and
if
you
look
at
ISPs,
you
see
that
ice
PS
usually
use
black
hole
communities
to
trigger
a
black
hole,
but
they
use
usually
different
Becker
communities.
Of
that-
and
you
know
we
heard
from
our
from
our
customers
that
triggering
a
black
hole
is
really
cumbersome
and
difficult,
because
everybody
does
different.
E
We
saw
a
demand
to
to
come
up
with
a
commonly
agreed
way
of
triggering
a
black
hole
for
XP
is
a
nice
piece
at
the
same
time.
So
we
started
thinking
about
the
internet
traffic
so
next
slide,
please
so
actually
that
work
started
over
in
2014.
Probably
aware
of
that,
because
I
was
talking
about
that
a
little
bit
early
already
Utley.
E
But
that's
idea
to
go
to
yawn
and
ask,
and
all
that
number
we
had
this
presentation
and
also
panel
discussion
about
that
during
the
25th
heroics
form,
it's
really
a
little
bit
then,
a
year
ago,
and
after
that
we
worked
on
the
internet
draft
beginning
of
this
year.
We
well
know
submitting
the
internal
draft
to
the
crow
working
group.
There
was
a
discussion
queuing,
ITF
93,
and
there
are
two
requests
from
the
Oryx
and
crow
community,
which
you
know
I'm
always
the
same.
E
One
thing
was
that
we
should
not
only
focus
on
XP,
because
initial
trusts
covered
only
IXPs,
so
ISPs
should
be
added
as
well
and
we
should
be
more
specific
about
operations
and
how
the
second
could
be
handled.
So
we
worked
on
this
to
request.
I
will
talk
about
that
on
the
next
slide
and
two
weeks
ago,
through
the
27th
or
eggs
from
we
discussed
what
we
f
worked
a
farm
so
next
slide.
Please,
the
current
state
of
the
document
is
that
we
edit
eyes
peace
through
the
document
as
well.
E
E
There
we
added
three
parts:
one
was
about
local
scope,
so
no
advertise
no
export
should
be
added
to
black
hole
announcements.
We
also
looked
into
how
PHP
speaker
should
handle
incoming
black
hole,
IP
prefixes,
so
it
should
check
the
length
of
the
prefixes-
that's
not
too
large,
and
it
should
also
make
sure
that,
for
the
black
hole
announcement
is
that
this
is
the
most
specific
soil,
which
means
there's
also
a
larger
IP,
prefix
unannounced
and
we
look
into
the
ixp
world.
E
So
all
that
was
added
to
the
version.
One
of
the
internal
draft,
which
was
released
a
couple
of
months
ago,
and
I
am
called
not
aware
of
any
comment
or
requests
that
is
unresolved.
So
all
the
input
should
be
put
in
and
yeah.
Also,
we
ask
for
working
group
adoption,
which
was
actually
accepted
today,
so
thank
for
that
and
yeah
next
slide
please.
So
we
are
looking
for
more
feedback
comments
and,
of
course,
questions
and
please
provide
us
some
insights
into
what
think
about
the
count
trot.
Oh,
that's
pretty
much.
It.
C
F
Hi
there
so
I'm
here
to
talk
about
a
serious
okay.
It's
just
work
a
bit
better
yeah
so
here
to
talk
about
the
draft
that
I
wrote
a
couple
of
weeks
ago,
posted
it
to
the
girl
list,
see
if
I
get
any
feedback
slightly
long
and
convoluted
name
can
probably
do
with
being
shortened
a
little
bit,
but
they
go.
This
is.
F
Do
this
right
so
a
little
bit
of
background
in
the
ivr
group
they're,
currently
working
on
the
specification
of
advertising
additional
paths
in
BGP,
so
that
the
BJP
speaker
can
announce
more
than
just
their
best
path
to
a
neighbor.
They
can
announce
multiple
paths
for
the
same
prefix
without
replacing
the
previous
ones.
F
Now
the
way
they've
done
that
is
they've
altered
the
nlr
I
encoding
on
bgp
message,
and
the
interpretation
of
that
is
now
subject
to
some
new
bgp
capabilities
and
so
all
of
the
prefixes.
If
I
now
have
beforehand,
they
were
just
a
prefix
length
and
then
the
prefix
itself
now
they've
added
a
4-byte
path,
identifier
on
to
every
prefix.
At
this
end,
in
order
for
the
receiving
rotor
to
discriminate
between
them,
mainly
so
that
they
can
then
tell
when
there's
then
withdraw
for
the
same
prefix,
which
path
it's
referring
to
now.
F
One
of
the
things
with
that
is
that,
in
order
for
a
BGP
receiver
to
actually
be
able
to
parse
it,
they
need
to
know
how
many
bytes
to
expect
and
that's
something
that's
available
to
the
BGP
speaker
because
of
the
communities.
Sorry,
the
capabilities
that
were
negotiated
at
the
end,
the
session
now
there
are.
F
F
F
That
information
is
in
the
open
message,
but
Mr
T
messages
are
standalone.
They,
you
may
have
an
mrt
message
for
a
message
that
was
received
several
weeks
after
the
session
originally
came
up.
So
in
order
to
preserve
this
new
information
and
to
tell
our
sir,
how
to
how
many
bytes
it
should
read
what
we
were
doing,
what
we're
saying,
you're
here
next
level,
there's
tight
codes
in
the
mrt
specification
which
are
used
to
carry
semantics
to
our
sir
there's
a
couple
of
examples
of
that.
F
One
of
them
is
used
to
indicate
whether
the
message
was
a
sent
message
or
a
received
message
and
another
one
is
to
indicate
whether
there's
a
s4
or
nes
two
paths
in
message,
because
they
redefine
the
existing
a
s
attribute
for
s4
rather
than
creating
a
new
one.
And
you
need
that
information
in
artist
know
how
to
parse
it.
F
F
What
this
proposal
was
is
to
add
new
type
codes,
that
signal
to
the
MRT
parser
and
how
many
bytes
it
should
read
in
the
nlr
I.
Basically,
so
what
we've
done
is
replicated
all
the
existing
type
codes.
Sorry
subtype
codes
for
a
s4
and
non
es
for
local
AAS
for
local
and
added
an
additional
path
version
of
it.
That's
basically
just
there
to
tell
the
parser
how
many
bytes
it
should
expect.
F
There's
ones
for
both
the
received
update
messages
and
also
for
the
BGP
routing
table
dumps
in
the
table
dumpy
to
as
type
again
it
just
redefines.
All
the
existing
ones
at
adds
new
sub
types
that
are
basically
the
same
as
the
previous
one,
but
they
tell
you
you
should
expect
this
number
of
bytes
in
the
message,
and
so
that's
basically
it
wrote
this
as
a
draft
proposed.
It
allows
you
to
then
store
the
additional
path
data
within
an
mrt
file.
B
F
That's
pretty
much,
it
I
think
it
seemed
like
a
sensible
and
off
draft
and
be
interested
there's
any
feedback
or
comments,
or
anything
like
that
or
if
anyone's
interested
in
working
on
the
document
co-author,
whether
anyone
wants
to
adopt
it.
If
anyone
hasn't
had
a
read
at
it,
please
have
read
and
provide
feedback
on
the
list.
F
So
at
the
moment
so
I'm
one
of
the
cool
maintain
errs
of
the
BGP
dump
software,
and
this
kinda
came
about
from
you
looking
at
the
additional
path
spec
and
then
seeing
whether
this
weather
btp
dump
could
handle
it
and
it
couldn't
because
of
this,
it's
with
the
way
I've
done
it
here.
It's
pretty
trivial
to
add,
and
I
can
add,
support
it
in
the
bgp
dump
crashing
library
producing
the
data
is
implementation-specific
depending
on
is
a
kwaka
or
a
bird
or
whatever.
Yet.
E
C
G
G
In
order
to
configure
a
BGP
session,
you
type
in
router
bgp
and
then
neighbor
12345,
remote
as6
or
whatever
I'm
press
return,
and
then
the
bgp
finite
state
machine
starts
running
before
you
have
a
chance
to
actually
go
in
and
configure
any
policy,
most
most
vendors.
There's
already.
You
know
more
than
one
vendor.
That
has
an
implementation
that
has
this
in
there
by
default,
and
so
this
is
really
documenting.
It
I
see
this
as
a
security
issue.
You
can
tell
because
the
iOS
XR
configuration
knob.
G
It
says
you
know
in
order
to
disable
this
built-in
safety
check
you
type
in
BGP,
unsafe,
ebgp
policy
command,
which
is
I,
think
a
very
clear
acknowledgement
of
you
know
the
the
issues
with
this.
These
are
real
life
issues
that
exist
that
are
observable
through
serums
draft,
a
Sri
Rama's
draft
as
well
of
all
the
routing
leaks,
and
this
contributes
to
the
damage
that
you
see
out
there
on
the
on
the
internet
next
slide
and
so
I
mean.
Basically
you
know,
I
received
some
input.
G
You
know
from
people
on
the
mailing
list,
I
haven't
solicited,
grow
yet
I,
don't
think,
and
so
I'm
here
to
solicit
input
from
people
in
the
room,
as
well
as
send
out
a
message
on
the
list
so
I'm
here
to
take
your
complaints
and
bullets
and
shots
at
you
know
this
draft
or
any
ideas
around
improving.
It
can.
A
G
I
have
an
interest
just
personally
conceptually
that
I
I
think
that
it
should
perhaps
be
an
eye,
dr
that's
my
own
personal
bias
and
thought,
because
this
is
really
something
that
you
know
the
implementers
need
to
know
about
who
are
going
in
writing
stuff.
But
I
am
not
an
expert
in
the
whole
IETF
regime,
believe
it
or
not,
and
so
if
it
belongs
and
grow,
then
I
would
be
happy
to
have
it
find
a
home
and
grow
as
well.
G
D
D
D
It
just
irritates
the
crap
out
of
me
because
I
think
that
when
you
have
a
router
and
it's
got
connected
interfaces
and
you
have
prefixes
attached
to
those
connected
interfaces,
that
those
connected
interfaces
should
get
put
into
and
be
accepted
by
the
BGP
process
state
machine
as
soon
as
it
starts
propagating
that
sure,
but
connected
routes,
you
shouldn't
have
to
configure
them
in
my
personal
world
view.
However,
that
creates
a
level
of
inconsistency,
because
connected
routes
then
become
special.
So
if
you
want
to
treat
everything
in
a
consistent
manner,
this
probably
makes
sense.
B
G
So
so
this
is
jared
responding.
I
absolutely
agree
with
wet
with
the
premise
that
you're
being
inconsistent,
because
I'm
not
talking
about
what
you
do
inside
of
your
igp,
I'm
talking
about
what
you
do
external
and
that
you
should,
in
order
to
speak
externally
to
an
upstream
appear
or
someone
else
that
you
should
have
to
configure
an
explicit
policy
I,
don't
you
know
that
policy
is
permit
all
so
right
now
so
hold.
D
D
B
H
H
Lydia
touch
telecom,
well,
ok,
looks
fine
with
me,
and
I
was
happy
that
one
of
him
more
recent
platforms
that
I'm
working
with
actually
got
it
right
on
the
other
end,
of
course,
there's
a
question.
What
other
advice
do
implement
us
actually
need
to
venereal
at
while?
Okay
doing
the
transitive
definition
of
true
of
attributes
in
BGP
actually
works?
Well,
if
you
have
to
act
explicitly
say
we
want
to
send
at
your
communities
I.
B
Rick
Tyler,
I'm
I'm
I'm
sort
of
a
wanderer
into
this
group.
This
isn't
my
normal
thing
to
do,
but
I
have
a
spare
space
in
my
slot.
What
concerns
me
about
this
is
you
seem
to
be
putting
mitigation
advice
for
some
implementations
who
have
bgp
software
that
works
in
this
way.
Is
this
really
I
ETF
business.
F
G
B
A
A
That's
perfectly
fine
for
grow
to
say
I
mean
grow
may
decide
that
the
Jared's
totally
crazy
and
in
toss
out
his
idea
or
not,
I
mean
I
think
it's
it's
something
here,
but
but
overall
be
the
purpose
of
growing
to
say
this
is
working
properly
or
we
could
use
some
improvement
in
this
way,
because
this
makes
the
operation
of
the
network
hard.
Okay,.
C
Can
I
have
a
show
of
hands
who
believe
this
should
be
a
working
group
document
and
anybody
who
Bill
feels
it
does?
It
should
not
be
a
working
group
document?
Okay,
so
we
have
some
strong
support.
Take
it
to
the
list
does
seem
like
there's,
probably
more
discussion
to
to
hash
out
the
issues
and
scope
and
go
from
there.
Thank
you
anything
else.
Oh
ok,
that's
it
for
our
agenda
today.
I
guess
we
will
see
you
in.
Is
it
Buenos
Aires
all
right
have
a
good
good
day.