►
From YouTube: IETF112-TEAS-20211109-1600
Description
TEAS meeting session at IETF112
2021/11/09 1600
https://datatracker.ietf.org/meeting/112/proceedings/
B
That
sounds
like
a
reza.
If
you
want
to
join
the
queue.
That's
great.
Your
timing
is
perfect.
Welcome
back.
This
is
our
second
tease
session.
We
broke
in
the
middle
of
a
the
last
from
the
previous
session,
but
first
before
we
can
get,
we
can
resume.
We
have
to
do
our
normal
administrivia
we're
required
and
asked
to
always
show
our
note.
Well.
This
is
to
ensure
that
all
participants
are
aware
of
the
process
and
procedures
that
govern
how
we
operate.
B
That
covers
both
the
the
what
is
discussed
here
and
that
it
becomes
part
of
our
permanent
record
and
it's
recorded
and
made
available.
It
also
governs
how
we
interact
with
each
other
next
slide.
Please,
and
our
leadership
has
oops
just
go
to
the
the
one
after
our
leadership
has
asked
to
emphasize
our
that
we
have
a
code
of
conduct,
it's
covered
in
bcp
54,
and
you
know
to
keep
it
short.
B
It's
you
know
please
be
respectful
and
courteous
of
others,
even
when
engaged
in
intense
technical
discussions,
which
are,
of
course
encouraged
the
agenda
now
onto
our
agenda.
B
So
we
broke
in
the
middle
of
or
the
middle
of
slot
4,
which
is
okay,
because
we
actually
had
40
minutes
of
open
time
right
now.
So
we're
going
to
give
adrian
up
to
40
minutes
if
you'd
like
to
take
it,
and
so
we're
going
to
start
with
that
and
continue.
And
then
all
the
other
slots
are
going
to
be
just
pushed
further
down
in
our
hours
and
with
that
back
to
adrian,
and
we
had
tarik
and
reza
in
queue
and
they're
back
in
queue.
C
So,
thank
you.
While
the
slide
comes
up,
it
occurred
to
me
during
the
break
that
I
may
be
defending
the
current
text
a
bit
too
forcefully,
I'm
the
pen
holder
and
it's
it's
your
text.
C
So
what
we
actually
need
to
do
is
try
to
get
some
consensus
on
these
these
points.
That
said,
I
propose
that
we
just
take
tarik
and
reza
on
this
slide
and
then
make
some
movement
through
the
rest
of
the
slides
in
the
hope
of
of
of
getting
through
them,
so
tarek.
D
Trait
adrian
to
thank
you,
you
know
getting
clarity
on
these
things,
you're
doing
a
great
job,
highlighting
what
makes
sense
my
my
question
now
is
about
the
connectivity
matrix
id
and
there
is
a
need
that
to
group
multiple
of
these
connectivity
matrices,
if
you
want
to
call
them
or
the
way
we
call
them
so
that
they
match
a
specific
filter
criteria.
C
I'm
I'm
I'm
hesitant
here
because
you're
moving
from
how
we
describe
the
slice
to
the
customer
and
then
you're
you're
going
from
that
to
how
you
would
actually
start
to
realize
and
deliver
the
slice
in
the
network.
Now
I
I
understand
that
the
second
is
important
and
it
is,
it
seems
to
me
very
likely
that
there
is
a
need
to
group
together
in
delivery,
matrices
or
slices
that
have
the
same
or
very
similar
service
characteristics.
C
A
Thanks
again
for
the
session,
one
comment
and
one
question:
I
guess
from
the
connectivity
type
traffic
that
we
see
here.
It's
also
it's
good
to
consider
that
one
as
two
group
of
unicast
or
multicast,
because,
for
example,
point-to-point
in
this
case
is
unique,
as
whereas
other
one
are
potentially
multicast.
A
So
this
is
one
aspect
that
also
maybe
can
clarify
the
type
of
the
traffic
we
have
and
the
there
was
some
comment
that
we
can
group
it
into
two
categories:
point
to
point
and
point
to
multipoint
and
others
are
the
kind
of
subset
of
that
we
more
or
less.
A
I
think,
in
my
opinion,
this
is
correct
because
at
the
end,
when
I
go
to
my
session
about
mbi
the
modeling,
we
basically
retouch
some
of
this
aspect
that
we
have
here
and
another.
The
comment
is
about
the
connectivity
metrics
when
we
say
metrics,
so
by
definition,
metrics
means
multiplicity,
multiple
role,
that
and
in
this
case
matrix,
if
we
are
clear
about
that
means
and
x
and
y
when
x,
is
sent
there.
Why
is
receiver?
C
Thank
you
yeah.
I
get
you,
I
think.
That's
that's
important
and
you're
also
right
that
getting
alignment
here
with
the
the
nbi
or
the
the
service
young
model
is
also
fundamental.
Yeah.
F
Yes,
just
a
few
comments
from,
I
think
some
of
the
other.
I
guess
discussions
on
mailing
lists
about
this
topic.
So
just
so,
I
I
think
what
was
mentioned
just
earlier.
I
think
the
grouping
of
unicast,
you
know,
flows
and
then
multicast,
but
then
as
well.
F
You
know
having
that
that
delineation
in
the
grouping,
but
then
also
you
know
in
the
description
I
think-
and
it
was
I
think
it
may
have
been
commented
on
as
well
like
when
you
look
at
the
functional
categories
and
then
you
talk
about
c
to
c
so,
like
let's
say
the
network
slice
controller.
You
know
this
is
kind
of
the
overall
provisioning
of
the
slices.
But
when
you
think
about
provisioning
of
the
slices,
the
action
is
happening
on
the
pe,
not
the
c,
but
then
you
have
the.
But
then
you
have
two
pieces
of
it.
F
F
So
when
you
look
at
it,
you
know
just
like
the
definition
of
each
each
one
and
you're
you're
you're
actually
defining
the
pe
role,
but
then
but
then
the
actual
description
has
this.
The
end
point
communication
to
see
you
to
see
communication
matrix.
So
just
a
point
that
you
know
when
you
when
you're
reading
it
it
does
look
a
little
bit
confusing
because
you're
actually
talking
about
the
pe
role
and
actually
provisioning
by
the
controller,
but
then
but
then
you're
actually
talking
about
descending
and
receiving
like
the
end
points,
cen
points.
F
Another
comment
all
certainly
I
think
someone
had
mentioned
like
is
as
since,
when
you're,
when
you
think
of
a
a
single
connection
or
connectivity,
it's
c
e
to
c
point
to
point
and
then,
like.
I
guess
when
you
think
about
a
point
to
multiply
like
say,
multicast
and,
let's
say
like
a
source
to
leaf.
You
know,
sub
lsp
everything.
I
think
the
building
block
of
any
communication
is
a
single
unicast
flow.
F
So,
let's
say
hypothetically:
if
you
took
a
a
single
unicash
flow,
so
like
a
point-to-point
flow
and
use
that
sla
and
slo,
and
then
you
can
actually
use
that
as
a
mirrored
building
block
to
build
really
any
any
point
to
multi-point
or
multi-multi-point
to
multi-point
up
communication
matrix.
C
Yeah:
okay
heard
that
greg.
G
Hello,
I
think
that
well
at
least
my
interpretation
of
what
connectivity
metrics
is
is
not
related
to
data
flows
that
are
traversing
it
so
because,
for
example,
if
it's
point
to
multipoint,
it's
not
restricted
to
carry
only
multicast
traffic,
it
can
be
a
unicast.
G
So
that's
in
in
my
my
mental,
you
know
picture
these
are
different.
C
Yes
and
that's
what
took
us
into
the
the
the
definition
of
any
to
any
in
as
much
as
we
were
trying
to
previously,
we
were
trying
to
represent
that
multicast
flow
in
p2mp,
not
that
not
the
potential
of
unicast
flows.
C
C
I
Yeah,
so
I
think
it's
important
to
really
define
where
the
boundary
is
right
in
point
to
multipoint
c
will
still
be
sending
single
copy,
where
p
might
be
replicating
if
it's
replicated
traffic
think
about
layer,
two
service
and
flooding
right
number:
two,
it's
not
necessarily
traffic.
It's
the
connectivity
model.
You
describe
commonly
known
as
point
to
cloud
cloud
to
pointer
cloud
to
cloud
and
it
defines
sls
and
even
so
you
might
be
sending
traffic
to
everybody.
Amount
of
traffic
in
total
could
be
well
defined
right.
I
C
Yes,
interesting,
yeah,
okay,
I'm
going
to
fold
all
this
in
and
try
to
come
up
with
a
thread
on
the
list
to
to
drive
this
discussion
further.
So
next
slide.
Please
we
finally
made
it
yay
yeah,
so
other
changes
that
happened
in
o5
and
this
will
come
back
still
to
the
whether
we
agree
on
the
definition
of
of
connectivity
matrix.
But
we
had
a
debate
about.
C
C
We
had
then
some
debate
about
what
is
a
service
definition
and
polished
that
the
main
issue
coming
out
of
it
was
the
the
connectivity
per
slice
which
we
just
talked
about
and
what
is
an
end
point,
and
that
was
issue
five,
and
there
was
a
figure
at
the
interim
which
has
found
its
way
into
the
draft
to
define
the
different
possible
positions
of
endpoints
in
ce,
at
the
seize
port
at
the
pease
port
or
in
the
pe,
and
to
add
to
that,
we
added
this
thing
called
an
ancillary
ce
to
catch,
the
idea
of
a
service
function
which
might
be
somewhere
inside
the
provider's
network.
C
More
on
that
later,
we
added
a
figure
on
the
realization
process
and
that
picked
up
some
some
texts
from
med,
joel
and
john
drake.
The
recent
email
exchange
on
that
on
the
list,
which
is
saying
that
these
components
are
fine
in
the
figure.
But
there
need
to
be
some
clearer
text
describing
what
they
are.
So
that's
easy
issue.
Seven
on
the
workflow
was
agreed
to
make
no
further
change,
because
the
workflow
is
pretty
much.
C
These
things
have
to
happen,
but
in
any
order-
and
then
there
are
also
a
couple
of
editorials
in
it-
next
slide-
we're
rumping
along.
C
C
There
are
a
couple
of
emails
review
comments,
kicking
around
louie,
for
example,
sent
comments,
and
that
needs
to
be
factored
in,
and
I
have
this
open
question
on
how
we
define
endpoints.
C
We've
got
endpoints
networks,
slice,
endpoints
customer
edge,
and
I
think
I
want
to
get
down
to
either
service
demarcation
point
or
service
at
another
access
point
service
access.
Point:
sorry,
service,
attachment
point
service.
Attachment
point
is
popping
up
at
the
moment
in
the
ops
area
working
group
where
there's
a
young
model
that
is
intended
to
apply
to
l3sm
and
l2
sm
and
other
services
as
well,
and
it
might
be
really
neat
if
we
could
be
consistent
with
that.
C
What
else
have
I
got
kicking
around
next
slide
is,
is
on
converging
with
8309
and
then
there's
a
slide
for
technology
agnostic
and,
as
I
said,
editorials
from
various
people
and
then
I
think
some
some
worked
examples
for
simple
services
and
mapping.
Those
two
connectivity
matrices
may
really
help.
C
And
this
is
really
about,
do
we
say
nbi
and
sbi,
and
it's
a
long-term
issue
across
quite
a
lot
of
sdn
based
stuff.
Is
that
my
southbound
interface,
maybe
your
northbound
interface
and
and
calling
it
mbi
or
sbi,
can
get
confusing.
C
So
a
proposal
from
med
here
was
to
try
to
align
with
8309
and
and
reference
the
existing
service
models
and
then
use
the
same
terminology
across
all
our
etf
network
level
sort
of
services.
C
J
In
the
ietf
concept,
why
I
mean
there's
a
idf
controller
considered
for
the
network
you're
adding
another
iatf
slice
controller,
even
though
you
have
a
higher
layer
of
slice
orchestrator,
I
just
I'm
trying
to
understand
that
idea
of
network
slice
controller.
What
does
it
do
that
I
can't
get
from
a
orchestrator
or
a
controller
in
the
bottom.
C
So
the
thing
about
orchestrators
is
they
you
get
them
sort
of
at
every
layer,
so
the
figure
on
the
right
here
is
maybe
the
one
to
look
at
and
and
in
this
picture
the
orchestrator
is
up
there
in
customer
space,
so
the
customer
is
working
out
what
slices
they
want
and
then
is
issuing
the
slice
service
request.
C
So,
as
an
operator
you,
you
don't
have
that
slice
orchestrator,
you
have
the
the
service
request,
reaching
your
controller
or
your
well.
I
think
it's
called
the
networks.
Slice
controller
in
in
the
in
the
main
document.
J
C
Yeah-
and
that
is
exactly
the
the
question
and
that's
kind
of
why
the
the
figure
on
the
right-
the
figure
three
bundles,
those
as
all
inside
one
controller
and
then
actually
how
it's
partitioned
in
software
is
kind
of
a
an
implementation
deployment
choice.
C
K
K
You
very
rightly
point
out
that
I
mean
there
are
some
drafts
now,
which
are
the
l3
vpn
network
models
which
are
not
yet
the
device
models,
but
but
they
are
a
network-wide
view
of
how
this
might
get
implemented,
and
then
you
need
one
more
conversion,
as
you
have
the
network
controller
to
say
this
is
what
actually
goes
on
a
device.
K
So,
but
you
know
I
know
it's
maybe
a
little
bit
gimmicky,
but
calling
them
intent.
Model
and
implementation
model
might
be
helpful
because
you
know
not
your
northbound
is
my
southbound,
your
I
mean
you
have
all
these
orchestrators.
So
if
you
say
customer
where
the
customer
really
come
in,
the
customer
actually
might
come
in
even
above
all
this.
K
So
the
idea
that
you
have
a
model
that
abstracts
away
from
the
implemented
implementation
details.
So
if
you
say
here
the
slos,
I
don't
know
how
you
do
it,
but
make
my
network
meet
my
my
slos
or
my
sles,
or
make
their
network
meet
these
assets.
So
in
a
way
you
have
a
thing
that
says
this
is
what
I
would
like,
and
then
you
have
something
that
says
this
is
how
it's
going
to
be
implemented
and
I
think
that's
maybe
a
little
less
sort
of
relative
than
northbound
southbound
or
customer
and
network.
K
L
C
Where
what
we've
defined
in
this
document
is
a
customer
is
the
the
person
who
makes
is
the
entity
if
you
like,
that
makes
the
request
for
the
service,
but
we
can.
We
can
look
at
that
again
and
certainly
the
if
there's
a
robust
definition
of
intent
better
than
what
the
super
working
group
failed
to
do.
Then
we
we
should
certainly
look
at
whether
we
can
glue
that
in
okay,
thanks
kiran.
M
C
N
C
B
So,
actually
I
was
going
to
bring
up
the
same
comment
about
configuration.
We
should
think
of
that
as
bidirectional,
even
though
people
tend
to
say
configuration
is
unidirectional,
but
that's
good.
The
other
thing
is,
I
think
it
would
be
useful
and
the
alignment,
if
you
really
are
going
to
head
to
tight
alignment
with
8309
is
you
know,
look
at
their
use
of
orchestrator
versus
controller
because,
for
example,
they
call
that
middle
box,
another
orchestrator
and
on
one
hand
it's
really
nice
to
be
aligned
with
an
rfc.
B
C
Yeah
point
taken
I'll
talk
to
the
author
of
8309
about
that.
J
Yeah
just
to
confirm
your
thought
on
the
endpoints
you're
right
I
mean
it
could
be.
The
customer
had
the
end
points.
We
can
have
infrastructure
endpoints
an
example
like
a
cudu
can
have
customer
traffic,
but
their
control
plane
traffic
needs
to
be
treated
differently,
so
the
endpoint
could
be
anywhere
right.
It
could
be
in
the
customers
could
be
on
the
operator's
network.
It
depends
on
what,
if
it
needs
any
kind
of
specific
or
special
treatment
than
what's
normally
offered
and
by
the
way-
and
I
know
a
lot
of
people
mention
qos.
J
I
always
think
us
is
always
there,
regardless,
if
you're,
slicing
or
not,
so
that
protection
is
always
there.
I
I
normally.
When
I
look
at
it,
I
don't
attach
qos
to
slicing.
It
helps
within
this
license
scope,
but
I
don't
know
if
it's
some
people
think
qs
is
slicing.
Personally,
you
know
just
my
personal
living.
I
don't
think
it
is.
You
know
one
for
one.
C
Yeah,
okay,
those
are
those
are
both
helpful
points
and
I
think
that
the
the
embedded
endpoint
ties
in
with
jeff's
comment
on
point
to
cloud
and
and
things
like
that
for
the
slos.
That's.
C
C
We
we
certainly
know
that
how
the
service
is
provided
belongs
to
the
the
operator
and
not
the
customer,
and
we
know
that
the
same
service,
in
other
words,
what
the
customer
sees
as
a
service
could
be
provided
in
multiple
ways
according
to
operator
preferences
or
according
to
technology
that's
available,
but
the
traffic
supplied
by
the
customer
is
a
specific
technology
that
is,
it
could
depend
on
the
encoding
on
the
attachment
circuit.
C
And
therefore
there
is
some
form
of
technology,
specific
aspect
of
a
network
size
service
and
the
wrongly
named
attachment
circuits
are
of
a
specific
technology.
So
the
ac
is
part.
If
the
ac
is
part
of
the
service-
and
it
is
in
some
of
our
models,
then
there
is
a
technology
specific
aspect
even
to
the
point
of
the
ac
itself
being
sliced.
C
So
we
have
a
choice.
We
could
clarify
this
by
stating
all
of
these
points,
calling
it
all
out
or
we
could
simply
remove
the
discussion
of
agnosticism,
and
my
preference
here
is
to
say
what's
quoted
here:
the
service
is
agnostic
to
the
technology
in
the
underlay
network
and
leave
it
at
that.
J
So
I
support
your
opinion
because
the
way
you
look
at
it
is
inside
on
inside
the
network,
you
can
use
whatever
you
know
it's
about
the
what's
in
the
house
right,
so
you
can
use
whatever
technology.
You
want.
It's
agnostic,
you
can
do
your
slice
and,
however,
to
receive
that
endpoint,
that's
coming
from
a
different
domain.
J
I
agree.
That's
a
technology
specific.
When
we
were
looking
at
it.
We
were
looking
at
the
f1
interface,
the
n3,
the
n6,
and
you
know,
and
none
of
those
we
were
really
agnostic.
We
were
but
to
your
point
as
soon
as
we
identify
where
the
slides
or
what
is
the
slides,
the
rest
of
it
becomes
technology
agnostic.
So
hopefully
I
said
the
same
thing,
but
I
support
that
view.
K
Go
back
to
the
intent
versus
implementation
intent.
You
want
to
stay
away
from
how
you
do
it.
So
you
say
this
is
my
connectivity
matrix.
This
is
my
requirements.
K
C
Yes,
yes,
I
think,
that's
that
that
was
the
point
of
the
original
text.
Is
it's
just
the
original
text
wasn't
clear
enough
about
where
that
agnostic
boundary
was
so.
I
will
try
to
tidy
that
brilliant.
Thank
you
next
slide,
then,
okay,
so
other
issues,
I'm
going
to
say,
let's
not
raise
other
issues
here
and
now,
because
otherwise
we
will
overflow
please
send
to
the
list.
Then
I
will
also
try
to
capture
what
we've
already
covered
in
this
meeting
as
issues
on
the
list
and
then
next
slide.
C
So
my
plan
is
to
get
another
pass
of
this
during
november
and
obviously
raise
the
issues
that
have
been
described.
There's
enough
going
on
that,
I
think
we
have
to
push
this
out,
probably
by
an
extra
revision,
but
I
think
we're
with
o6.
C
We
will
be
close
to
a
point
where
I'm
calling
on
you
all
to
do
a
a
pretty
thorough
review,
preferably
during
this
calendar
year,
so
that
we
can
start
to
tidy
up
all
of
the
remaining
issues
in
january
and
february
and
maybe
be
ready
for
a
last
call
before
the
next
itf
meeting.
That
would
be
my
hope,
because
this
document
is
kind
of
important
for
progressing
everything
else,
and
if
we
can't
get
consensus
on
it
soon,
we'll
be
slowing
down
our
other
work.
C
C
O
C
O
C
Well,
yeah,
this
is
still
slicing
and
and
since
you
said,
maybe
we
can
squeeze
this
in
at
the
end
and
since
I'm
talking
and
I've
got
the
slide,
I
thought
I
might.
B
Thank
you
very
much
for
running
the
last
almost
hour
and
thank
you
all
to
who
contributed
both
here
and
to
the
work.
It's
really
important
and
we,
you
know,
appreciate
the
timeline
and
pushing
to
get
it
out
and
thanks
again
reza
you're
up.
A
Yes,
okay,
hi
everyone
on
behalf
of
the
co-authors
of
nbi
giraffe,
I'm
going
to
present
lots
of
discussion
that
I'm
going
to
talk
about
is
already
discussing
the
previous
session.
You
know
connectivity,
metrics
and
everything
related
to
that.
So
this
and
the
concern
whatever
is
discussed
here,
is
just
from
the
modeling
perspective.
We
are
not
going
to
go
to
the
deep
dive
of
this
assumption.
Is
the
framework
is
going
to
cover
that
next
slide?
Please,
we
are
going
to
talk
about
connectivity.
A
Matrix
modeling,
water
verb
is
a
kind
of
summary
of
where
we
are
right
now
and
whether
or
not
this
is
agreed
upon,
and
there
are
some
other
the
discussion
that
needs
investigation,
namely
network
slice,
connection
group,
introduction
of
tag
and
how
the
realization
relates
to
the
underlay.
So
these
are
some
of
the
topic
that
will
be
discussed
today.
Next,
please
regarding
the
connectivity
metrics,
so
it's
just
a
kind
of
summary
of
whatever
we
just
seen
so
far.
Why
we
need
connectivity
metrics
why
we
need
multiple
connectivity
metrics
again
from
the
modeling
perspective.
A
A
So
why
we
need
multiplicity
of
the
connectivity
matrices,
so
these
are
two
reasons
that
you
know
it's
kind
of
summary
of
whatever
that
we
deduct
from
the
discussion
mailing
list
and
draft.
It
might
be
more
reasons
or
there
might
be
some
other
reasons
that
some
of
them
is
not
really
included
here,
but
the.
C
A
The
endpoint
on
the
right
hand,
side,
but
potentially
the
slo
is
different
and
we
consider
every
the
technology
a
specific
term
like
crash
of
service
type
of
services.
Everything
from
the
modeling
perspective
is
considered
as
slo
or
sla
in
this
case,
so
the
potentially
there
are
different
slo.
That's
supported
and
two
reasons
that
we
came
up.
Why
we
need
multiplicities
here
and
why
we
need
this,
because
in
the
modeling
that
you
will
see
momentarily,
this
will
be
included.
A
There
are
two
options
to
model
connectivity.
Matrices
next
slide
is
showing
you
the
first
option.
If
you
go
to
a
nexus
slide,
please,
so
this
is
aligned
with
whatever
we
just
discard
in
the
framework
for
the
sake
of
the
argument,
because
they
say
what
is
the
connectivity
matrix?
The
intention
here
is
that
we
try
to
say
they're.
Each
color
is
one
connectivity
metric
so
in
a
single
ietf
network
slice
again
the
assumption
here
is:
we
have
an
only
single
atf
network
slide
service.
It
contains
four
different
connect.
A
Metrics,
each
color
is
one
of
them.
Definitely
each
one
depends
on
the
type
of
the
traffic
they
send.
They
have
multiple
sender
and
receiver.
In
the
case
of
you
know
that
everything
except
point
to
point
everything
else.
It
seems
that
most
likely
our
multicast
traffic,
but
we
have
some
argument
before
that.
It
might
not
be
the
case
but
consider
everything.
First.
First
of
all
connection
is
one
directional.
A
In
the
case
of
red
and
orange,
you
will
see
in
the
picture
that
each
one
has
one
direction
and
the
in
most
cases
each
direction
has
different
slo,
so
multiple
slo
must
be
supported,
shall
be
supported
by
the
model,
because
upper
stream
and
downstream
traffic
most
likely
has
different
slos,
and
from
that
aspect
it
should
be
trivial,
simple
to
understand
that
the
multiple
slo
shall
be
supported
by
the
model,
and
here
the
the
intention
here
is
the
first
option
here
is
based
on
whatever
framework
described
as
a
connectivity
metric.
A
Any
type
of
the
connectivity,
for
example,
consider
the
orange
one
the
single
point
to
point
once
sender:
one
receiver
is
one
connectivity
matrix,
consider
a
matrix
as
one
connection.
This
is
the
first
option.
This
is
what
rate
the
train
will
discuss
and,
on
the
right
hand,
side
connectivity,
metrics
entry.
A
K
Question,
thank
you.
So
when
you
have
the
blue
matrix
on
blue
connectivity
matrix
on
the
top,
I
think
you
tried
to
say
it,
but
I
didn't
catch
it
is
it.
Nse
is
multicasting
through
nfc
nfc
one
is
multicasting
to
nfc
six
and
two
or
is
it
two
unicast
you
know?
Is
it
a
total
of
three
unicast
connections?
A
Or
is
the
point
that
we
try
to
raise?
For
example,
you
can
have
multiple
and
when
I
showed
it,
maybe
the
second
option
that
be
created,
but
in
this
case
we
consider
this
is
considered
as
a
multicast.
One
endpoint
is
sending
traffic
to
us,
basically
from
the
date
of
the
class
perspective.
There
is
that
data
replication.
A
This
is
one
of
the
important
thing
that
again
when
we
define
connectivity
metrics
in
framework,
we
consider
when
there
is
a
replication
in
the
data
path.
It's
a
kind
of
multi-point
or
point-to-point,
multiple
anything
that
has
multi-meaning.
There
is
a
new
progression
in
data
path,
everything
else
which
is
not,
for
example,
point
to
point.
At
the
end
of
the
day,
you
can
have
an
end
to
end
the
multiple
endpoint
on
the
point
to
point,
but
they
are
sending
unicast
traffic.
A
They
all
each
node
can
talk
to
each
other,
but
necessarily
traffic
from
one
node
goes
to
another
node,
and
that
could
be
from
implementation
point
of
view
you
can
have
abandoned,
spoke
or
full
mesh,
for
example,
but
this
is
a
clarity,
clarification
that
we,
the
the
attempt,
was
to
put
it
here.
Whether
or
not
this
is
something
that
foreign
is
going
to
address
it
very
clearly
and
we
bring
it
here.
This
is
just
the
intention
so
far
whatever
he
understood
from
what
were
discussed
in
africa,
I
hope.
K
I
answered
you
did,
but
I'm
still
a
little
confused,
because,
if
you're
trying
to
describe
the
con,
the
slos
for
the
multicast
connection
from
nse
one
to
nfc6
and
nse2
at
the
same
time,
but
there
are
physically
different
distances
different.
You
know
fiber
paths
and
different
all
kinds
of
things.
How
do
you
describe
say
delay
I
mean:
do
you
give
the
minimum
delay
or
because
you
know
the
the
even
though
you're
multicasting
and
replicating
the
traffic,
the
characteristics
of
the
traffic
over
different
parts
will
be
different.
So
how
do
you
model
the
slos.
A
Yeah
good
question
and
if
you
go
back
to
the
right
hand,
side,
the
third
bullet
is
basically
addressing
that,
so
each
connection
can
have
different
slo.
So
whether
or
not
we
consider
that
connectivity
in
this
case
from
nse
one
to
six
as
one
connection
to
an
sc2
another
connection,
you
can
potentially
have
multiple
slos,
but
maybe
this
is
addressing
the
option
too.
If
we
go
with
option
two,
this
is,
there
may
be
clarify.
A
We
clarify
that,
but
values
or
multiple
solos
should
be
supported,
and
I
think
you
gave
just
an
example
of
why
we
need
that
one.
We
want
to
have
different
characteristic
for
each
of
those
connectivity
that
you
see
in
this
picture
with
the
different
potential
slo
they
might
be.
The
same
I
mean
this
is
very
trivial
case,
but
they
might
be
different
as
well.
A
A
Id
that
we
introduced
it
could
be
integer
could
be
a
string
could
be
what
have
you
in
this
case.
The
picture
is
very
similar,
but
just
consider
the
red
connectivity
and
black.
This
is
a
bit
different
from
previous
one.
In
this
case,
the
red
connectivity
matrix
has
multiple
nses,
that's
sending
the
traffic.
A
So
basically
you
have
a
single
red
connectivity
metrics,
and
in
this
case
the
key
is
not
only
than
id,
but
it
is
the
id
which
is
red
in
this
case,
blue
red,
is
that
id
it
could
be
integer
or
could
be
a
string
and
type
of
the
traffic
with
this
one.
Basically,
you
can
address
the
connectivity
block
as
well
between
two
endpoints.
A
You
can
potentially
can
have
multiple
connections
with
different
slos
and
one
example
is
not
the
example.
One
example
is,
for
example,
in
the
orange
for
the
5g.
They
ask
about
having
multiple
keywords
inside
an
end-to-end
network
slice.
This
is
again
one
example
that
why
we
need
a
feature
or
a
characteristic
like
this,
but
in
this
case,
as
mentioned
connectivity
matrix
could
be
anything
I
put
it
blue
red,
but
it
doesn't
mean
necessarily
is
the
a
string.
It
could
be
an
integer,
it
could
be
type
of
the
class
whatever
we
we
can
select
here.
A
P
A
Yeah,
this
is
one
point
and
actually
the
model
that
we
have
in
the
draft
right
now
is
exactly
as
you
mentioned,
the
assumption
here
is:
we
have
a
single
connectivity
metrics
because
of
the
reason
that
you
say
if
a
customer
wants
to
create
connectivity
blue,
why
they
have
to
put
in
this
one
into
network
slice,
one
create
another
network
slice
network,
slash
two
itf
network,
slides
two
and
put
that
one
there.
This
is
exactly
valid
reason,
and
this
is
at
the
group.
A
H
A
Okay,
no
problem,
so
let's
go
to
the
next
question.
The
next
slide.
Please
sorry
the
italo.
We
can
take
your
question
at
that,
so
there
are
other
aspects.
For
example,
there
is
one
discussion
about
the
network,
slice
connectivity
group
and
the
whole
idea
here
is
and
if
there
is
an
endpoint
sending
traffic
to
multiple
other
endpoints,
maybe
the
aggregation
of
the
characteristic,
for
example,
each
one
sends
a
one
gig,
but
accumulatively.
A
A
A
Metrics
next
slide
is,
I
think,
about
the
tag
why
we
need
tag
we
used
to
have
tag,
but
it
was
removed
based
on
some
comments,
so
we
believe
that
co-authors
believe
that
there
is
a
need
for
having
a
tag
which
is
a
kind
of
association,
quote-unquote
between
network
slice,
itm
network
slice
and
higher
layer.
Consumer
again,
this
is
we'll
be
discussing
the
mailing
list,
but
just
that
gives
a
heads
up
that
this
will
be
one,
and
I
think
I'm.
I
have
one
more
slide
at
the
end.
A
So
there
is
a
discussion
about
how
the,
via
from
the
northbound,
the
underlay
information
in
some
cases
will
be
given
to
the
network
slice
controller.
Maybe
the
the
operator,
or
maybe
the
orchestrator
sitting
at
the
top,
knows
how
to
realize
the
transfer
slice
in
the
network
is
this
possible
for
that
to
influence
network
slice
controller,
to
specify
the
underlay
and
how
to
do
it.
This
is
one
aspect
again
it
needs
investigation,
but
I
think
it's
a
good
thing
to
discuss
it.
Whether
or
not
is
needed
depends
on
use
case.
A
This
might
be
relevant
to
our
discussion
and
from
that
I
I'm
done
and
we
need
the
more
distributed.
One.
Q
Yeah,
I
think
in
this
case.
Well
it
doesn't
matter
in
my
opinion,
if
you
allow
this
situation,
when
you
get
a
packet
from
the
asus
link,
you
have
three
three
steps.
The
first
steps
is,
you
have
to
know
which
access
link
the
packet
is
coming
from
the
seven
steps
you
have
to
say
to
understand
whether
the
packet
belongs
or
not
to
nsa
number
four,
and
then
you
have
three
steps.
Q
You
have
to
understand
whether
the
packet
that
goes
from
nsa
number,
four
to
when
I
say
number
eight-
should
go
over
the
red
or
the
black.
So
you
have
three
types
of
criteria
that
you
have
to
configure
for
traffic
classification
while
with
option
one.
You
have
only
two.
You
have
to
understand
the
link
and
then
whether
which
nse
the
packet
belongs
to
and.
C
A
B
Okay,
so
next
up
we
have
tarik.
This
is
the
start
of
the
non-working
group
draft
portion,
we're
going
to
really
try
to
stick
to
the
allotted
time
max
10
minutes,
hopefully
a
little
less
just
because
we've
managed
to
fill
up
all
the
slop
time
with
good
discussion
on
the
working
group
drafts.
So
turk.
D
Okay,
thank
you,
hi
everyone,
I'm
going
to
give
an
update
on
revision,
4
of
the
solution
to
realize
network
slices
in
ip
and
mpls
networks.
I
am
talking
on
the
behalf
of
the
co-authors
and
I
thank
all
of
them
for
their
contribution
next
slide,
please!
D
So
my
update.
Well,
the
agenda
consists
of
the
updates
I'll
go
in
details
about
each
one
on
the
slide
and
then
I'll
close
off
with
the
next
steps.
Next
slide,
please
so
summary
of
the
updates
we
go
before
we
go
deeper
I've
we
went
ahead
and
incorporated
the
new
term
network
resource
partition.
This
has
been
debated
on
the
keys
mailing
list
and
agreed
on
so
we
went
ahead
and
and
incorporated
it
in
our
solution.
D
D
I
will
talk
more
in
detail
about
each
one
of
those
next
slide,
please.
So
it's
a
network
resource
partition,
it's
useful
to
you,
know
flash
some
of
the
terms
that
we
used
in
our
solution
document.
D
First
slice
aggregate,
a
collection
of
packets
that
match
the
slice
policy
selection
criteria
and
are
given
the
same
forwarding
treatment
as
slice
aggregate
comprises
of
one
or
more
ietf
network
slice,
traffic
streams
or
flows.
The
mapping
of
one
or
more
of
such
fro
streams
or
flows
into
an
aggregate
is
maintained
in
the
idf
network.
D
Slice
controller,
the
network
resource
partition,
our
understanding
of
it
is
a
collection
of
resources
that
are
used
to
support
the
slice
aggregate
and,
lastly,
the
slice
policy
is
a
construct
that
enables
the
instantiation
of
the
behaviors
on
the
select
topological
elements.
The
enforcement
of
the
slice
policy
on
those
elements
will
result
in
the
network
resource
partition.
D
D
As
I
mentioned,
we
have
introduced
a
number
of
steps
and
no
no
definite
order.
We're
not
dictating
a
specific
order
in
order
for
realizing
the
itf
network
slice
service
I'll
just
go
over
them
one
by
one,
but
not
in
details.
I'll
leave
interested
parties
to
go
and
read
our
draft
for
the
specific
details.
So
we
talked
about
network
topology
filters,
slice,
aggregation,
mapping,
path,
placement
on
the
specific
topology
associated
with
the
slice
aggregate,
the
slice
policy,
installation
or
instantiation
of
the
network
resource
partition
path,
instantiation,
service
mapping
and
relationship
between
different
network
slice.
D
D
Last
ietf
111
zafar
had
some
feedback
to
incorporate
some
of
the
sr
building
blocks
draft
that
he
had
into
our
draft
and
he
was
he.
He
did
signal
an
intention
to
join.
We
took
from
our
side,
we
took
an
action
item
and
we
addressed
this.
We
did
try
to
incorporate
some
of
the
building
blocks
related
to
sr
in
our
draft
and
we've
given
zafar
a
chance
to
review
the
the
updated
revision
we're
still
pending
any
feedback
from
him.
D
D
We
are
highlighting
that
this
serve
is
not
mandated
by
our
solution,
but
if
it
is
enabled
it
will
allow
us
to
do
or
to
support
multiple
classes
of
service
on
the
same
network,
slice
or
same
sorry,
network
resource
partition,
I.e,
hierarchical
qs
support
for
hiker
goku.
Us
next
slide.
Please.
B
Before
you
go
there,
if
you
go
back
one
sec,
sure
sure
so,
there's
actually
been
a
little
mail.
I
think
about
zafar's
draft
and
it
looks
like
there's
room,
there's
still
not
closure
or
alignment
between
this
draft,
and
is
that
what
zafar's
looking
for,
if
you
can
have
that
discussion
at
play
out,
that
would
be
great
and
feel
free
to
have
it
on
the
list,
and
so
the
working
group
is
understanding.
B
What's
going
on,
but
zafar
at
least
on
email
says
that
there's
more
to
do
and
if
we
have
time
at
the
end,
maybe
we'll
give
him
a
chance
to
talk.
Alright
thanks.
D
In
terms
of
next
steps,
the
author
authors
think
that
the
document
is
ready
to
be
adopted.
We
do
welcome
further
review
from
the
working
group,
and
any
feedback
is
also
also
welcome.
Thank
you.
D
R
Tariq
yeah,
first
of
all,
thanks
for
the
update
solve
some
comments
from
our
site,
and
I
think
one
of
the
one
of
the
major
issues
left
is
about
determining
terminology.
I
think,
following
the
consensus
from
the
discussion,
we
will
prefer
to
use
the
generic
terms
for
the
slice
realization
in
the
end
delay,
so
that
it
is
related
to
the
terminology
like
the
slice
policy,
slice
policy,
topologies,
last
modes
policy
modes,
etc.
R
Another
terminology
I
have
raised
the
comments
in
the
middle
east
is
about
the
slice
aggregate.
I
think
it's.
The
usage
in
the
text
has
been
changed
to
network
resource
partition
from
this
version,
and
I
think
it
is
important
to
clarify
what
it
means
and
also
clarify
where
it
should
be
used
and
how
it
should
be
used
in
the
draft.
D
Thanks
jimmy,
so
let
me
clarify
the
the
the
definition
of
slice
aggregate
in
the
in
the
current
revision.
It's
clear,
the
size,
aggregate
and
network
resource
partition
play
different
roles
and
they
are
distinct
and,
and
it's
cloud
clearly
stated
in
the
draft,
what
each
is,
what
is
playing
the
role
of
each
now?
If
you
still
have
any
ambiguity,
please
phrase
it
and
I
will
try
to
address
it.
Definitely
in
terms
of
terminology
we
did
in
you
know,
align
with
what
the
working
group
has
proposed
in
terms
of
network
resource
partition.
S
Okay,
tariq,
in
fact,
the
champion
from
huawei.
In
fact,
I
proposed
my
comments
about
the
terminologies
slicer
cricket
in
the
middle
east.
So
that's
used.
My
original
understanding
about
celeste
aggregate
is
the
underlay
network
slice,
but,
but
now
it
seems
to
change
to
this
to
identify
this,
the
nicest
network,
slicer
stream-
but
I
I
wonder
the
yeah
I
I
have
this-
is
a
little
confusing,
even
in
your
slides,
you
mentioned
that
that
is
the
slice
aggregate
topology.
I.
C
S
Understand
how
to
define
technology
for
a
group
of
the
streams
of
the
network,
slice
and
the
second
one
I
I
think
that's
the
another
job
to
mention-
that's
the
slice,
aggregated
augmented,
to
cope
with
the
problem
of
the
apn.
I'm
not
sure,
that's.
What's
the
other
scope
of
this,
the
slice
aggregate
is
the
identifier
of
some
of
the
flow,
or
is
it
just
confined
to
some
specific
network
slicing
related
things.
B
B
The
question
on
the
list,
if
it's
not
already
covered
and
to
take
the
response
to
the
list
zafar,
if
it's
super
quick,
please
go
ahead.
If
not,
please
respond
on
the
list.
L
L
B
Better
to
combine
the
documents
and
then
move
to
working
group,
adoption
of
a
unified
document.
So
let's
see
what
happens
with
your
the
work
to
bring
these
two
documents
together
and
again
feel
free
to
have
the
discussion
on
the
on
the
on
the
list.
If
that
helps,
and
thank.
C
T
R
T
R
Okay,
hello,
everyone:
this
is
judo
and
I'm
going
to
give
an
update
about
the
scalability
considerations
for
the
vpn
plus
on
behalf
of
the
co-authors.
Okay,
next
page,
please,
or
can
I
control
it.
R
Okay,
a
quick
recap
of
the
vpn
plus
and
the
vtn
concept.
The
vpn
plus
framework
is
described
in
the
ts.
Enhanced
vpn
draft
one
of
the
typical
use
cases
to
deliver
itf
network
slices
service
and
the
rvtn
is
a
concept
which
consists
of
a
set
of
dedicated
or
shared
network
resources,
and
it
is
associated
with
a
customized,
logical
topology.
R
The
vtn
can
be
used
at
the
virtual
underlay
to
deliver
the
enhanced
vpns
on
vpn
plus
service,
as
shown
in
the
figure
on
the
right
side.
We
can
have
multiple
one
or
multiple
vpn
overlay
services
mapped
to
one
specific
vtn
as
a
virtual
entertain
and
with
the
widely
deployment
of
the
network
slide
services.
The
scalability
of
the
vpn
plus
and
vtn
becomes
an
important
factor
to
consider
in
the
solution
design.
R
R
Okay,
so
here
are
the
proposed
scalability
optimizations
for
the
control
plane.
Basically,
it
is
suggested
that
we
can
use
a
shared
control
protocols,
instance
or
session
among
multiple
vtns,
so
that
we
can
reduce
overhead
for
the
session
maintenance
and
also
for
the
information
distribution
in
the
network.
R
The
second
point
is:
we
can
try
to
use
a
shared
shared,
the
policy-specific
computation
among
multiple
videos
when
there
are
multiple
ideas
which
associated
with
the
same
topology,
they
can
use
the
shared
spf
computation
result
for
the
for
building
their
following
entries,
and
the
third
point
is:
we
can
rely
on
the
hybrid
control
plane
which,
with
the
help
of
the
centralized
controller,
and
that
you
can
use
together
with
the
distributed
control
plane
for
parts
computation
for
the
information
distribution,
so
that
we
can
balance
the
load
between
the
controller
and
the
distributed
control
plane.
R
So
the
general
approach
is,
we
can
use
a
separate
identifiers
to
identify
the
topology
and
the
destination
or
the
past,
and
in
addition,
we
can
introduce
a
dedicated
identifier
to
identify
the
resources
associated
with
the
vtn.
R
Based
on
this
mechanism.
We
can
instantiate
it
in
the
different
data
planes
for
the
ipv6
data
plane.
We
have
proposed
to
use
the
ipv6
hover
hub
extension
header
to
carry
the
vtn
resource
identifier
and
there's
also
a
discussion
in
the
npr
smoking
group
and
other
working
groups
about
how
to
carry
this
information
in
ampere's
data
plane.
R
Okay,
next
page
here
we
summarize
the
updates
in
the
latest
version.
First,
we
update
the
descriptions
in
abstract
and
the
introduction
so
that
it
aligns
with
updating
the
enhanced
vpn
and
also
the
update
in
the
itf
network,
slides
draft.
R
R
R
Then
we
proposed
a
segment
routing
based
vpn
plus
mvtm
mechanisms
in
2018,
and
the
work
has
been
adopted
in
spring
earlier
this
year.
I
start
best.
The
mechanism
is
suitable
for
the
small
or
medium
scale
network
slide
scenarios,
and
then,
after
that,
it
proposes
scalability
considerations
for
vbl
plus
in
early
2020,
and
after
that
we
have
four
updates
in
the
past
20
months,
so
that
we
also
have
the
solution
work
based
on
this
scalability
considerations
and
optimizations
ongoing
in
other
working
groups.
R
R
Then
we
have
the
realization,
based
on
the
vpnt
and
other
technologies
at
the
leaping
plus
framework,
then
for
the
realization
we
can
have
the
either
sr
based
mechanism
for
the
slice
realization
based
on
the
resource,
aware
segments-
and
we
all
can
also
have
this
high
scalability
network
slice-
realization,
based
on
this
scalability
optimizations
and
the
data
plane
resource
identifiers,
introducing
different
data
planes.
R
Okay,
next
page
for
the
next
steps.
I
think
this
document
provides
a
detailed
scalability
analysis
and
optimizations
for
the
control,
plane
and
data
plane
of
the
vpn
plus
and
vtn.
Add
a
complementary
to
the
scalability
considerations
in
the
vpn
plus
framework
and
provide
guidance
to
the
protocol.
Extension
work.
R
We
can
refer
to
the
generic
term
net
resource
partition
in
that
draft,
and
we
can
clarify
that
the
dvd
in
this
document,
in
the
context
of
the
network,
vpn
plus,
is
the
equivalent
to
the
natural
resource
partition
in
the
content
of
itunes
neutralizing
based
on
the
scalability
mechanism.
We
will
collaborate
on
the
protocol,
extensions
based
in
the
different
control
protocols
with
other
draft
authors
for
this
draft.
The
authors
think
this
version
has
been
stable,
so
we
would
like
to
request
for
the
working
group
adoption
on
it.
D
Yeah,
can
you
hear
me
yeah
hello?
Yes,
okay,
thanks
my
question.
I
would
like
to
see
more
alignment
with
the
terminology
that
the
working
group
is
adopting.
D
I
think
you're
right,
raising
that
so
network
resource
partition
should
be
used
instead
of
vtn,
and
I
would
like
to
see
vtn
go
away
before
we
call
this
ready
for
adoption,
and
the
second
point
I
have
is,
I
don't
think,
adding
vtn
id
in
the
packet
or
carrying
the
id
itself
inside
the
packet
is
too
restricted
restrictive
associated
to
the
we
can
have
multiple
mechanisms
or
selectors
to
ma
to
map
traffic
to
one
network
resource
partition
that
you
are
mandating
getting
an
id
inside
the
packet
and
yeah.
D
R
Okay,
maybe
a
quick
reply.
May
I
yeah
regarding
the
terminology,
I
think
we
have
agreed
to
refer
to
the
generic
term,
whether
it
should
be
a
replacement
or
a
reference
that
term.
It
is
determined
by
the
relationship
between
the
slice
work
and
the
between
plus
work,
which
we
can.
We
may
discuss
further
offline
for
the
id
based
mechanism.
As
I
mentioned,
we
can
have
either
the
segment
routing
resource
aware,
seed
based
solution
which
is
suitable
for
the
small
or
medium
sized
network
slices.
R
The
id
based
mechanism
is,
can
improve
the
scalability,
and
I
think
this
is
also
what
you
you
have
described
in
also
the
in
your
draft.
So
both
magnum
can
be
used
in
the
data
plane
right.
B
Okay,
so
we're
out
at
the
end
of
the
slot
I
apologize
to
the
person
in
queue.
I
thought
we
would
have
time
for
them.
If
you
can
take
the
list.
That
would
be
great.
I
will
take
the
discussion
on
working
in
group
adoption
to
the
to
the
list.
B
I
think
if
anyone
who
has
objections,
please
don't
wait
for
the
adoption
call.
Please
start
talking
about
it
right
now
and
the
the
point
on
alignment
is
is
quite
important.
B
The
vpn
plus
can
have
work,
have
scope
outside
of
slicing,
so
you
know
think
about
that
as
you're
doing
your
update
with
that
we're
going
to
move
to
the
next,
it
is.
O
I
think
is
it
tarik
again.
B
D
I
think
I
might,
I
may
give
you
back
some
minutes
here,
but
but
I
don't
see
the
slides
yet
okay,
so
this
is
the
update
on
revision,
two
of
the
slice
policy
inc
data
model
again
on
the
behalf
of
the
co-authors.
Next
slide,
please.
So
the
update
is
straightforward.
This
time
we
did
incorporate
the
network
resource
partition.
D
D
D
Absorb
the
top-level
container
change,
so
these
are
the
two
changes
that
we
had
in
this
revision.
Next
slide,
please.
So
in
terms
of
you
know,
we
always
welcome
further
review
and
feedback
to
the
data
model.
This
is
an
important
data
model
about
sorry
about
the
slice
policy
that
instantiates
the
network
resource
partition
in
the
network
we
request.
We
think
that
the
the
the
model
right
now
is
in
a
good
shape
to
be
adopted
by
the
group,
so
we
request
working
group
adoption.
Thank
you.
T
Yeah
thanks
direct,
I
posted
my
comments
on
the
on
the
chat
as
well.
Regarding
the
terminology
and
right
now
we
say
basically,
the
slice
policy
results
in
the
creation
of
the
network
resource
partition
to
support
slice
aggregate.
So
I
think
this,
like
the
term
itself,
slice
policy
is
not
making
too
much
sense.
T
Now,
since
we
have
like
you,
know
map,
we
don't
map
a
slap,
a
single
slice
here,
so
I
think
we
need
to
re-look
at
the
terminology
once
again
and
even
when
we
look
at
the
yang
model,
this
part
becomes
quite
confusing.
T
So
just
a
comment
that,
like
you
know
not
just
with
this
document,
but
the
document
that
you
presented
earlier
as
well,
that
terminology
is
something
worth
looking
at
and
second
comment
like,
while
looking
at
the
yang
model
in
the
section
about
php,
where
you
are
describing
the
rate
and
shaping,
I
think,
either
we
need
to
add
a
little
bit
more
description
or
maybe
use
references
to
some
other
document
which
describes
those
things
in
a
much
better
way,
because,
right
now,
when
you
read
the
young
model,
it's
not
very
clear.
How
is
this
getting
applied?
T
Like
you
know
this
whole
bandwidth,
how
is
it
getting
applied
to
a
particular
nrp?
That's
not
very
clear,
so,
just
think
about
those
things
would
be
my
comment.
Thank
you.
D
Sure
daruf,
definitely
if
it
is
thin
on
description,
we
were
willing
to
elaborate
and
on
the
terminology,
yes,
we're
opened.
You
know,
at
least
for
the
slice
policy.
We
had
a
discussion
among
co-authors
and
we're
hoping
if
the
working
group
thinks
that
calling
it
another
partition
policy
helps.
We
are
willing
to.
You
know
to
take
that
input
as
input
acceptor.
D
S
D
I'm
not
sure
why
you
want
a
couple.
You
know
the
data
model.
With
I
mean
we
are
aligned
with
with
the
slice
definitions
draft
framework,
and
we,
if
you
have
any
points
that
you
want
to
raise,
feel
free
if
we
are
diverging.
S
D
So
robin
if
you've
read
that
the
the
you
know,
if
you
give
it
a
read,
then
you
will
see
that
we
have
covering
multiple
options,
for
you
know
having
these
selectors
for
ipv6
and
mpls
as
well.
So
multiple
options
out
there.
D
We
have
references
to
where
each
option
is
coming
from,
it's
not
yeah,
so
I
mean
we
can
take
it
offline
and
I
can
point
out
each
okay.
N
N
Yes,
but
the
model
current
model
has
only
one
bandwidth
resource
reservation
for
each
slice
policy.
So
I'm
thinking
when
instantiating
and
network
resource
partition
instance
do
you
think
all
links
in
a
network
resource
partition
instance
all
the
same.
D
So
bo
actually
the
model
allows.
You
know
configuring
different
bandwidth
profiles
for
different
parts
of
the
topological
elements
in
the
network,
and
this
is
the
reason
we
introduced
topological
filters
or
topology
filters,
so
you
can
in
in
the
model,
you
can
say
my
blue
part
of
the
topology.
I
want
this
much
bandwidth
for
this
network
resource
partition
and
in
my
red
admin
groups-
and
this
is
just
an
example-
I
want
a
different
bandwidth,
so
it
allows
you
to
do
that.
N
Also,
regarding
the
like,
like
control
you,
you
use,
you
mentioned
in
the
model
that
there
could
be
have
a
controller
playing
like
mod
mode
and
also
some
data
playing
mode,
but
it
seems
that
network
resource
partition
only
have
controller
control,
plane
and
resource
and
id.
But
I
don't
see
that
there's
some
data
playing
resource
like
associated
with
this
network
resource
partition
there.
D
No,
no,
no,
it
is
a
data
plane
resource
reservation.
I
mean
data,
please
and
data
plane.
Resources
are
part
of
the
data
model
and
I
you
know
I'm
happy
to
point
you
to
that.
D
B
Okay,
well,
thank
you
very
much.
It
seems
like
there's
some
good
opportunity
for
follow-up
on
the
list
and
would
last
the
folks
asking
questions
as
well
as
the
authors,
to
try
to
take
that
you
know
continue
the
discussion.
I
believe
reza
europe.
A
A
But
if
we
look
at
the
general,
the
management
of
the
in
5g
into
a
network
slices
in
this
example
and
as
discussed
in
the
framework
document,
I
think
it's
important
to
understand.
5G
is
one
of
the
applications
or
the
use
cases
of
itf
network
slice
as
a
technology
that
it
was
clearly
defined
in
the
framework
document
that
itf
network
slice
is
a
technology
that
provides
various
use
cases,
one
of
the
use
cases
5g
and
in
a
specific,
in
the
context
of
the
5g,
the
way
that
end-to-end
net
focus
lies
from
the
left.
A
If
you
look
at
the
bottom
picture
from
left,
which
is
your
ue,
it
could
be
your
cell
phone,
your
I
o
or
iot
device
could
be
cc
tv
and
what
have
you
to
the
right
hand,
side
which
is
a
upf
and
which
basically
addresses
the
connectivity,
which
you
need
us
for
that
ue
to
the
network.
So
from
this
perspective
it
is
really
end-to-end
context.
It
has
various
domains,
run,
domains,
transport
domains
and
the
5g
coordinates
to
create
these
end-to-end
network
slides
based
on
the
theory
gpp.
A
This
is
a
kind
of
summary
of
whatever
is
proposed.
There
is
an
entity
sitting
at
the
top
and
you
see
the
acronym
on
the
right
hand
side.
Basically,
there
is
an
orchestrator
sitting
at
the
very
top
which
is
orchestrating
creation
of
end
to
end
and
delegating
it
to
the
access
network,
a
n
to
the
transport,
which
is
idf
network
slice
controller
and
to
the
core,
which
is
sca.
Whatever
you
see,
nssmf
is
basically
the
controller,
so
any
acronym
with
nsm
means
a
n
controller
domain
controller
or
cn
I'm
simplifying
it.
A
There
is
a
title
here,
it
should
say
cnn
slice
identify
and
it
sends
a
request
to
it
network
slides.
This
is
a
discussion
that
we
have
for
last
hour
or
so
to
create
quote
unquote
connectivity
between
them.
So
the
whole
idea
here
is
that
there
is
one
identifier
from
the
3gpp
and,
from
the
end
to
end
context.
It's
called
network
slice,
selection,
ids
and
ssa.
This
is
just
a
32-bit
number.
A
It
has
a
semantic,
but
for
the
our
discussion
consider
that
there
is
an
id
which
is
used
during
the
signaling
from
3gpp
from
the
ue
to
the
network,
which
identifies
the
whole
end-to-end
network
slide
so
from
our
site.
How
we
can
take
from
that
transporter
specific
how
we
can
take
this
id
as
nssai
to
map
it
to
transport,
and
there
should
be
same
question
for
a
n
and
c
n,
but
our
discussion
today
is
explicitly
from
the
transport
perspective.
A
So
if
you
go
to
an
extra
slide,
we
try
to
basically
formulate
this
question
into
more
detail.
So
you
will
see
here
that
for
an
example,
there
is
an
end-to-end
network
slice
with
the
id
at
the
very
top
zero
one.
One
one
is
a
32-bit
number.
As
I
said
it
creates
some
a-n-s
slice
access
network
slice
and
there
is
an
id
allocated.
You
know
what
the
controller
to
that
same
thing.
There
is
some
network
slides.
The
item.
A
Network
slice
will
be
created,
the
id6
and
same
thing
for
the
access
for
the
cn
for
the
core
network.
So
the
whole
idea
here
is,
at
the
end
of
the
day,
am
is
connected
to
the
transport
network
through
the
network
of
pes
and
same
thing,
cn
is
connected
to
bs.
The
idea
here
is
when
the
traffic
from
the
am
look
at
the
data
plane
the
bottom
line
at
bottom
portion
of
the
picture.
When
the
traffic
arrives
from
the
a
n,
it
should
have
some
identifier
this
identified.
A
We
call
it
ida
because
there
is
no
specific
agreement.
What
that
should
be
and
what
the
acronym
should
be,
but
consider
that
one
as
a
itf
network
slice,
internet
working
identification,
that
packet
comes
to
the
network
to
the
pe,
and
pe
knows
how
to
map
that
phone
to
itf
network
slides
with
a
specified
id
again.
We
put
idb
because
we
can
discuss
what
that
should
be.
A
It
seems
that
there
is
a
question
I
can
take
the
question
right
now.
If
it's
related
to
this
slide
kirtaki,
please.
K
So
you're
saying
the
ida
is
in
the
data
plane
in
the
packet,
as
opposed
to
a
conceptual
identifier.
I
mean
it's
possible
that
the
pe
could
say
I'm
going
to
use
a
five
tuple.
You
know
ip
ip5,
tuple
or
incoming
interface
and
vlan
id
to
do
the
mapping
instead
of
having
an
actual
id
in
the
packet.
A
A
This
traffic,
which
is
coming
from
am
to
pe
potentially
will
have
some
identifier
whether
or
not
is
in
the
packet
ip
packet
itself,
because
at
the
end
of
the
day
that
traffic,
which
is
coming
in
3gpp
term,
they
call
it
gtp
tunnel,
but
it's
basically
nothing
but
iep
on
top
of
udp,
so
potentially
that
ip
can
come
with
a
vlan
and
that
vlan
is
identified.
We
are
not
implying
that
there
is
an
id
internal
to
a
packet
and
the
whole
draft
try
to
basically
formulate
the
options
that
we
have.
A
I'm
just
doing
the
time
check
here.
I
I
go
with
the
try
to
finish
the
slide,
and
if
there
is
a
time
we
can
take
question
at
the
end,
let
me
just
go
to
that,
but
it's
very
important
question
that
you
asked
we
are
not
implying
that
there
isn't
a
specific
id
attached
to
the
ip.
What
are
the
potential
solution
that
we
have
is
basically
addressing
the
track.
If
you
go
to
the
next
slide,
please.
A
So
there
are
some
update
that
happens
to
the
version.
Four.
There
are
lots
of
detail
added.
Some
of
the
terminology
which
is
not
really
needed,
has
been
removed
or
revised,
and
I'm
encouraging
people
to
take
a
look
at
this
one.
You
know
there
are
fresh
look
at
the
problem,
especially
we
try
to
align
it
with
the
itm
network,
a
slice
draft
and
basically
simplified
as
well.
If
you
go
to
next
slide,
there
are
some
clarification
about
some
of
these
as
much
as
I
have
time.
A
So
you
will
see
here
that
the
whole
idea
of
the
the
creation
of
end-to-end
network
slice
assume
that
this
is
these
three
colors
that
you
see
here.
There
are
three
end-to-end
network
slices.
The
whole
idea
here
is
when
the
traffic
goes
into
one
of
these,
the
let's
pick
the
green
one.
When
the
traffic
from
the
access
site
comes
to
the
itf
network
slide
server.
A
A
This
is
just
an
example
of
that.
If
you
go
to
the
next
slide,
the
clarification
between
whatever,
on
the
left
hand,
side
the
picture
that
you
will
see.
This
is
the
view
of
the
3gpp
that
there
is
an
orchestrator
sitting
at
the
very
top.
There
are
three
controllers
for
three
domains
for
the
access
for
transport
from
the
for
the
core.
The
terminology
that
we
use
the
attempt
here
is
to
map
it
to
whatever
we
understand.
A
Basically,
from
the
perspective
of
the
the
transport
side,
the
ietf
network
has
a
controller
quote
unquote
that
tnssmf
is
equivalent
of
that,
and
anything
sitting
at
the
very
top
is
just
an
orchestrator
in
our
terminology.
That
entity
is
the
consumer
that
versus
customer.
This
is
one
of
the
the
topic
that
adrian
also
mentioned,
but
at
the
very
end
there
is
an
entity
sitting,
the
northbound
of
the
network,
slice
controller,
and
there
is
something
south
once
from
our
side.
A
Basically,
we
are
addressing
only
whatever
is
happening
at
the
idea:
network
slice
controller
and
this
mapping
is
clarifying
or
mapping
what
we
have.
So
we
have
only
maybe
less
than
a
minute
to
finish
up
the
thought
here.
If
we
can
quickly
go
through
this
slide
next
one
please.
So
there
are
two
ids
itm
network,
a
slice
identified.
So
what
is
that,
based
on
what
another
mention
we
have
to
come
up
with,
that
id
and
also
internet?
A
These
are
the
two
ideas
that
we
have
and
if
you
go
through
the
document,
if
you
go
to
the
draft
now,
it
says
how
we
can
map
these
two
id
together.
One
example
is
whatever
that
mentions,
for
example,
vlan
is
one,
but
it's
not
the
only
option.
There
are
values
options
discussed
in
the
draft
and
the
whole
idea
here
is.
We
are
not
imposing
any
specific.
The
mapping
is
just
trying
to
list
all
the
potential
problem
potential
solution
that
exists
today
and
in
this
context
we
just
trying
to
put
everything
together
and
for
the.
A
If
you
go
to
the
next
slide,
we
are
seeking
more
comments
and
also
the
the
the
real
thing
that
we
are
in
the
reach
to
a
stable
part,
which
we
are
aligned
with
the
itm
network,
slice
draft
the
framework
and
we
are
seeking
for
the
the
next
step
and
potential
adoption.
Thank
you
very
much,
and
I
don't
know
if
you
have
time
to
go
through
one
question:
we
love
the
way,
but
if
it
is,
please
do
it
no.
B
J
J
So
I'll
tell
you
you
need
to
you
know
from
the
picture.
I
see
n6
interface,
I
don't
see
how
it
applies
to
the
f1u.
I
mean
see
the
n3
interface.
I
don't
see
how
it
applies
to
n6
and
f1u.
So
that's
one
thing
to
consider
another
thing
to
consider:
you
might
have
multiple
vu's
talking
to
the
cu,
multiple
ceos
talking
to
upf.
A
A
I
simply
put
it
here,
but
we
can
talk
if
you
want.
We
can
have
more
detail
on
that,
but
yeah.
The
point
is
taken.
Thank
you.
B
And
please
continue
the
discussion
on
the
list.
I
believe
there
was
interest
in
a
pr
and
past
meeting
in
this
document.
We
had
you
know
gotten
some
indication
from
the
working
group
there's
interest
in
this
work.
So
please
discuss
it
on
the
list
and
you
know
I
think
we're
headed
towards
adoption,
but
we're
not
quite
there
yet.
S
Robin
okay
yeah,
this
legend
being
from
huawei.
My
presentation
is
the
framework
for
end-to-end
ietf
network
slicing.
Next
slice.
S
Okay,
here
this
is
the
background.
In
fact,
this
has
been
talked
many
times
in
the
previous
section,
so
here
you
see
the
quickly
so
the
first,
that's
the
there's.
The
cloud
from
the
design
team
define
the
concept
and
the
general
framework
of
ietf
network
slice,
and
also
we
have
this
realization,
based
on
the
vpn
plus
and
the
vpn
plus
and
the
vtm.
S
S
S
S
So
that's
in
the
transport
network
segment,
the
5g
network
slides,
can
be
mapped
to
an
ietf
network
slice
for
the
ietf
network
slice.
It
can
be
realized
with
multiple
domain
vpn
plus
service
and
also
in
the
analyte
network.
The
multiple
domain
vpn
plus
service
is
supported
by
a
multiple
domain
read
here,
which
is
comprised
by
multiple
intra-domain
retunes
in
the
different
domains.
S
S
Okay,
so
here
this
user
just
summarizes
this
identifier,
so
that's
a
user
for
each
domain,
a
local
retune
is
carried
in
the
packet
to
identify
a
set
of
network
resource
reserved
for
the
retain
in
the
corresponding
domain.
We
also
for
the.
We
also
have
this
global
return
id
so
this.
So
this
is
the
global
waiting
id
is
a
global
value
for
spanning
multiple
domain.
It
can
be
mapped
to
a
local
vtm
in
a
corresponding
domain
and
also
for
the
5g.
We
have
this
end
to
end
network
slice
id
as
an
iss
ai.
S
In
the
previous,
the
presentation,
the
interworking
between
the
5g
network
slides
and
the
ietf
network
slice
you
can
use
the
existing
encapsulation,
such
as
the
villa
et
cetera
here.
This
introduces
another
method.
That
means
this
snssi
can
be
directly
carried
from
this
luang
to
the
ietf
network,
slice
then
to
the
mobile
car
network.
S
S
Okay,
I
will
here
this
is
a
requirement
of
the
end
to
end
the
ietf
network
slicing.
So
this
is
a
data
plane,
so
that's
the
id
will
be
carried,
can
be
carried
in
the
data
plane.
S
So
that's
the
the
meeting
id
is
mandatory,
but
for
the
other,
two
ideas
is
optional
accordingly,
so
there's
there's
the
corresponding
the
manager
plane
and
the
controlling
the
extension.
So
that's
used
based
on
the
network
controller.
It
can
allocate
these
ids
and
also
set
up
this.
The
mapping
entries
between
the
global
waiting
id
and
the
local
retain
id
or
user
to
set
up
this,
the
mapping
entries
between
the
global
waiting
id
and
the
5g
under
to
under
network
slicer
id,
and
that's
the
ss
ai
okay,
next
slides.
S
Okay,
so
here
are
these
updates,
so
this
version
is
was
submitted
in
april
this
year.
So
the
updates
of
this
there
are
one
version,
so
we
refine
the
description
of
the
weeping
class
as
we
tune
in
networks.
Less
realization
and
the
new
courses
are
added,
then
there's
some
editorial
change.
Okay,
next
slides.
S
Okay,
so
that's
the
so
here
we
still
use
this:
the
realization
terminology,
vpnplus
and
the
vtm,
so
that's
the
according.
We
will
align
the
terminology.
According
to
the
draft
consensus
in
the
working
group,
such
as
the
network
resource
partition,
we
will
refer
to
this,
the
new
terminology.
S
D
S
A
new
framework
I
mean
so
that's
the
realization
for
the
for
the
realization
framework
for
the
itah
network
slice.
D
I
would
have
thought
it
would
be
covered
by
the
the
existing
network,
slice
framework
or
definitions
draft,
but
I
mean
I'll,
let
the
authors
of
or
the
editor
to
comment
thanks.
S
B
So
I
think
it's
a
good
action
for
the
authors
of
this
document
to
look
to
see
what
text
they
think
is
missing
from
the
existing
working
group
framework
document
and
propose
text
additions
there.
Clearly
some
of
the
text
doesn't
belong
there,
like
the
applicability
of
vpn
plus
I
mean
that
could
go
in
the
vpn
plus
document,
but
you
know
it's
it's
a
rather
short
and
thin
document.
It
would
be
good
to
just
understand
its
applicability.
B
You
know
how
much
of
it
could
be
taken
and
put
into
the
framework
rather
than
have
a
whole
new
standalone
document.
So
that's
a
request
from
the
chair
and
we
could
probably
take
the
response
offline
on
the
list.
If
you
don't
mind,
thank
you
and
with.
O
That
is
it
fun.
Are
you
one
yeah.
H
I
think
yeah,
that's
me,
so
this
is
not
a
slicing
presentation,
so
I
think
I've
gone
past
all
the
slicing
presentations
for
the
day.
So
this
in
this
presentation,
we
are
introducing
a
data
model
draft
for
discussing
topology
filters.
H
The
zero
zero
version
for
this
was
published
before
ietf111,
but
this
is
the
first
time
that
we
are
presenting
it
in
a
working
group
session.
I'm
presenting
this
on
behalf
of
my
co-authors
tarek
krakatian
schiffing,
the
topology
filter
construct
was
originally
defined
as
part
of
the
slice
policy
model,
but
given
its
generic
applicability,
we
decided
to
publish
it
as
a
separate
standalone
module,
as
the
name
suggests.
Topology
filter
is
a
filtering
construct
that
can
be
applied
on
a
native
topology
or
an
or
on
a
predefined
customized
topology.
H
H
This
is
a
an
illustration
of
the
high-level
model
structure.
The
data
tree
includes
a
list
for
topology
filters,
and
analysts
for
topology
filter
sets
the
top
level
container.
That
is
being
augmented.
Here
is
the
networks
container
from
the
itf
network
module.
The
initial
thought
was
to
augment
the
routing
container,
but
it
has
been
rightly
pointed
out.
H
I
believe
it
was
bo
who
pointed
that
out
that
routing
container
is
a
network
element
only
construct
and
and
that
we
need
to
augment
a
top
level
container
that
can
exist
say
both
on
a
network
element
as
well
as
on
a
controller.
So
that's
what
we
have
right
now,
so
the
next
three
slides
they
talk
about
topology
filters,
container.
H
H
This
is
so
the
topology
each
topology
filter
entry
in
the
list
specifies
a
set
of
include
any
include
all
and
exclude
filtering
rules
that
can
be
applied
on
either
the
native
topology
or
a
customized
topology,
the
the
topology
each
topology
filter
entry.
It
may
carry
a
reference
to
the
topology
on
which
the
filtering
rules
need
to
be
applied.
H
H
The
topology
filter
entry
allows
you
to
also
specify
a
varied
set
of
attributes,
as
part
of
the
include
any
include
all
and
exclude
constructs
that
can
be
used
as
rules
to
filter
the
topology.
H
If
the
entry
does
not
carry
any
filtering
rules
and
only
references,
a
specific
topology,
then
the
reference
topology
becomes
your
filter
topology,
as
is
the
topology
filter,
set
construct
it.
This
comes
into
play
when
there
is
a
need
to
create
a
union
of
multiple
topology
filters
and,
as
you
can
see
here,
each
topology
filter
set
entry
carries
a
list
of
topology
filter
references,
so
this
is
still
early
days
for
the
draft.
H
The
authors
do
believe,
however,
that
the
document
is
sufficiently
cooked
to
progress
to
the
next
stage.
But
the
ask
for
now
to
the
working
group
is
just
to
review
the
document
and
provide
feedback.
That's
it
I'll.
Take
questions
soon,.
U
To
compare
and
contrast
with
the
existing
work,
so
you
have
routing
filters,
lots
of
them
in
good
routing
models.
You
have
lots
of
flow
filters
in
bgp
and
then
you
have
this
topology
filter.
Could
you
compare
contrast
and
give
me
examples
where
each
one
fits?
Thank
you.
H
So
the
topology
filter,
the
mandate,
is
very
simple.
I
mean
the
couple
of
use
cases
think
of
any
computation
profile.
Today
we
do
pass
in
a
topology
and
say
computer
path
within
the
topology,
but
say
you
have
a
customized
topology,
and
on
top
of
that,
you
want
to
do
the
computation
only
on
a
filtered
set
of
elements.
H
You
can
apply
a
topology
filter.
You,
the
other
use
case
which
for
which
this
was
originally
put
together,
was
like.
It
was
presented
earlier
with
slice
policy.
You,
if
you
have
a
network
resource
partition
that
has
an
associated
filter
topology.
You
need
some
way
of
saying
this
is
these:
are
the
filtered
set
of
topological
elements
on
which
your
slice
traffic
needs
to
go
through,
so
that
that.
U
H
If
you
can
point
me
to
a
data
model
that
mirrors
what
I've
just
explained,
where
you
can
reference
the
topology
and
say
filter
it
using
so
so
and
so
filtering
rules,
I
I'd
be
happy
to
just
refresh.
U
H
H
I
will
take
a
look
at
those
references
that
you
provided,
but
the
last
time
I
checked,
I
couldn't
find
any
any
data
construct
that
I
could
use
to
apply
on
an
existing
topology
and
get
us.
U
I'm
I'm
asking
a
very
high-level
question
and
my
question
then,
is:
what's
your
background
on
policy
routing
I
I
I'm
I'm
not
trying
to.
U
U
B
B
Yes,
what
you're
focused
on
is
about
routes,
while
what
talking
is
focused
on
is
topologies,
and
maybe
we
should
have
some
references
on
the
list
to
show.
U
B
U
B
And
this
is,
and
we
can
have,
we
can
continue
the
discussion
on
the
on
the
web,
I'll.
B
All
right
with
that,
unfortunately,
dhruv
and
loa,
we
do
not
have
time
for
your
questions
and
the
last
presentation.
So
I
think
we
should
move
on
and
ask
you
to
take
the
question
to
the
list
apologize
for
the
time
management
there.
Okay.
S
Okay,
okay
jamin
from
huawei:
this
is
a
new
topic,
the
intent-based
routine.
Okay,
next
slide.
S
Okay,
so
here
are
these
you,
the
some.
This
is
the
introduction
about
the
background.
In
fact,
the
seamless
imprs
sr
has
been
proposed
to
describe
the
requirement
for
end-to-end
intend-based
paths
spanning
multiple
domain
networks
and
corresponding
the
protocol.
Extension
of
the
bdp
has
been
proposed,
but
we
know
that
the
because
our
seamless
mpsr
the
this
inter-domain
sr
path
needs
to
set
up
according
to
the
pair
a
color
and
a
point.
S
S
So
in
order
to
reduce
the
scalability
challenge
introduced
by
the
intel
domain
routine,
so
that's
this
document
proposed
intended-based
routine
mechanism.
S
So
that's
the
service
requirement
means
the
specific
intent.
Okay,
next
slice.
S
Okay,
so
here
this
is
the
some
the
introduction
of
the
concept,
so
this
first
is
the
color.
So
that's
the
color
is
used
is
defined
in
the
segmented
routine
policy.
So
there's
a
color
is
used.
Is
a
22-bit
numeric
value
that
associated
the
sr
policy
with
the
intent
so
means
that's
the,
for
example.
The
color
means
this
low
latency.
S
That's
for
the
sr
policy.
Okay
under
the
entrance.
This
is
a
new
concept
introduced
by
the
intent
based
routine
mechanism.
So
this
is
the
intrinsic
information
is
carried
in
the
data
plane.
These
are
different
from
the
color
that
means
associated
to
the
sr
policy
in
the
control
plane,
so
that's
used
because
they
both
of
color
and
the
intent,
can
represent
some
of
these,
the
intent
information.
So
there's
a
can
be
mapping
between
the
intent
and
the
color.
S
S
Okay,
so
here
we
can
see
that
the
further
for
the
inter
domain
network,
so
that's
the
for
the
for
the
network
node
at
the
edge
of
the
youtube
network
domain,
the
sr
policy
group
can
be
set
up.
The
sr
policy
group
includes
the
mapping
between
the
colors
and
the
sr
policy
was
specific
in
the
point.
S
So
when
the
package
arrived
at
the
edge
of
the
network
domain,
it
can,
according
to
the
destination
address
in
the
packet
to
search
the
sr
policy
group
that
for
the
underpoints,
then,
according
to
the
intended
information
in
the
packet
map
to
the
color
and
according
to
the
mapping
between
the
color
and
the
policy
to
search,
get
get
to
the
sr
policy.
So
that's
a
considering
the
packet
into
the
corresponding
sr
policy
to
satisfy
the
entrant.
S
Okay,
so
here
this
is
the
color
used
for
the
underlay
network
slice.
So
that's
the
same.
The
color
mapping,
the
the
mapping
between
color
and
the
local
underlay
network
slides
can
be
set
up
in
the
data
plane.
When
the
package
arrived
based
on
the
intended
information
in
the
packet,
it
can
be
mapped
to
the
corresponding
color,
then
corresponding
to
the
net
corresponding
underlying
network
slides.
So
then
we
can
steering
the
traffic
into
the
underlay
network
slides
to
satisfy
the
intent.
S
Okay,
so
there's
the
some
of
the
advantages,
so
this
is
the
scalability.
So
this
is
the
mapping
between
the
intent
and
the
sr
policy
can
be
done
locally
without
the
need
of
other
word.
Has
the
label
binding
for
the
pair
color
and
the
point
to
studied
stitch
the
sr
post
path
in
different
local
domains?
S
A
second
that's
the
use
of
flexibility,
because
the
intent
can
be
satisfied
by
the
different
solutions.
For
example,
the
internet
can
be
satisfied
by
the
sr
policy
or
the
underlying
network
slides
so
for
spanning
multiple
domain.
So
the
one
domain
can
use
the
sr
policy
for
that
intent.
Another
domain
can
use
the
underlying
network
slides
for
the
intent
so
that
we
can
flexibly
to
combine
these
solutions
for
the
same
intent.
So
this
is
achieve
the
advantage
of
flexibility,
lasso.
H
Robin
I've
lost
audio,
I'm
not
sure
if
everyone
else
has,
I
think
we
lost
robin.
I
think
we
are
at
the
top
of
the.
B
Yeah
I
mean
this
is
interesting:
new
work,
I'm
not
100
sure
it
belongs
in
teas
and
unfortunately
that
was.
I
was
going
to
ask
that
as
a
presenter
I'll
have
to
take
the
comment
to
the
to
the
list,
we're
we
are
pretty
much
out
of
time.
I
see
laura,
you
just
joined
the
queue
go
ahead.
B
K
B
I
I
think,
we're
okay
with
it
being
here
for
now,
but
we'll
continue
to
track
and
coordinate
with
the
ad.
We
are,
you
know,
so
it's
early
work.
So
I'd
like
to
hear
more
about
it
and
see
more
discussed
on
the
list.
Okay,.
G
B
Thanks
yeah,
no
thank
you
for
the
comment
given
where
we
are
on
time.
We
should
wrap
up.
Pavand
is
anything
you
want
to
add
before
we
close
or
even
close.
H
No,
yes,
we
had
a
great
meeting
thanks
to
adrian
for
all
the
time
that
he
put
in
yeah.
We
did
ask
for
extra
time
and
I
think
we
managed
to
fill
it
in
yeah
thanks.
Everyone
see
you
next
time.