►
From YouTube: IETF108 RTGWG 20200727 1410
Description
RTGWG session at IETF108
2020/07/27 1410
A
So
in
general
there
are
two
buttons
for
the
microphone
to
be
clear:
there's
one
that
has
a
hand
next
to
it,
and
that
places
you
in
the
queue
it
doesn't
actually
unmute
your
mic,
so
you
can
actually
just
unmute
your
mic
by
selecting
the
button
with
the
triangle.
Next
to
it,
that
puts
you
that
enables
your
audio,
basically
unm
unmute.
You
immediately.
A
C
A
A
A
E
D
D
A
A
A
Yes,
I
see
your
an
infinite
regress
of
your
screen
and
I
see
the
note
well
great
okay.
So
let's
move
forward
from
here.
So
please
look
at
the
note.
Well
and
it
applies
to
you
know
more
or
less
anything
you
contribute
or
say
in
the
context
of
an
itf
meeting,
what
defines
the
policies
about
what
what
applies
as
a
contribution
or
participation.
A
A
So
I
would
say
within
a
couple
minutes:
we
should
just
go
to
everyone
flipping
through
the
slides
on
their
own,
since
they
all
have
access
to
them
so
that
we
we
don't
spend
our
whole
okay.
What
do
you
see
now
now?
I
see
ipr
disclosure?
Okay,
let's
try,
okay,
so
you
know:
there's
general
rules
about
ipr
disclosure
and
itf.
A
The
routing
area
working
group
has
a
particular
policies
where
we
request
that
the
authors
and
contributors
state
their
awareness
of
ipr,
two
main
gates
in
the
working
group
document
process
before
the
working
group
adopts
an
individual
draft
and
also
before
the
working
group
request
publication
by
the
isg
that
is
at
working
group
last
call
next
slide.
Hopefully
we'll
advance,
oh
right
excellent,
so
I
think
I'll
skip
the
agenda
review
right
now
and
just
go
straight
to
the
document
status
update
since
we've
already
used
up.
A
The
pa
multi-homing
draft
and
the
yang
model
for
rip
so
good
work
thanks
for
getting
that
done,
expecting
to
do
working
group
last
call
soon
on
bgp
pick.
We
still
need
ipr
responses
from
two
out
of
the
three
authors
also
expect
to
do
a
working
group
last
call
on
a
policy
model
which
has
gotten
a
good
amount
of
feedback
from
our
reviews
from
directorates,
and
we
should
be
doing
the
yang
rib
extension
soon
as
well
next
slide.
A
So
two
existing
working
group
documents
deserve,
I
think,
some
special
discussion.
You
know
the
routing
area
working
group
has
a
very
broad
charter.
We've
got
sort
of
the
the
bread
and
butter
topics
which
are
fast
rear
out
topics
and
also
sort
of
miscellaneous
yang
models
for
routing.
But
then
we
have
sort
of
a
these
documents
fall
into
the
sort
of
catch-all
basket
for
the
routing
area
working
group.
A
You
know,
since
the
working
group
like
chose
to
take
this
on
at
its
own
discretion.
I
think
the
working
group
has
an
obligation
to
produce
a
very
high
quality
document
or
not
publish
anything
at
all,
and
so,
when
people
are,
you
know,
looking
at
the
state
of
this
document,
we
should
really
consider
like.
Is
it
ready
for
publication
as
it
is,
and
the
the
shepherd
write-up
has
a
very
important
question
related
to
this?
A
It
says:
is
this
version
of
the
document
or
if
this
version
of
the
document
is
not
ready
for
publication,
please
explain
why
the
document
is
being
forwarded
to
the
iesg.
So
at
this
point
I
don't
think
the
document
is
is
ready
for
publication
and
I
think
most
people
reading.
It
would
not
think
that
it's
ready
for
publication.
A
The
question,
isn't
you
know,
will
it
be
ready
for
publication
after
the
shepherd?
You
know,
does
a
lot
of
work
on
it
and
the
ad
does
a
lot
of
work
on
it
and
the
iesg
does
a
lot
of
work
on
it.
The
document
still
needs
a
lot
of
work
before
it
should
be
published,
so
our
goal
should
be
to
publish
a
high
quality
document.
A
You
know
whatever
is
coming
out
of
the
working
group,
not
after
it's
you
know
been
worked
on
by
after
the
working
group
last
call,
so
I
I
think
it's
up
to
the
working
group
to
either
improve
these
documents
or
to
decide
to
park
them
so
I'll.
Leave
it
at
that
and
we
can
carry
on
discussion
either
later
on,
or
you
know,
on
the
list
as
well.
A
I
I
I
Also,
there
was
a
clarification
required
for
protocol
field
in
ipv6,
as
we
all
know
that
ipv6
has
next
header
field,
not
a
protocol
field,
but
all
the
vendor
use
nomenclature
protocol
instead
of
next
header.
So
we
have
continued
with
that,
but
we
have
provided
a
lot
of
description
about
it
that
you
know
next
header
field
contain
the
same
information
as
protocol
field
in
ipv4.
I
I
A
I
Aggregated
name
counters
are
for
the
platform
where
there's
a
low-end
platform,
where
there's
a
limited
hardware
budget
for
the
counters
and
many
implementation
required
that
multiple
classifier
counters
can
be
aggregated
into
single
value,
and
so
the
classifier
having
the
same
name
counter.
Those
counters
will
be
aggregated.
I
Also,
there's
a
need
for
tagging
the
counters,
so,
for
example,
you
know
if
you
think
from
customer
perspective,
many
customers
do
want
to
tag
various
counters
in
a
particular
platform
networking
device
and
by
tagging
the
counters.
They
want
to
see
a
particular
set
of
counters
at
a
particular
cadence.
I
So
if
you
see
the
modified
name
statistics
model,
we
can
see
that
the
name
statistics
model
is
converted
into
aggregated
model,
as
well
as
non-aggregated
values,
aggregated
name
statistics
counter
will
only
contain
classification,
counters,
non-aggregated
name.
Statistics
counters
will
contain
classifier
metering
as
well
as
the
encounters
next
slide.
I
In
addition
to
these
changes,
we
have
simplified
the
node
names.
For
example,
many
of
the
names
the
prefix
of
qs
was
unnecessary
being
in
some
kind
of
a
node
hierarchy,
so
we
have
removed
those
unnecessary,
fixed
names
and
simplified
the
names,
as
well
as
as
suggesting
that
the
draft
working
group
share
name
has
been
removed
from
the
young
model
as
such.
I
D
A
C
D
C
C
C
C
C
And
then,
after
this
configuration,
igpe
will
distribute
the
information
about
this
information
and
then
the
peb
will
create
a
forwarding
table
or
feed
for
node
pea.
So
not
pa
will
be
the
node
to
be
protected
and
also
we
will
have
a
forwarding
behaviors
for
disease
on
the
node
on
the
p
loaded
pa
for
the
forward
entry
or
forward
the
package
to
the
same
destination
as
the
node
to
be
protected.
C
So
this
ink
this
this
incap
will
have
a
mirror
id
and
the
source
mode
of
p1
in
the
in
the
new
new
header
and
then
send
the
package
to
the
backup
user
node.
So
on
the
bicarb
equators
backup
equilibriums
will
decap
using
end
dot
dt6
to
decap
the
package
and
then
use
the
mirror
id
as
a
context
label
to
find
the
node
to
be
protected.
C
C
H
Hello
caitanya
from
cisco.
I
have
a
couple
of
questions.
One
is
in
the
previous
slide,
the
behavior
or
the
how
the
mirror
set
is
used.
Are
there
any
authors
plan
to
describe
this
in
either
a
spring,
or
this
document
itself
in
a
in
a
more
formal
in
a
normative
way,
as
well
as
the
perhaps
this
needs
a
location
of
a
behavior
code
point
from
ayanna.
C
H
H
C
H
C
Yeah,
we
assume
this
one
for
lsr
for
review,
because
that's
the
igp
extension.
I
think
we
just
followed
the
normal
procedure
and
I
think
that
quite
a
few
of
our
documents
do
the
same
thing.
They
have
an
extension
here
for
igp
and
then
we
need
to
ask
those
igp
experts
to
review
to
get
approval
from
there
right.
J
C
K
K
Here
is
the
motivation
of
this
document
when
srsex
policy
endpoint
node
fails,
are
the
existing
local
repair
mechanisms
such
as
fr
and
not
provide
protection,
because
the
following
reasons?
First,
is
the
current
repair
path,
also
traverse
the
endpoint
and
also
after
igp
convergence.
The
repair
path
will
be
deleted
along
with
the
routine.
K
K
K
So,
in
the
first
step
before
igp,
convergence,
node
b
still
keep
the
fifth
to
node
e,
but
the
output
interface
is
down,
so
the
proxy
forwarding
behavior
is
included
in
node
b
and
with
the
stamina
left
minus
by
one
copy
next
c
to
the
definition
address
of
the
activations
header
and
forwards.
The
packet
based
on
updated
destination
address
in
the
next
step
offered
igp
convergence.
K
in
step
3
after
srsa's
policy
convergence,
the
node
forwards
the
package
along
the
converged
path,
so
this
document
actually
defines
the
behavior
of
the
step
1
and
step
next
plate
next
page.
Please,
yes,
and
here
is
the
detailed
description
of
the
srsa's
midpoint
protection
behaviors.
We
take
an
example
when
the
repair
node
is
a
transient
node.
K
If
the
primary
output
interface
used
to
forward
the
packet
failed,
this
is
actually
the
the
first
step
in
the
previous
slide.
Also,
if
the
next
header
is
srh
and
7
on
the
left
isn't
zero.
The
failed
endpoint
is
directly
connected
to
the
repair
node
center
left
minus
one
updates.
The
ipv6
destination
address
with
srh
seminar
left
I'll,
fit
look
up
on
the
updated
destiny
address
and
forward
the
packet
according
to
the
match,
entry
else
forward
packet
of
gold
according
to
the
backup.
K
Next
next
hulk,
in
this
case
the
the
ordinary
rtrfa
works
and
another
case
when
the
igp
convergence
has
already
happened.
There
is
no
fib
entry
for
the
for
forwarding
the
packet.
If
next
header
is
srh
and
seven
left
isn't
zero.
Seven
left
minus
one
updates.
The
fps's
destination
by
srh
seminar
left
fifth
lookup
on
the
updated
destination
address
forward
packet
according
to
the
matched
entry
or
drop
the
packet
else
forward,
according
to
the
matched
entry
next
slide,
please
in
the
updated
version
we
end
the
section
about
security
considerations.
K
In
this
section
we
defined
the
midpoint
protection
cannot
be
enabled
by
default
and
also
the
repair
node
can
modify
the
srh
only
when
the
field
endpoint
is
in
the
same
trusted.
Domain
node
in,
in
other
words,
midpoint
protection
is
only
enabled
when
the
repair
node
is
trusted
by
the
failed
node
and
next
slide.
K
A
A
A
A
I
I
think
it's
an
artifact
of
maybe
when
people
join,
they
automatically
show
up
in
the
in
the
queue
and
it
gets
deactivated
because
I've
basically
seen
at
one
point
everyone
has,
you
know,
or
at
least
50
people
have
appeared
to
want
to
send
audio,
but
not
that
many
people
have
so
yeah.
Let's
move
on
to
thank
you,
and
I
I
so
go
ahead
and
unmute
your
audio.
A
How
about
we
jump
ahead
to
whim
if
that's
okay
with
whim,
perhaps
we
can
jump
ahead
to
win
and
come
back
to
linda
right
after
when,
hopefully
we
can
get
the
audio
working
and
linda
as
a
means
of
troubleshooting.
Your
audio,
if
wim
doesn't
mind
like
if
you're
able
to
get
audio-
and
you
think
you've
got
it,
then
like
speak,
and
it
will
interrupt
wim's
presentation,
perhaps
but
we'll
at
least
know
you.
We
have
audio.
A
E
Yes,
so
we
did.
I
in
singapore,
we
presented
in
the
whole
series
and
based
on
some
feedback
we
got
people
would
love
to
have
us
to
have
written
this
draft.
So
as
such,
this
is
what
we
did.
So
this
is
the
first
time
we
present
this
and
I
am
presenting
this
on
behalf
of
a
number
of
authors
and
co-authors
which
are
listed
here.
So
basically,
it's
an
architecture
for
network
function,
interconnection
which
we'll
go
through
in
a
bit
more
detail
next
slide.
Please!
E
So,
first
of
all,
what
are
we
and
and
what
this
is
about,
is
I
first
of
all.
We
see
that
with
5g
and
iot
in
industry
4.0
we
see
that
the
number
of
new
service
requirements
or
requirements
which
you
already
had
are
changing,
such
as
we
typically
had
bandwidth,
but
that
is
definitely
ultra
reliability
and
then
low
latency
coming
into
the
mix.
So
we
have
to
deal
with
that
somehow
in
building
networks.
E
Secondly,
we
see
that
virtualization
or
software
based
workloads
are
being
added
as
workloads
onto
the
network,
so
we
somehow
have
to
deal
with
that
when
we
do
interconnection
of
different
functions
and
third,
we
see
that
service
edges
are
so
the
boundaries
of
that
are
changing
and
as
a
result
of
dealing
with
low
latency,
we
have
to
deal
with
that
somehow.
So,
basically,
what
we
did
is
wrote.
This
draft,
which
we
call
nfix
so
n
of
x,
stands
for
network
function.
E
First,
we
introduced
a
few
terminologies,
which
I
don't
believe
are
completely,
let's
say
defined
in
itf.
So
first
of
all
we
defined
a
pnf
so
which
is
a
physical
network
function.
Then
we
defined
the
vnf.
We
did
not
distinguish
between
containerization
or
virtualization
and
stuff
like
that.
So
maybe
this
is
something
we
can
improve
upon,
or
it
would
be
good
to
get
some
comments
upon,
so
we
called
it
vnf
for
now,
then
we
have
a
data
center
border
router,
which
we
call
dcb,
and
then
we
had
an
interconnect
controller.
E
D
E
E
E
E
Secondly,
we
see
that
we
need
to
do
traffic
engineering
or
having
or
defining
as
a
lace
which
span
multiple
environments,
meaning
data
centered,
wide
area
network
and,
as
we
all
know,
wide
area
network
can
be
defined
or
can
be
implemented
using
multiple
pieces
of
network
like
an
aggregation,
access
and
core
domain.
So
it's
making
a
sim
a
seamless
fabric
that
or
service
architecture
that
spans
all
of
these
environments.
E
E
E
So
if
you
look
a
bit
from
the
architecture,
we
are
relying
on
the
wide
area
network
with
the
same
capabilities
as
we
have
today,
so
we're
using
segment
routing
paths
and
then
supported
by
bgplu
in
the
same
way
as
seamless
mpls
is
using
in
data
center.
We
are
introducing
segment
routing
in
in
various
options,
so
there
can
be
segment
routing,
impellers
or
srv6,
but
also
segment
routing
over
ip
or
udp,
as
defined
in
rfc
8663
and
then
for
inter
domain.
E
We
use
colors
to
actually
help
define
that
intent
of
that
kpi.
That
actually
is,
is
defined
and
what
we
are
doing
is
we
are
using
the
service,
so
the
basic
anchoring
is
done
at
the
data
center
gateway,
because
that
helps
to
scale
and
also
helps
in
scenarios
that,
when
you
have
convergence,
ensures
that
we
don't
have
to
update
all
the
elements.
For
example,
if
you
look
at
virtualized
workloads,
there
can
be
many
endpoints
that
has
to
be
updated
in
case
of
failure.
E
So
services
are
defined
end
to
end,
so
there
is
no
service
stitching
boundary
at
some
point,
so
the
services
are
defined
end-to-end
and
then,
of
course,
we
use
I
by
the
fact
that
we
have
head
and
collar
and
endpoint
and
working
in
conjunction
with
the
controller.
We
can
then
build
virtual
topologies.
E
E
So
it's
an
open
framework
built
on
various
idf
work
and
we
actually
have
already
implemented
this
in
a
number
of
environment
or
deployments
using
various
vendors,
so
it's
multi-vendor
in
nature.
So
as
such,
we
are
looking
for
feedback
at
this
stage
to
see
whether
there
are
things
that
we
would
have
to
add,
or
we
would
or
comments
in
general.
D
L
E
A
A
A
A
M
M
M
So
this
is
the
restructured
table
of
contents,
so
I
highly
encourage
people
to
reread
it
again.
If
you
read
it
before,
we
have
made
some
make
major
changes
so
primarily
we'll
talk
about.
We
add
a
new
section
on
how
do
we
reach
applications
with
medical
instances
in
different
cloud
data
centers,
we
added
a
more
detailed
description
on
the
dns
for
the
cloud
services
and
also
for
the
net.
M
So
here
is
the
highlight
of
the
problems.
I
encourage
people
to
read
into
the
detail.
One
is
the
identity
management
when
we
have
workload
in
different
cloud
data
centers.
First
of
all,
is
the
user
authentication
another
one
is
application
authentication
when
you
have
one
application
in
one
place,
try
to
access
or
call
another
function
call
in
another.
One
can
be
that's
a
really
big
issue
there.
Second,
one
is
the
api
abstractions.
M
That's
all
from
last
meeting
since
last
meeting
we
got
feedback
from
people
primarily
because
different
cloud
data
centers
have
different
interfaces
for
specific
features
provided
by
a
specific
cloud
data
center,
it's
okay
to
have
their
own
api,
but
there
are
lots
of
common
services
like
firewall
net.
All
those
common
services
is
preferable
to
have
a
shim
layer
to
be
able
to
allow
enterprise
to
move
clouds
to
another.
One
move
the
service
from
one
cloud
data
center
to
another
one
and
the
last
one
we
added
is
the
basically
added
more
content
in
this
cloud
discovery.
M
So
here's
after
discussing
with
dns
ops
and
their
feedback,
we
we
enhance
the
description
on
the
dns,
so
there
are
two
aspects
for
dns.
One
aspect
is
the
resolution
with
resolving
of
the
query
from
the
application
running
inside
the
cloud
data
center
because
for
enterprises,
not
all
entries
are
hosted
in
a
specific
cloud
data
center.
So
the
within
one
cloud.
The
resolution
may
need
to
forward
the
query
to
the
custom,
on-prime,
dns
and
customer.
M
If
the
end
target
is
in
another
cloud,
this
query
has
to
be
forwarded
to
a
specific
location
to
get
the
address
for
the
application
to
talk
to
each
other.
So
that's
on
the
dns
provided
by
the
cloud
and
how
to
they
interface
with
on-prem
dns.
Another
part
is
application.
As
we
know,
most
applications
today
have
multiple
instances
instantiated
in
different
places,
and
today
the
state
of
art
solution
is
using
dns
as
a
way
to
forward
the
target
into
the
closest
one
right.
So
so.
M
And
through
dns,
based
on
the
location
of
the
client,
they
return
back
the
address
of
the
closest
one.
This
has
their
own
problems.
This
is
basically
layer,
seven
kind
of
a
traffic
management.
The
problems
is
the.
It
depends
on
the
client
behavior
if
the
client
never
refreshed
their
cash
and
if
they
try
to
move
like.
If
you
have
a.
A
M
M
A
D
N
Yeah,
thank
you.
Okay,
hi
everyone.
I'm
tren
jung
from
zte.
My
presentation
today
is
a
precise
transport
networking
and
related
problem
statement
and
requirements.
Strats,
and
that's
this
night,
please
so
let
me
first
introduce
the
use
cases
of
precise
network.
As
we
were
long.
The
5g
networks
lead
to
provide
three
types
of
services,
including
embbb
mmtc
and
the
urls
llc,
and
the
urlc
services
harvard
use
cases
such
as
internet
over
electricity,
intelligent
factory
intake
internet
over
vehicles
and
other
in
industry.
N
Intellectual
scenarios
and
these
services
may
demand
precise
and
realistic
performance,
for
example,
as
the
figures
show,
the
the
internet
of
electricity
may
demand
service
isolation
and
high
security
other
than
precise
dentistry
loss,
energeta
the
internet
of
vehicles
and
remote
medical
has
special
requirements
for
inter
operators
deployment
and
the
last
one.
The
ar
vr
service
must
provide
a
precise
control
for
the
map
dynamics
flows
from
multiple
users.
N
So,
based
on
the
use
cases
as
well
alone,
there
are
existing
technologies
in
itf
to
provide
deterministic
queues
such
as
that
last
working
group.
But
besides
manchester
jitter
and
the
packing
laws,
more
other
precise
performance
should
be
provided
in
precise
network.
The
figure
shows
the
different
requirements
between
deterministic
and
precise
networks,
so
first
srfc
h655
defined
in
that
latch
working
group.
Their
primary
goals
for
the
lab
queues
is
ester
left
on
the
left.
N
The
data
queues
is
minimum
and
maximum
end
to
end
lengthy
and
low
pack
loss,
but
for
precise
network
it
would
provide
a
precise,
mentally
packed
loss
and
the
jitter
second
one.
The
base
the
base
per
mechanism
in
deterministic
network
is
the
resource
reservation,
but
in
precise
network
we
should
require
resource
and
the
surface.
Isolation
and
the
existing
technologies
provide
the
domestic
deterministic
performance
in
forwarding
layer
through
cycle
and
queen
management,
for
example,
such
as
the
mechanisms
provided
in
qsn,
but
in
precise
network.
The
candidate
mechanism
would
be
flexible,
slicing
turner.
N
N
We
discussed
the
problem
with
traffic
scheduling
mechanism,
for
example,
the
mechanisms
such
as
queen
shaping
and
their
sketch
scheduling
functions.
Their
mechanism
in
psn
will
not
be
appropriate
for
iep
networks.
Second,
the
problem
with
long
distance
transmission
delay
and
the
jitter
it
will
lead
to
uncertainties
such
as
increasing
transmission,
delay,
jitter
and
noise.
It
must
be
considered
considered
in
precise
network.
N
We
discussed
the
problem
with
dynamic
flows
for
multiple
users.
We
must
provide
precise
control
for
dynamic
flows
from
multiple
users,
but
this
is
not
considered
in
their
existing
mechanism
and
the
flows.
It
leads
to
a
aggregate
in
netherlands,
working
group,
and
last
we
discussed
the
problem
with
the
service
isolation
and
the
results
of
allocation.
N
N
N
D
A
D
A
L
L
L
It
will
introduce
some
the
design
experience
for
the
srv6
deployments-
okay,
next,
one
okay,
so
here
we
introduce
some
srv6
advantages.
In
fact,
these
are
already
presented
in
the
last
meeting.
So
here
I
just
briefly
introduced
the.
I
think
this,
the
first
one
is
the
ip
root
aggregation
so
that
you
can
improve
the
scalability
using
srv6,
comparing
with
the
smpr's
the
second
one,
I
think,
because
the
sr
npr's
used
to
design
the
srtb
and
the
node
id
such
resources
across
the
multiple
network
domain.
L
L
L
So
then,
the
second
step
we
will
can
deploy
the
srv6
vpn
it
only
to
is
only
need
to
upgrade
the
edge
node
to
support
the
srv6,
and
then
this
is
kind
of
supported
the
srv6
in
for
the
intro
to
me,
so
the
means
that
the
p
node
can
be
upgraded
srv6
to
support
the
srv6,
the
traffic
engineering
or
the
srv6,
the
trfa
fast
reload,
okay,
next
one,
okay.
So
here
this
is
the
deployment
cases.
So
this
is
the
china
telecom,
so
this
is
across
the
backbone.
L
So
this
is
the
here.
Is
the
data
center
network
across
the
backbone
there's
the
two
backbone,
so
the
and
also
this
one
backbone,
only
support
the
ipv6
reachability.
So
at
that
time
it's
very
hard
for
them
to
support
the
mcrs
vpn
services,
but
now
that
you
can
utilize
the
ipv6
reachability
to
support
the
vpn.
L
So
then
there's
a
user
who
go
on
to
use
the
srv6
policy
was
to
choose
the
different
backbone
because
it
has
two
backbone
either.
According
to
this,
the
congestion
situation
to
choose
the
possible
is
the
backbone
that
work
okay,
next,
one
okay,
so
this
is
the
china
unicom.
So
this
is
for
the
cloud
service.
It
also
needs
to
cross
multiple
backbone.
So
this
is
the
backbone
and
also
now,
this
only
support
the
native
ipv6.
L
L
L
That
is
a
lot
of
this
configuration
and
also
this
infrastructure
is
not
stable.
So
it's
always
a
failure,
happens
and
cause
the
complaints
of
this,
the
customers.
So
now
that
is
used
under
to
under
srv6
to
honor,
to
kind
of
seamlessly,
I'm
sure
seamlessly.
That's
you
set
up
this
cross
market
domain.
This
is
the
path,
then.
This
is
also
deployed
the
trfa
to
support
this
reliability
solutions.
L
So
this
is
comparing
this:
the
traditional
traffic
engineering
combined
with
the
pfd,
that
is
the
lot
of
huge
of
configuration,
but
now
use
the
srv6
and
the
trfa,
and
this
the
configuration
reduced
hugely
okay
and
also
is
improve
the
reliability
of
the
network
and
also
reduce
the
compliance
of
the
customers.
Okay,
next
one.
L
So
here
are
these
summaries
of
this-
the
commercial
deployment
in
china.
So
now,
there's
almost
more
than
10
deployment
of
srv6
for
the
different
scenarios
for
the
5g
transport,
or
this
is
the
cloud
service,
and
now
these
key
features
is
the
vpn
and
the
best
effort,
but
now,
let's
move
on
to
the
traffic
engineering
and
also
the
policy?
L
Okay,
next
one
okay,
so
this
is
the
next
type
of
we
will
also.
This
is
the
multiple
cases
and
also
different
this
design,
experience
for
using
srv6
for
the
5g
transport
or
the
data
center,
etc,
and
also
we
know
that
now
there's
a
lot
of
discussion
about
the
srv6
compression,
so
we
also
provide
this
the
experience
about
the
design
of
the
ipv6
address
and
also
the
srv6
locator
design,
etc.
B
L
L
N
N
Actually,
we
mainly
focus
on
the
application
of
our
network
domain
as
to
the
application
information
they
are
delivered
into
this
network
domain
and
based
on
this
information,
more
new
network
services
can
be
provided
as
to
those
application
information
that
could
be
added
or
encapsulated
at
the
application
in
the
terminals
all
at
the
network
edge
devices,
but
they
are
outside
of
the
application
world
network
domain
next.
Next,
please-
and
there
are
three
key
elements
of
apn.
First-
is
about
application.
N
Information
include
including
the
application
aware
identifiers,
as
well
as
the
service
performance
requirements
and
the
those
application
information
are
open
and
now
the
mandatory
they
could
be
added
based
on
the
agreement,
and
the
second
is
about
the
rich
network
services.
There
are
more
and
more
new
network
services
emerging.
So
with
the
application,
awareness,
more
new
applications,
more
new
network
services
are
going
to
be
provided
and,
third
is
about
network
measurements.
N
Currently,
we
have
a
lot
of
techniques
for
the
network
and
the
service
performance
management,
with
application
awareness
we
could
achieve
more
accurate
and
define
granularity
and
the
comprehensive
measurements.
Next,
please-
and
here
are
some
potential
work
items
in
apn,
including
both
new
work
and
the
work
that
needs
to
be
extended.
N
N
As
to
the
architecture,
we
would
need
to
define
the
apn
framework
and
the
key
functional
components,
and
on
top
of
that,
we
would
need
to
explore
what
would
be
the
new
network
services
can
be
supported
by
apm
next,
please,
and
here
again,
regarding
the
apn
scope,
we
would
like
to
emphasize
site
the
apn
application
aware
network.
We
would
only
focus
on
the
network
domain
and
the
application
information
describing
the
service
or
behaviors
needed
by
the
applications
could
be
added
by
either
the
application
or
the
azure
devices.
N
And
here
there
is
a
hack
song
on
apn6
that
is
apn
over
the
ipv6
data
plane
and
you
could
find
the
information
in
the
links
and
in
this
hacksaw
the
implement
implementation
of
apn6
is
demonstrated
and
including
the
ipv6
encapsulation
for
the
application
aware
id,
as
well
as
the
service
parameters
and
based
on
those
application.
Information
the
srv6
based
traffic
steering
is
demonstrated
here
are
some
specifications
next,
please.
N
Currently
there
are
some
proposals
on
the
acquisition,
encapsulation
and
convening
of
those
application
related
information,
and
we
also
invited
the
experts
to
present
those
proposals
and
at
last,
but
this
most
important
thing
we
would
like
to
discuss
and
clarify.
This-
is
about
the
privacy
and
security
issues.
That
is
the
two
issues.
The
apn
got
challenged
the
most
and
we
would
like
to
discuss
with
people
actually
on
those
two
issues
we
have
already
have
some
have
done
some
studies.
Next,
please.
N
This
one
is
the
privacy
issues
and
we
have
analyzed
those
scenarios
and
we
found
that,
probably
in
most
scenarios
that
there
will
be
no
privacy
issues
and
the
first
one,
and
we
know
that
more
and
more
operators
are
staff
started
running
their
own
applications
like
in
china
cmcc.
They
have
igoo
music,
I
believe
in
your
countries.
N
You
also
have
the
similar
applications
run
by
the
operators,
and
there
will
be
no
privacy
issues
because
operator
own
those
applications
and
then
for
the
application
providers
and
and
the
more
and
more
application
providers
are
building
and
running
their
own
networks
like
google
before
so,
google
actually
control
the
application
service
till
the
end
of
the
the
edge
of
the
network,
the
lan.
So
it
can
choose
everything
and
it
also
differentiates
those
important
applications
to
give
them
higher
priority.
N
And
then
the
third
one
is
apn
actually
works.
Only
within
our
operators
can
show
the
limited
domain.
So,
no
matter
where
the
application
information
is
added
or
encapsulated
so
there
will
be
no
privacy
issue
and
if
the
application
information
is
added
at
the
edge
devices
and
but
those
devices
are
controlled
by
the
our
network,
operation
readers,
so
again,
there
will
be
no
privacy
issues.
N
If
those
information
is
encrypted
encrypted
again,
there
will
be
no
privacy
issue,
so
only
scenario
will
be
if
those
information
is
added
as
the
application,
but
they
are
not
encrypted.
So
in
that
case,
we
may
need
to
think
about
the
privacy
issue,
and
probably
we
need
to
think
more
about
the
coding
of
the
application
information.
Next,
please.
N
So
in
the
inter
dc
scenario,
we
find
there
is
no
security
issue
and
for
the
enterprise
scenario
and
generally
they
access
so
the
enterprise
users
and
they
access
through
control
the
bng
interface
that
is
authorized
so
here
and
on
the
right
side
of
the
slides
I
showed
on
the
top
is
typical,
fixed
broadband
and
then
on.
The
bottom
is
typical:
5g
mobile
broadband,
the
typical
network
deployments
and
service
provisioning.
N
You
could
see
the
setup
and
from
there
for
the
fixed
broadband,
the
bng
is
acting
as
the
network
gateway.
Well
for
the
5g
mobile
broadband,
it's
a
5gc
and
it's
authenticating
authorizing
the
user
access,
so
the
apn
will
only
impose
its
security
issues
when
the
users
access
from
an
untrusted
domain,
but
in
the
home
broadband
scenario
that
could
be
validated
by
the
bng
in
the
mobile
broadband
that
could
be
validated
by
the
5g
core,
and
there
are
also
we
listed
the
four
four
types
of
security
issues.
N
The
first
one
is
raising
one
terminal,
and
that
could
be
this.
The
situation
could
be
one
application
in
one
terminal
as
arbitrary
application,
information
and
also
those
applica
one
application
in
one
terminal
could
add
the
application
information
of
another
applications
in
the
same
terminal,
but
the
both
cases
can
be
tackled
where
the
operating
systems,
if
they
finally
they
are
send
out,
it
can
be
blocked
by
a
bgp
bng,
all
the
5g
core,
and
the
second
case
is
once
those
information
is
sent
out
that
can
be
still
validated
by
a
network
site's
security
solution.
N
So,
for
example,
the
application
in
one
term
terminal
forges
the
application
information
of
the
same
application,
but
in
another
terminal
and
all
the
application
information
is
tampered
along.
The
way
between
the
application
information
creator
to
the
network
boundary.
So
here
are
the
four
types
of
security
issues
we
can
think
of
next
piece.
N
And
here
are
the
related
information
about
apn,
including
the
problem
statement
and
use
cases,
and
here
we
have
the
two
operators:
draft
one
is
about
apn
in
the
edge
computing
scenarios
and
the
other
one
is
about
apn
for
the
gaming
acceleration
use
cases.
If
you
are
interested,
you
could
have
a
look
and
then
framework,
and
then
the
requirements,
and
then
the
community
and
in
this
community,
and
you
could
find
the
latest
updates
on
apn,
including
the
infocomm
paper
we
just
published
and
the
interop
tokyo.
N
A
A
A
Okay,
so
I
don't
see
khaled
on
the
list
of
participants
logged
in,
so
let
me
check
the
chat
window
as
well,
see
if
drew
confirming
that
he
doesn't
see
khaled
as
well.
So
at
this
point,
I
I
think
we
should
probably
just
go
ahead
and
close.
The
meeting,
because
I
think
trying
to
do
a
little
discussion
right
at
the
end
is,
is
going
to.
F
A
A
A
A
D
F
F
A
G
A
So
basically,
an
individual
draft.
Can
you
know,
I
think,
have
have
whatever
you
know
as
long
as
it's
not
offensive
or
anything
you
know
can
use
whatever
convention
they
like
a
draft
that
would
get
adopted.
You
know
during
the
adoption
process.
I
think
a
lot
of
people
would
have
input
as
to
what
what
naming
conventions
are
used.