►
From YouTube: IETF112-DMM-20211110-1600
Description
DMM meeting session at IETF112
2021/11/10 1600
https://datatracker.ietf.org/meeting/112/proceedings/
A
A
A
So
if
you,
by
attending
this
meeting,
you're
generally
agreeing
to
follow
the
etf
rules
and
other
considerations,
so
these
are
the
this
slide-
is
about
the
ipr
considerations
and
note.
Well
again,
as
I
said,
by
attending
this
meeting,
you
have
to
you're
confirming
that
you'll
you'll
follow
the
idea
of
rules
and
regulations.
These
are
listed
in
this
guides.
A
A
So
a
quick
update,
I
have
not
seen
we
have
not
seen
much
progress
on
the
first
one
between
the
last
meeting
and
this
meeting,
so
I
think
we
need.
We
need
a
new
revision
to
see
where
we
are
right,
but
right
now,
at
this
point
not
much
progress
on
this
document
on
segment
routing
for
ipv6,
we
issued
a
last
call,
but
there
have
been
few
concerns.
There
have
been
active
discussions,
for
there
are
a
number
of
comments
like
you
know,
I
think
a
few
things
after
the
working
group
called
close.
A
We
did
not,
you
know,
send
any
text
any
email
on
on
the
outcome
of
the
call.
We
thought,
because
there
were
a
few
comments.
We
thought
we
let
the
authors
and
those
reviewers
settle
those
you
know
you
know,
discuss
offline
and
converge
on
on
on
what
what
the
changes
should
be.
So
as
we
speak,
the
authors,
other
son
and
others
are
in
actively
in
touch
with
with
the
reviewers
joel
we
know
is
one
of
the
reviewer
who
gave
some
specific
comments
right.
A
A
A
There
is
most
of
the
issues
are
addressed,
but
still
there
are
few
issues
we
want
those
issues
to
be
addressed
as
part
of
the
update
today,
the
authors
are
going
to.
You
know
talk
about
the
specific
issues.
You
know
what
are
the
blocking
comments
which
are
not
they'll.
Let
them
present
give
the
status
on
that.
A
I
have
also
spoken
to
or
a
area
director
eric
on
this
document,
so
he's
also,
you
know
watching
the
threads
carefully
so
we'll,
but
or
as
I
said,
our
plan
is
to
truly
you
know,
make
sure
all
the
issues
are
resolved
and
we
absolutely
want
to
move
forward
in
january.
That's
that's
the
plan
now
on
the
next
document.
Mobility
about
transport
network
slicing
this
this
is
today.
We
again
we
have
presentation.
This
was
adopted
recently.
A
A
So
there's
an
individual
submission,
it's
no
discussions.
Yet
today
we
are
going
to
hear
from
the
authors,
as
you
know
what
they
want
to.
You
know
on
the
proposal
with
that.
I
think
I'll
pause
for
a
second
and
see
if
there
any
other.
A
So
the
agenda
for
today
is
like
mainly
you
know,
three
presentations,
one
from
john
from
pablo
another
from
satoru,
so
two
working
documents
and
third
one
the
individual
id.
So
there
is
one
other
document
that
is
missing.
As
I
said,
the
first,
the
other
working
document.
You
know
the
authors
haven't
asked
for
a
slot,
yet
we
are
going
to
you
know,
reach
out
to
the
authors
and
see
you
know
what's
going
on
on
that
document.
A
But
but
this
is
the
status
as
of
today
now
I'll
pause
here
and
see
if
there
any
comments.
Otherwise,
we'll
go
with
the
presentations.
A
All
right,
I
believe
nobody
in
the
queue
I'll,
let
our
first
presenter
john.
Will
you
be
able
to
present
your
slides
using
your
slide
deck?
Okay,
let
me
okay.
C
C
A
B
A
A
I
can't
figure
this
out.
Well,
I've
asked
for
permission
to
share
the
screen.
Okay,
yeah,
I
keep
saying
grant
grant,
but
I'm
not
is
anybody.
You
see,
I'm.
We
are
not
sharing
anything.
We.
A
E
D
F
A
Of
windows-
yeah,
okay,
okay,
this
is
good!
Please,
please
continue!
Okay,
good
morning
and
oh
good
evening
to
you
all
and
sorry
about
the
you
know
time
to
take
up
to
set
this
up,
but
thanks
for
attending
all
of
this-
and
let
me
let
me
start
with
saying
what
what
we're
doing
in
this
draft
in
terms
of
the
updates
this.
A
These
are
mostly
updates,
based
on
comments
that
we've
got
in
the
during
the
adoption,
call,
and
also
from
feedback
from
related
aspects
in,
for
example,
the
routing
working
group
and
so
on.
So
I've
organized
it
into
four
areas.
A
A
So
on
so
that's
the
third
one,
and
then
we
have
a
few
miscellaneous
changes.
That's
you
know
to
make
sure
that
we
are
aligning
with
the
t's
working
group
draft.
A
Those
are
not
really,
I
don't
have
any
slides
to
discuss,
but
we've
made
changes
in
the
draft
so
I'll
go
on
to
the
first
one
and
clarify
this
is
a
very
simple
change,
so
I'll
just
walk
through
the
diagram
I
mean-
or
rather
let
me
just
say,
the
change
that
we
made
is
in
two
section
2
to
add
that
the
this
architecture
diagram
and
is
provided
here
for
information
and
we're
not
making
any
changes
to
the
architecture
per
se.
It's
exactly.
What's
in
3gpp
the
g
g,
node
b
d?
A
U
and
the
cu
on
the
radio
side
you
can
see
over
here,
the
and
and
then
the
the
f1?
U,
which
is
the
equal
to
the
user
plane
for
the
intro
gpp,
the
g
note
bcu
and
the
upf
all
bounded
via
the
n3
or
the
n9
connections.
A
All
of
that
is
exactly
what
is
in
3gb
will
be
making
your
changes
to
it.
What
we're
putting
in
this
diagram
is
a
clarification
on
how
we're
going
to
use
it
in
terms
of
handling
the
slicing
across
these
f1u
or
n3
and
n9,
and
I
think
that's
the
clarification
we
provided
going
on
to
the
second
change.
This
is
a
little
more
detail,
so
I'll
walk
through
it
as
in
as
much
as
we
can
so
this.
A
A
So
I've
copied
the
the
a
small
diagram
from
28541
which
describes
the
transport
endpoints
as
logic,
interface,
ids
and
there's
a
list
of
them
and
how
it
relates
to
the
points
in
this
draft
is
that
you
know
there
are
these
user
plane
network
functions
which
could
be
the
gene
node
b
cu,
I
mean
you
know
bdu
or
the
upf,
and
this
interface
id
is
what
is
then
used
for
forwarding
or
setting
up
the
classifying
and
setting
up
the
slice,
and
that
is
clarified
in
three
areas.
In
the
document.
A
There's
in
the
abstract
wave
added
some
text
to
that
in
the
introduction
section
it
refers
to
the
28541
and
then
later
on.
In
section
205
of
mtnc
id
in
the
data
packet,
we've
again
clarified
how
this
is
being
used.
A
So
on
the
mti
ncid
for
traffic
class
and
tenant
I
mean
this
is
there
was
some
discussion
on
this.
There
was
there
were
some
questions
on.
You
know
how
this
is
related
to
path
and
aspects
like
that
this.
This
was
even
before
the
I
think,
working
group
reduction.
We
had
made
some
changes,
but
in
in
this
one
the
authors
have
worked
to
really
remove
all
of
the
aspects
related
to
tying
it
to
a
path
and
really
what
we've.
A
What
we
now
have
are
traffic
classes
and
tenants-
and
you
can
see
here
that
that
I
mean
I've
just
copied
the
text
from
two
with
the
changes
we've
introduced
the
notion
of
the
tenants
in
this
and
if
there
are
and
the
notion
that
there
are,
if
there
are
t
traffic
classes
and
see
tenants,
then
yeah,
it's
a
function
of
t
by
c
in
a
fully
meshed
networks,
and
that
there
is
enough
space
to
represent
that.
A
Those
are
the
so
if
I
may
ask
a
clarifying
question
here
right,
so
the
slice
now
it's
no
longer
about
two
end
points,
a
logical.
You
know
a
logical
path
between
two
end
points
but
you're,
saying
a
it.
It's
a
set
of
you
know
nodes
on
the
transport
path.
A
Yeah
of
the
slice
is
between
the
two
end
points
as
we
clarify
here.
The
point
is
that
the
identity
I
mean
associating
that
identity
is
with
respect
to
a
tenant,
that's
using
it.
So
I
think
this
aligns.
I
mean
this
aligns
more
with,
what's
been
happening
in
the
idf
and
does
that
answer
your
question
or.
A
A
The
tenant
in
this
case
is
the
one
that
is
is
requesting
these
services.
A
So
you,
if
you
have
multiple
tenants,
then
they
you
know
they
would
have
different.
I
slice
identifiers.
A
And
so,
in
other
words,
if
it
is
to
put
the
other
part,
you
know
that
was
more
tricky
and
that
was
there
before
and
was
tying
it
to
a
path.
A
I
I
hope
that
clarifies
that
yeah.
Okay,
thank
you.
So
thanks.
I
think
this
was
the
these
two
are.
Perhaps
the
most
substantial
changes
in
the
text
of
the
others
are
relatively
minor,
so
that's
actually
all
that
we
have
for
this
draft
yeah.
I
think
that's
all
any
comments
or
suggestions
to
update
we'd
be
happy
to
take
them
now
or
on
the
working
on
the
mailing
list.
A
Yeah,
so
thank
you,
john.
Any
questions,
comments.
A
There
is
nobody
in
the
queue,
so
so
john
or
you
know,
are
we
requiring
any
changes
on
the
n4
interface
for
this
or
yeah?
Can
you
right
you
don't.
G
A
A
So
you
know
it
may
be
vlan
mpls
segment,
udp
port,
so
they're
all
identified
in
this
draft
and
that
will
be
associated
in
in
this.
You
know
endpoint,
then
you
know
how
that
is
mapped
is
is
via
this
interface.
I
mean
how
how
this
is
populated
so
based
on
where
this
is
destined
or
originating
from
and
the
other
classification.
It
will
use
this
mapping,
that
is
in
here
this
endpoint
transport
mapping
and
and
that
will
be
used
to
classify
these
the
slice
and
other
information
in
in
this
transport
network.
A
Okay,
good
to
hear
that
john.
So
I
think
just
to
clarify
on
the
overall
scope.
We
are
not
truly
defining
a
on
the
transport
side.
We
are
not
introducing
the
concept
of
a
slice
right,
but
it's
just
more
of
a
mapping.
We
are
giving
an
identifier
to
a
particular
transport
slice.
We
assume
that
transport
other
working
groups
would
create
that
all
what
we
are
doing
is
we
are
doing
an
asso.
We
are
associating
that
slice
to
a
session
in
the
mobility.
Absolutely
is
that
is
that.
H
A
There
is
a
gap
here,
because
transport
area
is
already
working
on
bunch
of
stuff
in
the
mobility
area,
we
are
doing
bunch
of
things
in
the
session
areas
in
the
session
management.
It's
just
a
mapping
of
the
two
as
long
as
the
scope
is
within
you
know,
stays
within
that.
We
are
perfectly
fine
and
thank
you,
john
eric
eric
was
on,
I
believe,
is
trying
to
say
something.
Eric
cline.
F
I
think
you
actually
asked
my
question.
It
was
about
whether
or
not
there
were
any
actual
modifications
required
to
the
to
the
elements
to
any
element
that
was
implementing
into
or
no
no.
A
No
changes
to
endurance,
for
you
know,
the
only
changes
we
can
see
is
that
already
in
28
541,
these
are
the
vlan
mpls
and
segment
information.
Already
there
I
mean
we're
talking
about.
As
we
mentioned,
you
know
the
association
between
the
the
way
we
populate
a
slice
in
the
transport
network
to
that
of
the
the
slice
in
the
mobile
network.
F
I'll
leave
it
to
the
the
chairs.
I
assume
you
guys
are
following
the
other
slice
work,
as
you
were
saying,
sri
and
other
other
working
groups,
there's
there's
a
fair
amount
of
other
slice
things
going
on,
and
I
know
that
there's
a
vtn
id
draft
in
six
man
about
trying
to
have
a
network
slice
id.
So
I
don't
know
if.
I
F
J
F
A
At
some
point
we
need
to
you
know,
make
sure
this
aligns
with
the
rest
of
the
work
that's
happening
in
other
groups
eric.
I
think
the
key
thing
is
currently
this
document.
What
whatever
this
document
is
doing
is,
like
you
know
it's
something
unique,
which
others
are
not
focusing
here.
It's
mostly
about
the
how
we
manage
the
you
know
how
we
create
an
association
between
a
session
and
a
transport
slice.
A
I
think,
as
long
as
we
stay
in
that
area
and
the
slices
can
be
of
you
know,
other
groups
can,
you
know,
come
out
with
different
idea
identifiers,
and
all
of
that
we
should
be
able
to.
You
know
we
are
not
creating
a
new
id,
but
we
are
just
using
one
of
the
id
that
other
group
creates
and
we
are
binding
it
to
a
session.
So
if
you
stay
in
that,
I
think
we
are
perfectly
fine,
but
one
thing,
john.
I
think
the
draft
need
to
be
a
little
bit.
A
You
know
as
to
you
know
cover
you
know,
reflect
these
points.
Currently,
it's
all
over
the
place,
but
if
somebody
reads
it
they
may
be
confused.
They
might
be
thinking
you
guys
are
defining
a
new
slice,
and
all
of
that
so
I
would
suggest
you
and
other
other
authors,
please
you
know
review.
You
know,
review
the
text
again
and
make
sure
that
you
know
the
the
comments.
Okay,
I
think
we
somewhat
agree
think
as
an
as
authors.
A
A
Think
not
me,
but
the
other
authors
are
or
some
of
the
other
authors
are
looking
at
the
tease
work
and
we
have
tried
to
align
the
text
in
here
or
even
reference
them.
A
I'm
not
sure
that
any
of
us
are
tracking
the
six
man
specifically
for
slicing
slices,
but
we'll
take
that
as
an
action
to
look
at.
But
as
tree
mentioned,
I
think
you
know.
The
focus
here
is
obviously
to
do
the
mapping
and
to
a
mobile
session
that
gets.
A
You
know,
gets
established
and
re-established
as
a
user
moves,
and
so
that's
sort
of
more
specific
to
the
mobile
environment
and
we'll
try
to
stick
to
only
that.
A
Okay,
so
on
this
I
think
one
final
comment
on
this
john.
I
think,
if
you
can
refer,
you
know,
make
sure
track
all
the
other
work
that's
happening.
Other
groups
add
some
information,
informative
forces
if
it
makes
sense
references
right
and
so
that
way
we
can
make
sure
that
the
identifiers
that
you're
referring
to-
or
you
know
we
are
not
ignoring
any
here.
Rather
you
know
it's.
We
are
neutral
to
any
of
the
types
right.
I
think
that's
that's.
A
Yeah
to
I
think,
eric's
last
comment
at
some
point.
We
may
have
to
get
this
reviewed
by
other
working
groups
as
well
john,
so
I
think
we
are
not
ready
yet,
but
let's
clean
up
and
that's
at
some
point
as
ricky
suggesting
we
may
have
to
do
that
sure.
I've
taken
these
notes
and
yeah
I'll
definitely
work
with
the
other
authors
to
update
this.
A
I
I
had
one
comment
to
what
eric
and
you
are
saying
right,
so
we
are
following
the
peace
working
group
what
they
are
trying
to
do
and,
as
during
the
working
group
adoption,
we
made
sure
that
we
referred
and
we
because
there's
a
huge
discussion
across
the
idea
of,
like
you
know,
a
centralized
piece
for
the
technology,
because
there's
a
lot
of
discussion
before
the
buffs
and
all
that
happened
so
we
wanted
to
align.
I
We
want
to
be
the
same
page
with
the
technology,
at
least,
and
also
some
of
the
things
we
mapped
to
the
t's
stuff.
So
we
referred
explicitly
during
the
working
group
adoption
based
on
the
comments.
So
apart
from
that
as
the
part
of
the
neutral
being
neutral.
Yes,
we
are
neutral.
That's
one
of
the
reason
when
in
iedf,
105
and
eric
said
that
empty
and
cid,
we
don't
want
to
put
that
into
the
data
plane
directly
right
so
because
we
need
to
go
touch,
l2
layer,
2,
ipv4,
ipv6
and
sr
and
pls
everything.
I
That's
why
we
took
the
neutral
approach
mtncd,
we
encoded
it
into
the
udp
ports,
but
people
further
once
it's
that
information
is
given
to
the
ip
networks,
then
further
they
can
put
encode
vtn
id
is
what
eric
is
mentioning
in
six
man
or
they
can
do
all
sorts
of
ideas
in
these
whatever
they're
trying
to
do,
they
can
do
it,
but
for
us
end
to
end
we
are
neutral.
That's
why
we
backtracked-
and
we
put-
we
didn't-
put
empty
ncd
all
over
the
place
in
all
data
planes.
I
F
Yeah
I'll
just
repeat
my
offer,
if
you
think
that
there's
other,
if
you're
satisfied
with
the
current
cross-working
group
awareness
and
then
great
and
if
not
then
let
me
know-
and
I
can
try
to
talk
to
two
other
ads
and
we
can
figure
out
how
to
do
some
multi-working
group
kind
of
a
session.
I
Sure
one
more
one
more
question,
one
more
thing
for
you.
I
think
this
is
one
of
the
routing
areas
pointed
to
me
offline
messages.
It
was
not
linked
to
the
individual
draft.
I
think
there's
some
ipr
concerns,
so
I
just
requested
an
administrative
action
from
your
side.
Yeah.
Okay,
all
right
thanks,
so.
A
Yeah
eric
I'm
making
notes
on
this
and
the
multi
cross
group
coordination
thing.
I
think
once
we'll
we'll
let
the
authors
work
on
this
a
bit
more
and
at
some
point
we'll
do
the
review
yeah.
A
Okay
with
that,
thank
you,
john
and
others,
and
thank
you.
H
A
A
Please
identify
specific
blocking
comments
right
and
what
you
guys
have
what
you,
as
authors,
have
done
to
for
resolving
those
specific
comments
right
so
again,
as
I
said,
the
goal
is
to
really
this
draw
draft
has
been
sitting
in
the
working
room
for
a
long
time.
We
need
to
close
this.
We
need
to
move
forward,
so
we
want
to
I'd
like
to
see
some
progress
by
january.
So
please,
in
your
presentation,
please
give
an
update
on
on.
Please
cover
these
aspects.
B
K
Can
you
see
the
slides
shri?
Yes?
Yes,
please
pablo
excuse
yeah,
okay,
so
many
thanks.
This
is
pablo
on
behalf
of
the
rest
of
the
co-authors.
Many
thanks
esri
for
the
introduction
and
I'll
try
to
to
cover
the
points
that
you
have
highlighted.
Okay,
so
as
a
brief
reminder,
so
this
document
went
into
working
group
last
call
on
april
this
year
on
revision
11..
K
We
had
a
good
participation
with
many
comments.
So
really
thank
you
to
everyone
who
has
reviewed
and,
and
many
thanks
as
well
for
eric
that
that
actually
also
posted
the
working
group
last
call
to
spring
as
well,
and
so
during
the
working
group
last
call.
We
have
issued
several
updates
so
actually
we're
on
revision
17
with
to
address
the
comments
from
the
reviewers,
and
there
have
been
many
editorial
points
as
well
as
technical
comments,
which
I
think
has
been
very
positive.
K
Okay,
there
are
still,
I
believe,
a
couple
of
items
that
we
should
look
at
before.
We
conclude
the
adoption,
so
there
is
one
email
thread
that
I
will
discuss
later
and
another
point
on
the
relationship
of
this
work
with
other
items
and
so
basically,
on
the
next
slides.
What
I
will
do
is
I
will
try
to
highlight
these
points.
K
Okay,
so
the
the
first
comment-
and
this
is
in
chronological
order-
so
the
the
one
of
the
first
relevant
comments
that
we
got
it
was
actually
from
joel
harper
and
it
was
related
to
the
relationship
of
this
work
with
3gbp
I've
put
in
there.
The
email
link
the
url
for
the
email
from
joel,
but
if
I'm
not
mistaken,
I
think
that
joel's
point
is
that
he
believes
there
is
a
conflict
in
between
three
sections
of
this
draft,
with
a
work
that
is
being
defined
in
3gbp.
K
The
authors
have
quite
a
different
point
of
view,
because
what
we
believe
is
that
we
are
defining
the
tool
or
the
data
plane
and
this
data
plane
can
be
used
by
any
other
entity
or
sdo
such
as,
for
example,
the
3gbp.
So
basically,
we
are
not
trying
to
deprecate
gdpu,
which
is
owned
by
3gbp,
but
joel
is
still
feels
that
there
is
a
conflict,
and
this
is
one
of
the
outstanding
items
that
we
should
discuss
and
that
we
should
resolve.
K
There
have
been
a
few
more
comments,
so
we
got
quite
a
bunch
of
editorial
changes
from
jerk,
and
actually
it
was
very
nice
that
they
gave
us
the
div,
so
we
actually
applied
it,
and
we
also
had
discussion
with
john
on
terminology,
particularly
on
the
l2
adjacency,
which
we
also
resolved
as
rita,
also
actually
asked
us
whether
this
draft
should
also
cover
the
dx2
and
the
f1u
interface
considerations.
K
Okay,
so
basically
the
way
that
we
resolve,
that
is,
that
is
not
covered
in
this
draft.
We
believe
it
is
out
of
the
scope
of
this
draft,
but
it
is
covered
in
the
draft
murakami
dmm
user
play
message
encoding.
So
we
added
a
reference
to
that
draft
and
then
there
has
been
a
quite
an
extensive
email
exchange
with
jeff,
which
has
been
really
good,
and
this
has
been
editorial
points
and
clarifications
throughout
all
of
the
texts
and
just
point
the
technical
points.
K
K
Then
there
have
been
a
lot
of
discussion
on
the
addressing,
and
actually
this
is
because,
in
the
examples
that
we
use
throughout
the
draft,
we
are
using
other
things
like
u1
tid,
which
is
not
a
correct
ipv6
address
in
my
opinion.
So
we
are
trying
to
see
how
we
tackle
that,
and
maybe
I
think
that
the
most
straightforward
option
would
be
that
we
just
use
the
documentation,
ipv6
block,
and
then
we
we
have
an
ongoing
email
spread
with
jeff.
K
That
is
revolving
quite
a
slowly
on
both
of
our
sites,
but
he's
progressing
quite
good,
and
I
believe
that
jeff
just
sent
his
last
email.
One
hour
before
this
meeting,
so
I
don't
know
what
was
the
content
of
email,
but
we
are
making
quite
a
good
progress
with
jeff.
So
all
in
all,
I
think
that
so
basically,
I
think
that
we
will
be
in
pretty
good
shape
for
all
of
the
comments.
I
think
the
major
point
that
will
be
outstanding.
K
K
So
I
I
think
the
derrick
john
and
srider
they
have
been
already
closed.
I
think
joel
comment
is
blocking
well
in
the
sense
that
it
needs
to.
We
need
to
have
discussion.
Perhaps
I
don't
know
if
it's
at
working
group
level
or
whether
it
should
happen
at
a
higher
level
to
see
what
is
the
relationship
of
this
work
with
3gbp?
So
I
believe
that,
from
this
slide,
only
joel's
point
is
the
one
that
needs
a
special
attention.
A
Okay,
but
so
you
know
how
do
you
you
know,
what's
the?
What
are
the
next
steps
like
you
know,
we
want
to,
you
know,
see
some
convergence
on
this
right.
So
you
know,
did
you
guys
give
up
on
this,
or
are
you
guys
still
talking.
K
I
think
we
need
to
have
a
further
discussion.
I
think
it
would
be
interesting
to
get
the
point
of
view
of
more
working
group
participants
or,
if
not
at
least
the
point
of
view
of
the
80s.
K
I
think
there
are
several
options
to
resolve
this,
but
still,
I
think
we
need
to
hear
a
bit
more
voices.
A
So
well,
I
believe,
joel
joel
is
on
the
joel.
From
your
point
of
view,
will
you
be
able
to
summarize
your
key
blocking
comments
and
posted
the
working
group?
That
way
you
know,
because
if
you
guys
are
not
able
to
resolve
it
and
like
to
get
you
know
more
broader
feedback
and
find
some
consensus
there,
so
will
you
be
able
to.
D
Yeah
yeah
speaker,
I
sent
them
to
the
list.
I
I'll
assume
that
the
archive
pointer
is
the
right
one,
but
I
I'll
restate
them.
I
mean
satoru
asked
to
talk
to
me
as
an
author.
I
was
I
did
so.
I
restated
them
there.
The
the
this
document
has
four
alternatives.
It
spells
out
three
of
them
change
the
behavior
of
the
g
node
b
and
or
the
upf.
D
One
of
them
says:
use
srv6s
tunnels
to
connect
gtp
the
genome
b
and
upf,
carrying
the
gtp,
etc,
and
so
forth,
as
we
do
with
tunnels,
hey
tunnels,
I
got
no
problem
with
that's
absolutely
valid.
You
want
to
describe
that
go
ahead,
but
the
other
three
cases
are
changing
interfaces
that
are
standardized
by
3gpp
and
that
is
not
the
ietf's
business.
D
We
expect
folks
to
respect
the
ip
standardization
we
do
not
to
change
ipv6,
not
to
change
mpls.
We
had
a
major
fight
with
itu-t
to
keep
them
from
changing
the
way
mpls
worked.
So
if
we
expect
other
people
to
respect
our
work,
we
owe
it
to
them
to
respect
their
work
and
my
understanding
of
our
processes
are.
We
don't
go
redefining
other
people's
architectures
dmm
can
define
alternative
architectures
completely,
not
saying
it's
redefining,
3gpp
different
topic.
D
K
Joel
just
one
comment:
if
I
may,
I
understand
your
point,
however,
I
believe
at
the
beginning
of
this
document
we
have
particularly
written
in
the
draft,
and
I
quote
the
user
plane
describing
this
document
does
not
depend
on
any
specific
architecture,
and
so
basically,
what
we
are
meaning
with
this
text
is
that
we
are
not
redefining
what
3gbp
is
doing.
We
are
not
redefining
3gbp
interfaces.
D
D
Joel
pablo,
I
think
that's
what.
D
A
No
I'll
just
you
know,
I
think
the
others
in
the
queue,
but
I'll
just
make
one
comment
here.
Yes
in
in
principle,
I
completely
agree
with
your
view.
Joel
we
are
our
it's
not
our
business.
To
change
the
gbp
architecture,
however,
we
can
define
alternative
interfaces
like
six
and
three
srv6n9.
These
are
all
the
options.
I
think
we
had
to
absolutely
make
sure
you
know
we
are
not
saying
you
know.
3Gbp
says
something
and
iv
idf
says
by
then
no
no,
we
do
it
differently.
A
That's
absolutely
not
the
intent
and
from
what
I
understand,
even
the
authors
are
not
saying
that.
But
let's
see
you
know
where
the
confusion
is
how
to
resolve
that.
But
but
in
principle
I
agree
with
your
comments,
search
or
we'll,
let
others
speak
up
in
the
queue
yeah.
It's
all.
L
A
L
Hi
about
the
the
relationship
with
3gpp,
my
thinking
is
that
if
we
are
not
changing
the
into
for
signaling
and
as
long
as
from
the
rest
of
the
3gb
mobile
system
point
of
view,
that's
the
genome
b
and
upfdr,
they
are
taking
the
m2,
m4,
signaling
and
and
then
and
to
set
to
send
traffic.
L
Then,
as
long
as
the
the
the
boxes,
the
gmlb
or
upf,
they
can
talk
to
each
other
or
in
a
particular
deployment
scenario.
That
should
be
fine.
That's
why
I,
while
I
share
the
concern
with
the
competition
with
while
stepping
onto
three
toes,
I'm
that's
why
I
have.
L
Even
though
I
have
that
concern,
I'm
still
I've
been
still,
I
still
have
been
making
all
those
comments
to
work
on
the
technical
and
editorial
improvements
of
the
document.
So
I
think
the
important
thing
here
is
that
we
do
not
change
3gpp
architecture.
We
do
not
change
3gpp,
signaling
and
then
for
a
particular
operator
if
they
wanted
to
to
deploy
srv6
tunnel
as
long
as
they
can
ensure
the
interoperability
based
on
n2m4
signaling.
L
That
should
be
fine.
Now,
going
back
to
the
technical
and
editorial
or
comments,
there
was
two
emails
thread
outstanding
earlier
I
sent
a
response
on
one
of
the
threads
before
the
meeting.
There
is
another
one
I
haven't
replied
yet
I
think
we
have
resolved
pretty
much
the
major
technical
issues
there
are.
There
is
one
issue
remaining
that
I
think
it's
good
to
to
point
out
the
option
of
doing
the
drop-in
mode
without
using
the
special
dropping
end
behavior.
L
I
think
we
can
still
continue
that
discussion
and
then
another
major
editorial
point
is
that
I
still
think
it's
good
and
it's
better
to
use
u1
colon
current
gid
instead
of
using
a
the
2001
blah
blah
blah
that
address,
because
we
are
what
we
are
doing
here
is
indeed
encoding.
The
tid
in
the
ipv6
address
it's
better
to
to
get
to
that
point
so
that
everybody
understands
what
what
it
is.
L
A
So,
first
thing
jeffrey,
you
know,
I
saw
lots
of
you
know
postings
from
you.
I
appreciate
that
we
did
a
very
thorough
review.
This
is
really
what
is
needed.
I
absolutely
you
know
thank
you
for
it's
very
much
appreciated
and
I
think
yeah
please
work
with
the
authors,
and
you
know,
let's
close
the
remaining
open
issues
so
that
we
can
move
forward
now.
Jeffrey.
J
F
Right
just
wanted
to
understand
whether
or
not
the
three
examples
that
joel
is
concerned
about
are
still
normative.
It
seems
to
me
from
the
chat
that
they're
still
listed
as
being
normative
and
I'm
wondering
why
they
need
to
be
normative.
F
Can
they
be
an
example
of
what
somebody
who
wanted
to
do
something
different?
You
know
in
an
appendix
would
that
be
satisfactory?
I
mean
people
who
are
going
to
do
it
are
going
to
do
it
anyway.
Does
it
need
to
be
a
normative
part
of
the
that
ietf
document?
I
don't
know
if
that
ameliorates
the
situation.
K
So
eric,
I
think
that
the
core
of
this
document
or
really
what
should
be
a
standardized,
is
section
six
if
I'm
not
mistaking.
That
is
where
we
are
actually
defining
the
srv6
segment.
Endpoint
behaviors
that
win
responsibility,
the
section
five
which
it
is
explaining
the
deployment
scenarios
to
me
honestly
it
is
not
normative.
I
would
say
I
mean
to
me:
the
normative
piece
is
the
behaviors.
That
is
what
we
need
to
standardize
how
an
operator
is
going
to
deploy
this.
K
We
are
proposing
three
behaviors
with
three
modes
or
four
modes
in
the
track,
but
actually
an
operator
might
decide
to
do
even
something
different
from
this.
So
to
me,
as
long
as
we
standardize
the
behaviors,
we
are
good
section
number
five
does
not
need
to
be
normative.
Am
I.
F
So
would
it
I
don't
know
if
jill's
still
in
this
session
or
if
he's
moved
on
to
other
sessions,
but
would
it
would
it
suffice
to
to
state
clearly
that
the
examples
given
are
non-normative
and
they
are
explicitly
for
folks
who
want
to
deviate
from
the
3gp
architecture
in
this
way?
F
I
agree
that
section.
Six
is
what
you
want
to
publish,
but
if
we
can't
find
a
way
to
get
around
some
of
the
issues
in
section
five,
then
the
whole
of
the
document
is
held
up
right.
So
maybe
I'd.
F
A
Any
other
comments
I
think
yeah
just
moving
on,
I
think
pablo
if
you
can
get
another
few
more
minutes
on
your
other
comments.
Just
please
go
back
to
other
slides.
Please.
A
A
A
G
B
This
is
saturday
from
softbank
j
hat
off
hi.
Today
I
present
a
service
mobile.
B
So
almost
all
contents
be
available
on
the
draft
I
the
first
submit.
Actually
we
explain
the
very
did
concept
of
the
architecture
by
texas,
but
the
second
submit
zero
one
version.
Today
I
submit
I
explain
illustration
so
sorry
for
the
the
submission
right
before
the
meeting,
but
I
think
it'd
be
helpful
to
understand
the
the
architecture
how
it
works
today.
B
I
present
using
powerpoint
slide
with
the
the
picture,
so
you
can
see
the
picture
for
the,
for
example,
the
deployment
of
the
five
3gb
5g
network,
using
the
upf
base
station
general
b
here
and
the
rdn
on
right
on
the
right
in
between
them.
B
B
Now
this
is
an
example
of
how
implementation
for
5g
user
plane
on
sr
under
ray
many
people
talk
about
segment
routing.
How
is
underrated
for
the
cpp
mobile
user
plane.
So
this
is
one
example.
One
operator
can
deploy
a
cpp
network
to
proprietary
connectivity.
B
Do
this,
so
one
vessel
network
consists
of
the
many
of
the
services
node
accommodate
the
above,
for
example,
for
instance,
ram
and
to
connect
access
point
general
b
and
ncupf
both.
B
B
So
this
way
the
packet
goes
through
the
base
station
access
network
from
and
to
the
upf,
then
upf
processor
packet,
then
for
the
packet
to
the
israel
network,
is
our
network
for
the
packet
to
ddn
and
vice
versa.
B
B
So
now
here
we
are
promoting
srvcmup
architecture.
In
that
architecture
we
can
see
the
data
path
for
five
user
plane.
B
B
B
You
can
see
the
detail
in
the
draft
on
right
side.
The
data
plane
cpp
is,
for
example,
sr
network
have
a
gateway
and
a
pe.
B
But
get
other
sr
node
required
to
connect
the
cpp
entity
upf
to
keep
the
scpp
architecture
as
it
did.
B
B
That's
the
overview
for
the
architecture
on
both
of
the
control
plane,
data,
plane,
control,
plane,
protocol
adopt
pgp,
but
not
limited
to,
and
data
frame
picture,
just
for
example,
four
or
five
is
using
cpp
term,
but
not
limited
to.
B
B
B
On
the
bottom
side,
the
upf
connected
to
the
sr
node
s2
with
the
two
buff
one
is
n3
upf.
Another
is
in
six
path
to
provide
connectivity
to
the
both
n3
and
m6.
B
B
Ups
route
means
the
the
endpoints
of
the
mobile
user
plane.
B
It
works
for
the
uplink
path.
It's
imported
in
the
in
three
numbers.
B
The
another
real
route
advertiser
imported
to
the
buff,
in
is
mep,
pe
on
s1,
same
node
of
the
imep
gateway,
the
n6dn
buff
imports
the
ue
route
as
well,
so
the
connectivity
between
the
ue
and
the
inside
is
actually
be
provided,
and
also
the
connected
connectivity
between
the
ue
and
the
insights.
B
Okay
next
slide,
this
picture
shows
the
equivalent
network
model
using
the
cpp
connector
protector
in
the
data
architecture
to
make
sure
the
the
equivalent
network.
For
previous
slide,
we
have
to
deploy
the
two
upf
on
each
side
in
between
the
n69
exists.
B
Accommodate
the
dn,
through
the
n6
network
on
the
other
upf
accommodate
dn,
another
dn
through
another
dn60.
That's
the
equivalent
network
model
to
previous
slide
in
cgpp
model.
B
Actually
it's
same
in
this
case,
but
the
the
h
site
is
this.
Another
p
e
I
mean
so
multiple
dn
side,
supported
by
multiple
sr,
node.
B
In
this
case,
mep
gateway
doesn't
need
to
import
us
ue
route
in
the
n16
above
because
it
just
only
provides
the
uplink
path
in
the
above
return
path
is
the
provided
by
a
service
mobilizer
frame
function.
B
B
Let's
show
the
another
deployment
case
for
to
host
the
edge
site.
B
The
decider
exists
on
the
in
additional
is
sr
node,
that's
different
from
the
previous
case.
B
In
this
case,
there's
no
need
to
import
ui
route
in
mpp
gateway,
so
it's
that
may
immediately
deployment
be
simple
and
not
to
import.
Much
of
the
eu
route
into
the
above.
B
So
equivalent
network
model
using
the
chpp
architecture,
model
architecture,
picture.
B
B
So
that's
a
brief
explain
how
the
service
semipenet
architecture
works,
for
example,
using
a
cpp
network
model.
B
All
of
the
the
background
and
the
what's,
the
requirement
are
certified
in
dmm
is
already
described
in
the
introduction
section
in
the
drafts.
So
please
read
it
so
after
you
read
the
document,
I
really
happy
if
you
have
any
interest
and
if
the
working
group
in
favor
I'd
like
to
ask
the
working
world
adoption,
that
was
my
side.
My
presentation.
A
Thank
you
so
couple
of
comments
I
think
before
I
ask
the
working
group,
so
can
we
say
that
this
scope
is
strictly
on
n6?
The
steering
is
more
from
the
data
network.
Is
that
did
I
get?
That
is
my
understanding
correct.
The
steering
is
more
on
the
n6
rather
than
on
the
core
network
interfaces
or
n3
or.
B
We
have
a
appropriate
the
term
defined
in
cpp
because
it's
not
cpp
architecture,
but
this
is
the
idea
of
architecture.
One
of
the
right
actors
shall
be
defined
for
mobile
user
plane.
B
But
yes,.
B
The
gtp
is
assumed
to
terminate
on
the
gateway
after
that,
the
the
pack
in
the
packet
handled
by
isr.
F
A
A
A
I
think
I'd
like
to
ask
the
relation
like
the
level
of
overlap
with
this,
and
although
marco
is
the
draft
we're
all
you
know,
I
we
discussed
on
on
defining
something
on
n6
steering
the
idea
of
n6
steering,
which
does
not
want
to
do
they're
very
clear.
You
will
not
recognize
anything
on
on
the
north
of
upf
right.
It
perfectly
falls
in
you
know
you
know
oscar,
but
but
those
two
documents.
The
relation
to
this
any
comments
of
that
sort
of
song.
B
Yeah,
I
I
really
like
mfa
id
and
I
really
like
the
mobility
idea
from
marco,
so
the
but
somehow
the
those
two
drops
are
haven't
been
maintained.
But
while
I
I
work
on
the
service,
mobile
user
plan
deployed
a
service
network
in
my
employees
network.
B
That's
the
my
relation
latest
proposal
to
provide
optimized
password
to
fulfill
the
dmm
requirement,
yeah
so
well.
I
think
the
mfa
supposed
to
use
the
fpc,
but
also
the
this
architecture,
can
adopt
ftc
as
a
northbound
of
the
mup
controller,
but
not
too
limited
too.
A
A
I
see.
I
think
this
has
value,
but
let's
see
what
others
think
you
know,
let's
collect
some
feedback.
If
anybody
has
read
the
document,
any
questions
comments.
This
is
again.
This
is
not
a
working
document.
This
is
just
a
individual
submission
at
this
point,
but
I
think,
let's,
if
anybody
has
any
questions
comments,
please.
B
Speak
up,
I
see
some
people
in
the
queue
john.
B
A
Yeah,
sorry
for
that
I
haven't
read
that
document
so
clarify
that,
but
in
the
presentation
I
got
the
feeling
that
you're
steering
both
and
three
and
and
six
somehow
you
know
because
that's
what
makes
it
optimal.
So
I
mean
even
that's
fine,
but
my
question
is
more
like
if,
if
that
is
the
case,
what
happens
to
the
functions
and
the
upf
like
charging
or
other
things,
charging
of
course,
but
also
other
access
control
aspects.
A
Like
you
know,
I
I
saw
that
it
was
first
single
dnn,
but
if
there
are
multiple
dnn,
some
slicing
or
other
cures
enforcements.
All
of
that
those
are
questions,
but
I'm
making
the
assumption
that
you're
steering
both
the
n3
and
then
six.
So
if
you
clarify
that
first.
B
Thank
you.
Yes,
in
the
sleepy
point
of
view,
it
will
be
yes
or
no,
but
but
let's
mention
that
the.
B
Other
functionality
of
the
the
processed
in
the
upf,
currently,
our
architecture
is
just
to
prove
fulfill
the
dmm
requirement.
Okay
at
the
basement,
okay,
so
I'm
really
happy
to
work
to
support
other
functionality.
If
any
people
interested,
I
was
thinking.
A
More,
like
you
know,
it
may
be
a
private
network
or
something
like
that.
So
it's
a
single
day
and
then
you
know
factory
or
whatever
you
know
something
of
that
sort.
But
and
then
the
questions
are
about
access,
control
and
other
things
like
that
is
that
going
to
be
in
some
other
access.
B
Controller
should
be
controlled
on
the
control
plane
on
session
management
side.
The
imp
network
mvp
network
just
follow
the
the
decision.
What's
the
decision
made
in
the
mobility
management
system,
okay,
mep
mobile
user
plan
doesn't
have
any
intent
because
just
to
provide
the
dmm
requirement
satisfied.
Okay,
I
think-
and
also
this
picture
shows
only
one
dna,
but
multiple
sides-
you
mean
one
single
dna,
but
the
multiple
d
and
d9
okay.
J
Hello,
everybody
yeah,
I
I
haven't
read
a
comment
not
played
this
hero
heroes
and
I
noticed
that
we
haven't
provided
taylor's
questions.
I
have
a
question
about
this
decision:
information.
J
What
you
are
mentioning
there
on
chapter
six
with
where
you
are
getting
the
session
information
from
the
control
gateways
and
in
that
interface,
as
I
have
understood,
also
from
the
responsible
what
you
have
in
in.
J
List
that
you
are
applying
routing
protocols,
irrespective
which
routing
protocol
it
is,
but
particularly,
if
you
consider
the
example
pgp
protocol,
I'm
curious
about
them
with
the
routing
of
be
sufficiently
reactive
to
sn
carrying
session
information.
Because
that's
that
change
that
that's
quite
rapidly.
A
A
The
point
is,
you
know,
because
you're
adding
individual
routes,
what
hanu
is
saying,
will
you
be
able
to
scale
because
when
you
do
steering
at
a
session
level,
you're
almost
almost
like
a
in
one
sense,
it's
like
a
host
route
right,
but
this
is
steering,
but
I
think
honest
question
is:
will
the
system
scale
I
know?
Did
I
get
that
right.
B
Okay,
thank
you
very
much.
I
have
the
same
question
to
the
5g
interface
svi
because
they
adopt
the
arrest
and
the
the
post
and
the
callback
how
time
how
react
immediately,
but
the
the
we
actually
not
defined
the
actual
transport
protocol
for
the
northbound
api
and
mit
controller,
as
well
as
the
southbound.
With
the
controller.
Now
we
adopt
the
pgp
but
not
limited
to,
but
at
least
the
pcp,
I
have
to
admit
the
vp
running
of
the
tcp
tcp
has
a
headphone
bottleneck.
B
I
have
to
admit,
but
the
best
as
well,
and
also
the
nowadays
vcp
carries
the
millions
out
of
inside
but
outside
of
the
network.
So
that's
the.
I
have
no
idea
how
to
compare
the
scalability,
which
session
based
routing
based
scale
scale
or
not.
That's
my
answer.
This
time.
Sorry,
I
haven't
exact
on
number
of
number
two
answer
to
you.
Right
now,.
H
Chucky,
can
you
hear
me
sorry,
yeah?
Yes,
okay,
okay,
I
have
some
questions.
I
I
didn't
spend
the
whole
time
watching
your
your.
F
H
But
I
went
through
your
slide
and
in
a
couple
of
them
you
mentioned
about
the
nine
interfaces
in
in
the
interface,
but
without
specific,
without
expecting
anything
about
like
vrf
or
those
type
of
things.
So
how
are
you
going
to
handle,
like
you,
have
more
than
one
upf
with
a
9
interfacing
toy,
his
first
question
and
then,
depending
on
that
I
have
another
question.
B
Okay:
okay,
thank
you
very
much
to
to
focus
on
the
one
single
question
and
if
I
understand
your
question
correctly,
I
think
we
don't
need
to
deploy
no9
in
the
in
the
sr
network,
because
the
this
case,
just
one
upf
exists,
so
there's
no
link
to
a
deployment
line.
But
if
we
see
the
same.
B
Capability
to
provide
two
site
of
the
one
single
dm,
we
need
two
ups,
that's
our
assumption.
So
then
we
put
a
nine
in
the
middle
of
the
path
of
the
upf
2up.
H
H
B
This
case,
you
don't
need
to
configure
the
n9,
but
if
you
follow
this
configuration
you
may
need
to
configure
internet
involved.
Okay,
yeah.
H
H
Okay
sure
no
problem.
This
seems
like
the
for
the
follow-on
question
regarding
something
being
discussed
in
3gpp
essay
2
about
the
multicast
part.
Probably
you
have
heard
there
is
like
mbupf
that'll
be
introduced
and
then
on
one
side
using
a
knight
about
the
upf
at
the
other
side,
n6
about
the
edd
and
then
because
of
some
limitation
or
restriction
on
the
genome
b
side.
And
so
there
might
be
point
point
or
point
multipoint.
H
H
So
basically
from
the
mbupf
you're
going
to
have
two
passes
yeah,
I
don't
know
how
it's
going
to
fit
in
this
architecture.
At
least
I
haven't
seen
it
from
your
slides.
B
Thank
you
very
much.
Thank
you
very
much,
but
actually
we
didn't
care
the
multicast
service
right
now.
I
think
the
mba
service
is
the
new
service
appeared
recently
in
the
cpp.
It's
even
it
was
already
existing
4g,
but
I
will
study
for
that
service.
But
currently
we
didn't
see
that
service
in
our
architecture
I
have
to
be.
I
have
to
admit,
okay,
sure.
H
It
says
a
new
that
being
introduced
in
sa2,
it's
a
like
a
5g
mbs,
so
I
think
the
the
the
work
I
think,
the
I
think
the
phase
two
has
been
done.
It's
it's
almost
there,
so
yeah
yeah
phase
three
for
the
release;
18,
probably
all
that
being
been
planning
right
now
being
planned
right
now.
H
A
That,
no
that's
a
that's
a
good
comment.
I
think
author
should
review
that.
A
L
Yes,
I
could
actually
offer
a
guess
answer
for
the
unknown
question
that,
from
from
png
to
me,
that's
in
iitf
terms
that
n9
the
box
that
does
n9
mapping
there
could
be
viewed
as
in
doing
inter
as
option
b
where
you
just
do,
label
switching
or
here
is
a
non-label
solution,
but
sr
b6
mapping
and
an
end
behavior.
That
mashima-san
has
already
specified
in
the
other
drafts.
We
were
talking
about
earlier,
just
a
guess.
A
All
right,
if
there
are
no
other
comments,
I'll
leave
this
topic
here.
Thank
you,
saturday,
son.
I
think
again
working.
Please
review
this
document.
I
think
post
your
comments.
A
If
there
is
interest
you
know
we'll
discuss
on
the
next
steps,
but
right
now
there's
an
id
individual
contribution,
but
with
no
working
group
status
any
other
before
we
we
are
done
with
all
our
presentations
again
as
we,
we
talked
about
number
of
things,
action
items
on
the
individual
ids
from
authors
and
also
from
the
working
group.
After
this
meeting,
we
are
going
to
send
the
notes
that
publish
captured
we'll
take
it
from
there.
F
B
Bye,
thank
you
see
you
in
bangkok,.