►
From YouTube: IETF104-RTGWG-20190326-0900
Description
RTGWG meeting session at IETF104
2019/03/26 0900
https://datatracker.ietf.org/meeting/104/proceedings/
A
B
B
I
wanted
to
point
out
that
for
the
routing
area
working
group
we
have
the
general
IETF
IPR
disclosure
policy
and
the
way
that
we
handle
that
specifically
in
the
routing
area.
Working
group
is
requiring
the
authors
and
contributors
to
state
whether
or
not
they're,
aware
of
any
relevant
IPR
for
a
document
in
question
at
the
two
main
gates
for
the
document
process.
That
is
at
working
group
adoption
and
also
when
doing
working
group
last
call,
and
sometimes
we'll
do
this
concurrently,
sometimes
before,
depending
on
the
specific
document.
B
B
B
B
We
have
one
document.
That's
passed
working
group
last
call
quite
a
long
time
ago
the
BGP
pick
draft
and
we're
really
expecting
a
shepherd
right
up
very
soon.
On
that
we've
nudged,
the
the
shepherd
recently
adopted
working
group
drafts
the
segment
routing
gif,
a
draft
was
adopted
and
the
net
to
cloud
problem
statement
and
gap
analysis
drafts
were
adopted
as
well
as
the
rib
yang
model
they
were
adopted.
B
B
The
source
test,
routing
draft
it
was
adopted
quite
a
while
ago,
it
sort
of
recently
been
unexpired,
and
we
also
have
the
VRP
PFD
point-to-point
draft
and
the
routing
timer
parameter
synchronization
draft,
which
were
adopted
quite
a
while
ago,
but
we
they've
expired,
so
we
probably
need
to
to
figure
out.
You
know
how
we're
proceeding
with
those
either
the
authors
bring
them
back
into
into
circulation
or
we'll
we'll
figure
out.
You
know
if
there's
still
still
interest
in
pursuing
them.
B
So,
in
addition,
several
drafts
that
have
been
discussed
over
the
last
several
IDF's
in
the
routing
area
working
group
related
to
control
and
usually
playing
separation
for
B
and
G.
There's
a
baath
occurring
basically
in
the
next
session
this
morning
after
the
break
related
to
those
drafts.
So
we're
not
going
to
discuss
them
here
because
there'll
be
a
dedicated
to
them.
C
So
in
terms
of
aviation
and
communication
standards
bodies,
the
International
Civil
Aviation
Organization
is
developing
an
aeronautical
telecommunications
network
with
Internet
Protocol
services
for
worldwide
air
traffic
management.
We
have
other
standards
bodies
that
are
involved
in
this
to
RTC.
A
special
committee.
2:23
is
identifying
an
IPS
architecture
for
remotely
piloted
Aram's,
which
are
also
known
as
unmanned
air
systems.
Rtc
ASC
228
is
identifying
communications
data
links
for
our
past
coordination.
C
C
So
in
terms
of
what
the
ATN
IPS
looks
like
again,
it's
currently
under
investigation,
ICAO
working
group
I,
it's
based
on
Internet
Protocol
version
6.
It's
an
overlay
network
over
an
underlying
Internet
work
that
could
be
either
secured
tunnels
over
the
public,
Internet
or
a
private
infrastructure,
and
we
want
to
have
a
single
air
traffic
management
service
for
all
Aviation.
C
So
in
terms
of
scaling
considerations
for
aviation,
each
aircraft
is
a
mobile
network
and
it
receives
an
ipv6
mobile
network
prefix,
for
example,
a
slash
56,
and
that
prefix
goes
with
the
airplane.
Wherever
the
airplane
travels
worldwide.
Today
we
have
on
the
order
of
10,000,
possibly
going
to
a
hundred
thousand
airplanes
in
operation.
Today,
however,
with
unmanned
air
systems,
personal
air
vehicles
gross
is
a
bit
in
their
future.
We're
going
to
need
to
consider
soon
large
orders
of
magnitude,
and
then
mobility
plays
a
role
in
control
message.
C
So
one
alternative
that
is
being
looked
at
is
what
we
can
call
centralized
mobility
management,
and
now
it
would
be
a
case
where
we
have
one
mobility
anchor
point
for
the
entire
worldwide
aviation.
So
you
see
all
these
airplanes
here
grouped
around
a
single
Anchor,
Point
I.
The
advantages
of
centralized
mobility
management
are
that
we
have
an
immediate
mobility,
signaling
and
cube
quality
of
service
signaling.
C
Since
all
aircraft
are
serviced
by
the
same
mobility,
Anchor
Point
disadvantages
are
that
you
have
scale
and
limitations
not
only
in
the
numbers
of
aircraft,
but
also
in
the
amount
of
mobility,
signaling
and
also
localized
mobility.
Events
cause
global
instability,
so
we
believe
that
this
is
not
going
to
scale,
and
so
now
we
have
this
option
that
we
call
distributed
mobility
management,
and
this
is
where
we
get
to
the
ATM
BGP
document.
C
With
the
ATN
BGP
document,
we
have
a
hub
and
spokes
architecture
with
a
BGP
routing
core
in
the
middle
as
an
overlay
network
over
the
underlying
network
and
stop
autonomous
systems
in
this
in
the
spokes.
Where
you
see
those
mobility
anchor
points
with
aircraft
grouped
around
them,
so
this
is
the
way
we
can
distribute
the
mobility
and
the
the
quality
of
service.
Signaling
is
by
having
smaller
mobility
anchor
points.
This
servers,
smaller
numbers
of
aircraft
and
the
global
arounded
system
tracks,
which
aircraft
er
are
associated
with
which
mobility
anchor
point
advantage
of
the
distributed.
C
Mobility
management
approach
is
that
it
distributes
the
load
among
many
mobility
anchor
points
and
it's
scalable
in
terms
of
the
number
of
aircraft.
We
can
handle
out
of
a
BGP
routing
core.
Now
the
internet
is
proof
of
concept
that
we
can
handle
upwards
of
close
to
a
million
routes
in
the
BGP
routing
tables.
C
With
the
distributed
mobility
management
approach,
we
also
have
scalable
mobility,
signaling
and
localized
mobility.
Events
are
kept
local
without
causing
global
instability.
The
advantage
of
this
advantages
of
the
this
approach,
though,
is
that
it
requires
an
effective
route
optimisation
service
to
reduce
congestion
in
the
core.
Otherwise
we
would
have
all
traffic
going
through
that
core
and
we
would
have
you
know
concentration
of
congestion
in
the
core
routers,
but
the
good
news
is
that
we
know
how
to
do
the
route
optimization.
C
So,
in
terms
of
the
draft
in
the
routing
working
group,
we
have
a
BGP
overlay
routing
system
for
distributed
mobility
management
again,
a
hub
and
spokes
autonomous
system
border
router
arrangement.
We
have
core
autonomous
system
border
routers
in
the
hub
and
stub
autonomous
system
board
routers
in
the
spokes.
C
Now
BGP
is
that
the
design
is
for
carrying
short-term
forward
of
initial
data
packets.
Only
and
then
route
optimisation
kicks
in
to
keep
the
data
traffic
out
of
the
core.
This
is
a
very
important
point.
We've
had
some
experimental
evidence
over
the
course
of
the
last
several
weeks,
showing
that
when
you
withdraw
a
BGP
route
from
the
routing
system,
it
can
take
several
hundred
milliseconds
for
that
route
to
disappear
and
for
the
new
routing
information
to
come
through,
so
that
we
found
that
after
we've
done
route
optimisation.
C
If
we
remember
where
the
aircraft
was
before
the
BGP
update
happened,
then
we
can
continue
to
forward
at
the
link
layer
without
going
through
the
BGP
routing,
and
in
that
way
we
avoid
periods
where
we
wouldn't
have.
It
might
have
several
hundred
milliseconds
of
packet
loss
and
that's
very
important
for
aviation
applications
where
we
can't
have
dropouts
and
in
voice-over-ip
we
can't
have
loss
of
position,
information
and
things
like
that.
So
so,
even
though
we
have
a
BGP
convergence
time,
we
take
care
of
that
at
the
link
layer
without
impacting
the
routing
system.
C
The
mobility
management
services
in
the
stub
autonomous
system,
border
routers
ICAO,
is
looking
at
three
alternatives
for
the
mobility
management,
proxy
mobile,
ipv6,
Lisp
and
Aero
are
the
three
candidates
that
are
being
looked
at
right
now
now,
in
terms
of
the
document
status
of
the
routing
working
group
document,
we
did
update
to
a
version
zero
and
one
recently
we
incorporated
clarifications,
do
to
list
comments
and
questions.
Also,
we
had
a
routing
area,
pre
review
that
we
responded
to.
C
So
now
we
have
this
concept
that
we
call
massively
distributed
mobility
management-
and
this
is
a
case
where
we
have
not
just
one
BGP
core,
with
its
router
information
base,
but
many
bgp
cores
that
each
have
a
separate
routing
information
base.
So
we
want
to
size
the
system
to
support
a
mobility
service
prefix
on
the
order
of
the
slash
32.
Now
each
one
of
these
bgp
routing
cores
maintains
an
independent
rib
with
up
to
1
million
rounds
per
mobile
of
mobile
network
prefix
routes
per
rib.
C
Each
rib
would
service
a
different
sliver
of
the
mobility
service
prefix
and
we're
calling
that
the
mobility
group
prefix.
So,
for
example,
if
each
rib
serviced
a
slash
44
in
ipv6,
slash
44,
then
if
we
had
a
thousand
ribs
that
would
get
us
to
a
billion
BGP
routes
and
again,
the
way
we
we
get
to
that
level
of
scale
is
by
having
multiple
ribs
that
are
independent
of
one
another.
C
But
even
though
we
have
these
multiple
ribs
the
aircraft,
when
they
move
from
mobility,
anchor
points,
a
mobility
anchor
point,
I
can
get
the
service
that
is
being
provided
by
their
sliver,
no
matter
which
mobility
anchor
point
they
move
to.
So
this
is
how
we
get
our
scalable
D
aggregation
for
massively
distributed.
Mobility
management.
C
And
I
think
that's
that's
all
I
had
so
in
terms
of
draft
status.
We
have
the
simple
BGP
based
mobility
routing
system
through
the
or
nautical
telecommunications
network.
That's
a
working
group
document
of
this
working
group
and
we
have
the
new
document
on
scaleable
D
aggregation
for
overlays
using
the
border
gateway
protocol,
so
that
that's
a
document
that
we
have
aligned
with
this
working
group.
But
we
haven't
asked
for
adoption
on
that
one.
Yet
that's
what
I
have
Jeff.
B
So
I
had
a
question
you
referred
to
some
like
experimental
data
and
I
think
at
least
this
second
draft
free
first,
you
know
kind
of
talks
about
that
a
little
bit.
But
could
you
just
elaborate
a
little
more
on
what
you
know
what
you're
you're
doing
to
sort
of
test
the
scalability
of
the
whole
solution
and.
C
Yeah,
so
we're
actually
working
with
the
group
in
Austria
from
a
company
called
free,
cuentas
and
frequentist
was
chartered
to
evaluate
these
mobility
solutions
for
the
ICAO
work.
They
ran
an
experiment
where
they
were
sending
a
hundred
packets
per
second
through
the
BGP
routing
system
and
then
with
through
a
route
from
the
routing
table,
and
they
noticed
that
over
that
one
second
period
they
were
losing
twenty
to
thirty
packets
out
of
that
100
packets
per
second
strength.
A
D
So
good
morning,
everyone,
this
is
Hugh
from
Huawei
I'm
here
to
discuss.
How
do
we
use
leverage?
The
ITA
I
found
a
model
to
automate
the
management
to
deliver
service,
and
so
this
is
the
job
that
we
actually
pack
for
a
long
time
actually
burn
out,
because
recently
we
see
a
lot
of
ITF
to
find
a
motorcade.
Perhaps
you
didn't
mature
enough
actually,
so,
when
a
motivation
actually
is,
we
want
to,
you
know,
raise
to
some
idea
of
young
tekmoto
standardization
issue
to
inspire
some
discussion
on
this,
so
we
we
also
see.
D
Actually,
you
know
for
so
many
young
Taylor
model,
actually
how
they
can
put
together
to
deliver
service
configure
devices
and
many
different
people
have
given
a
solution.
So
we
really
want
to
get
people.
You
know
to
understand
how
how
do
we
use
this
model
secondary?
Actually,
you
know
is
one
when
I
pick
a
challenger
for
operator,
because
we
talk
with
a
lot
of
operator.
The
people
challenge
is
the
facing
actually
how
to
use
this
moto.
How
do
you
select
the
idea
of
different
models
that
can
fit
it
to
their
use
cases?
D
So
this
is
something
we
need
to
face
actually
for
the
ITF,
and
so
the
Charter
proposal
here
and
the
Walker
proposed
here
actually
to
provide
a
framework
of
the
peril.
The
developer
implementer
operator
how
to
implement
the
ITF
defender
model,
also
discussed
top-down
subsidiaries
through
the
coordinator.
Young
data
model,
these
or
in
a
young
model
will
cover
high-level
model
and
lower-level
how
they
can
coordinate.
It
is
not
clear
to
everybody
if
we
get
time
actually,
where
you
can.
You
know
kyo
to
use
cases
to
discuss
this
so
before
we
get
to
discuss.
D
Actually,
we
I
wanted
in
to
you
know
concept
of
what
is
data
modelling
layering
secondary
data,
modern
representation
data
model
layering
actually
allow
you
to
abstract,
and
that
was
infrastructure
from
bottom,
also
allow
you
to
abstract
the
PCA
needs
several
requirements
that
from
the
top,
so
the
service,
so
the
young
data
model
in
ITF
can
be
split
into
two
layer.
We
have
service
model
can
carry
water
services.
What
is
the
customer
service
needs
and
for
device
model?
D
We
can
tell
you
how,
to
you
know,
get
a
network
set
up
to
program
in
and
walker
and
deliver
that
service
realize
these
service
lisa
has
already
be
specified
in
obviously
81
1990,
but
we
see.
Actually,
what
is
missing
is
mindo
in
the
middle
is
a
nano
resource
model.
Actually,
this
metal
resource
model
is
a
very
crucial
for
you
to
liver
the
service.
The
for
number.
You
need
to
schedule
the
results
so
to
meet
the
customer
needs
or
you
also
you
can
reschedule
resource
to
adapt
to
the
network
change.
So
it's
very
crucial.
D
So
we
introduced
these.
You
know
another
layer
also
for
theta
model
representation.
We
make
a
elegy
to
the
house
building
process.
For
example,
you
possibly
you
need
to
plan
the
house
building
and
then
you
can
put
into
the
production
for
the
house
building
process
you
your
custom,
actually
can
all
of
the
house
describe
their
requirements.
D
For
example,
you
wanna
order
a
house
with
three
room
and
living
room
bedroom,
and
these
can
be
actually
represented
by
the
blue
printer,
so
the
approve
blueprint
can
be
compared
to
the
service
model,
so
the
service
model
can
be
used
by
the
customer
to
communicate
with
operator
committee
who
is
managing
system.
So,
in
addition,
actually,
when
you
get
approved
by
the
customer
and
also
Regulation
Authority,
this
can
put
you
into
the
pro
Tanjung
and
actually
you
can.
You
can
actually
select
the
site.
D
You
can
put
a
foundation
for
the
house
building
and
you
also
can
actually
step
choose
a
change
for
the
water
supply,
erection,
supply
and
sewerage.
Actually,
there
is
a
water
supply.
Electricity
can
be
compared
to
this
a
nano
resource
model
and
also
for
the
foundation
with
how
the
house
building
and
the
building
block
in
the
house
can
be
compared
to
the
device
model.
So
did
question.
D
D
D
E
D
I
think
the
the
similarity
for
MAF
walk
an
idea
because
they
both
activities
described
the
connected
service
actually
for
air.
So
it's
an
USM
model
actually
to
actually
describe
the
service
from
the
customer
perspective
with
number
how
many
of
it
be
inside.
You
want
to
describe
it,
but
you
want
to
just
establish
it
and
what
a
location
of
this
which
inside
how
to
establish
the
connectivity.
What
is
the
KPI
or
SLA
for
the
for
each
connectivity?
So
it's
very
close
to
the
Uni
you
mentioned.
D
E
Carol
Ethernet
model
that
defined
by
math
being
used
to
order
services
I,
don't
know
where
L
2sm
being
used
to
offer
order
services,
networks
on
layer,
3
uni,
its
MF
61
document
already
been
published
and
continuous
working
on
operation
in
and
I.
Also
it
works
on
service,
L,
AM
service
activation
testing,
so
I
would
really
suggest
to
be
very
careful,
not
the
duplication
of
the
work,
but
it's
do.
D
We
have
already
being
aware
of
this,
so
thank
you
for
your
information.
Actually,
we
already
try
to
a
language
them.
You
have
I
think
a
way.
Actually,
it's
a
suggested
to
ecosystem,
which
we
need
to
need
a
more
coordination,
bring
accepted
really.
So
that's
why
I
bring
up
the
topic
about
then
not
the
focal
to
this
topic.
Actually,
we
can
take
this
off
nine
and
four.
How
do
you
know
each
other,
sto
yeah,
okay,
so
for
next?
Actually,
I
want
to
give
updated
for
the
idea
network
of
young
work
actually
I.
D
Think
recently
we
already
published
in
more
than
50
FC
and
also
in
addition,
we
have
more
than
eighty
more
than
eighty
working
with
jobs.
Actually,
you
know
get
a
progress
that
procedure
unite,
have
another
made
more
than
eighty
innovative
jobs,
and
we
have
enough
young
to
the
model.
Many
yamaoka
the
popular
recently,
especially
before
this
idea
meetings
so
and
we
all
I
think
this
is-
should
a
sense
for
the
design
team
formed
by
the
idea
for
like
many
design
team
formed
by
the
vendor
and
operator
and
distribution.
D
Given
a
vertical
working
group,
and
also
we
have
young
doctor
design
team,
a
young
correlation
design,
team
and
I
singly
fulfill
their
mission,
but
I
think
so
we
have
summer
work.
I
mean
we
need
to
actually
to
put
some
results
titute
to
see
how
to
get
get.
Some
more
work
actually
can
really
be
used
for
some
real
use
cases
so
also
I
want
to
mention.
Idm,
have
good
correlation
with
different
organization.
Also
have
a
you
know
can
get
a
lot
of
input
from
the
open
source
community
and
like
open,
configure,
actually
many
open
company
innovating.
D
Actually,
you
know
has
already
the
import
to
the
ITF
and
drive
a
lot
of
innovation
in
the
idea.
So
this
is
a
very
heavy,
so
we
hope
actually
for
open
source
and
idea
can
commercialize
is
very
challenging,
but
it
really
is
our
hope,
but
you,
you
know
see
you
know
different
organizations,
even
a
open
source
can
align
with
each
other
yeah.
So
this
is
the
overview,
the
idea
for
yamamoto
standing.
We
have
a
high
level
model
service
layer
model.
We
have
actually
a
common
building
block
in
the
middle.
We
call
the
natural
resource
model.
D
We
also
actually
define
some
mechanism
like
secure,
mount,
actually
collaborative
compositive
in
a
model
together
to
actually
to
to
configure
the
device
to
to
program
the
networker.
So
this
is
a
very
crucial
to
automate
the
network
management
on
and
I.
Actually,
we
have
a
large
amount
of
young
lady
model
actually
cover,
given
a
technology
spec.
Actually
you
know
this
model.
Actually
you
know
many
of
them
have
written
together,
popular
and
but
we
also
see
some
of
issue.
One
issue
we
want
to
raise
here
to
inspire
some
discussion.
Is
you
know
for
all
of
these?
D
You
know
we
call
the
device
model.
Southbound
interfaces
model.
Actually
is
this
distributed
in
Tiffin
upper
the
working
go?
Actually
it's
hard
to
for
user
or
for
the
operator
to
select
this
model
for
to
fit
in
their
use
case.
It's
hard
to
keep
chatter,
with
a
maturity
for
this
model,
for
all
these
more
because
the
reactive
she
will
give
in
a
protocol
working
group.
Actually
maturity
may
be,
may
be
different.
You
know
we
also
have
very
slow
idea
process
and
maybe
many
you
know
problem
in
idea.
The
lack
of
there's
resources
put
into
it.
D
So
they
were
all
delays
and
some
of
the
young
in
modest
ambition.
So
this
is
really
serious
you
we
should,
you
know,
pay
more
attention,
yeah
actually
for
actually
for
the
trend.
Actually,
we
really,
you
know
involved
from
Chinese.
You
know
service
delivery
to
the
motor
driven
service
delivery
and
the
big
difference
is
actually
you
know
for
channel
service
delivery.
Oncbs.
Actually
you
know
they
didn't
really.
D
They
actually
conquered
the
surface
efficient
from
how
the
service
is
realized,
so
that
calls
actually.
You
may
build
a
lot
of
OS
LPS
application
and
butyl
otto
sidle
over
years.
Actually,
the
lacquer
stand
are
in
the
face
and
and
I
may
move
a
lot
of
data
entry
and
a
manual
provision,
and
so
these
actually
cannot
automate
a
service
activation
or
provisioning
and
another.
So
that's
so
so
to
address
is
actually
what
we
can
do
is
in
the
motor
driven
sensitive
area.
We
can
take
copper
the
service
definition
from
how
the
service
is
realized.
D
So
for
the
management
system,
we
can
split
into
two
subsystem
why
we
call
the
service
activation
provision
system.
The
second
is
service,
the
enforcement
system,
so
the
service
activation
and
a
provision
system
just
take
a
standard
model
from
the
standard
interface,
and
these
will
literally,
you
know-
you
know,
reduce
the
service
period
time
and.
D
Go
back
to
the
the
Trantino
service
delivery
for
managing
system
management
systems.
They
need
to.
You
know,
tackle
the
money
vendor
environment.
You
know
they
need
to
manage
your
different
vendor
device.
So
it's
very
Chinese
because
you
need
to
do,
is
the
different
vendor
say
or
is
creeper,
and
so
how
do
you
automate
this
metal,
magic,
väri
Channing
you
based
on
our
talk
with
operator?
Actually
many
orbiter
actually
chance,
the
integrative
and
vendors
Eri
scrip
and
try
to
identify
the
vendor
device
and
and
call
the
different
vendors
Eri.
So
this
is
something
we
should
address.
D
D
So,
how
do
you
automate
that
the
management
actually
I
sing
away
Ottoman
imagine
can
from
two
different
layer?
One
is
the
service
layer.
The
second
is
a
network
layer
for
source
of
service
layer,
as
so
as
I
discussed
in
a
previous
slide.
Actually,
we
can
actually
define
top-down
service
delivery
model.
I'm
going
to
describe
the
service
requirements.
Kpi
a
necessary
and
and
associative,
is
a
connectivity
service.
And
are
you
ready?
You
really
want
to
automate
a
sub
statement.
You
also,
what
is
missing?
D
Actually
you
need
to
have
when
you
get
a
network
setup
or
you
also
need
to
you,
know,
expose
a
network
performance
or
expose
of
formal
VPN
performs
a
to
the
chasm
or
to
the
or
P
that
they
can
use
these
powers
that
resolve
the
to
reoptimize
a
networker.
So
you
can,
you
know,
form
the
closed-loop,
imagine
and
full
lifecycle
management,
and
you
know
the
here
as
a
net
were
later.
You
also
become
motive
automated
network
management
in
IPA.
D
We
already,
you
know,
developer
a
young
push
a
notification
as
a
telemetry
maximum,
even
average
disease,
and
to
connect
the
data,
and
actually
you
you
review
all
too
many
days,
network
management.
What
is
missing
is
you
know,
policy
metal
policy
model.
This
can
be
part
of
this
magical
system.
They
actually
can
you
know
to
hook
the
the
telemetry
data
with
provision
theater
and
to
really
ultimately
the
network
management
and
a
single
we
already
developed.
A
lot
of
building
block
in
night.
Here
is
vegetated
South
Boniface
device
model.
D
We
can
leverage
it
is,
but
what
is
the
missing
is
actually
policy
ready,
so
I
see
some
of
the
policy
promoter
has
already
progressed
and
I
got
a
say,
oh
and
routine
policy,
but
what
about
the
other
policy?
Cuckoos
always
say?
Maybe
generic
and
then
okolloh
say
this
is
still
very
important-
building
block
that
can
help
to
automate
the
narrow
management
so
yeah.
A
E
Egt,
so
speaking
of
oil
psycho,
orchestration
I
think
we
at
ATF
is
a
far
back
far
behind
comparing
to
efforts
being
done,
for
example,
at
MAF
in
oil
circle
orchestration
for
now,
Carol
either
met
and
now,
for
there
are
three
services.
I
would
probably
I
would
encourage
you
to
really
look
at
what
AF
is
now
at
the
level
and
what
are
the
components
because,
for
example,
it
seems
to
me
that
you're
dismissing,
for
example,
service
activation
testing
model
service
om
model.
E
F
B
E
D
G
You
versus
robots
and
Cisco.
It's
actually
a
question
for
Greg
in
terms
what's
happening.
Mf
is
obviously
they
defined
the
LSO
model
at
the
top
layer
of
service
layer.
They
writing
any
draft
walls
to
say
how
you
map
those
services
down
on
to,
for
example,
IETF
yeah
models
to
stand
state
those
services
on
the
devices
was
that
left
open.
It
is
there
somebody
doing
that
piece
of
work
between
the
two
is
one
of
the
top
there's
models
at
the
bottom
who's
who's.
To
say
how
you
bridge
between
those
two
things.
E
Again
so
work
on
layer,
3
is
only
being
developing,
they
do
have
already
our
psyche
for
Carroll
Ethernet,
so
it's
layer,
two
and
layer
they
have
demos
and
they
have
real
working
system
to
do
and
and
service
ordering
and
provisioning
and
monitoring
and
decommissioning.
So
again,
it's
not
layer,
3,
ok,
so
I.
E
D
Yeah
I
understand,
actually
that's
just
a
cursor.
You
know
I
think
we
do
need
some
reference
architecture.
We
may
actually
leverage
this
area
so
by
the
ITF.
Oh
I
think
we
do
need.
Actually
maybe
you
know
have
such
a
reference
architecture
to
have.
You
know,
developer
operator,
to
see
how
to
position
different
model
independent
interface
and
help
either
implement
this
a
young
model
and
also
I.
Think
it's
a
very
important
to
help
her.
You
know
to
to
understand
how
to
map
amia
for
service
definition
or
service
model
to
ITF
de
panamá
is
a
very
crucial.
D
I
Yeah
Charles
a
Cole,
Cisco
and
I'm
active
in
in
math
I
chair,
the
co-chair,
the
application
committee,
where
we're
defining
and
s
service
and
what
that
is,
and
obviously
it
overlaps
and
perhaps
even
conflicts
in
some
places,
with
work
going
on
in
IETF,
Jen
and
I
have
already
talked.
This
is
something
we're
going
to
try
to
align
better
overall.
What
I've
seen
in
math
is
there.
There
are
service
level
models,
they
don't
the
way
math
define
service
is
different
than
the
way
IETF
defines
service.
I
Any
most
places
in
math
do
not
have
a
complete
stack
built
out,
yet
that's
all
using
math
specifications.
At
some
point
it
starts
with
a
math
service
model
and
it's
and
then
switches
somewhere
to
either
some
proprietary
implementation
or
some
models
that
are
being
defined
within
math,
and
we
see
this
as
a
problem
because
we'd
like
to
be
able
to
reuse
a
lot
of
the
underlying
IETF
device
models
and
perhaps
other
models
as
well.
J
Him
Leo
away
actually
I'm
also
at
the
participant
of
math
I.
Think
chintz
approach
here
is
data
model
driven
with
Rath
connect
on
consistent
from
layer,
seven
to
layer,
zero
and
math
approach,
sometimes
on
depending
on
the
interface,
they
don't
have
data
driven
approach,
they'd
rather
do
some
open,
API
or
some
other
spec
without
a
young
model.
So
I
don't
see
any
conflict
between
what
Qin
is
trying
to
do
here
and
what
mefist
doing
architectural
II
there's
some
similarities,
but
in
terms
of
approach,
how
to
implement
there's
some
difference
so
I
think
as
charge.
J
Talk
talk
about
sd1
same
thing,
layer.
One
service
model
developed
here
actually
I
brought
it
to
math
so
that
they
can
take
it
so
that
we
have
same
consistent
model,
but
they
have
a
little
bit
different
idea.
They
don't
want
to
sometimes
use
young
model.
They
were
neural.
Spec
driven,
UML
JSON
schema,
open
API,
it's
a
REST
API,
but
slightly
different
flavor
I
think
Marshall
will
decide
which
one
is
the
right
way
to
go,
but
I
think
definitely
would
unite.
J
G
G
Rob
Walton
Cisco,
so
just
to
find
some
other
general
comments
on
the
presentation
of
a
material
you're
presenting
here
I
have
a
lot
of
sympathy
with
what
you're
saying
in
terms
of
IETF,
producing
a
lot
of
models
by
independent
working
groups
and
there's
some
efforts
to
make
sure
those
models
are
consistently
each
other,
but
I,
don't
think,
there's
very
much.
Looking
at
the
bigger
picture
of
how
do
you
actually
then
implement
services?
G
How
does
a
an
ISP
take
this
large
set
of
models
and
then
implement
the
services,
and
sometimes
it's
obvious,
and
in
other
cases
it's
not
it's
actually
having
some
informational
draft.
That
gives
some
guidance.
That
says,
if
you
want
an
improvement,
this
surface
service,
these
are
the
molds
you'll
need
to
use
on
the
device.
This
is
the
set.
We
recommend
so
I
think
that
more
work
to
actually
look
at
the
bigger
picture
as
providing
services
for
both
on
the
device
ease
and
off
the
devices
is
a
useful
thing.
G
I
think
there's
useful
work
to
be
done
here.
I
think
the
work
of
trying
to
map
like
these
service
models
being
produced
by
other
stos
into
the
ITF
device.
Once
again,
I
think
that's
very
useful
work
that
otherwise
is
left
to
the
ISPs
to
actually
figure
out
how
you
connect
these
two
things
together,
I,
don't
know
if
I
understand
exactly
you're
asking
about
into
these
extra
layers
and
things
yeah
I,
don't
know
they're
required,
but
in
terms
of
providing
the
documentation,
how
you
can
take
those
top-level
service,
young
models
and
the
bottom
level
device.
G
D
Thank
you
yeah.
This
is
something
it's
a
one
of
a
clean
motivation
would
really
bring
operatives
toppika,
not
sure
these
jobs.
Actually,
you
know
ready
for
that
about
a
we
really
want
to
provide
a
reference
actually
to
have
you
know
to
define
the
the
model
is
that
can
actually
to
to
provide
it
support,
different
nurseries.
You
know
that's
exactly
what
a
way
positive.
We
also
talked
with
best
walking
or
actually
try
to
see.
D
If
we
need
to
you
know,
have
such
a
mapping
from
service
layer
model
to
the
device
level
model,
and
maybe
is
very
challenging
to
do
that,
but
we
do
try
to.
Actually
you
know
freedom
of
contacts
ready
to
you
know
so
to
say
the
feedback
from
the
operator
to
see
what
is
the
key
service
or
hard
propriety
serve,
is
a
really
deployed
and
what
kind
of
thing
really
used
and
but
I'm
not
sure
how
to
you
know.
D
You
know
you
know,
try
to
achieve
this
goal
and
so
that
so
there's
a
chapter
child
to
you
know
bring
bring
up
or
summer
issue
and
inspire
some
discussion
and
I
get
a
some
feedback
to
see
whether
we
need
to
you
know:
peanut
bring
about
some
new
work
and
I
think
if
people
have
interesting,
we
do
need
to
work
together
to
see
if
we
can
actually
help
to
address
this
channeling
usual.
The
face.
Wide-Eyed
have
defined
a
model
yeah.
K
G
Sets
of
modules
could
be
ITF.
Modules
have
group
them
together
into
say.
This
set
of
modules
is
what
you'd
use
for
a
basic
router
on
this,
provides
high
level
routing
or
provides
LT
VPN
service,
and
you
can
piece
these
things
together
in
a
hierarchical
way
to
build
up
larger
complex
systems.
I
still
go
to
manage
those
independently
said
that
is
potentially
one
solution
to
this
problem.
Another
way
it's
been
proposed
is
to
use
the
module
tags.
That's
I
think.
L
G
D
Yeah,
you
are
right
after
that
I
didn't
imagine
this
dream
on
and
Walker
and
another
option
I
want
to
mention
is
a
young
catalog,
actually
I
sing
good
idea
for
a
lot
hope
we
put
a
lot
of
resulting
hacks
on
to
actually
develop.
The
young
caliber
right
now
migrated
to
the
idea
for
repository-
and
these
are
very,
very
important-
actually
reference
for-
have
you
to
for
a
hyper
operator
developer
to
select
our
young
beta
model,
but
maybe
this
is
not
enough.
We
do
you
know
some
additional.
D
A
Just
ensure
up
strong
so
who
left
disagree
with,
grab
and
overlap.
If
you
look
at
any
of
the
comments,
I
see
me
of
61,
they
are
not
obstructed
enough
to
provide
service
definition,
they're,
not
detailed
enough
to
provision
the
service,
so
people
who
work
in
was
is
just
would
be
great
if
you
facilitate
the
process
of
building
some
that
could
be
used
in
more
Lehrman,
so
Greg
and
young
can
just
we've
been
working
with
me,
a
fun
enough
for
number
of
years
right
it
just
there's
very
little
progress,
yeah.
F
This
is
true,
phonetic
are
assume
to
me
that
notably
Yamato
has
been
deveined,
but
actually
most
of
them
has
not
been
widely
using
care
network.
So
I
think
that
this
draft
provide
systematic
framework
to
integrate
the
young
models
into
a
production
system
which
can
be
used
in
a
you
know,
network
of
carriers
and
focusing
on
making
the
sudden
load
into
the
network
models
and
provide
a
service
automation
with
very
crucial
important
for
okay,
so
I
think
this
work
is
very
useful.
I
give
support
to
this
work.
Thank
you.
Thank.
D
D
Actually
you
know
we
already
discussed
the
you
know:
service
management,
automation
and
then
women
for
the
mission.
We
also
see
you
know
you
need
to
hook
the
service
in
managing
automation
with
Neto.
Imagine
automation.
You
can
provide
the
the
end-to-end
the
whole
full
automation
system
here.
What
is
very
important
piece
actually
is
to
do
the
service
mapping.
D
So
we
have
two
cases
in
a
piece:
an
error
in
an
icky
scenario
in
a
piece
naira,
you
need
to
actually
map
for
number
the
layer,
3
VPN
service
parameter
into
the
conversion,
parameter
that
can
be
enabled
eg,
P,
ACR
OSPF
in
the
P
and
C
and
fourth,
he
service
mapping.
You
really
need
to
you
know,
map
the
service
type
fishing
within
that
the
that
he
service
into
that
he
tunnel
and
into
that.
He
topology,
and
this
also
very
crucial
to
help
to
automate
the
resource
management.
D
So
so
the
resource
management
is
very
crucial,
but
it
also
is
very
challenging.
You
know,
based
on
our
talk
with
our
Peter
and,
and
so
last
actually
is
our
you
know,
take
a
take
away
and
we
actually
have
to
use
case,
and
maybe
we
don't
have
time
to
introduce
so
I
just
jump
to
the
the
claim
which
we
really
want
to
convey
in
this
presentation
is
the
poster
with
sink
for
idea.
For
you
know,
young
the
process
is
slow.
We
already
know
this.
D
We
company
a
lot
about
a
sing
with
you
can
do
something
you
know,
for
we
can
focus
on
some
model.
You
know,
for
example,
the
BGP
and
weep
here
and
related
young
data
model
is
crucial
to
deliver
the
VPN
service.
So
we
we
shouldn't,
you
know,
you
know,
put
more
attention
to
this
and
kind
of
operator
to
you
both
to
see
what
is
the
musing
and
trying
to
drive
the
majority
of
these
kind
of
young
model.
Also,
we
sync
is
very
important
to
engage
the
operative
community.
You
know
right
now.
D
We
already
met
Ahmad
already,
you
know
kind
of
publish
it
and
make
sure
enough.
So
we
within
you
know
create
a
you
know:
young
standards,
actually
that
can
meet
the
relevant
metal
operator
requirements.
Actually,
what
do
we
can
do?
Actually
we
can
condense
the
rate,
as
I
mentioned,
also
a
young
catalog.
We
also
actually
already
discussed.
That
is
very
powerful
tour.
So
how
do
you
leverage
this
tool
to
measure
the
maturity
of
the
younger
model?
Also,
the
bigger
issue
is
ITF.
Llamado
is
not
use
case.
D
Driven
this
young
model,
you
know
distributing
different
work
in
cooking
global.
So
how
to
you
know
cake
chat
code
is
the
maturity
of
young
in
the
model
you
know
so
we're
really
when
the
need
to
shift
to
the
use
case,
driven
or
project
dreaming
and
until
help
to
you
know
make
a
some
of
the
young
more
the
more
useful
for,
for
some
specific
cases
to
really
address
the
you
know:
pimping
or
robbery,
family
phone
operator
or
from
the
customers.
D
So
last,
actually,
we
defined
in
the
reference
frame
worker
to
tell
you
how
to
you
know,
do
these
top-down
service
delivery,
so
accordingly,
young
in
the
model.
This
is
something
one.
One
big
motivation
to
write
this
work.
Also
last
we
like
to
advocate
for
developer
for
operator
is
time
to
deploy.
This
idea
from
model
to
you
know
identify
some
implementation
issue
get
as
the
operation.
You
experience
the
feedback.
You
idea
community
to
have
a
job,
the
majority
of
Ikea
model.
That's
all
so.
N
It
was
book
Donna's
the
wrong
type
of
a
tea
in
this
room.
So
thanks
for
raising
this,
there
are
quite
many
of
painful
points
that
you
are
mentioning
on
another
hand,
you
seem
to
be
kind
of
proposing
certain
solutions
and
that
solution
seems
to
be,
let's
add
another
lay
of
the
models
and
it
will
solve
the
problems.
That
probably
will
not
happen
at
all.
N
So
a
few
few
of
the
specific
topics-
ITF
flow
processes-
slow.
Yes,
that's
a
fact,
but
proper
cooking
takes
time
and
looking
at
the
deliverables
of
an
element,
level,
models
and
technology
level
models.
I
think
that
time
is
worth
waiting.
Then
another
aspect
about
the
secret
sauce
between
the
service
models
and
the
element
models.
That
is
just
a
reality.
N
If
the
vision
is
that
we
will
define
one
set
of
service
models
for
all
interconnection
products,
which
I
even
built
from
a
standard
technology,
components
that
that
is
not
realistic,
different
users,
different
operators
implement
their
own
connectivity
products
in
different
ways
for
different
reasons
and
valid
reasons,
and
the
secret
sauce
component
will
always
stay
that.
The
question
is
what
proportion
but
I
don't
believe.
It
is
practical
to
try
to
even
to
try
to
eliminate
this,
then
about
the
quality
of
the
models
and
ability
to
use
them
in
here
or
here.
I.
N
Think
that
is
a
big,
problematic
area.
Ietf
is
historically
very
good
at
working
on
techno
and
unfragmented
technology
components,
but
not
necessary
on
end-to-end
systems,
and
we
see
clear
results
of
that.
We
do
have
technology
models
which
which
work
for
that
particular
technology
domain,
but
they
implement
the
same
functionality,
not
necessary
and
a
workable
way,
and
if
you
try
to
stack
different
technology
components,
one
on
top
of
the
other,
you
you
end
up
with
problems.
N
N
O
Can
I,
sir,
come
so
stiffened
from
oranges,
so
you
say
that
it's
time
for
para,
it
was
to
deploy
which
in
fact
we
can't,
because
first
there
is
almost
no
implementation
and
there
is
no
implementation
because
of
else
too
few
models
that
could
be
deployed
today.
So
let's
say
that,
for
example,
I
have
only
IETF
interface,
which
is
available
in
my
advice.
I
can't
use
it
because
it
does
not
make
sense
if
I
cannot
also
configure
my
si
yes
of
the
GP
or
whatever
I
need
all
the
full
stuff.
O
So
this
come
back
to
the
point
which
is
yes,
I
do,
but
it's
not
only
a
matter
of
assess,
it's
also
a
matter
of
people,
because
we
I
think
or
know
that
we
are
slow
to
progress
documents
and
it's
not
a
matter
of
processes.
It's
just
a
matter
of
people
and
resources
that
we
are
allocating
to
focus
about
documents.
D
O
D
We
we
can,
you
know,
I,
think
that
there's
no
company
will.
Hopefully
we
can
convert
you
for
IT
departments,
a
Yamoto
and
do
the
the
OSI
on.
Actually
they
do
have
some
deployment
made
sure
butter
and
icing
IBM
model
if
they
can
catch
happen
and
that
they
actually
can.
You
know,
I
think
they
focus
on
different
use
cases.
You
know
they
so
I
hear
the
amount
of
a
more
promising
you
know
because
they
shouldn't
try
to
have
an
otherwise
I
would
say
young
yeah.
That's.
P
Hi
I'm
Donald
Eastlake,
with
Huawei
for
a
little
behind
schedule,
maybe
I
can
catch
up.
I
think
this
is
a
fairly
short,
simple
presentation
on
a
point-to-point
tunnel
policy
yang
data
model,
so
it
kind
of
has
policies,
because
there
are
these
variety
of
tunnel
types
you
might
have
to
provide
VPN
services
and
you
need
to
be
able
to
select
between
these
they're,
not
necessarily
all
available,
depending
on
what
you
have
implemented
and
what's
currently
functioning
hasn't
yet
failed
or
whatever.
P
So
this
draft
provides
a
yang
data
model
can
be
used
to
configure
and
manage
your
point-to-point
tunnel
policy,
and
it
kinda
assumes
there's
two
flavors
of
policy,
a
sort
of
a
selection
sequence
and
a
tunnel.
Binding
selection
sequence
assumes
that
you
have
the
series
of
different
tunnel
types
and
you
sort
of
select
from
those
based
on
the
priority
they've
effectively
been
given
for
a
particular
VPN
service.
P
P
You
can
specify
multiple
ones
of
those
to
the
same
IP
destination,
to
get
load,
balancing
effects
and
things
like
that,
and
you
can
kind
of
say
what
happens
if
they're
not
available,
you
might
want
to
restrict
it
to
only
the
the
ones
you
specifically
bound
or
if
those
tones
are
all
unavailable,
you
might
want
to
just
be
the
best
you
can
so
there's
a
tribute
which
you
can
associate,
which
indicates
which
of
those
sort
of
meta
policies.
You
would
like
to
have.
P
P
So
the
top
level
there,
these
panel
tall
tunnel
policy,
selectors
and
that's
an
ordered
list
of
these
you've
got
to
go
through
an
order
until
you
you'd
get
one
that
that
matches
so
the
each
one
of
these
policy
nodes.
Whatever
has
a
set
of
matching
conditions
based
on
various
conditions,
next-hop
Rd
or
whatever
is
obviously
more
details
in
the
graph
and
to
do
back
to
a
particular
policy.
P
Node
the
you
need
to
basically
match
all
of
these
selectors
and
if
they
do
then
there's
various
PI
policies
which
specify
the
the
tunnel
moats
suctioned
tunnel
mode
and
which
tunnels
he
specifically
would
want
to
use
and
there's
also
the
possibility
of,
including
in
there
the
the
mode
that,
if,
if
none
of
those
matched
and
you
deny
your
route,
so
it's
a
fairly
simple
model.
I
think.
P
So
we
think
the
craft
is
in
moderately
good
shape
in
terms
of
possibly
being
eligible
for
adoption
vote
we'd
like
to
ask
people
to
look
at
the
draft
and
send
comments
to
us.
We
did
happy
to
improve
it
and
working
on
update
it
and
at
some
point
we
think
it'd
be
appropriate
to
ask
for
working
group
adoption.
G
H
Q
My
name
is
tarik
sad
whenever
there
is
some
work
that
we're
doing
in
these
working
group
to
model
the
tunnels
on
the
device
of
the
device
as
well
as
steering
on
the
tunnels.
So
I'm
not
sure
if
the
scope
is
the
provision,
the
tunnel
in
your
model
or
for
service
steering
on
the
tunnels
a
little
bit
confused
and
is
it
only
packet
layer,
tunnels
that
you're
interested
in
or
basically
maybe
stealing
on,
SR
policies
also
is
in
scope.
P
L
F
L
P
R
Igor
Pushkin,
however,
basically
I
just
wanted
to
add
same
thing
with
Derek
and
poana
saying
we
have
quite
a
few
documents
which
describe
how
services
are
mapped
on
tunnels
and
explicitly
and
implicitly
for
say,
for
example,
through
tunnel
pools
and
how
you
actually
separate
the
couple
services
from
the
mapping
and
who
exactly
maps,
services
or
tunnels
and
stuff
like
that.
So
it
seems
like
overlap
here.
So
basically
it.
S
As
I
looked
at
your
draft,
you
know,
the
you
know
model
is
perfectly
fine
for
a
lot
of
applications.
I
think
the
thing
you're
gonna
run
into
is
something
some
of
the
other
models.
An
ITF
have
a
tendency
to
run
into.
Is
your
sort
of
namespace
squatting
on
a
really
nice
name
for
an
application
that
is
potentially
too
narrow,
so
I
can
offer
by
example,
the
access
control
model
that
got
worked
out
and
also
partially
here,
which
gets
used
in
very
specific
applications?
S
T
Tough,
my
suggestion
on
the
reading
of
the
document
was
that
it's
more
better
for
a
device
model.
As
in
when
you
configure
vrf,
you
want
to
configure
the
tunnel
policy
along
with
it
and
specify
that
this
is
my
preference,
or
this
is
the
particular
tunnel
that
I
wanted
to
be
binded.
So
when
I
read
it
to
me,
my
gut
feeling
is
device
and
the
other
work
that's
happening
in
T's
with
respect
to
service
mapping
at
a
higher
there.
T
U
We
Berger
the
other
T's
co-chair
if
your
focus
is
really
on
tunnels,
I
think
the
work
should
come
to
T's
and
you'll
find
that
all
of
it
is
there,
except
that
maybe
a
couple
of
pieces
of
information
you
might
want
to
add,
or
you
may
find
it's
all
there.
If
your
focus
is
more
on
the
VPN
information,
you
you
do
whatever
you
want,
maybe
best.
U
P
B
G
It's
not
very
much
just
recap
what
this
model
cover.
There
are
some
basic
art
functionality
in
the
ITF
IPM.
What
also
that
allows
you
to
configure
dynamic
artworks
then
static,
ARP
entries.
So
what
this
draft
is
covering
is
the
extra
bits
of
art
that
are
not
in
ITF
IP.
The
lots
of
vendors
have
support
for
as
I've
covered
examples.
This,
like
our
packet
statistics
on
interfaces,
proxy
up
configuration
and
great
arc
configuration.
G
We've
simplified
it
and
taken
some
stuff
out
that
we
didn't
have
consensus
on
between
the
authors
on
the
fact
that
everyone's
implementing
these
in
the
same
way
and
I've
highlighted
two
leaves
there
that
I'll
talk
about
a
little
bit
more
one
is
the
in
a
belief
for
grata
and
the
second
one
is
a
discontinuity
time,
timestamp
3
for
the
statistics,
but,
as
you
can
see
here,
this
is
a
pretty
basic
model.
There's
one
extra
global
leaf,
there's
a
bit
more
stuff
on
the
interfaces
and
then
augment
ation
in
terms
of
an
expiry
time.
G
Next
slide,
please!
So
what
have
we
changed?
Mainly,
it's
been
editorial
improvements
to
improve
the
introduction
text,
the
security
sections.
We
just
tried
to
improve
that
those
we've
also
gone
through
and
cleaned
up
their
model,
a
little
bit
more.
We
simplified
it
in
places.
As
I
said,
we've
taken
a
few
things
out.
G
What
else
we've
done
so
there
was
a
dynamic
global
default
setting,
that's
now
on
by
default
and
to
try
and
make
that
more
intuitive,
as
I
said,
align
the
global
interface
configuration
together
so
that
these
are
the
same
names
and
the
same
defaults
formatting
has
been
improved
and
then
I've
added
this
content.
This
continuity
timestamp
for
the
ARP
counters.
Now
this
is
the
one
one
of
the
issues
I
would
like
to
raise
to
get
feedback.
What
people
think
about
this
as
the
next
slide.
G
So
of
the
two
issues,
the
first
one
is:
there's
a
set
of
art
statistics
that
we're
reporting
that,
unlike
the
number
of
part
packets
received
what
the
type
of
those
packets
were
and
the
ones
that
were
sent-
and
the
question
is-
is
whether
the
art
statistics
should
have
their
own
discontinuity
counter
to
say
when
those
counters
are
from
a
what
point
to
those
counters
actually
count
from
now.
There's
a
few
choices
here,
I've
added
one
in
here.
Another
choice
would
be
to
say
just
reuse.
G
The
interfaces,
interface
counters,
discontinuity
counter,
so
you'll
assume
that
the
ARP
counters
would
get
reset.
If
you
reset
the
interface
counters
and
the
to
align,
that's
one
choice.
You
could
keep
this
separate
as
I've
done
here
or
perhaps
you
could
say
it's
implementation
to
fine.
So
you
could
say
that
if
this
count
is
provided
by
the
implementation,
that's
what
it
means
and
it
doesn't
then
it's
up
to
the
implementation
to
specify
so
there's
anyone
have
any
opinions
on
this
on
how
which
way
we
think
we
should
go.
S
Jeff
has
so
it
does
seem
a
little
bit
weird
that
you
do
have
it
there
and
I
have
two
pieces
of
thinking
and
that,
based
on
classical
SNMP
type,
your
moobs,
if
you
really
do-
have
to
separate
internal
subsystems
that
can
have
distinct
discontinuities.
Having
that
sort
of
thing
make
sense,
yeah.
That
said
in
not
paying
as
much
attention
to
gang
models
as
I
used
to,
but
I
think
this
is
the
first
time
I've
actually
seen
a
specific
sub-module
have
its
own.
Just
can't
do
anything.
G
And
I
think
mean
like
when
the
root
is
rebooted,
which
is
one
standard,
discontinuity
time,
I'm
thinking
more
that
sometimes,
if
somebody's
come
along
and
clear
statistics
for
some
purposes
and
that's
the
one
I'm
worried
about,
and
maybe
in
the
young
model
you
just
don't
allow
that
you
don't
clear
the
statistics.
You
always
just
take
her.
G
If
you
want
to
see
the
change,
you
take
a
stamp
at
one
point
of
time
and
look
at
another
one
and
in
terms
of
the
subsystems
in
terms
what
you
say,
it
might
be
better
then,
for
this
not
to
be
in
the
model
and
if
a
vendor
wants
to
do
that,
they
Anna
added
in
their
own
model
and
they
modify
the
description
States
to
say
this
is
how
it's
changed.
That
might
be
a
bit
safer
right.
So,
okay,.
S
S
G
The
second
issue,
again
is
a
minor
one.
So
at
the
moment,
in
the
model,
the
gratuitous
ARP
settings,
the
interface
has
been
left
as
effectively
no
no
standard
default.
So
it's
up
to
the
vendor
implementations
to
decide
whether
they
do
gratuitous
art
by
default
and
whether
it's
on
or
off
by
default,
and
then
it
gets
explicit
use
a
way
for
a
client
to
be
able
to
decide
to
turn
it
on
or
off.
I.
Wonder
I,
sort
of
don't
like
these
ambiguous
defaults
in
yeah
models.
I
think
it
makes
them
harder
to
use.
S
G
G
What
their
position
is
over
time
was
that
as
that
technology
has
matured,
and
so
in
I
Triple
E,
that's
on
by
default,
whereas
our
management
model
has
it
off,
and
people
arguing
internally
to
say
all
this
make
it
ambiguous,
but
I
just
see
that's
really
hard.
Nobody
knows
whether
it's
on
or
off
until
they
explicitly
configure
I,
don't
think
it's
easier.
So
that's
why
I'm
are
you
need
to
try
and
say,
look
try
and
get
rid
of
these
ambiguous
e-force
where
we
can
but
Eve?
S
What's
people
that
have
a
good
security
standpoint,
but
argue
that
off
is
probably
the
same
thing
to
do.
The
thing
that
I,
based
on
your
comment
you
may
want
to
it
specifically
put
a
comment
in
the
module
that
the
module
should
survive
deviations
to
actually
cover
the
system
for
other
things.
Okay,.
G
That
seems
practical
and
I.
Think
I've
got
one
more
slide
and
suggest
in
terms
of
the
remaining
work.
I.
Think
we're
fairly
close
to
being
done
on
this
I
thing
and
there's
made
a
little
bit
more
tied
up
and
clean
up
those
two
issues.
We
can
act
as
an
update,
the
draft
so
I
think
for
maybe
we
might
not
have
that
much
more
to
be
done
before
we're
ready.
A
G
J
H
E
E
So
we
had
some
progress
made
in
SFC,
nsh
definition
of
interpretation
of
opiate
and
how
active
I
am
defined.
Rfc
8300
defined
orbit
as
when
it
said
it
indicates
an
oem
packet
and
in
a
document
with
effectively
addresses
and
discusses
SFC
active
om.
We
agreed
to
clarify
that
setting
this
bit
indicates
that
om
command
or
data
are
in
an
SH
context,
header
or
packet
payload.
E
E
So
this
example
demonstrates
that
so
let's
go
next
if
obit
set
and
the
next
protocol
is
one
of
the
protocols
associated
with
OEM,
then
the
payload
that
follows
immediately
after
an
SH
header
includes
OAM
data
or
command,
and
so
this
illustrates
whether
it's
a
fixed
header
or
variable
length,
context
header.
Next,
if
Oh
beat,
is
clear
and
next
protocol
is
not
one
of
the
protocols
associated
with
OEM.
Then
this
is
a.
E
E
E
Yes,
there
was
introduced
or
bit,
but
draft
expired,
so
I
don't
know
how
it
will
be
revived.
Progressed
I
would
like
to
discuss
it
with
offers.
If
they're
interested,
we
might
find
some
solution
for
the
Excel
NGP
next
slide.
Well
again
appreciate
your
questions.
Comments,
I,
don't
see
that
this
document
has
to
progress
very
far,
I'll
be
very
happy
if
there
will
be
some
consideration
of
what
we've
done
for
SFC,
a
message
for
other
variable-length
encapsulations
and
that
will
enable
work
on
om
for
this
network
layers.
Thank
you.
A
E
O
Okay,
just
as
a
reminder,
so
today
refa
stands
for
topology
independent
LFA,
so
it's
a
knight,
PFS
reward
mechanism.
It
is
based
on
segment
routing
to
build
via
the
backup
path.
However,
it
can
protect
any
kind
of
traffic,
whatever
its
IP,
MPLS,
LDP
or
even
MPLS
RSVP.
If
you
want,
could
work
as
it
could
be
seen
as
an
evolution
of
refe
remotely
Fillion
and
direct
the
forwarding
RFA
just
one
step
further,
the
added
value
we
see
in
two
pretty
independent
NFA
that
first
of
all
its
topology
independence,
so
we'll
nffa
matter.
O
If
a
we
always
add
an
issue
with
the
coverage
because
sometimes
depending
on
the
topology,
there
was
no
possibility
to
found
the
packet
path
and
with
jefa
whatever
also
topology
you
will
have.
You
will
always
have
a
backup
path
available,
which
is
pretty
good,
and
we
ever
think
you
have
a
benefit
coming
with
operation.
Independent
RFA
is
that
we
are
trying
to
optimize
the
backup
path
that
we
are
using.
O
So
ever
was
social
document
has
been
added
to
the
recently,
but
Farwest
bunches
of
comments
received
even
before
he
adoptions.
A
lot
of
comments
were
about
this
notion
of
post
convergence
path.
We
were
using,
which
was
quite
unclear,
but
we
will
come
back
to
that
a
bit
later
there,
as
was
also
some
question
about
the
scaling
of
the
computation,
especially
if
we
are
trying
to
compute
a
queue
space
for
each
destination.
O
Some
comments
were
also
pointing
some
anchor
points
in
the
data
plane
procedure,
especially
in
case
of
snps,
when
PHP
was
involved,
yeah
and
some
of
our
comments,
but
we
would
try
to
cover
them
in
the
next
slide.
So,
first
of
all,
post-conversion
staff,
the
idea
behind
LFA
is
to
try
to
provide
a
backup
path
which
is
I
would
say
optimal.
O
What
could
be
concluded
from
that?
From
the
X
point
of
view?
I
would
say
optimal
and
well.
Sized
path
is
to
use
X
H
of
X
d-link.
So
from
a
capacity
planning
point
of
view
of
the
network,
I
need
to
ensure
that
when
the
x
building
is
failing,
I
have
enough
capacity
on
XH
+.
Xd
link
to
support
the
traffic
that
was
previously
on
X
B.
O
This
is
true,
but
not
completely
optimal,
because
some
of
traffic
on
xB
is
not
splitted
on
XH
+
XD,
because
some
of
the
traffic
coming
from
p1
will
go
out
from
X
naught,
so
some
other
traffic's
that
was
previously
going
through
this
path
will
be
rerouted
there,
however,
depending
on
the
convergence
order.
So
if
P
one
is
converging
before
X
and
if
I'm
sizing
the
extension
XD
to
support
the
traffic
on
xB
I'm
old,
my
oversizing
a
bit
zerlings,
which
are
there,
however,
if
X
is
converging
before
p1,
am
I
sizing?
My
network?
O
Sizing
is
good
because
I'm
able
to
support
all
the
traffic,
so
the
IDB
int
RFA
is
to
try
to
reuse
this
capacity
planning
concept.
So,
from
the
point
of
local
repair
point
of
view,
we
will
try
to
use
the
next
shortest
path,
taking
into
account
the
failure
of
the
link.
So
if
we
take
into
account
that
xB
link
will
potentially
fail
now
you
want
to
protect
against
this
failure.
My
I
would
say
best
optimal
path
would
be
on
XH
or
XD.
O
This
is
an
assumption
in
terms
of
network
capacity
planning.
Some
networks
could
do
other
capacity
planning
in
another
way.
If
people
are
not
really
happy
with
this
post
convergence
path,
idea
of
jefa,
we
can
still
use
the
policy
mechanism
that
has
been
defined
in
a
1716
to
be
able
to
tune
of
a
backup
path
using
other
criterias
and
hasan
visa
post
convergence
perform
next
HP
shortest
path.
O
If
you
ever
comments
that
we
have
received
about
this
post
convergence
path,
is
that
it's
not
really
the
post
convergence
path?
Why?
Because
geography
is
a
first-world
mechanism,
so
it
pre
computes
a
path
for
an
expected
failure.
So
let's
say
that
I'm
doing
not
protection
I
will
free
computer
path,
taking
into
account
that
this
node
will
potentially
fail.
However,
in
reality,
maybe
the
node
will
not
fail.
Maybe
just
one
link
will
fail.
Our
set
of
links
will
fail.
O
So
this
leads
to
the
fact
that
the
backup
path
that
I
will
put
on
Shelly
use
is
not
completely
optimal
because
it's
optimal
from
an
expected
failure.
Point
of
view,
but
it's
not
really
optimal,
of
if
the
failure
that
is
happening
is
not
the
failure
that
I
was
predicting
and
protecting
for.
So
that's
why?
O
Before
so,
we
were
using
the
notion
of
post
convergence
path,
but
we
have
changed
the
wording
to
expected
post
convergence
that,
because
we
are
expecting
so
traffic
to
use
this
path
but
yeah,
maybe
if
the
failure
is
different
from
the
one
I'm
protecting
yeah.
So
post
convergence
path
will
not
be
exactly
this
one.
O
So
in
terms
of
update
to
address
this
post
convergence
path,
concerns
that
has
been
raised
on
the
list,
so
we
have
added
some
reference
to
the
RFE
79
16,
which
was
already
talking
about
via
path
optimality
issue,
especially
in
LFA,
on
a
remote
area
on
vironment.
So
we
also
changed
the
warning
from
post
convergence
path
to
expected
post
convergence
path
to
deal
with
this
potential,
not
full
optimality
of
the
Bekaa
path,
and
we
have
also
really
explained
the
use
case
and
the
benefits
of
using
the
post
comments
before
expected.
O
O
Now,
regarding
the
scaling
considerations
of
a
queue
space
computation,
that's
not
really
an
easy
issue
because
yeah
an
easy
topic,
because
this
is
one
of
the
points
that
we
need
to
discuss
for.
This
draft
is
what
is
the
level
of
detail
we
want
to
put
in
in
term
of
computation
algorithm?
Do
we
want
to
do?
O
We
expect
to
have
a
full
definition
of
an
algorithm
to
compute
the
backup
path
for
a
just,
a
concept
that
we
are
presenting
in
the
current
version
are
enough,
because
today
what
we
are
doing
is
just
to
say
that
okay,
we
compute
the
post
convergence
path,
so
we
compute
an
SPF
based
on
are
taking
into
account
the
failure
of
the
component.
So
SLG
is
another
author
link
and
then
we
need
to
express
this
post
convergence
path
as
a
loop
free
path
by
using
not
sidon
adjacency.
O
But
the
challenge
is
how
to
compress,
as
this
labor
stack
to
be
to
be
minimum,
and
here
we
can
reuse
the
p
space
and
Q
space
concept
that
we
are
defined
in
the
remote
LFA
drafts
or
RC
7490,
and
this
RFC
was
already
talking
about
the
scaling
issue.
If
we
are
trying
to
compute
a
queue
space
per
destination,
so
this
means
computing.
O
But
we
are
not
at
least
today
defining
a
full
algorithm.
We
are
just
defining
the
principles
of
the
technology,
so
we
are
pointing
miscarrying
considerations
to
the
paragraph
which
is
already
existing
in
the
remote
NFA
RFC,
and
we
just
say
that
it
will
be
implementation,
dependent
fight,
the
good
fight
off
between
optimization
and
computational.
O
Now,
in
case
of
data
point
procedures,
so
we
did
some
work
on
million.
The
text
try
to
be
more
consistent
in
the
wording
we
were
using,
because
sometimes
we
were
mixing.
I
said
that
a
plain
words
like
push
next
continue
and
so
on,
and
sometimes
we
were
using,
MPLS
push
swept
and
so
on.
So
now
we
are
more
consistent
and
we
are
using
unleash
terminology.
O
We
have
also
introduced
a
normative
language,
which
was
clearly
missing
in
the
previous
version,
and
the
important
point
is
that
in
case
of
SNMP
RS,
there
are
special
behaviors
to
deal
with,
especially
when
a
penalty
meta
popping
is
involved.
So
just
to
give
you
one
example
when
I'm
trying
to
protect
a
link
which
is
called
SF
and
let's
say
that
I
have
an
incoming
packet,
so
MPLS
packets,
coming
with
an
adjacency
seed
at
the
top
of
the
stack
which
is
a
via
SF
in
and
not
followed
by
a
note
segment
going
to
another
20.
O
So
the
basic
behavior
of
CIL
failing
protection
will
be
to
create
a
back
path
which
match
back
on
the
F
node.
So
we
will
create
a
repair
list,
which
is
a
called
year
at
EF,
followed
by
another
segment
going
to
F,
which
is
merging
back
as
two
to
the
limit
and
over
link.
However,
if
our
repair
lists
is
so
the
fgf,
which
is
also
a
combination
of
adjacency
segment
and
noodle
segment,
is
terminating
by
an
adjacency
segment
which
will
forward
the
traffic
on
F.
O
O
If
the
local
policy
is
changing
the
path
towards
something
which
is
different
from
the
shortest
path,
so
one
remark
about
that
is
that
such
local
policy
could
even
break
today,
LFA
or
remotely
fail
or
even
Vig,
be
shortest
path.
It's
not
just
not
something
related
to
TI
LFA,
so
it's
really
a
matter
of
network
design
to
create
local
policies
that
will
keep
the
network
loop
free.
So
that's
why
you
think
that
it's
a
responsibility
of
the
operator
to
ensure
that
this
local
policy
will
not
break
the
loop
free
nests
of
the
shortest
path.
O
The
other
solution,
which
could
be
to
protect
an
Al
Gore,
zero,
not
seed
by
using
nodal
segments
that
are
using
the
algorithm
number
one
so
algorithm
number
one
is
called
a
strict
SPF
and
restrict
SPF
is
exactly
the
regular
xpf,
except
that
we
can't
have
a
local
policy.
Okay,
it
can't
be
overridden
it's
always
via
shortest
path,
so
by
using
strict
SPF
instead
of
regular
instead
of
algorithm,
algo
zero.
Sorry
in
the
repair
list,
we
ensure
that
the
root
freeness
will
never
be
broken.
The.
O
Second
point
about
flex:
algo
is
that
we
could
make
a
nfa
working
with
flex
algo.
We
just
need
to
ensure
that
if
I'm,
protecting,
not
seed,
which
is
using
a
particular
flex,
algo
I
just
need
to
use
in
the
repair
list.
Some
not
seeds
that
are
using
exactly
the
same
flex.
I'll
go
and
eat
all
my
optimization
algorithm,
instead
of
using
the
regular
SPF
for
every
SPF
I'm
using
the
same
C
SPF
constraints
that
are
part
of
the
spec
salvo.
But
in
theory
it
should
work.
O
O
They
are,
of
course,
points
to
discuss,
especially
this
last
point
about
tal
FA,
jana,
si
algo
relationship,
and
if
we
want
to
set
a
strict
rule,
for
example,
to
protect
and
not
cede
with
alcohol,
only
with
some
nodal
segments
with
algo
one
do
we
want
to
set
it
as
a
master
or
not
and
yeah.
The
main
point
of
so
that
we
need
to
agree
on
is
what
is
the
level
of
details
that
we
are
expecting
in
this
document
in
terms
of
computation
steps?
V
So
I'd
like
to
comment
on
your
previous
slide,
so
I'm
kind
of
worried
that
we're
losing
the
unconditional
correctness
that
we
had
in
the
original
fast
reroute
concepts
particularly,
is,
if
anything
goes
wrong
in
fast
reader.
Not
only
will
you've
lost
all
the
reasons
that
you've
put
it
there,
but
it's
going
to
be
an
absolute
devil
to
debug,
because
these
are
really
transient.
The
bugs
will
be
transient,
because
these
properties
are
only
supposed
to
be
in
place.
Transiently
now,
I
suppose.
Your
second
suggestion
is
probably
the
the
least
worse
in
the
Thunder.
B
So
I'm
with
respect
to
that
point,
I
think
perhaps
for
you
know,
option
one
of
you
know
local
policy
sort
of
spelling
out
the
scenarios
where
or
an
example
scenario
where
you
could
create
create
loops.
Even
in
a
normal,
you
know,
unexpectedly,
you
can
spell
that
out
a
little
better
so
that
you
know
what
what
level
of
consistency
do
you
need
like
to
to
to
avoid
that
in,
and
mainly
just
in
the
the
topic
of
the
local
policy
being
in
fact,
TILs
right
now?
What
what
consistency
do
you
need
to
avoid
loose
yeah.
O
Yeah,
the
main
touch
video
an
issue,
not
a
concern,
but
it
sounds
just
strange
to
me
to
say
that
let's
say
that
for
Al
Gore's
you
will
not
sit
I'm
just
able
to
use
algo
one
not
sit,
and
for
let's
say
that
we
want
to
apply
this
to
flex
algo,
which
means
also
that
we
need
to
define
a
kind
of
sibling
algorithm
for
each
flex,
algo
to
be
a
strict
flex.
Algo.
V
Not
sure
the
I'm
not
sure
whether
you
need
twice
to
part
again,
whether
you
need
twice
as
many
algorithms
but
I
think
the
fundamental
is
that
you
need
to
operate
entirely
within
a
single
Tripoli,
a
single.
What
I
call
topology
I,
don't
sure,
where
that's
the
right
term,
so
that
there
is
always
mutual
consistency
in
the
in
the
network
in
terms
of
what
the
path
and
what
the
alternative
paths
are
and
the
packets
are
tracked
within
that
topology.
So
it's
true
anything
else.
V
B
A
L
W
W
Please
continue
so
just
to
again
overall
motivation.
What
we're
trying
to
do
we're
not
trying
to
create
a
standard
protocol
and
management
protocols,
control
protocols
for
the
interoperability
of
devices
in
an
SD
when
we
are
trying
to
create
into
working
protocol
at
standardization
between
and
wealth,
between,
SD
lands
at
well-defined
interfaces
next.
W
So
this
is
our
reference
architecture
which
we
have
created
in
the
open
estimate
exchange
as
part
of
the
open
network
users
group,
our
own
luck,
which
I
am
one
of
the
chairs
of
so
this
model
attempts
to
define
the
interfaces
of
which
around
which
we
will
stand
it
up
and
you
can
see
the
interfaces
around.
The
outside
focus
of
today's
presentation
is
primarily
interfaces
to
allow
for
communication
and
setting
of
path
management,
information,
sending
a
path
management
information
into
the
SD
when
transport
network,
so
the
next
slide.
W
B
W
Just
start
from
the
beginning
of
the
slide:
okay,
this
slide
covers
the
initially
used
cases
we
have
in
the
draft.
You
can
see
up
here
that
we
have
a
definition
of
act,
surf
management
service
model.
The
goal
of
that
service
model
is
to
define
the
parameters
needed
to
put
particular
applications
and
flows
on
a
specific
path
within
an
SD
when
the
third
use
case
number
one
as
to
define
the
path,
management
policy
service
model
and
the
definition
of
the
enforcement.
How
that
path,
management
service
model
should
be
enforced
within
each
st
LAN
domain.
W
Okay,
the
second
use
case
or
model
we've
created
is
a
gateway
service
model
which
defines
the
interoperability
interoperate,
interoperating
and
I
between
two
SP
one,
as
you
can
see
here
at
the
gateway
edges
for
achieving
a
connection
between
two
sp1
vendors.
So,
of
course,
there
are
many
ways
to
do
this.
W
There
are
many
ways
to
do
this,
so
we
are
trying
to
lock
down
a
standard
way
so
that
it
can
be
exported
in
all
different
vendor
controllers.
Okay,
let's
go
to
the
next
slide,
so
this
gets
in
to
the
structure
now
of
the
game
model
for
each
of
those
use
cases.
So
you
can
see
here
we
have
defining
a
set
of
parameters
to
allow
communication
between
an
upper
layer
Orchestrator
which
is
not
defined
as
part
of
the
the
RFC.
W
But
the
idea
is
to
create
a
set
of
yang
which
could
be
used
to
create
an
API
that
could
define
reach
ability,
the
parameters
between
the
gateways,
so
we
have
a
reach
ability
service
model
which
has
roughly
the
functionality
singing
here:
oscy
gateway
creation
within
each
domain,
the
Gateway
configuration
for
PGP
or
multi
port
called
BGP
and
Cokely
parent,
as
well
as
the
underlay
connection
setup
and
the
overlay
tunnel
setup,
either
a
grea
or
IB
CENTCOM.
In
addition,
in
addition,
we
have
an
API.
W
We
have
got
a
model
that
allows
us
to
do
a
segment
instance
creations
or
cross
connect
between
the
Kea,
the
segments
on
one
st
one
domain
and
the
companion
st
Lindemann
as
well.
The
new
models
created
containing
path
service
model
that
can
is
set
up
to
the
specified
parameters
needed
for
dynamic
path.
Selection.
Already
across
the
main
traffic
and
configuration
next
slide,
ok
gets
here
into
a
little
bit
more
of
the
guts
of
the
gateway
service
model
design
itself.
So
this
is
specifically
looking
at
some
of
the
details
of
the
Gateway
service
model.
W
L
W
T
W
Okay,
hopefully
this
will
be
better
okay,
great
okay,
so
we
have
two
options
for
control
plane
carrying
one
is
using
both
the
protocol,
php-based
evpn
or
l3
VPN
style
of
communication,
or
either
working,
and
then
they
have
fuss.
You
know
standard,
simply
simple
opportunity,
birth,
flight
type
of
control,
plane
and
different
interfaces
capability.
So
this
capability
can
be
negotiated
between
controllers,
what's
supported
and
then
set
up.
W
W
Ok
and
also
of
and
security
and
open,
have
a
face,
I
xx
and
a
VPN.
So
we're
expecting
for
the
most
part
that
IV
site
VPN
will
be
the
option.
That's
used
alright
and
then
you
can
see
as
well.
We
have
a
segment
mapping
list
a
lot
of
users
to
not
even
from
us
connect.
You
know,
it's
definition
is
to
be.
We
need
SP,
wet
islands.
W
Okay,
this:
this
is
the
path
management
service
model
design.
So
the
path
management
policy
is
really
ordered
list
of
traffic
classifiers
along
with
an
SLA
list,
and
then
the
selection,
old
or
preferred
path,
selection
policy.
Okay,
what
we
will
do
is
have
a
first
match
against
air
traffic
classifiers.
That
believe,
then,
would
be
applied
to
the
linking
path
policy,
which
is
then
contained
in
the
SLA,
that's
associated
with
those
links
in
past.
We
can
see
that
tree
model
diagram
up
here.
W
The
idea
here
is
that
we
have
a
definition
of
application
or
application
flow
with
classifiers.
You
can
see
that
is
attached
to
a
link
in
path
definition
policy,
so
which
meant
I
should
prefer
based
on
based
on
the
conditions
on
the
link
or
based
on
my
policy,
if
I
want
to
prefer
a
specific
private
network
or
as
a
specific
business
party,
flying
for
example,
and
then
any
kind
of
unique
and
performance
SLA
information.
So
we
have
a
name
for
that.
X
Sorry
further
connection
and
this
past
management
service
model
is
actually
used
for
the
traffic
for
cross
domain.
The
domain
a
belongs
to
one
vendor
domain
and
domain
B
belong
to
another
one,
so
there
is
a
because
in
UNIX
reference
model
that
the
oxidation
layer
is
a
quite
light,
quite
light,
one
that
ox
just
oxidative
for
the
application.
They
aware
service
policy
or
other,
like
the
previous
one,
that
the
Steve
just
described
about
the
owner,
the
gateway
and
then
I
interface
connection
setup
model.
X
So
these
two
model
can
can
help
the
owner
that
this
UNIX
reference
model
architecture
to
to
describe
the
what
their
service
requirements
is.
Actually
they
they
don't
want
to
touch
the
like
the
domain,
ace,
a
device
setup
or
the
infrastructure
setup.
All
the
UNIX
reference
a
framework
is
based
on
the
the
each
domains.
X
X
It
means
that
in
anak
scenario,
there
will
be
like
multiple
paths
for
each
site
that
connected
to
the
the
one
network,
maybe
like
private
MPR's
network
or
the
internet
work
so
but
in
the
ox
tration
have
the
like
the
two
domains:
topology
or
the
like,
and
an
SLA
information.
So
they
can
divide
the
like
the
cross
domains,
traffic
s,
s,
SL,
a's
requirements,
dividing
into
two
separate
domain,
then
the
end
and
SLA
can
be
guaranteed.
So
that's
a
this
model
so.
B
X
So
I
will
on
to
the
open
issues,
because
this
is
just
a
very
initial
draft
here
and
we
are
working
on
to
make
it
more
clear
and
more
complete,
because
right
now
the
own
acts
service
modeling
is
a
customer
facing
model,
so
they
rely
on
the
the
infrastructures
control
playing
protocol
defined
in
IETF,
because
that's
ITF,
expertise
and
and
ona
also
notice.
There
are
some
work
on
the
ITF
to
do
this
kind
of
work.
X
So
so
we
will
like
update
our
service
model
depending
on
those
work,
the
ITF
and
also
we
still
have
other
open
issue
with
paths
like
specific
domains,
a
traitor
loss
that
kind
of
a
sow,
a
measurement
requirements.
How
can
we
do
that
with
you?
That's
the
an
open
issue
choose
so
so
this
time
it's
a
quite
initial
draft,
so
we
would
like
to
have
more
were
review
and
feedback.
Can
we
can
like
to
collect
more
review
and
feedback
to
help
us
to
create
a
very
yes?
Oh,
yes,.
Y
Women
Eric's
from
Nokia,
okay,
I,
think
I
I
think
it's
good
work
that
is
it's
going
on
in
general,
I
was
wondering
with
respect
to
the
services
itself
like
layer,
2,
VPNs
and
layer
3
VPN.
Are
you
in
I?
Haven't
really
read
the
draft
in
all
details?
Are
you
going
to
reuse
l2
as
I'm
and
I'll
3sm
for
depth
in
this
draft,
or
because
the
focus
of
this
draft
is
mainly
about
the
gateway
and
the
interoperability?
Yes,
as
well
as
the
port
management,
but.
L
X
L
X
Y
X
W
Y
About
yes,
yeah
I,
actually
actually
across
the
board,
because
what
you're
trying
to
define
is
an
end-to-end
service
right,
so
we
should
actually
try
to
abstract
the
implementations
on
the
needs
and
I.
Think
then
it's
not
only
about
interconnection.
It's
not
only
about
the
path
selection
mechanism,
but
also
the
end-to-end
service,
which
you
define
either
within
or
even
across
the
different
scenarios.
W
Y
Line,
but
what
I'm
trying
what
I'm
getting
to
it?
It's
to
have
a
full
service
definition
for
SD
wanna
as
a
service
as
a
complete
service
suite,
rather
than
doing
a
bit
here
and
a
bit
there,
so
that
you
have
one
definition,
and
you
say:
okay:
this
draft
is
what
you
have
to
look
for.
This
is
your
as
the
one
service
definition
model,
and
this
will
not
only
cover
the
bad
management,
not
only
the
interworking,
but
also
the
end-to-end
service
layer,
I.