►
From YouTube: IDR WG Interim Meeting, 2020-04-08
Description
IDR WG Interim Meeting, 2020-04-08
B
B
C
B
My
sister-in-law
has
a
love
of
cats
and
so
kitty.
Condo
is
essentially
a
three-lever,
a
three-leveled
cage
that
looks
like
it's
cute,
but
that
way
he
can,
he
can
be
more.
He
can
be
contained,
but
not
feel,
like
he's
being
contained,
he's
always
his
bottom
levels,
his
pan
middle
levels,
his
food
top
levels,
his
bed.
It
looks
like
he's
an
apartment
complex
for
cats,.
A
B
B
B
B
Ac,
are
you
the
lsr
working
group
just
like
john
and
I
are
the
oh.
C
E
Actually,
not
you
can
log,
you
can
join
the
same
meeting
multiple
times
with
the
id.
C
B
We'll
give
it
one
more
minute
see
if
we
can
get
people
to
do
the
blue
sheet,
the
if
you
click
there
is
also
an
ether
pad
john,
if
you'll
click
the
ether
pad
in
love,
to
have
notes
on
the
ether
pad.
Do
we
have
mahesh
here
a
little
bit
scared
because
he
said
he
was.
B
B
Early
but
I
was
up
at
his
net
conf
meeting
that
started
an
hour
two
hours
earlier,
the
app
stuff
so
come.
A
B
G
Yeah,
for
some
reason
webex
doesn't.
Let
me
out.
B
B
Okay,
well,
do
you
want
to
do
the
note
well
today
and
then
we'll
flop.
C
Glad
to
see
you
yeah
sure,
let's,
let's
call
this
meeting
to
order
or
disorder
or
whatever
it
is
that
we're
doing-
and
this
is
an
ietf
working
group
meeting
as
such
we're
meeting
under
the
usual
ietf
no
well
and
you
get
to
see
the
notewell
slide
and
know
that
it
says
important
things
about
your
contributions
and
what
implications
that
has
for
intellectual
property,
among
other
things,
and
I'm
not
here
to
be
your
lawyer
or
interpret
it
for
you.
C
But
I
am
here
to
tell
you
that
if
you
don't
already
understand
it,
you
should
probably
go
talk
to
your
legal
counsel
and
whether
you've
read
it
or
not.
You
are
deemed
by
lawyers
to
have
read
it.
So
go
read
this
stuff.
If
you
haven't
already
done.
B
B
With
a
little
bit
of
discussion
time
between
after
well-known
communities
and
weaponizing
bgp
using
communities,
we
will
start
with
flow
spec
for
l2
and
tunnel
traffic.
That
follows
on
last
time's
discussion
and
then,
after
all
of
that,
kristoff
is
going
to
be
kind
enough
to
give
us
a
presentation
on
bgp
extended
community
registry
update.
H
Can
you
hear
me
guys
you
sound
great
all
right
thanks,
john
all
right,
so
we
I
just
have
two
quick
slides
to
give
an
update
on
the
bgp
yang
model.
Next
slide,
please
so
the
zero
eight
version
of
the
draft
essentially
is
mostly
acting
on
things
we
talked
about
in
106.
H
Next
slide,
please
so
coming
into
this
meeting,
one
of
the
commitments
that
we
had
been
working
on
was
trying
to
see
if
this
model,
as
it
is,
works
great
for
machines,
but
we
also
wanted
to
make
sure
that
if
anyone
wanted
to
use
the
model
for
the
show
commands-
and
some
of
the
more
basic
show
commands
that
the
model
should
be
able
to
support
that,
and
what
we
have
found
is
that
we
might
need
to
make
a
few
changes,
not
because
we
want
to
support
all
the
commands
in
this
model
itself,
meaning
we
are
not
going
to
make
augmentations
and
changes.
H
C
B
I
Loud
and
clear,
excellent,
okay,
so
I'm
donald
eastlake
with
future
way
and
I'm
going
to
talk
about
the
two
drafts
for
extending
flow
spec,
one
to
cover
l2,
including
l2
inside
of
vpn
and
the
other
for
tunnel
traffic
and
there's
a
substantial
number
of
other
other
authors.
I'm
sort
of
being
editor
and
pushing
this,
but
most
of
the
a
lot
of
it
originated
with
other
people.
But
we
can
go
on
to
the
next
slide.
I
This
kind
of
shows
the
document
dependency
structure,
so
we
got
base
rfc
5575
this
moving
along,
which
covers
ipv4
and
the
separate
ipv6
draft,
which
is
sort
of
dependent
on
the
basic
structure
set
up
in
55
75
this.
So
the
ultravpn
draft,
which
covers
l2
as
well
as
I'll,
do
vpn.
The
file
name
is
slightly
historic,
it's
kind
of
in
the
same
place
as
ipv6.
I
It's
a
separate
kind
of
flow
spec
based
on
5575
this,
but
there
is
a
some
interesting
difference
there
I'll
get
to
in
a
second,
and
then
the
tunnel
floats
back
kind
of
needs
to
do
a
bunch
of
things,
including
possibly
headers
before
and
after
the
tunnel
header.
So
it
kind
of
makes
the
dependencies
or
with
use
of
all
the
other
drafts.
I
So
if
we
can
go
on
to
the
next
slide
talking
about
the
l2
vpns,
it
covers
both
the
non-vpn
and
vpn
cases.
So
there
have
been
some
changes
between
version
12
and
the
current
version.
13..
Perhaps
one
of
the
important
ones
is
to
use
a
a
different
flow.
Spec
registry
sets
up
a
new
flow
spec
registry
for
l2
flow
spec
components
the
same
way
that
the
ipv6
sets
up
a
different
full
spec
component
registry
for
the
v6
components
that
also
solves
the
problem
with
non-extensibility
with
the
current
flow
spec.
I
That's
because
people
may
be
aware
that
the
bottom
two
bits
there
have
long
been
the
multicast
bit
and
the
local
bit
where,
if
the
local
bit
is
a
one,
it
means
that
that
mac
address
has
been
assigned
by
the
local
network
administrator
under
the
control
of
the
local
network.
Administrator.
I
That's
still
sort
of
the
the
mandatory
definition
of
mac
address,
but
ieee
802.1
is
set
up
a
thing
called
the
structured
local
address
plan
or
a
slap.
So
slap
defines
two
more
bits
above
that.
So
if
the
local
bit
is
a
one
actually
that
space
is
optionally,
they
say
divided
into
four
quadrants
and
they
one
of
them
is
kind
of
like
the
old
local
one
is
for
different
purposes.
One
in
particular
is
what's
interesting,
is
one
which
is
for
mac
addresses
that
have
been
locally
allocated
by
some
protocol.
I
So
there
are
in
fact
drafts
in
the
ietf
dhc
working
group
to
allocate
local
mac
addresses
and
there's
also
an
802.1
cq
effort
in
ieee
2.1.
To
do
that,
so
you
might
want
to
just
test
whether
a
mac
address
was
when
one
of
those
quadrants
or
something
like
that,
and
also
because
it
partly
because
it's
been
changed
to
to
have
this
separate
flow
spec
for
the
l2
stuff.
I
You
might
easily
want
to
test
something
about
the
l2
header
and
also
hand
that,
with
some
test
on
a
following,
l3
header,
make
you
want
to
test
that
at
some
particular
has
some
particular
ip
characteristic
and
also
has
a
particular
vlan,
for
example.
I
So
there's
a
as
part
of
the
use
of
separate
components
for
l2,
there's
also
a
means
to
have
a
different
l3
flow
spec
next
slide.
Please.
I
So
this
is
because
this
is
a
sort
of
the
structure.
That'd
be
a.
You
know,
happy
sappy
in
front
of
this
and
then
towards
the
end
of
this
presentation.
I
have
a
table
sort
of
talking
about
all
the
different
atheists
and
safies.
I
They
have
this
overall
length
and
then
you'd
you'd
be
using
a
safy
for
of
134.
If
this
was
for
vpn
case,
in
which
case
it'd
be
a
routing
discriminator
or
if
it's
just
an
l2
match,
you
have
the
safety
133
and
the
affy
will
be
one
indicating
that
it's
l2
in
the
front.
I
So
there's
a
space
where
an
l2
flows
back
current
draft
permits
that
to
be
null,
which
means
you're,
not
testing
the
l2
flow
spec
at
all.
Exactly
why
you're
using
this
l
flip
spec
design
for
l2?
If
you're,
not
testing,
l2,
who
knows,
but
maybe
it
was
auto
generated
or
something
at
least
it
allows
that
to
be
legal,
which
seems
to
be
in
the
spirit
of
house
suspect
handled,
and
there
is
a
space
to
specify,
in
addition
to
the
overall
l2
affi,
a
l3
aphe
to
test
the
l3
header
aft.
I
And
that's
the
structure
there.
The
only
change
I
think
is
needed
in
this
draft
right
now
is
that
it
needs
to
clarify
that
if
you
specify
zero
for
the
l
three
affy,
which
is
a
specifically
reserved
affy,
so
it
can
never
be
assigned
anything,
then
that
indicates
that
you're
not
checking
the
l3
at
all.
Otherwise,
if
you
sort
of
require,
if
you
have
to
have
a
non-zero
l,
three
ave,
then
you
have
to
sort
of
specify
whether
you
want
ipv4
or
ipv6
or
possibly
something
else,
I
suppose,
really
ipv4
or
ipv6.
I
You
might
not
want
to
constrain
that.
So
allowing
is
0
l3
a
fe
there
to
indicate
no
l3
testing
at
all.
It
needs
to
be
tweaked
in
the
draft.
That's
a
pretty
small
change.
I
I
So
if
people
think
that
some
of
those
shouldn't
be
covered
or
there's
something
else
that
should
be
covered,
that's
you
know,
and,
and
the
authors
are
willing
to
change
the
draft
to
make
the
scope
be.
What
a
working
group
would
like
there
have
been
some
changes
from
zero,
seven
to
zero,
eight
and
somewhat
similar
spirit
to
the
change
in
the
later
two
one
to
avoid
problems
with
the
non-extensibility
of
the
existing
flow
spec
and
then
to
line
up
with
the
v6
and
the
l2
specs.
I
There's
a
separate
registry
now
for
a
tunnel
header
tests
that
test
various
fields
in
a
tunnel
header
under
full
spec
components,
and
because
of
that
it's
also
sort
of
structured.
So
you
can
specify
whether
you
want
to
match
on
a
header
in
front
of
the
tunnel
header
and
or
a
title
header
after
that
done
later.
Of
course,
some
tunnel
headers
it's
really
hard
to
match
on
stuff
afterwards
like
if
it's
encrypted
or
something
you
really
can't
at
all.
I
But
some
cases
you
can
some
some
some
kinds
of
quote
tunneling
and
quote
like
ip
and
ip
are
really
very,
very
straightforward.
You
might
want
to
test
on
both
ips,
for
example,
but
both
these
drafts
also
have
some
editorial
improvements,
so
at
least
as
editor,
I
think
they're
improvements
next
slide.
This
is.
I
Somewhat
more
complicated,
there
would
be
a
a
new
saffy
to
indicate
this,
so
there's
a
table
dan
by
the
way
of
atheist
and
safy.
So
I
can
go
over
that
then
there's
the
oval
length
and
there
you
specify
what
tunnel
type
here
you're
after
and
it
only
matches
things
that
use
that
tunnel
type
and
there's
space
for
some
flags
there
and
there's
this
optional
routing
discriminator
and
the
presence
of
that
would
be
indicated
by
one
of
those
flag
bits.
I
I
So
it's
only
specified
to
be
indicated
by
a
flag.
The
I
guess
the
advantage
of
using
a
different
safety
is
because
you
can
indicate
support
for
affy
safety
pairs
independently
and
whereas
there's
no
facility
to
indicate
support
for
this
flag
internally.
I
So
that's
a
question
of
whether
it's
worth
having
another
safy,
so
the
for
either
a
non-vpn
or
vpn
case
of
tunneling
anyway,
the
there's
three
slow
specs
in
this
case,
potentially
three
rather
there's
a
the
the
tunnel
header
flow
spec,
which
would
always
be
well
it's
logically
present.
It
could
be
null
in
some
case,
we'll
see
the
there's
a
a
place
for
a
flow
spec
for
the
headers
in
front
of
the
the
tunnel
header.
I
It
might
be
a
l2
header
in
front
of
the
tunnel
header,
for
example,
and
depending
on
the
flags
you
can
optionally
specify.
You
also
want
to
match
on
headers
after
the
tunnel
header.
So
it's
it's
more
complicated
than
the
other
cases,
but
I
don't
think
excessively
so
it
provides
the
options
that
you
would
want
to
have
available
next
slide.
I
J
I
Any
tunnel
header
as
such
between
the
two
ips,
if
you
have
ip
and
ip
and
you
have
places
where
you
can
put
a
matches
on
the
outer
ip
header,
and
if
you
specify,
if
you
specified
l2,
you
could
also
you
could
actually
match
on
the
the
mac
and
possibly
the
tagging
there
you
could
match
on
vlan
or
something
and
as
well
as
the
outer
ip
header,
and
then
you
can
match
on
the
inner
ip.
I
So
that's
a
pretty
simple
case.
This
is
the
optional
matching
on
on
the
and
actually
the
ip
these
ip
matches
actually
match
on
things
like
they're,
a
little
beyond
ip,
the
udp
and
pcp
and
icmp
header.
Oh
now,
yeah
I
had
her
information
also
next
slide.
I
This
is
the
only
this
two
examples.
This
is
the
second
one.
So
this
is
the
xlan
software
tunneling,
which
has
a
vehicle
and
header
various
fields.
You
can
match
those
with
the
tunnel,
header
flowspec
and
as
before
you
have
the
outer
flows
back
of
cx
land.
The
way
it's
specified
there
should
be
a
udp
header
in
front
of
the
vxlan
header,
and
you
can
also
optionally
match
the.
I
Inner
material,
which
would.
I
There's
a
mac
header
there
and
you
can
you
can
match
on
that,
not
not
really
covered
in
this
presentation.
There
are,
of
course,
appropriate.
You
know.
Community
thing
feel
the
things
available
to
make
various
actions
on
matching
these
various
different
things
next
slide.
I
So
this
is
this
overall
to
the
structure
of
the
affy
safety.
I
The
first
row
across
there
is
55
75
bits
and
we
have
the
the
columns
are
the
actual
the
flow
spec
and
the
vpn
safies,
and
then
the
new
saffy
tbd
for
tunneled
and
then
the
far
right
is
the
registry
set
up
by
that
draft
or
we
used
by
hanging
used
by
it.
I
guess
so.
The
first
one
of
course,
is
ipv4
and
the
base
spec
next
one,
the
ipv6.
I
This
is
a
fe2,
not
gv6
flow
spec
components.
The
l3
l2
draft,
rather
the
third
row
across
has
currently
like
affy
equals
six
or
25.
Depending
on
whether
it's
vpn
or
not,
six
just
says
it's,
you
know
it
is
netback
header,
and
this
shows
that
the
interafe
can
be
one
or
two.
Let's
say
that
graph
needs
to
be
tweaked
to
allow
zero
to.
If
you
don't
want
to
constrain
to
the
ipv4
right
56,
you
want
to
ignore
the
interhead.
I
K
I
Completely
sets
up
the
l2
flow
spec
component
types
and
then
the
last
one
is
the
tunneling
draft,
which
can
have
various
fees
in
front
and
tests
various
different
types
of
addresses
and
can
have
optionally
the
inner
affi
and
sets
up
the
tunnel.
Header
flow
spec
component
types.
I
So
what
should
be
next
steps,
in
my
opinion,
say
they're
going
to
do
this
minor
tweak
to
the
l2,
the
produce
of
version
14.,
and
I
think
at
that
point
not
all
claiming
the
draft
is
perfect,
but
I
think
it's
ready
for
working
group
last
call
which
might
reveal
some
something
interesting
if
they're,
depending
what
comments
there
are,
but
I
I
think
that's
in
pretty
good
shape
the
flowspec
tunneling
draft
and
until
second
vo3
I
appreciate
people
could
look
at
that
draft.
I
It
may
also
get
tweaked
with
zero
nine,
but
it's
somewhat
more
complicated.
There
may
be
more
wonder
cases
there.
So
I
think
that
may
need
another
river
two
before
it's
ready
for
working
roof
last
call,
but
hopefully
soon
it
would
be
ready.
I
So
those
are
my
comments
and
be
interested
in
any
answers.
Questions
that
people.
H
L
C
C
The
mic
queue
I
do.
L
C
Comment
from
jeff
has
saying
that
as
soon
as
he
gets
around
to
it,
he
plans
to
review
the
documents.
I
I
I
hope
a
few
other
people
will.
You
know
please.
Please
take
note
of
the
fact
that
you
know
we've
got
a
working
group
last
call
and
a
soon
working
group
last
call
and
it's
it's
allowed
to
provide
review
before
working
group
last
call
it's
even
encouraged.
I
You
know
absolutely
no,
it's.
I
welcome
review
in
the
comments
and
there's
do
the
other
others.
N
Yeah,
hello,
so
the
authors
here
we
want
to
propose
a
well-known,
large
community
next
slide.
Please.
N
Okay,
as
a
background
here
is
the
large
community,
a
large
communities
just
like
a
regular
community,
but
it's
12
bytes
long.
The
first
four
bytes
are
typically
typically
in
asn
and
in
these
two
other
words
of
local
data
power.
N
This
is
typically
used
to
tell
other
asn's
how
to
treat
the
route
or
to
or
to
tell
others
about
properties
of
the
route
that
you
are
sending
them
next
slide,
please
large.
In
regular
communities,
there
is
well-known
communities
and
what
we
want
with
this
one
here
is
to
have
a
well-known
community
with
some
data.
N
We
do
have
some
examples,
no
export
to
a
specific
asn,
so
you
want
to
specify
the
asn
as
well
as
the
fact
that
this
is
a
particular
action
that
you
want
for
that.
Asn.
N
No
export
from
a
specific
asn
excuse
me
and
another
example-
is
the
down
only
indicator
from
a
specific,
a
n
for
right
league
detections.
That's
three
draft
the
routlec
detection
and
mitigation
draft
next
slide.
Please.
N
Okay,
so
here
is
the
encoding
we
want
to
so
now.
One
tricky
bit
here
is
that,
in
order
to
put
something
into
the
first
word
of
the
large
community,
we
need
to
make
sure
that
this
does
not
conflict
with
any
other
large
communities
from
or
or
used
by,
certain
es's,
because
in
that
first
word
you
put
an
as
number
typically
so
in
order
to
make
sure
we
do
not
conflict
with
any
existing
as's.
N
Look
like
a
certain
range
of
asn's,
so
we
need
to
reserve
a
range
of
asn's
just
for
the
use
of
this,
so
that
it
doesn't
conflict
with
any
of
those
things,
and
I
have
here
fixed
six
bits
to
indicate
one
and
a
large
community,
and
this
is
the
range
of
asms
that
it
reserves,
that
is
a
small
range
just
below
the
private
asms.
N
N
There's
any
data
that
you
want
to
put
in
there
now,
the
the
id
the
well-known
community
id
is
one
byte
long,
one,
eight
bits.
I've
had
some
comments
that
this
may
be
a
bit
short
now
to
make
it
longer
you
can
have.
You
can
use
the
data1
field
to
split
it
up
into
more
values
as
a
subtype.
If
you
will
next
slide.
N
The
transitivity,
so
I've
seen
that
there
are
some
issues
with
okay.
I
wanted
to
make
this
a
bit
of
a
parallel
with
extended
community
transitivity.
Regular
bgp
attributes
have
a
transitivity,
and
that
means
whether
a
receiving
router
will
or
will
not
transit
the
community
to
the
next
one.
If
it
doesn't
understand
the
community
in
for
extended
communities
and
for
this
one
transitivity
has
a
different
meaning,
it
means
whether
to
transit
the
community
across
an
as
boundary.
N
So
we
have,
we
have
four
different
transitivities.
We
have
transitive
regular
old
transitive
like
it
goes
everywhere
or
non-transitive.
It
does
not
go
across
as
boundaries
now.
The
new
transitivities
that
I
have
here
is
transitive
across
administ
throughout
a
single
administrative
region
only
and
not
across
that
administrative
region.
N
So
that's
the
the
picture
on
the
left
there.
We
have
as
one
two
and
three
which
are
part
of
an
administrative
region
and
as4,
which
is
not
the
way
that
this
would
work.
Is
that
the
ones
that
are
not
so
so
between
as3
and
as4?
It's
just
a
regular
thing.
There's
no
configuration
to
make
it
do
that
the
ones
inside
the
administrative
region
not
between
as
one
and
two
you
need
a
configuration
to
tell
it
that
those
are
within
the
administrative
region.
N
You
do
the
configuration
on
both
sides,
the
s
the
second
configuration
transitivity,
the
picture
on
the
right
is
one
time
transit.
That
means
that
means
the
community.
The
extended
the
large
community
can
transit
from
one
as
to
the
next
one,
but
not
to
a
subsequent
one.
So
it
only
does
it
only
does
one
hop,
and
the
way
that's
done
is
that
the
radar
software
will
as
soon
as
it
transits
1as.
N
One
more
comment
I
wanted
to
make
is
that
communities
so
this,
so
the
community
is
a
transitive
path
attribute
so
as
in
pathetic
transitivity,
so
anyone
that
doesn't
does
not
understand
this
scheme
here
in
these
transitivities
will
transit
them
anyway.
N
So
these
are
so
just
like
any
communities.
Anyone
is
free
to
accept
them
or
reject
them,
and
they
typically
do
that.
So
this
transitivity
is
what
do
you
say?
That's
it's
not!
It's
not
a
mandatory
thing.
It's
advisory.
N
C
He
had
two
questions
in
the
queue
jeff
then
randy,
okay,
unless
you
guys
want
to
hold
until
after
three
rom,
is
up
to
you.
G
And
to
your
point
john,
I
submitted
this
to
the
web
x,
specifically
because
I
didn't
have
to
be
the
one
reading
this.
So
when
I
was
reading
the
draft,
this
is
jeff
oz.
I
didn't
see
any
commentary
about
the
as
numbers
being
requested
being
reserved
from
ayana
or
our
irs
or
whoever
happens
to
hold
this
set
of
the
space
right
now.
That's
comment.
Number
one
comment
number
two.
One
of
the
interesting
side
effects
about
the
way
1997
was
put
together.
G
Is
it
basically
used
the
top
as
number
that
was
available
at
the
time
and
effectively
restricted
it,
because
a
side
effect
of
the
community
using
1987
as
an
example
of
being
the
all
ones,
is
that
that,
as
number
is
no
longer
available
to
have
more
generic
community,
see
done
to
it?
You
can't
say
as65535
colon
100
and
have
that
mean
something
generic
to
that
as
number,
so
the
consequences
that,
as
number
fell
out
of
use
in
pretty
much
everybody's
implementation,
sort
of
restricted
magic
number?
E
G
A
section
of
as
numbers
sort
of
in
this
middle
range-
that's
marked
by
this
big
pattern-
you've
as
a
consequence
created
a
set
of
as
numbers
that
now
probably
should
get
magic
treatment
if
they
are
seen
routed
in
the
internet.
Any
commentary
on
that.
G
Yes,
I
actually
see
it's
the
first
paragraph,
but
the
second
point.
N
Yeah
yeah
you're
correct
the
iona
consideration
section.
I
did
not
update
that
properly.
N
No
yeah
yeah
it
is,
it
is
now
in
a
consideration
section
and
yes,
it
is
requesting
a
range
of
as
numbers
which
then,
as
you
perfectly
say,
cannot
then
be
used
now
now
as
it
is,
you
know
I
did
look
in
the
in
the
iona
to
see
what
ranges
were
available
and,
and
this
range
is,
is
currently
unused.
There
is
an
extremely
large
range
that
is
currently
unused
and
will
never
be
used
for
any
air
sins.
N
This
range
is
so
big
that
it's
perfectly
reasonable
to
to
carve
out
such
ranges,
so
this
this
car's
out
at
a
range
of
1
64
of
the
available
space,
which
is
more
than
enough
for
anything.
G
A
N
Yeah
67
million
it's
1
64th
of
the
of
the
space.
G
G
I'm
not
talking
about
this
number
showing
up
in
the
community,
I'm
talking
about
the
as
number
that
you've
carved
out
showing
up
in
an
as
path.
Yes,.
C
N
N
It
yeah
yeah
in
the
in
the.
If
you
use
it
in
the
air's
path,
it
will
have
no
effect,
so
you
know
I
wouldn't
I
wouldn't
use
it
in
the
air's
path,
but
if
you
want
to
use
it
in
the
air's
path,
it
doesn't
actually
matter.
You
just
can't
use
it
in
this
community.
C
Relevant
to
this
part
of
the
conversation,
then
please
go
ahead.
K
Yes,
so
essentially,
jeff
is
asking
if
the
numbers
and
effective
s
numbers
that
are
part
of
the
well-known
large
community
set,
then
would
you
if
these
numbers
happen
to
appear
in
the
as
path,
then
would
you
drop
the
update
just
like
you,
you
would
drop
the
up
if.
P
K
A
private
as
number
that
appears
in
ebgp,
I
think
the
answer
to
that
question
should
be
yes,
I
I
think
jacob
was
trying
to
say
yes
to
that,
but
yeah
I
mean.
Is
that
all
that
you
wanted
to
ask
jeff
for
that?
Whether
the
answer
is
yes
or
no?
I
think
the
answer
is
yes.
G
I
think
it's
stronger
than
private
as
numbers.
This
is
something
that
feature
implementation
should
do
automatically,
rather
than
require
special
configuration
for.
N
Okay,
then,
if
that's
what
you
think
then
yeah
we
could
do
that
there
should
be
no
problem
to
do.
A
A
N
A
Currently,
communities,
decisions
about
propagation
and
manipulation
are
not
made
by
the
router
they're
under
opportunity.
It's.
C
Okay,
do
you
want
to
respond
to
that
or
shall
we
take
whitaker's
question
now.
N
Yeah
the
react.
The
rather
change
is
the
transitivity
from
from
this
one
time
when
it
goes
across
the
asp
boundary
for
the
first
time
it
changes
it
so
that
it
won't
go
across
the
next
one.
A
Oh
we're
well
in
we'll
deal
with
it
on
the
list.
Q
Okay,
we
hear
you
okay,
so
no
I'm
not.
N
L
Q
Q
Well,
okay,
that's
that's
going
to
be
a
source
of
leaking
unexpected,
unexpected
communities
due
to
due
to
failure
of
consistent
of
consistent
configuration
of
all
the
attributers
of
an
administrative
domain.
Q
So
that
needs
that
needs,
I
think,
a
lot
of
scrutiny
and
probably
and
probably
some
explanation
of
how
administrative
domains
are
supposed
to
be
actually
administered
towards
creating
the
proper
root
root
policies.
Thanks.
N
Okay,
rudiger
thanks
for
that
comment,
so
it
is,
it
appears
the
administrator
transitive
is
a
little.
N
I
don't
know
how
to
explain
it
any
more
than
I
already
did.
It
needs
to
be
configured
on
both
sides
of
the
in
of
the
ass,
so
the
leaking
leaking
across
say
from
s3
to
as4.
N
Is,
I
don't
think,
that's
very
difficult
at
all
it
because
to
make
that
two,
as
is
in
the
same
administrative
region,
it
needs
to
be
configured
on
both
of
them.
So
if
you
don't
configure
it
on
both
of
them,
it
won't
go
and-
and
this
this
would
be
done
in
the
router
code.
N
Let's
say
I
would
do
it.
I
would
do
it
in
the
router
code
to
have
the
router
recognize
these
things,
but
you
could
do
it
in
the
policy
if
you
wanted
to,
but
it'd
be
easier
to
do
it
in
erotica.
Q
Well,
just
just
just
note
that
whatever
is
being
done
in
root
manipulation
in
the
router
code,
of
course
also
is
a
part
of
a
policy.
Q
Well,
okay
for
for
doing
for
doing
stuff
in
the
router
code,
a
kind
of
some
configuration
seems
to
be
required
somewhere.
Yes,.
N
Yes,
yes,
the
configuration
is
required
these
the
configuration
you
need
to
configure
the
as's
to
be
in
a
specific
administrative
region
so
that
the
radical
knows
that
they
are
there.
Q
And
then
you
are
saying,
and
then
you
are
saying
for
the
administrative
domain
control
to
work
you
need.
You
need
coordinated
configuration
on
both
the
on
both
sides
of
of
the
peering
relations.
N
Q
Q
Have
that
consistently
configured
already
is
a
challenge
that
there
is
a
challenge
of
making
sure
that
the
configuration
is
consistent
on
the
full
edge,
but
making
the
assumption
that
all
of
the
peers
of
that
administrative
domain
also
consistently
configure
their
site
their
edge
policy
kind
of
that
looks
that
looks
to
me
completely
unrealistic.
N
The
reason
is
that
it
has
to
be
configured
in
for
all
the
routers
inside,
not
on
the
edge
of
the
administrative
region.
It
it
doesn't
have
to
be
configured
on
the
edge
of
the
administrative
region
only
for
the
ones
inside
of
it.
N
So
there's
no
there's.
No
there's
no
need.
There's
no
need
to
be
consistent
at
all
across
the
region.
Boundary!
Q
Okay,
so
kind
of
the
challenge
is
you
only
can
make
use
of
it
after
you
have
all
of
the
routers
that
are
doing
ebgp
in
between
the
aess
of
the
domain
actually
actually
actually
are,
are
applying
the
specific
new
policy.
Q
Well,
okay,
that's
that's
challenging
and
for
that's
to
work.
I
certainly
wouldn't
wait
for
having
all
of
my
vendors
delivering
the
implementation
in
router
code.
C
N
Yeah,
okay,
I
had
the
first
question
too,
which
I
forgot
what
it
was.
Q
Well,
okay,
I
just
I
just
commented.
I
just
commented
that
the
question
of
whether
recog
well,
okay-
for
for
implementing
the
metric
semantic
of
the
used
range
with
regards
to
transitivity,
quite
obviously,
quite
obviously,
is
something
that
probably
that
probably
could
have
could
want
support
from
specific
router
functions
to
identify
the
magic
number
range
or
the
question
of
how
to
deal
with
a
s
path
attribute
that
include
the
bad,
the
the
magic
numbers.
Q
My
comment
was
well
okay,
we
don't!
I,
I
don't
think
we
need
to
deal
with
that,
because
in
the
in
the
long
run
in
the
long
run,
I
would
expect
that
serious
networks
will
actually
filter
out
recognized
er,
a
bad
af
numbers
showing
up
in
the
as
paths,
for
example,
also
to
avoid
potentially
a
potentially
interesting
effect
of
have
people
using
strange
rulers
for
martian,
as
numbers.
N
So
the
iana
website
does
have
the
ranges
of
as's
that
are
to
be
allocated
that
are
ready
to
be
used
for
anybody
who
wants
to
get
a
new
asn.
Those
ranges
are
there
and
then
there's
the
unused
ranges,
and
so
I've
picked
an
unused
range.
That
is
not
there
to
be
allocated
for
people
that
want
an
asm
number
so
and.
Q
And
there
is-
and
there
is
the
nro
delegated
extenders
registry-
that
actually
also
can
be
used
to
identify
the
af
numbers
that
have
been
delegated
by
iana
to
the
rears,
but
are
marked
as
not
yet
to
be
or
not
anymore,
being
used
for
anything
by
the
rirs
and
actually,
actually,
I
presented
a
little
bit
of
statistics
about
that
at
one
of
the
previous
sidr
cider
ops
sessions.
N
Okay,
so
to
summarize
that
one,
you
said
that
the
range
is
if,
if
any,
if
any
one
of
these
magic
numbers
appears
in
an
ears
path,
that
it
would
not
cause
a
problem.
Q
Okay,
well,
okay,
you
define
actually
a
range
of
course
yes
to
be
to
be
assigned
by
ayanna
for
this,
for
this
use
as
magic
numbers,
and
I
I
would
not
see,
I
would
not
see
for
a
s-path
filtering-
a
need
for
specific
support
in
router
code
to
identify
this
range
kind
of
kind
of.
I
think
I've
I
I
think
that's
second
order
interest.
Q
The
interesting
thing
is
the
loading
of
magic
numbers
with
semantics.
Q
L
But
okay,
I'm
I'm
done
for
now.
For
now.
C
So
so
I'm
gonna
relay
a
message
for
jay
borkenhagen
who's
having
problems
with
his
mic.
He
says
friendly
reminder
from
rfc8642.
C
Five
note
that
or
note
for
those
writing
rfc
is
for
new
community-like
attributes
when
establishing
new
attributes
similar
to
those
in
rfc,
1997,
large
communities,
wide
communities
etc.
Rfc
authors
should
state
explicitly
how
the
new
attribute
is
to
be
handled
and
then,
in
parentheses,
handled
means
manipulated
by
policy.
C
Thank
you.
So
I
think
next
in
queue
is
wait
a
minute
you
none,
please
go
ahead.
J
Hi
jacob
hi,
everyone
else
am.
I
hurt.
J
Right
great,
I
I
just
have
a
a
small
suggestion,
not
specifically
to
this
draft
but
to
the
large
community
rfc,
which
is,
I
think,
8092
so
should
some
I
mean
specifications
regarding
the
handling
of
reserved
asn
be
specif,
be
specified
added
to
the
rfc.
J
I
mean
not
not
only
regarding
the
well-known
large
community
using
you
know,
a
part
of
the
reserved
numbers,
but
possibly
some
other
future
usage,
and
also
it
probably
should
cover
the
question
that
jeff
presley
raised
that
if
we
have
the
reserved
sn
carried
in
the
is
passed,
should
something
like
that
be
specified.
J
A
suggestion
specifically
towards
your
draft,
but
I
think
maybe
some
updates
to
rfc
8092-
should
include
some.
You
know
statement
regarding
the
handling
of
reserved
essence
right.
Q
The
philosophy
behind
creating
and
using
the
large
communities
actually
was
to
use
the
96
bits
that
we
have
in
the
large
communities
is
free
of
free
of
semantics
for
everybody
and
jacob's
suggestion
of
creating
number
ranges
with
magic
number
ranges
with
semantics
is
kind
of
a
fundamental
change
of
what
the
large
community
definition
is
right
now.
J
If
we're
going
to
like
use
this
special
range
of
asn,
we
should
at
least
specify
them
in
the
rfc
rate.
N
Yes,
I
have
asked
for
a
range
in
the
draft
to
be
reserved
for
this.
Q
Purpose,
asking
for
a
range
is
something
quite
different
from
saying
a
number
space
that
just
has
administrative
hierarchical
structure
at
the
moment,
as
numbers
first
32
bits
to
something
were,
as
numbers
actually
have
semantics
beyond
indicating
who
is
the
owner
of
the
code.
Space
of
the
following
64
bits
is
a
fairly
fundamental
thing
and
goes
far
beyond
just
registering
number
ranges,
and
that
and
that,
and
that
has
that,
has
repercussions
or
should
have
reaper
governments
yeah
for
for
for.
N
The
basic
for
the
basic
large
communities-
yes,
you've
already
said
that
and
yes,
that
is
what
I'm
asking
so
I
do
agree
with
you
now
actual
repercussions
in
my
opinion
are
pretty
much
nothing
actually
because
that
range
is
not
used
currently,
so
I'm
not
taking
that
and
and
and
and
there's
nothing
fundamental
about
it,
either.
Q
I
think
I
think
I
think
I
think
the
pointer
that
offered
is
essentially
pointing
at
this
kind
of
problem,
and
I
could
I
could.
I
could
very
much
imagine
a
system
where
we
do
not
need
to
do
this
kind
of
introduction
of
magic
for
a
number
range,
but
obviously,
obviously
explaining
that
is
far
beyond.
N
I
think
we
could
we
could
further
this.
C
Okay,
so
I
think
randy
also
had
a
a
point
that
related
to
jay's
point
that
I
relayed
so
randy.
If
you'd
like
to
jump
in.
A
Jay
is
saying
that
you
need
to
specify
what
must
be
provided
to
the
operator
for
configuration
options,
but
in
general
this
proposal
needs
to
that's.
You
have
to
say
what
the
operator
controls
what
the
router
does
by
vendor
hard
code.
What
the,
if
you
have
magic
numbers
and
those
magic
numbers,
look
like
as
numbers.
A
A
N
Yeah
I
will
read,
I
will
read
that
one
again
and
take
it
to
the
list.
Yeah
answer
to
this
on
the
list.
R
N
I
did
say
with
this:
this
was
this
was
asked
previously
also
by
jeff
and
rudiger,
and
I
will
I
will
add
that
to
the
draft
in
in
the
as
path.
I
don't
think
it
matters
whether
you're
using
this
path,
but
I
will
put
that
into
the
trust.
R
Okay,
the
second
comment
is
basically,
I
agree
with
what
rudiger
mentioned.
I
think
this
is
maybe
some
bigger
change
than
just
reserving
some
range
of
the
numbers,
because
the
new
encoding
looks
more
similar
to
the
like
structure
format
like
extended
community
rather
than
the
existing
large
community.
So
maybe
obviously
like.
N
Introducing
some
this
kind
of
thing
yeah:
can
you
can
you
bring
to
the
list
the
the
acts,
the
exact
problem
that
this
would
cause?
Because,
because
just
saying
oh,
this
is
a
fundamental
change
is
not
actionable.
R
Okay,
okay,
we
can
have
put
the
discussion
on
the
list
and
another
one.
Maybe
more.
Generic
comment
is
whether
maybe
we
should
revisit
the
design
methodology
of
the
existing
communities,
like
a
traditional
community,
extended
community,
a
wider
community
and
a
large
community
to
compare
what
what
are
the
pros
and
cons
of
each
mechanism.
So
what?
When
we
extend
this
one
or
another
one
we
can
make
it
both
extensible
and
also
this
behavior
clear
not
only
for
the
lens
extension,
but
also
the
like:
the
transmission
transit,
the
basicity
transceiver
transitivity.
R
N
Yeah,
I
I
really
don't
agree
with
that.
You
know
so
so
I
will
put
in
the
draft
what
I
want
to
do
with
it
and
that
the
router
code
will
I
I
guess
I
haven't
been
clear
as
what
part
the
router
code
does
and
what
part
the
policy
does.
N
But
I
could
I
could
try
to
clear
that
up,
but
I'm
not
sure
that
anything
else
is
needed.
Actually.
C
Okay,
sriram
you're
next.
K
Yeah,
okay,
so
this
is
sriram.
I
have
a
little
higher
level
question
actually
for
the
chairs,
john
and
sue
in
the
there
has
been
like
we've
been
talking
about
making
an
ayana
request
for
a
registry
for
large
community
for
some
time,
and
there
was
discussion
that
a
draft
would
be
generated
to
to
make
that
request
and
make
that
happen,
because
currently
there
is
no
large
community
registry.
K
K
C
Yes,
so
I
was
actually
planning
to
speak
to
that
a
little
later
in
the
in
the
sequence
here.
But
but
no
let
me
take
it
now.
So.
C
So
we
need
to
have
this
concept
of
well-known
communities
so
in
in
that
way,
I
think
that's
directly
related
to
this
draft.
The
problem
I'm
seeing
is
right
now
is
all
of
the
discussion,
so
far
has
been
related
to
sort
of
the
additional
bells
and
whistles
with
regard
to
transitivity.
C
The
the
controversial
part
out-
or
you
know,
equivalently
create
another
draft
that
encapsulates
the
non-controversial
stuff,
move
that
forward
promptly,
and
then
you
know,
argue
about
the
controversial
stuff
for
as
long
as
you
want.
I
agree
that
it
would
be
valuable
to
have
a
registry,
but
I
right
now
listening
to
this
conversation,
I
don't
see
much
hope
for
moving
it
forward
quickly.
C
G
If
that's
the
case,
then
all
that's
really
needed
for
that
application
somewhat
similar
to
how
the
as4
path
stuff
ended.
Up
working
is
to
reserve
an
as
number
a
single
as
number.
You
know,
one
of
the
registries,
to
do
that,
so
you
don't
necessarily
need
to
gate
things
on
some
more
generalized
feature
for
one
specific
application.
G
You
can
simply
carve
out
a
specific
as
number
where
this
runs
into
a
little
bit
of
headache
is
a
same
set
of
headache
that
the
four
byte
as
number
stuff
did
for
the
of
various
one.
Two,
three
four.
G
You
now
have
routers
that
need
to
do
something
special
with
the
new
magic
numbers
and
that's
sort
of
the
general
complaint
about
any
proposal.
That's
leveraging
these
name
spaces
that
already
know
set
up
various
numbers,
you're
carving
out
something.
That's
a
piece
of
signaling
information,
jacob's
point
and
others.
Point
about
this.
Being
a
very
large
namespace
means
that
it's
not
as
tragic
as
it
otherwise
could
be.
G
B
So
I
think
we
have
maybe
to
make
help
your
stuff
go
forward.
I
will
echo
jeff's
an
echo
that
was
the
original
intent
for
the
registry
draft
was
to
get
a
couple
numbers
and
the
suggestion
was
either.
Your
draft
can
allocate
one
or
more
and
we'd
work
with
ayanna
to
try
to
move
that
forward
and
leave
the
bigger
question
to
longer
discussions,
because,
as
rudiger
said,
there's
a
lot
of
operator
input.
You
need
on
anything
further
than
just
allocating
specific
numbers.
K
That's
perfect,
so
I
I
fully
agree
with
that.
So
thanks
to
jeff
and
you
for
those
suggestions,
one
quick
question
I
have
is:
is
large
community
considered
to
be
transitive
by
the
current
definition,
because
we
need
in
route
leaks?
We
need
it
to
be.
Transitive.
K
C
Q
I
guess
now
I'm
hurt
yes,
I
I
very
much
agree
with
sue's
point.
Q
N
Q
N
Q
That
would
mean,
like
the
original,
well-known
communities
said.
Every
router
who
sees
a
well-known
community
has
to
act
in
a
certain
way
at
the
dublin
or
rather
irish
countryside.
Iatf
idr
figured
out
that
well,
okay,
adding
well-known
communities.
This
way
is
something
that
was
impossible
at
that
point
in
time,
and
certainly
that
that
status
hasn't
changed
over
the
past
decade.
Q
A
couple
of
additional
well-known
communities
have
been
defined,
but
obviously
not
with
the
semantics
of
every
router,
who
sees
these
communities
has
to
actually
act
on
them,
at
least
at
least.
The
definition
were
whether
we
allowed
semantics
of
use
of
jacob's
large
communities.
N
So
I'm
doing
something
equivalent
to
if
you
want
to
make
it
parallel
to
the
regular
communities.
N
I
am
reserving
like
the
six
five
five
three
five
number,
but
this
actually
being
a
range
to
carve
out
the
six
five
five
three
five,
the
equivalent
of
the
six
five
five
three
in
which
he
can
then
specify
new
new,
well-known
communities
that
have
a
specific
behavior.
But
this
one
is
not
spit.
No
is
not
proposing
any
any
specific,
well-known
large
communities.
It
is
a
framework
within
which
you
can
then
specify
yeah.
Q
Kind
of
kind
of
do
following
your
proposal.
You
would
need
to
make
that
explicit
and
probably
work
out
the
consequences
of
the
point
that
j
was
bringing
in,
but
now
I
think
I
am
done
for
now
again.
N
For
each
for
each
new
one,
so
so
an
example
would
be
the
black
hole
community
that
was
recently
added
as
a
as
a
well-known
community.
What
to
do
with
that?
So
what
do
we
do
with
the
black
hole
community
that
still
has
to
be
treated
in
the
in
the
policy?
The
writer
doesn't
actually
do
anything
with
the
black
hole
community.
N
N
S
I
think
an
important
point
to
observe
about
jacob's
about
the
draft.
The
the
proposal
in
the
draft
is
that
it
allows
for
two
four
byte
ascends
or
four
octet
ascends
plus
you
have,
I
think,
it's
ten
bits
of
additional
space
that
you
can,
that
can
be
specified
as
as
part
of
the
of
the
community.
S
So
given
one
community
value
or
in
the
range
you
don't
have
to
you
have
the
ability
to
to
have
the
two
asms
plus
a
value
that
specifies
some
function
of
it,
which
is,
if
you're
allocating
asn's,
specifically
as
rudiger
suggested.
S
Then
I
guess
somebody
else
has
suggested
as
well
that
reduces
that
utility
because
of
that
that
extra
10
bits
that
you
could
otherwise
specify-
and
I
don't
think
I
expressed
that
all
that
well,
but
I
I
guess,
I'm
to
sum
that
up
it's
you're,
reducing
the
the
the
name
space
that
you
have
by
by.
C
Okay,
so
I'm
gonna
cut
the
line
now
after
me,
because
I've
been
standing
up
for
a
long
time
in
the
line
so
now
putting
on
my
individual
contributor
hat.
C
I
guess
a
few
of
my
questions
were
sort
of
nitpicky
in
coding
things
and
I'm
just
going
to
skip
over
that
in
the
interest
of
time.
I
have
sort
of
two
higher
level
things.
C
One
is
so,
as
I
remember
in
the
original
discussion
that
led
us
to
large
communities
to
begin
with,
there
was
a
really
strong
feeling
on
the
part
of
the
authors
that
large
communities
should
not
have
any
kind
of
fancy
embedded
semantics,
and
I
was
sort
of
expecting
to
see
the
you
know
a
a
slide.
You
know
on.
You
know
why
we
felt
that
and
what
changed
and
I
didn't
so
as
one
of
the
advocates
for
keep
it
simple
jacob.
N
Well,
john
and
sriram
came
up
with
uses
where
they
wanted
to
add
an
asn
to
the
community.
Well,
it
could
have
been
done
with
an
attribute,
but
if
we
have
communities
so
this
seems
like
an
easy
way
to
get
it
done.
D
N
And
might
we
should
have?
Perhaps
we
should
have
foreseen
need
for
for
such
structure
in
the
large
community
back
then,
but
we
didn't
so
now.
We
do.
C
Okay,
water
under
the
bridge,
and
then
the
second
point
is,
I
guess,
to
kind
of
repeat
what
some
other
people
have
said
is:
is
the
this
transitivity
stuff
seems
like
it
is
not
trivial
and
it
seems
feels
a
little
weird
and
maybe
wrong
to
apply
it
to
just
one
path
attribute
and
in
fact
just
one
flavor
of
one
path
attribute.
C
I
I
know
we've
you
know,
there's
always
this
risk
in
idr
of
of
saying,
hey,
let's
take
this
thing
and
generalize
it,
and
then
you
never
get
to
get
it
done,
but
gosh.
This
really
feels
to
me
like
something
that
ought
to
be
taken
and
generalized
before
we
just
put
a
special
case
of
transitivity
control
into
one
flavor
of
one
path
attribute.
N
Okay,
if
I
could
say
a
few
words
on
that,
I
know
that
there
was
a
draft
some
time
back.
I
think
kiara
was
on
it
to
have
all
subsequent
bgp
path.
Attributes
have
extra
transitivity
in
it
and
that
didn't
seem
to
succeed.
N
So
I
thought
I
would
try
it
in
a
more
restricted
in
in
a
restricted
part,
so
that
it
doesn't
have
to
affect
every
path
attribute.
So
I
was
taking
it
the
other
way
here
and
to
selecting
these
particular
transitivities.
N
I
do
remember
that
the
dmz
link
bandwidth
one
was
non-transitive,
whereas
that
didn't
make
sense,
it
really
had
to
be
transited
from
between
the
two,
as
that
were
using
it,
and
we
had
to
make
a
code
change
to
make
that
actually
work.
So
that's
an
exception
to
the
extender
community
transitivity.
N
And
that
seemed
to
be
quite
a
useful
transitivity.
So
that's
why
I
included
it
here
on
the
the
one
time
transitive
in
the
the
administration
transitive.
The
reason
I
put
that
one
in
was
because
there
are
some
there's
quite
a
few
operators
that
have
multiple
as's
and
yeah.
I
remember
there
was.
There
was
one
that
wanted
to
put
the
local
preference
across
between
asses
and
several
other
attributes
they
wanted.
N
To
put
it
across
is
because
they
all
had
different
answers,
but
one
one
operator
had
multiple
as's
and
they
wanted
to
put
lots
of
things
over
them,
and
so
so
that's
why
I
thought
that
one
was
a
particularly
useful
transitivity
to
have
yeah.
I
can't
draft
back
then
had
I
had.
No,
I
don't
quite
remember
all
of
it,
but
it
had
something.
To
do
with.
Configurations
is
well.
C
Right,
okay,
I
so
so
sticking
my
chair
hat
back
on
coach
air
hat
back
on
it.
I
think
that
we're
we're
out
of
time
here
so
I,
the
thing
I
can
predict,
is
a
active
discussion
on
the
list.
There
was
a
bunch
of
stuff
in
the
jabber
room
too,
that
I
thought
I
was
going
to
relay
to
the
mic
and
we're
just
out
of
time,
so
I
would
suggest
going
back
and
reviewing
that
too
later.
A
A
So
what
we
have
is
completely
undefined
semantics.
We
have
a
syntax,
but
there
are
no
formal
semantics,
just
convention
and
common
practice,
plus
a
lot
of
uncommon
practice.
You'll
excuse.
I
came
into
this
internet
as
a
compiler
writer
and
so
to
me
it's
like
we're
putting
semantics
in
the
comment.
Statements
right
that
just
doesn't
cut
it.
So
what
flavors
of
communities
do
we
find?
A
A
A
97
says
they're
transitive,
optional,
7454
says
advises
that
you
insert
policy
to
scrub
your
own
and
form
forward
foreign
communities
received
from
input
to
output,
so
many
people
do
not
expect
them
to
propagate
that
widely.
I
didn't
expect
them
to
propagate
that
widely
next,
only
14
percent
of
transit,
as
is
propagate
community.
This
is
measured
by
the
way
2.2
000
of
about
15
000.
A
A
Next
four
is
off
path:
okay,
the
community,
if
you
believe
the
as
number
didn't
say,
go
to
four
next,
it's
okay,
soon,
here's
the
distribution
of
on
path
and
off
path,
communities,
measured,
live
and
those
are
community
numbers
in
each
bar
and
just
remember
the
community
666,
and
that
there's
a
lot
of
it
off
path.
Next,.
A
So
there's
a
method
to
our
madness
and
we're
not
trying
to
do
real
damage.
So
all
the
active
experiments
that
I'm
going
to
now
go
into
were
actually
first
tested
in
the
lab.
The
impacts
were
estimated.
They
were
validated
on
the
real
live
internet
with
operators
consent.
So
he
did
real
hijacks
and
stuff
like
that
with
the
operators
consent
and
thank
you,
a
number
of
operators.
A
A
A
A
A
All
of
which
looks
cool,
except
it's
a
major
attack
vector
next,
the
attack's,
pretty
obvious.
The
attacker
is,
as
which
you
know,
we
see
everybody
sending
nice
traffic
towards
the
victim
in
as1,
good
traffic.
There's
no
dos
attack,
zed
announces
1.2.3.4
to
as2,
with
a
community
black
hole
for
one
two.
Three
four
good
traffic
to
as1
is
dropped
next
and
next
again
he's
very
happy.
The
attack
works.
Well,
it
works
from
a
distance
and
it's
hard
to
spot
triggering
is
possible
because
black
hole,
prefix
is
more
specific.
A
You
notice
that
it's
a
slash
32,
so
it's
accepted
by
exception
providers
check
the
black
hole
community
before
prefix
can
filters,
because
there
was
a
bug
in
an
analog
recipe
and
that
is
propagated
through
configurations
all
over
the
internet.
But
basically
there
is
no
validation
for
the
origin
of
the
community
tag
right.
There
is
no
authentication.
A
As1
originates
a
prefix
towards
two
with
the
path
one
two
passes
into
three
with
the
past
two:
one:
etcetera,
etcetera.
We
see
all
the
pads
next
seven
is
gonna
choose
the
bottom,
because
that's
the
shorter
as
path,
we're
gonna,
assume
just
path
length
and
not
going
to
the
93
other
tie
breaking
options.
A
A
A
Yes?
Next
it
was
seen
in
the
wild
dime
captured
multiple
instances,
making
use
of
communities
to
shape
route
propagation,
although
the
most
prominent
ones
also
change
the
origin
which
gave
it
away.
So
this
isn't
theory.
This
is
happening
in
the
wild
next,
so
asn
values
are
ambiguous:
who's,
the
sender,
who's,
the
recipient,
they're,
no
defined
semantics,
it's
used
for
signaling
and
triggering
there's
no
cryptographic
protection,
there's
no
attribution.
A
In
other
words,
we
don't
know
who
I
received
this
community
there's
a
six-pack
on
sixth
hop
long
as
path
in
front
of
it
who
had
in
that
community
who
changed
it
on
the
way.
I
have
no
idea
and
it's
hard
to
apply
filters
when
you
don't
understand
what
the
heck
is
going
on
and
filters
are
all
manual
all
right.
This
is
just
it's
a
free-for-all.
It's
the
wild
west.
A
A
A
Next,
don't
propagate,
so
so
what
we
should
do
for
the
moment,
given
the
mess,
we're
in
don't
propagate
without
thinking
very
deeply
drop.
Anything
that's
not
addressed
to
you
unless
there's
special
agreement,
unless
you
know
that's
coming
drop
everything
on
output
except
signals
from
you
to
the
direct
peer
by
agreement,
cisco
has
a
ugly
problem
with
well-known
communities
that
they
treat
them
differently
among
them.
Some
they
propagate
some.
They
don't.
A
But
watch
out
due
to
expansion
of
animations
the
slide
numbers
don't
match
in
the
lower
right
corner.
F
Okay,
this
one
will
do
so.
I
mean
I
agree
that
this
is
a
bad
bad
issue.
I
just
want
to
make
sure
I
understand
in
this
particular
thing.
If
the
attacker
had
not
tagged
or
had
not
added
the
community,
they
would
still
manage
to
have
an
attack
right.
They
would
be
announcing
traffic
for
one.
Two.
Three
four
would
float
them:
okay,
cool
just
making
sure
I
got
it.
Yep.
C
P
P
C
We
have
two
other
people
in
the
queue
we
have
rudiger
and
then
we
have
jeff
already.
Please
go
ahead,
thank
you
and
then
we
have
warren.
L
Q
One
thing
in
the
in
some
parts:
randy,
you
were
saying:
well,
we
have
all
these
communities
and
we
do
not
know
the
semantics.
Q
Q
Q
And
well:
okay,
going
into
details
how
that
can
be
done
and
how
that
might
be
even
done
in
a
way
so
that
the
metric
bit
strings
are
a
little
bit
transformed
into
something.
That
is
something
some
somewhat
more
readable
like
we
did
with
machine
language
in
the
50s.
A
I
use
those
rudiger,
don't
remind
me:
yes,
you're,
right
document,
good
documentation
and
and
as
you're
documenting
structuring
things
a
little
more
without
breaking
current
deployment.
Those
will
help.
The
question
is,
in
my
mind,
is
given
that
the
world
is
getting
to
be
an
uglier
and
uglier
place,
and
I'm
not
referring
to.
A
19,
I'm
referring
to
attacks
and
so
on
the
internet
and
especially
as
the
internet's
gaining
prominence
in
the
current
scene.
So
the
the
the
heat
is
going
to
get
greater
and
throwing
documentation
at
it
improves
things.
I
don't
think
it
improves
it
enough.
Q
Yeah
at
some
ietf
discussions,
I
started
to
make
remarks
about
the
need
for
hygiene
which,
in
the
current
such
situation
kind
of
comes
comes
also
to
mind
for
the
bgps
for
the
inter-domain
bgp
sessions.
Kind
of
one
needs
the
face
mask
in
both
directions.
Q
One
has
to
one
has
to
one
has
to
filter.
One
has
to
filter
what
the
air
that
we
that
we
inhale
and
make
sure
that
nothing
dangerous
is
there,
which,
in
bgp
terms,
means
we
minimize
the
stuff
that
is
actually
not
authentic
and
about
the
only
thing
about
the
only
thing
that
we
can
really
trust
is
what
the
neighbor
has
under
control
if
he
actually
exercises
control
for
the
other
direction
of
the
use
of
a
mask
where,
yes,
you
also
want
to
use
the
mask.
So
you
do
not
spare.
Q
You
do
not
spread
the
bad
stuff
and
the
fighter
cider
ov
egress
is
an
example
of
that,
but
say
propagating
propagating
stuff
with
strange
communities
or
other
path.
Attributes
potentially
also
comes
to
mind
kind
of
as
you
as
as
you
as
you
propagate
any
roots
in
ebgp.
Q
You
should.
You
should
consider
yourself
responsible
for
all
the
nasty
bits
that
you
are
sending
and
yes
doing.
That
is
something
that
has
not
been
done
20
years
ago
and
in
most
cases
is
not
done
completely
at
the
moment,
but
yes,
we
have
we
have
we
have
to.
Actually
we
have
to
actually
get
a
little
bit
closer
to
that.
C
G
So
I'm
going
to
change
what
I
was
going
to
say
and
just
simply
build
up
what
rudicker
is
expressing.
I
think
there's
several
other
larger
arguments
here,
but
sticking
to
your
presentation
what
I
think
is
needed
in
terms
of
hygiene.
So
I
think
that's.
The
biggest
actionable
thing
here
is
a
little
discussion
about
how
do
we
actually
put
together
lists
of
stuff
that
are
expected
to
be
propagated
versus
not?
G
This
is
partially
relevant
because
several
service
providers
are
extremely
strong
about
their
scrubbing
of
communities
and
don't
necessarily
let
things
through
that
aren't
theirs
they're
effectively,
not
intransitive
by
their
policy
design,
whereas
your
observations
are.
A
lot
of
people
are
very
lazy
about
their
policy
design
for
various
reasons,
it's
my
belief
as
a
vendor.
It's
been
working
on
a
few
implementations
over
the
years.
A
G
Q
Comments
to
jeff's
question:
I
would
think
that
actually
attacking
the
documentation
things,
the
documentation
aspect.
Q
Q
The
traditional
vendors
policy
languages
will
offer
easy
ways
to
to
draw
in.
Q
Information
from
a
documentation
base,
I
would
expect
that
it
is
far
more
realistic
to
assume
that,
based
on
documentation
that
you.
A
A
A
B
C
I
pasted
into
the
chat
that
anybody
who
objected
to
a
short
extension
should
email
or
should
you
know
message
me.
I
have
heard
nothing
from
anyone,
I'm
taking
that
as
silence
gives
consent
so
yeah.
If
anybody
has
a
problem
with
us
extending
for
let's
say
20
minutes,
please
speak
up
and
we
will
end
as
scheduled
and
schedule
another
meeting,
but
otherwise
I'd
like.
J
F
Please
continue
so
sorry,
warren
clary,
google,
so
first
off.
Thank
you.
I
think
this
is
really
important.
What
I'm
trying
to
figure
out
is
why
randy
is
telling
idr
like
what
exactly
idr
is
supposed
to
do
with
this
other
than
maybe
you
know,
don't
design
complex,
active
stuff
in
communities.
J
A
B
Be
really
blunt
warren
we're
getting
proposals.
If
we've
got
a
proposal
in
front
of
the
working
group
for
structuring
communities
going
forward,
we
need
to
again
hear
pros
and
cons.
This
is
a
pros
and
cons
discussion
about
a
proposal
coming
in
we'll
continue.
You
know
it's
like
wise
design.
Let's
hear
the
things
that
could
be
good,
which
jacob.
J
B
F
A
B
And
one
I'll
put
myself
at
the
top
of
the
line
to
respond
to
you
and
so
idr
being
the
community
that
tries
to
resolve
to
that
in
the
protocol.
Is
there
something
we
can
do
in
the
protocol
or
do
we
need
to
look
to
what
rudiger
is
suggesting?
Maybe
something
that
automatically
generates
what's
actually
happening?
B
What
can
we
do
to
fix
a
real
live
problem?
So
the
chairs
are
picking
the
thing
you
know
there
is
a
range
of
potential
solutions
we
could
say,
and
I'm
just
talking
like
john
out
of
10
seconds
thought
we
could
say.
Okay
communities
is
a
true
loss
and
maybe
what
we
really
ought
to
do
is
have
a
path
attribute.
If
we've
got
all
these
problems,
that
looks
like
large
communities
smells
like
large
communities,
but
has
some
sort
of
origin
in
it.
B
Okay,
large
community
form
identifier,
an
origin
or
something
that
can
be
tracked.
B
C
Q
Just
looking
at
it,
I
was,
I
was
hearing
randy
asking
for
cryptographically
armed
attributes
kind
of
for
getting
really
reliable
data.
That
is
obviously
something
that
has
to
be
considered,
but
we
know
it
takes
decay
to
actually
define
and
deploy
if
the
deployment
doesn't
fail
in
the
end,
looking
into
stuff
that
actually,
that
actually
goes
into
that
kind
of
direction,
probably
is
something
we
actually
should
be
doing.
Q
On
the
other
hand,
doing
things
that
that
have
a
chance
for
being
deployed
on
a
much
shorter
time,
timeline
probably
probably
goes
into
completely
different
different
topics
like
documentation
and
well.
Okay,
what
kind
of
filter
specifications
can
be
used,
and
I
think
I
think
we
need
to
do
actually
both.
A
C
On
that
fine
soap
box,
then
I
think
we
will
end
this
talk.
Thank
you
very
much.
That
was
obviously
super
useful
and
thanks
everybody
for
giving
us
a
few
extra
minutes,
so
that
kristoff
doesn't
have
to
talk
super
fast.
Thank
you
christoph
for
waiting
until
the
end.
Please
go
ahead.
T
Presenting
a
draft
which
is
more
or
less
like
a
housekeeping
draft
only
as
its
origin
in
alvaro's
review
of
the
rfp
5575
bis,
the
flowspec
draft
and
alvaro
pointed
I'm
not
sure
if
I'm
pronouncing
that
right,
but
alvaro
pointed
out
that
the
bgp
extended
community
types
that
are
used
by
bgb
flowspec
but
also
by
other
technology,
are
documented
as
experimental
use
in
the
inor
registries,
and
this
draft
is
basically
going
to
fix
it.
It's
actually
asking
ayanna
to
remove
this
experimental
use
statements
from
from
the
btp
registries
next
cycle.
T
Basically,
it's
it's
asking
to
update
the
pgp
transitive
extended
community
types.
I
remove
the
extended
com
experimentally
from
from
those
names.
Second,
you
can
next
type
please.
T
Yeah
second,
it's
renaming
those
three
registries
by
removing
experimental
use
from
the
titles.
Those
these
are
the
subtyper
subtype
registries
of
the
transitive
extended
community
types,
subtypes
and
third
next
slide.
Please.
T
It's
changing
the
registration
procedure
of
the
extended
community
types,
hex
80
to
hex
82,
to
remove
them
from
the
reserved
or
experimental
use
pool
and
put
them
into
first-come,
first-served
pool.
Well,
basically,
that's
it,
so
it
was
less
than
two
minutes.
Wasn't
it.
This
is
my
draft
created
it's
just
five
pages.
It's
a
little
bit
boring
and
I
request
working
group
adoption.
B
C
Well,
I
think
all
I
have
to
do
is
say
thanks.
Everybody.
C
And
thanks
for
hanging
in
here
thanks
for
the
useful
conversation-
and
I
really
hope
to
see
action
on
the
list
on
some
of
these
things
that
were
so
actively
discussed
in
the
meeting
as
before
any
feedback
to
the
chairs
about.
C
Using
a
virtual
meeting
for
this
purpose
would
be
helpful,
we're
still
still
learning,
but
I
suspect,
we'll
be
doing
more
of
these.
So
thanks
very
much
everyone
stay
safe
and
we'll
see
you
later
bye
thanks.