►
From YouTube: IETF109-IDR-20201116-0730
Description
IDR meeting session at IETF109
2020/11/16 0730
https://datatracker.ietf.org/meeting/109/proceedings/
B
C
It's
the
half
hour.
So
let's
get
this
thing
on
the
road.
Yeah
live,
live
from
michigan
it's
late
night
with
idr,
so
we
got
we.
We
have
two
sessions
this
week.
We've
got
this
one
which
is
just
an
hour
and
then
we've
got
a
longer
one
on
friday
and
because
this
one
is
short,
we
are
not
going
to
spend
a
lot
of
time
sue
and
I
are
not
going
to
spend
a
lot
of
time
listening
to
ourselves.
C
Talk
you
get
to
see
the
note
well,
because
you
get
to
see
it
every
time
and
as
usual,
it's
up
to
you
to
know
that
when
you,
when
you
join
one
of
these
meetings
at
some
point,
whether
you
remember
it
or
not,
you
did
sign
a
piece
of
click,
wrap
that
said
that
you
will
abide
by.
You
know
all
these
various
rules.
So
if
you
don't
know
what
they
are,
maybe
you
should
go
check.
C
C
You
definitely
know
where
to
find
the
meat
echo
because
you're
here,
if
you
want
to
help
with
the
notes,
that's
where
and
here's
our
agenda
for
today
and,
like
I
said,
I'm
not
going
to
spend
a
lot
of
time
talking
we're
just
going
to
go
into
the
first
first
presentation.
Unless
I
will
pause
and
see.
If
anybody
has
any
questions,
we
will
do
a
longer
chairs
thing
on
on
friday,
because
we
have
a
longer
session,
then.
C
Seeing
no
one
in
the
queue
who
who's
our
presenter
for
for
the
first
one,
is
it
where
agent.
C
F
F
F
F
In
this
scenario,
pes
establish
ibgp
sessions
with
rr
to
ensure
the
roots
can
be
transmitted
within
as100,
where
p124
maintain
weaken
routine
information
and
r,
don't
maintain
any
vrf's.
The
rdrf
mechanism
in
different
devices
is
independent
once
week
of
weapon,
one
in
p1
overflows
p1
will
find
out
the
main
source
of
vpn
routes
in
this
prf.
F
These
three
vrfs
have
different
maximum
prefix.
Once
the
vpn
routes
carry
rd3
cause,
the
overflow
of
the
rf3
p
will
send
a
bgp
root.
Refresh
message
contains
a
rdrf
entry
to
r,
then
r
will
stop
sending
associated
vpn
routes
to
p.
However,
this
will
cause
where
f1
and
2
failing
to
receive
vpn
rules.
Content
are
distributed.
F
F
F
F
F
G
G
C
All
right
talking
to
a
to
a
closed
mic,
I
I
wasn't
able
to
understand
what
you
said
earlier.
I
john
I'm
sorry.
C
What
I
was
going
to
say,
though,
is
you,
have
a
question
adopt
as
a
working
group
document
on
your
on
your
slide,
and
I
think
that
it
would
be
at
this
point
reasonable
for
us
to
to
do
that.
Adoption
call.
I
will
say
that
you
know
sort
of
that.
C
A
H
Super
so
I
think
I've
been
tracking
all
the
comments
I
I
still
don't.
I
still
believe
rd
based
mechanisms
are
not
useful.
I
think
I
don't
see
anything
that
has
been
drastically
changed.
That
being
said,
maybe
we
can
take
this
on
the
mailing
list
and
and
hopefully
can
provide
another
round
of
feedback.
C
List
any
other
questions
comments
you
can
take
yourself
out
of
the
queue
now
care.
C
Okay,
thank
you
very
much.
We
will
take
this
up
on
the
list
and
next
please.
C
Oh
wait:
we
have
someone
in
the
queue
giuseppe
did
you
want
to
say
something.
C
C
Giuseppe,
I
see
you
putting
yourself
in
the
queue
there.
You
go
hello,
please
go
ahead.
Yes,
we
hear.
D
I
D
Next
yeah
just
recap
about
background
and
motivation
for
this
graph,
so
density
flow
information
telemetry
refers
to
data
plane
on
path
techniques.
In
particular,
we
can
mention
all
inventory
and
alternate
marking.
So
with
the
I
feed
terms,
we
want
to
refer
to
the
visual
telemetry
techniques
with
just
a
single
word.
D
On
the
other
hand,
the
we
have
the
sr
policy
that
are
identified
to
the
well-known
tuple
and
an
add-on
may
be
informed
about
the
candidate
thought
in
different
ways,
in
particular
by
pgp,
for
example,
and
this
document
aims
to
define
an
extension
to
bgp,
to
distribute
dsr
policies
carrying
ip2
information,
and
I
feed
the
information
and
in
particular
in
this
way
we
want
to
enable
the
inventory
and
alternate
marking
when
the
sr
policy
is
applied.
So
this
is
the
scope
of
of
this
graph.
D
D
Yeah
in
this
slide,
we
just
recapped
the
the
changes
from
the
last
version
that
was
presented
that
during
the
last
online
meeting
now
we
are
at
0-4
version.
We
got
some
comments
during
the
last
ietf
session
from
joel,
and
in
this
regard
we
clarified
the
use
of
the
ip
terms,
because
there
is
something
confusing
with
another
document.
That
is,
I
think,
framework.
So
in
this
case
the
ic
terms
is
used
just
to
indicate
the
inventory
and
ultimate
marking
method.
D
So
all
the
in
c2
flow
information,
telemetry
techniques-
that
also
the
acronyms
say
the
other
comment
from
catan-
was
about
the
routing
and
control
playing
considerations.
D
We
are
also
having
an
exchange
image
just
in
in
the
last
days
with
katan
to
clarify
by
the
way
we
try
to
address
this
comment,
but
there
is
something
pending
that
need
to
be
clarified.
D
D
D
D
Yeah
yeah
in
this
slide,
we
just
explained
that
the
feet
attributes
can
be
attached
at
the
candidate
path
level
as
a
subtleties
yeah.
We
also
got
a
comment
from
you
that
this
figure
needs
to
be
updated.
Considering
the
latest
version
of
the
p
policy
draft,
we
will
do
that
in
the
next
version.
So
next
live.
D
Yeah,
this
is
the
detail
of
the
ifit
attributes,
subtle
v,
and
you
can
see
the
list
of
the
subtle
wheels
that
are
currently
defined,
so
the
inventory
allocators
option
the
incremental
transoption
the
direct
export
option,
the
h2h
option
for
immanuel
and
the
latest
one
is
about
the
enhanced
alternate
marking
subject.
D
D
D
Yeah
this
is
the
the
attending
matching
subfield
resource.
In
this
case,
this
is
taken
from
the
relevant
alternate
marking
document
and
particularly
the
application.
The
document
about
the
application
of
the
alternate
mark-
okay,
next.
D
This
document
complement,
and
we
want
to
clarify
that
this
document
complement
the
segment
routing
key
policy
draft
by
adding
the
ip
touch
bit
so
for
all
the
operation
we
have
referred
to
this
graph.
In
particular,
we
can
consider
that
these
ifit
subtleties
are
optional,
so
an
implementation
may
consider
to
ignore
the
unsupported
or
unrecognized
hypothetily.
D
D
On
the
other
hand,
the
sr
policy
and
lris
that
have
been
considered
acceptable
can
be
evaluated
for
propagation
and
can
include
also
the
ifit
information
regarding
the
error,
rendering
actions
for
now
we
considered
it
as
for
the
segment
routing
key
policy,
but
during
a
comment
we
got
a
comment
from
drew
that
we
have
to
include
some
specific
error
handling
actions,
also
in
our
draft.
I
also
think
we
need
so
maybe
in
the
next
revision.
We
have
to
include
some
information
also
regarding
the
error,
rendering
actions
for
the
validation
of
the
fit
attributes.
D
Next
yeah,
the
for
this
draft,
the
working
group
adoption
is
ongoing.
I
have
wrapped
up
the
inputs
from
just
a
summary
of
the
inputs
from
drew
that
will
be
addressed
in
the
next
revision,
so
we
can.
In
particular,
we
have
to
add
more
text
about
the
error,
rambling,
the
procedure
for
the
start,
stop
and
update
and
backward
compatibility.
So
we
will
complete
this
part.
D
I
I
didn't.
I
could
not
put
the
last
minute
comment
from
kaiten,
but
we
are
having
some
exchange
about.
We
can
say
the
inclusion
of
the
srtm
operation,
so
we
may
address
you
know
we
are.
We
are
building
the
building
blocks
of
the
world
architecture,
so,
of
course
we
need
to
include
more
details
about
the
srtm
we
need
to
understand
if
the
real
place
is
this
draft,
or
maybe
another
general
draft,
let's
see
so
anyway
welcome
questions
and
comments,
and
thank
you
for
the
time.
K
So
thanks
deceptive,
for
for
your,
you
know,
responses
and
update.
I
wanted
to
clarify
that.
I'm
not
asking
for
more
information
to
be
added
into
this
bgp
draft,
because
for
most
of
the
sr
policy,
what
bgp
is
doing
is
only
like
a
opaque
or
an
almost
opaque
kind
of
a
transport
functionality
and
all
of
the
actual
processing
and
interpretation,
and
you
know
provisioning
in
the
forwarding
and
all
of
that
is
left
to
you
know
what
you're
calling
also
as
an
srpm
module.
K
So
my
suggestion
would
be
like
you
said
these
are
building
blocks.
My
suggestion
would
be
for
the
authors
to
write
that
in
a
separate,
perhaps
in
a
spring
document-
and
you
know
work
that
through
the
spring
working
group,
so
I
just
want
to
clarify
I'm
not
asking
those
things
to
be
brought
into
the
idr
document
or
the
psap
document
or
the
igp
documents
for
that
matter.
D
K
Suggest
I
would
suggest
a
new
one
if
you
don't
mind
and
yeah,
because
without
that
piece
it's
difficult
for
many
of
us
perhaps
or
at
least
me
to
understand
how
all
of
these
protocol
stuff
are
kind
of
fitting
together.
C
Thanks:
okay,
zafar!
Please
go
ahead.
C
So
I
see
you
in
the
queue
you're
unmute
yourself
and
speak
if
you
like.
I
No
yep,
oh
great
thanks,
so
my
question
is
that
there
is
a
draft
which
is
draft
song,
ops,
a
w
working
group
on
ifit
framework,
and
that
is
an
individual
document.
I
So
I
thought
it
may
be
better
to
work
on
the
overall
framework
before
defining
the
protocol
extension.
There
are
certain
elements
that
are
in
the
frameworks
that
are
not
covered
by
the
track,
but
it
would
be
better
to
to
cover
the
holistic
framework
first,
and
the
second
comment
is
that
I
did
notice.
There's
a
typo
in
the
adoption
poll,
the
the
adoption
poll
points
to
a
different
draft
which
is
path
mtu
draft,
so
that
may
have
led
to
some
confusion
during
adoption.
L
E
J
D
Yeah
regarding
I
know
that
there
is
the
ip
framework
draft
in
upsa
fuji,
and
but
you
can
consider
that
the
first
one,
the
observation
draft
is
the
framework.
So
it's
a
general
draft.
Now
we
are
just
building
one
of
the
blocks
of
the.
D
So
it
is
not
so
related
with
the
word
framework,
so
the
word
framework
can
use
this
building
block,
but
it
does
not
imply
that
if
we,
the
framework
is
not
accepted,
this
graph
can
can
always
be
used
by
other
implementation
by
other
architects.
So
I
want
to
make
this
different
that,
because
I
think
it's
just
the
athlete
acronym
is
is
in
both
draft
but
are
two
separate
things.
I
C
C
I
think
I
understand
your
your
two
different
perspectives
and
we
probably
won't
make
a
lot
of
further
headway
right
now
on
it.
In
any
case,
I'd
like
to
let
the
other
two
people
in
the
other
three
people
in
the
queue
speak
first
and
then,
if
we
have
extra
time,
we
could
continue
so
yeah.
Please
go
ahead.
B
All
right,
finally,
all
right.
That
was
a
good
breakthrough
here,
all
right.
So
so
I
had
a
question
regarding
I
noticed
in
the
draft.
It's
referencing
the.
I
think
it
was
in
section
two,
the
bgp
tunnel
encapsulation
attribute,
and
I
guess
in
the
latest
version
I
guess
there's
a
lot
of
updates
with
the
pgp
title,
encapsulation
of
draft
that
actually
in
section
37
it
references
the
prefixes
of
tlb.
B
So
I
was
wondering
like
how
is
like
it
doesn't
have
there's
some
details,
that's
in
the
draft,
but
I
was
wondering
how
is
the
segment
routing
key
policy
leveraging
the
prefixes
of
tlb?
That's
referenced.
You
know
with
using
the
bgp
encapsulation.
B
D
B
Yeah,
I
was
just
wondering:
could
you
again
describe
how
is
it
referenced?
How
is
it
you
know?
I
guess,
because
it's
leveraging
the
bgp
tunnel
encapsulation
attribute,
but
how
is
it
leveraging
that
I
guess
using
the
prefix
sid
like
when
it's
building
the
candidate
path?
I
guess
how
is
how
is
it
was,
I
guess
in
the
draft.
It
doesn't
have
much
detail,
but
I
guess
that
is
that
what
you're
saying
you'll
update
it
quick
to
provide
some
more
detail.
D
Yes,
because.
B
C
All
right
thanks
and
zafar,
I
see
you
back
in
the
in
the
queue.
Do
you
have
another
point
you
want
to.
E
C
C
C
C
O
Yeah,
so
this
is
jaydon,
I'm
going
to
present
this
draft
bgp
extended
community
for
identifying
the
target
notes.
This
is
a
zero
three
version
and
here
are
the
closers
of
this
draft.
Okay,
next
page,
please,
okay.
First
of
all
a
little
recap
of
this
motivation.
O
We
know
that
in
some
cases
for
the
pdp
route
distribution,
the
target
of
some
of
the
bgp
routing
policy
information,
maybe
just
one
or
a
small
group
of
the
b2b
speakers
in
the
network.
Some
examples
are
the
bgp
flows
back
and
the
bgp
sr
policy,
and
we
can
see.
Maybe
there
are
also
other
use
cases
to
which
require
such
kind
of
behavior
and
for
bgpsr
policy.
The
route
target
is
used
to
determine
the
target
node
of
this
as
a
policy
route.
O
Well
for
some
other
address
families,
the
retargeting
misdeal
needs
to
be
used
for
the
vrf
matching
in
such
cases,
using
rt
for
both
the
target,
node
identification
and
the
vrf
matching
could
be
problematic.
We
will
show
an
example
in
the
next
page:
okay,
next
slide,
please,
okay.
O
But
this
route
will
be
imported
by
both
node
b
and
node
d,
because
I
know
d
will
use
the
rt
red
to
match
with
its
local
variables
and
if
it
is
matched
it
will
import
the
route
to
various
red
regardless
whether
this
route
contains
an
rt
which
identifies
node
d
or
not,
so
we
can
see
there's
a
problem
in
such
cases.
So
the
purpose
of
this
document
is
to
define
a
generic
mechanism
to
designate
the
target
nodes
for
information
advertised
using
bgp.
O
O
Okay,
this
is
a
proposed
solution.
We
introduced
a
new
bgp
extended
community
to
carry
the
target
node
information.
It
is
called
a
node
target,
extended
community
and
the
figure
the
format
is
shown
in
this
picture.
It
basically
will
need
to
include
a
four
octane
target,
bgp
identifier,
to
identify
the
target
node
of
this
bgp
update
message
in
one
bgp
update
message:
it
can
carry
one
or
more
no
target
extended
community
to
identify
the
target
nodes,
a
group
of
target
nodes
in
the
network-
let's
play
next
slide.
O
Please,
okay:
here
we
summarize
the
procedures
of
this
mechanism.
First
of
all,
the
sending
b2b
speaker
will
need
to
add
one
or
more
no
targets
to
the
b2b
update
and
on
the
receiver
side.
If
one
of
the
no
targets
match
in
the
message
matched
with
a
local
bgp
identifier,
the
information
is
out
in
the
updated
message
is
eligible
to
be
kept
and
installed
on
the
receiving
node.
O
Well,
for
this
ar
sbr
case,
this
drought
is
just
limited
to
the
multiple
ass
which
are
administered
by
the
same
operator
for
other
cases.
For
other
internal
us
cases,
it
will
need
some
further
study
and
if
none
of
the
node
targets
match
with
the
local
bgp
identifier,
the
information
in
the
bgp
update
is
not
eligible
to
be
installed
on
the
receiving
between
node.
O
The
same
procedure
as
above
the
r
may
choose
to
reflect
the
roads
only
to
the
peers
whose
php
id
match
with
no
target.
Okay.
Next
page,
please.
O
O
This
was
discussed
in
the
previous
meetings
and
also
think
reasonable
point
to
usb
identifier.
In
this
case,
and
for
the
procedure
section,
we
also
re,
I
reorganized
the
content
and
include
the
procedures
for
both
the
rod,
reflector
and
the
asbr
for
the
we
call
it
intra
domain
scenarios,
which
is
one
single
operator
case.
O
O
For
next
steps
here
we
would
like
to
collect
the
comments
and
feedbacks
from
the
team
working
group.
Then
we
can
revise
the
draft
accordingly
yeah.
That's.
J
Thank
you,
so
I
do
find
the
idea
of
a
extended
community
being
used
for
filtering
purposes.
That's
tied
to
node
semantics
to
be
useful.
E
O
Reasonable
that
the
rt
filtering
mechanism
can
be
optional,
and
we
can
maybe
next
version
to
say
that
it's
whether
to
use
filtering
on
rt
is
determined
by
the
operator's
policy,
and
it's
also.
The
position
of
the
rt
is
something
like
that.
J
J
My
second
comment
is
that
if
you
do
want
that,
your
procedure
still
may
not
help
you
in
your
original,
slides,
rt
constrain
says
that
if
any
of
the
targets
match,
then
it
would
be
received.
So
in
your
example,
where
you
had
a
red
and
a
blue
vrf,
therefore
red
and
blue
route
target,
if
you're
trying
to
do
a
restriction
to
a
subset,
you
still
may
not
get
the
semantics
you're
looking
for,
and
I
think
that
may
still
be
a
problem,
even
if
you
weren't
using
rt
constraint.
O
C
I'll
just
remark
that
the
jeff
tensura
says,
plus
one
jeff
over
in
the
chat
window.
P
Yep,
my
notoriously
bad
memory
is
that
the
bgp
identifier
is
unique
only
within
a
single
autonomous
system.
Therefore,
I
wonder
the
semantics
of
when
you
cross
ebgp.
O
Yeah,
I
got
your
point
yeah
in
the
beginning.
We
firstly
consider
the
use
case
in
the
intro
as
scenario
like
the
using
route,
reflector.
Okay,
for
the
interiors
case,
as
I
just
mentioned,
we
firstly
want
to
limit
it
to
the
multiple
ess
administered
by
the
same
operator.
In
that
case,
maybe
the
bgp
identifier
can
be
management
by
the
a
single
team
and
the
conflict
can
be
avoided,
but
I
again.
E
O
C
M
M
If
you,
if
you,
if
you
start
to
propagate
such
a
community-
and
you
have
to
assume
that
neighbors
may
not
be
able
to
clean
up
this,
you
are
you
are
opening
a
leak
where
uncontrolled
control
messages
may
be
spread
globally.
That's
a
really
bad
idea.
O
Yeah,
I
understand,
for
the
intro
yes
case,
many
more
considerations
about
this,
like
external
community
propagation
and
the
security
considerations
yeah.
So
we
we
want
to
limit
the
use
case
to
first
as
a
first
step
to
inquiry
as
editor,
maybe
multiple
years
under
the
same
operators,
control
that
may
be
more,
maybe
easier.
O
C
Okay,
thanks
and
guillaume,
let's
take
this
as
the
last
comment,
because
then
we'll
need
to
move
on
to
our
next
one.
Please
go
ahead.
B
So
the
use
case
that
I
think
that
you
have
you're
addressing
is,
is
it
primarily
for
for
bgp
explosive
distribution
or
are
there
like
in
the
draft?
Are
there
any
other
use
cases,
or
is
it
just
really
primarily
for
for
vgp
specs.
O
B
The
same
thing
also,
he
also
makes
it
independent
of
vpn
overlay.
So
it's
not
it's
independent
of
you
know
the
mpls
like
vpn
construct
or,
if
you're
doing,
even
if
you're
doing
like
vrf
light
but
non-vpd
and
not
non-mpls
related
overlay,
but
this
becomes
independent.
It's
just
just
you're,
just
tagging,
and
so,
if
you're
just
needing
to
tag,
you
may
be
able
to
get
away
with
standard
communities.
Maybe.
O
C
All
you
thanks
for
the
presentation
in
the
comments
and
our
final
presentation
for
this
evening
or
morning
or
day
or
whatever
it.
C
Is
you're
not
if
you're
speaking,
I
can't
hear
you.
Q
So
good
afternoon
from
beijing,
and
it's
good
to
have
you
all
here
and
today,
I'm
going
to
update
you
with
our
zero
one
version
draft
which
we
have
already
presented
at
itf
108,
which
is
titled
traffic,
steering
using
bgp
flows
back
with
srv6
policy.
So
next
page,
please.
Q
So
I'm
gonna
start
with
two
application
scenarios
of
our
draft.
So
generally
we
want
to
do
traffic
steering
using
bgp
flow
spec,
and
we
are
not
like
proposing
any
new
encoding
of
of
in
this
draft.
But
some
you
know
operational
operational
changes.
Q
So
now
suppose
we
want
to.
This
is
a
l3
vpn
traffic
steering
scenario
and
in
the
next
scenario,
we'll
talk
about
the
internet
traffic
steering
okay,
and
in
this
case
we
want
to
steer
the
traffic
from
the
the
blue
pass
to
the
yellow
path.
Q
Okay
and
then
so
we
have
a
either
a
controller
or
any
just
regular
bgp
flow
spec
speaker
that
can
advertise
bgp
route
to
the
head
end
of
an
srv6
domain,
which
is
router
2
at
this
case,
and
this
bgp
flows
back
route
will
include
two
major
parts.
The
first
is
the
filtering
components,
of
course,
and
in
this
case
we
use
the
destination
ip
address
as
the
filtering
condition,
which
is
nothing
new,
but
for
the
action
parts
we
are.
Q
This
is
something
we
are
newly
proposed
in
this
draft,
so
we
are
using
a
combination
of
different
action
components.
Here
we
propose
to
use
three
components
in
this
example.
The
first
two
is
the
redirect
ip
extended
community
and
the
second
is
the
color
extended
community
community.
Q
So,
basically,
what
you
can
do
with
the
two
components
is
that
when
the
head-end
router
router
2
receives
the
two
components
it
can
use
it
to
associate
with
an
srv6
policy
which,
as
shown
in
this
figure,
is
the
policy
two
okay
and
then
the
third
component
action
component
is
is
actually
an
optional
component.
But
in
this
case
this
component
is
needed
is
needed,
which
is
an
l3
service,
seed
tlv.
Q
So
for
cases,
especially
in
an
vpn
traffic's
theory
case
you
want
to
like
specifically
identify
which
link
you
want
to
like
direct
the
past
through
the
traffic
through,
you
probably
need
to.
You
know,
instruct
the
endpoint
router
to
tell
it,
for
example,
in
this
case,
to
tell
it
to
use
the
and
dx
function.
So
in
this
case,
l3
service
seed
is
carried
in
this
flow
spec
route.
Okay
and
then
can
I
go
to
the
next
slide.
Please.
Q
And
then,
in
this
case
we
showed
that
the
component
three,
which
is
the
service
seat,
is
not
mandatory,
which
means
it's
optional,
but
it
still
has
conditions.
Q
So
in
this
internet
traffic
steering
case,
we
only
carried
the
redirect
ip
community
with
the
color
community
to
you
know
indicate
the
srv6
policy,
but
we
don't
want
to
like
specify
a
dt
function
there,
but
this
is
under
the
condition
that
the
ant
seed
is
usd
flavored.
If
it's
like
psp
or
usb
flavored,
then
you
still
need
an
service
seat
to
instruct
the
endpoint
router,
okay
and
next
slide.
Q
Please
so
here's
a
summary
of
you
know
the
steps
that
we
have
in
this
draft
and,
as
I
said,
there's
no
new
encoding
and
there's
no
ion
allocation
actions
needed
here.
So
what
we
propose
is
generally,
it
could
be
two
steps
or
four
steps,
depending
on
whether
you
will
use
the
service
of
ctlv
okay.
So
the
first
step
is
that
you
need
to
generate
a
flows
back
route
with
the
the
two
or
three
components
we
just
used
in
this.
Q
In
the
example,
the
service
seat
is
optional,
depending
on
whether
it's
necessary
and
in
the
second
step,
the
head
and
should
associate
the
the
next
hop,
as
well
as
the
color
community,
to
an
srv6
policy.
Q
Q
And
we
have
also
made
two
changes
from
the
initial
version
and
first,
the
first
change
is
the
handling
of
multiple
communities
and
thanks
to
jeff's
comments
on
that.
Q
So
in
this
draft
we
we
only
want
to
like
support
or
or
say
we
only
allow
the
usage
of
one
redirect
ip
community
with
one
color
community,
because
we
think
that
is
sufficient
and
for
the
for
the
purpose
or
say
the
intuitive
of
having
you
know,
multiple,
maybe
color
community,
with
a
really
ip
community,
is
that
we
possibly
want
to
do
load
balancing.
But
I
would
say
that
using
only
one
redirect
ip
with
one
color
community
is
sufficient
for
load
balancing.
Q
So
what
you
do
is
that
you
basically
configure
you
know
multiple
srv6
seats
lists,
I'm
sorry
at
least
in
an
srv6
policies,
so
there
you
go
and
for
the
second
change
is
regarding
the
cross
domain,
traffic
steering
and
thanks
to
cali
rush's
comment,
and
we
would
say
that
the
you
know
the
handling
of
flow
spec
communities
in
this
draft,
for
both
the
intro
s
and
the
cross
as
cases
would
be
the
same.
Q
The
only
difference
would
lie
in
the
local
srv6
policy
configuration
okay.
So
if
you
want
to
do
like
cross
domain
traffic
steering,
then
the
policy
should
be
a
cross-domain
policy,
and
if
you
only
want
to
do
an
intro
domain,
then
it
it
will
be
an
inter-domain
policy
so
that
that's
it
for
for
the
presentation
and
any
questions
or
suggestions.
A
Ac,
linda
cisco
systems,
should
this
be
a
informational
draft,
then,
because
it
really
uses
srv6
and
redirect
prospect
redirect
draft
standards.
Q
Well,
I
I,
I
think
it
could
be
an
informational
because
it's
like
more,
like
you,
know,
and
usage
of
some
existing,
a
combination
usage
of
some
existing
like
methods-
I'm
not
quite
sure,
but
I
think
it
could
be.
C
L
Q
Or
I'm
sorry,
I
have
a
small
suggestion,
it's
more
appropriate
to
make
it
than
bcp
dropped.