►
From YouTube: IETF92-SPRING-20150326-1740
Description
SPRING meeting session at IETF92
2015/03/26 1740
A
A
A
The
note
well,
which
you've
no
doubt
already
noted
well,
but
yet
we
still
should
keep
it
in
mind.
In
particular,
we
were
recently
reminded
by
the
six-man
people
that
I
PR
disclosures
early
and
often
are
very
important
to
you
know,
maintain
good
relations
with
all
our
neighbors,
so
we
should
anyway
right.
So
we
wanted
to
talk
some
about
our
charter,
how
we're
making
progress
towards
it,
and
you
know
we
spent
some
time
Bruno
and
I
spent
some
time
looking
at
our
actually
quit
large
zoo
of
drafts
that
we
have
and
trying
to
figure
out.
A
A
I'll
also
point
out
that
that
there's
been
there
are
other
draft,
some
that
were
brought
quite
early,
some
that
are
continuing
to
arrive
that,
while
they
may
be,
you
know
very
good
and
you
know
laudable
work,
don't
actually
advance
our
Charter
and
what
you'll
find
is
that
we're
going
to
say
you
know
we're
really
hoping
to
focus
on
the
Charter,
we're
hoping
to
focus
on
advancing
the
Charter.
This
means
adopting
sort
of
the
minimum
necessary
set
of
documents
to
move
the
work
forward
and
not
possibly
every
single
draft.
A
That's
that
some,
you
know
in
existence
and
that's
not
met,
is
in
any
way
as
a
judgment
of
anybody.
As
anybody's
work,
this
happens
in
the
ITF
all
the
time.
So
our
first
point
from
the
from
the
Charter
is
we
charter
to
identify
and
evaluate
use
cases
for
spring?
They
must
include
a
definition
of
the
data
plane
for
the
environment
in
which
they
are
to
be
deployed,
and
then
we
have
a
milestone.
A
You'll
note
that
many
of
these
now
are
in
the
past,
despite
our
best
intentions,
so
one
of
the
things
that
the
chairs
will
be
doing
fairly
soon
is
going
and
putting
new
dates
on
the
milestones
that
are
in
the
future
one
or
more
documents
describing
spring
use
cases.
So
we
have
obviously
three
adopted
working
group
items
and
then
there's
a
number
of
other
use.
Cases
listed
here
and
I
said
it
on
the
slide.
I
didn't
talk
over
it,
but
you
know
we
just
made
our
best
effort
at
bidding
these
things.
A
Okay,
so
if
we
got
something
wrong,
you
know
tell
us
now
or
later
or
whatever
and
we'll
fix
it.
This
is
just
our
kind
of
first
pass
at
rationalizing
the
Charter
and
the
milestones
right
so
of
these
on
you.
No
problem
statement
is
kind
of
the
big
one
and
we
did
complete
a
working
group
last
call
and
we
were
awaiting
a
couple
of
administrative
things
and
you
know
I
don't
wish
to
find
fault
with
anyone
at
all.
A
Although
you
know,
if
there's
a
fault
to
be
found,
and
it
doesn't
get
anyone
else,
I
suppose
it
goes
to
the
chair.
So
there
we
go
Mia,
Maxima
culpa
for
not
chasing
down
the
necessary
people
and
saying
you
know
we
need
to
make
sure
we
get
all
the
IPR
statements
made
and
we
need
to
get
the
necessary
revisions
made.
I.
Think
that
you
know
we
are
now
on
track
to
have
this
done
fairly
soon.
There's
some
there's
a
document
update,
necessary
Stefano.
A
A
Okay,
then
the
kind
of
big
item
because
I
had
to
break
it
into
two
slides
is
the
second
thing
from
the
Charter
data
plate
encodings.
So
we
charted
for
definition
of
requirements
for
any
new
data
plan,
encodings
and
procedures
required
to
implement
the
use
cases.
Procedures
must
include
the
necessary
security
considerations,
so
we
we
have
a
high-level
abstract
architecture,
that's
adopted,
and
then
we've
got
several
na
is
here
requirement
for
modifications
to
mpls
architecture.
We
think
that
they're
basically
are
none
requirements
for
modifications
to
v6
architecture
I.
A
Let's
see
a
specification
of
any
required
new
procedures
to
support
spring
use
cases,
we
have
nothing
mapped
into
that
right
now,
one
or
more
data
plane,
extension
requirements
documents,
including
documenting
the
impact
on
existing
deployments
of
the
existing
and
data
plans
yeah.
So
to
some
extent,
these
requirements
are
maybe
implicit
in
the
architecture
and
the
data
plan
extension
documents,
and
then
we've
got
this
other
small
pile
of
drafts
that
that
may
be
may
be
applicable.
A
We
just
jumped
right
over
that
and
have
a
whole
lot
of
documents
in
virtually
well,
maybe
not
quit
every
other
routing
working
group,
but
a
lot
of
other
grouting
working
groups
and
I
think
that
one
of
the
things
we'll
have
to
do
is
decide
which
of
these
we're
tracking
as
working
group
items,
because
what
we
tentatively
agreed
to
do
is
that
we're
not
going
to
try
to
create
new
working
group
items
for
any
of
these
milestones.
We're
just
going
to
say
look
over
there
in
is
is
they're
doing
segment.
A
Writing
extensions
will
track
that
once
we've
cleared,
you
know
is,
is
and
ospf
and
whatever
else
we
decide
to
track,
then
we
will
say
that
our
our
milestone
is
complete
and
definition
of
requirements
and,
if
necessary,
management,
plane
mechanisms
needed
to
manage
and
operate
a
spring
enabled
network.
So
we
have
notably
no
adopted
working
group
drafts
here
and
I'm
going
to
say:
do
we
have
even
any
working
group
drafts
in
any
working
group?
I,
don't
think
so.
A
A
Then,
where
we
have
a
milestone
for
documenting
interworking
coexistence
between
new
procedures
and
existing,
so
basically
you
know
how
do
we
deploy
this
thing?
We
do
again
have
some
work
that
exists
here
again.
It's
not
adopted
as
working
group
items
and
again
we're
going
to
need
to
apply
some
focus
on
this
in
a
future
meeting.
Not
this
one
and
then
this
is
yeah
almost
the
last
slide
and
we're
almost
on
time.
A
So
we,
the
initial
data
plans
to
be
considered,
are
mpls
and
v6
and
so
far
the
only
and
I
kind
of
hope,
the
initial
and
complete
set
of
data
plans,
because
that's
enough
so
that
these
two
v6
related
drafts
were
presented
to
six
men
on
Monday,
Bruno
and
I
just
finished
having
a
meeting
with
the
six-man
chairs
and
the
relevant
ad
is
to
talk
about
you
know.
What's
our
way
forward
and
kind
of
agreed-
and
you
know
the
six-man
chair
said
well,
look
guys.
A
We
would
like
to
know
that
your
architecture
is
well
enough,
nailed
that
it's
not
going
to
shift
under
us.
If
we
start
adopting
this
routing
header
that
you've
brought
to
us,
you
know
we
don't
want
to
adopt
a
routing
header
and
then
find
out
that
nobody
really
knows
what
it's
for
so
give
us
some
confidence
that
you
know
what
this
routing
header
of
yours
is
for
said.
Okay,
how
shall
we
accomplish
that
and
what
we
agreed
to
is
that
the
architecture
document
shall
be
last
called.
A
Subsequently,
the
v6
extension
documents
themselves
shall
be
done
in
six
man,
but
it
is
important
and
I
will
say
you
know
crucially
important
for
anyone
in
this
group
that
cares
about
the
the
v6
data
plane
and
how
its
specified
to
participate
on.
You
know
in
the
six-man
list
and
meetings,
because
it's
not
there,
you
know
general
bailiwick
and
well.
Hopefully
the
reasons
are
obvious.
Why
and
why
your
attention
is
necessary,
so
no
sign
up
for
the
mailing
list.
Now,
why
don't
you?
A
So?
What's
our
plan
moving
forward?
We
need
to
update
the
milestones
we
need
to
work
on
mapping
the
you
know,
figuring
out
what
what
drafts
are
going
to
maybe
fit
underneath
which
milestones.
This
may
also
then
turn
into
a
bunch
of
working
group.
Adoption
requests,
though,
I
think
that
probably
the
first
thing
for
the
the
group
as
a
whole
to
focus
attention
on
is
trying
to
the
architecture
document.
For
instance,
it's
getting
the
v6
work,
yeah
and
I
think
that
I
pretty
much
talked
over
all
the
rest
of
this.
B
Okay,
hi
everybody.
My
name
is
Stefano
a
small
update
on
the
different
segments
routing
drafts.
What
do
we
have
there?
The
main
one
called
the
the
architecture
draft,
which
has
been
updated
with
the
last
comment
that
we
received,
we
didn't
get
any
other
comment
or
claims
after
that,
so
I
suppose
is
and
ready
to
go.
B
The
use
case
is
I
think
it
has
been
updated
recently
with
some
minor
stop
there.
So
it's
also
pretty
stable,
as
John
said,
also
about
the
different
ipv6
segments
rotting
draft.
The
protocol
extensions
are
being
discussed
now
in
six-man
and
finally,
we
got
some
discussions.
There
so
feel
free
to
join
the
six-month
waiting
list
to
contribute
to
the
discussion.
B
The
routing
mpls
segment
run
again
pls
data
plane,
a
no
change
is
pretty
stable,
probably
need
some
clean
up
just
to
refresh
some
sections,
but
mostly
the
content
didn't
change.
So
it's
also
pretty
ready
to
go
for
last
call
same
for
the
problem
statement,
except
that
there
are
a
bunch
of
comments.
My
fault
that
slipped
away
from
my
to-do
list
so
I
have
to
update
it
comments
from
from
alvaro.
So
after
this
this
round
it
should
be
also
quite
stable.
B
B
The
reason
I
yeah,
so
the
big
one
is
the
segment
writing
use
cases
draft
that,
in
fact,
it
has
been
the
first
segment
rotting
drop
that
we
submitted
a
little
while
ago,
and
that
contains
the
description
of
all
the
use
cases
that
we
want
to
address
with
segment
writing
and
how
to
address
them
with
segment.
Writing
then
part
of
the
content
of
the
use
cases.
Draft
has
been
used
and
moved
into
the
problem
statement
draft.
B
The
segment
writing
out
the
LDP
interrupt
draft
very
stable,
describes
how
to
interrupt
between
segments
running
and
lgp
the
protocol.
Extensions
of
doing
this
are
described
in
the
ospf
and
is
is
drafts.
We
have
multiple
implementations
and
are
also
interoperable
surprisingly,
but
yeah
so
clearly
dead
draft.
The
authors
would
like
now
to
see
the
adoption
as
working
group
item,
because
it
really
represents
the
use
case
and
reality
of
the
implementations.
B
Then
we
have
the
two
bgp
based
segments
riding
crop
ems
DC
and
the
central
EPE
both
described
only
the
use
cases
and
in
IDR
we
have
the
corresponding
protocol
extensions
drafts
or
the
prefect's
eight.
When
draft
and
the
BG
pls
extensions
for
EPA
and
the
on
the
other
one
we
receive
little
coins,
there
are
pretty
stable,
I
think
there
are
pretty
good
candidate
for
adoption
as
we
can
provide
them
as
well.
So
that's
what
we
request
and
finally,
the
segment
routing
tilf
a
which
is
the
second
writing
solution
for
the
resiliency.
B
A
B
A
A
B
C
C
D
D
Other
drive
that
left
and
now
welcome,
I'm
a
chat
to
us
and
we
added
one
use
case
and
consideration
for
processing
return
when
there
is
a
no
requested
return
path
available
next.
So
this
is
a
more
detailed
description
of
that.
An
error
when
they're
far
end
receives
their
return
path
to
lv
and
find
there
are
two
options
that
we
suggest.
One
option
is
that,
if
far
end
follows
RFC
58
84
and
establishes
be
the
session
reverse
direction
over
IP
domain.
D
According
to
1580
a
58
84,
it
has
an
option
to
use
LSP
echo
reply
to
send
back
report.
Then
we
state
that
in
that
case
it
may
use
a
return
code,
couldn't
find
their
reverse
path
to
clarify
the
situation.
If
their
agris
does
not
want
to
decide
by
implementation,
choice
by
a
parade
of
choice
or
implementation
establish
return
path
over
IP,
then
it
must
use
and
send
back.
Echo
reply
and
use
must
use
error
code
that
we
introduced,
and
then
we
boo,
sorry,
yeah,
I,
I
know
it's
it's
my
fault,
I
know
it's
my
fault.
D
D
So
that
is
just
illustrate
that
what
we
can
do,
because
if
we
imagine
that
we
have
tunnels,
ABCD
g
and
h
and
then
we
have
a
be
e
f
g
h
and
then
we
have
tunnels
in
reverse
direction.
Then
we
can
do
monitoring
of
each
in
a
bidirectional
carotid
manner
by
instructing
their
note
a
because
we
can
do
it
for
the
same
as.
D
1584
that
there
could
be
multiple
DFD
sessions
to
the
same
fact
using
the
different
discriminators.
So
I'm
using
explicit
return
path
till
v
we
can
direct
the
return
pad,
/,
h,
GD
c,
be
a
in
first
sanara
and
hgf
be
a
in
the
second
case.
So
it
we
already
made
the
presentation
and
mpls
working
group
and
ask
for
the
working
group
adoption,
and
so
it's
will
be
considering
it
probably
hopefully,
by
Prague
will
have
a
new
working
group
documented
mpls
working
group.
C
E
Folks,
so
the
talk
is
about
segment
routing
yang
model,
so
we
can
skip
to
next
slide
yeah
good.
So
this
is
a
horrible
model,
shows
that
we
are
currently
proposing.
So
it
will
advise
both
the
configuration
and
operational
state
for
segment
routing.
Here
you
can
have
a
view
of
e
of
our
global
configuration,
and
the
interesting
discussion
we
are
expecting
is
that
today,
in
our
implementation,
at
least
at
I,
know
we
segment.
F
E
So
a
salad,
so
we
are
proposing
a
segment
routing
model
that
is
directly
attached
to
the
cohousing
model,
with
routing
instance,
so
we
can
also
discussed.
If
is
this
segment,
halting
model
must
be
stagnant.
Rotting
model
be
attached
to
the
housing
instance,
or
is
it
also
more
chassis
wide
a
configuration?
This
is
something
that
we
need
also
to
to
discuss,
so
you
can
see
in
so
we
are
able
to
configure
with
cheaper
smtp.
We
are
able
to
configure
what
we
are
calling
the
mapping
server
so
for.
E
B
E
E
C
E
F
E
F
E
B
E
E
F
C
E
H
C
H
I
D
I
J
E
This
is
so
this
question
about
where
the
segment
routing
configuration
should
be
for
each
permit
offices,
some
things
that
we
need
clearly
two
to
discuss
between
our
between
us
next
time.
Please.
So
it
is
the
interface
configuration
so
within
the
interface
we
have
to
kind
of
segment
routing
parameters.
The
first
one
is
about
the
end,
linger
the
adjacency
segment.
So
do
I
want
to
advertise
this
adjacency
segment
for
forest
interface
and
also
the
ability
to
to
to
to
to
add
this,
to
manage
the
different
flags
that
we
have
in
the
adjacency
segment.
E
So
being
able
to
say,
I
want
to
advertise
the
protection
state
for
this
adjacency
of
saying,
I
want
to
advertise
both
a
protected
adjacency
segment
and
an
unprotected
adjacency
segments.
We
are
also
providing
some
facilities
to
perform
bundling
and
advertising
using
those
OS
flag,
single
adjacent
segments
that
will
be
shared
by
multiple
interfaces
to
facilitate
via
v
load
balancing.
E
We
are
also
proposing
the
configuration
of
the
prefix
segment
ID.
So
for
the
prefix
that
is
attached
to
this
interface,
we
can.
We
can
configure
a
prefix
it
value,
we
can
do
it.
We
propose
to
two
flavors
index
or
absolute
values,
and
we
can
also
define
is
this
perfect
segment
must
be
considered
as
a
nodal
segment
or
if
it's
just
a
perfect
segment
for
both
ipv4
and
ipv6.
Next.
C
E
E
So
the
idea
that
we
haven't
we
could
discuss
on
is
to
set
a
group
ID
four
inch,
each
interface
and
also
interface.
That
will
be
part
of
the
same
group
ID.
In
addition
to
the
unique
adjacency
segments,
they
will
advertise
a
common
adjacency
segments
that
will
permit
with
the
CMP
next
time
so
now
in
terms
of
protocol
extensions.
So
we
are
defining
here
with
global
second
housing
configuration,
but
then
we
must
interact
with
routing
protocols.
To
say:
okay
I
have
is,
is
protocol
I
authorizing
the
advertisement
on
V
of
the
segment
house.
E
Extensions
so
we
are
proposing
here
to
augment
is:
is
an
ospf
young
model
to
to
manage
this
segment
house
in
extensions
next
slide?
So
here
we
still
have
also
to
discuss.
Is
it
right
way
to
do
this,
or
do
you
need
to
manage
all
the
configuration
directly
in
is?
Is
an
ospf
modern?
Currently
we
also
have
some
segments
housing
container
we
machine
is
is
because
we
don't
really
know
a
good
way
to
do
it,
so
it
will
be
up
to
a
to
discussion
next
time.
E
E
So
most
of
the
people
that
are
involved,
this
work
are
coming
from
the
ASI
es,
no
SPF
modern,
it's
quite
I,
think
accurate
in
terms
of
future
compared
to
what
is
shipped
today
in
the
envy,
occasional
cut
it
scary
time
to
work
on
it,
because
cars
are
shown
here
just
shipped
or
under
shipping.
So
it's
time
now
to
try
to
think
on
a
common
way
of
configuration
for
four
segments
routing.
E
So
for
sure,
there
is
a
lot
of
things
that
we
need
to
discuss
so
via
salvia
scope
out
windows,
interactions
with
is
a
sno
and
ospf,
and
we
are
clearly
are
welcoming
all
the
comments
on
this
part
to
ensure
that
we
are
all
in
line
on
the
way
to
accommodate,
and
we
are.
We
think
that
this
is
already
important.
So
we
are,
we
asked,
are
working
on
production
floor
for
this
document.
A
I
E
I
E
E
A
K
G
Okay,
juniper
so
I'm
a
water
in
this,
but
still
I,
think
a
container
both
at
the
global
as
well
as
a
protocol
level
will
actually
suffice.
Lot
of
usage
say
what
I'm
trying
to
say
here
is
that
you
may
have
one
configuration
to
global
and
do
not
put
any
confusion
under
protocol
level.
So
all
protocols
take
that,
but
you
can
overwrite
that
on
a
specific
protocol
label
in
level.
G
G
J
J
Oh
maybe
local
or
organ
oboe
or
scope,
and
the
next
is
the
perfect
and
the
agency
of
the
neck
and
and
the
sort
of
know
that
is
the
fec
imagine.
Well,
we
define
and
obviously
a
professor
to
sr
pass,
so
the
the
next
to
is
the
as
art
it's
a
gas
operation
we
defined
as
a
neighbor
and
identity
and
a
therapist
for
the
SR
neighbor
energy,
with
the
fan
and
as
ID
incoming
and
outgoing
in
the
face
and
next
hope.
The
some
more
had
an
operation.
J
J
Under
the
last,
one
is
f
our
protection
method
that
we
define
and
loader
protection
or
interpretation.
So
this
is
a
configuration
natural
for
our
dynamic
model.
So
next
is
not
notification.
We
defend
I
star
passage.
You
went
well
even
though
maybe
a
sec,
neurology
and
creation,
and
the
second
or
odeon
pass
with
Indonesia
and
the
positive
change,
and
that
of
our
stage
was
changed
and
also
we
define
pastor
Protection
station.
So
this
is
the
gizmodo
design
inside.
J
J
Another
way
we
have
offered
online
discussion
with
Sudan
fought
the
first
yonder
Hamato
and
staff
oh
and
the
AC,
so
they
suggest
that
some
of
that
too
te
r
n8
the
nose
and
the
forwarding
neighbor,
no
sir,
should
it
be
augmented
from
NPR
CG
model
or,
and
he
hasn't
order.
So
I
think
agency
is
a
reasonable.
J
A
A
C
A
J
K
So
this
raft
has
just
become
a
working
group
per
document
in
the
MPLS
working
group.
It's
about
two
or
three
weeks
old,
as
a
working
group
document
and
I'm
going
to
update
on
the
changes
that
have
happened
since
the
last
IETF.
So
as
a
background,
this
is
history
for
load,
balancing
four
segments,
routing
specifically
for
the
MPLS
data
plane
and
specifically
it's
about
how
to
use
RFC
6790,
which
is
the
entropy
level
RFC
for
segment
routing.
K
K
So
we
have
changed
that
totally
to
a
traffic
engineering
use
case
using
only
node
suits
and
adjacency
sets,
and
the
readability
of
the
sample
algorithm
provided
to
compute,
where
the
entropy
Li
and
the
eel
needs
to
be
inserted,
has
also
been
improved
and
all
the
examples
have
been
updated.
With
the
new
changes
next
slide,
please.
C
D
K
So
so
I'll
try
my
best
so
essentially
the
use
case.
This
is
the
topology
for
the
use
case
where
the
packet
has
to
go
from
s
to
D.
There
are
parallel
links
between
the
lsr,
sp1
and
p3,
as
well
as
ecmp
paths
between
p2
and
destination.
So
the
constraint
for
the
two
out
the
LSP
is
that
it
should
go
through
a
specific
link
l1
and
for
that
normally
to
take
three
labels
for
the
label
stack
now.
The
node
p1
has
a
restriction
that
it
can
read
only
for
labels
on
the
label
stack.
K
So
when
you
have
a
three
label
label
stack
and
you
insert
a
liil.
Essentially,
the
AL
is
too
deep
for
the
4
p-12,
read
the
label
stock
and
do
good
load
balancing.
So
essentially,
there
are
a
set
of
recommendations
and
in
following
the
recommendations
you
have
to
insert
multiple
lol's
or
in
this
specific
case
it
is
to
li
else,
need
to
be
inserted
into
the
label
stack
and
that's
shown
in
the
bottom.
You
can
read
this
better
on
the
in
the
draft.
I
think
next
slide
please.
K
So
there
are
a
few
related
discussions
that
have
happened.
One
is
regarding
support
of
the
hardware
capability
parameter,
specifically
the
RLD
for
and
whether
it
should
be
interface
specific.
Now
we
have
considered
several
cases.
It
introduces
a
significant
amount
of
complexity
into
the
solution
and
the
benefits
seem
to
be
fairly
minimal
and
we
haven't.
We
really
don't
have
a
strong
use
case.
K
We
think
it's
worth
the
effort
to
actually
go
and
do
interface
specific,
and
the
second
discussion
that
we've
had
is
regarding
Oh
am
now
the
OEM
requirements
are
still
being
formed
in
segment
routing
and
we
are
working
with
those
authors,
but
the
solution
that
we
have
recommended
of
using
multiple
l.I.e
else
is
not
expected
to
introduce
new
problems
as
yet.
That's
that's
a
thought
right
now.
K
K
A
C
L
Its
one
you
are
segments
type
was
introduced
to
hear
it's
called
multi,
topology
segment,
routing
and
also
empty
seat,
and
it
which
is
a
igp
segment
attached
to
an
AGP
topology,
and
it
should
be
global
within
sr
demand
which
indicate
one
specified
topology,
so
disrupt
was
try
to
propose
this
mijito
budget
segment
for
the
SR
network.
Okay
and
MTC
was
used
to
identify
the
specified
topology.
L
Okay,
here's
the
use
case
for
mr
t,
FR
and
boy.
Oh
no
and
mrt
of
our
routing
was
was
done
by
two
disjoint
redundant
tree,
which
is
called
a
multi
blue
Marty,
read
in
the
mrt
architecture
document
the
four
layer
of
the
14
mechanism
for
IP
network
needed
to
do
eating
IP
IP
tunnel,
which
well
introduce
extra
IP
address.
But
with
this
mitc
empty
seat,
we
can
help
to
solve
that
problem.
L
Ok,
here's
forty
mechanism
for
this
draft,
for
example
a
young
ingress
router1.
The
push
operation
need
to
be
done
when
the
PR
founded
a
fort.
We
need
to
push
the
corresponding
at
mirchi,
blue
or
mr
t
read
seeped
into
the
package.
Then
this
deceit
can
steering
the
packet
alone.
The
update
parts
on
the
transit
router,
but
continued
operation
need
to
be
done
in
okay
and
on
the
egress
router.
So
the
next
operation
can
be
done.
L
Okay,
this
this
is
about
the
controller
control
plan
in
can
ISM
for
a
mark,
for
mr
t
FR
with
leave
a
GP
extension
for
this.
Am
I
marchi
a
multi
tablet
segment
to
need
to
be
done
and
this
segment
need
to
be
unique
within
a
GP
domain
and
when
this
segment
was
allocating,
we
recommend
this.
This
segment
was
allocated
to
the
English
centralized
the
way
willian's
say
distributed
way
is
now
working,
but
do
we
recommend
that
that
is
better?
Oh,
ok!
So
how
to
exactly
how
to
assign
this
segment?
L
L
H
Data
is
a
jog
in
front
of
puppy.
It's
a
user
to
be
clarified
because
a
current
of
the
IDP
market
of
holiday-
they
always
the
no
header,
no
weed
in
the
header
identify
Marty
topology
in
the
existing
the
network.
They
recommend
the
you,
the
diet
recipe
as
if
you
but
I,
think
that
so
that
we
want
to
use
the
I'm
just
to
order
a
segment
two
extended.
If
you
head
out
to
identify
muddy
topology.
F
This
is
hannah's
from
Jennifer.
Actually,
the
segment
routing
design
team
has
put
in
sufficient
provisions
in
the
igp
extensions
for
additional
protocols
right.
So
when
we
assign
all
those
indexes
and
label
blocks,
actually
the
right
way
to
extend
that
over
time
would
be
to
get
a
code
point
for
our
MRT
and
then
just
use
the
existing
label
block
and
index
machinery
for
doing
that.
F
F
M
So
QT
again
just
having
a
quick
side
discussion.
What
it
looks
like
is
you
really
want
to
do
MRT,
not
really
multi
topology
and
you
can
do
MRT
calculations
at
the
head
end
using
existing
SIDS
and
say
this
is
my
blue
parts
and
here's
my
blue
label
stock
and
here's
my
red
bath
and
here's
my
Reb,
the
red
label
stock?
And
if
you
do
the
computations
right,
whether
you
do
with
them
or
some
centralized
magic,
SDN
controller
does
it.
You
will
get
disjoint
paths,
which
is
maybe
what
you
want
all.
N
N
Actually,
oh
yeah,
Chris
Bowers
juniper.
The
idea
cariddi
is
not
to
use
a
label
stack
to
define
the
MRT
path,
but
to
simply
have
it
be
another
algorithm?
So
currently
a
CID
is
defined
to
follow
the
shortest
path
that
is
computing,
the
shortest
path,
algorithm,
correct
and
note
said
and
so
correct
correct.
So
one
and
two,
for
example,
could
be
red
and
blue
and
you
simply
populate
the
forwarding
entries
for
those
for
those
algorithm
SIDS.