►
From YouTube: IETF111-RTGWG-20210728-1900
Description
RTGWG meeting session at IETF111
2021/07/28 1900
https://datatracker.ietf.org/meeting/111/proceedings/
A
A
A
To
repeat
our
charter
here
and
we've
been
using,
it
really
really
successfully.
You'll
see
a
lot
of
interesting
stuff.
This
atf
we
facilitate
process
of
innovation.
We
propose
home
to
some
proposals
that
could
potentially
go
into
other
working
group
or
progress
in
routine
working
group
or
perhaps
develop
a.
A
Both
administration
perspective,
we
are
going
to
review
the
agenda
review.
All
the
working
group
documents
available
and
links
here
are
to
show
you
where
it
is
and
thanks
to
linda
for
taking
the
nuts.
A
A
This
work
starts
in
2015,
with
linux,
patches
and
now
being
deployed
a
number
of
hyperscaler
data,
centers,
really
interesting
technology
being
discussed
in
six
man
at
some
point
in
time.
So
I
really
wanted
just
to
bring
it
into
routing.
So
people
get
aware
of
what's
going
on
here
and
how
it's
being
used.
A
Nothing
has
been
adopted.
So
this
is
a
working
group
document,
the
routing
working
policy
model.
We
are
waiting
for
the
new
document
and
practically
it's
really
ready
and
it's
final
review
opportunity
for
you.
A
A
Bgp
peak,
we
are
in
process
of
reviewing
all
the
updates
and
comments.
A
Second,
routine
ki
lfa
we've
got
great
work
by
stewart
and
we
are
still
expecting
to
address
reviews
that
are
going
to
be
proposed
by
routing
their
threat
and
other
reviews
and
atm
bgp
is
going
to
be
presented
now,
as
well
as
eagles
protection
draft
there's
number
of
individual
drafts
that
are
covered
in
this
atf.
We
would
also
like
to
do
some
review
of
what's
going
on
and
perhaps
rejuvenate
some
discussions
before
112
there's
number
of
architectural
documents
that
been
dormant
for
quite
some
time.
So,
if
not.
E
Hey
guys,
thank
you
alert
on
the
road.
I
just
want
to
really
quickly
thank
chris
bowers
who,
as
you
all
know,
stepped
down
as
chair
a
few
weeks
ago,
and
thank
you
for
all
his
work.
He
is
here
today.
He
is
still
sheparding
some
of
the
documents
as
well,
and
welcome,
of
course,
yingsten
as
the
new
chair
of
rtwg,
as
you
notice,
with
with
the
slides
and
everything
the
working
group
is
not
missing
a
beat.
So
thank
you
both
of
you
for
your
work
and
that's
it.
Thank
you.
So
much.
A
D
Yeah,
so
fred
is
the
next
presentation
because
he
has
some
animation
in
his
slides,
so
he
will
be
sharing
his
screen.
F
Okay,
thank
you
insane
I'll,
go
ahead
and
get
my
screen
started
and
my
video
started.
Hopefully
the
video
comes
through
okay.
Let
me
try
sharing
my
screen.
F
So
the
first
document,
a
simple
bgp
based
mobile
routing
system
for
the
aeronautical
telecommunications
network,
is
a
document
working
group
item
of
the
arts,
routing
working
group
working
group.
It
is
a
bgp
based
spanning
tree
overlay,
actually
configured
over
one
or
more
internet
working
segments
based
on
a
non-broadcast,
multiple
access
or
nbma
interface
model,
and
it
uses
ipv6,
unique
local
addresses
for
navigating
the
spanning
tree.
F
The
ietf
routing
working
group
has
had
this
as
a
working
group
item
since
august
30
2018
and
it
has
been
coordinated
with
the
international
civil
aviation
organization,
aeronautical
telecommunications
network,
and
this
work,
we
believe,
is
ready
for
ietf
routing
working
group
last
call
the
next
document,
known
as
automatic,
extended
route.
Optimization
provides
route,
optimization
extensions
that
can
establish
shortcuts
over
the
spanning
tree.
I
referred
to
earlier
to
avoid
strict
spanning
tree
paths.
F
The
omni
interface
is
a
single
nbma
network
interface,
that's
exposed
to
the
ip
layer
and
offers
a
fixed
9kb
mtu
to
the
iplayer.
However,
it's
configured
as
an
overlay
over
potentially
multiple
underlying
physical
or
virtual
interfaces
that
may
have
heterogeneous
mtu's
that
may
be
different
size
than
9
kb
within
the
interface.
A
sub
layer,
known
as
the
omni
adaptation
layer,
provides
a
minimum
mid
layer,
encapsulation
that
maps
the
ip
layer
to
the
underlying
interfaces
and
again
this
pointer
to
the
document,
and
we
believe
the
work
is
ready
for
ietf
adoption.
F
So
how
does
this
look
like
in
a
typical
deployment
scenario?
So
here
we
have
arrow
and
omni
in
a
single
internetwork
case,
where
we
have
clients
that
are
represented
by
these
airplanes.
As
you
see
around
the
periphery
that
connect
to
access
network
sub
networks
via
one
or
more
data
links,
you
see
that
some
of
the
clients
have
just
a
single
data
link.
Others
have
multiple.
F
The
sub
networks
then
connect
to
the
internetwork
through
devices
known
as
proxy
servers
that
are
at
the
subnetwork
edges,
and
they
can
act
as
either
ipv6,
routers
or
ipv6
neighbor
discovery
proxies
and
then
internal
to
the
internet.
We
have
bridges
our
nodes
that
establish
the
spanning
tree
over
one
or
more
internetworks
and
again
using
ipv6,
unique
local
addresses
in
the
on
the
adaptation
layer
as
an
encapsulation
sublayer
that
sees
the
spanning
tree
as
a
layer.
Two
service
the
same
as
a
bridge
campus
land
would
do
so.
F
F
F
Now,
in
terms
of
the
omni
interface,
the
overlay,
multi-link
network
interfaces,
all
arrow,
omni
clients,
proxy
servers
and
bridges,
configure
omni
interfaces,
which
is
the
node's
connection
to
the
omni
link.
Client
omni
interfaces
are
configured
over
multiple
underlying
interfaces
and
they
connect
end
user
networks.
So
if
you
see
the
diagram
in
the
upper
left
here,
we
show
the
omni
interface
as
being
a
layer
below
ip,
but
a
layer
above
the
l2
underlying
interfaces
we're
showing
here,
if1,
if2
and
so
forth.
Through
ifn,
the
omni
interface
uses
ipv6
encapsulation,
I'm
sorry.
F
I've
got
to
hide
it
a
pop-up
window.
Here
there
we
go
to
expand
the
entire
concatenated
internet
working
path
in
a
single
nbma
l3
hop
so
that
all
arrow
and
omni
nodes
are
neighbors
on
the
link.
So
if
you
look
at
the
diagram
on
the
left
here
or
the
right
here,
you
see
the
arrow
proxy
servers,
clients
and
bridges
all
appearing
as
neighbors
on
a
link.
The
omni
link
and
this
link
is
manifested
through
nbma
encapsulation
over
one
or
more
internet
works.
F
3
hops,
then,
is
the
access
network
model,
where
the
client's
underlying
interface
connects
to
a
secure
access
network,
for
example,
an
enterprise
network,
a
cellular
operator,
network,
etc,
where
there
are
layer,
two
and
layer,
one
security
provisions
on
the
path
to
the
proxy
server,
but
then
the
proxy
server
connects
to
an
external
internetwork
and
then,
finally,
the
internetwork
model,
in
which
the
client's
underlying
interface
connects
directly
to
an
external
internetwork,
for
example
over
a
coffeehouse.
Why
public,
wi-fi
or
a
hotel
public
wi-fi
in
in
this
case
the
proxy
server
may
be
one
or
more
layer?
F
Now,
clients
may
have
diverse
underlying
interface
types,
which
may
connect
to
multiple
distinct
inner
networks,
as
opposed
to
all
via
the
same
internet
work.
For
example,
a
nine-n
interface
could
connect
to
the
public
internet.
An
a
net
interface
could
connect
to
a
cellular
operator
network.
A
direct
interface
could
connect
to
a
dedicated
enterprise
network,
proxy
server
and
etc,
and
the
client
can
utilize
all
of
these
underlying
interfaces
according
to
on
traffic
selector
attributes
that
we'll
talk
about
later.
F
So
in
terms
of
encapsulation
and
segment
routing,
the
omni
interface
is
going
to
insert
mid-layer
encapsulations
between
the
ip
layer
and
the
underlying
interfaces
and
they're
going
to
it's
going
to
use
minimal
encapsulation
with
effective
header
and
compression,
so
that
we
don't
have
excessive
encapsulation
overhead.
F
It
may
apply
oil
encapsulation,
potentially
fragmentation.
It
might
include
a
udp
encapsulation.
If
the
packet
needs
to
traverse
in
a
public
internet,
it
then
would
include
ip
encapsulation,
decapsulation
and
layer,
2
encapsulation
decapsulation,
for
transmission
over
the
underlying
interfaces.
F
Now
the
ol
mid-layer
segment
routing
is
used
as
necessary
to
traverse
the
spanning
tree
over
disjoint
inner
network
segments,
as
shown
in
the
right
hand
diagram
here.
We
have
segments
a
b
c,
etc,
where
the
bridges
of
each
segment
peer
with
one
another,
and
we
use
segment
routing
to
traverse
the
different
segments
between
a
source
and
estimation.
F
Now,
then,
each
arrow
and
omni
node
configures
an
ipv6
link.
Local
address
for
use
in
ipv6,
neighbor
discovery,
messaging
clients
configure
a
mobile
network,
prefix
link
local
address
so,
for
example,
for
the
mobile
network,
prefix,
2001,
dba,
colon
1.2,
the
mnplla
is
fe80,
followed
by
a
strain
of
zeros,
then
ending
with
2001
db812.
F
F
So,
for
example,
if
the
ula
prefix
for
the
omni
link
was
fd00
colon
zero
one,
zero,
two
colon
zero,
three
clone
zero.
Four
colon
zero
five
coins.
Six,
then
the
mnp
lla
taken
from
the
above
mnp
lla,
is
shown
in
that
one
string.
We
see
that
begins
with
fd00,
slash,
128
and
finally,
clients,
proxy
servers
and
bridges
use
ulas
as
the
ol
header,
source
and
destination
address.
F
F
Then
finally,
arrow
and
omni
proxy
servers
configure,
ipv4
and
or
ipv6
anycast
addresses
to
advertise
the
omnilink
reachability
to
into
access
networks
that
would
allow
potential
clients
that
connect
to
the
access
networks
to
send
network
join
ipv6
neighbor
discovery
messages
within
any
cast
encapsulation
destination
address
to
discover
the
nearest
proxy
server
for
the
desired
omni
link.
F
So
for
ipv4,
the
anycast
address
that
we'll
be
using
is
192.88.99.1.
This
address
was
formally
reserved
as
the
64
relay
anycast
address,
but
that
use
has
been
deprecated.
So
what
we'll
be
asking
for
is
the
iana
to
reclaim
that
prefix
for
the
use
of
arrow
and
omni
and
then
for
ipv6.
The
anycast
address
is
going
to
be
based
on
the
64
expansion
of
192.88.99.1.
F
As
you
can
see,
that
expansion
is
2002.
Calling
c058
colon
6301,
followed
by
the
64-bit
mobile
network
prefix,
followed
by
a
16-bit
link.
Suffix
that
address
would
be
broadcast
into
will
not
broadcast
propagated
into
the
ipv6
routing
system
of
the
access
network,
and
any
prospective
client
that
wanted
to
join
the
omni
link
could
send
control
messages
with
an
encapsulation
header
that
includes
that
as
the
destination
and
the
ipv6
routing
system
will
then
convey
the
messages
to
the
nearest
proxy
server.
F
Now
I
want
to
talk
about
the
atn
bgp
routing
system
and
again
this
is
the
routing
working
group
working
document
that
we're
looking
for
working
group
last
call
on.
So
in
this
model
we
have.
The
proxy
servers
are
simply
stub
autonomous
system
border
routers
and
they
appear
with
bridges
as
core
autonomous
system,
border
bridges
use
bgp
to
peer
with
the
bridges
of
different
segments
to
create
a
ulab
spanning
tree,
which
you
can
see
here
in
the
green
lines.
F
F
Now
the
reason
for
this,
which
is
not
very
well
called
out
in
these
these
slides,
but
must
must
be
clearly
understood,
is
that
we
will
contr.
We
will
secure
all
control
messages
that
traverse
the
spanning
tree.
Now
again,
ipsec
and
wireguard
are
used
in
the
core
network
between
proxy
servers
and
bridges
in
the
client
to
proxy
server
arrangements.
F
We'll
use
either
the
native
l2
security
features
of
an
access
network
or
over
public
internetworks
will
use
hip
messages
that
provide
hip
security
so
that
the
client
can
securely
convey
its
control
messages
to
the
proxy
server
and
then
once
conveyed
securely
to
the
proxy
server.
The
proxy
server
can
convey
it
across
the
secured
spanning
tree
to
other
infrastructure
nodes,
other
bridges
and
proxy
servers.
F
F
The
oil
source
again
is
going
to
produce
carrier
packets
and
the
oil
destination
is
going
to
reassemble,
but
the
intermediate
nodes,
in
other
words,
bridges,
join
the
network
segments
in
the
spanning
tree,
and
this
also
provides
support
for
global
mobility
and
route.
Optimization
again
with
dynamic
mtu
tuning.
F
So
the
control
messages
used
to
establish
routing
information
to
disc,
establish
these
route.
Optimizations
I've
been
referring
to
our
ipv6
neighbor
discovery
messages,
all
ipv6,
neighbor
discovery
message
types
are
used,
including
router,
solicitation,
router,
advertisement,
neighbor,
solicitation,
neighbor
advertisement
and
sometimes
even
redirect.
F
So
your
own
omni.
U
nodes,
use
ipv6,
neighbor
discovery,
messages
for
omni-link,
neighbor
coordination
and
the
messages
include
a
new
ipv6
neighbor
discovery
message:
option
type
known
as
the
omni
option.
The
reason
for
including
the
omni
option
is
first
to
assert
protocol
perform
conformance.
This
is
to
assert
to
both
ends
that
the
omniprotocol
is
being
observed.
F
Secondly,
is
to
synchronize
identification
windows
and
then,
finally,
to
exchange
configuration
information
and
on
the
right,
you
see
the
format
of
the
omni
option.
It's
in
tlv
format,
with
a
type
field
that
has
the
type
of
the
option,
which
is
something
that
we'll
have
to
procure
from
iana.
To
identify
this
as
an
omni
option,
the
length
provides
the
length
and
awkwards
of
the
entire
option.
Prefix
length
and
source
target
on
om
index
refer
to
the
prefix
length
of
the
source.
F
Address
of
the
of
the
message
and
the
underlying
interface
index
used
to
carry
the
message,
and
then
you
see
sequence,
number
acknowledgement
number
flags
in
window.
You
may
notice
that
these
are
copied
exactly
from
the
tcp
header,
because
they're
used
for
exactly
the
same
purpose,
which
is
to
establish
a
window
of
outstanding
identification
values
and
without
having
this
window,
it
would
be
impossible
to
detect
spurious
carrier
packets
that
should
be
dropped.
F
So
when
a
client
first
joins
the
network,
the
clients
and
proxy
servers
exchange,
router,
solicitation
and
router
advertisement
messages
either
directly
or
via
proxy
middle
box.
F
So
when
a
client
sends
an
rs
message
to
proxy
server,
a
with
either
all
routers
multicast
or
the
administrative
link,
local
address
of
a
as
the
destination
proxy
server,
a
assumes
the
router
role
and
returns
a
unicast
router
advertisement
message,
while
injecting
the
client's
mobile
network
prefix
into
the
aero
omni
routing
system.
This
is
the
atm
bgp
routing
system
that
we
refer
to
into
the
working
group
document.
F
So
what
this
looks
like
in
terms
of
the
figure
here,
we
have
a
client
that
connects
through
three
underlying
interfaces.
Again,
this
is
could
be
within
a
single
internetwork
or
across
multiple
internetworks.
F
The
first
proxy
server,
that's
coordinated
with,
which
is
shown
in
the
lower
portion
of
the
diagram,
becomes
the
hub
proxy
server
and
again
it
will
act
as
an
ipv6
router
and
a
mobility
anchor
point.
The
remaining
proxy
servers
are
instead
enlisted
in
proxy
mode,
where
they
forward
a
proxied
version
of
the
router
solicitation
message
to
the
to
the
hub
proxy
server
and
access
proxies
instead
of
routers.
F
Once
it
receives
a
neighbor
advertisement
for
address
resolution,
it
would
then
have
the
underlying
interface
for
the
the
target
client
that
it
wants
to
communicate
with.
So
the
secured
spanning
tree
delivers
the
neighbor
solicitation
to
the
target's
client's
hub
proxy
server,
which
returns
a
neighbor
advertisement
message
with
multi-link
link
layer,
addressing
information
for
the
target.
F
When
the
target
receives
the
ns
of
nud,
it
retains
a
neighbor
advertisement
message
of
nud
to
populate
the
reverse
path
state
and
to
confirm
that
the
bidirectional
state
information
has
been
established
now.
Also
during
this
nsna
of
nut
exchange,
both
standard
receive
identification
windows
are
established
with
acceptable
carrier
packet.
Identification
value
ranges.
F
F
Optimization
so
the
multi-link
forwarding
parameters
block
is
essentially
a
a
blank
slate,
that's
included
by
the
source
that
sends
the
neighbor
solicitation
message
with
for
for
neighbor
unreachable
detection.
It's
an
omni's
option,
sub
option
with
type
3.
It
includes
first
hop
segment
and
last
top
segment
parameters
with
associated
forward
mode
type
and
segment
routing
topology
codes,
the
first
top
segment
and
laptop
segment
parameters
include
a
client,
udp
port
and
internet
address,
a
proxy
server
mobility
service
id
and
address,
and
a
bridge
mobility
service
id
internet
address.
F
It
also
includes
a
list
of
up
to
five
abm
fi,
mfvi's
established
at
each
first
top
segment,
last
top
segment
path
and
then,
finally,
a
and
b
indexes,
plus
a
two
bit
job
code
that
tells
the
proxy
servers
and
and
bridges
in
the
path.
What
the?
What
the
role
of
this
ns
or
any
message
is
in
establishing
the
mfbi
state.
F
So
when
an
arrow
omni
node
creates
an
mfv
that
records
the
ol
source
and
destination
ualas
and
records,
two
32-bit
multi-length
14
vector
indexes,
one
is
a
local,
a
which
is
for
the
forward
path,
and
one
is
a
local
b,
which
is
the
reverse
path
mfei
and
it
also
records
any
next
top
am
fbis
or
any
previous
hop
b.
Mfvi's,
the
local,
a
b
m
f
b
I's
must
be
assured.
F
Node
local,
unique
through
the
example,
a
32-bit
random
number
generation,
while
testing
for
local
uniqueness,
but
they
need
not
be
unique
among
other
aero
omni
nodes,
so
to
be
very
clear:
mfeis
are
not
ip
addresses,
they're,
not
m
pls
labels,
they're,
not
autonomous
system
numbers
they're,
not
security,
parameter
indexes
or
any
of
that
type
of
thing.
That
is
typically
seen
in
internet
working,
they're,
simply
unique:
local
32-bit
integers
that
are
no
local,
unique
scope.
F
So
when
an
error,
omni
node
processes,
an
nsf,
nud
message,
it
creates
an
mfv
generates
a
local
bmfi
while
recording
its
information
in
the
multi-link
forwarding
parameters
and
then
forwards
the
ns
of
none
to
the
next
top
towards
the
target,
and
this
forwarding
is
going
to
be
doing
done
at
a
layer
two
by
the
way,
it's
not
a
layer
three,
so
that
the
the
ttl
hop
limit
of
dns
is
not
going
to
be
decremented.
When
it's
forwarded,
when
the
next
top
arrow
omni
node
receives
the
ns
of
none.
F
It
creates
a
multi-link
fluorine
vector
caches
the
previous
hop
b
value
and
generates
a
local
b
m
fbi
and
forges
above
then
when.
Finally,
the
final
hop
arrow
omni
node
receives
the
ns
of
nut.
It
discovers
the
full
map
of
the
previous
hop
nodes,
along
with
the
b
values
for
all
the
previous
hop
nodes.
F
So
then,
finally,
the
final
hop
arrow
omni
node
receives
the
ns
of
nut
and
creates
the
multi-link
forwarding
vector,
assigns
a
unique
local.
Am
fbi
then,
generates
a
neighbor
advertisement
of
nut
and
returns
it
to
the
towards
the
original
source
by
following
the
reverse
chain
of
bmfis,
created
through
the
anus
of
nud.
F
When
a
previous
hop
air
omni
node
receives
the
nmd
it
locates,
the
mfv,
based
on
the
cache
b,
mfvi
caches,
the
next
top
a
mfbi
and
a
c
assigns
a
unique
local,
am
fei
and
then,
finally,
when
the
first
top
error,
omni
node
receives
the
n
a
of
nud.
It
discovers
the
full
map
of
next
top
nodes,
along
with
the
a
values
for
all
hops,
on
the
path
to
the
target.
F
F
We
have
the
first
top
segment
proxy
server,
the
first
top
segment
bridge,
and
then
we
have
the
segment
routing
topology
spanning
tree
that
could
could
span
potentially
many
segments
along
the
way
to
the
final
segment,
which
is
known
as
the
last
top
segment.
The
last
top
segment
connects
to
the
spanning
tree
by
the
last
stop
segment
bridge.
F
Then
the
last
top
segment,
proxy
server
and
finally,
the
last
top
segment
client.
So
what
would
happen
is
that
the
first
top
segment
client
would
create
a
neighbor
solicitation
message
for
neighbor.
Unreachability
detection
include
a
multi-link
forwarding,
parameter
block
and
create
a
b
local
value
b,
a
b
local
mfbi
value.
F
It
would
then,
for
the
neighbor
solicitation
message
to
its
first
top
segment:
proxy
server,
which
would
record
the
b
of
the
previous
hop
as
the
b
out
value
and
also
create
a
unique
local
b
n
value
and
the
the
the
the
vector
would
point
backwards
towards
the
f,
the
first
top
six
segment
client
as
the
previous
hop
that
sent
the
neighbor
solicitation
message
and
then
the
first
top
segment
proxy
server
forwards,
dns
to
the
first
top
segment
bridge,
which
does
the
same
thing
records
the
b
value.
F
It
recruits
a
pointer
to
the
previous
hop
and
creates
a
bn
value.
The
bridge
then
forwards
the
neighbor
solicitation
message
into
the
spanning
tree,
where
it
will
take
strict
spanning
tree
hops
using
ip
address,
based
forwarding
until
it
arrives
at
the
last
hop
segment
proxy
ser
bridge,
which
again
creates
a
b
out
and
a
vector
to
the
previous
hop
and
a
bn
value,
and
that
then
forwards
the
neighbor
solicitation
message
to
the
last
top
segment
proxy
server
and
then
finally,
to
the
last
stop
segment
client.
F
F
So
after
the
ab
mfbis
have
been
established,
oal
peers
can
begin
sending
carrier
packets,
while
emitting
significant
portions
of
the
oil
header
fragment
header
and
the
compressed
rodney
header
32,
used
for
by
using
the
omni
compressed
header
type,
0
or
type
1..
The
omni
compressed
header
type,
zero
type.
One
includes
the
a
or
b
m
fbis
for
the
next
top
arrow
omni
node.
F
F
So
after
the
mfvi's
have
been
established,
oil
peers
will
exchange
additional
ns
and
na
of
nud
mission
messages
before
reachable
time
expires
to
keep
the
soft
state
alive.
If
the
reachable
time
expires,
the
euro
omni
nodes
simply
garbage
collect
the
mfvi's
and
future
nsa
n.
A
of
nut
exchanges
would
be
needed
to
re-establish
new
mfvs.
F
F
F
Now,
normally,
what
happens
is
that
the
packets
will
go
to
each
node
in
the
path
without
skipping
any
of
the
nodes.
However,
that
provides
more
work
than
is
necessary,
especially
on
the
proxy
servers,
and
so
it
would
be
very
useful
to
have
a
route
optimization
that
can
eliminate
unnecessary
nodes
from
the
path.
F
So
after
the
route
optimization,
the
first
top
segment
client
can
send
to
the
first
top
segment
bridge,
while,
while
skipping
the
first
top
segment
proxy
server
and
the
reason
they
can
do.
This
is
because
the
client
and
the
bridge
are
within
the
same
segment,
which
is
that
they
can
use
encapsulation
to
talk
to
each
other
without
having
to
go
through
the
proxy
servers.
F
F
That's
both
the
first
top
segment
and
last
top
segment
bridge
now
again
before
route
optimization,
we
would
be
going
through
proxy
servers,
but
after
route
optimization,
the
first
top
segment
client
can
go
to
the
first
stop
segment
laptop
segment
bridge
to
the
last
stop
segment
client
without
without
going
through
proxy
servers
and
then,
finally,
after
client-to-client
route
optimization,
we
can
have
the
first
top
segment
client
speaking
directly
to
the
last
top
segment
client
without
involving
any
infrastructure
elements,
neither
proxy
servers
or
bridges.
F
Each
client
naturally
establishes
nap
mappings
when
it
performs
an
rsxr
exchange
with
its
first
top
proxy
server,
but
these
mappings
generally
are
not
viable
for
client
exchanges
with
other
air
omni
nodes,
since
the
other
omni
nodes
would
not
be
using
the
same
encapsulation
source
address
and
destination
addresses.
As
for
the
proxy
server.
F
So
after
clients
have
gone
through
this
route,
optimization
they've
gotten
the
shortest
paths
possible
by
avoiding
spanning
tree
paths,
they
may
at
a
later
time
change
their
underlying
network
connection
points,
for
example,
changing
their
their
addresses
so
that
hub
proxy
servers
will
announce.
Client
state
changes
again
based
on
a
mobility
related
address,
change,
based
on
link
quality
changes,
track
traffic,
selector
changes
and
other
things
that
would
affect
the
client's
reachability
and
they
they
announced.
F
These
changes
by
sending
unsolicited
neighbor
advertisement
messages
to
all
nodes
that
it
has
recently
sent
a
neighbor
advertisement
for
address
resolution
solution
to
when
these
nodes
receive
the
unas.
They
update
their
state
information
for
the
client
and
that
may
require
them
to
issue
new
nsfna
nud
path,
state
exchanges
which
is
okay,
because
the
nodes
will
be
able
to
track
the
mobile
client
even
as
it
moves
the
new
hub
proxy
servers
send
unas
to
inform
all
proxy
servers
that
the
client
has
departed.
F
So
when
an
old
hoppy
hub
proxy
server
receives
an
unknown
una
saying
that
the
client
has
departed,
it
records
the
new
hub
proxy
server.
Lla
withdraws
the
mnp
route
and
forwards
the
una's
to
any
nodes
that
has
recently
sent
an
na2
now
target
nodes
can
request
selective
link
layer
transmissions
by
sending
unassociated
advertisements
to
the
source,
with
the
identifications
and
oral
fragment
numbers
of
any
missing
fragments
when
the
source
node
receives
these
unas,
it
retransmits
the
requested
fragments,
if
it
still
has
them
its
retransmission
cache.
F
However,
this
is
a
link
link
layer,
re-transmission,
it's
not
an
end-to-end
re-transmission,
so
the
re-transmission
window
should
be
brief
and
that
the
the
period
of
retransmission
determines
what's
known
as
the
link
persistence.
It's
not
a
perfect
reliability
mechanism.
It's
it's
simply
there
to
fill
in
opportunistically.
If
fragments
can
be
retransmitted
that
were
somehow
lost
before
the
link
persistence
window
window.
F
F
So
again,
the
simple
bgp
based
mobile
routing
system
for
the
aeronautical
telecommunications
network
is
work.
That's
ready
for
iatf
writing.
Working
group
last
call
automatic,
extended
route,
optimization
we're
asking
to
be
adopted
as
an
ietf
routing
working
group,
working
group
item
and
transmission
of
ip
packets
overlay
multi-link
network
interfaces
again
we're
asking
to
adopt
as
an
ietf
routing
working
group
working
group
item.
D
So
we
just
hello,
we
just
want
to
point
out
right
now
the
arrow
and
the
omni
drafts,
and
they
were
discussed
in
six
men
and
now
they
are
under
ise.
They
independent
stream.
F
I
I
see
adrian
farrell
on
the
call
adrian.
Would
it
be
fair
for
me
to
ask
you
to
say
something
about
the
status
of
these
documents.
G
So
after
some
back
and
forth
in
history,
fred
brought
these
documents
to
me
as
independent
stream
editor,
because
I
think
it's
fair
to
say
he
was
finding
it
hard
to
get
traction
in
the
ietf
and
that
makes
the
independent
stream
a
potential
publication
venue.
G
G
G
I
prefer
that
to
publishing
them
in
the
independent
stream,
but
that
doesn't
mean
that
I'm
slamming
any
doors
the
documents
at
the
moment
are
flagged
as
being
in
the
independent
stream,
and
that's
purely
just
because
that's
how
they
are
in
the
data
tracker.
I
could
turn
off
that
flag
at
any
time
and
certainly
if
a
working
group
shows
that
it
wants
to
talk
about
it
not
necessarily
adopt
yet
but
at
least
talk
about
the
work,
then
that
would
be
the
appropriate
thing
to
do.
I
hope
that's
clear.
H
A
D
The
omnidroid
needs
a
change
in
ipv6
packet,
so
that
one
certainly
needs
to
be
discussed
in
six
months.
The
change
to
the
ipv6
packet
at
that
level
doesn't
belong
to
rtcwt.
That's
one
of
the
issues
I
see.
F
When
you
say
changes
to
the
ipv6
packet,
are
you
referring
to
the
new
omni
option?
Is
that
the
piece
that
you're
you're
asking
about.
A
More
from
kind
of
process
perspective,
those
are
large
documents
and
in
order
to
progress
them
in
routing,
really
need
to
see
willingness
of
working
group
to
participate
in
discussion
looking
into
it
and
at
least
from
what
I
gather
from
people
here
on
the
meeting,
I
don't
really
see
significant
interest
in
progress
and
routing.
Obviously
we
will
call
mailing
please,
because
not
everybody
who
is
participating
routing
is
here,
but
practically
interested
people
to
work
on
it
would
be
pre-requirement
to
progress
document
in
rtwg.
I
F
However,
it's
a
a
separate
bgp
instance
that
does
not
interact
with
the
internet
bgp
routing
system
in
any
way,
it's
its
own
overlay
instance,
and
it's
it's
working
based
on
ipv6,
is
using
standard,
ipv6
routing,
so
there's
not
really
any
changes
to
routing
protocols
and
then
any
inter
domain
routing
protocols,
your
ospf's
or
or
rip
or
whatever
might
happen
to
be.
There
operate
as
they
always
have.
An
omni
in
aero,
don't
interact
with
those
in
any
way.
I
So
the
bgp
running
among
those
omni
nodes
are
separate
instance
from
the
underline
right.
So
is
there
any
any
portable
extension
needed
to
run
this
overlay
dcp
slices
or
instances.
F
No,
in
fact,
I
I've
got
this
set
up
in
a
in
in
demonstration
networks
where
I'm
using
standard,
quagga,
routing,
zebra
quagga
routing
that
with
no
ext
with
no
changes
whatsoever,
it's
it
simply
injects
the
ipv6
unique
local
address
prefixes
into
the
bgp
routing
protocol
and
and
standard
bgp
routing
is
used.
A
So,
since
there's
no
more
questions,
I
think
we'll
take
it
to
the
list
and
discuss
it
among
participants
in
routine
working
group
as
well
as
probably
with
adrian
and
we'll
take
it
from
there.
D
J
J
Actually
we
have
introduced
this
work
in
rtg
for
several
times,
so
I
think
most
of
people
will
be
familiar
with
this
work.
I
won't
go
to
details
about
the
the
motivations
and
goals
again.
Basically,
this
document
introduces
srv6
midpoint
protection
mechanisms
when
the
services
endpoint
fails
and
srv6
proxy
forwarding
node
can
replace
the
segment
of
the
failed
endpoint
to
the
next
segment
to
provide
local
protection
for
the
end
point
and
next
slide.
Please.
J
So
it
will
perform
the
proxy
for
wording
and
send
packet
to
next
available
endpoint
in
the
segment
list
in
the
sec
second
period
after
igp
convergence,
any
upstream
node
that
has
been
converged
and
deleted
the
fit
to
the
failed
node
will
be
the
repair
node
and
perform
the
proxy
forwarding.
J
J
In
the
document
we
specifies
the
srvs's
midpoint
protection
behavior
in
some
cases
is
divided
about
when
to
trigger
the
behavior,
but
the
the
behavior
itself
is
similar.
The
the
second
left
decreases
updates
the
ipv6
destination
address
with
the
srh
segment
left
in
that
case,
and
the
fee
blue
cap
on
the
updated
destination
address
for
word
packet
according
to
the
matched
entry.
J
Here
is
a
very
brief
review
overview
of
the
history
of
the
draft.
In
the
first
two
versions,
the
mechanisms
is
defined
and
in
the
second
in
version
o2,
we
update
section,
6
and
consider
security
consideration
and
specifies
that
the
srv6
midpoint
midpoint
protection
can
only
be
excluded
when
the
repair
node
and
the
failed
endpoint
are
in
the
same
srvss
domain
and
in
version
03.
J
We
update
section
5
according
to
the
discussion
in
the
main
list
of
spring
working
group,
and
explains
that
in
some
use
cases
the
endpoint
can't
be
bypassed,
and
maybe
some
other
document
will
help
to
handle
this
case
and,
in
the
last
two
case
versions,
version
o4
and
version
o5.
We
modify
the
test
and
end
a
new
co-order.
Thank
you.
Thank
you
for
the
contribution
of
the
new
co-order
from
channel
mobile
on
next
page.
J
Please,
actually
in
this
ietf,
we
we
think
the
document
is
stable
and
has
been
fully
discussed
and
based
on
the
the
suggestion
of
the
working
group
in
last
itf.
We
bring
the
work
to
spring
working
group
and
we
collect.
We
have
collected
some
feedback
in
spring.
Working
group.
Here
are
the
the
discussions
in
on
monday
in
the
session
of
spring.
J
The
first
one
is
how
to
deal
with
the
case
that,
when
the
segment
of
the
next
endpoint
is
also
failed,
actually
the
process
can
be
iterated.
There
will
be
another
repair
node,
that's
the
proxy
for
wording
to
skip
the
second
field
node
until
the
the
reachable
endpoint
is
selected
or
the
segment
is
lost
in
the
assembly
list.
J
We
believe
that
local,
the
repair
solution
could
provide
could
provide
faster
protection
mechanisms
than
the
end-to-end
solution
and
in
some
cases
this
is
requested,
and
another
question
from
spring
is
when
the
repair
node
is
a
transient
node.
It
may
be
against
rfc
a200,
which
won't
allow
the
transient
node
to
modify
srh.
J
To
solve
this
problem,
we
have
sent
an
email
to
six
mem
analysts
and
also
actually
the
section
six
security
considerations,
as
I
have
mentioned
before,
is
trying
to
solve
the
problem,
and
we
propose
to
check
that
the
skipped
segment
belongs
to
the
same
block
as
the
repair
node.
First,
to
guarantee
that
they
are
in
the
same
trusted
domain
before
doing
the
proxy
forwarding
defining
this
document,
so
we
think
the
transit
node
is
could
be
trusted
in
this
case
and
after
all,
the
modification
and
work
and
discussions.
B
J
J
B
Talked
about
proxy
forwarding
and
authors
co-authors
seem
to
be
the
same.
So
I'm
trying
to
understand.
J
J
The
first
document
you
mentioned
is
to
to
actually
advertise
the
capability
of
some
nodes
that
could
do
the
proxy
forwarding,
but
this
document
this
defines
the
how
to
do
the
proxy
forwarding.
So
with
the
first
document,
it
will
help
to
make
this
document
work,
but
without
that
it's
it
still
work.
This
is
independent
work.
B
J
Yes,
kind
of
that
document
solved
problem
in
srmps
network
and
this
document
defines
the
similar
mechanisms.
You
know
srv6
network.
B
Okay,
but
I
mean,
but
I
think
the
proxy
forwarding
proposal,
so
it
would
help
if
you
could
clarify
these,
perhaps
in
the
draft,
because
the
same
authors
are
saying
that
the
version
which
is
adopted
is
not
good
or
okay
and
there
there
is
a
proposal
for
proxy
forwarding
base
being
a
better
mechanism.
B
J
K
Yeah
so
as
I
think,
the
the
one
in
the
spring
group
is
mostly
focused
on
the
airsoft
emptiness,
but
this
one
is
focused
on
srv6.
So
that's
the
one.
That's
the
major
difference.
B
B
Okay,
I
I
think
we
can
take
it
further
on
the
list.
Yeah
yeah,
okay,
okay,
but
it
would
be
good
to
clarify
this
can
be
clarified
because
yeah
yeah.
B
A
Yeah
and
it's
still
up
to
chairs-
and
we
are
in
discussion
with
spring
chairs,
where
to
keep
fast
conversions
documents,
how
to
progress
them
together,
because
I
mean
from
formally
it
doesn't
make
sense
to
keep
the
services
in
one
place
while
the
pls
another
I'm
talking
about
same
technology
right.
So
I
agree
with
skating
comments.
J
So
jeff
is,
if
I
understand
this
right,
we
still
we
still
supposed
to
wait
for
the
results
of
the
discussion
to
yeah.
A
D
Yeah,
please
make
sure.
M
C
J
J
Because
the
the
problem
of
the
working
group
discussion
has
lasted
for
several
meetings
last
one
and
the
one
before
last
one.
So
we
think
this
is
not
the
reason
to
to
just
stop
the
progress
of
this
document.
If
people
think
the
the
document
is
reasonable,
and
this
document
has
already
been
discussed
in
spring
already,
I
think
no
matter
which
working
group
it
should
belong.
We
we
can
consider
to
adopt
a
document
if
we
think
the
the
mechanisms
is
reasonable
and
the
comments
from
people
have
already
been
addressed.
So
what
what
do
you
think?
J
Because
the
working
group
discussion,
the
the
home
of
the
document,
has
already
been
discussed
for
several
times.
D
D
I
also
feel
this
should
be
together,
not
one
in
rtcwc
and
the
other
in
spring,
but
we
can
resolve
this
offline
on
the
list.
D
So,
if
no
more
questions
we
go
to
the
next.
L
Okay,
so
hello,
everyone
good
afternoon,
good
morning
or
good
evening,
based
on
wherever
you
are,
I'm
going
to
present
the
extension
of
transport
network,
our
mobility
in
the
data
network,
on
behalf
of
the
other
authors.
L
Just
a
quick
recap
from
itf
109
and
the
background,
so
this
draft
was
originally
presented
in
the
itf-109
as
a
quick
background.
The
existing
transport
network,
our
mobility
for
5g,
defines
a
framework
for
mapping
that
5g
mobile
systems,
slice
and
service
types
to
the
corresponding
underlying
paths,
but
the
focus
of
that
work
is
limited
in
the
mobility
domain,
so
now
to
maintain
that
end-to-end
network
characteristics,
the
framework
needs
to
be
expanded
beyond
the
upf
in
the
data
network.
L
So
this
proposed
draft
kind
of
defines
a
framework
for
extending
that
mobility.
Our
transport
network
characteristics
from
the
upf
to
the
data
network,
so
the
figure
below
kind
of
represents
that,
like
the
left
hand
side,
we
see
the
mobile
mobility
network
is
represented
by
the
dnr
mobility
dropped
and
where
the
right
hand
side
is
represented
by
this
proposed
dropped.
L
L
The
next
slide
on
the
packet
transitions
from
mobile
network
to
the
data
network.
There
are
two
scenarios
exist
here.
The
first
scenario
is
how
the
upf
is
part
of
the
hcp
node,
and
in
that
case,
local
policy
could
be
configured
in
the
node
itself,
where
that
mobility,
sst
udp
source
port,
could
be
transferred
to
the
local
cpu
node.
So
that's
the
first
scenario.
L
The
second
scenario
in
the
upf
and
the
hcp
node
are
connected
through
a
ip
network
and
in
that
case
also
a
local
policy
could
be
configured
and
the
udp
source
port
carried
by
the
original
udp
header
in
the
mobile
network
that
can
be
transferred
over
some
transport
header,
based
on
the
operator
choice
in
the
cpe
node.
So
either
one
of
these
kind
of
approaches
in
a
data
plane,
wave
method
that
we
transferred
the
transport
characteristics
in
the
data
network.
L
Now,
once
we
transfer
the
network
characteristics
in
the
data
network,
we,
the
next
mechanism,
comes
like
how
it
would
be
mapped
in
that
in
the
using
a
different
mechanism
to
maintain
that
same
characteristics.
So
there
are
different
scenarios
and
different
mechanism
for
that.
The
first
three
scenarios
we
already
discussed
in
the
earlier
itf:
it's
a
bgp,
srt
controller,
driven
approach.
The
first
scenario.
L
The
second
is
the
odn
srt
policy
based
approach,
and
the
third
is
same
srt
controller
over
wrist
grpc
session,
and
that
will
be
providing
the
mapping
and
the
fourth
one
is
the
new
addition
to
the
flow
spec
controller
and
and
that
kind
of
use
the
mapping
using
the
indirection
id
technique.
So
we'll
go
over
it.
L
So
the
next
again
just
a
quick
recap
from
that
109,
the
bgp
srt
policy
for
tnr
mobility.
The
way
it
works.
The
ingress
node
will
have
a
bgpsr
policy
session
with
the
srt
controller
and
the
controller
would
be
provisioned
for
the
different
ssd,
specific
source
port
range
and
the
corresponding
te
policies
and
the
binding
seed.
Those
would
be
downloaded
by
the
srt
policy
policy
beta
and
sub
dlvs,
along
with
a
5g
metadata
sub
tlp,
which
we
introduced
last
time
that
carries
the
udp
source
port
range.
L
Now,
when
the
packet
comes
from
the
uv
side
to
the
ingress
node
and
using
one
of
the
technique,
that's
kind
of
the
back.
The
characteristics
is
transparent,
the
in
the
source,
port
udp
source
port.
If
it
falls
within
that
udp
source
port
range,
the
corresponding
sr
policy
would
be
applied
to
maintain
that
characteristics.
It
would
be
redirected
to
one
of
that
path
like
for
urlc
traffic.
L
If
the
the
source
port
comes
with
the
urlc
range,
and
it's
mapped
to
that
policy
path,
it
would
be
redirected
to
maybe
hdc
for
miot
could
be
as
soon
and
the
pacific
policy
could
redirect
to
a
public
cloud
or
embb.
It
would
be
private
dc.
So
here
is
the
kind
of
way
it
will
use
the
bgpsrt
policy
for
the
mapping.
If
there
is
no
binding
sheet
or
the
policy
found
for
a
specific
source
port,
then
it
will
take
a
best
effort
path.
L
L
L
L
Here
again,
the
with
the
the
controller
is
flow,
spec
controller,
having
a
session
prospections
with
the
ingress
node
and
again,
the
controller
is
provisioned
with
a
different
udp
source
port
range,
corresponding
to
the
different
ssds
and
the
with
that
corresponding
mapping
is
the
here
generalized
indirection
id,
so
the
slow
spec
in
lri
would
be
downloading
the
udp
source
port
range
to
the
ingress
node,
along
with
the
action
for
the
extended
in
the
action
for
the
indirection
id
in
the
extended
community.
L
That
would
be
redirected
to
a
specific
policy
which
will
be
back
to
a
transportator
and
take
it
to
that
one
of
the
path
url
cmit
or
embb,
as
we
kind
of
see
it
here,
just
a
note
here
again,
there
is
a
new
draft.
He
is
proposed
in
the
idr
that
would
be
presented
in
friday.
So
if
there
is
a
more
granular
flow,
then
if
the
traffic
redirections
will
be
happen
based
on
whatever
is
described
in
the
ideal
prospecting,
our
mobility
draft.
L
So
here
we
are
covering
that
specific
ssd
range
and
it's
kind
of
a
as
long
as
the
udp
source
port
belongs
to
that
certain
range
like
it
would
be
redirected
based
on
the
flow
spec.
So
it's
kind
of
in
a
way
it
gives
operator
good
choices
among
all
the
methods
kind
of
there.
The
way
you
try
to
map
in
the
ingress
node
either
closed
back
or
bgp
srt
policy
or
srt
odn
driven
approach,
or
even
the
the
grpc
netcon
with
a
city
controller.
L
So
I'm
not
going
all
the
approaches,
because
it's
kind
of
those
are
there
is
no
change
on
those
from
the
previous
presentations.
L
Next
part
is
the
extending
that
transport
network,
our
network
characteristics
to
for
the
sd-wan
network,
and
if
the
sd-wan
network
is
presented
here
based
on
the
bgp
sd-wan
use
case
dropped,
there
are
cpe
node
and
the
2cp
nodes
are
presented,
and
it's
in
the
case
of
hybrid
sd-wan
scenarios,
there
would
be
ipsec
case
a
tunnel
between
the
nodes
and
there
would
be
also
maybe
low
latency
path
using
a
mpls
over
gre.
L
L
Here
the
dmm
drop
is
expanded
to
convert
the
security
characteristics
under
each
ssds,
so
the
sub
ranges
are
located
under
each
ssd
to
have
the
security
characteristics.
So
when
that
kind
of
free
ui
traffic
comes
to
the
the
sdo
and
cph
node,
that's
based
on
the
security
characteristics,
it's
given
a
priority.
It
would
be
mapped
to
a
certain
ipsec
essay
tunnel
between
the
branch-to-branch
communication,
because
in
the
sd-wan
deployment
the
security
takes
a
priority,
and
generally
they
have
the
ipsec
tunnels.
L
If
the,
if
we
see
any
traffic
coming
from
the
ue
side-
and
let's
say
you
are
llc
traffic
without
any
security
characteristics,
then
if
we
have
a
path
for
let's
say,
mpls
over
gre
path,
that
could
be
redirected
over
that
path.
L
So
that's
how
the
it
will
map
over
a
sd-wan
network,
but
I
also
kind
of
want
to
add
a
note
here
that,
in
the
specific
use
case
where
there
is
in
based
on
the
sd
when
use
case
drop,
private
vpn
pe
based
is
demand
use
case.
L
The
p
could
be
kind
of
initiating
the
sd-wan
tunnel
and
the
ps
are
the
vpn
ps
are
connected
to
rr
and
they
could
have
a
sd
internal,
and,
in
that
case,
like
again
besides
that
connections
to
the
r
controller,
they
could,
the
ingress
p
node
could
have
a
connections
to
that
srt
controller,
and
in
that
case,
that
mechanism
we
saw
the
previous
mechanism
would
be
applied.
On
top
of
that
security
header.
L
L
L
At
this
point,
we
kind
of
request
for
what
group
adoption
and
we'll
continue
to
update
based
on
the
feedback.
Another
quick
note
I
forgot
to
mention
in
that
in
this
slide
that
for
the
bgp
srpc
odn
based
integrations,
there
are
new
metric
tribe.
Metric
types
are
used
for
the
metric
types
are
used
for
the
embp,
urlc
and
and
miot.
So
that's
need
to
be
expanded
in
the
precept
side.
So,
once
this
the
document
is
adapted,
we
can
plan
for
expanding
those
metric
type
in
the
pcip.
A
M
I'm
not
sure
that
it
may
be
my
problem.
I
have
not
understood
on
slide
six,
why
it's
about
udp
source
port,
because,
okay,
if
it's
udp,
why
not
tcp?
If
it's
a
subscriber
or
traffic
identification,
why
it's
not
a
tid
from
gdp?
I
don't!
Maybe
I
just
don't
know
properly
5g.
L
Okay,
so,
basically,
if
it
was
like
a
if
you
see
there
is
actually
let
me
go
back
to
this.
So
if
you
look
into
this,
there
is
a
existing
drop
in
the
dmm
and
that's
basically
trying
to
define
that
different
slice
and
service
types
like
for
the
miot
and
embb
and
urlc
and
that's
kind
of
allocated.
L
There
is
a
table
there
if
you
look
into
the
draft
so
that
allocates
a
different
udp
source
port
range
for
different
ssds
and
from
the
when
the
traffic
generally
and
that's
how
they
kind
of
may
try
to
maintain
that
specific
you
using
that
udp
source
port
range
to
maintain
the
characteristics
in
the
mobile
network.
They
understand
it's
super
it's
safe
for
miot
or
it
kind
of
a
mbb
or
urlc.
L
Now,
that's
that
range
is
basically
carried
over
udp
source
port
and
that's
basically
dictates
the
network
characteristics.
What
is
maintained
in
the
mobile
network?
So
now
that's
what
we
are
trying
to
carry
in
the
data
network
to
maintain
that's
the
only
informations
you
can
bring
it
pretty
much
from
the
gtp
side
or
the
mobile
side
of
the
network
to
the
in
the
data
network.
To
maintain
kind
of
a
end-to-end
ue
network
characteristics,
so
that's
why
we
are
not
kind
of
adding
any
extra
field.
M
But
this
draft
looks
like
from
atf,
probably
because
it's
related
to
base
station-
probably
it
should
be
on
three
gp
site.
Probably
it
should
be
some
some
draft
or
or
do
they
have
acceptance
from
3gbp
because
you're
asking
effectively
special
functionality
from
png
over
from
from
from
base
node
from
innodba.
But
it's
it's
3gbp
stuff.
It's
not
itf!.
L
None
so
the
drop
is
accepted.
Let
me
go
back
to
the
previous
slide,
so
the
drop
is
is
accepted
in
the
dmm,
so
only
information
it's
carrying.
I
wish
yeah
that
we
had
that
the
ssd
range,
but
the
only
information
is
carrying
is
that
in
the
udp
header,
it's
nothing.
We
are
bringing
from
the
gtp
header
or
anything
from
the
ue
specifics.
L
Only
informations
we
are
bringing
here
the
there
is
a
udp
source
port
which
is
kind
of
given
for
a
specific
ssd
range,
so
that
informations
we
are
bringing
to
the
transport
header.
I
don't
think
that's
depends
on
the
3gpp,
because
that's
a
udp
header
kind
of
dictates
the
network
characteristics
in
the
mobile
network
and
that
informations
we
are
bringing
in
a
loosely
coupled
way
to
to
the
data
network
side.
A
L
N
N
Perhaps
3gpp
is
there
any
opinion
from
the
gpp
side
to
use
what
kind
of
which
fields
in
the
package
to
map
to
the
the
service
and
slice
of
service
types
either,
and
if.
L
Yeah,
so
so,
if
you
see
that
we
are
not
kind
of
directly
bringing
the
gtpu
header
like
just,
we
are
not
propagating,
that's
like.
Obviously,
if
it
is
a
teid
or
some
kind
of
informations
from
the
gtb
header
that
we
cannot
propagate
that's
the
kind
of
context
we
are
not
proposing
to
bring
into
the
data
network.
We
are
all
just
bringing
kind
of
that's
udp
header,
the
source,
port
and
kind
of,
even
not
even
saying
that
the
same
header
would
be
carried
right
like
any
type
of
transport
header.
L
It
can
be
carried
into
the
data
network
side,
so
I
think
means
in
terms
of
means
the
I
don't
know
whether
rumor
is
there
but
like.
I
think
we
have
internally
reviewed.
I
don't
see
that
say
any
ish
causing
any
issues
from
the
3gpp
side
linda.
If
you
are
here,
do
you
want
to
comment
on
that.
I
Yeah,
I
just
want
to
add
a
few
comments.
Actually
I
wrote
that
on
the
chat
to
chat
window,
so
basically
the
gdp
tunnel
head
is
udp
based
and
there
are
a
couple
of
ways
for
the
5g
to
propagate
some
of
the
information
to
the
local
data
network.
So
supposedly
like
this
would
be
a
controller.
They
could
have
informed
our
ip
network
outside
upf,
the
udp
core
is
being
used
by
the
gdp
panel.
I
That's
one
method
and
another
method
is
when
you,
the
traffic,
comes
to
the
ingress
node,
our
cpe
node,
and
between
the
cpu
node
to
the
edge
data
center.
There
could
be
another
layer
of
transport
header
and
that
transport
header
could
continue
using
a
similar
port
range,
as
used
by
the
5g,
to
ensure
the
end-to-end
quality
of
the
surface.
So
with
that,
we
could
also
reuse
some
of
the
udp
port
from
use
within
the
the
mobile
network,
which
is
on
different
header.
Instead
of
you
had
a
tunnel
header
and
use
another
layer
of
transport.
N
A
Yeah,
it
is
an
option
and
now
without
share
head
on
intriguing,
for
this
option
had
been
used
extensively.
If
we
look
10
12
years
back,
it
has
been
deployed
this
way
in
a
lot
of
different
places.
So
it's
not
really
a
new
way
of
doing
it.
So
you
just
copy.
A
O
The
first
one
is:
does
the
work
define
a
set
of
mapping
between
the
mobile
network
to
the
I'll,
say,
data
network
resources
right.
O
L
O
Yeah,
the
second
one
is:
is
it
any
implementation
yet.
L
So
the
second
one:
what
is
the
question?
Is
there
any
implementation?
Already?
Okay?
So
no!
Currently,
I
don't
think
we
have
any
implementations
ready,
it's
kind
of
giving
a
different
choices
to
the
operator
like
a
based
on
the
network
deployment.
We
can
pick
one
of
the
one
of
the
mechanism,
but
the
currently,
I
don't
think
we
have
any
implementations
yet.
A
P
Kind
of
all
over
there
there's
like
four
different
options
for
for
for
doing
this
kind
of
same
as
my
comments,
similar
to
chen's
and
sort
of
a
new
one,
the
flow
spec
controller.
I
guess
it
was
inevitable.
I
guess
this
is
what
flow
spec
v2
is
going
to
be.
It's
going
to
be
open
flow
at
layer
3..
P
What
is
other
than
the
overlap
of
offers?
What
is
the
tie-in
to
sd-wan?
P
Just
that
there
could
be
different.
There
could
be
requirement.
I
mean
it
doesn't
look
like
it's
handled
any
different
than
any
other
appleware.
You
know
any
appleware
flows.
It
doesn't
appear
to
me
that
5g
should
be
any
different
than
any
other
ones
that
are
in
a
in
back
of
an
sd-wan
or
run
over
an
sd-wan.
P
L
Yeah,
so
let
me
so
let
me
go
a
little
more
ac
on
that.
So
yeah
the
there
are
four
mechanisms
we
kind
of
kept
it
because
it's
a
first,
your
first
questions
regarding
what
kind
of
along
the
line,
what
chain
means,
and
it's
kind
of-
gives
a
option
to
the
operator
that
way
like
based
on
the
deployment.
They
can
choose
one
of
the
mechanism
to
maintain
the
characteristics.
L
That's
our
view
now
coming
back
to
the
sd-wan
network
like
if
we
see
that
any
sd-wan
based
on
the
sdn
use
case
dropped
and
the
deployment
scenarios,
especially
the
in
the
sdn
network,
in
a
hybrid
sd-wan,
there
would
be
kind
of
some
secure
tunnels
and
some
mpls
over
gre
link
could
be
between
the
two
branch-to-branch
communications
right,
and
in
that
case
the
main
main
important
thing
is
that
secure
communications
between
the
branch
or
the
cloud
gateway
and
if
we
now,
if
it's
uv
traffic
kind
of
a
land
in
the
one
of
the
cpe
node,
and
then
how
do
we
maintain
the
security
characteristics
if
we
other
than
kind
of
a
mapping
to
specific
srt
mechanism?
L
If
the
security
is
a
priority,
so
then
that
has
to
be
given
a
choice.
So
that's
one
of
the
reason
that
dropped
the
other
day.
Okay,.
P
L
You
agreed
but
yeah
for
esd1
case.
It
is
pretty
obvious,
like
between
the
branch
to
branch
traffic,
you
need
to
have
a
security,
and
although
you're
kind
of
saying
that,
if
there
is
a
security,
characteristics
comes
on
a
specific
traffic
from
the
ue,
so
that
would
be
given
a
priority
to
map
to
a
specifics,
ipsec
tunnel.
Otherwise
it
could
be
mapped
to
a
any.
You
are
means.
You
are
llc
traffic
and
in
this
case
this
is
basically
the
in
the.
L
If
you
see
the
sd-wan
deployment
there's
some
cases
there
are
really
ce.
Node
kind
of
there
are
two
sets
of
deployment
scenarios.
One
is
the
hybrid
sd-wan.
This
is
this.
P
P
I
Okay,
so
for
the
flow
stand,
there's
current
flows
back
for
redirect
to
ip
tunnel
and
srv6
tunnel
is
our
v6
path
and
the
flows
back
addition
is
to
add
another
type
of
tunnels,
which
is
ipsec
security
association
panel.
So
that's
how
like
sd1
one
in
using
that
special
additional
flow
spa.
A
I
think
we'll
cut
the
cue
here
practically
to
the
authors.
I
think
it
would
be
good
to
extend
the
draft
to
explain
the
mapping,
probably
even
starting
with
q5
4g
towers,
5
qi
in
5g
and
how
all
of
this
maps
and
how
qs
architecture
and
joint
would
look
like
it
would
make
understanding
of
the
draft
much
better,
because
I
see
the
questions
are
exactly
because
the
mapping
is
not
well
understood,
and
I
agree.
The
3gbp
part
is
rather
important
here.
L
Okay,
so
we'll
take
it
to
the
list
and
maybe
we'll
try
to
expand
based
on
the
comments,
so
please
feel
free
to
post
comments.
I
will
initiate
a
thread
and
please
feel
free
to
post
comments,
we'll
try
to
expand
based
on
that
we'll
expand
the
draft
accordingly.
L
H
And
because
just
actually
a
tiny
update
of
my
slides,
so
I'd
like
to
show
my
screen
by
myself.
H
Okay
is
my
screen
available
for
everyone.
H
H
D
H
H
H
H
H
Okay,
this
is
daniel
huang
and,
as
my
player,
to
make
the
presentation
of
the
drafts
on
behalf
of
the
officers
and
sorry.
M
A
H
H
H
H
The
draft
is
about
computing
delivery
in
routing
network,
actually
what
the
computing
delivery
means
is
might
be
confused
for
for
for
someone
in
this
community.
So
I
would
like
to
clarify
in
the
next
couple
of
slides.
H
D
D
H
H
Actually
about
computing
delivering
routing
network
is
not
new
topic
in
this
community
because
there's
during
the
past
two
years,
just
a
couple
of
impressive
jobs
which
have
been
discussed
in
the
past
conferences-
the
site
meetings
about
about
this.
So
there's
the
a
lot
of
use
cases,
problem
statements,
even
architecture,
so.
H
The
first
page
of
my
slides
is
not
exactly
the
use
case
that
I
simply
want
to
clarify
the
is
the
how
to
say
the
general
use
keystone
rationally
of
of
my
proposal
when
it
comes
to
the
centralized
computing
deployment.
H
You
know
the
extension
and
the
scheduling
of
the
computing
services
and
resources
by
the
application
system.
It
makes
more
sense
to
them
than
than
then
been
been
done
by
the
routing
network,
and
while
the
coordination
between
the
cloud
services,
services,
resources
and
networking
I
mean
route,
networking
could
be
cost
effective
because
of
the
scalability
and
the
intensity
under
the
centralized
computing
department
mode,
and
so,
as
far
as
the
centralized
computing
deployment,
the
use
case
stays
perfectly
within
the
computing
unaware
routing
architecture
as
the
routing
mechanism
right
now
works.
H
So
when
it
comes,
however,
when
it
comes
to
distributed
computing
deployment
mode
is
the
interconnection
among,
particularly
among
the
edge
at
computing
size,
is
in
a
different
shape
and
as
as
in
the
in
the
use
case,
drop
style.
H
I've
mentioned
illustrated:
there's
the
storm,
multiple
motivation
to
coordinate
the
computing
services
and
resources
to
mom
that
is,
distribute
the
nodes
and
make
them
make
them
as
to
the
kind
of
the
virtualized
the
computing
pool
to
to
bring
bring
back
benefits
to
a
lot
of
applications
and
services
and
use
cases.
H
So
that's
the
comparison
between
the
two
compute
and
deployment
mode.
Just
why
why
we
proposed
a
new
framework
about
computing
delivery
and
the
routing
network
and.
H
As
far
as
the
challenges
problems
and
problems
to
that
are
concerned,
because
the
routing
is
actually
an
inherently
addressing
system
in
terms
of
networking,
topology
and
decoupled
from
the
applications
in
the
in
the
cloud
and
well
routine
without
aggregation
is
an
important
and
in
an
indispensable
feature
of
the
routing
and
nevertheless
the
computing
resources
services
has
been
deployed
in
such
a
way
that
it
could
not
be
easily
aggregated
as
the
network
resources.
H
So
and
then
the
computing
intercollection
and
the
coordination
is
the
application
level,
as
as
the
as
the
practice
of
the
ongoing
in
industry,
lex
refined,
grains,
the
network
services,
just
as
the
summarization
of
the
problem
service
and
when
it
comes
to
challenges,
because
full
granularity,
computing
services
and
the
resources
to
status
in
routing
network
would
be
absolutely
in
the
disaster.
H
So
when
it
comes
to
the
computing
delivery
in
the
darting
network
and
mechanism,
so
the
the
computers
that
are
stingray
network
has
to
be
put
in
in
an
engineeringly
acceptable
way.
H
So
the
the
the
second
requirements
about
this
is
the
the
computing
and
ultra
mechanism
has
to
be
decoupled
from
an
ongoing
routing
network.
So
the
the
ruby
framework
of
the
computer
delivery
could
be
compatible
with
the
with
the
the
traditional
ip
and
launching
network
and
also
select
unlimited
routing
loads.
The
computing
aware,
while
the
rest
should
remain
as
to
the
all
and
which
is
computing
unaware.
H
So
the
first
part
of
of
the
framework
of
computer
delivery
in
the
routing
network
is
the
aggregation
of
computing
services
and
resources.
H
So
we
categorize
the
generally
the
the
computing
resources
teams
two
and
two
types:
one
is
the
global
computing
routing
nodes
where
the
general
computer
resources
and
service
terrorists
are
from
the
remote
computing
sites.
D
Sorry
to
interrupt
daniel,
we
are
still
seeing
your
second
slide
on
your
screen
is.
Are
you
still
talking
to
the
second
slide.
D
Your
slide
is
now
moving
and
we
are
now
seeing
the
presentation
mode
is.
We
are
seeing
the
editing
mode
if
you
have
multiple
screens.
C
H
Okay,
just
to
save
the
time
engine,
would
you
please
show
the
screen
for
me,
because
I'm
not
sure.
H
H
H
Okay,
thank
you,
but
I
I
do
not
stay
the
full
screen
nerve.
I
I
cannot
say
the
the
two
scares
then
the
button
somehow.
H
I
still
cannot
see
full
screen.
I
can
only
see
the
figure
and
about
30
30
percent.
The
the
squirrel.
D
D
For
me,
I
can
see
the
the
picture
and
the
two
text
box.
I
see.
H
H
Okay-
okay,
sorry,
sorry,
the
first
part
of
the
framework
proposer
of
my
our
draft
is
is
the
aggregation
of
computing,
our
services
and
resources.
We
categorize
the
the
the
the
the
routing
load
into
two
types
to
the
first
one.
We
would
like
to
record
the
global
computing
routing
nodes.
Well,
the
general
the
computing
resourcement
service,
the
host
from
the
remote,
the
computing
sites
will
be
maintained
and
well.
H
The
computing
global
computing
status
is
categorized
to
2bs
to
comparatively
stable
as
possible,
such
as
the
overall
gt,
gpu
and
cpu
occupation
rate
and
the
service
computing
services.
Types
are
available
in
the
specific
computing
sites
and
when
it
comes
to
local
computing
routing
nodes,
simply
simply
the
dynamic
computing
service,
such
as
to
the
instance.
Some
company
instances
were
virtual
machine.
The
host,
something
like
that
status
from
the
local
computing
sites
to
be
maintained
as
low
as
the
lucas
has,
which
worries
would
be
the
the
egress
node.
H
H
H
The
first,
the
first
segment
we
call
the
global
computing
routing
routing
segment
actually
is
simply
from
ingress
to
egress,
such
as,
as
illustrated
in
this
figure
r1,
as
the
ingress
will
select.
The
egress
in
terms
of
the
global
computing
stairs
maintained
the
edge
that
r1
as
the
demonstrated
in
the
previous
slide,
and
an
in-band
encapsulation
of
computing
service
and
resources
is
delivered
to
the
egress
in
an
overlay
and
hollow,
and
the
traffic
affiliate
is
the
guaranteed
by
combining
the
five
tuples
and
the
egress.
H
When
it
comes
to
the
another
routing
segment,
we
call
the
local
computing
routing
segment
through
the
imbalanced
computing
service
and
resource
encapsulation
and
the
local
computing
standards.
A
service
to
specific
service,
to
instance
such
as
a
host
and
a
virtual
machine,
will
be
selected.
There's
an
art
at
r2,
which
is
supposed
to
be
the
egress
of
of
the
entire
network.
To
me,
also,
the
traffic
affiliate
is
again
guaranteed
by
combining
the
five
tuples
and
the
service
host
next.
H
H
Okay,
this
is
the
workflow
about
the
computing
service
resources,
aggregation
a
full
granularity
computing.
Servicing
resources.
Stairs
is
notified
from
the
cloud
sites
to
the
local
at
those
at
networking
loads,
which
would
maintain
the
local
computing
status
while
updating
to
the
global
part
to
the
remote
networking
nodes,
the
global
computing
status,
the
updated
main
actually.
H
H
All
right,
oh
okay,
overlapped
with
the
traditional
team
network
domain,
the
computer,
so
so
the
computing
routing
routine
table
size
that
could
be
would
be
reduced
and
the
update
frequency
will
reside
in
the
controlled
and
accept
acceptable
range.
Next,
please.
H
When
it
comes
to
control,
plane
and
digital
plane,
we
have
three
general
options
to
when
global
computing
standards
neglected
to
maintain
the
controller
which
delivers
the
routing
policy
from
ingress
to
egress,
but
local
computing
status
should
be
bad.
It
better
maintains
that
egress
locally,
as
far
as
to
the
distributed
control
plane
global
computing
status.
That
is
the
only
is
to
propagate
it
among
edge
loads
without
in
particle,
while
local
computing
status
could
be
notified
through
ways
beyond
login
protocols.
H
Because
both
the
global
and
local
computing
status
information
are
updated
in
the
integrations
to
the
reality
network
process
as
the
third
party
resources.
So
the
securing
credibility
of
the
computing
services
resources
that
have
to
be
guaranteed
and
addressed
a
details
of
security
and
credibility.
Consideration
will
be
easier
proposed
in
the
future,
updated
version
of
this
drop
of
this
draft
or
will
be
proposed
in
the
standard
alarm
draft.
Next,
please.
H
And
a
trial
test
based
on
our
prototype
system
is
ongoing
and
in
good
progress
and
the
results
do
be
synced
with
the
group
as
some
as
as
possible.
That's
all
of
my
presentation
thanks
thanks
very
much
for
your
time.
A
Thank
you
very
much
for
presenting.
As
you
know,
coin
rg
is
looking
into
network
computing,
so
I
would
advise
you
to
engage
and
present
there
as
well,
and
thank
you
for
the
presentation
and
to
our
esteemed
days.
We
hope
to
see
you
tomorrow.
Second
meeting
thanks.
Everyone.
H
A
Hey
hey,
we
did
really
well
and
but
I
still
feel
ashamed,
not
remembering
that
it's
the
first
time
you're
scotch
here,
not
the
second.
I
was
sure
that
we
did
it
like.
Like
last
ptf,
you
didn't.