►
From YouTube: IETF109-DMM-20201117-0730
Description
DMM meeting session at IETF109
2020/11/17 0730
https://datatracker.ietf.org/meeting/109/proceedings/
D
B
B
A
few
things
we
need
to
take
care
of
one
is
the
the
ipr
rights.
I
hope
you
are
able
to
see
the
see
the
slides
on
the
itf's
position
on
the
ipr
declarations
and
the
general
rules,
and
this
is
the
noteworld
statement.
You're
running
the
itf
meetings
are
held
in
certain
rules
and
regulations.
These
are
documented
in
these
specific
documents
and
a
few
other
things
you
don't
need
to
take
care
of
blue
sheets
anymore.
There's
a
virtual
meeting.
B
B
B
B
B
B
B
Now,
thanks
pablo
for
that,
and
now
a
few
things
I
think
our
last
idf
meeting
was
itf.
106.
honor
7
was
cancelled
108.
We
did
not
schedule
it
so
between
106
and
now
I
think
a
few
updates.
The
key
things
is,
we,
I
think
the
distributed
mobility.
Anchoring
draft
is
published
as
rfc818
contracts
to
the
authors.
B
B
I
think
so
that's
that's
the
key
update
and
now
on
the
working
group.
The
documents
I
think
we
have
the
user
plane,
protocol
and
architecture
analysis
document.
That's
it's
coming
out.
You
know
pretty
good,
that's
in
a
great
shape
in
general.
I
think
last
time
I
believe
the
authors
were
not
ready
for
the
last
call,
or
at
least
you
know
I
thought,
but
now
we
should
probably
in
the
next
you
know
now
it
should
be
able
to
move
forward.
B
B
B
We
promised
to
see,
show
some
activity
on
this,
but
that
did
not
happen
so
for
now
you
know
we
are
not
making
any
decision
on
this
yet,
but
we
want
some
more
time
to
reach
out
to
charlie
and
laurel
and
finally
make
a
decision,
but
but
it's
so
sad
the
document
is
almost
done.
It's
just
that
that
one
last
push.
I
think
that's
one.
B
In
fact,
all
we
need
is
just
a
you
know,
publishing
the
document,
a
new
revision
and
somebody
willing
to
you
know,
address
any
comments,
ideas
through
the
iesc
process,
but
I
think
tremendous
amount
of
efforts
went
into
this
this
document,
I
think
that's.
It
will
be
unfortunate
if
you
leave
it
out
here,
but
but
let's
see
what
comes
up
now,
this
is
where
we
are
with
respect
to
the
working
group
documents
right.
I
think
now.
B
Today's
topics,
I
think
you
know
there
are
you-
know,
updates
on
the
the
two
working
documents
and
two
other
new
topics,
and
also
there
is
a
rechartering
discussion
we
would
like
to.
You
know
discuss
that
at
the
end
of
the
presentations
like
to
see
like
you
know,
I
think,
overall,
this
working
group
is
chartered
to
do
two
things
right.
Overall,
what
are
the
topics
that
we
actually
do
for
the
distributed?
Mobility
management
that
we
are
somewhat
you
know
getting
closer
to
completion
right?
The
srv6
work
is
a
major
thing.
B
That's
left
out,
but
at
least
the
other
documents
were
done
and
we
also
are
chartered
to
support
any
mobile
ipv6
pm.
V6
v6
extensions
as
an
ongoing
process.
That
was
the
agreement
when
we
form
the
working
group,
so
so
that
is
there,
but
overall
for
the
near
topics
we'd
like
to
have,
you
know,
see
some
interest.
I
think
you
know
more
last,
I
think
a
few
months
we
have
been,
you
know
the
terribly
really
bad,
actually
with
respect
to
working
group
activity.
B
I
think
it's
more
than
the
the
participants,
even
the
chairs,
we
were
not
active.
I
think
it's
inside
a
perfect
example
as
how
not
to
run
a
iet
working
group,
but
I
think
hopefully
you
know,
I
think
if
you
bring
some
focus
back
and
like
with
some
new
topics
and
if
there's
proper
interest,
we
want
to
take
it
forward.
At
least
that's
the
that's
the
goal,
and
with
that
I
think
today's
topics.
First
topics
is
the
transport
network.
Availability
for
5g
uma
is
going
to
present
this
uma.
Are
you
there.
A
B
B
F
F
F
But
the
problems
are
so
these.
There
is
no
transport
network
awareness
in
the
scenarios
right
so
if
they
care
about,
ran
their
radio
access
network
and
the
core
network,
but
the
transport
network
is
not
factored
so
why
this
has
to
be
factored
because
some
of
the
use
cases
where
here
we
are
at
5g,
regular
network
cases,
the
transport
network
and
sla
guarantees.
Transport
network
need
to
be
factored
both
on
f1,
new
and
npn
interfaces.
F
F
So
this
aspect
also
has
been
addressed
in
this
draft
on
x,
right,
please
yeah,
okay,
so
so
this
draft
was
first
presented
in
july
2018,
ietf
102
in
montreal,
this
mobility
function
aware
underlying
transport
has
been
defined
here
and
mapping
to
various
underlying
transfer
technologies.
Initially,
like
you
know,
we
laid
out
a
lot
of
stuff.
Also.
We
talked
about
lisp
and
other
technologies
at
the
time,
2018
we're
talking
about
ila
based
mobility
and
other
scenarios,
but
we
eventually
in
our
number
2001.
We
just
focused
on
the
specific
two
aspects.
F
That
is
how
how
the
framework
can
be
defined,
how
the
underlying
transport
mapping
can
be
defined.
So
these
two
aspects
we
boiled
on
in
november
2018,
both
in
and
three
online
interfaces
we
started.
N9-
is
the
new
interface
in
5g
how
the
cost
is
being
carried
in.
Both
these
interfaces
has
been
defined,
missing
transport
network
related
items
like
slice,
selection
and
integrated
approach.
There
are
two
approaches,
as
defined
in
a
backward
compatible
way
in
4g
deployments,
which
addresses
the
4g
deployments
and
eventually,
which
can
be
migrated
to
5g.
F
Both
cases
have
been
defined
in
section
2.2
and
eventually
section
3,
some
updates.
As
for
comments
received
from
from
the
list
and
offline
in
2009
ieta
105,
we
further,
we
got
a
lot
of
feedback
time
in
one
of
my
time,
so
we
have
contributions
from,
although
star
we
are
working
on
the
rant
landslide,
mostly
and
nokia,
for
future
wireless
and
interdisciplinary.
F
So
they
have
a
lot
of
discussion
a
lot
of
contributions,
so
their
content
have
been
added
and,
as
a
co-authors
have
been
all
set
as
co-authors
and
that
time
or
there
were
we,
because
we
couldn't
come
up
with
a
unified
approach,
so
there
were
two
solutions
set
for
the
time
in
zero.
Four
version
next
slide.
F
F
Us
even
eventually,
these
two
solutions
got
harmonized
in
zero,
five
simplified
solution
approach
and
we
left
with
the
one
outstanding
issue:
how
to
carry
the
transport
network
context
identified
in
the
packet.
So
we
don't
want
to
specify
anything
srv
specific,
because
the
network,
some
parts
of
the
network
cannot
do.
We
may
not
use
sr
at
all
or
some
layer,
2
network,
so
we
we
have
a
lot
of
ideas
from
the
working
group
that
time
so
finally,
eventually
settled
up
with
one
option
which
is
neutral
to
the
trafficking
moving
in
the
transport.
F
F
So
a
recent
comment
summary.
So
now,
sorry,
unfortunately,
we
couldn't
present
last
two
sessions
because
there's
no
dmm
session
and
also
we're
also
not
active
various
other
things
that
were
happening.
So,
unfortunately,
we
couldn't
progress
further.
But
when
we
asked
two
months
back,
chase
asked
to
discuss
in
the
working
group-
and
we
mentioned
it-
and
a
couple
of
folks
responded
with
a
couple
of
comments.
F
One
is
from
one
comment
is
from
pablo
related
to
simplifying
section
three
section,
three
and
appendix
which
is
the
new
mobility
scenarios
with
the
tv
mechanism.
Ppr
second
comment
is
additional
ranges
texan.
This
demand
scenario
for
enterprise
5g
use
cases
they're
working
on,
so
they
wanted
to
extend
this
to
end-to-end
scenario,
where
your
session
generation
is
not
happening
on
the
edge
rather
than
on
the
cloud
right.
So
in
this
case
n2
under
service,
they
want
sdm,
sd1
extensions.
F
F
Okay,
so
what
we
changed
to
zero,
eight,
so
the
last
region,
so
the
main
section
is
from
pablo
to
take
care
of
the
public's
comments.
We
we
just
simplified
the
section
three
and
just
to
show
the
applicability
of
the
framework
on
different
underlays.
This
is
not
meant
to
be
exhaustive
on
the
list.
Like
you
know,
we
discussed
couple
of
underlays
how
this
can
be
done
so
this.
F
Similarly,
any
new
underlying
transport
mechanism
can
be
used
with
this
framework
in
a
mobility
domain,
similarly
appendix
which
is
related
to
ssc
modes.
Various
mobility
scenarios
have
been
described,
and
you
know
that
that
pablo
asked
to
remove
that
into
a
surprise
section,
because
that
is
mostly
focused
on
ppr,
how
that
can
be
done,
so
this
all
been
moved
to
a
different
raft
ppr
and
that
is
appropriately
referenced
in
various
parts
of
this
draft.
Unfortunately,
both
the
drafts
are
uploaded
on
the
same
day.
F
F
Yes
and
other
ranges
says
kaushik
asked
we
are
we
added
the
text
to
define
the
additional
ranges
for
the
security
with
slicing?
Like
you
know,
some
slices,
they
want
security
as
a
key
parameter,
so
this
is
in
addition
to
what
happens
from
the
g
note
b
emits
the
packet
with
ipsec
in
cases
of
it
cannot
be
done.
This
can
be
done
in
the
pin
in
front
of
it,
and
the
comments
are
also
this.
Next.
F
I
think
we
were
ready,
from
other
point
of
view,
undercover
the
common
side
from
zero
section,
zero,
six
version
itself,
but
unfortunately
you
can
follow
up
as
I
specified
earlier.
So
current
version
is
explained
at
us
for
the
comments
received
last
month
and
and
that
been
all
addressed,
so
we
feel
from
other
side.
We
wanted
to
ask
for
working
reproduction,
and
I
want
to
continue
further
continuous
work
based
on
the
amount
of
efforts.
This
has
been
already
done
on
this.
F
G
G
Now.
The
question
that
I
have
for
you
is
that
if
I
do
the
math,
if
you
have
three
traffic
classes
and
200
gps,
for
example,
you
have
already
burned
all
of
these
16-bit
ideas
and
the
question
that
they
have
for
you
is:
have
you
considered
decoupling
the
slice
id
from
the
heart
id
because
to
me
it
seems
like
you
could
really
only
I
mean
one
way
that
you
can
improve.
Scalability
is
just
by
encoding
the
an
identifier
for
the
slides
instead
of
an
identifier
for
this
license.
F
F
Oh,
no,
no,
okay,
so
path
id!
You
don't
have
to
so
see
you
you
don't
have
to
it's
not
coupled
at
all
right.
So
so
what
is
done
is
when
the
packet
is
emptied
from
gmp
or
upf.
The
source
ports
are
representative
of
this
la
the
information
ssd
information,
so
that
information
you
can
use
it
in
the
pe
to
configure
policy.
If
you
are
using
sr
srv6
or
sr
mpls,
whatever
the
technology
you
use
underlying
use
a
configuration
policy
in
the
ingress
node
and
use
those
codes
to
map
it.
F
G
F
That's
correct,
but
there
was
in
section
I
forgot
the
section
there
was
a
calculation
john
has
done
the
typical
scenario.
How
many
are
required,
and
you
know
how
this
is
justified.
There
was
a
text
based
on
that
and
you
can
see
that
if
it
is,
if
you
have
any
questions,
I'm
happy
to
answer
there,
but
that
has
discussion
has
been
done
in
one
of
the
versions
and
we
added
specifically
text
for
that.
E
Just
just
checking
this
that
observation
that
in
in
this
work,
group
they're
working
on
network
slices
and-
and
they
have
also
the
framework-
this
looks
fitting
into
that,
but
I
think
later
on,
when
you
develop
further
this
it,
it
would
be
good
to
have
in
in
line
what
what
this
working
group
is
doing.
Otherwise,
we
are
just
acting
more
confusing
here.
F
Okay,
so
I
can
I
can
take
this.
Somebody
commented
on
this
and
the
working
room
calls
in
the
mailing
list.
So
yes,
so
this
work
has
been
started
with
you
for
almost
one
half
year
before
this
workbook
is
done.
I
started,
I
think,
this
working
group.
I
am
following
this
closely
what
this
working
group
is
doing,
both
the
framework
document,
the
definition
document
they
are
not
specifically
targeting.
Of
course
the
3gpp
use
case
is
there,
but
it
is
a
more
generic
framework,
idf
slice.
F
What
is
idea
of
slice
and
what
is
required,
but
we
are
talking
about
two
two
two
points
that's
being
addressed
in
this
draft
is
a
little
bit
orthogonal,
but
but
only
thing
common
is
eventually
once
the
young
models
are
defined
there.
If,
if
working
group
accepts
this
draft,
we
can
extend
that
whatever
the
framework
they
come
up
with,
we
can
extend
whatever
the
mapping
scenarios
we
creating
here.
We
can
add
it
there.
We
are
not
conflicting
with
what
we
are
generically
proposing.
F
Now
way
back,
we
presented
I'm
not
remembering.
No,
we
only
presented
in
dmm
we
thought
of
presenting.
No,
I
think
this
working
group
john
has
presented,
I
believe,
oh
no,
no
wait!
A
minute
yeah
john
has
presented
in
peace
working
up
in
a
different
format.
Oh
yeah.
Now
I
remember
so
john
has
one
contribution
in
last
year,
so
he
was
presenting
in
peace
but
rather
than
it's,
mostly
3gpp
specific,
so
we
he
merged
that
portion
that
part
of
the
draft
into
this
draft.
B
All
right,
okay,
I
think
yeah,
where
we'll
get
the
work
done.
Probably
that's.
You
know
a
separate
discussion,
but
in
general
I
just
you
know.
I
think
it's
good
to
get
some
feedback
from
other
groups
as
well
right.
So
I
think
so
you
are
suggesting.
Authors
are
suggesting
we
you
know
issue
an
adoption
call.
Is
that
what
the
you
know
ask
is
yes,.
F
B
E
B
I
H
E
A
A
D
B
B
B
H
B
B
B
B
H
H
H
H
B
E
E
H
Yes,
sorry
for
the
trouble,
thank
you
so
for
the
future
distributed
mobile
network
access
should
be
more
heterogeneous.
Next
next
slide.
Yeah
so
actually
should
be
heterogeneous
and
data
should
be
spread
ubiquitously
by
multi-cloud
or
distributed
edge
cloud.
So
we
are
aiming
more
simple
on
flat
architecture
by
communalize
data
plane
across
domain
and
ovary
underlay.
H
H
H
H
H
H
H
B
B
B
F
B
B
F
J
E
B
E
E
I
H
I
understand
the
question
the
how
the
application
can
interact
with
the
yes,
yes,
so
the
application
needs
some
framework
or
programming
framework
or
programming
platform,
and
such
platform
need
to
support
the
data
frame.
And
if
the
data
plane
is
supported
by
the
compute
stack,
then
it's
it
becomes
easier
to
to
be
the
application
platform.
That's
what
I
mean.
B
J
J
J
J
So
the
main
motivation
for
this
is
to
work
in
control
solutions
for
mobility
management
in
in
distributed
sfcs
well
in
sfcs,
in
service
fashion
chains,
where
in
sfc
you
know
that
there
is
a
working
group
in
atf
working
on
on
different
mechanisms
for
service
function.
Chaining
and
control
mechanisms
for
for
sfc
were
not
there
in
scope
in
sfc,
so
they've
even
defined
control
mechanisms.
J
Yet,
but
I
believe
that
is
an
interesting
topic
and
mechanisms
that
are
required
and
in
particular
there
are
some
points
regarding
mobility
of
functions,
migration
of
functions
within
an
sfc
that
I
believe
could
leverage
from
from
using
or
reusing
or
extending
mobility
protocols,
as
the
ones
define
and
maintaining
the
mm.
So
in
the
picture
I
have
just
one
example
of
architecture.
So,
even
though
I'm
gonna
use
terminology
about
cellular
controllers
and
central
controls
is
just
an
example,
so
the
idea
is
that
we
have
an
sfc,
so
a
function,
a
service
function
chain.
J
We
have
different
nodes
here,
ues
and
a
g
node
b,
and
we
may
have
an
infrastructure
connected
to
the
dnob
in
the
network.
We
have
functions
running
on
ues
and
gnode
bs.
For
example,
we
have
function,
1
running
at
node,
a
function,
2
running
at
node
b
and
function,
3
running
in
the
g
node
b
in
node
with
current
architectures.
J
We
have
a
central
controller,
slash
orchestrator
call
it
whatever
you
want.
That
is
basically
managing
responsible
of
the
control,
the
lifecycle
management
and
under
control
of
the
sfc,
and
the
motivation
for
this
work
was
some
solutions
that
we
are
exploring
in
which,
in
addition
to
this
central
controller,
we
may
have
what
we
call
silver
controllers,
but
basically
is
other
entities
that
are
capable
of
also
controlling
the
the
sfc,
and
one
of
the
things
that
these
controllers
may
do
is
detect
the
need
of
moving
a
function
to
another
node,
for
example.
J
J
So
this
is
the
motivation
for
having
a
mechanism
that
allows
two
move,
functions,
migrate,
functions
in
sfc
and
our
approach
or
our
proposal
is
to
extend
mobile
ipv6
mechanisms
with
new
messages
for
this
specific
purpose.
That
is
moving
a
function,
which
is
something
similar
to
moving
a
host,
but
not
the
same
thing,
because
here
we
have
that
the
node
that
is
triggering
the
movement
is
not
may
not
be
the
move,
the
node
that
is
moving
itself
and
we
don't
have
like
central
entities
like
a
home
agent
or
an
lma.
J
So
basically,
the
scenario
is
different
and
I'm
going
to
go
into
the
details.
Because
again,
my
my
idea
for
this
presentation
is
to
see
whether
you
think
that
this
may
be
of
interest
of
dmm.
I
I
want
to
present
this
kind
of
work,
also
in
ssc,
but
it's
a
cd
we
meet
for
the
last
couple
of
itf
meetings,
but
the
idea
is
that
that
we
we
extend
the
mobility
pv6
to
support
this
kind
of
mechanisms.
In
the
draft
we
define
different
mobility
headers,
so
one
is
service
path,
update
and
the
acknowledgement.
J
J
I
believe
that
for
mobility
for
for
life,
cycle
management,
operation
related
to
mobility
of
functions,
I
think
that
we
could
reuse
mobile
ap
as
a
control
protocol.
For
that
that's
the
proposal,
so
they
they
need
to
do
this
if
they
wanna
standardize
this
kind
of
sfc
control,
that
is,
they
haven't
done
yet
that
sure.