►
From YouTube: IETF-IDR-20230925-1400
Description
IDR interim meeting session
2023/09/25 1400
https://datatracker.ietf.org/group/idr/meetings/
B
D
C
C
This
is
September
25th,
we're
hoping
that
other
people
will
join
us
I'm
going
to
go
through
the
chair
slide
to
first
use
the
note.
Well,
please
make
sure
you
read
it
if
you've
not
read
it,
it's
on
the
slides,
if
you'd
like
a
longer
look
at
it,
but
this
ITF
when
you
participate
it
implies.
You
agree
the
processes,
ITF
processes
and
policies.
C
C
C
C
We,
the
agenda
bashing,
is
we'll
probably
run
through
the
whole
time
John's
going
to
give
us
a
discussion
about
the
entropy
11.
We're
gonna
do
that
before
a
second
working
group
last
call
and
Karen
Jeff
I
will
ask
you
to
take
notes
while
I
disappear,
John
I
believe
Jeff.
Can
you
monitor
John's,
call
and
start
the
dance
presentation
for
me.
C
C
D
D
All
right,
good
day
everybody,
so
we
had
a
working
group
Last
Call
on
this
draft,
and
she
asked
me
to
give
a
roll-up
of
what
happened
during
the
working
group
last
call.
We
had
some
fairly
significant
reviews
come
in
after
the
end
of
the
working
group
last
call,
which
thank
you
very
much
for
those
I
would
much
rather
have
a
late
review
than
no
review,
so
just
ever
so
briefly
to
set
the
stage
I
I
don't
want
to
give
a
tutorial
on
this.
D
D
And
the
reason
is
basically
so
that
the
the
receiver
can
know
that
that
the
forwarding
path
is
actually
what
the
attribute
says
it
is.
And
finally,
there's
this
tlb
called
ELC
V3
intricate
label
capability,
it's
defined
to
be
carried
in
there.
It's
an
item.
Potent
data
list
attribute
that
just
says
the
egress
can
support
entropy
label
processing.
D
The
title
was
misleading.
We
changed
the
title.
The
file
name
was
misleading
I'm.
Sorry,
the
file
name
is
still
misleading.
It
seemed
worse
to
change
it
than
to
keep
it
the
same,
and
there
was
no
real
consensus
in
the
discussion
for
one
way
or
the
other
section.
2.3
was
too
insistent
that
you
must
not
influence
ipgp
route
selection
and
the
resolution
on
that
was
to
say
you
know,
as
usual,
in
bgp
you're
allowed
to
do
anything.
D
D
There
was
a
issue
that
the
messaging
or
the
language
in
section
2.4
about
message.
Malformation
was
sloppy
and
yes,
it
was
sloppy.
Thank
you
for
the
improved
language.
There
was
a
desire
for
a
private
use.
Range
resolution
was
sure.
Why
not,
and
then
we
also
put
in
some
new
explanatory
text,
to
try
to
clear
up
things
that
seemed
to
trip
people
up
during
the
working
group
last
call,
even
if
they
wasn't
specifically
requested
and
that
got
published
as
version
10.
D
D
D
My
answer
to
that
anyway,
is
we
got
to
get
this
done?
People
actually
need
this
thing
in
their
Networks,
so
actually
because
this
is
a
an
open
question.
I'll
pause
here
to
see
if
anyone
wants
to
discuss
that
or
or
maybe
I'll
keep
going,
but
I'll
point
out
that
this
is
a
you
know:
Point,
that's
open
for
discussion,
but
my
my
proposed
resolution
is,
you
know
your
points
noted,
but
but
I
think
that
we
need
to
have
a
solution
that
is
able
to
be
deployed
now.
D
Three
had
a
long
review
from
ketan.
Thank
you
very
much
for
that
I
think
most
of
it
we've
already
closed
an
email,
so
the
he
points
out
that
the
labeled
mlri
language
introduced
in
tan
is
still
imprecise
and
like
fine,
we'll
work
on
a
rewrite
and
there's
it's
still
pending,
but
I
I,
don't
think
we'll
have
trouble
closing
on
that,
the
there's
a
section
in
2.1,
that's
kind
of
introductory
material
about
potentially
useful
material,
it's
information,
etc,
etc,
and
Katana
has
sent
text
for
that.
D
Do
we
need
to
do
then?
Okay,
so
this?
This
is
this
one
is
a
little
less
easily
taken
care
of
so
about
non-selected
routes.
Do
we
need
to
do
anything
so
for
non-multipath
routes?
We
agreed
text
as
written
is
just
fine,
but
then
Caitlin
said
what
about
multipath
routes
and
I
said:
oh
snap,
multipath
routes
are
just
gnarling
and
as
far
as
I
can
tell
in
our
documents
that
we've
never
actually
standardized
what
the
heck
to
do
about
multi-path
threats.
F
D
G
D
D
I
I
guess
we
need
some
aggregation
language
in
there
and
because
aggregation
is
tricky
in
vexing
and
I
want
to
take
some
time
to
do
it
right,
I'm,
perfectly
happy
to
you,
know:
Overjoyed.
In
fact,
you
accept
contributions.
If
anybody
has
ideas
about
how
we
should
spec
it,
otherwise
I'll
hopefully
find
some
time
later
this
week
to
work
on
it.
That's
that's
what
I've
got
to
say.
Okay
time,
please
go.
G
Yeah,
so
I
just
wanted
to
say
that
you
know
if
the
router
is
programming
multipath
and
if
one
of
those
path
is
not
does
not
carry
or
is
not
El
capable
or
does
not
carry
that
indication,
then,
basically
what
you
said
in
the
email
we
should
have.
The
text
must
not
propagate
the
ELC
V3
further,
so
I
mean
that
would
be
the
obvious
thing,
but
also
indication
for
further
on
new
or
NHC
capabilities
to
cover
this
aspect,
so
that
I
think
that
should
addressed
this
comment.
D
D
D
So
then
yeah
this
could
be
a
longer
or
a
shorter
conversation.
I
think
it's
likely
to
be
shorter
in
part
because
of
some
of
the
unicast
email
I've
gotten.
So
the
the
issue
that
ketan
brought
up
is
that
appendix
a
is
problematic
and
I'll.
Just
quote
him.
The
issue
with
this
appendix
getting
into
an
RFC
is
that
vendors
may
be
asked
to
implement
this
transition
mechanism
and
that
that
flies
against
what
I
believe
was
a
consensus
to
Simply
deprecate
and
discard
attribute
28.,
so
I
agree.
That
was
the
consensus.
D
My
Counterpoint
is
that
you
know
yes,
exactly
vendors
may
be
asked
to
implement
a
transition
mechanism
and
I
believe
that
will
you
know
happen
regardless
of
what
we
say
or
don't
say
in
an
RFC,
so
I
I
think
that
it's
a
service
to
the
community
to
say
you
know
if
you're
asked
to
implement
it,
here's
some
hints
about
how
to
do
so.
Now.
D
You
know
pulled
on
this
because,
anyway,
the
the
options
are
either
we
keep
the
appendix
as
written,
which
is
kind
of
my
preference,
but,
like
I
said
I
think
I
may
be
in
the
rough
on
this
point
where
we
can
remove
the
appendix
and
add
this,
this
other
bullet
that
I
proposed
in
email,
so
I'm,
pretty
close
to
calling
myself
in
the
rough
I
I.
Think
it's
a
mistake,
but
not
a
huge
mistake.
D
B
D
D
D
H
D
B
Okay
and
and
I
have
one
quick
comment:
I
know
you
have
listed,
who
are
the
editors
and
who
are
the
authors?
I
just
don't
know,
will
go
back
as
the
chairs
and
discuss
about
this.
Also
along
with
you,
but
I'm
assuming
remaining
offers
are
okay.
If
editors
just
get
to
stay
on
the
front
page
right
because
they're
more
than
five,
it
seems
like.
D
I
Okay,
thank
you.
John
I
know,
John
has
a
quick
exit
here,
so
if
you
would
send
him
a
chat
or
send
him
an
email,
if
you
have
a
problem
but
we're
going
to
go
on
with
the
rest
of
the
agenda,
I
intend
to
start
the
working
group.
The
second
working
group,
Last
Call,
on
this
new
text,
pretty
shortly
after
John
finishes
and
all
the
discussion
closes
down
because
I
think
we're
it'll
help.
People
keep
the
context.
I
I
I
I
Okay,
so
in
in
my
discussion,
we've
walked
through
in
the
working
group.
Last
call
we
did
around
ITF,
we
had
a
one-log
mail
thread,
but
inside
of
it
we
had
questions
about
motivation
for
the
IP
prefix.
Why
was
the
type
2
NRI
prefix
added
and
that's
one
of
the
real
keys
for
why
I
wanted
to
make
sure?
We
clearly
discussed
that
questions
about
the
clarity
for
the
type
of
support
in
sections
we
had
a
security
concern.
I
I
I've
I
kept
this
in,
because
we
really
need
to
make
sure
that
as
we're
going
forward,
we
consider
the
security
for
the
intent
issues.
I'm,
not
sure
there
was
a
lack
of
clarity
in
procedures
in
sections
eight
through
ten,
there
was
a
relationship
about
multiple
drafts.
I
want
to
make
sure
that
we
understand
any
antecedents.
That
means
the
things
that
came
before
this
draft
things
that
go
there
and
correctly
note
them.
There's
the
car
in
Safi
and
the
car
VPN
Safi.
I
E
Yeah
I
think
this
is
the
appropriate
place
to
raise
the
point.
So
one
of
the
other
things
that
we
had
also
talked
about
as
well
is
that
the
type
2
is
part
of
the
discussion
is
apparently
moving
is
a
item
that
is
not
specifically
color
aware
in
the
original
sense
of
the
draft
that
was
adopted,
so
there's
a
chance
that
this
work
is
basically
out
of
Charter
for
this
specific
document
so
well,
the
work
itself
may
be
useful,
so.
I
We're
gonna
let
the
authors
answer
that
question
themselves,
as
it
hasn't
been
in
I've,
had
discussions
with
them
where
they
have
suggested
it's
a
tight
binding
with
color,
so
I'm
gonna.
Let
DJ
speak
to
that
point
and
I'm
sure,
swadesh
and
Akira
can
help
him
with
that,
and
we
need
to
talk
about
how
the
car
safi's
support
the
service
families
and
which
service
families
they
support.
I
So
the
other
thing
that
we
I
did
is
I
sent
out
early
directorate
reviews
and
we've
been
very
thrilled
that
we
got
the
decadent
reviews
and
I
missed
the
Lobster
director
view
here
as
well.
So
the
the
the
routing
director,
it
simply
said,
there's
issues,
and
it
should.
The
introduction
should
cover
why
the
Affy
staffies
are
used
in
y2nri
types,
I
think
that's
sort
of
what
Ben
said.
The
App
Store
review
said
a
bit
more.
It
said
the
amount
of
abbreviations
were
there
without
explanations.
I
It's
this
draft,
it
said
e
is
globally
unique,
which
makes
e
Come
A
C
in
that
order
unique
and
it's
looking
for
an
explanation.
Maybe
that
needs
to
be
front
end
loaded,
so
the
rest
of
the
draft,
and
then
we
come
back
to
the
type
2
lri
for
the
prefix
and
how
it's
used.
Then
there's
also
a
very
good
point
that
I'm
hoping
that
Joel
and
the
folks
from
cider
will
help
us
with.
There
is
a
dependency
on
the
progression
of
draft
ITF
HR
spring
intent,
wear
routing
using
color.
I
I
I've
got
to
tell
you
that
some
of
the
car
stuff,
if
as
we're
going
forward,
we
have
to
resolve
the
things
that
we
didn't
really
take
time
to
resolve
beforehand,
but
that's
mostly
the
Shepherd
saying.
Did
you
think
this
is
really
settled
and
I
note
that
DJ
may
make
comments
on
this
in
his
thing
or
it
may
be
something
we
have
at
a
different
time
and
the
last
is.
J
I
J
J
I
I
J
Yeah
so
I
mean
just
for
some
background
context.
You
know
the
car,
our
solution
draft
was
adopted
at
IDF
114
and
we
had
broad
multi,
vendor
and
operator
support,
both
during
the
adoption
and
at
the
working
group
last
call,
as
so
indicated
and
or
mail
to
the
list,
and
we
have
had
two
interoperable
implementations
for
most
of
the.
J
You
know:
content
in
the
in
the
draft
in
terms
of
progress,
as
you
mentioned,
a
bunch
of
issues
or
questions
were
raised
during
working
group
last
call
and
we've
been
working
with
so
to
drill
down
into
concrete
action
items.
Since
you
know
some
of
the
items
raised
were
addressed
in
the
draft,
but
perhaps
not
you
know
clear
enough
or
not
in
the
right
location.
So
that's
something
we've
been
working
on
and
then
you're
also
addressing
additional
reviews
that
we
have
gotten.
J
You
know
from
Ben
and
and
then
in
terms
of
an
implementation
update
from
the
time
of
working
group.
Last
call
shortly
thereafter.
You
know
we
have
updated
the
implementation
report
to
say
we
have
one.
You
know
sub
implementation
of
the
the
type
2
route
and
I
believe
another
one
is
in
the
works
next
next
slide.
Please.
J
Yeah
again
on
Sue's
request
kind
of
trying
to
focus
on
a
few
key
aspects.
You
know
in
general,
the
motivation
for
the
two
route
types
that
are
defined
I
mean,
of
course
one
you
know
was
more
recent,
but
what
you
know?
What's
the
motivation?
What's
the
difference
and
then
yeah
I'm
just
getting
into
some
clarifications
with
respect
to
the
common
quality
of
the
procedures
and
then
the
trying
to
resolve
any
lingering?
J
E
F
J
You
know
a
whole
list
of
services
that
can
run
over
an
srv6
transport
and
there's
two
broad
models
described
there.
One
is
the
case
where
a
service
said
is
non-routed
in
the
transport
Network
or
the
underlay,
and
instead
the
there
is
an
Sr.
You
know
D
policy
that
you
know
provides.
You
know
a
path,
a
reachability.
You
know
through
the
through
the
underlay
for
for
a
given,
you
know
intent
and
then,
of
course,
the
service
said
you
know
is
processed
at
the
at
the
PE
now
in
terms
of
bgp
car.
J
As
with
you
know
what
we've
seen
with
mpls
and
srmpls,
we
had
support
for
redistributing
an
Sr
policy
that
may
exist
within
a
domain
but
cannot
be
propagated
into
the
multi-domain
network
for
various
reasons,
and
you
know
in
bgp,
car
is
used
instead.
So
that's
the
direct
in
applicability
here
as
well.
J
For
you
know,
the
type
type
1
route
gets
used
for
you
know
that
use
case
now,
but
additionally
rxc
9252
Define
a
routed
Services
model,
wherein
you
know
the
service
said
that
is
advertised
with
the
various
you
know,
VPN
or
overlay.
Services
are
resolvable
and
you
know
routable
in
the
in
in
the
underlay
and
the
the
reachability.
J
J
Naturally,
you
know
the
the
the
locator,
you
know
prefix
or
the
summary
would
be
distributed.
You
know
using
bgp,
and
here
you
know,
since
we
are
using
bgp
car
as
a
a
transport
mechanism,
for
you
know,
underlay
inputable,
routing
it
it's
just
a
natural.
You
know,
extension
to
distribute
the
locator
prefix
in
you
know
in
bgp
car
and
that's
where
you
know
the
the
type
2
route
you
know
has
been
defined.
J
J
J
You
know
that's
used
for
srv6,
where
a
unique
locator
prefix
is
assigned
for
a
given.
You
know
intent
or
color.
The
other
aspect
is
it's.
You
know
the
this
IPv6
prefix
route
is
routable.
It's
installed
in
the
IPv6.
You
know
forwarding
table
from
you
know
the
route
processing
semantics
point
of
view.
This
is
just
an
IP
prefix.
Hence
you
know
the
the
mechanisms
of
RFC,
4271
and.
E
J
J
A
J
J
J
J
J
J
So
yeah,
so
here
we
just
you
know
contrasting
the
two
and
you
know.
Of
course
you
know
the
motivation
for
having
both
in
the
car,
Safi
I,
think
clearly,
I
mean
you
know
and
presuming
the
type
1
route
is
fairly
familiar
to
to
most
folks,
but
just
you
know
to
quickly
educate
what
the
the
difference
here
you.
J
J
J
Now,
in
contrast
to
that,
the
type
2
route
is,
as
we
just
you
know,
saw
in
the
earlier
slide.
Here
we
have
a
one
is
to
one
relationship
between
the
intent
and
the
IP.
You
know
address
or
or
prefix
you
know,
yeah,
you
know,
srv6
being
a
prime.
You
know
use
case
here.
We
do
not
have
a
requirement
to
have
multiple
instances
of
the
locator.
You
know
for
different
colors.
In
fact,
we
do
not
want
it.
J
J
J
The
use
case
is,
you
know,
intent
aware
routing
for
srv6
in
this
case,
but
you
could
also
you
know
say
there
are
networks
where
we
would
have
mpls
or
Sr
mpls
with
transition
to
you
know,
srv6
the
the
end
use
cases,
a
routing
answer.
So,
regardless
of
the
you
know,
the
route
type
or
the
encoding
that
you
defined
there
is
a
commonality
between
the
you
know
between
the
the
two
route
types,
both
from
an
implementation
perspective,
as
well
as
from
an
operational
perspective.
J
It
would
just
be
you
know
simpler
to
have
these
routes
in
you
know
in
a
single
surfing,
and
then
you
know
when
it
comes
to
srv6.
You
know
they
also
have
a
case
where
both
the
you
know,
the
type
1
and
the
type
2
route
are.
You
know
used
simultaneously
to
get
both
the
benefits
of
NSR
policy.
You
know,
being
you
know,
extended
across
a
multi-domain
network
as
well
as
getting
the
benefit
of
you
know,
summarization
in
the
in
the
underneath.
J
Yeah,
this
is
just
just
an
illustration.
You
know,
you
know,
you
know
highlight
the
the
fact
that,
regardless
of
the
nlri,
you
know
format
the
model
you
know
the
routing
model
is
still
the
same.
You
know
flat
routing
model
that
we
have
with
bgp
card,
for
you
know
mpls
for
type
one,
as
well
as
what
we've
had
with
bgpi,
and
you
know
IP
and
LU.
So
there's
no
difference
in
in
any
behaviors
or
semantics,
with
the
introduction
of
the
type
2
Dot.
J
Please
right
now
I
mean,
maybe
you
know,
drilling
down
one
more
level
on
the
on
the
choice
of
the
you
know,
wire
route,
type
and
I.
Think
you're
just
refer
to
so
sue,
I
think
yeah.
This
does
look
like
it's
an
older
version,
but
yeah
I
think
that's
fine.
It's
just
a
reference
to
the
to
the
to
The
Exchange
on
the
list.
J
J
Now,
of
course,
we
could
have
done
that.
I
mean
it's,
it's
an
encoding
all
right,
but,
and
you
know
there
was
a
reference
to
something
similar
that
you
know
has
been
done
on
the
on
the
CT
side
for
best
effort.
You
know
routes,
it's
it's
it's
just
that
this
would
be
an
overloading
of
the
you
know
of
the
the
e-commerce
route.
The
you
know
this
notion
of
a
special.
J
You
know
that
were
in
there
in
the
email
you
know,
exchange
around
put
them
here
in
terms
of.
What's
the
you
know,
the
color,
you
know
value
0
is
not
something
that's
you
know
standardized,
as
part
of
you
know
the
color
definition
in
rsc9256
and
the
semantics
of
having
the
zero
value,
and
you
know
treating
them
with
or
without
the
correctional
Community.
If
you
get
into
a
lot
of
redefinitions
to
handle
this,
it
just
looked
hacky.
J
So
when,
given
that
the
cars
that
we
have
was
built
for
extensibility,
we
have
defined
a
route
type,
it
was
just
a
Natural
Choice
to
use
you
know
a
distant
route
type
to
give
it
that
distinction
in
you
know
the
the
processing
that
it
you
know
needed,
but
again,
as
we
said,
it
doesn't
really
change,
regardless
of
encoding,
the
actual
semantics
associated
with
the
route
that
we
saw
in
the
you
know,
the
previous.
You
know
couple
of
slides,
they
don't
change
right.
J
I
mean
we're
talking
about
a
routable
prefix,
that's
you
know,
distributed
in
the
underlay
installed
in
the
IPv6
according
table.
You
know
used
for
you
know
resolution,
so
it
doesn't
change
the
actual
Behavior.
It
changes
the
encoding
so
but
I
think
the
fact
that
we
use
the
route
type
seems
to
have
raised
a
lot
of
you
know,
concerns
and-
and
but
we
see
here
that
you
know-
we've
had
a
similar
example
in
the
other
Safi.
You
know
as.
D
J
Where
we
have
have,
you
know
some
special,
you
know
Behavior
or
you
know
a
value
that's
being
used
for
carrying
you,
know
best
effort
route,
so
I
think
the
cement,
the
the
a
bunch
of
the
issues
that
have
you
know
being
brought
up
and
we'll
cover
them
the
remaining
slides
they
seem
to
be
in
done
in
the
context
of
the
new
route
type,
but
they
really
aren't
and
I.
Think
that's
what.
J
Know
convey
and
have
a
you
know:
I
have
a
some
resolution
about
next
slide.
Please,
okay!
So
now
we
try
to
you
know,
go
into
some
of
these
issues,
so
the
first
one
yeah
is
more
I,
think
just
about
the
clarity
of
procedures
and
I.
Think
I
won't
go
through.
All
of
this
I
mean
there's
a
bunch
of
sections
describing
different
procedures.
Most.
E
J
Science
really
and
but
then
there
are
some
which
are
car
specific.
You
know,
color
related
and
all
of
them
applied
to
the
type
2
route,
and
this
reference
in
you
know
in
the
the
you
know,
since
section
10,
which
describes
that,
but
not
in
specific
detail
on
each
and
every
one
of
these
and
I.
Think
part
of
the
discussion
with
Sue
has
been.
J
E
J
J
You
know
you
define
the
use
of
the
IP
prefix
route,
but
again
you
know
if
you
going
back
to
the
actual
semantics
that
it
introduces
I
mean
it's
as
we've
seen
it's
it's
just
a
regular
IP
prefix.
So
it's
not
introducing
something.
You
know
unique
or
novel.
You
know,
apart
from
you,
know,
yeah
it's
a
new
dog
type,
it's
using
the
mature
IP,
unicast
implementation
and
design.
Both
from
you
know,
protocol
specification.
C
J
Of
view
as
well
us
from
the
implementation-
and
you
had
proof
of
that,
as
we
implemented
the
type
2
route,
I
mean
it's
pretty
much,
you
know
straightforward
leverage
of
what
you
had
with
the
you
know
the
IP
Unica
savvy
and
then
the
color
specific
aspects.
You
know
the
use
of
the
LCM,
the
use
of
the
color
EC,
you
know
for
various,
you
know
aspects
they
they
really
remain
the
same.
There's
no,
you
know
difference.
J
J
Now
this
one
is
a
you
know,
interesting
one,
because
there
was
a
issue
raised
whether
the
introduction
of
the
prefix
route
and
as
we
see
this,
it
seems
to
be
about
the
route
type,
but
you
would
expect
the
same
concern
to
be
there
for
any
Safi
that
distributes
an
IP
prefix
with
a
quick
color
without
color.
You
know
with
Rd
without
Rd.
J
J
This
is
prior
to
these
comments
being
made.
We
have
the
security
section
which
clearly
calls
out
that
it's
a
separate
safety
that
carries
you
know
infrastructure
routes.
You
know
there
is.
This,
provides
actually
a
separation
between
any
overloading
that
might
be
happening
with
other
staffies,
like
you
have
the
bgp
ipv4
IPv6
Safi.
J
Routes
or
bgplu
again
3107,
you
know,
there's
you
know
your
usage
of
service
routes
and
that's
our
fee.
The
using
the
cars
IP
for
the
transport
routes
automatically
provides
that
separation,
and
hence
it's
actually
addresses
this
notion
of
you
know
route
leaking
or
you
know
wall
Garden.
Instead
of
actually
introducing
it
right.
J
You
have
the
automatic
separation
you,
you
know
you
do
not
have
route
leaking
between
the
car
Safi
and
the
IP
Unica
Safi,
and
this
is
something
you
know
operationally.
It's
a
benefit
as
well
and
again.
This
is
all
documented
in
the
draft,
because
one
then
doesn't
need
to
worry
about
having
a
specific
route
filter
at
the
you
know,
peering
points
you
know
towards
customers
or
towards
the
internet,
which
you
would
have
if
you
were
trying
to
carry.
J
Okay,
okay,
sure
so
yeah
I
mean
it's
yeah.
So,
in
fact,
what
we're
saying
is
the
use
of
the
car
safety
actually
provides
the
separation
and
the
so-called
you
know
what
Garden,
rather
than
you
know,
break
it.
So
it's
you
know
it's
not.
You
know
clear
why
this
concern
is
there
now
there
is
a
of
course,
a
question
about
you
know
what
happens
if
somebody
did
do
redistribution
I
think
there's
another.
We.
J
Sue
had
brought
up
is
yeah,
even
though
these
sections
do
call
out
the
use
of
the
carsafe
for
infrastructure
out.
So
let's
be
you
know
very
clear.
You
know
in
the
introduction
and
the
through
the
document.
So
that's
something
again.
We
will
work
on
next
slide.
Please
right
so
I
think
yeah.
So
the
there
is
an
issue
raised
whether
you
know
again.
This
is
I.
Think
coming
out
of
the
fact
that
we
use
your
route
type.
Is
that
evpn
had
used?
J
You
know,
route
types
and
one
of
them
is
carries
an
IP
prefix.
So
whether
there's
any
you
know
related
concerns,
now
I
mean
we
really
don't
want
to
be
getting
into
a
question
of
you
know
what
were
the
issues
with
evpn
because
that's
you
know
that's
kind
of
out
of
scope
of
what
you
know.
This
particular
discussion
is
about
the,
but
suffice
to
say
that
you
know
again:
car
carries
infra
routes,
not
service
routes,
so
one
you
know
from.
J
We
have
that
you
know
whatever
issue.
Secondly,
you
know,
as
we
said,
the
the
car
Safi
you
know,
does
not
you
know
get
mixed
or
redistributed
into.
You
know
like
the
IP
Unica
savvy.
So
you
don't
have
this.
You
know
concern
or
question
of
inadvertent
leaks.
You
know
by
default
now,
if
one
did
go
ahead
and
enable.
J
Maybe
for
some
you
know,
maybe
it's
a
Brownfield
case.
We
don't
know,
and
so,
if
they
did
that
this
would
be
the
case
for
any
two
bgp
surface,
both
existing
and
new.
It's
not
specific
to
car
and
it's
not
specific
to
the
route
type
2
for
certain
I
mean
we
have
examples
today
where
we
have.
You
know
Safi,
1
and
74
and
there's
you
know
in
some
implementations,
there's
an
automatic
pre-distribution,
because
it's
the.
J
In
others,
you
have
to,
you
know
enable
it,
but
in
the
end
those
are
two
safies
which
are
you
know
from
on
in
between
which
you're
you
know
exchanging
routes,
or
you
would
have
I
think
in
the
in
the
parallel
context.
We
have
the
case,
you
know
with
safety,
four
and
bgpct,
as
called
out.
You
know
for
that
best
effort
case.
It's
it's
the
same.
Tj.
I
I
think
what
you're
trying
to
say
is
what
John's
cutter
said
earlier:
bgp
allows
policy
that
allows
redistribution,
and,
if
someone
does
it
without
knowing
what
they're
doing
they
can
cause
themselves
problems
or
they
can
enable
something.
That's
important,
I
think
that's
what
you're
trying
to
say
here
is
that
correct
that.
J
What
we're
also
saying
is:
this
is
not
a
specific
problem
to
the
car
route
type
2
or
to
the
car
Safi
you
know
and
and
the
moreover,
the
the
thing
is
it's
not
as
if
this
is
a
unsolved
problem.
I
mean
since
this
problem
already
exists,
if
at
all
it
did
the
the
answer
is
the
fact
that
you
know
path,
attributes.
F
J
A
J
Slide
please
yeah.
Okay,
now
there's
the
question
of
whether
we
have
Clarity
on.
What's
our
fees
are
used
for
service
routes,
and
so
I
mean
if
the
section
three
in
the
draft
already
lists
the
surface
that
are
steered
into
vgp
card.
It
talks
more
generally
in
terms
of
the
nature
of
the
you
know:
service,
ipv4,
V6
and
3vpn
Etc,
and
also
refers
to
SRT
in
rsa9256
compatibility.
So
then
there's
a
list
of
stuffies
listed
there.
So
in
general
we
Define
I
mean
the
service
office
is
an
ongoing
list.
H
J
B
A
B
B
I
J
Sure
sure
so,
thanks
just
one
thing,
I
would
just
a
quick
comment
on
your
your
response.
There
is
no
specificity
in
terms
of
steering.
That
is
very
you
know,
car
specific
and
that's
the
thing.
You'll
section
three
lists
out
as
well.
The
the
steering
service
steering
has
always
been
compatible
with
what's
already
defined
and
implemented
in
you
know
other
Solutions
like
SRT,
so
that's
where
the
rs9256
comes
in
then,
of
course,
for
srv6
we
already
have
a
9252
which
again
the
car
safety
adhes
to
so
that's
one
benefit
in
that.
J
J
Yeah
thanks
thanks,
so
I
think
yeah.
The
related
you
know,
potentially
related
issue
has
been
yeah.
You
know
the
the
use
of
the
VPN
car,
Safi
and
I
think
you
know
just
to
contrast
it
with
what
we
discussed
just
now.
Vpn
car
essentially
extends
the
the
notion
of
color,
where
routing
to
the
customer,
you
know
network
and
hence
so
that
it
allows
a
customer
who
you
know
who's
running
car
in
their.
You
know,
Network
they
can
still
get.
J
You
know
that
those
paths
extended
across
you
know
a
service
provider
on
through
which
they
are
getting.
You
know,
Transport
Service
it.
You
know
the
car
safety
still
carries.
You
know.
Infrastructure
routes
is
one
very
good
use
cases
a
CSC
like
deployment
which
needs
you
know,
intent,
awareness
and,
of
course,
VPN
car
is
upgrade
Safi,
as
described
in
in
the
draft.
The
the
the
the
notion
I
mean
the
from
there's
a
question
about
the
procedures.
What
we've
described
is
it
follows
the
same.
J
You
know
VPN
semantics
and
procedures
that
are
actually
4364
defines.
The
difference
is
just
that
the
nlri
is
a
car
and
lri.
You
know.
So,
that's
why
it's
you
know
it's
a
great
safety
and,
of
course
there
is
a
VPN
Rd
here,
I
mean
just
to
you
know,
since
there's
always
a
question
about
what
is
this
here.
This
is
just
a
regular.
You
know.
E
J
As
you
know,
you
have
with
rxd4364
because
it
distinguishes
car
routes
that
a
service
provider
may
get
from
different
customers.
So
it
just
provides
that
you
know
the
the
standard
you
know
use
case
for
which
it
was
you
know,
defined
it's
to
differentiate
routes
from
different.
You
know,
customers
procedures
apply,
but
again
you
know
I.
Think
Sue
has
suggested.
We
add
more
detail
in
terms
of
the
specific
procedures
we've
been
doing,
that.
C
J
A
yeah
they've
walked
through
the
various
issues.
Think
you
know
fully.
We
clarified
the
applicability,
I
mean
they're,
not
specific
to
the
route
type,
and
you
know
certainly
not
in
some
cases
not
specific
to
the
car
Safi
procedures.
Wise
yeah
I
mean
even
though
it
is
that
we
have
defined
a
new
route
type,
the
whole
intent-
and
you
know
you
see
that
in
the
you
know
the
spec
and
the
implementation.
J
J
I
B
Speaking
with
working
group
chair
head
off
and
author
hat
on
the
issues
that
were
listed,
we
plan
to
document
and
put
some
kind
of
text
in
the
draft
where
it's
deemed
necessary,
where
we
think
we
should
provide
explanation,
sufficient
explanation
to
working
group
and
get
around
to
that.
We
would
like
to
do
that.
If
there
is
a
specific
guidance
of
what
needs
to
go
where,
then
we
would
welcome
that
shoe,
but
that's
the
path
we
are
going
to
take
after
this
interest.
I
H
No
I
have
a
quick
comment
thanks
for
the
clarifications
and
yeah,
so
a
couple
of
ambiguities
I
see
that
I
wanted
to
record.
Nothing
really
needed
to
be
answered
right
now.
We
can
take
it
in
the
word
group
if
needed.
So
one
is
the
problem
with.
Where
is
my
color
ambiguity,
so
some
quoting
from
some
sections
so
in
O2,
so
for
Carlo
generally
color
easy
takes
the
presidents
over
the
route,
nlra
color.
H
So
at
this
point
the
type
one
color
seems
to
get
thrown
off
when
there
is
a
color
easy
on
the
car
route,
so
I'll
post
all
this
in
the
group,
so
I'm
just
trying
to
go
and
record
these
points
right
now.
Car
route
me
recursive
result
over
in
bgp
Road
carrying
DEA.
So
there's
there
is
some
needs
to
be
a
gap,
so
the
Gap
is
a
color,
so
Carnival
type,
1,
color
or
LCM
is
an
open.
Color
is
present
on
the
car.
Color
easy
is
present
on
the
cardboard.
H
So
at
this
point,
because
color
is
he
takes
precedence
so
that
point
of
Precedence
is
not
clear
where
which
to
take
or
what
to
take
so.
The
about
statements
invalidate
the
need
for
in
color
in
the
nlra
or
the
lcmec.
If
calories,
he
takes
the
Precedence.
So
that's
one
and
we're
not
able
to
really
get
the
Precedence
for
between
the
color,
EC
and
lcmbc
use
cases,
and
for
some
of
the
anycast
use
cases
where
the
color
you
see
is
actually
used.
H
There
is
a
mandatory
that
two
different
boxes
generate
the
same
label,
so
those
are
things
where
there
is
a
should
or
a
must
Clause
need
to
be
added
accordingly,
so
I
can
point
it
to
that.
The
second
ambiguity
is
that
the
mpls
srv6
intro,
working
where
we
have
say
one
side,
is
a
mpls
IPv6.
Other
side
is
mpls
survey,
just
student
srv6
network
with
IPv6
forwarding
plane.
So
in
such
cases,
the
type
1
routes
and
type
2
routes
need
to
have
some
interoperation
procedures.
H
I
H
J
H
J
I
I
Again,
if
you
want
to
look
at
the
shepherd
reports,
you
will
see
the
shepherd
reports
and
now
I'm
going
to
the
shepherd
comments
for
CT.
By
the
way,
this
was
my
cute
idea
to
show
that
I'm
shepherding
lots
of
different
opinions
and
for
each
of
these
I
tried
to
find
a
graphic
that
was
vendor
neutral.
That
is
actually
a
CT
scanner,
so
I
hope
a
little
humor
in
the
day
is
useful.
I
Let's
look
at
the
CT
working
group
call.
K10
has
been
wonderful
to
take
and
look
at
these
drafts
and
provide
comments,
and
so
just
as
he
provided
comments
to
John
Scudder
that
are
very
helpful.
He's
provided
some
comments.
He's
indicated
in
consistency,
removal
of
text
provided
by
other
drafts,
Sr
V6
support-
requires
features
in
individual
draft
you'll
find
that
this
particular
issue
is
also
mentioned
by
Jeff
Haas.
G
I
Alumin
my
shepherd's
report-
I'm
sorry
I
missed
it.
Thank
you
Kate
for
again
just
going
through
all
of
this
carefully.
Are
we
really
reprove?
This
is
technology.
I
think
will
last
for
a
while
I'm
a
proponent
of
intent
based
or
color-based
work.
So,
if
you
are
someone
who
wants
to
just
sit
down
and
review
these
specs,
please
do
that.
I
would
really
appreciate
any
reviews.
You
have
Jeff
noted
and
Jeff
I'm
gonna.
I
Ask
you
to
be
ready
to
comment
on
what
I
might
have
missed
in
the
high
level
report
in
case
you
want
to
Pride
that
he
also
knows
this
inconsistent
terminology
normative
sport
added
for
individual
drafts
and
I
think
that's
a
very
key
Point
again,
the
same
type
of
drafts,
inconsistent
terminology
and
editorial
now,
folks.
This
is
a
snapshot
at
the
time
of
working
group.
Last
call
Kali
Raj
will
provide
his
status
report.
As
of
now.
I
The
adoption
call
I'm
going
to
remind
you
that
during
June
and
July
for
the
CT
draft,
we
had
repeated
calls
and
I
queried
people
specifically
for
responses.
So
I
considered
after
all
that
work
that
if
someone
had
some
concerns
about
the
adoption,
calls
that
were
issues
that
were
mentioned
for
CT
that
hopefully
they
would
have
closed
them
at
that
point,
I'm
also
requesting
feedback
on
the
working
group,
I've
queried
again
most
people
issue
one
and
two
is
off,
because
those
authors
had
finished
issue
three
has
been
replaced
with
a
chair
team
review.
I
Jeff
Haas
did
one
and
Gene
will
do
one
as
well
issues
four
unintended
service
level,
review
of
Technology
base.
The
rest
of
those
are
open,
but
I
have
queried
most
of
the
people.
If
I
do
not
get
a
response
in
the
upcoming
weeks
on
these
I
will
consider
them
closed
as
we
go
into
a
second
working
group.
Last
call
that
is
still
also
true
for
any
things
that
I'm
outstanding
from
adoption
call
for
car
I
will
do
a
call
and
I
will
then
say:
that's
it.
I
We've
closed
those
issues
because
they're
available
on
GitHub
working
group,
early
directorate,
recalls,
I
really
have
to
put
my
hats
off
to
Med.
Med
did
an
excellent,
excellent
review
of
CT
and
I.
Think
the
authors
are
extremely
grateful
to
his
points.
I
believe
all
the
issues
were
addressed
prior
to
the
working
group
last
call,
except
for
internal
consistency
of
handling
Reserve
bits.
My
understanding
is
again.
Calories
will
provide
you
status
on
that
the
apps
to
recalled
by
Bo
Wu
is
indicated.
Not
ready.
I
I
I
B
Yeah
so
before,
starting
on
CD
I
want
to
just
thank
nuts
for
taking
his
time
and
recording
the
issues
with
the
the
car.
Workout
and
I
would
also
encourage
other
working
group
members
to
spend
time
in
doing
the
thorough
review
like
what
the
city
others
are
doing.
Okay.
So
this
is
the
session
to
provide
us
status
update
on
bgpct
right.
B
So
the
agenda
is
quick,
so
we
will
just
do
a
recap
on
the
bgpct
what
it
is
and
then
go
over
some
changes
since
version
12
and
then
status
of
the
issues
that
are
being
tracked
on
GitHub
and
the
next
steps
next
slide,
please
so
bgpct
what
what?
What
is
it?
So?
Basically
it
is
an
intern
driven
service
mapping,
solution
that
is
transport
protocol
agnostics,
supports
the
following
transport
protocols:
rcbt
UDP
Etc
and
Sr
protocols,
SRT
ISS,
flexible
SPF,
Flex,
algo
and.
B
Mpls
and
services
datablings,
and
it
is
service,
family
agnostic.
It
supports
various
elderly
services,
L2
services
or
flow
spec,
Based
Services,
and
it
provides
a
per
route
granularity
fallback
options
using
some
formalized
constructs
so
transport
class
and
resolution
scheme.
So
these
don't
need
any
standardization,
but
it's
good
to
formalize.
These
constructs,
instead
of
just
saying
that
you
do
it
in
some
way,
so
you
can
implement
it
in
the
way
that
you
feel
fit
into
your
implementation,
but
it's
good
to
just
formalize
the
concepts.
Just
like
next
up
resolution.
B
Here
we
are
just
saying:
use
resolution
scheme
and
transport
class
uniformly
across
the
network
so
that
we
are
able
to
accommodate
homogeneously,
intern,
driven
service
mapping
for
various
deployment
realities
and
those
deployment.
Realities
are
basically,
it
works,
the
same
manner
in
intra
domain
interdomain
option
a
b
and
c
and
a
new
Safi
76
is
defined
only
for
the
option,
C
scenario
and
it
works
the
same
manner
for
or
it
works
holistically
for
any
cast,
as
well
as
unicast
endpoints,
and
it
accommodates
heterogeneous
color
domains
as
well
as
non-againing
color
domains.
B
So
if
you
are
looking
for
an
intern
driven
service
mapping
solution,
look
no
further,
so
we
have
something
that
is
very
comprehensive,
so
you
can
just
go
ahead
and
collaborate
with
us
implement
it.
If
you
want
to
look
for
some
other
alternative
yeah,
you
can
spend
more
time
doing
that,
but
yeah
just.
F
F
B
Please
yeah
so
yeah.
So
what
are
the
changes
since
draft
version?
12
2016.?
So
there
have
been
a
lot
of
good
feedback
that's
coming
in
and
there
are
many
editorial
comments:
Incorporated.
We
have
reorganized
the
text
and
new
subsections,
so
these
are
like
taking
care
of
difficulties.
Leaders
were
having
in
understanding
the
key
Concepts.
So
if
you
go
through
the
tabular
contents,
now
you'll
be
able
to
clearly
see
what
is
the
organization.
B
Basically,
you
have
the
mapping
Community
resolution
schemes,
the
thought
selection
changes
that
are
required
for
handling
the
multiple
ABR
cases,
avoiding
routing
Loops.
That's
like
a
base
RR
in
forwarding,
plane
problem.
So
those
things
now
Stand
Out
by
being
organized
into
proper
subsections
and
the
thing
about
mapping
Community
being
a
base
class
and
any
bgp
Community
can
play
the
role
of
a
mapping
community.
So
mapping
Community
is
not
a
certain
type
of
vgb
community.
It's
it's
not
an
ie
in
a
type.
B
B
E
B
If
you
find
something
that
you
cannot
consume
in
a
bgpct
update,
if
you're
able
to
pass
it
properly,
then
keep
it
as
A
Treatise
withdrawal
following
7606
RFC
guidelines,
and
we
have
Incorporated
the
comments
from
the
routing
review
like
she
was
pointing
out
excellent
review
from
Med
and
there's
only
one
point
that
is
starting
out.
That
is
the
handling
of
the
resort
bits.
So,
basically
there
it
is
the
it's.
Actually
we
have
taken
the
suggestion
that
Jeff
had
Jeff
has
had
on
how
to
handle
the
result.
B
Bits
basically
must
set
it
to
zero
on
send
and
should
ignore
it
and
left
unaltered
on
receive
so
Matt's
question
is
when
you're
receiving
it.
Why
would
you
actually
order
it?
What
are
the
cases
where
you
would
order
it
so
I
think
the
intent
here
is
the
Jeff's
intent
is
that
when
a
new
version
implements
or
defines
the
those
beds
and
old
version
should
be
able
to
at
least
do
policy
matches
on
those
bits
that
will
get
defined
in
future
so
that
we
can
do
some
firefighting
filtering
of
things
and
stuff.
B
So
I
think
the
way
it
can
be
clarified
is
the
receive
site
can
say
that
it
should.
It
should
ignore
on
reception
and
must
leave
it
unaltered.
So
that
is
the
response.
I
have
on
GitHub,
who
have
asked
both
Jeff
and
Matt,
whether
that
looks
okay.
So
once
that
is
done,
then
that
issue
will
be
closed
and
also
another
thing
about
the
list
of
issues
that
Sue
you
had
in
the
previous
report.
Suppose
report
so
I
think
some
of
those
issues
are
already
closed.
B
I
B
B
I
K
K
Yeah
go
ahead,
yes,
so
it
was
a.
It
was
about
the
design
limitation
because
of
the
RTS
I
have
sent
multiple
mails,
which
you
have
replied
to,
but
it's
us,
but
I
just
want
to
capture
that
it's
a
significant
deviation,
the
way
bgpip
or
Lu
that
works
in
the
transport
today
and
where
we
don't
have
this
duplicate
route
or
churn
issues.
And
we
don't
see
these
multi-path
and
active
backup
in
the
bgplu.
K
K
K
In
fact,
you
are
captured
in
the
table
itself
that
it's
the
same
bgp
Route
16
routes
with
only
two
forwarding
labels
are
not
sure
how
we
can
agree
to
such
a
procedures
and,
of
course-
and
the
third
part
is
since
we
are
carrying
these
duplicate
or
random
bgp
routes.
It
will
cause
the
increase
in
the
control
plane.
State.
Even
the
forwarding
state
is
not
there
and
you
are
carrying
an.
K
Information
which
is
not
required
because
the
data
model
you
have
it,
it
will
cause
the
control,
plane,
convergence
and
the
churn
across
the
multiple
domains.
We
are
talking
about
multiple
domains
here,
till
the
Ingress
P,
whenever
any
local
failure
happens
so,
which
was
for
transport,
does
not
have
these
issues
I
want
to
capture
that
and
if
you
are
not
addressing
them,
probably
we
should.
We
should
add
the
these
limitation
in
the
draft.
That's
the
way
I
want.
H
B
K
K
B
There
are
multiple
ways
of
deploying
bgplu
or
CT
or
even
originate
the
transport
or
the
City
route
at
either
the
egress
b
or
at
the
asps.
So
the
recommended
way
is
to
originate
the
route
at
the
egress
PE
and
when
we
originate
the
route
at
the
egress
PE.
The
problems
we
are
talking
about
don't
exist.
Basically,
even
the
USB
is
advertising
it.
B
B
B
The
label
value
has
not
changed
because,
yes,
we
are
doing
for
transport
class
called
prefix
level
allocation
mode,
and
none
of
the
other
nodes
in
the
network
know
about
this
change
and
only
when
there
is
a
gold
path,
for
example,
broken
end
to
end,
for
example,
in
this
topology
we
have
carefully
engineered
this
path,
such
that
the
Gold
Path
exists
only
between
ABR
23
and
AVR
asbr
22..
So,
if
that
gold
LSP
goes
down
so
can
you
go
to
the
next
slide?
Please.
B
So
if
this
Gold
Path
goes
down,
then
there
will
be
a
withdrawal
for
rd1
colon
pe11
to
the
Ingress,
and
that
has
to
be
propagated
to
the
Ingress,
because
now
the
Ingress
knows
that
the
Gold
Path
is
not
available
and
it
goes.
The
Ingress
will
do
fallback
for
each
of
the
service
route
based
on
what
they
want,
because
that
that
information
of
the
Gold
Path
is
not
available.
B
End-To-End
should
reach
the
Ingress
and
English
has
to
take
on
a
per
service
routes
basis,
whether
the
service
or
wants
to
take
a
best
effort,
backup
or
a
bronze
backup.
It
will
do
it
based
on
the
resolution
scheme,
so
this
is
how
it
works
and
the
drafts.
So
we
have
given
references
to
the
draft
sections
which
talk
about
this
illustration.
Those
comments
that
you
had
were
talking
about
this
draft
section
and
saying
that
the
churn
is
not
contained
locally.
B
So
that
is
why
I
was
repeatedly
saying
that
for
these
scenarios
that
are
described
in
the
illustration,
which
are
the
recommended
way
of
deploying
City,
there
is
no
redundantly
travels
or
updates
when
the
local
failure
happens.
The
case
that
you're
talking
about
is
for
when
the
routes
are
originated
from
the
asbrs,
that
is
asbr
13
and
asbr
14
and
they're,
using
unique
RDS
on
asbr,
13
and
asbr
14th,
and
it
is
right
that
whenever
the
link
will
go
down
in
that
scenario,
then
you'll
have
a
withdrawal
going
for
the
asbr
13
route.
B
K
If
you
are
recommending
now,
because
in
the
draft
I
thought
unique,
Rd
is
the
recommendation,
but
if
you
are
recommending
now
that
on
the
PE
you
have
to
originate
the
route,
then
I
don't
see
how
your
advantages
of
using
the
RDR
applicable.
Now,
what
you're
saying
is
whatever
the
advantages
we
had
with
the
Rd
that
on
the
Ingress
P,
you
know
you
can
for
the
debug
purposes
you
know
from
where
it's
originated.
H
H
Gives
us
flexibility
and
it's
not
really
a
huge
concern
here?
You
have
multiple
ways
of
deploying
it.
There
are
more
recommended
ways
if
we
can
say
we
can
actually
find
to
go
into
a
deployment,
find
you
on
how
say
somebody
wants
it
to
be
deployed
in
that
case.
In
that
case,
flexibility
is
more
important,
I
think
if
the
visibility
can
be
controlled,
the
way
the
routes
has
to
be
actually
advertised
can
be
controlled
at
this
level
of
control.
I
think
for
such
a
use
case
of
Indian
driven
service
mapping
is
needed.
K
And
therefore
I
will
say:
the
cases
are
this
problem.
Is
it's
significant
and
it's
it's?
It
causes
some
optimal
problem
because,
as
you
have
any
cost
cases
or
too
many
Originators,
this
problem
gets
heightened
means
it.
It
just
multiplies
the
number
of
routers
which
are
originating
it.
Let's
say:
I
have
such
10
abrs,
which
originates
you
are
carrying
10
times
the
copy
of
the
routes
and
the
churn
in
in
the
multi-domain
case.
The
churn
is
significant,
so
I
think
this
problem
cannot
be
said.
Oh
it's
a
flexibility,
it's
not
flexibility.
It's
the
it's!
H
I
I
I
Okay,
so
Dash
as
you
go
forward
with
your
comments,
since
it's
been
back
and
forth
three
times
you've
you've
expressed
your
opinion.
I've
asked
you
in
the
chat
to
send
the
details
on
your
concern
linking
back
to
the
original
adoption
call,
which
I
think
I've
captured
in
the
adoption
call
notes.
Your
con
specific
churn
concern
for
this
section
and
now
I'm
going
to
add
something.
I
So
please
send
that
to
the
list,
so
I
can
capture
it
and
we
can
carefully
let
the
working
group
discuss
it
prior
to
the
CT
second
working
group
last
call
since
you've
raised
it.
The
third
point
is
you've
added
Rd
to
car
VPN.
Can
you
compare
and
contrast
the
your
Rd
situation
or
your
rdu's
versus
Kali
Raj's
rdu's
just
tell
us
why
his
rdu's
is
not
appropriate
and
your
Rd
use
is
for
car
VPN.
That's
just
a
request
as
part
of
the
discussion.
Please
continue
on
you
have
you.
K
Sure,
thanks
so
thing
is
for
the
VPN
card.
We
are
still
carrying
the
because
VPN
Rd
purpose
originally
was
for
the
VPN
purposes
and
what
I
mean
by
that
was
carrying
the
customer
routes
across
a
provider
Network,
because
when
your
multiple
customer
routes,
they
may
have
a
overlapping
IP
prefixes,
because
they
are
different
customers.
They
have
its
own
IP
space
and
they
could
be
overlapping
in
the
provider
provider
space.
So
therefore,
the
Rd
is
required
and
that's
exactly.
I
K
A
little
bit
yeah:
yes,
yes,
so
it
focused
more
in
Faster
routes.
If
the
bgp
car
or
intent
awareness
that
customers
of
a
provider
like
to
use,
then
they
will
use
their
their
infrastructure
routes
with
the
car
procedures
and
when
they
go
through
a
provider,
they
will
go
as
a
VPN
card
and
therefore
the
Rd
that
is
required
there,
because
again,
the
customer
intent
investor
routes
for
the
customer
again,
their
IP
space
may
be
overlapping
or
the
color
space.
K
So
therefore,
Rd
is
required
for
that
purpose,
and
RD
is
at
the
users
only
at
the
edge
of
the
network,
as
we
are
aware
at
any
service
address
family,
whether
evpn,
mvpns
or
anything
else
where
the
Rd
is
applicable.
Today.
This
is
the
first
case
where
bgp
CT
is
bringing
the
Rd
into
a
transport
into
the
hubby
hop
routing
model
and
therefore
the
problems
are
there
with
the
Rd
with
the
Rd.
I
K
K
K
B
Basically,
what
I
was
saying
was
ID
is
not
used
only
at
the
edge
of
the
network.
Like
you
know
what
option
b,
it
is
also
used
at
the
border
nodes
and
because
it
is
a
transport
protocol,
transport
layer
protocol,
it
will
be
used
at
all
the
Border
nodes.
So
you
need
to
be
specific
specific
about
the
procedures
just
like
how
bgpct
does
about
how
these
Rd
manipulation
and
the
route
visibility.
The
churn.
All
these
things
happen
for
the
VPN
car.
K
It's
exactly
same
procedures
as
the
4364
for
the
VPN
car,
but
therefore
pgpct
and
for
bgp
CT,
as
as
I'm
saying
again
that
you
are
doing
at
every
bgp,
hop
as
in
your
example,
it's
from
P
to
the
asbr
to
the
it's
an
option:
C
we
are
talking
about
here,
we're
not
talking
about
option
b,
where
you
are
trying
to
extend
a
VPN
Services
across
the
admission
domain.
That's
a
different
case
here:
you're
trying
to
create
an
option.
C
model
where
bgp,
where
multipath
or
the
churn
going
to
other
network,
is
very
important.
K
If
you
don't
want
to
contain
that,
I
will
leave
it
to
bgpct
I'm,
not
saying
I'm,
not
saying
you
have
to
address
it.
What
I'm
saying
is
these
limitations
need
to
be
captured?
It
cannot
just
be
deflected.
We
we
nearly
I'm
I'm,
just
asking
to
be
captured
very
clearly
the
problems
of
using
the
RT,
because
I
have
mentioned
that
in
the
email.
In
fact,
after
the
working
group
last
call
also
so
I
just
want
it
to
be
captured.
If
you
you're
not
getting
addressed,
that's
what
I
will
say
thanks.
E
B
I
Don't
wait
guys
time
so
Dash
send
me
the
list,
so
I
can
make
sure
I've
checked
off
everything
and
we
haven't
missed
anything.
You
say
that
okay,
you
say
that
Colleen
Roger
Smith
is
let's
slow
this
down
and
make
sure
we've
checked
everything
off,
because
we're
going
to
a
second
working
group
last
call:
will
you
do
that
for
me,
swadesh.
I
I
That's
important
at
this
point,
I
appreciate
you
being
patient
as
we
sort
of
slow
it
down.
You
guys
have
a
May.
Each
of
you
have
amazingly
fast
and
creative
minds
now
swadesh.
If
you
want
to
come
back
in
a
moment,
let's
let
Catan
try
to
ask
his
questions
and
then
we'll
try
to
slow
this
down
a
little
bit.
Thank
you
guys
for
the
patience.
G
Hi
actually
I
wanted
to
share
a
suggestion
on
the
debate
that
we
were
just
having.
The
city
draft
does
have
a
lot
of
flexibility
and
options,
and
it's
captured
very
nicely
in
a
table.
Could
authors
just
consider
maybe
having
like
a
pros
and
cons
of
each
design
in
a
text?
Therefore,
I
remember
there
was
something
about
an
operational
consideration
section.
H
F
I
G
G
So
I
think
this.
So
this
is
more
of
a
discussion
now
on
how
how
this
can
be
addressed,
really
I
sense
from
the
response
from
the
authors
that
they
want
to
document
like
a
full
and
complete
proposal.
As
somebody
would
do
you
know
in
any
general
document
or
a
white
paper,
but
here
we
are
dealing
with
an
ITF
specification
which
has
you
know
normative
and
informative
parts,
and
you
know
we
have
some
some
process
or
the
way
we
go
about
it.
G
So
yeah,
basically
I
wanted
to
open
up
a
discussion
and
see
how
we
can,
because
how
how
this
thing
can
be
addressed,
because
the
way
it
is
done
for
right
now
the
shape
I
I'm,
not
really
sure
this
would
go
past.
The
working
group
last
call
right
just
a
question
that
I'm
asking
so
to
you
as
a
Shepherd,
mainly.
I
I
As
far
as
the
one
I've
read
and
I've
actually
tracked,
the
28
years
of
history
for
experimental
drafts
I
know
weird
thing
to
do,
but,
and
they
do
contain
more
information
just
because
it's
a
documenting
of
an
idea
before
a
proposed
standard,
but
they
should
have
to
be
a
standard.
They
have
to
not
reply
to
an
informational
drafts
as
normative
I.
Hope.
I
said
that
in
two
different
ways.
Hopefully,
if
it's
clear,
because
it's
an
in-between
answer-
please
let
me
know
if
it
if
I
was
clear.
G
I
B
G
Do
I
think
the
solution
is
there
and
which
I
had
also
suggested
I.
Believe
Med
has
also
brought
it
up
and
I
have
not
seen
Jeff's
detailed
review,
but
I
think
he
may
be
also
suggesting
is
to
I
mean
just
take
them
into
separate
documents,
because,
except
for
the
SR
V6
functionality,
which
is
you
know,
we
can
say
score.
The
other
things
are
more
like
added
things,
and
you
know
they
can
proceed
in
separate
documents.
So
I
mean
I,
leave
it
to
the
authors
or
you.
G
B
G
B
G
H
So
one
more
thing-
I
I
want
to
just
add,
is
just
that
as
part
of
this
early
work
in
group
last
called
review.
I
think
we
did
some
exhaustive
review
of
the
other
draft
in
the
srv6
as
well
from
jingram
and
G.
Also
so
I
think
the
procedures
were,
they
did
go
through
and
verify
it,
and
we
do
have
some
I,
don't
know
we
are
trying
different
angles
here.
H
One
of
the
angle
is
to
get
that
draft
adopted
in
the
spring,
and
the
author
group
haibo,
who
was
part
of
the
CBR
approach,
is
also
part
of
this
approach,
so
I
think
we're
trying
to
go
and
ask
for
adoption
on
that
craft
as
well,
so
we'll
we
are
thinking
on
these
lines
as
well,
but
right
now,
I,
don't
know
if
we
have
any
very
clear
idea.
I
think
it's
it's
a
good
discussion
to
have
how
to
go
about
it,
but
not
really
we're
not
cemented
on
anything
yet.
H
E
Okay,
microphone
should
be
working
now
so
with
respect
to
you
know
the
normative,
informative
and
also
no
split
discussions.
Srv6
clearly
has
been
the
problem.
You
know
use
case,
that's
been
difficult
to
capture
in
the
documents,
so
both
sets
of
the
proposals
have
spent
a
lot
of
energy,
trying
to
figure
out
what
a
srv6
route
with
color
would
look
like
in
each
of
the
proposals.
C
E
Think
the
each
of
the
proposals
has
done
a
fairly
no
clean
job
of
that
piece.
If
it
became
the
case
that
that
was
the
single
element,
that's
holding
up
the
authors
again,
splitting
things
may
make
sense.
You
know,
and
as
it's
been
pointed
out
in
informative
reference
to
say
that
this
you
know,
other
document
will
solidify.
E
There
I
don't
think
that
was
specifically
covered
by
the
work
that
we
were
adopting
as
we
were
moving
forward
a
way
to
Simply
address.
You
know
that
entanglement
and
also
the
implementation
considerations
for
the
widely
document
to
advance
on
the
RFC
track.
Is
you
know
to
Simply,
do
a
split
on
you
know
the
type
twos
you
know
that
way,
the
the
use
cases
further
clarified
and
kept.
You
know
separate
from
the
color
aware
no
use
case.
That's
the.
G
G
F
I
B
From
my
perspective,
I'd
rather
see
them
both
being
carried
out
in
the
same
document
unless
we
have
real
reason
to
say
no,
the
only
reason
I
would
provide
as
a
justification
within
the
same
document
is
we
are
implementing.
We
have
implementations
in
place,
we
believe
IPv6
should
be
handled
and
there
is
no
difference.
There
is
no
reason
why
the
procedures
and
Rule
sets
of
IPv6
will
be
any
different
than
ipv4.
B
C
I
Ct
Jeff
for
car
and
CT
and
that's
for
a
car
I'm
going
to
raise
these
as
issues
in
the
next
week
with
a
two-week
call.
So
we
have
time
to
work
on
this
and
then,
if
we
can
have
time
for
the
working
group
last
call
before
the
next
ITF.
This
is
carefully
planned
for
this
time.
So
we
can
have
those
discussions.
So
please
respond
to
Jeff's
note
on
the
list.
I'll
form
it
in
a
in
a
com
comment
and
the
same
two
is
Nats
and
so
Dash.
B
G
If
you
look
at
this
slide
and
as
I
think
that
mentioned
the
recommended
way
to
would
be
for
the
PE
11
to
originate
its
its
colored
route
into
into
the
transport
into
bgp
Staffing
right,
so
when
it
is
doing
that,
I
would
expect
normally
that
it
would
send
it
with
an
implicit
null
label
right.
So
this
is
a
normal
thing
and
it's
not
really
an
indication
to
say
that
you
know
the
asbr
should
not
send
the
packet
using
mpls
encapsulation
to
it.
Yes,.
B
G
B
G
Today,
yeah
you're
right
today
we
have
there
is
there
is
a
challenge
and
I
can.
What
I
can
say
is
that
as
part
of
the
again,
this
is
the
first
time
that
I'm
comparing
with
car
now,
but
that
was
one
of
the
main
or
key
motivations
for
Carr
to
have
the
encoding
that
it
has
to
allow
this
indication
explicitly
without
and
in
a
clean
way,
because
we
were
doing
a
new
safety.
G
B
Whatever
end
cap
is
required
and
this
kind
of
a
deployment
is
actually
there
for
mpls
versus
UDP
tunnels
today
in
one
of
our
major
Customs,
so
that
works
today,
I
mean
this
is
like
at
the
bgpct
layer.
We
are
saying
that
you
can
use
whatever
end
caps
you
want,
but
it
does
not
dictate
even
for
bgplu
or
Internet.
It
does
not
dictate.
What
is
the
tunnels
that
we
use
to
reach
v11?
There
are
some
mechanisms
like
tea,
where
we
can
say
that,
okay
to
reach
PE
11,
you
use
this
specific
type
of
end
cap.
B
B
If,
if
we
need
a
specific
tunnel
to
be
reached
in
the
CT
model
of
doing
things,
you
put
those
specific
tunnels
in
a
certain
transport
rib
and
then
you'll
be
able
to
resolve
only
only
that
so
that's
a
way,
but
yeah
you
could.
We
could
find
the
different
other
ways
of
explicitly
requesting
that
this
is
the
type
of
funnel
that
I
want.
Just
like
tea
or
somewhere
new
mechanisms.
G
Here,
it's
a
little
different,
because
this
actual
packet
that
is
carrying
the
said
it
could
be
an
IPv6
packet
in
the
case
of
srv6,
and
then
we
any
or
it
could
be
a
label
and
if
it's
a
label
you
know
we
cannot
end
up.
We
should
not
end
up
carrying
a
wrong
service
data
type
service
context,
data
type
to
the
wrong
p.
B
G
B
I
Yeah,
okay,
K10.
What
I
would
appreciate
in
Colorado
is
Kate
and
I
would
appreciate
if
you
would
send
me
and
Kali
Raj
your
points.
Color
Raj
I'd
like
to
make
sure
we've
solved
all
of
cayton's
points,
exams
points
except
for
the
normative
one,
as
we're
going
to
pick
that
up
with
Jeff.
If
you
would
help
me
complete
that
cycle
this
week,
I'd
appreciate
it
is
that,
okay,
both
of
you
sure,.
A
I
I
Please
send
me
this
stuff
today,
I'll
start
that
K-Town
and
Kali
Raj
I'd
like
to
get
your
discussion
finished
by
Friday,
so
I
can
at
least
give
a
week
to
two
weeks
now
the
thing
I'd
intended.
So
please
do
this,
so
we
can
do
that
before
we
do.
The
CT
calls
I'm
trying
to
get
CTN
car
toward
their
next
working
group
last
call
for
experimental.
I
What
we
didn't
get
time
to
talk
about
is
the
next
steps,
after
with
consultation
with
my
chairs,
I
may
pull
this
off
to
another
interim
simply
because
we
need
to
to
allow
the
other
people
some
time
at
ITF
118.,
so
watch
your
mail
list
for
the
discussion
of
the
steps
after
I've.
Given
you
my
shepherd
report,
but
the
shepherd
report
should
always
go
along
with
a
discussion.
I
Any
questions
on
that
before
I
go
to
the
next
topic
is
my
steps.
Cl
on
my
steps,
clear
step,
one
discussion
of
the
key
points
raised
before
we
do
a
CT
last
call
second
CTN
car
before
we
do.
The
last
call
second
have
perhaps
have
another
discussion
on
steps
after
so
we
have
this
longer
debate
time,
in
which
case
I
will
ask
not
a
couple
of
keen
on
authors
to
give
their
opinion
and
then
working
group
last
calls.
Okay.
I
I
It'll
be
15
minutes
and
I'll.
Try
to
do
this.
How
did
this
particular
well
I'm?
Not
getting
I'm,
not
getting
my
gallery
view
okay,
so
this
one
thing
we
had
is
we
finally
gotten
some
very
wonderful
people,
Juniper
Nokia,
to
tell
me
how
they
wanted
to
start
implementing
flow
spec
V2
and
we
got
some
feedback
and
Donald
and
I
talked
about
this
at
with
Gunter
and
Jeff
at
the
last
ITF.
So
for
the
rest
of
you,
let
me
bring
the
history.
I
We
did
some
extensive
trying
to
querying
working
group
and
operators
on
what
to
do
with
flow
spec
V1,
because
there
were
known
implementation
problems
with
it
and
they've
been.
The
working
group
basically
said.
We
have
a
use
case
of
only
dos
for
denial
of
service
and
packet
form
format,
shouldn't
change
so
for
a
new
tlv
form
that
we
needed.
I
I
But
then,
if
we
break
it
up
like
we
did
with
the
te
policy
in
two
parts,
that's
a
good
thing,
because
we've
thought
it
out.
Okay,
this
is
ready
for
complete
implementation.
This
is
later,
and
this
may
be
what
you
all
think-
and
this
is
the
query,
look
we
if
we
did
a
highest
priority.
People
tell
me
enhanced
denial
of
service,
enhanced,
DDOS,
enhanced
and
perhaps
a
simple
firewall
is
important.
I
The
user
can
always
have
an
ordering
of
every
match
with
a
large
ordering
space,
they
can
say.
I
have
one
I
have
two
I.
Have
three
I
have
four
as
you're
ordering
somewhat
with
the
dependency
deals
with?
Is
the
default?
Okay,
you
gave
the
flow,
spec,
V2
says:
I
said
user
order
one,
but
you
gave
me
five
with
user
order
one.
So
we
give
a
default
matching
ordering
within
that
based
on
something
that
looks
like
the
flow
spec,
V1
spec.
I
I
Seems
to
be
duplicated,
then
you
might
have
problems
with
actions
right
now.
The
suggestion
is
to
stay
with
the
extended
Community,
but
do
some
reformatting
one
approach
would
be
to
give
me
seven
bits
of
assignment,
so
we
can
expend
things
out
and
a
one
bit
failure
mode
stop
and
roll
back
or
continue
on.
If
you
have
a
failure,
how
would
we
deal
with
this?
With
current
assignments,
we
might
re,
decide,
assign
it
to
make
things
Organo.
I
We
might
have
a
new
action
that
says
redirect
and
with
this
interaction
and
then
traffic
great
I'm,
trying
to
make
sure
we
solve
the
problems
short
term
and
long
term.
The
second
approach
is
five
bits
of
assignment
and
take
two
more
bits
for
a
short
ordering.
Jeff
is
worried
and
he
makes
a
good
point
whether
that's
really
any
value
versus
doing
this
option.
I
I
B
Hi
Susan,
so
I
was
just
going
to
the
fsb2
and
the
list
of
actions,
and
it
is
going
quickly
going
over
the
list.
It
looks
like
at
least
there
are
like
four
actions,
so
that
can
be
folded
into
the
mnh
draft,
which
is
also
in
that
option
queue.
So
if
we
Implement
mnh
for
any
address
family,
then
this
redirect
ipv4
redirect
IPv6
redirect
to
the
indirection
ID
and
the
MPS
level
actions.
All
of
this
can
be
achieved
using
their
manage,
including
the
color
resolution.
So
that's.
I
I
E
That
Sue
was
mentioning
one
sort
of
critical
point.
Is
you
know?
White
communities
is
listed
here
as
a
potential
piece
of
the
solution
space.
What
we're
looking
at
I
think
feature
wise
that
we
need
autoflow,
spec
V2
is
more
about.
How
do
you
take
sets
of
actions
that
need
to
be
bundled
together
and
allow
them
to
be
number
one
grouped
appropriately
so
that
you
know
they
represent
their
dependencies
correctly?
Pick
an
easy
example
out
of
our
existing
flow
spec
features
that
we
have.
We
have
a
redirective
verb.
E
We
have
a
redict
IP
when
the
authors
were
doing
redirect
IP,
we
were
trying
to
figure
out.
You
know
how
these
things,
combined
with
each
other
and
there's
texted,
redirect
IP.
They
try
to
talk
about
this
sort
of
thing,
but
we
also
talked
about
as
part
of
that
very
first
effort
of
how
do
these
features
cross
and
direct.
What
happens
when
you
can't
Implement
them
consistently?
If
they're
separate,
extended,
Community
style
actions,
then
you
potentially
have
ambiguities
going
on
in
terms
of
even
just
signaling
much
less.
How
do
you
program
things
so?
E
The
bundling
the
dependencies
and
the
failure
modalities
are
really
the
solution.
That's
needed
the
encoding.
You
know,
that's
you
know
whatever
you
can
go
into
a
wide
Community
container,
not
specifically
the
white
Community
format,
or
it
can
go
into
a
brand
new
path
attribute.
So
that
item
is
not
necessarily
the
hold
up.
That
is
who's
mentioning
as
part
of
the
action
portion
of
her
slides.
Just
simply
addressing
that
set
of
things
is
a
longer
discussion,
whereas
a
lot
of
the
things
that
for
flow
spec,
V1
was
problematic,
rule
ordering
is
a
default.
E
What
do
you
do
if
some
of
the
you
know
criteria
can't
be
satisfied
and
also
she's,
mentioning
the
default
sort
orders,
one
of
the
properties
of
flow
spec
V1
had
that
wasn't
really
documented
but
again
sort
of
built
into
the
document.
You
know
the
sort
order
is
great
for
denial
service
and
the
consequence
there
is
that
we
have
rules.
E
There
currently
ordered
one
through
15
I
think
for
89.56,
and
this
means
that
if
we
start
adding
on
additional,
you
know
match
criteria
and
allow
for
default
sorting
were
things
potentially
hit
in
the
sword
order,
even
though
we
have
the
ability
to
allow
users
to
specify
that,
as
part
of
you
know
the
packet
itself,
we
want
the
defaults
to
make
sense.
So
there
may
be
some
need
to
have
a
discussion
about
how
we
change
our
numbering
space.
E
I
I
Flow
spec
was
first
designed
because
people
needed
it
and
it
seems
that
it's
still
a
key
piece
and
I
don't
want
the
large
spec,
which
we
did
to
be
technically
consistent
to
make
us
to
make
us
blocked.
Let's
just
break
it
into
pieces,
leaving
the
original
document
and
we'll
call
out
pieces.
The
original
document
doesn't
have
to
go
to
our
C.
I
We
could
take
these
little
pieces
and
just
leave
it
and
I'd
probably
do
an
ask
for
an
adoption,
call
on
all
the
little
pieces
and
then
once
it's
adopted,
we'll
move
the
rest
so
that
anyway,
any
other
thoughts
before
we
close
I
know
you've
been
very
patient
to
to
work
through
all
a
very
technical
discussion
today.
Any
thoughts.
I
I
Last
call:
okay
action
item,
Nat,
swadesh,
Jeff
and
Katan,
slash
Kali
Raj,
if
you
would
natsudesh
and
Jeff.
If
you
would
send
that
today,
if
you
haven't
send
it
so
I
can
start
that
kalaraj
and
Canton.
If
you
can
get
together
and
work
it
and
give
me
a
summary
by
about
Wednesday
or
Thursday,
that
would
be
helpful.
Thank
you.
All
have
a
good
day,
we'll
probably
see
you
in
another
interim.