►
From YouTube: IETF103-DMM-20181108-1350
Description
DMM meeting session at IETF103
2018/11/08 1350
https://datatracker.ietf.org/meeting/103/proceedings/
A
A
Think
we
can
get
started.
Welcome
to
the
DMM
working
group.
This
is
the
organ
obsession,
so
today
a
couple
of
things-
my
co-chair
dapeng
is
not
here,
and
this
is
a
shriek
and
overly
from
Cisco
and
or
ad
suresh
should
be
joining
any
time,
but
we
can
get
started
so
a
couple
of
things.
This
meeting
is
governed
under
some
IETF
rules
and
regulations.
These
are
captured
in
various
IETF
specifications.
Please
be
aware
of
thought
regarding
IPR
policy
and
with
respect
to
what
you
say
right.
Please
be
mindful
of
that
and.
A
But
maybe
we
can
yeah
I
didn't
I
asked
one
of
the
guy.
He
said
little
pink,
I
think
she's
in
a
meeting,
but
now
it's
mine
so
welcomes
rational
and
minute
takers.
I
think
you
know
right,
yeah,
Hassan
and
Pablo
and
just
some
background.
The
deadline
for
the
slides
was
Saturday
and
surprisingly,
they
send
the
slides
on
Saturday
morning,
but
they
put
a
ETA
one
or
two
that
threw
them
back
to
the
next
day
and
they
won
the
award
for
the
you
know,
note
takers,
so
thank
you,
sir
Thank
You
Pablo.
A
B
A
C
That
would
be
to
do
like
a
quick
check
on
the
mailing
list.
Saying
like
hey
like.
Are
you
interested
in
this
progressing?
And
that
would
be
like
how
things
fine
with
me
too
so
I
don't
mind
sending
a
mail
to
the
mailing
list,
like
that's
fine
with
you,
I'll
just
send
a
note,
saying:
hey
I
interested
in
this
track
progressing
because
I
do
want
to
see
like
a
trail
of
like
people
who
are
interested
in
this
progressing
outside
the
author
said
really,
and
that's
pretty
much
it
so
III
I,
don't
think.
C
Definitions
are
being
done
by
POSIX,
not
by
us,
okay,
so
like
so
another
thing
that
probably
needs
to
get
done
here
is
like
make
it
a
bit
more
Kendrick
in
a
take
out.
The
hash
include
night,
a
night
like
stuff,
and
things
like
that
right,
so
those
things
probably
have
to
get
ironed
out
a
little
bit.
So
Danny
are
you
here,
Danny's.
D
C
So
like
again,
this
has
come
up
as
a
design
pattern
in
multiple
places
which
didn't
work
right.
We
did
the
Miss
API
didn't
get
through
right,
like
PVD,
miss
PVD,
API
didn't
get
through
and
and
so
on,
and
the
one
thing
we
know
like
for
sure
works,
I
think
is
the
gssapi,
so
I
think
we
can
probably
get
inspired
by
that.
Like
that's
kind.
A
Fair
I
think
I
agree
with
what
you
said
so
rich
only
thing
I
want
to
be
little
bit
sensitive
is
the
amount
of
time
the
authors
have
invested,
because
you
know
I
think
there
is
this,
because
it's
so
late
in
the
game.
I
want
to
be
little
bit
sensitive
on
that
aspect,
because
there's
a
element
of
frustration
that
I
think
we
should
address
it
properly.
Yeah.
C
Suresh
again
so
III
think
that's
a
fair
point
right
and
I
really
think
we
should
I
know
this
thing
came
during
the
chair
transition
so
like
I,
think
it's
kind
of
slipped
in
between,
but
our
really
expected,
like
this
decision
to
be
done
like
much
further
ahead,
I
think
in
December
2016.
So
this
document
was
working
group
last
called
in
December
26
ice.
A
Yeah,
definitely
on
the
socket
thing,
even
normally
on
a
good
day.
I
would
definitely
I.
Don't
have
progressed
this,
but
it's
it's
not
my
decision
yet
so
I
think
yeah.
We
have
a
way
forward
on
that.
Let's
see
how
those
discussions
come
now
next
going
to
the
deployment
models.
This
is
one
you
know.
I.
Think
I
was
one
of
the
co-author
on
this,
but
for
you
know
this
came
would
much
earlier,
but
we
are
not
seeing
much
value
in
this
and
I
mentioned
in
IETF
one
or
two
and
I.
A
Don't
think
it
brings
any
value
to
the
industry
or
to
anybody
at
this
point
to
progress
the
document.
So
therefore,
as
author
and
also
the
chair,
I
thought,
you
know,
withdrawal
is
the
right
thing.
I've
notified
the
quarter
and
I
think
this
was
also
notified
in
the
previous
idea,
but
just
to
be,
you
know
for
the
process
to
be
completed,
we'll
close
it
formally
and
we'll
remove
now.
The
next
one
is
services
for
mobile
user
I.
Think
good
work
is
going
in,
but
again
a
couple
of
things
I
think
two
things
haven't.
A
The
discussions
are
still
light.
Maybe
maybe
it's
still
more
reviews
are
needed.
That
is
one
thing.
I
think
the
I
think
offline
conversation.
Authors
wanted
to
include
end
marker
support,
but
I
think
for
to
eliminate
any
feature
creep
on
this
I
want
to
be
extremely
careful
here.
Not
to
you
know.
We
are
okay
with
the
additional
documents,
but
not
wrote
this
document,
but
that's
my
view,
but
you
should
take
yeah
so.
B
A
Because
n
marker
has
so
many
configurations
like
as
big
easy
as
gateway
relegation.
You
know
all
of
these
modes
to
complete
that
this
is
impossible
to
capture
in
this
document.
So
I
think
that's
one
thing,
but
in
general,
subtle
is
on.
When
do
you
think
we'll
be
able
to
I
know
your
presentation,
but
just
quick
word:
what
is
the
timeline
looking
light
because
you
know
for
closing
this
work.
B
I
don't
mention
later,
but
let
me
say
a
little
bit:
I
think
they
all
be
almost
done.
I
mean
main
part,
so
I
think
we
need
to
improve
the
clarity
and
readability.
C
As
a
dino,
it
doesn't
need
to
run
through,
but
I
think
we'll
get
a
routing
director
to
review
at
some
point
in
the
process,
but
I
kind
of
want,
like
a
little
bit
more
review
in
the
working
group,
so
I
think
he'll
be
good.
Sorry,
if
we
can
take
some
names
of
people
today
like
like
you
know,
you
go
to
last
column,
okay,.
A
H
G
A
G
A
I
think
the
FPC
we
will
talk
about
this
I
think
I.
Think
in
general,
authors
believe
it's
in
a
complicated
state,
but
we'll
talk
about
it
and
finally,
the
anchoring
I
think
that's
also
I
think
Carlos
rewrite,
but
pretty
much.
You
know
I
think
at
least
the
document
looks
much
much
much
better
than
before,
but
still
it
needs
more
reviews,
I.
Think.
J
K
B
H
B
B
If
the
mapped
a
seat
and
puts
our
policy
include
one
more
one
or
more
si
D
in
the
reserve
policy,
so
the
third
it
we
added
new
terminology
section
for
abbreviation
and
the
convention,
so
that
makes
people
help
to
understand
and
to
Barry,
SR,
basic,
specific
terminology
and
convention,
so
rusting
the
we
added
new
terminal
detection
for
predefined
a
service
function.
So
it's
also
helpful
to
the
people
not
aware
of
the
service
externally
any
function
so
that
come
from
the
screening
document.
B
So
this
is
a
brief
snapshot
of
the
argument
of
the
art
Mobb
session
format.
It
is
a
40-bit
argument
that
we,
you
can
see
the
qfi
in
in
the
raft
and
the
one
bit
is
read
out
and
another
bit
is
in
decay.
I'm.
Sorry,
one
bit
indicate
rqi
one
bit
in
bit:
seven,
it's
undefined
and
the
best
sagittal
bit
is
to
indicate
video
session
in
the
seeds
poppy
context
it
it
it
could
be
filled
by
tid.
B
B
So
next
step
we
need
to
extend
function
coverage,
but
other
I
talked
before
the
end.
Marker
will
be
good
to
describe
in
another
document
and
the
some
ID
or
the
exist
using
orbit
in
decelerator,
or
we
have
a
indicator
of
the
SL
in
the
marker
or
other
gtp.
You
related
methyl
message
in
the
seat
and
the
other
is.
B
It
will
be
nice
to
her,
but
if
we
can
it'll
be
good,
if
you
have
another
concise
an
example
of
how
to
use
your
ideas,
our
basics,
it
to
the
required
user
plan
function,
but
I
don't
think
it'll
be
necessary
to
be
in
the
document.
So
so
we
did
certain
improvement
in
terms
of
clarity
and
readability.
Thank
you
for
Chari
and
but
I
think
we
need
more
review
from
the
working
groups,
so
they
won.
Was
it
one
of
them?
It's
the
anchor
anchoring
clarification
pointed
out
by
canoe
and
other
would
be
have
another
mod
opinion.
D
You
had
the
qf
ID,
so
you
can
know
how
to
handle
the
flow
and
then
there's
a
special
meaning
to
the
are
bit
that
has
to
do
with
whether
or
not
you
can
infer
by
directionality
for
the
flow
well.
That
kind
of
stuff
is
not
obvious
to
people.
Reading
this
document
and
I
found
out
about
it,
was
about
plowing
through
some
3gpp
stuff
that
wasn't
cited,
and
so
that's
not
a
good
situation
and
I
think
it
would
be
at
least
more
expedient
if
we
could
find
a
name
for
this.
B
A
L
This
is
Ken
Theresa
from
to
tidy,
see
what
say
you
name
again,
please
Kentaro
can
Teresa.
Thank
you.
No
actually
I
have
to
comment
and
I
sent
two
of
them
to
the
mailing
list
this
week.
One
is
that
I
think
we're
trying
to
implement
I
found
that
sue
decoding
for
and
m
GT
p
4e
is
either
inaccurate
or
or
hard
to
understand
and
actually
I
sent
the
one
which
I
think
correct.
L
So
if
you
could
review
it
and
update,
if
is
inaccurate,
and
one
more
comment
is
that
about
T
dot,
n
dot,
T
mass
name,
this
dysfunction
is
translating
my
db4
GT
in
place,
every
six,
which
corresponds
to
end
mg,
T,
P,
six
dot
d
for
ipv6
GTP
and,
if
I'm
not
sure,
if
there's
any
reason,
you
did
not
put
gtp
in
the
name.
But
if
there
is
no
reason,
then
I
I
would
suggest
that
with
gtp
in
the
name
to
qualify
that
this
is
about
GTP
and
not
other
type
of
tunnel.
A
C
One
of
the
things
I
was
concerned
about
is
the
SRH
insertion
stuff
in
the
in
the
draft.
It's
like
you
know.
We
had
this
really
long.
Conversation
in
six-man
and
I
really
don't
want
this
to
draft
to
get
ahead
on
that.
Okay,
so
I
have
a
couple
of
ways
to
resolve
this
okay,
so
one
of
them
is
put
the
header
insertion
as
a
precondition
for
this
to
go
forward.
There's
a
graph
about
Harry
insertion,
which
is
the
draft
wire
header
insertion
right,
but.
E
C
Alice
we
know
how
to
do
this
properly.
I
cannot
progress
this
draft
okay,
so,
as
I
said
couple
of
ways
forward
like
either
keep
it
out
and
add
it
in
later
and
when
that
other
thing
happens
or
just
like
I'll
take
care
of
the
dependencies
myself.
So
you
keep
this
and
let
this
go
on.
But
I
want
a
reference
to
graph
wire
in
this,
because
this
draft
does
not
have
a
reference
to
draw
fire.
Okay,
so
just
add
that
and
then
I'll
keep
track
of
the
dependencies
myself
and
the
other
thing
is
like
you
know.
C
This
thing
has
a
strong
dependency
on
on
SR
v6
itself.
That's
one
thing
and
it
has
a
dependency
on
draft
fizz,
fizz
network
programming,
which
is
not
even
a
working
group
draft
anywhere.
So
there's
like
quite
a
bit
of
dependencies
that
are
required,
so
I'm
I'm,
a
bit
worried
like,
but
buddy
Oh
with
the
what
I
wanted
to
say
is
when
you
are
ready
push
it
don't
wait
for
the
other
things
to
happen.
I'll
make
sure
the
other
things
happen
before
this
progresses.
Further.
Okay,
yeah.
A
C
B
A
A
A
G
Okay,
so
hi
everyone
in
California
and
I
will
quickly
review
the
state
of
this
with
the
mobility
and
Korean
draft.
So
the
status
of
the
draft
well
has
been
significantly
updated
in
London.
That
was
the
main,
the
main
change
for
a
while
and
as
I
mentioned
there
and
as
I
mentioned
in
Montreal,
we
came
from
46
pages
to
15,
and
now
we
are
in
C
in
17
pages.
So
we
tried
to
reduce
complexity
and
try
to
make
the
comment
simpler,
because
also
the
cost
of
the
documents
were
not
that
complex.
H
G
Was
about
introducing
the
distributed
and
Korean
concept
so
then
in
Montreal
we
got
or
after
month,
well
PDI
after
months
are
pretty
soon
after
mantra.
We
got
a
detailed
review
by
Lyle
thanks
for
that,
and
we
address
the
comments
at
of
that
review
now,
so
it
will
summarize
later
well
the
dreyfuses
available
on
github,
for
anyone
of
you
wanna,
take
a
look
and
also
contribute
there.
So
this
is
the
overview
of
the
current
version.
G
So,
basically,
as
I
mentioned,
we
try
to
simplify
a
lot
the
content
and
now
it's
basically
everything
around
this
describing
the
three
main
cases
for
the
for
the
encoding,
which
are
the
know,
Mary
case
the
Mobility
case
with
traffic
regulation
and
the
mobility
case
with
uncle
revocation,
which
is
what
I
summarized
on
this
slide.
So,
basically
in
a
mini
cases
where
there
is
no
others,
continuity
require.
So
basically,
when
you
move,
you
change
your
IP
address
and
that's
all
we
have
to
Mobility
cases.
One
is
the
traffic
redirection
case.
G
Well,
basically,
you
need
other
continuity
I'm.
Basically,
the
way
you
achieve
that
is
by
getting
or
by
getting
by
getting
the
traffic
from
the
previous
anchor
forwarded
to
the
current
anchor
and
then
there
is-
and
you
keep
using
the
the
ol
IP
address,
of
course,
and
then
there
is
this
additional
case.
We
see
colon
quarry
location
where
you
require
a
discontinuity,
but
then
you
have
real
mobility
of
anchors
and
it's
a
bit
more
complex,
of
course.
G
So
the
three
cases
are
documented,
with
some
general
diagrams
trying
to
use
simple
notation
and
because
the
first
version
were
a
bit
heavy
on
on
on
the
notation
I
was
hard
to
follow
so
next
steps.
We
believe
that
the
document
is
table
has
gone
through
several
detail.
Reviews,
including
the
the
one
from
line
in
the
last
site,
colon
and
the
one
from
Marco
before
I,
was
very
helpful
to
try
to
simplify
the
the
document.
This
document
has
been
there
for
a
long
time,
so
I
honestly
believe
that
is
the
moment
to
make
it
go
forward.
G
A
G
But
that's
that
was
in
in
London,
so
we've
been
already
a
couple
of
reviews
from
people
that
that
computer
right
so
I
think
now
is
it's
simple
to
read.
It
should
be
I
mean
it's
a
very
simple
document.
No,
no
high
expectations
of
what
are
these
documents
about
and
I
think
that
the
energy
is
going
in
the
room
to
other
topics.
So
if
we
keep
this
thing
there
for
a
while,
you
will
probably
I
mean
okay.
So
that's
my
main
concern
sure.
A
A
A
So
again,
for
this
document
we
need
some
reviews
and
I.
Think
folks,
can
you
please
volunteer?
We
need
help
from
the
working
group,
otherwise
we
cannot
produce
documents.
This
is
you
know,
I
think
we
depend
on
the
community,
so
Charlie
Perkins
and
John
John
and
any
we
need
one
more
review.
Please
at
least
Marco.
A
G
G
So
this
is
the
status
and
story
of
the
drug
he
was
allotted
working
with
document
after
London
in
the
0-1
version.
We
address
all
the
comments
that
we
received
early
in
the
working
coop
adoption
call
then
in
the
0-2
version
that
already
happened
since
Montreal,
we
address
a
Lisle
detail
review
and
then
in
Silla
three
version,
which
is
the
current
one.
We
also
addressed
the
Danny's
comments.
I
will
summarize
the
comment
that
we
reviewed
in
a
next
slide
so
quick
overview.
So
the
document
is
about
a
network
based
solution
for
DMM
based
on
team
EEP.
G
So
basically
we
push
the
mobility
management
to
the
to
the
edge
at
the
access
router
level.
So,
instead
of
having
one
single
anchor,
we
have
multiple
anchors
for
the
data
plane
and
we
have
a
one
control
plane
entity.
So
we
have
centralized
control
plane,
which
kind
of
anime
that
is
called
C
and
D
and
then
I
through
the
data
plane.
So
it's
accident
router,
where
the
movie
not
can
attach
to
become
a
Mac
from
the
data
playing
point
of
view
on
us
as
an
LMA.
G
For
the
end
point
of
view
for
the
addresses
that
that
passes,
router
delegates
to
the
to
the
momo
a
note,
it's
time
it
attached
to
one
of
these,
these
root
identities,
it
will
obtain
an
IP
prefix
from
that
anchor
and
it
will
remain
getting
continuity
for
the
other
addresses
that
it
got
on
previous
access
router.
So
that's
why
this
is
routed.
Entities
play
the
role
of
Mac
and
LM
a
for
the
data
play
okay.
G
So
it's
seen
you
since
last
IDF.
So
in
C
wrote
two
versions
that
was
basically
addressing
live
comments.
We
improve
terminology
based
on
his
review.
We
added
a
lot
of
text
on
the
registration.
That
was
something
that
we
even
focused
much
or
enough
on
the
previous
version,
and
we
also
had
a
lot
of
clarifying
text,
the
Encino
3
version
that
was
also
based
on
a
detail
review
from
Danny.
We
also
did
a
lot
of
text
improvement
based
on
the
suggestions
from
Danny.
G
G
So
again,
we
we
believe
that
I
recommend
is
a
stable.
Of
course
we
will
appreciate
more
reviews,
but
at
this
point
we,
as
from
the
author's
point
of
view,
we
really
need
to
get
those
reviews,
because
we
don't
believe
there
is
anything
else
we
may
need
to
be
done,
but
to
of
course
address
any
review
that
we
we
make
it
ok.
G
Implementation
status:
well,
we
have
on
implementations
for
quite
a
long
time
ago
because
we
actually
shown
that
implementation
twice
in
ITF
like
four
or
five
years
ago.
I,
don't
remember
so
implementation.
There
is
implementation
available
and
we
actually
show
it
there.
I,
don't
remember
in
which
I
TFS
was
in
battle
in
2014.
That
was
one
of
it
and
the
other
one
I,
don't
remember
so.
There
is
code
available
and
recent
publicly
available
on
github.
So
it's
not
I
mean
it's
a
public
implementation.
If
people
wanna
try
is
available.
A
A
A
M
M
A
N
As
can
we
go
to
the
next
slide,
please,
the
the
effort
was
was
put
together,
but
the
park
was
to
put
together
as
an
effort
by
a
few
people
around
here.
Change
and
Pablo
helped
a
lot
to
provide
the
base
code
for
this
and
change
and
provide
the
actually
implementation
of
the
rest
of
the
codes
that
we
put
together.
I
put
the
setup
together
and
during
London
and
Montreal
I
showed
you
the
the
progression
from
from
existing
gtp
based
system,
20s
or
v6
based
system.
N
N
Yes,
so
this
is,
this
is
what
we're
gonna
cover,
so
the
the
starting
point
for
us
is
basically
a
set
of
s
are
the
six
gateways
and
the
reason
we
chose
this
approach
is
to
show
that
we
can
actually
drop
the
S
or
B
6
data
plan
in
in
place
of
gtp,
without
changing
the
the
control
point
3gpp
control
plane.
So
this
is
cool.
N
This
goes
back
to
the
mandate
that
3gpp
put
forward
city
for
in
3gpp,
build
forward
for
us
to
only
touch
the
the
data
plane
and
and
the
control
plane
was
out
of
the
scope.
Based
on
that,
we
picked
up
this
approach
to
show
that
we
can
actually
use
SR,
b6
and
smoothly
migrate.
The
exist
in
GDP
based
user
plane
to
SRB
six
based
user
play
next.
Please
next.
N
So
I'm
gonna
talk
about
like
this
is
this
is
how
things
are
gonna
work
in
in
the
5g
I.
Don't
have
a
5g
set
up
just
yet,
but
if
this
was
supposed
to
be
done
in
the
5g
network,
we
have
an
s
MF
out
there
that
we're
gonna
be
using
with
the
end
for
interface,
to
connect
to
you
PF
s
and
then
we're
gonna
drop
to
s.
Our
v6
gateway
right
in
the
middle.
N
So
the
idea
is
basically
to
pick
up
the
the
gtp
packet
as
they
come
in
and
pick
up
the
source
address,
destination
address
and
the
gtp
tunnel
ID
and
pack
them
into
the
into
the
interstate
and
since
in
this
particular
scenario,
and
perhaps
for
for
a
long
while
we're
gonna
have
to
deal
only
with
two
UPF.
Therefore,
we
will
simply
using
the
RP
v
six
destination
address
as
our
CID
to
send
this
information
across
the
across
the
network.
N
Once
we
get
the
the
packet
on
SR
gateway,
then
we
we
pick
up
the
destination
address
we
decoded
into
into
it's
original
gtp
format
and
shape
it
to
the
to
the
UPF
for
processing.
So
the
UPS
in
this
scenario
will
basically
do
not
know
that
there
is.
There
is
any
GS
or
v6
in
the
middle.
The
the
control
plane
in
3gpp
remains
intact,
and
this
is
simply
changing
the
data
plane
without
the
control
plane
to
satisfy
3gpp
requirements.
Next,
please.
N
So
the
idea
basically
applies
to
today
LTE
network
as
well,
and
this
is
what
we
used
in
our
proof
of
concept.
You
have
an
even
would
be,
and
we
got
a
combined
SP
GW
and
that's
the
link
that
we
are
showing.
It
is,
of
course,
is
entry
that
I'm
showing
not
the
N
and
nine.
The
reason
for
this
is
because
we
are
using
open
source
software
that
combines
the
SVG
WI
needed,
and
you
don't
want
to
spend
too
much
time.
N
Decoupling,
the
the
service
gate
day
from
the
packet
gateway
and
and
that's
why
we
be
trying
to
show
the
same
work
on
the
entry
interface,
which
is
also
applicable
easily
to
2n9
again
the
same
idea.
The
gtp
tunnel
extends
from
a
node
B
to
SVG
W,
and
we
do
the
same
type
of
decoding
as
we
did
in
five
gene
in
in
4G
LTE
network.
To
accomplish
the
work
next
slide,
please.
N
So
this
is
the.
This
is
the
setup
that
we
are
using.
We
are
using
way
I
open
source
software,
along
with
VPP
modified
version
of
the
BPS,
our
v6
code.
There
is
a
USRP
SSB
200,
the
phone
that
is
connected
to
the
to
the
system.
We
got
a
couple
of
war
shark.
The
points
that
actually
to
to
show
the
packet
trace
to
actually
show
the
conversion
that
happens
right
after
the
e
node
B
and
right
before
the
the
packets
enter
the
the
second
second
routing
gateway.
N
You
recall
born
as
our
gateway,
a
VirtualBox
as
our
second
gateway
and
the
the
second
VM.
The
third
server
is
a
combination
of
service,
gated
packet
gateway,
Mme
and
HSS.
This
is
the
bundle
that
we
got
from
it
and
I
I
have
a
more
elaborate
version
of
this
thing
in
my
lab.
But
if
you
didn't
want
to
muck
around
with
the
oh
I
saw
for
packaging
and
we
basically
took
it
as
it
was
again.
N
N
N
You
see
that
you
know
the
practice
information
into
the
into
the
said
we
got
the
source
address
destination
address
and
the
TU
ID
pack
into
the
state,
along
with
an
IP
prefix
that
that
that
is
at
the
beginning
of
the
city,
coming
out
of
the
coming
out
of
the
service
as
well
gateway
to
at
the
beginning
of
the
entering
the
this
packet
gateway
that
the
packet
has
been
returned
to
to
his
gtp
format,
and
we
process
the
packet
at
the
UPF
as
if
nothing
really
happened.
So
the
UPF.
N
The
idea
is
that
the
ups
will
not
see
any
any
control
plane
changes
next
slide.
Please-
and
this
is
the
this-
is
the
reverse
traffic
coming
out
from
the
SP
GW
go
into
the
enol
P,
as
you
can
see,
we're
just
doing
the
exact
opposite.
The
T
or
ID.
Here
is
a
bit
more
elaborate
because,
as
I
said,
the
UI
software
basically
randomizes
the
te
o
ID
on
an
away
from
several
Skateway
to
2
e
note
e
and
but
the
process
is
identical.
N
We
basically
sent
the
GT
packet
to
2
s
or
gate
number
2,
where
it
basically
gets
packed
into
the
CID
and
ship
to
the
he
no
would
be,
but
you
taught
me
guess:
lien
would
be.
On
the
other
side.
The
packet
basically
has
been
modified
to
his
gtp
format
by
the
SR
gateway.
One
and
the
inner
would
be
basically
receives
a
gtp
GT,
the
packet,
so
I
believe
Chen
Jian
is
in
the
room.
N
He
probably
you're
right
after
this
is
gonna,
go
and
set
up
the
the
demo
outside
the
room
on
a
desk
or
something
do
you
have
a
compact
version
of
this
demo
that
we
can
actually
show
to
people
who
are
interested
so
I
encourage
people
to
go
and
have
a
look
and
by
all
means,
provide
us
with
comments.
We
need
your
comments
to
actually
go
forward.
The
next
step,
I,
the
next
step
of
this
demo,
will
perhaps
deal
with
a
combined
mixed
ipv6
ipv4
equipments
again,
this
is
the
first
phase
of
migrating.
N
The
aim
of
this
this
park
is
to
show
the
first
phase
of
the
migration
path
from
the
existing
gtp
based
system
to
an
S
or
v6.
The
next
step
would
be
in
showing
that
okay,
so
once
we
have
done
such
as
equipments
will
turn
to
ipv6.
People
perhaps
will
show
a
mix,
ipv6
ipv4
network
and
be
show
how
things
can
actually
interwork
between
the
two
two
domains.
Okay,.
C
I
have
a
couple
of
questions
right.
So
first
one
is
the
ASR
gateway
to
prefix.
So
do
you
assume
that
it's
going
to
be
a
/
32
prefix
because,
like
anything
longer,
will
not
work
right
because
there's
like
32-bit
each
IP
addresses
and
then
32-bit
Eid,
so
you
need
a
/
32
for
every
node
that?
Yes,
yes,.
N
For
this
particular
gtp,
instead
of
working,
we
have
to
actually
set
aside
some
space
for
the
year
for
the
source,
address
destination
address
and
the
tu
ID,
so
the
rest
can
be
basically
did
is,
is
allocated
to
thee
to
the
prefix
which,
which
probably
works
for
for
for
many
of
the
networks
right
now.
Okay,.
C
N
N
Generally
speaking,
the
structure
of
the
city
we
can
suggest
suggest
as
structure
in
our
in
our
in
our
drafts
and
an
IETF
can
actually
propose
that
thing,
but
I
believe
that
at
the
end
is
gonna,
be
3gpp
who's
going
to
decide
us
or
how
this
said.
This
structure
is
going
to
be
done.
So
what
we
do
in
OIT
F
is
suggestions
to
to
3gpp.
It
would
be
probably
changed
once
it
gets
to
see
it.
It
gets
to
be
to
the
3gpp
and
they
will
decide
how
how
to
restructure
these
things.
Okay,.
C
That
is
the
I
think
the
most
important
question.
So
what
happens
if
you
get
a
v6
gtp
packet
like
if
you
have
a
v6
better
on
there,
any
get
a
visa
to
gtp
packet,
yeah.
N
C
N
C
A
N
A
N
C
A
N
That's
why
I
was
always
I
was
alluding
to
the
fact
that
you
know.
Yes,
we
can
actually
suggest
all
sort
of
the
structures
into
the
said,
but
I
would
like
to
actually
when
I
think
when
we
go
to
see
a
city
for
I
want
to
mention
that
they
are
the
one
who
gonna
be
having
the
final
say
in
defining
all
these
structures.
We
are
just
showing
them
the
way
they
will.
They
will
have
the
trans
to
actually
standardize
this.
The
way
they
like
it.
Alright.
I
A
A
A
E
So
let
me
just
so
since,
like
cannot
be
here
just
about
recap
and
the
status,
so
we
went
through
twelve
revisions.
That's
the
version
you
find
on
the
repository
right.
Now
we
put
quite
some
effort
in
making
the
core
part
clear,
which
describes
the
operation
and
information
models
in
the
back.
We
still
have
the
young
model
so
since
why
we
have
Charlie
on
board
who
put
some
effort
in
making
the
core
part
clear,
so
it
doesn't
help.
If
authors
say
it's,
it's
ready
for
working
group
last
course.
E
So
we
want
none
of
us
to
understand,
what's
written
in
the
core
part
and
that's
why
we
need
reviews.
We
got
a
library
view
from
from
Carlos,
for
that
we
need
a
little
bit
more
review
on
a
deep
dive
on
the
information
Marla.
So
if
this
is
understandable
reasonably
so
that
kind
of
feedback
would
help
us
a
lot
to
get
green
light
to
proceed.
E
A
A
E
A
Should
be
separated
out
or
would
that
help
in
reviews
or
I'm
trying
to
see
because
anytime,
you
know
it's
hard
to
get
reviewer
commitment
or
a
hundred
page
document
I
think
that's
that's
a
fact.
Right,
I
think
it
is
a
big
document
right
I'm,
just
thinking
to
really
you
know,
for
the
time
being,
is
it
okay
to
break
that,
remove
the
yang
stuff
and
maybe.
E
E
A
C
C
I
read
it
and
it
is
much
bigger
too,
but
III
do
think
it's
gonna
be
challenging
in
in
ITF
when
it
goes
iesg
because,
like
Roger,
the
document,
the
larger
the
attack
surface
and
like
more
comments,
people
are
going
to
have
and
III
don't
have
a
good
suggestion
of
trimming
it
down.
Like
you
know,
nobody
like
she
said.
Maybe
it
is.
This
is
something
you
can
discuss
like
with
something
and
probably
like.
Then
that's
Bret's
out
the
expertise
that
somebody
requires,
but
that's
also
a
negative
thing.
C
If
you
split
it
out,
the
other
person
has
to
still
read
the
Nanyang
part
anyway
to
understand
the
yang
part
right
so
I'm
pretty
neutral
on
this.
So
if
you
want
to
keep
this
together
or
not,
but
IIIi
personally,
don't
see
any
major
issues
in
the
document.
Other
than
it
not
getting
review,
that's
like
what
worries
me.
I
will
try
to
get
another
review
outside
the
working
group.
C
A
M
C
It's
really
like
you
know
it's
not
like
useful,
but
maybe
I
can
push
like
a
yang
doctor
review
or
something
at
least
for
that
part
right,
that's
something
we
can
probably
try
to
shoot
for
so
that
that
part
gets
done,
but
even
the
yang
doctor
has
to
read
the
rest
of
the
document.
So
it's
not
that
they
just
check
the
yang
model
right
because
they
need
to
understand,
but.
C
We
seen
this.
This
is
like
a
common
design
pattern.
Like
you
know,
we
saw
l2s
em
right.
There's
a
document.
People
are
just
tired
of
the
whole
working
group
was
tired
and
they
just
managed
to
just
get
this
past
the
finish
line
and
died
right.
That
kind
of
level
of
thing
which
was
like
in
150
something
plus
page
document
right
so
I
just
I,
want
the
wasn't,
keep
going
but
like
I
want
like
people
to
review
it.
E
D
That
could
then
be
shown
how
the
information
model
is
applicable
to
PMF
and
3gpp
architectures.
Just
the
fact
that
the
information
model
encompasses
both
of
those
shows
the
power
of
it
and
also
the
well
first
I
said
I
mean
somebody
might
only
be
interested
in
the
Pima
model
for
the
yank
stuff,
or
only
be
interested
in
the
3gpp
part,
but
anytime
I'm.
A
C
Like
that's
kind
of
the
issue
right
like
so
Suresh
again,
so
somebody
could
easily
consider
it
the
other
way
saying
the
yang
is
more
precise,
so
it
should
be
the
final
definition.
That's
what
I'm
saying
that's
something
to
be
considered
too,
like
I'm
not
taking
a
position
one
way
or
another,
but
that's
something
that
wouldn't
give
me
set
aside.
A
O
K
O
So,
firstly,
I
will
explain
the
background
of
this
book,
so
this
work
is
related
to
user
plane.
Protocol
study
in
CT,
PP
64
and
this
is
became
reasonably
part
of
the
eternal
apply
from
diem,
am
working
loop
to
CPP
64,
and
this
document
has
mainly
too
much
patience.
First
is
a
unifying
understanding.
Level
of
IDF
to
specifications
and
an
architecture
of
CCP
5g
system
and
secondary
is
a
showing
to
be
showing
it
to
CPP.
O
O
O
Major
updates
are
listed
in
the
following
two
slides,
so
in
the
first
division
we
modified
mainly
modified
GPU
observation
based
on
the
feedback
from
CCP
PCT
for
LS
out.
So,
for
example,
gtp.
You
is
basically
a
point-to-point
tunneling
protocol,
but
some
implementation
will
be
have
as
much
point-to-point
protocol
tunneling
protocol.
Well,
there
are
no
definition
about
the
order
of
extension
header,
but
the
specification
document
describes
a
note
to
recommend
putting
qfi
information
at
the
first
extension
header,
and
we
describe
the
note
in
the
document
in
the
second
division.
O
We
leave
little
bit
feedback
on
the
discussion
on
email
list,
a
mailing
list.
So,
for
example,
we
received
a
question
about
termination
point
of
gtp
you,
so
we
describe
a
concrete
description
about
the
termination
point
of
gtp
you
did.
Bill
is
used
on
industry
interface
between
Gino
to
PDF
and
90s
between
different
ups.
O
So
we
have
this.
Drive
has
adapted.
This
update
are
provided
at
second
division,
so
version
number
should
be
zero.
Please
note
that
and
in
the
second
division,
so
we
provided
supplementary
explanation.
For
example
regarding
IP
connectivity,
we
describe
that
in
terms
of
wide
coverage.
Ipv6
would
be
better
and
we
should
consider
how
to
interconnect
with
legacy.
O
We
received
point
that
there
are
no
summary
about
the
texturizing
architecture
and
we
added
the
overview
of
network.
Stressing
architecture
is
EPP.
Epp
rice
is
composed
of
fundamentally
composed
of
SMF
rounds
ups
and
the
DNS,
but
CBP
focuses
on
just
only
mobility
management,
also
transport
network
or
other
external
network,
otoscope
CTP
PD
study.
O
So
finally,
I
talk
about
status
and
in
states,
so
we
caught
up
feedback
from
both
IDF
and
CCP,
and
these
we
bleep
that
we
received
enough
feedback
and
we
would
like
to
request
working
group
adoption
of
this
document
and
it's
just
question.
I
would
like
to
confirm
whether
this
document
can
be
information
RFC.
If
so,
we
can
polish
this
document
at
this
contents
more
right.
C
So
the
one
like
I'm
finding
it
like
you
know
adopting
this
if
needed,
but
I
just
don't
have
a
visibility
into
what's
happening
in
3gpp
regarding
this,
so
I
kind
of
want
some
kind
of
official
communication.
So
if
status
on
is
there
or
if
you
are
there,
probably
like
you
know,
get
another
LS
out
from
there
and
probably
get
it
down
the
dependency
list,
because
if
3gpp
is
going
to
make
a
decision
based
on
this
I
want
to
see
it
on
the
dependency
list.
C
M
P
My
the
3gpp
years
and
you
adding
this
to
the
study,
will
not
help
you
for
dependencies
because
the
dependencies
are
only
for
normative
specifications.
H
P
So
I
mean
it,
it
doesn't
put
any
pressure
from
sweetie
psi
to
ITF
to
progress
this
work
as
long
practically
as
long
city
for
hasn't
taken
a
decision
which
way
to
go
so,
on
the
other
hand,
of
course,
I
have
to
be
careful
how
to
phrase
it,
but
I
think
there
are
some.
There
are
some
people
in
City
for
that
sometimes
doubtful
how
far
the
work
in
ITF
in
general
has
progressed.
So
everything
that
gets
working
group
adopted
and
sort
of
gets
gets
the
indication
that
you're
working
on
that
and
you're
progressing.
P
A
C
So
if
I
understand
okay,
so
now,
I
have
a
better
view
after
like
Garrick
spoke
right,
so
then
I
have
a
different
issue
right.
So
if
the
only
use
for
this
document
is
to
guide
the
study
item,
what
is
the
archival
value
of
this
document
in
the
RFC
series?
Right,
because
once
the
3gpp
study
item
is
done,
then
3gpp
just
moves
on
right,
so
who's
document
use
fallar
in
India
ATF.
So
that
is
like
the
second
question
we
can.
C
We
can
do
this
all
during
the
mailing
list,
discussion
right,
but
that
would
be
my
question
so
if
it
doesn't
have
value
by
itself
to
guide
3gpp
and
3gpp
is
not
waiting
on
it
and
they're
doing
their
own
evaluation,
then
I
don't
see
the
value
in
publishing.
This
I
really
see
the
value
of
this
document,
but
not
publishing
in
Taurasi.
So
keep
the
document
up.
Data
like
we
can
even
are
out
to
test
a
button
right
and
keep
it
going.
But
then,
after
the
decision
is
made,
we
just
drop
it
right.
C
Understand
but
there's
a
difference:
okay,
so
the
documents
she
is
talking
about
is
I.
Think
33,
RFC,
33:14,
okay,
3gpp
asked
us
okay.
What
is
the
prefix
length
you
want
to
recommend
clear
question.
We
give
them
an
answer
at
64.
This
one
3gpp
didn't
come
and
ask
us
hey?
Can
you
recommend
as
a
protocol
if
they
did,
that
would
be
a
different
reference.
Like
Garak
said.
Okay,
so
3gpp
is
doing
an
independent
evaluation.
They're
not
asking
us
to
do
an
evaluation
so
do.
A
C
But
3pp
is
making
the
decision
in
the
study
item
right,
so
I'm
not
I'm,
something.
This
is
very,
very
valuable.
I
don't
have
a
question
in
that,
but
if
the
decision
is
going
to
be
made
in
a
3gpp
study
item
it
respect
your
what
we
write
here
right
then
I
don't
see
the
value,
that's
what
I'm
trying
to
say.
A
I
think
if
you
go
back
to
the
LS
statements
that
we
have
received
from
3gpp
so
far,
they
all
talked
about
their
work
item.
That's
the
study.
That's
happening
there
in
general.
They
reckon
courage,
etf,
to
make
progress
on
on
these
work
items
so,
based
on
that,
I
think
we
need
to
make
a
call
whether
this
kind
of
work
has
value
or
the
should
I
eat.
Is
it
just
a
publishing
and.
A
C
What
you
can
decide
like
I'm,
not
gonna,
stop
the
wooden
boy
from
deciding,
but
I
do
see
like
a
hard
time,
testifying
a
publication
of
an
RFC
for
this,
especially
since
it
has
no
archival
value.
So,
like
one
of
the
things,
if
you
look
at
like
let's
say
the
last
six
tele
chats
right,
there's
a
lot
of
documents
that
have
been
sent
back
to
working
groups
because
they
don't
have
archival
value
now
that
it
doesn't
have
value.
C
So
one
of
them
running
an
sctp
document
right,
which
contains
probably
like
five
years
of
work
of
like
things
like
clarifications
and
errors
that
have
been
discovered
that
got
sent
back
to
TS
vwg
recently,
because
people
didn't
see
the
archival
value
of
it
so
like
who
so,
who
will
read
this
document
in
five
years?
That's
the
thinking
right
period,
I'm,
not
gonna,
say
anything
more.
B
Certificate
on
I'm
gonna,
put
up
the
city,
philosophy
and
I
think
the
the
document
really
berry
welcome
for
us
and
because
he
we
already
have
input
from
an
IETF
side.
So
the
the
all
of
the
idea
of
the
use
of
all.
So
that's,
that's
a
be
sure
the
wizard.
The
IDF
is
aware
of
the
CPP
act
so
that
the
sukima
show
the
good
ribbit-ribbit
understands
that
good.
But
after
that,
I
think
would
be
valuable
if
the
this
document
could
be
good
difference
to
introduce.
B
P
That's
my
that's.
The
only
concern
I
have
is
this
paper.
I
think
you,
you
cannot
assume
that
3gpp
will
reference
it
and
you
you
cannot
assume
that
we
will
review
it
right.
So
any
content
will
be
your
content.
It
will
not
imply
any
changes
in
our
architecture
it
it
might
be
used
as
a
guidance
that
is
fine,
but
I
agree
in
that
sense.
We
suresh
that
the
guidance
will
mostly
come
from
the
study
we
are
currently
doing
in
CT.
P
For
again,
the
CT
for
study
is
not
the
whole
business
once
if
CT
for
agrees
on
something
that
doesn't
mean
we
will
adopt
it,
there
needs
to
be
other
working
groups
included
in
this
discussion
and
so
on,
but
it
you
have
a
good
chance,
then.
So,
if
this
document
is
valuable
for
your
own
purposes,
then
I
think
you
should
go
forward
with
it
and
you
should
show
that
by
some
way
of
adoption
or
whatever
I'm
not
so
familiar
in
detail.
H
P
A
P
No
I
first,
let's
say
would,
would
anybody
raise
an
eyebrow?
Let's
say
it
right,
we
will
not
and
I
I,
don't
I,
don't
think
so.
I
mean
it's
practically
you
doing
here
what
we
are
doing
in
our
study,
so
yeah
fine
go
ahead
and
you
you
need
to
notice
if
it
if
it
in
the
end
should
be
an
RFC,
that's
well,
that's
you
have
set
aside.
P
C
M
I
C
Gonna
like
talk
something
to
Satoru
son,
okay,
so
imagine
I'm,
giving
you
like
a
completely
crazy
alternative
scenario.
Okay,
so
working
group
works
on
this
adopts
the
document
finishes
at
the
dock
man.
She
doesn't
work
in
a
class
call
everybody's
happy
with
it.
Okay
and
then
we
take
the
texture
of
this
document.
Put
it
in
a
layer
since
statements,
n83,
gbb,
okay,
that's
option
a
other
thing.
Is
we
go
through
the
RSC
publication
process?
Seven
months
later
we
have
an
RFC.
Do
you
see
a
difference
in
value
between
these?
Two?
That's
what
that's
my
question?
C
A
A
Q
Dave
Allen
Eriksen
I'm
confused
here.
All
of
the
discussions
leading
up
to
the
liaison
was
they
asked
us
for
specific
protocols
we
were
working
on.
It
was
agreed
that
we
were
not
going
to
send
them
analysis.
We
have
a
draft
whose
purpose
is
to
attempt
to
say
we
understand
this
well
enough
that
the
analysis
we
provide
is
credible.
We
liaised
it
to
them.
My
understanding
and
based
on
some
of
the
dialogue
I
saw
was
the
A's
back
saying
we
didn't
want
analysis,
but
we
are
persisting
so.
A
A
Q
The
technical
feedback
I'm
kind
of
encountering
this
everywhere,
where
somebody
liaises
asking
a
very
specific
question,
which
typically
is
like
what
can
we
consume
in
the
time
frame
of
we
16
or
whatever
and
everybody's,
sending
them
the
moon
in
response,
and
this
Tomita
seems
to
be
another
example
of
it
I
remember
reading.
Quite
specifically,
they
asked
that
ct4
liaised
here.
What
we
sent
them
back,
I
do
not
believe
begley
correspond
to
it
and
they
called
us
on
it
and
working
we're
persisting
on
going
down
this
path.
I,
don't
think
this
is
a
good
idea.
Okay,.
Q
P
A
bit
it's
it's
a
bit
strange,
you
you're,
mixing
these
two
types
of
works
so
strongly
up
in
your
argumentation,
I
mean
we
have
to
CT
for
work
and
that's
rolling
and
I
I
mean
the
only
way
you
can
interfere
with.
That
is
that
you
make
your
you're
technically
drafts
that
are
under
evaluation,
they're,
more
stable.
That
I
guess
that's
the
unambitious
that
we
might
have
liaison
exchanges
on
on
certain
dedicated
issues
that
that's
one
thing.
But
this
is
your
your
work.
This
is
your
own
working
group,
evaluation
and
so
on.
P
A
Q
Q
A
B
F
A
E
E
Alright,
so
background
and
motivation.
So
far
we
discussed
the
new
data
plan.
Progress
in
the
context
of
the
liaison
and
cd4
and
the
candidates
are
other
tunneling
protocols.
I
do
like
separation
protocol,
it's
locator
rewrite
protocols,
so
these
Broncos
supply
to
the
interface.
That's
what
the
study
is
about.
So
everything
in
between
the
anchor
use,
a
big
function
and
the
extra
data
network
services.
E
Do
we
need
to
repeat
all
right
so
that
that's
what
the
draft
is
about?
So,
in
the
view
of
future
use
of
5g
network
and
in
the
view
of
efficient
support
for
industry,
where
it
goes,
we
see
that
there
may
be
some
demand
for
more
flexible
deployment
options
for
customization
and
also
taking
some
control
on
traffic
steering
and
polishing
on
that
n6
interface.
E
E
On
the
NSX
interface,
in
particular,
on
transport
network
nodes
which
are
associated
with
the
data
networks
and
that's
not
being
discussed
in
3gpp,
so
can
we
adjust
this
one
so
to
previous
cases
just
to
motivate
this?
So
this
is
a
deployment
per
today's
3gpp
directions
and
mobile
applications
may
be
associated
and
take
services
from
distributed.
Applications
in
distributed
data
centers,
so
3gpp
5g
control
plane.
Allow
us
setting
up
multiple
user
plane
function.
E
Anchors,
like
you,
see
here,
to
talk
to
the
different
data
networks,
so
these
UPF
scan
enforced
traffic,
steering
rules
for
uplink
traffic
to
achieve
that.
This
traffic
reaches
the
data
networks
at
on
the
right
way,
but
there
is
no
guarantee
that
downlink
traffic
happens
in
the
same
way,
so
there
may
be
kind
of
misleading
route
taking
the
wrong
UPF
in
case
the
two
n6
paths
are
on
the
shared
links,
so
we
need
some
control
on
the
downlink
routes
inside
the
data
networks
here
to
actually
select
the
most
suitable
UPF
photonic
traffic.
That's
one
case.
E
Just
as
one
example,
one
case
where
we
apply
user
plain
function,
serving
as
a
PD
accession
anchor
to
the
very
edge
of
the
network
and
just
to
support
services
in
the
edge
cloud
here
is
the
connected
car
scenario.
So,
in
addition,
services
running
in
the
central
cloud
use
this
video
session
anchor
on
a
long
distance
and
six
interface,
so
in
case
the
car,
the
user
equipment.
E
In
that
case
moves,
then
maybe
your
relocation
offer
user
plane
anchor,
maybe
also
aligned
with
the
relic
ation
of
the
actual
service,
just
to
keep
the
low
latency
kind
of
agreed
service
levels,
and
in
that
case
in
case
I,
P
address
continuity
and
previous
session
continuity
is
required.
We
need
to
align
the
downlink
routes
in
the
different
data
men
anchors
data
networks,
which
use
this
use
a
plane
function
in
terms
of
the
unyk
traffic
guarding.
E
E
That
we
first
want
to
motivate
this
work
by
use
cases
discussing
the
operation,
then
second
propose
an
architecture
that
basically
closes
the
gap
between
the
policy
enforcement
points
associated
with
the
data
networks
and
provide
an
architecture,
a
function
of
3gpp
as
a
binding
element
between
this
actually
out
of
scope,
data
network
item
and
the
5g
control
plane,
because
these
darling
routes
not
only
raw
as
per
also
Q
s,
whatever
you
need
in
terms
of
bounding
traffic
treatment
policies,
need
to
be
aligned
with
a
five
system.
So
we
need
a
binding
element
here.
E
So
the
draft
is
about
the
architecture:
how
to
bind
the
5g
control
plane
with
a
control
of
the
downlink
policies.
Second,
is
how
to
enforce
these
policies
in
the
transport
network
of
the
Dana
networks,
so
FPC,
maybe
one
candidate
here,
either
discussion
or
specification
or
information
level
or
on
the
data
data
models.
The
third
thing
is
to
see
if
3gpp
can
expose
on
its
control
plane
the
required
attributes
and
semantics
to
allow
us
and
forcing
the
policies
we
need.
So
this
is
something
which
is
treated
orthogonal
to
or
3gpp
does.
E
So
the
semantics
and
the
data
models
for
VPN
traffic
treatment
policies
on
n6
that
should
be
in
scope
of
this
draft.
The
current
draft
is
a
little
bit
focused
on
describing
the
problem,
the
scope.
There
is
not
too
much
on
solution.
We
have
some
architecture
being
proposed
in
sections,
but
more
work
is
required
here.
So
the
summary
we
could
discuss
this
draft
before
posting
with
a
couple
of
people
got
valuable
feedback
like
so
n6
aspects
are
on
the
specified
in
3gpp,
so
it's
treated
as
valuable
work.
E
We
should
clarify
the
works
on
n6
and
now
interference
with
what
3gpp
does
is
intended
here.
If
we
come
up
with
a
few
extensions
in
terms
of
attributes
or
semantics
that
is
required,
we
can
make
a
contribution
to
http.
Here
there
was
a
comment
to
include
the
isometric
route
case,
referring
to,
as
this
text
slide
number
three,
so
that
should
be
in
the
draft
and
highlighted
a
little
bit.
E
Then
there
was
a
question
if
we
should
be
specific
to
the
n6
protocol,
whether
it
should
be
segment
routing
ila,
whatever
kind
of
channeling
approach.
So
here
we
should
be
generic
in
my
opinion
and
just
treat
this
as
a
policy
being
enforced
and
under
control
of
the
control
band
which
protocol
is
being
used.
E
There
was
a
good
point
about
that.
Some
data
networks
will
apply
load
balancers,
so
this
is
not
seen
on
this
line
and
six
between
the
user
plain
function
serving
as
a
PTO
second
anchor
and
the
actual
server
in
the
data
network.
So
there
are
some
considerations
to
consider,
but
I'm
pretty
sure
we
can
easily
handle
that
and
also
yeah.
One
comment
was
actually
supporting
effect
to
decouple
the
anchor
UPF
deployment
from
the
actual
terror
networks.
E
A
B
What
do
you
expect
the
function
to
be
deployed
in
any
six,
because
here
nowadays
at
5g
architecture
that
hub
the
UPF
function
like
a
Porsche
enforcement
and
charging
certain
set
of
the
function
as
defined
already
in
UTS?
So
the
I
don't
much
Korea
about
the
what
functionality
deployed
in
the
m6
in
the
5g
architecture?
Can
you
clarify
that
so.
E
There
may
be
more
so
if
we
decouple
the
UPF
anchor
from
the
data
network
and
move
it
to
the
very
edge,
so
n6
becomes
very
long,
so
we
may
have
to
apply
more
policies
to
that
traffic
like
MPLS
labels
or
AK
us
kind
of
treatment.
So
these
policies
also
need
to
be
enforced
for
downing
traffic
on
the
data
network,
CP
n
DB
n
is
a
heavy-ass
which
can
be
a
provider
at
router.
E
So
we
should
not
be
specific
here,
which
kind
of
data
plane
oak
we
assumed
here,
but
you
should
be
programmable
and
the
policies
come
from
the
control
plane.
So
there
may
be
some
basic
policies
which
we
derive
from
the
use
cases
in
the
document,
and
for
that
we
are
specific,
but
we
should
be
open
same
as
busy
traffic.
Okay,.
B
A
B
Can
you
just
repeat:
I
didn't
at
the
last
point,
so
one
in
the
5g
architecture,
the
fabric
on
fabric
core,
provides
the
interface
to
allow
the
application
to
touch
the
airport.
She
effect
effect
to
the
contour
to
the
user,
presses
the
5g
control
plane,
but
that
couples
come
from
the
optic,
a
application
function,
but
your
proposal,
it
looks,
a
abdication
function,
does
contour
directory
or
the
user
friend.
E
So
we
just
show
this
here
using
the
AF,
which
is
in
the
3gpp
specs
and
most
generic
function,
but
the
interface
between
AF
and
5g
core
is
being
specified
on
3gpp,
so
we
see
AF
as
one
binding
element
between
the
5g
core
and
the
data
plane
policy
control.
The
AF
may
be
associated
with
any
other
controller
like,
for
example,
the
MFA
controller
and
serese--
draft,
or
something
else
right.
So
I'm
not
sure
we
should
be
specific
here,
but
actually
consider
the
two
interfaces
and
work
out
the
details
here.
Okay,
thank
you.
A
John
from
Huawei
I've
talked
to
mark
about
this
quite
a
bit
offline
and
I
just
wanted
to
add
that
in
3gpp,
most
of
the
time
the
UPF
and
the
AF
and
so
on,
are
quite
tightly
coupled
in
some
sense
and
the
architecture
that
Mark
was
exploring.
Here
is
a
little
bit
loose
Lee
couple
where
there
are
really
two
domains
and
then
you
have
to
have
some
way
to
exchange
the
policies
and
make
sure
that
these
two
domains
I
mean
each
of
these
two
domains
are
rich
in
their
own
interaction.
A
C
So,
like
so
part
of
this
has
like
effect
towards
si
and
passive
this
towards
CT.
Is
that
the
goal
like
because
I
I
do
see
both
the
kind
of
things
in
the
draft
right
like
because
you're
trying
to
change
some
architectural
stuff
and
I?
Let
like
you
know,
York
talked
if
he
wants
right,
but
I
do
want
at
least
like
a
clear
separation
of
like
things
like
a
bigger
things.
C
You
want
to
change
and
like
more
like
the
bits
you
want
to
do
because,
like
the
initial
promise
was
like,
this
is
not
like
clearly
defined
right.
So
that's
a
different
thing,
because
we
are
pretty
much
used
quite
a
bit
right
like
we
did
like
twenty
nine
to
seventy
five
like
she
and
I,
whether
to
say:
okay
for
a
stage
three
spec
that
for
something
like
you
know,
VK,
we
we
are
kind
of
used
to
that
mode
of
things,
changing
the
architecture
itself.
C
E
Some
more
brain
cycles
need
to
go
into
here,
but
so
I
could
say
that
interface
between
a
F
and
a
data
plane
and
the
data
network-
that's
not
covered
in
3gpp,
what's
covered-
is
AF
to
PCF
SMF
kind
of
reference
point.
So
that's
something
we
want
to
leverage,
not
change,
maybe
extent
is
required
in
terms
of
UPF
I.
Don't
think
we
break
what
switch,
because
it
does,
but
it's
definitely
assuming
a
different
kind
of
deployment.
So
if
you
deploy
it
in
a
different
way,
I'm
not
sure
if
it
conflicts
with
the
3gpp
specification
of
today.
P
Yeah
and
several
things
on
that
well,
first
of
all,
you
have
to
decide
whether
you
want
to
have
to
censor
each
EVP
or
not
or
but
that's
one
one
path
to
go,
but
that
you
say
well.
This
is
something
we
do
and
our
goal
is
to
have
it
in
3gpp
in
the
end
like
so
HBP
would
reference
it
as
something
to
be
done
or,
if
you
say
well,
we
do
this
and
if
it's
not
appearing
in
a
3gpp
specification,
it's
still
a
solution
via
offering
rights
would
be
standalone.
P
If
you
want
to
have
it
in
3gpp,
you
need
your
agents
in
3gpp.
Now
that
practically
say
we
require
this,
so
you
need
to
start
from
stage
one.
Actually,
somebody
must
has
to
say
there's
a
technical
order
as
a
requirement
to
have
these
functionalities.
Then
this
trickles
down
to
the
architecture
group
that
will
maybe
look
at
your
what
you're
proposing
in
this
paper,
but
practically
they
will
let
us
do
their
study
on
their
own
and
only
then
the
proper
call
groups
get
involved.
So
what
we
have
so
far
is
the
discussion
on
the
n9
interface.
P
There
is
a
replacement
of
an
existing
protocol
that
is
fine
they're
there.
You
can
go
directly
to
the
protocol
group
and
say
look
at
the
pros
and
cons
and
so
on.
But
what
you're
doing
now
is
something
completely
new
and
if
we
want
to,
if
you
want
that,
then
you
really
have
to
go
strictly
by
the
process
that
we
have.
We
don't
take
technical
solutions
for
the
beauty.
We
need
really
people
who
come
and
say
and
put
pressure
on
us
and
say
there's
a
requirement,
so
you
need
companies
in
3gpp
that
pushed
it
so.
A
P
So
you
need,
you
need
to
have
a
high
level
requirement
from
a
users
or
network
providers
perspective
that
you
can
formulate
without
your
your
language
of
interfaces
and
so
on,
where
you
practically
just
say
that
there
is
a
requirement
or
there
are
several
requirements
and
those
will
be
discussed
in
essay
1
and
that
might
take
a
time
they
have
their
own
style
of
working
and
only
then
it
goes
down
to
the
two
through
the
architecture
group.
So
I.
Think
if
you
want
that,
you
have
to
do
sort
of
the
same
here.
P
You
should
get
clear
on
the
requirements.
You
should
really
think
of.
What
do
we
want
and
then,
before
you
start
working
on
the
very
technical
details
and
describing
everything
you
should
wait
on?
What's
the
outcome
of
the
3gpp
process
as
well,
because
that
is
the
way
you
can
work
best
hand-in-hand.
That's
just
a
proposal.
I'm
not
saying
you
have
to
do
that,
but
it
would
sort
of
look
natural
to
me.
A
E
There
was
a
good
comment,
but
I
also
think
how
much
impact
we
have
to
3gpp
procedure
depends
on
the
use
case.
It's
at
the
very
first
use
case
may
be
something
that's
entirely
complementary,
just
to
achieve
down
in
routing
and
to
achieve
the
best
route.
Second
use
case
was
a
bit
more
impact
with
3gpp,
and
here
understand.
We
should
first
approach
sa
one
with
use
cases
and
maybe
do
key
issues
kind
of
description
and
then
make
a
proposal
towards
Shu
NCT.
So.
P
A
F
F
He
presented
this
document
in
a
rush
last
time
at
102
and
since
then,
what's
the
motivation
behind
it.
So
we
talked
a
lot
about
user
plane
and
control
plane
here.
What
we
are
focusing
on:
the
mobile
UPF
mobility
that
comes
in
5g
network
and
the
impact
or
the
contribution
of
transport
network
in
it.
So
what
we
are
trying
to
solve
here
is
we
have
different
slice
and
service
types.
They
are
going
to
use
different
kind
of
SLA
guarantees
and
how
are
we
going
to
provide
that
from
the
transport
network
perspective?
F
So
quick
rip
recap.
So
in
order
to
have
those
kind
of
first
SSDs
and
SLA
guarantees,
we
are
proposing
a
new
reference
architecture
in
which
we
include
a
TNF,
which
is
transport
network
function
in
the
5g
architecture.
This
that
this
function
will
be
responsible
for
distributing
the
te
path,
specific
information
to
UPF
and
G
note
piece
and
we
can
use
the
clear
mapping
functions
to
integrate
video
sessions
with
different
te
paths.
F
So
what
will
happen
is
something
like
if
you
have
three
different
type
of
SSDs,
they
will
be
mapped
to
three
PPR
IDs
on
each
a
node
P.
So
this
way
you
can
get
the
SLA
guarantees
for
each
kind,
each
type
of
service
and
slice
type
so,
and
we
don't
make
any
changes
in
the
user
plain
if
it
is
gtp
based
or
whatever,
based
that
user
plain
remains
intact.
We
are
only
providing
an
underlay
solution
and.
F
So
in
in
terms
of
a
survey
6,
we
are
not
focusing
it's
completely
orthogonal.
In
our
case,
we
don't
try
to
replace
gtp
layer
at
all
and
what
PPR
is
that
information
is
already
being
discussed
in
LSR.
What
we
do
is
we
provide
we
compute
the
TE
path
at
the
controller
level
and
distribute
the
PPR
ID
to
the
router
nodes
in
the
network,
and
it
has
resource
pacific
information.
So
if
you
want
to
provide
SL
s,
that
information
is
distributed
and
corresponding
resource
reservation
is
made
on
the
nodes
and
in
comparison
to
SR.
F
What
we
do
is
we
reduce
the
overhead
on
the
transport
and
all
that
de
characteristics
are
included
and
we
have
described
the
table
for
this
in
the
draft.
In
addition,
this
I
already
mentioned
that
for
each
type
of
SST
we
will
have
PPR
IDs
and
what
we
have
done
in
the
document
is.
We
have
described
all
the
three
mobility
modes-
SSE
mode,
one
two
three
and
describe
how
PPR
ID
could
be
used
there,
and
these
are
the
changes
since
last
time.
F
What
we
have
done
is
explained
more
clearly
how
QoS
is
used
and
how
it
will
be
carried
over
the
N,
3
and
9
interfaces,
and
there
was
lack
of
clarity
on
the
bearers
information
that
has
been
modified
and
the
clear
definition
of
transport
network
function
was
missing.
We
added
that
now
and
made
some
minor
connections
and
I
think
we
have
moved
some
of
the
information
from
the
main
draft
into
the
appendix
section.
F
A
F
A
J
Like
you
know,
talk
about
the
time
since
you
network
applicability
for
fine
G
Pierson
as
a
topic.
It's
it's
not
something
new.
If
you
see
on
the
wireline
side,
it's
very
mature
but
with
ultra-low
latency
kind
of
an
applications
coming
in
and
there
is
a
heavy
dependency
on
the
wireless.
So
that's
where
the
TNS
applicability
to
Phi
G
is
scanning
lot
of
fraction.
J
So
with
that
without
spending
much
time
here,
this
is
something
you
see
on
the
5
g
sy
ultra-low
latency
application
category
is
gaining
a
lot
of
traction.
That's
this
the
important
bucket
from
operators,
point
of
view,
which
kind
of
opens
up
the
b2b
opportunities.
So
on
the
speck,
like
you
know,
22
to
61
it
kind
of
calls
all
V
alpha
low,
latency,
the
parameters,
the
stats.
What
we
are
talking
about
is,
like
you
know,
in
milliseconds
we
are
talking
about.
Like
you
know
the
network,
the
network
should
be
able
to
provide
a
millisecond
deterministic
latency.
J
That's
that's
the
ass
coming
in
from
the
the
3gpp
specs.
So,
if
you
see
to
be
the
the
challenge
is,
what
we
have
is
like
most
of
the
deployments
are
it'll
at
least
and
and
it's
and
it's
extremely
impossible
to
get
that
kind
of
a
latency
what
the
ultra-low
latency
applications
are
looking
for.
So
the
idea
here
is,
like
you
know,
the.
A
J
Guys,
the
idea
here
is,
like
you
know
so,
like
I,
said,
on
the
5g
point
of
view
from
pts,
and
you
know
this
already
a
lot
of
work
going
on
in
2.1
cm
in
terms
of
how
we
can
leverage
the
TSN
protocol
stack.
You
know
on
Ethernet
media
to
kind
of
achieve
the
deterministic
latency,
which
is
kind
of
a
prerequisite
for
a
unique
and
different
applications.
So
the
point
what
I
want
to
highlight
is
you
know
this
lot
of
verb?
You
know
things
we
have
to
look
at
from
the
end-to-end
network
slicing
point
of
view.
J
J
So
if
you
see
the
the
work
here
like
you
know
this,
this
already,
like
you
know
in
city
and
kind
of
a
controller
recommended
as
part
of
the
year
time
since
you
network
II.
But
there
is
a
holistic
piece
missing
like
when
you
talk
about
the
slices.
It
should
be
an
end
to
end
and
end
to
end
slices
requires
an
Orchestrator,
a
kind
of
a
centralized
Orchestrator
which
kind
of
integrates
with
the
TSN
controllers.
J
So
that
is
where
you
know,
I
feel
this
lot
of
work
required
in
terms
of
defining
the
standards,
how
we
can
integrate
multiple
domain
controllers.
That
includes
the
TSN,
as
well
as
the
deterministic
networking.
This
lot
of
good
work,
going
on
on
the
that
knit
idea
for
working
group
like
you
know
how
all
these
things
can
come
together
and
make
it
in
their
outcome.
In
terms
of
you
know,
achieving
an
end-to-end
slices
and
able
to
orchestrate
the
whole
thing
so.
J
Any
comics
guys,
you
know
you
know
my
ask,
is
like
to
the
team
is
like,
if
any
of
you
guys
interested
to
work
on
this
you're
welcome,
so
we
are
in
the
process
of
defining
the
stuff.
This
is
more
like
a
problem
statements.
We
are
working
on
the
solutions
and
stuff
for
maybe
in
the
next
presentation,
we'll
come
up
with
a
detailed
proffer
on
this
problem
statements.
Okay,.
R
R
Okay,
so
actually
as
happy
six
mobility
is
progressing.
We
have
a
six-mile
draft
of
this
working
group,
which
has
some
of
the
motivation
behind
it.
We
also
have
the
the
3gpp
city
for
study
item
that
is
focusing
on
a
nine
and
then
we
have
some
talks
going
on
like
the
one
that
RSP
percentage
before,
but
we
realized
that
we
believe
that
there
is
a
lack
of
one
single
document
that
is
documenting
their
motivation
and
applicability
for
us,
our
v6
mobility.
R
So
what
we
did
in
in
these
draft
is
we
try
to
look
at
all
the
use
cases
where
a
sorry
six
could
fit
in.
So
we
divided
this
into
two
big
blocks,
so
the
first
one
is,
it
would
be
serviced
by
the
network,
simplification
use
cases
and
then
the
new
mobility
use
cases
and
we
started
trying
to
divide
what
would
be
the
use
cases
for
asar.
So
the
first
big
item,
starting
from
the
top,
will
be
the
radio
curanto.
So,
for
example,
can
we
improve
how
the
front
whole
interface?
R
Can
we
try
to
do
a
state
of
load
or
a
state
transfer?
Can
we
do
well
that
the
reaper
replace
DDP
use
case
that
it
just
simply
were
placing
GDP
with
it's
a
v6?
Then
we
have
other
use
cases
like
antoinette
work
as
slicing
since
that's
our
v6
can
cover
the
overlay
and
the
underlay,
then
sir,
retaining
on
the
n6
or
potentially
on
the
a9
interface
and
idyllic
isolation.
R
A
R
So
there
is
actually
a
table
of
content,
but
is
what
I
just
said.
So
the
draft
is
in
our
very
earliest
stage.
We,
some
of
the
use
cases
are
still
not
very
tender.
We
want
to
look
at
the
idea
of
isolation
and
the
n9
interface.
There
has
been
a
lot
of
discussion
on
these
written
mobile
enforces
the
one
ultra
you
see,
and
then
we
also
want
to
do
further
study
analysis
on
if
services
can
be
used
to
optimize
the
end
for
interphase
contain
security
and
the
security
implications
on
benefits.
R
We
would
like
to
do
right
now,
since
it,
since
this
document
is
very
early
stage,
is
just
to
call
for
participation
from
people
in
this
group.
We
believe
there
are
many
use
cases.
There
will
be
used
cases
where,
of
course,
as
our
v6
will
not
fit,
and
we
want
to
identify
this
too,
and
we
just
welcome
anyone
to
to
join
this
RAF
if
they
want,
or
it
just
will
provide
feedback.
Ok,.
A
L
A
A
That's
so
two
broad
comments:
I'm
like
I'm,
getting
from
my
CT
for
guys
as
well,
is
that
in
many
places
in
the
draft
it
looks
like
it's
going
to
change
the
come
see
the
3gpp
control
plane.
Sometimes
it
looks
like
it's
going
to
be
only
2035
or
one
base,
but
then
and
other
places
and
say
that
the
path
the
head
end
is
going
to
do
a
lot
of
things
same
thing
about
the
state
and
it
says
that
it
can
reduce
state.
A
R
Just
to
reply,
in
short,
so
in
essence,
there
will
be
some
of
the
use
cases
that
might
require
to
change
their
3gpp
architecture,
but
what
we
are
trying
to
do
here
is
to
identify
the
use
cases.
We
are
not
trying
to
propose
this
as
a
standard
is
justify
the
use
cases.
Some
of
these
cases
will
will
PCs
have
a
fresh,
a
v6
home,
node
and
then
based
on
it,
we
can
evolve
on.
There
is
our
basic
values:
that's.