►
From YouTube: IETF113-TEAS-20220323-1200
Description
TEAS meeting session at IETF113
2022/03/23 1200
https://datatracker.ietf.org/meeting/113/proceedings/
A
I
am
lou
berger
with
me
is
my
co-chair
pavan
and
birum.
We
also
have
luis
contras
in
the
room,
our
secretary,
and
I
think
we
have
enough
people
here
that
we
can
manage
the
session.
But
if
you
experience
any
problems,
please
just
feel
free
to
put
it
in
the
chat.
It's
probably
the
best
way
to
get
attention.
A
I
don't
know
if
I
said
this,
but
welcome
to
teas
at
one
ietf
113.
We
are
obviously
hybrid
we're
the
middle
of
the
week,
so
everyone
is
really
used
to
that
being
the
middle
of
the
week.
We're
also
familiar
with
our
note.
Well,
if
you
are
not
familiar
with
it,
basically
we
have
rules
governing
our
participation.
A
These
the
ones
here
are
mainly
related
to
intellectual
property
and,
basically
anything
you
say
here:
it
becomes
part
of
our
permanent
record.
This
session
is
being
recorded.
Everything
you
contribute
at
the
iepf,
whether
by
email
comment,
even
well.
A
Everything's
up
private
conversations
come
under
the
rules
published
here
if
you're
not
familiar
with
it.
Please
go
to
that
link.
A
There
is
the
meat
echo
tool
for
the
mic
cue.
It
does
help
us
out
if
you
use
it,
but
if
you
don't
luis,
is
in
the
room
and
he'll
help
us
manage
the
queue
remote
participants,
you
know
we're
we're
experts
at
doing
remote
meetings.
At
this
point,
given
the
last
couple
of
years,
the
blue
sheets
are
fairly
automatic,
although
there
is
a
requirement
for
everyone
in
the
room
to
sign
the
blue
sheet
through
the
meat
echo
tool.
A
Please
do
that
for
our
note,
taking
we
are
continuing
to
use
our
collaborative
tools
and
please
join
us
there.
I
did
drop
the
link
in
the
chat
so
that
it's
easy
to
just
go.
Click
on.
It's
also,
there's
also
links
in
the
upper
right
hand,
corner
of
your
screen
for
those
on
echo.
A
We
have
a
pretty
tight
agenda,
I'm
not
sure
we
need
to
go
through
anything.
This
is
published.
I
don't
believe,
there's
been
any
recent
changes
on
it.
So
all
the
material
is
uploaded
thanks
to
drew
for
pointing
out
that
I
uploaded
the
wrong
slide
somehow,
but
that's
all
been
fixed.
A
We
had
one
liaison
that
came
in,
I
think
it
was
just
last
week
yeah
and
it's
interesting,
the
it's
from
the
etsy
nfv
group.
That's
interesting
there
is.
They
think
that
there's
some
gaps
there's
a
document
that
points
to
those
gaps,
gaps
in
work
that
we've
done,
there's
an
expectation
that,
as
I
read
it,
they
are
planning
individuals
are
planning
to
come
participate
here,
as
well
as
there
and
contribute
here.
A
That's
great
one
question
or
comment
to
our
aed,
because
this
came
in
via
email
versus
the
formal
liaison
process,
and
I
don't
know
if
that
makes
this
a
communication
or
a
liaison
or
how
to
handle
that.
But
just
wanted
to
give
you
a
heads
up
that
this
seemed
to
come
outside
the
process.
I
did
check
and
we
do
have
a
liaison
relationship
with
etsy,
not
sure
why
john.
B
Yeah,
do
you
know
offhand
who
our
liaison
manager
is
anyway,
we
should
find
out
who
it
is
and
check
in
with
them.
I
think
I
believe
I
looked
that
up,
but
I
don't
remember
I'm
sorry,
okay,
let's
yeah,
we'll
we'll
check
in
with
them
once
we
figure
out
who
it
is.
A
Yeah,
it
didn't
seem
all
that
critical,
because
the
information
got
here,
they're
not
asking
for
any
specific
action.
It
just
seemed
a
little
bit
out
of
process
and
I'm
not
sure
if
the
I,
I
don't,
really
understand
the
etsy
organization
well
enough
to
say
that
you
know,
maybe
it
had
to
do
with
the
subgroup
that
it
was
a
subgroup
and
not
the
main
group.
C
D
Okay,
hello,
in
fact,
this,
in
fact,
atl
has
another
formal
liaison
with
etsi.
D
A
I
thought
I
checked
and
I
thought
there
was
a
liaison
relationship,
but
either
way
you
know
we're
okay,
because
number
one
they're
not
asking
for
a
response.
Number
two
they're
saying
they're
gonna
come
to
say
here,
which
is
good,
and
we've
talked
listed
this
under
liaison
and
communications
to
cover
just
the
case
where
people
don't
have
formal
relationships.
A
This
is
just
a
reminder
that
if
you
would
like
to
schedule
a
virtual
interim
to
contact
the
chairs,
I
don't
think
that
we
are
looking
for
anything
right
now
between
now
and
the
next
itf.
We
don't.
I
don't
think
we
have
anything
on
our
planning
for
virtual
interim,
but
if
you
participants,
which
one
please
just
contact
the
chairs.
A
Yeah
we
we,
this
new
step,
is
pretty
old
at
this
point,
there's
just
a
reminder
about
our
ipr
process.
I
think
everyone
is
really
familiar
with
it
at
this
point,
all
right,
I'm
going
to.
If
there's
not
any
questions,
we're
gonna
move
to
the
next
one.
E
G
F
There
are
22
working
group
documents
that
are
listed
here,
three
of
those,
the
ones
in
blue
or
on
the
agenda.
Today
we
have
one
document,
the
signaling
extensions
jar
for
smp,
which
is
with
with
the
ad,
so
that
leaves
us
with
18
documents.
The
status
for
each
of
these
18
documents
is
covered
in
this
deck.
F
Like
in
previous
meetings,
I
will
not
be
walking
through
each
and
every
one
of
those
here.
I
will,
however,
double
click
on
a
select
view
that
the
others
believe
are
either
ready
or
close
to
ready
for
working
with
last
call
and
dwell
on
them
a
little
bit
more
for
the
rest
of
them.
You
can
use
your
own
pace,
go
through
the
slides
and
the
reports
that
are
sent
out
to
the
list
and
ask
questions.
If
any.
F
F
The
latest
revision
has
more
details
on
the
applicability
of
service
data
models
to
enhance
vpn,
and
also
it
has
some
text
clarifying
the
relationship
between
vtn
and
nrp.
So
please
do
go
through
it
and
discuss
on
the
list.
If
this
needs
more
clarification,
I
do
hear
a
q.
I
don't
know
if
it's
just
me,
but.
C
F
So
let
me
jump
to
slide
nine.
This
is
the
pcc
use
cases
document
the
authors
have
completed
the
pending
items
and
now,
looking
to
the
working
group
decides
fate.
F
F
This
is
3272
best
document.
We
have
had
a
couple
of
revisions
published
since
the
last
meeting
and
there
seems
to
be
one
more
update
covering
aqm.
That's
ready
to
be
published.
The
editors
is
saying
that
he
has
no
more
changes
to
make
and
we
should
consider
taking
this
to
last
call.
This
is
a
fairly
large
document
and
it
could
definitely
use
some
thorough
reviews
from
the
working
group.
So
please
do
review
it
in
anticipation
of
last
call.
F
The
other
document
that's
ready
is
on
slide
15.
Okay,
this
is
the
young
path
computation
model,
rev
17
was
published
early
in
the
month.
Rev18
just
got
published
yesterday.
The
authors
believe
they
are
ready
for
last
call.
So
please
do
add
it
to
your
list
of
drafts
to
be
reviewed
in
anticipation
of
working
with
last
call.
So
those
are
the
drafts
that
are
close
to
lc
and
that
we
wanted
to
draw
your
attention
to
in
this
deck.
F
H
I
H
H
So
just
a
reminder:
we
had
some
fairly
simple
use
cases.
These
are
sort
of
functional
components
across
a
specific
topology
here
of
sort
of
packet
over
optical
networks
in
the
document
or
if
you've
looked
at
the
latest
dot
document.
H
The
the
main
diffs
really
are
some
reordering
of
the
sections
and
the
subsections
aligning
some
of
the
content,
specifically
to
agreed
scope
regarding
segment
routing
t
end
to
end
more
on
that
a
little
bit
later,
we
also
added
some
sort
of
technical
details
around
insta
link
discovery
as
part
of
the
poi
function,
and
we
are
now
sort
of
putting
substantive
text
into
our
conclusion
section,
which
is
really
the
one
of
the
major
outcomes
from
the
document
is,
is
what
are
the
gaps
if
any,
certainly
we've
had
a
number
of
new
pieces
of
work
that
have
been
sort
of
initiated
from
this
process.
H
So
that's
that's
just
making
sure
we've
kind
of
captured
those
requirements
spun
out
new
documents,
rare
required.
What
we
will
see
in
the
conclusion
document.
Really
sorry
in
the
conclusion
section
in
the
document
is
discussion
on
the
the
poi
capabilities
for
sort
of
discovering
topology
setting
up
the
links,
whether
it's
single
domain
or
inter
domain
providing
capability
from
sort
of
the
underlay
to
the
overlay
network.
H
We've
also,
as
mentioned
sort
of
spun
out
some
new
work
that
included
the
inventory
model,
some
specific
requirements
for
the
path
computation
across
particular
technologies,
as
well
as
some
of
the
discovery
capabilities
that
required
sort
of
to
provide
automation
when
setting
up
ipf
optical
services
and
the
sort
of
the
the
latest
section
or
subsection
in
the
conclusion
summary
of
the
document
is
really
related
to
segment
routing
sort
of
more
on
that
a
little
bit
later.
H
So,
where
are
we
then,
with
our
segment?
Routing
discussion?
H
Well,
there's
been
sort
of
various
email
discussions,
but
but
a
lot
of
this
discussions
happened
on
our
poi
call
and
we
will
we've
had
a
break
on
those
but
we'll
resume
those
after
ietf113
and
the
dates
and
times
for
those
are
at
the
end
of
the
presentation.
H
H
What
we
don't
want
to
do,
of
course,
is
come
to
conclusions,
offline
document
them
and
then
sort
of
bring
them
to
the
working
group,
so
we're
really
trying
to
sort
of
keep
the
working
group
involved
with
these
discussions,
we've
also
brought,
as
mentioned
we've
kind
of
discussed
this
with
various
spring
folks.
H
We
were
considering
sort
of
presenting
these
in
the
spring
working
group
session
later
this
week,
but
the
agenda
was
extremely
busy
already
so
that
there
really
wasn't
sort
of
an
opportunity
to
kind
of
do
that
in
in
any
great
detail.
So
we
need
to
kind
of
handle
that
probably
continuing
that
through
email
and
then
maybe
inviting
some
of
those
folks
to
attend
our
poi
core,
but
but,
as
mentioned,
these
are
sort
of
ongoing
discussions.
H
Another
area
that
that's
really
sort
of
had
a
a
significant
amount
of
discussion
is
regarding
sort
of
our
inter-domain
link
setups.
So
this
is
not
just
sort
of
horizontal,
but
it's
it's
kind
of
vertical
as
well.
So
this
slide
here
really
shows
you
almost
a
process,
although
it's
it
makes
sense
to
look
at
the
figure
when
you're
reading
the
documents
a
little
bit
more
difficult.
If
this
is
the
first
time
you've
seen
this
figure,
but
essentially
the
mdsc
receives
a
request
to
set
up
either
an
l2
or
l3
vpn
service.
H
So
the
ndse
will
look
at
the
requirements
and
then
decide
what
needs
to
be
done
and
specifically
the
order
of
that
to
fulfill
the
service
request
that
it
received.
So
that
may
require
setting
up
a
new
optical
tunnel
itself.
That
would
then
support
an
ip
link
or
a
series
of
ip
links.
H
So
then
the
mdse
will
have
to
send
the
request
to
the
relevant
optical
pncs,
going
back
to
that
sort
of
earlier
figure
that
we
had
of
the
topology
in
order
to
request
that
optical
tunnel
once
the
optical
tunnel
has
been
set
up,
then
the
mdsc
will
wait
for
confirmation
before
it
then
sends
a
request
to
the
pnc
for
an
optical
link
on
multiple
optical
links,
and-
and
this
is
all
relatively
well
described
in
detail
in
the
document,
so
you
can
kind
of
walk
through
that
process,
where
there's
kind
of
a
requirement
either
for
sort
of
static
or
manually
configured
information
or
an
option
to
have
a
a
more
dynamic
method.
H
So
this
may
be
things
like
once
the
optical
tunnel's
been
set
up,
the
pnc
the
physical
pnc
would
then
potentially
be
able
to
automatically
discover
that
this
optical
tunnel
has
been
established
through
a
sort
of
an
adjacency
mechanism,
and
that
would
be
discovered,
you're
potentially
through
something
like
lldp
and
therefore
you
know,
the
new
ip
link
is
configured
automatically.
H
So
these
are
kind
of
the
things
that
we've
been
document
documenting
in
the
draft
and
that
that's
been
the
intention.
I
I
guess
what
we
wanted
to
do
was
show
how
all
of
these
kind
of
yang
models
for
actn,
the
optical
pnc,
the
the
the
packet
pnc,
which
optical
models
would
use
for
the
service
for
the
optical
tunnel
for
the
ip
link
and
so
on
and
so
forth.
H
How
are
they
combined
and
what
mechanisms
mechanisms
are
available
for
automation,
so
the
big
area
that
kind
of
needs
further
documentation
at
this
point
is
once
the
ip
link
has
been
set
up
by
the
the
packet
pnc?
H
How
do
we
then
set
up
the
srte
path
or
if
this
is
already
an
existing
service
that
needs
to
be
sort
of
optimized
or
we
optimized
off
to
some
kind
of
failure
or
protection?
Switching?
How
do
we
reroute
an
existing
srt
path
through
a
different
ip
link,
and
that's
that's
kind
of
working
progress
at
the
moment,
so
next
steps
for
the
document?
H
Well,
those
are
sort
of
the
two
big
areas.
Really.
I
think
that
we
need
to
continue
so
the
srt
discussion,
as
well
as
some
of
the
multi-layer
link
ip
setup.
These
are
documented
via
various
issues
in
our
github
and
in
fact,
we've
got
several
issues.
I
mean
more
than
several
probably
sort
of
actively
around
20
issues.
Most
of
those
are
relatively
minor:
editorial
updates
figure,
adaptions
etc,
but
the
list
of
issues
that
you
see
on
on
on
the
slide
here:
83,
81,
80,
78,
etc.
H
Those
are
kind
of
the
main
issues
and
as
mentioned
you
know,
we
will
continue
to
highlight
these
to
the
working
group
and
also
engage
with
some
of
the
spring
folks.
We
will
resume
our
attn
poi
calls
from
march
29th.
I
believe
we've
had
to
have
two
calls,
as
as
we've
kind
of
mentioned
previously,
because
we've
got
quite
a
number
of
authors
and
contributors
that
spread
across
the
various
sort
of
continents
around
the
world.
So
there's
two
slots
so
hopefully
one
of
those
will
suit
a
time
zone
for
you.
H
We
would
like
to
finish
the
document.
Of
course,
there's
there's
been
some
feature
creep
granted
since
we
started
the
work
that
was
to
be
expected.
H
H
So
we,
you
know,
we've
tried
to
at
this
point
just
sort
of
draw
a
line
under
the
document
itself,
and
I
think
once
we
finish
these
two
sort
of
major
areas
of
discussion
we'll
be
ready
to
kind
of
stabilize
the
document,
maybe
go
through
a
sort
of
text
reduction
exercise
make
sure
that
we
try
to
keep
the
document
as
succinct
as
possible.
H
Then
look
for
working
group
last
call,
probably
certainly
sometime
before
ietf114.
A
Looks
like
we
might
have
some
people
in
queue
or,
as
was
in
the
chat
john
asked
that
we
make
sure
to
say
our
names
before
we
say
anything.
Of
course,
I
just
violated
that
this
is
so
first.
Thank
you.
Please
go
ahead.
J
J
H
I
I
think
that
was
just
essentially
the
requirement
that
we
had
from
some
of
the
authors
and
we
could
look
to
expand
on
that.
It
just
hasn't
been
a
specific
requirement
from
other
people.
We
haven't
seen
it
from
the
working
group,
so
we
just
wanted
to
kind
of
limit
the
scope
of
sort
of
the
use
case
and
the
scenarios
that
we
were
looking
at.
J
My
suggestion
would
be
that
we
can
easily
do
this
by
saying
that
we
are
using
srt
as
an
example
in
the
rest
of
the
document
and
since
ac
tn
procedures
are
anywhere
agnostic
to
it.
Like
you
know,
they
can
be
applied
in
a
similar
fashion,
so
I
think
using
that
kind
of
terminology
would
be
much
better
than
rather
having
a
document
that
only
focuses
on
srt
and
uses
the
name
actin
yeah.
I
do.
I
do
take.
H
Your
point:
it's
just
that
even
by
saying
that
srt
as
an
example,
there
is
still
a
lot
of
sort
of
detail,
minutiae
that
needs
to
be
described
you've,
so
we're
dealing
with
a
lot
of
potential
options,
even
by
just
saying
that
srt
is
the
use
case
that
we're
using
here,
but
I'll.
Try
to
all
the
authors
will
try
to
just
highlight
that
this
isn't
the
only
technology
that's
supported
at
the
higher
layer,
but
it's
the
example
that
we've
used.
A
Yeah,
I
think
that's
a
really
good
comment,
one
that
matches
how
the
stat
the
level
srte
played
in
the
when
we
adopted
the
document.
You
know.
B
A
Was
listed
literally
once
it
wasn't
the
focus
of
the
document,
so
that's
that
readjustment
it
would
be
really
good.
So
thank
you.
Moving
on
in
the
cube.
K
J
G
H
Yep
so
understood
on
that
drew
danielle
and
lou
yeah.
A
And
just
adding
a
little
color
to
that
comment
when
the
document
was
adopted,
I
believe
srte
was
mentioned
once,
as
was
rsvp
mentioned
once
now.
I
think
srte
I
just
did
a
quick
search
shows
up
94
times
and
rsvp
is
still
one
so
yeah
a
detailed
example
is
great,
but
it's
I
think
I
think
the
comment
is
spot
on
group's
comment.
L
Yeah,
the
problem
with
we
face
with
this
document
is
that
there
are
many
options
when
you
start
looking
at
multi-domain
vpn.
There
are
many
options
to
do
them
and
then
you
do
multi-layer.
There
are
many
options
to
multi-layer
and
we
were
a
little
bit
afraid
that
we
are
going
to
explode
on
the
the
set
of
cases
that
we
need
to
analyze.
So
we
said,
no,
all
the
other
cases
are
not
excluded,
but
we
decided
we
we
we
said
that
it's
better,
to
focus
only
on
one
case,
which
is
srt.
F
H
B
You
don't
by
any
chance,
have
the
lower
right,
lower
local
mute
button.
A
A
A
N
Yeah
now
I'm
on
right.
What
happened
was
when
you
I'd
requested,
share,
slides
and
you
granted
share
slides
and
my
mic
disappeared.
N
I
certainly
write
for
asking
I
shouldn't
ever
ask
right
hello:
you
should
have
slide
control
and
we
can
hear
you
so
please
proceed.
Thank
you
right,
so
network
slicing
framework.
The
thing
to
start
is
this
note?
Well
I
there
used
to
be
eight
front
page
authors
all
the
way
through
this
document
and
we
ran
into
a
bug
in
the
itf
draft
submission
tool
where,
having
precisely
eight
authors
caused
the
date
field
to
get
scribbled
on
and
sent
the
submission
failed.
N
N
Right
recent
vision,
revisions,
since
we
held
an
interim
in
teas
in
october
and
devoted
quite
a
lot
of
time
to
discussion,
I
will
not
go
through
all
these
bullets,
but
they've
been
three
revisions
that
were
basically
picking
up
and
clearing
out
the
points
that
were
raised
and
discussed
at
the
interim
and
getting
so
that
zero
eight
completed.
All
of
that
and
included
a
fairly
detailed
editorial
read
through
by
john
drake
and
me
fixing
a
lot
of
knits
and
duplication
that
we
found.
N
So
there
is
a
zero
nine
in
the
buffer
for
submission
soon,
and
I
I
plan
that
this
week
it
includes
a
short
section
on
realization
of
slices
with
respect
to
service
function,
chaining,
which
is
a
a
special
case
and
uses
ancillary
service
demarcation
points,
service,
delivery
points.
Rather
that
text
comes
from
med
and
we'll
sit
down
with
the
other
realization
examples,
and
it's
brief
also
going
is
section
5.4.
N
The
various
prunings
and
tidings
up
made
this
a
really
small
section,
and
it
only
says
what
is
already
in
other
places
in
the
document
so
we'll
take
that
out,
and
I
don't
think
we
lose
anything
thanks
to
john
again
for
finding
even
more
knits.
It
seems
to
be
no
end
to
the
number
of
nits.
It's
probably
because
I
can't
type
and
previously
I'd
forgot
to
acknowledge
kristoff,
so
that
goes
in
0-9.
N
If
you
look
in
the
hedge
dock,
I've
got
some
additional
material.
That
was
not
on
the
sides,
because
it's
happened
to
too
recently.
N
There's
a
further
change
there
planned
for
09,
which
was
discussed
on
the
the
mailing
list.
It's
an
extra
sentence
going
into
4.1.2
on
sles,
to
mention
the
realization
or
how
the
operator
realizes
a
slice
may
itself
be
an
sle,
and
this
is
especially
because
of
the
case
of
multicast,
where
apparently,
customers
like
to
tell
the
operator
how
to
deliver
the
multicast.
N
Of
course,
the
customer
may
have
no
way
to
know
whether
this
is
actually
done.
There
was
some
text
sort
of
about
this
in
zero
seven
and
it
got
lost
in
the
editorial
tidy
up.
So
that's
going
back
in.
N
Okay,
that's
zero.
Nine!
Then
we've
had
some
recent
discussions
on
the
list
which
I
think
are
resolved.
One
of
them
was
how
is
hub
and
spoke
reflected
in
the
service
and
the
realization.
N
This
text
was
in
and
then
out,
and
so
it's
now
going
back
in
a
provider,
may
use
hub
and
spoke
to
realize
a
slice
if
they
like,
and
a
customer
that
wants
to
control
the
hub,
may
build
a
hub
and
spoke
themselves
out
of
p2p
and
p2mp
connectivity
constructs
where
the
hub
is
actually
a
customer's
device
or
they
could
use
a
real
or
ancillary
service
demarcation
point
as
the
hub.
N
I
don't
want
to
be
accused
of
calling
consensus,
but
it
seems
that
the
overwhelming
view
on
the
list
was
that
the
scope
must
include
any
use
of
network
slicing
but,
of
course,
take
advice
from
the
5g
use
case,
because
it's
important
our
related
issue
was:
should
this
draft
be
limited
to
slicing
only
ipmpls
networks?
N
The
realities
and
discussions
of
how
to
slice
sub-ip
networks
then
belong
in
other
places
and
their
realization
questions
rather
than
framework
or
service
questions
so
related
to
those
two
points.
There
may
be
some
specific
questions
the
sea
camp
chairs
want
to
raise,
but
these
are
the
these,
I
think,
are
the
questions
to
tease
and
not
to
the
editor
of
the
document,
and
I
see
danielle
in
the
queue.
So
perhaps
now
it's
good
time
to
take
it.
K
Thanks
again,
yeah,
actually
I
mean
two
of
the
specific
questions
and.
N
Well,
this
this
really
sucks.
I
see
that
yes,
lou
has
just
typed
at
me.
My
audio
is
broken
and
funnily
enough.
Yes,
it
is
because
I
can
see
who's
talking,
but
not
here.
K
I
I
can
take
the
comment
and
then
the
typo
you
type
it
on
the
chat
for
adrian
after
so.
The
thing
is
that
we
identified
some
some
questions
from
c
camper
to
teaser.
Probably
the
two
most
relevants
are
the
ones
that
they
didn't
just
described
on
5g
and
limiting
slicing
it
to
apm
pls
networks.
K
Other
questions
were
brought
to
the
mailing
list
by
igor,
so
I
don't
know
if
you
want.
We
can
do
a
summary
of
those
questions,
but
I
would
say
that
they
have
already
been
discussed
pretty
pretty
extensively
so
up
to
you.
If
you
prefer
us
to
send
a
a
new
email
summarizing
the
questions,
we
will
do
that.
Otherwise
I
think
we
are
satisfied
with
the
the
answers
that
we
received
so
far.
A
Yeah
I'd
say:
if
you're
satisfied
with
the
answers,
there's
not
much
to
discuss,
so
we
don't
have
to
discuss
it
again.
Okay,
in
terms
of
the
it
sounds
like
there's
answers,
you're
not
happy
with
by
the
way,
I'm
getting
great
after
that.
A
If
there's
answers
you're,
not
the
question,
you're
not
happy
with
the
answers
with
which
ones
are.
Those
are
the
ones
on
the
slides
here
for
something
else.
K
A
And
I'll
point
out,
even
though
he
doesn't
hear
us,
so
it's
good
that
he
doesn't
hear
that
he
has
this
power.
It
is
the
job
of
the
editor
to
capture
what
they
believe
is
the
consensus
of
the
working
group
in
that
document.
So
he's
done
just
fine
here
from
our
our
standpoint
and
we
appreciate
that
I'm
gonna
tell
him
that
he
should
continue
going
and
and
then
at
the
end,
we'll
figure
out
how
to
deal
with
his
audio.
N
Right
most
peculiar
way
of
communicating,
I
hope
that
that
that
was
an
interesting
conversation
that
you
had
and
I
will
listen
to
the
recording
afterwards
to
find
out
what
it
was
about
all
right.
There
was
a
question
about
whether
we
should
include
worked
examples.
This
question
has
been
around
for
a
while,
but
nobody
actually
coughed
up
any
text
and
apart
from
med
who
pointed
me
at
some
text
from
8969,
that
could
be
useful.
N
E
Yeah,
I
would
like
just
to
comment
that
there
are
some
other
documents
starting
to
to
describe
some
potential
examples.
In
my
case,
I
will
present
later
on
one
of
how
to
map
in
three
bps
places
to
be
it's
called.
Idf
is
less
sorry,
so
probably
that
word
could
be
or
either
integrated
or
keep
it
apart,
but
there
will
be
some
documents
discovering
that
I
think.
A
I
have
to
say
that
was
so
low.
I
couldn't
really
catch
it,
I'm
hoping
did
you
catch
it.
F
Yeah
he
said
that
he
there
are
other
documents
where
examples
are
being
specified.
One
of
those
documents
is
being
presented
later
on
today,
so
I
guess
his
preference
is
not
to
I
mean
I
guess
he's
leaving
it
to
the
working
group
to
decide
if
it
needs
to
be
discussed
separately
or
somehow
roll
it
into
an
app
index
into
this
document,
but
yeah
the
point
is
making.
Is
it's
been
discussed
in
some
other
documents?
A
A
O
I
The
first
question
is
whether
or
not
it's
helpful
to
have
examples
answered
in
my
opinion,
is
yes
and
I
can
volunteer
to
write
down
something
about
5g,
because
there
are
lots
of
discussion
about
5g,
and
I
felt
that
it
is
good
to
have
a
good
example
of
5g,
at
least
to
have
the
same
context
for
everyone,
because
people
talking
about
that.
But
the
context
might
be
different.
So
I
volunteered
to
do
that.
One
and
I
talked
to
adrian
about
it.
A
N
Yeah,
so
so
please
reza
and
kieran
and
lewis
drop
me
a
mail,
and
we
can
talk
about
what
type
of
example
we're
looking
at
and
whether
the
how
to
map
5g
is
is
a
good
or
a
bad
solution
right
at
this
point,
I
just
want
to
draw
your
attention
to
the
five
extra
threads
that
have
come
up
in
the
last
couple
of
days
on
the
mailing
list.
N
I've
put
those
summary
of
those
into
hedgedock
as
well.
N
The
first
of
them
is
just
to
re-highlight
that
a
service
is
not
a
realization
of
the
service,
and
this
is
my
usual
rant
about
the
fact
that
l3
vpn
has
confused
the
service
delivered
to
the
customer
with
the
technology
used
to
realize
the
service,
and
since
his
point
keeps
coming
up,
we
should
perhaps
include
a
brief
piece
of
text
on
the
subject
in
the
draft
right
just
to
help
make
it
clear.
N
I
don't
believe
that
there's
a
need
for
us
to
make
any
change
in
what
we've
got,
but
I'd
be
happy
to
hear
otherwise,
there's
a
really
active
thread
on
receiver
slos,
and
I
don't
believe
that
we've
reached
a
point
where
we
can
draw
a
conclusion
from
that.
N
So
please
contribute
to
that
discussion
and
that
may
lead
on
to
the
idea
of
a
group
slo,
whether
it's
an
slo
that
applies
to
these
to
a
set
of
connectivity,
constructs
and
then
most
recently,
there's
a
start
of
a
thread
on
multiplexing
and
I
need
to
push
on
that
a
bit
more
because
I'm
not
quite
sure
which
bit
of
multiplexing
what
and
where
in
the
network
that
applies
so
watch
out
for
emails.
On
all
of
these,
which
takes
me
then
to
my
last
slide,
which
says
I
will
be
posting
0.9.
N
We're,
probably
not
quite
done
yet,
because
there
are
those
five
issues
to
be
pushed
through.
But
at
that
point
I
think
we
might
be
ready
for
last
call,
and
I
will
now
stop
talking.
B
Okay,
thank
you
adrian.
M
M
I
believe,
and
I'm
not
sure
whether
I
probably
it's
not
this
document,
but
that
is,
in
my
view,
a
need
to
describe
the
realization
aspect
in
an
abstract
way
without
going
into
the
technology
as
such,
because
there
is
a
layer
in
between
that
is
important
that
I
does
what
I
call
multiplexing
and
mapping.
Maybe
there
is
a
better
technology,
but
I
believe
that's
important
now.
The
question
is:
how
would
that
be
in
a
separate
document
that
is
detached
from
it,
but
associated
with
it
before
we
go
into
the
specific
technology
implementations?
I
Okay,
so
we
can
go
to
the
next
draft,
hello,
everyone,
my
name
is
cui
I'm
from
siena
on
behalf
of
my
co-authors
bo
drew
and
trek,
and
tarek
and
luian
I'm
going
to
present
you
the
young
model
for
the
ita
network
slice
services.
Next
slide.
Please
just
remind
the
just
a
reminder.
What
we
try
to
do
here
is
if
we
consider
the
itf
network
slice
service
controller.
I
There
is
a
northbound
which
is
a
technology
agnostic.
It
receives
a
request
to
create
an
itf
network,
a
slice
service
with
a
specific
characteristic,
as
adrian
mentioned
in
the
previous
draft,
and
we
have
a
southbound
which
is
a
technology
specific.
We
want
to
implement
it
on
an
ip
or
mpls
or
optics
or
other
technology.
I
This
document
is
going
to
talk
about
the
former,
the
northbound
interface
that
we
have
and
we
had
the
really
the
one
you
will
see
here
that
what
are
the
main
changes
that
happen?
I
assume
you
already
read
the
first
draft
or
the
this
draft.
You
already
know
what
the
context
here
is.
What
is
the
structure
of
the
draft
trying
to
say?
I
One
thing
that
we
did
is
we
aligned
the
network
slice
connection
with
the
definition
of
the
connectivity
construct
that
we
had
the
whole
idea
of
these
changes?
Are
we
want
to
make
sure
that
we
adhere
and
follow
the
framework
suggestion?
Whatever
framework
is
discussing
in
terms
of
the
structure
in
terms
of
the
terminology,
we
are
going
to
reflect
it
here,
and
these
changes
that
you
you
see
here
is
basically
the
reflection
of
that
fact.
I
We
also
introduced
the
context
of
the
network
connection
network
slice,
connection
groups,
the
whole
idea
of
the
grouping,
some
connection
which
have
the
same
characteristic
in
terms
of
the
slo
and
sle.
This
is
introduced
and
the
as
you
see
here,
the
network,
slice
type
and
ep
roll.
These
are
removed,
but
the
one
thing
that
we
didn't
do
that
one
in
this
draft
is
changing
the
network
slice
endpoint
to
stp
that
right
now,
that
term
is
used.
We
are
going
to
do
that
one
in
the
next
list.
I
I
We
introduced
that
one-
and
this
is
in
our
our
opinion-
is
a
good
tool
to
address
lots
of
the
discussion
that
we
had
in
the
mailing
list.
I
For
example,
there
was
some
question
that
how
we
can
introduce
some
aspect
of
the,
for
example,
customer
name
for
some
application
like
5g,
how
I
can
specify
the
network
slice
id
which
is
coming
down
if
there
is
a
big,
if
here
that,
if
we
want
to
somehow
the
higher
layer
knows
about
some
type
of
the
realization
that
we
want
to
do
in
the
network,
it
knows
that
we
want
to
use
layer,
2
or
layer
3..
We
can
use
this
stack
to
just
reflect
that
fact.
This
stack
is
optional.
I
If
you
don't
want
to
use
it,
don't
use
it,
and
this
is
a
network,
slash
controller's
job
to
address
all
those.
But
this
is
a
very
good
extensible
approach
that
in
the
future,
if
you
want
to
add
anything
else,
we
can
just
do
that
one
and
we
design
the
yang
model,
which
is
extensible,
and
there
is
no
need
for
augmentation
of
any
sort.
I
And
last
but
not
least,
we
add
some
action
about
the
accessport
access
connection
between
c
and
pe,
and
you
can
go
through
the
detail
of
that.
Something
was
added
here,
and
these
are
basically
the
reflection,
the
overall
reflection
of
the
changes
that
has
been
done
in
release
one
next,
please,
as
the
scene
here.
The
idea
of
the
network
construct
modeling
there
are
three
type
of
the
connection
is
described
in
the
framework
point
to
point
point
to
multipoint
and
any
to
any.
I
Nse
is
basically
the
sdp,
the
access
port
that
the
the
connectivity
between
the
any
two
nses,
and
there
are
one
direction
as
you
see
some
of
them,
then,
for
example,
point
to
point:
if
I
want
to
have
that
bi-directional
connectivity,
I
have
to
define
both
and
why
we
did
it
this
way,
because
in
some
example,
for
example,
the
the
donor
stream
and
upstream
traffic,
they
have
the
different
sla
and
slo
from
that
earthquake.
I
I
This
is
another
example
of
for
whatever
adrian
mentioned
before
that.
If
we
want
to
have
some
example
to
a
concrete
example
to
show
what
we
want
to
do,
the
overall
picture
shows
that
I
have
a
network
of
slice,
1
and
s1,
which
contains
three
group
of
connections,
connection,
blue
red,
green
and
think
of
color
as
the
slo
and
sle
that
that
connection
wants,
whatever
it
is.
So
the
whole
idea
here
is
each
connection
that
we
have
here.
I
It
has
a
type
and
it
has
an
slo
that
basically
carries
and
from
that
aspect
you
can
extend
this
one
to
any
number
of
the
connection
that
you
want
to
do,
whether
or
not
it
is
applicable
to
any
specific
use
case.
It
depends
on
the
use
case
for
some
of
the
use
case.
It
doesn't
make
sense.
We
have
to
have
only
one
of
them,
but
from
the
modeling
perspective,
we
should
allow
that-
and
this
is
exactly
what
has
been
done
next,
please,
there
are
few
issues
that
it
still
is
in
progress.
I
I
will
go
through
that
one
slight
pair
issue
that
we
have
one
was
the
network
slice
group.
As
I
mentioned
the
whole
idea
of
the
grouping
the
network
is
licensed.
You
know
we
want
to
see
some
other.
The
type
of
harvard
spoke
adrian
talked
about
that
as
well.
You
want
to
see
if
it
should
be
added
there
and
also
adding
connectivity
type
at
the
network
layer
as
a
connection
layer,
for
example,
in
the
previous
example.
If
the
green
is
point
to
point,
there
is
no
need
to
specify
the
type
for
each
connection
you
can
specify.
I
Green
is
point
to
point
and
everybody
will
inherit
that
those
type
of
things
we
want
to
add-
and
this
was
some
suggestion
from
the
mailing
list-
that
we
thought
it
it
is
valid
and
it's
going
to
be
added
to
the
next
release.
Next,
please.
I
The
second
one
is
a
four-wall
import
of
rfc
9181,
which
is
the
discussion
about
the
common
young
model.
I
Going
to
the
next
issue,
adding
a
statistical
parameter,
for
example,
for
the
slo.
As
you
see
here,
the
the
current
slot
that
we
have
is
clearly
you
see
here,
and
the
whole
idea
here
is,
as
the
framework
goes
to
the
next
the
version,
and
if
there
is
anything,
will
be
added.
The
proposal
has
that
we
are
going
to
add
it
into
the
framework
and
in
most
cases
the
yang
model
is
defined
in
such
a
way.
That
is
extensible.
There
is
no
need
really
to
do
the
augmentation.
I
If
I
summarize
for
us,
the
nexus
service
at
least
address
these
three
issues
that
I
mentioned
to
you
and
including
the
I
didn't
mention
that
sdp
to
nse
now
one
of
those,
but
that
one
should
be
also
part
of
that.
I
And
there
are
two
that
the
last
two
it
was
mentioned
by
tariq
a
few
days
ago
that
we
want
to
align
the
terminology
for
the
access
port
with
the
document
that
we
already
have
and
clarify
the
concept
of
the
access
point
node
id,
because
there
was
something
that
we
use
at
two
eyes
and
for
the
multi-homing,
how
it's
going
to
be
others
so
longer
story,
show
three
issues
plus
a
couple
of
them
that
I
mentioned
here.
I
G
Okay,
hello
hi:
this
is
kiriti,
so
there
are
several
points
you
made
one.
Is
you
call
it
the
vpn
type
for
the
access?
G
And
I
like
that,
it's
there,
but
I
I
would
prefer
that
you
said
something
like
the
layer
of
the
access
layer,
one
layer,
two
layer,
three
as
opposed
to
vpn
type,
because
if
there's
a
layer
two
for
example,
you
might
just
say
it's
a
vlan
or
it
might
be
a
vpls
or
it
might
be
evpn.
G
So
I
don't
want
to
get
to
the
specifics
of
the
especially
in
the
northbound
model,
just
say:
I'm
connecting
at
layer
2,
I'm
connecting
in
layer,
3
or
maybe
I'm
connecting
at
layer
1.,
that's
just
a
suggestion
in
the
southbound
you
might
say.
Oh,
I
would
like
to
make
this
vpls,
but
in
the
northbound
from
a
higher
level
point
of
view.
Just
I
want
a
layer,
2
connection.
I
G
Using
that
common
yang
model,
I
like
the
idea,
but
I
think
it
was
written
so
that
it's
common
between
the
two
vp
and
l2
vpn
and
lcvpn-
you
may
you
know
if
it
works
great.
If
it
doesn't
work,
you
might
want
to
extend
it
and
say
this
is
a
common
model
to
you
know
to
be
across
different
types
of
things,
but
from
what
I
remember.
This
is
primarily
to
make
sure
that
the
l2
and
l3
vpn
the
network
models
have
these
in
common.
I
Sure
that
is
a
valid
point
and
there
was
another
that,
along
the
same
discussion,
the
drew
also
mentioned
that
if
we
can,
if
we
can,
for
example,
not
able
to
use
that
we
can
in
our
model
separate,
we
have
the
same
concept
of
putting
two
young
models,
maybe
in
one
file,
but
the
two
one
is
common.
One
is
a
specific
and
in
the
future,
people
can
use
that
common
model
that
we
have.
That
is
also
another
way
that
we
want
to
see
if
it
is
possible.
I
But
your
point
is,
is
valid
is
taken
and
we
consider
that
great
and
then.
G
You
have
that
diagram
with
three
types
of
connections
all
in
the
same
slice-
maybe
red,
green
and
blue
or
red
this
this
one.
So
I
was
wondering
when
I
saw
this.
If
there
are
common
things,
can
you
sort
of
abstract
the
common
things?
For
example,
they
all
have
the
same
bandwidth
and
not
bandwidth.
They
have
the
same
latency
requirements,
but
they
have
different
bandwidth
requirements.
I
Work
together,
basically,
in
this
example,
we
have
three
connection
groups,
blue
red
green.
So
this
is
a
connection
group.
I
think
if
you
want
to
go
that
in
my
opinion,
it
might
be
possible,
but
we
make
the
model
very
complex.
We
want
to
make
sure
that
when
we
say
blue
blue
is
blue,
whether
or
not
if
they
are
the
same
way,
you
have
three
of
them
just
put
everything
into
one.
So
the
whole
idea
is
from
implementation
perspective.
I
We
don't
want
to
be.
They
try
to
go
through
all
detail
of
a
specific
slo
one
vibram,
and
so
these
are
the
same.
Let's
put
it
somewhere.
If,
as
a
operator,
you
decide
to
make
connection
three
of
them,
you
do
it
and
they
are
sort
of
independent
from
the
modeling
perspective,
and
I
think
it's
very
simple
and
at
the
same
time,
very
clean
design,
instead
of
rather
to
put
very
complex
logic,
to
put
some
a
specific,
you
know
together
so
from
that
last
week.
I
think
it's
better
to
keep
it
this
way.
Okay,
okay,.
G
G
I
It
might
be,
but
this
is
mainly
the
question
for
adrian
for
framework,
not
this
one
we
are
just
importing
whatever
is
defined.
Whether
or
not
this
is
the
case
might
be
not
slo
but
sla
service
level.
Expectation
is
exactly
those
thing
that
you
cannot
necessarily
measure
them.
It's
like
security
isolation,
those
type
of
things.
This
might
be
another
one.
They
say
I
need
some
sort
of
protection
and
again
depends
under
what
we
want
to
put
the
frame
or
it
it's
a
valid
point.
Yes,
it
is
valid,
but
it's
not
relevant
to
this
document.
A
Yeah,
so
we
have
one
more
question
in
the
queue
where
over
time,
we
should
take
that
question
and
then
stop
and
take
our
break
because
we're
going
to
get
cut
off
at
some
point
greg
go
ahead.
P
I'm
much
appreciated
that
you
read
the
pointing
to
their
protection.
I
have
somewhat
different
view.
I
think
this
is
how
something
can
be
realized
and
let's
discuss
it
on
a
mailing
list
in
a
separate
thread
details,
but
I
think
that
their
protection
is
something
that
operator
can
use
whether
redundancy
or
control,
plane,
service,
restoration
and
not
necessarily
needs
to
be
exposed
to
their
client.
Thank
you.
Okay.
A
Thank
you
all.
We
will
see
you
in
less
than
half
an
hour
looking
forward
to
continuing
the
good
discussion.