►
From YouTube: IETF105-RTGWG-20190722-1000
Description
RTGWG meeting session at IETF105
2019/07/22 1000
https://datatracker.ietf.org/meeting/105/proceedings/
B
B
B
Okay,
let's
look
at
working
group
governments.
We've
got
one
year,
FCAT
541
an
impact
on
SPF
triggers
and
delays
to
documents
submitted
to
is
G.
Read
document
has
been
in
limbo
for
almost
two
years,
so
I
conducted
our
sirs
and
I
think
we
are
trying
to
progress
documents
by
moving
some
parts
of
it
into
informal
PA
multi
Jamica
columns,
ready
city
follow
up
gruff
anyway,
so
the
informal
document
has
been
in
this
state
for
over
a
year
we
are
still
waiting
for
Shepherd
review.
B
C
So
for
the
problem
statement,
we
specifically
add
a
section
how
the
SD,
when
placing
this
domain
cloud
data
center
itself,
it's
really
they
can
interconnect
themselves
and
then
the
problem
is
for
Enterprise
instantiating
their
workload
into
the
cloud
data
center
because
of
the
geographic
location,
the
proximity
to
their
end
users,
the
most
enterprises
tend
to
instantiate
their
workload
to
the
locations
which
is
suitable
to
their
usage.
So
the
the
workload
becomes
ephemeral
like
they
change
when
they
can
be
instantiating
location,
one
another
time
can
be
instantiation,
so
the
location
being
changing
in
form.
C
C
And
we
also
got
comments
about
on
the
V
PC
itself.
Is
it's
called
virtual
private
cloud?
What
it
really
is
is
really
kind
of
virtual
network
dedicated
to
one
tenant,
the
like
actually
as
one
enterprise,
they
could
have
multiple
virtual
private
cloud,
multiple
virtual
networks
and
almost
virtual
networks.
They
instantiate
different
compute
resource
or
storage
resource.
So
that's
how
the
virtual
private
cloud
being
differentiated
from
the
virtual
network
itself,
it's
including
the
compute
and
also
many
times
virtual
functions
as
well
for
the
problem
itself.
We
ended
the
clarification,
multiple
different
ways.
C
A
workload
can
be
connected
and
many
cloud
datacenters
today
offers
internet
a
gateway.
Allow
users
to
connect
to
the
workflow
through
the
internet.
Another
way
is
like
a
virtual
gateway
or
IPSec
gateway.
So,
though,
allow
them
to
connect
to
their
work
go
through
secure
Channel.
Then
another
option
could
be
the
recollect
they
could
have
physical
infrastructures
or
physical
path.
They
purchased
from
provider,
provide
network
to
connect
to
the
customer
gateway
so
as
from
workload
perspective,
they
could
just
being
connected
by
different
methods.
C
Also
that
we
also
added
details
on
the
for
the
Gateway
itself.
It
will
advertise
all
the
prefix
for
this
particular
client
of
particular
tenant,
but
the
actual
workload
itself
may
be
actually
located
in
different
locations
from
cloudiness,
and
the
perspective
is
Oh
like
lumped
together
as
all
the
reachable
through
this
particular
gateway
or
through
multiple
gateways.
So
that's
another
problem
from
routing
perspective.
C
C
C
So,
for
example,
prefix
10.1.1.1
fix
or
be
line
number
three
PennDOT,
one
thought
X
have
the
encapsulation
of
gie
and
villain
number
three
can
be
encapsulated
by
the
enemy
to
be
excellent
and
then
it
advertised
to
all
the
peers.
So
when
our
three
receiver
prefix
to
route
to
10.1,
they
know
that
oh
I
can't
use
this
particular
gie
encapsulation.
So
the
confusion
part
lots
of
discussion
on
the
mailing
list
and
just
give
us
some
up.
C
It's
about
the
remote
end
point
the
remote
end
point
to
people
who
are
familiar
with
who
wrote
the
draft
is
very
clear
to
them,
but
to
many
people
is
kind
of
confusing
is
real,
especially
for
our
one
perspective.
Well,
he
sent
out
the
update.
The
remote
end
point
is
actually
himself
and
for
the
receiver
they
see
the
remote
endpoint
McCandless
R
one
and
another
confusion.
Part
was
some
esta,
a
note.
Themself.
A
third
party
can
send
on
behalf
of
r1.
C
So
like
a
controller,
they
want
to
notify
all
the
relevant
parties
of
encapsulation
capability
to
r1.
They
can
use
the
remote
end
point
to
indicate
it
is
actually
our
one
is
where
the
encapsulation
destination
should
be
so
with
that
being
cleared
out
and
the
gaps
need
to
the
the
one
point
management,
because,
as
you
see,
that
the
EB
piano
or
any
VPN
is
all
about
the
client
routes
distributions
and
for
the
one
port
is
connected
to
the
provider
network.
So
it's
less
of
a
concern,
but
for
SD
one
is
different
for
SD
one.
C
The
one
point
could
facing
different
ISPs
facing
internet
facing
trusted
network
or
facing
untrusted
Network
and
the
one
point:
if
it's
in
the
cloud
it
could
be,
a
private
address
could
facing
the
net
could
facing
different
gateways.
So
all
those
web
properties
need
to
be
propagated
to
the
remote
peers
and
the
peers
can
be
in
different
countries.
C
Different
continents
so,
and
also
the
the
route
reflect
themselves
on.
The
controller
themselves
can
only
be
reached
through
untrusted
Network,
so
that
part
has
to
be
making
it
clear
but
very
different
than
the
tunneling
cab
and
that
property
on
the
web
port
management-
that's
not
in
the
tunneling
cab.
C
In
the
past,
many
of
the
vendors
deploying
sd1
have
been
using
modified
and
HRP
to
basically
advertise
to
the
peers.
What
kind
of
one
port
address
they
have,
what
kind
of
like
a
net
functional
support,
but
for
some
of
the
large
deployment
and
HRP
just
doesn't
scale
well,
and
another
thing
is
about
attachment,
so
attachment
can
change
and
some
of
the
IPSec
tunnels
the
one
port
on
change
so
that
something
has
to
be
addressed.
C
We
also
clarify
this
security.
Bpm
CQ
v
PM
has
done
a
good
job
to
basically
set
set
up
the
IPSec
tunnels
between
like
a
node
in
shopping
mall,
on
node
in
cloud
data
center,
where
that
is
not
directly
connected
or
directly
attached
to
the
provider,
McKeon's
PE,
so
that
IPSec
tunnels
can
be
established
at
different
Claire
different
granularities.
C
C
You
connect
to
the
provider
VPN
and,
and
you
want
to
expand
your
capacity-
you
create
an
Internet
port,
so
through
the
internet
port
you
can
bypass
some
of
the
traffic
either
secured
or
not
secured,
and
the
decision
is
really
the
local
decision.
From
the
CPS
perspective,
some
traffic
had
to
go
to
the
VPN.
C
Sick
is
SLA
and
some
traffic
can
go
through
the
the
public
Internet,
and
this
can
change
depending
on
the
network
performance
and
most
of
the
sd1
deployment.
Have
this
traffic
monitoring
based
on
different
applications
and
they
adjust
the
policies
on
the
wrong
time.
Another
characteristics
of
the
st1
is
location
of
proximity
requirement.
Some
of
the
deployment
requires,
some
traffic
have
to
traverse
certain
locations.
Maybe
they
have
specific
functions
need
to
perform.
C
D
C
D
Thanks
so
I
had
I
provided
a
lot
of
feedback
specifically
on
the
problem
statement,
document
and
I.
Think
Jeff
and
I
are
of
the
opinion
that
just
focusing
on
that
document
that
it
still
it
still
needs
a
lot
of
work.
In
terms
of
you
know,
clarity,
it
draws
a
lot
of
interesting
conclusions,
but
the
means
by
which
it
arrives
at
that
conclusion
are
kind
of
unclear,
but
I
also
had
a
question
looking
at
this
on
the
the
fact
that
you
have
two
documents
here,
is
there
any
possibility
to
combine
these
two
documents.
D
Mean
in
general,
we
in
a
working
group,
we
see
a
certain
amount
of
work
to
publish
a
document,
but
once
it
leaves
a
working
group
once
you
do
working
group
last
call
and
request
publication,
there's
a
huge
amount
of
work
that
goes
on
by
the
ad
and
the
iesg,
and
so
just
the
fact
of
having
two
documents.
If
they
could
really
be.
One
document
might
help
that
that
aspect
quite
a
bit.
E
C
No,
no.
Actually,
this
is
just
a
little
bit
update
on
the
email
discussions
that
clarification
is
clear.
It's
not
in
this
draft.
Okay,
just
I'm!
Just
me
myself,
because
going
through
lots
of
discussion
I
want
to
update
the
group
with
some
clarification.
So
the
main
thing
is
really
the
that
gap
itself
in
a
document
is
just
to
talk
about
on
the
one
point
because
sd1,
when
port
can
facing
different
ink
networks.
So
that's
that
the
can
then.
E
Even
the
you
know,
if
we
trying
to
say
there
is
a
gap
Frank
though
I'm
not
sure
there
is
a
gap
because
you
go
through
the
tunneling
cap,
it
provides
tons
of
flexibility.
I
mean
you
can
do
the
Vanport
that
you're
talking
about
tunneling
cap
allows
for
sending
the
encapsulation
over
the
van
port
and
the
van
port
can
be
public
or
you
can
deprive
it,
and
then
it
allows
for
the
recursive
resolution
of
the
VPN
addresses
into
the
van
port,
and
so
that
you
don't
have
to
send
the
tunnel
attribute
with
every
VPN.
E
F
E
C
Actually
tunnel
in
cap
itself,
it
would
be
great,
you
can
point
it
out.
We
have
lots
of
discussion
on
the
mailing
list.
However,
it
didn't
address
about
the
one
port
property
when
talking
about
a
1
port
property,
it's
not
about
encapsulation,
it's
not
about
the
the
client
route
distribution.
So
the
section
you
mentioned
about
recursive
and
about
all
those
sections
we.
G
G
I
think
that
you
may
have
context
difference,
I
think
that
it's
possible
to
including
it's
possible
to
do
what
you're
just
saying
right,
but
the
secure
VPN
draft,
which
may
not
be
the
right
kind,
export
that
was
what
I
took,
does
not
have
it
in
it.
It's
it's.
It's
it's
and
I.
Think
that's
what
you
and
Linda
are
at
opposite
side
done.
Let's
just
saying
it's
not
specified
someplace
you're
saying
it's
possible
thumbs
up
to
both.
We
just
need
to
put
it
someplace
and
decide
where
it's
gonna
go.
H
H
H
C
Okay,
so
the
document
is
to
document
the
problem,
statements,
problems,
issues
and
for
myself,
I
think
is
invaluable
as
a
history
about
getting
the
together
discussion
on
the
problems
and
what
is
missing
and,
as
Chris
was
saying
that
we
need
more
people
to
put
into
the
problems.
Actually,
I
was
hoping
to
reach
out
to
some
cloud
providers
to
actually
go
through
the
document
and
maybe
adding
more
to
clarify
them.
C
I
think
it
will
be
valuable
for
the
community
to
have
this
document,
whether
you
publish
a
not
publish
but
I,
think
to
have
that
in
terms
of
gap
analysis,
some
of
the
gaps,
the
gaps
identified.
Of
course,
the
trust
where
the
tunnel
in-cab
or
secure
VPN
can
be
enhanced
to
address
those
gaps.
Then,
if
they
do
that's
great,
that's
served
the
purpose
of
this
document
right
so,
but
I
think
the
problems
is
is
valuable.
I
personally,
thank.
I
So
I
think
that,
having
a
problem
statement
document
that
looks
at
the
hybrid
cloud,
connectivity
is
extremely
valuable
and
this
document
does
a
lot
of
those
pieces
if
the
gap
analysis
and
it's
very
useful-
to
have
us
actually
thinking
and
discussing
SEO
and
some
of
these
other
constructs
that
are
very
commonly
used.
I'm,
not
sure
if
a
gap
analysis
is
the
right
endpoint
for
something
to
publish,
it
might
be
that
it
transforms
instead
for
being
a
gap,
analysis
that
sparks
discussion
into
a
recipe
book
yeah.
That
would
be
useful.
That's.
C
J
Dear
Patel
arcus
speaking
as
an
co-author
for
tunneling
katstra
I
just
wanted
to
let
you
know
that
refresh
is
being
made
as
we
speak.
It's
going
to
be
submitted
version,
13,
stone.
It's
submitted
today.
I
completely
agree
with
Ali
that
from
a
solution
perspective,
everything
is
in
there,
but
if
you
feel
something's
missing
feel
free
to
send
a
note
to
either
idea
or
routing
working
group.
J
D
G
Is
this
is
an
idea
moment
that
may
hope
the
cheers
we
will
be
discussing
these
straps
in
an
idear
session
on
Wednesday
from
1332
1530?
During
that
time,
I
will
give
an
overview
of
the
secure,
VPN
and
Ali
Ali
and
June
remotely
will
will
be
discussing
it.
Maybe
you
want
to
move
some
of
the
technical
stuff
over
the
IDR
with.
E
K
So
if
I
accidentally
say
path,
preference
routing,
it's
because
I
keep
mixing
the
two
up.
It's
really
called
preferred
path
routing.
So
let
me
start
by
giving
a
quick
overview.
Some
of
you
may
have
seen
this
work
token
about
in
LSR,
but
not
everyone.
So
PPR
provides
a
method
of
injecting
paths
into
a
specific
arts
into
a
link
state
IGP.
In
the
data
plane,
the
packet
is
back
to
its
intended
path
by
its
PPR
ID.
K
So
it's
an
identifier
on
the
planter
front
of
the
packet
that
says
what
the
path
is
and
then
it's
up
to
the
forwarders
pp.
The
PPR
ID
is
a
single
identifier,
that's
put
in
the
packet,
so
it's
just
the
name
of
the
path
and
the
format
will
be
data
plane
specific.
So
this
is
a
technology
that
can
support.
K
Ipv6
addresses
ipv4
addresses,
MPLS
labels
and
also,
if
you
want
to
MAC
addresses,
if
you
want
to
apply
this
technology,
for
example,
to
trill
or
link
state
bridging
or
something
there
was
an
interrupt
for
PBR
yesterday
at
the
hackathon.
So
how
does
it
work
say?
I
want
to
send
a
packet
from
A
to
B,
to
C
to
D,
that's
not
the
shortest
path.
K
K
K
So,
first
off
I'm
going
to
consider
a
simple
basic
link:
repair
I've
got
the
this
sub
technology
here
a
b
c
d
is
the
prover
is
the
path
I
want
to
go
and
I
need
to
deal
with
an
incidence
of
the
breakage
of
the
length
of
bc.
So
the
first
thing
I
do
is
to
assign
a
PPR
ID
to
this
repair
or
call
that
C
Prime
and
then
I
set
up
the
path
that
I
want
the
packet
to
follow.
K
If
it
bc
failures,
the
path
is
going
to
be
from
B
to
e,
to
F,
to
G
and
then
on
to
C
note
that
this
could
be
any
arbitrary
path
that
I
wish
to
construct
for
any
policy
reason
that
I
wish
to
construct
it.
So
what
they
do
is
I.
In
cap,
the
packet
to
C,
Prime
and
I,
push
it
from
B
to
E
and
started
on
its
journey,
and
it
will
follow
the
repair
required
repair
path
now
could,
of
course,
terminate
this
repair
path.
K
K
K
So
we
don't
need
to
do
the
targeted
LDP
stuff,
but
if
we
can
adopt
that
sort
of
approach,
note
I'm
thinking
of
just
using
that
to
steer
the
packet
they're,
not
a
full-blown
sr
solution,
node
repair.
So
this
is
well
known.
You
have
to
treat
a
node
repair
as
K
minus-1,
separate
failures.
You
have
to
also
repair
to
the
note
itself
in
case
it
was
a
link
failure.
Each
of
the
repairs
can
follow
again
any
required
policy
that
you
want
it
to
follow
and
you
can
have
multiple
repairs
if
from
a
particular
node.
K
So
in
this
little
sub,
topology
I
have
a
traffic
engineered
path,
ABCD
and
that's
where
my
primary
path
is
and
I
create
a
traffic
engineered,
backup
path,
a
efg
today
and
what
I
do
is
I
construct
some
connectors
from
the
traffic
engineer
from
from
the
main
traffic
engineer,
path
to
the
repair
traffic
engineered
path.
So
I
can
join
that
part
that
a
number
of
stages
and
the
reason
I
do
that-
is
that
it
minimizes
the
amount
of
paths
I
have
to
inject
into
the
network
and
minimizes
the
calculation.
K
So
in
this
particular
case,
if
any
of
a
b,
b,
c
or
c
d
fails,
then
I
have
a
short
path
that
takes
me
into
a
traffic
engineer,
backup
path
and
I
what
the
sort
of
traffic
I
would
want
to
put
on.
This
is
traffic
with
a
critical
SLA
that
must
use
fr,
are,
for
example,
altra,
low
latency
or
up
to
reliable
traffic
or
some
IOT
slice
or
high
bandwidth
traffic.
That
I
don't
want
to
go
near
the
best
effort,
because
it's
going
to
damage
my
normal
traffic.
K
So
we
can
make
this
a
bit
easier.
So
there's
a
draft,
that's
also
in
LSR
that
describes
the
construction
of
PPR
grants,
and
what
happens
here
is
that
the
the
T
Ovie's
describe
a
graph
as
a
series
of
lists
of
and
the
anode
can't
figure
out
where
it
is
in
this
graph
and
forward
the
packet
accordingly
in
the
graph,
any
note
may
be
a
source,
but
we
have
to
note
that
a
graph
that
a
node
is
a
potential
source
with
the
S
bit
mechanism
and
there
isn't
in
the
PLF
alien
solution.
K
So,
let's
look
at
our
simple
graph.
We've
seen
this
topology
before
the
key
difference
is
that
the
repair
is
constructed
as
a
single
graph,
so
the
graph
with
the
PPR
ID
of
D
Prime
has
got
three
sub-links
in
if
you
like,
or
three
sub
paths
in
it,
the
one
a
the
one,
EF
g
d
and
then
the
one,
a
the
1
B
2
F,
and
the
one
C
2
G
notice
that
all
the
sources
are
marked
with
the
s
bit
in
the
PPR
syntax,
and
there
is
only
one
destination
which
is
d,
prime.
K
So
we
do
exactly
what
we
did
before.
If
any
of
the
paths,
a
b,
b,
c
or
c
d
fail,
we
inject
the
part
of
the
packet
into
the
PPR
graph
and
it
will
arrive
at
D
Prime,
and
this
is
useful
both
in
the
traffic
engineer
case
and
actually
in
the
best
effort
case,
because
it
it
produces
a
more
compact
representation
of
the
of
the
repair
and
that
we'll
see
in
a
moment.
K
So
Ilia
may
recognize
this
graph.
This
is
from
RFC
7812
and
I'm
going
to
look
at
how
we
would
construct
a
maximally
redundant
tree
using
this
technology.
So
if
you
recall
a
maximally
redundant
tree
is
a
method
of
getting
a
packet
through
a
repair
where
you're
going
to
do
your
best
shot
at
having
two
paths
which
are
redundant.
But
if
you
can't
find
two
fully
redundant
ones,
you
don't
care,
that's
the
best.
You
can
do
so.
Look
at
the
two
connected
graph
here.
K
We
want
and
we're
not
constrained
to
having
a
uniform
algorithm
across
the
the
network,
which
was
one
of
the
constraints
of
the
MRT
approach,
and
so
we
can
actually
construct
easily
multiple
paths
each
according
to
policy
and
have
multiple
repairs
each
with
its
own
color.
Now
there's
a
much
richer
set
of
approaches,
particularly
when
we're
moving
into
the
world
where
we
need
to
worry
about
loss,
minimization
and
delay,
minimization
and
slices,
etc.
K
So,
let's
look
at
another
figure
from
the
MRT
RFC.
So
this
deals
with
the
case
where
there
is
a
constraint
that
C
and
G
and
the
link
between
C
and
G
are
a
single
point
of
failure,
and
we
can
obviously
what
we
can
by
demonstration
here
construct
the
MRT
pair
subject
to
the
SPF
constraint,
but
nonetheless
we
can
construct
it
using
whatever
policy
we
wish
to
apply
to
construct
the
graph.
K
Any
node
can
inject
the
PPR
path,
so
that
can
be
either
the
PLR
itself,
creating
its
own
repair
paths
or
it
can
be
an
SDN
controller
on
behalf
of
the
network,
constructing
managed
repairs,
multiple
nodes
can
inject
the
repair
for
redundancy,
so
I
can
multiply
connect
and
then
the
IGP
flooding
mechanism
will
strip
the
duplicates
and
make
sure
that
any
that
providing
one
copy
gets
into
the
network.
The
repair
gets
to
all
the
no
repair.
Information
gets
the
blue
nodes.
It
needs
to
get
to.
K
K
Pla
is,
of
course,
independent
of
any
other
repairing
techniques,
so
I
can
run
it.
Ships
in
the
night
and
use
it,
but
we
use
it
for
specialist
cases,
I
can
use
it
in
conjunction
with
classical
LFA
if
I
want
I
can
use
it
with
any
of
the
approaches
to
do
the
thing
that
it's
really
good
at
or
I
can
just
say.
Well,
why
don't
I
just
have
one
approach
because
it
will
do
it
will
find
it
has
the
capability
of
finding
a
repair
in
any
joint
in
any
network.
K
That's
not
in
our
cut
set,
as
I
mentioned
earlier.
We
can
apply
it
to
multiple
data
planes,
the
usual
ones
NP
s,
NP
SS
are
IP,
ipv4,
ipv6
or
Ethernet.
Indeed,
I
can
apply
to
any
data
plane
in
which
the
topology
is
known
by
an
entity
capable
of
calculating
the
repair
paths,
and
it
requires
no
additional
data
plane
services
beyond
the
singles,
capsulation
and
decapsulation
of
a
packet
at
the
PLR
and
decapsulation
at
the
repair
target.
K
K
B
L
Good
morning,
everyone,
my
name,
is
Selena
comes
from
Hawaii,
and
this
morning's
presentation
is
the
new
protocol
name,
the
PAP
and
this
protocol
is
actually
to
help
the
existing
routing
protocols
to
that's
more
flexible
and
efficient
troubleshooting
method.
Ok,
so
before
I
introduce
the
detailed
information
about
the
new
protocol,
I
just
want
to.
Let's
talk
about
the
motivation,
why
we
needed
to
introduce
a
new
protocol
for
the
troubleshooting
of
the
whole
network?
Actually,
in
the
in
now
existing
network
a
world,
we
already
have
many
many
measures
to
troubleshooting.
L
One
direction
is
for
the
centralized
troubleshooting
such
as
we
can
use
Lib
to
connect
some
alarm
notification
and
so
on
to
our
centralized,
the
EMS
or
we
can
use
bianchi
protocol
to
connect
detailed,
BGP,
routing
protocol
information
to
the
centralized
Sdn
controller
and
the
EMS
our
centralized
controller
connector.
All
this
massive
information
it
can
analyze
the
relationship
hawke
of
this
information
and
to
find
the
route
fault
of
the
network.
So
I
can
we
can
we
can
see
if
you
use
the
centralized
the
troubleshooting
we
can
see.
L
The
the
advantage
is
very
clear
is
automatically
our
operator
just
to
sit
here
and
to
see
our
EMS
or,
as
the
in
controller
can
can
know
why
we
have
some.
Maybe
the
route
path
selected
wrong
or
maybe
the
configuration
is
wrong
or
anything
else,
but
it's
automatically,
but
the
disadvantages
career
also
because
we
won't
you
get
this
whole
analyze
result.
We
need
massive
information
from
the
equipment's.
L
That
means
we
can.
We
need
it,
connect
to
all
alarm
all
blocks,
all
maybe
protocol
informations
from
the
ever
equipment.
That
means
we
need
extra
cost
extra
bandwidth
cost
extra,
you
know,
scipio
cost
of
the
equipment
and
second,
very
big.
The
disadvantage
is
actually
the
lack
of
the
costume
and
information.
This
cross-domain
not
means
the
a
ass
to
me
or
anything
else.
Its
magnitude
to
man
magnus
even
won't
go
to
the
root
fortune
from
the
equipment.
L
We
need
this
equipments
managed
by
our
centralized,
DMS
or
centralized
eyes
in
controller,
but
we
know
the
route
from
which
we've
focus
open
for
PGG.
Actually,
maybe
the
14th
note
from
our
demand
maybe
comes
from
other
operators
and
so
on.
So
if
we
just
you
centralized,
we
cannot
get
this
information.
We
cannot
get
the
route
fault
of
this
BGP
is
passed
the
action,
so
this
is
the
advantage
and
disadvantage
with
the
centralized
troubleshooting
method
and
another
direction
is
distribute
to
all
semi
distribute
troubleshooting
methods.
L
L
If
this
routing
table
without
any
problems,
they
will
find
where
the
upstream
did
you
pee
speaker
or
anything
else,
to
log
into
another
equipment,
to
see
also
to
see
the
alarm,
the
notification
and
the
routing
table
information,
and
so
on,
and
one
by
one
to
get
the
route
fault.
So
we
can
see
this
distribution
method
is,
do
not
generally
act
extra
information,
extra
messages
to
the
from
the
increment
to
the
centralized,
the
EMS
or
or
all
controller.
L
But
we
also
need
to
very
high
experience
for
the
engineer
to
can
find
the
trouble
one
by
one
and
to
know
how
to
get
to
this
upstream
and
Latin
engineer
familiar
with
different
route.
Routing
protocols,
IDP
BGP
are
apt,
and
so
on.
So
this
and
also
the
same
challenge
with
the
centralized
the
troubleshooting,
because
he
needed
to
log
in
this
increment.
That
means
the
boundary
of
the
monument
domain
is
also
that
is
also
a
challenger
for
the
troubleshooting
or
the
route
troubleshooting.
Okay.
L
So
for
for
this
okay,
well,
for
these
challenges,
we
want
to
introduce
a
new
light
protocol
them.
The
PAP
protocol
assisted
protocol,
this
light
protocol
to
meet
all
these
challenges,
to
help
our
operators
to
reduce
the
experience
requirement
and
to
reduce
the
time
a
troubleshooting
time
for
the
whole
network,
and
this
this
new
light
protocol
I
mean
very
light.
That
means
from
this
protocol
we
will
not
be
exchanging
very
detailed
information
about
the
routing
protocol
or
about
some
alarm
sense,
or
are
we
just
too
extreme?
L
L
So
we
don't
need
centralize
the
server
to
connect
to
the
informations
so
and
they
we
don't
need
massive
information
from
the
commander
to
the
centralized
server,
but
actually
I
have
said
that
it's
a
light
protocol,
so
we
need
exchanger
a
little
more
additional
information,
but
the
data
information
is
not
too
much
so
the
bandwidth
and
the
Scipio
pressure
of
the
equipment
is
not
too
much
not
too
much
extra
cost.
And
another
thing
is:
this:
protocol
is
separated
with
the
acidity
the
porticoes.
L
L
The
FAK
is
for
the
additional
of
scenarios
for
some
special
scenario
to
exchange
the
information,
so
the
main
process
and
the
men's
messages
is
negotiation
and
request
to
reprise
messages,
and
we
think
for
because
this
for
troubleshooting,
it's
not
like
a
routing
protocol.
We
needed
soul
very
high
with
reliability.
So
we
think
the
UDP
is
enough.
L
If
this
PSP
carry
the
thought,
r3p
know:
okay,
I
am
the
I.
Am
the
fault
I,
have
this
fault
and
might
increase
failure?
So
I
repeat
he?
This
module
will
help
your
PAP
and
then
help
you
answer
this
request
to
the
ingress
equipment.
So
they
see
the
requester
on
the
reply.
Processor.
That
means
we
just
ask
a
question
and
the
PAP
speaker
will
answer
the
the
fort
note
will
answer
this
question.
L
M
Hi
Greg
nurse
qzt
I
think
that
it
would
be
interesting
and
beneficial
that
before
addressing
troubleshooting,
which
is
a
reaction
to
their
failure,
detection
is
that
you
discuss
how
the
tailor's
being
detected,
because
I
understand
that
questioning
something
from
your
peer
neighbor
or
for
upstream
is
driven
by
detecting
abnormal
behavior,
so
how
this
abnormal
behavior
is
detected
and
then
what's
done
because
first,
we
need
to
know
that
we
have
either
contact
continuity,
problem
or
quality
degradation
or
some
other
abnormal
behavior.
That
drives
us
to
conclude
that
there
is
situation
in
a
network
that
requires
troubleshooting.
M
L
So
I
think
your
question
is
how
to
detect
the
forethought
how
to
detect
the
problem.
I
I
think
the
PAP
is
just
a
protocol
generic
channel
to
each
other
equipment
to
let
them
can
exchange
the
messages.
But
how
about
this?
For
the
detective
is
based
on
the
traditional
existing
protocol,
such
as.
If
beauty
have
problems,
the
PGP
will
know
it,
and
then
that
means
that
the
PGP
hotel
are
PAP.
L
So
they
say
it's
the
ad,
the
protocol
that
means
PGP
or
how
these
PAP,
and
then
this
key
speaker
will
answer
the
question
to
the
requester
cagey
speaker,
so
this
PAP
pert
over
just
eighty
to
connote
they
do
not
to
do
anything
about
the
detective
or
anything
about
analyze
the
chance
to
give
the
channel
to
help
different
massive
different
protocols
can
exchange
the
troubleshooting
information
from
our
protocol.
It's
like
that.
So
it's
we
don't
touch
anything
about
the
detective
yeah.
N
N
What
I'm
going
to
suggest
is,
rather
than
inventing
a
new
mechanism
to
try
to
actually
troubleshoot
these
things.
I
would
suggest
instead
that
this
type
of
information
belongs
in
something
like
the
ITF
yang
model
for
that
protocol
or
an
augmentation
for
it,
something
that
actually
already
contains
state
relating
to
that
protocol
itself
and
that
existing
ITF
mechanisms
like
rest,
comp
or
maybe
Vegeta,
am
I
carrying
these
types
of
things
is
a
better
fit
so
I
agree.
This
is
a
nice
problem
to
work
on.
I
would
suggest
working
on
it
and
existing
models
that
we
have.
L
D
O
D
O
O
It's
two
different
scenarios.
Once
you
say
we
take
the
centralized
controller
out,
we
don't
want
it
or
we
have
a
mechanist
that
when
we
have
a
situation
in
the
network
when
the
centralized
control
is
not
working
in
the
entire
network,
a
portal
network
we
don't
really
like
need
to
rely
on.
You-
can
hang
go
to
the
situation
where
it
actually
comes
back.
P
Mr.
Romeo
way,
so
they
say
we
can
either
I
seem
at
least
commitment
or
centralized
solution.
Yeah
I
think
that
there
isn't
maybe
the
difference
in
scenario
yeah,
because
the
way
you
think
there's
a
centralized
solution,
I
have
the
benefit.
Okay,
you
know,
that's
the
our
the
tradition
of
the
myth
in
maintenance.
They
always
are
you
the
say
all
right.
That's
what
other
you
know.
That's
when
the
feeder
having
some
duluth
herb
butter,
this
video
happens
other.
O
Okay
and
then
I
think
I,
like
this
I,
want
to
I
want
to
look
at
it
a
bit
more
before
me.
I
have
one
further
question
in
BGP.
If
you
have
oscillation,
do
you
actually
know
that
you
are
the
source,
probably
a
question
for
BGP
people,
but
you
had
an
example.
Think
someone
responds
I
am
the
oscillation
source
and
I.
Don't
think
we
actually
know
we
are
just
behaving
at
the
total
process.
I.
L
Q
Regarding
this
PAP,
where
you
have
given
an
example
of
oscillation
right
to
identify
an
oscillation
source,
how
about
detecting
of
black
holes,
etc,
I
mean
when
you
cannot
even
forward
the
request
to
our
neighboring
router.
That
was
one
question,
and
the
second
was
in
this
case
also,
you
need
a
centralized
entity
to
initiate
and
to
get
that
report.
D
B
L
Q
L
D
So
next
up
is
Donald
Eastlake
talking
about
control
and
user
plane
separation
for
BMG
and
just
to
provide
a
little
bit
of
context.
For
this.
There
was
a
bath
at
the
last
IETF
the
because
both
discussing
how
the
IETF
and
the
routing
area
should
proceed
in
relation
to
this.
So
this
this
is
not
a
working
group
document,
but
we
have
a
pretty
liberal
policy
and
Archie
WG
about
presentation,
so
we're
not
say
working
on
this,
but
perhaps
Martin
would
like
to
just
provide
an
update
on.
S
H
Yeah
I
like
to
remind
the
book
that
this
presentation
doesn't
change
anything
about
the
statement
I
made
after
consultation
with
the
IES
tree
on
the
because
list,
which
basically
says
that
until
we
hear
back
from
BBF
who's
working
on
requirements
and
possibly
solutions
for
in
that
space,
that
there
should
be
no
work
to
progress
in
the
IETF
stream
and
that
decision
still
holds.
Thank
you.
T
S
So
this
is
intended
to
be
a
quick,
simple
presentation.
Mr.
an
update
on
the
status
of
the
draft
is
draft
name
is
given
here,
I'm
donald
Eastlake
from
future
way,
and
these
are
the
other
authors
of
this
draft
so
purposes.
I
did
give
a
gonna
give
a
brief
background.
This
in
case
of
people
who
aren't
aware
of
that
and
talked
about
very
briefly
on
the
relevant
architecture.
Would
yes,
cus
protocol
is
about
and
messages
it
has
and
mostly
talk
about
it
up
date
on
the
status
of
that
draft
s.
S
Cusps
stands
for
simple
control,
plane
and
user
plane.
Separation,
protocol
and
I'll
explain
what
that
means.
So
the
idea
is
you
have
a
broadband
network
gateway
which
is
providing
connection
between
customer
equipment
and
the
internet?
Usually
so
that's
authentication
and
accounting
and
all
kinds
of
stuff
like
that,
and
this
is
very
much
focused
on
the
fixed
network
rather
than
mobile
network,
so
I'm
not
talking
about
cell
phones
talking
to
cell
towers,
but
more
like
residences
or
businesses
that
have
fixed
network
connections.
S
So
this
is
a
very,
very
high-level
generic,
but
it's
useful
Yuval
found
to
be
able
to
separate
in
the
control
plane
parts
of
this
network
gateway
from
the
user
plane,
and
one
of
the
common
idea
is
that
you
can
put
the
control
plane
in
the
cloud
making
it
much
more
scalable
and
you
can
have
the
user
plane,
which
probably
has
the
highest
bandwidth
with
lots
of
bits
flowing
through.
They
implement
it
in
a
more
physical
fashion.
But
of
course,
that's
not
actually
a
constraint.
S
S
This
is
a
kind
of
a
more
detailed
explosion
here,
with
the
dotted
line
across
the
center
being
the
control,
plane
and
user
plane
separation,
boundary
and
those
triple
liner,
because
most
people
have
looked
at
this,
see
there
being
as
three
interfaces
a
management
interface
we're
using
that
confiden
service
interface,
which
is
kind
of
encapsulation
of
some
itraq
particular
control,
service,
initiation
and
control
stuff
doing
from
the
customer
equipment.
And
then
this
control
interface,
which
is
what
we're
talking
about,
might
need
a
a
new
protocol.
S
So
ask
us:
was
a
lightweight
extensible
protocol
design,
support
this
control
interface
for
fixed
networks
focused
on
that
runs
over
TCP.
It's
currently
in
production
use
at
over
a
hundred
thousand
customers,
and
next
year
expected
to
be
more
than
a
million
customers
actually
using
this
protocol,
and,
as
has
been
mentioned,
there
was
a
because
barf
at
IETF
104,
so
the
IETF
is
currently
awaiting
further
input
from
the
broadband
forum
and
a
number
of
liaisons
have
been
exchanged.
S
You
look
in
the
liaison
database
to
see
that
out
of
order,
if
you
go
back
to
the
previous
presentations
that
have
made
early
right,
you
have
some
of
those
have
pointers
to
the
liaisons.
So
I
guess
we're
anticipating
the
ova
feature
liaison
from
the
broadband
forum
and
not
expect
that
there'll
be
any
IETF
work
until
happens.
So
what
is
that?
The
change?
The
the
new
version
is
oh
six
of
this
protocol.
It's
a
lot
more
detailed,
it's
up
from
7,200
27
pages.
S
There's
been
a
reorganization
of
some
of
the
material
which
I'll
show
briefly,
and
the
additional
details
include
contents
of
the
messages
expressed
in
routing
backus-naur
form,
which
is
a
an
IETF,
a
no
exactly
a
standard,
but
it's
a
Nydia
specification
for
our
BNF
error.
Fields
in
various
messages
have
been
detailed
to
greater
extent
what
values
can
appear
there,
there's
a
expanded,
Security's
consideration
section
still
not
that
perhaps
super
big,
but
anyway
in
general,
it's
a
much
better,
much
more
detailed
draft.
S
So
somebody
who
was
interested
in
this
protocol
would
recommend
they
look
at
this
latest
draft
as
though
they'll
learn
a
lot
more.
Here's
how
the
core
specification
material
was
reorganized.
You
can
see
some
things
that
were
previously.
One
section
have
been
split
into
multiple
sections
and
some
previous
multiple
sections
of
income
line
new
organization,
it's
a
little
more
more
logical
and
straightforward,
and
just
to
give
sort
of
a
little
flavor
of
the
protocol.
S
A
couple
slides
here:
the
s
capiz.
Is
this
a
extensible
message
formatted
as
a
message
header
and
there's
t
all
these,
not
too
surprising.
Some
T
of
these
can
have
sub
TVs
in
them
it's
possible
to
for
vendors
to
construct
their
own
message.
It's
a
vendor
mess
specified
message
and
a
vendor
specified
TLV.
S
This
shows
the
the
message
header.
It's
got
a
type
and
a
message
length
and
transaction
ID
and
stuff.
It's
pretty
much
of
a
request
response
kind
of
protocol.
The
tle
header
format
has
a
a
shown
as
logically
having
this
operation
field
at
the
top
of
the
type
area,
you
can
sort
of
considered
that
to
be
all
the
one
in
sort
of
type
field
or
or
not
certain
tlvs
there's
an
operation
that
can
be
associated
with
the
t
Ovie's,
which
is
an
operation
being
performed
on
data
blocks
that
are
specified
by
the
within
that
TLV.
S
So,
and
here
are
the
different
categories
of
messages
as
they're
divided
in
this
latest
version
of
the
draft
and
the
various
different
categories
of
tlvs.
So
if
you
want
more
information
than
these
three
graphs,
you
should
read
the
127
pages
that
are
in
the
draft.
You'll
learn
a
lot
more
of
that.
So
that's
all
I
had
to
say.
H
H
S
Yes,
I,
don't
believe,
there's
any
intent
to
for
the
IETF
to
adopt
any
drafts
or
do
anything
here
ago
we've
heard
for
the
BBF
okay.
So
it's
reasonable
for
us
to
continue
posting
updates
to
the
forces
draft
I.
Think
anybody
who
can
post
graphs
that
they
want
that
they
think
or
have
interests,
and
they
think
that
people
would
like
to
read
yeah
all
right,
we'll
post
an
update,
then.
D
D
T
So
again,
I'm
the
ietf
liaison
manager
to
the
broadband
forum,
so
I'm
speaking
with
that
hat
on
just
to
give
you
an
idea
of
the
work
that
was
started
as
a
result
of
the
B
Kozlov,
the
work
in
the
BBF
is
progressing
well.
The
work
there
is
known
as
WT
4:59
disaggregated
bng
and
you
should
be
able
to
find
a
line
item
on
it
in
the
BBF
work-in-progress
page.
T
Basically,
what's
there
is
the
equivalent
of
a
working
group
document,
it's
well
underway.
It
contains
the
architecture,
the
use
cases,
protocol,
functional
requirements
and
functional
model
requirements.
So
it's
fairly
comprehensive
document.
The
scope
of
the
work
is
the
set
of
functions
that
are
currently
supported
by
BN
G's
today,
so
not
just
completely
fixed,
but
also
dealing
with
mobile
and
mobility
integration.
T
The
document
does
not
get
into
protocol
design.
We,
the
BBF,
made
sure
that
that
was
something
that
was
designed
as
otoscope,
but
rather
it
sets
the
stage
for
protocol
selection
either
this
protocol
that
Donald
presented
or
others
there
are
others
out
there
and
also
and/or
protocol
design
where
gaps
are
found
or
a
whole
new
protocols
needed
they've
taken.
The
output
of
the
beacause
ball
very
seriously.
U
U
U
For
the
challenge,
one
is,
as
we
know,
in
real
network,
especially
in
metro
network.
The
traffic
is
always
heavily
unbalanced,
just
as
the
figure
shoes,
some
things
are
highly
overall
did
well.
Some
links
may
be
very
light
loaded,
so
the
result
is
the
whole
network.
Throughput
is
remain
a
very
low
level.
U
Huge
risk
of
natural
resources
and
current
technologies
such
as
ecmp,
cannot
handle
them
very
well,
because
the
SMB
doesn't
care
about
the
real
situation
of
congestion,
either
on
the
local
links
or
on
the
remote
links
and
for
for
the
use
EMP,
which
involves
in
the
centralised
calculation
of
the
multiple
pass.
The
controller
will
specify
ratio
of
the
multiple
paths,
however,
in
data
plane,
because
especially
for
the
segment
road
in
technology,
is
get
a
plane.
There
is
no
actual
technology
to
guarantee
and
get
a
plane
ratio
aligned
with
the
space.
That's
specified
ratio.
U
Data
first
challenge
the
challenge:
to
is
that
for
some
general
considerations.
As
we
know,
some
natural
network
are
actually
evolving
to
more
DC
like
architecture,
so
within
this
context,
for
example,
the
cloud
migration,
this
factor
will
cause
the
traffic
to
be
more
difficult
to
plan
or
to
predict
now
for
some
specific
considerations.
U
If
we
look
into
the
traffic
in
a
very
finer
granularity,
for
example
in
in
milliseconds,
although
the
current
traffic
planning
technology
can
make
sure
the
traffic
is
okay
in
the
in
a
longer
interval,
but
with
a
much
lower
interval,
it
is
still
a
very
serious
problem.
This
is
also
why
the
Chinese
one
existing
okay,
so.
U
Thank
you
so
to
address
those
challenges
we
proposed
any
solution.
I
can
solution,
so
the
essential
idea
is
to
allow
very
fast
and
the
continuous
measurement
became
inquest
and
egress
rotors,
and
before
this
we
still
rely
on
the
controller
to
calculate
multiple
paths
for
each
pair
of
ingress
and
egress
rotor.
This
could
be
done
in
much
slower
interval,
for
example,
minutes
or
even
longer
days.
U
U
In
order
to
do
this,
the
ingress
rotor
need
to
sense
the
flow
size
so
that
a
top
end
flow
will
be
recognized.
This
is
something
done
totally
within
the
rotor
and
note
that
the
action
solution
only
requires
the
ingress
and
egress
rotor
to
be
enabled
with
such
mechanism.
The
intermediate
router
doesn't
need
to
do
anything.
U
And
next
my
please
thank
you
and
with
the
same
suit
all
core
technologies,
but
with
four
different
purposes.
We
can
come
up
with
three
use
cases.
The
first
one
is,
of
course,
the
network
load
balance,
but
it
is
a
guaranteed
balance
for
this
one.
We
already
have
a
commercial
wrote:
hardware,
water
based
prototype,
I,
briefly
introduced
indenter,
slides
and
the
second
one
is
for
the
SRA
assurance
for
some
very
high
priority
services.
U
This
resulting
may
be
not
very
balanced
to
traffic,
but
to
make
sure
the
most
important
flows
can
be
guaranteed
with
the
SLA.
The
third
one
is
the
have
a
bit
higher
building,
because
the
measurement
itself
intrinsically
supports
the
BFG
like
functions
and
can
even
do
more
and
the
most
advantageous
is
that
there
is
no
complex
configuration
for
the
account
as
the
PFD
requires,
and
the
I
Cameron
cannot
come
not
only
to
the
on
all
government,
but
also
the
service
degradation
measurements.
This
is
also
advantageous
than
the
tradition,
ampere
field.
U
U
U
Sorry
we
got
a
pod
ELISA,
as
you
can
see
the
topology
there's
the
AIDS
rotor
and
we
used
the
traffic
generator
to
push
the
traffic
into
the
network
and,
according
to
the
physical
capacity,
the
network
should
be
handled
up
to
80
gigabyte
per
second
traffic,
with
the
tradition,
SMP
technology,
when
the
traffic
is
up
to
48
or
at
most
50
gigabytes.
There
is
packet
drop
happening,
but
with
the
ICANN
system
enabling
the
throughput
can
be
reached
to
61
to
65
in
abet,
which
is
30%
engine
throughput,
your
car
could
resort.
U
V
Emission
from
juniper,
because
in
your
example,
you
there's
only
one
ingress
router.
So
that's
not
a
typical
in
case,
if
you
add
more
ingress
routers
to
the
network
and
then
let's
say
assume
that
these
ingress
router
react
to
congestion
at
same
time,
right,
yeah,
yeah,
sure
it
does.
There
will
be
a
base
condition,
and
you
know
yeah.
U
V
U
U
W
W
Your
flows,
when
you
get
microburst
situations,
you
can't
handle
it
but
part
of
the
situation.
The
solution
involves
a
controller
to
calculate
these
paths.
Now,
depending
on
the
microbe
Anderson,
the
frequency
is
microbrews.
You
might
be
wasting
a
lot
of
cycles.
You
know
trying
to
react
to
these
microbursts
and
actually
have
these
paths
being
deployed
and
by
the
time
they're
deployed
a
useless,
so
I'd
be
curious
to
see
in
the
solution
how
you
would
handle
timing
in
terms
of
those
Microverse
yeah.
U
Yeah
yeah:
that's
exactly
the
one
of
the
most
motivation
of
why
we
start
this
work.
You're!
Absolutely
right!
For
the
controller.
It
is
almost
impossible
to
handle
the
macro
curse
intervals,
so
we
allow
a
very
fast
merriment
directly
on
a
data
plane
in
our
implementation.
The
egress
rotor
will
feed
back
some
Merriman
results
every
three
point:
three
milliseconds
and
then
the
ingress
rotor
will
calculate
and
do
the
traffic
adjustment
every
10
millisecond.
That's
our
current
implementation
and
it
can
handle
the
necro
post
farewell,
but
in
still.
U
X
X
U
Y
U
Yes,
the
pecking
order
issue
and
the
oscillation
issue
basically
is
to
based
on
the
flow
let
and
if
there's
no
flow,
let
the
water
will
false
or
follow
that
that
will
break
the
flow
into
two
parts.
The
further
part
will
go
into
a
high
priority,
cooing
in
the
rotor
to
make
sure
it
will
be
forwarded
as
fast
as
possible
and
the
back
end
of
the
flow
we'll
get
into
slower
a
longer
QE
that
to
make
sure
the
two
packet
will
transfer
in
time
interval.
U
B
U
Yeah,
the
current
draft
is
only
a
skeleton
of
the
whole
story
and
because
these
are
the
first
hand,
we
present
the
whole
idea
in
our
community.
We
want
to
get
feedback,
especially
from
operators.
Do
you
think
this
is
a
valuable
work
to
do?
Do
you
think
it
is
meaningful
for
your
real
network?
You
want
to
improve
your
your
transmission
quality,
especially
in
Action
Network.
U
B
R
Good
morning,
everyone,
my
name,
is
Rosa
rockweed,
on
behalf
of
my
co-author
or
myself,
I'm,
going
to
present
this
new
draft
regarding
5g
transverse
wise
connectivity
interface.
Before
going
through
this
draft,
it's
important
to
note
that
there
has
been
a
net
project
at
BBF.
It
has
been
accepted
few
weeks
ago.
R
It's
related
to
this
area
and
I
already
talked
to
Dave's
in
a
crop
and
others,
and
it's
under
discussion
how
this
fork
and
B
bf4
can
collaborate
with
each
other,
how
they
complement
each
other
and
whether
or
not
there
is
a
synergy
between
them
and
how
it's
going
to
work.
So,
basically,
this
is
ongoing
discussion,
I'm
part
of
the
BBF
as
well,
but
it's
important
to
note
that
the
at
the
end,
these
two
should
work
together
and
basically
provide
a
bigger
picture.
How
ITF
and
BBF
can
work
together
to
define
this
interface?
R
The
name
is
different
at
BBF,
but
the
concept
is
more
or
less
the
same.
This
work
is
related
to
5g
Antoinette
worker
slicing.
This
picture
try
to
depict
the
whole
idea
of
the
five
unit
focus
slicing
and
how
they
work
at
idea.
It
basically
relates
to
that.
The
console
net
forget
slicing
in
this
picture.
You
will
see
from
the
left
right.
The
PowerPoint
presentation
is
better.
It
has
the
animation,
but
anyway,
here
I'm
trying
to
explain
from
the
left
to
right.
There
are
few
tenants,
BMW
fear
public
safety.
R
There
are
tenants
or
customers
which
basically
want
to
have
logical,
independent
network
from
the
left,
which
is
the
UE
all
the
way
to
the
right,
which
is
the
application.
We
call
each
of
these
logical,
independent
network.
The
end-to-end
net
focus
lies
in
this
picture,
I
have
five
net
focus
lies
and
each
color
you
can
think
of
the
SLA.
R
For
that
a
specific
end-to-end,
the
network,
a
slice
we
want
to
have
each
of
these
into
a
networker
slides
we
meet,
ran
a
slice
personality
on
ran,
we
meet
chorus,
lies,
personality,
encore
and,
at
the
end
we
need
connectivity
between
their,
which
is
basically
the
discussion
of
this
topic.
Transfer
the
slide
transfer
slides
are
the
logical
connectivity
between
various
components.
So
each
of
these
ran
call
transport
needs
a
controller.
R
It
needs
a
controller
to
basically
control
the
connectivity
that
is
needed
and,
at
the
end,
for
the
end
to
a
network
of
slides,
we
need
a
refrigerator.
The
topic
of
our
discussion
is
specifically
in
this.
Discussion
is
transverse
lies
and
how
it
relates
to
whatever
enter
whatever
IETF
already
has
on
how
we
can
work
together.
So
this
is
basically
to
create
one
of
those
into
a
network.
A
slice
click
one
of
them
in
the
previous
picture,
and
here
I
try
to
basically
show
the
logical
steps.
R
These
are
not
by
any
means,
a
specific
read
your
steps,
as
I
put
it
in
the
yellow
node,
but
it's
the
kind
of
logical
steps
from
the
customer
portal.
All
the
way
to
the
network
from
customer
portal
sends
a
request
to
end
to
a
network
as
like
a
company
the
why
I
want
to
create
a
type
of
service
with
a
specific
SLA,
and
it
goes
to
orchestrate
or
orchestrate
or
creates
a
profile,
and
then
it
goes
through
some
decomposition,
as
the
name
suggests
Dave,
you
have
a
question
yeah.
T
R
Latter
one,
it
could
be
a
set
of
functions
that,
as
you
will
see
as
I,
go
through
it
it.
This
interface
addresses
three:
the
functions,
automation,
aka
creation,
monitoring
and
assurance
analytics
and
optimization.
Whether
or
not
we
need
one
interface
to
address
these
three
or
we
need
three
or
more.
Basically,
this
under
discussion,
in
my
opinion,
I
think
it's
a
multiple
interfaces.
Ok,
the
address
so.
R
R
Four
and
five,
which
comes
to
ram
controller
and
core
controller
respectively,
are
defined
in
various
technical
specification
on
3gpp
and
interfaces
is
basically
the
discussion
of
this
meeting
that
we
want
to
have
similar
interface
for
transport,
which
basically
aligned
with
3gpp
interface,
four
and
five,
how
we
can
define
interface,
six
and
how
this
relates
to
our
ITF
fork
that
we
already
have
various
various
data
models
and
work
that
has
been
done
at
ITF.
How
this
interface
relates
that?
Basically,
this
is
the
topic
of
this
discussion.
R
I
put
it
in
red
here
to
just
clarify
that
we
talked
about
transport
SMS
creation,
but
that
one
should
be
addressed
every
time
that
we
talk
about
transfers
like
we
have
to
think
of
an
end-to-end
Network,
a
slice
that
I
want
to
create
in
the
network
as
a
result
of
that
I
need
to
create
transport
ran
and
code,
yet
then
go
ahead.
Why
do
you
create
two
separate
transport
slices?
And
you
know
you
have
like
a
5
g
TS
each
and
then
it
goes
to
the
third
party
controllers.
It
creates
another
transport
transfer.
R
A
slice
is
a
set
of
connections.
For
example,
in
this
specific
topic,
the
right
one
is
addressing
connectivity
between,
ran
and
call
the
left.
One
is
addressing
the
connectivity
in
ran,
because
this
is
a
cloud
run
between,
for
example,
vu
and
see
you.
So
basically,
your
endpoints
of
connectivity
are
different
in
the
first
one
is
to
call
the
second
one
is
inside
the
rent
equipment
between
C,
U
and
vu.
So,
basically,
since
we
have
different
end
points,
we
have
different
transfers
and
I
put
transfer
slices.
R
There
is
capital,
it
means
that
this
is
not
one
connectivity
if
I
have
ran
one.
Two
three
I
want
to
connect
it
to
call
one
two.
Basically,
the
set
of
connection
that
I
have
to
do,
and
basically
this
is
the
whole
idea
of
this
picture,
show
so
long
story
short.
We
are
discussing
their
red
item
in
this
picture
and
how
it's
related
to
idea.
So
these
two
picture-
I
put
it
there
to
make
sure
we
clearly
see
whatever
we
want
to
do
here,
is
really
related
to
3gpp.
R
On
the
left
hand,
side
top
left
it
any
document
that
you
open
from
3G
15.
You
see
this
picture
and
in
this
one,
basically
the
transfer
a
slice
of
connectivity
are
our
dash
line,
but
we
shall
not
basically
define
an
3gpp,
and
the
whole
intention
is
that
the
yellow
box
that
I
put
there
transfers
life
is
basically
defining
on
dashed
line
that
from
3gpp.
D
R
The
whole
idea
of
the
transfer
slice
is
defined
here.
The
name
is
different,
but
the
concept
is
the
same.
So
the
short
summary
of
these
three
slides
are:
we
want
to
define
an
interface
between
transfer
the
slice
controller
and
top
Orchestrator
to
basically
align
whatever
we
want
for
a
tree
for
a
transport
similar
to
the
run
on
cup.
So
this
is
basically
the
summary
of
this
presentation
and
this
draft
in
this
picture,
I
try
to
put
together.
R
There
are
top
Orchestrator,
there
are
three
controllers
left
is
red
right,
its
core
and
the
middle
east.
Sometimes
you
take
a
look
at
the
3gpp.
They
call
the
controllers
that
we
are
referring
to
ran
and
transfer
and
code.
They
call
it
and
ssmf
network
sub
slice
management
function,
but
it's
basically
the
same
idea.
The
important
aspect
of
this
picture-
I
finished
it
and
I
go
today,
is
trying
to
mention
that
the
functionality
which
are
needed
for
each
of
these,
including
the
transport,
our
automation
or
creation,
monitoring
and
analytics
and
optimization.
R
T
R
T
T
R
As
I
go
to
the
next
slide,
I
clarified
that
one.
The
idea
here
is
this
interface,
similar
to
3gpp
our
technology,
agnostic
and
other.
What
how
we
are
implementing,
let's
say,
I,
give
you
an
example:
I
want
to
connect
in
the
not
very
simple
that
5g
or
4G
connectivity
I
want
to
connect
in
ODB
to
a
core.
R
The
connectivity
it
has
I
want
to
connect,
ran
to
call
and
with
a
specific
isolate,
my
latency
should
be
less
than
5
millisecond.
My
bandwidth
should
be
more
than
10
megabit
per
second.
How
this
one
is
implemented
in
the
network,
implementation
or
realization
really
doesn't
change
the
fact
that
I
want
to
connect
this
together.
I
can
connect
at
the
end
of
the
day.
I
can
connect,
grant
to
course,
through
some
routers
in
the
middle,
using
layer,
3,
VPN
or
I
can
simply
use
rocket.
R
Vpls
connectivity
of
layer
through
lavatory
the
connectivity
is
the
same
implementation
and
realization
is
different,
and
this
is
one
of
the
item
that,
in
my
opinion,
should
hold
to
make
sure.
For
example,
we
are
separating
the
implementation
from
the
definition
of
that,
and
this
is
basically
that
abstraction
layer
that
is
created
how
I
can
implement
the
need
for
network.
Maybe
in
the
future
there
is
a
new
way
of
implementation
of
light
or
layers
3
services
in
the
network.
It
should
not
change
this
interest,
and
this
is
exactly
the
same
for
3gpp.
R
Those
interfaces,
regardless
of
how
is
implemented,
who
is
the
vendor
and
how
detail
is
the
implementation
of
random
code?
They
are
very
generic.
I
want
to
connect
of
any
creative
personality
for
networkers
life
with
some
estimate
focus
was
ID.
My
SLA
is
this
and
very
high
level,
and
this
is
basically
aligned
with
them.
So.
R
R
T
A
minute
switch
hats,
so
no
longer
Ericsson,
but
now
the
IETF
plays
I
manager
to
the
BBF.
What
si5
has
done
in
its
its
3gpp
sa
five
that
are
that
are
doing
the
asking
they've
set
out
a
widespread
liaison
asking
for
the
interfaces,
the
network
management
interfaces
that
can
be
used
to
facilitate
network
slicing
in
the
transport
level.
T
They
sent
this
liaison
a
belief
to
IETF,
although
I'm
not
exactly
sure,
but
they
they
sent
it
to
at
least
like
three
or
four
other
stos
that
are
well
known
to
be
involved
in
the
transport
space,
so
MAF
BBF
studied
with
15,
etc.
Each
one
of
these
groups
has
answered
that
liaison
with
what
they
can
offer
in
terms
of
network
management
interfaces,
so
the
the
I
what
I'm
hearing
resin
mention
is
that
the
target
interface
here
is
an
abstraction
of
all
of
these
different
management
interfaces
that
have
been
set
back.
That's
a
lot
and.
R
B
R
Q
Have
a
comment:
my
name
is
Uma
from
hook
feature
a
so
you
talked
about
end-to-end
slices
and
you
are
focusing
on
the
transport
part.
What
happens
if
a
microwave
link
between
the
ran
ran
interface
between
the
Ino,
TRG
node
P
to
the
Southside
router
goes
bad.
So
do
you
care
about
that?
What
happens
to
the
end-to-end
slicing,
so
your
transport
slice
is
good,
but
the
ran
interface
has
a
problem.
Like
you
know,
micro
link
is
bad
or
optical
is
not
good.
Q
R
Are
two
aspect
to
that
one?
You
know
we
can
have
a
slight
discussion
on
that.
One
is
when
we
are
creating
this
various
ran
core
and
transport
slice,
and
in
some
document
they
call
it
subs
or
they
call
it
submit
is
the
same
thing.
One
is
connectivity
between
them.
They
basically
don't
talk
about
that.
How
I
connect
rent
to
transport
and
transport
2-chloro
slices
to
have
that
real
end-to-end
from
the
data
path
point
of
view.
So
this
is
one
aspect.
R
Another
aspect:
if
you're
talking
about
how
I
can
make
sure
that
end-to-end
net
focus
lies
monitoring
and
assurance
Forks.
In
that
case
the
end-to-end
says
it's
not
working,
because
there
is
some
problem
with
the
read
and
how
that
will
translate
to
transport.
Maybe
they
have
to
change
the
transport
connectivity
or
they
have
to
it.
Should
the
change
there
are,
in
other
words,
in
this
picture.
Neither
rancor
and
transport
doesn't
understand
the
end-to-end
context
and
the
marks
aren't
at
the
top.
R
Q
So
the
one
more
comment:
actually
this
good
good
answer.
Thank
you!
So
much
so
we
have
put
a
draft
in
DMM
working
group.
Three
IDs
back
we
presented
and
we
have
been,
will
present
Nick
this
Wednesday,
which
talks
about
similar
area,
but
not
not
or
not.
This
actual
the
slicing
aspect,
another
end-to-end
here,
but
what
needs
to
happen
when
the
mobility
happens,
when
the
ue
in
the
5g
network
moves
from
one
gino
to
another
G
node
V,
but
the
transport,
the
end-to-end
slices
of
the
similar
SLA
cetera,
are
not
after
the
car
in
the
target.
Q
R
R
Issues
with
with
technical
service
model
developments
in
the
past
yeah
I,
don't
this
I,
don't
know
whether
or
not
this
is
the
right
and
the
place,
and
this
good
question
absolutely
and
I
want
to
see
whether
or
not
there
is
some
relevance
of
this
work
to
this
working
group
and
I
want
to
get
the
consensus
of
others,
but
this
is
a
good
question
and
I'm
looking
forward
to
get
the
answer
for
that,
so
I
have
a
few
minutes.
Let
me
just
finish
my
thought
here
and
after
we
can
take
questions
there.
R
So,
in
summary,
what
we
want
to
do
is
the
red
box.
Here
we
want
to
define
that
interfaces.
There
should
be
asked
here
to
address
three
things
and
all
the
time
you
have
to
think
about
that
three
thing:
not
only
the
creation
but
rather
monitoring,
analytics
and
optimization.
These
are
very
important
aspect
that
should
be
addressed
and
my
opinion
in
previous
discussions
or
some
other
draft.
They
don't
talk
about
these
to
us.
They
just
talk
about
creation
and
very
you
think
that
can
happen
so,
but
we
have
two
other
stree
at
the
same
time.
R
R
They
call
it
s
and
s
si,
but
it's
basically
net
focus
lies
ID,
fit
some
for
some
customers
on
the
service
info
service
service
infotainment
and
with
some
a
specific
SLA
to
create
that
yellow
connectivity
from
ran
all
the
way
to
core
orchestrate
or
which
is
sitting
at
the
very
car,
creates,
ran
and
called
the
also
it
create
the
transport.
Our
discussion
is
a
transport,
and
these
are
the
choosing
a
step
two
and
three
please
to
entry.
R
In
my
opinion,
this
picture
is
basically
shows
how
this
work
is
relevant.
To
idea
number
one
is
abstract
connectivity
requires,
which
is
sitting
on
top
of
number
three,
which
are
existing
IETF
models
for
various
tunnels,
paths
and
services,
and
basically
this
is
the
relevance
of
this
world
to
IETF
giorgos.
Please.
Z
Z
What
I
wanted
to
say
is
that
these
two
activities
will
be
somehow
related
and
already
what
Reza
meant
already
an
important
point
is
to
identify
what
are
the
activities
that
the
BBF
should
do
on
this
area,
because
that
interfaces
as
another
name
is
the
transport
network.
Slice
instance
interfaces
and
here
is
up,
give
another
name,
but
we
have
to
somehow
synchronize
that,
but
it's
important
I
think
there
will
be.
You
know
some
activities
that
need
to
be
done
and
DBF
others.
Z
R
You
for
yeah,
we
will
have
a
discussion
to
have
exactly
as
giorgio
smashing,
and
basically
this
is
a
last
slide,
so
we
need
to
have
more
review
discussion
by
didn't
put
it
here,
but
discussions
between
us
and
BBF.
We
have
to
address
in
more
detail
the
optimization
assurance
of
an
automation
and
finding
the
information
model
for
that
with
the
requirements,
and
hopefully
the
next
ITF
addressing
those
and
also
the
discussion
that
we
have
at
the
PDF
I
hope
this
one
was
clear
and
that's
it.
This
is
the
presentation.
Thank
you
go
ahead.
Thank.
T
R
In
my
opinion,
that
the
again
this
is
something
that,
at
the
end
of
the
day,
maybe
we
have
to
do
only
one
of
them
so,
but
at
this
time
the
way
that
I
see
it
is
we
can,
from
the
IETF
perspective,
we
can
have
to
define
the
requirements.
For
example,
we
need
for
the
various
technology
which
is
related
to
ITF,
for
example,
and
that
requirement
will
be
basically
the
implemented
for
the
value
of
the
young
model
that
we
want.
You
know,
for
example,
at
BBF.
R
There
are
two
activities,
one
is
defining
the
requirement
and
one
is
the
informational
model.
So
this
is
the
way
that
I
said
at
this
time,
but
again
the
discussion
that
we
will
have
in
more
detail
with
George's
and
others
from
the
BBF
will
clarify
that
one.
But
at
this
point,
I
guess
this:
the
way
that
I
said
if
George
wants
to
add
any
comments
and
if
he
says,
and
it's
more
than
whatever
I
mentioned,
please.