►
From YouTube: IETF109-RTGWG-20201118-0730
Description
RTGWG meeting session at IETF109
2020/11/18 0730
https://datatracker.ietf.org/meeting/109/proceedings/
B
You
could
you
can
go
ahead,
you
can
go
ahead.
Okay,
okay,.
C
Working
group
welcome
to
the
second
meeting
we
are
about
to
start
and
we'll
start
with
broadcast
history
protocol
that
has
been
moved
from
first
meeting
to
the
second.
B
I
believe
it's
okay.
D
D
D
D
Now
the
local
configuration
and
the
maintenance
is
more
inconvenient,
and
if
the
user
use
use
the
nmis
on
the
controller
and
then
they
they
have
to
take
time
to
adopt
it
yeah
and
then
another
for
another
controller
protocol
like,
for
example,
the
idt,
and
the
pdp
in
fact,
has
some
some
existing
method
from
there
for
the
past
error
and
the
result,
error
and
a
bb
notification
message
like
this
next
slide.
Please.
D
Hello,
while
a
comma
assisted
protocol
is
needed
in
order,
if
the
protocol
is
affiliated,
it
cannot
otherwise
the
any
information
to
the
neighbor
yeah.
This
is
mainly
the
reason
another
is.
The
existing
control
protocol
is
restricted,
for
example,
if
the
more
maintenance
the
information
is
introduced
it
may
it
may
have,
it
has
a
much
impact,
for
example,
bdp
and
rsvp.
D
When
now
the
bdp
evo
bp
extends
the
password
tribute
again
update
package,
then,
when
the
device
received
the
update
package
message
it
how
to
the
how
to
do
how
to
deal
with
the
attributes
attribute,
how
to
see
you
and
how
to
searching
and
how
to
compare
and
how
to
practice
legacy.
D
So
it
is
a
big
impact
and
another
product
with
rsvp,
as
we
extend
the
course
code
for
past
setup
for
the
features,
but
as
we
produce,
we
now
only
have
two
euler's
available.
So
this
is
the
two
controller
protocol.
Okay,
so
if
a
common
protocol
is
used,
I
think
it's
better
to
define
an
otherwise.
The
related
information
next
says.
Please.
D
Here
I
list
the
two
troubleshooting
use
cases.
First
of
all,
the
bp
rooting
oscillation.
If
your
device
want
to
know
which
guy
which
guy
is
the
oscillation
the
source,
he
will
introduce
a
message.
I
use
the
oscillation
source
to
his
neighbor.
If
the
neighbor
received
the
message,
if
he
can
reply
a
message,
I
mean
yes
or
not.
If
not,
if
not,
then
the
neighbor
can
continue
to
receive
the
message
to
other
neighbor.
Okay
until
the
someone
replies
with
the
oscillation
source.
This
is
the
first
use
case
and
another
is
the
rpt
the
setup
thingy.
D
D
And
I
introduced
the
php
protocol,
we
know
the
protocol,
the
pvp,
the
is
designed
for
device
to
exchange
protocol
related
information
between
each
other
and
separates
the
routing
and
the
non-rooting
data.
D
I
think
the
I
think
the
ppp
has
assembled
some
of
the
merits.
The
merits.
For
example,
the
facility
facilitates
the
automatic,
the
troubleshooting
and
are
not
impacted
impact
impacted
on
the
lunar
system
and
another
relying
on
centralized
server
and
so
on.
Okay,
next
slide.
D
Please
at
least
the
two
discussion:
the
first
discussion
is
the
udpr
tcp,
which
one
we
we
want
to
select
here
is
the
list
three
main
requirements
for
one
is
the
event
driven
and
recognize
the
law
resource,
the
consumption
and
the
law
reliability
requirements.
This
is
three.
I
think
it
is
the
mainly
the
requirements
for
the
for
the
pep,
and
now
this
discount
tool
is.
There
are
two
possible
options
to
implement,
implement
the
pvp
option.
One
lpp
is
development.
D
It
develops
independently
as
a
protocol
and
open
two
people,
reuse
the
existing
protocol
and
grasp
and
on
the
next
topic
is
the
grasp
we
can
discuss
together
about
this
question
is
the
question?
Okay?
Next,
the
at
least
the
grasp
and
pv.
The
two
protocol
in
here
give
the
simple
compare.
The
main
information
is
stability
and
irritability.
D
E
So
first
question
is
like:
how
do
we
guarantee
there's
a
end-to-end
ipad
to
run
this
protocol?
E
E
F
I
have
this
the
reply
simply
reply,
the
first
one
I
think
the
guarantee
the
end
to
end,
because
this
is
depends
on
this-
the
configuration
because
at
the
beginning,
because
if
we
want
to
send
this
exchange
into
information,
so
that's
need
some
this,
the
pre-configuration,
so
there's
the
first
one-
and
also
this
is
the
and
also
this
is
the
reachability
is
dependent
on
this.
The
forwarding
table,
the
second
one
I
think,
that's
the
second
one.
F
I
think
that
we
to
be
honest
that
just
now
we
just
think
about
this-
the
udp
and
tcp
you
propose
this
is
the
new
protocol.
We
will
have
more
research
on
later
and
also
that's
used
to
check
if
we
use
okay
for
this
scenario,
okay,.
C
F
Oh
hello,
randy,
I
I
may
be
not
a
catch
all
your
point
you
mentioned.
That's
the
secularity.
That's
used
depending
on
the
md5
is
okay.
You
saying
enough.
F
C
If
we
have
no
more
questions
we'll
move
on,
I
would
really
advise
authors
to
articulate
who
is
the
end
consumer
of
this
data,
because
networking
devices
don't
usually
do
anything
this
kind
of
information.
So
if
the
end
consumer
of
the
data
is
kind
of
nms,
the
real
question
would
be.
Why
not
use
south
north
communication?
We
already
have
highly
optimized
channels
such
as
grpc,
and
I
really
like
to
see
better
justification
of
doing
it
horizontally
rather
than
vertically
and
hopefully
on
the.
F
F
Jeff,
I
thanks
for
your
comments.
I
think
that's
you
in
fact,
in
the
previous
page,
we
talked
about
this,
the
reason
to
introduce
the
west
east
network
monitoring
and
also
I
agree
with
this
one,
and
also
that's
we
we
we
think
this
protocol
should
light
the
protocol
yeah,
but
I
think
this
is
the
possible
infection
effect
on
the
existing
operation
of
protein
protocols
should
be
taken
into
account.
G
H
Hi,
are
you
bringing
up
the
the
slides
to
share,
or
should
I.
H
Okay,
so
yeah
so
after
seeing
pap
and
we
we
we
started
seeing
that
on
the
anime
mailing
list,
I
thought
I'd.
You
know
kind
of
a
debrief,
rtg
working
group
on
the
work
we've
done
for
grasp,
which
I
think
is
already
providing
everything
and
more
that
pep
is
trying
to
do
and
that's
going
to
be
pretty
soon
as
a
standard
rfc.
It's
it's
in
the
editor
queue
next
slide.
H
Sorry
right
so
just
a
quick
rant
in
the
beginning.
Right
so
I
mean
so
self-optimizing
self-healing
you
know
is,
is
something
that
really
you
know
our
ancestors
with
the
arpanet
introduced
right
through
the
distributed
routing
protocols,
so
it
was
really
great,
but
then
really
you
know
it
went
downhill
from
there.
We
we
started
to
evolve.
H
You
know
through
sdn,
into
more
of
you
know
a
revival
of
ss7
with
the
hierarchically,
centralized
management
and,
and
obviously
we
know
a
lot
of
reason
why
that's
necessary,
but
we've
seen
how,
in
parallel
in
the
80s
through
the
2000s
others
have
taken
on
the
step
of
building
more,
you
know
a
self-automating
self-management,
optimizing
networks,
like
you
know,
apple
talk
and
then
also
ibm
and
others
started
the
autonomous
networking.
So
we
we
basically
in
irtf
and
nmrg,
started
to
revive
that
self-automation
and
then
started
to
standardize.
H
The
you
know,
building
blocks
for
that
in
the
animal
working
group
and
grasp
is
one
of
the
building
blocks
of
that,
and
so
I
wanted
to
try
to
summarize,
maybe
from
a
pragmatic
perspective,
how
it
could
be
really
quickly
be
introduced
into
running
networks
without
necessarily
having
to
use
all
the
components
that
were
standardizing
in
enema
next
slide.
H
So
you
know,
routers
of
many
vendors
had
scripting
support
for
automation,
often
since
the
2000s
right,
so
the
first
language
probably
was
tickle.
H
I've
seen
that
in
in
in
many
vendor
routers
now
there
are
many
more
languages
and
that
stuff
has
been
widely
used
even
before
the
advent
of
sdn
to
provide
device,
local
automation
in
which
a
script
uses
router
internal
cli
and
now
hopefully,
also
you
know
yang
interfaces
locally
to
call
it
monitor
some
router
behavior
and
trigger
actions,
and
I
could
go
on
for
a
lot
of
you
know
interesting
examples
what's
been
done,
maybe
in
general
scripting,
you
know
it's
something
that
can
run
on
the
router
itself
can
be
built
not
only
by
the
vendor
but
also
by
the
customer
and
can
have
its
own
lifecycle
independent
of
the
router
os
right.
H
So
how
do
you
do
across
the
land
between
adjacent
routers
or
you
know,
even
across
the
whole
network,
east-west
automation,
in
a
coordinated
fashion
in
enema?
This
is
what
we're
calling
autonomic
service
agents
right
so
and
the
examples
from
which
we
really
started
a
lot
of
you
know.
Animal
work
were
pain,
points
of
automating
security
right.
H
So,
for
example,
many
routing
protocols
have
kind
of
a
symmetric
key
options
and
there
are
no,
you
know
automated
key
negotiation
mechanisms
and
those
are
really
very
easy
to
do
when
you
can
discover
a
peer
and
have
a
simple.
H
Obviously,
my
examples
would
come
from
multicast
or
qs,
but
I
very
much
liked
the
examples
given
in
pep
right,
so
those
would
be
ideal
asas
in
enema
if
they
would
be
specified
out
in
terms
of
what's
the
actual
negotiation
that
would
need
to
happen
to
make
bgp
or
other
routing
protocols
operationally
work
better.
H
H
So
the
first
requirement
is
really
security
right,
so
you
need
some
mutual
keying
material
to
authenticate
the
peers
and
also
for
confidentiality
for
communication
between
them,
because
as
soon
as
you're,
starting
to
automate
these
things,
you're
really
taking
the
control
point
of
the
human
out
of
the
picture
that
you
know
is
using
north
cells
communication
to
basically
set
up
the
coordinated
behavior
right,
so
security
for
for
anything
that
goes
east
west
between
the
nodes
to
automate
other
things
is,
is
really
very
important,
and
you
know
you
really
want
to
have
a
common,
easily
extensible
negotiation
protocol
right
and
peer
discovery
mechanisms,
link
local
and
network
wide
and
when
you
then
want
to
do
network-wide
discovery
of
candidate
peers
to
automate
with.
H
You
also
would
like
to
have
routing
protocol
independent
layer,
3
reachability,
because
you
know,
one
of
the
things
you
may
want
to
do
is
really
even
start
configuring.
The
routing
protocol
not
only
securing
it
next
slide,.
H
So,
let's
assume
you
know
and
I'll
get
back
to
that
in
a
later
slide.
The
precondition,
for
you
know
the
the
secure
peer-to-peer
communications
there.
We've
got
the
discovery
and
we've
got
the
mutual
trusted
keying
material.
So
then,
obviously,
we've
got
the
building
blocks
like
tls
or
if
you
can
survive
packet
loss
dtls
right.
So
that's
authenticated
confidential
communication.
So
we
don't
need
to
invent
anything
new
in
there
right.
So
then
comes
the
question.
So
what
else
do
we
need
for
a
common?
H
You
know
east-west
communication
protocols
and
in
animal
we
looked
into
the
building
blocks
that
have
been
successful
in
the
web
layer,
and
that
was
basically
you
know,
a
data
modeling
language
that
was
about
embodied
in
the
programming
languages
like
json
in
javascript.
That's
basically
making
a
lot
of
communication
negotiation
very
easy
in
the
web
layer,
and
then
you
know
a
few
simple
primitives
where
you
know
in
the
application
layer,
web
layer,
it's
rest
through
http
and
uris,
and
so
those
two
building
blocks.
H
We
try
to
emulate
next
slide
in
a
more
efficient
fashion
for
east-west
communication
between
potentially
even
constrained
devices
like
low-end,
routers,
iot
devices
and
so
on.
So
what
we
used
was
what,
at
that
point
in
time,
a
few
years
back
when
we
started
grasp
was
just
upcoming
and
now
obviously
has
gained
a
lot
of
attraction
through
the
ietf,
which
is
cyborg,
which
is
a
binary
encoding
of
you
know
pretty
much
the
same
data
structures
that
json
has
it
does
not
only
support
textual
but
also
much
more
compact
binary
data.
H
So
it's
an
ideal
evolution
from
you
know
all
the
binary
protocols
we
love
to
build,
but
without
the
ascii
art,
but
actual
you
know,
schema
languages
like
cddl
to
have
formal
definition
of
than
the
negotiation
message
that
you're
forming
and
obviously
we
didn't
need
to
have
the
whole
overhead
of
http
or
so
to
to
build
something
like
rest.
But
we,
of
course,
for
the
few
primitives
that
grasp
offers
are
simply
using
seabor
message,
headers
as
well
right.
H
H
So,
just
as
a
simple
example
here,
just
a
simple
message:
exchange
from
initiator
to
responder.
So
I
don't
want
to
delve
too
much
into
the
details
here
for
time
reasons.
But
x2,
for
example,
would
be
the
iana
registered
application
kind
of
a
particular
automation
application
where
you
know
the
initiator
requests
that
and
then,
for
example,
the
responder
would
respond
with.
You
know
some
value
of
that
a
string
and
a
numeric
value,
and
all
of
that
is
shown
here
in
seabor.
H
H
So
how
we
can
discover
grasp
peers
for
setting
up
this
automation?
Obviously
you
know
if
we
have
simple
things
where
a
routing
protocol
like
in
bgp
may
already
have
a
configured
peer.
We
can
latch
on
to
that,
but
grasp
itself
comes
with
its
own
discovery
mechanism.
So
we've
got
the
layer,
two
grass
multicast
to
announce
or
request
objectives.
H
That's
currently
specified
and
standardized
on
top
of
ipv6
link
local
multicast,
and
we
can
also
do
a
whole
network,
domain-wide
multicast
announcement
or
request
objective
like
looking
for
services
and
that
doesn't
require
any
layer,
3
connectivity,
unicast
or
multicast.
Instead,
it's
a
simple
grass
per
hop
forwarding
and
flooding
agent.
That
you
know,
creates
loopless
flooding
by
a
per
unique
message,
identifier.
So
that's
a
very
simple
thing
that
could
be
added
in
a
domain
to
all
routers
to
enable
self-automation
and
that
adds
to
you
know:
primitives
flood
and
discovery
to
the
grass
primitives
next
slide.
H
So-
and
this
is
basically
the
step-by-step-
you
know,
what's
the
most
simple
way
on
how
you
can
start
with
grasp
all
the
way
up
to
the
full
enema
option
right.
So
the
most
simple
thing,
of
course,
is
you
just
require.
You
know
lan
discovery,
so
you
just
use
a
grasp
layer
to
multicast
you.
Obviously
you
may
already
have
some
tls
keying
material
and
then
basically
grasp
is
a
very
simple
standalone
thing
without
anything
to
be
added,
and
that
would
be
already
you
know
a
super
set
of
what
pap
promises
to
do
right.
H
H
We
also
have
the
autonomic
control
plane,
which
is
also
a
self
build
hop
by
hub
virtual
out
of
band
management,
like
you
know,
automatically
build
brf
and
that
basically
would
allow
to
build
all
that
and
also
have
layer,
3
unicast
connectivity
to
remote
peers.
Before
you
have
any
form
of
you
know,
layer,
three
unicast
routing
otherwise,
and
finally,
there
is
obviously
an
automated
way
to
create.
You
know
your
mutually
trusted
keying
material.
We
call
that
brewski
and
that,
of
course,
is
also
self-configuring,
with
the
help
of
the.
H
H
So
we
really
think
that
grass
is
ready
to
use
and
would
be
lovely.
If
you
know,
people
interested
in
automation,
east-west
communication,
like
the
use
cases
outlined
in
the
pap
document,
would,
for
example,
concentrate
on
refining
those
in
a
way
that
they
can
actually
build
as
application
of
grasp
right.
So
I
mean
there
is
no
need
to
reinvent
that
common
communication
protocol,
or
hopefully
using
the
best.
H
You
know
common
knowledge
of
the
itf
c
board,
tls
the
keying
material
right,
so
that
that
would
be
happy
to
do
in
conjunction
between
whoever
is
the
experts
on
the
use
cases
like
routing
protocol,
automation,
routing
working
group
and
enema
to
help
with
the
formatting
everything-
and
you
know,
yeah-
we
really
love
to
evolve.
You
know
our
networks
into
something,
that's
self-automating
and
doesn't
always
require
the
big
sdn
controller
called
mum
to
to
do
any
form
of
automation,
and
I
think
that's
it.
B
Oh
yeah,
why
don't
you
well?
Should
we
get
questions
from
g
first,
I
think
she
was
in
the
queue
first.
E
B
Oh,
I
think
she
said,
maybe
that
he
was
in
the
queue
accidentally,
so
we'll
just
go
ahead
with
robin
okay.
F
Robin
from
hawaii
told
us
thanks
very
much
for
the
information.
I
think
this
is
valuable
for
our
reference
to
design
the
pap
and
here
this,
because
you
know
that
we
propose
this.
The
discussion
on
the
in
the
in
the
php
presentation,
because
I,
according
to
my
understanding,
is
the
grasp
is,
is
based
on
the
tcp.
F
So
I'm
a
little
about
about
the
resource
resource
assumption,
because
you
know
that
if
the
pep
is
used
to
locate
the
error
of
the
pdp,
so
maybe
we
have
to
set
up
the
full
mesh.
The
the
tcp
appears
with
the
fulfillment
of
the
peers.
So
I
think
that's
maybe
a
challenging
work
for
the
pap,
because
you
know
the
pdp
for
mesh
already
proposed
a
challenge
for
the
operation.
I
think
for
the
pvp
is
only
for
the
network
of
monitoring,
so
that
is
also
to
set
up
the
full
mesh
tcp
based
up
here.
H
So
grasp
itself
doesn't
really
specify
the
underlying
transport,
so
we've
basically
outsourced
that
to
a
component.
We
call
the
security
and
transport
underlay
for
for
grasp
right.
We
define
grasp
messages
and
those
can
be
you
know,
put
into
tls.
They
can
be
put
into
dtls.
They
can
be
put
into
quick,
they
can
be
put
into
any.
You
know
secure
underlying
transport
protocol
you
want
and
then
they
can
be
nicely
standardized
in
the
itf.
H
Of
course,
you
can
also
try
to
simply
put
the
grass
messages
inside
of
udp
or
tcp
or
anything
insecure,
and
you
can
make
it
perfectly
well
work
in
your
network.
You'll
probably
just
have
problems
getting
through
the
security
area
with
you
in
the
ietf
to
get
it
standardized
and
that
isn't
a
grass
problem.
That
is
something
that
is
ipf
expectation
that
would
apply,
I
think,
equally
to
any
protocol
like
if
you
reinvented
grasp
and
faulted
pep.
I
think
the
same
type
of
you
know,
transport
considerations
in
the
ietf
would.
B
I
B
Okay,
well
at
this
point:
let's
go
with
brian,
then
what.
J
Yeah
hi,
so
the
prototype
code
that
taurus
mentioned
is
my
code,
and
I
should
say
that
it's
full
of
disclaimers
saying
this
is
this
is
not
yet
ready
for
production
use,
but
you
know
that's
a
problem
that
could
be
solved.
Probably
what
I
wanted
to
comment
on
is
I
looked
in
one
over
tcp
or
tls
at
the
moment,
mainly
tcp,
but
I've
looked
at
what
would
be
involved
in
switching
to
udp.
J
The
messages,
of
course,
could
perfectly
well
be
wrapped
up
in
udp,
packets
and
set,
but
my
impression
was
that
all
the
overhead
that
tcp
allegedly
adds
I
would
have
to
add
back
into
my
code
just
to
make
sure
that
udp
messages
were
delivered
to
the
right
recipient
to
the
right
session,
the
right
thread
and
a
threaded
implementation,
and
you
would
also
have
to
put
in
more
recovery
logic,
because
udp
doesn't
do
that
for
you.
So
I'm
not
at
all
convinced
that
there's
an
efficiency
argument
against
using
a
transport
layer.
H
And
I
think
you
know,
through
the
years
in
enema,
we've
seen
a
lot
of
opinions
about
transport
layers.
So
I
think
that
the
prudent
thing
is
obviously
to
define
the
message:
protocol,
independent
of
the
transport
and
the
security
as
we've
done
in
grasp
and
then
basically
let
the
chips
of
the
itf
fall.
Whatever
the
wisdom
is,
so
I
think
if
we
had,
for
example,
more
iot
people
in
here,
they
would
come
and
say
that
you
know
some
even
lower
overhead
things
that
based
on
udp,
is
really
crucial
and
very
low-end
devices.
H
You
know
that's
why
they
did
co-op
to
avoid
tcp
and
that's
that's
based
on
udp.
So
I
don't
think
there
is.
You
know
a
industry-wide
common
understanding
of
what
the
best
transport
is
and
that's
how
we
why
we
did
grasp
the
way
we
did
it.
F
H
Yeah
I
mean,
as
I
said
I
would
I
would
really
love
if
you
folks
would
think
about
you,
know,
refining
and
building
and
proposing
drafts
for
the
actual
examples
you
gave
in
terms
of
bgp,
and
I
forgot
the
other
one
in
terms
of
you
know
what
automation
it
is
you
want
to
do
right
within
enema.
Obviously,
you
saw
this
slide
on
the
securing
protocol.
H
So
if
I
had
more
cycles-
and
some
other
folks
would
love
to
basically
build
those
asas,
there
are
a
couple
of
asa
examples
that
brian
said
are
in
code,
we're
also
having
some
asa
with
negotiation
coming
into
rfcs.
So
I
think
we
we're
starting
to
build
this
framework
of
the
self-automation
thing.
So
would
really
invite
anybody
from
the
routing
working
group
interested
in
that
automation
to
see
what
they
are
interested
to
contribute
and
they
wouldn't
need
to
worry
about
the
encoding
crap,
which
we
could
happily
take
care
of.
B
Yeah
thanks
a
lot.
I
mean
this.
This
does
seem
like
a
a
pretty
good
way
to
bootstrap
the
sort
of
the
use
cases,
and
you
know
we
could
spend
a
year
or
two
discussing
encodings
for
for
pap,
but
instead
you
know
it
makes
sense
to
yeah.
Try
these
use
cases
in
the
existing
encoding.
B
You
know
see,
it
seems
like
you
would
get
a
lot
of
benefit
from
a
reliable
transport.
To
begin
with,
you
wouldn't
have
to
worry
about
a
lot
of
protocol
stuff.
If
you
could
just
be
sure
that
messages
were
getting
received.
So
so
you
know
that
that
would
be.
B
I
think,
a
pretty
good
way
to
to
get
this
well
bootstrapped.
As
I
said,
or
moving
moving
along
faster
with
you
know,
solid,
more
convincing
use
cases.
H
Yeah,
I
I
I'm
trying
to
remember
there
was
this
one
effort
to
try
to
unified
and
build
better.
You
know
common
security
for
the
different
routing
protocols
and
I
think
that
ended
in
pretty
much
nothing.
So
you
know
if
if
people
also
think
that
the
securing
of
the
router
routing
protocol
is
still
something
that
you
know
the
industry
struggles
with,
I
you
know
I
haven't
followed
track
with
that.
You
know
beside
the
other
operational
examples
given
in
the
pep
draft
right.
I
think
the
securing
might
be
something
that
could
be
most
easily
done.
H
C
C
K
Olivier,
thank
you.
Do
you
hear
me?
Yes,
yes,
okay,
so
this
is
a
presentation
of
working
progress,
which
is
a
paper
that
was
published
a
few
weeks
ago.
This
is
joint
work
with
chain
contact
according
randy,
busch,
lauren
van
bever
and
myself
next
slide.
K
So
if
we
look
at
the
evolution
and
the
standardization
within
the
itf-
and
this
is
an
example
that
we
looked
at
the
idea
working
group-
and
we
tried
to
understand-
what's
the
delay
between
the
first
id
about
a
new
extension
to
bgp
and
the
publication
of
the
rfc
and
on
the
figure,
you
showed
that
the
standardization
delay
for
some
rfcs
takes
up
to
10
years
and
the
median
delay
is
about
3.5
years.
So,
every
time
we
have
a
new
id
that
needs
to
get
into
bgp.
K
K
Basically,
we
have
networks
with
multiple
vendors
and
each
vendor
has
its
own
configuration
command,
and
so,
as
an
operator,
we
need
to
tackle
this
diversity
in
configuration
comments
and
the
solution
to
that
is
to
go
with
netconf
and
yang,
but
this
works
only
for
features
that
are
configured
inside
the
network.
Next
slide.
K
And
we've
seen
over
the
last
years
many
examples
such
as
this
one
from
robert
and
others
asking
new
bgp
options
and
new
bgp
extensions
that
that
have
been
discussed
for
several
years
and
in
this
example
the
the
document
was
requesting
a
new
bgp
attribute
that
would
allow
to
encode
geolocation
and
other
types
of
information.
Eventually,
it
was
not
accepted
by
the
working
group
and
it
was
never
standardized
and
implemented,
but
there
are
use
cases
and
there
are
operators,
maybe
small
ones.
K
K
So
the
question
that
we
ask
ourselves
in
in
this
paper
is
that
is
there
a
better
way
to
organize
bgp
implementation
and
routing
implementation
in
general,
so
that
we
can
address
this
extensibility
and
the
flexibility
which
is
required
by
network
operators,
and
we
propose
xbgp
as
a
paradigm
shift
for
bgp
implementation.
But
the
idea
is
applied
to
other
routing
protocols
as
well.
Next
slide.
K
So
what
we
propose
is
that
each
xbgp
router
would
expose
a
simple
api
that
allows
to
dynamically
extend
the
protocol
with
platform
independent
code
that
we
call
plugins,
and
these
plugins
can
be
developed
by
network
vendors,
but
also
by
network
operators,
so
that
they
can
extend
the
features
of
the
bgp
protocol
that
are
used
inside
our
network
by
downloading
extension
code
directly
on
the
routers
and
the
solution
that
we
propose
is
that
to
have
a
plan
for
a
vendor
independent
api
that
allows
to
run
these
extensions
on
different
vendors
on
routers
from
different
vendors.
Next.
K
Slide
so
different
routers
expose
the
the
same
api
and
you
you
could
consider
a
routing
protocol
implementation
as
a
kind
of
microkernel
that
exposes
a
set
of
system
calls
and
by
using
this,
this
system
calls
you
can
extend
the
routing
protocol
and
we
have
done
that
with
bgp,
and
let
me
explain
you
briefly
how
we
did
that
with
bgp
and
how
the
solution
works.
So
next
slide.
K
So
if
you
look
at
the
bgp
specification
in
the
bgp
specification,
there
is
no
api
that
every
bgp
implementation
should
implement.
But
if
you
go
more
deeply
in
the
rfc
4271,
you
can
see
that
the
processing
of
the
bgp
messages
follow
the
workflow
that
all
bgp
implementation
needs
to
apply.
So
typically,
what
happens
is
that
when
you
receive
a
bgp
message
from
your
peer
on
the
left,
it
first
go
to
the
import
filters
and
you
have
an
attribine
that
needs
to
be
maintained
by
the
water.
K
Then
the
the
routes
that
are
accepted
by
the
by
the
import
filters
will
be
placed
in
the
lock
rib
and
then
the
lock
rip
contains
is
a
data
structure
that
contains
all
the
acceptable
routes.
It
runs
through.
The
bgp
decision
process
that
select
the
best
route
towards
each
prefix,
then
the
best
route
are
downloaded
in
the
field
and
then
we
we
use
the
export
filter
to
send
new
messages
to
the
peer.
K
So
by
looking
at
that
by
looking
at
this
workflow,
we
can
identify
next
slightly
several
places
inside
the
the
implementation
that
are
shown
with
the
the
green
circles.
Where
you
have
you,
you
do
special
processing
on
the
bgp
messages,
and
these
are
the
key
locations
of
any
bgp
implementation
that
you
could
want
to
modify
if
you
wanted
to
implement
new
stuff
in
a
bgp
implementation
next
slide.
K
K
K
I
need
to
be
able
to
compute
in
the
decision
process,
for
example
the
geographical
distance
between
the
road
that
I've
received
and
multiple
routes
that
I've
received
with
the
geolocation
attribute,
and
then
I
need
to
be
able
to
send
the
geolocation
attribute
to
my
peers
over
ibgp
sessions.
How
do
I
do
that
next
slide?
K
Please?
So
I
will
inject
these
different
code
inside
the
bgp
implementation
at
the
location,
so
the
decoding
will
be
part
of
the
code
that
receives
bgp
message
from
the
pier
the
locating
the
nearest
router
will
be
part
of
the
bgp
decision
process
and
the
serialization
will
be
part
of
the
code
that
sends
messages
to
the
peer
now.
The
question
is:
how
can
I
execute
a
code
that
comes
from
the
network
operator
on
routers
from
multiple
vendors
and
next
slide?
K
Please
so
the
the
solution
that
we
use
is
that
so
we
have,
we
add
libx
bgp,
which
allows
to
to
connect
to
data
structures
in
the
routers
and
extract
additional
information
from
the
router,
such
as
the
configuration
file
next
slide
so
now
to
execute
the
plugin.
K
K
So
basically
we
had
to
do
small
changes
to
the
code
base
of
these
two
implementations.
We
have
changed
a
few
tens
of
lines
to
implement
the
five
insertion
points
that
I've
mentioned.
We
have
developed
a
plug-in
api
that
allows
to
limix
bgp
to
extract
information
for
the
from
the
host,
such
as
the
the
neighbor
table
and
things
like
that,
and
then
we
have
we
added
an
existing
ebpa
virtual
machine
and
limix
bgp.
K
So
to
demonstrate
the
the
feasibility
of
the
approach
we
have
re-implemented
rot
reflectors,
so
the
cluster,
the
different
attributes
that
are
used
by
to
do
rot
reflection
and
this
costed
us
about
300
lines
of
code.
We
have
added
new
filters
to
do
rot.
Origin
validation
to
support
valet
free,
pass
check
in
data
centers,
and
we
have
implemented
the
geolocation
attribute
and
there
are
additional
information
in
the
in
the
paper
and
there
is
running
code
next
slide.
K
So
to
to
summarize
with
xbgp,
you
can
think
as
of
your
bgp
implementation
and
more
generally,
of
your
routing
protocol
implementation
as
a
kind
of
microkernel
operating
system
that
exposes
an
api
which
can
which
allows
network
operators
and
researchers
to
run
code
that
allows
to
extend
the
protocol
itself.
So
there
is,
there
are
more
information
in
the
paper.
There
is
running
code
and
we
would
be
interested
in
discussing
with
network
operators
and
other
bgp
implementers
to
discuss
the
approach
and
to
see
how
the
approach
can
be
improved
and
can
extend
to
other
routing
protocols.
K
K
A
Hopefully,
you
can
hear
me
this
time.
Yes,
thank
you,
so
olivier.
Thank
you
for
the
presentation,
so
I
I
think
the
the
nice
thing
that
is
an
output
of
this
presentation
is
that
yes,
plugins
can
be
done
for
allowing
code
to
be
hooked
externally.
You
know
the
linux
kernel
is
an
excellent
example
of
that.
A
The
the
challenge,
I
think,
that's
not
really
covered
in
the
paper
or
at
least
the
presentation
here
of
the
paper,
is
most
of
the
headache
for
bgp
is
really
incremental
deployment
issues.
So
writing
code,
isn't
all
that
bad
getting
code
that
can
run
in
implementations
that
are
scattered
around
the
internet
and
follow
b2b
rules
in
terms
of
validation
and
such
that's
the
main
challenge.
So
I
agree
that
having
plug-in
frameworks
is
actually
a
very
useful
thing,
but
I
think
that's
not
necessarily
the
hard
problem
here.
K
But
I
think
there
are
benefits
in
being
able
to
deploy
extension
inside
an
ais
so
for
ib
gp.
Only
so
doing
it
over
external
bgp
is
much
more
difficult,
but
for
ib
gp
I
think
it
makes
sense
and
it
could
address
some
use
cases
for
network
operators
that
have
specific
requirements,
and
it
could
also
allow
network
operators
or
network
designers
to
develop
new
extensions
before
they
are
being
discussed
within
the
itf,
and
so
you
could
get
you
could
get
information.
K
A
Understood
I'll
leave
my
comments
with.
I
agree
with
you
that
doing
this
is
not
hard
and
that,
if
you
contain,
as
I
would
call
it
the
blast
radius
of
this
problem,
to
something
that's
strictly
internal
you're
right
that
this
is
not
too
much
of
a
problem,
but
the
blast
radius
is
really
the
discussion.
A
H
I
Hi
I'm
jared
moch
akamai,
so
so
I
think
this
is
interesting,
but
I
have
a
lot
of
concerns
here,
specifically
around
deployability
and
usability
and
testing.
I
So
if
we
were
to
do
this,
I
you
know
similar
to
what
jeff
was
talking
about
with
the
attribute
128
issue,
of
which
I'm
still
trying
to
get
the
config
out
of
our
many
of
our
network
devices.
For
you
know,
because
we
we
have
a
variety
of
code
bases
that
we
still
run
I'm
concerned
about
what
happens
when
we
deploy
these
plugins
and
they
have
different.
I
You
know
different
results
across
different
vendors
and
how
that
kind
of
bug
ecosystem
interacts,
because
it's
one
thing
to
specify
a
protocol
and
a
method
for
transporting.
You
know
this
this
meta
code,
but
it's
a
whole
nother
thing
to
discuss
what
that
operational
impact
is-
and
I
I
think,
similar
to
what
jeff
commented
about
about
the
internal
use
cases
versus
external
use
cases.
I
We
have
a
lot
of
internal
use
cases
where
we
transport
hd
data
and
signal
that
around
our
you
know,
our
internal
infrastructure
and
those
use
cases
tend
to
not
really
align
with
what
shows
up
in
the
public
internet
and
a
lot
of
what
happens
is
people
have
maybe
more
fine-grained
signaling
that
they
want
to
do
for
geo-location
than
what
you
actually
want
to
announce
in
the
routing
table
as
a
result.
I
So
I'm
very
concerned
about
something
like
this
and
what
happens
in
the
operational
use
case
when
we
have
a
lot
better
things
like.
If,
if
we
want
to
signal
you
know
geo
feed
data
or
something
there's,
the
geo
feeds
rfc
that
that
was
recently
published.
I
There
was
discussion
last
week,
iepg
meeting
about
how
to
actually
go
and
potentially
authenticate
and
sign
that
data
to
provide
more
granular
information
than
what
you
actually
want
to
publicly
expose
in
bgp.
So
this
is
definitely
an
interesting
idea,
but
I,
I
really
fear
the
unintended
side
effects
that
that
this
is
going
to
introduce
and
instability
that
I'll
create
as
a
result.
K
Yes,
so
I
I
think
there
are
two
different
parts
of
the
presentation
and
there
are
two
different
elements.
So
the
first
one
is
the
ability
to
consider
a
routing
protocol
as
a
let's
say,
a
kind
of
microkernel
operating
system
that
exposes
an
api
and
it
allows
you
to
extend
it,
and
this
is
this
is
generic.
K
And
although
we
implemented
in
bgp,
because
it
was
easy
for
us
to
extend
bgp
and
to
do
tests
with
bgp,
we
believe
that
it
can
apply
to
an
e-writing
protocol
and
that's
why
we
discuss
with
jeff
to
present
that
here,
because
this
is
an
idea
that
is
generic
and
that
would
be
applicable
to
any
routing
protocol.
I
agree
with
you
that
doing
that
over
external
bgp
session
and
over
the
public
internet
is
something
that
would
be
between
brackets
dangerous
and
that
would
need
to
take
much
more
care
to
be
able
to
do
that.
K
So
this
is
a
research
prototype
which
is
intended
to
show
that
you
can
extend
routing
protocols,
and
you
can
view
the
routing
protocol
as
a
different
way
and
for
the
bgp
extensions
and
for
the
bgp
use
case.
We
are
focused
on
internal
bgp
issues.
We
don't
consider
external
bgp
as
a
possible
solution
right
now,.
L
Taking
take
taking
taking
taking
up
the
definition
of
root
manipulation,
quite
obviously,
quite
obviously,
when
you
provide
agile
development
for
complex
systems,
you
introduce
from
some
fragility
and
you
need
to
control
very
carefully,
and
that's
that's
that's
where
I
certainly.
I
certainly
see
jeff's
point.
L
L
Are
are
done
by
the
operators
and
in
the
bgp
case.
That's
quite
that's
quite
clear
that
the
policy
definitions
that
are
available
to
the
operators
and.
L
Exactly
points
to
to
a
pro
to
the
control
problem,
that
jeff
was
mentioning.
L
L
So
kind
of
I
see
I
see,
I
see
an
opening
with
your
approach
to
actually
to
actually
to
actually
allow
users
to
do
much
nicer
and
much
better
controlled
stuff
for
extending
functionality
and
customizing
functionality.
L
Certainly,
with
great
power
comes
great
responsibility,
and
yes,
it
it
should
not
should
not
be.
It
should
not
be
abused.
Abuse
will
happen
nevertheless,
but
the
agility
that
comes
out
of
a
proposal
like
this,
I
think,
is
pretty
much
needed.
Thanks.
K
Yeah,
so
maybe
let
me
try
to
to
answer
a
bit
some
of
your
concerns,
so
you
mentioned
that
operators
do
a
lot
of
with
bgp
communities
to
implement
the
policies
and
basically
the
bgp
communities
is
an
add-on
solution.
So
you
have
to
play
with
root
filters,
use
with
access
control
list
with
root
maps
and
stuff
like
that
to
be
able
to
implement
the
policies
that
operators
want
on
the
other
side
by
using
xbgp.
What
you
have
is
that
you
have
a
standard
programming
language.
K
You
know
you
know
prototype
dc,
but
this
could
be
another
language
and
when
you
have
standard
programming
language,
it's
also
possible
to
use
software
validation
techniques,
where
you
can
specify
the
properties
that
the
plugin
has
to
be
able
to
support
to
be
able
to
be
acceptable
by
a
router.
So
obviously
we
don't
want
a
plugin
that
that
runs
forever,
but
we
can
have
properties
that
are
defined
formally
and
we
can
design
tools
based
on
the
progress
in
software.
M
Thank
think
thanks
for
good
presentation,
I
have
one
concern
which
potentially
possible
to
mitigate
feature.
Velocity
by
itself
is
good.
It's
a
good
issue,
but
unfortunately,
for
majority
of
temco
worldwide
multivendor
interpretability
is
more
important.
Unfortunately,
the
future
velocity
could
not
be
trade
off
to
instead
of
multi-vendor
interoperability.
What
I
see
here
is
the
risk
for
multi-vendor.
Interoperability
is
the
api.
The
api
should
be
exactly
the
same
for
all
implementations
of
all
vendors.
On
the
previous
slide,
we
have
seen
that
for
two
current
implementation.
M
In
one
case,
you
have
400
api
calls
in
that
case,
600
api
calls
it's
a
very
big
alarm
for
me,
big
alarm,
because
it
looks
like
you:
don't
have
mature,
stable
api,
which
you
could
really
demand
from
all
vendors,
and
it
means
it
means
that
there
would
be
no
multi-vendor
interoperability
and
it
would
be
no
multicultural
interpretability.
I
believe
this.
This
particular
good
effort
will
not
be
accepted
by
the
market.
Therefore,
from
my
point
of
view,
you
could
mitigate
multi-vendor
credibility
problem
if
you
will
clearly
specify
and
make
it
mandatory.
M
K
Yes,
so
just
to
answer
your
comments,
so
we
have
a
very
simple
api
which
is
available
on
the
website
that
I
can
provide
the
slide.
That
jeff
shows
here
shows
the
number
of
lines
of
code
that
we
have
to
change
to
far
routing
and
to
bird
to
be
able
to
be
able
to
implement
the
api.
G
C
C
Olivia,
thank
you
so
much
for
coming
over
and
sharing
your
work.
It's
always
exciting.
Thanks
for
the
invitation,
I'm
looking
forward
to
hosting
you
any
time
been
working
together,
probably
10
past
years.
So
it's
great
thank
you.
Everyone
for
joining
us
tonight
or
this
morning,
and
we
will
see
you
virtually
again
in
4
months.