►
From YouTube: IETF110-DMM-20210308-1600
Description
DMM meeting session at IETF110
2021/03/08 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
A
A
B
Okay,
I
guess
I
think
it's
8
o'clock
we
can
get
started
so
welcome
folks,
thanks
for
joining
the
dm
I'm
working
with
myself
straight
in
the
valley
and
I'm
with
saturism.
B
So
this
is
the
agenda
for
today.
Just
before
we
get
started
some
the
rules
about
the
itf
is
being
run
under
certain
rules
and
regulations,
and
these
are
listed
here.
These
are
the
ipr
is
the
ipr
statement.
Please
review,
and
this
is
the
noteworth
statement.
B
This
meeting
is
under
hosting
understanding
rules,
and
these
are
the
these
are
documented
in
this
specifications.
Please
review
and
blue
blue
shades.
Please-
and
I
think,
yeah
there's
a
virtual
meeting
and
if
you
can,
somebody
can
sign
up
for
taking
some
notes
that
will
be
appreciated.
B
B
All
right,
then,
this
is
agenda
for
the
meeting.
B
Today,
just
you
know
a
brief
update
from
the
last
meeting
between
idea,
109
and
109
on
our
10.
We
have
adopted
the
following
document
as
a
working
of
document.
This
is
a
transport
network,
aware
mobility
for
5g.
B
B
There
were
mainly
two
objections,
but
we
didn't
get
much
feedback
when
we
worked
when
we
tried
to
it
was
all
this
offline,
but
but
we
still
chose
to
take
up
the
document
as
a
working
document,
but
we
are
hoping
whatever
the
objections
that
were
raised
will
be
fixed
in
the
you
know
the
course
before
between
now
and
within
the
document
becomes
a
is
sent
to
ies.
B
B
We'll
see
it
in
the
day
or
two,
that's
then
followed
by,
I
think,
a
quick
update
on
the
working
of
documents.
B
B
I
think
we
should
be
able
to
you
know,
send
you
know,
issue
last
call
on
this
and
there's
a
segment
loading
ipv6
for
mobile
user
plane.
I
think
some
few
updates
happened
between
now
and
the
last
meeting,
and
I
think
this
also
is
completely
ready
and
all
the
dependencies
are
met
and
we
should
be
able
to
move
this
document
forward,
and
then
this
is
the
transport
aware
network
aware
mobility
for
5g.
B
As
I
said,
this
is
just
it
was
adopted
as
a
working
document,
so
we
should
be
able
to
do
over
the
next
few
months.
We
should
be
able
to
take
more
this
forward,
and
today
is
with
that.
We
have
two
presentations
today.
One
is
the
one:
is
the
architecture
discussion
on
srv6?
This
is
an
individual
id
and
miyazan
has
presented
this
in
the
last
meeting.
B
As
well,
but
you
have
to
you-
have
not
issued
an
adoption
call,
the
plan
is
like
you
know,
plan
is
once
we
get
few
more
reviews
from
the
working
group
and
we
will.
We
will
be
able
to
take
this
up.
So
I
think
with
that
I
think,
and
then
there's
the
segment
routing
ipv6
for
mobile
user
plan.
There's
a
quick
update
on
this
as
well.
So
these
are
the
two
presentations
that
we
have
and
that's
about
it
with
that
anything.
You
want
to
add
sort
of
song.
C
No
I'm
just
waiting
when
a
working
group
adopted
document
comes
my
way
for
ed
evil.
B
D
D
Okay,
do
you
hear
me?
Yes,
please,
please
go
ahead,
yeah!
Thank
you
very
much
for
your
time
and
the
opportunity.
Let
me
recap
the
what
we'd
like
to
we'd
like
to
achieve
with
this
draft.
So
next
page,
please.
D
So
today,
I'd
like
to
recap
the
objective
and
some
architectural
discussion,
and
I
have
some
new
exam
purification
and
conclusion
and
next
step.
D
Background
for
this
is
that
the
current
mobility
related
discussion
in
ietf,
like
network
slicing,
based
on
the
assumption
of
the
existing
domain
and
the
current
gdp,
which,
in
my
opinion,
in
my
opinion,
is
not
good
for
future
for
considering
the
new
architecture
for
future.
D
So
the
current
connection,
intensive
network,
has
the
limitation
that
session
termination
point
be
a
scaling
bottleneck
and
the
connection
oriented
network
is
not
very
optimized
for
edge
distributed
computing,
not
optimized
for
any
dna
communication
and
policy
and
authentication
are
tied
to
access
methods
and
the
security
model
is
parameter
security,
but
for
future
next
page,
please.
D
For
future,
the
network
architecture
is
more
data
intensive,
and
we
are
discussing
about
distributed
mobility,
so
mobility
entities
will
be
distributed
and
the
computing
workload
will
also
be
distributed
and
access
will
be
getting
more
heterogeneous
and
policy
or
security
will
be
considered.
D
And,
as
you
know,
srb6
is
proposed
as
a
common
data
frame
across
domains
and
by
srb6
net
programming,
which
has
now
rfc
it
can
program
program.
Anything
including
overlay
functionalities
such
as
gdp,
pxm
nsh,
and
it
could
achieve
simple
flat
architecture
and
it
can
be
a
common
data
plane
across
domains
and
for
both
overlay
and
android,
and
it
can
be
easily
it
can
easily
interact
with
applications
with
scaling
and
flexibility.
D
D
So
this
kind
of
functionality
will
be
required
for
edge
computing
platform
and
for
and
for
make
the
container
pod
belong
to
tenant
or
slices.
D
And
the
3gpp
discusses
a
lot
of
you
are
llc
and
multipath,
so
for
for
reliable
transport
gdp
could
be.
Could
we
could
have
dual
gtp
tunnel
also.
D
So
I
really
want
to
have
dma
working
group,
adopt
this
document
and
consider
how
to
how
how
how
to
make
across
domain
or
or
across
or
how
to
how
to.
D
That
is
what
I'd
like
to
discuss
with
this
dma
working
group.
Thank
you
very
much.
E
B
Okay,
so
miyazan,
so
what
do
you
want
to
accomplish
from
this?
Is
it
a
more
sorry.
F
Sorry,
question
yeah,
okay,
so
I
I
recognize
that
that
the
connection
originate
nature
of
setting
up
pdu
citizens
is
not
optimized
for
its
computing.
That's
fair
observation,
but
on
the
other
hand,
if
you
consider
your
3
cpp
is
now
hitting
is
that
we
are
now
in
release
17
and
it's
building
on
top
of
two
releases
already,
which
are
using
gtp
as
the
basis
for
pdu
system
for
the
quality
of
service,
mostly
of
the
management.
F
I
I
would
say
that
changing
this
at
this
point
would
be
much
too
radical
to
be
realistic
for
5g,
so
I'm
now
wondering
that
we
have
in
in
the
iatf
or
irtf
corridors
this
discussion
on
6g.
So
maybe
this
is
something
to
discuss
over
there
and
change
the
timeline
so
that
we
address
6g
rather
than
try
to
change
something
which
is
already
nearly
halfway
off.
It
takes.
B
So
I
think
thanks
thanks
for
your
feedback,
so
I
think
one
observation
one
comment
would
be
like
the
dmm
working
group
is
not
chartered
to
say
we
are
working
only
on
4g
or
5g
or
6g
in
general.
We
are
trying
to
solve
the
mobility
problems
right.
I
think
sure
I
think
you
know
for
the
srv6
work.
The
authors
try
to
push
it
into
the
3gbp,
really
17
standard
1617
right.
B
It
did
not
happen,
but
it
does
not
mean
that,
like
you
know,
I
think
you
know
you
know
we
have
to
really
be
under
the
scope
of
5g
or
6g,
but
my
point
is:
if
there
is
an
opportunity
to
push
that
into
future
versions
of
3gbp,
it
may
be
possible,
but
as
long
as
we
solve
the
right
technical
problems
right
with
that
hanu,
you
think
is
there
something
that
this
working
group
should
do
or
your
are
you
recommending
that
this
only
irtr
should?
This
is
only
that
this
is
the
target.
F
Link
is
good
linkage
to
this.
This
irtf
discussions,
yeah
preparatory
discussions-
maybe
dear
google,
could
comment
this
because
I
think
he's
one
of
the
drivers
of
this
discussion
discussions
in
this
60
interest
group
of
ia.
Yes,
I
think
yeah
that
that
was
my
comment
and
observation
right
I'll
leave
to
you
to
conclude
what
is
the
best
place
to
discuss
these
matters.
B
Yeah
yeah
thanks
hannah,
I
think
in
general.
I
think
you
know
if
the
problem
is.
You
know
interesting
enough
if
the
problem
is
relevant
to
mobility,
architectures,
right,
5g,
6g
or
in
any
other
access
architecture.
I
think
in
general
I
think
in
my
opinion
we
should
we
should
do
it
here,
but
again
it's
up
to
the
working
group
and
the
ada
and
the
you
know,
participation
interest,
but
I
think
yeah.
I
I
think
let's
get
some
more
feedback.
Any
other
comments,
any
other
feedback
on
this
document.
B
Okay,
so
yes
and
one
question
I
have
right,
I
think
you
know
you
talked
about
the
the
the
url
c
scenarios
in
the
3
gbp
that
3gb
talks
about.
I
assume,
with
srv6
you're,
only
addressing
one
of
the
scenarios
right.
Only
the
network
site
path,
redundancy
right,
in
other
words,
there's
only
the
one
one
of
the
scenarios,
but
not
all
the
same
urls
scenarios
can
be
addressed
through
a
services.
Is
that
correct.
B
Yeah
three
3gbp
specification
supports
multiple
scenarios
for
url
right.
In
one
case,
the
uae
can
be
connected
to
two
different
brands
and
potentially
there
can
be
an
end
to
end
reliability
right.
That
is
one
of
the
scenarios
right
now,
then,
the
core
network
redundancy.
So
my
question
is
with
srv6
what
you're
arguing
is
it's
only
one
of
the
scenarios
it
you
will
be
able
to
support
right,
which
is
the
network,
which
is
the
redundancy
on
the
network
side.
D
Yeah
yeah!
Well,
yes,
so
sorry,
thank
you
for
the
question,
so
srv6
supports
any
form
of
redundancy.
D
What
I
wanted
to
raise
this
particular
model
is
that
so
ue
could
have
dual
gtp,
which
is
fine,
but
this
model
only
has
the
one
connection
and
and
network
is
going
to
provide
a
redundancy,
but
this
model
is
not
very
I.
How
can
I
say,
efficient
because
gtp
doesn't
have
knowledge
of
underlay
so
how
to
make
this
diverse
pass?
This
joint
is
is
lacking
from
the
3gpp
consideration,
so
this
is.
This
is
not
very
effective.
B
Okay,
all
right
and
that
that
helps
yeah
any
any
other
questions
comments.
Otherwise
we
can
move
on
to
the
next
topic.
Thank
you.
Yes,
before
yeah.
Sorry,
sorry,
I
I
wanted
to
just
add
on
to
the
comments.
I
also
agree
that
you
know
gtp
does
have
limitations
in
terms
of
latency.
B
You
know
reliability
and
all
of
those
things,
as
you
know,
hanu
and
sri
or
all
of
you
remarked.
I
did
have
a
couple
of
questions.
I
mean
this
may
be
interesting
work,
but
I
had
a
couple
of
questions
that
to
consider
in
more
specifically,
you
know
one
is:
does
this
impact
the
control
plane
on
the
gtp
on
the
3gpp
side,
and
if
it
does,
then
how
do
we
handle
you
know?
How
do
we
go
forward
in
a
way
that
you
know
does
not
impact
that
or
reduces
the
impact,
or
how
do
we
do
that?
B
It's
somewhat
related
to
hanu's
comments
that
you
know
a
lot
has
been
developed
already
for
5g,
so
this
may
be
something
to
think
about
as
we
move
forward
and
a
second
question
is
more
or
less
about
the
radio
side
they're,
also
using
gtp
in
the
distributed
when
you
distribute
between
the
cu
and
the
du.
That's
also.
B
B
B
Yeah,
okay,
it's
truly,
but
that
may
be
manageable.
I
think
you
know
I
haven't
looked
into
how
this
may
you
know
adversely
or
not
affect
it,
but
it
it
may
be.
Okay,
because
I'm
not
sure
you
know
the
only
my
the
main
point
would
center
around
the
control
plane,
because.
B
Plane
is
more
or
less
you
know
heavily
intertwined
into
this
whole
thing
and
the
control
plane
is
managed.
You
know
not
in
the
ietf,
so
that's
where
I
think
the
challenge
will
be
and
something
that
we
can
think
about.
You
know
I
once
we
can
get
past
that
maybe
there
are
some.
You
know
interesting
ways
we
can
solve
for
the
radius
idea
and
the
core.
B
D
I
think
it's
a
fair
comment
and
for
that
purpose
the
srv6
mobile
user
plane
defines
the
gtp
to
srv6
mapping
so
that
so
that
we
can
insert
with
pre
preserving
the
existing
control
plane.
But
I'd
like
I
wanted
to
point
out
that
if
we.
D
Don't
consider
across
domains
and
we
don't
have
a
good
slicing
mechanism
or
we
don't.
We
don't
achieve
a
good
way
for
edge
computing
platform.
B
Yeah
I
mean
just
a
last
little
bit.
I
I
agree
with
the
problem.
You
know
there
is
no
question
that
these
problems
exist.
It's
only
a
question
of
how
we
manage
forward
yeah
yeah.
Thank
you
very
much
yeah.
Just
one
comment:
okay,
so,
but
john's
key
point,
mia
you're
agreeing
that
there
will
be
inter
impact
to
the
control
plane.
In
other
words,
I'm
assuming
there
is
impact
to
this
n4
interface,
correct.
B
F
May
I
compliment
sean
just
just
tiny,
tiny
addition
that
that
so
that
we
get
the
minutes
right.
In
addition,
it's
not
only
f1
interface,
it's
also
x,
x,
n
and
that
x,
mentioning
x
and
which
is
between
these
run
nodes.
There
is
so
that
also
leads
to
the
question
of
backwards
compatibility
if
we
want
to
roam
to
40..
Of
course,
we
can
say
that
this
is
next
generation
network,
so
we
don't
need
to
carry
all
of
the
pop
or
the
heavy
heavy
things
of
of
backwards
compatibility.
F
B
Or
any
other
comments?
Yeah.
Thank
you
for
comments.
Yes,
yeah.
I
think
a
few
things,
so
your
for
your
email.
You
want
this
document
to
be
adopted
as
a
working
group
document
right.
Yes,
yes,.
D
Yes,
since
dmm
working
groups
should
discuss
about
the
distributed
mobility,
and
so.
B
Okay,
so
I
think
one
thing
you
know
I
would
I
would
we
would
request.
The
working
group
is
to
review
this
document
and
provide
some
feedback.
Some
good
points,
like
you
know,
from
hanoi,
john
right
and
yourself
right.
I
think
we
want
some
more
feedback.
I
think
you
know.
Can
we
request
few?
You
know
volunteers
to
sign
up
and
provide
some
feedback.
You
know
any
anybody
other
than
the
office
right.
Can
you
know,
can
some
any
of
you
raise
your
hands
or,
like
you
know,
state
that
you're
willing
to
review
this
document?
B
B
E
D
Yeah
ctpd
so
for
for
making
more
reliable.
D
D
Underlying
it's,
it's
not
very
effective,
so
I
my
point
is
to
have
control
control
controllability
on
underlay
which
make
the
disjoint
path
effective.
E
Well,
I'm
not
okay,
maybe
I'll
write
it
in
the
mailing
list.
In
my
yeah.
E
No,
no,
no!
It's
fine!
You
were
well
understood.
I
just
didn't
the
the
it's
not
how
you
pronounced
it,
that
it
doesn't
make
sense
in
my
mind,
it's
more
than
the
content
on
itself
like,
but
I
will
write
my
question
in
the
in
the
mailing
list
and
and
it
would
be
better
for
you
to
answer.
B
Yeah
that
that
makes
sense
daniel,
thank
you
for
that.
So
I
think
so
we
have
a
few
volunteers
signed
up
and
I
think
you
know
based
on
the
feedback
we
are
saying
we
can.
You
know
if
there's
interest
right,
but
we
want
some
more
reviews.
I
think
I,
this
is
what,
if
you
guys,
can
also
ask
so
ask
anybody
to
review
and
provide
feedback.
I
think
we'll
be
able
to
move
forward
on
this
document
so
with
that.
Thank
you
yes
on
next
is
a
quick
update
on
the
architecture,
discussions,
services,
values.
G
G
Okay,
so,
as
a
very
brief
reminder,
what
this
document
is
discussing
is
the
applicability
of
facilities
to
the
m3,
n9
and
n6
interfaces
to
this
purpose.
This
document
standardizes
how
this
how
the
mobile
data
plane
could
work.
So
it's
focused
only
on
the
data
plane
and
it
is
presenting
two
modes
for
the
data
plane,
the
so-called
traditional
mode
and
the
enhanced
mode.
G
G
Okay,
so
very
briefly,
a
bit
as
a
reminder
on
the
content
of
this
document.
G
G
Then
we
have
a
ball:
amor
evolve
mode,
which
is
the
enhanced
mode
in
this
enhanced
mode.
Basically,
what
we
have
is
that,
in
addition
to
the
overlay,
we
can
also
integrate
underlay
traffic
engineering
as
well
as
nfv
services,
so
that
is
the
enhanced
mode
and
then
what
we
are
doing
is
we
are
presenting
a
set
of
interworking
mechanisms
for
an
unchanged
and
three
interface:
okay
and
these
interworking
mechanisms.
G
G
Then
we
also
have
the
srv6
dropping
interworking,
which
was
a
work
from
iras
main
and
then
well
as
well,
then,
for
the
purpose
of
obviously
defining
this
rv6
data
plan,
we
are
defining
a
set
of
srv6
segment.
Endpoint
behaviors,
which
are
defined
in
section
six,
and
then
we
have
a
few
considerations
on
the
control
plane,
network
slicing
and
security
next
slide,
please.
G
So
that's
a
bit
on
the
draft
content
data
bit
moving
into
the
history.
So
the
last
time
we
presented
an
update
on
this
document.
It
was
actually
in
the
itf
in
singapore
pandemic.
So
well,
this
draft
the
first
revision
we
posted
in
july
2017.
G
G
So
the
document
in
that
target
as
well
next
slide,
please,
okay,
so
since
singapore,
what
have
been
the
changes?
Well
in
revision,
seven,
we
added
the
drop
in
interworking
mode,
which
was
the
the
poc
that
our
smith
did
for
us
and
revisionaid.
It
was
just
a
pure
refresh
on
the
document,
then.
At
that
time
the
working
group
chairs
asked
to
get
some
reviewers
to
the
document
and
carlos
jesus
reviewed
the
document.
Many
thanks
carlos.
So
we
in
revision
nine.
G
G
Please,
then,
from
our
technology
status
point
of
view,
there
were
two
pocs
which
were
previously
discussed
on
this
working
group.
So
a
sprint
did
one
project
which
was
using
encore
where
they
actually
were
capable
of
demonstrating
this
srv6
mobile
user
plane,
so
that
was
slide
steam
and
then
we
also
had
the
poc
that
was
actually
presented
a
few
eight
years
ago
from
arasmit
leveraging
the
opener
interface.
G
Aside
from
that,
we
also
have
two
other
open
source
implementations.
One
in
fdi
of
bvp
contributed
by
tessuya
many
thanks,
and
then
we
have
a
p4
implementation
that
is
also
available.
Open
source
from
contarusan
nexus
live
please,
so
the
document
has
been
stable
for
the
last
two
years.
G
This
document
actually
had
a
normative
reference
on
the
spring
document
on
the
srv6
network
programming
draft,
which
has
been
approved
on
january
this
year.
So,
given
that
the
document
has
been
stable,
there
are
no
significant
changes
and
we
have
the
implementations.
I
think
that
it
would
be
the
right
time
to
move
forward
this
document.
A
A
Okay.
Can
you
repeat
the
last
few
words?
Please
sorry
asking
ayanna
to
allocate
the
basic
behavior
code
point:
okay,
it's
being
rc8986
already
open
the
code
point
speaker.
C
I
had
my
hand
up.
I
was
going
to
ask
a
question
and
then
I
thought
for
a
brief
moment.
Saturday
was
reading
my
mind,
but
now
I
have
to
respond
to
that
as
well.
I
on
an
early
allocation.
C
I
think
it's
rfc
7120,
it's
something
we
could
do,
but
I
I
think
maybe
it's
I
was
wondering
the
question
I
was
going
to
ask
before
that
was
has
has
spring
reviewed
this
document,
and
does
anybody
think
that
document
the
spring
should
be
notified
about
this,
or
at
least
notified
during
the
dmm
groups?
Last
call
or.
B
I
I
think
you
know,
I
believe,
authors
very
early
did
present
this
in
spring
I'll.
Let
them
confirm
that,
but
at
least
from
the
content
that
we
have,
I
do
not
know
eric
if
we
need
any
explicit
feedback,
but
as
an
fyi
just
to
see.
If
there
are
any
objections,
we
can
certainly
do
that.
Maybe
you
know
if
you
in
any
capacity,
if
you
can
forward
that
that
will
be
great.
Otherwise
we
can
do
that
as
well.
B
G
Okay,
I
haven't
checked
the
registry
there.
Just
one
comment
so
on
the
first
revisions
of
the
document
went
into
us
an
individual
document.
We
did
send
it
to
to
a
spring
and
indeed
dmm
choose
to
adopt
it,
because
we
were
hesitating
between
a
spring
and
dmm.
G
For
the
last
couple
of
revisions,
the
document
has
not
been
forwarded
to
a
spring,
so
certainly
eric.
Maybe
one
interesting
thing
that
we
could
do
is
whenever
the
document
goes
into
working
group
last
fall.
Maybe
we
can
cross
post
it
to
both
the
spring
and
dmm.
C
Work
either
one
of
those
things
I
think,
would
be
polite
for
spring
folks
and
I'll
I'll
I'll
talk
to
the
spring
ad
about
early
allocation.
If
you
want
okay,.
B
Thank
you,
okay,
so
so
eric
to
close
the
ai.
Are
you
going
to
forward
the
document
or
do
we
want
us
to
do
anything
there.
B
B
All
right
thanks
everybody,
this
wraps
up
our
meeting
for
today
was
the
meeting
minutes
and
we'll
follow
up
on
action
items.
Thank
you
so
much.