►
From YouTube: IETF99-NVO3-20170719-1520
Description
NVO3 meeting session at IETF99
2017/07/19 1520
https://datatracker.ietf.org/meeting/99/proceedings/
A
B
C
D
D
Okay,
so
blue
sheets,
so
there's
two
sets
of
blue
sheets
going
around
one
down
each
side
of
the
room.
Please
please
fill
it
in
when
it
when
it
reaches.
You
know
taker,
so
big
miss
doing
that
during
the
minutes
entails
doing
a
volunteer
to
be
JavaScript.
Thank
you
very
much
to
both
of
those
right.
This
is
this
is
the
first
normal
meeting
we've
had
in
a
while.
So
we've
got
you
as
you.
D
If
you've
been
to
the
previous
ITF,
so
you'll
be
aware,
we've
had
this
experiment
running
where
we've
been
doing
some
roundtables
and
on
different
topics,
and
we've
had
some
success
with
that.
That's
generated
some
drafts
in
the
security
area,
so
we're
now
going
to
focus
this
meeting
mostly
actually
on
those
security
drafts,
but
we
do
a
really
practice.
So,
please,
if
you're
presenting,
keep
your
time
slot.
Otherwise
we're
really
gonna
have
to
cut
you
off.
Thank
you,
okay.
So
the
agenda.
D
D
Okay,
so
milestones
so
we
have
not
dated
these
for
a
bit.
The
chairs
will
we'll
go
in
and
discuss
these
I
think
probably
be
able
to
update
them
again
that
time
document
status.
So
we
have
one
new
RFC
8151,
which
is
the
use
cases
for
DC
VPNs,
nothing
in
the
RSU
editors
queue
at
the
moment
the
multicast
frame,
a
draft
went
through
last
call
and
we
did
publication
request.
So
that's
where
the
Lea
now
and
the
other
two
documents
of
note
is
that
we
adopted
the
I
show
there's
a
typo
on
a
slide
here.
D
One
of
these
jaws
is
the
design
team
document
for
the
data
plane
encapsulation,
so
that
was
adopted
and
there's
also
draft
Geneva.
That
is
a
doctor.
Thank
you,
okay,
the
other.
The
other
thing
that
we
tried
to
do.
We
at
ran
an
adoption
poll
for
to
OEM
drafts
that
were
the
output
of
the
routing
area,
OEM
design
team.
As
regarding
the
overlay
OEM
header
and
CCNC
undermanned,
CC
and
cv
for
overlay
networks,
there
wasn't
really
consensus
to
adopt
the
drafts,
but
the
chairs.
You
know
we
need
to
make
some
kind
of
progress
in
this.
D
Okay
thanks
so
one
other
thing
I
should
mention
is
that
we
do
have
one.
We
will
have
one
remote
remote
session
from
Halong.
Go
for
a
draft
genève
update,
so
we're
going
to
try
and
do
that
through
me,
taco
in
a
moment
so
I
think
first
up
on
the
agenda
is
Sammy
with
the
design,
encapsulation
design
team.
E
E
E
Yeah,
since
last
updates,
the
draft
became
our
group
draft,
as
mass
we
mentioned
here
so
I'm
gonna
be
discussing
mainly
the
changes
that
went
to
the
draft
okay.
So
we
did
couple
of
removal.
Here
we
removed
backward
compatibility
to
be
excellent
as
a
requirement.
There
were
those
yeah.
Those
updates
were
to
reflect
the
comments
that
was
sent
on
the
list
and
many
many
discussions
that
happen
on
this
graph
over
the
NBS
realest.
E
So,
as
I
mentioned,
we
remove
the
backward
compatibility
as
a
requirement
to
be
excellent.
User.
Sangu
removed
is
issues
with
extending
the
bit
width
flags
that
was
under
goo
as
well
as
the
rat.
Then
following
changes
are
more
addition
or
clarification
to
the
document.
So,
for
example,
we
added
a
recommendation
for
the
control
plane
to
have
the
working
group
work
on
a
draft
for
guidance
on
how
control
plane
would
would
help
in
option
processing
and
as
well
ordering
and
option
size
and
exporter
calls
that
could
be
signaled
with
Genevieve
using
control
plane.
E
So
the
control
plane
participation
in
general
was
that
this
is
a
dynamic
or
a
centralized
control
plane
as
well.
We
clarified
the
transit
node
rule,
so
what
kind
of
option
would
be
processed
by
the
transit
nodes?
So
we
clarified
that
only
a
subset
of
option
here
will
be
looked
at
by
the
transit
node.
E
E
We
clarified
how
the
design
team
addressed
some
usage
model
while
considering
the
requirement
you
know
for
here
is
a
implementation
of
Geneva
option
for
both
software
and
hardware.
Is
that
were
a
few
clarification
as
well
that
we
made
for
statement
we
had
in
the
recommendation
about
early
bit
assignment?
This
was
related
to
the
GU
in
cap.
So
it
clarified
that
too
on
how
we,
how
our
processing
for
an
option
that
could
be
in
an
extension
for
a
bit
extension
for
you
will
be
processed
and
I.
E
Think
you
can
look
up
the
explanation
in
the
draft
as
well.
We
added
some
classification.
Sorry
some
clarification
about
the
requirement
to
to
add
this
variable
lengths
and
different
subtypes
from
where
this
requirement
came.
So
we
had
a
clarification
that
this
came
from.
Om
and
this
wall
came
from
some
security
extension.
E
We
added
more
clarification
on
the
OEM
aspect,
because
there
were
some
requirement:
meat
from
OEM
about
alternate
marking
and
the
need
of
two
bits
and
the
sink.
Recently
there
were
some
discussion
about.
How
can
we
live
with
one
bit
instead
of
two,
so
so
I
think
that
om
in
general
usage
and
usage
models
justification
need
to
be
discussed
more.
E
There
were
some
discussion
about
removing
or
repurposing
the
current
way
ambit
in
the
genève
header,
and
so
we
need
to
I
think
has
mass
dimension
to
to
talk
more
about
how
OEM
can
be
addressed
in
general,
and
how
will
that
impact?
The
genève
time
array
we
recommended
for
gen8
to
follow
the
fragmentation
recommendations
that
was
made
for
bowie
for
boost
layer,
2
and
layer,
3
VPN
as
well,
and
we
gave
the
section
from
the
P
we
document
here.
Is
that
discuss
how
fragmentation
should
be
hand.
E
There
were
some
discussion
as
well
as
a
critical
bit
on
the
genève
draft,
and
you
know,
and
we
recommended
you
have
some
text
on
how
critical
bits
can
be
used
with
controlling
specifying
the
critical
options.
So
so
there
were
some
discussion
on
that
and
the
things
a
Geneva
document
Elango
well
as
well,
be
addressing
some
of
the
comments
here,
including
this
one
that
we
are
some
of
the
recommendations
that
we
made
in
the
design
team
in
cap
document.
E
We
as
well
added
for
the
telemetry
option,
a
recommendation
for
a
use
case
that
require
256-byte
option
on
in
a
single
TLV.
There
was
no
consensus
to
extend
a
single
TL
VLANs
to
256,
but
I.
Believe
further
discussion
is
needed
on
that
aspect,
so
that
change
as
well
would
require
some
discussions
that
we
need
to
do
with
the
genève
tunneling
cap,
whose
the
Geneva
right
we.
Finally
a
couple
of
things
here,
which
changed
the
D
key
Ellis
reference
in
the
et
cap
document,
replace
it
with
IPSec
and
DTLS.
E
So
sync
was
that
yeah
was
that
saying
those
are
the
changes
we
made
or
we
add,
visiting
the
document,
workgroup
document,
the
IETF
and
vo
screen
cap
document,
but
as
well
as
there
were
some
more
more
comments
that
and
discussion
happening
an
hour
the
list
on
the
mailing
list
and
we'll
be
updating
that
in
the
next
version,
discussion
were
related
to
the
calculation
of
the
entropy
as
well.
Some
discussion
were
related
about
traversing
net
or
doing
some
s
net.
So
those
are
some
of
the
discussions.
That's
happening
of
the
list.
E
G
Might
tell
mizrahi
marvel
I'm
a
co-author
of
this
draft,
so
I
have
a
question
which
is
more
intended
to
the
chairs.
So
now
this
is
a
working
group
document.
I
guess
means
the
recommendations
are
adopted
by
the
working
group
and
at
this
point,
V
excellent
GP
is
still
a
standard
write
draft.
So
my
question
is
regarding
the
future
of
the
X
on
GP.
Is
there
a
future
and
if
so,
when
will
the
recommendations
come
into
effect
Thanks?
G
D
I
think
when
we
what
we
said
when
we
had
charge
at
the
design
team
and
when
the
design
team
came
up
with
a
recommendation
for
Geneva,
was
that
the
other,
the
other
encapsulation
drafts
would
have
to
wait
for
Geneva
to
be
sent
to
the
ISJ
adopted
it's
our
right
and
then
following
that.
So
when
the
working
group
is
basically
done
with
Geneva,
we
can
progress.
If
people
want
to
progress
as
an
informational
document
or
experimental,
we
have
yet
to
determine
the
exact
stasis
of
it.
You
know
the
other.
D
The
other
drafts,
like
vx1
GPA
I,
think
there's
some
changes
that
need
to
be
made
for
examples.
The
VX
on
GP
Draft
anyway.
At
the
moment,
for
example,
it's
I
was
it
says,
standard
track
on
it
and
we've
said
it
won't
be
standard
track,
but
the
way
it
requests
and
ion
allocation
is
only
valid
for
standards
track
documents.
It
won't
stand
as
action.
So
there's
a
few
things
we'll
have
to
fix
in
the
draft.
Let's
make
it
appropriate.
If
that's
what
you
would
want
to
progress.
E
E
D
D
I
D
E
J
Yeah,
first
of
all,
thank
you
for
the
IETF
and
the
meeting
organizers
for
providing
me
the
remote
presentation
opportunity
so
I'm
going
to
cover
the
draft
genève
update
this.
We
are
closely
coordinating
with
with
the
design
team
so
that
you
know
the
questions
that
were
asked
in
the
previous
session.
I'd
be
addressing
this
during
this
presentation.
J
Yes,
so
this
is
a
recap
of
the
draft
Jenny
or
you
know
the
previous
version,
when
we
did
this
update
and
the
update
was
based
on
the
recommendations
by
the
design
team
and
as
Sami
mentioned
earlier,
the
first
one
of
them
is
the
control
plane
for
the
constraints
for
the
options.
So
what
we
did
this
one
is
this.
J
This
has
been
addressed
in
Section
4.2.1,
where
we
stated
that
the
control
plane
can
limit
the
number
of
option,
TL,
B's
and
TLB
ordering
size
of
tlvs
and
what
DL
V's
can
be
transmitted
between
the
NVE
end
points.
So
all
those
constraints
were
added
to
this
section,
and
this
helps
the
software
as
well
as
the
hardware
implementation
of
the
the
Geneva
in
the
end
points,
and
also
if
the
control
plane
should
have
the
ability
to
describe
the
supported
tlvs.
J
To
the
end
points,
and-
and
also
we
mentioned
that
you
know
in
the
absence
of
the
control
plane,
an
alternate
configuration
mechanism
may
be
used
for
this
purpose
and,
as
I
said
that
you
know
this,
these
things,
you
know
all
these
tax
has
been
already
included
in
the
draft
in
the
current
version.
In
the
Oh
fall,
so
let's
move
on
to
the
next
slide.
Okay,.
J
Yes,
so
after
that,
the
change
is
like
further.
Discussion
were
happening
in
the
mailing
list
and
as
well
as
some
of
these
recommendations
have
been
captured
in
the
design
team
draft
recent
design
team
draft
for
trade,
so
I'm
going
to
go
over
the
recommendations
here.
The
first
one
is
the
follow
the
recommendation
for
the
overlay
services,
like
the
pw
III
for
the
l2
l3
VPN.
Their
main
objective
for
this
request
is
to
prevent
fragmentation.
J
So
one
of
the
ways
these
you
know
the
the
PW
three
draft
is
addressing
that
one
is
on
our
the
RCS,
addressing
that
one
is
guaranteeing
a
larger
MTU
size
for
the
tunnel
overhead.
So
we
have
a
similar
draft
in
Section
4.1.1
engineer
that
outlines
you
know
best
practices
for
preventing
fragmentation,
pretty
much.
J
One
of
them
is
the
you
know
two
bits
for
alternate
marking
for
the
performance
measurements,
and
there
was
also
another
question
related
to
do.
We
really
need.
Is
there
a
need
for
an
OEM
bit
and
or
if
so
then
clarify
the
deed
for
the
OEM
bit?
And
you
know
there
are
you
know
other
OAM
ducts
available
in
there
and
you
know
in
general,
I
would
say
that
the
OEM
proposals
and
use
cases
need
further
discussion
before
we
go
ahead
and
make
changes.
J
If
you
look
at
the
draft
tests,
you
know
which
talks
about
I
am
in
fact
that
drafts
just
are
the
proposals,
the
use
of
the
existing
om
bit
in
order
to
disambiguate
between
you
know,
OEM
frames
was
just
a
the
normal
data
frames
and
also
you
know.
The
draft
also
poses
a
further
an
OEM
channel
in
order
to
carry
the
OEM
messages
as
well,
and
so
this
is
just
an
example,
but
there
are
other
proposals
as
well
as
on
table.
So
we
wanted
to.
J
J
J
Is
the
recommendation
to
provide
additional
text
in
order
to
clarify
the
usage
of
the
critical
bit
processing?
Of
course,
the
critical
bit
is
helpful
in
options
processing
both
in
software
and
hardware
and
more
specifically
in
hardware.
So
it
allows
quickly
to
look
at
the
critical
options
speed
and
if
the
hardware
is
capable
of
processing
the
options,
it
will
continue
to
process
the
options
and
if
it
is
not
capable,
it
also
allows
the
hardware
to
skip
over
the
options
and
and
then
process
the
rest
of
the
payload
before
it
forwards.
J
You
know
the
data
out
stream
or
the
higher
layers
in
the
stack.
So
that's
one
of
the
advantages
of
having
the
critical
bit
but,
and
that
has
been
clarified
or
if
it
is
not
clarified,
we
will
add
additional
text
in
order
to
clarify
this
information,
and
the
other
recommendation
is
to
increase
the
single
TLV
option
to
256-
and
this
is
this.
J
One
was
specifically
for
a
telemetry
use
case,
and
this
was
discussed
during
the
previous
round
table
as
well
as
during
the
working
group
meeting
after
the
roundtable,
and
there
was
no
consensus
regarding
this
use
case.
There
were
multiple
discussions
happening
at
this
point
for
completeness
sake,
so
we
wanted
to
bring
this
up
here.
I'm
sure
that
the
working
group
has
an
opportunity
to
look
at
that
and
well
and
comment
on
this
one,
and
based
on
that,
you
know
we
will
go
ahead
and
make
any
changes
if
needed.
J
J
If
telemetry
option
takes
away
the
entire
space,
then
it's
going
to
be
difficult
for
carrying
other
options
and
also
in
you
know,
one
of
the
examples
that
was
quoted
is
the
p4
int,
which
is
specifying
an
example
use
case
of
how
to
carry
the
telemetry
and
that
same
document
mentions
about
how
you
can
carry
split
the
you
know,
information
into
two
different
options
to
carry
it
over
Geneva.
So
that's
another
example:
I
can
I
can
quote
you
so
the
as
I
said
right.
J
This
requires
further
discussion
before
we
affect
any
any
change
to
the
Taft
and
next
slide
please
so
after
you
know,
some
of
these
information
has
been
captured,
as
I
mentioned
in
the
design
team
draft,
and
then
we
have
been
closely
coordinating
with
the
design
team
to
make
sure
that
you
know
we
capture
all
those
points
when
we
make
make
a
draft
update
on
Jenny
and
even
after
the
design
team
that
was
published.
Further
discussions
were
on
the
mailing
list
and
we
are
closely
observing
that
one
and
based
on
how
the
discussion
progresses.
J
L
L
L
So,
as
you
can
see,
we
have
NV
e
and
then
we
have
some
geneveive
forwarding
elements.
So
the
packet
has
to
go
from
one
tenant
through
the
NVE,
so
the
different
forwarding
elements
back
to
a
tenant
system
somewhere
else,
so
the
genie
be
overly,
is
really
between
the
tenant
and
the
infrastructure.
So
it
has
different
goals.
L
One
of
those
is
as
gene
the
genie
be
overly,
is
managing
the
different
tenants,
so
it
has
to
isolate
each
of
the
tenants
and
make
sure
traffic
is
not
mixing
between
the
different
virtual
networks,
and
he
also
has
to
protect
all
this
traffic
from
the
infrastructure,
which
can
be
seen
as
a
different
entity
and
also
the
overlay
network
has
to
be
quite
robust.
So
these
are
the
three
goals
tenant
insulation.
So
you
want
to
avoid
that
some
traffic
goes
into
one
virtual
network.
L
You
want
to
prevent
that
some
traffic
that
leaks
outside
the
virtual
networks
be
analyzed
and
then
re-inject,
and
you
want
also
maybe
to
provide
an
additional
service
to
the
tenants
which
is
where
will
protect
your
traffic
to
an
infrastructure.
We
might
not
trust,
and
then
the
overlay
network
should
be
rubbished,
which
means
robust
against
replay
attacks
and.
L
Yeah
against
traffic
modifications
and,
of
course
well,
we
should
be
protecting
the
traffic
against
the
infrastructure,
so
the
first
thing
is
that
tennis
might
encrypt
their
communications
using
IPSec,
for
example.
Well,
in
this
case,
it
won't
be
part
of
Geneva,
the
Geneva
overlay,
to
provide
some
of
the
protections
in.
In
that
case,
the
tenants
are
somehow
providing
some
of
the
ways
but
to
protect
their
communications.
L
L
So
well,
what
we
considered
is
mostly
that
any
nodes
can
be
performing
an
attack
like
injecting
injecting
some
traffic's
and
that
any
nodes
on
path
must
be
able
to
read
the
Geneva
header
and
the
destination
must
be
able
to
authenticate
the
incoming
packets.
So
that's
how
we
base
the
analysis
on
so
here
is
a
some
of
the
requirements
we
went
to
in
order
to
avoid
traffic
injections.
L
So
when
you,
when
you
are
evolving
within
a
virtual
network,
you
don't
want
actually
any
packets
going
well
illegitimate,
illegitimate
packets
going
to
your
virtual
network,
so
the
first
requirement
is
a
Geneva
and
ve
must
be
able
to
authenticate
the
Geneva
header,
including
the
immutable
Geneva
options.
This
means
that
a
Geneva
packet,
where
you
have
switched
one
bit
in
the
NVE
I,
won't
be
able
to
reach
the
modify
target,
for
example,
but
that's
of
course
not
enough.
L
So
we
went
to
Geneva
and
we
must
be
able
to
agree
that
the
authentication
also
includes
some
of
the
options.
Of
course
the
option
says
do
not
change
and
it
should
be
also
included
some
parts
of
the
Geneva
payload.
So
the
reason
we
think
it's
not
always
it
doesn't
always
need
to
include
the
Geneva
payload
is,
for
example,
if
you
only
want
to
authenticate
a
single
Geneva
option.
So
in
that
case
the
payload
is
not
involved,
but
the
other
thing.
L
The
other
reason
we
don't
want
to
while
we
may
not
want
to
include
the
full
Geneva
payload,
is
that
during
the
Chicago
session,
we've
been
told
that
it
would
take
too
much
resource
to
include
the
wall
pay
lot
and,
for
example,
if
the
traffic
is
protected
with
TLS
or
D,
TLS
or
IPSec,
then
you
can
lower
the
need
for
results
by
limiting
the
amount
of
data
you
encrypt.
So
that's
some.
Some
of
the
reason
then.
L
We
also
mentioned
that
well
require
three:
is
that
a
Geneva
in
timothy
intermediary
forwarding
element
may
be
able
to
validate
the
authentication
before
the
packet
reached
the
NVE.
It
clearly
means
that
if
is
well,
provisioned,
encryption
or
authentication
and
validation
can
be
done
outside
the
NVE,
for
example,
and
that
when
a
an
inter,
inter
Missouri
forwarding
element
wants
to
include
an
authenticated
Geneva
option,
if
you'd
be
able
to
do
so,
I
don't
know
if
there
are
any
comments
or
when
I
could
I
think
you
feel
free
to
jump
on
the
mind,
so
some
next
requirements.
L
Well,
we
would
like
that,
even
though
some
Geneva
packets
are
authenticated,
note
forwarding
nodes
that
are
not
supporting
that
authentication
option
or
validation
can
still
work
and
for
what
the
different
Geneva
packet
through
the
data
center
requirements
6.
So
we
have
split
that
one
in
two
different
requirement.
L
You
should
be
able
to
apply
different
type
of
security
to
the
different
flow
you
have
and
that
the
big
question
is
how
you
characterize
the
flow
and
well
the
we
assumed,
or
we
required
that
you
should
be
able
to
describe
the
flow
from
the
Geneva
clear
text
packet,
which
includes
de
genève,
a
fixed
header,
the
options
and
eventually
some
part
of
the
payload
de
genève,
a
payload.
The
reason
to
include
some
parts
of
the
Geneva
payload
is
still.
L
L
So
that
was
for
traffic
injection,
and
now
we
have
some
different.
If
we
we
considered
redirections,
it
starts
with
well
a
leech
of
sum
of
traffic,
and
then
the
traffic
is
being
rejected.
It
could
be
modified
or
not
so
in
the
reinjection
is
mostly
the
same
as
injection
but
and
leakage
is
a
little
bit
hard
to
well,
it's
harder
on
the
protocol
to
provide
some
require
protocol
requirements
to
avoid
leakage,
it's
more
mostly
part
of
how
you
deploy
the
Geneva.
L
L
L
Minutes,
okay,
so
now
that
we
well,
we
worked
on
what
we
have
only
addressed
how
to
isolate
the
tenants
from
an
attacker.
So
now.
The
second
part
is
how
we
can
make
the
overly
bravas
itself
so
whether
the
type
of
attacks
we
consider
at
that
level
is
an
attacker
that
is
replaying
some
traffic.
So
you
can
sometime,
modify
the
header,
but
even
though
he's
not
modifying
the
header,
if
you
replace
no
I
am
traffic.
Well,
usually
you
design
the
your
networks
for
a
given
amount
of
traffic
on
each
category.
L
I
L
G
Is
wahi
marvel
so,
first
of
all,
thanks
for
putting
together
this
draft
one
thing
that
was
missing
for
me
to
understand
the
entire
picture
was
threat
analysis
to
understand
the
set
of
threats
that
were
trying
to
deal
with
the
set
of
attack
vectors
and
then
maybe
to
have
kind
of
a
mapping
between
requirements
and
attacks,
because
this
was
would
allow
us
to
understand
the
priority
of
the
requirements
and
make
sure
we
haven't
forgotten
in
any
attacks
or
just
to
make
sure
that
everything
fits
together.
Okay,
so.
L
K
Description,
linear,
thanks
for
putting
it
together
and
I,
had
a
couple
of
questions
like
first
of
first
of
all
on
the
e
and
the
requirements
stuff
right.
I
would
like
to
see
some
kind
of
description
on
like
why
just
encrypting
the
UDP
payload,
it's
not
sufficient
right
and
what's
the
advantages
and
disadvantages
doing
that
right,
so
encrypting
UDP
outer
yeah,
okay,
yeah,
okay,
so
like
that
gives
you
like
some
benefits
and
some
disadvantages
so,
like
you
know,
that'll
be
something
that's
good
to
have,
and
the
second
thing
is
just.
L
K
Sounds
good
and,
and
the
other
thing
is
like
the
document
structure-
is
a
bit
hard
to
handle.
So
this
has
the
exact
same
document
structure
as
IPSec
pretty
much
right.
So
there's
an
architecture
and
I
think
it's
a
bit
too
heavy.
Wait
for
this
right,
like
so
and
they're
like
pretty
simple
document,
the
crypto
suites
are
somewhere
else
so
like.
Maybe
we
don't
need
all
that
complexity
to
keep
all
these
things
separate.
Maybe
one
document
could
cover
the
architecture
and
the
options
together
right
like
because.
L
B
K
L
L
Well,
on
the
slides:
well,
we
had
a
we
started
with
the
discussion
on
basically
why
the
current
DTLS
solution
and
why
the
current
IPSec
solution
does
not
feel
exactly
the
requirements
and
also
why
we
need
to
find
out
a
specific
solution
that
is
specific
to
Geneva.
So
I'm
gonna
skip
the
slides
but
I'm
happy
to
cut
some
questions
so,
as
mentioned
before.
Well,
basically,
what
we're
doing
is
and
well
as
a
strong
IPSec
flavor,
and
we
use
the
anti
replay
the
authentications.
L
So
it
enables
the
authentication
of
the
the
fixed
header,
the
options,
a
subset
of
the
options.
We
believe
it
does
not
impact
forwarding
notes
that
are
not
aware
of
these
options,
and
it
also
enables
someone
in
the
past
to
insert
an
Authenticator
options
or
to
insert
an
options
on
an
authenticated
packet.
So
this
is
so
it
looks
very
much
well.
This
is
a
Geneva
option
which
looks
blue
much
like
the
IPSec
aah
option.
The
only
difference
is
that
the
ID
used
in
IPSec
is
called
the
SVI
and
it's
a
32
bits
long.
L
L
So
this
is
how
it
works.
We
have
the
genophix
header,
some
Geneva
options
that
are
not
covered,
and
then
we
indicate
that
from
that
with
the
Gallow
option,
we
just
indicate
from
that
point
up
to
the
covered
length.
This
is
going
to
be
authenticated,
so
things
that
are
outside
the
covered
lengths
are
not
authenticated
and
think
before
you
go
between
the
GAO
and
the
Geneva
header
or
not
authenticated
either.
L
So
the
well
I
think
in
the
design.
The
the
event
one
of
the
advantage
of
doing
so
is
that
when
you
see
the
packet,
you
know
exactly
what
is
going
to
be
authenticated
and
which
options
is
going
to
be
authenticated
and
which
are
that
are
not
going
to
be
authenticated
and
you
also
have
to
cover
them.
So
you
can
process
the
packet
at
that.
Well,
the
processing
is
very
much
like
the
IPSec,
so
I'm
going
quite
fast,
well
the
encryption
option.
So
it's
really
like
the
IPSec
as
well
ESP.
L
One
of
the
difference
is
that
usually
in
ESP,
you
include
the
encrypted
packet
into
that
option,
but
Gav
options
have
some
limited
size,
so
we
basically
adopted
the
same
design.
As
for
the
authentication,
which
is
we
put
a
marker,
the
authentic
Geneva
Authenticator
option
that
says
from
here
we
are
authenticating.
This
cover
length
encrypting
this
cover
length
of
amount
of
data
and
the
signature
is
in
the
the
options
itself.
So
that's
not
an
issue
problem,
so
basically
you
will
have
the
fixed
header,
the
Geneva
option
that
are
not
protected.
L
L
Another
thing
we
changed
is
that
the
we
usually
use
authenticated
encryption
so
and
in
our
case
the
Geneva
fix
header
is
also
authenticated.
So
we
can
bind
the
packets
together
the
two
part
of
the
packet,
so
we
will
see
another
proposal
later
and
you
will
be
also
to
compare
those
two
proposals,
but
we
are
happy
to
see
any
any
comments
on
that.
I
think
I
was
fine
for
this
one.
L
L
Now
we
need
to
be
able
to
orchestrate
all
these
options
together
according
to
flows.
So
this
is
really
the
purpose
of
the
security
as
architecture
from
one
flow
to
be
able
to
associate
to
write
security
options
and
then,
when
you
receive
the
packet
to
be
able
to
decrypt
validate
this,
these
protected
packets
and
then
which
is
important
to
make
sure
that
the
resulting
clear
text
packet
match
the
security
policies.
L
So
it
looks
complex,
it's
not
so
much
complex,
but
it's
like
a
psychic.
So
the
model
we
had
is
you
have
Geneva
and
you
have
what
we
call
the
Geneva
security
model.
So
you
have
a
clear
text:
Geneva
packet,
it
is
process
protected.
Then
the
receiver
got
a
protected
Geneva
packet.
We
process
that
and
give
back
a
clear
text
packet.
L
So
well,
the
policies
are
you.
When
you
have
received
a
clear
text,
Geneva
package,
you
need
to
know.
If
it,
you
have
to
discard
it
to
bypass
that
one
so,
which
means
not
protected
or
to
protect
it,
when
you
have
to
protect
it,
you
need
to
have
some
security
material
ready.
So
that's
what
we
call
the
security
Association,
so
the
policies
say:
do
you
have
to
secure
it?
How
to
secure
it
that
the
security
Association?
L
So
the
big
question
is
how
we
define
a
packet
needs
to
be
protected
or
not.
So
we
use
what
we
call
traffic
selectors,
because
we
have
to
read
from
the
packet
what
needs
to
be
well
which,
if
the
packet
needs
to
be
protected
or
not,
and
so
we
are
listing
a
few
fields.
So
the
fields
include
the
fields
of
the
Geneva
header,
as
well
as
some
inner
some
fields
of
the
inner
packet.
L
The
real
question
is
currently
I
think
we
have
been
a
little
bit
exhaustive,
but
a
field
should
be
mentioned
if
it
makes
sense
to
say:
okay,
according
to
this
field,
we
might
need
different
security
policies
if,
for
example,
I'm
just
taking
the
example
of
the
first
field
to
Geneva
version,
if
it
makes
no
sense
to
say
well,
if
this
is
version,
one
I'm
going
to
use
this
security
policy,
while
if
it's
version,
two
I'm
gonna
use
this
one.
If
we
don't
have
this
kind
of
distinction,
then
the
field
should
not
exist.
L
L
So
if
that's
too
complex-
or
if
it's
not
enough
well,
it's
time
to
say
it
well,
outbound
processing,
so
physically
you
receive
the
packet
according
to
the
traffic
selectors
you
have
designed,
which
that
is
the
security
policy
you
mentioned.
Okay,
this
packet
has
to
be
protected.
Then
you
apply
the
different
security
options,
which
means
that
currently,
what
we
for
seen
is
that
in
a
control
environment
you
will
provide
the
security
policies
and
the
security
associations
so
which
means
the
cryptographic
material
necessary
for
to
security.
L
So
I
have
to
double
check
the
security
policy
and
sighs.
Well,
it
is
not
what
I
intended
to
so
I
have
to
reject.
So
that's,
basically,
the
scope
of
the
security
architecture.
Tls
does
not
make
it
simpler.
It's
just
because
it's
a
different
model
TLS
is
being
used,
but
that's
the
reason
we
need
a
security
architecture.
D
E
E
So
this
is
the
frame
format
here
for
carrying
SP
over
a
genève
tunnel,
so
we
have
shown
here
as
the
outer
IP
and
the
outer
Ethernet
header.
Of
course,
the
UDP
port
for
Jenna
of
the
EDP
header,
followed
by
the
Geneva
header
that
X
for
the
collagen.
It
will
be
50
which
is
ESP.
Then
we
have
the
options.
Then
we
have
the
ESP
header
and
then
the
inner
payload,
of
course,
given
the
zener
payload
is,
could
be
there
too.
E
Then
we
need
to
have
and
I
another
header
to
carry
is
earlier
to
if
it's
saying
that
payload
is
gonna,
be
layer
to
which
most
most
likely
be
the
case.
Here
as
why
we
need
a
nice
at
IP
header
of
two
bytes
or
GRE
header
of
four
bytes,
then
the
inner
layer
to
packet,
of
course,
the
ESP
trailer
and
is
ICV
so
I
shown
here.
E
The
part
that
will
be
encrypted
is
going
to
be
the
inner
packet
starting
from
the
after
the
ESP
header
choose
a
trailer
to
the
end
of
the
trailer
and,
of
course,
the
authentication
how's.
The
integrity
will
include
as
well
as
a
ESP
had
the
ESP
had.
An
X
protocol
could
be
either
IP
as
I
mentioned
or
GRE,
and
those
are
IP
protocol
and
the
JRE
protocol
type.
Of
course
here
will
be
sad
ethernet
if
you
are
going
to
be
carrying
Ethernet.
So
this
is
how
can
we
carry
ESP
or
protocol
50
over
genève?
E
The
next
slide
here
is
for
say,
H
and
the
H
again
is
another
IP
protocol
of
type
51
and
in
here
same
same
idea
as
at
the
outer
IP
header,
we
have
the
outer
IP
header
for
the
Geneva
tunnel,
Zenzi
DP
port
again
or
the
UDP
header,
with
support
equal
to
name
as
then
de
genève
hazard.
Next,
what
the
code
is
going
to
be
51,
then
we
have
the
option.
Tlvs,
authentication,
header
of
the
h,
IP
SEC,
H,
then
again,
theory
and
the
in
F
period,
in
here,
what's
being
authenticated,
include
the
outer
stun
header.
E
Of
course,
except
for
what's
defined
under
IPSec
age
as
muta
for
mutable
fields,
those
are
the
fields
that
are
not
being
is
that
are
not
included
in
the
authentication.
So
in
here
the
idea
is
that
some
of
the
option
tlvs
could
be
included
in
the
authentication
while
other
could
not
be,
and
that
will
depend
on
the
control
plane,
as
stated
with
that
option,
TLV
as
we
are
defining
them.
So
so
one
can
envision
that
some
of
the
options
here
we
could
be
inserted
by
mid
point
and
those
will
not
be
authenticated
by
the
age
here.
E
E
Here
the
control
plane
consolidations
the
draft
we
are
talking
about.
You
know
we
are
definitely
you
are
envisioning
that
there
would
be
a
control
plane
between
the
MVS
was
a
centralized
or
distributed
that
are
going
to
be
negotiating
or
signaling
that
the
next
cortical
carried
by
Geneva
will
be
ESP
or
H.
E
So
now
the
endpoint
will
know
is
that
as
a
genie
tunnel
will
be
carrying
the
IPSec
ESP
or
H
as
well
as
control
plane,
as
mentioned
in
the
other
presentation,
can
be
used
to
signal
as
well.
What
kind
of
option
we
are
going
to
be
carrying
on
the
genève
tunnel
so
once
that,
when
these
agrees
that
they
have
to
carry
SV
or
H
as
next
protocols,
and
this
kid
could
be
a
trigger
for
negotiating
it's
a
security
Association
right
that
can
be
used
here
and
establishing
as
si
or
the
secure
Association
and
same
thing
mechanisms.
E
Defining
IPSec
can
can
simply
be
used
here
as
well
to
do
the
key
change.
So
so
this
is
leveraging
what
exists
in
IPSec
to
do.
The
secure
Association
and
as
well
to
to
set
up
I
mean
establish
security
issue
and
this
wall
to
negotiate
the
keys
and
whatever
can
be
carried
again
over
the
secure
Association.
Whether
this
is
going
to
be
policy
based
or
routed,
meaning
we
can
route
some
packet
over
that
secure
association
can
simply
be
used
right.
So
this
things
that
said
so
you
know
in
terms
of
next
steps.
E
E
Here
we
are
talking
about
carrying
SP
over
janay
right,
because
you
Neve
has
an
excellent
to
cool
on
which
you
can
specify
that
I'm
carrying
ESP
or
carrying
age
or
carrying
whatever
night,
while
the
excellent
only
have
BNI
does
not
have
an
expert
to
pull
on
it.
So
you
cannot
carry
a
ESP
over
ex9.
You
can
use
ESP
before
we
explained
before
the
UDP
and
encrypts
the
whole
packet.
So
so
that's
another
option.
I
saying
here.
E
G
L
M
M
M
The
main
objectives
in
RFC
742
were
first
to
replace
the
old
flood
and
learn
behavior
that
we
have
in
traditional
Ethernet
networks
with
PGP
right.
So
we
want
to
distribute
MAC
addresses
in
with
PGP,
and
that
is
actually
giving
you
a
lot
of
control
control
that
you
can
use
to
detect
things
like
Mac
duplication
or
things
like
Mac
protection
or
allows
you
to
have
a
very
quick
Mac
mobility
right,
so
it
it
makes
it
a
perfect
technology
for
the
data
center.
M
The
other
objective
was
to
have
an
efficient
way
to
to
deliver
multi
destination
traffic
or
bump
traffic,
and
the
other
key
feature
in
a
VPN
in
743
was
multihoming.
So
if
you
can
support
in
our
only
single
active
multihoming,
but
all
active
multihoming,
which
was
really
probably
the
first
standard
based
technology
supporting
this
so
since
743,
a
VPN
has
evolved
quite
a
bit
and
there
are
a
lot
of
drafts
and
documents
that
are
explained.
M
The
evolution
of
V
VPN
is
now
a
unified
control,
plane
technology
that
allows
you
to
have
pretty
much
all
the
services
you
need
so
L
AM,
aligned,
III,
but
also
layer,
3
services
and
cloud
DCI
services.
The
good
thing
about
the
VPN
is
is
pretty
flexible.
You
can
extend,
it
is
transported
mastic,
so
you
can
use
it
with
any
tunnel
and
it
has
a
lot
of
advanced
features
already
here.
M
So
if
you
had
to
explain
what
a
VPN
7
4
3
2
is
in
just
one
slide,
you
could
think
about
it
like
this
is
actually
a
VPN
that
you
define
in
a
bunch
of
peers
in
the
network.
The
instantiation
of
a
VPN
in
AP
is
called
Mac
Verve.
The
a
group
of
Mac
verse
for
the
same
VPN
is
an
e
VI,
so
any
VPN
instance
and
then
within
a
VPN
instance,
you
can
have
one
or
multiple
broadcast
domains
right
in
each
book
has
domain.
M
M
The
MAC
addresses
that
you
learn
on
those
attachment
circuits
can
be
learned
dynamically
ethically
through
the
management
plane.
So
there's
no
limitation
there,
but
then,
whatever
you,
you
learn
at
the
access.
You
can
actually
distribute
in
multi-protocol
BGP
using
Mac
IP
routes,
those
maka
I
P
routes,
they
encode
the
Mac
and
IP
information
of
the
attached,
hosts
and
and
those
are
advertised
along
with
a
label
in
a
BGP.
M
Next
stop
now
the
tunnel
that
you
have
among
all
the
piece
that
are
part
of
the
same
Evi
can
be
anything
can
be
MPLS
tunnels,
including
point-to-multipoint,
for
bomb
traffic.
We
also
support,
like
pvp
encapsulation
over
MPLS
tunnel.
That's
what
we
call
PvE
zbn,
but
we
also
for
mvo
three
tunnels
right
and
nowadays
the
the
most
popular
option
is,
of
course
VX
LAN.
M
Finally,
one
of
the
key
features
in
evpn
is
multihoming,
a
single
active
multihoming,
which
means
per
VLAN
load,
balancing
from
AC
to
a
group
of
PS,
and
if
you
have
single
active
multi
domain,
there
are
also
nice
features
like
maths.
We
throw
that
allows
you
to
have
a
uniform
failover,
irrespective
of
the
number
of
Mac
verbs,
that
you
have
enemies
during
a
segment,
but
especially
something
very
appealing
is
the
idea
all
active
multihoming,
so
that
is
the
ability
of
having
per
flow
load
balancing
from
a
given
C
to
a
group
of
piece.
M
There
are
part
of
the
same
Ethernet
segment
along
with
it
is
all
active
multihoming
where
you
allow
the
this
perf
load
load,
balancing
from
the
sea
to
the
to
the
network.
We
have
this
aliasing
function
that
is
providing
the
same
per
flow
load,
balancing
from
the
remote
p2,
all
the
peas
in
there
Ethernet
segment.
So
this
is
pretty
much
seven
four
three
two,
but
as
I
said
before,
since
seven
four
three
two
heaping
has
evolved
a
lot.
So
we
have
a
lot
of
documents,
and
here
you
have
the
some
of
the
most
relevant
ments.
M
We
have
40
VPN
above
T
dashed
line.
You
have
a
bunch
of
documents,
some
of
them
RFC's,
some
others
are
already
drops
in
the
last
call,
and
then
they
pretty
much
define
all
the
the
services
that
that
you
need,
and
some
of
them
are
specific
to
the
use
case
of
the
data
center
and
the
TCI
right
specifically,
you
have
here
the
Ethiopian
overlay
draft
that
talks
about
how
to
use
the
VPN
for
overlay
tunnels
like
the
exam
and
the
GRE.
M
You
have
the
PCI,
a
VPN
overlay
travel
that
talks
about
how
to
connect
overlay
data
centers
to
a
wham,
and
you
even
have
the
inter
74
in
the
prefix
advertisement
raft
talking
about
how
to
provide
inter
subnet
for
winning
using
a
VPN,
but
not
only
that
so
below
the
dashed
line.
You
have
many
more
documents,
extending
the
other
feature
set
of
evpn,
and
if
you
look
at
the
website,
the
best
tracker
you'll
find
more
than
20
individual
EVP
and
related
troughs.
So
it's
a
very
active
and
and
dynamic
technology.
We
keep
expanding
it.
M
So
why
is
it
being
used
in
data
centers?
So
you
can
have
the
base
specification
in
the
EVP
novel
a
draft,
but
the
idea
is
that
modern
data
centers
are
based
on
a
class-based
architecture
and
IP
fabrics
right.
So
it's
all
IP,
all
the
links
are
routed,
and,
and
on
top
of
that,
you
need
multi-tenancy
with
intra
and
Inter
subnet
forwarding,
right
and
obviously
in
order
to
to
Calais
or
to
only
or
three
on
top
of
this
IP
fabric.
M
You
need
IP
overlay
tunnels
and
nowadays
the
exam
as
I
said
before
is
the
the
most
popular
option.
Why
do
we
need
a
control
plane
for
fixed
LAN
or
any
other
IP
over
the
tunnel?
Well,
first
of
all,
you
need
to
out
discover
the
remote
V
tips,
so
when
I,
given
V
em
in
a
subnet
needs
to
talk
to
them
to
someone
else
in
a
different
leaf
or
your
datacenter
Gateway
I
need
to
know
how
to
to
reach
that
leave
40s
in
a
gateway
trying.
M
The
other
thing
you
need
is
to
somehow
distribute
the
Mac
in
IP.
Information
of
the
different
hosts
in
your
subnets
and
you'll
also
need
some
more
advanced
options.
So
if
you
PN,
is
a
perfect
fit
for
the
data
center
for
M
and
n
vo
data
center,
so
it
provides
all
the
basic
control
plane
needs
that
you
have
and
as
an
example
here,
you
have
two
leaves
right
with
a
VM
attached
to
each
of
them
and
then
you
get
their
data
center.
M
So
you
have
the
same
subnet
for
a
tenant,
configuring,
the
three
of
them,
the
inclusive,
multicast
ether
tank
route,
which
is
one
of
the
EVP
and
route
types,
is
providing
you
with
this
out
of
discovery
function.
So
the
two
leaves
can
send
this
and
go
seek
multicast
route
and
the
data
center
gate.
We
can
actually
learn
that
those
two
V
types
are
associated
to
V
and
i1,
and
they
are
part
of
the
same
flooding
list,
but
not
only
that,
but
when
they're
two
leaves
they,
they
learn
the
Mac
and
IP
addresses
of
the
VMS.
M
They
can
actually
other
ties,
Mac
IP
routes
with
that
information,
along
with
the
Vita
The
Associated,
Vita
and
V
and
I.
So
the
the
remote
node
is
going
to
add
our
information
to
the
forwarding
database
and
also
to
the
IDR
table,
etc.
You
can
also
do
advanced
things
with
a
VPN
like,
inter
submit
forwarding,
so
it's
the
same
tenant
has
a
different
subnet,
a
red
subnet,
which
is
not
defined
in
all
the
MVS.
M
You
can
use
evpn
with
special
valve
type
to
propagate
or
to
advertise
prefixes
right
in
to
install
those
prefixes
in
an
IP
routing
table,
and
you
have
other
things
that
you
can
do
with
the
VPN.
You
have
some
examples
here
in
the
slide
now,
if
you've
been
in
the
industry
today,
so
it's
not
only
a
lab
exercise
for
a
scientific
paper.
It's
actually
deployed
widely
everywhere.
M
So
in
you
have
multiple
implementations,
hardware
based
software
based
and
the
proof
that
we
are
doing
a
great
job
in
the
IETF.
Is
that
actually
it's?
If
you
can
interoperate
across
different
vendors
right
and
here
you
have
an
example,
so
we
do
every
year,
this
interoperability
event
run
by
the
EI
NTC
and
for
two
or
three
years
now
we
are
testing
the
VPN
across
different
vendors
and
we
are
testing
very
interesting
scenarios
and
and
very
I
would
say
in
a
successful
successful
way.
So
that's
great
news.
M
So
if
it
being
works
and
it
works
across
different
vendors
now-
and
this
is
an
open
discussion-
so
what
else
do
we
need
to
do
with
a
VPN
for
MgO
3
for
this
working
group?
So
obviously
we
need
to
support
new
encapsulations
like
genève
and
there's
a
first
attempt
I
think
Sam
is
presenting
tomorrow
this
distract
about
how
to
how
to
use
the
VPN
with
geneed
and
I
can
think
of
using
we
need.
N
M
B
M
D
Okay,
so
I
think
there
were
a
couple
of
couple
of
reasons.
I
think
thank
you.
How
here
for
that
presentation?
Why
why
we
asked
to
have
an
overview
of
what
was
going
on
in
invest
with
free
VPN
in
mvo?
3
was
partly
to
get
some
idea.
So
it's
you
know
it's
an
applicable
control
plane
from
vo3,
although
working
on
evpn
isn't
isn't
necessarily
on
our
scope.
D
So
there's
definitely
a
kind
of
discussion
about
whether
or
not
we
some
need
some
kind
of
applicability,
RFC
or
something
in
MVO
32.2
point
of
this
work
and
to
show
how
you
know
how
it
fits
with
with
the
MV
i3
architecture.
The
second
issue,
I
guess,
is
yes,
other
new
require
other
requirements
that
we
are
generating
in
mvo,
3,
that
we
can
input
into
the
working
bass
for
the
evolution
of
V
VPN
to
support
our
requirements
which,
which
is
so
yeah.
I
O
Okay,
this
is
Olli
I'm,
going
to
give
a
quick
update
on
this
trip.
We
ate
all
2000
Q
C,
which
is
the
VDP
extension
for
Mao
3,
as
per
the
requirement
document
from
there
Mao
3
working
group
next
site.
This
is
a
background,
so
we
have
started
this
projects
as
per
this.
Control
are
split,
em,
a
control,
plane
requirement
document
and
the
draft
0.4
is
available
at
this
link
and
the
password
is
available
next
page,
so
I'm
next
slide,
please
so
I'm
gon
going
to
give
some
summary
on
the
progress
of
this
project.
O
O
Basically,
we
found
nothing
controversial,
so
the
current
revision
we
think,
basically
meets
the
needs
for
the
split
control
playing
our
requirements
and
will
we're
going
to
update
it
to
the
draft
is
0.6
as
per
the
comments
resolution.
So
the
comment
disposition
is
available
at
the
following
link
and
it
requires
the
password.
So
is
the
same
as
those
of
the
drafts.
You
may
also
contact
a
chairs
for
the
password
in
the
reviewers.
O
So
please
trying
to
find
this
comment
disposition
and
you
may
talk
to
me
on
what
your
opinions,
ok,
one
more
thing
is
because
the
QC
in
which
is
the
standard
number
has
ambiguity,
because
I
Triple
E
has
another
project
called
QC
n,
with
the
name
quantized
just
a
notification,
so
we
are
going
to
change
the
standard
number
QC
and
to
some
other
numbers,
but
with
the
same
title
is
still
called
up.
The
BTB
extension
for
mm3.
So
don't
be
too
surprised
if
you
change
the
number
later
next
page.
O
So
basically,
what
we
are
going
to
do
is
for
the
under-eye
tributo
one.
We
are
going
to
prepare
the
new
document
drop
0.6
and
going
to
start
our
working
group
ballot
on
it
and
I
ET
f
em.
It
was
three
side
we
are
going
to
request
a
working
class
call
on
the
requirement
documents
after
this
QC
n
drops,
your
pi/6
is
ready.
So
this
is
to
update
and
in
questions.
D
P
Firstly,
our
problem
is,
we
are:
we
are
introduced.
We
are
introduced
a
new
architecture
of
PNG
in
our
network
compared
to
traditional
PNG.
We
separate
PNG
Concha
plan
and
drew
the
plan
and
in
into
two
parts,
deploy
control
plan
in
a
centralized
site
and
distribute
user
plan
as
needed.
So
between
control
and
the
Euler
plan.
There
were
several
interface
for
for
CP
and
AUP
to
exchange
necessary
information,
one
of
the
interfaces
service
interface.
P
This
interface
is
for
the
pppoe
or
IPO
syndication
package
exchange
between
CP
and
u
P
and
we
choose
to
be
actually
as
their
encapsulation
protocol
to
form
folder
for
the
package
and
because
in
our
network,
most
all
for
device,
casa,
proto,
bx
lam,
but
furthermore,
when
needed,
we
needed
the
user
access
port
information
and
be
carried
in
the
extra
header.
So
this
part
is
not
is
not
standardized
in
any
in
any
existing
document.
The
protein
information
included
device,
ID
slot
ID
sub
card
ID
and
pot
ID
so
way
so
way.
Our
way
extender.
P
We
request
a
new
and
that's
the
hope
in
we
excellent
GP
header
for
v
b,
ng
service,
header
and
and
we
define
a
VI
ng
service
header
to
carry
the
port
information
and
there
there
are
flag
next
to
protocol
and
the
node
ID
slot,
ID
sub
sub
card,
ID,
port,
ID
and
port
type,
and
and
also
there's
another
optional
format.
For
the
port
information,
which
is
interface
index,
it
is
specified
again
2008
and
63
and
it's
a
standard
way
to
indicate
support.
P
But
this
way
is
not
a
explicit
way
to
describe
a
part
and
we
have
to.
We
have
to
build,
maintain
a
mapping
table
between
interfacing
tax
and
the
pot
information.
So
it's
relatively
a
more
complex
way,
but
in
this
two
way
had
their
advantage
and
a
disadvantage,
and
we
hope
we
can
receive
some
comments
on
the
choice
of
this
two
ways.
Q
Q
P
You,
and
here
is
example
pppoe
process
I,
hope
it's
helpful
for
the
understanding
of
the
co
separated
with
Eng
how
how
the
the
new
extension
works
and
I
was
skip.
The
details
and
anyone
is
interesting-
can
read
the
detail
in
my
matrix
and
for
the
next
step
and
welcome
your
comments
and
suggestions
and
and
the
requestor
for
working
group
adoption.
Thank
you
any
question.