►
From YouTube: IETF101-TEAS-20180319-0930
Description
TEAS meeting session at IETF101
2018/03/19 0930
https://datatracker.ietf.org/meeting/101/proceedings/
A
Blue
sheets
are
going
around
as
usual,
please
sign
and
as
I
mentioned
before,
we
have
a
etherpad
link
on
the
bottom
of
the
slide
here.
Please
join
it
and
help
us
capture
minutes
of
what
goes
on.
Usually,
we
don't
take
notes
on
what
people
are
presenting,
but
more
of
the
conversation
we
have
a
new
note.
Well.
A
A
We
are
doing
our
usual
audio
and
video
streaming
when
you
make
comments
at
the
mic
once
it
shows
up,
please
make
sure
to
state
your
name
for
the
record.
I
am
on
jabber
right
now.
We
don't
have
anyone
on
it,
but
I
will
be
trying
to
watch
the
Java
room
to
make
sure
that
if
anyone
wants
to
add
anything
remotely,
we
we
get
that
read
into
the
mic
and
the
questions
responded
to.
A
A
Where
do
we
stand
on
documents?
We
have
one
new
RFC.
Thank
you
to
those
I'm.
Sorry,
two
new
RFC's.
Thank
you
to
those
who
contributed
to
work
very
much,
appreciate
that
and
appreciate
seeing
that
we
are
actually
getting
documents
out.
We
have
two
more
documents
in
the
editor
queue,
and
notably,
we
have
quite
a
number
of
documents
with
that
are
in
publication
requests,
including
one
that
went
in
yesterday.
We
had
been
working
on
that
teehee
topology
for
quite
a
while,
and
there
was
one
section
that
needed
a
little
cleanup.
A
A
We
have
one
document
that
post
last
call
there's
a
little
bit
of
cleanup,
that's
being
discussed
between
the
document,
authors
and
shepherds.
It's
not
expected
to
be
a
significant
change,
but
it's
still
something
we
want
to
see
cleaned
up
before
we
submit
to
the
IC
for
publication.
We
have
a
few
new
working
group
documents.
A
A
We
have
one
document
which
is
a
little
bit
coming
to
the
group,
a
little
bit
differently
than
most
documents.
This
is
the
RMR
document.
This
document
was
headed
towards
the
adoption
in
the
MPLS
working
group
and
through
some
discussion
with
the
chairs
and
ad,
we
agreed
that
it's
actually
belongs,
not
an
MPLS,
but
in
t's.
So
we
expect
this
document
to
come
in
and
be
adopted.
A
B
B
B
A
Any
review
alright,
then
we'll
certainly
we'll
talk
about
that
offline
and
then
come
back
to
the
working
group
on
the
list
and
suggest
out
of
receive
a
thank
you
thanks
for
the
clarification
we
have
one
incoming
liaison.
This
is
a
typical
liaison
we've
received
from
itu-t
over
the
years,
it's
very
good
to
see
the
synchronization
of
activities
to
make
sure
we
have
a
common
understanding
across
the
different
working
groups.
This
actually
came
in
to
not
only
tease,
it
came
in
to
I,
think
CKD.
A
Came
in
to
came
in
to
see
camp
MPLS
did
also
get
a
piece
of
PCE.
Okay
in
the
past,
C
camp
has
taken
the
lead
on
responding
to
itu-t.
This
type
of
liaison
we
haven't
talked
to
the
chairs
if
they
want
to
take
the
lead,
doesn't
necessarily
require
such
a
formal
response,
but
thinking
we'd
proceed.
The
same
way:
I'm
seeing
a
sea
camp
co-chair
nodding
his
head,
so
we'll
we'll
proceed
as
we
don't
really
do
his
liaisons
in
general.
A
A
As
a
reminder,
we
have
an
IPR
process
that
we
follow,
which
includes
pulling
both
before
adoption
and
last
call.
Please
follow
our
process.
This
is
part
of,
what's
captured
in
that
note.
Well,
if
you
need
references
on
this,
go
look
at
the
note
well
slide
or
the
note
well
page
off
the
ietf
top
page.
A
As
always,
we
really
appreciate
the
discussions
being
brought
on
the
list.
This
is
even
including
authors,
I
think,
we've
seen
a
good
example
of
that
with
the
work
that's
been
going
on
with
yang
and
TE
topology,
where
there's
a
lot
of
meetings
that
are
happening
and
the
reports
are
sent
to
the
list.
That's
a
very
good
way
to
keep
the
the
working
group
and
aware
of
what's
going
on
and
provide
the
opportunity
for
those
who
wish
to
contribute.
A
Who
may
not
be
authors
that
allows
them
to
contribute
to
the
to
that
work
and
the
consensus
building
process.
So
that's
really
important.
Please
use
the
list
and,
as
always,
we
try
to
allocate
time
based
on
list
discussion.
So
if
you
want
more
time
in
this
session,
have
more
or
less
discussion
and
with
that
we're
going
to
move
on
to
the
next
slide.
C
Good
morning,
everyone
will
now
quickly
look
at
the
status
of
the
working
group
documents.
We
currently
have
23
working
group
documents.
There
are
11
that
are
in
various
stages
of
the
publication
process
6
or
on
the
agenda
today,
so
that
leases
at
6
and
those
are
listed
up
here.
The
first
couple
of
documents
listed
here
but
adopted
last
month,
there
hasn't
been
any
progress
on
these
insert
options.
I
will
skip
those
jump
to
the
one
that's
listed.
C
Third,
that's
the
PCC
see
use
case
document.
We
did
not
receive
any
status
for
this.
There
hasn't
been
any
change
to
the
Darkman
since
April
of
last
year.
This
is
currently
an
expired
document
and
based
on
a
prior
update,
there
was
an
indication
of
intent
to
make
further
changes
to
the
document
we
haven't.
Seen
that
happen
is
there
anybody
representing
the
authors
who
like
to
come
out
of
the
mic
and
give
an
update
on
this.
C
C
There
are
still
some
outstanding
comments
in
the
list
that
need
to
be
addressed
and,
in
the
previous
update,
authors
did
say
that
they
would
like
to
align
the
procedures
in
this
document
with
the
ones
that
are
specified
in
IRC
8001.
So
I'd
like
to
see
those
two
items
get
addressed
before
we
have
any
discussion
on
moving
this
to
the
next
step.
Is
there
anything
that
the
author's
would
like
to
add
to
this?
C
Since
it
came
in
just
last
night,
I,
don't
see
anybody
coming
up
to
the
mic?
So
let's
move
on
next
is
the
l3t
topology
yang
model.
This
was
adopted
last
month
there
was
a
revision
published
for
this
early
this
month.
The
changes
were
primarily
done
to
address
some
warnings
from
the
yang
Lin
tool.
There's
still
some
work
that
needs
to
get
done
before
the
author's
can
say
that
they
are
ready
for
the
next
step.
C
In
the
meantime,
they're
requesting
the
working
group
to
review
the
model
and
reach
out
to
them,
if
there
are
any
specific
concerns,
next
is
the
SRT
topology
model
update
for
this
is
quite
identical
with
the
one
that
we
saw
in
the
previous
slide.
There's
still
some
work
that
needs
to
get
done
before
this
can
progress
to
the
next
step.
C
E
They're
working
did
you
give
me
well
okay,
this
is
a
short
update
on
the
working
group
Russ,
the
three
of
them
I'm
listening
here,
I'm
I'm,
awkward
I,
am
a
big
I,
don't
think
I'll
take
all
of
its
all
people.
I've
tried
to
give
back
to
all
the
time
for
other
spots.
We
did
it.
I
am
presenting
on
behalf
of
the
equalities
here,
I,
don't
review
of
my
slide
deck
well
I
bought
without
these
talk
about
the
open
issues
and
those
off
with
next
time.
E
Before
I
go
to
the
updates
a
little
bit
of
document
our
organization,
we
have
at
the
moment
three
documents
as
I
was
presenting
on
the
first
slide,
the
first
document
terms
of
organization
of
the
module.
It
covers
the
RSVP,
the
data
modeling
for
RTP
protocol
and
an
extended
module
for
that
at
Bates,
and
it's
ended
so
that
this
is
being
driven
in
one
document
separately,
the
second
one.
E
So
the
second
one
is
basically
an
augmentation
of
traffic
engineering
that
RTP
protocol
and
it
contains
or
seats
two
modules,
the
RSVP
and
the
compare
das
bitte,
please
initiation
of
it
and
that's
being
driven
a
separate
document
and
the
third
document
that
we
have
the
the
PE
Yankee.
At
the
moment
it
is
seeding
a
multiple
module,
including
the
generic.
He
made
a
famous
mastic
modules.
F
E
Have
them
highlighted
in
green
here,
basically,
the
key
fellows
module
leader,
faint
agnostic,
the
and
the
device
specific
video
and
the
e-types
module
for
reusable
grouping
and
so
on,
and
then
there's
the
MPLS
specific
module.
The
e
MPLS
e
sr
kirisaki
types,
MPLS
they're,
all
seated
in
one
documents.
At
the
moment,
we've
got
some
advice
to
split
it
up
into
two
documents:
one
containing
the
data
plane
agnostic
part
and
then
the
other
is
MPs
part.
Well,
that's
an
action
item
on
us.
We
are
planning
to
do
this
in
the
next
update.
E
E
Stuff
of
this,
this
part
about
the
organization
of
these
pockets.
I
will
go
out
of
marketing
here.
First,
the
patronage
and
terms
of
summary
I
have
to
start
by
hanging
all
the
all
the
team
that
is
continuously
meeting
and
driving
this
work
to
completion
I'm,
not
mentioning
anybody
in
specific,
but
thanks
to
all
terms
of
the
changes
we
added
RFC
references,
many
places
in
our
model,
so
that
was
one
big
update
that
we
had.
We
have
several
updates
in
the
T
panel
model
of
analysis.
A
Tarik,
thank
you
for
the
just
going
back
to
the
previous
slide.
Thank
you
for
those
updates
really
good
and
it's
nice
to
see
those
references.
There's
still,
some
I
took
a
quick
look
through
and
definitely
notice
the
a
big
change,
but
there's
still
places
where
the
there's
an
element,
that's
being
configured
that
doesn't
refer
back
to
the
base
spec.
You
know
whether
you're
talking
about
to
205
or
32
and
I
in
order-
and
it
would
be
I-
think
it's
important
on
those
in
particular
to
know
what
the
right
reference
is
for
those.
A
So
it
definitely
is
a
big
step
forward,
but
there's
still
pieces
that
don't
refer
to
the
default
lean
of
the
base
and
as
long
as
it's
not
sort
of
that
the
base
I
think
we
have
to
have
a
reference
there
and
in
some
places
I
know,
there's
not
good
references
and
in
that,
let's
just
make
sure
to
have
a
good
description.
Yeah.
E
A
E
We
have
an
explicit
route
this
where
we
specify
the
house.
We
noticed
that
we
needed
a
hint
when
the
permutation
element
for
the
engine
is
trying
to
expand
a
new
spot
we
want
to.
We
want
to
like
a
hint
to
indicate
that
it
should
stop
on
a
link
as
incoming,
so
the
computation
will
enter
the
note
specified
by
the
hop
or
it
should
exit
in
the
outgoing
case.
They
come
kitchen
will
exit
the
note
at
the
specified
Park.
E
Currently,
this
is
not
even
in
the
specific
object
of
object
that
we
have
in
our
CP.
There's
no
indication
to
say
that
this
is
the
computation
of
ship
spa
from
incoming
or
exit
or
the
egress
of
Toledo.
So
we've
got
in
the
modeling
we
needed
this
in
and
we
added
this
direction
for
the
numbered
top
case,
as
well
as
the
unnumbered
objects.
E
The
second
update
to
the
same
explicit
drop
list
that
we
have
in
the
model
was
for
the
label
and
we
added
a
label
direction.
So
in
the
list
we
have
an
option
where
we
can
add
a
label
on
a
specific
link
and
what
we
wanted
to
indicate
that
this
table
is
an
upstream
or
downstream
sign
legal,
so
for
the
forward
direction
or
for
the
reverse
direction
again.
This
applies
to
the
label,
hop
in
our
explicit
about
this.
E
E
E
The
next
action
would
be
lockout
of
protection,
which
this
allows
extra
traffic
and
normal
traffic
from
using
the
affection
confession
path,
and
we
have
an
action
force
which,
which
forces
switch
over
from
the
working
that
our
perfection
about
regardless
of
the
state
of
the
protection
path.
So
basically
there
no
additional
checks
for
the
validity
of
the
very
top.
So
the
description
we
try
to
make
it
as
as
much
as
descriptive
on
stone.
E
Hopefully
yeah.
Please
do
go
through
the
description
of
this
monthly
or
ambiguous.
Let
us
know,
and
the
next
one
in
the
manual
switch.
So
the
difference
between
a
force
which,
in
the
manual
switches
there
are
some
additional
in
the
manuals
which
case
additional
checks
of
for
validation
on
expected
from
the
device
and
the
action
exercises.
Is
it
before.
E
E
It
will
take
a
location
where
the
action
is
being
fought.
It
is
among
the
ingress
egress
or
even
on
so
there
is
there,
no
idea
where
you
can
specify
where
the
action
is
expected
to
be
involved
and
there's
a
path
reference.
So
it
is,
you
want
to
switch
over
to
a
specific
path.
You
can
supply
that
reference
and
action
will
be
taken,
switch
over
to
that
path.
And,
lastly,
what
type
of
traffic
action
is
applied.
Do
we
have
multiple
types
of.
E
The
next
update
here
is
well,
while
going
through
the
you
know
the
the
elements
that
we
needed
to
model.
We
discovered
that,
when
we're
computing
with
constraints,
we
wanted
some
constraints
to
be
relaxed
at
all.
So,
in
certain
cases,
a
strict
constraints
that
will
produce
infeasible
paths
are
not
desirable,
so
we
wanted
a
hint
kind
of
with
the
computation
region
so
that
they
can
have
a
fallback
option
and
and
relax
certain
constraint.
So
these
constraints,
we
we
thought,
are
applicable
to
include
and
exclude
broad
objects.
They
can
be
applicable
to
other
ones.
E
So
we
are
introducing
an
optimization
metric.
The
computation
engine
will
try
to
optimize
the
number
of
includes.
Obviously,
if
all
of
them
are
possible
to
be
included,
the
computation
engine
will
allow,
but
include
all
of
them
and
another
one
for
exclusions.
Optimized
excludes
again
the
the
computation
engine
will
try
to
exclude
all
of
them
and
if
it
is
not
possible
to
be
explored
all
of
them,
it
will
fall
back
and
exclude
as
many
as
possible
in
the
case
of
includes
there.
E
E
Next
I
have
the
other
two
drafts
that
we're
driving
for
those
in
terms
of
the
changes
we
have
mostly
done.
Editorial
changes,
adding
references
and
aligning
with
augmentations
to
the
other
model.
He
model
there
isn't
any
major
changes
that
we've
done
for
those
two
models
in
terms
of
next
steps
trying
to
wrap
up
updates
to
the
tea
tunnel.
E
E
E
H
H
E
E
A
Yes,
oh
this
work
has
been
going
on
for
a
while.
It's
clearly
pretty
foundational
important
work,
it's
really
good!
Thank
you!
Tariq,
and
a
machine
and
we'd
really
like
to
try
to
wrap
it
up.
We
do
have,
as
you
mentioned,
there's
a
few
things
going
on.
There's
the
this.
The
split
piece
I
know
that
also
there's
been
a
net
to
go
through
the
models
to
make
sure
that
we
have
a
good
split
of
generic
and
non-generic
I
actually
found
one
little
myth
and
going
through
it
again.
I
had
talked
of
a
lot
about
it.
If.
A
If
people
in
the
room
could
take
a
look
at
the
document
now
and
the
models
now
and
start
doing,
if
there's
a
lot
of
work
here
so
start
doing
your
review
and
seeing
if
you
can
find
any
anything,
you
think
needs
to
be
changed
because
we'd
like
to
really
wrap
it
up,
because
once
the
split
happens,
I
think
we're
going
to
be
ready
for
yang
doctor
review
and
moving
to
the
last
call
right
right,
yeah.
So
that's
so
we
really
want
to
start
wrapping
this
up.
A
So
now,
if
you
haven't
looked
at
this
in
a
while,
now
is
a
really
good
time
to
do
it.
If
you
haven't
looked
at
it
before
even
better
the
splits
gonna
be
editorial,
you
know
some.
So
the
models
are
gonna
move
and
some
words
are
gonna
move
around,
but
the
technical
content
really
isn't
gonna
be
changed.
Yeah
the.
E
A
I
Basically,
as
you
mentioned,
to
have
a
publication
request,
ability
to
poetry
model,
and
we
are
very
close
to
come
to
the
last
call
for
the
eternal
models,
and
it
is
important
to
understand
that
apology
and
animals.
They
are
not
very
complex
model,
just
very
complex
model,
to
fully
appreciate
the
complexity
of
motivation.
I
Ambition
of
this
work,
one
might
think,
as
I
do
about
this
work
as
an
attempt
to
produced
like
as
the
inversion
of
jumping,
was
basically
no
more
no
less
to
alleviate
Jim
Palace
on
the
next
evolution
of
stage
and
took
our
pretty
much
all
other
aspects
that
Jim
Palace
has
produced,
including
like
topology
discovery,
abstraction
multi-layer,
multi
domain
considerations
of
computation
traffic
engineering,
application
and
so
forth
right.
But
we
also
bring
other
aspects
like,
for
example,
telemetry
collection.
I
We
added
we
were
adding
things
that
never
existed
in
Jim
fellows,
like
Jared
mentioned,
protection,
commands
switching
commands
and
we
also
solve
a
few
problems
that
we
knew
about.
Jim
bill
is,
and
we
do,
the
discussions
will
pick
up
and
say.
Oh,
this
was
a
perennial
problem
for
us:
let's
fix
it
like,
for
example,
the
directionality
of
the
inclusion
elements
that
Eric
mentioned
on
time
to
say
is
that
this
is
extremely
important.
I
You
know
motivations
use
cases
and
stuff
that
needed
to
be
sound
somewhere
documented
and
if
we
would
just
put
into
these
two
models
which
also
contain
the
entire
source
of
the
models,
it
would
be
extremely
difficult
to
actually
finish
this
book.
So
what
I'm
trying
to
say
that
our
the
success
of
the
apology
and
tunnel
model,
in
particular
with
respect
to
the
transport
networks,
very
much
depend
on
the
success
of
this
work
presented
already
it
twice
and
it's
it's
been
adopted
as
working
group
document
and
basically
in
many
ways,
is
just
beginning
on
this
book.
I
There
are
many
definitions
and
explanations
that
are
required
by
many
people,
including
even
her
office
of
the
models.
Sometimes
there
is
very
unclear
what
exactly
we
meant
by
this
of
that.
Basically,
semantics
in
the
model,
so
there
are
also
great
need
of
use
cases
that
will
explain
how
this
model
work
the
different
guidelines,
how
these
models
could
be
invented,
so
both
so
over-smoked.
We
are
trying
to
put
into
this
document.
I
Basically,
there
were
no
much
progress
since
the
last
80
around
that,
because
we
were
focusing
on
finishing
the
topology
and
on
our
models,
but
there
were
certain
changes
that
that
happened.
For
example,
it'll
a
bird
use
of
the
contribution
upon
explaining
what
protection
commands
are,
what
shed
protection
is,
and
basically
this
is
our
goal
or
where
we
start
to
get
more
and
more
definitions
with
respect
to
all
kind
of
aspects,
including
Park,
complication,
optimization
and
an
use
cases
that
involve
all
that
people
would
ask.
I
I
Well,
I
I
will
not
try
to
basically
repeat
what
was
presented
already,
but
this
document
has
like
three
parts.
One
of
them
is
dedicated
to
definitions
for
the
poetry
model,
the
other
maternal
model
and
then
use
cases
which
basically
describe
how
these
models
could
be
used
separately
and
in
combination
with
each
other,
because
it
were
beneficial
to
use
them
in
conjunction.
But
it
is
also
possible-
and
we
consider
various
use
cases
where
each
of
the
models
are
used
independently
from
the
other,
regardless
whether
they
are
those
used
for
not.
I
Well,
I
just
want
to
encourage
people
to
risk
questions
with
respect
overturn
on
topology
model.
This
question
come
quite
frequently
during
discussions,
but
not
outside
of
their
design
teams
or
basically,
we
would
want
to
hear
them
so
that
we
could
put
more
definitions
in
different
sections
and
provide.
You
know
like
very
you.
K
I
A
The
the
document
is
very
helpful,
particularly
for
people
coming
in
to
the
work
afresh
and
there's
a
lot
of
complexity
here
in
the
models,
because
we
support
a
lot
of
different
functions
and
so
having
this
type
of
documents
really
important.
And
if
you
are
reading
the
tea
topology
dot.
It
model
that
we're
talking
about
before
the
one
that's
gone
to
publication
requests.
A
I
Just
one
more
think
that
I
would
recreate
so
Derek
mentioned
that
we
introduced
like
a
correct
unusual
elements
into
how
the
paths
could
be
computed
for
the
terrace.
For
example,
we
allow
for
optimization
and
both
just
constrained
for
inclusions
and
exclusions.
Basically,
you
can
specify
strict
inclusions
and,
or
you
can
specify
a
desirable
inclusions
that
would
be
our
computation
would
follow
as
much
as
possible,
but
also
a
in
in
relation
to
other
optimization
criterias.
I
So,
for
example,
the
the
path
computation
can
produce
the
best
possible
trade-offs
between
how
many
inclusions
are
to
a
fault
with
another
optimization
like
delay
and,
and
course
stuff
like
that.
So
basically
those
things
are
not
conventional.
They
are
not
part
of
current
PCE
and
basically
we
would
like
to
have
an
opinion
as
to
how
this
could
be
aligned
how
this
work
could
be
aligned.
I
F
Yeah
this
to
Fanta
so
I'm,
trying
to
help
you
go
to
use
of
sometime.
Okay,
so
you
know
actually
I
think
this
job.
It's
very
useful
and
helpful
for
vendors
and
also
operators
to
understand
how
to
use
term.
You
know
I
give
young
models
for
transport
networks,
but
you
know
actually
in
the
CEM.
We
also
have
another
similar
chaffed,
that
it's
a
transport,
MPI
chaffed,
so
I
think
from
the
motivation
of
this
to
Jeff.
F
They
have
the
similar
motivations
they
both
are
trying
to
describe
how
to
use
ITF
models
for
the
transport
networks
anyway,
I
think
for
the
eCos.
You
have
to
just
focus
on
that.
He,
a
generic
generic
young
like
heat
apology
and
he
tunnel,
but
I
think
anyway,
on
this
two
jobs,
the
job.
The
authors
of
this
to
job
should
have
more
discussions
and
coronations,
and
this
to
job
should
not
be
progressed
independently
from
each
other
right.
Yeah.
I
No
just
good
to
make
it
where
we
do
participate
in
a
mutual
design
team
course.
So
I've
been
personally
taken
part
in
the
MBI
and
answering
questions
that
Ito
and
serger
generated.
Okay,
so
and
on
the
other
hand,
they're
little
and
serger
and
deter
they're
like
a
quite
active
members
of
this
design
team
that
are
considered
constantly
on
our
calls.
So
so
so
we
do
cooperate.
Basically,.
A
Yeah,
the
hope
is,
is
that
the
the
folks
contributing
figure
out
the
right
split
I
mean
these.
Are
these
are
two
informational
documents,
we're
looking
to
the
authors,
to
figure
out
the
split
and
if,
for
some
reason,
they
decide
that
it
makes
sense
to
combine
it?
That's
okay
and
we'll
figure
out
how
to
run
the
working
group
process.
A
If
the
authors
think
it
that
the
split
is
artificial,
so
please
continue
on
and
continue
coordinating
now
if
it
makes
sense
to
come
to
see
camp
and
have
C
camp
here
this
work
we
can
do
that
or
vice
versa.
Have
the
the
NBI
presented
here
we'll
look
to
the
C
camp
chairs
to
provide
some
input
there
and
some
guidance.
L
Okay,
this
is
the
summary
of
the
changes
from
version
zero,
zero.
When
the
document
has
become
a
working
group,
the
draft
has
been
modified
based
on
comments
coming
from
Michael
and
the
draft
has
been
restructured
according
to
this
comment
with
a
new
introduction
and
a
start
with
the
new
terminology
section
and
a
structure
of
new
chapter
with
the
motivation
of
path
computation.
So
why
a
young
model
for
a
path
computation
request,
the
interaction
with
the
a
topology
connectivity,
matrix
concept
and
stateless
and
stateful
computation
analysis
and
description
of
the
difference
and
the
pro
and
cons?
L
There
is
the
new
there
there,
the
cap
ability
to
return
the
value
for
computed
matrix.
That
is,
help
comparison
or
they
select
the
best
solution
for
the
path
by
Orchestrator.
And
it's
then
there
is
the
introduction
of
iox
row
using
a
grouping
coming
from
eternal,
and
we
clarify
an
issue
regarding
the
endpoints.
L
Here
we
synthetizer
the
situation
of
the
github
repository
in
which
we
can
track
the
situation
of
the
drugs
and
basically,
we
we
remain
eleven
open
issue
about.
There
are
eight
of
out
of
out
of
these
open
issue
that
is
in
common
with
the
tea
eternal
and
we
proactively
work
with
them
to
solve
the
issue.
L
So
if
it
is
useful
or
not
to
have
this
type
of
possibility
in
which
you
can
choose
what
is
the
best
apology,
the
the
best
solution
between
among
different
apology
for
the
optimal
path,
so
the
the
structure
of
the
Eternals
are
set
up
in
a
given
topology.
So
the
topology
makes
the
contest
for
all
the
entities
topology
entities,
the
particle
computation
can
be
used
to
select
which
topology.
Then
we
have
two
possible
options
that
we
have
multiple
requested,
one
for
each
topology
and
another
solution
at
the
one.
Requester
attorney,
multiple
part,
one
for
each
topology.
L
L
L
Okay,
next
step
that
we
plan
to
have
for
this
draft
is
obviously
work
to
resolve
the
open
issue
and
in
particularly,
we
continue
our
cooperation
with
tunnel
mode
guys
and
try
to
have
more
comments
from
a
working
group.
And
after
a
further
cleanup
of
the
draft
request,
a
young
daughter
review.
And
so
we
would
like
to
be
ready
for
a
working
group.
Last
call
after
next
IDF.
A
L
A
M
M
As
I
said,
motivation
of
the
document
is
to
describe
how
to
use
that.
Well,
actually,
it's
a
double
double
scoop:
how
to
apply
existing
models
to
a
city,
Anna
and
define
what
is
or
better
was
missing
to
meet
actn
requirements.
In
fact,
in
the
next
slide
you
will
see
which
models
apply
to
which
interfaces
and
which
new
ones
have
been
been
defined.
M
These
sections
have
been
updated
and
fixed
the
victim,
and
then
there
was
well
a
CTN,
mostly
focus
on
the
m
VI
on
CMI
interfaces,
where
we
have
network
models,
not
device
models,
and
there
were
references
to
device
models
and
those
have
been
removed
because
they
do
not
do
not
apply
to
the
CTN
interfaces
and
we
added
also
references
attuned.
The
new
work
on
the
transport
MBI,
which
is
the
technology
specific
extensions
of
the
MPI
interface
and
Ethernet
models.
So
these
are
the
two
interfaces:
the
CMI,
the
MPI
very
shortly
kappa.
M
The
CMI
is
the
one
that
is
exposed
exposed
to
the
network
user
scenarios
in
which
it
is
used,
provisioning
event
and
and
vehicle
networks,
inter
data
center
connectivity
and
so
on
and
so
forth.
As
you
can
see
here,
the
one
in
red
is
there
is
a
water
we
added
to
the
CMI.
Basically,
one
of
the
requirements
was
to
be
able
to
set
up
services
with
de
and
water
services
constraints.
M
This
one
is
the
one
that
is
heavily
based
on
the
tea
topology
tunnel
model
path,
computation,
API
and
Swarna.
We
have
so.
We
have
highlighted
all
the
technology
independent
models,
the
one,
the
ones
that
you
have
seen,
and
all
the
technology
specific
models
because
between
the
PNC
and
then
the
mdac,
where
abstraction
cannot
be
a
can
possibly
be
not
yet
done.
M
M
M
A
Yes,
it's
great
comments,
so
I
think
I
think
one
area,
that's
still
a
little
unclear,
is
how
working
on
the
upper
interface
to
CMI
and
I
think
there's
some
disagreement
among
participants
of
whether
or
not
that
needs
to
be
the
a
CTN
service
models
or
whether
we
can
just
reuse
the
other
models.
And
so
that's
something
that
is
reflected
in
this
document
is
I.
Think
going
to
be
discussed
on
the
next
couple
of
presentations
on
the
individual
documents
and
I
think
we
still
have
to
work
through
that.
A
A
M
G
Hi,
this
is
true
from
Huawei
and
I'll
be
presenting
the
ACD
in
VN
yak,
the
draft
which
was
just
was
talking
about
and
how
it
will
be
used
at
EMI,
and
what
are
the
updates
that
we
have
done
based
on
the
feedback
that
we
got
from
the
last
meeting,
we
have
a
new
co-author,
Igor,
helped
us
reviewing
and
integrating
this
work
better
with
the
existing
yang
models.
So
what
is
this?
This
is
the
yang
model
for
virtual
network
services.
G
At
the
CMI
level,
it
is
aligned
to
the
customer
service
model
description,
that's
been
defined
in
net
mod
and
other
working
groups.
It
works
on
VN
level,
so
it
does
be
an
instantiation
VN,
computation,
real
life
cycle
as
compared
to
doing
it
on
a
path
or
a
tunnel
level,
so
it
acts
on
the
whole
VN
as
an
entity.
It
also
has
information
about
the
access
point
and
the
V
and
a
P.
G
What
is
the
VM
VN
is
nothing
but
a
list
of
various
VN
members,
so
it
describes
how
that
grouping
is
done.
Now
we
have
some
things
like
VN
compute,
where
we
can
compute
the
whole
VN
as
a
whole
and
also
have
interesting
things
like
multi-source
multi
destination
problems,
which
has
been
put
as
a
requirement
in
the
a
CDN
requirement
document
and
also
discussed
in
the
framework.
So
this
young
model
is
basically
achieving
those
requirements
and
those
frame,
those
things
that
we
highlighted
in
our
information
documents.
G
So
what
we
did
basically
in
this
update,
look
we
try
to
align
ourselves
to
the
T
topology
model
as
much
as
we
can
and
since
T
topology
model
had
a
lot
of
constructs
that
already
exist,
so
we
simply
use
them
simply
refer
to
them
and
simply
aligned
to
them
as
much
as
possible
and
anything
that
was
duplicated,
which
was
also
defined
in
the
a
CT
and
VN
model
was
completely
removed.
So
what
were
the
duplicated
things?
G
We
have
the
OPCON
set
of
assigning
constraints,
king
of
optimization,
criterias,
setting
up
explicit
parts,
all
of
that
has
been
removed
and
we
simply
relied
on
the
T
topology
yang
model
right
and
then
we
also
simplified
that
doe
we
have
of
multiple
types
of
VN.
We
can
have
VN
type
1,
which
is
a
single
node
topology,
or
we
n
type
2,
where
you
may
have
an
abstract
topology
at
various
levels:
grey
white
black,
but
to
this
model,
things
could
be
simplified.
G
So
we
have
will
talk
about
how
we
have
done
that
simplification
and
how
using
a
D,
topology,
single
node
abstraction
helps
us
to
achieve
that.
So
what
were
the
key
things
in
our
model?
We
have
the
access
information,
which
is
nothing
but
a
P
and
V,
and
a
P
which
kind
of
maps
to
T
topology
ltp.
We
have
the
concept
of
a
virtual
network
which
maps
to
an
abstract
node
in
the
T
topology
model.
G
I'll
show
a
little
bit
more
details
about
that,
and
then
we,
when
we
have
a
VN
member,
which
is
how
the
two
endpoints
are
getting
connected.
That's
nothing
but
an
entry
in
the
connectivity
matrix
matrix
or
the
abstract
node.
So
why
are
aligning
ourselves
to
the
D
topology?
In
this
way
we
have
kind
of
removed
a
lot
of
things
which
were
we
were
defining
it
again
in
our
model
and
this
kind
of
works
in
our
opinion,
like
it
works.
Well
with
the
existing
model,
so
how
does
that
look?
G
G
Wien
member
can
be
put
inside
thirty
matrix
entry,
and
this
young
model
also
had
a
concept
of
connectivity
matrices
and
their
connectivity
matrix
ID.
A
connectivity
matrices
is
a
global
container,
so
when
something
is
applicable
to
the
whole
VN
as
a
whole
and
doesn't
need
to
be
repeated
for
each
VN
member
can
we
put
in
the
connectivity
matrices,
but
when
we
have
a
specific
VN
member
detail
that
goes
and
as
an
entry
in
the
connectivity
matrix
ID.
G
So
why
are
this
concept,
which
is
already
there
in
the
gate
apology
model,
we
could
simply
refer
to
simply
ref
put
a
reference
to
the
single
node
topology
and
try
to
achieve
that
information,
and
why
are
the
single
node
topology?
You
have
the
connectivity
matrices,
which
also
have
an
underlay
contrail
container,
and
why
are
that
underly
container,
whatever
information
that
we
wanted
to
represent
about
the
about
how
the
path
is
set
up?
What
is
the
path?
What
is
the
properties?
Those
things
can
be
achieved
by
that.
G
So
this
is
an
overview
of
how
the
restructuring
and
the
major
change
that
we
have
done
with
this
update.
This
just
shows
like
the
our
old
model,
so
our
own
old
model
was
there.
We
were
repeating
some
information
like
how
to
set
the
constraints
and
what
will
be
the
optimization
criterias,
so
those
we
have
completely
remove
now-
and
this
is
the
connectivity
matrices,
which
is
a
global
thing
applicable
to
the
whole
VN,
and
this
is
per
entry,
which
is
nothing
but
a
VN
member.
G
So
we
maintain
a
reference
to
an
ID
here
and
a
reference
to
a
node
in
an
abstract
topology.
That's
nothing
but
2
BN.
So
when
we
are
talking
about
setting
a
particular
constraints,
those
constraints
goes
here
when
they
are
global,
but
when
something
has
to
be
applied
to
a
particular
v
end
that
comes
to
the
connectivity
matrix
ID.
So
why
are
this
alignment?
The
model
has
got
simplified
quite
a
bit
and
we
are
not
duplicating
any
information
across
models.
So
how
did
we
do
that
by
maintaining
a
simple
references
to
the
T
topology
model?
G
So
all
of
this
is
handled
so
now.
Let
me
just
show
you
about
how
we
did
do
this
in
VN
type
1
and
the
we
in
type
2
and
okay,
so
BN
type
1.
The
VN
type
1
is
basically
an
edge-to-edge
collection
of
VN
members
which
are
set
up
as
tunnels
in
the
underlying
network.
So,
as
we
earlier
said,
basically,
what
we
will
do
is
when
we
create
a
V
and
1
in
a
CD
and
VN
yang
model.
G
We
maintain
a
reference
to
an
abstract
node
in
the
tea
topology
model
when
we
have
various
VN
members.
Those
are
also
linked
to
the
connectivity
matrix
IDs
inside
the
inside
the
tea
topology.
When
we
have
some
VN
properties,
so
these
million
properties
are
set.
Why
are
the
connectivity
matrices
parameters
inside
the
is
inside
the
tea
topology
model?
G
So
this
having
at
this
single
node
single
node
mapping
to
a
single
node
in
te
topology
has
helped
us
to
simplify
the
model
and
now,
let's
talk
about
the
more
complicated
case,
which
is
the
type
2
topology
in
which
the
customer
expect
to
see
an
abstract
topology,
the
VN
topology,
which
is
exposed
also
to
the
customer,
but
to
simplify
the
mapping.
We
anyway
always
have
a
single
node
topology,
a
single
node
created.
This
can
be
created
automatically.
It
doesn't
have
to
be
set
by
the
customer
or
it
could
be
set
by
the
customer.
G
But
the
concept
is
the
a
CT
and
VN
model
will
always
refer
to
a
single
node
abstract
as
a
single
abstract,
node
topology
and
uses
the
connectivity,
matrices
and
connectivity
matrix
containers
inside
the
TA
topology
to
maintain
the
reference
so
dual,
the
customer
may
see
this
topology.
The
a
CT
vn
model
always
referred
to
a
higher
level
single
node
topology,
which
maintains
a
relationship
via
the
underlay
to
the
real
VN
topology,
and
the
VM
topology
might
further
have
underlay
to
the
physical,
the
physical
domain,
P
topology.
G
We
are
able
to
do
that,
so
the
actn
VN
yang
model
doesn't
have
to
worry
about
type
1
and
type
2
that
also
simplified
the
model
quite
a
bit,
and
then
we
had
like
some
of
the
things
like
VN
compute
and
multi-source
Martita
station
as
some
of
the
innovative
things
that
we
can
do
with
the
a
CT
and
VN
yang
model.
So
this
problem
basically
is
when
we
may
have
multiple.
G
We
have
a
choice
between
multiple
destinations
or
multiple
source
and
the
customers
can
see.
Nc
can
set
that
oh
go
ahead
and
set
up
a
b
and
member,
and
you
have
a
choice
between
resource
and
these
destination
and
from
the
network
point
of
view,
you
decide,
which
is
the
best
B
and
member
to
set
up
right
now,
and
that
can
also
further
change.
So
by
setting
a
simple,
a
simple
leaf
that
oh,
you
are
apart:
a
group
of
multi
source
or
a
multi
destination.
G
It
is
the
job
of
the
MDS
C
to
decide
which
one
gets
selected
and
the
selected
one
only
gets
a
actual
reference
to
the
connectivity
matrix
because
that's
something
that's
actually
getting
established,
whereas
the
intention
from
the
CNC
can
be
put
in
a
a
CT
and
VN
yang
model
as
a
part
of
various
VN
members.
But
the
VN
members
that
actually
gets
selected
is
the
one
that
has
a
reference
to
the
connectivity
matrix
ID.
G
So
just
to
us
to
summarize,
what's
the
role
of
our
AC
T
in
VN
model?
Well,
we
still
want
to
maintain
a
customer
view
of
the
VN
have
a
VN
as
an
entity
so
that
the
service
model
aspects
can
be
easily
satisfied.
You
could
still
do
some
innovative
things
like
VN
compute
computing,
the
VN
as
a
whole,
rather
than
using
us
a
set
of
path,
imputation
and
and
or
a
set
of
tunnels,
but
having
the
VN
as
an
entity
still
helps
giving
the
customer
of
view
of
VN
as
a
single
entity.
G
Like
a
little,
you
know
a
seamless
MPLS
case,
how
a
mapping
between
the
tunnels
that
are
being
used
by
these
services
is
maintained,
which
is
very
useful
to
show
to
a
customer
that
what
his
intention
was
with
the
service
model
and
what
is
being
realized
by
the
MDS
C,
so
that
mapping
also
gets
simplified
if
we
have
a
CD
and
VN
young
model
and
also
the
information
about
the
access,
the
customer
access
and
when
the
customer
access
is
being
shared
across
V.
And
that's
where
the
concept
of
V
and
AP
comes
in.
G
So
those
things
should
be
mapped
in
the
ACD
and
VN
young
model.
So
this
is
the
simplified,
a
CT
and
VN
young
model.
You
have
the
access
points
and
the
V
and
ap
a
reference
to
the
T
topology
model,
which
is
the
abstract
node
and
the
TV
apology
ID.
This
is
the
VN.
You
have
the
source
the
destination
and
then
a
reference
to
the
connectivity
matrix
ID
in
the
a
topology
model.
So
this
is
just
the
AC,
the
VN
part.
G
You
also
have
the
RPC
called
the
V
and
compute
which
I
have
not
put
in
this
diagram,
because
it's
almost
a
similar
idea
with
setting
up
of
a
configuring
of
Ian
and
multi-source
multi
destinations
is
also
handled
via
these
leaves
right
here
and
the
selected
one
is
highlighted
via
this
leaf
call,
if
selected.
So
this
is
also
explained
in
the
document.
We
still
have
some
global
properties
here,
like
admin,
state,
operational
state
and
some
other
VL
level,
diversity
requirements,
so
those
are
still
here
in
the
AC
DMV
and
young
model.
G
So
this
update,
we
basically
the
feedback
that
we
got
from
the
last
last
meeting.
We
have
tried
to
handle
that
with
this
update
and
we
feel
that
now
we
have
much
better
align
with
the
T
topology
model
and
the
T
topology
model
has,
of
course,
a
space
at
the
CMI,
because
you
need
to
expose
the
topology
to
the
customer,
but
how
the
AC
t
+
VN
yang
model,
works
well
with
the
existing
T
topology
young
model
to
give
VN
as
an
entity
as
a
customer
service
model
entity
for
our
customer
to
look
and
visualize.
G
H
I'm
dieter
Bella
nokia,
yes
yeah.
We
found
out
that
there
is
another
graph
in
the
operations
area
working
group
addressing
also
virtual
networks,
I'm,
just
wondering
whether
you
are
aware
of
that
crap,
because
it
seems
that
there
is
quite
some
commonality
between
this
draft
and
the
route
in
the
ops,
our
working
group.
G
Feel
that
we
are
talking
about
two
different
things
if
I
were,
if
I
am,
if
I
remember
correctly,
that
document
was
talking
more
about
network
slicing
and
and
sort
of
like
what
that
it
was
not,
of
course,
in
the
AC
T
M
VN,
as
we
define
in
the
case
working
row.
That's
something
that
those
guys
are
like
no
coming
at
this
problem
in
a
different
way.
But,
yes,
we
need
to
coordinate
it's
an
idea.
We
have
to
yeah.
H
G
A
A
G
A
G
N
G
A
A
A
A
Can't
these
trick
questions
rephrase
things,
how
many
think
that
this
work
is
a
suitable
foundation
for
the
working
groups.
Activity
in
this
area,
I
would
say
it's
about
the
same
number
as
who
have
read
it,
so
that
that's
good
well
before
I
say
the
next
statement
keep
in
mind
that
were
this
is
an
individual
document
if
we
adopt
that
it's
a
starting
point.
A
So
it's
okay
for
there
to
be
open
issues
when
we
start
working
on
something
that
said,
is
there
anyone
who
has
reservations
about
taking
this
document
in
as
a
working
group
document
good
answer:
don't
want
no
hands
up
all
right,
so
I
think
we
got
reasonable
responses
to
the
the
first
two
questions
about
reading
and
interest
in
taking
this
document
on
we'll
talk,
offline
and,
of
course,
anything
we
don't
make
any
final
decisions
here.
We
confirm
on
the
list.
Thank
you
very
much.
H
A
N
N
N
So
basically,
this
model
tea
service
metal
model
in
the
middle
are
basically
create
a
mapping
relationship
between
this
various
service
model
and
the
traffic
engineering.
True
or
a
CT
and
VN
model,
because
group
explained
HDTV
end
model
has
a
good
relationship
and
a
reference
point
to
tea
topology
model.
As
you
see
here,
and
then
tea
topology
model,
as
ego
explains,
always
work
together
with
eternal
model,
so
that
whatever
in
a
service
model,
need
to
be
connected
seamlessly
with
the
traffic
engineering.
N
We
need
key
service
mapping
model
instead
of
specifying
some
T
specific
policy
or
binding
relationship.
How
service
should
be
bound
to
at
eternal,
for
instance,
isolation
mapping?
You
know
I
want
my
service
to
be
isolated
from
other
VP
other
tunnels,
for
instance,
as
those
are
information
that
we
conveyed
or
you
can
do
it
at
a
service
model,
but
service
model
doesn't
have
that.
So
we
think
that
it
might
be
good
to
have
one
focal
point
or
the
shim
layer
so
to
speak
or
to
buy
doll.
N
N
Services
with
a
solution,
mapping
and
then
site
mapping
as
well
as
supposed
to
provide
it
with
the
proper
site
mapping.
But
one
of
the
important
thing
is
a
map
type
which
is
applied,
whether
we
choose
layer,
3
or
layer,
1
or
layer
to
this
map
type
is
very
important
in
terms
of
isolation
or
not,
for
instance,
we
kind
of
specify
some
example
map
type.
N
You
know
customer
wants
to
create
VN
a
new
VN,
but
I
don't
want
to
share
with
anybody
else,
for
instance,
so
it's
called
hard
isolation
do
so
requirement
has
to
or
intent
has
to
be
conveyed
or
I,
don't
care
whether
I
share
with
other
a
tunnel
and
output.
I'll.
Just
give
me
any
tunnel,
for
instance,
so
they
can
be
specified
as
a
TN,
TN
selection
and
then
or
you
can
be
I
just
don't
want
to
create
another
tunnel,
but
just
modify
the
advantage
of
existing
tunnel,
for
instance.
N
So
those
are
kind
of
example,
map
type
that
can
be.
You
know,
facilitated
using
a
tea
service
model,
tea
service
mapping
model.
So
this
one
is
actually
dependent
on
the
progress
of
VN
young
model
and
I
hope.
I
see
some
positive
feedback
from
the
working
group,
and
this
is
kind
of
the
last
clue
that
will
really
facilitate
service
model
to
RT
and
topology
through
a
CT
and
VN
also.
N
So
it's
also
worked
on
this
quite
a
while,
and
actually
this
is
driven
by
operator
requirement
and
and
we
believe
that
history
could
be
a
good
base
for
the
working
group
adoption
and,
of
course,
the
map
type.
We
haven't
defined
details
yet
and
also
had
a
comment.
Previous
ITF
meeting
we
can
add
to
the
most
specific
map
type
which
may
not
be
covered
by
here.
So
we
have
still
work
to
be
done,
but
we
believe
that
this
might
be
a
good
start.
Starting
point.
B
K
N
N
And
architecture-
and
this
is
another
step
further,
but
we
are
ITF
and
then
we
have
all
the
service
model
defined
here.
Young
models
already
so
I,
don't
think
we
need
to
eat
much
concerned
about
any
F.
But
if
MF
wants
to
have
the
other
relationship
with
us,
we
can
actually
provide
young
models
for
them
so
that
ITF
mother
can
pro
you
know,
progress
further
into
other
fields
and
like
Crimea,
four
levels
here
same
model
service
definition
they
actually
make
a
liaison
which
she
can't
and
sitting
has
young
mother.
Also
that's
work-in-progress
like
that.
N
C
In
general,
I
I
do
think
that
this
working
group
should
look
at
working
on
a
charity
service
mapping
function
at
this
point,
I'm
still
trying
to
figure
out
whether
this
needs
to
be
done
in
a
generic
fashion.
I,
don't
see
the
reason
why
this
needs
to
sit
in
one
of
the
actn
umbrella,
but
let's
see
how
the
previous
document
is
nice
to
tune
umbrella.
It
does
but
use
the
duck.
If
you
read
through
the
draft,
it's
very
much
tied
to
a
CTF,
but
let's
see
how
the
other
document
progresses
and
then
they
can
revisit.
Okay,.
C
C
I
G
G
G
A
Think
this
goes
to
the
disconnect
that
I
was
talking
about
earlier,
where
some
CTE
topology
as
equally
applicable
as
a
service
module
model
as
it
is
on
it
as
a
device
as
device
and
I
think
we
have
a
difference
of
perspectives
here
and
that
we
have
to
work
through
as
a
group,
but
I
think
that
that's
what's
going
on
here
is
is
that
we
have
that
disconnect
of
perspectives.
So
we
can
have
more
discussions
here.
That's
good!
No,
no
continue
come.
We
can.
We
can
have
more
discussions
here.
A
G
I
Is
forward
so
I'm
small
I
agree
with
you
on
the
service
mapping
problem.
It
has
to
be
solved
in
the
general
way
we
have.
For
example,
we
have
like
a
lot
of
discussions
in
ethernet
layer
and
how
to
map
say.
Epl,
services,
EVPs
or
I
said
we're
on
the
tunnels
as
well,
and
it's
almost
you
know,
they're
back
on
the
same
issues
as
well
as
you
have
here
and
I
would
say
that
their
teeth
are
not
sent
apology,
it's
it's
something
which
should
be,
in
my
opinion.
I
I
Then
you
have
another
model
which
describe
a
device
specific
model:
how
to
map,
for
example,
service
on
a
particular
PE
with
respect
to
the
tunnels,
and
then
there
is
a
totally
separate
model,
which
is
a
tunnel
model
which
basically
ensures
the
services
and
you
can
map,
whereas
services
on
those
tunnels
and
see.
Pollicis
is
just
one
part
of
a
service
mapping.
There
are
other
police's,
which
could
be
also
considered
as
well,
and
this
is
not
our
job
to
discuss.
But,
for
example,
how
do
you
constraint
the
connectivity?
I
You
know
what
kind
of
length
on
weapons
on
the
edges
stuff
like
that
right?
How
you,
for
example,
translate
the
LAN
ID
is
coming
from
customers
into
the
LAN
ideas
going
onto
network
this.
Those
are
very
generic
issues
that
needs
to
be
actually
discussed
as
a
separate
issue.
It
would
be
good
to
have
like
some
some
kind
of
service,
independent
agnostic
model
that
provides
like
various
you
know,
divisions
like
key
policies
like
connectivity,
limitation
support,
but
but
but
I
would
strongly
suggest
to
actually
decouple
the
T
tunnels
from
the
services
the
tunnel.
I
So
that's
something
that
infrastructure
that
source
thesaurus
like,
for
example,
there
should
be
a
layer,
3
VPN,
which
is
delay
constraint.
Okay,
so
and
the
customers
say
I
want
to
have
left
the
end,
which
has
like
this
kind
of
latency.
The
only
way
to
produce
us
before
that
creator
is
to
come
up
with
the
Chicanos
which
are
properly
optimized
them
to
state.
So
that
the
role
that
these
will
be
connected,
these
certain
panels
right
certain
constraints,
but
those
tunnels
can
sue.
I
N
You
know
service
say
you
know
10
millisecond
and
then
I
don't
it
has
to
be
deterministic,
for
instance,
without
any
variation
of
Q
delay,
and
this
one
accepts
and
then
make
sure
that
the
T
eternal
will
be
created
as
a
such
such
a
fashion,
and
then
the
custom
will
be
able
to
monitor
in
a
closed
loop
through
a
telemetry
model
so
that
they
understand
you
know
what
they
have
requested
its
instantiate
in
the
proper
way.
So
those
things
actually
are
this
one
actually
provide
that
glue.
I
So
one
thing
is
that
sometimes
it
sounds
like
duplication
of
what
you
specify
as
a
TV
policy
with
us.
What
do
you
specify
as
a
key
constraints?
Optimization?
But
in
fact
it's
not
that's
not
true,
say
the
customer
may
say:
I
want
to
have
our
saved
99.99
percent
availability
or
or
basically
the
diversity
of
these
two
services,
and
this
could
be
translated,
but
you
know
to
say
SLT
to
join
right,
but
customer
doesn't
know
what
the
seulji
means
right.
He
doesn't
have
no
clue
how
several
G
is
assigned.
I
What
does
it
mean
whether
it's
a
single
cable
or
single,
building
or
single
geographical
area?
He
only
cares
about
you
know
like
availability,
and
this
is
something
that
we
can
common
and
choose
a
operator
or
violation
of
this
right
and
it's
the
joke
of
service
weapon
into
map
into
particular
constraints
and
optimization
as
to
how
the
tunnels
could
be
actually
set
up
on
the
provider
network.
P
Adrienne
Farrell,
so
I
think
either
nailed
it
there
and
the
the
generalization
of
that
statement
is
that
service
is
not
aware
of.
The
service
model
is
not
aware
of
the
content
of
the
network
and
and
somewhere.
You
need
a
model
that
is
aware
of
the
content
of
the
network,
but
there
may
also
be
a
little
loop
around
in
that.
N
Yeah
I
think
you
know,
that's
exactly
why
you
know
key
service
mapping
is
needed
because
service
model
doesn't
address
how
te
should
be
constructed.
That's
why
this
is
gluing
between
this
two
world,
so
their
customer
can
have
a
visibility
of
underlay
and
monitor
monitoring
capability
in
the
closed
loop.
So
there's
a
purpose
to
review.
A
Provide
was
a
Adrian,
I
think
Adrian.
Actually,
you
know
he
had
a
point
that
I
always
go
to
is
recursion
piece
sure,
so
these
are
really
good
things
to
capture
here
and
really
important,
right
and
and
with
that
I
think
we'll
have
some
really
good
work
to
reach
over
okay.
Okay,
thanks.
Thank
you
very
much.
A
A
A
I
So
this
is
the
work
then
I'm
personally
very
excited
about
and
so
do
micro
office,
and
we
have
a
new
co-author,
which
is
Jeff
in
surah,
who
is
also
we're
excited
about
this
work,
but
unfortunately,
our
people
outside
of
this
group,
we
feel
kind
of
to
get
the
the
same
level
for
excitement
so
far.
Okay,
so
that's
why
our?
Basically
we
have
no,
no
any
progress
on
the
model
that
we
actually
wrote
before
Singapore
and
it's
fully
it's
actually
written
and
it's
it's
quite
good
in
my
opinion
right.
I
But
but
we
need
to
obviously
some
other
comments
on
that
and
I
think
we
have
the
same
issue:
I
hope
that
we'll
have
the
same
problem
as
steam
engines
right,
which
we
are
appreciated,
not
when
they
were
invented,
but
when
the
era
of
the
steam
engine
arrived
right.
So
so
what
we're
hoping
that
you
of
software
at
apologist
is
rapidly
arriving
in
the
form,
for
example,
as
Network,
slicing
and
stuff
of
that?
Okay.
I
Yes,
so
basically
just
to
remind
what
what
is
the
whole
idea
of
this
work
twenty
years
ago?
If
you
look
at
the
network
it,
basically,
it
was
just
a
topology
that
would
explain
how
the
connectivity
services
could
be
provided
on
the
net
or
how
to
get
like
information
from
point
A
to
point
B
across
the
network,
and
then
it
would
have
some
kind
of
T
parameters,
attributes
that
you
can
constrain
the
past
Alexis
stuff
like
that,
but
everything
was
limited
only
to
the
connectivity
right
so
and
network
today
is
a
very
different
animal.
I
So
network
provides
not
just
connectivity
services,
but
many
other
services
service
function,
Network
functions
and
for
the
client
it
is
very
important
to
see
not
just
the
network
topology,
but
also
what
is
available.
What
kind
of
services
are
the
client
can
outsource?
You
know,
and
it
sees
the
service
not
just
like
a
connectivity,
a
connection
or
a
tunnel,
but
a
change
for
such
tunnels,
which
are
properly
constrained
and
optimized
and
connect
appropriately
selected
network
functions,
so
so
that
the
data
is
not
coming
from
A
to
B
but
experience
certain
processing
and
so
forth
right.
I
So
so
we
see
it's
important
to
provide
information
about
not
just
topology,
illogical
elements,
but
also
the
service
functions
available
on
this
network
and
importantly,
how
they
are
related
to
the
topology.
Where
do
this
service
function
leave
or
can
leave,
and
so
that
the
user
can
have
a
say
as
to
how
the
service
function
chain?
Not
just
a
tunnel
could
be
created
and
optimized.
I
So
things
like
that
so
graphically
the
service
function
where
topology
looks
like
it
is
on
the
picture
now.
So
it's
it's.
You
can
see
it.
For
example,
like
IT
topology
with
18
nodes
are
hosting
various
service
functions,
and
then
we
find
some
components
of
the
basically
topology
very
useful
to
describe,
for
example,
which
service
functions
are
available
on
which
nodes
and
employing
connectivity,
metrics
concept
to
describe
how
they
and
whether
they
could
be
connected
at
work
course
just
to
remind
the
connectivity
matrix
basically
is
used
to
describe
that
nodes,
switching
limitations
and
capabilities.
I
So
what
we
decided
is
why
not
to
employ
an
intuitive
method
and
in
particular,
detail
connectivity
methods
for
service
functions
and
describe
which
service
functions
could
be
connected
on
a
given
node
and
at
what
cost.
For
example,
what
kind
of
delay
would
introduce
connect
an
SF
1
to
SF
to
what
kind
of
bandwidth
limitations
how
they
could
be
protected?
I
Stuff
like
that,
and
then
we
also
can
provide
the
similar
connectivity
matrices
to
specify
which
service
functions
could
be
connected
to
nodes,
Lync
termination
points
and
tunnel
termination
points,
so
that
various
service
functions
could
be
interconnected
not
just
on
the
node
but
across
the
network,
right
yltp
to
the
neighboring
node,
and
why
TTP's
service
fashion
could
be
connected
located
anywhere
in
the
network.
So
now,
basically,
what
happens?
I
Is
that
the
path
computer,
having
this
knowledge,
can
do
what
we
call
dual
optimization
and
optimize
the
selected
service
function
chain
on
two
criterias
on
the
location
of
service
functions
as
well
on
the
tunnels
interconnecting
them
so
and
there
could
be
a
pretty
good
idea
how
what
kind
of
end
to
it
to
add
delay
could
be
for
entire
service
function,
as
well
as,
for
example,
between
the
neighboring
service
functions.
Okay,
and
as
we
discussed
as
we
present
that
in
Singapore
right,
there
could
be
various
interesting
use
cases
like,
for
example.
I
How
can
you
or
say
do
proper
optimization
of
teton
also
so
that
the
proper
constraints
could
be
satisfied
between
the
two
neighboring
service
functions
and
end-to-end?
How
can
you
protect
our
satisfaction
if
a
node
or
a
function
fails?
You
know,
how
can
you
go
from?
How
can
you
do
a
lot
of
balance
and,
and
things
like
that,
so
it's
it's
pretty
interesting
concept
and,
in
my
personal
opinion,
it's
a
it's
almost
perfect
start
for
networks.
I
Now
young
one
of
Kawarthas
came
was
a
interesting
idea.
He
said
why
why
stop
on
service
functions,
who
are
not
to
shoot
us
into
the
and
strata?
Okay
and
basically
described
applications
can
make
use
of
information
about
tu
they
work
on,
and
there
are
various
applications
that
that
could
be
considered,
including,
for
example,
where,
as
web
caches
are
like
a
content,
network
distribution
right
like
I,
see
a
CD
ins
and
and
my
personal
favorite.
It's
a
high
frequency
trading
application,
which
you
know
since
I
have
a
bit
of
luxury.
I
I
So
how
quickly
you
can
learn
information
and
how
quickly
you
can
react
on
that
right.
This
would
give
their
client,
for
example,
the
idea
aware
to
put
the
application
to
begin
with.
There
is
a
very
expensive
but
very
profitable,
potentially
service.
That
exchange
can
provide
to
a
client
by
allowing
to
what
they
call
collocate
collocation
to
collocate
there,
for
example,
brokerages
next
to
exchanges
right
and
then
you
can
have.
You
can
know
how
to
optimize
your
transport
network.
I
Some
people,
for
example,
replace
lambdas
with
microwaves
just
because
why
can
we
have
speed
of
light
and
fiber
doesn't
right?
It
has
only
a
fraction
of
that,
so
things
like
that
right
so
and
basically,
the
whole
idea
is
that
there
in
in
ideal
world
are
this
prices
and
these
trades
are
done
instantaneously,
but
there
is
always
discrepancies
between
the
current
price
and,
for
example,
on
one
exchange
and
the
other
exchange
and
the
the
price
of
a
stock,
and
it's
derivative
like
say,
option
and
and
future
and
people
are
put
in.
I
You
know
morale
aside,
okay,
but
it's
totally
legal
to
exploit
these
discrepancies
and
loopholes,
and
the
client
can
get
a
lot
of
advantages.
Just
looking
and
optimizing
this
network
and
use
the
knowledge
into
what
they
call
their
route
in
applications
that
route
there
are
three
requests
and
distributed
in
the
most
optimal
way
between
available
exchanges.
So
this
is
just
one
way
how
the
model
would
be.
I
I
Right
so
so,
as
I
said,
we
did
erode
the
moon,
the
young
model
for
that,
and
but
there
are
certain
challenges
that
we
have,
for
example,
we'll
rely
on
the
HC
definitions
of
the
services.
Okay,
so
far,
we
we
depend
on
them
and
we
try
to
be
dependent
on
them
as
loose
as
possible.
We
just
use
service
IDs
and
source
instance.
Ids,
like
a
big
numbers,
but
interested
client
might
want
to
understand
what
the
services
are
especially
to
understand
their
in
extent
of
mutual
substitutive.
I
For
example,
if
I
want,
they
have
a
fella
on
one
note
of
a
certain
function
and
I
want
to
go
to
another
node.
So
I
need
to
understand
how
similar
these
functions
and
to
what
extent
they
can
substitute
each
other
right.
So
the
problem
that
we
have
it's,
basically,
the
egg
and
chicken
right
so
on
one
hand,
we
are
told
that
we
cannot
define
the
services
ourselves
because
that's
the
job
of
get
see,
but,
for
example,
on
the
other
hand,
se
is
not
quick
enough
right,
so
the
progress
is
very,
very
small.
I
So
what
can
we
do
about
this?
So
can
we,
for
example,
issue
license
as
we
do
to
ITU
or
top
of
that
or
on
water,
but
in
order
to
get
to
this
stage
right,
we
need
to
have
some
sort
of
interest
in
this
call
so
and
I
hope
that
Network
slicin
will
actually
produce
a
sufficient
interest
and
sufficient
power
that
we
can
leverage
such
instruments
right.
So
one
of
the
courses-
Louise
I,
don't
know
whether
it
is
in
the
yeah
yeah.
I
He
mentioned
that
he
would
bring
this
Moodle
Internet,
wise
and
environment,
and,
yes,
we
will
try
to
do
our
best
to
actually
use
this
as
a
very
important
use
case
for
for
this
model,
and
once
we
get
to
this
point
there.
Obviously,
though,
the
various
comments
and
recommendations
as
to
how
to
modify
augment
our
model.
E
Question
Tarek
Francisco
hi,
your
yeah.
If
you
go
back
to
one
of
the
figures
that
you
had
your
show
us
a
previous,
so
the
the
service
function
the
way
you've
modeled
it
is
a
property
of
I
know.
Yes,
do
you
think
the
service
function
can
be
in
a
standalone
and
a
function
element
in
your
model,
not
hosted
on
a
routing
or
switching
switch
or
another
outing
or
switching
node
yeah.
I
I
Okay.
So,
in
order
to
combine,
for
example,
tea
links
right
with
the
service
functions
and
their
course
right,
so
we
had
to
go
this
way
if
it
would
produce
like
a
separate
note,
it
would
be
totally
different
picture
and
personally
I
don't
see
an
advantage
to
let
right
I
would
actually
add
even
applications
as
attributes
to
the
north.
So
the
note
could
be,
for
example,
a
data
center
I
see.
E
F
This
is
a
fact,
I'm
comment,
verification,
so
I
tell
some
examples
on
the
service
function
you
listed
in
this
chapter,
including,
for
example,
firewalls
epi
I,
think
they
a
they
are
all
applicable
for
the
network.
So
my
comment
is:
if
the
service
faction
of
where
technology
can
also
be
applicable
for
the
chance
for
Network
OTN
yeah.
I
For
example,
you
may
think
about
service
for
the
network
function
as
three
re
generator
right
and
you
can,
and
normally
people
put
through
our
generators
in
like
strategic
pools,
like
I,
said
strategically
replace
all
the
network,
and
this
would
make
for
T
application
very
interesting
to
your
application
with
you
can
assign
dynamically
regenerators
without
having
operators
to
explicitly
specify
where
they,
for
example,
based
on
optical
environments,
consideration,
okay,
so
this
would
be
one
a
use
case
for
like
layer,
1
layer,
0
network
function,
the
other.
There
are
other
examples
like,
for
example,
certain
thorium
capabilities.
I
They
require
certain
hardware
support
or
the
Indian
network,
which
is
not
readily
available
on
all
devices.
This
also
could
be
modeled
that
what
Martin
results
actually
suggested.
They
also
could
be
modeled
as
network
functions,
which
so
basically
only
certain.
But
not
all
network
elements
will
have
such
possibilities,
and
then
you
can
route
your
tunnels
in
such
a
way
that
oi'm
will
be
like
a
most
feasible
and
most
efficient.
F
C
I
No,
no,
the
whole
point
is
that
we're
trying
to
build
this
Moodle
as
an
augmentation
to
cheat
on
a
tree.
Topology
model
right
and
this
model
will
provide
the
identity
of
the
functions
that
available
on
the
network,
as
well
as
the
constraint.
As
for
how
this
functions
could
be
connected
locally
and
the
course
in
network
right.
C
But
you
say,
for
instance,
you
have
a
firewall,
but
that
particular
firewall
and
a
particular
node
is
utilized
ninety
percent
and
you
only
have
a
10
percent
of
ability.
Now
there
could
be
other
places
where
the
firewall
is
available.
Was
your
topology
change
based
on
the
service
of
ability
and
the
percentage
utilization
or
the
viability
of
the
service
itself?
Not
you
know
that
you
have
a
key
constraint.
I
Point
so,
basically,
so
far
we
haven't
considered
their
attributes
of
the
Souris
functions
per
se,
because
we
hoped
that
by
looking
up
like
definitions
defined
by
HC
and
the
models
like
Tosca
Moodle
support
that
we
could
get
such
information,
but
we
might
get
actually
the
resources
that
available
on
for
service
function
basis.
Partially.
We
consider
that,
because,
when
we
say
connect
source
version,
one
without
ammunition
point
we
specify
at
which
breathless
it
could
be
connected.
Okay,
obviously
could
not
be
more
than
breakfast
available
on
the
function
itself.
I
D
K
Iv
sigani
future
we
yeah.
This
is
interesting
because
we
are
looking
into
separating
the
service
layer
and
primarily
our
information
model.
I,
don't
know
you
Korea
looked
at
it
or
not.
The
information
model
includes
the
service
function
and
this
topology
graph
and
that
graph
will
basically
primarily
tribes
their
service
layer
connectivity,
nothing
at
the
network
level.
Now
there's
a
separation
of
the
information
model
from
the
data
model
describe
the
actual
network.
Are
you
planning
to
separate
those
two
layers?
K
Because,
because
someone
mentioned
that,
if
s
service
function
is
the
attribute
of
the
node
or
my
opinion
to
know
that
service
function,
that
layer
is
different
from
the
actual
network
connectivity?
If
you
and
really
connect
those
points
together,
you
need
to
define
like
a
data
model.
You
mentioned
task
area,
so.
K
To
map
the
toss
about
the
service
layer
into
a
data
model
at
that
data
model
could
be
specific
to
your
underlying
network.
Okay,
for
example,
if
you
say
layer,
2
network,
where
they
are
trimming
is
that
separation
is
already
I
have
yet
you
draft
yet,
but
is
that
the
part
of
your
desk
over
your
draft
or
no?
Oh.
I
Well,
what
we
are
trying
to
achieve
is
that
we
want
to
decouple
service
models
from
from
basically
the
topology
models
right
and
but
we
also
want
to
combine
them
together
in
a
way
that
you
can
do
this
dual
optimization.
So
it
doesn't
matter
for
us
whether
it's
Bosco,
no
postcode
it
have
produced
service
models
as
far
as
their
should
could
be
some
IDs
that
could
could
be
used
to
interconnect
this
models.
I
personally,
do
not
like
very
complex
Eon
models,
which
you
know
with
more
man
porn
stuff
out.
I
There
I
prefer
much
better
to
have
a
simple
models
that
could
be
interrelated
based
on
like
IDs,
rather
than
full,
say
X,
passes
and
perfect,
and
because
one
reason
is
that
some
clients
may
be
interested
for
certain
things,
but
not
others,
and
they
don't
want
to
bother
with
a
lot
a
very
large
and
complex
models.
So
if
I
am
only
interested
as
to
how
service
functions
could
be
connected,
but
I'm
not
interested
what
exactly
they
are
doing.
A
O
Just
there's
difference
between
network
view
and
application,
application
driven
networking
and
you
should
look
it
from
perspective
of
network
doing
application.
So
imagine
it's
front
hall
and
a
particular
constraint
this.
Where
it's
going
to
play,
we
don't
want
to
mix
viral
capacity
with
you
know
what
dealing
right.
A
Q
Q
A
N
A
We
keep
in
mind
that
we're
talking
about
the
use
cases
here
and
the
question
for
the
working
group
is:
does
this
working
group
want
to
work
on
this
type
of
these
types
of
solutions,
and
if
we
do
talking
about
identifying
what
the
use
cases
are
is
a
great
place
to
start.
So
the
first
question
for
the
working
group
is:
do
we
want
to
be
working
on
these
types
of
solutions
that
Igor
has
been
talking
about?
I?
Think
we've
got
some
good
support
on
that.
A
How
many
people
think
that
the
document
that
was
presented
is
a
reasonable
place
to
start
the
discussion
on
what
are
the
use
cases?
I
would
say
the
same
number
note
that
I
did
not
ask
how
many
have
read
the
document.
So
I
will
ask
that
now
how
many
of
read
the
document
slightly
more
than
the
previous
two,
but
the
previous
two
questions
had
I
think
had
good
support.
Thank
you
very
much.
Well,
we'll
talk
offline,
the
chairs
and
I
assume
you'll
see
it
on
the
list.
A
J
So,
okay,
we've
got
this,
be
a
working
group.
What
we've
been
defining
you
know:
new
multicast,
forwarding
and
I
wanted
to
give
a
quick
background
of
that.
So
the
state
is
that
we've
basically
finished
the
definition
of
the
shortest
path
forwarding
model
which
we
call
beer
and
have
adopted
the
forwarding
plane
model
for
the
you
know:
hop-by-hop
controlled
forwarding
for
traffic
engineering
and
with
the
working
group
going
more
towards
an
attract
now.
J
So
let
me
give
you
quickly
the
background
here,
a
traditional
multicast
problem.
So
why
are
we
doing
beer?
The
problem
multicast
is
that,
instead
of
simply
having
prefix
or
seat
forwarding
entries
that
are
the
size
of
your
network,
topology
in
traditional
multicast,
you
have
forwarding
and
control
plane
state
that
you
need
to
build
on
every
transit
hub
in
the
network,
which
we
call
multicast
trees,
and
the
number
that
you
need
is
you
know
the
possible
number
of
sources
by
the
possible
number
of
subsets
of
receivers
in
the
network.
J
You
have
50
receivers
worst
case
until
tenant
and
source.
You
have
ten
by
the
power
a
two
by
the
power
of
ten
times
two
by
the
power
of
fifty
different
trees
that
you
need
to
build
right,
and
you
know,
operators
weren't,
really
so
keen
and
managing
all
these
trees
in
the
network.
So
that's
basically
the
root
cause
for
going
to
a
model
which
you
know
similar
to
segment
routing
tries
to
avoid
having
stayed
in
the
network
and
it's
even
worse
in
multicast
because
in
you
know,
segment
routing.
J
It's
still
only
about
the
path
topology
and
the
number
of
pests
you
want
to
have.
So
it's
really
independent
of
most
of
the
application
specifics,
while
a
multicast,
it's
very
naturally
based
on
how
many
applications
you're
running.
So
this
is
basically
for
later
reading.
Writes
I,
didn't
wanna,
show
all
that
stuff.
So
with
beer
proper,
there
is
no
state
in
the
network
anymore
right,
so
basically
I'm
not
sure
if
it's
appropriate,
but
let
me
try
to
explain
it
in
terms
of
segment
routing
right.
J
So
imagine
that,
instead
of
simply
having
you
know,
the
LD
pre
fee,
pre
LD,
P,
LD,
P
free
network
with
you
know
a
single
label
to
indicate
a
receiver
in
the
network.
Now,
basically
in
your
packet
header,
you
have
just
you
know
a
sequence
of
all
the
possible
receivers.
You
want
this
negative
received
it
right.
So
basically
you
want
to
send
it
to
p2
p3.
You
basically
put
the
seats
of
p2
p3
in
there
and
let
me
see
if
we
can
actually
have
this
so
in
p1
you're.
J
Looking
at
the
packet
and
you're
saying
oh
wait,
a
second,
so
I
need
to
send
it
to
p2
p3.
So
let
me
make
one
copy
to
every
interface
where
I
have
from
my
routing
table
at
least
one
receiver.
There
that's
pretty
much
what
beer
does
on
every
hop.
It
basically
looks
at
all
the
destination
addresses
and
figures
out,
okay,
which
interfaces
do
I
need
to
send
one
copy
to
every
interface,
where
I
have
one
or
more
receivers
behind
it.
And
basically
you
know
it's
you.
J
It's
just
routing
on
the
shortest
path,
okay,
you
say,
but
if
I
have
20
or
128-bit
for
every
address,
the
header
gets
fairly
large
if
I
want
to
address
something
like
50
or
100
receivers,
which
is
why
we're
simply
addressing
every
receiver
by
a
single
bit
write
our
address
space
is
from
address
1
to
address
256
or
could
get
as
large
as
1,024.
If
your
header
is
a
thousand
24
bits
and
that's
basically,
what
we're
showing
down
there
right,
you've
got
the
beer
header,
and
here
you
see
two
red
bits
so
bit
number
two.
J
Okay,
this
packet
needs
to
go
to
p2
bit
number
three
green
right,
two,
three
and
four
and
five
right.
So
basically,
you
know
you
can
compress
addresses
down
to
bits
if
you
don't
have
that
many
and
well,
if
you
now
have
something
like.
Maybe
a
thousand
peas
in
that
you
need
to
target-
and
you
only
want
to
you
know-
have
an
overhead
of
256
bits.
Well,
what
are
you
going
to
do?
You're
simply
going
to
send?
Well,
maybe
four
packets
right.
J
So
yes,
multicast
originally,
you
said
one
tree
is
good
enough,
but
when
the
trees
actually
become
a
problem,
maybe
it's
less
of
an
overhead
to
basically
instead
say
well,
I'm
still
getting
a
benefit
of
twenty
fifty
six
times
less
data
to
send.
So
why
do
we
need
to
do
more?
So,
basically,
that's
why
you
know
the
bit
string
language
support,
typically
256
bits
for
beer
is
seen
as
good
enough
and
otherwise
you'll
send
more
packets.
So
this
is
basically
you
know
the
typical
shortest
path
architecture.
J
So
the
path
engineering
that
you
can
do
in
this
environment
is
typically
based
on
a
really
nice
ecmp
architecture.
We
have
there
and
based
on
you,
know
using
all
type
of
different
topologies
of
an
IGP
and
engineering
your
IGP,
but
it's,
of
course
doesn't
support
the
typical
explicit
path
set
up
that
were
known
from
rsvp-te
or
that
we
can
do
in
segment
routing
with
specifying
also
a
label
stack
with
intermediate
house.
So
that
is
exactly
where
te
comes
in
beauty
and
so
in
beer
to
e.
J
The
bits
are
not
indicating
only
the
receivers
but
they're
simply
indicating
the
interfaces
on
the
path
themselves,
so,
for
example,
with
the
same
type
of
trees,
the
the
red
one
as
one
g1
going
here.
Basically,
you
would
need
the
following
bits:
right
from
the
sender.
You
would
basically
say:
okay.
This
interface
here
is
bit
number
two,
this
interface,
three
four
five
and
you
would
basically
just
set
to
three
or
five
those
bits
in
the
beer
header
to
get
basic.
You
need
the
packet
passed
over
this
non
shortest
path
here
and
then
replicate
it
here.
J
Likewise,
the
other
examples
right
you
just
assign
bits
to
every
interface
and
again
like
in
the
beer
case,
one
bit
for
every
address
you
need.
The
big
forwarding
difference
is
simply
that
in
beer,
you're
looking
on
every
hop
in
all
the
destination
address
and
trying
to
figure
out
where
to
send
it
to
and
the
logic
in
beer
te
is
very
simply
that
you
simply
need
to
look
only
at
those
bits
that
you
have
direct
adjacencies
right.
J
P
one
would
never
bother
looking
into
whether
there
is
another
copy
going
up
here,
overbid,
three,
four,
five:
four,
so
it's
simply
ignoring
all
the
bits
that
it
doesn't
have
direct
adjacencies
for,
but
otherwise
it
also
in
peril,
looks
at
all
the
bits
and
individually
creates
copies
for
every
bit.
That
is
being
said
and
that's
the
direct
adjacency.
So
that's,
basically
the
simple
rule.
Now,
obviously
there
is
a
good
discussion
about
what
is
the
bit
overhead
that
we
have?
How
large
can
the
topologies
become?
J
The
forwarding
architecture
has
a
lot
of
details
about
that,
and
so
there
are
a
lot
of
tricks
to
reuse.
The
same
bits
in
different
parts
of
the
topology
I
was
just
here
showing
a
simple
case
that
obviously,
on
a
point-to-point
link.
Both
sides
can
use
the
same
bit
right.
So
you
just
need
one
bit
in
the
same
way:
a
LAN
can
use
one
bit.
A
ring
could
use
two
bits
for
you
know
clockwise
and
counterclockwise.
J
J
A
few
points
in
my
topology
that
I
want
to
steer
traffic
true
and
basically
in
between
that
are
not
going
to
do
hop-by-hop
path
with
beer,
but
I'm
just
going
to
build,
for
example,
segment,
routing
tunnels
between
the
different
replication
points
and
that's
what
we
call
routed
adjacency.
You
have
some
bit
you
replicate,
but
you
don't
send
it
to
a
direct
neighbor.
You
send
it
through.
You
know
an
adjacency
which
you
have
predefined
to
be
a
segment
routing
town.
J
So
there
is
in
the
drafts
that
we
have
up
for
this
in
the
working
group,
some
interactions
between
beer
te
and
this
and
obviously
you
know,
given
that
the
resilience
and
not
only
the
path,
selections
to
keep
heart
of
the
dead
net
use
cases.
We
felt
that,
for
the
framework
of
traffic
engineering
wanted
to
include
this
a
resilient
functions
as
well
and
a
proper
to
figure
out
how
to
basically
provision
and
manage
them.
J
Okay,
so
how
do
we
do
the
traffic
management
in
terms
of
okay?
How
does
it
work
from
from
the
traffic
perspective,
and
so
I
was
trying
to
show
here
the
starting
point?
There
is
not
that
much
documentation
about
this
in
the
zero
zero
version
of
the
draft,
but
if
you
think
about
it
right
in
beer,
how
do
you
create
a
bit
string?
You
create
a
bit
string
by
knowing
on
the
sender
what
are
the
receivers
I'm
interested
in
each
receiver.
J
I
have
a
bit
for
and
I'm
just
oaring
the
different
bit
in
the
bit
string
and
then
I
send
off
the
packet
into
beer
right.
So
basically,
it's
getting
replicated
to
all
the
receivers
one
bit
per
receiver.
That
I
need
to
remember
now
in
beer
to
e.
If
I
do
pre
calculate
paths
that
I
want
to
use.
Ultimately,
what
you're
ending
up
is
you
have
from
a
particular
source
to
a
particular
receiver?
Just
you
know
a
bit
string
with
the
individual
hops
that
you
need
to
go
through
and
you
can
equally
or
them
right.
J
So
if
you
say,
oh
I
have
pre
calculated
on
my
PC
controller.
You
know
for
one
particular
set
of
applications,
the
set
of
paths-
then
it's
basically
one
path
from
every
particular
source
to
receiver
and
the
source
can
basically
or
these
paths
together
to
basically
multicast
the
data.
So
from
that
perspective
there
is
a
really
nice
easy
way
to
basically
create
pre,
calculated
path.
J
Where
then,
the
sender
can
individually
still
you
know
if
one
receiver
joints
and
leaves
the
multicast
group,
he
doesn't
have
to
necessarily
go
back
to
the
PC
controller
subject
to
bandwidth
management,
of
course,
they're
really
fun.
You
know
minimum
overall
cost
they're
called
Steiner
trees,
which
means
you
remove
one
receiver.
You
need
to
recalculate
the
whole
path,
obviously
somewhat
different,
but
if
you
try
to
do
the
same
thing
with
rsvp-te
point-to-multipoint
well,
you
have
to
do
a
lot
of
reasoning,
and
here
you
know
in
gear
two.
J
J
So
this
is
basically
the
the
overall
architecture
that
we're
proposing
with
all
the
underlay.
Here
is
basically
the
beer
stuff
and
basically
the
signaling
to
a
PC
controller
provisioning
system.
Let
me
quickly
try
to
go
through
that.
So
what
we've
been
trying
to
figure
out
in
the
0-0
draft
is
how
to
provide
a
framework
where
we
can
use
the
PC
controller
for
everything
or
just
for
the
provisioning,
then
using
the
IGP
to
disseminate
the
information
for
diagnostics
for
basically
automatically
overcoming
inconsistencies
and
then
also
to
enabling
the
sources
to
actually
calculate
paths
if
that's
desired.
J
So
just
the
framework
or
these
different
things,
and
so
one
of
the
next
steps
is
then
figuring
out.
You
know
what
type
of
data
models
do
we
need
to
build
out
in
yang,
so
what
the
rest
of
the
slides
here
is
and
I
think
we're
running
out
of
time.
So
maybe
taking
up
next
time-
or
maybe
you
know
in
the
PC
working
group
world
presenting
so
we
can
go
into
more
detail
there.
J
Let
me
skip
through
those
details,
but
here's
basically
kind
of
two
slides
about
the
data
model
that
we
think
is
going
to
be
the
target
for
whether
we're
going
from
a
PCE
controller
or
the
same
information
to
put
in
an
IDP
and
yeah.
So
we
basically
would
like
to
start.
You
know
going
forward
with
the
framework
figuring
out
what
pieces
are
missing
in
the
framework
and
then
basically
identify
what
the
next
product
call
steps
are
like
the
yang
model,
the
Eleazar
extensions
and
yeah
get
the
the
guidance
from
the
t's
working
group
on.
J
A
Quick
because
we
didn't
have
a
lot
of
time
and
appreciate
you
cutting
a
little
short
there's,
actually
a
lot
of
commonality
here,
with
what
we're
doing,
with
any
controller
based
path,
selection
and
control.
It's
just
that
the
way
the
control
is
instantiated
is
in
the
data
plane
rather
than
through
control,
plane
signaling.
So
there
actually
is
some
really
good
overlap
with
the
work
that's
going
on
here.
A
So
it's
definitely
worth
looking
at
this
document.
If
you,
if
you
haven't
and
I,
think
you'll,
be
surprised
to
see
the
the
common
eye
ideas,
how
many
people
have
looked
at
this
work,
but
that's
actually
a
reasonable
number
and
how
many
more,
if
you
didn't
raise
your
hand
before
interested
in
hearing
more
about
it
or
pursuing
it
in
this
working
group,
so
a
few
more
hands.
So
you
know
the
the
it
looks
like
there's
some
some
good
interest
here.
Maybe
it's
a
little
early
to
try
to
go
for
adoption,
but
you're
not
asking
for
that.
A
G
Hi,
this
is
true
again
and
I'll
be
talking
about
her
Ikey
or
IP
controllers.
So
basically,
this
is
not
something
new.
The
the
idea
here
is
basically
to
kind
of
capture
how
what
we
have
already
developed
in
the
T,
these
working
group
with
respect
to
a
CTN
and
the
various
de
Young
models,
how
they
actually
get
work
in
a
real
IP
controller,
where
you
have
key
components
and
the
non
key
components,
and
you
have
various
other
protocols
that
are
running.
G
You
are
using
PCA
on
EGP
there's,
so
many
different
things
that
we
have
been
working
across
in
various
different
working
groups
within
T's
and
outside
T's
working
group
as
well,
so
how
they
come
together.
How
is
it
in
a
CTN
framework
that
we
have
developed
yet
applies
in
the
IP
controller
case?
So
those
are
the
things
that
we
have
tried
to
capture
in
this
document
and
it's
an
informational
document.
It
covers.
G
Basically,
various
interactions
talked
about
other
protocol
considerations,
talks
about
the
services
that
we
offer
the
IP
services
and
how
are
they
realized
and
also
notes
if
there
is
some
missing
pieces?
That's
something
that
we
need
to
work
on,
which
is
not
currently
captured
in
the
existing
solutions.
There
are
so
nothing
new
here
you
have
like
you
know
the
domain
controllers.
You
have
somebody
like
a
super
controller.
G
A
super
controller
receives
the
request
from
the
customer
breaks
down
into
tasks
that
each
domain
controller
has
to
take
care
of,
and
it
does
the
coordination
function,
something
that
we
very
well
know
in
the
AC
T
and
in
this
working
group.
So
the
main
thing
that
we
wanted
to
capture
was
that
what
we
define
in
the
AC
TN
basically
is
are
some
functional
blocks,
and
these
are
the
functional
things
that
any
controller
needs
to
our
needs
to
implement.
G
So
within
the
controller
you
may
have
various
other
functions
and
the
actn
part
is
just
the
functional
block,
which
is
nothing
but
our
MDS
C
and
P
and
C,
and
those
are
the
functional
block
within
the
physical
controller
that
packages
multiple
other
functions.
So
you
have
your
empty
interface,
which
is
focusing
on
the
teapot
and
the
actn
part,
but
you
would
also
need
various
other
non
tea
interactions
to
actually
get
IP
service
established.
So
this
was
usually
because
there
is
when
we
talk
about
a
CTN.
G
There
has
been
some
confusion
with
respect
to
what
is
the
real
value?
How
does
it
actually
helps
in
setting
up
IP
services?
So
don't
those
words?
That's
why
we
thought
that
writing
this
information
model
and
capturing
those
things
also
would
help
to
realize
that
inside
the
hierarchy
of
IP
controllers,
how
it
is
being
used-
and
we
also
try
to
cover
the
interactions
between
the
nandi
parts.
So,
for
example,
is
there
any
interaction
with
BGP?
What
are
the
set
of
other
young
models?
G
How
do
we
do
ohmmm
after
the
service
is
established
all
those
things
we
want
to
capture?
This
is
just
a
0/0
version,
but
that's
the
vision
that
we
have
with
this
document
and
focus
that
when,
when
we
say
mdac
and
PNC,
we
really
don't
mean
the
full
controller,
but
only
the
functional
block,
which
is
doing
the
ECT
and
functionality,
and
then
you
would
need
lot
of
other
things.
G
This
is
not
new,
even
the
abner
and
the
other
work
that
has
captured
that
that
even
the
PCE
is
just
a
functional
block
within
your
controller,
which
does
the
path
imputation,
but
you
would
need
multiple
other
things
to
actually
establish
a
service
using
this
architecture,
so
in
the
next
slide,
I
am
focusing
on
some
of
the
key
concept.
This
did
not
change.
This
remains
exactly
what
actn
described
we
we
can
implement
it
it.
Why
are
various
different
mechanism?
The
PNC
we
very
well
know
can
take
part
in
ICP
and
learn
the
topology.
G
That
could
be
there,
which
is
why
topology
great
apology
like
topology
and
all
those
things
are
already
well
supported
with
the
protocols
that
we
have
so,
for
example,
in
VG
pls
case
or
P
sub
LS
case.
We
could
carry
abstract,
topology
and
Mark
that
this
topology,
how
it
is
being
abstracted
and,
of
course
the
Yankee
model-
captures
this
quite
well.
But
the
job
of
the
MDS
is
also
to
take
care
of
the
end-to-end
topology
that
it
might
be
exposing
to
the
customer.
G
So
we
have
just
tried
to
at
one
place,
try
to
list
all
the
different
possibilities
that
is
there
with
respect
to
the
top
topology
building.
So
you
have
your
tea.
The
yang
based
work
that
we
do
in
this
working
group,
but
then
there
is
some
other
pointers
to
other
things
that
are
happening
which
are
outside
the
working
group
as
well.
G
Similarly,
with
path
computation
and
instantiation,
completely
aligned
to
the
acct
and
framework,
what
we
have
already
captured
and
again
it
list
is:
what
are
the
possibilities
for
us
to
actually
do
this
work?
It
could
be
yang
based
there
as
well.
We
have
two
options:
we
have
the
tea
tunnel
compute
only
and
other
options,
as
well
as
to
instantiate
a
tunnel
why
the
tea
topology
model,
we
have
the
part
computation
yang
model
which
uses
the
are
pcs.
G
So
these
are
the
set
of
things
which
are
yang
base
and,
of
course,
via
p,
sub
based
work
that
we
have
been
doing
in
the
PCC
working
group,
which
is
how
stateful
HPC
could
be
used
to
do
part
setup
from
super
controller
or
the
ndse
to
be
NC.
So
nothing
new
here.
This
is
just
to
list.
What
are
the
possible
options
that
we
have
when
we
are
implementing
this?
G
Next,
we
are.
We
move
on
to
some
of
the
services
that
we
offer,
so
we
are
focusing
here
on
the
IP
services,
so
seamless,
MPLS,
l3,
VPN,
l2,
VPN,
etc.
So
what
are
the
various
interactions
that
needs
to
be
done
when
we
have
to
establish
a
service
so
in
case
of
a
seamless
MPLS?
What
are
the
jobs
that
the
controller
needs
to
do?
What
would
be
done?
Why
are
various
interfaces
so
that
we
have
tried
to
capture
that?
G
One
of
the
key
thing
that
the
super
controller
might
have
to
do
is
selection
of
what
are
the
boundary
nodes
or
the
ABR
s
that
I
need
to
a
use.
Of
course
you
need
to
do
the
service
model
to
the
network
model,
to
device
model
translation
which
has
been
discussed
in
the
ops
area
as
well,
and
apart
from
the
configuration
part,
there
is,
of
course,
the
tunnel
selection
and
the
AC
TM
thought
that
comes
in
that
what
are
the
parts
that
needs
to
be
set
up?
G
How
do
we
set
up
the
domain
parts
and
stitch
them
together
to
form
end
to
end
an
SP,
so
that
part
we
have
tried
to
capture
another
key
thing
would
also
be.
Is
there
any
role
of
running
controlling
protocols
like
BGP
between
the
domain
controller
and
the
super
controller,
in
form
of
RR
functionality
that
the
BGP
provides
and
what
else
how
we
could
use
that
information
at
the
super
controller
to
make
some
intelligent
decisions,
etc?
G
Similarly,
in
l3
VPN,
this
is
actually
covered
in
the
service
model
part
as
well.
Maybe
we
are
talking
about
how
the
mapping
between
the
service
model
and
the
and
the
a
CDN
and
the
T
would
be
done.
So
this
kind
of
captures
that,
and
though
sometimes
we
may
receive
the
service
in
form
of
a
service
model,
we
need
to
decide
based
on
the
QoS
and
policy
requirements.
What
kind
of
tunnels
that
needs
to
be
actually
established?
What
are
the
set
of
boundary
nodes
that
I
have
to
use,
and
what
is
the
map
type,
for
example?
G
This
is
something
that
was
discussed
in
the
service
model,
so
that
is
captured
here.
The
dear
mayor
might
be
a
requirement
to
bind
a
tunnel
or
to
reuse
a
tunnel
or
just
make
some
modifications,
so
those
things
are
captured
and
what
will
be
the
mechanism
used.
So
if
you
are
using
a
CDN
interfaces,
we
have
a
choice
of
what's
the
job
of
the
the
MBI
interfaces
and
it
can
be
implemented
by
a
piece
F
or
it
could
be
implemented
by
the
yang
mechanism.
G
That
we
we
are
highlighting
is
that
the
network
model
is
some
piece
that
is
kind
of
missing.
You
know
we
have
the
service
model,
we
have
the
device
model,
but
representing
this
at
the
network
domain
level
is
something
that
needs
to
be
worked
on
and
what's
applicable
to
l-3.
Sm
is
also
applicable
to
l,
to
SM
for
giving
L
to
B&R
evpn
services.
G
Then
we
move
on
to
the
protocols
and
the
models,
so
those
were
the
services.
What
what
are
the
choices
with
respect
to
various
protocols?
So
we
have
some
control
plane
protocols
that
could
be
used,
so
we
have
tried
to
capture
PC
and
BGP,
and
possibly
if
there
is
a
role
of
BMP
there,
that's
something
that
needs
to
be
investigated
further
and
with
respect
to
can
management
plane.
What
are
the
various
sets
of
yang
model
and
what
are
the
roles
that
those
young
models
are
playing?
G
So
PC
has
a
lot
long
history,
that
this
is
the
ladder
that
the
PC
working
group
has
worked
on,
and
we
are
very
well
aligned
to
the
requirements
that
we
have
with
respect
to
this
hierarchy
of
IP
controllers.
Now,
with
respect
to
yang
models,
the
service
models
are
well
established,
something
which
we
need
to
think
about.
A
little
is
the
network
configuration
model
where,
from
the
domain
point
of
view,
how
do
we
represents?
G
G
So
that's
something
that's
missing
and
I'm
sure
there
are
other
yang
models
that
are
being
developed
at
other
places
that
we
would
like
to
capture
so
that,
like
you
know,
we
can
point
out
to
how,
if
we
have
to
implement
this,
these
are
the
set
of
things
that
you
need
to
look
at.
Some
of
the
things
that
we
we
are
highlighting
is
as
a
possible
features
or
extensions
that
can
be
done
and,
of
course,
depends
upon
the
protocol
choice
and
how,
based
on
that
protocol,
how
do
you
implement
these
things?
G
The
image
initial
configuration
right
now
when
we
are
establishing
various
controllers
and
you
have
a
domain
controller
and
a
super
controller
or
a
PNC
and
mdac?
How
is
this
relationship
established?
How
do
we
learn
about
their
individual
capabilities
and
the
role
that
they
are
playing,
and
how
do
we
work
with
when
you
have
multiple
instances
of
the
same
controller,
a
different
level
for
reliability?
How
is
your
protocol
taking
that
into
consideration?
So
those
are
the
things
that
some
thickness
that
we
need
to
think
about
and
highlight.
G
While
we
are
also
working
on
this
topic,
so
aim
for
this
presentation
was
basically
to
get
some
feedback
on
whether
this
kind
of
work
is
useful
and
what
what
else
are
we
not
thinking
about
what
can
be
added?
What's
not
in
scope
and
that
should
be
removed?
We
still,
of
course,
agree
that
this
is
just
the
starting
point.
There
is
a
lot
of
things
which
are
missing,
so
some
of
the
things
that
we
know
that
we
have
not
added
is
about
yang
models,
more
details
about
BGP,
om,
etc.