►
From YouTube: IETF111-APN-20210730-1900
Description
APN meeting session at IETF111
2021/07/30 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
And
my
clock
has
just
ticked
over
the
hour,
so
I
guess
it's
a
tight
agenda
and
we
should
start
so
welcome
to
the
application
aware
networking
apn
both
you
have
three
chairs
today:
bob
daniel
and
myself,
adrian
and
martin.
Our
ad
is
also
here.
A
The
chairs
have
decided
to
sort
of
split
the
roles
with
with
bob
looking
after
slides
dan,
looking
after
cue,
the
clue
of
people
and
and
the
chats
and
me
being
the
person
who
gets
to
speak
to
the
chairs,
slides
reminder
that
this
is
a
a
working
group
forming
both,
which
means
nothing
more
than
at
the
end,
or
the
purpose
of
the
meeting
is
to
gather
information
for
the
ad
to
decide
whether
there's
work
here
for
the
ietf
and
whether
or
not
to
form
a
working
group
and
the
chair's
job
is
to
let
the
proponents
explain
their
ideas
and
allow
the
community
to
ask
questions
and
dig
and
express
their
opinions
so
slide.
A
A
Just
because
it's
a
buff
doesn't
mean
the
note
well
doesn't
apply.
In
fact,
it
probably
applies
pretty
strongly
because
here
are
some
new
ideas
coming
along.
So
if
you're
not
aware
of
of
this,
please
go
away
and
read
the
references
understand
that
if
you
contribute
in
the
chat
or
at
the
microphone,
that
is
an
atf
contribution.
A
A
Our
intention
is
that
when
the
proponents
are
presenting,
which
is
items
four
through
eight,
there
is
space
to
ask
questions,
but
the
questions
are
for
clarification.
That
is
to
say,
I
heard
you
say
this
in
the
presentation.
What
did
it
mean
or
did
you
were
you
trying
to
say
this,
and
then
we
hold
the
real
debate
up
until
the
open
session
at
the
end,
when
there'll
be
opportunity
for
the
proponents
to
come
back
and
answer
questions
as
well,
but
we
hope
there'll
be
a
good
exchange
of
opinions.
B
Thank
you.
Do
you
hear
me
correctly,
yep,
okay,
great,
so
thank
you
all
for
being
here
as
shepherding
ad.
What
I'll
be
looking
for
or
looking
at
during
this
session
is
twofold.
B
You
already
started
depending
on
that
adrian,
but
first
is
there
standardization
work
to
do
in
that
space,
and
here
I
mean
what
are
the
concrete
use
cases
and
problems
that
we
would
need
to
address
in
our
etf
and
do
these
problems
or
use
cases
need
interoperable
solutions,
because
that's
why
we're
doing
standards
and
can
or
can
they
be
addressed
with
existing
mechanisms?
B
So
I
believe
a
good
part
of
the
session
is
dedicated
to
that.
So
I'm
hopeful
we
will
be
able
to
conclude,
so
I
was
saying
twofold.
Sorry,
so
is
there
a
standardization
work
to
do
and
if
so,
that's
the
important
part
for
me,
what
is
the
best
way
to
achieve
that
is
a
working
group,
the
most
effective
way
or
not
so,
and
in
that
context
I'll
be
looking
at
two
things
and
specifically
whether
there
is
critical
mass
for
the
work.
B
When
I
mean
when
I
say
critical
mass,
I
mean
both
in
terms
of
number
of
people
willing
and
to
do
the
work
over,
let's
say
two
or
three
years,
but
also-
and
that
is
very
important.
Is
there
sufficient
diversity
of
interest
in
that
topic,
because
diversity
of
interest
is
what
makes
our
standards
robust?
B
Proponents
have
gone
have
come
a
long
way
since
they
first
introduced
that
topic
in
ietf,
and
they
have
done
quite
a
lot
of
work.
I
have
to
thank
them
for
that
quite
a
lot
of
work
in
getting
and
addressing
inputs
they
have
received
from
the
community
specifically,
for
example,
when
they
presented
that
in
several
sessions
during
last
ietf,
but
also
from
iesg
and
iab.
B
B
I
think
this
is
important
for
us
to
have
a
fruitful
discussion
and
define
the
proper
way
forward
before
I
close
and
hand
you
back
the
microphone.
I
want
to
thank
you.
B
B
Adrian
and
dan,
the
three
of
you
for
all
the
work
you
did
because
you
pulled
an
enormous
amount
of
work
to
prepare
that
that
buff
session.
So
thank
you
very
much
back
to
you.
A
Lovely
thank
you.
Martin.
Okay,
I've
got
just
a
couple
of
slides
to
set
us
up
and,
and
one
of
them
builds
well
actually
both
in
build
on
what
martin
just
said.
The
first
is
the
name
apn
application
aware
networking
has
a
long
history
behind
that
name
and
apn
6
was
mentioned
in
an
id
back
in
2019
and
and
then
presented
in
six
man
and
since
then,
the
function
and
the
meaning
have
evolved
considerably.
A
There's
there's
quite
a
lot
of
difference
between
what
the
proponents
are
going
to
talk
about
today
and
what
was
written
in
the
original
drafts.
So
please
don't
get
hung
up
on
the
name.
A
name
can
be
changed
to
anything
and
the
function
that
you're
going
to
hear
about
has
outgrown
that
original
name.
So
please,
listen
to
the
presentations.
A
Give
the
proponents
a
chance
to
say
what
it
is
they
want
to
do
now.
Not
what
was
in
the
early
drafts,
draw
your
understanding
from
the
technical
details
and
not
from
the
name
next
slide.
A
The
presenters
and
you
as
a
community
don't
have
to
answer
these
questions,
but
thinking
about
them
may
help
and
help
guide
the
discussion
at
the
end
of
the
meeting.
So
we'll
put
this
slide
up
again
at
the
end
of
the
meeting
when
the
open
discussion
is
there
not
because
you
have
to
talk
to
these
points,
but
because
they
may
help
clarify
in
everybody's
mind
what's
going
on
and
what
input
they
want
to
give
to
the
discussion.
A
Yeah
that
slide
is
for
the
end,
so
we
will
move
to
our
first
presenter,
who
is
robin
so,
if
you'd
like
to
unmute
yourself,
robin
you'll,
be
good
to
go.
C
Slice,
okay,
so
the
first
is
what's
the
apn,
so
apn
is
the
observation
of
application.
We
are
not
working.
Apn
is
a
framework
we
are
apn
attribute
is
introduced
at
network
edit
devices,
and
the
api
attribute
is
the
structure
fields
and
the
api
attribute
is
carried
along
with
the
tunnel
encapsulation,
and
the
api
attribute
will
be
used
for
policy
enforcement
on
the
nodes
within
an
apn
domain
and
in
short,
so
that's
a
if
you
classify
a
packet
at
ingress
to
the
apn
domain.
C
The
classification
can
be
based
on
the
five
tuple
information.
We
like
information
et
cetera
api,
encapsulates
the
packet
into
a
tunnel
header
within
an
apn
domain
and
transverse,
the
apn
domain
server
apn
will
lose
process
and
forwards.
The
packet
within
the
network
using
policy
dependent
on
the
api
attribute
and
the
last
apn
will
decapulate
the
packet
on
in
egress.
C
That
is,
the
epm
will
remove
the
ipap
attribute,
along
with
the
outer
tunnel
encapsulation
and
in
the
process
of
promoting
the
apm
work.
There's
the
concern
on
the
privacy.
C
C
Slice
so
here
this
is
a
reference
diagram
of
the
api
framework,
so
here
we
can
see
the
packet
will
be
sent
from
the
source
to
the
destination
when
the
packet
is
sent
from
the
source
to
the
apn
network
domain.
So
this
here
this
is
a
normal
packet.
C
When
the
packet
arrived
at
the
edge
of
the
18
edge
of
the
apn
domain,
the
apn
edge
will
determine
the
api
attribute.
According
to
the
mapping
from
the
existing
packet
header
information
to
derive
the
actual
apn
attribute,
then
the
api
edge
will
encapsulate
the
api
attribute
to
the
packet
along
with
the
tunnel
encapsulation.
C
So
then,
the
tunnel,
the
apm
packet,
will
transverse
will
transverse
to
the
will
transverse
the
ap
domain.
The
api
attribute
in
the
outer
tunnel
header
can
be
used
for
policy
enforcement.
C
The
policy
enforcement
can
be
divided
into
ap,
head
ap,
midpoint,
ap
underpoint,
so
this
is
depend
on
the
duration.
User
depends
on
the
different
law
of
the
policy
enforcement.
C
C
So
from
this
reference,
their
gram
we
can
see
the
api
attribute
will
be
only
used
in
the
api
domain.
So
here
just
a
clarification.
Api
domain
is
a
logical
concept
that
means
in
the
physical
environment.
It
can
be
multiple
network
domain
controlled
by
the
same
operator,
a
second
one,
the
ap
edge
and
the
apin
head.
That
is
a
logical
node
that
means
in
the
physical,
the
api
edge
and
the
api
head.
Node
can
be
the
two
node
in
the
apn
domain
and
also
there's
maybe
the
case.
C
C
C
Api
attribute
the
edge
node
may
look
at
all
of
the
euro
fields
of
the
package,
header,
the
possible
the
available
information,
including
the
five
tuple
information,
including
the
designation,
address,
source,
address,
etc,
and
maybe
the
layer,
2
information
reliant
information
and
also
maybe
the
access
port
of
the
packet
and
also
this
is
a
a
one
of
cost
as
an
edge
and
does
not
need
to
be
repeated
as
a
transit
node.
C
That
means
the
mapping
can
be
done
as
the
edge
node,
so
the
ibm
attribute
can
be
used
in
the
transition
nodes
of
the
api
domain,
and
here
they
are
in
the
process
of
promoting
the
apn.
Some
experts
propose
that
the
package
may
be
encrypted
so
that
some
fields
of
the
package-
header,
maybe
not
accessible,
so
there's
the
two
possible
way.
So
that's
a
the
first
way
the
api
function
may
be
reduced.
C
That
is
only
use
the
two
type
of
information
for
the
mapping
to
the
api
attribute
and
the
second
way
there
may
be
there's
other
information
such
as
the
access
post,
other
way
line
information
can
be
used
for
apn.
This
depends
on
the
configuration
for
the
possible
mapping.
Okay,
next
slides.
C
Okay
and
then
the
network
knows
how
to
know
what
to
do
so.
The
network
knows
will
do
the
policy
informants.
According
to
the
apn
attribute,
the
operator
of
the
apn
domain
configure
the
mapping
from
the
api
attribute
to
policies
at
the
youtube
policy
enforcement
enforcement
notes.
The
methods
can
include
following
way.
C
C
Slides
the
goal
of
the
apm
apn
attribute
allows
the
network
device
to
only
look
at
one
easily
accessible
fields
in
the
tunnel
header.
So
that
means
comparing
the
traditional
file
type
information
for
the
classification.
C
So
now,
let's
only
use
one
tuple
information
from
the
api
attribute
for
the
possible
policy
enforcement-
a
second
one,
because
the
five
type
of
information
may
be
not
available
because
the
original
packet
may
be
encapsulated
in
the
tunnel.
So
that's
the
five
type
of
information
is
not
available,
so
the
api
attribute
in
the
tunnel
header
can
be
go
on
to
be
used
for
the
classification
and
the
policy
enforcement.
C
A
second,
the
apn
attribute,
allows
to
simplify
the
policy
control
at
every
policy
enforcement
point
within
the
network,
so
that
first,
the
ap
attribute
allows
to
reduce
each
matching
entry
or
policy
filter,
since
it
is
only
one
field.
So
that's
a
because
you
know
in
the
traditional
way
you
use
five
type
of
information.
C
It
has
to
introduce
the
complex
flooring,
algorithm
and
expensive
hardware
resource,
but
the
policy
enforcement
based
on
the
one
type
of
information
can
reduce
the
complexity
and
save
the
hardware
resource
a
second
one,
because
the
api
attribute
is
relatively
stable.
So
that's
it
introduce
the
possibility
of
any
meters
data
or
policy
filter
entries.
C
So
that's
a
similarly
so
that
in
most
cases
the
api
attribute
is
centralized
configured
and
distributed
to
all
the
policy
enforcement
points.
A
third
one.
The
structure
api
attribute,
allows
to
express
fine,
granular
service
requirement.
So
here
there's
the
example
of
this.
The
requirement
defined
for
the
different
user
group
and
the
application
group,
for
example,
for
specific
user
super
civic
user
or
applications
in
the
for
enterprise.
C
We
can
have
the
market
user
group
and
we
can
also
have
the
r
d
user
group
for
the
final
reality
service
and
last
one.
The
structure
api
attribute
allows
to
match
the
evolving
the
fine
granular
different
network
capability.
That
means
now
the
scalability
of
the
network
service
can
be
has
been
improved
greatly.
C
D
I
think
we
should
go
with
kerati,
but
there's
a
couple
questions
also
in
the
chat,
so
maybe
character.
If
you
want
to
start
with
your
question.
First.
E
Sure
in
slide
five,
you
talk
about
policies
and
you
talk
about
how
the
policies
can
be
enforced,
but
not
what
the
policies
should
be
doing
so.
Can
you
give
some
examples
of
policy
enforcement?
What
kind
of
policies
they
would
use?
C
Okay,
so
I
I
mean
the
next:
the
apn
user
case
will
have
the
more
details
about
this
policy
enforcement
here.
This
is
just
a
simple
example.
That
means
we
can
match
office
user
and
to
action
users,
theory
to
a
sr
policy
or
network
slicing.
So
that's
the
policy
enforcement
okay.
F
Thank
you
for
the
presentation
from
what
you
describe
how
you
characterize
apn
attribute.
It
seems
very
similar
in
philosophy
and
function
to
ipv6
flow
label
so
because
it
appears
that
what
you
identifying
with
apn
is
a
flow,
and
then
you
enforce
some
policies
to
treat
this
flow
through
the
tunnel
so
which
is
the
purpose
of
a
flow
label.
F
Can
you
point
to
what
you
see
as
a
difference
that
motivates
to
introduce
a
new
structure
in
in
tunnel
encapsulation
and
not
to
reuse
available
flow
label?
Thank
you.
C
Okay,
thanks
thanks
greg,
so
in
fact,
in
the
following
presentation
of
the
gap
analysis,
there
will
describe
this.
The
gap.
Analysis
of
the
ipv6
flow
label
here
just
use
a
small
communication.
Ipv6
flow
label
now
is
always
used
for
the
ecs
ecmp
purpose.
C
C
G
Yes,
go
ahead,
thank
you
for
your
presentation,
robin
I
having
five
pupils
to
look
up.
The
apn
attribute
sounds
like
it
may
create
a
lot
of
permutations
of
attribute
values
at
the
edge
if
these
are
to
be
downloaded
from
the
controller
or
configured
centrally
and
downloaded
to
all
of
the
edge
policy
enforcement
nodes.
G
It
sounds
like
we're
going
to
create
a
lot
of
lookups
there
for,
for
a
large
number
of
apn
attribute
values
is.
Is
that
something
that
you're
concerned
about
in
terms
of.
C
Yeah
tom-
I'm
not
sure
I
guess
your
point
all,
but
in
fact
this
is
the
controller,
definitely
to
download
the
possible
configuration
to
implement
the
mapping
to
the
from
the
existing
package.
The
header
information
for
the
api
built.
Yes,.
H
G
C
C
Yes,
that
thanks,
I
got
your
this
phone.
This
is
a
good
question.
Yes,
but
I
think
that's
that's
the
possibility,
but
I
think
that's
in
the
actual
deployment.
I
think
this
is
the
for
specific,
specific
user
of
the
network
as
network
network
a
service.
C
So
I
think
that's
a
the
possible
the
classification
of
the
ap
attribute
should
be
limited,
but
I
think
that's
here
I
explained
that's
a
there's:
a
possibility
to
use
one
sample
of
api
attribute
in
the
higher
scalability
than
the
traditional
way,
which
use
five
topo
information.
Yeah.
D
I
I
So
I'm
not
sure
if
there
is
some
delay-
I'm
not
okay
here.
Thank
you
so
well.
The
idea
here
is
to
present
some
illustrative
use
case
in
order
to
yeah
yeah.
Usually,
let's
see
the
applicability
of
a
apn
of
the
apn
approach,
so
the
apn
attribute
will
be
in
the
tunnel
header,
so
we
will
consider
the
application
of
this
tunnel
in
what
is
called
an
ipn
apn
domain.
I
I
will
take
some
time
to
say,
prepare
the
the
scenario
that
we
will
comment
later
on,
so
we
will
consider
an
apn
domain
which
is
under
the
umbrella
of
an
operator
and
reset
the
domain,
but
that
could
be
realized
from
different
network
areas
such
a
way
that
we
could
have
a
different
subdomains.
Let's
say
within
this
apn
domain,
the
api
attribute
the
end.
I
What
is
intended
to
allow
is
a
finer
grain
c
enforcement
in
such
a
way
that,
based
on
the
attributes
of
of
this
field,
this
tag
in
the
in
the
tunnel
where
we
could
apply
these
policies,
and
here
we
will
illustrate
with
two
of
them,
with
performance
measurements
and
also
with
the
traffic
steering.
I
We
have
considered
for
you
street
station
purposes,
this
lease
line
service,
essentially
with
the
idea
of
connecting,
for
instance,
cloud
sites
from
cloud
provider
and
using
the
in
these
examples
and
then
wrapped
in
version
6,
but
we
could
use
another
encapsulation,
so
it's
not
dependent
on
the
encapsulation
at
all.
So
what
we
consider
is
that
we
will
essentially
create
a
tunnel
between
the
piece
connecting
the
two
different
sides
and
also
we
consider
that
we
will
not
have
a
will.
We
will
have
a
loose
the
t
traffic
engineering
setup
between
three
these
three
different
areas.
I
I
So,
regarding
the
two
examples
that
we
will
provide
according
to
policies,
we
will
talk
first
about
the
performance
measurement
in
the
ip
backbone,
so
without
having
apn.
The
circumstances
of
for
applicability
of
this
policy
could
imply
in
each
of
the
transitions
between
the
metro
area
and
the
ip
backbone
and
then
from
the
ip
bacon
and
the
other
metro
area
to
check
the
phi
tuples
that
are
in
the
inner
label
of
of
the
of
the
tunnel.
I
So
somehow
we
would
need
to
process
the
the
the
tunneling
and
then
the
other,
a
header,
the
additional
header,
in
order
to
identify
what
could
be
the
performance,
the
triggering
of
the
performance
measurement
to
apply,
for
they
require
a
flow
in
this
one.
In
this
case
in
situ.
I
am
an
approach,
so
this
is
expensive
in
terms
of
processing
and
the
idea
of
replica
of
applying
apn
in
this
respect
would
be
to
yeah
to
essentially
to
alleviate
such
processing.
I
So
if
we
go
to
next
page,
probably
we
we
could
make
more
evident
this.
This
fact,
so
the
point
here
would
be
in
the
entry
pe,
the
one
that
is
on
the
left.
Essentially,
we
would
have
the
the
need
of
processing
these
five
doubles
coming
from
the
original
packet
sent
by
the
ce
and
according
to
that
apply
or
identify,
apply
the
the
proper
ap
and
apn
tag
to
the
respective
packets.
I
I
So
in
this
case,
without
apn
necessarily,
we
would
need
to
do
the
same
process
as
as
before
so
checking
the
the
five
tuples
that
are
in
the
inner
label
of
the
of
the
tunnel
messages
and
based
on
that
to
apply
the
the
specific
steeding,
because
we
have
here,
we
consider
as
assumption
to
have
a
loose
traffic
engineering,
the
the
granularity
that
we
could
apply
to
the
path
in
the
ip
backbone
part.
It
could
be.
I
So,
when
relying
on
on
apn,
what
we
could
have
is
a
simplistic
way
of
of
applying
the
policies
so
in
such
a
way
that
when
we
transition
from
the
cta
metro
area
to
the
ap
backbone,
we
can
look
just
simply
to
detect
the
apn
tag
in
the
in
the
tunnel
and
then
apply
a
a
more
optimal
policy.
That,
in
this
case,
for
instance,
is
represented
by
the
fact
that
the
traffic
will
go
through
the
segment
routing
path
number
two,
instead
of
going
through
the
segment
routine
path,
number
one.
I
Apart
from
that
and
based
on
the
same
information
of
the
tag,
we
could
also
even
trigger
a
second
policy
that
would
be
in
the
applicability
of
measurement
for
this
second
flow,
as
we
saw
examples
before
so
essentially.
Here
what
we
intend
to
highlight
is
the
flexibility
of
the
mechanism
for
triggering
more
than
one
action,
and
also
the
simplicity
in
the
in
the
processing
but
yeah
by
focusing
on
just
this
simple
attribute.
I
So
next
page
please
so
apart
from
the
use
cases
mentioned
before
for
illustration
purposes,
there
are
a
number
of
other
scenarios
that
have
been
already
documented
and
plus
another
that
are
more
or
less
in
the
discussion,
and
this
is
just
to
show
some
references
somehow
on
all
of
them,
and
I
think
that
with
that
I'm
finished
next
page,
please
just
to
to
be
sure,
okay.
Well
just
the
summary.
I
We
have
used
this
class
cloud
list
line
service
as
an
example.
There
are
others
documented,
as
we
saw
before,
and
we
have
considered
these
two
policies,
the
triggering
of
performance
measurement
and
the
traffic
steering,
and
that's
all
from
from
my
side.
Thank
you
so
much.
F
Go
back
to
performance
measurement
use
case
slide.
F
F
Yes,
so
it's
a
single
encapsulation
single
tunnel
encapsulation
then
goes
for
all
these
three
domains,
regardless
of
administrative.
I
F
But
all
right,
it's
probably
very
unique
case
when
you
can
cross
two
cities
and
ip
backbone
and
not
to
leave
an
operator.
F
I
F
So
we
probably
have
different
experiences,
but
I
think
that
it
needs
to
be
very
clearly
stated
that
your
assumption,
for
this
use
case
is
that
all
three
domains
are
managed
by
the
same
operator.
It's
a
not
multi-operator
environment
by
the
single
operator,
multi
domain
environment,
because
that
changes
changes
their
scenario
and
changes
the
perspective
and
changes
the
mechanics,
okay
and,
as
a
result,
I
believe
it
changes
applicability
of
api,
because
if
we
look
from
iom,
then
by
iom
applicability
that
iom
has
to
be
removed
at
the
edge
of
the
domain.
F
So
if
you
have
multiple
operators,
I
would
imagine
that
it
will
be
applicable
in
this
case.
But
if
you
have
multiple
operators,
I
would
expect
that
your
tunnel
encapsulation
will
be
removed
at
the
edge
of
your
operator's
domain.
F
I
Yeah,
you
are
totally
right,
so
it
was
my
fault
not
not
cleaning
properly
well
in
the
first
slide.
There
was
this.
This
idea
of
having
just
a
single
administrative
domain
is
the
different
domains
and
totally
agree
with
you
that
if
we
cross
we
go,
we
cross
the
boundaries
of
operators.
This
should
have
to
has
to
be
removed.
D
K
Hi,
my
name
is
gion
mishra,
I'm
with
verizon,
and
I
will
be
going
over
the
deck
related
to
apn
and
why
existing
mechanisms
are
not
enough.
Next
slide.
Please.
K
So
why
our
existing
mechanism
is
not
enough
so
today
what
I
so
on
this
this
slide
in
the
next
slide
I'll
be
going
over
existing
mechanisms,
so
the
first
mechanism
dscp,
so
I
for
ipv4
and
ipv6
marketing,
so
dscp
has
been
around
for
for
a
long
time
for
marketing.
It's
been
used
in
the
industry
for
for
decades,
for
classification
and
providing
like
sla
to
customers.
K
So
really
the
the
big
piece
here
with
dscp
is
the
field.
Is
I
for
what
the
type
of
granularity
that
we
would
like
to
achieve
with
with
apn
is,
is
a
fairly
high
grade,
granularity
and
and
what
we
call?
I
guess,
a
fine
grain
sla
versus
a
quarter
screen
sla
and
with
dscp,
even
with
the
with
the
64
bits.
It's
not.
It
does
not
provide
the
granularity
that
that
we
require
with
apn
the
next
one
ipv6
flow
label,
so
ipv6
flow
label,
so
with
rfc
6437.
K
The
primary
goal
of
v6
flow
label
in
in
use
cases
by
operators
as
well
is
for
stateless
ecmp
load.
Balancing
there
is
a
there
is
a
stateful
component
as
well,
but
in
jet
in
general,
most
operators.
The
use
case
for
ipv6
flow
flow
label
is
localized
and
it's
a
you
know:
five
tuple
20
20
byte
hash
that
that's
used
for
as
an
income
input
key
to
a
hash
function
that
provides
that
localized
load
balancing
function,
mpls
entropy
as
well
our
c6790
as
well.
It's
got
its.
K
It
has
its
use
case
and
that's
for
providing
the
same
hashing
function
for
load,
balancing
and
reduce
and
eliminating
on
control,
plane
and
data
plate.
State
pseudo
wire
as
well
fat
fat
pseudo
wire
has
been
around
for
for
many
years
as
well,
and
that
that
as
well,
is
used
for
being
able
to
look
into
the
payload
and
look
at
the
source
destination
to
build
that
hash
for
as
well
load
balance
and
function.
K
The
next
one
is
sfc's.
The
service
function
chaining,
so
the
subscriber
this
subscriber
identifier
is
there
for
nsh
in
that
con
in
the
context
header,
so
that
is
as
well
is
used
for
service
function,
changing
overlays
and
carrying
information
between
service
function.
Nodes
for
for
surface
function
forwarding.
So
it
has
a
specific
use
case.
K
K
It's
used
in
srt
for
segment
routing
to
bind
the
candidate
path
to
buy,
bind
the
candidate
patch
of
the
forwarding
plane
for
for
srt
for
for
strict
or
loose
paths,
and
the
binding
sit
can
only
be
used
with
sr
so
for
the
sr
data
plane
and
that's
ssr
and
pls
or
srv6
number
six
flows
flow
spec
label,
so
the
flow
spec
has
been
also
been
around
for
a
long
time
and
it's
and
it
has
its
purpose,
used
for
ddos
mitigation.
K
I
mean
it's
and
it's
been
deployed
quite
a
bit
by
providers.
It
took
on
that
role.
I
guess
after
rtb
rtbf
became
and
used
traditionally
for
bgp
and
pls
vpn
for
identifying
and
and
providing
ddos
mechanisms.
K
K
The
last
one
is
a
group
policy
id,
so
the
capabilities
of
vxlan
gpe
protocol
can
be
extended
to
find
a
next
protocol.
Shin
header,
that
is,
that
are
also
used
and
implemented
for
new
data
plane
functions
and
the
group
policy
id
shim
header
can
also
be
is
used
today
in
gen
eve,
that's
being
standardized,
as
well
as
the
excellent
gpu
to
carry
metadata.
K
So
these
seven
different
mechanisms
that
do
exist
today
and
they
they
have
their
data
plan
specific
function
and
they
provide
they
have
their
goal
and
really
they're
tied
and
they
have
tied
to
their
specific
data
plan
the
pacific
functional
goal.
They
they
all,
have
they're
all
possibilities
that
could
be
used
for
apn,
but
I
think
the
granularity
is
it
is.
It
is
more
coarse
and
it's
not
the
fine
grain
granularity
that
that
we're
looking
for
for
for
apn
for
the
application
id
attribute
next
slide,
please.
K
K
Apn's
aim
is
to
define
an
attribute
that
is,
generic
can
be
used
for
various
policy
enforcement
functions,
enables
service
provisioning
and
can
be
carried
in
all
iedf
data
plan
encapsulations.
So
what
we're
looking
for
is
a
really
ubiquitous
approach
that
can
be
implied
that
it's,
it's
really
data
plane,
agnostic,
that
it
does.
It's
not
tied
to
a
particular
solution
or
a
particular
function,
but
a
data
plan
encapsulation
that
can
carry
a
application
specific
attribute
that
can
be
used
across
all
data
plans
in
the
same
same
data
structure,
but
apply
to
all
data
planes
next
slide.
L
Yes,
hi.
Can
you
hear
me
yeah
yeah
yeah?
Yes,
yes,
yes,
I
agree
pretty
much
with
your
literature
review
and
the
gap
analysis.
L
I
noticed
you
missed
the
work
being
done
on
carrying
an
aggregate
id
in
the
packet
for
network
slicing,
not
sure
if
you
you
had
a
chance
to
look
at
that,
there's
a
lot
of
resemblance
in
the
in
what
an
aggregate
id
can
do
in
application.
Where
networking.
K
Thank
you.
Thank
you
tariq.
I
I
believe
I
have
looked.
I
looked
at
that.
I
guess
the
aggregate
idea
for
network
slicing
and
then
that
that
is
a
good
good
point
that
you
that
you
bring
out.
So
I
mean
that's,
definitely
something
to
look
at
and
then
maybe
something
that
could
actually
be
tailored
and
could
possibly
work
with
apn,
but
I
think
in
this,
in
the
gap
analysis
we'll
definitely
look
at
add
that
into
the
into
the
deck
as
something
to
investigate.
M
Yeah
thanks
in
the
very
first
set
of
comparisons
there,
you
said
that
the
identifier
spaces
weren't
big
enough,
so
I
was
wondering
what
size
of
identifier
space
is
needed,
like
how
many
bits
does
this.
This
label
need
to
be
so
I
know.
K
K
I
believe
it's
it's
32-bit
or
I
believe
it's
like
16
or
32,
but
the
details
of
that
is
it's
right
here
on.
I
guess
on
the
on
the
screen
now,
so
I
guess
the
answers
will
be
coming
shortly.
K
N
Okay,
hello,
everyone.
This
presentation
is
about
ap
attributes.
As
mentioned
earlier,
each
ep
refer
to
the
application
aware
network
which
attempts
to
perform
application
level,
traffic
steering
and
network
resource
allocation.
So
the
question
is
how
to
mix
network
more
precisely
know
the
requirement
of
different
applications.
N
N
The
structure
ap
attribute
can
be
used
as
opaque
value
to
map
to
a
policy,
as
mentioned
by
the
earlier
speakers,.
N
So
the
ap
attributes
will
be
attached
to
a
packet
to
in
indicate
how
it
should
be
handled
in
the
network
in
specific,
the
video
fields
of
the
struct
api
can
be
inspected
and
used
to
indicate
which
parts
to
apply.
N
N
Apid
can
be
used
to
undefine
the
policy
on
the
various
policy
enforcement
points
with
the
epm
domain,
the
values
of
ep9ds
are
assigned
and
the
integrated
analytical
demonstration
determined
by
mapping
the
package
fields
as
instructed
based
on
controller.
N
So
here
is
a
the
domain.
Maybe
epm
domain
may
be
may
consist
of
multiple
multiple
network
domains
operated
by
a
single
operator.
N
It
can
include
the
following:
informations.
The
first
one
is
api
group
id
which
unifies
the
application
group
of
the
traffic.
It
does
not
refer
to
any
specific
application.
N
N
N
D
O
Okay,
so
I
have
two
questions.
The
first
question
is
that
you
mentioned
the
apm
attributes
is
opaque
and
then
you
also
talk
about
it
has
structures
and
the
router
network
devices
in
the
middle
will
inspect
individual
fields
in
that
structure.
O
So
that
seems
to
be
contradicting
to
me
with
the
opaque
number
you
shouldn't
be
looking
into
individual
fields
of
the
opaque
number.
That's
the
first
question
verified
that
the
second
question
is
about
apn
attribute
where
you
define
it
specified
bandwidth,
jitter,
latency,
all
those
things.
So
do
you
expect
a
transit
router
to
look
at
those
raw
numbers
in
terms
of
bandwidth,
latency
jitter
and
determine
how
to
forward
traffic.
N
Regarding
to
the
first
question,
I
don't
think
they
are
contradictory,
congratulate
each
other,
because
the
ap
apn
may
be
opaque
because
it
is
derived
from
other
information
for,
for
example,
five
tuples
and
this
line
id.
So
it
is
derived
from
this
derived
from
this
specific
import
information
and
it
may
be
structured
because
the
ap
enemy
take.
My
understanding
is
that
and
my
expectation
that
epn
may
take
the
structure
which
may
include
the,
for
example.
N
Enterprise
users
need
to
include
the
id
of
this
employee
user
also
may
include
some
information
about
the
department
of
this
employee
users,
so
it
it
is,
should
be
structured.
That's
my
understanding
regarding
the
same
question.
Yes,
there's:
several
parameters
may
be
contained
in
the
parameters.
N
D
Shipping
you've
been
in
the
queue.
I
think
you
want
to
clarify
a
few
things.
Do
you
want
to
grab
the
mic
and
express
your
views?
Yeah
go
ahead.
D
P
Yeah,
can
you
describe
how
this
work
differs
from
debt
net,
where
we
already
have
six
tuple
classification
as
well
as
can
support
all
the
service
parameters
you've
listed.
N
Sorry
I
have
not
been
involved
in
that
night.
I
I
hope.
N
My
my
understand
is
that
if,
if
ap
architecture
or
the
attributes
can
be
adopted,
I
think
it
will
be
helpful
to
or
it
would
be
useful
for
for
the
dead
nets
and
to
solve
the
to
meet
the
requirements
of
that
night.
I
don't.
I
think
that
they
will.
N
This
will
be
give
some
good
support
to
that
net.
P
Q
Yes,
first,
I
think
to
the
tonight
that
night
is
one
of
the
network
services
we
can
support,
and
so
the
that
net
is
used
to
provide
the
guaranteed
latency
within
the
network
and
apn
is
used
to
express
the
services
and
to
be
better
matched
to
those
one
of
the
deterministic
paths
that
is
to
that
net
and
how
to
integrate
this
to
work,
and
we
can
continue
working
on
that
and
beta
clarified
to
jeffrey
and
yes,
the
opaque
and
structured
is
now
the
conflicted,
and
we
have
the
structured
ap
attribute
doesn't
mean
we
have
the
clear
text
within
this
field,
so
that
is
different
and
also
the
parameters.
P
Now
I
look
forward
I'll
get
out
of
the
cube,
but
I
look
forward
to
hearing
the
differences
between
what
you're
describing
is
the
apn
architecture
and
apn
solution
that
isn't
already
met
by
net.
Thank
you.
R
R
Structure
both
the
id
and
the
parameters
could
be
used
to
do
an
opaque
lookup.
I'm
wondering
how
that
can
work
when
you
have
fairly
rich
parameters.
What
what
exactly
is
a
lookup
operating
on
when,
when
it's
running
opaquely.
R
Q
So
yeah
so
here
when
we
put
opaque
it,
just
the
operators
doesn't
need
to
know
the
identities
of
the
users
and
even
their
group
of
the
applications.
So
the
operators
only
want
to
do
the
policy
enforcement
more
flexibly
more
efficiently
and
it
doesn't
need
to
know
the
identities
which
will
eliminate
the
privacy
issues.
But
with
this
id
we
have
so
many
ideas.
As
in
the
stated
in
the
gap
analysis
is,
you
can
use
those
identifiers
to
do
the
policy
enforcement.
That
is
the
whole
point.
R
Okay,
let
me
make
sure
I
understand
what
you
said.
It
sounds
like
what
what
I,
what
you
said
was
that
the
I,
the
identifier,
is
opaque
and
that
it
hides
the
parameters
from
which
it
was
defined,
but
it
is
visible
to
the
network
and
the
network
expect
to
understand
it
and
use
it
accordingly.
Q
Yes,
so
this
is
the
same
when
you
do
the
policy
enforcement
even
for
the
icp,
the
sorry,
the
yes,
so
so
you
you
use
those.
You
use
this
information
to
reinforce
the
policy
and
then
you
know
what
is
in
indicates,
but
again
here
it
doesn't
needs
to
know
the
all
the
information
related
with
the
privacy.
D
F
I
just
want
to
appreciate
if
you
can
clarify
their
apn
parameters,
do
they
explicitly
in
any
way
convey
the
bandwidth
requirements,
some
other
performance
requirements
like
scheduling.
F
N
G
N
Currently,
we
think
that
the
bandwidth
can
be
carried
in
the
atrium
in
the
parameters
and-
and
as
I
mentioned
in
my
presentation,
I
think
this
definition
this
attribute
is
open.
It
can
carry
other
informations
based
on
the
actual
requirement
of
the
use
cases.
F
But
okay,
so
if,
if
if
the
apn
parameters
convey
a
bandwidth
requirement,
then
what
you
think
happens
if
the
transit
node
cannot
comply
with
this
requirement
if
the
packet
get
dropped,.
Q
Yeah
and
greg,
let
me
clarify
so
first
the
parameters
how
to
use
the
parameters
is
a
topic.
We
too
we
can
investigate
in
the
future
and
and
also
currently,
we
only
identify
the
network
performance
parameters
that
we
could
use
and
how
to
use
it
in
the
transit
node.
Again
I
just
answered
before
I
don't
think
that
will
be
used
by
the
transit
node.
F
F
T
F
Benefit
on
a
transit
node,
because
you
want
to
maintain
the
shape
of
your
flow
and
use
this
information
in
a
transit
node.
So
because
you
do
the
policing
and
shaping
in
the
transit
nodes
and
that
been
demonstrated
that
improves
the
overall
service
quality.
D
I
need
to
interrupt
but
shopping
before.
F
D
Q
Yes,
just
a
quick
clarify
the
transit
note
is
not
doesn't
have
to
be
the
policy
enforcement
note
yeah.
Okay,
so
I
will
start.
My
presentation
here
is
about
the
worked
items
to
be
covered
in
this
potential.
Ap
work
working
group
next
piece.
Q
Q
So
it
covers
from
the
data
plane
to
the
control
plane
and
the
architectures
and
the
new
services
that
can
be
supported
by
apn.
So
first
in
the
data
plane,
the
core
work
we
need
to
work
on
is
that
aping
attribute
and
so
based
on
the
previous
presentations.
We
would
know
what
we
need
to
include
in
this
18
attribute
and
what
will
be
the
reasonable
design
and
then
so
how
to
carry
the
ap
attribute
over
the
various
in
types
encapsulations,
the
tunnel
encapsulations.
Q
It
doesn't
have
to
be
amperes
and
it
could
be
an
ipv6
srv6
and
even
overlay
protocols
and
in
the
control
plane
we
need.
We
would
need
protocols,
extensions
to
exchange
or
to
carry
the
apn
attribute
and
to
do
the
policy
enforcement
and
for
the
management,
and
we
would
need
the
young
model
to
to
define
the
young
model
and,
for
example,
to
enforce
the
mapping
relationship
between
the
rules
and
the
a-ping
attribute
and
and
on
the
top
architecture,
which
was
also
very
important
and
the
fundamental
work
the
framework.
Q
And
we
can
see
that
caused
a
lot
of
confusions
before
and
we
need
to
have
a
very
clear
framework
to
be
defined.
Q
And
here
we
will
need
the
help
from
maybe
cross
areas
and
here
again
the
problem
statement.
We
have
after
this
so
long
work.
Our
discussions.
Q
We
have
a
very
clear
problem
to
be
solved,
so
we
have
a
clear
problem
statement
and
that
is
also
need
to
do
within
the
group
and
and
also
the
use
cases
and
some
very
key
use
cases
that
could
show
what
apn
could
do
and
also
the
security
privacy
issues.
And
we
have
been
challenged
upon.
And
we
would
need
to
address
that
and
gave
a
clear
statement
on
that.
Q
Q
Yes,
so
what
do
these
working
group
deliver
and
first
the
statement
and
it's
a
very
important-
this
working
group
will
not
publish
anything
that
varies
the
users,
privacy
and
security
and
that
will
be
stated
included
in
the
charter,
and
so
we
have
six
work
items
and
first
the
framework
and
the
problem
statement.
That
is
fundamental.
Q
Q
Q
We
would
need
the
bgp
or
psap
and
those
source
southbound
interface,
to
enforce
the
apn
and
the
policies
and
those
policies
that
are
rules
I
just
mentioned,
and
here
igp,
because
the
av
apn
attribute
is
not
actually
for
routing
and
whether
we
will
need
a
idp.
But
there
are
already
some
similar
work
in
lsr.
We
could
refer
to
and
next
piece.
C
Hello
yeah.
We
can
hear
you,
okay.
I
just
used
to
clarify
for
the
greg
the
the
issue
that
one
because
that's
greg
mentioned
that
how
to
process
the
parameter.
So
I
think
that's
about
the
solution,
so
I
think
that's
the
user.
F
Please
so
you
identify
as
one
of
group
of
encapsulations
to
for
apn
to
work
on
as
overlay
protocols,
genevieve
vxlan
gui,
probably.
Q
Yeah-
and
just
here
is
all
based
on
the
deployment
scenarios
and
in
some
cases,
the
overlay
protocols,
the
vxlan
and
the
gnaf
may
not
be
ipv6
based
so,
but
they
could
still
be
used
to
support
apn.
Q
Q
T
D
Need
to
wrap
up
on
shipping
presentation,
so
we
can
go
back
on
okay.
F
A
Yeah
sure
so
in
fact
we're
we're
a
little
bit
ahead
on
the
agenda,
which
is
good,
because
I
think
we've
got
lots
and
lots
of
open
questions.
Some
of
them
are
about
how
does
the
technology
work
and
some
of
them
are
about?
What's
it
for
and
quite
a
lot
of
them
I
think,
are
about.
A
Why
can't
we
do
this
with
what
we've
already
got
so
a
reminder,
you
don't
have
to
address
these
questions,
but
it
may
help
you
to
think
about
them,
and
then
I
think
we
should
just
simply
run
the
queue
until
five
minutes
before
the
hour
or
until
everybody
has
talked
out
and
then
we'll
wrap
up
so
go
for
the
queue
and
and
dan
can
run
it.
Oh
yes,.
D
So
zoe
I
I'd
like
you
to
go
first,
so
I
don't
have
to
pull
you
out.
O
Okay,
so
I
have
two
top-level
comments.
The
first
one
is
that
the
entire
problem
domain
and
the
solution
was
considered
so
far
for
apn.
I
think
it's
already
well
covered
by
the
ietf
network
slicing.
O
O
So
I
can
give
the
mic
to
the
next
person
in
the
queue
now,
but
if
I
could
in
the
mean
in
the
meantime,
if
I
could
share
that
one
slide
to
better
illustrate
my
first
point,
that
would
be
great.
J
J
O
Okay,
is
it
sharing
now.
O
Okay,
so,
as
I
mentioned,
I
have
seven
sub-bullets
there.
Basically,
the
quotes
from
the
ietf
network
slicing
framework
document
to
show
that
that
it
well
covers
the
apm
problem
domain
answer
solutions.
A
Yeah
I'd
I'd,
I'm
not
sure
that
meat
echo
is
is
achieving
the
desired
sharing
here.
So
I
don't.
A
I
mean
yeah,
maybe
just
well
yeah,
don't
don't
don't
make
a
a
60-minute
talk
of
it,
but
just
really
quick.
O
Okay,
okay,
I'll
just
read
them
so
an
ietf
network's
nice
provides
the
required
connectivity
between
different
entities,
blah
blah
with
a
specific
performance
commitment.
That's
our
first
bullet
point.
The
second
one
is
that
it
is
intended
that
itf
network
slices
can
be
created
to
meet
specific
requirements,
typically
expressed
as
bandwidth
latency,
latency
variation
and
other
desired
or
required
characteristics.
O
The
next
one
is
itf
network
slides,
combines
the
connectivity,
resource
requirements
and
associated
network
behaviors,
such
as
bandwidth,
latency,
jitter
and
network
functions
with
other
resource
behaviors
term
slice
refers
to
a
set
of
characteristics
and
behaviors
that
separate
one
type
of
user
traffic
from
another
itunes.
Microsoft,
next
slides
assumed
that
an
underlying
network
is
capable
of
fulfilling
all
or
some
of
the
slos
to
all
the
traffic
in
the
slides
or
to
specific
flows
in
a
slice.
O
Many
approaches
are
currently
being
worked
out,
worked
on
to
support
iit
network
slides
in
ip
and
nps
networks,
with
or
without
the
use
of
segment
routing.
Most
of
these
approaches
utilize
a
way
of
marking
packets,
so
that
network
nodes
can
apply
specific
routing
and
forwarding
behaviors
to
packets
that
belong
to
different
igf
network
slices.
O
The
realization
can
be
achieved
in
a
form
of
either
physical
logic,
connectivity
using
vpns
virtual
networks
or
a
variety
of
tunneling
technologies
such
as
segment,
routing,
mpos,
etc,
and
also
a
slice.
Every
concept
brought
up
in
the
some
draft
best
paragraphs
is:
it
is
extension
to
the
network
slicing.
O
A
sliced
aggregate
is
basically
a
collection
of
packets,
it's
very
similar
to
the
behavior
aggregate
concept
in
the
deep
server
days,
but
here
obviously
it
can
be
at
any
greater
energy
level
and
it
can
be
identified
by
opaque
number,
for
example,
an
mpos
label
that
derek
mentioned
earlier
exactly
so,
those
are
the
some
quotes.
Yes,
I'm
done.
Okay,.
O
Yeah,
I'm
down
I'm
down
basically.
U
Yeah,
so
I
have
two
quite
a
few
questions
and
some
comments.
So
the
question
was
around
the
work
that
you
expect
an
apn
working
group
to
do.
Is
it
more
or
lined
around
creating
lots
of
informational
drafts
or
rfcs
around
how
to
implement
apn
with
the
various
encapsulation
protocols,
or
are
there
actually
legitimate
creation
of
work
that
needs
that,
because
I
haven't
seen
it
aside
from
maybe
the
apn
id
what
I've
transpired
is
more
around
how
to
leverage
the
protocol?
Maybe
I'm
wrong
indian
interpretation.
U
Q
Yes,
that
is
to
my
presentation,
yeah.
So
besides
we
we
will
have
some
information
drafts
and
probably
for
the
use
cases,
but
for
you
could
see,
we
do
need
some
standards
to
be
defined,
like
the
ap
attribute,
how
to
define
the
structures
and
the
design,
and
also
it's
it's
like
the
header
of
apn
and
also
in
the
data
plane
and
the
control
plane
and
the
management
plan,
and
we
all
need
some
standards
to
be
defined
in
those
areas.
L
I
wasn't
sure
I
was
at
the
top
of
the
queue
or
not
but
yeah.
My
question
is
very
much
similar
to
what
danielle
bee
had
asked
is
chuping
in
her
presentation
had
presented
multiple
extensions
in
data
plane
and
control
plane,
routing
protocols,
but
I
haven't
seen
the
gap
analysis
being
you
know
done.
Existing
tools
can
achieve
what
she's
asking
for.
Did
we
look
at
the
tools
that
we
have
and,
and
is
it
short
of
delivering
what
we
expect?
Thank
you.
D
Thanks
peng
you're
next.
V
V
W
Chad,
hardly
speaking
thanks
very
much
to
the
presenters
in
particular
to
shooping
for
her
presentation
of
the
commitments
of
the
working
group
toward
privacy
and
security
in
the
course
of
intended
work,
and
I
also
appreciate
the
fact
that
there
is
already
a
draft
produced
for
the
intended
working
group
which
which
deals
with
that.
W
Unfortunately,
I
think
there's
a
problem,
and
I
think
that
problem
is
around
the
richness
of
the
intended
identifier,
and
the
placement
of
the
ingress
point
means
that,
depending
on
how
it's
structured,
it
could
end
up
being
an
identifier
which
carries
a
great
deal
more
information
than
the
five
triple
itself
would,
and
the
result
of
that
is
that
it
needs
to
be
handled
very,
very
carefully.
The
current
proposal
in
the
documents,
as
I
understand
it,
as
that
this
would
be
bleached
at
the
edge
of
a
network's
set
of
domains.
W
So
if
an
operator
was
multi-domain,
it
would
be
bleached
before
it
left
the
operator's
domain
so
that
it
did
not
cross
outside
of
the
operator's
policy
control
the
difficulty
there
is
you,
you
don't
really
have
a
mechanism
for
doing
that
inside
the
protocol,
because
you're
moving
from
domain
to
domain
when
they
are
controlled
by
a
single
operator.
The
end
cap
and
d-cap
points
are
flexible
and
the
result
of
that
is,
you
could
have
the
d-cap
point
outside
of
the
operator
and
subvert,
essentially
by
collusion
the
entirety
of
the
proposed
solution
for
this
problem.
W
I
I
think,
if
you
tackle
that
and
say
okay,
we
will
handle
that
and
make
sure
that
there
is
some
way
to
ensure
that
the
decap
point
is
is
known,
say
to
the
end
point
or
or
or
in
some
other
way,
one
you're
going
to
increase
the
complexity
of
producing
the
solution
here
enormously
and
two
you're
going
to
end
up
losing
or
you're
going
to
end
up
losing
the
multi-domain
single
operator
use
case
or
more
likely
both.
W
I
I
think
that
reads
on
c
and
d
realistically,
in
order
to
avoid
apn
becoming
the
handy
place
for
putting
identifying
metadata
across
all
encapsulation
formats,
you're
going
to
have
to
do
a
great
deal
of
work,
and
that
means
that
worth
the
cost
of
development
and
deployment
in
reality,
I
I
don't
believe
it
will
be,
so
I
I
think
we
have
to
be
very
honest
with
ourselves
here
that
there
are
other
parts
of
the
packet
already
that
have
the
same
risks.
W
It's
been
pointed
out
in
the
chat,
for
example,
that
flow
labels
can
carry
much
of
the
same
information,
but
I
think
adding
another
one,
and
in
particular
adding
one
that's
meant
to
be
generic
across.
All
of
them
is
not
the
right
thing
for
us
to
do
at
this
time.
Thank
you
very
much.
Thanks.
S
Daniel
speaking
from
the
zte,
thanks
for
the
wonderful
presentation
of
old
presenters,
I
have
two
questions
to
the
first
one
is
I
I
would
appreciate.
If
anyone
could,
I
could
clarify
that.
Is
there
an
top-level
attribute
structure
defined
over
all
of
the
title
practice
or
the
attribute
structure
will
be
specified
talo
by
talo?
S
This
is
my
first
question.
The
second
one
is
actually
what
I'm
confused
about
is
what,
when
it
comes
to
the
policy
employing
employment.
On
the
network
closed,
it's
only
involved
with
the
combination
of
flow
identification
and
the
according
attribute,
and
so
why
do
we
have
to
do
this
on
the
basis
of
packet
by
package
by
encapsulating
the
attributes
in
the
data
plane?
X
Oh
I've
covered.
I,
I
think,
there's
a
lot
there's
a
big
problem
with
this
piece
of
work,
which
is
it's
not
clear
why
you
ever
have
the
problem
of
having
multiple
domains
within
my
administrative
domain
with
incompatible
tunneling
protocols,
you're
going
to
need
to
change
all
your
hardware
to
do
this,
you're
going
to
need
to
change
your
software
to
put
on
this
new
tunneling
layer
and
then
hook
up
the
tunneling
layers.
You've
already
got
if
you're
going
to
do
all
that
work.
X
Can't
you
just
pick
a
tunneling
layer
like
mpls
or
or
death,
or
that
enhancements
are
something
that
lets
you
get
the
quality
of
service
and
policy
enforcement
things
you
want
and
there's
a
huge
tension
here
between
having
a
complex,
rich,
structured
identifier
and
very
efficiently
pushing
packets
around,
and
it's
not
clear
where
this
work
falls
on
that
it,
it
seems
like
there's
a
problem
I
complained
about
before,
which
is
it's
not.
There
isn't
a
clearly
defined
use
case
that
we
can
map
onto
a
set
of
things
and
see.
Okay.
X
This
is
exactly
where
the
gap
is.
It
seems
to
be
a
very
protein,
so
we
need
an
identifier.
We
need
a
very
arbitrary
identifier
and
it
needs
to
control
these
core
networking
functions.
I
don't
think
that's
really
feasible.
I
think
when
it
comes
to
quality
of
service,
there's
been
a
lot
of
work
already,
and
the
fact
that
the
draft
authors
haven't
haven't
been
involved
like
detona.
It
just
doesn't
seem
to
make
a
lot
of
sense
to
pursue
independently
saying
very
similar,
especially
when
it
comes
across
all
these
things.
Y
Comment
hi,
thank
you
for
the
presentation
and
and
I'm
going
to
start
off
by
saying
that
I'm
going
to
repeat
some
of
ted's
points,
probably
most
of
mostly
what
I'm
saying
has
been
covered
by
ted.
So
it's
both
a
good
and
a
bad
idea
to
go
after
him.
Y
For
me
right
now,
I
want
to
repeat
it,
however,
because
I
think
it's
worth
repeating
the
watson
pointed
this
out
as
well
that
the
richness
of
information
here
to
me,
that
is
a
a
big
part
of
the
the
problem
I
have
with
the
proposal
at
the
moment.
Y
Richness
is
not
always
a
good
thing
and
particularly
when
it
comes
to
the
ability
to
describe
data
and
for
the
ability
to
to
to
arbitrarily
share
that
rich
metadata
about
whatever
you're
observing,
without
putting
any
serious
bounds
on
this
without
actually
doing
a
serious
on
without
having
a
good
understanding
of
what
exactly
that
could
entail.
Y
Basically,
we
can
imagine
any
use
of
this
information
and
this
metadata,
and
I
want
to
draw
attention
to
that.
We've
seen
proposals
like
this
in
the
past,
where,
again,
a
generic
structure
is
used
to
describe
a
a
a
specific
problem
or
as
a
solution
to
a
specific
problem,
and
I
always
find
that
the
that
it's
lost
on
the
proponents
that
that
that's
the
the
simple
notion
of
the
fact
that
this
is
a
general
structure
is
in
fact
the
problem.
Y
If
the
solution
was
much
more
specific,
it
would
force
you
to
think
about
the
problems
much
more
precisely
and
as
a
result,
the
solution
might
be
much
more
meaningful
for
the
problem
that
you're
trying
to
solve.
If
all
you're
trying
to
do
is
build
a
mechanism
that
will
allow
you
to
solve
all
future
problems.
That
also
has
the
potential
and
will
definitely
create
a
lot
more
problems
in
the
future.
For
us
to
solve
again
so
yeah
I
mean
those
are.
Z
Young
from
china
mobile-
I
I
have-
we
have
some
opinion
with
panglio
on
the
on
this
apn,
but
before
we
have
before
talking
about
opinion
on
this
apn,
I
have
question
on
this.
Z
The
question
is,
if
you
know
we
have
many
many
kind
of
tunnels
in
case
of
we
have
end
to
end
tunnel,
just
a
single
tunnel
for
end-to-end
connection,
that's
clear
that
apn
can
work
correctly
and
as
expected,
but
in
case
of
we
have
many
domains
and
one
dom
instrument
has
different
kind
of
tunnel
encapsulation,
then
how
to
handle
the
the
the
ap
handover.
Z
That
is
one
one
question
and
after
this
question
I
have
I
want
to
to
talk
about
my
opinion
on
this
apm
and
you
know,
apn
is
helpful
for
more
fine
granularity
of
the
applications
to
carry
in
the
package.
So
I
support
to
have
the
apn
to
to
to
for
the
future
work,
and
the
first
question
is
the
question
list
here
is:
do
you
think
if
you
will
be
harmful
anyway?
I
think
that
that
if
you,
if
apn,
is
managed
in
one
single
operator,
that
is
a
limited
domain
that
is
manageable.
Z
So
that's
one
question
and
then
I'm
for
the
deliverables,
I'm
I'm
thinking
that
only
the
framework
and
the
mechanism
is
not
not
sufficient
for
supporting
the
future
work
and
I'm
thinking
that
at
least
we
need
to
define
some
concrete
common
applications
like
codepoint
and
similar
with
the
dscpn
flow
labels.
That
can
be
a
guide
for
the
device
vendors
to
do
their
implementation.
Z
That
is
my
suggestion
to
the
question
the
deliverables
and
the
third.
I
think
we
can
have
the
group
to
start
the
solution.
Solution
work
as
soon
as
possible.
Z
D
U
Is
not
about
the
questions
about
that,
so
I
do
agree
that
there
is
a
need
to
to
work
on
the
application
piece
of
networking,
I'm
not
sure
that
it
needs
something
new.
I
think
we
we
the
notion
that
an
application
needs
to
be
able
to
talk
to
another
right
now.
If
you
look
at
how
those
systems
are
built,
they
do
actually
create
a
lot
of
new
ways
of
doing
things
using
service
meshes
after
product
on.
T
U
And
some
military
systems
which
rely
on
the
existing
network,
I
think
there's
a
gap.
I've
discussed
this
a
while
ago
in
pan
rg
as
well
when
it
started,
is
that
we
have
the
way
of
the
network
to
express
its
systems.
We
talk
about
how
an
application
should
express
this,
it's
logic,
but
the
developer
itself
doesn't
want
to
deal
with
that
model.
So
there
needs
to
be
an
abstraction
layer
from
a
developer
to
build
an
application
that
should
not
have
to
worry
about
which
encapsulation
is,
and
I
don't
think
that
abstraction
needs
to
be
another
protocol.
U
A
F
Yes,
so,
as
lou
have
pointed
out,
that
net
already
solved
its
problem
and.
F
It
doesn't
appear
that
there
is
need
for
another
mechanism
to
solve
the
detonate
problem.
I
concur
with
ted
with
his
concerns,
and
actually
I
agree
with
daniel
very
much
that
the
problem
that
does
exist
doesn't
have
to
be
solved
in
a
data
plane.
We
do
have
some
other
mechanisms
and
management.
Plane
is
one
of
them.
F
Where
are
their
policies
and
application
requirements
can
be
conveyed,
so
that
probably
would
be
more
reasonable
and,
I
would
repeat,
the
other
suggestion-
is
just
look
at
existing
mechanisms
and
probably
start
with
the
rfc
6437
that
defined
flow
label
for
ipv6,
because
this
rfc
does
not
say
that
flow
label
must
be
used
and
only
used
for
load,
balancing
in
ecmp
and
lab
okay.
Thank
you.
D
D
H
I
think
what
we
have
here,
the
use
cases
are
a
bit
light
when
I
say
they're
light.
What
I
mean
by
that
is
the
use
cases
that
have
been
presented
right
now.
Don't
don't
justify
the
broad
charter
that
the
proponents
are
asking
for
because
they're
a
bit
light.
It
also
makes
it
difficult
to
do
a
gap
analysis.
H
Do
we
do
we
already
have
what
we
need?
It
also
makes
it
difficult
to
know
whether
it's
worth
altering
the
forwarding
plane,
which
we
know
is
going
to
be
a
big
problem,
and
then
the
third
problem
with
chartering
this
working
group
is
that
it
would
span
so
many
areas.
It
would
span
a
forwarding
plane,
it
would
span
mpls,
it
would
span
ipv6.
H
D
AA
Comments
for
constancy,
we
have
to
use
kickstarter
for
implementing
apn
to
re,
realize
game
acceleration
based
on
the
implementation
of
apm.
The
api
attribute
is
only
using
our
network
domain
and
will
not
be
harmful
to
other
network.
I
think
the
implementation
process
is
according
to
the
contract,
with
a
game
service,
a
provider
provider.
AA
We
can
also
explore
better
business
business
models
to
achieve
winning
cooperation
through
apm.
So
I
think
this
work
makes
a
lot
of
sense.
I
will
contribute
to
the
work
and
maybe
there
are
more
applications
attributed
needed
to
be
defined.
So
a
new
working
group
has
a
better
way
to
do
this
work.
That's
all.
AB
So
I
don't
have
a
complaint.
I
actually
have
a
suggestion,
hopefully
a
constructive
one,
and
the
suggestion
is
that
you
know.
Maybe
what
you
should
be
doing
is
is
write
the
document
that
assumes
this
this
model,
where
one
one
does
one
lookup
and
then
encodes
some
information
in
a
very
small
constraint
set
of
bits
and
and
then
this
document
would
explain
how
to
do
that
with
some
of
the
existing
itf
technologies,
such
as
mpls
or
sfc
and
whatnot.
So
I
think
that
would
be
a
useful
document
for
us
to
read.
D
AC
AC
D
Thank
you
richard.
If
you
want
to
go.
AD
Okay,
this
is
richard
yeah,
I'm
from
yeah.
So
one
thing
I
want
to
emphasize
I'm
academia
so
therefore,
I'm
not
really
from
industry,
but
what
I
do
want
to
see
is
I
do
actually
I
like
this
work
and
the
particular
reason
I
want
to
see
it
is
I
forgot
who
gave
the
presentation
to
show.
There
are
all
kinds
of
labels
we
have
flow
labels
or
dsdp,
and
so
on
and
all
kinds
of
things
define
already
in
the
packet
headers.
AD
If
we
learn
one
thing
in
academia,
for
example,
in
programming
language
theory,
is
you
probably
want
to
have
some
kind
of
type
theory
to
become
whenever
we
have
static
type?
And
if
you
have
semantics
defined
it's
great,
you
can
catch
all
the
bugs
and
you
don't
want
to
do
all
kind
of
hacking
and
so
on.
This
is
great.
So,
overall
right
now
there
are
a
lot
of
different
flow
labels,
nps
labels
and
the
code
upon
the
all
defined,
but
all
have
very
well
narrowly
defined
types
or
external
type
systems.
AD
Here,
apm
might
be
a
very
good
way
to
essentially
introduce
some
kind
of
generic
type
system
into
the
pack
header,
which
is
great
and
one.
I
do
have
one
very
quick
suggestion.
Oh
I'll
shut
up,
I
do
actually
see
a
lot
of
used
cases
and
somehow-
and
also
I
do
have
a
lot
of
like
questions
about,
for
example,
the
current
and
the
encoding
of
the
identifier
format
and
so
on.
AD
For
example,
I
can
see
the
api
as
a
way
of
signaling
from
applications
to
the
network,
and
actually
I
also
see
a
lot
of
arguments
talking
about.
Essentially,
you
can
really
compress
the
five
tuple
lookup
to
essentially
some
kind
of
apn
id
lookup,
but
that's
actually
our
total
different
use
case,
for
example,
for
the
compressing
or
essentially
reducing
expensive,
lookup
and,
of
course,
they're
early
working
academia,
for
example,
from
beyond
stockholders
talking
about
core
seedless
networking
basic
philosophy.
Is
you
want
to
do
a
lot
of
things
at
add?
AD
You
want
to
do
a
lot
of
things
and
you
know
the
core
make
a
chord
to
be
lightweight
and
there
are
kind
of
things
which
should
probably
you
probably
want
to
be
more
careful
to
define
all
the
like
semantics
of
the
identifiers
as
carefully
as
possible,
but
that
could
be
very,
very
valuable.
And
finally,
we
can
have
soft
system
here
in
the
network.
AD
D
AE
Yes,
thank
you.
I
just
wanted
to
ask
about
the
limits
of
what
can
be
used,
what
can
be
gleaned
and
put
into
an
identifier
based
on
the
five
tuple
and
in
a
world
of
like
increasingly
encrypted
everything,
how
how
much
meaningful
identifier
space
is
there
actually,
and
particularly,
also
in
a
world
where
we
start
having
lots
of
mask
tunneling
and
oh
gtp
proxies?
D
All
right,
thanks
dirk.
AF
Okay
yeah.
Maybe
this
was
a
comment
already
given
by
several
people,
but
perhaps
I
can't
repeat,
I
think
the
apn
work
is-
has
done
a
good
job
in
pointing
us
to
the
need
for
better
traffic
classification
in
the
internet,
which
is
typically
really
an
inter-domain
scenario,
and
I
want
to
thank
them
for
that.
But
what
I
learned
here
is
that
they
introduced
just
a
new
apn
domain
in
addition
to
the
existing
sfc
and
mpls
and
so
physics
demands
and
so
and
claiming
that
they
can
grant
infinite
granularity.
AF
T
Thanks
daniel,
I
just
wanted
to
make
a
comment
from
my
understanding
of
what
apn's
actually
trying
to
do
and
and
how
it
does
differ
from
network
slicing.
I've
always
thought
of
network
slicing,
as
really
looking
at.
How
do
I
dedicate
resources
in
the
network
to
specific
flows?
T
What
apn,
at
least
from
my
perspective,
is
ultimately
trying
to
do
is
is
identify
who
you
are
what
you
are
where
you
are,
and
what
you're
trying
to
do
and
map
that
to
an
identifier
that
can
be
used
to
enforce
policy
and
that
policy
might
be.
This
traffic
needs
to
go
through
a
particular
network
slice
or
this
traffic
needs
to
go
through
a
particular
service
chain,
or
this
traffic
needs
to
go
through
a
particular
segment
routing
path,
and
the
who
you
are
is
you
know,
is
this
jim?
Is
it
his
wife?
T
T
Is
he
on
an
ipad?
Is
he
on
an
ipod?
You
know,
is
he
on
his
xbox?
Is
he
in
his
home
office
or
is
he
in
a
a
controlled
environment
such
as
a
company
office,
or
is
he
down
the
library
or
in
the
pub?
And
what
am
I
actually
trying
to
do
and
I'd
map
that
to
an
identifier
that
then
I
can
enforce
policy
in
the
network.
T
So
I
think
that's
how
it
differs.
But
you
know
perhaps
it's
difficult
in
these
cases
because
you
have
to
choose
simplified
use
cases
to
try
and
get
the
points
across
and
you
know
perhaps
more
detailed
use
cases
are
required,
but
I
just
wanted
to
make
that
comment
and
and
get
that
out
there
thanks.
AG
Hey
just
make
a
very
quick
comment
on
the
gap
analysis.
I
think
one
thing
that
we
can
do
with
the
gap.
Analysis
is
also
try
to
focus
on.
AG
Why
do
we
need
a
agnostic
mechanism
for
this
work,
and
why,
like
you
know,
adding
things
into
iom
or
nsh
would
be
a
bit
of
a
hack
and
why
we
need
to
start
from
a
clean
state
and
design
this
in
an
agnostic
mechanism,
and
it
also
adds
on
to
the
point
that,
by
this
work,
if
it
is
distributed
across,
multiple
working
groups
would
be
a
bit
of
a
pain
and
having
a
common
place
would
be
really
helpful
because
of
the
issues
that
are
kind
of
highlighted
today,
we
need
something
where
those
things
can
be
handled
in
a
common
place
in
an
agnostic
fashion
and
then
apply
it
to
various
data
plans.
AG
D
Thank
you,
shuping
or
robin
you've
been
in
the
queue
for
quite
some
time.
Pretty
sure
you
have
some
answer.
Are
you
yeah
go
out?
Please.
Q
Yes,
so
here
we
I,
I
can
see
it
first.
Maybe
we
can
let
him
go
first
for
source.
AH
Q
AH
Q
AH
Quick
note
on
the
privacy
right
that
just
like
to
make
my
standard
reminder
that
there
is
more
and
more
communications
that
doesn't
include
a
user
with
privacy
concerns,
but
more
and
more
machine-to-machine
communication,
and
you
know
there
is
a
lot
of
auditing
and
other
transparency
and
regulation
requirements.
Where
you
know
the
information
carried
in
this
headers
or
so
will
have
completely
perfect
semantic
without
you
know
introducing
any
privacy
concerns.
AH
Q
I
I
can
just
play
some
clarifications
and
to
the
questions
before
and
also
the
the
chat
box.
So
I
think
what
we
haven't
addressed
in
this
meeting
is
that
we
are
not
creating
any
new
apn
domain.
We
are
based
on
the
existing
network
deployment
and
we
are
also
building
on
the
existing
business
model.
The
use
cases
we
give
here,
you
could
say,
is
light,
but
we
want
to.
We
have
been
presenting
use
cases
since
very
beginning
and
since
108
we
have
for
a
few
operators
have
already
presented
their
use
cases.
Q
We
have
presented
particular
use
cases
and
the
more
general
one
in
much
more
details,
so,
whichever
we
have
presented
so
much
so
in
this
meeting
within
within
this
short
10
minutes,
we
will
give
a
very
clear
use
case.
It
will
be
simple,
clear
and
straightforward
for
people
could
catch
the
key
point.
So
here
we
already
see
that
is
the
existing
business
model
for
the
cloud
lease
line.
Q
That
generally
is
very
expensive
and
they
will
must
tell
the
operators
what
will
be
their
services
and
what
will
be
their
requirements,
and
they
will
tell
the
operators
what
will
be
the
key
user
groups
of
their
some
department,
for
example
finance
or
marketing,
and
so
in
that
case
the
operators
will
know
some
information
of
those
who
use
groups
our
key
application
group,
so
they
could
perform
some
fun
granular
treatment
on
this
key
traffic.
You
know
currently
the
cloud
lease
line
is
they
have
to
they.
They
can
only.
D
Q
Yes,
and
about
the
privacy,
security-
and
yes,
nothing
is
perfect.
We
currently
we
just
had
the
start,
although
we
have
been
working
about
two
years
on
that,
but
we
need
help
on
this
surprise
and
security
issues,
and
we
have
to
do
the
effort
and
we
also
needed
help
from
the
community
to
help
us
to
solve
this.
Thank.
A
Wow
right,
thank
you.
That
was
a
a
mammoth
clue
at
one
point
and
sorry
to
to
those
who
who
have
just
been
cut
off.
The
chairs
have
been
typing
at
each
other
frantically
during
the
meeting
and
I've
scribbled
some
notes.
A
A
Some
of
that
was
covered
in
glenn's,
slides,
but
det
net
and
slicing
were
were
not,
and
that
needs
more
attention
potentially
that
apn
is
a
solution
for
slicing
or
that
det-net
is
a
solution
for
apn
and
so
on,
so
that
that
needs
attention
quite
a
lot
of
concern
about
privacy,
and
although
that
was
explicitly
excluded,
there's
I
think
it
was
ted,
pointed
out,
there's
risks
of
accidental
breaches
and
subversion
of
decapsulation,
as
well
as
the
worry
about
being
an
arbitrary
thing
for
carrying
metadata.
A
There
was
discussion
about
whether
this
should
be
applied
to
multiple
transport
or
underlay
protocols,
or
whether
it's
more
sensible
to
pick
one
and
say
this
is
what
you
use
for
apn
and
and
part
of
that
led
to
or
comes
from
it
being
very
unclear
whether
the
use
cases
are
general
or
or
more
open.
And
so
there
needs
to
be
more
focus,
probably
on
a
killer
or
some
killer
use
cases
and
in
particular,
what's
needed
in
the
attributes
and
the
policies
to
to
expose
those
use
cases.
A
And
one
other
thing
I
had
was
think
from
that
and
from
the
metadata
it's
not
clear
what
can
be
what
what
the
difference
between
what
needs
to
be
in
an
apn
attribute
and
what
could
be
in
an
apn
attribute,
and
then
my
last
scribble
here
says:
beware
of
ubiquitous
encryption
and
and
making
sure
that
apn
is
useful
in
that
context.
B
Hopefully,
my
network
won't
break
within
those
two
minutes.
Thank
you
all.
Thank
you
very
much.
I
think
it
was
a
success
success
in
its
forcing
function
to
bring
an
important
number
of
people
together
to
discuss
a
specific
topic.
B
B
B
Okay,
echoing
the
the
words
I've
said
at
the
beginning,
I
I
I
think
the
the
the
the
proponents
need
to
find
the
ways
to
convince
more
people
and
bring
more
diversity
to
and
yeah
bring
more
diversity
to
their
proposal.
B
And
so
what
are
the
next
steps?
Maybe
I'll
pick
up
the
idea
of
yari,
which
are
understood
as.
B
Try
to
write
a
draft
taking
one
example
for
a
specific
use
case
you
have,
which
is
clearly
well
defined.
That's
not
a
problem
for
me
from
my
perspective,
but
maybe
try
to
target
a
specific
data,
plane
technology
and
target
a
working
group
and
see
how
it
goes
because
we
are
engineers
and
it's
we.
We
do
need
to
understand
how
things
work,
and
that
would
be
the
advice
I
give
to
the
to
the
proponents.
A
So
I
think
our
time
is
up.
Can
I
thank
the
minute
takers.
Who've
had
a
tremendous
task
to
to
deal
with
and
ask
everybody
who
spoke
at
the
mic
to
take
a
couple
of
minutes
just
to
go
to
cody
md
and
check
that
what
they
wrote
down
was
approximately
what
you
said.
J
D
A
I've
never
had
to
stop
a
cody
md
a
meet
echo
meeting.
I
don't
know
what
we
do.
Do
we
just
kind
of
go
away
and.
E
B
You
need
to
leave
the
room
as
as
jails,
and
that
closes
the
the
session.