►
From YouTube: IETF112-TEAS-20211109-1430
Description
TEAS meeting session at IETF112
2021/11/09 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
Hello
all
welcome
to
teas
at
ietf
ietf112
virtual,
I'm
blue
burger.
We
have
with
us
vishnu
pavon
biram
co-chair
as
well
as
our
secretary,
our
news
secretary,
luis
contreras.
We
really
appreciate
luis
being
willing
to
serve
as
secretary
and
continue
on
the
tradition
that
matt
laid
out
of
really
being
very
helpful
behind
the
scenes,
so
welcome.
Luis
pavan
has
already
put
the
link
into
for
hedgedock.
If
you
could
join
us
there,
we
really
appreciate
it.
A
A
This
is
all
covered
under
the
note
well,
and
we
have
a
set
of
bcps
of
documents
that
cover
how
we
operate,
and
notably
related
to
contributions
to
the
ietf
intellectual
property
and
next
slide
and
a
piece
that
that
the
isg
has
asked
us
to
really
highlight
it
was
on
the
previous
slide,
as
we
always
mention
it,
but
really
want
to
highlight
code
of
conduct
and
that
it's
we've
had
a
very
a
long-standing
document,
long-standing
practice
for
how
we
should
treat
each
other
with
respect
and
courtesy
and
be
professional.
A
And
it's
you
know
it's
okay,
to
have
heated
arguments
but
keep
it
technical
and
and
keep
it
on
on
the
topic,
and
the
isg
is
asked
to
highlight
this
you've
seen
discussions
on
the
ietf
list.
So
you
know
it's
an
important
topic.
A
A
You're
on
media
echo
right
now,
so
you
have
found
us.
Thank
you
for
joining
us
today,
and
our
blue
sheets
are
automatic.
A
A
I
mentioned
earlier
hedge
dock
code,
emd,
whatever
it's
being
called
today
for
note
taking
and
please
joining
us
there.
The
link
in
the
chat
is
the
right
link.
I
think
the
rank
link
here
might
be
wrong,
but
and
all
of
our
material
is
online
next.
A
A
It
is
possible
that
the
the
network
slices
discussion
will
continue
past
its
allotted
time,
in
which
case
we
will
still
take
the
half
hour
break,
but
we
will
just
can
pick
up
the
conversation
at
the
start
right
after
the
break,
so
that
is
that
number
four
might
extend
into
number
five
if
necessary
will
be
also
a
little
looser
on
time
than
we
have
been
in
the
past.
Although
we
still
will
put
up
the
timer
as
usual,
one
change
here
is
on
slot.
A
Nine
reza
will
be
presenting
versus
shusang,
who
was
originally
listed
next.
A
So
this
is
our
usual
discussion
about
working
remote.
I
think
everyone
is
really
familiar
with
that.
We
are
working
remote
and
continue
to
do
so
that
the
mail
list
is
how
the
working
group
judges
consensus.
These
discussions
are
very
important
that
we're
having
right
now
our
periodic
informal
meetings
as
well
as
interims,
are
hugely
important,
but
it's
really
we
gauge
consensus
on
the
list
and
it's
important
when
we're
trying
to
basically
close
down
on
a
topic
to
show
that
we're
done
with
it.
It's
also
equally
important
when
we
start
new
discussions.
A
So
if
you
have
a
new
idea
or
a
new
document
that
you
want
to
get
in
front
of
the
group,
the
mail
list
is
the
right
place
to
introduce
it,
publish
your
document,
send
some
intro,
an
intro
summary
to
the
list
and
try
to
generate
some
discussion
there.
That's
it's
just
as
important
to
do
that
at
the
beginning,
as
it
is
at
the
end,
our
online
meetings
continue.
A
It
seems
that
for
the
next
meeting
we
have
hope
of
maybe
doing
a
mixed
meeting
of
online
and
in
person
we'll
see
what
happens
that
has
not
been
announced
yet,
but
stay
tuned,
but
the
we
have
the
the
ability
to
do
informal
as
well
as
interim
meetings.
A
A
A
As
a
reminder,
we
have
an
ipr
disclosure
process
to
check
to
sort
of
help
us
in
that
process.
We
referred
back
to
and
well
where
we
ask
everyone
to
disclose
any
ipr
that
their
intellectual
property
that
they
are,
they
know
about
in
work
that
they
are
contributing
on
and
we
pull
both
at
the
beginning
of
the
process
on
adoption,
as
well
as
at
the
last
call
step,
and
you
see
we
just
started
one
today.
A
As
you
add
new
authors,
we
think
it's
really
important
to
get
a
polled
response
from
that
person
or
even
an
unsolicited
response
from
that
person.
This
is
only
applies
to
working
group
documents
and
if
you
are
an
author
or
an
editor-
and
you
add
someone,
we
really
ask
you
to
have
that
person
make
an
explicit
statement
on
the
list
at
the
time
they
are
added.
A
B
A
So,
what's
new
with
our
documents,
we
have
no
new
rfcs
and
nothing
in
the
editor
queue
we'll
have
to
try
to
speed
up
and
get
some
new
things
in
there.
We
do
have
a
batch
of
documents
that
are
headed
to
last
call,
so
you
know,
I
think,
that
we're
gonna
fill
the
queue
again,
not
sure
why
that
formatting
came
out
strange,
but
we
have
one
document
in
publication
requested.
I
believe
that
is
with
our
a
d.
A
There
was
an
update
issued,
so
it
was
with
the
authors,
but
I
think
it's
now
back
with
the
aed
and
we've
had
one
recent
adoption
next.
A
There
was
one
liaison
received.
Excuse
me
it's
from
gsma,
I
don't
know
if
that's
actually
a
formal
liaison
or
a
communication.
Tsma
is
part
of
3gpp,
so
I'm
not
I'll
defer
to
the
iab
and
what
their
liaison
or
communication
relationship
is.
But
we
do
have
one
new
white
paper
available.
Please
review
it.
If
we
we
have
some
working
group
documents
in
this
area
now
on
itf
network
slicing.
It
may
be
time
to
send
a
response,
and
so,
if
you're
interested
as
always
we're
contribution
driven,
please
send
a
proposal.
A
A
Come
on
yeah,
that
was
the
final
slide.
Okay,
great!
If
you
have
any
questions,
come
to
the
queue,
if
not
we'll
proceed
with
pavan,
giving
the
detailed
draft
steps.
C
Okay,
good
morning,
good
afternoon,
good
evening,
I'm
pawan
biram
your
other
coacher.
Before
I
start
with
the
working
group
document
status.
Let
me
thank
our
new
secretary
lewis
for
proactively
collating
the
status
reports
and
compiling
the
slide
deck.
C
We
there
are
22
working
group
documents
that
are
listed
here,
five
of
those
colored
in
blue
or
on
the
agenda.
Today
we
have
one
document,
the
signaling
extension
staff
for
some
pivot,
for
which
we
put
in
a
publication
request
a
while
back
lou
went
over
the
status
of
that
in
the
previous
text,
so
it's
not
covered
here.
So
that
leaves
us
with
16
documents
the
status
for
each
of
those
is
covered
in
this
deck.
C
I
don't
intend
to
walk
through
each
and
every
one
of
those
here.
I
will,
however,
double
click
on
a
select
view
and
dwell
on
them
a
little
bit
for
the
rest
of
them.
You
can
use
your
own
page,
go
through
the
slides
and
the
reports
that
are
sent
out
to
the
list
and
ask
questions
if
any.
So,
let
me
jump
to
slide
six
first.
C
So
this
is
the
enhanced
vpn
framework
document,
a
new
revision
for
this
was
published
in
late
october.
There
is
some
new
text
describing
in
detail
the
applicability
of
enhanced
vpn
to
network
slicing
as
part
of
the
next
steps.
The
authors
have
indicated
that
they
would
like
to
sort
out
the
relationship
between
ns,
vpn
and
itf
network
slice.
C
From
the
chairs
point
of
view,
this
is
a
topic
that
has
been
discussed
on
the
list
before
and
as
noted
in
the
ietf
network
slices
framework
document.
Enhanced
vpn
does
offer
one
solution
approach
to
realize
idf
network
slices,
as
noted
in
that
document,
and
also
on
the
list.
It
is
not
the
only
solution,
approach
for
realizing
idf
network
slices.
C
So
if
there
is
a
specific
question
that
the
authors
are
looking
to
get
answer
for
the
from
the
working
group
regarding
this
relationship,
please
do
initiate
a
thread
on
this
on
the
mailing
list.
C
C
This
is
the
pc
cc,
use
cases
document.
As
stated
in
the
previous
meeting,
the
chairs
have
decided
to
take
this
to
last
call.
It
seems
like
there
are
still
a
couple
of
items
pending.
The
authors
have
indicated
that
they
would
be
wrapping
this
up
soon.
So
please
do
review
this
in
anticipation
of
last
call.
C
This
is
the
3272
bis
document,
a
new
revision
for
this
was
published
yesterday.
The
ada's
notes
suggest
that
there
are
still
a
couple
of
pending
items.
There
is
still
this
open
question
on
whether
the
scope
needs
to
change
from
overview
and
principles
of
internet
traffic
engineering
to
overview
and
principles
of
traffic
engineering.
C
As
adrian
says
here,
there
has
been
silence
on
this
topic,
so
if
anyone
wishes
to
chime
in
or
help
adrian
out
with
suggested
changes,
please
do
come
forward
and
help
out
this
is
a
large
document
could
definitely
use
some
thorough
reviews
from
the
working
group.
Adrian
do
you
have
anything
else
to
add
to
this.
D
No
thank
you.
As
you
noticed
I
I
published,
I
posted
a
a
an
update
for
the
keeper
live
and
to
pick
up
one
of
med's
comments,
and
this
is
just
sitting
in
my
pile
of
to
do
things.
C
Next
up
is
the
sf
aware,
topology
young
model
document.
The
authors
have
said
that
they
are
almost
done
with
this.
They
have
requested
a
young
doctor's
review
for
this.
We
did
initiate
the
review
yesterday.
Hopefully
that
will
get
done
in
the
next
few
weeks.
Let
me
jump
to,
I
think,
that's
slide
17..
C
So
this
is
the
base
t
young
document,
the
authors
have
requested
working
glass
call.
The
initial
plan
was
to
progress
this
document
and
three
other
documents-
the
rsvp
young
document,
the
rsvp
young
and
the
key
mpls
young
document
together,
but
there
are
still
some
minor
issues
open
against
the
other
three.
So
the
plan
is
to
initiate
the
working
group
last
call
process
for
this
document
first
and
let
the
other
three
follow
soon.
The
ipr
for
this
just
got
started.
So
please
do
review
all
these
documents
in
anticipation
of
the
last
call.
A
One
of
the
authors
is
mail
is
bouncing
so
co-authors.
Please
check
that
all
the
authors
addresses
are
right
and
contributor
addresses
are
right.
C
C
E
Correct
so
yeah
thanks,
hi
everyone
I'll
be
discussing
an
update
to
a
bunch
of
yang
models
that
I'm
the
editor
on
so
next
slide,
please.
E
E
So
let's
go
update
one
by
one
next
slide.
We
will
focus
on
vn
model
next
slide.
So
an
update
to
what
is
vn
model
vn
model
is
basically
our
yang
model
for
vn
operations.
It
is
the
customer
view
of
the
virtual
network.
It
is
an
abstraction
over
the
t,
topology
and
the
t
tunnel
model.
It
has
a
tight
coupling
with
those
models.
It
uses
the
connectivity
matrix
to
to
describe
how
the
vm
interact.
That
is
how
the
various
vn
members
and
the
access
points
come
together
to
form
the
vm.
E
So
the
update
in
the
latest
model,
the
recent
changes
next
slide.
E
Let
me
go
through
them,
so
the
main
change
was
there
was
a
request
to,
like
you
know,
clean
up
our
names.
I
think
this
was
common
in
bunch
of
tea
models
so
as
as
the
same
operation
was
done
for
itfte
and
and
other
models.
We
also
take
look
it
up
for
the
vm
model
and
we
have
resolved
the
naming
issue
thanks
to
tom
patch
and
other
people
who
have
pointed
out
this
issue,
the
another
major
update
is,
we
have
added
an
empty
container
for
underlay,
as
I
was
mentioning
earlier.
E
Currently,
we
have
a
quite
a
tight
coupling
with
te
topology
model,
so
we
have
added
this
empty
container
underlay
in
a
hope
that
any
future
update
can
be
made
very
easily
a
future.
Augmentation
can
be
done
for
this
model
to
add
things
which
cannot
be
covered
by
the
topology
model,
for
example,
if
you
want
to
add
details
about
sr
policy,
etc,
that
can
be
an
augmentation
of
this
model
and
the
place
to
augment
that
detail
would
be
this
empty
container
called
underlay.
E
So
this
is
another
update
that
we
have
done
and
discussing
one
way
to
handle
the
discussion
that
we
had
when
last.
This
was
presented
that
how
do
we
handle
this
issue?
So,
right
now
to
keep
the
scope
of
the
this
draft
limited?
We
thought
that
this
could
be
a
good
approach
that
we
handle.
What
is
already
published-
let's,
let's
finish
this
and
allow
a
way
for
this
to
be
augmented
in
a
future
in
a
very
clear
way,
so
have
an
empty
container.
For
now,
which
can
be
augmented
by
a
future
model.
E
We
updated
a
description
for
v
and
compute
status.
We
we
were
reusing
this
from
the
t
types,
but
it
was
not
a
one-to-one
map.
There
was
little
bit
description
needs
to
be
added
that
how
a
t
compute
is
little
different
from
vm
compute.
So
we
have
added
that,
though
we
are
still
reusing
it,
but
we
have
added
a
description
saying
how
we
expect
this
to
be
used
in
the
vm
model.
E
There
was
an
update.
There
was
a
request
to
add
cos
as
an
additional
constraint.
We
have
added
that
and
then
there
was
a
major
update
with
respect
to
the
json
example,
since
the
topology
model
had
quite
a
bit
of
change
during
the
last
few
cycle,
and
we
were
still
using
the
json
example,
which
was
written
based
on
an
older.
C
E
E
We
wanted
to
ask
the
working
group:
are
these
changes?
Okay,
do
people
have
any
other
open
issues
and
we
believe
that
if
once
these
are
handled,
maybe
we
can
consider
this
document
in
pipeline
for
working
group
last
call.
The
young
doctor
review
was
done
some
time
back
on
version
10..
We
can
see
if
we
need
to
repeat
that
again
anyway,
it
will
be
done
as
a
part
of
the
last
call
process
anyways.
So
this
is
my
status.
Thank
you.
A
The
queue
I
I
looked
at
the
cos
change
and
there's
no
context
for
it,
so
it's
not
immediately
clear
how
you
expect
it
to
be
used,
so
I
think
there's
needs
to
be
a
little
more
language
around
it.
A
C
It
so
it's
called
cos,
but
I
I
thought
I
saw
you
use
the
dst
class
type
is
that
is
that
what
is
being
done
here?
C
It's
a
fee
you're,
just
picking
the
dst
class
type,
zero
to
seven.
E
C
E
Okay,
so
I
think,
let's
move
on
to
the
next
models.
So
next
we
have
telemetry
yang
model
next
slide.
Please,
in
this
model
we
basically
have
the
performance
monitoring
parameters.
We
also
have
something
what
we
call
as
a
scaling,
intent
mechanism
where
we
tell
at
what
time
the
capacity
for
our
vn
or
tunnels
can
be
increased
and
by
how
much
so
basically,
this
model
allows
any
customer
to
subscribe
to
various
monitor,
monitoring
performance
parameters
for
a
particular
tunnel
or
a
vm,
and
also
to
define
the
the
scaling
intent.
E
So
the
update
in
this
model
next
slide.
Basically,
we
handle
comments
from
adrian
and
greg.
Thank
you
for
those.
The
major
update
was
we
removed
the
term
kpi.
I
think
it
was.
I
agreed
that
it
was
not
so
useful.
We
let's
call
it
telemetry
model
and
keep
it
simple.
We
updated
the
figures
to
depict
the
model
relationship.
There
was
still
some
confusion
that
are
we
redefining
things
or
are
we
reusing
between
the
two
models?
E
So
we
have
updated
that
description
so
that
the
readers
is
well
aware
of
our
intent
with
respect
to
the
relationship
between
the
models.
We
added
an
example
for
how
the
scaling
would
be
done
with
help
of
xml
example
and,
as
usual
adrian
gave
a
lot
of
useful
suggestions
and
nits,
and
I
hope
all
those
have
been
handled.
E
We
have
comments
from
greg
regarding
not
to
use
the
word
proactive
when
we
are
talking
about
re-optimization.
E
There
was
also
a
comment
whether
how
it
links
with
other
work,
such
as
one,
which
is
happening
in
ops
area
related
to
vpn
service
performance
measurement.
So
we
have
added
that
how
we
assume
that,
like
no,
these
two
work
can
work
together,
that
you
can
have
a
vpn
overlay
pm
as
well
as
you
can
have
traffic
engineering
telemetry
data
and
how
both
of
them
can
be
reused,
used
together
and
correlated
when
looking
for
fault,
etc.
E
E
That
is,
since
we
are
talking
about
scaling
intent
and
there
is
some
overlap
with
the
work
that's
happening
in
ops
area,
so
there
should
be
like
you
know,
notification
sent
to
them.
So
our
query
was
that,
should
we
send
it
as
authors
or
is
it
better
if
it
goes
from
chairs.
C
Yeah
we
yeah,
we
can
definitely
send
it.
There
is,
I
mean
we
haven't
done
a
young
doctor's
review
for
this
document.
Yet
right,
yes,.
E
E
I
think
the
main
point
with
op
series-
I
think
this
intent
word
is
also
like
today
in
the
ops
area.
Again,
this
discussion
was
happening
and
earlier
also,
we
have
the
ad
being
this
discussion,
whether
the
terminology
map,
so
I
think,
just
a
quick
idea
of
what
we
are
doing.
It's
not
just
the
modeling
part,
but
the
terminology
that
might
be
a
good
input
to
get
from
the
ops
area
as
well.
F
Does
this
telemetry
model
cover
the
the
service
telemetry
as
well
as
the
transport
underlay,
or
is
it
just
the
transport.
E
It's
just
the
transport,
just
the
te
and
vn
and
as
as
I
was
mentioning
that
it's
in
fact
the
vpn
service
young
model,
where
we
expect
the
service
telemetry
to
be
there.
E
E
Okay,
so
the
final
draft.
For
me,
the
t
service
mapping
model
now
this
model
basically
maps
the
services
and
the
networks,
various
l3,
sm,
l2,
sm
and
even
l1
csm,
and
also
the
network
models
like
l3m
and
l2nm.
How
do
they
map
with
the
te
infrastructure
so
mapping
to
t
toppo
e
tunnel,
vn,
etc?
So
all
of
this
is
handled
in
this
model.
E
Idea
of
this
model
is
so
that
we
could
have
a
seamless
service
operations
and
understand
how
the
service
is
being
run
on
our
underlay
t
network,
and
what
is
the
relationship
between
the
two?
This
allows
us
to
do
monitoring
and
diagnostic
much
much
better,
and
it
also
supports
various
type
different
types
of
map
types.
That
is
what
is
the
relationship
between
the
service
and
pe?
There
could
be
multiple
tight
coupling
or
it
could
be
loose,
so
those
different
map
types
are
supported
in
this
model.
E
The
recent
changes,
because
there
were
inputs
from
adrian
oscar
kenichi
and
based
on
that,
what
we
have
done
is
we
have
added
a
clear
section
on
what
is
the
purpose
of
this
service
mapping
so
and
where
we
intend
this
to
be
used.
One
thing
that
we
did
clarify
that
this
will
be
useful
for
an
outside
entity
only
if
the
outside
entity
also
understand,
for
instance,
vn
and
tunnel.
E
Otherwise
this
model
would
be
more
for
internal
purposes,
for
the
network
itself,
mostly
for
diagnostic
and
monitoring
purposes,
and
not
might
not
be
exposed
to
the
outside
world.
So
both
of
these
are
valid
approaches
like
if
the
t,
topology
and
p
tunnels
are
exposed,
then
this
mapping
could
be
useful
by
an
external
system.
E
Otherwise,
it's
only
for
internal
purposes.
There
were
bunch
of
things
which
were
marked
as
open
issues
and
thanks
for
adrian
for
pushing
us
and
giving
us
good
solutions
on
how
to
handle
it.
So
we
have
kind
of
marked
that
scheduling
is
not
out
not
part
of
this
draft,
but
how
it
could
be
handled.
The
those
texts
has
been
added.
One
more
open
issue
was:
how
do
we
map
traffic
onto
this
particular
services
and
our
t
infrastructure?
So
we
have
said
that
this
is
out
of
scope.
There
is
some
discussion.
E
We
know
that
this
is
happening
in
other
young
model.
One
early
attempt
that
we
did
also
exist
with
respect
to
this
document,
which
I've
mentioned.
This
is
t
traffic
yang,
which
tries
to
say
that
how
we
can
maybe
use
acl
and,
like
even
flow
spec
kind
of
information
to
to
do
this
is
again
very
early
work.
But
anyway,
from
the
scope
of
this
document,
we
are
saying
it
is
out
of
scope
somewhere
somewhere
else.
This
needs
to
be
handled.
E
So
if
there
is
an
interest
in
this
area
and
like
you
know,
please
reach
out
to
me
as
well
next
steps
in
the
next
slide.
E
Itf
network
slice
is
out
of
scope,
so
we
wanted
to
check
whether
that's
a
good
approach.
Do
we
need
to
add
it
as
one
of
the
other
possible
service
types
like
if
we
are
already
handling
l3,
sml
and
others?
Should
we
also
map
itf
networks,
slice
to
te
resources?
Is
this
the
right
way
to
do
it
or
should
something
else
is
needed?
So
this
is
an
open
question
to
the
working
group.
A
So
on
the
network
slice
part,
I
think
we
can
proceed
without
it
and
then
we
can
always,
if
necessary,
augment
the
model,
and
that
way
we
don't
have
to
hold
up
this
document,
which
is
hopefully
getting
pretty
mature
at
this
point,
and
if
we
tried
to
bring
in
slicing
that
I
think
that
would
cause
a
large
delay
in
this.
As
far
as
I
can
tell,
there's
no
reason
why
it
can't
just
be
done
as
a
standalone
document,
an
augment
if
we
do
need
to
augment.
A
I
think
that's
our
perspective
from
the
chair
outside.
If
anyone
wants
to
give
an
alternate
view,
now
would
be
a
good
time.
E
Yeah,
let
me
just
discuss
with
my
author
set
as
well
and
see
what
they
feel
we
are
dependent
on
couple
of
models
still
like
l1
csm
is
one
of
them.
There
is
sr
policy,
so
though
our
t
part
is
going
well
and
those
models
are
all
like.
I
t
f
t
e,
I
t
f,
t
top
are
all
progressing,
but
on
the
other
side
we
have
progress
on
l3,
nm,
l2
nm
is
also
progressing,
so
I
think
l1
csm
and
sr
policy.
E
Those
are
the
two
models
which
we
are
dependent
on,
so
we
might
have
a
little
bit
more
time
while
this
document
would
be
ready
to
publish
in
rfc.
A
But
those
changes
are
not
likely
to
change
the
content
of
this
document.
Correct
yeah,
that's
true!
Well,
if
we
sat
in
miss
ref,
it
wouldn't
be
a
big
deal.
We
could
just
wait
until
those
are
go
through
the
process.
Yeah,
okay,
yeah.
I
think
I
think
if
we
could
wrap
this
up-
and
you
know
start
going
through
the
publication
process,
it
would
be
better
to
do
that
than
to
try
to
hold
it
indefinitely
or
hold
it
much
longer.
A
So
you've
added
two
very
small
sections
on
things
that
are
out
of
scope.
I
I
found
those
to
be
really
not
clear
what
you're
saying
and
the
nice
thing
is,
though,
is
they're
out
of
scope,
and
you
know
many
documents
just
are
silent
on
things
that
are
out
of
scope.
So
would
you
be
opposed
just
to
dropping
those
two
sections,
or
do
you
think
we
at
paragraphs?
A
I'm
sorry,
not
sections
paragraphs
which
just
came
in
the
last
version,
or
do
you
think
we
really
have
to
state
that
it's
explicitly
out
of
scope.
E
I
think
the
main
reason
why
was
there?
These
were
the
questions
that
were
asked
to
the
authors
and
that's
why
we
were
maintaining
them
as
an
open
issues,
and
people
had
this
idea
that
oh
without
these
things
handled,
is
this
mapping
useful
so
mainly
because
of
that
we
wanted
to
give
it
a
little
bit
more
importance.
E
I
think
the
text
came
from
adrian
if
I'm
not
wrong
at
least
related
to
scheduling,
so
I
can
discuss
with
adrian
and
post
it
to
the
working
group
and
see
what
the
working
group
thinks,
whether
we
need
to
keep
it
or
remove
it.
D
Yeah
yeah,
so
my
my
question
was
really
just
to
the
authors
to
say:
have
you
deliberately
left
this
out
and
it's
fine
in
my
opinion
that
they've
deliberately
left
it
out
and
their
answer
closed
that
for
me
you
might
wonder
what
will
happen
when
the
next
person
reviews
the
document
and
and
whether
having
this
paragraph
will
just
even
reduce
it
to
a
sentence
would
help
the
reviewer.
The
next
reviewer
not
also
ask
the
question,
but
it's
it's
pretty
unimportant
to
them.
A
Yeah
and
I'm
worried
about
declaring
things
out
of
scope
when
someone
comes
along
and
wants
to
augment
the
document
that
someone
will
use
that
statement
about
it
being
out
of
scope.
As
saying
that
you
can't
augment
the
document-
and
I
don't
think
that's
what's
intended
here
and
I
I
just
find
that
you
know
unless
it's,
it
really
seems
that
something
should
be
in
the
scope
of
the
document.
It's
better
just
to
be
silent
on
it.
A
A
And
actually
the
next
paragraph
is
really
the
one
I
think
is
problematic,
but
I
I
think
in
practice
it's
better
just
to
be
quiet
on
things
that
are
out
of
scope
if
you'd,
like
you
know,
I
think
talking
it
to
your
authors,
about
the
other
paragraph
and
whether
or
not
you
you're
comfortable,
just
being
quiet
there,
you
know
adding
one
sentence.
You
know
currently
on
out
of
scope,
you
know,
and
then
you
say,
although
they
could
use
their
own
scheduling
mechanism.
I
don't
think
this
is
adding.
A
I
think
it's
opening
a
door.
That's
not
really
clear!
I,
I
really
don't
think
the
other
scope
statements
are
adding
anything,
but
I'm
also
happy
to
take
that
as
a
you
know,
as
a
contributor
position
as
chair
definitely
think
it's
bad
practice
to
put
out
a
scope
statements
unless
you
really
need
to,
but,
as
you
know,
for
these
two
pic
two
particular
ones,
I'm
happy
to
take
it
to
the
list
and
pursue
it
as
a
contributor.
C
D
D
Just
want
to
start
by
thanking
everyone.
That's
been
involved
because,
although
it's
my
name
on
the
front
page,
it's
not
really
my
work
so
much
so
this
is
all
the
people
who
were
in
the
design
team
who
wrote
the
foundation
documents,
the
people
that
came
along
to
the
interim
meeting
and
discussed
it,
and
many
people
who've,
contributed
on
the
mailing
list
to
move
the
work
forward.
So
next
slide.
D
What
we
have
in
the
fairly
recently
published
05
is
an
attempt
to
resolve
the
open
issues
that
were
discussed
at
the
interim
and
had
text
proposals
on
the
table,
and
so
I
run
through
these.
The
first
one
was
connectivity
matrices
and
what
we've
done
here
is
clarify
the
definition
of
the
four
basic
connectivity,
matrices
and
added
a
new
matrix
for
any
to
any
connectivity,
and
the
intention
here
is
to
enable
every
type
of
use
case
that
people
have
been
suggesting
chiefly
operators.
D
The
general
case
is
based
on
a
sort
of
tunnel
connectivity,
but
we
also
wanted
to
support
the
vpn
type
service
and
that's
what
brings
in
any
to
any
which
is
not
a
tunnel
connectivity.
It's
effectively
a
rootable
full
mesh.
D
D
So
here
are
the
types
of
connectivity
matrix
that
we've
got
defined
and
I
think
that
point
to
point
is
pretty
straightforward.
It's
a
pair
of
ces
with
the
traffic
going
from
one
to
the
other.
It
behaves
like
a
private
wire
or
a
tunnel,
and
the
slos
and
sles
are
applied
at
the
sender
and
so
they're,
implicitly
the
same
slos
and
sles
at
the
receiver.
D
It
would
be
very
odd
if
they
weren't
the
bi-directional
version
of
that
is
really
just
a
pairing
and
there's
no
implication
of
co-rooted
or
not
co-rooted.
D
Although
I
guess
you
could
define
an
sle
to
to
force
that
there
are
two
sets
of
slos
each
applying
to
one
of
the
ces
as
its
sender
so
point
to
multipoint.
It
just
extends
that
really
it's
a
single
sender
and
multiple
receivers
and
it
behaves
like
a
point
to
multi-point
tunnel
or
a
multi-access
vlan
segment.
D
Then
we
get
the
multi-point
to
point,
which
is
something
that
we've
sort
of
seen
in
a
an
ldp
sense
and
then
got
added
to
rsvpte
for
for
mpls,
and
what
you
have
here
is
that
all
traffic
that
is
injected
at
any
sending
cd
is
received
by
the
single
receiver.
D
So
you
could
model
this
as
a
set
of
point-to-point
connections
with
a
common
receiver,
each
sending
ce,
as
it
has
its
own
set
of
slos
and
sles.
So
it's
not
a
given
that
each
sender
on
this
matrix
has
the
same
traffic
requirements
and
the
implicit
slos
and
sles
for
the
receiving
ce
really
are
a
combination
of
these
sending
slos
and
sles.
D
So
multi-point
to
multi-point
is
is
a
bit
ugly.
I
I
see
turret
in
the
queue
but
I'll
finish
the
slide
and
then
we'll
come
back
multi-point
to
multiple.
It's
a
little
bit
ugly
in
a
tunnel
sort
of
sense.
There
are
nces
that
can
send
traffic
and
that
anything
they
send
is
delivered
to
all
of
the
other
ces.
D
And
then
we
hit
the
any
to
any,
and-
and
this
is
different-
this
is
not
tunnel-like
here
you
have
a
set
of
ces
and
they
may
send
to
any
of
the
other
ces
anyone
or
any
set,
so
they
can
support
point-to-point
and
multicast,
and
it's
not
unlike
the
the
multi-point
to
multi-point.
It
isn't
the
case
that
a
sender's
traffic
is
delivered
to
all
receivers.
D
The
matrix
must
determine
to
which
c's
to
deliver
each
packet,
so
something
has
to
be
looked
up
to
work
that
out
and
then
the
slo
sles
apply
to
individual
senders
are
paired
with
their
individual
receivers,
so
you
can
actually
say
this.
I'm
going
to
send
this
sort
of
traffic
from
here
to
here,
and
then
that
means
there's
no
linkage
between
sender
and
receiver
and
a
sender
may
be
disappointed
if
a
receiver
is
over
subscribed.
D
F
Adrian
on
on
on
jotting
down
the
types
of
matrices
connectivity
matrices,
I
I
want
to
start
with
the
basic
matrix
point
to
point
and
my
question:
is
we
talk
about
a
connectivity
matrix
and
we
talk
about
connections?
In
your
view,
a
a
matrix
can
have
multiple
connections
and
and
just
to
highlight
that
we're
going
to
raise
this
topic
up
in
the
in
the
nbi
network
size,
mbi
data
model-
we
did
discuss
it
among
the
authors,
but
I
want
to
get
your
initial
thoughts
on
this.
D
So
when
you
say
we
talk
about
connections,
I
thought
I
had
mopped
all
of
that
up
out
of
the
framework.
I
don't
see
it
helpful
to
talk
about
connections
and
a
connectivity
matrix.
D
F
D
F
So
I'll
give
you
more
context
on
my
question.
So
if
I
have
two
network
slice,
end
points,
basic
network
slides
with
two
end
points,
and
I
want
can
connectivity
between
them
will
will
I
be
ending
up
creating
one
connectivity
matrix
with
two
point-to-point
connections,
or
will
I
have
two
connectivity
matrices
where
one
in
one
of
them?
The
sender
is,
you
know
one
end
point
other
and
the
other
it's
the
other
endpoint
can.
Can
this
be
clarified.
D
Yeah,
so
let's,
let's
put
sort
of
names
to
that.
If
you
want
to
send
traffic
a
to
b
and
you
want
to
send
traffic
a
to
c.
You
have
two
matrices
two
point
to
point:
matrices,
you're,
you're
right.
My
my
text
in
the
multi-point
point
was
sloppy.
It
should
say
this
is
like
a
set
of
a
set
of
p2p
connectivity,
matrices.
F
Yeah,
I
find
it
awkward
that
matrix
is
usually
made
of
multiple
entries
and
your
definition
has
only
one
entry,
but
maybe
other.
D
No,
no
everything's
got
more
than
one
entry,
because
you're
counting
the
ces.
D
No,
no,
so
you
list
think
about
think
of
a
list
of
ces
for
your
whole
network,
all
of
the
edges
and
then
each
matrix,
you're
going
through
and
saying
I'm
connecting
this
set
of
ces
and
in
the
point-to-point
case.
Yes,
it's
almost
trivial,
but
you
you
still
have
both
ends
of
them,
so
you
have
two
ces
in
your
matrix.
F
D
Yeah
we
we
should
certainly
try
to
get
some
either
alignment
between
the
use
of
terminology
or
an
intentional
divergence.
I'm
fine
with
that.
This
usage
has
been
around
for
a
couple
of
revisions,
so
it
we
might
assume
that
it's
it's
been
thought
about
a
bit
but
yeah,
let's
get
together
and
and
try
to
resolve
that
tallest.
H
So
I
think
the
the
fundamentals
here
are
point-to-point
and
point-to-multipoint,
and
everything
else
is
just
a
random
subset
of
potentially
interesting
groupings
right
and
maybe
it
would
be
very
helpful
to
to
just
say
that
you
know
there
needs
to
be
the
concept
of
groupings
and
these
can
still
be
listed
there,
but
obviously
there
there'll
be
other
interesting
ones.
You
know,
I
think
we
we
have,
you
know
a
redundant
hub
and
spoke
and
I
don't
want
to
go
through
through
the
list,
but
otherwise
it
looks
like
a
long
flat
list.
D
I
I
hear
what
you're
saying,
but
I
think
you
need
to
step
back
and-
and
this
is
from
a
service
perspective,
so,
for
example,
something
like
hub
and
spoke
is
about
realization
inside
the
network
and
the
the
the
service
may
want
to
talk
about
that
or
the
service
user
may
want
to
talk
about
that.
But
they
have
no
real
control
over
what
the
network
is
doing.
H
No,
no,
no,
I
think,
for
example,
a
set
of
point-to-point
where
one
point
is
always
the
same
right,
a
set
of
bi-directional
pointer
points
with
you
know,
one
point
being
the
hub
and
the
others
all
the
spoke
is
exactly
you
know.
H
A
grouping
like
like
many
of
the
others
here
like
any
to
any
or
or
multi-point
to
multi-point
or
so
right
so
happen
spoke,
is
in
the
same,
is
in
the
same
bucket
as
a
as
a
type
of
connectivity
matrix.
H
D
So
if
they,
if
that,
if
the
hub
is
a
a
customer
site
that
is
very
different
from
if
the
hub
is
inside
the
network,
yeah.
D
Right
so
we
we
had-
and
I
think
we've
removed
a
paragraph
that
actually
told
you
how
to
make
a
hub
and
spoke
using
the
customer
site
by
building
that
out
of
multi-point
to
point
and
a
set
of
point
to
points.
But
we
can.
We
can
revisit
that.
H
You
know,
but
I
I
just
wanted
to
make
one
example.
There
are
more
examples
in
the
same
way
as
you
removed
the
the
the
happened
spoke.
You
can
equally
remove
the
bi-directional
point-to-point.
If
you
do
have
the
concept
that
the
customer
can
request.
A
connectivity
matrix
of
a
set
of
fundamentals
like
a
set
of
p2p
and
p2mp
with
a
common
policy.
H
Then
all
these,
these
others
bidirectional
multi-pointer,
point
multi-pointer
multi-point
a
to
a
are
just
creations
out
of
here
is
a
set
of
fundamentals
like
a
set
of
p2p,
and
I
want
to
have
this
set
and
a
common
policy,
and
then
we
don't
need
to
argue
whether
a
bidirectional
p2p
has
you
know
is
so
much
more
important
to
be
listed,
whereas
happenspoke
is
not
listed.
D
Let's
take
three
hari
and
then
move
on
with
other
slides.
Oh
we'll
lose
in
the
queue
as
well.
Three
hurry.
E
Sure
so
I
might
have
a
question
very
similar
to
what
tourist
was
talking
about.
Let
me
just
ask
the
question
and
then
you
can
defer
to
same
answer.
What
I'm
struggling
with
is,
let's
say,
take
a
multi-pointer
point
example
where
the
receiving
ces
slo
is
implicitly
derived
from
the
multiple
senders.
E
What
I
am
thinking,
maybe
you
can
correct
me
if
I
am
receiving
this.
If
I
am
the
receiver
ce,
then
I
get
to
define
and
because
I'm
paying
for
the
you
know
service.
So
I
get
to
define
what
slos
do
I
need
and
therefore,
implicitly,
all
the
senders
slo
should
be
derived
is
what
I'm
thinking
care
to
comment
on
it.
D
E
D
Yeah
we
could,
I
guess
we
could
so
far,
we've
not
until
we
get
to
any
to
any
we've
not
specified
the
slos
for
the
receiver,
but
I
I'd
be
interested
to
hear
if
people
have
got
sort
of
like
operator
use
cases
where
they
need
to
specify
the
receiver's
slo
on
on
a
pipe
model
as
different
from
the
sender.
E
What
happened
there
go
ahead
I'll
wait
for
I'll
wait
for
more
comments.
C
A
All
right,
so
I'd
like
to
go
back
to
how
many
sort
of
external
services
are
exposed.
I
we
have
been
through
whether
or
not
bi-directional
as
a
special
case
of
point-to-point.
A
Bi-Directional
point-to-point
is
a
special
case
of
unidirectional
and
we
have
gone
through
that
discussion
so
many
times
and
every
time
at
the
end
we
come
back
and
say:
yeah
bi-directional
is
important
to
call
out
separately.
So
I'd
like
to
propose
that
we
keep
that
in
you
know,
there's
been
lots
of
times
where
that
is
a
important
provisioned
service
or
port
service
to
deliver
to
a
user.
A
D
A
Yeah
so
with
chair
hat
on,
we
very
privately
said
we
expect
this
slide
to
be
the
last
slide
of
this
session
and
then
we'll
do
the
rest
of
the
slides
at
the
start
of
the
next
session.
D
Yeah
that
works
whatever
you
want,
or
we
can
take
it
at
the
end.
You
choose
okay,
lewis,
then.
B
Yes,
just
commenting
on
the
cases
that
you
you
mentioned
before
about
the
need
of
having
a
split
view
of
the
receivers
hello,
I
think
that,
because
we
are
not
explicitly
describing
the
way
in
which
we
are
distributing,
the
content,
if
it's
unique
or
multicast
could
be
the
cases
that
if
we
go
for
a
multicast
or
unicast,
this
has
an
impact
on
the
receiver
side.
So
this
could
be
a
case.
I
think
thank
you.
D
Yeah,
so
I
think
we
need
to
look
carefully
at
the
the
a
to
a
matrix
compared
to
say
the
p2mp
matrix.
D
But
I,
but
I'm
this
comes
back
to
the
question
that
we
had
before
is:
where
does
a2a
make
actually
mp
to
p
and
mp
to
mp
redundant
and
then
actually
I
think
you
get
everything
you
want
through
the
a
toa.
J
Yeah,
so
I
think
thanks
for
doing
the
great
work,
because
this
is
not
an
easy,
an
easy
thing.
J
My
main
question,
the
I
that
I
have
is
the
following
with,
which
is
also
as
a
follow-up
question,
so
the
connectivity
matrix
in
my
view,
is
mainly
to
help
define
the
characteristics
of
the
azolo
and
azales
is
that
is
my
understanding,
correct.
D
Yes,
sort
of
I
mean
consider
yourself
there
requesting
a
slice
service.
You
need
to
say
in
some
sense
what
traffic
is
going,
what
the
traffic
demand
is
going
to
be,
I'm
going
to
be
sending
traffic
from
here
to
here,
and
this
is
how
I
want
it
to
behave.
So
it's
yes,
it's
a
kind
of
an
anchor
for
the
slos,
but
it's
it's
it's
a
little
bit
more
than
that.
Yeah.
J
Because
see,
the
reason
why
I
bring
it
up
is
the
following.
I
I
also
I
I'm
a
bit
of
the
opinion
that
I
or
agree
with
some
of
the
comments
that
we
should
try
to
model
it
as
much
as
possible
as
a
point-to-point
thing,
because
there
is
an
other
potential
characteristic
that
we
say
here.
We
say
that
for
point-to-point
there
is
a
single
ce
and
a
single
sender
and
a
single
receiving.
D
I
find
myself
having
to
thank
you
for
making
it
more
complex,
sorry
about
that,
but
yeah
yeah,
because
yeah
multi-homing
need
to
think
about
multi-homing.
In
this
context,.
J
Because
I
think
we
defined
it
in
I,
there
was
a
sentence
of
all
active
and
and
single,
active
and
stuff
like
that,
so
even
for
point-to-point,
you're
not
restricted
restrictive
in
that
sense
to
a
single
ce
device.
So,
as
a
result,
I
believe,
is
it
not
better
that
we
try
to
model
each
of
these
scenarios
or
traffic
traffic
or
connectivity
matrixes
as
a
as
a
collection
of
point
to
point
with
certain
characteristics
such
that
that
and
and
use
that
to
define
the
as
a
layer
as
a
law.
J
C
D
I
can
do
that
that
would
be
louie.
I
Yeah
my
comment
is
really
taking
a
step
back.
You
know,
I
know
what
a
ce
is,
but
I'm
trying
to
bring
the
ce,
which
is
you
know
in
your
draft
customer
endpoints
in
the
context
of
this
I
mean,
is
it
you
esee
is
the
app
behind
the
you?
Is
a
ce
I'm
trying
to
figure
out.
Where
do
you
define
the
ce,
or
is
it
just
on
the
network
edge?
Is
that.
D
Nice,
nice,
nice
question
because
we
have
a
point
coming
up
on
on
the
next
slide,
which
you'll
get
after
your
break.
That
is
talking
about
how
we
talk
about
endpoint
service
endpoints
in
the
context
of
slicing,
and
I
I'm
not
comfortable
with
ce.
Although
we
sort
of
understand
what
it
means,
it's
not
very
good
when
the
sea
is
in
fact
a
service
delivery
point
in
the
middle
of
the
network
or
the
end
of
the
the
network.
Slice
is
actually
in
a
pe.
So
it's
it's!
It's
ugly
and
yeah.
C
Yeah,
I
think
we
can
stop
here
tarek
reza.
If
you
guys
can
hold
on
to
your
questions,
we
can
resume
after
half
hour.
I
A
Thank
you
all
we're
going
to
break
now
and
we'll
see
you
in
half
an
hour
yeah.