►
From YouTube: IETF100-BESS-20171117-0930
Description
BESS meeting session at IETF100
2017/11/17 0930
https://datatracker.ietf.org/meeting/100/proceedings/
A
C
C
C
C
Just
small
heads-up
on
on
the
inner
flags
will
be
moving
quite
happily
from
the
adoption
to
working
group
Lascaux
because
it
depends
another
document.
Foxy
Efendi
depends
on
it
and
it's
ready
from
working
or
plastic.
Also.
We
want
to
advance
these
two
documents.
Together,
we
have
a
bunch
of
documents
in
our
hands
Ali.
Is
there
or
not?
D
D
C
C
E
C
D
Back
to
the
previous
life,
with
respect
to
the
ping,
we
got
pink
and
BFD
draft
and
the
pink
LSP
VPN
Alice
with
pink.
That
is
in
pretty
good
shape,
and
we
would
like
to
request
working
group
call
on
that
and
we've
we've
had
several
iterations
of
it
and
the
last
review
we
had
there
were
a
couple
of
you
know.
There
were
a
couple
of
minor
tweaks
that
needed
to
be
done,
which
we
did
that,
but
it
is
in
pretty
decent
shape.
Can.
D
C
C
So
yeah
I
was
saying
we'll
be
working
closely
with
NBO
three
from
now
on,
as
a
working
in
nvo,
three
on
genève
develops
and
they'll
be
working
on
applicability
statements
and
we
will
likely
be
working
on
control,
plane,
extensions
for
that
so
watch
out
for
documents
in
both
groups
and
be
ready
to
review
them
as
they
go
through
their
important
phases
like
adoption
and
that's
called,
but
also
anytime.
Adrian
Adrian
wants
to
speak
on
LTS
on
so
I'm,
giving
in
the
mic.
F
Thanks
Martin
I'm
Adrian,
Farrell,
co-chair
of
L
to
SM
working
group.
We
produce
a
young
model
for
representing
a
layer,
2
VPN
service
between
an
operator
and
the
operators,
customer
so
not
down
in
the
bits
and
bytes,
but
a
description
of
the
service.
Our
young
model
is
reaching
completion
and
we
would
particularly
like
people
to
review
it,
obviously,
especially
operators,
because
they
are
the
consumers,
but
it's
also
valuable
to
have
input
from
people
who
understand
the
delivery
of
l2
VPN
services.
So,
just
to
remind
you
again
that
this
is
not
how
you
build
the
service.
F
G
G
G
G
G
H
H
There
was
a
prototype
and
I
cannot
say
that
for
network
management,
data
stores,
architecture,
an.
E
H
G
H
H
H
If
he
excuse
me,
would
you
go
back
three
slides
one
keep
going,
keep
going
one
more!
Okay
in
here
there
was
a
tunnel
MPV,
SPD
tunnels.
There's
a
tunnel
attribute
out
of
idea.
Do
we
need
to
have
these
yang
models
interacted
if
you
think
so,
then
I'll
dig
into
it
along
with
this.
It's
ID
ours
fault,
because
we're
late
in
getting
the
base
stuff
out,
but
we
don't
have
an
augmentation
to
our
base
for
our
tunnel
attributes.
H
H
G
G
I
E
K
K
Let's
first
take
a
look:
how
the
MS
DP
works.
Very
quick
review
in
this
picture.
I
have
six
RP
s
used
for
PM
ESM.
We
have
first
hop
router
on
the
upper
right
corner.
It's
a
sense,
pin
register
messages
towards
RP
1,
so
RP
1
now
learns
the
source.
It
was
an
MSD
P
source.
Active
messages
to
other
are
peds.
Eventually
it
arrives
at
RP.
6
are
there
is
a
last
hop
router,
that's
connected
the
receivers.
His
sensor
start
GTO
and
pin
start
showing
towards
RP
6,
and
he
stops
there
and
now.
K
Rp
6
has
a
star
G
going
and
it
also
has
si
messages.
So
now
he
has
this
as
the
source
information
as
a
as
a
group
information
now
RP
6
will
send
up,
pin
as
she
joined
towards
the
first
hop
router.
So
this
is
how
how
PASM
works
with
with
the
MS,
DP
and
multiple
our
piece
notice
that
in
this
picture
the
we
have
continuous
beams
MSTP
sessions
among
those
are
peds.
K
My
pin
has
a
similar
situation
here
we
have
four
p's
connected
to
connected
by
this
provider
or
network
at
the
top.
We
have
the
customer
harpie
particular
VPN,
and
it
discovers
the
sources
information
from
the
first
hop
router
and
between
pu.1
and
CRP,
the
customer
are
Peter.
There
is
M
SDP
session,
so
the
PE
one
learns
the
from
by
the
MSTP
message
and
therefore
it
was
sends
a
VPN
source
active
routes
into
two
other
peds.
Now,
in
this
picture
notice
that
at
the
bottom
we
have
a
c
e,
and
that
is
not
a
customer
RP.
K
K
Therefore,
the
star
G
join
from
the
last
hop
router
was
stopped
there.
It
does
not
go
to
p3
anymore.
On
the
other
hand,
while
a
PE
advertise
MA
MVPs
a
routes
from
received
MSD
PMS
G,
it
does
not
do
the
other
direction.
So
P
is
3.
When
p3
receives
the
MVPs
a
rose,
it
does
not
send
the
MSTP
si
to
CR
P
2.
Now
we
have
a
disconnect,
so
the
PE
3
has
the
source
information,
but
it
does
not
have
the
stars
which
you
stadium
from
group
information.
K
The
CRP
too
has
the
star
G
information,
but
it
does
not
have
the
source
information.
Now,
it's
disconnected
so
to
fix
this
problem.
We
have
to
have
MSTP
session
either
between
p1
and
p3,
or
between
p1
and
CRP
2,
or
between
CR,
P,
1
and
P
is
3
so
that
we
can
have
continuous
MSTP
session
the
this
is
it's
just
oversight
or
in
the
original
MVP
and
specification
it
didn't
consider
the
situation
now.
Those
additional
MSTP
sessions
will
are
not
desired.
For
two
reasons.
Why
is
that?
So
those
sessions
are
per
variants.
K
The
different
VPNs
wouldn't
have
only
different
people
session
of
those
MSTP
sessions
and,
additionally,
those
those
additional
MSS
MSTP
sessions
will
cause
excessive
ma
PSA
roles.
In
this
example,
PE
one
learns
the
sources
from
CRP
one
year,
weather
has
mm
dpns
a
routes
and
p3
learns
the
same
source
either
from
PE
1
or
from
CRP
1
over
the
MSTP
session
will
do
the
same.
So
now
we
have
too
many
Mbps
erodes.
K
So
the
solution
is
quite
simple:
it's
just
something
that
we
didn't
consider
in
the
original
VPN
now
for
when,
when
you
have
when,
when
IP
receiver,
VPS
aids,
and
if
it
also
has
MS
to
be
session
to
another
peer,
then
you
will
just
trigger
MSD
BSA's
from
those
MEP
estates.
K
K
We
I
presented
this
in
the
M
bonding
session
as
well.
I
got
a
good
comment
back.
That's
in
this
situation.
We
are
using
MSD
P's
between
those
harpy's,
but
in
other
modes.
To
work
with
multi
bar
appears
is
that
you
to
know
user
MSTP,
but
you
just
for
pin
register
messages
among
those
are
peds,
so
the
desta
dead
mode
is
very
similar
here,
and
the
solution
should
also
cover
that.
K
So
we
are
seeing
a
seeking
the
working
group
comments.
I've
already
got
some
from
n
boondi
session.
The
solution
here
is
quite
simple,
and
the
scenario
problem
is
narrow
is
real.
We
got
run
quite
run
into
this
situation
quite
often
so
I'm
actually
trying
I'm
seeking
organ
group
adopted
op
adoption
now
this
so
that
we
can
move
forward.
K
K
So
we
they
still
need
a
solution
and
BGP
signal.
Multicast
can
can
be
a
solution,
can
provide
some
mitigation
and
to
their
to
whether
is
to
their
discomfort,
or
these
add
order
to
the
complexity
they
they
have
to
face
with
the
podcast
that
they
have
to
deploy.
So
essentially,
it's
just
to
use
BGP
to
signal
Marquez,
trees
or
set
of
signal.
K
Mld
Peeta
notes,
it's
just
a
replacement
with
that
with
the
BGP
signaling,
we
can
remove
PIM
soft
states
and
we
can
remove
him
a
SME
complexities
and
we
can
consolidate
BGP
signaling
and
apparently
we
were
with
s
our
network
and
some
operators
are
quite
eager
or
to
remove
additional
protocols
from
their
network
and
the
BGP.
It
will
be
a
good
choice
for
them.
K
Going
to
skip
this
slide,
it's
covered
in
the
inner
drafts.
It's
basically
you
just
use
the
P
messages.
Replaced
up
in
your
speech,
be
messages
to
replace
P
messages
or
replace
em
LDP
paper
mapping
and
the
reason
for
the
that
addresses
PASM
complexity
is
that
we
use
the
BGP
methods
that
discovery
to
discover
our
sources.
Then
the
last
hop
routers
was
just
establish
your
source
Pacific
trees
towards
the
sources
directly
instead
of
going
through
the
surgery
and
because
it
replaces
a
pain
or
ml
DP
to
set
up
the
trees
or
tunnels.
C
C
K
But
that's
okay,
I'll
just
explain
so
here:
I
have
five
routers
r0
is
the
root
of
the
tree.
We
have
two
routers
at
the
bottom,
three
and
four,
the
last
hop
routers.
So
our
three
needs
to
join
the
tree,
so
it
sends
a
BGP
message
towards
the
r1
that
that
message
can
be
either
through
the
overall,
a
diuretic,
the
read
pgb
session
or
acquittals,
who
are
in
this
picture.
It
goes
through
ours.
K
K
Because
note
so
in
this
mall
mode,
you
notice
that
our
are
in
the
middle.
It's
it's
sent
reflecting
them
routes
back
to
the
routers.
Now,
if
you
think
that
you've,
what
if
you
replace
that
are
with
a
controller,
the
controller
that
knows
everything
that
knows
the
topology
in
those
the
rules
and
all
the
lives
and
it
can
use
whatever
algorithm,
whatever
input,
whatever
constraints
to
calculate
that
tree.
So
once
the
controller
figures
out
their
tree,
you
can
just
directly
go
to
each
router.
Also
is
router
set
up
the
falling
state.
K
Then
that
way-
and
you
can
do
that
using
the
same
messages
that
we
propose
to
use
for
the
harbor
hub
receiver
initiative
trees
with
that
the
the
routers
become
very
simple,
they
don't
do.
Don't
need
to
do
the
orders
RPF
thing
to
the
figure
out
where
my
upstream
is
now
the
errata
just
become.
This
is
like
a
static
I
set
up
set
across
you
accept
that
that's
the
static
routes
are
coming
from.
The
controllers.
I
have
a
question
from
operational.
L
K
So,
in
the
old
days
peace
be
free
core
often
used
for,
for,
for
the
unicast
and
in
the
nowadays
bgp
is
become
more
and
more
popular.
In
some
networks
they
did
some
customers,
they
like
to
run
PHP
on
every
step
and
and
also
on
other
hands.
Even
we
use
PGP
here
how
about
hop
on
every
router
those
those
PHP
sessions,
and
they
do
not
have
to
be
used
for
unicast.
It
could
be
only
used
for
for
multicast
understands.
L
L
K
K
K
So
now
there
are
two
differences
from
from
the
hopper
hop
signal
case.
First,
one
is
that
in
the
hubba-hubba
case
notice
that
our
zero
has
two
down
streams,
so
you
would
need
two
are
0.
We
need
to
receive
two
peach
B
message,
one
from
each
downstream
to
set
up
the
state
with
the
controller.
The
controller
are
only
need
us
in
the
one
Beach
Marina
is
messages
to
the
upstream
and
specify
all
the
downstream.
You
know
in
the
panel
attribute,
so
here
we
propose
to
use
user
composite
a
new
composite
handle
that
base
it
lists.
K
All
the
component
panels
that
you
want
to
send
traffic
out
of
another
difference
is
that
the
label
allocation.
Now
we
this
gives
us
more
options
of
for
allocating
labels
in
the
label
tree
case.
It
could
be
that
the
label
could
be
allocated
from
the
controller's
own
label
space
or
it
could
be
allocated
from
the
akame
sRGB
or
is
just
like
allocated
from
EG
routers
local
local
label.
K
Block
that
that
the
controller
somehow
has
learned
in
the
first
two
cases,
you
can
actually
do
per
tree
label
in
a
unidirectional
tree
or
we
can
do
per
tree
direction
label
in
the
bi-directional
tree
case.
This
could
simplify
the
routers
operation
because,
just
like
in
the
unica's
case,
yes,
our
network,
you
can
use
the
same
label
all
the
routers
for
particular
panel.
K
So
if
you
use
per
tree
label
or
per
tree
Direction
label,
then
you
need
to
use
additional
label
in
a
stack
to
identify
the
neighbor
and
you
do
the
RPF
checking
on
that
and
if
you
also,
if
you
allocate
the
label
from
the
controller's,
only
local
base
level
space,
you
have
also
you
need
another
label
to
identify
the
the
controller.
So
that's
a
base
test.
Basic
a
context
label
for
the
upstream
inoculate
was
the
case.
K
You
can
use
multiple
controllers
in
your
network,
they
can
calculate
tree,
they
can
say
to
the
signaling
independently.
As
long
as
all
the
routers
on
a
tree
or
on
panel
choose
the
routes
from
the
same
controller,
it's
going
to
be
fine,
and
even
and
in
a
labeled
case,
even
if
somehow,
the
different
routers
on
trees
choose
the
best
route
from
different
controllers.
You
will
not
even
know
the
traffic
forwarding
will
not
work
out
buddy.
We
will
not
cause
the
traffic
loop
I
already
mentioned.
K
D
D
This
is
a
proposal
for
both
IP
transport,
as
well
as
MPLS
transport
right
with
respect
to
the
IP
transport.
I
can
see,
you
know
some
benefit
for
it,
but
with
respect
to
the
MPLS
that
is
trying
to
replace
em
LDP
I
fail
to
see
the
benefit
I
mean,
except
what
you
mentioned,
that
you
know
reduction
in
number
of
four
accounts,
but
that
is
pretty
subjective.
Given
that
ml
DP
to
use
for
the
tree
sort
of
is
also
not
that
complex.
D
Right
I
can
see
some
network
like
an
MSP.
You
know
MSD,
see
kind
of
scenario
that
they
want
to
just
use.
Bgp
I
can
see
some
certain
scenario
that
that
can
be
applicable.
What
sort
of
they're
in
the
niches
so-
and
this
is
a
is
it
accurate
to
say
that
this
is
an
interim
solution
until
bill
comes
along.
K
So
this
is,
our
updates
are
intercepted
Marcus
for
evpn.
This
is
the
for
the
first
revision
of
the
drafts
we
have
Eric
Rosen
joined
as
the
as
the
editor.
Basically,
we've
revamped
the
drafts
with
a
lot
of
details
and
explanatory
materials,
and
also
we
have
enhanced
the
mapa
integration
section
and
we
have
the
additional
details
for
inter
working
with
legacy
peds.
K
First
I
review
the
key
concepts
of
this
optimized
in
their
southern
vodkas.
What
is
about
so
in
you
know,
let's
say
you
have
a
EVP
network
with
multiple
and
for
particular
tenants.
You
have
multiple
PDS
and
you
have
when
you
have
IP
multicast.
That
needs
to
be
delivered
to
receivers
in
different
biddies.
How
can
it
be
done
optimally
there?
K
If
you
don't
do
anything,
special
things
will
still
work
out,
but
there
will
be
some
inefficiencies
which
I
will
not
talk
about
in
this
presentation,
but
but
to
optimize
it.
We
have
defined
these
procedures.
How
to
do
it
when
so
you,
if
you
receive
a
eternal
frame
from
a
local
attachment
secret,
circuiting
@bd
you
just
to
look
a
little
switch
to
local
receivers
in
the
source,
PD
itself
and
also
switch
to
to
remote,
please
again
using
the
ER
to
tunnel
that
part
they're,
switching
it's
either
in
a
source,
PD
itself.
K
K
K
Receivers
in
that
BD,
but
here
we're
going
to
intercept
that
we
send
into
the
remote
receivers
and
on
a
remote
PE
when
you
get
a
frame
from
an
ear
to
tunnel
again,
you
switch
it
to
local
receivers
in
the
receiving
BD.
Remember
that
no
a
receiving
BD
could
be
a
source
feed
in
itself
or
it
could
be
the
speedy.
K
Additionally,
it
was
routed
to
our
B
interfaces,
to
local
again
to
local
receivers
on
other
babies
and
for
packets
from
my
external
source
outside
the
EVP
em.
We
just
routed
by
our
benefits
to
local
receivers
and
also
rotated
down
ARB
interface
to
the
Supplemental
through
BD
that
will
cause
layer,
2
tunneling
to
egress
piece.
Now
there
is
a
difference
between
the
third
bullet
and
other
and
order
to
put
bullets.
If
the
the
package
that
is
routed
down
SPDR
be
interface,
is
going
to
be
sent
across
the
core
to
remain
rural
feeds.
K
M
K
M
K
K
So
there
are
several
characteristics
we
want
to
emphasize
here,
the
first
most
importantly,
it
maintains
correct,
Ethernet
and
emulation
for
receivers
on
the
source
bit
itself.
You
see
a
unaltered
frame
same
source,
MAC
address
same
TTL,
whether
the
whether
the
receiver
is
had
attached
to
the
local
P,
the
ingress,
P
or
attached
to
egress
PE.
K
K
K
K
The
the
routing
or
replication
throughout
this
tenant
domain
itself
it's
optimal.
There
is
no
change,
EVP
multi-home
procedures,
the
spirit
horizon
label
based
procedure
for
ma
p,
an
infrastructure
or
the
local
biased
procedure
for
the
explained
and
infrastructures
work.
The
same
way
it
builds
on
top
already
deployed
features
as
manuals
and
RB
interfaces.
It
maintains
clear,
distinct
written.
They
are
near
to
a
nursery
Marcus.
K
K
Basically,
some
of
the
EVPs
become
become
a
gateway
to
the
tools
between
the
vaping
world
or
the
external
world.
We
we
called
max
EVP
and
basic
appears
as
a
stop
lend
to
external
network
and
those
the
gateways,
basically
as
first
hub
routers
to
the
external
network
for
the
sources
in
the
in
eBay
PM
or
it
becomes
the
last
hop
routers
for
receivers
in
the
EVP
em
in
the
MEP
in
case
the
max
wrong,
both
MEP
n
Andy
vaping
procedures
and
they
move
traffic
between
the
MVP
and
evpn.
K
K
We
designed
this
trying
to
follow
a
principle
that
no
entanglements
the
MEP
domain
even
domain
of
operate
independently,
so
that
we
can
have
a
clean,
clear
interface
between
the
two
domains.
Each
domain
has
its
own
native
control,
plane
and
data
plane.
The
interaction
between
those
two
planes
are
achieved
through
the
nursery
model
states
that
each
control
plane
recognizes.
K
Working
between
everything
EVP
is
achieved.
Basically,
operators
choose
which
piece
becomes
the
vacate
waste
of
the
max
it.
The
choice
work
depends
on
the
deployment
scenarios.
You
could
make
every
VPN
a
Mac
or
you
could
just
put
a
few
max
at
the
natural
entry
or
exit
points
to
a
DC
or
anything
between
just
purely
based
on
your
requirement.
K
If
you
want
need
optimal,
routing
and
replication
between
those
two
domains.
Obviously
we
want
to
put
the
max
along
the
best
path
speed
between
those
domains,
so
there
there
are
situations
where
you
may
need
to
put
every
EVPs
as
max,
but
we
try
to
avoid
that
as
much
as
possible.
So
the
reason
is
that
some,
adding
the
omitting
procedures
to
the
CVP
in
peace,
brings
added
added
complexities
within
configuration.
The
procedures
and
provisions.
K
K
K
So
if
you
have
an
EVP
and
receiver
and
a
media
sources,
if
that
receiver
is
attached
to
that
to
a
Mac,
then
the
Mac
will
just
use
ordinary
Olympian
procedure
or
to
poor
traffic
from
the
MVP
in
ingress,
PE
and
deliver
traffic.
The
local
receivers.
But
if
a
given
receiver
is
not
attached
to
that
Mac
advice
to
attach
to
it
not
the
different
different
EVP
in
PE.
K
K
I'd
I
have
a
picture
for
it
here.
In
this
picture,
example,
I
have
P
1
through
P
3,
a
p
0
through
p
3
p,
0,
1,
&
2
are
on
the
EVP
inside
and
PE
1
2
3
are
on
the
MEP
inside.
You
have
a
source
attached
to
multi-home
to
both
P
1
and
P
2
on
the
EVF
inside
and
as
the
source
being
a
multihomed
source.
It.
It
uses
its
out
hash
algorithms
to
to
choose
visioning
to
send
traffic
so
for
particular
flow
you
can
send
to
P
1
or
2
P
2.
K
Let's
just
say
that
it
sends
traffic
to
P
1
and
we
have
a
receiver
are
attached
to
a
mm
between
P
is
3.
Now
the
MEP
procedure
requires
p3
to
determine
which
key
is
ingress.
P,
in
this
case,
both
P
2
and
P.
1
could
be
a
potential
ingress
P
for
MVP
and
because
both
adder
has
the
same
unicast
ral
to
the
source.
K
K
So
here,
let's
just
say
that
ps3
picked
the
p2
as
the
MEP,
an
ingress
P,
but
the
source
is
sending
the
p1.
What
happens
using
the
EVM
procedure,
the
p1
would
deliver
trafficked
to
p2
using
PE,
VPN
and
p2
will
further
send
the
traffic
down
to
ps3
on
one.
We,
when
we
look
at
this
situation
before
for
a
moment,
we
thought
that
ok,
the
p1
could
just
send
the
source
active
routes.
We
receive
the
traffic
from
the
source
and
then
p3
would
which
is
p1
based
on
source
active
routes.
K
It
turns
out
that
is
not
use
applicable
Babel,
because
in
everything
procedures
we
do
not
use
si
routes
to
to
influence
our
an
ingress,
P
selection,
but
because
we
have
separated
EVP
and
they're
emitting
procedures.
Here,
the
p1
wasn't
traffic
to
p2
in
on
the
EVP
side.
Therefore,
no
matter
what
P
Street
shoes
on
visa
side
things,
we
will
still
work
out.
K
So
this
is
our
first
relation.
We
can
still
still
have
some
work
to
do
with
with
the
draft.
We
need
to
make
ensure
that
we
environment
with
the
new
pin
proxy
draft,
and
we
need
even
ensure
the
alignment
with
a
VPN
IP
Munich
has
interoperability
traps.
However,
we
have.
We
believe
that
it's
got
well
a
state
where
they
think
it's
quite
mature
that
so
we
would
like
to
request
our
walking
with
adoption
and
we
can
work
on
the
remaining
issues
collectively
in
the
working
group.
N
Jorge
ravelin,
nokia
speaking
a
second
sort
of
this
draft,
so
so
this
revision
I
think
it's
pretty
good.
It's
pretty
maturing,
especially
Eric
and
Jeffrey
have
done
a
great
job,
so
I
agree
with
Geoffrey
I.
Think
it's
a
at
this
point
in
time
as
it's
ready
for
a
working
group
adoption.
You
know,
I
also
wanted
to
reinforce
these
two
messages.
D
A
C
N
So
in
the
in
the
meantime,
my
name
is
Jorge
Rob,
Allen,
Nokia
and
I'm
I'm,
presenting
this
draft
a
VPN
and
I
PvP,
and
interoperability
or
interworking.
This
is
a
revision,
0
0,
but
there
is
a
long
history
behind
this
draft
and
a
lot
of
work.
The
basically
the
history
is
that
we
we
had
a
in.
In
the
past,
we
had
a
draft
that
was
addressing
the
a
VPN,
an
IP
VPN
interpretability,
and
we
also
had
another
draft
that
was
talking
about
the
BGP
path,
attributes
propagation
between
evpn.
N
So
the
the
authors
of
both
drafts.
Basically,
we
sit
down
and
we
said:
okay,
let's
doesn't
make
sense
to
have
two
drafts
to
address
pretty
much
the
same
solution.
So,
let's
start
from
scratch:
let's
a
merge
both
drafts
and
let's
address
all
the
concepts
in
a
single
draft,
so
we've
been
meeting
for
for
a
few
times
in
the
in
the
past
months,
and
this
is
the
result
of
it
of
it.
So,
even
though
it's
a
revision,
0-0,
there
is
a
lot
of
discussions
behind.
C
N
All
right,
Thank
You,
Martin
yeah.
So
this
is
the
list
of
authors
for
this
draft,
and
this
is
the
the
first
time
that
we
present
the
result
of
the
you
know.
Merging
of
the
end,
the
two
drops
I
was
talking
about
before
what
is
it
the
problem
we
try
to
solve,
so
we
see
more
and
more
EVP
M
being
deployed
for
for
layer
3.
N
So
we
all
know
that
is
a
great
evolution
for
VPLS
and
layer
2
services,
but
now
we
see
it
more
and
more
for
layer
3
and
not
only
in
the
data
and
data
center
environment,
but
even
in
other
places
too.
So
what
that
means
is
it's
at
some
point
you
will
have
tenants
that
have
C's
that
are
connected
to
evpn
domains
and
and
c
is
connected
to
IP
VPN
domains,
and
those
C's
must
be
able
to
talk
to
each
other.
N
So
in
other
words,
you
will
end
up
with
some
gateways
in
your
network
that
are
able
to,
you
know,
convert
from
a
VPN
to
IP,
VPN
and
vice-versa.
So
in
that
situation
we
need
to
solve
some
issues
or
some
potential
issues.
So
one
of
the
things
we
try
to
to
address
in
the
document
is
the
BGP
route
selection
across
the
different
Saffy's,
so
across
IP
VPN
and
a
VPN
for
the
same
prefixes.
N
We
also
try
to
address
do
prevention
that
you
could
end
up
with,
and
this
a
you
know
with
these
gateways,
and
the
other
thing
we
try
to
address
is
the
a
path
attribute
propagation
across
different
Saffy's.
So
it
is
in
the
draft.
If
you
start
reading,
you
will
see
that
we
devote
a
pretty
big
section
to
terminology.
We
think
it's
very
important
to
settle
on
the
terminology
that
we
are
using
in
the
rest
of
the
document,
and
here
we
talk
about
interworking
peace
and
interworking.
N
P
is
it's
actually
this
PE
that
has
to
receive
and
process
a
VPN
route,
and
now
IP
VPN
routes
in
the
same
might
be
Verve
for
the
same
tenant
and
these
interworking
PS,
because
they
need
to
handle
IP,
VPN
and
also
a
VPN.
They
will
have
like
an
IP
verb
pertinent
and
they
will
have
a
set
of
Mac
verbs
attached
to
those
IP
verbs
and
within
each
Mac
very
few.
You
may
have
one
or
a
multiple
broad
broadcast
domains
right,
that
is
a
VPN
terminology.
N
Now
you
can
have
also
MPLS
or
IP
tunnels
connected
to
IP
verbs
and
the
Mac
verbs
and
attachment
circuits
that
can
be
connected
to
again
either
broadcast
domains
in
a
VPN
or
the
IP
verve
directly.
In
addition
to
that,
you
will
have
your
your
BGP
module
handling,
multiple
Saffy's
and
128
Safi,
one
as
well,
and
a
VPN.
N
So
with
that-
and
there
are
three
very
important
concepts:
we
clarify
in
the
terminology
section
the
composite
P,
the
Gateway
PE
concept
and
the
concept
of
the
domain
itself.
Let's
start
with
the
and
the
last
one
a
domain.
So
what
we
refer
to
when
we
say
domain
is
basically
a
set
of
IP
verbs
that
provide
connectivity
for
the
same
tenant
and
those
IP
verbs
can
actually
handle
a
VPN
and
IP
VPN
routes
and
I.
Give
you
here
two
examples
so
that
you
can
actually
get
all
of
this.
N
What
this
domain
means
by
the
way
each
domain
has
a
domain
identifier
that
should
be
able
to
derive
or
configured
on
the
IP
verse
and
in
the
typical
DCI
solution
that
you
can
have
on
the
you
see
here.
On
the
left
hand,
side
of
this
slide.
You
normally
have
like
a
evpn
domains
in
in
data
centers
and
they
are
connected
by
an
IP
VPN
domain
in
the
web
right.
It's
a
typical
deployment
nowadays,
so
we
define
that
to
PS
are
in
the
same
domain.
N
If,
in
the
data
path,
there
are
no
tenon
IP
lookups
required
in
any
intermediate
router
in
this
case.
In
the
left
hand,
side
example,
when
you
send
packets
from
the
left
hand,
side
T,
they
go
to
a
gateway
P,
and
then
you
need
to
do
an
IP
lookup
in
order
to
forward
a
packet
to
the
next
gateway
and,
finally,
to
then
to
the
remote
T.
So
because
you
have
multiple
IP
lookups
in
in
between,
so
each
one
is
actually
happening
in
the
same
domain.
N
In
the
right
hand,
side
example,
you
have
a
single
domain,
even
though
it's
again
you
are
connecting,
for
instance,
two
data
centers
through
a
wine
network.
The
data
center
gateways
are
not
gateways
as
such,
but
you
use
a
you
know
ASPRS
to
to
make
the
comment
they
can
activity.
So
between
the
two
peas,
let's
say
you
have
a
BGP
labeled
unicast
Tunnel
and
you
have
a
direct,
a
VPN
session
between
them.
So
in
this
case
we
talked
about
a
single
domain
because
there
there's
no
in
the
data
path.
N
N
Is
you
have
a
mix
of
IP
VPN,
any
VPN
piece
in
the
same
domain,
so
they
are
connected
by
the
same
tunnels
right
and
and
you
need
to
make
sure
that
you
provide
connectivity
for
C's
that
are
connected
to
I,
P
VPN
piece
or
these
composite
piece.
So
what
we
do
in
the
composite
piece
is
we
advertise
the
same
prefix
multiple
times
one
pair
Safi
for
intercept
meant
for
oiling
Safi.
N
N
N
This
attribute
is
composed
by
a
length
field
and
and
a
list
of
domain
segments
where
each
domain
segment
is
composed
by
a
domain
identifier,
and
this
intercepted
forward
is
for
forwarding
Safa
type.
So
the
idea
is
that
works
pretty
much
like
a
s
path,
but
irrespective
of
the
the
a
s
right
and
is
actually
giving
us,
the
idea
of
how
many
domains
are
given
prefix
has
been
has
gone
through
until
I
received
that
prefix,
so
here
in
the
second
bullet
at
the
N
and
gives
an
example.
N
So,
in
addition
to
to
give
us
more
visibility
of
the
different
domains
that
that
a
given
prefix
is
traversing,
it's
also
allow
allowing
allowing
us
to
detect
loops.
So
if
I
am
receiving
a
this
prefix
with
a
D
path
and
I
see
on
the
list
that
one
of
the
domains
is
my
own
local
domain
I
can
flag
the
route
as
a
loop
route.
N
The
other
thing
we
are
doing
is
to
talk
about
the
route
selection
across
different
Saffy's,
so
in
in
BGP
RFC
42
71.
Basically,
you
have
the
path,
selection,
the
best
path
selection,
but
usually
for
routes
of
the
same
Safi.
So
here
we
are
extending
that
across
different
surface,
for
instance
a
VPN,
an
IP
VPN.
So
here,
basically
you
have
a
summary
of
what
we
agreed.
N
So
the
idea
is
that
you
are
at
the
beginning
of
this
process.
You
have
a
set
of
best
paths
for
a
VPN
and
a
set
of
s,
paths
for
IP,
savvy,
Safiye
hundred
and
twenty-eight
and
the
basically
the
they
intend
is
that
we
need
to
come
up
with
with
a
set
of
best
pants
from
the
union
of
those
two
groups.
So
what
we
do
first,
is
we
remove
from
consideration
the
lowest
local
preference
routes.
We
also
remove
from
consideration
the
routes
that
do
not
have
the
shortest
d
path
and
in
the
step
number
two.
N
Basically,
we
then
we
follow
regular
RFC
forty-two,
71
selection
criteria
and
if,
at
the
at
the
end
of
that,
we
still
have
a
VPN,
router
type,
two
and
wrapped
I-5,
we,
basically
we
prefer
route
type
to
always
and
step
number.
Four
is
basically.
If
the
previous
steps
still
give
us,
you
know
a
set
of
ecmp
paths
between
IP
and
a
VPN.
We
can
we
by
default.
We
pick
up
the
a
VPN
path,
but
if,
if
you
configure
at
the
box
for
ecmp,
basically
we
can
allow
you
cmp
across
a
VPN
and
IP
DPM
paths.
N
The
other
thing
we
are
doing-
and
this
requires
a
bit
more
thought,
but
basically
we
are
defining
the
path
attribute
propagation
across
different
Saffy's.
So
from
a
VPN
to
IP
vpm,
for
instance,
there
are
two
modes
of
operation:
the
default
one
is
no
propagation
mode,
so
you
receive
an
EVP
and
route.
You
stole
it
in
the
IP
verve
and
when
you
need
to
realize
it,
basically,
you
read
real
originator,
the
attribute,
a
path
attributes
and
the
other
alternative
is
to
have
this
uniform
propagation
mode.
N
And
then
here
we
are
defining
the
attributes
that
you
should
propagate
between
a
VPN,
an
IP
VPN,
and
this
is
the
initial
thought
and
then
we
define
the
operational
procedures
for
both
composite
piece
and
gateway
piece.
So,
in
the
case
of
composite
piece
again,
you
have
a
single
domain
where
you
have
the
IP
VPN
piece
and
you
have
composite
tee's.
N
So
the
composite
piece
will
send
a
prefix
for
both
IP
v
BN
and
evpn
Saffy's,
and
when
a
composite
P
receives
both,
they
will
actually
select
the
best
path
based
on
their
browser
selection
that
we
saw
before
for
the
gateways
piece.
It's
a
little
bit
more
complicated,
complicated
because
we
receive
from
one
staffing.
We
need
to
realtor
ties
to
the
other
one,
so
we
define
the
rules
to
to
make
that
we
advertise
meant
happening
and
we
also
set
the
rules
for
inserting
the
D
path
attribute
and
also
to
detect
loops.
N
So
this
is
basically
the
Gateway
P
and,
of
course,
there
are
also
combinations
of
both
interworking
functions.
You
can
have
on
the
same
network.
You
can
have
a
gateway
P.
That
is
at
the
same
time
a
composite
P
right,
and
there
is
also
a
section
in
the
trap
describing
what
to
do
in
that
case.
So
again,
even
though
it's
a
provision,
0
0,
we've
spend
a
lot
of
time.
N
O
Me
Raj
Cisco,
so
I
have
a
comment
regarding
the
Gateway
P
functionality.
Perhaps
I
mean
by
the
way
it's
a
very
useful
draft
with
respect
to
the
Gateway
P.
It
might
be
useful
to
consider
a
use
case
where
the
Gateway
P
is
shared
across
multiple
evpn
domains.
For
example,
let's
say
you
have
a
shared
DCI
gateway
that
is
doing
the
DCI
gateway
function
for
two
data
centers,
so
it's
basically
connected
to
two
local
data
center
domains,
eva
via
a
VPN
and
it's
doing,
IP,
VPN
or
evpn
based
DCI
function.
N
N
N
So
the
next
one
is
just
an
update.
It's
pretty
quick,
so
this
is
the
the
proxy
pin
proxy
any
VPN
networks
draft.
This
is
revision.
0-1
soja.
We
presented
this
in
the
last
IETF.
You
have
here
their
list
of
my
cars
and
just
a
short
refresher.
So
the
idea
is
this
is
a
natural
extension
of
the
current
EVP
and
work
so
in
an
EVP
and
broadcast
domain.
N
As
you
know,
one
of
the
goals
is
to
reduce
the
amount
of
bump
traffic,
especially,
is
on
you
know:
sea
based
control,
blame
protocols
that
are
generating
a
bump
traffic.
So,
in
the
same
along
the
same
lines
as
we
do
with
ARP
or
enable
discovery,
you
know
we
have
mechanisms
to
actually
reduce
and
suppress.
N
You
know
that
traffic
we
do
the
same
thing
for
a
GMP
proxy.
There
is
a
separate
track
for
that,
and
this
is
yet
another
work
to
actually
do
the
same
thing
with
PIM
proxy.
So
when
you
use
an
EVP
and
Brooke
has
domain
to
connect,
pin
routers
what
we
want
is
actually
just
to
stop
flooding
all
those
pain
messages
right,
that's
one
thing
until
other
thing
we
want
to
do
is
to
convert
those
soft
State
beam
messages
into
hard,
State
BGP
routes.
N
We
want
to
to
also
leverage
the
the
work
that
we
have
in
the
IGMP
proxy
draft
to
do
pretty
much
the
same
thing:
synchronize
multicast,
States
across
all
day,
Pease
in
the
same
Ethernet
segment
and
provide
a
faster
failover,
so
we've
yeah-
and
this
is
just
an
animation
showing
that,
basically,
when
we
receive
hellos,
we
are
able
to
turn
those
into
PGP
routes
and
generate
hellos
at
the
egress
piece,
and
we
do
the
same
thing
for
him.
Join
and
paim
proof
messages
so
updates
in
revision:
zero
one
based
on
the
feedback
that
we
got.
N
We
removed
the
sections
every
year
we
had
and
we
started
to
work
on
about
pendants,
bootstrap
and
RP
discovery.
The
feedback
was
that
was
really
not
necessary.
We
also
got
the
agreement
and
to
reuse
the
existing
evpn
routes.
So
in
the
IGMP
proxy
draft
we
are
using
the
estimate
route
and
we
are
using
the
IGMP
join
sync
route.
N
Those
routes
can
be
easily
extended
a
little
bit
for
this
draft,
and
then
we
can
reduce
the
same
route
type
in
the
same
structure
and
similar
procedures,
and
we
also
added
a
caveat
that
one
of
the
authors
pointed
out,
and
that
is
when
you
have
you
know
you
don't:
have
the
I
upstream
pin
routers
connected
directly
to
Broca's
domain
attachment
circuits.
You
may
end
up
in
this
in
a
situation
where
you
have
a
source
and
an
upstream
router
that
you
are
not
selecting
for
there
are
certain
procedures
and
you
may
have
some
measures
there.
N
P
One
common
emitter
from
Cisco,
so
I
heard
one
question
about
your
route:
type,
six
and
seven,
which
you
are
reusing
in
this
PIM
proxy
draft.
So
do
we
really
need
two
separate
draft
updating
the
same
route
type
at
same
time,
because
even
a
GMP
proxy
I?
Don't
it's
still
a
draft?
It's
not
RFC!
So
I
was
just
trying
to
understand.
Why
do
we
need
to
overload
here
again
I
can't
we
have
single
document
which
does
because
IGMP
proxy
and
pimp
rocks
kind
of
they're
talking
in
the
same
segment
of
solution,
yeah.
N
N
D
C
N
Agree
with
Ali
it's,
this
is
defining
different
procedures
as
well,
so
some
of
them
are
common,
but
yeah
different
applications,
indeed,
any
more
questions.
E
O
So
with
respect
to
the
unicast
traffic,
if
you
consider
an
ESI
that
is
multihomed
to
two
pease,
the
unicast
multipath
procedures
essentially
enable
equal
load
balancing
of
all
the
traffic.
If
you
consider
like
all
the
flows
that
are
destined
to
that
ESI
across
all
the
evpn
instances,
the
multipath
procedures
try
to
achieve
sort
of
equal
distribution
of
traffic
or
flows
across
the
set
of
two
PS.
O
So
you
would
expect
essentially
half
the
flows
across
all
evpn
instances
destined
to
ESI
one
to
go
to
p1
and
the
other
half
to
go
to
PE
and,
however,
the
problem
with
this
is
essentially
that
if
you
have
an
asymmetric
distribution
of
bandwidth
within
the
ESI
across
the
set
of
multihoming
pease,
the
existing
multi
multipath
procedures
would
still
result
in
equal
load
balancing
of
flows
across
the
two
pease.
So
essentially,
you
would
expect
half
the
flows
to
still
go
to
PE
one
and
half
the
flows
to
still
go
to
PE
two.
O
O
You
would
expect
again
sort
of
like
a
half
split
of
DF
role
across
all
the
services
that
are
enabled
or
all
the
VLAN
service
fee
that
are
enabled
on
that
ESI
across
a
set
of
multihoming
pease
again,
the
suboptimal
behavior
here
occurs
with
respect
to
bump
traffic
as
well.
If
you
have
an
asymmetric
split
of
bandwidth
within
the
ESI
across
the
multihoming
pease,
for
example,
you
have
double
the
bandwidth
on
PE
one
side
and
half
the
bandwidth
on
p2
side.
O
So
essentially,
the
objective
of
the
draft
is
to
have
the
overlay
unicast
flows
load
balanced
across
a
set
of
multihoming
pease
in
proportion
to
the
link
bandwidth,
or
rather
the
relative
link
bandwidth
that
that
particular
PE
has
within
the
ESI,
as
well
as
with
respect
to
the
bump
traffic.
Have
the
DF
roll
across
the
or
the
service
carving
across
a
set
of
multihoming
e's,
also
distributed
in
proportion
to
the
relative
bandwidth
that
that
PE
has
within
that
ESI.
O
So,
essentially,
now,
when
you
have
an
asymmetric
distribution
of
bandwidth
across
a
set
of
multihoming
pease,
the
desired
behavior
is
that
in
this
particular
example,
let's
say,
p1
has
200
gigs
of
bandwidth
and
p2
has
hundred
gigs
of
bandwidth
on
that
ESI
that
is
shared
across
p1
and
p2.
The
desired
behavior
would
be
to
have
2/3
of
the
flows
destined
to
ESI
1,
be
forwarded
to
P,
1
and
1/3
of
flows
destined
to
that
ESI
being
forwarded
via
p2.
O
So
the
solution
that
is
proposed
here,
it's
fairly
straightforward.
Basically,
what
we're
proposing
is
for
the
local
PE
to
advertise
a
link
bandwidth
attribute
together
with
the
per
yes
Ethernet
order,
discovery
route.
So
this
is
basically
an
ESI.
You
know
an
attribute
you
could
think
of
as
a
property
of
the
ESI
being
advertised
from
that
local
PE.
O
The
attribute
definition
itself
we're
trying
to
reuse
an
existing
BGP
extended
community
that
is
defined
in
an
earlier
draft
for
layer,
3
VPN,
because
it
it
pretty
much
enables
a
similar
kind
of
function
for
a
VPN
on
the
remote
PE
side.
Again
pretty
intuitive
functionality.
You
collect
the
link
bandwidth
attributes
for
a
given
ESI
received
from
all
the
peas
within
the
redundancy
group
for
that
ESI,
and
then
you
essentially
program
your
load,
balancing
forwarding
load,
balancing
in
a
weighted
fashion.
O
You
compute
relative
weights
for
each
PE
for
that
ESI
and
you
compute
your
forwarding
path,
list
or
load
balancing
structure
based
on
those
with
respect
to
bum
traffic,
the
df'
service,
carving
we're
still
discussing
it.
So
that's
that's
not
yet
covered
in
the
version
zero
of
the
drop.
There
is
some
overlap
with
the
existing
preference
based
EF
election
algorithm,
and
there
are
other
DF
election
algorithms
that
are
defined
so
we're,
basically,
you
know
discussing
with
other
co-authors
for
revision,
one
as
to
exactly
how
to
disk
how
to
address
it.
O
So
next
steps,
basically
a
couple
of
key
work
areas:
one
is
the
DF
election
part
that
I
just
discussed
that
is
being
discussed
with
other
co-authors
for
the
next
revision.
The
bgp
link
bandwidth
extended
community.
That
Draft
has
expired,
so
we
are
discussing
as
to
how
to
reinstate
the
attribute
definition
and
and
reuse
it
so
that
that's
basically
it
I
mean
basically
looking
for
more
reviews
and
more
comments.
N
For
here
on
nokia,
so
thanks
for
this
document,
I
think
is
very
useful
about
yeah
yeah,
the
bomb
traffic
I.
Think
we
pretty
much
got
to
an
agreement
yesterday.
So
hopefully
we
can
reflect
that
in
the
next
revision.
I
had
a
comment
about
yeah.
The
link
Bank
with
extended
community
at
the
moment
is
defined
as
a
non-transitive
extended
community.
Have
you
thought
about,
inter
yes,
and
if
we
need
to
fix
that
I
guess
we
do
I
have.
O
D
L
K
K
O
O
O
I
L
While
looking
into
data
center
stuff,
we
kind
of
looked
at
floral
at
signaling,
it
seems
to
be
extremely
complicated.
Since
you
need
to
make
sure
packets
don't
get
your
dirty,
you
need
to
count
to
dub
delays.
So
it's
definitely
of
interest
to
look,
especially
in
a
VPN
case
where
elephant
floors
could
be
20,
elephants
right,
right,
right.
O
Q
Himanshu
from
Siena
a
similar
comment:
I,
if
you
have
multiple
remote,
pease
right,
they're,
sending
it
to
this
p1
and
p2.
How
do
you
coordinate
you
know
from
the
remote
ingress
bees
with
with
respect
to
how
the
traffic
is
distributed
right?
They
will
they're
all
taking
independent
enough,
obviously
with
elephant
and
mouse
flows,
and
all
that
I.
E
O
O
Instead
of
you
know,
load
balancing
them
equally
across
the
two
remote
Peas,
it
is
going
to
basically
distribute
its
local
flows
in
a
proportional
manner.
So,
overall,
across
all
the
peas,
you
would
expect
all
the
flows
from
all
the
remote
Peas
to
be
distributed
in
like
2/3
to
1/3
manner,
for
example,
instead
of
instead
of
ecmp,
so
I
hear
what
you're
saying.
O
P
D
Q
D
We
are
not
trying
to
boil
the
ocean
in
here.
We
are
trying
to
say
okay
currently.
Currently,
if
you
look
at
the
load
balancing
the
load,
balancing
that
it's
performed
by
the
remote
PE
is
blind
blindly
down
between
the
p1
and
p2.
Equally,
we
are
saying
that
now
do
it
animated
basis
and
the
weight
is
the
link
bandwidth.
So
we
are
doing
an
additional
improvement.
We
are
not
trying
to.
You
know
solve
the
world
hunger
problem
here.
One
one
additional
comment:
I'll
add.
E
D
I
It's
different
how
much
to
come
back
also
to
to
this.
Yes,
we
see
distributive
routing
issue,
so
you
cannot
control
globally
your
network.
So,
yes,
this
is
a
good
way
to
go,
and
if
we
you
want
a
kind
of
global
optimization,
you
may
need
yeah
kind
of
central
controller
to
optimize
your
flow,
and
there
is
no
other
way
to
do
right.
E
O
Have
like
some
very
quick
updates
on
the
IRB
mobility
draft,
so
the
version
zero
of
this
draft
was
presented
at
the
last
IDF
in
Prague,
just
just
a
couple
of
quick
updates
on
waters
new
or
what
has
changed
and
the
next
revision.
Just
to
recap,
the
draft
itself
is
intended
to
extend
the
existing
Mac
mobility
procedures
defined
in
7432
to
IRB
use
cases,
including
all
use
cases
that
might
result
in
changing
Mac
to
IP,
bindings
or
IP
to
Mac
bindings
across
across
mobility.
O
The
solution
that
was
proposed
in
the
draft.
It's
essentially
the
same,
so
nothing
has
changed
with
respect
to
the
main
content
of
the
draft
and
the
solution.
It's
it's
very
much
aligned
with
the
Mac
mobility
procedure
defined
in
RFC
7432.
It
pretty
much
takes
that
and
extends
the
sequence
number
assignment
rules
to
account
for
scenarios
where
Mac
IP
bindings
could
change
across
across
mobility.
O
So
key
updates
to
the
to
the
next
revision
based
on
comments
and
contributions
received
from
additional
co-authors.
One
area
is
that
we
also
included
IP
mobility
for
a
routed,
evpn
overlay
use
case
where
basically
you're.
You
have
a
purely
routed.
A
VPN
network
and
IP
mobility
procedures
are
are
are
captured
in
section
8
of
the
document,
which
are
pretty
much
aligned
with
Mac
mobility,
and
they
they
take
the
same
procedure
and
applied
to
IP
mobility.
O
Duplicate
host
detection
section
has
been
extensively
rewritten.
There
was
a
lot
of
comments
with
respect
to
it,
not
being
very
clear
with
respect
to
each
use
case
how
it
is
handled
so
now
it
goes
by
case-by-case
basis
for
each
scenario.
It
describes
the
handling
in
greater
detail
as
well
as
it
includes
type
II.
Mobility
scenarios
as
well,
particularly
the
duplicate
host
recovery.
Section
now
goes
into
much
greater
detail
with
each
scenario
and
describes
as
to
how
the
host
or
how
the
recovery
from
the
duplicate
or
frozen
Mac
or
IPE
would
happen
for
each
different
scenario.
O
Other
than
that
there
was,
there
was
an
overlap
between
IP
duplicate,
IP
handling
with
the
proxy
art
draft,
so
we
have
kind
of
aligned
it
with
that
drop.
I
mean
the
the
main
sort
of
procedure
was
very
much
aligned
with
the
draft,
but
since
it
is
already
defined
in
that
draft,
so
we
kind
of
added
appropriate
references
and
just
just
talk
about
the
deltas
in
this
drop.
That's
that's
basically
it
so
we're,
basically
looking
for
more
more
reviews
and
more
comments
on
this
draft
from
the
working
group
to
take
it
further.
C
Have
a
bit
of
time,
anyone
wants
to
say
something:
no
exploit
the
time.
Okay,
thank
you
very
much.
If
you
haven't
signed
in
assign
the
blue
sheets,
there
must
be
somewhere
in
the
home.
Please
do
sign
them
and
thank
you
very
much
for
being
here
on
Friday
I
see
a
lot
of
people
as
many
as
usual,
so
I'm
really
pleased
to
see
that
doesn't
mean
we'll
continue
being
on
Wednesday
on
purpose,
but
I'm
happy
for
that
anyway,
thank
you
and
see
you
next
meeting
I,
don't
know
where
London.