►
From YouTube: IETF108-MPLS-20200731-1300
Description
MPLS meeting session at IETF108
2020/07/31 1300
https://datatracker.ietf.org/meeting/108/proceedings/
A
I
guess
we
can
get
started
hello.
Everyone
welcome
to
the
ietf
108
virtual
online
meeting
for
the
mpls
working
group.
We
have
a
a
rather
shorter
meeting.
It's
a
15-minute
meeting
for
this
session.
The
chairs
are
loa
tariq,
myself
and
nick
nick
is
not
with
us
today.
A
He's
in
germany
hopefully
he's
okay
and
our
secretary
is
mac,
chen.
A
Okay,
great!
We
have
our
note
well,
this
is
the
regular
note
well
for
newcomers
or
those
who
haven't
read
it.
Please
take
some
time
and
read
through
it.
A
It
governs
our
interactions
with
ietf
and
our
conduct
and
all
the
intellectual
property
subject
or
subject
some
administrative
stuff,
the
blue
sheet,
as
you
know,
by
now
it's
friday,
so
that
it's
you
don't
need
to
log
in
your
names
for
attendance,
the
tool
does
it
for
you
automatically
when
you
log
in
jabber
the
meet
echo
chat
is
the
jabber,
but
if
people
want
to
join
using
their
client,
you
know
they're
used
to
it,
so
they
can
use
that
and
for
minute
taking
we
have
using
the
the
tool
and
we
encourage
people
to
pitch
in
and,
you
know,
add
their
comments
on
the
minute.
B
Yeah,
just
one
good
comment
that
I
heard
from
the
these
shares
is
that
if
you
have
spoken
gauchek
in
the
notes
that
the
information
is
correctly
correctly
captured
in
the
in
the
in
the
tool,
yeah
saves
long
talk,
and
especially
your
name.
A
Indeed,
okay
yeah,
please
log
into
this
tool
and
do
check.
The
whatever
has
been
noted
is
accurate
and
if
it
is
not
there,
please
add
it
yourself
for
the
record.
The
slides
are
also
available
online
and
our
working
group
documents
are
on
data
tracker.
In
the
usual
place
we
have.
We
have
an
up
a
progress
report,
update
from
the
working
group
chairs
and
and
secretary.
A
It's
a
longer
one,
and
we
only
have
three
presentations
today,
so
each
one
will
get
their
10-minute
chair
on
this,
so
I'll
leave
it
the
details
for
the
presenters
to
talk
about
them,
but
I
will
highlight
that
we
have
received
or
requests
overflow
requests
that
we
couldn't
fit
into
this
50-minute
session,
we're
working
towards
an
interim
meeting
after
this
meeting,
and
we
have
four
requests
so
far,
but
we
are
accepting
more
more
requests.
So
please
reach
out
to
us
as
usual.
A
So
for
those
who
have
sent
the
request,
please
be,
please,
you
know
be
aware
that
there
will
be
an
interim
and
you
will
get
your
chance
to
present
your
work.
A
A
So
the
suggestion
is
to
add
a
a
bullet
under
the
operations
to
perform
for
a
nh
lfe.
The
last
bullet
here
is
the
suggested
addition
push
a
new
label
for
on
the
unlabeled
packet.
A
We
have.
We
have
a
couple
of
suggestions
from
the
working
group.
Members
steward
has
suggested
renaming
this
new
label
as
a
first
label,
makes
sense
because
it's
unlabeled
it
can
be
first
or
more.
As
adrian
has
pointed
out-
and
you
know
there
are
opinions
that
the
the
rfcs
is
can
be
stretched
out
to
cover
the
unlabeled
without
ending
errata.
A
A
A
Okay,
anybody
else
made
them.
Let
me
check
the
queue
and
there's
no
one
all
right.
Let's
move
on,
we
don't
have
any
leah's
liaisons,
either
from
outgoing
or
incoming
to
mpls.
A
This
time
now,
I'm
going
to
switch
to
the
document
status
I'll
highlight
that
documents
with
blue
color
are
on
the
agenda
this
time
since
ietf
107,
we
have
a
new
rfc.
So
I
would
like
to
thank
the
authors,
the
shepherd
and
the
area
director
and
the
working
group
for
getting
this
achievement.
A
We
have
a
bunch
of
documents
in
the
iesg
right
now,
so
the
first
one
is:
it
needs
their
vision.
We
expect
their
office
to
jump
so
feel
free.
If
anybody
wants
to
comment
I'll
so
lower
you
have,
you
can
give
them
ex.
You
can
accept
them
if
they're
in
the
queue,
otherwise
I'll
have
to
keep
switching
back
to
check.
B
A
Okay,
great,
thank
you.
The
second
one
is
the
in
iesg
it
was.
You
know
we
were
expecting
a
revised
draft
to
be
published.
The
authors
are
encouraged
if
they're
attending
now
to
address
the
the
comments
and
publish
a
an
update
and
so
that
the
progress
can
continue.
A
A
The
next
one
is
the
mpls
sfl
framework.
It
is
waiting
for
okay.
B
A
Okay,
if
he
wants
to
come
to
the
mic,
we
can
give
him
a
chance,
otherwise
I'll
continue,
so
that
we
can
stick
to
the
agenda.
A
All
right,
so
the
next
one
is
the
sfl
framework.
It
is
waiting
for
write
up
right
now.
So
again
the
authors
are
encouraged
to
address
that
or
is
it
the
write
up
from
the
adi.
A
I
will
do
that
coming
week.
Also,
okay,
great,
thank
you
for
clarifying
that
we
have
the
mpls
base
yang
working
group
document.
It
was
requested
for
publication
right
now
and
and
we'll
watch
out
for
any
comments
coming
from
isg.
A
Similarly,
we
have
the
spl
terminology.
We
have
received
comments
on
this,
so
the
authors
we
expect
them
to
address
those
comments.
A
Great
thank
you.
We
have
adopted
a
couple
of
new
working
group
documents,
the
epeom,
as
well
as
the
rfc
63
74
sr
sr.
A
So
these
are
two
new
documents
now
that
were
recently
adopted,
some
of
the
documents
that
are
updated
just
to
let
fyi
we
have
an
update
on
the
bfd
and
we're
gonna
talk
a
little
bit
more
on
this
one.
We
have
a
recently
expired
document
it
it's
a
working
group
document.
A
A
We
have
a
bunch
of
new
individual
documents,
so
some
of
them
are
already
given
a
slot
to
present
today,
but
for
the
rest
feel
free
to
reach
out.
If
you
want
to
present
your
work
in
the
interim
upcoming
meeting,
we
will
flag
that
a
new
working
group
document
replaced
the
old
yang
yang,
oem
or
mplsp
lsp
ping.
A
That
expired,
so
we
have
new
authors
that
are
holding
the
pen
on
this
and
we
thank
them
for
continuing
this
work.
A
Okay,
so
a
little
bit
more
on
the
again
individual
drafts,
we
have
completed
adoption
of
the
first
one
I
did
already
mention
mention
it
under
adopted
documents.
So
we
expect
you
know
the
authors
to
publish
a
revision,
zero,
zero
revision
in
this
case
with
a
name
change.
If
you
haven't
done
that,
please
do
that.
A
We
have
another
document.
That's
on
the
agenda,
the
last
one
I'll
talk
a
little
bit
more
on
it.
So
we
have.
A
The
authors
have
addressed
all
the
review
comments
and
the
working
group
adoption
is
underway
after
this
meeting
so
watch
out
for
an
email
for
adopting
this
document.
A
So
again,
more
on
the
individual
drafts
individual
documents.
We
have
the
lsp
ping.
As
our
generic
said,
we've
received
a
request
from
the
authors
that
they
want.
They
would
like
to
proceed
with
working
group
adoption
we've
asked
or
we
will
trigger
actually
a
review
from
the
mpls
review
team,
so
that
is
happening
soon.
Lowell
has
taken
this
action
item
so
expect
authors
expect
reviewers
to
come
with
comments,
and
after
that
we
will
proceed
with
working
group
adoption.
A
The
second
one.
I
will
talk
a
little
bit
more
on
the
in-band
vm
encapsulation
this
one.
We
have
also
received
the
request
for
adoption.
It's
already
assigned
reviewers
from
the
mpls
review
team
and
the
once
all
com
comments
are
addressed.
We
will
proceed
with
adoption
of
this.
A
Other
than
this
we
have
one
individual
draft
on
the
agenda
as
well.
So
talk
more
about
it.
I'll
switch
to
the
progress
reports
on
the
working
group
documents
that
are
not
presented
in
today's
session,
the
first
one
we
have
the
yang
for
mpls
space.
A
It's
currently
we've
requested
publication
on
it
and
it's
sitting
in
iesu
review
the
second
one.
We
have
the
mpls
lsb
static
yang
model.
A
We
we
received
young
doctors,
review
comments
and
those
got
addressed
all
of
them,
so
we
will
proceed
as
next
step
to
working
group
last
call
once
the
mpls
base
is
has
progressed
enough,
so
that
will
be
the
next
step
on
this
one.
A
The
third
document
is
the
mpls
mldp
yang
document
and
the
current
status
is
there
was
a
young
doctor
review
on
this
draft
back
in
2017
a
while
back
so
likely.
We
will
request
another
yang
doctor's
review
once
we
have
a
signal
from
the
authors
that
it
is
in
a
good
shape,
we've
noticed
compiled
errors
in
the
documents,
so
we
encourage
the
authors
to
address
those
and
let
us
know
their
intention
to
progress
this
to
a
young
doctor's
review.
C
A
Or
maybe
use
by
chance
in
the
queue?
No,
he
dropped.
Okay.
Anyone
else
want
to
comment.
Oh
he's
back.
Okay,
you
want
to
give
him
a
chance.
B
D
F
D
C
Yes,
okay,
yeah,
for
that
mpls
bass,
draft,
that's
kind
of
a
relatively
simple
one
that
all
the
other
protocol
yang
models
are
waiting
on.
Is
that
sitting
with
deborah
now
waiting
for
her
to
pull
the
trigger
and
do
the
ietf
last
call
it
says
publication?
Is
that
what
what
it
also
says
revised
id
needed?
I
don't
what's
what's
going
on
with
that
one
other
than.
C
Okay,
okay,
good:
I
hope
that
would
be
push
to
ietf
last
call
and
the
rfc
editor
soon.
Yeah.
A
C
Because
that
that
one
has
that
one
that
one,
you
know
this
whole
chain
of
dependencies
with
this,
the
at
the
root
as
stopping
about
probably
half
dozen
documents
from
being
public
public
published.
E
B
B
A
I'll
have
to
progress
a
little
bit
faster.
I
I'm
you
know
two
minutes
beyond
so
I'll
move
on
to
the
next
slide
and
continue
with
the
progress
update.
We
have
a
document,
mpls
bfd
directed
this.
The
current
status
on
this
one
is
stalled.
A
A
We
also
received
the
request
from
the
authors
that
they
want
to
proceed
with
the
working
group
last
fall,
except
that
there
were
no
changes
to
address
any
comments
that
were
received
earlier
from
carlos,
so
we
have
tried
the
working
group
last
call
multiple
times
now
and
we're
not
sure
if
we
want
to
you
know
if
the
next
one
will
succeed
now
the
next
steps
is
working.
Group
chairs
are
open
for
suggestions
from
authors
from
from
the
working
group
we're
open
to
options.
D
Hi,
I
believe
that
all
technical
comments
received
from
routine
directorate
review
have
been
addressed,
so
I
kind
of
a
little
bit
puzzled
at
their
situation,
because
the
comments
that
are
out
remaining-
actually,
that's,
not
the
comments.
There
are
statements
that
not
been
technically
substantiated,
and
maybe
somebody
can
look
at
the
discussion
and
really
help
offer
us
understand
what
are
technical,
outstanding
issues
that
are
remaining.
D
Because
the
the
purpose
of
this
document
have
been
clear,
there
was
a
question
of
how
their
stability
of
the
reverse
path
to
use
for
the
bfd
session
to
be
monitored,
and
that
was
part
of
update
that
we
put
into
the
document
for
some
time
already.
A
Greg
from
my
my
perspective
and
and
feel
free
other
chairs
to
speak,
I
got
back
where
the
progress
of
the
discussion
was
with
with
the
with
with
carlos,
on
the
comments
roof.
If
you,
if
you
can
refresh
your
working
group
on
the
resolution,
you
know,
although
that
you
know
from
your
perspective,
it's
resolved.
I
understand
that,
but
at
least
refresh
the
working
group
on
the
email
list.
F
D
Yes,
we,
there
was
a
discussion
and
we
had
some
discussion
not
on
the
list
about
their.
Whether
this
is
a.
D
Useful
solution
to
the
real
problem.
D
Again,
there
were
some
changes
being
done,
not
that
recently,
but
after
the
last
comment
from
carlos,
so
I
really
would
appreciate
if
someone
take
a
look
at
their
discussion
and
the
current
state,
I
can
give
a
more
detailed
explanation
of
what
the
scope
of
the
changes
and
really
help
to
understand
what
are
technical
remaining
issues
with
the
document.
B
Okay,
we
tried
to
find
something,
but,
as
a
working
group
share,
I
don't
really
want
to
actually
put
the
document
to
work.
Group
last
call
if
I
don't
think
it
has
a
chance.
C
B
D
I
I
understand
that
and
again
I'll
gladly
work
on
a
document.
If
somebody
helps
me
to
understand.
D
Where
the
technical
gaps
remain,.
A
Yeah
yeah,
I
I
appreciate
greg
if
you
can
refresh
the
on
the
list
the
issues
so
that
people
can
comment
more
on
the
validity
of
the
statements
being
made
and
or
not,
I'm
sure
you
know
yeah,
okay,
I'll
work
on
that.
Okay,
thank
you.
So
I
did
talk
about
the
mpls
rmr
status
and
you
know
the
ldp.
Rmr
is
also
waiting
on
that.
So
I'll
skip
quickly
over
those
to
mention
the
last
two
document
update
on
those.
So
we
have
the
code
point
for
lsp
ping
for
osp
v3.
A
This
is
currently
it
underwent
a
undergone,
a
review
and,
to
version
two,
the
authors
invite
more
reviews
from
working
group
and
they're.
Looking
for
working
group
class
called
after
108
iedf10108,
the
next
one
it
was
just
adopted.
A
B
B
A
Okay
yeah:
I
look
forward
to
volunteers.
A
And
we
can
take
it
to
the
list
if
you
want
loa
and
see
if
we
have
someone
who's.
A
native
english
speaker
is
that
what
you're
looking
for.
A
Okay,
so
I'll
skip,
because
I'm
eating
time
from
the
presenters,
we
did
talk
about
the
sfl
framework.
It
is
progressing
well
and
we
encourage
the
office
to
address
all
the
outstanding
comments.
If
there
are
any
the
next
one
is
dependent
on
it,
so
mpls,
rfc,
6374,
sfl,
it's
dependent
on
the
framework,
so
working
through
class
call,
will
continue
once
that
one
progress
as
well
with
this.
A
I
finish
my
progress
report
and
I
will
go
ahead
to
the
first
presenter
who
is
rakesh
but
before
you
get
yourself
ready,
rakesh,
but
if
we
before
that,
if
anybody
has
any
comments
to
make
also
feel
free
to
come
to
the
mic
rakesh
also,
you
can
I'll
accept
you
to
come
to
the
you.
Have
the
mic
as
well:
rakesh.
A
E
Wonderful
hi
everyone,
my
name
is
from
cisco
systems
presenting
this
draft
on
mpls
and
cap
for
the
ium
on
behalf
of
the
authors
listed
next
slide.
E
E
So
we
will
look
at
the
requirements
and
the
scope
of
the
draft,
the
history,
the
updates
that's
made
since
ita
106
in
singapore
and
the
summary
of
the
draft
and
the
next
steps
and
next
slide.
E
So
the
requirements
is
to
carry
the
iom
data
fields
with
mpls
and
cap.
So
just
to
recall
that
iom
is
a
is
the
oem
information
carried
by
the
data
traffic,
a
lot
of
work
being
done
in
the
ippm
working
group.
There
are
relevant
drafts,
that's
listed
here
and
the
scope
is
the
s2h
and
hub
by
iom.
E
So
the
draft
has
been
around
for
almost
two
years.
It
was
in
the
spring
and
it
was
then
moved
to
mpls
working
group
last
year
and
it
was
presented
in
in
singapore.
Last
virtual.
We
ran
out
of
time,
so
I
will
present
an
update
since
singapore.
E
So
there
were
many
comments
received
and
those
comments
have
been
addressed
so
now
the
it's.
It's
mpls,
the
generic
data
payment
cap,
which
includes
sr
the
procedure
updated
for
the
up
by
hub
iom.
There
were
a
few
other
review
comments
and
editorial
changes
made
to
the
draft.
E
So
there
is
nothing,
no
open
item
right
now.
We
believe
we
have
addressed
all
the
comments
just
a
summary
of
of
the
draft,
so
it
defines
iom
indicator
label
which
goes
on
the
mpls
header
in
the
label,
stack
followed
by
the
iom
data
files
defined
in
the
ippm
various
working
group
documents.
E
So
indicator
label
is,
is
used
to
indicate
that
this
iom
data
is
present
present
on
the
in
the
header
for
hop
by
hop
and
h
by
s.
E
There
are
separate
label
values,
and
next
like
this,
so
in
order
to
address
the
ip
hashing
issue,
there
is
also
iom
and
flow
indicator
label
which
will
be
followed
by
the
the
four
zeroes
to
say
this
is
not
ipv4
ipv6,
so
that
it's
not
incorrectly
hashed
and
it
contains
the
flow
label
as
well
as
block
number
which
are
useful
for
the
performance
pm
related
stuff.
Next,
like
this.
E
So,
as
mentioned
here,
there
are
also
separate
labels
for
this
kind
as
well
for
edge-to-edge
and
up
by
hop.
The
protocol
allows
to
avoid
the
increment
caching
flow
label
is
to
identify
the
flow,
that's
being
monitored
for
iom
and
block
number
allows
to
aggregate
and
correlate
the
data
for
ioa
next
slide.
Please.
E
E
Next,
so
the
allocation
wise
for
h2s
case,
we
are
requesting
a
special
purpose
label,
extended
special
purpose
label
from
ayna,
but
in
a
variation
of
a
scheme
it
can
also
be
a
controller
allocated
global
label
or
it
can
be
also
signaled
by
the
decap
node
next
slide.
Please.
E
E
E
So
this
slide
throws
a
half
fit
into
the
header,
including
the
path
segment
id.
What
segment
id
work
is
being
done
in
spring.
It
just
shows
the
how
the
header
would
look
like
this
wasn't
a
comment
that
we
addressed
the
next
slide.
Please
sure.
E
Again,
it
just
shows
with
flow
label
in
the
indicator
as
well,
and
next
like
this
all
right,
if
I
can
steal
from
okay.
E
Go
ahead,
yeah.
So
next
steps
welcome
your
comments
and
suggestions.
We
do
believe
that
we
have
addressed
all
the
comments
that
we
have
received
so
far
and
the
document
is
ready
for
the
working
group.
Adoption
we've
been
asked
to
keep
a
spring
working
group
in
in
loop
for
the
srs
specs
and
ippm
working
group
also
asked
us
to
keep
them
in
the
loop
for
all
the
milestones,
because
we
are
reusing
network.
A
Who
wants
to
comment?
I
have
a
question
if,
if
I
don't
know
if
greg
is
in
the
queue
you've
been
there
for
a
while.
D
Go
after
you,
okay!
Thank
you.
Okay.
I
have
a
couple
questions.
First,
you
identify
you.
You
said
the
requirement
is
to
collect
and
carry
their
information
in
mpls
packet.
D
I
think
that
it
can
be
a
little
bit
changed
and
the
real
requirement
is
collect
on
path.
Information
using
iom
and,
as
you
mentioned,
direct
export
is
in
the
scope
of
this
document.
So
I
would
like
on
the
list
to
have
a
discussion
about
using
direct
export
as
a
mechanism
of
collecting
this
and
transporting
this
information
so
getting
the
measurements
using
their
mpls
packet.
D
Bob
collection
to
be
out
of
that
second
comment
is:
I
understand
that
in
your
encapsulation
after
the
bottom
of
the
label
stack
the
first
nibble,
you
indicate
that
you
set
it
to
all
zeros
and
this
value
for
the
first
nibble
is
used
by
a
pseudowire
control
war.
D
So
there
might
be
some
situation
when
that
can
be
misinterpreted.
D
And
another
question
I
have
is
it:
I
believe
it
would
be
helpful
if,
in
a.
D
B
D
A
E
Yeah,
so
thanks
greg
for
the
comments,
so
this
draft
just
uses
the
mechanisms
defined
in
ippm.
It
only
thing
it
adds.
Is
the
mpls
end
cap
where
it's
required
for
the
mpls
data
plane,
so
it
doesn't
change
any
underlying
procedure.
E
That's
one
thing,
and
the
second
thing
is
that
zero
zero
zero,
the
we
did
look
at.
I
think
the
rfc
is
reference
here
and
there
is
zero,
zero
zero
and
there
is
zero,
zero
zero
one,
and
so
we
decided
with
this
one.
But
if
there
is
a
contention
we
can
address
that.
A
Okay,
thank
you.
Rakesh,
okay,
so
expect
some
further
comments
on
the
list
and
we
can
have
that
discussion
on
the
email
list,
I'll
move
ahead
to
the
next
okay.
In
terms
of
the
adopt
sorry,
the
allocation
early
allocation,
you
are
saying
that
it
can
be,
it
can
be
globally
allocated
by
a
controller.
So
you
don't
need
need
that
special
purpose
label
is
that.
E
No,
we
do
no,
we
are
asking
for
the
allocation
from
the
special
purpose
label,
but
we've
also
documented
that
if
in
somebody
wants
to
use
that
approach,
it's
also
feasible,
but
it's
documented,
but
we
do
ask
for.
I
think
it's
better
to
have
a
reserve
label
for
that.
I
see.
Okay,.
A
So
yeah
I
mean
for
for
the
allocation.
We
will
wait
until
adoption
happens
at
least
of
the
document,
and
you
know
at
least
we
have
to
remove
all
the
objections
on
you
know
if
there
anybody
anybody
has
objections
on
adopting
the
the
document.
A
Let's
address
those
before
we
proceed
ahead
with
our
location,
early
on
location
sounds
good.
Thank
you,
rakesh,
thanks.
Okay
on
the
agenda
is
kiriti
and
reggie.
A
F
F
So
it
took
a
recap,
so
in
the
figure
we
have
an
mbls
fabric
with
t1,
t2
and
t3
being
part
of
the
mpls
fabric,
and
we
have
x,
y
and
z
are
either
host
or
service,
which
doesn't
really
want
to
run
any
routing
protocols
or
signaling
protocols,
but
want
to
actually
be
part
of
the
mbls
domain,
and
it
is
here
that
the
lf
actually
comes
into
picture.
So,
if
x
wants
a
label
up
to
y,
it
would
send
an
alarm
request
for
y
right
through
its
gateway
interface.
F
So
the
elapsed
server
on
t1
would
receive
the
lab
request.
It
will
look
up
in
the
database
and
see
if
there
is
an
established,
lsb
path
to
y
and
if
it
finds
one
it
will
allocate
a
new
label
and
then
send
that
label
in
the
lr
replay
to
x.
It
will
also
install
this
new
label
in
its
l5
so
that
when
a
packet
actually
comes
from
x,
it
could
swap
this
label
to
the
corresponding
level
for
the
lsd
path
to
1.
F
So
apart
from
this
right,
when
the
t1
gets
an
lr
request,
it
learns
about
x.
So
it
does
a
proxy
label
distribution
for
x
over
the
fabric
and
that's
essentially
how
t2
and
t3
will
learn
about
x
and
similarly
for
y
and
inside,
and
this
is
the
bootstrapping
process
in
lr
and
finally,
right
like
there
is
no
specific
dependency
on
any
signaling
protocols
which
needs
to
be
really
used
in
the
fabric.
F
Okay,
so
updates
on
the
last
in
remaining,
there
has
been
in
recent
revision
of
the
draft,
and
the
draft
actually
includes
the
provision
for
optional
attributes
via
tlvs
in
the
lr
request
and
trusted.
F
So
the
draft
specifically
defines
a
right
which
carries
a
ct
attribute
and
the
ct
attribute
is
actually
defined
in
another
draft,
which
is
the
ppp
class
for
transport
plains.
Draft
right.
I
will
get
into
more
details
later,
but
for
right
now
you
can
consider
cta
attribute,
as
denoting
a
transport
class
or
a
service
mapping
to
a
path
for,
like
a
specific
attribute,
say,
let's
say
path
with
a
specific
protection
or
a
bandwidth,
etc.
F
Right
so
now
the
ct
tlv
essentially
allows
the
lr
client
to
actually
request
multiple
labels
to
a
given
destination
with
each
label,
which
denotes
a
specific
transport
tunnel
right
given
by
the
transport
class,
do
not
buy
the
ct
and
yes,
it
can
also
request
for
an
uncolored
label
too.
The
rest
of
the
process
essentially
remains
the
same,
except
that
a
lab
server
when
it
receives
such
a
colored
alert
request.
It
would
look
up
in
its
color
transport
fib
to
actually
see
whether
it
has
a
transport
label,
a
transport
tunnel
to
the
destination
next
slide.
A
F
F
Okay,
so
so
the
topology
right,
like
which
I
will
be
using
for
the
presentation,
is
like
where
you
have
a
conduit
cluster
in
two
data
centers,
and
these
data
centers
are
saying,
like
they're
connected
over
an
mpls
fabric
and
we
have
the
mbls
fabric
on
the
data
centers,
also,
which
are
essentially
terminated
at
the
doors
and,
as
you
see
like,
we
have
bgpct
also,
which
is
running
in
the
data
center,
as
well
as
on
the
core.
So
we
talked
about
the
transfer
class.
F
What
the
bgpct
essentially
gives
is
a
transport
tunnel
over
different
domains
for
a
specific
transport
class.
So
essentially
for
our
discussion,
we
already
have
a
transport
terminal
or
an
mbls
tunnel
from
a
tour
in
one
data
center
to
the
touring
another
data
center.
So
and
what
we
want
to
do
is
to
actually
extend
this
mpls
tunnel.
All
the
way
to
the
compute,
and
you
can
see
the
compute
over
here
are
multi-home
to
two
different
tools
right
for
somebody
who
doesn't
understand
the
control
architecture.
Actually,
the
underlay
actually
ends
up
on
the
compute.
A
Yep,
keep
in
mind
that
we
might
be
cut
off
any
time
after
one
minute.
F
So
essentially
the
overlay
route
like
if
you
look
in
the
bgpct,
it
actually
defines
a
bgp
community
called
a
mapping
community
which
actually
serves
as
a
notification
to
on
which
transfer
class
should
the
overlap
tunnel
be
should
be
only
route
should
be
resolved
against,
and
so
I
have
used
that
as
the
color
blue
right.
So
now,
when
the
overlay
route
is
actually
downloaded
into
the
v
router
right.
So
because
I
am
its
end,
cap
is
an
mbls
or
mbls.
F
It
will
send
an
lr
request
towards
the
fabric
site,
so
this
ldap
request
is
received
by
select
both
the
doors
and
since
the
bluetooth
already
has
a
blue
transport
tunnel
right
all
the
way
to
the
other
compute,
it
will
respond
with
a
lr
replay
all
right,
so
the
bluetooth,
the
red
door,
also
can
replay
with
an
lf
replay
if
it
had
a
blue
transport
tunnel.
F
Now,
for
that
purpose,
right,
like
a
develop
replay,
has
a
metric
associated
with
it,
which
allows
the
client
to
decide
which
part
to
be
taken,
and
if
the
metric
is
the
same,
it
can
actually
do
an
ecmp
path.
F
Also,
so,
essentially,
that
is
what
happens
so
if
our
packet
is
actually
sent
right,
it
uses
the
transport
level
of
the
lf
label
and
it
goes
to
the
corresponding
bluetooth,
which
actually
switches
it
with
the
corresponding
transport
tunnel
label
and
send
it
all
the
way
to
the
other
data
center
store,
which
actually
removes
the
transport
level
and
switches
the
packet
to
the
corresponding
vray.
A
And
you
to
you
know:
go
to
the
next
steps
and
yeah.
F
F
Yeah,
so
just
the
developments
right
like
a
there,
is
a
contrail
with
openstack
prototyping,
which
is
currently
done
and
that's
a
use
case
which
I
just
presented,
and
we
have
a
basic
linux
prototype
which
is
already
done
and
which
we
are
extending
for
metric
and
color
support.
We
have
a
lab
server
support,
which
is
also
planned
in
junos,
and
the
subsequent
updates
should
actually
have
these
protocol
details,
which
should
be
ironed
out,
specifically
with
respect
to
the
label,
withdrawal
and.
A
Presentation
at
this
stage
you
are
waiting
for.
You
know,
comments
you're,
asking
for
working
group
to
review
and
that's
good
enough
all
right.
So
we
we
still
had
one
one
request
for
a
presentation.
We
will
not
be
able
to
entertain
this
in
this
session.
It
will
be
going
to
the
interim
session,
so
we
do
apologize
from
greg
and
yao.
We
cannot
fit
in.
A
I
honestly
don't
know
if
we're
gonna
be
cut
off
ten
minutes
after
the
session.
It's
fine
five
minutes.
Okay,
so
I
don't
think
there's
enough
time
to
go
over
this.
So.
B
B
This
one
first
on
the
inter
meeting.
A
Right
right,
okay
with
this,
we
end
the
the
the
session
and
thank
you
for
attending
your
attendance,
and
we
look
forward
to
seeing
you
next
time
in
the
interim
meeting
and
next
sessions.
Thanks.