►
From YouTube: IETF111-RTGAREA-20210729-2030
Description
RTGAREA meeting session at IETF111
2021/07/29 2030
https://datatracker.ietf.org/meeting/111/proceedings/
A
Hello,
everyone.
I
hope
you
can
hear
me
and
probably
see
me
now.
This
is
the
routing
area
open
meeting
we're
missing
john.
I
don't
know
where
he
went,
but
I
hope
he
should
be
here
soon.
So
I'm
gonna
give
him
a
minute
or
two
before
we
start.
A
A
A
Okay,
so
we
got
john,
I
don't
know
john
martin,
if
you
want
to
turn
your
camera
on,
so
people
can
see
us
and
we
can
wave.
As
I
said,
this
is
the
voting
area
open
meeting,
there's
john
and
there's
martin
soon
there
we
go.
A
Let
me
see
how
this
works,
okay,
so
as
in
all
the
sessions,
here's
a
note
well
not
well,
it's
not
only
about
ipr.
It's
about
other
things
like
conduct
and
the
anti-harassment
procedures
are
in
there.
So
please
take
a
look,
especially
the
links
at
the
bottom,
all
the
pcbs
down
there
there's
here's
a
couple
of
other
links
that
you
can
go.
Take
a
look
at
the
routing.
Your
wiki
is
right
here
directorate.
A
We
need
blue
sheets
because
we
have
the
meet
echo,
please
if
you
can
go
to
the
code
emd
and
collaborate
on
the
notes.
A
A
We're
always
looking
for
feedback
about
how
we're
doing
what
could
we
do
better,
what
things
we
may
be
actually
doing.
B
A
A
A
A
Here's
the
agenda
for
today
it's
relatively
simple.
We
only
have
one
hour
we're
gonna
go
through
a
very
quick
area
status,
then
we're
going
to
have
the
record
report
and
then
we're
going
to
have
just
like
we
started
last
time
having
some
working
group
updates
we
have
asked
for
about.
A
So
not
much
has
changed
in
terms
of
working
groups
in
the
area.
We
don't
have
any
new
working
groups,
we
didn't
reach
her
or
anything
and,
of
course
we
didn't
close
any
working
groups
either.
We
do
have
a
couple
of
new
chairs
don
fedec
joined
as
co-chair
of
monet
with
ronald
who
is
acting
as
the
as
the
sole
chair
for
at
least
over
a
year
now
welcome
dawn
and
also
welcome
to
ying
sen
ku,
who
is
the
new
rtgwg
chair?
A
A
We
also
have
one
buff
this
time
that
will
happen
tomorrow
at
noon.
Local
time,
in
whatever
the
meeting
local
time
is,
this
is
the
apn
buff
application.
Aware
networking
please
plan
to
attend.
There
shouldn't
be
any
other
running
conflicts
at
that
time.
A
Just
in
case
you
don't
know
who
the
responsibility
for
your
working
group
is.
This
is
the
way
we
have
distributed
the
working
groups,
so
you
can
go
talk
to
the
ad
for
any
working
group.
You
want.
A
Okay,
so
unless
there's
any
questions
now
we're
going
to
go
into
the
rotten
director
report.
A
I'm
guessing
that
homien
you're,
probably
going
to
present
this.
C
C
Experts
and
of
them
are
quite
active
in
different
kind
of
working
groups
and
appointed
by
the
ads,
and
the
purpose
of
this
team
is
to
review
the
drafts
in
the
from
the
rocking
area
as
they
pass
through
the
itf
last
call,
or
we
are
also
having
the
review
of
the
other
routing
related
drafts
for
itf
from
from
other
areas,
and
we
also
provide
those
kind
of
early
review
for
any
routing
area.
Working
group
document
before
the
working
group
last
call
so.
C
This
is
always
requested
by
the
working
group
chairs
before
the
working
group
last
call
on
demand.
Next,
please.
C
Actually,
we
show
the
statistics
of
the
of
each
ietf
meeting
from
2020,
and
I
think
this
time
we
are
having
around
totally
17
documents
reviewed
and
maybe
eight
of
them
for
our
review
and
the
nine
of
them
for
for
for
working
group
last
call
review,
and
this
is
the
the
data
from
last
ietf
since
march,
and
we
also
give
a
distribution
according
to
the
working
groups
as
a
at
the
right
hand,
side
of
this
picture,
and
actually
we
have
quite
good
distribution,
and
we
cover
a
lot
of
working
groups
in
the
routing
area.
C
Yeah-
and
this
would
be
a
kind
of
result
for
the
review,
because
we
consider
most
of
them
a
review
completed
with
ready
with
issues,
and
this
would
be
around
the
39
percent
and
almost
30
of
them
are
ready
with
nets
and
28
for
totally
ready
without
any
issues
and
there's
three
percent.
C
C
Another
twenty
percent
is
labeled
as
ready
with
knit,
and
there
is
also
one
document
marked
as
not
ready.
Okay.
This
has
a
basically
introduction
for
the
review
of
sir
rotten
dark
rate,
and
I
assume
this
is
the
last
slide.
We.
C
A
Great
thank
you.
I
should
have
said
before
at
the
beginning
that
haumyan
is
joining
or
just
joined
the
group
of
directorate
coordinators,
along
with
luke
andre,
he
is
replacing
amy
who
stepped
down
because
of
changes
in
her
job.
So
welcome
and
thank
you
amy
for
all
the
work
that
you've
done.
Any
any
questions
comments,
I'm
not
watching
the
chat
actually
by
the
way.
So,
if
anything
comes
up
there,
please
come
to
the
microphone
any
questions
or
comments
around
the
running.
A
Okay,
so
we're
gonna
move
on
to
the
working
group
updates
and
first
up
we
have
nvo3.
I
think
matthew's
here
go
ahead.
Matthew.
D
Hi
alvaro,
can
you
hear
me
chris
yep
good,
so
a
little
summary
because
we
haven't
presented
for
a
while,
so
what's
nvo3
about
so
envyo3
is
charted
to
develop
a
set
of
protocols
or
protocol
extensions
for
network
virtualization
in
a
data
center
environment
with
an
ip
underlight
and
and
it's
to
provide
basically
later
and
layer,
3
services
for
these
virtual
networks
to
enable
multi-tenancy
and
and
workload
mobility
and-
and
the
working
group
has
a
pretty
broad
brief
in
this,
covering
the
architecture
and
the
data
plane
and
control,
plane,
security
and
oem
for
all
of
these
sorts
of
solutions
and
has
seven
rfcs.
D
So
far
we
in
the
early
early
life
of
the
working
group,
we
had
a
lot
of
debate
on
the
control
plane
and
should
it
be
centralized
should
it
be
distributed?
What
should
we
focus
on
the
control
plane
and
so
basically
the
distributed
control
plane?
Part?
Basically,
bgp
was
hived
off
into
mostly
covered
by
bess
working
group.
Now
so,
in
terms
of
control,
plane
work
we're
really.
We
assess
the
applicability
of
the
distributed
control
planes,
but
mostly
centralized
next
slide
piece.
D
So
data
plane
has
been
a
very
major
part
of
the
work
of
the
the
group.
It's
basically
choosing
and
designing
an
encapsulation
for
network
virtualization,
and
the
group
over
the
last
few
years
has
spent
a
significant
amount
of
time,
selecting
a
data
plane
encapsulation
from
numerous
candidates.
So
there
were
candidates
who
were
born
brought
into
the
working
group
itself,
so
geneve
vxlan,
I
should
see,
say:
gpe
not
bgp
for
audiences
and
goo.
D
There
were
also
some
kind
of
pre-standard
encapsulations
of
vxln
and
mvgre
that
were
deployed
in
data
centers
for
these
kinds
of
applications
as
well.
These
this
debate
was,
as
I
think
many
working
groups
have
found,
is,
is
particularly
controversial
and
difficult
because
it
impacts
hardware
and
it's
once
something
is
deployed.
D
An
encapsulation
is
deployed
it's
difficult
to
upgrade
or
interoperate,
with
existing
different
deployments.
The
way
we
we
worked
through
this
was
to
form.
Actually,
I
think
there
were
two
encapsulation
design
teams
over
the
process
of
this
and
they
ended
up
selecting
the
geneve
encapsulation,
and
that
was
last
year
published
as
a
standards
track.
Rfc
8296
and
the
process
we
took
was
to
say
well,
there's
going
to
be
one
standard.
D
The
working
group
needs
to
be
able
to
pick
what
it
is,
but
the
the
the
other
the
others
can
then,
once
the
working
group
has
focused
on
this,
one
can
go
ahead
as
an
maybe
an
informational,
rfc
and
also
ones
that
had
broader
applicability,
like
you
were,
sent
off
to
the
internet
area.
D
We
wanted
to
publish
this
as
an
rfc
really
to
to
kind
of
help
with
documenting
our
experience
of
of
trying
to
pick
a
standards
track.
Encapsulation,
because
this
is
you
know
numerous
times,
is
it's
very
challenging
thing
for
for
working
groups
to
do
next
slide.
D
Thank
you
on
the
control
plane
side
so
distributed
control.
Planes
are
explicitly
out
of
scope
of
nvo3.
D
D
D
D
So
there
is
also
some
ongoing
work
on
oem,
particularly
the
use
of
bfd
over
geneve
and
a
more
general
draft
talking
about
oem
aspects
of
the
geneva
encapsulation
and
we
hope
to
wrap
this
up
during
2021,
so
hopefully
this
year,
okay,
and
that
is
it
for
nvo3.
Thank
you.
E
E
So,
just
a
very
brief
introduction
of
what
sfc
is
service
function
chaining.
Basically,
a
service
function
chain
is
an
ordered
set
of
service
functions,
so
these
can
be,
for
example,
firewalls
or
load
balancers
and
like
we
can
see
in
the
figure
a
chain
of
service
functions,
but
it's
not
necessarily
a
very
nice
linear
chain.
It
can
actually
be
a
bunch
of
virtual
machines
or
physical
machines
which
are
in
different
places
and
then,
when
we
have
a
service
function,
path
and
a
packet
that
is
forwarded
through
this
path.
E
E
E
Two
of
them
are
related
to
nsh
the
network
service
header,
and
this
was
the
encapsulation
that
was
standardized
in
the
working
group
for
service
function
chains.
So
this
was
published
a
couple
of
years
ago.
E
There
was
also
an
rfc
which
defined
the
oem
framework
in
the
context
of
source
function
chains,
and
there
is
an
rfc
about
context,
headers,
basically,
a
context.
Editor
is
a
type
of
metadata
that
is
attached
to
the
network
service
header,
and
this
metadata
can
be
used
by
service
functions
along
the
along
the
path.
E
Okay,
so
the
current
work,
we
have
five
active
working
group
documents
and
12
individual
internet
drafts
and
basically
one
document
is
currently
an
isg
review
and
this
is
a
document
that
is
related
to
integrity,
protection
and
so
right.
Now,
there's
a
lot
of
discussion
about
this
document
between
the
authors
and
the
ids
which
have
reviewed
the
draft.
There
are
quite
a
few
comments
that
need
to
be
resolved
at
this
point.
E
E
So
these
are
on
their
way
to
the
isg,
and
we
have
a
couple
of
more
active
working
group
documents
and
there's
a
bunch
of
documents
that
haven't
been
adopted
by
the
working
group.
Yet
so
here's
the
tricky
part
we
haven't
been
meeting
regularly
in
the
last
two
years
and
there's
quite
a
bit
of
traffic
in
the
mailing
list
by
the
authors
of
these
drafts.
E
E
If
people
read
documents
and
sent
us
any
comments
over
the
mailing
list,
and
if
we
see
that
there
is
some
new
energy
in
the
mailing
list
and
more
discussion
of
these
documents,
we'll
probably
go
back
to
meeting
regularly
and
we
may
be
able
to
get
some
more
work
more
work
done.
So
that's
something
that
we're
looking
forward
to.
D
Thanks
alvaro,
it's
matthew
again
co-chair
of
of
stefan,
my
my
co-chair,
unfortunately
couldn't
make
the
meeting
so
next
slide.
Please
so
bess
stands
for
bgp
enabled
services,
so
it's
the
it's
the
home
for
key
bgp
based
services
such
as
l3,
vpns,
bgp,
vpls,
evpn,
multicast,
vpns
and
so
on,
and
it's
kind
of
grew
out
of
the
old
l3
vpn
and
l2
vpn
working
groups
for
the
bgps
based
services
from
those
because
we
work
with
bgp
as
as
our
control
plane.
D
We
have
a
very
strong
relationship
with
the
idr
working
group
and
we
regularly
co-review
drafts
and
obviously
we
we
ask
for
extensions
to
bgp,
which
have
to
be
reviewed
by
idr
next
slide.
D
So
this
I've.
Just
this
is
a
very
active
working
group.
We
keep
martin,
who
is
our
sharpening
id
very,
very
busy.
So
I
I've
just
picked
out
a
few
of
the
the
key
sort
of
hot
topics
that
have
been
going
on
in
the
working
group
over
the
last
year
or
two.
D
So
so
one
of
them
is
a
abyss
for
rfc
7432.
Now
rc7432
defines
control,
plane
procedures
for
bgp
bgp
based
ethernet
or
vpn.
So
this
has
started
quite
a
long
long
time
ago,
and
the
update
has
been
there's
been
quite
a
few
deployments
now
for
this,
so
we're
updating
the
rfc
based
on
deployment
experience
with
some
clarifications
and
enhancements
to
the
base.
Rfcs,
I
mean
the
basic
things
like
terminology,
but
there's
things
to
do
with
reprioritization,
there's
no
forwarder
roles,
pdf
and
df,
and
so
on.
D
Next
slide,
there
is
a
pretty
active
draft
on
bgp
based
controller
for
multicast,
and
this
is
about
how
to
use
a
centralized,
bgp
controller
to
set
up
multicast
trees.
The
work
started
a
couple
of
years
ago
with
a
bgp
multicast
drop
controller
draft
draft
itf
s
bgp
multicast
controller
that
was
adopted.
Then
there
has
also
been
some
other
work
done,
which
I
think
originally
started
in.
D
I
this
draft
draft
hb
idr
sr
p2mp
policy
started
an
idr
which
contains
some
some
procedures
as
well
for
building
segment
rated
point
to
multiple
entries
for
sort
of
points,
multiple
points
segment
reaching
policies,
but
that
was
mostly
discussed
in
idr
and
we're
trying
to
work
out
with
the
authors
now
how
to
take
these
these
drafts
forward
and
come
to
a
single
solution.
D
Next
drop
slide.
Please,
a
lot
of
the
work
in
best
is
really
optimizations
to
evpn
ethernet
vpns,
a
lot
of
the
work
now,
obviously
with
this
with
increasing
deployment,
so
people
are
looking
at
multi-homing
they're,
looking
at
load
balancing
improvements
to
convergence
as
well
for
evpn,
so
we're
very
active
in
an
improving
evm
evpn
based
on
the
deployment,
experience
and
new
requirements,
so
in
the
multi-homing
and
load
balancing
areas.
There's
a
couple
of
notable
drafts
here:
evpn
mhpa,
which
is
port-based
multi-homing
a
bit
like
multi-chassis
lag,
but
for
evpn.
D
There's
the
evpn
in
equal
cost
process,
using
a
link
bandwidth
to
provide
low
balancing
on
access
links
running
at
different
speeds,
an
area
of
convergence.
We
have
a
couple
of
drafts,
at
least
the
the
fast
df
recovery
draft,
which
is
ntp
to
get
faster,
df
switch
over
and
there's
an
ip
aliasing
draft
to
aid
in
this
area.
D
We
also
look
at
interworking
between
different
bgp
based
services,
so
there's
a
draft
draft
preset
best
ebpm
vpws
seamless,
which
is
really
a
merged
effort
to
get
into
working
between
evpn
vpws
and
legacy,
bgp
pws
services
and
there's
a
lot
of
additional
ongoing
work
going
on
for
any
vpn
and
ipvpn's
and
or
merging
evpn
working
with
multicast
vpns.
D
And
thank
you
any
any
questions.
A
Thank
you,
matthew,
we're
now
on
to
pce.
F
Hello
hi
everyone
on
behalf
of
julian
and
hurry.
Let
me
give
you
a
good
update
about
the
pc
working
group.
Next
slide,
quick
motivation
on
why
we
started
working
on
pce.
F
The
idea
was
that
we
would
need
a
central
place
to
do
things
like
path,
engineering,
global,
optimization,
trying
to
figure
out
how
to
compute
a
diverse
path
across
our
network
make
sure
there
is
synchronization
between
the
view
that
is
there
on
the
devices
and
the
controller
that
all
require
centralized
control,
and
that's
where
the
pce
comes
in.
The
initial
set
of
reason
for
pc
were
more
focused
on
multi-domain
and
multi-layer
coordination,
where
no
single
device
would
have
a
global
view.
F
So
you
need
something
like
a
pce
to
cooperate
with
each
other
and
help
compute
path
which
are
like
you
know,
best
part
across
domains
and
across
layers,
and
once
you
do
multi-domain
again,
you
need
to
do
path,
optimization
at
boundaries.
That's
where
path
key,
and
things
like
that
came
in.
So
this
was
a
very
quick
motivation
for
why
pce
was
being
worked
on
in
itf
next
type.
Please
let
me
give
a
quick
update
of
what
pc
working
group
does.
F
We
are
responsible
for
the
protocol
path,
computation
element,
communication
protocol,
the
protocol
that
is
used
between
the
client
called
pcc
and
the
server,
which
is
the
pce
vsep,
is
also
used
between
the
pcs
in
multi-domain
and
multi-layer
cases.
So
this
is
well
suited
for,
like
the
coordination
between
controllers,
pc
became
the
core
component
of
any
sdn
system.
Pcs
unique
thing
was
psep
was
that
it
has
been
used
to
signal
rsvpt,
segment,
routing,
pcc
and
now
new
work
coming
in
from
beer.
F
We
hope
work
would
come
in
from
that
sfc
wherever
there
is
a
requirement
for
controller
to
play.
A
role,
pce
and
pc
protocol
has
a
role
to
play.
Unique
thing
about
psep
again,
is
that
it's
not
just
for
packet
networks,
it's
being
used
for
optical
gm,
pls,
wson,
flex,
corel,
all
networks,
which
requires
part
computation
and
path
setup
to
happen.
Pce
and
psap
has
a
role
to
play
next
slide.
F
F
All
that
work
has
been
standardized
quite
a
while
ago,
but
the
new
work
is
there
are
enhancements
that
are
happening
over
the
stateful
protocol,
inter-domain
stateful
pce
things
like
state
synchronization
when
there
are
multiple
pcs,
new
association
types
between
the
lsps
at
staple
pc,
so
stateful
is
continue
to
be
enhanced
with
new
use
cases,
use
of
pce
and
sdn
system.
F
We
worked
on
a
pcc
architecture
in
teas
and
then
the
pcc
first
extension
just
got
published
as
rfc
9050,
and
we
have
further
enhancement
to
pcc
in
the
working
group
for
segment,
routing,
srv6,
p2mp
native
ip
etc.
Use
of
pc
in
in
us
sr
system
is
no-brainer.
Pce
remains
as
the
part
which
is
going
to
help
you
compute
your
sit,
stack
and
srv6
path,
etc.
So
the
basic
sr
has
already
been
standardized.
The
new
work
is
sr
policy,
handling
of
binding
segment
path,
segment,
bidirectional,
etc.
F
The
latest
work,
which
is
keeping
like
a
big
chunk
of
our
agenda,
this
time
was
multicast.
There
was
work
related
to
srp,
2mp
policy
being
worked
in
spring
and
pim,
and
the
extension
for
that
in
psep.
A
lot
of
work
from
beer
brte
makes
a
lot
of
sense
where
pc
would
be
involved,
but
there
are
other
new
proposals
as
well
where
pc
based
peer
system
and
multicast
system
in
general.
F
So
these
have
been
some
of
the
topics
that
are
recently
being
discussed
in
the
working
group
last
slide
next
piece.
So
we
have
to,
of
course,
based
on
our
work.
You
could
see
that
there
is
a
lot
of
coordination
between
working
group
that
is
required
is
still
the
owner
of
the
pce
architecture,
so
things
like
pcc
and
use
of
pc
in
actn
and
even
in
future,
any
network
slices
related
work.
F
That
would
happen
in
teas
and
any
psep
extension
will
of
course
happen
in
pc
working
group,
but
we
need
to
make
sure
that
the
requirements
and
architecture
comes
from
these
with
camp,
mostly
all
our
optical
work,
wson
flexgrid,
good
coordination
is
needed
with
c-cam
spring
for
sr
mplssr,
as
well
as
srv6,
a
lot
of
beer
related
things
that
I
was
just
talking
about.
With
idea.
We
had
one
one
proposal
called
native
ip,
which
uses
psep
for
bgp
session
establishment.
F
So
there
is
some
coordination
with
idea
is
needed
on
this,
which
has
been
done.
There
is
a
cross
review
from
sue
recently
on
this,
which
is
very
helpful
and
since
idea
and
psep
are
both
being
used
for
sr
extension.
This
is
important
that
we
maintain
some
parity
between
the
two
protocols
with
respect
to
features.
So
that's
always
a
thing
to
look
out
for
with
idr
with
pim
srp2mp
policy.
We
hope
that
when
that
net
has
starts
works
on
controller
plane,
pc
would
play
some
role
there.
F
Similarly,
for
sfc
any
control
plane
work
any
would
require
some
coordination
with
sfc
working
group
in
pc,
and
with
this
I
close
are
there
any
questions.
F
A
A
And
the
last
update
we
have
today
is
for
less
go
ahead.
G
Okay,
so
I'm
luigi,
I'm
considering
this
working
group
with
joel,
which
is
not
here.
He
has
a
conflict,
as
was
stated
for
us
sfc
and
we
have
patna
our
secretary,
maybe
is
here
in.
I
don't
know
anyway
slide
please
next.
So
let
me
just
introduce
lisp
stands
for
locator
id
separation
protocol.
This
working
group
has
been
around
for
something
around
10
years
and
the
early
years
was
about
experimental
deployments
so
later
on.
We
have
been
recharged
in
order
to.
G
Go
for
standard
tracks
so
that
we
have
documents
that
are
proposed
standard
and
the
in
the
last
couple
of
years.
We
worked
a
lot
on
what
we
call
the
beast
documents
that
basically
define
the
control
plane
at
the
data
plane,
so
the
basic
specification
of
lisp
as
proposed
standard
and
don't
be
scared
about
the
figure
that
is
the
the
status
of
our
data
tracker
is
just
that
we
are
happy
because
we
we
finally
got
over
some
blocking
points.
Okay,
so
and
we
have
the
main
specs
out
and
a
few
additional
items.
G
Also,
we
have
a
couple
of
documents
that
need
to
be
shepherd
that
the
most
important,
besides
the
main
specs,
what
we
were
working
on
in
the
last
year
or
so,
is
to
secure
the
control
plane.
G
I
have
to
say
we
kind
of
underestimate
the
work
to
secure
the
control
plane,
but
at
the
same
time
we
had
a
sequence
of
unfortunate
events
in
in
the
review,
let's
say
the
control
plane,
which
basically
has
a
a
pull
model.
Basically,
I
like
dns
in
the
sense
you
query
you,
you
obtain
the
mapping,
so
basically
the
association
between
I
identifiers
and
routing
locator.
G
G
Now,
on
the
control
plane
side,
we
have
that
we
have
what
we
call
the
elkaf
lisp
canonical
address,
format
which
we
can
associate
different
address
format,
so
so
classical
ip,
but
also
geocoordination
or
anything
in
a
certain
way,
and
we
have
registers
that
can
be
extended
on
the
data
plane
part
we
we
still
are
more
on
the
ip
over
ip
model,
okay,
but
we
we
also
work
it
on
a
extended
extensible,
encapsulation
format
that
allows
to
to
go
further
in
the
future.
Okay,
next.
G
Yeah,
thank
you
so
looking
forward
looking
at
the
charter,
we
have
a
couple
of
things
that
needs
to
be
done:
okay,
so
and
somehow
related
and
one
is
the
not
traversal
and
then
is
lisp
mobility.
So
we
promised
to
have
a
non-traversal
feature
because
in
some
use
cases
this
is
what
happens
that
the
endos
is
behind
the
nut.
So
we
need
something
that
allows
us
to
traverse
a
knot
and
the
other
thing
is
lispen
mobility.
So
this
is
one
feature
that
has
been
discussed.
G
I
think
from
day
one
from
lisp,
because
if
you
have
a
dynamic
association
between
identifiers
and
locator,
obviously
is
some
form
of
mobility
with
which
you
can
play
with
and
so
turns
out
in.
The
implementations
that
have
been
shown
so
far
is
when
you
have
mobility
a
lot
of
time.
You
are
be
behind
or
not
so.
G
That
is
why
the
two
working
items
are
somehow
related.
I
didn't
put
any
draft
name
of
these
slides
because,
anyway,
you
have
everything
at
the
tata
tracker
and
it's
much
more
easier
to
remember
this
mobility
than
draft
blah
and
thinking
about
overlap
with
possible
other
working
groups.
What
comes
to
mind
is
the
dmm
distributed
mobility
management?
G
We
we
are
not
yet
in
contact
with
them,
but
I
I
think
would
it
is
a
sensible
thing
to
do,
is
to
go
there
and
present
what
is
their
least
mobility
solution,
because
at
least
there
will
be
mobility
expert
in
a
certain
way
that
can
give
us
feedback.
Okay,
on
the
specific
solution
that
we
are
developing
and
looking
forward
more
long
time
in
a
certain
way.
G
G
Okay,
one
is,
for
example,
the
use
of
lisp
for
multicast,
and
this
is
some
work
that
is
being
developed
actually
in
the
team
working
group
and
just
keeps
us
nicely
updated,
and
the
role
of
the
list
working
group
would
be
only
if
any
change
in
the
protocol
specs
are
needed,
then
we
will
say
something
but
other
than
that
we
just
try
to
keep
to
to
to
be
informative
on
what
is
going
on,
because
we
have
to
say
that
we
also
have
a
list
also
support
natively,
multicast.
G
Okay,
then
another
couple
of
interesting
things
we
that
are
starting
is
what
we
call
the
overlay.
So
thing
is
the
icao,
which
is
in
in
international
civilian
aviation
organization,
is
looking
to
revise
their.
G
Aviation
telecommunication
network,
okay,
so
one
possibility
is
to
use
lisp,
okay
and
there
are
trials
already,
but
this
environment
is
pretty
peculiar
in
the
sense
that
you
have
radio
regions,
okay,
that
very
often
are
controlled
by
by
governments.
But
for
obvious
reasons
and
also
historical
reasons.
Then
you
have
different
communication
service
providers
which
provide
ip.
G
Transport
to
these
radio
regions,
but
then
the
interconnection
of
these
providers
is
strictly
regulated.
It's
not
a
multi-stakeholder
model
like
the
internet.
I
would
say
in
the
sense
that
there
are
stick
the
regulation
to
be
followed.
Okay,
because
governments
are
into
the
picture
there,
so
it
turns
out
that
you
have
different
providers
that
may
use
different,
let's
say
lisp
cloud,
and
then
you
have
something
that
has
to
connect
all
of
them,
and
everybody
has
to
have
full
control
of
the
local
policies,
but
also
a
way
to
transfer
some
policy
information
when
aircrafts
move
around.
G
So
that
is
why
we
call
that
the
overlay
in
a
certain
way
is
that
an
overlay
that
connects
several
other
overlays.
So
we
will
soon
work
on
the
exact
requirements
that
we
received
and
try
to
to
be
sure
that
are
clear
enough,
that
something
can
be
provided
as
a
solution.
Okay,
the
other
thing
is
nexagon.
This
is
some
also
some
something
that
is
related
to
energy,
so
coin
is
in
in
network
computing,
so
is
like
edge
computing
in
a
certain
way.
G
So
vehicle
to
vehicle,
instead
of
looking
around
and
having
direct
contact
with
the
different
vehicles,
you
have
a
leveling
of
indirection
that
uses
lisp
and
basically,
what
you
have
is
that
you,
you
split
the
rods
in
tiles
which
have
an
hexagon
shape.
The
reason
is,
there
is
a
what
is
called
a
h3
standard
in
order
to
be
able
to
to
to
build
this
style,
and
then
you
can
group
a
few
hexagons
to
form
a
bigger
hexagon
and
so
on.
G
G
What
you
do
you
do
subscribe
to
the
specific
ids,
identifying
the
tiles
and
so
that
you
can
get
update
on
the
status,
so
basically
getting
updates
about
traffic
jam
or
problems
on
the
road
anything
so-
and
this
is
quite
nice-
work
that
is
taking
off
in
the
working
group
next.
I
think
that
I'm
done
with
yes
and
you,
if
you
have
any
questions
just
let
me.
A
So
I
hope
everyone
saved
all
the
questions
and
comments
for
the
open
discussion,
which
is
where
we
are
right
now.
So
anything
you
want
to
bring
up
that
pertains
to
the
area
or
that
you
want
to
ask
any
of
us
up
here
or
anyone
else.
B
B
Ahead
yeah,
my
my
answer
to
that
is,
we
haven't
decided
because
I
think
the
first
I
heard
that
question
was
in
the
last
session
from
you.
It
kind
of
makes
sense
to
me
to
try
to
harmonize
that
area
wide
if
we
can
and
I'm
open
to
discussion
at
the
mic
now,
but
we
might
want
to
also
have
that
as
one
of
our
topics
for
the
next
routing
area
chairs
chats.
B
It
seems
like
a
sensible
policy
to
me,
but
you
know
we
haven't
yet
taken
any
steps
to,
and
I
I
guess
the
one
of
their
point
is
you
know,
working
groups
have
a
lot
of
different.
You
know
poor
working
group
policies,
so
I
don't
see
it
as
being
a
problem
intrinsically,
for
you
know,
one
working
group
to
say
you
know
we're
asking
for
ipr
affirmations
in
this
way
and
another
working
group
not
to
say
that
that's
that's!
Okay,
too,.
B
I
We're
just
gonna
talk
about
our
experience
and
tease.
Hopefully
my
audio
is
coming
through.
I
know
it
was
bad
in
one
of
the
earlier
meetings.
Okay,
great
thanks,
so
we
talked
about
that
in
teas.
I
don't
know
if
it
was
one
or
two
meetings
ago.
It
came
about
because
we
were
had
a
late.
I
I
an
ipr
surprise
during
a
last
call,
so
in
teas
we've
been
following
the
practice
of
ipr
at
adoption
and
ipr
last
call,
but
somewhere
along
the
line
for
a
particular
document
and
that
an
author
was
added
and
like
a
year
or
year
and
a
half
later
we
got
the
surprise
about
the
ipr
disclosure
and
it
just
would
have
been
nice
when
they
were
added
that
we
knew
about
it
and
that's
what
caused
us
to
change
the
policy
that
we're
now
doing
it
on
only
working
group
documents
where
we've
added
an
author.
H
I
think
this
makes
sense.
I
just
the
experience
I
have
that
I've
been
active
in
a
number
of
working
groups
and
we've
been
doing
ipr's
differently.
I
think
in
each
working
group
and
that
works
fine,
so
as
much
as
possible.
We
should
let
the
working
group
handle
this,
but
according
to
the
guidelines
that
lou
and
john
talked
about
here,
I'm
saying
I
don't
think
we
need
a
strict
policy
that
actually
is
required
across
the
entire
area.
H
B
Right
but
there
there
was,
you
know
no,
no
intention
on
the
part
of
the
ads
so
far
to
to
require
a
strict
policy.
G
You
hear
me:
yes,
yeah,
okay,
it's
just
an
observation
in
a
certain
way
concerning
the
the
the
status
update.
No,
no,
it's
not
status
update,
so
the
presentation
about
the
different
working
groups.
G
I
mean
the
the
email
you
sent
out
to
to
ask
for
this
presentation
was
about
also
point
out
possible
overlaps
with
different
working
groups,
which
I
assume
is
not
just
related
to
to
routing
area,
but
also
in
other
areas,
but
unless
the
the
working
group
is
really
peculiar
in
the
sense,
let's
take
pieces
as
an
example,
he
has
to
to
deal
with
different
working
groups,
which
is
wonderful,
the
job
they
are
doing.
I
have
the
impression
that,
in
a
certain
way,
the
working
groups
working
in
silos
not
isolated,
but
but
we
do
our
solution.
G
G
What
what
can
anything
we
can
do
in
order
to
have
a
to
improve
the
exchange
in
a
certain
the
information
exchange
between
the
different
working
groups,
because
certainly
there
is
some
kind
of
overlap
or
help
that
we
can
have
from
different
working
groups.
That's
my
comment.
B
It's
a
great
comment,
and
I
hopefully
it's
not
just
a
comment
for
the
ads
because
I
I'd
be,
you
know
no.
B
Exactly
so
you
know,
cross-working
group
communication
is
is
pretty
difficult
and
or
you
know
it's
it's
difficult
to
figure
out
how
to
promote
it.
So
if
there's
ideas
from
you
know
other
people
on
the
floor,
please
you
know
come
to
the
mic.
B
B
B
Otherwise,
I
think
we
can.
We
can
close
right.