►
From YouTube: IETF-IDR-20220829-1400
Description
IDR meeting session at IETF
2022/08/29 1400
https://datatracker.ietf.org/meeting//proceedings/
B
A
A
C
A
B
A
A
C
B
C
Is
the
number
of
working
group
last
call
and
adoptions
that
are
in
progress,
we'll
be
having
a
presentation
on
sd-wan
edge
discovery?
Another
presentation
on
bhp
updates
for
5g,
head
servers,
metadata
and
then
we'll
be
moving
into.
You
know
hp
routes
with
color.
You
know.
The
first
item
will
be
the
chairs
review
of
the
hp.
Current
ct
status
we'll
be
having
a
new
presentation
for
php
colorful
prefix
grounding
cpr
for
srv6
based
services,
and
the
final
item
on
the
agenda
is
a
set
of
proposed
interop
procedures
for
bp
routes
of
color.
A
A
A
A
A
A
A
We'll
probably
extend
it
and
ask
job
to
see
if
anyone
to
push
it
a
little
bit
more
draft
jang
idrts
flow,
spec
sr,
v6
policy,
there's
not
under
a
presentation
for
that
today.
There's
about
12
people
having
interest.
It's
got
another
couple
days.
So
if
the
authors
are
listening,
it
needs
to
have
a
few
more
what
it
does.
Is
it
augments
the
draft
flow
spec
redirect
ipit?
A
Wang
draft
wang,
idr,
vpn
prefix
orf,
has
been
getting
a
lot
of
play
on
them
on
the
list.
I
will
need
to
go
through
a
detailed
review.
I'm
also
the
shepherd
it's
circling
around
the
robert
igor,
john
and
jim
I'll,
probably
talk
to
each
of
you
directly
and
then
see
how
we
go
from
there.
The
rogue
pe
that
I
need
to
as
the
shepherd
talk
to
these
people
present
a
discussion
to
the
chairs
and
then
we'll
decide
the
next
step.
The
open
issue
is
a
rogue
pe.
A
A
The
next
three
drafts
that
are
going
to
be
scheduled
are
you
taro,
and
if
jim,
if
you're
on
the
call
just
a
minute,
let
me
see
if
jim
is
nope.
I
need
to
see
if
he's
updated,
his
draft
he
needed
another.
One
is
a
draft
sas
id
or
max
prefix
inbound.
This
may
be.
The
reason
I
want
to
talk
to
the
four
authors
is
the
max
prefix
inbound
draft
did
not
get
any
support.
A
It
got
crickets,
meaning
silence,
but
again
the
authors
who
are
objecting
to
the
vpn
or
after
after
one
of
the
suggested
solutions
was
inbound
prefixes
and
lastly,
we
have
john
scutter's
bgp
entropy
label
capability,
redo
we're
going
to
run
those
simultaneously
and
then
see
what
happens.
I
am
going
to
delay
to
the
six,
so
I
have
about
a
week
to
clean
up
the
rest,
since
they
were
my
shepherds
and
maybe
I'll
tag.
A
One
of
my
co-chairs
to
do
the
rest,
exciting
drafts
on
the
list
was
idr
bgp
send
holder
and
again
the
chairs
will
send
out
a
more
detailed
review.
The
detailed
reviews
for
the
car
ct
seem
to
provide
helpful
information.
That's
it.
I've
done
it,
hopefully
in
10
minutes
and
we'll
go
on
to
the
next
presentation,
which
is
linda,
and
I
see
linda
in
the
in
the
room
and
I'm
going
to
load
pre-loaded
slides
just
a
minute.
G
G
G
G
G
G
G
G
So
that's
one
part.
Another
part
is
exactly
same
as
mkls
vpn
advertise
the
decline
routes
and
with
the
prefix
and
different
route
target,
and
only
addition
to
that
is
that
is
using
the
encapsulation
extended
community,
which
is
specified
in
the
ifc
9012
section
4.1,
and
also
use
color
extended
community
to
associate
the
climb
routes
with
appropriate
underlay
properties.
G
G
G
G
So
this
is
the
client
route
update
which
just
illustrate
what
bits
and
what
pass
attributes
are
included
in
the
client
route.
The
client
route,
the
path
attribute,
multireach
nlri,
is
still
the
same.
You
have
same
afi
same
savvy
same
whatever
exactly
you
want
to
advertise
for
the
client
routes,
and
you
extend
cp2
at
this
pass
attribute
for
the
extended
community.
G
G
The
page
five,
which
shows
the
one
side,
has
multiple
cps.
Yes,
this
one.
So
this
one
is
to
show
that
in
sd-wan
in
some
sd-wan
deployment,
there
could
be
multiple
cpes
at
the
edge
like,
for
example,
you
may
have
a
cloud
data
center.
You
may
have
two
gateways
and
both
gateway
can
reach
the
the
client
routes
and
in
the
sd1
update
it
is
reflected
by
the
color
id
the
site.
Id
basically
indicating
this
is
pretty
and
to.
G
They
can
use
the
one
address
of
the
or
cpe21
to
reach
their
desired
client
routes,
so
this
is
just
showing
another
option.
Okay,
thank
you.
Okay,
go
back
okay,
so
this
is
the
second
example
like,
for
example,
you
may
have
a
second
group
of
vpn
client
routes
and
is
identified
by
the
purple,
so
the
purple
will
associate
with
different
set
of
the
the
property
of
the
tunnel,
could
be
having
different
ipsec
tunnels
or
could
have
different
encapsulation
or
could
have
different
encryption
mechanism
next
page
please.
G
G
Another
possibility
is:
there's
a
pre-established
episode,
security
association
between
the
peer
node
already
and
here
the
cp2
only
need
to
include
the
ipsec
security
association's
id
identifier
and
with
that
they
make
it
simpler,
so
just
two
different
ways
to
advertise:
the
ipsec
attributes
next
page.
Please.
G
G
So
the
remote
node
know
that,
in
order
to
reach
this
two
two
to
two,
his
wan
port,
the
ipsec
author
encapsulation
address
should
be
the
one
for
address,
so
that's
it
and
this
draft
has
been
in
the
has
been,
has
implementation
one
finished
implementation,
another
one
underway,
so
we're
hoping
to
finish
the
other
one
and
go
for
a
working
group.
Last
call.
Thank
you.
A
E
Okay
cool,
so
I'm
going
to
present
this
bgp
update
for
5g
h,
service
metadata
drop,
which
is
in
the
workgroup
adoption,
call
just
a
quick
update
on
the
first
slide.
That's
we
have
recently
changed
the
name
from
the
edge
compute
app
metadata
to
5gh
service
metadata.
We
felt
this
is
more
appropriate
based
on
that
kind
of
recommendations
in
the
mailing,
alias
so
moving
forward
with
this
name
next
slide.
Please.
E
So
that's
the
kind
of
a
key
idea
like
we
are
bringing
the
routing
solutions
and
kind
of
do
the
proper
load
balancing
based
on
this
service
metadata
from
the
ingress.
So
that's
traffic
kind
of
dynamically
change.
How
this
when
this?
This,
which
metadata
services
kind
of
gives
that
indications
this
based
on
that
site,
availability
or
not
next
slide,
please.
E
So
this
is
an
important
subtlety,
so
we
kind
of
captured
it
a
little
more
in
detail.
So
this
is
the
capacities
of
tlb
indicates
the
site.
Id
and
site
capacity
index
site
capacity
index
could
be
any
type
of
values
like
a
between
0
to
100.
It
represents
that
availability
of
that
specific
site
capacity.
It
could
be
like
example,
here
it
could
be
operating
at
100
capacity
or
50
percent
or
zero.
Zero
means,
like
the
site,
is
not
available
anymore.
E
So
this
is
just
a
kind
of
a
showing
the
past
reference
we
are
not
using.
There
was
a
drop
from
robert
on
that
aggregated
withdrawal.
That
was
kind
of.
I
think
it
was
there
for
quite
some
time.
It's
how
the
mp
aggregate
withdraw
mechanism
was
done
by
the
hp
is
the
different
type
of
safety
case
right.
So
it's
just
a
difference
and
we
kind
of
took
the
kind
of
idea
from
there.
But
here
the
use
case
is
different
and
we
are
using
that
capacity.
E
A
G
G
I
think
that's
her
next
page,
there's
two
other
metadata
being
proposed
in
this
draft.
One
is
the
preference
index
and
load
index
the
preference
index
is
the
value
between
from
1
to
100
is
to
really
to
differentiate
different
size.
For
example,
you
could
have
a
spell
site
in
the
metro
area
where
all
the
management
systems
classic.
E
Yeah
is
reason
I
don't
know
what
happened
like.
My
connections
may
be
blipped,
so
yeah
as
linda
was
mentioning.
There
are
two
other
subtleties
which
is
preference
of
tlbs
and
the
load
index
load
sub
klb,
so
preference
also
could
be
kind
of
presented
by
the
site.
What
is
the
site
preference
and
same
that
load?
Sub
tlb
has
two
form
like
in
aggregated
form
or
for
the
measurement
period,
or
it
could
be
a
raw
low
load
measurement.
E
Sub
dlp
number
of
packets
bites
to
the
specific
app
server
where
this
kind
of
services
are
boosted.
So
the
compute
engine
kind
of
working,
in
conjunction
with
the
bgp
that
will
have
an
interpretations
of
this
different
subtleties.
The
bgp
will
feed
that
computing
in
and
they
kind
of
do
that
computations
and
determine
like
that.
What
would
be
the
cost
factor
for
the
different
next
stops
associated
with
the
cinequest
route
and
accordingly,
that
will
change
the
decision
in
the
forwarding.
E
Yeah,
so
we
have
introduced
a
new
path,
attribute
optional,
transitive,
bgp
path,
attribute
to
carry
all
the
services
metadata,
this
metadata
applicable
to
multiple
nlris
type.
So
we
why
this
new
metadata
type
we
felt
it
would
be
much
easier
for
implementation,
wise
not
to
mixing
up
with
the
existing
kind
of
path
attribute,
and
this
metadata
again
applicable
to
different
types
of
lrys
like
what
we
want
to
propagate
to
the
ingredients.
E
E
E
A
Craft
is
in
working
group
adoption
that
was,
I
mentioned
earlier.
The
specific
adoption
issues
that
people
are
concerned
with
is
it's
linked
to
the
can
buff,
but
maybe
that
obscured
some
other
questions
or
concerns
you
have
about.
The
draft
now
would
be
a
good
time
to
ask
questions
so
I'll
pause
and
see.
If
you
want
to
ask
kossik
or
linda
any
questions.
A
A
A
B
E
Yeah
so
two
parts
like
ac,
so
one
is
kind
of
the
bgp
updates.
Another
is
the
basically
the
traffic
forwarding,
so
the
bgp
updates.
Basically
it's
more
of
a
point
to
point
from
the
egress
to
the
ingress.
Like
it's
a
it's
a
transitive
attribute,
it
will
be
going
to
the
rr
and
r
would
be
reflecting
based
on
that
routing
policy
to
the
ingress
nodes.
So
in
between
nodes,
anything
they
don't
have
to
kind
of.
It's
not
meant
for
them
like,
and
they
don't.
E
One
is
it's
more
of
a
delivering
through
route
reflector
or
could
be
point
to
point
and
the
when
the
traffic
comes.
Then
it's
again
it
is
encapsulated
properly
to
that
specific
egress
tunnels
like
where
we
have
a
multipathing,
it
would
be
kind
of
any
kind
of
tunneling.
Encapsulations
could
be
used
for
the
specific
destinations
like.
G
B
G
B
E
F
B
Yeah,
I'm
saying
I'm
saying
I'm
saying
if
it
only
goes
to
the
ingress
and
they
they're
using
it
for
pap
selection
and
if
they
forward
it
to
a
router
that
is
to
the
data
center.
It's
an
anycast
address.
So
there's
multiple
paths,
so
you
could
actually
you
know
if
if
they
don't
all
understand
it
and
it's
not
tunneled,
you
could
actually
have
a
route
loop.
That's
what
I'm
saying.
A
A
B
B
D
B
A
A
A
If
there's
any
high
level
changes,
I
will
put
forward
a
final
forum,
three
draft
once
we
I
get
through
reviewing
it
with
the
authors,
so
remember
that
our
call
had
three
parts
part
one
is
the
customer's
intent
that
it
needed
to
be
sla
and
service
level
expectations
needed
to
be
interoperable
and
it
needed
to
be
scalable
a
lot
of
forum,
threes
discussions
discussed
the
scalability
and
the
mechanisms,
so
I
will
go
into
some
of
that.
We
didn't
really
talk
about
interoperability.
A
A
I'm
gonna
scrub
it
through
with
the
authors
and
then
I
will
send
it
out
and
I
would
appreciate
additional
feedback.
What
I'm
going
to
do
is
simply
try
to
unweave
all
the
wonderful
back
and
forth
conversation
into
a
single
document.
You
can
look
at
and
then
we're
going
to
upload
the
issues
into
the
data
tracker.
These
documents
have
been
accepted
as
experimental.
A
A
We
are
convinced
from
the
customers
that
the
technology
is
meeting
in
the
field.
There
is
interoperability
issues
and
jeff
is
going
through
that
because
we
felt
that
was
important
and
we
need
to
turn
it
into
rfc
quality,
but
we
still
feel,
as
we
did
originally,
that
the
drafts
are
functionally
the
same
and
that
we
should
be
able
to
get
to
some
interoperability.
A
A
So
when
I
looked
at
the
forum
and
did
a
deep
dive
in
the
last
week,
or
so
I
found
that
the
itf
list
of
topics
was
accurate
with
two
additions,
so
I'm
gonna
go
through
that
we're
gonna
discuss
it
a
little
bit
and
we
had
the
spring
problem
statement
come
out.
We
sort
of
hinted
that
it
was
out
at
itf
and
didn't
really
give
it
play.
I
will
give
out
some
additional
comments
on
that
on
the
list.
I'm
mentioning
that
the
draft
is
draft
hr,
spring
intent,
routing,
aware,
color
and
dj.
A
A
If
you
want
to
stop
at
that
point
and
ask
any
questions,
because
we
went
pretty
quickly
through
the
idr
meeting
in
itf
114
and
then
we'll
dash
on
to
the
new
draft
cpr
colorful
prefix
routing
for
srv6,
and
we
will
go
into
jeff's
discussion
on
an
interoperability
now,
let
me
go
through.
You
will
see
in
red
what
I've
sort
of
gleaned
thanks
to
the
authors,
their
discussion
at
itf
1114
was
pretty
complete
with
all
the
forum.
Three
there's
some
more
detail,
but
the.
A
A
A
As
we
listen
to
the
next
draft,
some
of
those
issues
might
want
to
be
looked
at.
Then
we
had
intent
at
a
service
level
exist
me.
We
had
scaling
and
scalable
replacement
value.
Now
this
has
quite
a
bit
of
play
on
the
forum
three
list.
When
I
looked
in
detail,
I
will
need
to
scrub
this
part
and
send
you
out
a
specific
recommendation
based
on
talking
to
both
authors
and
the
recommendation
may
be
different
for
each
author
set,
meaning.
I
need
a
recommendation
for
improving
the
draft
at
this
point.
A
There
is
an
intent
at
the
service
level
that
I
think
needs
a
little
bit
more
pulling
out
and
making
sure
we
have
a
clean
logic
line
between
this
is
what
the
discussion
of
intent
all
the
way
forward
and
how
it
transitions
from
the
bgplu
and
becomes
a
scalable
file
follow
on.
There
is
the
use
of
add
path
which
seems
to
have
some
general
discussion,
but
again
the
discussion
on
forum
three
pointed
out
that
that
was
not
as
clean
as
it
could
be.
A
Now,
as
we
go
on
from
that,
the
things
below
the
line
are
things
that
each
draft
pointed
out
that
that
the
discussions
pointed
out
the
authors
could
improve
the
text
for
carr.
There
was
some
suggestions
for
the
anycast
scenario:
the
color
mapping
resolution
lcm
and
color
communities,
the
non
and
green
color.
A
Now
we
need
to
add
the
epm
prediction
for
color
domains
we
need
to
in
our
discussions
there.
I
need
to
determine
for
each
of
these
issues
a
summary
of
the
issue
and
a
summary
of
the
things
that
have
to
be
resolved.
These
summaries
of
what
have
to
be
resolved
for
car
and
I'll.
Give
you
the
same
example
in
ct
in
a
moment
will
be
put
into
issues
in
the
github.
A
We've
opened
a
github
for
both
drafts,
the
so
the
authors
can
both
field
issues
and
then
be
able
to
provide
changes
in
the
drafts
that
might
be
commented
on
you.
Can
the
authors,
the
main
editors?
That's
why
their
two
main
editors
are
in
charge
of
the
github
repository
and
changes
they're
in
charge
of
resolving
the
issues
once
we
put
them
in
I'm
hoping
we'll
get
to
agreement
on
issues
again.
A
A
A
A
A
I
am
seeing
swadesh
in
the
in
the
chat
room.
I
am
seeing
kali
raj
and
swadesh
and
I've
seen
both
author.
Both
editor
teams.
I
am
seeing
dj
and
swadesh.
I
am
seeing
kali
raj
and
nats,
so
I
will
pause
here
because
at
itf
114
we
didn't
have
much
time
for
discussion
and
let
the
queue
open
to
ask
the
authors
about
any
of
their
draft.
We're
we're
at
the
stage
we're
no
longer
comparing
for
adoption,
but
we're
comparing
to
improve
the
drafts
at
this
point
I'll
open
the
queue
for
a
moment.
A
D
So
so
this
is
kali
raj.
I
just
want
to
confirm
so.
Basically,
the
issues
that
you
have
listed
here
most
of
them
are
already
discussed
or
explained
in
the
mailing
list.
So
here
we
just
listing
it
for
completeness,
and
maybe
you
will
be
opening
the
the
github
issues
for
the
unresolved
ones
which
are
not
made
into
the
draft
yet
is
that
right.
C
A
A
Details
on
any
of
these,
because
I
haven't
reviewed
them
with
the
editor
teams,
both
car
and
ct.
So,
but
these
will
be
the
beginnings
of
that.
I
haven't
seen
where
the
high
level
issues
have
changed
at
all.
The
details
will
be
there
once
we
get
the
document
finished,
I
will
post
a
pdf
of
the
details,
just
like
I
did
with
for
with
questions
one
and
two
on
the
idea.
F
A
It's
taken
me
a
lot
longer
than
I
thought
it
would
to
go
through
all
the
details
and
sort
them
and
try
to
find
the
issues
and
I'm
not
sure,
I'm
even
happy
with
it,
and
it's
that's
just
because
there's
a
lot
of
good
work.
Okay,
so
just
to
review.
This
is
what
dj
presented
at
itf
114,
the
things
that
the
working
group
can
help
with
review
and
feedback
for
current
version
updates
on
srv6
flows,
consideration
updates
on
filtering
and
inputs
on
use
case
scenarios.
D
A
A
In
the
discussion
forum,
people
have
suggested
there
needs
to
be
updates
and
the
some
of
the
authors
have
agreed,
but
so
this
for
both
car
and
ct
may
expand
again.
That
will
be
the
basis
of
it.
Now
the
current
ct
document.
This
is
the
text
we
said
it
needed
to
handle
a
larger
discussion.
What's
it
for
color
impact
error,
filtering
jeff
is
started
with
interoperability
procedures.
A
So
that's
all
the
expectation,
if
you
feel
some
of
these
things
aren't,
aren't
there
pick
it
up
and
send
it
to
the
list,
send
it
to
the
chairs
we're
moving
at
this
very
carefully
step
by
step,
we're
moving
into
github
simply
so
we
have
an
issues
tracker,
that's
common
and
open,
because
what
I
found
after
going
to
the
list,
we
sort
of
really
did
need
to
have
an
issues
tracker
to
get
this
through
quickly.
Other
working
groups
have
found
that
to
be
successful.
A
F
F
F
In
this.
In
this
case,
we
we
may,
we
must
best,
delete
different
services
locators
for
different
intent.
The
locators
are
we
recorded
as
a
for
locators.
It's
a
it's.
A
split
from
the
basic
locator,
the
srv6
service
seeds,
with
specific
intent
are
located
using
the
corresponding
colorful
locators
and
as
a
covering
prefix
for,
for
example,
the
yellow
one
and
color
for
locator.
One
maybe
means
low
latency.
The
blue
one
color
for
locator
two,
maybe
means
the
high
bandwidth.
F
Oh,
why
ipv6
colorful
prefix
are
advertised
as
bdp
ipv6,
unicast,
roads,
safety,
rfe
and
safety
means
two
and
one
because
there
is
also
a
ipv6
routing,
ipv6
router,
but
for
this
router
the
color
color
extender
community
color
ec
should
be
carried
in
the
road.
It
will
describe
the
intender
for
this
ipv6
route.
F
On
the
domain
border
nodes,
the
color
you
see,
may
be
changed
to
the
color
in
the
local
domain
and
the
next
hop
will
be
set
to
itself.
It's
similar
light
to
bplu
srv6
the
service
rules
and
are
advertised
using
the
mechanism
defined
in
rfc
9252
for
inter
interac
operation
c
is
used.
So
the
net
hope
for
the
srf6
service
road
is
kept
changed
since
the
intent
of
the
service
is
embedded
in
the
srv6
service
seed.
F
F
This
is
the
procedure
about
the
path
resolution.
Well,
now
the
receiver
cp
colorful
prefix
router.
It
will
should
resolve
it
into
an
intel
intro
to
make
color
aware
paths
based
on
the
top
over.
Let's
see
in
the
next
hop
and
see
the
color,
the
inter
domain
color
aware
path
can
be
one
of
the
following
types:
maybe
srv6
policy
as
amperes
policy,
rcbt
and
other
tunnel
types
it
will
each
tunnel
can
let
the
srv6
the
ipv6
road
to
the
network
is
okay.
F
For
the
service
router,
there
are
76th
service
seed
carried
in
the
srv6
service.
Road
is
used
for
water
iteration,
the
sr6
service
seed
matches
to
a
cpr
road
based
on
ip
longest
match
matching
lookup
an
intro
to
main
in
intended
aware
path
which
the
cpr
route
is
resolved
to
is
used,
is
used
to
encapsulate
and
afford
the
sr6
service
traffic.
F
This
is
an
example:
when
the
p3
will
advertise
the
loads
to
p1
and
across
three
iss,
the
pe
will
assign
the
seed
for
different
services
such
as
here
show
the
vpn
one
to
vpn
file.
We
can
one
two
three
may
use
the
yellow
one
color
color,
the
locator
one
under
the
vpn
four
and
the
c5.
Maybe
you'll
use
the
blue,
the
color
locator
together
the
cpr
row.
So
this
is
the
down
here.
There
are
maybe
two
cpi
colored
locator
prefix.
That
means
the
color,
the
color
locator
one
calculator.
F
Two,
these
two
rows
were
advertised
and
also
we
are
installed
in
the
fifth.
The
route
will
advertise
to
espr31
with
the
color
three
c
three
with
the
color
c3c31,
and
this
also
will
advertise
to
asbr
23
and
send
nethop
to
the
sbr31
and
also
in
the
cat
with
make
up
the
color
with
the
color
331
sbr2222
sbr23
may
advertise
the
ipv6
road
to
spr21
in
this.
B
F
In
s
vr
11,
it
may
be
advertised
the
color,
you
say
the
the
accuracy
reloads
to
p1,
but
change
the
color
to
color.
You
say
to
c
c
11,
because
s1
c11
maybe
means
the
latter
in
terms
of
low
latency
for
p1
p1.
It
will
first
first
install
the
c
locator
one,
the
zero
color
locator
one,
it's
the
then
hole
is
spr
11
and
its
color
is
c11.
F
F
Then
the
then
the
service
router
from
p3
advertised
to
p1
will
capture
the
network
for
is
p3,
but
also
it
will
advertise
the
roads
with
a
vpn
seed.
That
means
the
vpn
one
seed.
The
seed
is
corresponding
to
the
colored
locator
y.
As
the
p1
the
service
rose,
we
will
use
the
colored
use
between
ones
seed
to
to
to
blow
the
red
resolve
and
then
maybe
then
here
it
will
match
matching
to
the
color.
The
locator
work,
because
the
between
one
seed
is
a
long
longest
match
to
the
color
locator
one.
F
F
And
also
when
the
package
arrived
at
spi-11,
the
local,
the
inter-domain
tunnel
may
be
reduce
the
butter
and
unless
the
original
test
address
is
also
between
one
seed
now,
it's
also
here
it
also
maybe
look
after
the
fib,
maybe
matching
the
c
color
locator
one
and
also
use
the
this
tunnel.
It's
a
it's
a
tunnel
path
to
arrive,
folding
to
the
sbr21
and
all
by
all
axis,
and
then
the
pector
will
finally
arrived
at
the
p3
in
this.
F
This
is
the
benefits
of
the
color
of
prefix
routine.
For
this,
because
we
are
basically
based
on
the
existing
bgp
mechanism.
No
new
protocol
extension
is
needed.
We
may
use
only
the
ipv6
unicast
road
and
the
original
color
extent
community,
and
this
is
a
backward
compatible.
It
is
very
easy
to
deploy
increments
in
network
domains
which
which
we
don't
support
us
color,
prefix
routing,
but
based
on,
if
you
prefix
the
longest
match.
F
Srv6
service
are
also
steering
to
intro
to
main
best
effort
pass
and,
and
also
we
may
support
the
different
types
of
intro
to
make
color
where
paths
srv6
is
only
required
on
the
pe
node.
So
for
the
in
for
the
inter,
inter
interim
one
main
mps
or
sr
second
and
sr6
and
the
other
another
tunnel
is
okay
and
it's
more.
If
efficient
data
plan
in
campus
solution
for
mpos
data
plan,
the
the
ppiu
label
is
also
not
for
us,
I'm
sorry
for
npr's
data
plan.
It
may
be
also.
F
F
Next
step:
well,
we
are
welcome
comments
and
feedbacks,
and
also
we
are
progress.
This
document,
as
a
lightweight
until
to
make
intent-based
routing
mechanisms
for
76
service
and
also
some
other
design,
may
be
integrated
with
other
internet-based
routing
mechanisms
for
better
support
for
srsr6
based
service
and
efficient
data
plan
encapsulation.
D
Yeah,
so
I
I
would
say
this
is
like
generalize:
you
can
generalize
this,
as
so
the
two
ways
of
of
advertising
the
different
intents
from
the
egress
pe
either
you
use
different
low
backs
where
each
loopback
pertains
to
a
color
or
you
use
the
same
loopback
and
then
use
the
color
community.
That's
a
combination,
the
color,
comma
endpoint.
So
in
this
case,
because
on
the
service
and
service
layer,
we
use
multiple
endpoints
and
each
endpoint
pertains
to
a
color
and
in
the
transport
layer.
D
What
you're
doing
here
is
avoiding
the
need
of
a
new
savvy,
and
that
can
be
done.
I
would
like
to
point
out
that
that
can
be
done
not
only
for
srv6,
but
also
for
lu
with
multiple
loopbacks
or
with
gre
tunnels,
with
multiple
or
with
udp
tunnels.
So
in
those
cases
you
will
have
like
mpls
over
udp
or
mkillers
over
gre
kind
of
scenarios.
D
D
F
B
A
F
A
Since
the
well
I'll
send
some
questions
to
you
via
email,
it
may
be
difficult
to
hear.
I
think
that's
what
you're
saying
kali
raj.
If
you
have
your
questions,
you
could
send
them
to
the
list
or
the
comments
to
the
list,
so
huevo
could
pick
them
up.
I
may
move
all
of
that
to
a
separate
thread,
I'm
being
very
careful
to
try
to
track
all
comments
related
to
car
ct
and
color
technology.
A
D
A
Good,
if
you
had
questions
for
weibo
or
suggestions,
that
would
be
good
as
well,
and
we
will
probably
start
a
mail
thread
on
this
discussion
as
well.
Folks,
we
are,
the
chairs
are,
are
based
on
the
working
groups,
feedback
trying
to
very
much
help
or
nurture
this.
Hopefully,
it's
nurture
for
all
of
you.
Are
there
more
questions.
D
D
A
F
B
Yeah
yeah-
I
just
want
to
reply
to
congress
comment-
is
with
this
solution.
Srv6
is
only
required
for
the
service
layer,
which
is
we
need.
I
service,
6
capable
keys
at
the
two
end
points
for
the
transit
domain
tunnels
you
can
use
either
at
every
six
or
other
npr
space.
The
tunnels,
like
I
said,
mpls
or
the
rsvpt
based
tunnels.
All
this
can
be
supported
as
a
transport
layer.
D
B
For
the
transport
layer,
the
ipv6
unicast
will
be
used
to
cross
the
domains
and
the
transient
nodes
does
not
need
to
trade
it,
as
our
I
services
said
just
like
ipvc
prefix
and
resolve
it
over
a
intro
domain,
colorware
path,
yeah.
That
is
the.
So
we
think
this
does
not
require
the
transit
domains
to
support
srv6.
B
D
B
D
B
D
B
B
A
C
I
got
to
spend
time
working
on
this
at
ietf,
because
I
was
one
of
the
people
that
you
know
came
a
little
bit
too
close
to
one
of
the
coveted
exposures
managed
to
not
get
infected
at
the
conference
itself
and
then
got
nailed
during
trying
to
get
home.
So
I
had
a
lot
of
time
to
think
about
things
in
my
hotel
room
just
for
context.
C
The
original
draft
that
I
had
started
writing
was
to
start
differentiating
the
different
routing
and
color
technologies,
and
you
know
the
diffract
name
partially
came
out
of
that,
but
it's
also
a
play
on
words.
That
diffraction
is
the
technology
used
with
a
prism
to
separate
colors,
so
it
has
no
deeper
meeting
than
that.
C
So
what
am
I
going
to
be
talking
about
today?
You
know
the
thing
that's
not
actually
mentioned
on
the
slide
is
this
is
not
at
this
current
point
in
time,
a
request
for
working
group
adoption.
This
is
just
some
thinking
and
if
the
procedures
are
helpful
now
the
working
group
can
choose
to
adopt
it
or
potentially
take
a
completely
different
attack,
we're
very
early
in
this
process.
So
please
spend
some
time
thinking
about
this
yourselves.
C
C
I'm
going
to
be
talking
about
mapping
of
hillary
keys,
because
that's
really
the
interesting
thing
that,
as
we've
sort
of
gone
through
six
months
worth
of
discussion
about
currency
team.
This
is
the
part
that
is
where
all
the
interesting
headaches
are
present
on
and
and
how
those
otherwise
keys
interact
with
where
the
color
is
inside
the
route.
C
So
I'll
spend
exactly
one
slide
talking
about
the
forwarding
behaviors.
The
draft
actually
has
a
lot
of
comments
about
how
stuff
actually
gets
remapped
from
one
to
another
and
basically
the
core
observations
that
both
documents
talk
about
three
basic
forming
behaviors
standard,
lu
style
label,
stacks
sr
style
label
index
and
srv6.
C
Now
ct
basically
says
we're
going
to
use
the
core
rfc
behaviors.
For
these
things,
just
like
lu
does
car
mostly
operates
in
its
draft
discussing
that
here
are
the
same
features:
here's
how
the
encoding
gets
carried
on
them
and
their
local
optimizations
to
try
to
do
better
packing
and
they
get
carried
along
in
the
non-key
portion
of
the
annual
rise.
C
So
for
each
of
the
proposals,
you
know
we
have
a
nlri
key,
that's
related
to
how
bgp
treats
it
for
announcement
and
route
comparison
purposes
in
car.
The
nlri
is
the
you
know
ip
prefix
for
the
endpoint
and
a
color,
that's
32
bits
and
in
ct
you
know
the
nri
key
is
a
route
distinguisher.
You
know
standard
l3,
vpn
style
route,
distinguisher
and
an
ip
prefix
endpoint.
C
C
So
sort
of
kicking
off
this
effort.
Now
we
have
to
sort
of
ask
ourselves
what
does
interoperability
mean
well
for
a
given
bhp
route
and
you
normally,
when
we
talk
about
bgp
in
a
4271
rfc
cents,
you
know
a
route
is
a
prefix,
that's
carried
in
nlri
paired
with
a
set
of
path
attributes
we
think
about.
You,
know,
sort
of
what
the
subtleties
mean
for
routes
with
colors.
We
sort
of
continue
these
discussions.
C
It's
basically
an
endpoint
with
a
color
for
a
specific
set
of
forwarding
behavior,
with
a
set
of
otherwise
uncoupled
path.
Attributes.
You
know
from
those
things,
and
you
know
for
a
given.
You
know
protocol
you
know.
Can
you
know
that
I
give
a
native
no
version
of
this
now,
whichever
side
you're
looking
at,
can
we
create
native
state
from
foreign
protocol
state?
C
And
if
we
do
so,
can
we
actually
have
consistent
route
selection
and
pass
them
around
well?
The
answer
appears
to
be
yes:
foreign
protocols
can
be
napped
into
the
native
protocol
and
a
thing
to
think
about
in
terms
of
how
these
routes
get
passed
around
is
that
receiving
a
foreign?
You
know
bgp
route.
C
You
know
and
turning
it
into
locally
a
native
route,
or
vice
versa,
is
effectively
the
same
type
of
polymorph
operation
that
we
see
with
our
vpn
technology
is
where
you
know,
maybe,
as
an
example,
we
receive
a
you
know:
standard
fe-1
safety,
one
ipv4
unicast,
you
know
route
in
the
ce
context
and
it
gets
turned
into
an
l3
vpn
unicast
route
in
the
php.
You
know
pe
core,
so
the
routes
get
created
pairwise
and
they
share
fate.
C
C
That
operational
context.
You
know
with
bgp
car
color
is
the
original
intent,
that's
what
they
want
to
carry
end
to
end
and
make
visible,
and
certainly
if
you
go
from
one
color
domain
to
another,
the
effective
color
may
move
around,
but
the
original
intent
is
still
the
color,
that's
in
the
nlri
and
very
similarly
for
ct.
Well,
it
doesn't
really
have
quite
the
same
original
intent,
color
wise
as
no
car
does
that's
not
the
construct.
C
The
ct
authors
have
chosen
to
use
they're
using
information
that
can
be
encoded
in
a
route
distinguisher,
which
gives
you
a
sense
of
origin
of
the
route,
and
you
know
that's
the
piece
that's
carried
across
bgp
through
the
protocol,
so
putting
it
sort
of
a
different
way.
You
know
it's,
the
nlr
keys
are
what
we're
talking
about.
The
intent
effectively
is.
What
we
have
is
the
native
thing
for
the
nri
key
and
it's
what
we
do.
C
C
I
just
want
to
make
sure
that
we
convey
the
high
level
details
today,
but
you
know
an
easy
example
is
what
happens
if
you
have
a
series
of
domains
that
are
adjacent
to
each
other
or
potentially
even
tie
into
each
other
so
rounds
that
passed?
You
know
from
ct1
to
car
1
to
ct2
to
car
2..
Lct
1
also
has
a
direct
connection
to
ct
2..
This
is
an
example
of
you
know
that
your
feature,
you
know
your
mapping.
C
C
So
what
bit
of
machinery
looks
like
it
can
be
usable
for
this
sort
of
thing,
and
there
are
three
specific
constructs
that
I've
come
up
with
through
this
initial
pass.
The
first
one
is
in
a
ct
context:
lct
carries
a
route
distinguisher
as
part
of
its
format.
A
route
distinguisher
has
enough
space
and
it
to
actually
carry
a
32-bit
color.
C
C
C
One
is
to
actually
encode
the
classful.
You
know
transports
original
rd.
Now,
that's
present
in
the
route.
So
that's
basically
the
tunnel
for
the
rd
in-car
and
now
ct
doesn't
really
have
a
color-wise
original
intent
like
car.
Does,
let's
allow
the
transform
on
a
hi-hat
basis,
but
when
you
have
domains
of
car
that
you
know
may
be
disconnected
and
are
bridging
you
know
one
or
more
ct
domains.
C
It's
important
that
when
the
route
you
know
enters
the
c2
domain,
sorry
enters
the
car
domain
and
exits
that
within
the
car
domain
it
maintains
a
consistent
nlri.
You
know
key
for
the
end-to-end
process,
so
we
end
up
with
a
original
intent
in
terms
of
the
color
that
was
carried
with
the
ct
route,
the
first
time.
It's
transformed,
and
you
know,
every
time
it
crosses
into
a
car
domain.
That's
the
one
that
keeps
so
core
observation
here
this.
C
This
is
the
state
that
needs
to
be
used
for
doing
the
interop,
especially
the
extended
communities.
Nope,
that's
one
option:
you
know
it
could
be
used
as
in
a
different
format.
It
could
go
into
a
new
path,
attribute
sort
of
like
the
address
set.
For
you
know
the
tunneling
of
ibgp
attributes
for
vpns.
C
Is
this
machinery
you
know
complex?
Well,
probably
not.
This
is
a
small
set
of
transformation
stuff
that
this
is
going
to
be
run
by
the
software
and
not
an
operator.
So
these
things
are
not
expected
to
be
part
of
this
policy,
although
realistically
you
could
probably
implement
that
as
an
initial
hack,
if
you
felt
like
doing
so.
C
C
If
we
don't
have
that
original
intent
extended
community,
then
we're
going
to
add
one.
But
if
we
had
one
you
know
we
keep
it
again.
The
idea
is
that
within
a
car
domain,
we're
going
to
keep
a
consistent
nlri
key
of
the
endpoint
plus
that
original
color,
you
know,
which
happens
to
be
coming
from
no
ct's.
No
first.
C
You
clean
up
the
communities
that
are
not
relevant
to
the
proposal.
In
question,
so
in
this
case
we
get
rid
of
the
transport
class
inside
of
our
car
route
and
the
mapping
is,
you
know,
very
similar
and
goes
the
other
direction
ct
routes
rd
is
set
to
the
one
that
was
titled.
You
know
from
the
original
rd
you
know
the
transport
class
is
set
now
to
the
car
routes,
effective
color.
Now
this
is
a
detail
that
was
off
in
the
internet
draft
realizes
making
the
slides.
This
is
because
you
know
within
a
car
context.
C
Obviously
routes
can
be
passed
around
and
you
know
pass
potentially
from
one
color
domain
to
another
and
we,
you
know
ct
is
going
to
want
to
actually
know
what
that
effective,
color
is
yeah
and
the
original
intent
is
just
simply
preserved.
The
only
reason
for
it
is
that
if
the
route
having
now
become
ct
again
passes
into
another
car
domain,
you
know
we'll
end
up
with
the
same
car
nlri.
You
know
for
this
route
ended.
C
The
ct
routes
route
distinguisher
gets
created
into
this
new
rd
color
new
mechanism
we
were
discussing,
and
you
know
that
preserves
the
original
intent
and
the
transport
class
just
sets
the
routes
effective
color,
and
then
we
clean
up
the
lcm.
If
that
happened,
to
have
been
present,
this
part
of
the
car
route.
C
And
very
similarly,
the
unmapping
procedure
you
know
very
simply,
is
that
we
have
a
car
route
and
we
have
a
map
route.
You
know
the
car's
lry
is
set
from
the
rd
color,
you
know,
that's
been
carried
around
the
color
value
in
the
rd.
Color
is
different
than
the
transport
color
in
the
ct
route
that
we're
unmapping.
C
C
So
the
core
purpose
for
these
procedures
is
to
make
sure
that
any
time
we've
gone
from
one
domain
to
another,
potentially
multiple
times
again
picture
of
the
simple
line
topology
well,
the
line,
topology
is
very
boring.
The
transforms
you
know
are
somewhat
obvious,
but
if
you
have
connections
between
those
lines
where
you
receive
the
native
routes
and
along
with
the
mapped
routes
now
being
transformed,
we
need
to
make
sure
that
the
routes
maintain
a
consistent
and
lower
form
for
whatever
is
native
for
that
specific
pgp
router.
C
If
that's
done,
then
we're
going
to
end
up.
You
know
for
that
native
router,
some
sense
of
what
we're
picking
as
the
specific
encoding
that
is
native
for
the
domain,
and
this
is
where
all
of
our
route
selection
is
going
to
get
done.
You
can
run
our
best
path
there
and
you
know
just
like
each
of
the
proposals
talk
about
you
know.
Both
of
them
effectively
can
construct
the
same
route
resolution
state.
C
C
Now
the
details
for
that
are
intentionally
not
described,
because
you
know
how
that
looks
in
a
specific
implementation
will
probably
vary
considerably
depending
on
how
your
route
injection
works.
But
again
you
know
the
the
semantic
is
somewhat
similar
to
what
happens
when
you
have
vpn
routes.
You
know
you
have
one
route
that
shares
rates
with
another
one,
and
you
know
it
can
cause
a
redistribution
as
part
of
that
transform
process.
C
Now,
how
close
are
we
to
a
solution?
That's
basically,
you
know
a
single
merged
solution
and
you
know
clearly
these
observations
hold
based
on
current
observations,
but
if
you
know
other
details
develop
that
should
show
that
the
procedures,
you
know
can't
handle
things
well,
maybe
this
is
not
quite
as
close
to
being
a
single
solution,
as
we
were
hoping,
but
set
of
observations
are
that
once
you
have
an
rd
color
route
distinction
format,
you'd
be
able
to
carry
original
intense's
color.
Well,
this
means
that
you
can
use
an
rd.
C
This
means
that
even
in
sort
of
car
format,
instead
of
endpoint
and
color
endpoint
plus
rd,
you
know
it
just
simply
changes
your
operational
idea
of
what
a
android
key
looks
like
in
a
car-like
context
or
even
a
ct
like
context.
You
know,
the
real
question
is:
where
is
your
color?
Well,
this
means
that
if
you
have
an
rd
rd,
color
style
route
distinguisher,
if
the
effective
color
is
the
same
as
the
one
that's
inside
that
rd
now
effectively
what
car
currently
does
you
don't
need
an
extended
community?
C
You
know
car
when
it's
doing
its
remapping
from
one
domain
to
another
uses
lcm,
and
you
know
the
transport
class
potentially
becomes
so
optional
in
that
circumstance
as
well,
so
the
the
real
differentiator.
If
we
go
with
a
somewhat
combined,
you
know
rd
endpoint,
for
both
proposals
is
what
do
we
do
about
the
forwarding
behavior
encoders.
C
C
C
C
So
maybe
the
interesting
questions
long
term
is
no.
What
do
we
want
to
do
in
terms
of
you
know
this
type
of
encoding?
This
was
one
of
the
I
believe
intense
of
the
car
authors
as
part
of
making
this
proposal
is.
Maybe
this
is
a
good
generic
way
for
us
to
carry
these
sorts
of
forwarding
behaviors
forward.
C
C
Over
the
years
about,
maybe
it's
time
to
update
the
bgp
update
format
itself,
you
know
we've
been
living
with
a
set
of
path,
attributes
with
the
number
of
vandal
orion
side
of
it
for
years.
You
know,
maybe
it's
time
to
further
subdivide
it
into
something
that
potentially
can
carry
per
annulari
type
state
without
necessarily
having
the
nlri
itself.
The
ntlv
format.
C
One
possible
example
of
such
an
encoding
is
there's
a
draft
in
bmp
for
carrying
tlvs
and
that
they
do
this
for
exactly
the
same
sort
of
reason
that
the
car
proposal
has
at
least
this
part
of
what
I
consider
it's
a
perceived
intent
of
having
better
packing.
You
don't
want
to
disturb
the
actual
message
format
in
the
bmp
stuff,
but
annotations
per
mlri
is
still
a
useful
thing,
and
this
is
a
way
that
they
have
figured
out
how
to
preserve.
Basically,
it
encapsulated
php
update
and
allow
for
bmp
specific
notations.
C
C
Certainly
I
I
have
no
strong
opinions
about
the
ordering
on
some
of
these
things.
English
topic
comment.
Type
syntax,
you
know,
makes
it
a
tricky
sort
of
thing,
and
certainly
I'm
willing
to
you
know
consider
whatever
is
necessary
again.
This
is
some
initial
thinking.
It's
not
you
know
the
formal
proposal
at
this
point
in
time
and
perhaps
people
have
a
different
way
they'd
like
to
look
at
it.
So
certainly
I
shouldn't
we
can
take
a
look
at
you
know.
Maybe
changing
the
syntax
of
this
a
little
bit
robert
asks.
C
C
So,
as
I
made
a
sort
of
casual
mention
inside
the
slide
that
discusses
the
sample
topology,
it's
my
belief
that
this
works
perfectly
fine
in
a
single
domain,
a
single
as
potentially
cross-route
reflector
boundaries
as
an
example
where
some
of
the
devices
know
speak
ct,
some
of
them
speak
car.
I
believe
that
the
route
mapping
procedures
cleanly
accommodate
things-
and
I
agree
with
you
robert.
C
This-
is
probably
the
one
scenario
that
maybe
has
some
tricky
semantics
to
it,
and
it's
gonna
probably
take
a
little
bit
more
failure
analysis
to
see
if
there's
any
edge
cases
that
I
hadn't
accounted
for.
But
my
sort
of
core
observation
is
that
once
remapping's
done
route
selection
can
happen
consistently
within.
You
know,
certainly
the
side
of
the
as
that
speaks
one
proposal.
C
What
I
think
is
the
relevant
component
for
the
analysis,
and
certainly
this
is
a
place
where
the
working
group
can
help
is.
If
we
do
have
these
sort
of
split
domains,
could
we
ever
end
up
in
a
situation
where
the
generated
route
resolution
state,
because
that's
the
end
goal
that
we're
desiring
out
of
each
of
these
mechanisms?
C
You
know,
is
there
a
possibility,
it's
not
exactly
identical
and
there's
at
least
one
of
the
threads
inside
of
the
form
3
stuff
raised.
I
think
originally
by
nats
coloring,
some
covering
a
car
scenario
where
lcms
are
used
and
may
not
consistently
resolve
that
exact
same
type
of
analysis
needs
to
happen
here
as
well.
D
D
D
It
mentions
that
the
resolution
procedures
are
similar
for
car
and
cd.
I
think,
if
you
look
at
the
text
that
is
specified
in
the
draft
today,
they
are
not
similar.
So
ct
clearly
specifies
that
the
end
points
need
to
be
segregated
into
color
package,
and
then
resolution
happens
on
those
and-
and
I
think
that
is
not
clearly
specified
or
under
specified
in
the
car
drought
to
say
the
least,
and
then
the
next
comment
is
about
the
ctoi
in
slide
11
to
14..
D
Now
what
the
effective
color
you
want
to
propagate
into
a
mapping
scenario
is
what
is
the
effective
color
of
my
adjacent
domain
and
what
is
the
agreement
of
what
that
color
means?
What
is
the
intended
maps
doing
my
local
domain?
I
think
what
the
original
color
was,
what
the
original
intent
was
when
the
routers
originated.
That
is
less
important,
because
what
is
more
important
is
the
transformations
it
has
gone
through
and
when
the
route
is
coming
into
my
domain
from
the
adjacent
domain.
What
is
its
color
and
what
are
the
intended
maps
too?
D
So
if
you
look
at
the
point
slides
11
to
14,
I
don't
see
ctoa
being
used
any
of
the
procedures.
So
that's
one
thing
and
the
flip
bullet
in
slide
11.
It
deletes
all
the
transport
cluster
targets.
That
kind
of
procedure
seems
a
little
dicey
to
me.
So
overall,
it
looks
like
these
procedures.
Maybe
we
can
make
it
work
for
some
simple
use
cases,
but
when
you
have
more
involved
scenarios
it
may
be
really
difficult
to
operate
and
manage
and
I'll
leave
that
for
the
operators
to
comment
on.
Thank
you.
C
So
the
simplified
procedures,
as
you
and
I
discussed-
certainly
that's
something
that
somebody
can
write
no
stuff
down
as
text
I'm
happy
to
take.
You
know
that
text
in
there
and
I'm
certainly
willing
to
try
taking
a
swing
at
it
myself.
That
said,
you
know
it's
less
interop
and
more
just
simply
the
fact
that
we
give
up
and
we're
devolving
back
to
an
existing
mechanism-
and
you
know
basically,
both
the
ct
and
car
documents
discuss
that
in
some
detail.
That's
why
I
left
it
out
of
the
first
round
of
this.
C
C
There
is
a
long
set
of
threads
where
we
work
through
what
is
the
effective
behavior
of
each
of
the
proposals,
and
I
absolutely
believe
you
in
terms
of
the
behavior
for
no
ct
is
my
belief
based
on
that
set
of
discussions,
that
car
shares
the
same
semantic,
even
though
they
think
about
it
differently,
and
I
will
dig
out
the
necessary
thread
from
there
and
you
know.
Certainly
you
know
as
part
of
this.
C
So
ctoi,
if
it
doesn't
look
like
it's
needed
any
slides,
I
have
a
transcription
error
for
my
draft,
but
the
desired
behavior.
Out
of
that
is
that,
when
we're
moving
from
a
ct
route,
let's
say
that
we
have
a
ct
route
going
to
you
know
destination.
You
know
10
8,
with
color
100
in
the
transport
class
and
we
move
into
a
car
community
car
context
o'carwood
normally
if
it
originated.
That
is
ten
slash.
Eight
with
color.
You
know,
one
hundred
is
the
other
high
key.
C
C
You
know
the
effective
color
as
it
exited
now
this
remapping
procedures,
but
if
we
entered
a
car
domain
again,
it's
important
that
you
end
up
with
the
same
current
nlri
as
you
would
have
had
in
that
first
transform
because
you
want
them
to
be
comparable
in
case.
You
know
the
you
know,
two
card
domains
have
one
connection
to
each
other
and
a
different
connection
through
the
tunnel,
no
ct
domain.
C
C
C
D
C
C
This
seems
like
a
lot
of
things
to
do
to
a
set
of
routes,
but
these
are
automated
things
for
if
you
actually
want
these
to
be
you
know,
if
you
want
the
intense
to
be
carried
and-
and
you
know
the
you
know
enter
a
s
options,
you're
sort
of
giving
up
on
carrying
you
know
end
to
end
color
intent
or
at
the
very
least
you
may
have
to
go
with.
You
know
multiple.
You
know
physical
sessions
between
various
as's
to
carry
the
individual
intents.
C
Okay,
so
robert
asks
in
chat
has
to
list
about
two
more
points:
no
question
a:
how
do
you
handle
incremental
additional
functionality
to
either
car
and
ct
once
we're?
Interop
is
running.
That's
a
good
question.
We
don't
know
because
this
is
a
completely
wide
open,
theoretical
thing.
The
procedures
may
need
to
change.
C
Certainly
this
is
one
of
the
reasons
that
people
are
trying
to,
or
just
to
go
to
some
sort
of
merge
solution.
That's
one
of
the
reasons
I
made
the
observation
that
a
wider
field
to
carry
the
color
you
know
allows
both
the
ct
and
car
operational
context
to
be
used,
and
maybe
the
working
group
will
take
that
up
as
a
point
for
maybe
a
merged
solution.
C
Robert
asks
as
part
of
his
question
b.
When
there
is
discussion
there
is
a
lot
of
indications
for
a
single
solution,
but
we
still
need
to
drop.
If
there's
a
single
solution
adopted.
No,
probably
not
the
challenge
that
we
have.
Is
that
the
longer
we
let
the
proposals
continue
running
even
an
interop
solution
effectively
becomes
a
third
protocol
and
you
know
things
just
get.
You
know
combinatorically
messier,.
C
Okay,
so
this
is
all
that
I
had
again.
This
is
just
some
initial
thinking
and
I
think
what
this
sort
of
shows
is
that,
as
things
are
currently
defined
for
much
of
the
defined
scenarios,
the
technologies
do
map
fairly
nicely
between
each
other
and
that,
if
we
actually
wanted
a
you
know
ability
to
carry
each
other's
routes.
You
know,
through
a
mapping
procedure
that
is
currently
possible.
C
Robert
points
out
that
this
may
become
more
difficult,
as
the
features
are
maintained
and,
finally
that
there
may
be
some
option
in
terms
of
at
least
the
lri
keys
to
have
a
converged
solution,
and
the
working
group
would
have
to
decide
what
it
wants
to
do
about
carrying
the
forwarding
you
know
state,
so
there
there
is
potentially
some
option
for
a
merged
solution.
The
written
group
to
set
this
aside-
if
that's
what
it
wants
to
work
on,
that's
it
for
me,
sue.
B
A
A
If
you
were
going
to
sort
of
settle
things
out,
make
sure
we,
the
chairs,
understand
what
happened
this
week
and
then
friday,
when
we
have
our
normal
chat,
cheers
meeting
or
the
next
time
we
can
meet.
This
is
a
holiday
us
week.
We
will
send
out
a
question
about
this.
If
the
bird
solution
looks
like
something
the
idr
should
work
on
again,
because
we
did
have
as
robert
put
out
a
call
for
it,
but
no
consistency
on
whether
car
or
ct
could
be
chosen.
So
again
at
each
step.
A
The
chairs
are
trying
to
find
out
what
the
working
group
input
on
the
only
other
thing
is.
I
want
to
thank
the
car,
the
editors
for
the
car
draft
dj
and
swadesh
for
their
continued
hard
work
and
of
the
ct
draft
kali,
raj
and
nats.
We
appreciate
all
your
active
work
and
we
just
appreciate
the
passionate
interplay
in
the
working
group
with
that
we'll
cut
it
off
and
tony
lee.
We
did
make
it
in
about
two
hours.