►
From YouTube: IETF97-GROW-20161116-1110
Description
GROW meeting session at IETF97
2016/11/16 1110
D
F
G
E
D
G
B
H
Thank
you
very
much
for
closing
the
doors
slides,
all
right,
I'm
Chris.
This
is
Pete
your
regularly
scheduled,
grow
chair
people's
there's,
a
note,
well
I'm,
you've
seen
at
least
three
times
already
this
meeting,
not
this
particular
meeting,
but
this
week
here's
the
agenda.
Anybody
have
anything
else
they
want
to
add.
Yes,
b2p
rejects
PGP,
reject.
Okay,
we'll
add
that
into
the
list.
You
want
to
do
that
right
after
your
large
communities.
A
E
H
So
we
have
some
draft
status
stuff.
We
had
two
more
grow
filtering
and
leak.
Probable
detection
made
it
out
of
the
Q
into
RFC
state.
A
PG
PG
shet
is
the
perennial
waiting
on
references.
That's
fine,
rps,
elvia
I
think
this
is
status
from
last
time.
There
hasn't
been
an
update.
We
need
to
go
poke.
The
authors
for
that
bgb
reject
job
is
going
to
talk
about
I.
Think
he's
gonna
ask
for
one
group
last
call.
H
E
I
Yes,
it's
this
better.
Okay,
we've
noticed
that
over
the
years
there
have
been
many
BGP
implementations
that
have
different
behaviors
out
of
the
box.
When
you
configure
the
bare
minimum
to
bring
up
a
BGP
session,
for
instance
on
cisco
iOS.
All
that
is
required
is
that
you
put
in
a
neighbor
statement
defining
the
remote
AAS
and
that's
it,
and
then
the
session
comes
up,
and
by
default,
iOS
will
announce
everything
it
has
and
accept
anything
it
can
unbirth.
I
It
will
accept
anything
but
not
announced
on
juniper.
It
will
accept
anything
announce
anything
on
XR.
It
will
accept
nothing
and
announce
nothing
and
there's
all
these
different
behavior
isms
and
over
the
years
we've
discovered
that
it
is
highly
undesirable
to
to
be
promiscuous
when
you
set
up
the
session
instead
of
having
a
more
restrictive
approach.
So
this
is
where
the
reject
draft
originated
and
the
following
slide
shows
you.
What
reject
really
is.
I
This
is
it
all.
The
advice
is
that
by
default,
you
do
not
accept
any
routes
without
configured
policy
and
by
default
you
do
not
announce
routes
unless
explicitly
configured
to
do
so,
and
one
very
pragmatic
example
of
what
this
would
prevent
an
iOS.
If
you
copy
paste
a
snippet
of
config
and
you
don't
copy
paste
fast
enough,
the
session
can
already
be
up
before
the
session
is
protected,
with
configuration
in
modern
operating
systems.
I
Before
we
can
go
to
last
call,
they're
essentially
is
one
outstanding
question.
In
version
1
of
this
draft,
the
default
behavior
of
rejecting
anything.
If
there
is
no
policy
configured
apply
to
all
api's
and
subsequent
a
vis.
But
then
we
came
to
realize
that
this
may
or
may
not
be
the
desire.
The
what
we're
trying
to
achieve,
because
Jared
and
I
approached
this
from
an
Internet
routing
perspective.
I
Nokia
did
an
inventory
of
all
the
API
CF
today
and
it's
roughly
20
api's
and
Counting,
and
it
is.
It
is
really
a
question
to
the
working
group.
Should
this
restrictive
behavior
be
confined
to
the
fee
for
and
fee
6
unicast
address
families,
or
should
it
cover
anything
I
personally
think
that
reject
should
be
for
fee
6
and
fee
for
unicast
it's
easy
to
implement
and
it
aligns
with
some
of
the
implementations
out
there
and
if
we
have
hit
apply
to
any
address
family
that
exists
now
and
somewhere
in
the
future.
I
It
might
lead
to
complications
and
restrictions
on
innovation,
but
this
is
the
one
question
I
have
left
and
I
would
appreciate
feedback
from
the
working
group
either
now
at
the
microphone
or
on
the
mailing
list,
and
once
we
solve
this
question,
for
instance
by
reaffirming
that
the
current
version
that
specifies
v6
and
fee
for
unicast
sufficient,
then
we
can
move
to
last
call.
Thank
you.
J
J
I
I
For
me
personally,
a
motivation
to
have
this
document
published
is
that
at
least
going
forward.
We
have
something
to
reference
to,
as
this
is
the
desired
behavior
and
I
understand
that
implementations
that
are
no
longer
really
updated,
may
not
comply
with
it,
but
going
forward.
I
would
strongly
encourage
implementers
to
abide
to
this
document.
M
N
Jeff
has
I'm
strongly
sympathetic
with
this,
just
like
everybody
else
in
the
room,
but
just
like
Jacob.
No,
we
can't
change
the
core
default
behaviors,
because
people
rely
on
us
again,
because
this
is
pgp.
It's
used
lots
of
places,
but
if
it's
allowed
to
be
done
via
a
no
top
level,
knob
that
just
gets
configured
that's
great,
if
no
operators
care
to
find
some
way
to
get
the
people
who
are
actually
doing
this
off
for
packaging
on
things
to
get
a
knob
basically
enabled
in
a
given
package.
N
So,
for
example,
you
download
judo
state
by
default
then
you'd
get.
This
behavior
is
something
that
we
could
do
as
a
default,
but
our
generalized
packaging
system
right
now
does
not
vary
things
like
that,
so
we
would
not
be
able
to
comply
with
this
document.
If
the
existing
stands
in,
there
says
that
you
have,
you
cannot
have
a
knob.
It
just
cannot
be
done.
If
you
want
to
figure
out
some
way
to
change
that
behavior
we
can
go.
Then.
I
Of
course,
I'm
willing
to
discuss
it
and
I
would
also
like
to
make
it
clear
that,
in
the
discussion
that
how
we
ship
this
in
products
and
whether
we
agree
with
the
documents
as
it
is,
can
be
to
two
different
things
because,
for
instance,
Nokia
and
birth
have
committed
to
applying
to
this
behavior
and
they
their
approaches.
Just
the
next
major
release
and
we'll
put
it
in
the
release,
notes
and
I.
Guess
there
are
their
various
opinions
on
how
you
ship
this
to
to
customers
in
the
more
customers.
N
No,
my
general
observation
is
going
to
be
that
anything
that
is
a
broad
change
of
default.
Behavior
does
not
be.
This
is
going
to
be
this
class
of
problems,
and
you
will
have
to
find
some
note
thing
whether
its
packaging
or
some
other
behavior,
that
alters
n.
What
about
346?
Do
everything
I
think
this
should
be
done
by
everything.
Making
somebody
have
a
you
know,
allow
all
4l
three
VPN,
for
example,
seems
perfectly
reasonable,
but
again
this
is
partially
a
problem
as
I
as
I
put
in
a
different
presentation,
blast
radius.
N
O
General
in
cola
yeah,
it's
a
great
idea,
but
I
agree
with
previous
speakers.
That
migration
plan
should
be
considerate
right,
I,
do
not
suggest
putting
it
and
release
note
for
any
vendor
would
actually
help
a
lot.
So
migration
might
be
quite
painful
here
yeah.
So
it's
a
serious
problem
and
I
don't
think
we
should
decouple
the
discussion.
Yes,
it's
a
direction
we
should
go,
but
we
also
need
to
think
how
we're
going
to
get
there,
and
so
people
are
not
scared
and
not
break
internet
even
worse
by
migration.
L
This
comment
to
the
actual
question
about
the
v4
or
v6.
So
it
seems
to
me
that
if
you
wanted
to
cover
other
address
families,
then
you
would
also
cover
ibgp,
but
since
you're
limiting
this
use
case
very
narrowly
to
protecting
the
internet.
I
think
this
is
the
current
draft
is
totally
fine
as
it
is
to
just
cover
be
4
and
6
unicast.
On
the
point
from
the.
I
L
Applies
to
right
so
I
guess
what
I'm
saying
is
if
you
were
going
to
make
a
change
to
cover
their
address
families
that
change
I
think
would
have
to
be
coupled
with
actually
applying
this
for
ibgp
as
well.
So
I
would
go
either
way
but
I'm
perfectly
fine
with
the
draft.
Is
this
the
the
other
point
to
the
vendors?
I?
L
Guess
is
a
you
know:
anybody
who's
gone
through
12
0
to
12,
2
or
you
know,
xrd
exr
is
used
to
really
large
major
changes
and
it's
I
think
it's
kind
of
funny
that
developers
would
stand
here
and
say
they
won't
do
something.
If
it
gets
put
into
RFPs
and
rfis
by
operators,
then
they
will
do
it
so,
but
you
know
I
guess
I
would
say
people
should
use
their
money
to
motivate.
D
I
J
I
P
A
peel
off
work,
if
you
want
to
make
a
change,
but
why
don't?
Why?
Don't
you
make
it
be
eating
everything
that
has
built
in
you
have
to
know
what
it's
going
to
do
is
confusing
right.
So
if
it
actually
turned
off
all
AFIS,
if
it
had
turned
off
all
outgoing
and
incoming
announce
at
least
or
if
it
if
it
behaved
the
same
for
all
the
address
families,
I
think
that
is
better
and
then
the
only
thing
you
need
is
a
knob
that
says
for
this
address:
family
dude.
P
What
you
know
turn
on
everything
or
something.
But
but
you
don't
want
III,
think
it's
confusing
that
you
have
to
know
by
magic.
What
address
families
is
going
to
behave
different
from
other
address
families
right.
So,
if
you're
going
to
ask
for
a
change,
make
it
consistent,
which
is
the
one
you
have
at
the
bottom
right
and
then
it's
up
to
the
vendors
to
do
different
kind
of
implementation,
but
basically,
if
it
turns
off
all
the
others,
families,
and
then
there
is
a
0
turn
on
the
address
family
of
madonna's
or
whatever
right.
P
P
O
The
link
over
here,
I
agree,
sit
covering
every
scene
is
also
actually
simple
from
a
configuration
automation.
Point
of
view.
It
minimizes
the
chances
of
mistake
yet
so
now
I
have
another
logic
shall
I
applies
that
policy.
In
this
case,
oh
it's
going
to
be
fine
and
so
on.
So
just
a
consistent
behavior
is
better
I.
K
Just
like
to
echo,
are
you
Jared
much
from
NTT
I,
just
like
to
echo
Peters
comments
in
that
you
know,
we've
had
drafts
come
through
here
about
route,
leaks
and
other
things,
and
this
is
a
well-defined
problem.
This
is
a
well-defined
solution
for
the
problem
set
and
if
the
vendors
are
going
to
have
such
a
hard
time
listening
to
the
operators
on
that,
this
is
a
real
problem
and
this
needs
to
be
fixed.
I
L
Object,
if
you
don't
change
it
to
ibgp,
because
ebgp
is
used
in
a
number
of
applications
that
are
very
similar
within
the
AAS,
so
people
do
confeds
people
use
EBT,
p-labeled
unicast
within
them.
Selves,
so
I
expect
that
the
eb,
if
you're,
going
to
change
it
to
affect
other
address
families,
you've
introduced
a
whole
bunch
of
applications.
L
D
D
So
I'm
going
to
cut
you
all.
I
think
we
probably
need
a
little
bit
more
on
the
list,
but
I
think
it's,
this
relatively
small
issue
that
should
be
able
to
be
hashed
out
and
hopefully
in
a
matter
of
weeks,
but
I
would,
I
think
we
can
take
it
to
the
lists
based
off
the
input
unless
there's
some
strong
feeling,
Oh
Jeff.
N
D
G
G
D
Q
H
H
H
Sorry
so
in
in
the
eye,
dr
working
group,
over
the
last
several
weeks,
there's
been
a
long
say,
400
message,
discussion
with
a
bunch
of
folks
louder,
better
more
more
than
400.
Okay,
sorry
there's
been
a
very
long
discussion,
some
kind
of
anger
and
in
in
faffing
about
for
one
particular
issue
which
is
4-byte
asn
and
how
to
use
those.
If
you
have
also
have
a
community
structure
for
traffic
engineering
purposes
with
your
customers,
it
seemed
like,
during
this
conversation
at
least
in
the
eye
dr
world.
H
Somebody
forgot
there
was
there
might
be
a
set
of
requirements
from
network
operators
about
you
know,
tools
that
they
use
in
the
network
every
day
at
least
one
person
in
the
mailing
list
jared
said
it
looked
like.
Maybe
this
was
just
a
loss
requirement,
and
maybe
there
are
others,
so
I
think
grow
probably
is
the
place
that
should
say
here's
a
list
of
requirements
that
we
care
about
for
operating
a
network.
We
at
least
care
about
this
community's
thing.
H
I
couldn't
come
up
with
any
others
up
through
last
night
in
this
morning,
so
if,
if
I
think
part
of
the
thing
I'd
like
to
say
here
is
if
other
folks
have
things
that
they
believe
are
important,
it
would
be
good
to
hear
about
that,
either
on
the
mailing
list
or
at
the
mic
and
then
decide
what
we
want
to
do
about
this.
We
can
just
say
one
grow
person
says
you
know.
H
Maybe
we
don't
really
care
to
say
much
more
about
this,
we're
just
going
to
fight
this
out
every
time
or
will
inform
our
vendors.
You
know
through
our
nor
a
vendor
process
and
hope
that
that
gets
fed
back
into
IDR
in
some
fashion
to
keep
track
of
the
things
we
actually
care
about
to
operate.
The
network
I,
don't
actually
know
what
the
right
answer
is
so
I
was
hoping.
Somebody
else
would
stand
up
and
say:
think
yeah
so
should
grow.
Be.
Do
should
grow
care
about
this
at
all,
I
think.
I
Job
Snyder's
ntt
I
I
have
two
comments
about
two
communities.
When
the
transition
was
made
from
to
bite
a
essence
to
4-byte,
asn
I
think
the
either
an
incomplete
inventory
was
done,
which
parts
of
the
ecosystem
are
affected
by
death,
and
it
should
have
been
more
obvious
that
the
communities
were
constructed
to
two
bites
and
as
such
would
need
a
modification
of
sorts
and
another
risk
that
I've
seen
is
when
a
relatively
simple
idea
from
grow
goes
towards
IDR.
I
They
sometimes
suffer
from
feature
creep
and
where
what
we
wanted
was
a
simple
hammer,
but
we
end
up
with
the
Swiss
Army
knife
that
is
1
meter
wide
and
I've.
Seen
a
number
of
proposals
get
completely
out
of
hand,
so
it
if
grow
can
sometimes
put
the
brakes
on
things
where
we
forcefully
say:
stop,
stop
making
this
more
and
more
extendable
and
do
extensibility
inside
extensibility.
We
need
this
one
tool
make
one
tool
because
most
things
that
come
through
grow
are
centered
around.
We
need
one
feature
with
one
document
number.
I
So,
even
if
there
is
a
language
barrier,
we
can
communicate
with
each
other,
because
there's
only
one
way
to
solve
this
particular
interaction
between
you,
n,
my
network
and,
and
maybe
that
is
something
that
we
can
capture
in
a
statement
of
sorts
or
a
design
instruction.
That
extensibility
is
sometimes
not
what
we
need.
Okay,.
R
Hi
Bill
Fenner
arista
networks,
one
time
running
area
director,
maybe
when
some
of
these
things
should
have
been
looked
at,
I,
think
that,
rather
than
not
taking
things
into
account,
IDR
was
expecting
that
they
would
be
subsumed
by
other
work,
and
this
other
work
has
just
you
know,
taking
10
plus
years
and
not
completed,
and
that's
that's
more
optimism
than
anything
else.
I
think
like
it.
This
is
this,
is
you
know
a
straightforward
problem,
we're
going.
We
need
all
sorts
of
different
types
of
communities.
Let's
solve
all
those
problems
at
once.
R
H
Just
to
be
fair
right
that
the
4-byte
asn
says
that
there
is
this
use
case
for
sticking
for
by
day
s
into
communities,
and
that
will
be
handled
by
this
other
draft
called
I,
think
flexible
communities
which
essentially
says
zero
about
this
use
case.
So
I
think
at
the
time
people
said
great,
someone's
gonna
handle
this
I'll
walk
away
and
do
my
thing:
it's
not
super
important
right
now,
so
it's
okay
to
walk
away
and
do
my
thing,
but
then
later
on,
like
it
just
never
got
picked
up,
which
is
your
optimism.
Yes,.
R
S
Yeah
Jolie,
egli,
I
I,
think
there's
a
bit
of
this.
That
is
a
second
system
problem,
in
the
sense
that
we
have
this
system
multi
protocol
bgp,
which,
especially
in
the
interdomain
case,
is
actually
quite
successful
at
resisting
innovation,
and
that's
in
fact,
part
of
the
reason
it
still
works
is
because
people
are
action
unable
to
bolt
new
into
it
and.
S
So,
as
operators,
we
have
sort
of
a
practical
approach
to
that,
which
is
that
we
we
look
at
what
is
the
minimum
possible
necessary
thing
to
employ,
and
we
do
that.
But
there
is
a
vantage
point
where
notionally
these
things
are
extensible
and
so
any
debate
that
looks
at
the
system
as
though
it
is
relatively
flexible.
I
think
mrs.
an
understanding
of
how
it's
actually
employed
in
the
Internet
m
and
how
long
it
takes
to
make
changes
that
actually
have
substantive
impact.
S
T
Jeff.
Are
you
up
here
for
Jabbar
I?
Oh
sorry,
look.
It
was
operators
who
defined
this
for
by
crap
in
IDR.
So
are
you
just
confused
which
room
you're
standing
in
could
be?
This
has
been
a
long-standing
problem.
If
you
were
frustrated,
I
should
be
using
the
first
person-
plural.
I
guess
if
we
were
frustrated
by
not
doing
it
years
ago,
which
we
were
the
burden
is
on
us
for
not
having
done
it
years
ago.
This
is
a
load
of
crap.
U
K
acquittal
arcus,
I
think
4
x,
4
x,
ts,
was
standardized
a
while
back.
I
think
that
grow
can
really
help
is
when
idea
progresses
standards
like
for
by
a
s
they
can
proactively
look
into
it
and
say
what's
missing
from
a
deployment.
Standpoint
is
a
complete
solution,
and
if
we
could
do
that
collectively,
as
a
group
out
here,
we
would
have
done
a
large
or
reflects
whatever
that
was
five
years
back.
Okay,.
V
Jon's
glitter
eye
dr
co-chair
yeah,
so
everybody
who
said
everything
already
said
good
things
but
yeah.
If
in
an
ideal
world
we
you
know,
when
we
did
s4
bite,
we
would
have
done
a
gap
analysis
and
then
thought
through
everything
super
carefully
and
then
in,
like
oh
yeah,
there's,
obviously
this
this
deployment
case
that
will
need
to
be
fixed,
and
you
know,
and
and
therefore
we
know
that
we
need
to
have
this
on.
You
know
running
on
some
certain
deadlines.
In
reality.
V
You
know
everybody
is
bandwidth
constrained
and
we
sort
of
to
what
what
bill
said,
which
is
we,
you
know,
are
optimistic
and
figure.
Yeah
we've
got
something
in
the
hopper
and
it's
proceeding
as
long
as
you
know
as
fast
as
it
proceeds
and
no
will
definitely
get
there
as
soon
as
that
thing
actually
gets
shipped.
V
Just
if
you
were,
if
you
were
at
yesterday's
IDR
meeting,
you
realize
that
we're
pretty
much
using
all
of
our
bandwidth
already
for
discussion
and
you've.
We've
got
another
forum
here
for
discussion.
It
oh
and
one
further
point
on
that
is
for
better
or
for
worse,
IDR
gets
used
for
talking
about
Internet
routing,
and
it
gets
used
for
talking
about
all
that
other
weird
swiss
army
knife
stuff
that
BGP
is
also
used
for
so
our
bandwidth
is
divided
on
this
room
has
the
advantage
of
being
able
to
talk
only
about
Internet
routing,
so
yeah.
V
W
So
one
of
them
is
consigned
sue
hairs.
Thank
you.
It's
not
like
peter
hasn't
seen
me
a
few
years.
Im
sue
hairs
wall
way
in
this
hat,
IDR
co-chair
what
John
and
I
want
to
say,
I'm
sure,
there's
a
squatting
code
points
moment
in
jokes,
previous
slides.
If
you
need,
if
you
see
situations
where
the
administrative
wheel
for
I
Anna
or
for
code
points
needs
to
be
turned,
don't
be
shy.
Comes
here,
I
chairs,
John
and
I
really
will
deal
with
stuff
on
a
one-to-one
basis.
Don't
stand
on.
Don't
worry
about
process.
W
N
So
jeff
has
several
different
points.
First,
one
RFC
4893,
the
one
I
actually
did
for
my
de
esas
says
specified
in
RFC
1997,
the
the
these
two
octets
and
code
AS
number
quite
clearly.
This
would
not
work
for
bgp
speakers
that
use
for
octet
AAS
numbers
such
speaker
should
use
for
octet
AAS,
specific,
extended
communities
instead
so
the
boogeyman
of
flex,
and
why
communities
was
not
specifically
in
the
picture
and
being
one
of
the
people
that
had
the
clue
bat
applied
to
my
head
about
two
years
ago
about
hey
people
do
for
colon.
N
For
that
conversation
didn't
happen
until
in
the
grand
scheme
of
things
extremely
late,
because
it's
just
never
written
down
anywhere
is
it
was
in.
You
know
in
RFC
the
format
of
that
packets
been
cleared
for
years.
People
like
juniper
allow
you
to
configure
arbitrary
communities,
and
you
could
do
this
without
even
a
registered
code
point,
and
one
of
the
drafts
I
picked
up-
and
I
was
told
by
arbor
days-
was
to
try
to
get
a
code
point
specifically
around
for
carrying
around
for
by
generics.
N
But
again
the
clue
back
out
applied,
I
think,
was
John,
Key's,
Lee
and
finally
said:
hey,
there's
colon
for
on
the
right-hand
side
too.
We
can't
do
this
and
it
was
a
here.
Here's
what
this
could
look
like
it
went
into
wide,
since
that
was
the
current
generic
know,
Swiss
Army
knife
that
we
had
at
the
time
and
totally
agree.
It
was
the
wrong
Swiss
Army
knife,
because
that's
not
the
primary
purpose
for
that
feature.
Oh
so
it
got
bogged
down.
N
N
You
know
we
need
for
colon
for
for
parody,
for
1997,
to
hey
we're
going
to
extend
this
now
and
throw
an
extra
colon
for
on
top
of
that,
so
you
had
requirements
creep
no
already
in
that
sense,
so
there
wasn't
requirement
analysis
and
then
transmission.
It
was
boom
here.
So
no
physical
feature
influent.
This
thing,
dammit.
K
I'll
try
and
be
brief,
Jared
Monti,
ntt,
so
I.
I
think
that
one
of
one
of
the
lessons
that
I
learned
from
this
is
that
I
went
to
my
vendors
as
a
proxy
to
reach
the
eye,
dr
group
and
apparently
that
message
did
not
make
it
through
to
the
eye
dr
group
for
a
number
of
years,
and
that's
that's
a
frustration
that
I
carry
today
and
also
lesson
learned
from
this.
Is
we've
it's
not
as
if
the
operators
didn't
approach.
K
People
I,
remember
specifically
approaching
Jeff
personally
about
this
as
well
saying
we
have
this
problem,
we
need
this
fixed
and
it's
certainly
culminated
in
the
past
six
months.
I
you
know,
or
four
months
on
the
ID,
our
mailing
list,
basically
saying
no,
here's
the
clue.
Bat
like
we
have
to
address
this
now,
because
we've,
like
we've,
tried
for
years
to
address
this
directly
with
the
vendors
and
unfortunately
they
did
not
hear
the
message
and
understand
the
urgency
to
the
point
that
it
became
I.
K
P
This
may
be
competed
off
quick.
This
may
be
a
pretty
typical
Peter
comment,
but
I
think
it's
time
to
actually
start
some
work
in
the
IETF
for
the
IOR
tf4
somewhere
ought
to
do
look
at
what
are
we
going
to
replace
bgp
would
instead
of
starting
to
adding
and
adding,
because
it
looks
like
my
christmas
tree
where
I
was
trying
to
put
you
know:
50-pound
weights
instead
of
those
small
things
and
it's
about
to
fall
apart.
J
I
10
10
minutes,
and
on
that
note
I
would
like
to
present
to
you
a
draft
martin
smith
and
myself
have
been
working
on
called
large
communities
usage.
One
of
the
things
thatÃs
has
stood
out
from
IDR
discussions.
Is
that
there's
perceived
lack
of
clarity
on
how
these
communities
actually
are
used
by
operators,
and
if
we
look
at
the
1997
documents
which
specifies
classic
HP
communities,
it
is
accompanied
by
a
document
1998.
I
The
global
administrator
field
often
was
overloaded
by
using
a
private
asn
in
that
location,
simply
because
we
did
not
have
enough
space,
so
we
would
squat
on
the
private
a
sense.
Of
course.
This
is
not
ideal
because
in
cases
of
mergers
and
acquisitions,
or
where
you
have
multiple
suppliers
that
use
the
same
community
but
have
different,
meaning
that
the
thing
could
fall
apart
so
with
large
communities,
because
we
have
that
furred
field
that
defines
whose
name
space
this
is.
I
I
These
are
ideas
that
you
can
eat
a
copy
or
modify
or
ignore
the
design
pattern
that
we've
chosen
to
follow
is
where
we
separate
between
informational
communities
and
action
communities,
the
difference
kind
of
lays
in
the
intended
audience
as2
914
when
we
send
communities
to
our
adjacent
networks,
ninety-nine
percent
of
the
time
those
are
informational
communities
to
inform
the
other
network.
This
is
where
we
picked
up
the
route.
This
is
the
relation
with
the
entity
from
we
learned
the
routes.
This
is
the
you
name
it.
I
So
the
intended
audience
for
informational
communities
is
usually
the
downstream
networks
that
we'll
use
that
for
their
traffic
engineering
decisions,
then
the
other
aspect
that
we
have
is
action,
communities
and
action.
Communities
of
them
are
sent
by
downstream
networks
to
their
suppliers
to
inform
the
supplier
or
vendor
to
perform
a
non-default
action.
If
you
announce
a
route
to
entity
by
default,
it
will
have
no
ASP
path.
Prepend
a
by
default.
I
Another
effect
of
the
design
pattern
is
that
we
advocate
the
method
of
me
function,
parameter
with
me,
being
the
global
administrator,
the
the
AAS
number,
who
owns
the
namespace
function
being
a
number
that
refers
to
something
that
should
happen.
So,
for
instance,
a
function
could
be
prepend
twice
or
prepend
only
in
North,
America
or
only
prepend,
on
Sundays,
and
then
the
parameter
could
be
a
geographic
area
or
a
adjacent
ASM
or
something
else
again
we're
enough
not
forcing
anything
upon
you.
I
This
is
also
not
an
attempt
to
do
any
form
of
global
product
management,
so,
for
instance,
if
you
would
like
ntt
to
perform
certain
actions
when
certain
communities
are
sent,
this
document
is
not
the
place.
Talk
to
your
account
manager
and
I've
listed
a
number
of
examples
in
the
documents.
It's
not
finished
that
the
there
are
I
think
seven
functions
listed
at
this
point
in
the
document
and
I
think
we
can
collect
a
few
more
use.
I
S
Deal
with
the
fact
that
we
have
particular
intentions
and
we
would
like
to
have
those
abstracted
from
every
single
providers-
a
particular
idiosyncratic
way
of
interpreting
this.
The
proposal
here
is
actually
kind
of
a
radical
improvement
on
that,
because
the
only
thing
that
I
actually
have
to
have
in
the
rosetta
stone,
then
if
people
were
to
implement
this
widely,
is
the
proprietor
specific
intentions
which
is
the
bit
in
the
middle,
because
you
know
the
signaling
around
a
SN
is
now
kind
of
rigorously
specified,
so
I
actually
see.
This
is
like
a
huge
improvement.
S
Even
if
you
don't
standardize
the
intent
right,
I
mean
standardized.
Intense
would
be
great,
but
everybody
you
know,
has
their
own
different
way
of
doing
things,
and
some
people
have
some
kinds
of
intense
and
not,
and
those
are
not
universally
supported
right
for
business
reasons
or
whatever
right,
but
yeah
I
like
I.
Look
at
this
and
go
you
know,
that's
a
radical
improvement
as
a
consumer
and
I.
Think
it's
the
audience
for
this.
Signaling
is
not
actually
large
transit
providers.
I
mean
the
saying
where
you
learn
to
route
is
great.
D
P
X
So
this
talk
is
about
many
mystery
gum.
This
talk
is
about
you,
r
PF,
and
what
we
are
trying
to
achieve
here
is
that,
first
of
all,
like
many
of
us,
observe
that
you
are
PF
should
be
more.
You
big
ubiquitously
deployed
RFC
30,
a
bc
p38
bcp
84,
but
it
is,
it
is
not
so
one
of
the
things
we
are
trying
to
look
at
is
what
what
can
we
do?
Can
we
make
some
improvement?
So
you
are
you
RPF?
X
So
the
main
thing
is:
if
the
ISPs
have
less
of
a
concern
that
that
they
might
disrupt
service
for
their
customers
and
then
then
the
chances
are
that
they
may
actually
deployed
more
significantly.
So
thanks
for
all
the
discussions
over
the
last
week,
or
so
on,
the
list
I'd,
it's
been
very
useful
feedback.
X
The
in
terms
of
like
just
like
a
brief
run-through
of
what
you
are
PF
is
you
have
district
your
PF
we're
only
if
the
prefix
appoints
to
the
that
particular
interface
towards
that
customer.
Only
then
you
would
accept
a
data
packet
from
the
customer
with
with
the
source
address
in
that
prefix,
so
the
customer
has
to
have
announced
that
prefix
on
to
the
ISP
on
that
interface.
X
So
strict
you
as
a
result
of
that
it
doesn't
allow
flexibility.
Customer
may
have
other
prefixes
which
which
they
don't
announce
towards.
This
is
P,
so
those
other
prefixes
might
be
denied
when
a
data
package
shows
up
with
the
source
address
in
with
in
that
prefix
and
loose
your
PF
is:
is
there
it
minute,
you
would
use
it
as
a
last
resort?
It's
not
very
effective
and
it's
good
for
filtering
out
bogan
or
Martian
source
addresses.
Otherwise,
it's
not
very
useful
for
IP
address,
poofed
spoofing
now
feasible
path.
X
Your
PF
tries
to
do
a
I
link
between
those
two
and
in
infeasible
path.
You
are
not
only
looking
at
what
is
the
prefix
that
it
does.
The
does
the
prefix
route
point
to
that
interface
for
routing
in
the
fib,
but
you
are
also
looking
at.
Are
there
alternate
paths?
Did
the
customer
announced
the
another
prefix,
perhaps
perhaps
deep,
deep
rift
by
prepending
and
if
that
that
could
be
I
also
be
pointing
towards
the
same
interface
but
with
a
much
lower
priority?
So
in
that
case,
what
happens?
X
Is
it's
able
to
filter
the
in
a
more
logical
way,
so
multiple
prefixes
originate
from
the
customer
one
they
want.
They
want
the
traffic
to
come
there,
their
way
on
that
link
or
interface,
another
prefix.
They
deep
rift
it
but
still
feasible
path.
You
r
PF
allows
flexibility.
I
mean
has
logic
that
says.
Okay,
if
you
did
announce
a
prefix
towards
me,
even
if
it's
not
my
best
path,
I
would
still
allow
the
prefix
to
belong
to
that
source
address.
X
So
that's
feasible
paths
you
r
PF,
but
even
with
that,
the
ISPs
are
apprehensive
that
they
might
still
deny
a
traffic
with
legitimate
customer
source,
IP
addresses
and
particularly
when
you
have
multi-homing
and
asymmetric
routing.
So
the
question
is:
can
we
do
some
improvements
to
feasible
path?
You
r
PF,
and
that's
what
we
looked
at
and
the
goal
I
like,
like
I
said,
is
to
encourage
wider
deployment.
X
So
the
key
principles
of
the
enhanced,
your
feasible
path-
you
r
PF,
that
that
we
have
proposed
is
the
algorithm
can
be
roughly
described
as
in
these
four
steps.
First
of
all,
you
create
a
union
of
all
announced
prefixes
that
have
a
common
origin,
a
s
and
so
at
the
ISPs
routers.
In
the
eighth,
with
the
various
routers,
you
collect
all
the
prefixes
that
have
a
common
origin
areas
and
those
announcements
have
potentially
been
received
on
different
customer
or
peer
or
provider
interfaces.
X
Now
you
take
that
Union
and
and
include
that
that
entire
list,
the
Union
on
the
reverse,
pass
filter
tables
on
any
on
all
of
the
interfaces
on
which
one
or
more
of
those
prefixes
in
the
Union
were
announced.
So
this
makes
it
quite
a
bit
more
generalized
and
accurate
as
compared
to
the
conventional
feasible
path
you
r,
PF,
and
because
the
ISP
lasts
last
point
simply
says
that
the
ISP
might
choose
to
apply
step
3
across
customer
interface
is
only
now.
X
We
look
at
a
few
scenarios
and
the
first
one
pretty
straightforward,
simple
scenario:
two
prefixes
the
as1
may
originate
data
packets
from
either
network
p1
or
p2
towards
any
of
the
two
isps,
but
it
announces
only
p1
towards
a
s
one
and
only
p2,
towards
as2
and
in
this
case
clearly
strict.
You
r
PF,
fails
because
they're
the
data
packet
in
contain
a
source
address
in
p1
or
p2
feasible.
X
The
next
scenario
is
where,
in
this
case,
the
s1
is
announcing
prepended
a
deep
rift
prefixes
also,
so
it
has
to
a
prefix
s,
p1
p2
and
it
announces
both
of
them
towards
s2,
as
well
as
a
s3
and
will
be
like
a
deep
rift
for
traffic
engineering
purposes.
So
in
this
case,
feasible
path
you
RPF
works
of
and
I
mean
if
it
works.
If
something
else
happens
at
s1
s2
s3,
if
they
prefer
a
customer
route
at
s3,
let's
look
at
a
s2.
X
If
the
customer
route
is
preferred
at
as3,
then
s3
would
would
would
choose
p
1
as
well
as
p2,
that
I
received
from
a
s1
those
paths,
direct
paths,
and
it
would
announce
them
both
to
as2
in
this
case.
In
this
case,
if
a
data
packet
starts
off
at
a
s1
goes
through
s3
and
ends
up
at
as2.
On
that
peer-to-peer
link
between
a
s
3
and
s,
2
s
2
will
not
drop
that
data
packet
because
you
did
get
p1
as
well
as
p2
from
a
s3.
X
However,
if
a
s3
prefers
shorter,
shorter
path,
/
customer
route,
then
s3
is
not
announcing.
As3
prefers
a
s2s
path
towards
p1
and
it
is
not
announcing
p12
as2.
As
a
result,
the
data
packet
get
will
get
dropped
at
as2,
so
so
feasible
path.
It
depends
which
of
those
preferences
are
applied
at
at
the
s,
SS
2
or
a
SAS
3
I'll
lose
your
PF
works,
of
course,
but
again
not
desirable.
X
Enhanced
a
feasible
path
again
works
best
in
this
case
as
well,
a
little
bit
more
complex
scenario,
and
what
we
are
doing
here
is
what
we
are
looking
at.
Here
is
same
s.
One
has
two
prefixes
and-
and
it
is
in
this
case,
it
is
again
not
announcing
all
prefixes
towards
all
its
ISPs.
It's
selective
realloc
am
announcing
p1
towards
s2
and
p2
towards
as3.
X
So
if
you
work
it
out,
if
you
look
at
this
essentially
what
a
s4
does
with
with
enhanced
feasible
path,
let's
describe
that
a
little
bit
more
carefully
here
with
this
example.
So
in
enhanced,
feasible
path,
as4
looks
at
all
these
prefixes
coming
in
it
matches
the
as1,
so
they
have
a
common
origin
as1
and
now,
as
for
says,
okay,
I
can
now
apply
a
p1
as
well
as
p2
on
a
customer
interfaces
toward
as2
as
well
as
a
s3.
So
in
this
case
any
prefix.
X
The
data
can
can
have
any
source
address
in
any
of
these
prefixes
p1
or
p2,
and
they
will
not
be
blocked
at
a
s4
whether
they
come
in
through
those
t2p
interfaces
or
a
p2p
interface.
So
it
works
fully
to
appropriately
treat
the
traffic
in
a
fair
way
without
without
blocking
or
without
unnecessary
blocking.
X
So
one
thing
I
forgot
to
mention
is
I
mean
it
would
be
nice
when
Artie,
ki
and
origin
validation
takes
off,
and
in
that
case,
even
if
an
S
did
not
announce
prefix
that
it
owns,
but
it
has
a
role
for
it.
Then
the
ISP
can
look
up
the
rower
and
add
those
prefixes
to
the
list
in
the
reverse
pass
filter
and
that
will
certainly
make
the
reverse
pass
filter
a
lot
more
accurate.
D
D
U
U
X
X
Y
While
you
are
you
very
green
Akamai,
so
while
I'm
glad
you're
looking
at
this
I
think
you
need
to
take
the
work
and
step
back
a
few
steps
re-evaluate
the
assumptions
complete.
Where
does
unicast
RPF
strictmode
fits.
You
never
put
unicast
RPF
strict
more
than
a
hey
s
boundary.
Why
did
we
do
loose
check
because
loose
check
wasn't
about
doing
any
anti
spoofing?
It
was
a
reaction
tool.
Why
was
vrf
mode
created
because
a
lot
of
what
you're
asking
to
do
right
now
is
vrf
mode,
and
why
did
we
create
flows
back?
Y
So
you
have
to
put
this
work
within
that
context.
Ok,
step
back
and
then
also
realize
that
feasible
path
was
created
because
of
how
jtree
is
built
versus
how
Cisco
Seth
built
all
right.
So
you
got
to
go
back
to
the
original
history
of
how
these
particular
featurettes
evolved
based
off
of
the
vendor
implementations.
Ok,.