►
From YouTube: IETF104-RTGWG-20190329-1050
Description
RTGWG meeting session at IETF104
2019/03/29 1050
https://datatracker.ietf.org/meeting/104/proceedings/
A
E
E
F
E
F
As
you
know,
a
little
stressing
is
a
hot
topic
and
I
assume
that
there
are
several
factors:
for
example,
diversity
of
the
devices
and
services
with
communications
or
improvement
on
flexibility
of
the
drug
control
presented
by
network
virtualization
technologies
such
as
NFB
MSDN.
Also,
the
docs
rising
is
a
fundamental
concept.
405
G
and
5g
will
be
launched
soon.
F
That's
right,
so
that's
what's
rising,
is
related
to
a
5
g,
so
ITU
and
Swiss
VP
defined
three
communication
types
as
features
of
5z
e
mb
b,
m
mt
c
and
view
our
LLC
under
the
tax
rises.
Pricing
appears
on
this
context,
but
we
would
like
to
aim
more
general
concept
on
the
clocks,
rising
x5
so
and
jela
syrup
programs,
for
example.
The
first
rising
is
discussed
in
several
SD
odds,
but
the
the
definitions
seems
very,
for
example,
some
s.
F
Videos
said
s,
rice
is
just
VPN
but
said
it's
rising
will
be
being
a
unsub's
cheney,
also
a
range
or
range
where
rice
is
provided.
It's
not
strictly
defined,
for
example,
is
EVP
discussing
just
using
slices
within
just
a
5c
quality,
but
we
would
like
to
realize
rice
from
end
to
end.
Also,
one
more
day
is
one
more
program
it
is.
F
F
Purpose
of
this
work.
Ant
is
draft
so
we'll
direct
to
aim
a
sweet
spot
for
each
service,
like
this
video
not
only
edge
of
the
triangle,
so
this
enables
to
enables
tenants
to
use
appropriate
network
resources
depending
on
the
service
and
use
provide
the
the
service,
the
service
and
network
resources
as
their
own
service.
F
F
Also,
we
would
like
to
gratify
capabilities
required
for
required
by
tenants
and
how
to
provide
such
resources
to
the
channels
so
in
the
following
few
tries
I
would
explain
the
overview
of
the
contents
of
this
draft
so
first.
Firstly,
this
draft
defines
resource
types,
so
we
assume
that
the
list
of
resources
can
be
categorized.
Three
variations,
so
first
is
network
or
one
resource,
such
as
a
connectivity,
Express
ways
Plinko.
G
F
F
So
this
right
shows
the
basic
structure
of
the
dogs.
Rising
with
differing
3gpp
were
chained
forum
definitions,
so
the
doctorÃs
subnet
instance
is
gallardo
in
each
domain
with
such
resources,
and
by
connecting
these
subnets
instance
in
to-
and
it
works
rising
instance
to
be
created
also,
sometimes
it
oxidizes
instance
may
be
a
multi-level
structure,
so
this
verse
shows
that
patient
button.
This
is
one
of
the
main
contents
of
this
draft,
so
we
categorize
relation
pattern
on
network
splicing
into
three
hotels.
So,
firstly,
it's
already
made
a
turn
in
this
pattern.
F
Networks
tries
provider,
creates
thrice
catalog
in
advance
and
tenant.
Select.
One
of
each
east
was
to
demand,
so
this
is
very
similar
ways.
Current
little
Saudis
second,
is
a
custom-made
model.
So
in
this
attempt
so
little
service
provider
design
catalog,
depending
on
the
comments
from
tenants,
dynamically,
it's
very
challenging
model,
and
so
there
is
the
semi
custom
made
model.
This
is
hybrid
of
ready-made
and
custom
made.
So
in
this
model,
network
service
provider
creates
a
line
or
catalog
and
tenant
in
put
some
kilometer
depending.
F
This
slide
shows
the
provision
models
which
is
defined
in
this
draft,
so
we
categorized
provision
model
into
three
models.
So
first,
it's
a
strike
model
in
this
model,
so
where
detailed
network
resources
is
hidden
from
tenant
and
tenant,
requests
its
own
just
requirement
and
created
appropriate
thrice.
F
F
So
next
steps
of
this
box,
so
this
is
new
one
and
we
have
very
few
feedback
are
to
be.
We
welcome
more
feedback,
and
especially,
we
would
like
to
know
opinions
from,
but
your
customers
and
second
is
mapping
such
budget
provision
models
and
controllable
resources
and,
finally,
if
needed-
and
we
would
like
to
expand
the
current
young
models.
H
F
F
F
H
I
think
it's
good
thing
to
somehow
check
what
other
is
dioz
are
doing
and
not
to
do
the
duplicate
work
and
one
of
the
ways
to
resolve
that
and
clarify
that
is
the
sent
liaison.
So
I
think
that
before
we
start
discussion,
it
will
be
good
to
set
liaison
and
ask
our
so
network
slicing
project
to
review
and
explicitly
describe
what
they're
doing.
H
E
H
E
F
F
E
F
F
I
E
J
J
K
K
K
K
Interconnection
was
the
product
provider
VPN
and
but
at
additional
ports
to
connect
to
the
internet,
thus
can
be
unprimed
CPE
being
upgraded
to
utilize.
The
bandwidth
the
internet
LTE,
could
be
your
extension
virtual
router
inside
cloud
data
center,
saying
if
you
have
a
cloud
datacenter
you
like
use
AWS
as
the
example
because
everybody's
familiar
with
that
cloud
services,
you
instantiate
a
virtual
router
and
one
port-
you
use
Direct
Connect,
which
is
directly
connected
to
your
corporate
VPN.
K
Another
port
is
connect
to
the
virtual
gateway,
Internet
gateway,
so
that
you
can
utilize
both
bandwidth
and
you
can
differentiate
traffic
for
different
egress
port.
So
the
the
difference
between
those
two
is
on
the
one
port
management.
So
in
the
hybrid
sd1,
some
of
the
traffic
can
have
to
go
through
the
private,
a
VPN
doesn't
matter
what
so
they
have
a
policy
on
the
device.
Certain
traffic
have
to
go
through.
The
private
network
are
encrypted
because
encryption
is
very
processing
intensive.
So
for
the
traffic
goes
through
the
private
network,
you
can
go
natively.
K
Another
part
is
some
traffic
can
be
either,
but
you
can
some
traffic
has
a
choice
of
you
can
go
through
a
private
network,
I
encrypt
it
or
you
can
go
through
the
public
network,
but
that
have
to
be
encrypted.
So
another
part
is
because
those
device
are
far
away
from
other
devices
and
and
also
the
connection
to
the
controller.
Here
we
use
a
broad
reflector
because
they
are
forwarding
a
propagate.
The
routes
can
be
going
through
the
untrusted
domain,
so
thus
very
different
from
our
traditional
VPN.
K
So
first
well
know
what
powers
up,
not
only
he
need
to
figure
out
who
is
his
controller,
but
also
need
to
be
able
to
create,
establish
a
tiara.
Who
is
the
controller
after
you
establish
the
connection
with
the
controller,
you
need
to
be
able
to
register
your
one
port
before
your
IPSec
tunnel
can
be
established.
This
is
almost
like.
K
So
that's
part
of
the
the
gap
not
there
yet
and
we
actually
put
together
a
draft
in
IDR
a
working
group
just
for
that
purpose
for
the
one
port
management.
Well,
one
node
powers
up
it
established
TRS
with
its
controller
and
report.
There
were
import
proxies,
which
can
be
a
private
address
or
could
be
dynamically
assigned
address
by
the
ISPs
and
also
report
the
loopback
address,
and
then
the
controller
propagate
that
information
to
the
authorized
peers,
because
the
node
themselves
doesn't
know
who
he's
entitled
to
talk
to
or
authorized
to
talk
to.
K
Okay,
so
further
on
the
gap,
analysis
in
addition
to
what
we
presented
last
time,
here's
something
new
for
them.
We
plan
to
use.
We
think
the
tunnel
in-cab
trap.
The
base
should
be
used
for
a
brigade
of
advertise.
The
port
properties
are
advertised
they're
out
with
the
tunnels,
but
as
of
now,
as
at
least
as
of
now,
the
tunnel
in
cap
draft
is
a
social
mr.
client
routes
like
he
in
example,
here
20.1
can
use
particular
tunnel,
can
use
VX,
lantern
or
can
use
IPSec
tunnel,
but
it
doesn't
address
the
issues
of
like
see.
K
I
have
a
one-pot
like
here.
The
8th
year
is
3.
This
particular
port
has
those
properties
way.
I
have
private
address
a
public
address,
I,
have
the
net
associates
port
and
I
want
to
establish
IPSec
tunnel
between
82
and
B
3,
say
a
to
maybe
by
the
ISP
1
like
AT&T
b2
may
be
in
a
different
country
by
China
Telecom,
so
those
two
have
different
assigned
IP
addresses
and
the
loopback
address
is
in
a
different
address.
Space
right.
The
loopback
address
is
in
the
space
of
the
overlay
layer.
K
So
as
of
now,
we
talked
on
Wednesday
about
this,
and
the
authors
agree
to
add.
Hopefully
they
were
at
basically
allow
the
tunneling
cat
to
be
able
to
advertise
the
tunnel
with
say
a
loopback
address,
or
maybe
with
the
web
port
at
rest,
so
those
can
be
used
to
identify
to
propagate
the
properties
of
the
port
and
advertise
them.
The
mapping
between
private
address
and
public
address.
So
with
that
then
say:
if
you
we
have
four
routes.
K
In
this
example,
the
four
routes
may
be,
20.1
can
go
through
all
three
egress
ports
and
then
that
one
has
to
be
able
to
recursively
being
advertised.
I
can
go
through
those
three
egress
LAN
ports.
They
don't
have
to
repeat
all
those
one
port
properties
in
each
of
the
update
that
maybe
the
20.2
can
only
egress
two
ports
or
maybe
one
port.
Then
he
can
advertise
that
with
indication
of
the
specific
port
and
doesn't
have
to
repeat
the
the
tunnel
detailed
information.
So
all
those
has
to
be
it's
not
there.
K
Yet
it's
not
that
we
have
identified,
and
also
that
say
if
the
the
route
can
every
okay
egress
three
different
ports,
and
so
for
today,
based
on
the
rate
of
the
how
the
in-cab
trap
is
written,
it
seems
like
you
need
to
include
three
different
remote
endpoint
sub
theories,
but
then
the
travel
itself
also
indicated
that
you
cannot
have
more
than
one
so
there's
some
kind
of
inconsistency
in
the
draft.
So
that's
on
the
tunnel
income,
the
gap
next
one.
K
This
part
I'm
just
reiterate
about
the
one
port
management
after
note,
pause
up
the
crate
TRS
session
with
the
controller-
and
the
first
thing
you
need
to
do
is
to
tell
the
controller.
What
am
I
one
course
I
have
three
on
one
horse:
I
have
two
one
ports,
my
one,
one
port
is
connecting
the
private
network.
My
two
web
host
is
connected
to
the
the
public
Internet
and
my
one
point
can
be
supporting
MPLS
or
maybe
I'm
just
doing
a
standard
CPE,
which
is
just
IP
or
Ethernet
handoff
and
who's.
K
K
The
problem
with
NAT
calm?
Is
it?
Doesn't
it's
not
easy
for
the
node
himself
to
report
and
especially
when
you
change
you
to
report
dynamically
every
time
the
port
address
change,
a
property
change
and
another
important
part
is
to
be
able
to
propagate
to
the
authorized
peers.
So
that
say,
if
a
CPU
one
can
talk
to
CPE
to
see
ps3
in
different
cities,
then
they
need
the
Rob
reflector
to
propagate
them.
With
the
power
policy
identify
okay,
I
say
the
idea
chairman
speak.
L
Oh,
that's:
okay,
unless
one
individual
Susan
hears
individual
contributor
I
just
want
to
perhaps
put
a
slight
spin
on
what
Linda
just
said
about
that
cup.
The
not've
stuff
is
really
you
smell
or
the
push
notification,
but
it's
just
finishing
so
you
know
it's
a
little
bit
of
time
to
the
deployment
you
in.
In
many
cases,
some
things
we're
doing
are
just
saying:
okay,
we've
got
to
have
these
sort
of
things
so
that
the
the
management's
can
still
continue
and
be
easy.
Some
of
that
feedback
is
from
product
groups.
K
Thank
you,
okay,
next
page,
okay,
so
we
see
that
for
sd1
control
plan
there
are
actually
three
different
components
just
to
wrap
up
than
the
control
plan.
Part.
The
first
part
is
the
one
port
management
being
able
to
report
the
web
for
properties
and
dynamically.
The
second
part
is
for
the
IPSec
configurations.
K
The
traditional
IPSec
manual
configuration
appear
to
appear,
negotiation
doesn't
scale
when
you
have
more
than
100
notes,
because
each
node
need
to
establish
multiple
IP
sex
sessions
having
those
peer-to-peer
negotiation
just
doesn't
scale
so
that
part
there's
a
draft
in
the
IPSec
Amy
talked
about
that,
then.
The
third
part
is
our
traditional
evpn,
also
VPN
the
route
propagation
right.
So
there
are
three
different
parts
for
the
sd1
and
the
third
part
has
been
studied
really
well.
We
have
RFC's.
K
K
K
It's
indicated
that
in
PGP
is
widely
used
today,
right
between
ES
domain
between
cloud
provider
and
when
the
cloud
providers
a
AWS,
has
initiated
virtual
router.
You
exchange
the
a
s
number,
but
it
doesn't.
The
BGP
itself
doesn't
have
the
performance
characteristics
right.
So
you
see
I
can
reach
from
this
round,
but
maybe
my
immediate
link
is
wide
open.
I
have
two
possible
ways
to
reach
my
destination.
K
My
immediate
port
I
can
test
the
available
link
utilization,
maybe
link
and
one
is
very
little
utilized-
think
two
is
heavily
utilized,
but
I
don't
know
after
one
hop,
maybe
after
what
the
second
hop
and
think
ones
baby
penguin
heavily
utilized,
so
the
peach
tree
doesn't
have
any
of
those
indicators.
So
in
their
paper
they
talk
about
some
ways
to
mitigate
that
I
recommend
people
to
maybe
go
back
to
listen
to
the
video
I,
look
at
the
the
the
presentation
I've,
and
that
is
another
gap
which
are
needed
for
HD
ones.
Intelligent
path,
selection
think!
K
That's
it
that's
the
end.
Oh
the
next
step.
Okay,
so
here
I
just
listed
all
the
relevant
drafts
for
this
domain.
In
the
routing
area,
we
have
secured
a
VPN.
We
have
secured
our
VPN,
they
talked
about
how
the
way
stretch
a
PE,
far
away
through
the
untrusted
domain
and
there's
also
the
IDR
talking
about
a
new
and
RI
for
the
one
point
management
and
then
in
a
security
area.
K
There's
IPSec
ami
the
Sdn
control
key
ricky
management,
because
IPSec
needs
the
key
need
to
be
refreshed
periodically.
If
you
let
every
node
to
refresh
key
on
their
own
frequency
and
node
can
maybe,
if
you
have
10
IPSec
tunnels,
and
you
have
to
go
through
a
lots
of
process
so
that
drive
basically
document.
How
do
you
do
Sdn
controlled
the
Ricky,
then
there's
some
iTunes
SF
talk
about
initial
configuration
like
when
you
the
note
powers
up
for
the
IPSec
basic
configuration.
K
You
have
two
cases
when
is
a
key
based
configuration
by
controller
another
one
is
a
keyless.
Just
assuming
a
node
is
the
IOT
device,
doesn't
have
a
power
to
handle
the?
I
key
I
give
me
two,
then
what
are
the
procedures
to
do
the
initial
configuration,
so
that
is
in
the
i29
self
and
there's
also
the
in
ops
area?
There
is
a
SD
one
service
model,
I
forgot
a
listed
there's.
K
Another
data
model
being
listed
in
the
RTG
working
group,
which
was
presented
last
session,
is
more
about
intern
vendor
exchange,
because
that
that
is
under
the
assumption
that
all
the
sd1
deployment
single
vendor
domaine.
So
when
the
traffic
crosses
the
vendor
domain,
what
kind
of
pass
information
need
to
be
exchanged?
So
there
was
a
drag
for.
The
RTG
working
group
in
the
ops
area
is
more
from
the
operators
perspective.
The
operators
perspective
is
about
okay
from
operator.
One
set
up,
the
sd1
I
may
have
different
vendors,
but
how
I
do
it
from
client
perspective?
K
What
kind
of
policy
he
wants?
How
do
we
want
to
set
out
the
the
appear
association
so
a
different
angle,
so
the
the
ops
working
groups,
the
the
data
model,
is
more
aligned
with
mu
F's
model,
which
is
like
service
provider
perspective,
the
one
being
presented
at
RTG
working
group
on
third
tuesday
right.
That
was
more
from
vendor
perspective,
say
if
you
are
enterprise
and
you
buy
vendor
a's
devices,
and
maybe
your
traffic
need
to
reach
change
with
another
vendor.
K
B
So
the
I
just
had
a
general
question
about
sort
of
how
the
focus
of
the
two
documents,
the
problem
statement
and
the
gap
analysis,
because
the
the
gap
analysis
document
really
focuses
on
SD
when
it
generically
and
not
so
much.
The
idea
is
connecting
an
SD
win
to
a
cloud
mmm-hmm
to
some
extent,
it
seems
to
be
providing
the
framework
for
a
lot
of
protocol
work
that
you're
doing
to
eventually
allow
Sdn
solutions
to
be.
You
know
standard,
not
right
now,
dusty,
grant
solutions
are
sort
of
a
proprietary
glue
in
them.
Right
is
that?
M
K
So
the
intention
is
really
because,
when
you
see
sd1,
many
people
interpret
it
as
just
a
branch
office
interconnect
with
two
links:
that's
very
narrowly
scoped
and
the
we
call
it
a
network
cloud.
Datacenter
is
more
about.
How
do
we
interconnect
the
underlay
network
with
the
cloud
datacenter?
Where
is
the
main
drive
now
for
sd1?
You
know,
st1
has
been
in
the
market
for
maybe
six
seven
years
initially
started
with.
K
Oh
I
can
deploy
a
cheap
box
to
aggregate
all
the
bandwidth
together,
but
that
never
really
fly
well
in
the
in
the
industry
has
deployment,
but
the
appointments
very
little,
and
as
of
now
like,
for
example,
in
anak,
many
of
the
enterprises
stated
that
the
reason
we
need
sd1
is
not
because
we
want
to
achieve
or
we
want.
The
low-cost
is
primarily
is
for
us
to
have
a
way
to
reach
cloud
workload
in
the
cloud
anywhere
any
place.
K
So
when
you
reach
the
workload
in
the
cloud
datacenter
you
have,
you
have
to
go
through
your
underlay
Network
for
sure,
like
from
your
enterprise
out,
you
have
to
go
through
an
underlay
down,
then
you
have
to
go
over
to
the
internet,
the
overlay,
so
the
reason
I
call
it.
We
call
it
Network
to
cloudy
see
it's
because
of
reaching
to
emphasize
the
the
Focus
ST
wines,
not
just
branch
office
interconnection.
If
I
write.
B
However,
the
actual
focus
and
text
in
the
gap
analysis
document,
a
lot
of
the
examples
are
and
I'm
not
suggesting
you
change
the
examples
to
be.
You
know
cloud
connected,
but
a
lot
of
them
are
simply
SD
ran
without
you
know,
involving
the
particulars
of
the
cloud
and
I
I.
Think
it's
useful,
regardless
I
I
worry
that
people
won't.
You
know
just
looking
at
the
tie,
won't
necessarily
know
where
to
look.
Okay
right.
K
E
Agree
with
Chris
on
this
point
and
they're
sort
of
focus
on
bootstrapping,
not
traversal,
this
kind
of
stuff-
that's
not
really
cloudy
stuff
right,
so
it
would
be
good
if
you
put
maybe
bit
more
definite
examples
with
regards
to
what
requires
to
connect
to
such
services
as
a
lot
of
cases
to
just
break
out
right
so
to
define
this
models,
how
people
do
connect
from
sd1
domain
into
cloud?
To
me,
okay,.
N
E
P
P
P
P
P
So
in
order
to
provide
so
that's
a
normal
operation,
so
in
order
to
provide
equal
protection,
so
we
needed
to
do
more
work
here.
We
need
to
configure
the
Nero
s
ID
to
protect
the
egress
ps3.
So
you
more
details
which
we
need
to
configure
mirror
ID,
for
example,
give
a
variety
here
and
then
protect
the
locator
which
is
associated
with
with
p3.
So
with
this
information
and
under
the
other
information
such
as
the
VPN
routes
and
then
with
those
information,
p4
will
create
a
mapping
which
we
are
my
pin.
P
Data
Bureau
ID
with
the
whipping
ID
which
is
associated
p3,
might
be
my
pin
that
that
one
to
the
local
VPN
vaping
IDs,
because
those
kind
of
a
variety
and
locator,
which
is
a
variety
protected.
We
also
teach
tributing
in
the
network.
So
when,
when
DC
in
from
when
P
P
1,
which
is
the
APIs
upstream
hope
of
us
know,
the
ps3
receives
those
informations.
P
It
will
compute
back
half
of
us
from
here
on
to
the
pi
Kappa
equals
no
to
PF
o
so
with
Josie
Pye
campus
and
also
it
world
check
updates
for
wardens
on
PG
one.
So
with
those
information,
and
so
as
p3
fails.
Pg
1,
we
attacked
a
failure
and
then
we'll
send
the
traffic
to
the
pi
Kappa
equation
or
the
PG
4.
So
when
p1
send
those
packages
to
PI
capital,
P
4,
it
will
push
that
Amero
s
ID.
P
So
this
package,
with
Marisa
D,
versatile
peeve
or
so
after
Kiev,
or
received
the
package
with
those
of
variety
and
also
the
vbid
associated
to
p3,
and
then
people
will
use
the
information
to
Mac
those
package
map
to
the
local
baby
in
vaping,
as
ID,
so
using
local
vape
living
anxiety
where
TV
for
that
that
traffic
to
the
same
c2.
So
that's
the
idea
about
of
the
egress
of
protection.
P
So
here
in
order
to
provide
equal
protection,
so
we
need
to
distribute
the
MIR
ID
and
locators,
which
is
the
protected,
which
is
to
be
protected
by
the
beer
I
D.
So
the
last
is
the
appropriate
engines
to
distribute
those
those
informations.
So
regarding
the
port
of
contention,
and
we
need
to
use
them
to
ask
SS
and
similarly
and
aahs
oohs
here
so
for
SS,
the
Xfinity
is
simple
and
then
we
just
just
define
a
new
sub
T
of
V.
So
this
new
software
V
is
in
the
SF.
P
Is
six
locator
tell
V,
so
this
Sabater
v
basically
were
contains
the
mirror,
ID
and
then
stops
some
sub
T
of
V.
So
most
here
we
just
define
the
two
sub
T
of
visa
under
this
apathy
of
V.
So
why
is
allocated
subjective
V
is
the
locator
and
then
which
is
to
be
protected
by
the
mirror,
partner,
ID
and
also
me.
We
may
have
protector
that
the
other
protectors
IDs
to
be
protected
by
the
mere
ID.
So
that's
the
attention
to
access.
Similarly,
we
have
extensions
to
all
ocf.
H
Okay,
great
mercy
city
couple
reflections.
Well,
it's
like
deja
vu,
I
recall
we
had
the
similar
discussion
on
our
CP
T
OSP
egress
protection-
that's
one!
The
second
one
is
that
III
think
that
would
be
good
to
get
more
strong
case.
Why?
It's
you
consider
it
useful,
because
you're
effectively
changing
the
paradigm
or
proposed
benefit
of
s
are
not
creating
the
state
in
a
transit
note,
yeah.
P
Regarding
the
first
question:
yeah,
we
have
RFC
and
I'm
the
main
author
of
that
RFC
or
provider
equal
protections
yeah,
that's
a
as
I
need
to
maybe
some
some
kind
of
similarities.
Yeah.
Maybe
we
can
add
some
reference
here
in
you
know,
draft
recognize
a
question
and
then
we
add
some
some
states
in
the
in
the
middle
point.
Yes,
because
you
can
get
up
for
one
more
functions,
so
be
the
look.
H
H
If
customers
need
these
functions,
that
probably
they
need
can
have
some
other
alternative
solution
like
CEC
monitoring
and
redundant
connections
between
C
and
P.
So
there
are
alternatives,
technologies
already
available.
Why
to
complicate
a
serve
one
of
the
advantages
of
SR.
Is
that
simplicity
for
the
transit
node?
So
why
to
break
it
because
effectively
you're
proposing
to
go
back
to
RSVP
T.
H
You
still
again,
you
still
need
to
monitor
your
backup,
because
you
cannot,
you
monitor
only
working
path.
You
need
to
cut
monitor
your
backup
because
back
up
might
go
down
so
again,
you're
creating
hell
of
a
lot
of
new
state
and
complexity.
I
think
that
I
suggest,
let's
better
first
to
this
discuss
whether
this
complexity
is
justified.
P
Mentioned
that
we
need
a
more
use
at
the
backup
path,
I
think
for
the
other
protection
ways.
We
also
need
the
mood
in
the
back
of
house
right
evil
so
either
way
more
than
Bahamas
or
we
need
a
computer
back
of
house
are
dynamically,
so
we
have
two
ways
right:
if
we
computed
back
apostille
a
movie
and
then
maybe
not
fast
enough,
so
in
the
other
way,
we
I
think
we
also
need
more
in
the
back
of
house
right
again.
H
H
You
advocating
dynamic
calculation
on
a
upstream
node
of
backup
for
egress.
I
can
say
that
with
the
same
expediency
can
be
done
in
a
centralized
controller
or
the
head
end
and
converged
all
things
together.
So
again,
I
suggest,
let's
build
first,
discuss
the
case
and
then
consider
whether
we
need
to
solve
it
or
not.
Yeah,
please
republic,.
Q
Build-Up,
shellac,
Cisco.
So
contrary
to
what
has
been
said
here,
I
think
this
is
interesting
problem
to
solve.
The
problem
with
your
proposal
is
that
it
only
works
if
you
have
the
same
work
on
both
species,
which
may
not
be
the
case
because
you
are
actually
protecting
the
locator
and
the
second
thing
is
this:
may
work
for
a
DT
sits
for
Paris
Tec
HDX.
This
would
require
some
kind
of
sign
synchronization
between
the
bees,
how
they
sign
the
labels.
So
there
is
more
work
to
be
done.
Q
J
Okay,
Jaden
chromoly,
actually
I
think
this
is
a
good
idea
to
solve
this
a
use
case
and
that's
in
the
key
difference
repeat
from
the
RC
BT
based
methods,
the
means
that
we
don't
introduce
Pro
passed
it
into
the
network.
Actually,
you
can
monitor
the
back
of
a
pass,
but
you
can
also
use
other
ways
do
to
protect
the
pocket
pass
also.
So
this
is
a
about
OEM,
not
just
stating
the
forwarding
thing.
R
But
why
do
we
need
to
protect
it
using
the
IGP
here
BGP,
you
can
advertise
the
backup
path,
because
you
learn
the
prefix
both
on
from
p3
as
well
as
pe4.
So
p1
already
have
two
primary
and
backup
path
through
bgp,
so
these
are
already
resolved
in
SR,
MPLS
or
anywhere
else
right.
So
if
you
have
a
CD
dual
home
C
and
there's
p3
and
p4,
both
will
Alta
is
a
VPN.
Prefix
and
p1
will
already
have
two
paths
and
if
the
p3
goes
down,
then
it
will
work
right.
J
R
P
R
P
So
here
we
talk
about
a
protection
history,
which
is
the
he
grace
note
offer
this
as
a
pass
and
then
when
this
piece
we
fails
and
the
traffic
were
not
at
which
to
fascinations
the
c2
right.
So
with
this
a
faster
local
protection,
she
won,
because
she,
why
is
a
direct
adjacency
of
ps3?
But
so
p1
can
quickly
detect
the
failure
piece
we
and
then
he
can
quickly
switch
the
traffic,
but
with
the
PP
for.
P
H
Again,
you
you
only,
you
can
differentiate
the
node
failure
from
the
link
failure,
so
you
can
have
multiple
hops
between
p1
and
p3
in
the
segment
routing,
because
you
can
have
combination
so
loose
strict
routing
and
there
will
be
multiple
nodes
between
TR,
t1
and
t3.
So
that
would
be
a
channel
and
you
don't
know
what
failed
in
a
tunnel.
T3
can
be
perfectly
fine.
Yeah.
P
B
The
line
here
and
the
discussion,
so
this
is
really
good
discussion,
I
think
so
personally,
I
think
it's
a
problem
that
that
does
need
solving.
If
the
people
you
know,
we
have
a
couple
minutes,
but
let's
just
we'll
cut
the
line,
let
the
two
people
speak
and
then
continue
to
the
next
presentation.
I.
N
So
this
is
a
mantra
from
Siena
I
think
there
are
a
couple
of
things
here
that
has
been
said
in
the
ad,
the
mic.
If
you
are
doing
BGP
pick
and
if
your
p3
node
goes
down,
if
you
are
doing
multiple
pi
p
PF
t
it
will
automatically
switch
to
p4.
But
if
your
link-
and
if
your
linked
to
p3
to
CT
c
2
goes
down,
then
you
have
the
you
know
the
withdraw
and
that
will
take
some
time
so
that
in
that
particular
case
you
can
have
this
egress
protection.
N
If
this
egrets
protection
will
not
work
there
either,
because
p3
node
is
fine,
it
is
the
cp3
to
see
to
link
has
gone
down.
So
this
has
a
limited
scope
in
that
sense.
As
far
as
the
backup
path
is
concerned,
that
mirror
seed
is
already
programmed
as
a
alternate
next
hop
when
P
p1
detects
the
failure
to
link
to
the
p3
or
the
node
of
p3
node
failure.
Maybe
then
that
that
case
work,
but
there
are
other
solutions
to
handle
that
as
well.
That's.
E
S
E
O
O
Okay,
so,
as
we
know,
I
saw
FC
and
I
fit
guy
important
past
services
and
for
each
pass
service.
There's
encapsulation
Hyder
has
been
defined,
for
example,
the
I
Freight
encapsulation.
There
is
a
IOM
Hyder,
pbd
Haider
and
as
well
as
the
IFA,
so
just
a
move
to
from
the
six-man
session.
It
seems
in
that
room
people
has
got
consensus
that
we
need
to
carefully
consider
the
the
design
for
the
ipv6
encapsulation
for,
for
example,
IOM.
So
here
in
this
piece
of
work,
we
are
doing
the
same
thing,
so
we
are
considering.
O
O
So,
just
to
give
example
here
is
the
IOM.
So
we
see
this
is
the
IOM
package
and
in
the
tracing
mode,
if
the
package
traversing
along
the
path
and
the
IOM
data
is
going
to
become
very
large,
and
if
we
put
that
data
into
the
hop
by
hop
audio
h
and
option
hiders
so
in
the
right
part
of
the
string
that
we
show,
that
is,
the
ipv6
extension
higher
order
recommended
in
the
RC
and
a
200.
So
those
two
option
hiders
are
before
the
rh.
O
So
in
that
case
I,
the
data
becomes
very
large
we're
going
to
push
the
arch
out
of
the
parsing
ducts
and
out
of
the
parsing
the
window
in
the
chip,
so
that
will
impose
the
challenge
in
the
hardware
and
reduced
the
forwards,
forwarding
performance
and
also
another
point
to
think
about
this.
With
the
introduced
introduction
of
the
ice,
our
v6.
So
we
would
need
to
distinguish
the
ipv6
pass
and
as
our
v6
pass,
so
why
this
matters?
O
We
need
to
consider
the
optimal
location
to
place
those
dos
data-
and
the
third
point
is
the
meta
data.
Currently
they
are
recorded
separately
for
IO.
Am
I
free-
and
there
might
be
some
redundant-
are
inconsistent
meta
data
exists
and
also
for
the
future.
We
need
to
consider
the
extensibility
for
the
future.
The
future
proposed
path
services.
Next,
one
piece.
T
Joel
Halpern
with
Erics
and
I
have
a
couple
of
concerns
with
the
basic
premise
of
this
work.
My
objection
is
not
to
the
particular
format
it's
on
the
wire
it's
on
the
wire.
First,
we
have
multiple
encapsulations
and
this
is
an
unfortunate
reality,
but
it
is
the
reality
making
up
yet
another
one
has
never
solved
the
problem
of
too
many
standards
for
something
we
have
too
many
tunnel
encapsulations.
So
we
make
up
more
it
I,
don't
like
it,
but
I've
never
seen
make
up
another
one
cause
us
to
stop
using
the
others.
T
In
the
particular
case
of
SFC,
the
point
of
the
SFC
work
and
I
brought
this
up
when
a
yet
different
proposal
for
carrying
metadata
and
path
information
was
brought
up
in
the
spring
working
group.
The
point
of
SFC
was
to
provide
a
common
transport,
independent
encapsulation
of
path,
identification
and
metadata.
It
works
across
SR
v6s,
our
MPLS
conventional
MPLS,
genève
IP
encapsulation,
you
name.
It
works
the
whole
point
of
the
design.
T
The
reason
the
working
group
was
chartered
was
to
get
an
interoperable
mechanism,
so
we
didn't
have
an
N
squared
problem
that
we
had
an
order.
N
problem
creating
a
specific
SRV,
SR
v6
encapsulation
for
carrying
that
information,
precisely
undoes
what
the
community
agreed
was
important
when
they
chartered
SFC,
and
I
would
like
folks
to
consider
that
when
evaluating
this
work,
yes,.
O
Sure,
thank
you
for
your
comments.
Actually,
we
have
been
collecting
feedbacks
and
comments
over
the
IETF
104,
also
even
before
that-
and
this
is
one
comments-
I
think
that
ice
FC
case
is
a
special
case
is
a
additional
sauce
here.
So
we
agree
and
in
the
future
version-
and
we
need
to
take
into
your
comments.
I
T
T
If
somebody
wants
to
work
with
I'll
be
happy
to
work
with
somebody
if
they
want
to
do
a
wreath
in
of
that,
that
does
exactly
the
same
thing
in
a
nice
short
draft,
which
we
can
progress
very
quickly
once
the
SR
v6
base
dastan
on
how
to
do
exactly
the
same
thing
with
us,
our
v6,
because
it's
just
carry
it
and
we
have
Andy
held
the
pen
on
the
mpls
won
it.
It
was
very
easy.
T
That's
why
it's
already
been
approved
for
publication
as
an
as
an
RFC
in
the
MPLS
case
that
particular
one
works
for
both
conventional
and
pls,
and
segment
wrote
in
MPLS.
So
we
could
do
one
that
worked
for
ipv6
that
worked
for
conventional
ipv6
and
and
sr
v6.
If
somebody
wants
to
work
on
that
fine,
it's
an
easy
draft.
I
O
Ok,
I
will
continue
so
here
some
design
considerations
to
optimize
the
file
service
encapsulation
in
ipv6
and
SR
v6.
So
basically,
the
key
point
here
we
are
trying
to
propose
here
is
to
separate
the
past
service
encapsulation
into
two
parts.
So
the
instruction
part
end
the
recording
parts,
so
the
instruction
parts
will
be
put
in
the
service
option
is
what
we
proposed.
O
And
another
thing
is:
we
would
like
to
propose
this
IP
v
metadata
hider
and
that
is
to
contain
the
recording
part
and
it
can
be
taken
as
a
uniformed
unified
container
to
put
the
service
metadata
of
those
past
services
and
that
could
be
placed
after
the
routing
header.
So
the
benefits
of
doing
this
is
when
you
realize
there
are
too
much
data
in
the
too
much
metadata
in
the
package.
So
you
could
choose
to
stop
a
recording
and
in
so
that
could
avoid
reaching
the
hardware
limitation
next
piece
and.
O
Here
are
the
service
options
we
have
defined
if,
for
example,
the
iOS,
the
resorption
PBT
and
IFA
service
options,
and
this
is
the
places
we
recommend
to
place
those
service
options
next
to
this
next
piece-
and
here
is
the
ipv6
metadata
hider
and
here
the
structure
and
also
for
each
service
tab.
We
could
have
this
service
metadata
to
contain
the
data.
Next,
please.
O
So
this
is
the
key
takeaway
message
just
a
repeat
here:
we
are
trying
to
propose
to
separate
the
path
service
encapsulation
into
two
parts
and
the
one
is
service
option,
the
other,
the
ipv6
metadata
hider,
the
benefits
of
doing
this.
We
could
keep
the
hider
as
short
as
possible
and
and
and
also
fixed.
So
in
that
case
we
could
keep
the
the
performance
that
forwarding
performance
on
the
data
plane
and
also
we
in
that
case
we
could
have
the
capability
to
choose
to
stop
recording
the
the
metadata.
So
the
next
piece.
O
E
Q
E
O
O
If
we
want
to
do
the
IOM,
we
have
to
put
our
inserted
data
somewhere
in
the
package,
and
the
thing
here
we
are
trying
to
do
is
to
find
the
optimizer
way
to
keep
the
forwarding
performance
with
the
consideration
that
is
somehow
is
going
to
damage.
So
that
is
the
the
considering.
Thank
you.
Thank
you.
Okay,.
H
H
B
H
H
So
if
you
do
protection,
then
you
have
extra
on
in
the
water
speed.
You
need
to
do
I,
don't
know
sha-256
on
the
data
at
the
wire
speed
right,
so
I
think
that
need
to
be
very
careful,
proposing,
adding
something
in
a
packet.
I
think
that
we
need
to
consider
other
option
how
to
collect
on
path
telemetry,
and
there
are
already
proposals.
Okay,.
U
H
O
The
security
I
think
we
have
two
parties,
one
is
a
you
mean
the
security
of
the
data.
The
other
way
is
the
way
to
do
it.
To
precise
the
data
will
impose
some
security
risk
right,
so
I
think
in
the
ipv6
header
there
is
already
the
authentication
I
mean
other
hiders
to
do
this,
and
also
in
the
ice,
our
basic
CRV.
They
have
the
the
the
solution
to
do
to
fix
the
security
problem.
Okay,.
H
O
E
H
M
M
M
The
only
problem
right
now
we
we
are
having
is
right.
Now
the
draft
is
showing
errors
because
of
the
tool
is
now
picking
up
those
models.
We
have
a
dependency,
so
we
are
using
some
actually
models.
The
ITF
to
that
is
now
picking
up
lots.
So
I,
don't
think
any
the
house
directors
are
now
here
so
I
guess
this
is
an
IPF
issue.
We
we
probably
want
to
fix
those
tools,
Ignace.
M
M
S
M
M
M
If
not,
then
the
next
one
okay,
so
this
is
actually
a
rib
extension
model.
The
one
two
extension
extend
the
the
model
defined
in
Wellington,
the
rape
defined
in
adult
in
config
model.
So
this
one
just
became
working
group
document,
but
before
this
idea
that
we
actually
have
this
model
for
three
years
already.
So,
although
it's
just
became
a
working
group
document,
but
the
only
changes
we
did
before
they
say:
I
D
ETF
editorial
changes.
M
We
also
had
some
combined
trade
over
Graham
from
this
idea
brought
in
heavy
appendix
so
we
plan
to
add
more
examples.
Just
you
know
to
help
people
understand
how
to
use
this
model,
but
the
content
of
this
draft
is
complete.
So
we
want
to
collect
more
review
comments
and
requests
start
a
young
doctor
review
and
we
want
to
we'd
like
to
progress
this
model,
so
maybe,
after
the
policy
model
whip,
we
would
like
to
last
call
this
one.
M
V
V
Issues
were
caused
by
protocol
failures,
and
so
with
monitoring
and
analysis
of
control
and
data.
The
detecting
and
recurse
analysis
of
the
issues
can
be
improved
and
then
the
other
type
of
applications
would
be
in
our
planning
so
with,
for
example,
with
more
detailed,
more
information,
you
can
have
better
route,
optimization
and
stuff
like
that,
and
another
thing
is
that,
with.
V
With
policy
information
correlated
with
route
attribute
information,
you
could
do
applications
like
route
validation
and
yeah.
So
we'll
discuss
some
use
cases
and
before
that,
here's
a
the
problem
space
that
we
we
discussed
it
for
each
use
case.
So,
starting
from
the
data
generation,
the
data
source
types
are
discussed
and
also
the
network
device
coverage
and
also
discussed
here.
So,
for
example,
what
type
of
data
should
be
retrieved
from
what
devices
and
then
I
comes
to
the
data
processing
the
data
encapsulation
serialization
subscription.
So
in
this
part
the
processing
efficiency
should
be
considered.
V
Of
course,
performance
should
also
be
guaranteed
and
then
and
then
it
comes
to
the
data
analysis
at
the
controller
side
and
in
here
the
analysis
is
very
application
specific
and
the
problems
such
as
data
synchronization
and
data
correlation,
because
we
have
Puma,
have
multiple
options
and
and
data
sources.
So
these
these
questions
should
be
considered
with
your
India
data
analysis,
okay
and
to
use
cases
very
quick.
The
first
one
is
easy.
V
V
In
this
case
the
device
may
have
some
diagnose
information
and
it
could
be
issued
from
the
device
and
and
sent
to
the
controller,
but
in
other
cases,
for
example,
there
are
software
or
hardware
packs
in
this
case
that
rice
does
not
Cape
is
not
capable
diagnosing
the
issue,
so
in
that
case
the
SDP
and
also
the
center
received
LSPs
are
required
to
be
collected
and
compared
to
localize,
where
the
issue
actually
happens.
Okay-
and
then
let's
see
this
one,
so
the
example
that
I
want
to
discuss
is
the
addition
of
group
policies.
V
So
currently
policies
can
be
exported
using
either
a
PC
or
an
aircraft
with
Llamados.
However,
it's
not
sufficient
to
do
policy
validation.
You
need
to
have
the
way
to
correlate
the
exact
part
of
the
policy
processing
with
the
policy.
Sorry
was
they
wrote
to
attribute
change?
Okay,
so
with
such
correlated
work
hard,
then
the
operators
can
have
a
very
clear
view
villain
how
each
policy
is
exactly
changing
its
roots,
okay
and
that
helps
with
the
troubleshooting
and
also
the
validation
of
your
policy
and
also
alright,
that's
just
up
there.
V
Okay,
so
there
are
more
use
cases
in
our
draft
and
if
you're
interested,
please
read
the
draft
and
provide
some
comments
for
us.
So
here's
a
a
quick
summary
from
the
use
cases.
We
think
there
should
be
a
a
tunnel
for
the
controller
data
to
be
exported.
So
when
building
this
tunnel,
the
data
processing
performance
should
be
guaranteed
per
specific
use
cases
and
then
and
then
the
second
requirement
is
to
guarantee
the
data
coverage,
because
some
data
has
already
been
is
able
to
be
exported
in
our
days.
V
E
E
K
V
O
W
Of
all
I
see
like
just
sure,
okay,
sorry,
this
is
regarding
the
prior
presentation.
I
mean
I'm,
not
questioning
the
need
to
debug
networks,
but
it
seems
like
we're
doing
all
this
work
to
reduce
flooding
in
LSR,
and
here
you
have
a
proposal
to
collect
every
link,
state
packet
and
everything
from
every
router
and
IG
BP
domain.
I.
Think
it's
I
think
you
can
do.
You
could
do
something
that
was
a
lot
thinner
it
with
an
IG
P.
Then
what
was
in
this
picture?
I
just
saw
I.
B
Mean
that
that's
that's
useful,
but
at
the
same
time
I
think
that
was
actually
from
a
an
actual
customer
use
case
that
large
networks
find
it
useful
to
actually
compare
as
a
you
know,
kind
of
like
a
third
party
check,
I,
don't
like
traffic
lights,
have
circuits
like
BMP
for
for
is
eyes.
Yes,
yes,
I.
W
X
Y
Y
Ldp
was
first
published
in
January
2001
RFC
303
six,
it
was
it
replaced.
You
know,
as
a
progressed
on
the
standards
track
by
503.
Six
and
2007
LDP
specified
the
use
of
TCP
md5
signature
option
for
the
authenticity,
integrity
of
LDP
messages
and
to
prevent
against
LTP
spoofing,
and
that
is
still
the
case
that
has
that
has
not
changed.
However,
as
far
back
as
1998,
the
IETF
has
been
aware
of
problems
with
md5
see,
for
example,
RFC
2385.
Y
So
in
2010
we
wrote
our
C
59
25,
which
deprecated
the
TCP
md5
signature,
optionally,
replaced
it
with
the
TCP
authentication
option,
TCP
a
oh
and
then
there's
a
companion
RFC,
which
actually
specified
the
cryptographic.
Algorithms,
such
as
AES,
128
or
256,
that
you
could
use
with
TCP
ao
and
then
RSC
74/54
in
2015
took
the
step
of
deprecating
md5
for
BGP
and
in
replacing
the
Oso
misses
step.
Y
Rfc
69
52
in
2013
recommended
that
all
tcp-based
routing
protocols,
which
includes
BGP
and
LD
P,
for
example,
but
there
are
others
as
well,
move
from
md5
to
TCP
AO
and
that
happened
for
BGP
in
February
2015,
when
our
C
74/54
deprecated
md5.
For
a
BGP
and
replaced
it
with
TCP
ao,
however,
LDP
continues
to
use
md5.
So
that
brings
me
to
my
last
slide,
which
is
the
goal
of
this
draft
is
to
do
the
same
thing
for
LDP
that
we
did
previously
for
bgp,
which
is
to
deprecate
md5
and
replace
it
with
TCP
ao.
Y
However,
we,
the
combined
authors,
are
really
much
more
LDP
experts
than
we
are
security
experts,
and
we
have
some
questions
that
we'd
like
to
throw
open
to
the
audience
here.
We
wanted
to
give
it
a
wider
audience
than
just
the
MPLS
working
group.
The
first
is
how
successful
has
TCP
AO
been
through.
Bgp
is
TCP
ao
actually
used
in
the
field
for
BGP?
We
don't
know,
do
any
of
you
know,
and
here
comes
Jeff
Haas.
X
Stay
for
the
record
that
the
routing
ADEs
had
asked
me
and
a
few
other
people.
Sorry
that's.
Can
you
hear
me
now
yeah
stay
for
the
record
that
the
routing
ADEs
had
asked
me
and
a
few
other
people
to
try
to
put
together
the
status
of
things
and
some
notes
for
the
security
group
almost
a
year
ago.
Now
no
there's
been
no
cycles,
so
that's
not
actually
happened,
but
the
answer
the
specific
question
here:
TCP
AO,
is
finally
starting
the
sea
deployment,
no
we're
seeing
it
from
at
least
one
vendor.
That
is,
that
my
employer.
X
That
said,
we
don't
have
experience
in
the
field
to
see
how
well
it's
working,
but
there
at
least
it's
starting
to
show
up.
So
that's
good
problem
that
you
have,
unfortunately,
is
that
TCP
AO
protects
one
half
of
LTP.
You
know
if
he's
got
that,
obviously
the
transport
session,
they
carry
all
the
state,
but
it's
also
got
a
hello
mechanism
as
well
right.
So
the
problem
is
TCP.
Ao
is
only
gonna
cover
half
of
your
story.
What
are
you
doing
for
the
other
half
right.
X
Z
Wanted
to
correct
a
little
bit
of
the
history,
you
said
that
74
or
50
for
deprecated
75,
it
didn't
really
it
didn't,
update
the
base
pack
or
anything
else.
All
it
said
was
if
T
CPO
is
preferred
is
available.
It
should
be
preferred
and
actually
comment.
Paragraphs
later
it
says
that
protecting
the
sessions
is
not
required.
So
yeah
I
tried
to
go
further
to
saying
that
we
should
do
better
than
md5,
but
I
don't
think
it
was
strong
enough
at
that
point.
Okay,.
G
Y
G
X
Jeff
as
again,
it's
worth
pointing
out
that
AO
solves
no
the
TCP
type
problem.
If
what
you're
really
trying
to
do
is,
you
know,
add
a
layer
security
on
top
of
it,
it
may
be
time
to
play
with
IPSec
IPSec
snot,
my
favorite,
that
chainsaw
to
use
for
its
security,
it's
very
tricky
to
use
in
the
majority.
The
headache
is
to
figuring
out
how
to
configure
things,
but
it
does
cover
both
streaming
protocols
like
TCP
and
also
Datagram
protocols
like
the
UDP
discovery
component.
You
can
do
both
things
there.
X
You
can
actually
use
static
security
associations
if
you
really
wanted
to
you
can
use
like
if
you
actually
wanted
to
do
things.
The
challenge
that
IPSec
has
is
that
that
it's
not
an
appropriate
tool
to
you
know,
get
it
working
just
that
the
way
security
people
really
want
to
use.
The
thing
tends
to
push
into
interesting
chicken
and
egg
type
problems
for
protocols,
which
the
whole
point
is
to
get
the
network
up
and
running
right.
D
X
Little
bit
of
that
stuff
was
covered
in
the
carp
working
group
back
of
the
day.
There's
some
notes,
I
think's,
that
covered
ldt
in
that
circumstance
that's
worth
scraping
through,
but
my
suspicion
is
that
if
you
were
to
take
some
random
sets
of
LD
key
implementations
and
spend
probably
a
couple
of
days
worth
of
the
fielding,
you
could
probably
get
IPSec
to
cover
every
situation.
You
really
need.
If
that's
really
your
concern
cool.
Y
Now,
if
I
can
ask
you
to
state
the
mic
for
a
second,
because
you
may
have
input
on
my
next
question,
seeing
as
as
you
already
stated,
that
you're
aware
of
some
use
of
TCP
a
Oh
in
the
field
for
bgp.
The
next
question
is
assuming
that
we
do
this
for
LDP
as
well,
which
crypto
algorithm.
Should
we
choose?
There
are
a
choice.
X
Security
people
are
looking
to
provide
appropriate
level
of
coverage
for
things,
and
sometimes
the
tax
base
is
unclear
to
them
and
therefore
the
solutions
they
offer
are
sometimes
rather
heavy-handed.
So
the
offer
easy
example:
no
BGP
you'll
have
a
BGP
direct
connections.
Securing
a
link
that
transport
session
runs
over
is
often
enough
to
provide
the
necessary
security
writing
TCP.
On
top
of
that
is
exercise,
they
tend
to
call
defense-in-depth
sure
it's
good
to
run
it
but
know
you're
less
motivated
to
do
so
when
the
transport
is
covered.
That
TCP
is
on.
X
However,
BGP
also
does
no
ibgp,
which
crosses
your
a
s
which,
oh
you
don't
know.
Customer
Yolo
do
bad
things
to
your
eternal
sessions.
Similarly
for
LD,
P,
New,
York
or
use
case
in
a
lot
of
no
circumstances,
it's
just
simple.
You
know
between
pairs
of
routers
and
therefore
the
necessity
of
covering
you
know.
The
session
is
not
quite
as
challenging,
but
also
for,
like
targeted
LVP
for
other
circumstances
as
well,
which
what
you
really
need
is
a
strong
enough
cipher
to
provide
protection
against
the
key
things.
You
know.
K
X
X
It
was
like
so
like
even
you're
using
IPSec
authentication
header
might
be
enough
to
provide
you
all
the
integrity
checks
to
keep
your
session
theme
locked.
The
additional
security
you'd
get
from
a
cipher
to
provide
secrecy
as
a
property
may
be
overkill
for
much
comes
down
to
do
you
care
if
somebody
actually
sniffs
on
your
labels
or
not
some
cases,
you
might
do
that.
You
know
might
have
know
some
three-letter
agency.
That
actually
cares
about
such
things,
but
the
other
thing
that
TCP
AO
gives
you
aside
from
you
know.
X
Just
simply
the
doll
ready
to
use
better
ciphers
is
it
gives
you
cipher
agility
and
a
common
property
for
cryptography,
and
this
is
where
you
go
find
a
real
code.
Talker
think
you
know,
the
real
story
about
things
is
that
you
want
to
use
something.
That's
strong
enough
for
the
lifetime
that
you
care
about.
If
you're
trying
to
provide
end-to-end
secrecy
over
a
huge
amount
of
time,
you're
using
the
strongest
cipher,
yet
you
possibly
can,
but
all
the
consequences.
X
If
you're
trying
to
provide
just
integrity
of
things,
you
use
a
strong
enough,
cipher,
that's
protected,
will
protect
you
over
a
reasonable
period
of
time
and
if
you're
rotating
your
keys
on
a
reasonable
enough
basis,
they
may
not
be
able
to
catch
up
with
you
before
you've.
Actually,
don't
change
them
out.
So
a
lower
horsepower
cipher
may
get
you
exactly
what
you
need
as
long
as
the
key
rotations
work
appropriately
in
the
case
of
spao
that
mechanisms
player
in
the
case,
I,
P,
SEC,
I,
guess,
unfortunately,
the
mechanism
they
use.
X
D
Question
I've
been
asked
for
Stuart
I've
been
asking
for
around
here:
I,
don't
know
who
to
address
it.
To
is,
if
we
spun
the
md5
key,
often
enough,
would
that
be
good
enough,
and
how
often
would
we
need
to
spin
it
so
that
the
security,
a
DS
would
be
happy
because,
since
we
originally
did
these
designs
we're
no
longer
running
Reuters
with
scripts
that
stay
there
forever
we're
in
a
world
where
network
management
systems
and
Sdn
systems
spin
this
sort
of
config
all
the
time.
X
Normally
you'd
say
I'm,
not
a
lawyer.
In
this
case,
I
am
NOT
a
cryptographer
hard,
an
answer
that
I
am
aware
of
as
cover
to
covered
by
two
things.
There
are
known:
semi,
real-time
attacks
against
md5
as
a
cipher.
At
this
point
by
cryptographers
you
can't
you
can
have
big
enough
horsepower
boxes
to
do
this
sort
of
thing
and
even
with
the
H
Mac
md5,
that's
recommended
these
days.
X
Cryptographers
tell
you
don't
do
that
just
a
weak
cipher
at
this
point,
but
the
second
half
of
the
observation
is
the
existing
TCP
md5
provides
no
mechanism
for
key
rotation,
so
the
side
effect
of
that
is,
if
some
implementations
may
allow
you
to
use
coordinated
clocks
to
try
to
swap
out
your
ciphers
at
an
appropriate
time.
You
configure
effectively.
Cipher
1s
are
a
key
one
number
one
key
number
two
and
a
time
X
are
coordinated
by
a
clock.
You
start
using
validation
against
both
ciphers.
X
What
you
see
the
new
cipher,
no
validating
you
drop
a
new
key
validating.
You
drop
the
old
key,
so
you
can
turn
mechanisms
that
are
deployed
that
allowing
to
get
that
sort
of
thing,
but
they
don't
always
work
very
well
and
the
consequence
of
them
not
working
is
that
your
BGP
drops.
Let
me
know
that
bgp
drops
yours
bad.
The
whole
point
is
t
s--
bao
is
that
it
provides
the
necessary
protocol
plumbing
so
that
this
stuff
could
happen
smoothly.
Okay,.
N
What
I
wanted
to
find
out
is
your
goal
is
to
then
come
to
a
conclusion
and
make
a
definitive
recommendation
for
whether
to
use
drop,
md5
and
usage,
H
Mac,
md5
I
think
H
Mac
amplifies
becoming
more
as
a
replacement,
so
I
mean
there
are
things
ongoing,
I
think
we
need
the
conclusion
as
soon
as
possible.
Okay,.
Y
Okay
thanks
and
that
actually
comes
up
to
my
last
question,
which
we
we
got
some
kind
of
it.
We
did
get
one
answer
in
the
mpls
session,
so
my
last
question
was:
does
anyone
really
care
and
is
anyone
currently
using
md5
with
LD
P
in
the
first
place,
and
it
turns
out?
The
answer
is
yes
from
at
least
one
vendor
reported
that
they
know
of
at
least
ten
of
their
services
right
of
customers
that
are
actively
using
md5
with
LD
P,
but
the
buts
questions.
Are
they
aware
of
their
problems
with
md5?
Y
We
do
not
know
the
answer
to
that
question
so
anyway.
I
think
that
this
has
actually
been
quite
successful
in
terms
of
the
presenter
presenting
both
MPLS
working
group,
and
here
we
got
some
really
good
feedback.
It
looks
like
there
is
reason
to
continue
this
work.
One
of
the
questions
we
were
asking
these
questions
was,
you
know,
should
we
continue
the
work
and
it
looks
like
there
is
reason
to
continue
the
work
and
and
I
think
we
have
a
good
consultant
to
talk
to
now
too,
to
help
us
with
that.
E
The
working
group
member
md5
it
deployed
I,
used
to
work
for
a
number
of
vendors
and
we've
seen
it
significantly
deployed
and
when
the
issue
of
md5
floss
products,
usually
it's
an
interior
protocol-
doesn't
leak
out.
So
we
don't
really
care,
so
it
would
be
quite
difficult
to
get
operators
to
do
something
properly.
In
this
case,
it's
personal
opinion.
Okay,.