►
From YouTube: IETF113-IDR-20220322-1330
Description
IDR meeting session at IETF113
2022/03/22 1330
https://datatracker.ietf.org/meeting/113/proceedings/
A
B
B
B
B
Other
reminders
we
are
under
the
ietf
note.
Well,
you
have
agreed
to
this.
You
know
as
part
of
your
conference
registration
and
are
going
to
be
bound
to
it.
A
point
that
is
part
of
the
notewell
that
we'd
like
to
point
out
is
that
the
ietf
code
of
conduct
applies
here,
so
you're
requested
to
be
respectful
in
your
conversations
with
other
people.
B
A
point
that
is
not
made
on
here
that
has
been
called
out
through
the
meeting
is
due
to
the
nature
of
this
being
a
hybrid
conference
we'd
like
to
request
that
anybody
who
speaks
please
identify
yourself,
those
who
are
on
mikdelko.
Your
name
will
show
up
in
the
minutes
as
a
side
effect
of
that
those
of
you
who
are
in
the
room.
B
B
Those
of
you
who
are
on
site,
hopefully
by
this
point
of
the
conference,
you
have
downloaded
the
meet
echo
tool
and
are
capable
of
putting
yourself
into
the
virtual
queue.
Apparently
there's
a
qr
code
that
you
can
scan
as
part
of
doing
this.
Please
take
advantage
of
that.
That
will
help
us
with
cue
management.
B
B
We
have
auth
48,
that's
in
progress
for
the
bgp
open
policy
stuff.
There
is
a
lot
of
energetic
back
and
forth
on
the
mailing
list.
You
know
dealing
with
the
edge
cases
there,
and
this
may
eventually
be
a
motivation
to
revisit
the
rfc
7606
error,
handling
procedures,
a
issue
that
will
be
resolved
at
a
later
time
as
part
of
more
general
cleanup,
is
that
the
original
code
point
allocated
for
open
policy
apparently
has
conflicts
with
stuff.
B
B
We
also
have
several
adoption
calls
in
progress,
and
now
this
is
where
idr
certainly
is.
A
large
group
is
a
little
distractible
at
the
moment.
Side
effect
of
this
is
that
we
have
a
lot
of
things
in
flight,
not
only
in
terms
of
our
big
pieces
of
work,
but
also
know
some
other
ones
flow.
Spec
v2
is
one
of
those
larger
items
and
we'd
like
to
get
that
adopted.
So
we
can
start
trying
to
move
that
down
the
pipeline
a
little
bit
more
energy.
B
We
also
have
an
adoption
request
and
process
partially
motivated
by
some
grow
work
for
clarifying
procedures
for
maximum
prefixes
and
how
it
interacts
with
the
bgp
state
machine
and
as
part
of
a
set
of
work
related
to
the
bgb
control
plane
being
used
for
multicast
purposes.
We
have
this
document
for
srp
to
mp.
B
Please
take
a
look
at
that
and
also
the
related
work.
That
is
in
other
working
groups,
including
best
you
can
see,
on
the
right
hand,
side
that
there's
a
link
to
the
idea
wiki,
and
it
will
help
you
find
the
current
status
of
this
sort
of
thing
and
we're
also
trying
to
keep
documents
that
are
clustered
together
with
related
work
and
other
working
groups
in
the
mickey
we
have
some
adoption
calls
that
will
likely
be
getting
kicked
off
as
part
of
finishing
up.
This
ietf
work,
the
bhp
class.
B
Will
transport
and
php
car
are
two
of
the
topics
to
be
discussed
today,
and
you
know
as
part
of
working
through
things
today,
we'll,
hopefully
be
able
to
start
a
working
group.
Adoption
calls
once
we
figure
out
what
that
looks
like
and
very
similarly,
we
have
a
set
of
adoption
calls
to
be
done
on
auto
configuration
and
we'll
discuss
those
as
we
move
along.
B
We
had
one
no
consensus
on.
You
know
the
vpn
prefix
rf.
There
is
a
lot
of
energetic
discussion
there
and
the
authors
are
still
very
interested
in
continuing
work
on
this.
As
discussed
on
the
mailing
list,
they're
encouraged
to
you
know
obtain
a
first
come
first
serve
code.
Point
and
begin
implementation-
and
perhaps
you
know,
as
their
work
actually
bears
fruit.
We
can
hopefully
see
if
the
working
group's
willing
to
reconsider
this
based
on
implementation
experience,
not
a
specific
working
group
adoption
item
but
had
generated
a
lot
of
energy.
B
We
had
a
lot
of
discussion
on
link
local
desktop
capability.
I
think
this
one's
just
mostly
a
matter
of
finding.
You
know
a
single
editor
to
take
point
on
this
and
move
that
forward
and
once
the
chairs
have
a
little
bit
more
bandwidth
yeah.
We
can
drive
this,
but
this
is
a
place
where,
if
you
have
the
energy
to
drive
this
yourself,
you
know,
maybe
we
can
help
schedule
it
that
way.
B
We've
also
had
a
request
for
working
group
attention
from
several
other
working
groups,
including
best
pce
beer
and
cider
ops.
Some
of
this
is
about
working
group
last
call
comments.
It's
part
of
a
d
follow-up,
so
john
scudder
has
asked
us
to
help.
Take
a
look
at
the
color
bits,
no
as
part
of
the
segment
routing
te
policy
draft.
B
So
please
chime
into
that
thread
from
best.
We
also
have
three
specific
documents
that
need
additional
focused
review:
the
srv6
services
document,
the
evpn
pvpn
internet
working
draft
and
the
unequal
load
balancing
draft
as
well
from
cidrops
randy
bush
has
asked
us
to
take
a
look
at
the
rov,
no
rr
draft.
The
short
version
of
that
is
carefully
main
carefully
managing
how
route
refreshes
are
done
when
you're
running
the
rpk
router
protocol
for
route,
origin
validation
and
pce
beer
also
has
no
feedback
requested
for
some
of
their
work
as
well.
B
Trying
to
wrap
up
the
status,
we
attempted
to
schedule
interim
meetings
and,
as
we've
discovered,
both
partially
from
the
usual
end-of-year
scheduling,
problems
and
also
fun
with
the
pandemic.
We
made
three
attempts
to
schedule
interims
that
failed.
We
did
finally
manage
to
have
a
successful
interim
with
a
lot
of
energetic
discussion
on
january
24th
and
the
subjects
there
were
largely
bgp
routes
of
color
in
terms
of
serious
presentations
on
car
nct
and
some
other
properties.
B
B
B
B
B
After
those
things
had
been
presented,
we
had
a
general
plan
to
start
adoption,
questions
and
calls.
After
the
january
intro
we
had
a
last
minute
proposal
for
l3nd
and,
as
part
of
fairness
to
you
know
the
authors,
I'm
going
to
make
sure
that
they
got
equal
time
for
presenting
their
work
and
also
to
have
equal
level
of
scrutiny,
paid
attention
to
it
similar
to
what
had
been
done
over
the
last
couple
of
years
as
part
of
the
design
team
analysis.
B
So
we
delayed
the
adoption
call
until
we
can
get
it
presented
at
this
ietf
and
yeah.
We
kicked
off
some
discussion
about
the
proposal
and
idea
mailing
list
you're
encouraged
to
take
a
look
at
those
threads
and
you'll
respond
to
any
questions
that
may
have
been
raised
there,
and
that
was
a
critical
point
with
l3nd
being
issued.
No,
we
now
have
all
of
the
idr
chairs.
You
know
with
an
active
hand
in
the
solution
space
for
these
proposals.
D
B
D
D
D
There
is
no
pre-transmission
because
it
uses
tcp
tcp
handles
that
the
only
state
that's
kept
is
the
minimal
state
at
the
ends
of
what
it
is
learned
about.
The
other
end,
it
is
not.
The
protocol
itself
contains
restartability,
but
not
state
thanks
to
tcp,
it's
guaranteed,
reliable
in
order,
etc,
etc.
D
D
D
D
D
The
tls
open
we've
seen
this
there,
the
hello
has
come
in
the
sender,
knew
its
ip
address.
The
receiver
saw
the
source
address
on
the
hello,
so
each
knows
the
others
address
for
the
interface
for
the
hello,
so
they
can
choose.
Who
is
going
to
be
the
tcp
server
and
who's
going
to
be
the
client
by
the
classic
method
of
the
lowest
I
p
address,
provides
the
server
and
the
highest
is
the
client.
D
D
D
D
Okay
and
there's
a
serial
number
you're
going
to
see
in
the
data
pdus
which
allow
that,
if
things
get
broken,
they
can
reconnect,
they
can
reissue
an
open
with
the
old
session
id
and
the
serial
number
of
the
last
good
pdu
and
say
hey
if
you're
cool,
I'm
cool
with
resuming
the
session
from
that
point
now.
This
is
designed
much
more
for
the
large-scale
addressing
space
of
ebpn
etc.
D
D
Okay,
all
pdus
are
act.
This
is,
as
I
said,
a
really
dumb
standard
old
style
protocol.
The
ack
also
acts
as
an
error
notice.
So
if
there
is
an
e
type
greater
than
zero,
it
tells
you
hey.
This
is
a
warning:
the
session
is
broken
or
call
the
operator,
and
there
are
room
for
error,
codes
and
hints
and
so
on
and
so
forth.
D
So
note
there
was
the
serial
number
and
then
I
pass
you
a
list
of
ipv4
addresses
or
we
call
them
for
the
moment.
Encapsulations.
That
word
has
been
confusing,
we'll
work
on
it,
but
each
one
each
ipv4
address,
has
a
flag
field
and
then
a
prefix
length.
Of
course
the
flags
say
whether
I'm
announcing
it
or
withdrawing
it.
D
D
D
D
I'm
going
to
tell
you
my
as
I'm
going
to
tell
you
what
ipv4
peering
address.
I
would
like
to
use
and
remember
that
could
be
a
loopback
and
when
I
told
you
my
addressing,
I
told
you
what
would
I
have
marked
it
as
a
loopback
you'd
have
known
my
primary,
so
you
can
set
up
forwarding,
okay,
blob
for
authentication
data,
md5
or
whatever,
and
also
a
flag
for
gtsm.
D
D
D
We
can
argue
that
it
really
only
costs
a
few
bits
in
the
length
fields.
If
you
don't
use
the
scaling
and
hand
try
to
handle
over
a
ton
of
addresses,
and
I
can
go
into
now
or
some
other
time
how
you
can
use
it
for
highly
scaled
evpn,
multipod,
etc,
etc.
With
the
whole
thing's
multi-tenancy
microservices
that
whole
world.
D
D
When
is
discovery
finished,
should
it
be
stopped
or
because
new
people
will
keep
plugging
in
devices
and
old
devices
will
leave?
Do
we
keep
running
forever
how's?
That
done?
Is
there
a
full-scale
orchestration
system
over
there?
If
so,
you
know
that
we
haven't
really
discussed
this
okay
and
I
really
question:
do
we
rather
need
the
restartability?
It
adds
complexity,
and
now
I
really
am
through
and
jeff.
If
you
wanted
to
ask
questions.
E
F
Ac
landing
cisco
systems-
hey,
I
was
just
going
to
say
the
last
part
about
how
this
is
communicated
to
be
bgp.
I
think
this
in
that's
an
internal.
We
don't
have
to
specify
those
apis
between
the
discovery,
protocols
and
the
nbgp
or,
let's
say
any
other
any
other
entity
that
wants
to
learn
these
things.
I
really,
I
really
think
I
really.
I
really
think
that's
out
of
scope
for
the
ietf
for
the
standard.
E
D
A
G
D
D
G
D
A
H
H
B
Yeah
minto,
unfortunately,
we
have
to
move
forward.
Randy,
I
think,
to
minto's
point.
What
is
being
requested
is
more
details
about
the
contents
of
the
certificate,
since
some
tls
certificates
are
bound
to
ip
addresses.
So
you
want
to
go
to
more
detail
about
the
profile
you're
expecting
bill,
yeah
the
microphone.
I
B
B
B
B
B
B
Okay,
I
think
we're
slicing
at
details.
Third
comment
that
I
had
was
about
the
lowest
address
for
bringing
up
the
session
for
determinism.
I
understand
why
you
did
that
in
the
sense
of
lmtp.
As
an
example
uses
something
very
similar,
I
would
suggest
that
you
take
a
look
at
how
this
impacts
using
this
mechanism
on
the
network
segment
that's
broadcast
or
that
can
be
used
for
like
a
route
server.
I
believe
this
tie
breaking
will
encourage
full
mesh
connection
rather
than
up
and
spoke.
B
B
D
D
B
D
B
B
B
So
where
does
this
move
us
originally,
when
we
had
only
three
proposals
on
the
table,
the
questions
that
we're
going
to
be
going
to
the
idr
list
about
auto
configuration
for
adopting
a
solution
with
question
number
one:
what
layer
did
we
want
to
actually
have?
No
our
solution,
work
at
and
the
option
could
be.
You
know,
layer,
two
layer,
three
or
potentially
a
solution
for
each
once.
The
question
has
been
answered
about
which
layer
we
wanted
what
proposal
we'd
like
to
take
for
it.
B
B
B
F
J
B
J
J
I'm
not
seeing
ac
jump
back
in
the
queue
so
folks
do
you
have
any
preference
on
how
we
do
these
calls
and
ask
this
question
because
maybe
you're
saying
we
should
do,
we
should
adopt
all
four.
We
like
the
two
of
the
layer
two,
because
they
have
two
different
properties.
We
like
two
of
the
layer
three,
because
they
have
properties.
K
K
next
slide,
please,
okay,
so
we
have
been
evaluating
the
structure
of
the
model
and
we
believe
at
this
time
that
it's
holding
up
with
respect
to
any
further
future
extensions
that
we
believe
are
going
to
come
for
all
the
changes
that
are
coming
to
bgp.
So
there
is
a
update
as
far
as
the
l3
vpn
model
that
I'll
cover
in
a
later
slide.
K
K
Next
slide,
please,
okay!
So
what
are
some
of
the
outstanding
issues?
By
the
way
we
have
a
running
list
of
all
the
issues
at
this
particular
github
link,
if
you
ever
want
to
go
there
and
you're
free
to
add
to
those
list
of
issues,
if
you
feel
it's
not
being
covered
adequately
here
on
the
list,
some
of
the
major
issues-
and
this
by
no
means
is
an
exhaustive
list.
K
K
K
K
K
As
I
said,
the
only
thing
it
needs
to
provide
is
the
keychain
reference
and
then
the
final
item,
the
l3
vpn
yang
model.
So
we
did
look
at
the
l3
vpn
model.
We
have
suggested
some
changes
that
would
be
needed
in
that
model
to
if
it's
going
to
augment
the
bgp
model
and
then
also
we'll.
We
have
an
example
that
works
with
the
provided
changes
in
the
model.
So
that's
an
again
again
an
example
of
how
somebody
could
use
the
bgp
model
for
and
augment
it
for
their
purposes
like
l3
vpn
right.
G
B
B
B
B
It's
clear
that
each
proposal
is
trying
to
bring
a
specific
operational
model
to
how
things
work,
so
that
will,
I
think,
be
part
of
our
longer
discussion
about
you
know.
Adoption
and
one
of
the
things
that
I
encourage
the
presenters
for
the
next
set
of
slots
to
discuss
is
you
know
the
operational
considerations
for
what
your
mechanism
looks
like,
and
you
know
what
does
your
format
specifically
bring
the
operators?
B
Aside
from
all
these
details,
the
largest,
you
know
remaining
functional
comparison,
point
that
we
have
between
a
car
and
ct.
This
car
does
add
a
idea
to
bgp
of
carrying
optional
components
as
part
of
lri,
to
try
to
decouple
the
formatting
that
we
have
from
bgblu,
where
we
carry
a
label
stack
that
is
non-key
but
isn't
explicitly
called
out
as
part
of
the
structure
in
the
format.
B
B
B
So
a
point
that
the
car
authors
have
brought
up
repeatedly
is
you
know
they
believe
that
there's
local
convergence
issues,
the
question
sue
has
is:
is
there
really
a
local
convergent
issue
with
ct
when
the
same
rd
is
used?
Care
has
raised
himself
that
the
ct
document
is
not
necessarily
clear
in
some
respects
about
when
you
would
want
to
use.
B
So
that
would
be
a
useful
thing
to
discuss
as
part
of
the
main
list.
It
will
kick
off
a
specific
thread
there
and
in
terms
of
fallback
you
know,
can
the
different
proposals
actually
handle
specific
sets
of
fallback?
The
car
document
calls
out
explicitly
what
the
fallback
order
should
be
ct
does
not,
and
it
may
be
worth
the
ct
authors.
You
know
adding
that
as
part
of
their
discussion
points.
B
M
M
M
What
this
means
is
on
a
bgp
service
route
that,
for
example,
in
l3
vpn
route
that
requests
a
particular
intent.
It's
indicated
by
using
the
bgp
color
external
community
next
slide,
please
what
bgp
colorado
routing
does
now
is
it
actually
sets
up
the
transport?
You
know
path
for
a
given
endpoint,
but
for
a
given
color.
This
allows
multiple
routers
to
be.
You
know,
used
in
the
network
for
different
intents
for
the
same
destination.
M
As
you
see
here,
the
endpoint
for
the
endpoint
e3,
then
at
an
ingress
point,
a
service
route
needs
to
be
then
steered
or
you
know
the
traffic,
for
it
needs
to
be
smeared
over
a
particular
intent.
You
know
aware
path.
The
steering
or
the
resolution
uses
not
just
the
bgp
next
top,
but
also
the
color
that
came
in
the
color,
extended
community
and
then
resolves
over
a
bgp
color
out
for
that
color.
M
M
So
we
are
introducing
a
new
smartphone
bgp,
because
we
needed
to
signal
multiple
instances
for
the
same
prefix.
It's
an
operational
requirement.
You
don't
want
to
burn
different
ip
addresses.
You
know
so
you
you
know,
have
the
same
ip
address,
but
you
want
to
different
routes.
We
use
you
know
color.
M
M
At
the
same
time,
we
are
modernizing
this.
You
know
the
use
of
this
safety
by
you
know
in
bgp
car
addressing
some
of
the
limitations
that
exist
with
bgp.
At
the
same
time,
we
are
maintaining
the
functional
and
operational
consistency
of
bgp
and
you
in
terms
of
the
route
processing.
You
know
the
best
path.
Other
things
as
we'll
you
know
see
along
the
next
slide
and
illustration
below
kind
of
you
know,
gives
a
sense
of
how
a
car
route
looks
with
respect
to
a
bgplu
route.
M
This
is
the
proposal
for
the
car
llri.
It's
it's
a
simple
extension
to
you
know
existing
vgp
route,
which,
in
addition
to
the
prefix
you
have
the
color.
The
color
you
know
serves
to
provide
act
as
a
distinguisher
for
the
route,
but
it
also
provides
the
intent
you
know
provided
by
the
route.
This
is
optimized
for
the
majority
of
you
know.
You
know
deployments
where
you
have
network
devices
that
operate
within
your
color
domain.
That
is,
you
know
they
have
the
same
consistent,
color
mapping.
M
We
do
support
the
you
know
the
exception
cases
we'll
cover
it
later.
Next
slide.
Please
we've
gone
through
this.
Before
I
mean
we,
you
know,
we've
defined
it
to
be
the
you
know,
the
simplest
data
model
we
can
use,
you
know,
and
it
enables
the
most
efficient
route,
processing
and
storage.
You
know
we
are
talking
about
an
old.
You
know
inc
in
a
much
increased
scale
than
what
you've
seen
with
bgplu
today,
because
now
it
gets
multiplied
by
the
number
of
intents
that
may
be
supported,
so
we
need
to
focus
on.
M
You
know,
efficiency,
that's
what
we've
done
this
model.
You
know,
as
it
works
very
similar
to
bgplu.
It
inherently
provides
ecmp
awareness
or
backup
paths
at
every
bgp.
Hop
we'll
see
details
in
the
next
in
a
slide.
This
provides
faster.
You
know,
localized
convergence,
we
you
know
again.
We
don't
have
to
deal
with
complex
workarounds
to
make
things
work
because
we
use
an
import
or
a
mechanism.
We
don't
need
that.
The
next
slide,
please.
K
M
This
is
the
illustration
for
that,
in
our
case,
as
jeff
said,
you
know
described
it
before
it's
been
debated,
you
have
two
abrs
here,
two
three
one
and
two
three
two
originating
the
route,
for
you
know
an
endpoint
e3.
Now
that,
naturally,
you
know
ends
up
being
you
know
treated
as
multipath
at
the
ingress
nodes
of
the
domain,
you
get
a
common
label
next
top
self.
What
gets
propagated
is
just
you
know
the
route
from
the
those
border
nodes,
any
failure
of
the
abr
gets
handled
locally
within
the
domain.
M
There's
no
churn!
You
know
outside
with
ct.
You
don't
get
this
by
default.
You
know
you,
the
the
you
know,
the
user
unique
rd,
those
already
end
up,
creating
unique
routes,
the
routes
in
the
lsp
propagates
all
the
way
to
the
ingress
fees-
and
you
know
any
kind
of
convergence
has
to
happen
at
those
ingress
fees
and
at
the
same
time
you
know
you
have
all
this.
You
know
failure
propagation,
the
churn
going
across
in
outside
the
domain.
M
Some
workaround
has
been
proposed
and,
as
we
not
discussed
it
previously,
that
you
know
fails
to
address
it
because
it
still,
you
know,
propagates
the
churn
outside
to
jeff's
point
and
just
to
address
it
there,
or
I
guess
this
question
if
same
rd
was
used.
I
mean
you
know
you,
you
could
potentially
use
same
rd,
that's
another
in
a
way,
because
it's
an
already
you
have
that
option,
but
it
still
doesn't
take
away
the
the
import
processing,
that's
there
and
it
seems
redundant.
You
know
at
that
point
same
idea.
M
I
don't
know
how
we
end
up
doing
automatic
automatically,
because
there
isn't
enough
space
to
put
any
an
id
that
says
that
multiple
devices
come
up
with
the
same
value.
You
know,
I
don't
think,
there's
enough
bits
to
put
the
32-bit
color
in
there
and
then,
if
at
all,
that's
the
you
know
solution,
then
it
kind
of
renders
the
you
know
the
rd
mirrorless.
M
Now
the
other
critical
aspect
is
really
have
we
defined.
You
know
our
transport
safety.
That
is
future
proof.
Right
I
mean
because
we
are
trying
to
move
people
from
bgplu
to
a
new
safei.
We
have
taken
that
into
account
when
we
defined
bgp
car
we
put
in
extensibility
again
leveraging
a
lot
of
you
know,
experience
from
other
bjp
selfies.
So
we
have
a
route
type.
We
have
a
key
line.
We
have.
We
have
encoded
non-ktlvs.
M
As
jeff
said,
there
is
monkey
data,
even
today
in
bgplu
you
know
l3,
vp
and
other
other
safies.
We
have
provided
a
structure,
you
know
made
it,
you
know
tlds,
we
enabled,
and
you
know
that
enables
us
to
you
know,
add
additional
tlvs
as
needed,
and
you
know
that
provides
some
benefits
as
we'll
see
in
the
next
slide.
At
the
same
time,
we
ensured
you
know
we
maintain
the
packing
efficiency
again,
we'll
see
an
example
of
that
in
the
in
the
next
line.
M
So
we
think
these
extensions
actually
make
you
know
this
new
safety.
You
know
as
a
good
base
for
future
extensions
virtual
use
cases
which
we
don't
even
you
know
are
aware
of
today.
One
thing
to
point
out
is
even
though
you,
you
know
introduced
tlps.
They
are
for
the
non-key
data,
as
pointed
out
here
so
from.
If
you
look
at
the
nlr,
the
prefix,
the
key,
that's
just
like
any
other
existing
next
slide,
please
coming
to
the
encapsulations.
M
So
clearly
this
is
a
you
know,
a
critical
improvement
with
you
know,
bgp
car.
You
can
signal.
Of
course,
the
same
you
know
forwarding
information
labels,
you
know,
sets
etc,
but
now
you
can
signal
them
without
having
to
overload
the
label
fields
of
of
the
you
know
existing
safeties
that
have
that
that
can
only
signal
labels.
You
can
signal
multiple
encapsulations
and
we
can
signal
different
values
for
those
encapsulations,
so
you're
not
constrained
to
ensuring
it's
the
same.
You
know
value.
M
M
This,
of
course,
makes
things
efficient
in
the
steady
state,
but
it
also
provides
a
benefit
when
you
look
at
migration
when
you,
when
you
have
these
different
encapsulations
in
the
network
and
you're
moving
from
one
to
the
other
today,
what
you
would
be
forced
to
do
is
set
up.
You
know
different
control,
plane,
distribution
channels
and
generate
duplicate
routes
for
the
same
information
with
you
know
for
different
end
cap
and
make
sure
they,
you
know,
travel
in
a
disjoint
manner
such
that
you
know
the
ingress
nodes
that
need
it.
M
You
know
receive
it.
That's
that's!
A
lot
of
operational
complexity.
We've
taken
that
care
of
that
here,
because
now
you
don't
you.
First
of
all
don't
have
duplicate
routes.
You
use
the
same
set
of
control
plane.
You
know
sessions,
it's
you
know
more
efficient.
It's
the
protocol
automatically
handles.
You
know
this
scenario
that
you
know
really
provides
through
objects.
You
know
operational
simplicity
and
optics
reduction.
B
O
M
Observation-
and
this
was
discussed
before
one
thing
that
did
come
up
that
they
have
come
out
of
the
interim
discussion
is
yes,
there's
an
acknowledgment
that
there
are
these
limitations
with
the
you
know
the
rxc827
encoding,
and
we
would
like
to
address
it.
This
is
a
general.
You
know,
I
think
expression
and
including
you
know,
from
the
bgpct
co-authors,
so
bgpct
unfortunately,
does
inherits
the
same
limitations,
whereas
with
bgp
card
view,
you
know,
recognize
those
limitations
and
address
them
from
day
one
into
the
design.
Next
slide.
Please.
M
M
Maybe
one
thing
to
bring
up
here
is
there's
been
some
discussion
about
longest
prefix
match,
and
you
know,
maybe
it's
a
good
place
to
mention
that,
of
course
guard
supports
the
longest
prefix
match
when
it
comes
to
next
stop
resolution.
So
if
you
hear
anything
to
the
contrary,
that
would
be
incorrect
next
slide.
Please.
M
Again,
another
key
goal
from
the
beginning,
and
this
again
talks
to
the
operational.
You
know,
simplicity
and
the
experience
bgp
car
is,
you
know
completely
com.
You
know
compatible
with
the
sr
policy
architecture
in
terms
of
using
the
color,
you
know
steering
mechanisms
fall
back
etc,
and
that
is
a
model
which
you
know
has
multiple
implementations
and
is
deployed.
So
you
get
that
in
a
sort
of
leverage
next
slide.
Please.
M
As
I
said
earlier,
there
can
be
exceptions
where
you
know:
networks
come
together
and
they
have
different.
You
know
color
to
intent,
mappings.
This
is
not.
Nobody
starts
with
this.
You
know
where
day
one,
but
it
can
happen.
So
we've
accommodated
that
you
know
by
leveraging
you
know
an
extended
community
called
the
local
color
mapping
community
to
signal
the
local
color.
You
know
within
a
domain
when
you
know
routes
come
from,
you
know,
other,
you
know
color
domains.
M
The
nlri,
however,
you
know
is
immutable,
does
not
have
to
be
rewritten,
it
just
deserved
end-to-end
and
then,
even
if
the
color
you
know
in
the
nlra,
is
you
know
now
you
know
from
a
different
domain.
The
prefix
is,
you
know
unique
in
the
inter
domain
transport
network,
for
example,
it's
a
pe
address,
so
that
makes
the
the
e-commerce
tuple
in
a
unique
next
slide.
Please.
M
This
is
essentially
a
iteration
of
some.
I
mean
like
more
set
of
clarifications,
because
some
points
have
been
raised
in
the
past
which
we've
addressed,
but
you
know
sometimes
they
you
know
come
back.
I
don't
think
at
this
point.
We
need
to
go
through
it
point
by
point
but
they're
there,
for
you
know
reference
the
if
it's
helpful
next
slide.
M
Please
again,
there
are
other
aspects
you
know
described
in
the
draft
and
you
know,
for
example,
different
scaling
designs
again.
Some
of
these
are
actually
used
today.
So
there's
nothing
new,
but
we've
done
an
analysis
of
the
trade-offs
and
some
optimizations
that
can
help
again
another
car
also,
you
know,
even
though
the
focus
is
largely
on
transport
here,
but
it's
it's
routing,
so
it
can
extend.
You
know
to
the
vpn
domain.
You
know
like
between
a
b
and
c,
so
you
define
an
extension
there
next
slide.
Please
again,
you
know.
M
I
we
think
it's
a
really
good
base
framework
that
can
be
extended
with
you
know,
lower
at
four
different
use
cases.
If
there's
a
heavy
focus
on
you
know
better
protocol
performance
and
scaling
both
in
terms
of
processing
and
memory
storage.
This
is
you
know,
important
again,
finally,
to
restate
it
yeah.
It
works
across
both
the
traditional
networks
as
well.
As
you
know,
newer
technologies
next
slide.
Please
yeah.
I
think
we
can
skip
past
this.
It's
just
an
output,
you
know
for
reference,
so
I
think
bottom
line.
M
B
Thanks
ninja
three
points
and
then
I'll
yield
this
to
stick
with
clarification
questions
we
have
discussions
scheduled
after
the
presentations
are
done.
Point
number
one
here
that
I
wish
to
raise.
You
have
two
implementations
with
interoperability
as
raised
on
the
mailing
list.
That
means
you're
squatting
at
code
points.
Please
address
that
asap.
You
should
not
be
leaking
that
out
into
the
internet
at
large
point
number
two,
based
on
how
the
discussion
has
evolved
across
the
mailing
list.
B
I
wish
to
caution
all
of
the
participants
about
making
value
judgments
about
other
people's
implementations,
giving
a
specific
example.
You're
raising
you
know
what
you
think
tables
look
like
in
terms
of
import
export
behaviors
for
ct.
You
know
you've
similarly
responded
to
cali
raj,
making
assumptions
about
longest
prefix
match
behaviors
and
your
implementation.
B
J
J
I
do
note
that
the
ct
document
needed
to
specify
that
it
could
be
run
in
multiple
rds
or
one
rd
when
I
pinged
them.
They
responded
to
that.
So
would
you
go
back
to
that
point
in
your
slide,
where
you
were
discussing
that
bring
up
the
prison,
bring
up
the
slide
and
just
sort
of
go
through
it?
I
I
thought
it
was
a
side
point,
so
I
didn't
want
to
interrupt
your
flow.
M
Sure
so
so
the
of
course
I
mean
and
just
to
point
out
what's
illustrated
here,
is
a
bgp
car.
You
know
and
lara.
So
you
know
we
would
still
be
now
talking
about.
You
know
ct
the
the
difference.
The
main
difference
you
know
I
was
you
know
was
describing
is
my
default
city
would
originate
routes
with
unique
rd's,
so
you
know
the
same
route.
M
M
Sure
I
think
I
was
just
pointing
out
that,
yes,
with
same
rds,
some
of
the
issues
could
be
ameliorated,
but
it
still,
you
know,
has
issues.
I
guess
one
comment.
You
know,
I
don't
know
if
I
should
restate
it
given
jeff's
government,
but
it
still
requires
an
input.
You
know
process,
you
know
a
procedure
at
you
know
at
the
nodes,
two
one
one
and
you
know
two
and
two
to
get
that
merge
happening.
M
It
is
not
automatic
right,
because
now
you
have
two
nodes
that
have
to
generate
the
same
value
to
get
the
same
rd
and
given
how
what
the
types
of
rd
we
have.
There
aren't
enough
bits
when
you
know
in
the
rd
to
fit
in
a
32-bit,
color
value.
Assuming
you
know,
color
was
a
way
to
you
know
generate
that
same.
N
L
Yeah
with
the
same
rd,
imagine
if
it's
originated
from
the
e3,
because
that's
what
kali
raj
mentioned,
if
it
origin
from
e3,
we
are
carrying
the
same
value.
That
means
the
prefix
e3
as
well
as
rd,
is
also
carrying
e3.
It's
a
repetition
of
information,
I'm
not
sure
for
what
reason,
but
we
are
carrying
the
same
information
twice
in
the
nlri,
so
I
don't
know,
what's
the
point
of
this
data
model,
if
we,
if
you
say
we
will
propose
same
rd,
so
this
is
a
great
point
for
the
author.
J
N
B
So
we're
going
to
move
to
the
ct
presentation,
we
also
do
have
an
lcu
presentation.
Afterwards.
The
goal
is
to
leave
as
much
time
for
discussion
about
the
sets
of
things,
and
I
do
want
to
point
out
there's
interesting
stuff
in
chat.
Please
take
that
to
microphone
once
we're
done
with
the
presentations
kylie
raj,
you
have
the
microphone.
P
P
Next
side,
please
so
problem
statement
is
it's
just
doing
intern
driven
service
mapping
so
basically,
irrespective
of
intra
domain
or
inter
domain,
you
have
the
same
way
of
how
you
specify
classified
transport
classes,
transport
tunnels
into
transport
classes
and
how
you
do
service
routes
resolving
over
a
set
of
transport
tunnels
in
a
desired
fallback
and
where
each
route
can
have
a
different
fallback
and
how
it
works
with
how
to
extend
pcp
to
carry
the
signaling
information
across
and
as
domain
next
slide.
Please
yeah!
This
is
just
a
reference
diagram.
P
It
just
shows
a
bgplu
network
trick
and
it
shows
the
different
redundant
asbs
and
abrs,
and
the
pe
hp
having
multiple
color
tunnels
and
how
the
colors
are
not
visible
today,
when
you're
using
vg
value
to
other
domains.
So,
for
example,
p25
cannot
put
a
traffic
on
the
gold
tunnel,
2pe11
yeah,
exactly.
P
So
this
is
the
main
reason
why
we
didn't
go
without
you,
because,
when
you're
going
for
new
extensions,
it's
good
to
just
have
a
way
which
works
always
and
if
you
have
a
route.
For
example,
if
you
have
a
city
route
or
a
transport
class
gold
and
the
english
pe,
we
know
that
end
to
end
the
gold
tunnels
are
up,
so
we
want
that
kind
of
a
guarantee.
That's
why
we
didn't
go
with
lu
and
using
ad
path
id
as
a
per
shuttle
scope.
P
P
Of
course,
I
think
everybody
agrees
that
we
don't
want
to
put
more
transport
routes
into
health
vpn,
so
we
did
not
do
that
and
the
carrying
color
in
the
basically
color
is
an
adjective
it's
not
a
noun,
so
it's
instead
of
carrying
it
and
carrying
the
attribute,
makes
more
sense
and
more
on
this
on
the
next
slide.
It
also
ties
in
into
how
the
internal
resolution
data
structures
are
built
and
use
of
rte
target.
It
allows
for
rtc,
like
mechanisms
providing
on-demand
next
up.
P
L
P
P
With
color,
with
the
with
the
pure
longest
prefix
match,
there
may
be
other
arrangements
possible
which
are
less
efficient
and
it's
not
possible
with
ipsrt,
also
colorful
ip
also
and
look
lpm
look
up
on
non-host
previously
crowd.
So
this
is,
I
think,
it's
one
of
the
main
things
in
the
in
the
responses.
P
So
we
need
to
do
some
jewelry
here
and
it
is
of
course
supported
in
colorful,
ip
prefix
and
and
carrying
best
effort
tunnels,
it's
possible
with
the
iphone
color,
because
color
is
at
the
end,
but
it's
not
possible
with
srt.
That's
a
color
column
ip.
So
we
see
that
it's
kind
of
evolution
and
because
cd
does
not
include
the
color
in
the
mre
at
all,
all
the
things
are
possible
with
cd
next
right.
Please.
P
So
this
is
just
restating
the
solution
constructs
and
the
main
things
here
I
want
to
point
out
is
a
transport
class
that
is
the
construct
that
equalizes
the
different
transport
protocols.
Some
of
them
have
energy
know
the
colors
some
of
them
may
not,
and
then
we
have
the
resolution
team
and
the
mapping
community.
So
these
are
the
important
things
the
mapping
community
is
not
it's.
Basically,
we
define
it
as
any
vdp
community,
so
it
is
not
like
a
one-to-one
mapping
with
a
color
so
most
default
cases.
P
It
will
be
a
color
that
you
want
to
derive
the
mapping
community,
but
you
can
have
a
mapping
community
that
that
can
describe
the
actual
fallback.
We
will
have
an
example
of
this,
and
I
think
this
this
is
the
missing
piece.
This
is
the
difference.
I
see
that
it
is
not
there
in
a
car
I
mean
I
I
don't
know
how
you
do.
I
have
asked
those
questions
on
the
email,
alias
and
I'm
expecting
a
response
from
others.
P
So
if
r1
wants
to
use
color
c1
as
a
primary
and
c2
as
backer,
whereas
a
different
route
r2
wants
to
use
the
reverse,
c2s
primary
and
c1
as
backup.
How
do
you
express
this
if
it
needs
config
changes
from
the
box,
then
basically
you
don't
actually
signal
it
so,
but
with
ct
we
can
signal
it
next
slide.
Please.
P
Yeah,
so
this
is
just
an
example
of
how
you
expect
intent
in
bgbcd.
It
just
gives
a
concrete
example
of
how
you
do
the
mapping
and
how
can
you
how
you
can
signal
using
the
mapping
community,
what
fallback
game
the
route
wants,
and
we
don't
see
these
kind
of
details
in
the
car
document
it'll
be
good
to
add
how.
P
Yeah,
so
these
are
the
advantages,
and
this
is
like
a
reputation
from
previous
sessions.
I
think,
instead
of
going
through
this,
I
like
to
respond
to
some
of
the
comments
that
were
made
in
cosmic
sunday's
presentation.
One
was
about
the
limitation
of
8277
encoding,
so
our
point
was
to
move
non-key
fields
out
of
the
nlri,
not
to
add
more
of
them
to
the
nlri.
P
So
what
our
suggestion
was
to
go
with
that
model
where
we
take
forwarding
information
or
non-key
information
out
of
the
environment,
you
just
want
to
clarify
that
and
yeah
and
the
point
on
local
convergence.
So,
like
was
pointing
out,
I
mean
if
you
use
a
rd
at
the
egress,
I
mean
if
you
use
cp
route
origination
at
the
us
ee,
then
like
jeff
points
out.
These
two
proposals
are
identical.
You
have
the
same
kind
of
prefix.
P
You
don't
have
any
different
rd
that
the
ingress
pcs,
all
the
asps,
and
to
the
point
where
why
do
you
need
the
ip
in
both
the
rd
and
the
prefix?
I
mean
you
should
look
at
id
as
only
the
identifier,
it's
just
a
identifier,
and
you
have
flexibility
to
what
you
say
configure
the
rd
like
you
want
and
like
jeff
has
been
pointing
out
it's
okay
if
we
bring
up
a
new
rd
which
encodes
color
or
if
we
have
some
way
to
have
a
wider
rd.
P
P
The
color
will
be
two
bytes,
but
for
most
practical
use
cases
that
will
be
good
and
I
just
want
to
bring
up
the
point
that
whatever
city
does
it
basically
protects
the
investment
of
operators.
I
have
made
an
operational
training,
tooling
procedures,
so
there's
like
nothing
new
here.
It's
like
using
well
oiled
machinery
of
l3
vpn
in
a
new
transport
layer.
P
B
L
Things
that
that
was
just
now
mentioned,
one
of
the
questions
was
regarding
the
the
same
rd
originating
from
the
originating
pe,
as
khalid
just
mentioned,
I'm
not
sure
why
we
need
to
advertise
again
the
republic
of
the
same
question.
I
already
asked
that
what's
the
point
of
sending
pe
address
is
still
a
global.
It's
in
a
transport
network,
it's
global.
L
What's
the
point
of
sending
the
p
address
in
rd,
because
you
yourself
mentioned
you're,
sending
a
pu1
colon,
some
value,
then
a
pu
on
address
and
again
you
will
do
the
same
thing
for
another
vgpct
route
sent
from
the
ojtp
to
achieve
the
conversion.
So
I'm
not
sure
what
is
the
point
of
putting
a
rd
in
flutter
if
you're
saying
for
any
local
convergence,
you
need
a
same
article,
I'm
not
sure
where
you're
getting
with
it.
That's
the
first
point.
L
Second
point
is
for
the
multi
you
are
proposing
you,
you
agree,
there
are
limitations
for
eight
to
seven
seven
rfc,
but
you
are
proposing
another
multi-next
stop
attribute
to
carry
it
remember.
Multi-Net
attribute
is
also
an
attribute.
We
are
talking
about
transport
network
where
the
label
allocation
is
per
prefix.
For
each
transport
city
route,
you
have
to
have
a
unique
label.
Now,
if
you
start
moving
that
to
a
next
top
attribute,
it's
carried
in
the
attribute
update
message:
it's
not
good
with
the
nlri
so
day,
one
you
are
making
each
nri
unique
and
remember.
L
We
cannot
compare
the
bgp
cpr
card
to
bgplu.
Pgplu
was
just
carrying
a
best
effort
today,
with
the
single
ip
address
being
carried
for
a
particular
pe.
Now
we
may
be
carrying
many
intents
for
a
pe
address.
The
scale
of
bgp
is
going
much
higher,
so
I
don't
see
a
reason
to
break
the
packing
right
from
start,
there's
no
reason
we
should
try
to
optimize
thing
when
possible
and
it
will
help
when
you
are
going
across
one
bgp
domain
to
another
eager's
domain,
that
time.
J
L
Okay,
I
I
will
be
a
little
slower
yeah.
My
my
point
was
one
of
the
things
that
has
been
agreed
is
that
8277
has
the
limitations,
because
it
encodes
the
label
within
the
nlri,
in
the
hard
coded
fashion,
which
breaks
which
doesn't
support
multiple
end
caps,
if
required
during
migration
and
coexistence,
and
as
well
as.
L
It
has
a
limitations
for
any
future
use
cases
like
other
type
of
encapsulation
so
and
the
proposal
is
that
we
should
move
to
multi-next,
stop
attribute,
remember
it's
an
attribute
in
bgp
update
message
and
we
are
talking
about
encapsulation
informations,
like
label
or
equivalent
for
other
encapsulation
in
the
future.
So
if
we
start
carrying
such
information
in
the
attribute,
not
in
the
nlri
as
car
has
suggested,
we
are
day
one
baking
breaking
the
packing
of
pgp
and
we're
not
talking
about
bgplu
anymore.
That
was
only
a
single
address
for
a
particular
global
pe
address.
P
Yeah,
so
my
response
to
that
is
that
even
with
bgplu
doing
per
prefix
label
and
doing
the
putting
the
label
in
the
nri,
you
do
have
other
attributes
that
are
attached
today
to
each
at
each
bgplu
origination,
point
like
origin,
community
or
some
other
community
which
is
used
for
operational
use.
So
you
you're
not
getting
that
much
packing
today,
even
today,
so
complicating
the
protocol
to
do
this
kind
of
artificial
packing.
So
that
is
what
I
think
is
unnecessary.
P
L
C
L
B
O
B
P
Q
C
C
Yes,
this
document
aims
to
throw
into
domain
network
selection
problem
using
existing
technologies.
It
attempts
to
establish
a
multiple
gpr
usp
of
different
colors
for
all
all
multiple
prefix,
whose
teaching
mathematical
network
segments
this
document.
This
describes
the
colored
ptr
usp,
which
contains
two
options.
C
One
is
to
define
dramatical
paths
for
the
same
destination,
prefix
and
advertise
the
ubp
update
message
and
each
updated
message
can
contain
the
color
extended,
communicate
combinated
with
different
color
value,
which
helps
to
select
the
land
and
the
lighting
without
resources.
This
code
requires
additional
pass
function,
defined
in
rfc
7911.
C
C
C
C
Yes,
here
are
two
topics
initiated
by
chair
jeff,
the
question
one:
how
does
root
resolution
work
with
your
feature
for
for
our
color,
the
ppl
is
request,
recursive
and
color
of
wired.
We
use
color
and
next
hope
in
the
lookup
king.
I
will
choose
and
will
choose
only
sla
paths.
They
include
sr
police,
stp,
flag
fa
and
r3pte
rpm
based
on
polis.
C
For
question
2
root,
original
nation
and
propagation
because
it
configured
consider
the
following
example
of
established
metaphor:
ptlu
lcp
for
different
colors
in
cro
across
domain
scenarios
in
this
figure
p1
at
the
word
type
advertise
to
pass.
One
point
one
point:
one
point:
one
plus
id
one
calculates
the
color
one
attribute
and
one
point
one
point:
one
point:
r
one
plus
I
two
carries
the
color
two
attributes
to
espr1
p1
advertises
the
bounding
between
prefix
1.1.1.1
and
labeled
0.
Because
of
the
end
note,
both
paths
has
the
same
label.
D
C
To
spr2,
1.1.1
plus
id1,
okay,
with
color
one
plus
label,
two
zero
one
and
one
point
one
point:
one
plus
id
two
calories:
color
2
plus
label
2
0
2.,
similar
sbr2,
also
generates
two
different
labels
based
on
the
prefix
id
and
color.
As
shown
in
the
feature
multiple
end-to-end
pgpr
usp
are
established,
different
bgplus
selects
and,
like
I
say,
all
eternals
according
to
zero
colors.
C
Q
Q
C
C
R
B
B
O
You
know
you've
mentioned
in
in
the
in
the
recent
today's
chat,
as
well
as
in
the
last
interview.
This
discussion
did
come
up
about
the
color
mapping
between
the
domains.
This
is
something
that
you
know.
I
want
to
make
sure
that
we
all
have
a
common
understanding,
specifically
with
respect
to
the
car
they
talk
about
bringing
in
the
lc
lcm,
which
brings
in
the
community
mapping
between
the
domains
that
have
different
colors
now.
O
So
that's
something
that
we'll
have
to
go
through
on
a
node
by
node
basis,
to
the
originating
node,
to
understand
where
the
color
and
what's
the
real
intent
of
this
color
is
now
we've
been
hearing
from
swadeshi
and
dj
that
this
is
a
remote
case,
and
this
is
a
not
a
common
case.
But
this
is
exactly
what
we
did
not
hear
a
couple
years
ago
in
one
of
the
idea:
meetings
about
specifically
the
color
mapping
between
providers.
So
I
want
to
know
what
is
the
real
scenario
here.
O
I
want
to
open
up
the
forum
to
see
what
others
have
to
say.
I
know
we've
heard
from
both
the
ct
authors
and
the
co-authors,
but
anybody
else
would
want
to
comment
on
how
easy
it
is
to
color
mapping
between
providers
and
domains,
and
is
it
a
normal
case,
whereas
a
remote
case
would
appreciate
any
comment
on
that.
L
Multiple
times
and
replied
on
the
list,
as
well
as
to
the
chef
very
clearly
and
jeff
has
also
summarized
in
his
mail.
It's
clearly
said
that
in
the
single
color
domain,
it's
a
color
in
the
analog.
That
is
the
color.
I
don't
think,
there's
any
confusion
and
once
it
crosses
the
boundary
yeah,
you
can
rewrite
the
l.
You
can
introduce
lcm
which
will
carry
the
color.
It's
very
clear,
I'm
not
sure
where
the
confusion
is
also.
Why
you're
trying
to
bring
up
a
confusion,
it's
very
for
single
color
domains.
Very
okay,
it's
easy!
There's!
O
L
The
optimization
we
have
done
and
remember
and
share,
remember
the
optimization
we
have
done.
We
had
make
it
work
like
bgp
lu,
with
all
the
convergence,
all
the
advantages,
no
repetition
of
ip
addresses
in
different
places
and
intent
is
right
in
front
in
the
nri.
That's
the
right
data
model
opaque,
putting
a
global
pe
address,
putting
a
rd
in
front
of
it
and
making
it
opaque.
L
A
L
O
L
L
B
I
must
I
must
stop
this
question.
We
we
have
limited
time
left.
We
are
going
to
be
colliding
with
the
room,
so
we're
going
to
continue
for
another.
You
know
six
minutes
at
most
so
srihari.
Please
take
your
question
to
the
list
in
detail
and
let's
actually
resolve
this,
since
we
do
continue
coming
back
to
it.
Ketan
you
have
the
mic.
Q
Q
We
have
heard
today
from
the
city
authors
a
similar
or
a
different.
They
have.
I
mean
there
is
a
proposal
to
how
to
do
that
as
well
in
that
city
proposal.
So
I
would
request
if
you
know
that
information
is
added
into
the
city
proposal,
so
that
now
right
now
it
just
comes
across
like
an
mpls,
only
solution.
Q
S
Assad
with
juniper
today
the
pce
can
cater
or
service
a
request
for
a
for
an
intent
identified
by
color,
and
it
can
compute
an
inter
domain
path
across
multiple
igp
domains,
for
example,
and
each
igp
domain
can
have
different
representation
of
what
algorithm
id,
for
example,
they
want
to
implement
in
their
domain,
but
still
the
pce
can
do
into
domain
across
different
algorithm
ids.
There
is
no
mandate
to
have
the
same
algorithm
id
across
multiple
domains.
L
Yes,
have
a
brief
moment
to
make
a
response,
yeah
again
the
same
repetition.
What
I
already
mentioned
to
shreeri,
that
for
car
to
work,
there's
no
requirement
to
have
the
same
color.
We
support
multiple
color,
multiple
ways
to
represent
the
color
or
different
values
to
represent
the
color.
But
again
I
will
repeat:
we
are
talking
about
a
single
administrator
managing
it,
and
this
is
about
inter-domain
bgp
routing
solution.
L
So,
if
you
want
to
carry
the
intent,
you
have
to
carry
intent
somewhere
in
car,
we
can
we
we
prefer
to
carry
in
the
nlri
for
the
most
useful
cases
or
most
optimized
cases.
Otherwise,
it's
in
lcm
for
multiple
color
domains
and
same
way
ct
can
speak
for
it,
but
that
exactly
also
carries
in
the
tc.
I
don't
think
there's
any
confusion
about
this
assault.
B
B
G
G
G
The
the
main
thing
I
wanted
to
just
raise
in
case
it
hasn't
kind
of
come
out
come
across
the
either
sets
of
authors
as
a
use
case.
For
this
is
fortunately,
I
don't
provide
inter-domain
esl
aware
services,
but
what
I
do
need
is
a
solution
to
the
problem
of
providing
local
repair
for
egress
peer
engineering,
bgp
routes,
and
I
think
that
probably
both
drafts
can
provide
a
solution
to
that.
G
The
idea
essentially
being
advertising
a
unique
lu
label,
depending
on
what
the
potential
backup
path
is,
so
that
you
don't
have
to
fall
back
to
ip
forwarding
in
the
event
of
a
local
failure.
It
would
be
nice
to
see
either
in
the
draft
or
maybe
when
we
next
speak
about
this
at
114,
to
hear
a
bit
about
whether
the
authors
think
that
that's
a
good
use
case
and
how
that
might
work
in
practice.
A
A
A
B
Thank
you.
This
ends
our
session
for
ietf
113..
We've
had
again
a
good
discussion
that
unfortunately
again
got
compressed
a
little
bit.
What
we'll
be
doing
as
part
of
collecting
the
minutes
is
trying
to
summarize
the
questions
and
points
where
people
seem
to
be
in
disagreement
and
we'll
be
feeding
those
questions
back
to
the
list.