►
From YouTube: IETF104-NVO3-20190328-1050
Description
NVO3 meeting session at IETF104
2019/03/28 1050
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
B
Okay,
I
think
you're
gonna
make
you
start
welcome
to
MPI
3
I'm
Matthew,
Bakshi
I
co-chair
Sam,
unfortunately
couldn't
make
it
this
time.
So
please
go
easy
on
me.
If
there's
any
technical
glitches
secretaries,
you
will
be
doing
that.
The
minutes.
Thank
you
here
is
the
note.
Well
basically
says
anything.
Any
statements
you
make
here
are
a
contribution
to
the
IETF
sure
you're
well
aware
of
its
now,
but
just
take
a
minute
to
contemplate
they're
not
well.
Please.
B
B
B
Our
milestones,
so
we
did
update
them
and,
as
usual,
they're
out
of
date
already
so
the
chest-wall
will
go
in
and
post
an
update
to
the
list
if
you'll
review
on
these
courses.
These
are
incorrect
anyway,
because
it
states
that
we
should
have
recharged
or
closed
the
working
group
back
in
August
last
year.
B
All
right
document
status,
so
we
have
no
new
rfcs
since
the
last
IETF
for
the
previous
ITF
I
have
a
few
few
RFC's
published.
So
in
general,
our
data
pane
encapsulation
documents,
which
is
draft
IETF
and
vo3
genève.
This
is
on
the
agenda.
It
went
through
working
group
last
call
some
discussion.
There
was
some
discussion
after
the
working
group
last
call
around
that.
You
may
have
seen
on
the
list
and
we
have
a
an
update
on
where
we
are
with
genève.
B
In
this
meeting,
the
output
of
the
design
team
encapsulation,
the
design
team
for
the
encapsulation
choice
has
currently
expired.
Our
intention
was
to
publish
that
order.
Publication
request
for
that
in
order
to
document
the
encapsulation
twist
process
and
rationale
after
we
had
sent
genève
to
the
is
Jay
still
intend
to
do.
That.
Ideally,
would
obviously
like
to
see
this
document
revived
first,
since
we
can't
last
call
expired
drafts.
So
if
you
are
an
author
of
this
draft,
please
can
you
wake
it
up.
B
We
are
currently
going
through
a
working
group.
Last
call
for
the
Evie
Evie
Evie
p.m.
applicability
to
genève
draft
this
correspondence
system.
Work
was
also
done
in
the
best
working
group
for
sealing
the
parameters
related
to
the
Geneva
encapsulation
in
Evie
p.m.
and
BGP.
There
hasn't
been
a
lot
of
response
on
the
list
of
this
soap.
So
can
you
raise
your
hand
if
you
have
read
this
document
space?
B
Okay,
one
two
good
three
raises
a
cup
of
it.
If
you
please,
ideally
read
the
document,
this
is
a
fairly
significant
piece
of
our
control.
Plane.
Work
in
home,
vo3
is
obviously
we
can't
proceed
if
there's
no
real
response
on
the
list
to
the
working
group.
Last
call
and
please
send
comments
to
the
list
or
if
you
have
no
comments
just
say:
you're,
okay,
with
it
it's
respond
positively
or
negatively
or
otherwise
send
comments.
That
would
be
much
appreciated.
Thank
you.
B
B
There's
a
virtual
machine
liability
protocol
document.
So
we
trying
to
do
a
working
big
last
call
on
that.
It's
currently
expired.
We
haven't
had
a
lot
of
responsible
discussion
or
review
on
the
list.
Again
we
did
request
some
ops
area,
routine,
Directorate
and
TSV
area
reviews
and
and
we've
had
a
number
of
comments
from
those
reviews,
but
the
authors
have
gone
rather
quiet
on
this
document
after
pushing
quite
hard
for
it
to
be
last
hold.
B
C
Hi
so
I'm
gonna
present
it
so
I'm
gonna
go
through
the
genome
security
requirement,
draft
status
and
issues
that
I
think
it
has
to
be
solved
to
make
that
document
move
forward.
So
the
history
is,
we
had
a
call
for
adoption.
In
February,
we
had
an
update
in
November
in
March,
so
in
March
receive
some
comments
and
reviews
from
the
person
from
the
security
Directorate
up
reviewed.
The
genève
specification
provide
comments.
I
think
we
addressed
those
comments,
which
means
we
clarify
and
also
from
the
feedback
we've
seen
in
Bangkok.
C
So
we
had
a
split
between
the
requirements
we
think
are
operational
and
those
the
requirement
for
jean-yves
mechanisms
generate
mechanism
for
security,
and
we
also
uniform
uniform
is
the
requirement
for
authentication
and
encryption.
So
there
is
a
clear
parallel
between
those
and
we
also
had
a
deeper
analysis
with
how
and
when
you
can
use
IPSec
or
DTLS
in
specific
deployments
and
what
is
actually
missing
to
have
IP
ii
DTLS
in
every
deployments.
So
we
went
through
for
each
of
the
solution.
C
C
So
if
you
disagree
with
some
of
the
requirements,
usually
we'd
have
to
see
I
mean
the
origin
of
the
contention,
which
might
be
the
threat
model,
for
example,
or
the
specification
or
the
understanding
of
the
specification.
So
requirements
as
I
mentioned
before
are
operational,
which
means
it's
a
kind
of
checklist
to
operational.
People
could
check
to
see
if
their
deployment
is
actually
securely
deployed,
or
it's
a
protocol
which
is
checklist
for
to
be
next
to
be
jeanne
of
security
mechanisms.
C
So
in
my
in
my
opinion,
and
at
least
I'm
happy
to
be
wrong,
but
DTLS
an
IPSec
cannot
be
secured
for
generic
Geneva
Valley.
It
cannot
be
the
generic
mechanisms
we
provide
associated
to
NIMH,
and
the
other
thing
is
that
NVE
and
transit
device
are
reading
genève
options
and
are
processing
those
options,
so
they
need.
There
is
no
reason
for
to
have
one
being
secure,
the
other
one
not
being
secure
and
this
transit
device
are.
C
So
one
of
the
concern
is
that
well
the
security
complexity
over
genève
I
agree.
It
might
be
complex
to
have
the
three
party,
but
it's
probably
it's
probably
reflect
the
consequence
of
a
complex
architecture
overall
and
that's
more
more.
My
understanding
so
just
to
be
clear
why
DTLS
or
IPSec
cannot
be
sick
cannot
be
used
as
a
generic
security
mechanism
for
Geneva.
This
is
a
deployment
and
example
of
a
deployment
and
I
think
it's
I
hope.
My
understanding
is
that
it's
compatible
with
this
fact
transmitted.
C
So
you
have
jean-yves
option
here,
ABC
process
by
1mpg
and
on
this
side
you
have
the
Trinity
device,
processing,
options,
reading
and
processing
on
from
PC,
and
this
one
nve
processing
of
champagne.
So
the
packet
go,
for
example,
through
this
NP
e
goes
to
transit
devices,
a
b
c
d,
c--
area
process.
Here,
just
a
is
that
the
I
mean
is
there
any
there
anything
wrong
with
that
deployment?
For
example,
any
big
misunderstanding
of
specification.
C
C
C
You
could
have
security
at
the
gene
level,
which
makes
option
NBC
e,
so
you
say
Wow
option
B
C.
They
are
going
to
be
performed
by
the
transit
device
and
security
after
that
here,
so
yeah
option
BCE
and
after
that
he
takes
it
here.
Translates
can't
get
it
and
in
here
well
the
decryption
of
Sunnah
make
it
and
process
so
these
transit
device
you
can
want
to
have
those
we
clearly
need
to
have
the
security
being
performed
at
the
Geneva
layer.
It
doesn't
mean
we
always
have.
C
C
C
This
is
not
really
true
because
well,
first
of
all,
we
haven't
seen
any
mechanisms
where
transit
device
or
transit
nodes
are
mandatory.
So
the
fact
that
it
is
optional
in
capital,
libraries
even
suspicious,
it's
a
bit
like
when
your
banker
say
it's
free,
you
say
Oh
or
when
your
kids
come
back
from
school
and
say
I've
been
very
quiet.
It's
a
what.
C
It's
not
option.
Transit
devices
are
not
optional
in
the
sense
of
this
RFC
specification
of
the
meaning
of
his
term,
because
if
you
introduce
this
device,
it's
going
to
affect
your
deployment.
So
it's
more.
The
deployment
has
to
be
made
in
function
of
these
transit
device,
at
least
the
security
poth,
which
contradicts
in
my
understanding
the
term
optional.
C
So
if
we
want
to
have
Jeannie
the
Android
protocol,
it's
much
easier
to
secure
end-to-end
protocol,
this
can
be
easily
done
at
the
idea,
reusing
existing
protocols,
and
but
the
thing
is
that
we
need
to
have
the
protocol
being
end-to-end.
If
you
want
to
use
end-to-end
security,
it
probably
has
to
be
end-to-end,
which
is
not
achieved
with
transit
device.
So
I
think
it's
a
good
path
to
go
to
end-to-end
security,
to
end-to-end,
Protocol
security,
much
easier.
The
threat
model
is
easier
to
understand.
It's
gonna
be
security.
C
A
A
C
B
Was
just
a
little
bit
of
history
on
that
the
transit
devices?
There
was
a
lot
of
discussion
in
a
working
group
a
number
of
years
ago
about
things
like
being
able
to
trace
the
under
light
from
the
overlay.
So
that
means
that
the
transit,
what
you
call
the
transit,
divides
the
Ritter
or
a
switch
along
the
path
of
a
ritual
on
the
path
of
the
the
MBO
through
on
the
path
of
the
tunnel
must
be
able
to
actually
inspect
your
example.
B
Oem
messages
in
there
must
be
alerted
and
be
able
to
inspect
and
then
respond
to
OEM.
So
that's
one
example
of
a
transit
device.
So
if
you
look
back
on
the
list-
and
they
were
actually
drafts
in
the
working
group,
transmitting
trace
routes
was
one
of
them.
Now,
I,
don't
want.
You
call
that
I
transit
device-
I,
don't
know.
Okay,.
A
E
E
The
current
spec
is
only
read,
then,
with
a
little
bit
more
design
work.
Unfortunately,
DTLS
is
not
exactly
what
you
want.
You
can
arrange
to
to
secure
the
readable
options
for
integrity
end
to
end
without
encrypting
them
and
then
encrypt
everything
else,
and
at
that
point,
you're
back
to
an
end-to-end
security
model.
Just
some
of
the
stuff
that
you
have
integrity,
protected
end-to-end
is
in
the
clear
yeah.
C
F
So
first
thing
I
think
the
plat
mean
you
are
not
characterizing
the
transit
devices
accurately
and
that's
the
main
contention
between
you
know
what
your
written
in
the
document
Daniel
versus
you
know
what
the
architecture
is
supposed
engineer.
Transit
devices
exist
in
the
network
right,
so
it's
you
know
it's.
It
could
be
the
switches
or
routers.
You
know
whatever
that
carries
our
forwards.
The
traffic
between
the
two
endpoints
right
and
you
know
what
what
the
what
we
are
allowing
is.
F
We
have
a
formal
guidelines
so
that
you
know
you're
exposing
or
when,
when
the
transit
devices
are
viewing
the
headers
information
general
information,
they
can
use
that
information.
For
example,
I
gave
you
a
very
specific
example,
like
you
know,
could
be
a
ecmp
purposes
that
could
be
an
option
that
has,
for
example,
flow
context,
so
it
might
be
using
the
transit
device
might
be
using
the
flow
context
in
order
to
forward
the
traffic
right
for
ecmp
purposes.
F
If
the,
if
Jenny
is
secured
integrand
between
the
envy
is,
then
it
doesn't
have
the
visibility
and
if
it
doesn't
have
the
visibility
it
can
continue
to
forward
it.
Based
upon
the
outer
header
information
and,
and
today
that's
how
the
transit
devices
today
operate
in
respective
Geneva,
you
know
even
with
other
encapsulation,
for
all
that's
how
it
operates
and
it
does
not.
You
know
require
that
Ginebra
does
not
require
the
transit
devices
has
to
look
at
or
observe
the
options
in
order
to
forward
the
traffic.
That's
number
one
right
and
encryption.
F
This
is,
if
you
are
using
encryption,
if
you're
not
using
encryption
and
as
I
think
David
black
said.
If
you're
you
know
using
integrity
data
integrity
mechanism,
then
you
don't
have
to
do
that
right.
So
do
different
deployments
may
choose
to
expose
this
information
to
the
transit
devices
or
not
depending
upon
what's
applicable
to
that
deployment
it
doesn't
mean
that
genève
is
not
secure
or
it
doesn't
mean
that
any
way
is
not.
You
know,
secure
intent,
so
I
would
suggest
that
the
author,
you
know,
does
not
miss
characterize
that
Jenny
was
insecure.
F
E
David,
what
can
I,
don't
think
I
heard
a
suggestion
that
was
insecure.
What
I
think
I
heard
was
a
suggestion
that,
if
you
want
Friends
of
devices,
you
need
to
do
something
genève
specific
and
are
people
I
heard
from
a
long
ago
was
mostly
in
terms
of
exposure,
not
modification
which
is
going
to
make
the
problem
much
much
simpler.
I
also
think
back
to
the
router
sort
of
tutorial
discussion
yesterday
afternoon
and
I
would
suggest
that
inserting
or
removing
options
in
route
is
going
to
be
painful.
E
For
some
of
that
high
speed
hardware
and
that's
clearly
avoided
modification
would
be
bad
enough,
and
if
it
sounds
like,
we
don't
even
need
to
do
that,
which
means
that
you've
probably
got
an
end-to-end
security
model.
You
just
have
to
figure
out
how
to
spec
the
crypto
to
get
integrity
on
the
stuff
that
needs
to
be
exposed
to
the
transit
devices
along
I
must
have
said
something
you.
F
G
A
G
H
Correct:
okay,
I
think
that
I
understood
common
differently.
It
was
not
saying
that
says
it
should
say,
but
my
comment
was
continual
they
said
in
connection
to
yesterday.
Buff
is
there
was
a
suggestion
to
start
data
plane
consideration,
especially
for
new
encapsulations
and
variable
length
encapsulations.
I
think
that
will
be
good
to
take
it
before
it
becomes
mandatory
and
add
a
section
that
will
highlight
impact
of
geneva
on
a
fast
path,
processing.
C
If
I'm
trying
to
summarize
some
of
the
comments,
the
current
spec
is
saying
clearly
that
I
think
that
was
my
reading,
that
transit
device
can
only
read,
but
the
current
spec
does
not
make
any
I
mean
the
recommendation
on
how
to
protect
the
gene.
If
packets
does
not
apply
with
those
even
read.
Only
because
we
don't
have
you
don't
provide
any
security
mechanisms
nor
for
this
transit
device.
C
B
C
C
C
Conclusion
well,
the
transit
device
introduced
a
lot
of
complexity
sharply.
So
maybe
we
have
to
reduce
that
and
it
is
not
address
yet
by
your
current
specifications.
Security
complexity-
it's
not
enough
to
say
security
is
complex.
Usually
the
security
reflects
the
complexity
underlined
so
and
we
should
have
more
use
cases
on
those
transit
device
to
understand
what
is
the
intention,
so
the
next
step
I
would
like
is
that
we
have.
C
We
enabled
some
discussions
regarding
these
security
requirements
so
that
the
first
set
for
that
would
be
the
adaption
of
the
document,
removal
of
the
transit
device
from
the
specification
it's
just
one
way,
but
it's
maybe
not
what
the
working
group
is
willing,
but
we
have
to
discuss
that
how
to
integrate
then
properly.
But
this
is
not
currently,
in
my
opinion,
done
so
I
might
be
wrong,
but
I'm
stating
my
my
vision
and
so
well.
C
F
B
F
D
F
Artie
earlier
of
you
and
sector
early
review-
and
we
have
the
latest
draft-
that's
posted,
which
is
IETF,
mu
or
313
between
the
twelve
and
thirteen.
There
is
only
one
change
that
I.
You
know
posted
that
on
the
mailing
list
as
well.
So
we
address
all
the
comments
to
the
satisfaction
of
the
commenter's,
except
for
the
two
comments,
as
noted
below,
one
of
them
is
from
Daniel
we
go.
This
is
the
comment
regarding
options
handling.
We
have
a.
A
F
Behavior
of
the
devices-
and
we
believe
there
are
no
issues
with
the
definition
of
transit
devices
and
moving
on
to
the
next
line.
I,
don't
TS
VRT,
already
review,
we
added
applicability
statement
and
reference
to
Europe
usage
guidelines
as
per
RFC,
8
0,
8
5,
and
we
updated
the
text
to
address
data,
integrity
and
checksum
usage
guidelines
for
ipv4
and
ipv6,
and
we
also
added
text
on
usage
of
genève
in
traffic
managed
control
environment,
as
outlined
in
RFC,
eight
zero,
eight
six.
F
A
F
And
in
general,
these
are
the
working
group
last
call
comments.
We
have
several
commenters
who
submitted
comments
on
the
working
group
last
call,
and
we
have
addressed
all
those
comments
and
we
did
post
them
on
the
mailing
list
and
to
the
satisfaction
of
the
commenter's.
So
we
just
to
give
you
a
summary
that
modified
clarity
on
the
options,
processing
and
checking,
and
we
also
provided
interpretation
on
options
by
the
transit
devices
and
we
also
clarified
by
providing
text
on
the
role
of
transit
device
lights.
F
We
updated
the
security
considerations
section
in
general,
we
added
text,
we
beefed
up
the
transit
security,
consideration,
sections
a
lot
for
clarity
as
well
as
we
removed
redundant
text
for
better
readability
purposes,
and
we
also
addressed
your
editorial
comments.
I
am
moving
on
to
the
next
slide
and
there
are
few
other
comments.
One
of
them
is
updated.
F
F
F
E
David
Black
has
transmitted
wave
uirr
first
of
all,
wanna
thank
you
long
ago
and
authors
for
doing
a
very,
very
productive
and
cooperative
job
of
addressing
with
ribbons
rather
difficult
comments
on
the
draft.
There
are
a
couple
of
issues
that
Barrington
from
from
France
Ferreira
Lindo
I
would
characterize
as
half
open,
where
the
proverbial
right
thing
to
do
in
quotes
does
not
seem
to
align
well
and
I
want
to
quickly
bring
these
these
the
working
groups,
attention
I,
expect
little
more
attention
during
ATF
last
call.
E
The
first
one
is
that
omitting
UDP
checksums
in
ipv6
is
an
interesting
area
to
zero
the
UDP
checksum.
You
want
to
increase
the
Hamming
distance
between
valid
packets.
So
as
much
as
you
can,
one
of
the
recommend
techniques
for
doing
so
is
to
vary.
The
ipv6
source
address,
not
clear
that
this
is
what
running
code
is
prepared
to
do,
and
the
other
one
is
that
it's
a
very
good
idea
for
an
encapsulating
nve
to
maintain
an
MTU
value
for
the
tunnel,
particularly
when
that
encapsulation,
vme
and
NV
is
not
at
the
track
origination
point.
E
The
upshot
is
that
if
you
send
a
packet
into
that
in
VN
and
NV
from
the
network-
and
it's
too
large-
you
get
the
ICMP
response
from
encapsulating
node,
rather
than
getting
it
getting
it
downstream
somewhere
and
risking
loose
using
ICMP
payload.
Both
these
I
think
we
round
up
as
maze
because
I
think
the
long
are
resigned
to
the
fact
that,
while
they're
good
things
to
do
running
codes,
not
doing
them.
F
B
Okay,
so
I
think
the
chairs,
and
the
idea
will
probably
just
discuss
how
to
proceed
with
this,
because
we
still
have
these
this.
This
ongoing
security
comments
coming
from
Daniel
I
mean
he
is
the
only
person
speak.
Who
still
has
concerns
on
the
list.
It
has
to
be
said
so,
but
they
you
know
they
may
be
valid
and
we
have
to.
We
have
to
be
aware
of
that.
Those
may
be
brought
up
again
in
the
security
Directorate
view
by
the
security
review
by
the
security
IDs.
B
If
we
progress
but
anyway
well,
we'll
get
together
with
the
authors
and
decide
how
to
proceed,
but
I
think
I
think.
As
far
as
we
can
see
from
spective
of
calling
consensus
from
the
list,
discussion
I
think
we're
probably
pretty
much
there,
but
there's
there's
still
some
discussion
around
security
that
we
have
to
be
aware
of
so
I
can
I
can
address
that
as
a
part
of
the
Shepards
review.
D
Go
ahead,
yes,
yeah
I
just
wanted
to
I.
Let
the
help
from
multiple
folks
there's
a
language
on
making
this
a
better
draft,
and
also
we
believed
after
the
version,
13
addresses
the
comments
for
the
security.
You
know,
considerations
as
well,
you
know
and
clarifies
the
text.
We
believe
it's
a
little
more
crisp
with
respect
to
the
role
of
trans
devices,
just
want
to
state
that
there's
a
comment.
Okay,
thank
you.
I
J
J
J
So
in
our
initial
draft
we
selected
this
last
option,
and
so
we
did
that
because
fab
Jalan,
which
is
a
new
feature
in
5g,
and
it's
enables
land
collectivity,
so
it
probably
does
most
or
a
lot
of
what
needs
to
be
done
on
the
veggie
side
right,
so
it
provides
IP
or
Ethernet
LAN
connectivity
between
a
4G
device
and
another
5g
device
or
another
land
device,
and
so
compared
to
an
internal
nve
solution.
The
interest
of
this
may
be.
J
J
So
here
is
a
you
know,
just
as
an
illustration
of
the
possible
type
of
interconnections
you
could
have.
You
have
envy
l3
domain
in
the
center
and
5g
system
presented
on
the
sides,
so
the
first
type
of
interconnection
would
be
between
the
control
plane.
Here
the
control
plane
evangeline
would
be
session
management
function,
including
the
management
of
a
fuzzy
line
group,
and
on
the
other
side
you
would
have
an
envier
and
in
between
you
can
have
either
it
can
be
some
form
of
cooperation
configuration
or
we
can
go
through
some
network
functions.
J
But
you
know
this
is
not
a
5g
type
of
use
case.
We
have
here
so
we
don't
want
society
to
go
into
any
detail
there,
but
just
to
have
an
idea
what
type
of
requirements
we
will
have
on
the
type
of
corporation
and
then
you
would
have
also
a
certain
type
of
interface
between
the
the
network
anchor
in
the
the
fact
discount
of
every
side,
so
that
the
UPF
here
and
nve
on
the
envy,
l3
side
or
some
final
gateway.
And
so
you
would
have
data
plane.
Packets,.
I
J
J
The
auto
VM
migration
support
would
be
an
important
feature
as
well,
and
since
those
are
5g
devices,
you
may
want
also
to
support
some
form
of
mobility.
So
if
you
move,
if
multiple
ups
are
connected
to
the
same
edge
data
center
or
multiple
data
centers,
which
are
interconnected,
you
may
need
to
support
you
in
moving.
You
know
relocating
from
one
UPF
to
the
other,
and
other
features
in
this
interconnection
could
be,
could
include
a
QoS
or
access
control.
J
So
basically
we
we
are
looking
really
for
a
community.
We
to
discuss
this.
We
like
to
know.
Basically,
there
is
some
form
of
interest
to
you,
think
and
and
vo3
data
center
would
benefit
from,
including
or
extending
via
virtual
networks
towards
5g
devices.
You
know
is
this
the
right?
This
is
a
last
item.
So
is
this
the
right
forum
for
it?
Do
you
think
that
there
is
interest
in
this
room
or
in
this
area,
to
basically
discuss
at
very
high
level
what
could
be
some
form
of
cooperation
between
a
data
center
and
Falchi?
K
K
Yeah
I
mean
it
may
be
a
good
thing,
because
people
are
not
very
clear
about
the
definition
of
theories
how
to
use
what
can
they
do
with
TVs?
Maybe
if
we
find
some
interesting
scenarios,
we
can
define
some
theories
for
Geneva,
which
I
think
it
will
be
helpful
for
you
to
extend
the
usage
scope
of
Geneva.
J
H
J
Actually,
I
hope
that
not
I
think
that
you
know
you
have
a
lot
of
work
being
done
in
the
5g
to
support
edge
computing,
as
you
know
probably-
and
there
is
a
lady
that
was
a
new
study
starting
to
enhance
the
support
for
computing.
So
I
think
that
right
now,
fudgie
does
not
really
mandate
any
specific
thing
outside
of
algae
in
terms
of
data
centers
that
were,
it
provides
some
mechanism
to
enable
interconnection
with
external
data
networks.
L
Assuming
that
I
understood
your
question,
I
think
that
one
of
the
reasons
why
we
thought
was
interesting
to
variant
is
this
paper
here
and
have
the
feedback
from
the
community?
Is
that
we're
also
looking
at
the
fragile
and
fragile
and
feature
that
is
going
to
be
developed
in
3gpp
and
their
based
on
the
requirements
I've
seen
there
yet
NSA
to
standards
at
this
last
case
of
the
rate
level
communication
in
particular
the
in
particular
the
use
of
Agilent
like
type
systems
for
industrial
IOT,
I,
think
that
I
will
be
the
use
case.
L
L
M
Want
to
bring
your
attention,
you
can
go
back
to
a
few
slides
to
show
the
structure
there
yeah.
This
is
a
little
bit
like
what
we
have
already
done
in
a
mostly
working
group
called
the
split
ma,
your
whatever
external
ma
yi.
So
the
difference
is
that
your
enemy,
which
is
external
device
from
the
end
device
and
currently
because
we
are
more
focusing
on
the
wired
apart.
So
there
is
a
VLAN
mapping
between
the
so
called
vni
in
the
villain.
M
I'm
probably
want
to
consider
for
the
one
I
mean
the
four,
the
five
chillin
case
there:
what
kind
of
mapping
information,
because
between
the
PTU
session
there,
you
don't
have
the
via
nine
information
which
provided
by
jean-yves.
So
that's
one
possibility,
that's
how
I
mean
any
which
we
can
help
in
your
scenario.
J
B
Those
those
have
read
the
draft
who
thinks
this
is
hidden
scope
of
MV
o3.
First
of
all
on
and
there's
some
contribution
and
do
three
convey
count
as
our
Charter
is
very
much
focused
around
kind
of
traditional,
fixed
data
centers
in
one
geographical
site.
Not
then
they
Center
interconnects,
but
they,
you
know,
and
inside
of
a
physical
doctor
Center
and
a
distributed
data
center.
Architecture
like
this
is
perhaps
a
little
bit
new.
B
B
I
K
K
So
I
guess
maybe
it
is
the
right
time
to
start
the
standard
edition
of
the
young
modem
so
what
to
build
a
base?
Louis
Riel?
First,
it
is
because
several
encapsulations
and
VPN
technology
exists
to
avoid
repeated
works
and
non
consistent
approaches.
A
common
and
the
reusable
young
should
be
defined
and
people
can
use
this
base
young
model
as
a
start
point
for
incremental
work
to
fit
a
specific
technology,
did
bring
a
controlling
and
just
augment
this
base
young
model
when
necessary.
K
So
we've
been
thinking
that
what
is
a
common
and
reused
or
young
reusable
parts
for
all
the
lvl3
protocols?
The
answer
is
obvious:
it
is
the
framework
and
the
architecture
which
is
defined
in
this
and
be
a
working
group
and
I
think
we
should
define
the
young
model
based
on
this
framework
and
the
architecture,
so
it
would
be
the
common
and
we
use
real
part
and
during
the
design
of
the
spatial
model,
we
have
also
take
into
taken
into
consideration
the
European
reality.
K
K
In
this,
in
this
blue
box,
we
have
defined
all
the
attributes
to
identify
the
mve,
and
we
also
consider
we
have.
We
have
also
considered
the
multihoming
cw's,
anycast
gateway
is
drawn
and
below
that
we
have
a
list
of
very
high
members
because,
as
you
can
see
here
in
the
will
in
the
NVE
of
the
model
below
1ve,
we
can
have
multiple
being
an
ice,
and
then
we
have
the
the
pier.
We
have
a
BGP
enabler
define
here
so
which
permits
only
to
discover
appear
in
a
dynamically.
K
Of
course,
the
pyramid
can
be
pointed
statistically
and
the
enabler
is
pravinia
basis,
thus
for
different,
very
high.
We
can
use
different
controlling
and
then
we
have
the
pier
and
the
ease
define
here,
and
we
also
have
flood
proxies,
which
is
the
in
the
RFC
80
to
93.
It
is
no
ice.
The
motor
has
a
service
note
in
this
RC
and
we
also
have
the
multicast
group
and
the
multicast
group
is
praveen
ibises,
so
we
can
achieve
the
attendant
isolation
and
then
we
have
it
is
still
in
the
container.
K
It
is
defined
for
the
noise
and
the
VM
peers,
and
the
Bayesian
model
has
passed
the
young
validation
and
for
next
steps
will
continue
to
check
the
compliance
according
to
the
views,
3
architecture
and
then
make
sure
the
thermal
energy
is
realigned
with
other
work
in
with
the
other
work
inside
ITF
and
the
comments
are
always
welcome.
And,
finally,
if
you
think
the
Yamato
is
in
the
scope
of
this
working
group
and
if
you
think
that
we
are
moving
in
the
right
direction,
please
consider
adopting
these
drafts.
Thank
you
any
comments.
Oh.
B
This
general
comment
for
me
I
think
it
needs
to
be
very
clear
on
the
scope
of
because
we've
got
another
young
model
draft
coming
up
next
city,
to
be
very
clear
on
the
scope
of
the
individual
young
models
that
one
one
is
generic
to
the
overall
architecture
and
the
other
one
is
specific
to
configuring.
The
parameters
of
a
particular
encapsulations
right,
yeah,
yeah.
Ok,
thank
you.
N
N
Ok,
history.
Yes
present
the
Traphagen,
a
maori
battalion
young.
For
many
times.
The
working
group
would
like
to
generic
young
model
for
coffee,
green.
Various
elements
need
a
bursary,
Octavia,
so
converts
just
a
mystery
with
Helene
young
into
destruct.
Oh,
yes,
this
is
ml,
three
configurations
below
inter-american
winners.
N
N
A
N
K
N
B
A
K
Don't
see
the
relationship,
maybe
relationship
is
I,
don't
think
it
is
obvious
here
because,
for
example,
here
I
see
below
that
Emile's,
for
instance,
we
have
the
way
an
eye
and
I
say
in
the
way
II
reference
model
below
and
ve.
We
can
have
multiple,
very
nice,
but
here
I
just
see
one
because
you
use
the
VI
the
key
of
a
real
three
instance.
You
know
yes,.
N
D
K
J
K
N
K
K
N
K
But
I
don't
think
it
is
correct,
because
we,
the
motivation
to
generic
encapsulation,
for
example,
vexillology
tree
extensive,
ve
or
Geneva,
is
that
we
are
trying
to
reduce
the
number
of
tunnels
instead
of
increasing
it,
for
example
between
the
same
pair
of
and
ve.
We
can
tunnel
for,
for
example,
for
one
tenant,
and
we
can
use
this
tunnel
to
carry
to
transport
different
kind
of
traffic.
For
example,
we
can
try,
we
can
transport
ipv4,
ipv6,
MPI's
and
sh
traffic
using
the
sim
tunnel,
but
I
hear
you
define
you
fix
it
to
the
finest
go.
N
P
You
can
osburgh
donnas
the
wrong
type
of
the
ID
for
this
ROM,
but
I
do
care
about
manageability,
though
I
think
I
have
something
to
say
a
question
for
the
chest.
May
I
just
try
to
hijack
the
stage
for
a
while
and
to
have
a
slightly
broader
discussion,
because
what
I
see
happening
here
is
talk
about
tiny
fragments
but
I'm,
not
certain
whether
the
working
group
has
the
say
broader
view
or
the
manageability.
B
P
So
the
problematic
aspect
that
I
would
see
is
first
Inc
and
vo
interface
is
an
interface.
It's
not
a
special
type
of
interest.
Yes
in
the
spherical
route,
it
might
be
a
special
interface,
but
in
a
reroute
it
is
not
therefore,
from
a
manageability
point.
It
should
be
put
into
the
hearer
as
any
other
interface
and
have
its
own
parameters.
P
The
transport
protocols
below
enter
and
client
protocols
above
they
again
should
be
aligned
with
the
overall
manageability
of
other
transport
and
client
protocols,
and
the
Ofri
is
no
special.
If
I
want
to
try
to
use
that
for
for
practical
purposes
in
a
practical
network,
if
it
is
radically
different
than
say
IP
or
MPLS
encapsulated
interface.
Something
is
just
not
right.
P
Another
aspect,
and
that's
probably
broad,
and
what
what
probably
needs
to
be
done,
is
to
revisit
the
use
cases
draft
and
try
to
talk
to
the
user
community.
What
problems
are
trying
to
solve
when
you're
free
and
how
they
are
trying
to
do
that,
and
this
will
come
as
a
set
of
requirements,
how
that
should
be
managed.
The
fact
that
you
have
a
young
model,
it's
good,
but
that
is
nowhere
near
enough.
It's
just
a
tool,
but
it
needs
to
fit
into
the
overall
management.
Here
are
some
how.
K
K
Ok,
first
intention
for
this
chart:
it
is
best
fast
use
of
PFT
in
Geneva
1
in
a
deluxe.
This
chapter
is
similar
to
another
job:
that's
EFT
for
exam
which
using
iesg
processing
so
as
I
know,
the
major
difference
between
a
Geneva
and
the
big
slam
is
that
Jenny
suppose
multi-protocol
payload
and
grabber
lens
options.
K
K
K
And
this
is
the
second
scenario
in
necessary
to
new
payload
is
neither
is
Annette
friends,
no
IP
packets,
nor
amperes
packets.
So,
in
this
table
you,
a
new
Janu
protocol
type,
is
requested
to
indicate
the
PFD
control
message.
So
we
have
a
question
to
ask
any
of
the
working
group
to
wait.
I
really
needed
this
kind
of
PFD
encapsulation,
because
I'm
not
sure
about
the
requirement
to
use
PFD
monitoring,
Janene
tunnel
of
non
I,
P,
no
IP
service.
B
I
guess
the
question
is:
do
we
need
to
separate
modes
for
encapsulation
of
BFD
in
here?
Do
we
need?
Can
we
just
rely
on
the
fact
that
IP
UDP
packet,
or
do
we
need
effectively
a
unique
protocol
type
for
BFD
in
in
the
genitive
header?
Is
this
kind
of
precedent
for
this
in
in
MPLS
and
past,
for
example?
For
you
know
you
can
either
run
BFD
on
on
IP
UDP
or
we
can.
B
You
can
explicitly
identify
in
the
g
OCH
that
you're
carrying
the
or
carrying
PFD,
but
that
was
specifically
for
cases
when
you,
when
you
didn't.
That
was
really
for
MPLS
TP,
for
example,
where
you
did
not
rely
on
IP
forwarding
at
the
influence,
I
think
I.
Think
in
the
case
of
caso
Geneva,
it's
it's
an
IP
underlie.
B
H
H
Yeah
on
that
note,
it's
it's
a
question
for
the
working
group
and,
in
my
opinion,
it's
a
broader
scope,
question
of
om
in
in
the
three
and
Janique,
because
the
question
is
so.
How
do
we
encapsulate
BFD
in
this
case?
So
this
is
a
question
for
this
draft
and
in
general,
so
how
with
demultiplex,
om
active
OEM
protocols
in
enviable
protocols
in
Geneva
in
particular,
so
I
think
that
since
janu
specification
is
stable,
is
ready
to
be
passed.
To
is
G
I!
Think
that
we're
at
a
time
where
we
can
start
looking
at
discretion,
yeah.
Q
Yeah
actually
I
do
have
some
basic
question.
First,
and
maybe
we
can
provide
feedback
about
was
that
we
should
include
an
IP
header.
So
is
this
semi
semi
Boutros
from
VMware?
So
so,
actually,
when,
when
you
are
running
the
ad
here,
are
you
are
you
testing
the
connectivity
of
the
tunnel
or
pair
vni
service?
G
H
Being
mentioned
in
the
document
presentation,
there
is
a
lot
of
similarity
with
the
BFD
for
VX
LAN
and
v
ni
similar
interpretation.
As
already
so
just
a
note.
You
probably
know
that
BFD
for
VX
LAN
is
waiting
for
ad
review,
so
it's
best
working
BFD
working
group
who
ask
all
and
will
follow
similar
interpretation
of
v
ni
in
this
specification
and
is
the
excellent.
So,
but
obviously,
if
you
have
some
suggestions,
okay,.
Q
Welcome
yeah
sure,
yeah
I
think
I.
Think.
The
other
comment
is
that
when,
when
we
did
be
a
different
pls
CP
and
who
didn't
include
an
IP
header,
it
was
mainly
because
we
didn't
have
an
IP
network
on
which
we
could
be
running
via
beyond
wisdom,
velocity,
but
I
think
the
case
here
is
different.
We
already
have
an
IP
network.
H
The
reason
I'm
sorry
if
it's
like
two
men
show
the
reason
to
question
whether
to
include
IP
header,
because
it's
extra
header
and
the
only
purpose
of
this
header
is
UDP
port
so
to
demultiplex
the
payload
so
think
of
our
ipv6,
addressing
more
than
necessary
overhead
we're
inflicting
just
to
carry
our
UDP
port.
So
that's
why
we're
suggesting
to
consider
use
of
ACH.
H
Okay,
but
just
think
of
you
know,
BFD
is
supposed
to
be
right.
Wait
right!
So
if
we
add
ipv6
IP,
UDP
headers
on
top
of,
if
memory
serves
me
like
40
bytes
of
BFD,
so
the
header
is
larger
than
BFD
right.
So
the
overhead
is
like
hundred
twenty
percent.
No,
so
I
think
that
it's
a
good
enough
reason
to
at
least
to
consider
it.
Q
H
Q
H
H
B
Q
Added
because
of
layer
to
only
and
I,
not
lay
asleep
yet
meaning,
as
stated
channel
was
added
for
pseudo,
odd
or
BCC
B,
because
food
water
carrying
layer
to
traffic
that
could
carry
IP
or
non
IP,
but
here
the
cases
that
we
already
have
an
IP
network.
If
you
are
worried
about
overhead,
that
is
a
anyways.
The
genève
header
is
an
over
and
as.
Q
Ip
network,
you
mean
underlined
anyway,
I
think
correct,
I,
think
I
think
when,
when
VC
C
V
was
a
added
or
associated
channel
was
added
for
pseudo
odd.
We
were
carrying
only
a
few
and
Lear
2
does
not
need
to
carry
only
layer.
3
can
carry
other
protocol,
others
an
IP
sorry.
So
this
is
why
you
needed
to
have
PFD
running
with
city
channel,
because
the
network
may
not
have
IP
and
so
on
right.
But
in
here
you
have
an
underlayer
cheese
idea
for
the
over
overlay
net
overlay
point
and
yeah.
Maybe.
A
Q
Think
I
think.
Okay
is
this:
what
you're
saying
is
that
I'm
carrying
a
layer
to
overlay
and
now
is
that
layer
to
overlay
may
not
be
an
IPO
overlay
then,
should
I
have
an
exporter
call
for
BFD
similar
to
the
city
channel,
so
I
can
run
be
a
via
on
it
right
as
a
control
message.
Only
right,
I
think
okay,
I
I
can
buy.
That
argument.
That's
fine!
Thank
you.
Thank
you.
G
I
G
G
Part
is
this
is
answered
in
if
the
control
bit
there,
the
control
bit
in
goo
the
control
bit-
is
set.
That
protocol
type
field
is
now
a
control
type
field.
It's
a
completely
different
numbering
space.
So
what
I'm
concerned
about
here
is:
do
you
really
want
to
add
an
ether
type
for
control
messages?
It
seems
like
a
slippery
slope,
so
you
might
want
to
consider
something
like
that.
I'm
just
going
to
check
with
the
chair.
B
H
H
How
its
interpreted
is
everything
for
genève,
again
not
for
genie
but
I
have
a
little
bit
analogy
and
point
to
what
has
been
done
in
SFC
and
Sh,
so
Anna
C
and
s
fcns
H
does
have
a
beat
which
in
8300
RFC
was
defined
as
identifying
or
am
packet.
There
is
draft
ITF
SFC,
multi-layer
om,
which
we
named
as
SF
c
active
or
a.m.
draft.
It
extends
this
definition,
so
I
don't
want
to
repeat
it
off
top
of
my
head.
H
So
just
take
a
look
there
and
we
you
and
we
have
defined
with
the
working
group
together,
how
all
beat,
with
their
protocol
field,
identify
combinations
of
OAM,
whether
in
header
extensions,
because
they
can
have
an
NS
h,
fixed
length,
extension
or
variable
length.
Extension,
header
and
I
am
in
the
payload.
So
it
defines
the
situation
that
om
information,
data
or
commands
are
in
a
header
part
or
in
the
payload
part,
or
there
is
none
o
am
at
all.
H
Okay
and
that
actually
there
was
a
discussion,
I
think
in
Bangkok
and
Adrienne
provided
case
that
led
us
to
a
point
to
situation
that
has
to
be
interpreted
as
erroneous
extension,
a
situation
that
OB
is
not
said,
but
next
protocol
field,
one
of
am
so
that
has
to
be
interpreted
as
erroneous
I
will
encourage
you
to
look
at
this.
I
had
I
made
presentation
at
our
t,
GV
g
group,
so
there
is
a
draft
that
I'm
kind
of
keeping
alive
until
I.
H
Think
that
everybody
who
supposed
to
read
it
and
listen,
got
to
me
with
questions
and
said.
Well,
let's
talk
about
it,
it's
overlay
or
am
identification
and
I
learn.
I
know
what
GUI
is
doing.
I'm
not
completely
agree
with
that,
because
there
was
not
all
OAM
goes
to
the
control
plane
in
particular.
Bfd
things
are
done
usually
in
the
hardware.
So
thus
changing
two
main
spaces
might
be
unnecessary
burden
on
the
hardware,
support
implementation,
but
I'm
open
to
discuss
it.
G
So
so
one
comment,
so
you
made
an
important
point.
There
are
two
flavors
of
this
one
is
the
payload.
Is
the
control
packet
and
to
2?
We
want
to
attach
control
information.
So
it's
not
it's
not
about
OEM
or
this
it's
about.
How
do
you
deal
with
these
two
flavors
I
have
arbitrary
control
information
to
attach
or
I
have
specific?
In
this
case,
it
looks
like
the
payload
is
the
control
data,
which
means.
G
Is
the
payload
contain
an
IP
packet?
That's
another
thing
that
we
just
discussed:
no,
no!
No!
It's
not
what
I
mean.
Is
it
a?
Is
it
being
attached
to
a
user
IP
packet?
No
okay!
So
then
I
consider
that
a
control
packet,
it's
not
okay,
I'm,
not
I'm,
not
concerned
about
data
averse
or
hardware
versus
not
Hardware
on
the
wire.
What
does
this
pack
look
like?
If
I
say
this
is
protocol
type
800
and
that
those
bits
are
some
kind
of
control
information?
G
Q
E
Q
E
Busy
mumbling,
oh
good,
good,
lord,
don't
do
that!
Okay!
So
this
is
these
copper
levels
today,
they're
black,
we
need
to
talk
about
why
we're
doing
BFD
in
the
first
place.
What
is
the
thing
on
the
far
side
whose
liveness
and
ability
to
talk
to
us,
we'd
like
to
establish
and
I
believe
what
we're
going
after
here
is
the
chunk
of
the
NVE
that
knows
how
to
decap.
E
That
knows
how
to
decap
genève,
so
the
hardware
is
busy
being
being
referred
to.
Is
the
hardware
that
chews
on
that
that
chews
on
the
genève
header,
being
caption
here
as
most
is,
is,
is
an
effective
way
to
do
that,
because
what
essentially
it
says,
is
the
hardware
chews
on
the
genève
header,
something
in
there
says
this
is
BFD
and
the
BFD
payload
comes
next
and
now
you
have
BF
be
solving
the
problem
you
want
to
solve.
Is
the
NVE
capable
tune
on
on
genève
or
did
something
break
before
it
opened
up
that
header.
E
Want
the
BFD
header
to
be
as
close
to
the
thing
whose
liveness
I'm
testing
the
more
headers
you
add
in
the
middle,
the
more
ways
there
are
to
break
BFD
without
breaking
the
the
forwarding
agent
I
care
about
or
the
other
way
around,
the
more
I.
The
further
away.
I
move,
BFD
from
from
the
chunk
of
hardware's
lightness,
I
care
about
the
more
opportunities
are
for
BFD
and
the
hardware
to
not.
E
E
Q
B
I
think
somewhere
I
think
somewhere.
We
need
to
describe
hell
more
comprehensively
how
the
obit
is
used
and
how
that
should
be
interpreted
in
Geneva
I
mean
in
other
technologies
like
Siddha.
Well,
we
had
you
know
you
you,
you
have
you
define
an
exception
mechanism,
whether
that
0
0
0
1
be
on
a
header
or
it
roll
at
you
know,
I
mean
to
me
my
interpretation
of
the
over
here
is
it's
an
exceptional
mechanism
that
says
this
is
a
control,
channel
message
and
no
more
than
that
right.