►
From YouTube: IETF112-RTGWG-20211110-1600
Description
RTGWG meeting session at IETF112
2021/11/10 1600
https://datatracker.ietf.org/meeting/112/proceedings/
A
Oh
okay-
and
you
can
hear
me
you're
like
good
morning
good
afternoon-
everyone
wherever
you
are,
welcome
to
idea
112.
and
we
are
opening
routine
working
group
session
for
idea
of
hundred
twelve.
So
for
a
change
to
the
city,
we
got
single
to
our
session
and
we
figured
out
that.
Probably
it's
still
not
enough
time.
We
have
to
decline
some
presentation
so
we'll
try
to
have
two
sessions
next
state
here.
A
C
A
A
It
has
been
paid.
A
lot
of
attention
to
sometimes
behavior
that
doesn't
belong
to
native,
would
like
to
remind
you
that
as
participants,
you
agree
that
you
will
walk,
especially
with
other
people.
You
don't
harass
other
people
and
while
we
don't
see
it
in
russian
working
group,
there
were
some
cases
where
it
did
happen.
Please
keep
it
this
way,
please
be
friendly
to
other
disrespects
and
all
the
documents
are
below
for
your
information.
A
So
idea
policy
requires
to
review
and
dislodge
intellectual
property.
That's
nfc,
8179,
routine
working
group,
specific
rules.
We
will
ask
you
to
disclose
apr
on
document
adoption
and
working
group
call
and
unless
all
authors
and
contributors
have
responded,
documents
won't
progress.
Please
remember
that.
A
So
agenda
for
today
is
we'll
have
updates
on
certificates.
Past
users.
Protection
apn
fox,
will
be
talking
about
changes
in
last
time
and
we
would
like
them
to
focus
on
explaining
what
changed
and
why
they
think
their
documents
should
progress.
A
New
work
is
related
to
satellite
communication,
as
well
as
cloud
through
optical
problems
and
cloud
network
integration
and
ppr.
As
part
of
a
larger
focus.
We
are
going
to
have
hpcc,
plus
plus
presentation,
which
is
talking
about
high
precision,
control
needed
in
large
data
center
networks,
potentially
applicable
to
routing
to
go
forward
and
then,
since
bbt
doesn't
meet,
we've
got
presentation
on
signal
degradation
from
this.
A
A
In
terms
of
existing
documents,
we've
got
qs
model
and
it's
being
reviewed
by
document
shepherd,
and
we
finally
reviewed
and
thank
you,
cultures
and
engine
working
with
cultures
of
removing
norm
is
retired.
A
To
answer
stewart's
question:
it's
up
to
you,
we
can
do
the
slides
or
you
can
up
to
you
will
let
us
know
so.
Klfa
the
str
brand
is
shepard
in
it
and,
although
still
need
to
address
all
the
comments,
ikn
bgp
had
been
requested
to
go
through
working
plus
call
will
start
reviews
next
week
and
the
services
protection
will
be
presented
today.
A
C
Juan
are
you
there?
I
don't
see
him.
D
D
C
D
D
Okay:
okay,
okay,
maybe
easier
for
you
to
just
upload
this
slide.
C
A
D
D
This
node
will
execute
the
behavior
of
a
mirror
sheet,
so
this
node
basically
will
decapitulate
the
package
through
removing
the
outer
ip56
header
and
then
forwarding
the
payload
of
the
package
using
the
forwarding
table
associated
with
this
mirror
sheet
to
distribute
the
payload
to
the
package.
So
this
is
very
simple
and
is
already
well
defined
for
the
underdog
dt6c.
H
K
And
my
question
is
related
to
the
work
that
being
discussed
in
spring
on
a
compressed
service
six
side.
So
because
there's
not
yet
final
decision.
Well,
there
is
a
decision
to
adopt
cc
proposal.
K
D
K
Yes,
I
agree
it's
probably
more
broad,
but
especially
since
authors
of
this
document
consider
asking
for
the
working
group
last
call.
I
think
it
will
be
good
to
have
the
compressed
srv6
sid
already
considered
and
addressed
in
this
document.
Rather
than
have
another
document
that
would.
L
Ac,
linda
my
cisco
systems,
given
we
have
some
documents
for
encoding
of
srv6,
we
have
one
that
is
even
further
along
than
this,
and
I'm
not
I
don't.
I
would
be
really
against
holding
them
until
the
whole
compressed
sid
thing
is
is
sorted
out.
I
mean
we
can't.
We
can't
wait
for
that.
L
It's
not
like
we're.
Gonna
have
compressed
sid
architecture
approved
in
the
next
before
the
next
ietf.
E
L
It's
fine
with
me.
I
just
don't
think
we
should
hold
up
any
work
unless
it's
on
sid
compression
for
the
com
agreed
upon
sid,
compress
in
architecture
from
spring.
E
C
L
I
I
took
I
took
lois
comment
to
me.
You
point
at
it
in
an
email
not
as
a
normative
reference
in
any
of
the
base,
srv6
drafts
or
drafts,
as
they
go
forward.
C
N
O
O
O
O
So
the
in
order
to
meet
this
this
demand
data
center
international
network
are
keeping
migrating
tradition.
Traditionally,
people
access
the
claude,
usually
by
using
ip
networks.
O
Alternatively,
we
believe
accessing
cloud
with
optical
networks
is
increasingly
attractive
at
the
and
become
an
option
for
for
user
to
access
cloud,
because
optical
transport
work
is
based
is
basically
based
on
on
tdm
and
time
division.
Multiplicing
mechanism,
so
it
don't
have
it
doesn't
have
the
the
turing
problem
and
the
time
perfect
avoid
package
congestion.
O
Okay,
okay,
I
see
now
thank
you
and
I
will
give
several
use
case
for
accessing
cloud
using
option
networks.
The
first
use
case
is
multi-cloud
sizing.
O
We
know
that
cloud
services
are
usually
supported
by
multiple,
interconnected
data
centers,
which
are
usually
basic
within
one
region:
space
the
facing
usually
100
kilometer
in
order
to
provide
active
to
active
or
virtual
machine
services
with
within
this
kind
of
distance.
O
So
so
data
send
this
central
service.
Yuri
demand
require
on
demand
and
the
stability,
high
reliability
and
the
user
based
building
et
cetera
this
kind
of
requirement.
O
For
example,
we
can
use
otl
networks
with
vpn
to
to
connect
multiple
cloud
clouds
together
and
we
we
have.
We
have.
We
have
the
odu
k
channel
in
between
to
connect
the
this
kind
of
clause,
and
perhaps
we
have
smart
measurement
under
control
systems
for
for
traffic
perception.
O
Okay,
the
second
use
case
is
high
quality
at
least
a
lot
high
quality
private
land
can
provide
a
lot
bandwidth,
low,
latency,
high
security
and
reliability.
O
O
Thus,
the
third
use
case
is
a
cloud
virtual
reality
and
we
know
that
the
user
experience
of
virtual
reality
likely
depends
on
the
local
dedicated
hardware
which
can
do
rendering
under
something
like
that.
And
if
we
move
the
the
rendering
function
from
local
hardware
to
cloud
side,
we
can
improve
the
user
experience
and
reduce
the
cost.
O
But
this
is
a
high
requirement
for
the
interconnection
between
user
side
and
cloud.
We
think
optical
networks
is
a
idea
approach
to
connect
the
user
and
the
clause
for
the
claude
virtual
reality.
O
For
example,
it
can
provide
a
large
and
sometimes
flexible
bandwidth,
for
example,
from
mega,
for
example,
from
tens
of
mega
bits
per
second
to
one
gigabit
per
second
and
the
low
latency,
for
example,
smaller
than
10
milliseconds
and
the
lower
jitter,
for
example,
smaller
than
five
milliseconds
on
the
next
page.
Please.
O
So
this
page
summarize
the
requirement
for
accessing
to
a
cloud
optional
networks,
so
optical
networks
with
vpn
can
provide
the
capability
of
multiple
to
multiple
cloud
access
and
actually
some
otn
equipment
has
adopted.
The
patient
processing
functions
such
as
packet,
switching
npr's,
vpn,
et
cetera,
already,
and
also
the
second
is
a
high
performance
and
high
reliability.
O
The
third
is
small,
granule,
larity
and
container,
and
it
can
be
tuned
flexibly
from
two
mega
to
one
gigabit
per
second,
and
this
can
improve
the
efficiency
of
the
network
and
also
option
network
can
provide
a
lot
bandwidth,
low,
latency
and
the
logiter.
O
O
A
O
And
to
my
understanding
so
first
I
think
we
should
evaluate
the
common
ground
of
my
my
proposal
under
the
previous
work
and
so
as
you're
stretching.
Maybe
we
can
it's
time
to
previous
work
and
merge
something
into
it
that.
A
M
Great,
it
seems
always
have
to
do
about
three
different
mics,
okay,
just
quick,
because
I
noted
this
is
also
being
presented
tomorrow
in
ccamp.
M
I
just
would
like
to
say
that
I
think
this
is
really
a
c
camp
document
as
it
is
addressing
otn
requirements,
and
I
would
just
like
to
say:
vpn
work
was
addressed
in
c
camp
quite
a
while
ago
2005.
M
So
if
any
gaps
are
needed,
they
can
address
that,
but
they'd
have
done
layer,
1,
vpns
already
and
there's
even
a
another
draft
rfc
on
rfc,
I
should
say
4974,
which
even
adds
more
sophistication
to
that
and
as
far
as
the
requirements
on
lower
switching
granularity
for
otn,
that's
not
an
ietf
discussion
that
should
be
done
in
study
group
15,
who
holds
the
rights
to
otn
technology,
and
it
is
quite
an
active
discussion
there.
M
So
the
if
you
need
requirements
on
lower
granularity,
you
should
be
going
to
study
group,
15.,
okay
and
then
to
tomorrow
for
further
discussion.
Thank
you.
O
Okay,
should
I
and
thank
you
for
your
very
good
question
and
for
the
your
first
part
of
your
question,
I
think
that
we
could
just
evaluate,
for
example,
the
gmpr's.
O
Need
to
be
adapted
or
changed
to
meet
the
new
new
requirement
for
the
accessing
cloth
with
optical
network,
for
example,
multiple
material,
multiple
claws.
So
maybe
I
think
there's
some
work
to
do
in
this
regard,
and
I
just
agree
that
osu
related
what
is
mean
they.
O
G
I'm
very
happy
to
see
the
draft
because
you
know
we
just
post
similar
drafts
in
ipv6
later
one
years
ago,
so
I'm
very
happy
to
see
that
and
we
hope
to
have
more
discussion
with
you,
the
co-orders
and
let's
see
how
to
move
the
world
together
in
the
future.
Thank
you.
A
P
Excuse
me,
charles
coming
from
actually
I
I
would
like
to
have
a
short
question
to
the
working
group,
because
we
see
the
two
existing
working
group
document
has
been
expiring
for
a
while.
So
we
are
curious
about
the
reason
and
to
check
who
is
working
group
if
we
still
have
a
chance
to
to
integrate
what
has
been
done
in
this
document
to
the
existing
one.
As
a
chair
suggested,
we
we
can
merge
some
of
our
common
requirements
and
work
on
separate
solutions
suggested
by
by
debra
in
different
working
groups.
A
I
So
can
you
hear
me
this
is
the
link
I
just
missed
the
last
call
from
insane.
I
don't
know.
I
Okay,
great
so,
should
I
share
my
screen
or
just
use
yeah.
A
I
I
This
is
my
presentation
is
about
satellite
network.
It
is
a
quite
new
area
and
the
satellite
network
is
a
complete
different,
just
networking
on
ground.
So
it's
a
quite
complicated
and
my
presentation
has
a
two
draft.
So
far
one
is
about
problem
and
statement.
Another
is
about
proposal
to
use
semantic
address
for
satellite.
I
Of
course
it's
not
complete
solution.
It's
just
a
tiny
step
to
propose
to
use
semantic
address
to
improve
the
id
routing
in
the
future,
and
I
have
presented
this
first
draft
in
the
inter
area.
Before
I
invest
its
this
time.
I
want
to
bring
it
to
a
logging
group,
since
I
think
the
routine
is
one
of
the
most
challenging
issue
in
cell
life.
Networking.
I
So
as
a
whole
objective,
this
tried
try
to
solve
the
routing
and
switching
issue
for
large-scale
satellite
concentration
network
for
internet
access
with
a
shorter
latency
and
the
global
coverage
and
the
right
hand
is
a
picture
for
the
starlink
phase,
one
satellite
network.
If
you
can
see
the
how
big
is
the
network
it
has
over
4000
satellites
and
right
now
it
launched
more
than
1500.
I
So
this
kind
of
consternation
is
made
from
the
new
altitude
satellites
500
to
2000
kilometers,
and
normally
it
has
a
couple
of
thousand
or
over.
Even
10.
000
satellites
and
into
satellite
link
will
be
used
to
connect
satellites
even
right
now.
The
even
starlink
has
not
started
yet.
It
only
does
it
in
some
experimental
and
the
satellite.
It
will
be
integrated
with
many
ground
stations
by
microwave
on
desert,
and
there
are
two
types
of
ground
station
ones
called
the
gateway
ground
station.
I
It
can
relay
the
traffic
from
satellites
to
another
satellite
and
also
the
ground
gateway
grants.
The
ground
station
is
connected
to
internet.
That's
why
we
can
access
the
internet
through
the
satellite
network
and
from
this
scale
a
lot
of
networking
will
more
have
more
than
even
more
than
10
000
grand
station
on
earth
and
another
type
of
ground
station
is
called
terminal
ground
station.
If
you
are
direct
connect
to
user
terminal,
just
like
our
wi-fi
router
and
it
may
be
able
to
do
really
as
well
as
suggest
by
starlink.
I
So
this
is
example
of
a
styling
plan
for
their
satellite
network
for
the
phase
one
it
has
four
shears.
A
shear
of
the
satellite
constellation
is
defined
by
same
the
satellites
with
the
same
altitude
and
same
inclination
angle.
I
With
the
such
dynamics,
we
can
see
the
satellite
network
topology,
keep
changing,
link
state
cost
change
very
frequently,
for
example,
link
cost.
If
we
use
the
satellite
distance
as
selling
cost,
then
it
will
keep
changing
and
the
cellulite
ground
station
link
it'll
also
keep
changing,
because
the
reachability
issue
and
the
it
will
have
an
interruption
every
two
to
three
minutes
for
450
kilometers
altitude
and
the
links
between
satellites
and
for
the
cell
launch
latitude
and
direction
links.
I
It
is
steady
because
the
relative
position
is
not
changing,
but
for
the
links
on
the
longitude
direction,
it
will
be
unsteady
at
the
polar
area.
I
will
show
you
later
and
it
will
have.
We
will
have
a
two
interruption:
every
cycle
for
the
satellites
for
this
kind
of
altitude,
the
every
one
and
the
six
1.6
hours,
satellite
removal,
a
circle
on
earth
and
also
the
links
with
satellites
moving
in
opposite
direction.
I
Unfortunately,
even
with
the
same
altitude,
the
satellites
adjacent
satellite
may
move
in
into
opposite
direction
and
for
this
kind
of
link
we
will
interrupt
every
three
to
four
minutes.
All
these
calculations
in
my
first
draft
and
for
vertical
link
with
a
different
altitude,
then
it
depends
on
the
altitude
difference
and
the
inclination
angle.
I
So
as
a
summary
cell
life
position
is
a
critical,
a
predictable
by
a
mass,
but
not
the
links,
because
the
link
ground,
for
example,
links
between
ground
station
to
satellite,
its
quality,
will
be
impacted
by
weather
and
obstacles
and
the
links
between
satellites
also
impact
by
tracking
technology,
because
the
they
will
use
a
laser
to
check
the
pier
and
definitely
not
be
hundred
percent
succeed,
and
also
the
distance
is
changing
and
position.
I
So
we
can
see
that
the
the
traditional
distributed
igp
bgp
mps
model
is
hard
to
use.
Why?
Because
we
will
have
a
convergence
issue
for
two
frequently
changed
technology,
and
we
will
have
a
constant
control
data
flooding
issue
because
of
the
new
topology
and
also
overhead
of
control
protocol
message
for
previous
in
the
satellite
link
bandwidth,
because
from
the
current
technology
we
can
only
have
about
10
gig
for
the
up
to
2000
kilometers
distance.
I
So
how
about
the
centralized
sd
model
because
master
itf
meeting
some
people
said
this?
There's
no
problem
for
this
stem
can
solve
it,
but
we
can
see
it's
it's
it's
impossible
because
we
will
see.
Where
is
the
controller
then?
Because
we
have
so
many
satellites
which
one
is
a
controller
satellite
and
what
is
the
basic
connectivity
between
controller
to
all
satellites?
I
I
The
first
draft
I
have
update
two
sections,
one
sections
analyze
the
adjacent
orbit
with
the
same
altitude
in
non-polar
area
and
the
polar
area
then
the
another
section.
I
have
a
detailed
analysis
for
the
estimation
of
communication
lifetime
for
satellites
on
adjacent
orbit
with
the
same
altitude
moving
on
different
direction.
I
So
this
shows
the
satellites
on
adjacent
orbits,
even
adjacent
orbits
may
move
in
the
opposite
direction
and
more
complicated.
Is
that
when
adjusting
orbit
moving
to
the
polar
area
that
have
a
crossing
so
as
a
whole,
the
there
are
four
type
of
cellular
links.
One.
Is
that
one,
the
two
non
latitude
direction
link
it
will
be
relatively
steady
but
for
the
other
links
or
may
be
interrupted
for
period
time,
for
example,
link
for
longitude
direction
in
only
a
steady
at
the
non-polar
area
at
the
polar
area
it
may
be
interrupted
depending
on
the
tracking
technology.
I
I
wish
you
one
and
unsteady
link
is
that
between
satellite,
even
on
adjacent
orbit,
but
with
a
different
moving
direction,
then
their
distance
will
be
changing
faster
and
so
the
lifetime
of
communication
it
will
be
shorter
and
the
vertical
links
is
between
the
satellites.
On
adjacent
orbit
with
a
different
altitude,
that
state
depends
on
the
difference
of
altitude
and
inclination
angle.
I
I
I
will
have
a
video
clip
at
the
end
will
be
easier
to
see
so
new
draft
new
draft
is
that
to
propose
to
use
a
semantic
ip
address.
It
will
embed
the
orbit
and
other
information
into
the
ip
address
so
and
what
to
embed?
We
have
proposed
the
five
index
owner
share
and
orbit
plan
index
and
seller
index
and
the
unit
interface
index.
I
Then,
why
we
do
this
first
benefit
is
that
we
can
make
the
link
identification
easier
and
faster.
We
don't
need
to
have
a
satellite
here
to
exchange
the
orbit
information
before
we
know
if
appear
is
kind
of
steady
or
unsteady,
and
also
it
can
make
the
symmetrical
routing
and
switch
possible.
But
this
one
is
not
described
in
this
object:
it's
not
mature,
yet
we
will
describe
update
material
so
how
to
use
this
semantic
address.
I
We
have
proposed
three
ways:
one
is
id
address
embedded
into
the
interface
identifier,
and
second,
is
that
embedding
to
the
neat
field,
but
with
a
shorter
lens.
Third
one
is
the
usually
does
a
variable
lens
ip
address.
Why
we
propose
this
because,
as
I
said,
the
satellite
link
bandwidth
is
suit.
Pressure
directly
use
a
1
28
bit
ipv6
interface,
maybe
too
much
overhead.
I
So
this
is
just
a
coding,
and
this
is
a
ipv6
embed
into
the
interface
identifier.
This
is
a
neat
field
and
of
course
it
will
have
a
shorter
field
for
different
index,
and
this
is
directly
used
as
a
ip
address,
but
with
shorter
than
one
connect
bits.
I
Of
course,
it
will
be
only
we
will
decide
the
exact
length
after
this
variable
length.
Ipfs
is
accepted
by
the
commun
community.
I
Here
I
show
the
examples
of
links
by
this
semantic
address,
how
to
distinguish
different
links
and
how
to
identify
the
step
status.
For
example,
if
we
see
the
peer
which
has
the
satellite
index
difference
is
one
that
means
it's
on
the
same
orbit
and
its
link.
I
A
I
Oh
sorry,
so
probably
I
I
just
stopped
here:
everyone
can
check
by
themselves.
A
Yeah
steven
shared
the
url,
the.
A
C
F
Sorry,
it
takes
a
couple
of
seconds
to
do
all
the
microphone
allowing
so
lynn.
At
the
very
beginning
of
your
presentation,
you
made
an
assertion
that
normal
link,
state
style
convergence,
normal
routing
conversions,
would
not
be
adequate
for
this
mark.
Handley
who's
well
known
in
this
community
did
some
simulations
quite
some
years
ago,
and
these
were
real
simulations
on
a
gaming
engine,
as
I
recall
for
the
whole
cluster
and
he
concluded
that
it
would
work.
I
Yeah
sure
yeah,
because
just
imagine
if
a
network
has
a
couple
of
thousands
raw
or
nodes
and
many
nodes
will
have
a
link
interaction.
Every
couple
of
minutes
and
for
this
kind
of
network
it
will
be
very
unstable
in
the
in
the
ground.
F
I
Yeah,
I
know
his
paper
and
I
know
his
simulation
it's
a
similar
as
I
I
used,
because
this
simulator
software
also
from
serve.
F
I
L
F
To
we
need
to
be
clear
what
the
real
parameters
are
and
deal
with,
that
from
position
of
knowledge
and
say
mark
was
very
convincing
that
he
thought
he
could
do
it.
A
Q
Hobby,
but
my
question
is
that
you,
this
use
the
thematic
address.
What
will
be
the
forwarding
table.
I
The
folding
table
is
a
is
because,
for
example,
if
you're
using
us
in
ipv6,
it
will
be
same
as
for
before,
but
the
problem
is
that,
should
we
use
the
folding
table?
That's
another
question
because,
as
I
said,
if
we
use
a
traditional
technology,
of
course,
we
will
use
the
forwarding
table.
But
if
we
we
want
to
use
some
new
technology,
you
may
not
be
able
to
use
the
folding
table.
Q
So
because
so
that's
either
just
my
doubt
so
so
I
mean
maybe
not
the
forwarding
table.
So
I
mean
what
will
be
the
forwarding
mechanism
for
this.
I
Yes,
yes,
that's
also,
I
yeah.
I
also
want
to
have
a
community
to
to
be
aware
of
this
challenge
and,
if
us
still
still
was
said,
the
traditional
technology
works
very
well.
Of
course
we
were
still
using
floating
table,
but
are
very
doubtful
about
that.
If
we
don't
have,
we
need
may
need
some
new
technology
to
make
this
work
perfect.
Q
Okay,
the
second
one-
I
think
this
is
the
will
be
the
research
work
or
this
is
some
of
the
working
group
work,
because
this
is.
I
Actually,
I
don't
know
right
now,
so
I
want
the
community
make
the
decision.
Finally,
because
I
see
some
research
work
but
think
about
right
now,
the
many
companies
already
try
to
deploy
this
network,
so
maybe
they
we
need
some
solution
quicker
quickly
to
to
to
to
provide
to
industry.
R
Hi,
so
a
very
quick
point
first
is:
I
think
this
is
a
man,
a
problem,
and
I
think
it's
would
probably
experts
in
this
area
contribute
to
the
money
working
group.
This
is
a
classic
moving
adjusting
network,
the
topology,
although
the
number
of
nodes
within
your
network
is
fairly
constant,
because
it's
there's
new
satellites
do
not
get
launched
that
often
or
they
get
launched
at
well-known
periods.
The
topology
itself
is
in
flux,
but
it's
influx
in
a
fairly
predictable
manner.
R
So
I
think
you
can
bound
the
problem,
and
I
agree
with
you
that
perhaps
the
approach
of
of
some
of
the
traditional
link
state
protocols
may
not
be
right,
but
I
don't
think
you
have
to
throw
the
forwarding
the
forwarding
table
concept
away.
I
mean
it's
a
fairly
basic
concept
on
which
we
pin
a
lot
of
ip
on
the
concept
of
a
forwarding
table
and
discarding
that,
I
think,
seems
like
a
big
step.
R
I
think
you
could
add
some
sort
of
contact
information
within
the
forwarding
table
to
say
at
this
moment.
Your
forwarding
should
be
going
this
way,
and
after
this
moment
it
should
be
going
that
way,
as
as
the
contacts
change
between
the
satellites,
but
still
that
is
deterministic
and
can
be
predicted,
but
anyway,
either
way.
I
think
this
would
be
a
good
topic
to
take
to
mani.
I
Yeah,
thank
you.
Thank
you
comments,
but
actually
your
idea.
We
we
we
did
think
about
that
way.
But
when
we
in
con
we
still
encounter
that
some
unpredictable
events,
for
example
some
adjacency
lost
then
distributed
way,
may
still
not
quick
enough
to
to
synchronize
all
that
base.
But
we
can
discuss
offline
because
it's
a
very.
R
And
that's
why
I
think
manet,
because
I
think
a
hybrid
approach
between
understanding
that
it
should
be
there
and
some
detection
of
whether
that
contact
is
there
or
whether
it's
yeah
yeah.
So,
but
this
is
the
sort
of
subject
that
many
deals
with
thanks.
Thank
you.
A
Lynn,
thanks
for
the
presentation
like
to
second
and
monet,
was
focused
on
solving
similar
problems,
lower
skills
so,
and
I
would
really
like
you
to
focus
on
trying
to
address
stewart's
comment.
They've
been
proposals,
they've
been
at
least
theoretical
proof
that
things
could
work
if
you
could
review
it
and
provide
the
information
would
be
very
valuable
for
the
first
discussion
and
thank.
B
Okay,
can
you
hear
me
yeah?
Okay,
thank
you.
I
am
wondering
here
in
here
from
china
mobile.
So
on
behalf
of
other
authors,
I'm
going
to
present
this
draft
the
cloud
and
network
integration
considerations,
so
ironic,
suggestions
and
discussions
are
welcome.
So
I
have
to
please.
B
So
the
motivation
of
this
contribution
is
first
analyze
a
trend
of
the
network
and
cloud
into
an
integrations
so
with
the
development
of
5g
and
the
internet.
First,
the
convergency
trend
of
cloud
and
network
is
increasingly
so
more
and
more
services
and
applications
will
be
carried
on
the
cloud
data
centers
in
order
to
support
new
services
and
applications
requirements
and
meet
the
security
and
also
the
delay
requirements.
B
So
the
deployment
location
of
the
edge
cloud
data
center
is
also
lowered
from
the
original
disease.
B
So,
in
order
to
avoid
new
construction
of
a
huge
cloud
transport
network,
we
consider
the
exit
existing
metro
network
to
use
to
access
hdcs
so,
for
example,
in
our
company
china
mobile.
So
we
use
a
5g
backhoe
transport
network,
which
is
an
iut
mtn
technology
to
access
httc.
B
So,
therefore,
the
access
point
of
the
enterprise
entering
the
cloud
is
usually
in
the
metro
network
and
the
dedicated
line
entering
the
cloud
also
involves
the
interconnection
between
the
cloud
and
transport
cloud
transport
and
the
metro
network.
I,
in
this
draft
we
describe
the
cloud
and
network
integration
scenarios
and
the
networking
technologies.
B
Okay.
Next,
please,
for
the
net
internet
working
scenarios,
there
are
only
two
scenarios:
the
multiple
domains
so
with
all
without
the
common
border
nodes.
Okay.
Next,
please.
B
B
There
are
independent
idp
instances
in
macro
and
the
cloud
transport
networks.
If
the
skill
of
the
metro
network
is
large,
it
will
be
divided
into
multiple
idps
and
for
the
conspiration
of
the
controllers,
they
may
have
different
controllers
or
under
the
same
superior
controller
like
the
orchestrator.
Also
okay.
Next,
please.
B
So
the
second
scenario
is
the
multiple
domains
with
without
the
common
border
nodes.
Also,
the
also
the
right
side
is
a
cloud
transport
network
and
the
left
side
is
a
macro
transport
network.
B
B
Okay,
so
next,
please,
so
we
can
consider
the
technology
for
networking,
depending
on
whether
the
lateral
domain
support
or
does
not
support
srv6.
B
The
first
networking
technology
was
a
metro
network,
does
not
support
srv6,
so
we
need
segment
splicing
of
the
different
network
technologies
to
use
to
achieve
the
end-to-end
connection
of
services
and
for
the
second
case,
is
some
nodes
of
the
natural
network
support
srv6
and
in
the
case
of
the
multiple
domain,
with
the
common
border
nodes
which
is
researched
in
the
spring
srv6
amps
interworking
draft,
it
can
be
used
to
achieve
the
interworking.
B
B
Also,
and
that's
the
piece.
B
So
about
is
our
considerations
on
the
cloud
and
network
integration
scenarios
and
technologies.
So
comments
are
welcome
for
us.
We
are
more
focused
on
the
case
that
the
multiple
domains
with
metro
network
and
the
cloud
transport
network
with
not
without
a
common
border
nodes,
so
they
connect
it
with
some
direct
links.
That
is
also
real
scenario
in
our
operators.
Networks
and
further
techniques,
technologies
should
be,
will
be
considered
more
and
hope
to
see
some
comments
on
that.
Okay,
so,
thank
you.
That's
all.
I
G
G
And
hopefully
we
can
have
more
cooperation
in
the
future
and,
as
you
know,
that
we
have
post
a
draft
last
year
about
the
network,
a
cloud
network
inter
creation,
recorded
ipv6
based
cloud,
oriented
networking
and
released
a
list
of
the
requirements
and
salute
and
associated
solutions
in
the
draft,
and
I
have
post
the
link
in
the
chat
box
and
you
can
take
a
look
and
we
can
have
more
discussion,
apply
to
to
take
a
look
at
how
we
can
make
cooperation
further
yeah.
A
A
G
B
F
Don't
have
any
questions,
no
okay,
so
preferred
path
of
routing
next
slide.
Please.
F
Right
in
in
this
talk,
I
want
to
do
two
things.
I
want
to
give
a
two
slide
reminders.
Close
revision
of
what
ppr
is,
and
then
I
want
to
look
at
the
use
cases
that
we
think
ppr
would
be
advantageous
to
to
deploy
in,
and
then
I'd
like
to
encourage
others
to
to
work
with
this
on
this
technology.
So
next
slide,
please
so.
Here's
a
quick
overview
ppl
provides
a
method
of
injecting
engineered
paths
into
link
state
igps
in
the
data
plane.
The
packet
is
mapped
to
its
intended
path
by
the
ppr
id.
F
The
ppr
id
is
a
single
identifier
in
the
packet,
so
just
one
address
of
whatever
type
the
packet
is
using,
but
it
and
it
can
support
multiple
data
plane
types,
so
the
ppr
id
can
be
an
ipv6
address.
An
ipv4
address,
an
mpls
label,
an
mpls
or
an
ipv6
sid
or
a
mac
address.
So
we
can
apply
it
to
any
of
these
technologies.
It's
not
hemmed
into
just
mpls
or
just
ipv6.
F
F
All
right
next
slide,
please
and
there's
a
a
a
a
a
a
draft
that
describes
this
for
people
who
want
to
remember
how
it
worked
next
slide.
Please
right!
Thank
you!
So
it
can
we,
it
can
support
quite
a
rich
range
of
structures.
We
can
describe
point-to-point,
we
can
describe
multi-point
to
point
and
we
can
describe
graphs
within
the
control
plane,
structures
that
were
designed
for
this
technology.
F
The
ppr
paths
can
be
injected
by
a
node
for
its
own
purposes
so
locally.
I
can
decide
I
want
to
do.
I
want
to
construct
a
ppr
path.
I
just
inject
it
into
the
into
the
igp
like
I
would
any
other
lsp
or
it
can
be
injected
by
the
it's
through
an
s
from
an
sdn
controller,
and
you
can
just
create
these
paths
right
so,
but
what
what?
F
It
really
does,
what
the
really
important
characteristic
of
it
is
that
it
enables
engineered
parts
in
cost-sensitive
network
applications,
so
think
cheap
hardware,
the
cheapest
hardware.
You
can
imagine
think
small
overhead,
because
packet
overhead
is
a
problem
and
think
a
sim,
relatively
simple
operational
model,
and
we
have
an
open
source
implementation
of
this.
That
was
demonstrated
so
some
while
ago,
at
ietf
105..
F
F
A
mobile
crosshall
and
the
thing
we're
interested
in
is
in
those
little
purple
circles
and
they
are
where
we
need
to
provide
cheap
connectivity
and,
at
the
moment,
they're
provided
by
a
number
of
technologies,
layer,
2,
ipv4,
mpls,
ipv6
underlays.
It
is
by
no
means
a
world
that's
gone
entirely
to
to
ipv6
and
not
necessarily
even
to
mpls
next
slide,
please!
F
So,
let's
drill
down
a
bit
here,
we
have
what
one
of
those
circles
that
little
little
pink
or
mohs
circles
look
like
all
right.
It's
actually
got
structure
and
it's
got
structure
in
which
we
have
to
do
traffic
engineering.
It's
usually
a
set
of
large
subscent
subtended
rings
of
various
sizes.
F
On
this
structure.
We
need
to
provide
slicing,
because
this
is
the
world
that
slicing
was
was
created
to
serve,
but
we
also
need
to
apply
things
like
and
that's
nicely,
we'll
need
strict
piles
and
it
will
need
traffic
engineering.
We
also
need
to
provide
fast
traffic,
aware
traffic
engineering,
aware
fast
reroute
in
this
environment,
so
you
know
think
how
do
we
do
this
for
the
minimum
amount
of
money
on
the
cheapest
hardware,
much
of
which
is
actually
already
deployed
and
will
cost
a
lot
of
money
to
change
next
slide?
Please.
F
Right
so,
but
we
will
get
to
binding
seats
right,
so
these
spine
networks,
sorry
look
think
about
the
edge
of
the
the
network
right
in
the
edge
of
the
network.
We're
gonna
have
to
put
some
some
mini
micro
data
centers
right,
because
the
trend
is
to
get
these
computes
out
as
close
to
the
user
as
possible
to
save
bandwidth
and
to
improve
latency.
F
So
these
tend
to
be
leaf,
spine
edge
fabrics.
These
are
not
massively
scalable
data
centers.
These
are
small
systems.
They
use
an
igp
and
they've
got
an
ipv4
data
plane.
In
many
cases
they
will
need
to
reproduce
to
support
traffic
prioritization
and
they
will
need
to
support
redundancy
and
granular
park
level.
Oam
next
slide,
please
fast,
reroute
right,
so
we
discussed
this
a
little
while
ago.
F
The
the
interesting
diagram
on
here
is
the
purple,
the
purple
line,
which
is
a
traffic
engineered
path,
and
what
we
need
to
do
is
to
traffic
engineer
the
the
the
backup
for
that
path,
and
we
don't
want
to
wait
for
end-to-end
recovery,
because
that
takes
too
long.
We
lose
too
much
traffic.
We
don't
really
want
a
controller
to
go
and
control
everything.
F
We
would
like
to
do
this
with
some
sort
of
more
classical
fast
reroute
approach,
so
local
detection
and
a
path
that
is
suitable
for
repairing
from
this
point,
which
may
be
different
from
a
path
that's
suitable
in
in
another
point,
so
we
may
have
to
put
a
number
of
these
in
and
we
may
need
to
merge
them,
and
we
showed
in
our
draft
in
draft
rtg
wg
pla,
how
we
could
do
that
next
slide,
please
right.
So
this
is
ac's
question
right.
So
there
are,
there
are
other
uses
for
this.
F
F
We
can
also
use
this
as
a
method
of
providing
ti
lfa
in
ipv4
and
ethernet
networks,
and
also
in
mpls
and
srv6
networks,
where
the
overhead
is
critical,
because
the
nice
thing
about
this
is
one
identifier
gets
you
there.
So
we
see
this
as
a
way
of
intro
of
adding
bindings
to
a
network,
but
it
has
a
number
of
other
properties
right.
So,
for
example,
just
skipping
one
for
the
moment,
there's
no
algorithm
metric
needed
the
path
is
the
path
you
needed.
F
So
that
is
a
a
nine
minute
introduction
as
to
what
ppr
is
it's
an
introduction
to
what
the
to
what
we
think
the
problem
space
is
that
this
maps
nicely
to
so.
Has
anyone
got
any
questions
and
is
there
anyone
interested
in
collaborating
with
us
to
see
how
where
we
can
take
this,
this
approach.
S
Peter
well
tarek.
You
were
first,
okay,
thanks,
hi
stuart,
so
I
have
a
question
regarding
the
scale
I
mean
you,
you.
S
F
Well,
we
think
it's
we
think
it's
scalable,
particularly
as
a
lot
of
these
networks
are
relatively
small,
and
so
we
think,
for
example,
in
a
mobile
phone
as
network.
We
think
it
probably
it'll-
probably
work
we're
not
talking
about
doing
the
whole
internet,
we're
not
talking
about
doing
the
whole
core.
This
way,
we're
talking
about
edge,
cost
sensitive
in
all
of
its
terms,
networks
that
may
want
to
map
onto
existing
hardware.
S
F
Right
so,
I
think
there's
some
work
done,
which
hasn't
been
widely
discussed
on
how
to
redo
flooding,
flooding
reduction
for
this
as
well,
because
you.
A
T
T
There
it
is
myself
and
pushed
in
traffic
engineering
working
group,
t's
working
group,
so
a
similar
approach,
but
but
rather
than
relying
on
igp,
we
relied
on
rsvp.
F
So
so
this,
but
this
fits
in
with
the
current
philosophy,
which
is
to
get
rid
of
rsvp
and
rely
and
get
rid
of
the,
for
example,
the
mpls
protocols.
That's
one
thing
right,
and
secondly,
rsvp
really
only
works
with
mpls,
and
this
will
work
with
anything,
including
one
of
the
things
that
we
looked
at.
Was
we
couldn't
we
apply
this
to
link
state
ethernet
systems,
so
this
will
apply.
T
Exactly
that's
what
I
was
trying
to
say
is
that
the
the
draft
we
wrote
was
addressed
for
ipv4
and
ipv60e,
but
it
I
understand
your
your
response.
U
Stuart,
I
just
wanted
to
say
thanks
very
much
for
the
draft.
I
hadn't
gone
through
it
before
this
meeting,
but
in
answer
to
your
question,
if
there's
anybody
interested
in
working
with
you
on
this
100,
because
I
really
like
the
philosophy
of
this,
and
particularly
within
the
african
ecosystem,
where
we
do
have
a
need
for
lower
cost
technologies,
etc
with
a
lot
of
our
clients,
etc.
This
this
is
really
really
a
very
big
interest
to
me.
So
thanks
very
much,
and
if
you
do
need
someone
who's
going
to
work
with
you
on
it,
100.
A
F
A
W
All
right
so
the
the
changes
and
updates
to
this
the
framework
and
just
kind
of
carrying
on
from
the
the
lab.
This
has
been
presented
a
few
times
so
and
I
think
what
the
goal
of
this
presentation
is
to
help
provide
more
clarity
to
the
apn
solution
and
what
the
gaps
that
exist
today
and
the
solution
that
this
provides
and
how
it
feels
how
this
fills
the
gap.
W
So
what
I'd
like
to
do
is
walk
through
this
scenario
and
and
and
and
really
help
depict
kind
of
this
use
case
and
how
it
applies,
and
then
and
then
just
go
over
the
gaps
and
and
where,
where
the
gaps
exist
today
in
current
and
existing
solutions
and
where,
where
we're,
where
we're
really
have
a
fit
for
api.
So
so,
let's
so
for
to
start
I'll
walk
through
this.
W
This
is
basically
an
office
productivity
scenario
and,
and
just
and
what
this
does
is,
I
think,
to
just
point
it
and
it
really
kind
of
goes
to
the
updates
that
we
had
to
apn.
It
really
is
clarification
of
what
apn
provides
and
that's
with
this
use
case.
What
I'm
trying
to
do
is
really
clarify
and
help
help
everyone
understand
kind
of
what
what
this
does
and
how
it
helps
move
the
ball
forward.
So
with
that.
W
So
with
that
this
use
case,
so
it's
described
in
section
six
in
the
apn
framework
draft,
but
basically
it's
a
typical
office
productivity
scenario.
Where
you
have
a
branch
office,
it
sits
in
domain,
one
in
city
a
connects
across
an
operator
backbone,
connecting
cloud
to
cloud
applications
in
city
b
connected
to
the
another.
You
know
within
another
metro
network,
so
very
typical
office
productivity
series
in
this
use
case
we're
we
were
in
this
case.
It's
an
ipv6
underlay,
so
we're
using
srv6
end-to-end
traffic
steering
with
an
l3
vpn
overlay.
W
So
just
a
typical
scenario.
Next
slide.
W
So
this-
and
this
is
really
kind
of
kind
of
this-
is
really
the
main
update
and
then
what
we're
doing
is
trying
to
provide
more
clarity
and
how
this
can
be
used
so
apn,
because
it's
providing
an
ability
to
allow
for
the
same
deep
packet
inspection
that
you
get
with
key
os.
Now
we're
actually
doing
it
with
an
apn
id.
That
is,
that
id!
That's
that's!
That
is
encapsulated
added
to
the
to
the
to
the
to
the
packet.
W
So
with
that
apn
id,
because
it's
in
the
outer
header
versus
deep
packet
inspection,
you're
able
to
get
that
fine
grain
information
at
the
outer
layer
so
saves
on.
W
You
know:
hardware,
memory
and
cpu
resources
and
actually
going
through
the
deep
packet
with
that
that
apn
id
and
with
that
being
able
to
provide-
and
this
is
the
use,
the
big
really
one
of
the
use
cases
but
being
able
to
provide
endpoint
endpoint
connectivity
access
control
capability,
similar
to
an
acl,
but
now
we're
doing
it
at
the
at
the
network
layer
being
being
able
to
provide
it
with
traffic.
Steering
where
we're
we're
able
to
take
a
user
group.
W
W
You
have
the
a
5n
tuple
of
of
headers
that
that
you
know
that
define
the
application
flow
and
it
could
be
any
typical
in
this
scenario
we're
showing
voice
video
and
data
traffic,
so
that
traffic
gets
matched
with
the
source
ip
and
then
it
gets
set
to
a
user
group
so
that
specific
user
group
is
part
of
that
endpoint
application
flow,
that's
defined
in
the
application
id
and
then
and
then
with
that,
it's
it's
matched
to
a
that
source
and
destination,
and
then
it's
set
to
the
it's.
W
The
user
group
is
now
set
to
an
application
group.
So
we
have
the
source
get
set
to
a
user
group,
and
then
data
is
actually
classified
to
an
application
group,
so
discreetly
to
control
the
that
fine
grain-
and
this
is
really
where
the
action
happens,
with
apn
being
able
to
provide
that
fine
grain
on
on
a
on
an
application
basis.
Next
slide.
W
So
with
that
with
the
with
the
access
control,
what
would
this
depict
is
in
in
that
in
that
endpoint
control
of
end
user
application
control
from
some
particular
user
group
mapping
that
to
an
application
group?
So
here
what
we're
showing
is
we
have
a
user
group
defined?
W
You
know
one
zero,
zero
one,
and
then
here
we
showed
that
there
are
other
application
groups
that
exist
and
so
we're
explicitly
denying
so
that
that
application
user
group
does
that
user
group
does
not
have
access
to
these
particular
destination
application
groups
and
it
only
matches
the
101,
the
the
ones
that
we
wanted
to
have
access
to.
So
the
one
zero
zero
one,
one
zero,
two
one,
zero
three,
so
those
are
permitted
so
providing
that
fine
grain
application
control
from
basically
source
destination.
Literature
therefore
flow
next
slide.
W
So
with
that's
the
same
concept
about
taking
the
with
the
fine
grain
infrared
information
to
find
five
tuple
sort
layer,
three
letter,
four
information
defining
it
mapping
to
a
user
group
and
then
matching
that
user
group
mapping
that
to
an
application
group
now
with
that,
instead
of
having
to
do
any
type
of
deepak
and
inspection
to
determine
where
I
want
to
apply.
Let's
say:
if
I
I
need
iom,
like
oam
services,
to
get
telemetry
information
for
a
particular
application
flow.
W
It
could
be
like
voice
or
video
or
something
that
has
high
jitter
latency
could
be
across
like
a
3gpp
user,
plane
or
whatnot.
But
let's
say
you
want
to
apply
ion
just
to
that
particular
flow
instead
of
having
to
require
deeper
packet
inspection
to
go
into
the
payload.
Now
you
have
this
outer
header,
this
application
id.
That's
that's
added
to
the
payload,
but
it
I'm
not
adding
there
but
added
to
the
outer
header.
W
So
you
don't
have
to
go
deep
into
the
packet
and
you
and
that
that
information
is
right
there
that
you
can
match
so
saving
on
hardware.
You
know
hardware,
you
know
resources
and
and
latency
and
processing
of
the
packet
and
to
apply
the
yeah
and
any
iom
characteristics
for
telemetry
and
then
and
then
once
once
that's
done
now
at
the
at
the
head
end
of
the
of
the
apn
infrastructure,
now
we're
able
to
mat,
we
got
the
classification
done
with
the
matching.
W
W
So
as
as
far
as
gaps,
I
in
the
last
presentation
at
itm
111,
we
did
go
through
a
lot,
the
gaps
that
exist.
So
I
just
wanted
to
touch
on
those
again,
and
this
is
something
that
there
was
a
lot
of
question.
We
spent
a
lot
of
time
on
this,
but
really
the
the
bottom
line
is
that
they
exist.
There
are
existing
solutions
and
what
apn
does
it
provides?
W
It
provides
its
own.
It's
it's,
it's
a!
It
provides
a
solution
to
you
know
for
this
fine
grain
sla
capability.
W
However,
in
looking
at
the
existing
solutions
and
mechanisms,
most
and
just
looking
at
what
we
have
here.net
with
the
flow
id
as
well
as
network
slicing
with
the
resource
id
or
as
well
as
service
function,
chaining
would
be
the
spi
identifier.
They
all
have
their
own
particular
function
that
they're
used
for,
but
being
able
to
leverage
those
existing
functions
to
actually
provide
that
same
type
of
fine
grain.
Sla
is
impossible
because
they
have
you
can't
really
use
these
already
have
their
pre-defined
function.
So
you
can't
really
use
this
for
another
function.
W
This
you
know
such
as
the
fine-grained
sla
and
that's
where
the
apn
id
having
this
new
structured
section,
you
know
section
or
or
intelligent
id,
that's
able
to
provide
this
fine-grained
service.
I
mean
that's
really
kind
of
the
big
thing
we
did
talk
about
other
other.
Existing
mechanisms
like
the
float
like
like
the
ipv6
slow
level
that
was
discussed
quite
in-depth
and
the
issue
that
exists
with
the
ipv6
flow
label
is
that
it
even
with
rc
6437.
W
W
There
isn't
any
use
case
or
or
scenario
where
that's
how
that's
even
possible,
and
even
in
discussions
with
six
man,
just
in
related
to
that
it's
either
one
or
the
other,
and
if
you're,
using
signaling
and-
and
there
are
some
other
drafts
that
talk
more
in
detail
or
archie's
to
talk
more
in
detail,
but
if
you're
you're
either
using
the
flow
label
for
signaling,
but
then
that
would
actually
break
ecmp
and
you
really
can't
do
both.
W
So
that's
that
that's
the
big
deal
there,
the
the
other
thing
that
was
meant,
I
guess,
was
qos
and
qos
with
so
what
geos
provides?
I
mean
that
that's
been
around
for
for
decades
and
it's
provided
really.
It
means
you
know
providing
sla,
you
know,
and
but
what
I
would
call
quarter
stream,
but
it
does
provide
sla
for
classifying
traffic.
W
What
this
does
kind
of
goes
above
and
beyond
that
business.
Now
it's
able
to
do
some
more
acl
type
like
infrastructure,
acl
type,
endpoint
flow
flow
management,
as
well
as
being
able
to
provide
that
same
qos
type
of
traffic,
classification
and
privatization,
but
now
taking
it
kind
of
to
the
next
next
level.
A
finer
grain
of
of
classification
next
slide.
W
So
in
in
the
gap
analysis
we
we
this
slide
just
kind
of
shows
kind
of,
although
all
the
different
existing
solutions
that
exist
existing
mechanisms
that
have
used
for
existing
technologies
today.
So
what
apn?
What
we
feel
is
apn
would
be
positioned
for
not
only
existing
technologies
but
as
well
as
future
technology,
then
it
would
also
enhance
any
existing
solution
or
technology
that
exists,
let's
say,
for
example,
q
os.
This
could
be
used
with,
as
in
conjunction
to
provide
a
finer
grade
of
application
flows
similar
and
similar,
to
kind
of
what
I
did.
W
What
I'd
shown
in
the
use
case
with
me
being
able
to
classify
a
further
classification
of
interesting
traffic
with
an
acl
but
more
granular,
so
taking
taking
what
you
do,
what
you
have
with
qos,
but
now
applying
acls
to
that
and
being
able
to
do
a
really
a
more
robust
classification
of
characteristics
and
being
able
to
map
them
to
discrete
traffic
engineer
flows.
W
W
Those
mechanisms
that
exist
today
and
being
able
to
leverage
that
to
actually
be
to
use
it
for
apn
is
and
that's
what
we're
showing
is.
That
is
that
that
is
not
possible.
They
they
are,
they
they
serve
their
function,
they're
good
that
that's
what
they're
made
for,
but
being
able
to
leverage
it
to
be
used
for
apn
would
not
be
possible,
and
that's
why
that's
really
why
apn
really
kind
of
this?
W
Thank
you.
So
any
comments,
questions
for
anyone.
I
hope,
as
I
went
through,
that
if
anyone
has
questions
or
comments
just
to
help,
I
can
try
to
help
explain,
and
I
guess,
there's
a
couple
other
slides
decks
that
we're
going
to
be
going
through
with
that
robin
shipping
as
well.
Thank
you.
T
T
W
So
it's
like
again
because
it's
granular
it
would
be
the
flow
would
be
it
could
be.
It
could
be
a
an
aggregation
of
flows,
so
any
anything
coming
from
a
ce.
It
would
be
an
aggregation
of
flows
or
it
could
be.
M
W
Up
to
the
operator,
you
know
how
grainy,
where
you
would
like
to
make
it.
T
T
R
I'm
glad
you
mentioned
qos
as
the
as
the
kind
of
the
de
facto
standard
for
for
labeling
application
flows
in
in
existing
edge
networks.
One
of
the
nice
properties
of
of
the
qos
bits,
of
course,
is
that
when
you're
traveling
across
an
ipsec
tunnel,
qos
can
be
promoted.
R
Do
you
consider
the
apn
information
that
the
the
header
information
also
being
sort
of
carried
from
the
inside
of
tunnels
during
the
encapsulation
process,
to
the
to
the
encapsulating
packet?
Is
that
in
your
model,
have
you
considered
that,
at
all.
W
Yes,
so,
let's
just
understand
yeah,
so
the
the
apn
id
it
would
be
encapsulated
and
it
would
be
part
of
the
so
the
data
packet
that
gets
transmitted
so
that
the
apn
engine
would
be
print
it
would
be
in
the
and
in
the
packet,
and
you
know
throughout
the
apn
domain.
So
throughout
that
closed
domain
and
then
and
then
removed
at
the
egress
point
of
the
domain.
R
Q
Okay,
okay:
this
is
the
champion
so
from
huawei
we
I
will
introduce
this
the
encapsulation
of
the
apn,
so
the
encapsulation,
including
the
apn
header,
and
also
this
the
data
plane
ipv6
so
means
the
ipv6
encapsulation
for
the
epm
header
of
the
next
page.
Q
Q
Maybe
we
have
the
different
scope
for
the
apid,
so
here
defined
the
two
types
of
the
api
id
one
is
the
short
api
id
is
32
bits.
Another
is
the
long.
Apid
is
128
bits
and
also
that's.
The
apid
is
mandatory
in
the
epn
header.
Besides
the
apid
there's
the
two
optional,
the
fields,
one
is
the
entrant,
so
this
means
the
represent
the
set
of
the
service
requirement
to
the
network
for
specific
apid,
and
also
that
we
also
have
this
the
epm
parameter.
Q
So
that's
this
is
the
apm
parameters
defined
for
the
specific
apid
and
also
in
order
to
indicate
if
the
specific
apm
parameter
exists
or
not
in
the
api
header.
So
we
have
the
fields
of
the
epm
parameter
type,
so
use
a
60
16
bit
identifier,
you
use
each
bit
to
subversive
like
versify,
which
vpn
apm
parameter
are
exists
in
exist
in
the
epm
header
or
not.
So
that
means
they
use
a
bitmap
okay.
So
there
is
a
header
next
slide.
Q
Okay,
so
apid
can
be
divided
into
three
parts.
So
that's
the
cursor
is
the
api
group
id
and
the
user
ib
group
id,
and
then
this
reserved
so
the
length
of
the
app
group
id
user
group
id
and
the
result
fields
can
be
variable.
So
this
can
be
configured
in
the
domain
and
be
consisted
in
the
specific
network
domain.
Q
Okay,
so
here
we
defined
this,
the
four
apn
calimeters
for
the
network
service
requirement.
So
that's
the
this
is
the
bandwidth
and
the
delay
and
delay
variation
and
the
package,
the
loss
ratio
for
the
specific
api
id.
Accordingly,
we
will
define
this
the
four
bit
for
the
apm
parameter
type.
So
that's
a
huge
bit
to
indicate
a
specific
api
parameter
exist
or
not
next
slide.
Q
Okay,
so
this
is
the
ipv6
encapsulation
for
the
apn
header,
so
we
defined
that's
the
option,
so
that's
the
the
one
this
is
the
has
defined.
This
is
the
option
type
under
the
data
length.
Then
this
is
the
value.
Now
the
data
option
data
the
option.
Data
is
just
the
api
header
defined,
so
this
option
can
be
used
in
the
whole
backup
option,
header
and
the
destination
open
header.
Q
Q
N
N
N
So
those
two
parts
will
be
integrated
into
one
ap
id
next
piece
and
here
and
the
ordering
of
the
flows
back
is
also
important
for
apn.
There
are
two
reasons:
one
is
that
there
are
also
other
coexisting
flows
back
rules
and
besides
the
apn
flows
back
rules,
and
also
because
we
know
ap
id
is
structured
and
different
parts
of
it
can
be
decided
by
different
rules.
So
that
means
we
need
to
have
a
careful
organization
of
those
rules.
N
Here
we
introduce
this
new
ec
and
we
have
the
group
id
and
the
subgroup
id
and
for
within
the
sub
provided
is
actually
the
same
as
what
we
have
previously
defined.
That
depends
on
whether
the
traffic
action
is
carried
out
not
out
and
whether
the
t
flag
is
set
and
once
when,
when
one
condition
in
the
subgroup
is
matched.
The
evaluation
of
the
n
is
subsequent
flow.
Specifications
within
this
subgroup
will
stop
and
between
subgroups.
N
That
is
because
each
subgroup
contains
the
rules
for
for
tagging,
the
one
part
of
the
ap
id,
so
all
the
sub
groups
will
will
be
evaluated
one
by
one
and
between
the
groups.
We
gave
the
group
with
a
priority,
and
that
means
once
there
is
a
one
condition,
is
matched
in
a
group
in
the
ap
group
and
the
following
evaluation
will
stop
next,
please.
N
So
here
is
about
young
model,
and
there
are
a
few
parts
of
this
young
one
of
currently,
we
only
focus
on
the
ipv6
data
plane
and
we
define
global
action.
That
is
for
the
inherited
which
I
just
introduced,
and
then
it's
about
the
ap
id
templates
and
to
define
the
templates
for
this
structured
apid
and
for
the
marking,
and
we
could
mark
the
ap
id
based
on
the
the
templates
we
have
selected.
N
That
is
once
you
select
the
the
flow,
and
then
you
tag
the
api
id
and,
and
lastly,
is
the
mapping
policies
and
we
could
use
color
to
differentiate
my
pin
policies
to
indicate
those
different
set
of
mapping
policies
and
then
based
on
the
ap
id
we
could
decide
which,
as
our
policies
to
go
into
based
on
the
color,
and
it
could
also
be
the
redirect
to
the
nasda
hop
and
that
is
belongs
to
the
native
ip
next
piece.
Yes,
that's
all.
Thank
you.
Any
questions.
K
I
think
they
will
be
good
to
get
more
information
and
on
the
list
on
what
their
expectation
of
having
in
the
profile
packet
to
us
ratio
and
a
jitter.
So
I
understand
that
that's
to
be
added
in
ipv6
encapsulation
for
apn,
so
what
their
expectation
of
how
that
can
be
used.
Is
it
constrained
for
forwarders
or
local
path,
selection
or
such
so?
Just
let's
discuss
it
on
the
list.
X
Hey
hello,
can
you
hear
me?
Yes
hi?
This
is
ray
from
alibaba
we're
going
to
present
how
we're
going
to
precisely
control
the
conditioning
condition
inside
network
and
that
also
relate
to
how
we
choose
the
route
inside
the
data
center.
Together,
we
contribute
to
the
low
latency
networking
for
our
applications.
Next
slide,
please.
X
So
today's
a
new
application,
such
as
high
performance
storage
and
the
large-scale
deep
learning
applications
use
a
new
hardware
that
can
generate
data
orders
or
magnitude
faster
than
before.
X
So
that
requires
a
low
latency
for
the
network
and
also
that
network
become
more
important
than
before,
and
another
trend
is
that
resource
disaggregation
is
happening
inside
clouds
which
separate
the
compute
and
storage
and
memory
into
different,
separate
recessive
pools.
So
even
memory
access
will
go
through
the
network
in
the
future,
so
that
that
means
that
we
will
add
considerable
load
to
the
network
and
also
require
ultra
latency.
X
X
X
X
So
we
observed
a
couple
of
issue
in
today's
condition:
control
inside
high-speed
network
first
of
all
is
that
we,
those
network,
has
to
use
a
float-based
flow
level
of
flow
control
such
as
pfc
to
reduce
the
packet
loss.
However,
due
to
the
pfc
stall
and
the
deadlock
happen
in
the
inside
clouds,
which
cause
the
stability
issue
of
our
network-
and
this
whole
reason
is
because
that
the
country
is
a
have
a
slow
convergence
time,
so
that's
why
we
cannot
resolve
congestion
in
time.
X
The
second
issue
that
we
cannot
run
multiple
applications
together
inside
the
cluster
and
they
were
using
qualitative
service
queue,
cannot
solve
this.
This
issue
because
qasq
is
very
skilled
resources
which
has
been
allocated
to
different
applications.
X
The
the
rhythm
behind
this
is
that
existing
solution,
using
standing
queue
to
identify
condition
and
a
standing,
cue
itself
being
a
issue
of
latency.
X
X
So
there,
the
new
trend
inside
the
silicon
switching
silicon
is
that
inband
tenement
tree,
so
new
switches
has
invented
telemetry
ability
if,
for
example,
inside
this
figure
that
when
the
packet
goes
to
the
switch,
the
switch
can
add
a
tenant
tray
information
into
the
package,
so
it
so
each
switch
can
add
some
information
into
the
packet
and
those
packy
and
the
telemation
information
can
be
redirected
to
the
remote
collector
to
fund
the
the
many
use
for
troubleshooting
purpose,
such
as,
where
the
packet
get
lost,
is
any
routing
black
hole,
etc.
X
X
So
that's
the
original
idea,
which
we
call
the
hpcc
and,
if
the
so
when
the
packet
goes
through
the
network
and
each
switch
along
the
path
will
add
animation
information
into
the
package
when
the
package
arrives
at
the
destination
and
the
reserver
can
generate
notification,
packet
or
icon
packet
back
to
the
sender
to
add,
adjust
the
sending
rate
next
slide.
Please.
X
So
in
hpcc
we
define
the
algorithm
to
using
those
tiny
machine
information
for
condition,
control
those
information,
including
the
q
lens
transmitted,
bytes,
timestamp
link
capacity,
etc.
So
we
actually
defined
how
we
can
use
those
information
and
how
we
can
calculate
the
precise
ascending
ray
based
on
that.
However,
the
actual
package
format
is
depend
on
the
environment,
so
here
we
give
an
example
of
telemetry
being
embedded
into
the
a
certain
tenementary
form
format.
X
X
So
when
we
use
this
approach
to
precisely
identify
and
control
the
sending
rate-
and
we
solve
the
all
three
issues
previously
mentioned-
first
of
all,
we
achieve
faster
convergence
because
we
know
precisely
how
much
we
can
send
to
the
network
without
causing
the
congestion
and
then.
Secondly,
we
we
know
that
we
base
our
information
based
on
the
tenant
trading
information,
not
based
on
the
q
length.
So
we
actually
don't
require
a
queuing
in
the
in
the
switch.
X
So
we
can
actually
achieve
a
near
zero
q
to
achieve
both
high
throughput
and
low
latency
and
the
because
we
we
know
precisely
what's
going
on
in
the
network,
so
we
don't
need
a
heuristic
approach
to
guess
what's
happening
inside
network
and
we
we
that's,
why
we
use
very
few
parameters.
X
So
so
that
also
relates
to
the
routing
inside
network
as
well,
because
route
condition
changes
dramatically
inside
data
center,
for
example,
incas
can
happen
quite
frequently
and
link
failure
due
to
a
routing
black
hole
and
also
silent.
Jobs
can
also
happen
in
particular,
routes
and
applications
want
to
fast
reroute
to
a
different
path.
To
avoid
this
temporary
failure
or
partial
failure,
so
rerouting
is
a
is
a
kind
of
a
lightwork
network.
X
Primitive
provide
for
application
before
the
application
got
affected.
So
spc
is
actually
using
those
precise
information
to
kind
of
have
a
view
of
a
router
capacity.
We
know
how
much
traffic
we
can
send
to
a
particular
route
if
this
route
has
failure,
which
means
that
there
is
a
zero
capacity,
we
must
do
the
re-route
as
soon
as
possible,
so
joint
with
the
routing
and
the
traffic
allocation.
So
we
can
have
a
combined
view
at
the
endpoint
site
to
decide
how
much
traffic
we
can
send
to
each
of
each
route.
X
Evaluation
results
in
the
production
when
we
implement
into
the
smart
link.
We
see
that
the
traffic
actually
been
the
latency
has
been
reduced
to
up
to
95
percent
in
the
small
messages.
If
you
look
at
the
left
figure
and
and
that's
happened
because
we
actually
control
the
q
length
and
reserve
the
congestion.
X
Q
Oh
quick,
so
I
want
to
know
the
purpose
of
this.
The
draft
user
defender
framework
or
user
tried
to
propose
some
of
the
protocol
extension
according
my
understanding,
because
we
know
that
already
has
this
the
ippm
working
group.
That's
the
imbalance
elementary
and
also.
We
also
have
this
traffic
engineering
work
in
the
rtg
area.
X
So
ip
ippm
is
defined
in
the
the
format
of
the
information
being
put
into
the
data
package,
so
our
work
is
defined.
The
algorithm,
because
this
across
has
to
be
implemented
in
both
the
the
end
host
in
the
switch
around
the
path.
So
it's
different
different
vendors.
So
we
want
to
have
a
a
general
agreement
under
an
algorithm
and
a
protocol,
so
we
can
coordinate
with
different
parts
of
the
net
inside
network
to
work
together.
X
So
that's
the
purpose
is
we
want
to
provide
a
a
kind
of
a
framework
and
a
protocol
so
to
define
especially
that
how
the
algorithm
works
and
beyond
that,
because
that's
also
related
to
the
how
we
choose
the
different
routes
based
on
the
condition
of
of
each
route,
so
that
also
require
the
the
software
part
to
to
be
aligned
with
hardware
implementation.
X
A
We
are
over
time,
I
think
it's
really
interesting
work,
and
I
mean
we
are
very
very
far
away
on
distribution
of
reachability.
A
However,
this
work
brings
us
knowledge
about
condition
of
the
network
and
also
defines
both
standard,
as
well
as
transport
nodes,
so
we'll
be
working
with
authors
to
provide
kind
of
better
alignment
with
what
routing
area
is
all
about,
but
I
think
this
is
something
we
really
need
to
work
on.
This
step
is
coming
up,
artificial
intelligence
being
deployed
in
all
large
data
centers,
and
today's
igps
and
bgp
doesn't
address
it.
That's
why
you
see
the
presentation
here
we
are
over
time.
A
C
Time,
yeah
and
we
are
sorry
we
couldn't
let
the
bfd
presentation
happen,
because
we
are
really
running
out
of
time.
So.