►
From YouTube: IETF102-IDR-20180720-1150
Description
IDR meeting session at IETF102
2018/07/20 1150
https://datatracker.ietf.org/meeting/102/proceedings/
C
B
Okay,
so
we
actually
are
starting,
and
we
have
a
note
well.
This
is
the
last
time
you
have
to
note
it
well
this
week,
I
mean
unless
you
want
to
go
back
to
the
privacy,
your
own
hotel
room
and
note
it
well,
some
more
that's
up
to
you,
but
as
usual,
we
have
IPR
rules,
and
your
lawyer
really
wants
you
to
know
what
they
are.
Even
if
you
don't
find
that
kind
of
thing
interesting
today,
it's
not
Thursday
so
we're
skipping
over
these.
D
Okay,
John
sending
me
me
these,
because
I
wrote
them
I
tried
to
put
pretty
pictures
in
it's
the
last
day.
You
want
to
see
pretty
pictures
right.
So
thank
you
for
your
patience.
You're
working
group
chairs
tried
to
plan
up
the
last
year
year
and
a
half,
but
we
had
perfect
of
personal
things,
so
please
we're
trying
to
still
catch
up
if
we've
dropped
your
draft.
If
there's
some
one
regime
cost
me
last
night
and
reminded
me
of
something:
I've
got
a
spreadsheet,
but
maybe
something
felt
off.
Please
come
talk
to
us.
D
Please
tell
us,
and
this
email
send
it
directly
to
us
we're
still
trying
to
catch
up,
and
you
know
beat
us
over
the
head.
We're
happy
to
have
that
happen,
although
maybe
so
this
was
a
little
comic
side.
We
have
two
drafts.
Alvaro
is
draft
ITR
prefix
SIV
considered
to
be
at
the
RFC
editor
still
in
process.
D
Alberto
was
saying
you
just
in
my
mind,
got
it:
we
have
these
following
draft
past
working
group
last
call
and
to
implementation,
which
means
our
review
team
chairs.
G
are
working
hard,
I
may
tag,
some
of
you
and
John
may
take
some
of
you
for
a
targeted
group
view.
So
if
you
get
a
question
from
the
chair
saying,
would
you
please
review
this
document
and
it's
outside
of
our
routing
Directorate?
We
are
sometimes
trying
to
help
our
speed
up
process
by
asking
targeted
reviews
good.
B
Speaking
of
asking
for
volunteers,
we
periodically
and
sort
of
gently
suggest
that
if
you
want
to
volunteer
as
a
document
shepherd
that
would
be
great
we
usually
have
to
you
know,
then
like
push
people
away,
because
we
get
so
many
volunteers.
I
wish
I
were
serious,
but
I
will
just
repeat
that
if
you
should
like
to
volunteer
as
a
document
shepherd,
it's
a
very,
very
valuable
function,
your
working
group.
Well,
thank
you.
The
documents
will
move
forward
faster.
D
What
I
wanted
your
patients
up
is
when
you
get
through
working
group
last
call
there's
lots
of
things
to
get
through
before
you
finish
the
RFC.
If
we're
ahead,
we
sometimes
send
these
ahead,
like
routing
Directorate
review
ops,
to
review
sometimes
for
Security
Review
than
other
Shephard
comments.
So
please
be
patient
with
us
as
we
get
through
that
race.
We're
racing
with
you
were
your
sport
team.
Okay,
we
do
need
to
implementations
for
these.
The
draft
ID
our
TP
is
what
I
want
to
highlight.
If
you
know
of
implementations,
tell
me
please.
D
John
and
I
meet
are
following
the
rules.
These
are
upcoming
working
group
call.
John
has
an
IPR
call
for
flowspec
interface
set
the
BGP
model
I
mentioned
yesterday.
I
believe
care.
Did
we
get
through
all
the
cleanups
on
that?
Okay,
so
that
will
go
for
working
group.
Last
call,
probably
sometime
this
evening
when
I
touch
down
at
some
flight.
Okay,
special
entrance,
we
had
the
open
leak
throughout
link.
Open
policy
I
need
to
see
a
hand.
We
have
had
several
positive
extended
message
calls
just
as
a
help
to
the
chair.
D
How
many
people,
but
how
many
people
don't
want
to
see
extended
messages,
go
to
working
group
last
call
again
hum.
Please
I'm,
hearing
silence:
okay,
we
will
go
another
round,
there's
a
flow
spec
draft
bgp,
LS,
BG,
page
star,
four
segment,
routing
and
operator
graphs.
Now
do
we
need
to
process
for
the
operators?
John
and
I
would
like
feedback
if
there's
anything
that
we
need
to
fast-track
okay,
I
think
I've
gone
through
the
rest.
You
can
read
it
in
your
mail,
Joe
Alexander
turn.
B
F
It
less
so
one
more
time:
Alexander
zoom
of
curator
lips
and
today
I'd
like
to
talk
with
you
about
a
local
preference
and
since
changing
recently,
so
originally
local
prefer
a
preference
was
a
representation
of
local
policy,
but
we
are
getting
new
functions,
new
default
policies
and
it
it
is
affecting
the
way
local
preference
is
protests.
So
we
may
have
a
default
policy
that
is
applied
when
the
route
is
received.
F
After
that
we
will
have
a
route
map
that
will
change
our
results
of
this
default
policy,
and
after
that
we
will
have
another
default
policy
that
will
provide
us
a
result.
So
for
me
it
seems
that
such
chain
of
changes
where
parties
are
totally
ignoring
each
other
can
provide
some
kind
of
unpredictable
results
with
ongoing
debugging
issues
and.
F
Of
course,
the
problem
is
that
we
need
default
policies.
We
need
to
apply
some
of
them
in
code
to
guarantee
r2
aware
that
there
are
no
fat
fingers
and
so
on
so
and
so
on,
but
maybe
we
should
avoid
applying
default
policies
after
route
maps,
because
it
makes
the
situation
really
unclear
and
instead
of
encoding
different
types
of
fruits
inside
single
non
transit
attribute,
which
had
different
purpose
at
the
moment
at
the
beginning.
F
Maybe
we
should
do
it
in
other
way,
so
it
there
is
no
draft.
It's
just
an
idea
that
I
want
to
share
with
you,
and
maybe
there
is
no
problem,
and
you
will
tell
me
about
it.
So
what
is
on
top
of
BGP
decision
process?
We
will
add
something
like
a
route
type
and
with
next
comparison
inside
this
route
type
will
be
also
used
as
in
the
default
policies,
and
currently
it
will
solve
all
situations
when
we
need
to
override
local
preference
after
route
maps.
G
G
And
I'm
not
I'm,
not
aware
that
any
recent
thing
really
asks
for
that.
I
think
I
think
the
proposals
that
are
around
so
far
are
essentially
saying.
Well,
okay,
if
you
see
that
signaling,
you
should
apply
certain
policy
like
setting
local
draft
to
zero,
but
it's
as
far
as
I
as
far
as
I
understand,
the
assumption
is
that
that's
actually
done
in
locally
configured
policy
and
I
would
not
like
to
see
that
any
implied
manipulation
of
attributes
is
done
anywhere.
G
It
may
be.
It
may
be
an
interesting
thing
to
consider
asking
vendors
to
provide
kind
of
simple
calls
to
standard
policies
that
can
be
called
up,
but
and
for
stuff,
like
you
have
there
well,
okay
in
my
environment,
I
would,
if
I,
if
I,
have
different
things
for
setting
local
pref
I,
probably
would
be
setting
also
some
internally
defined
community.
That
tells
me
exactly
the
context
and
kind
of
kind
of
yes.
I
can
see
pointing
something
like
back
to
Ignace
story
about
the
take-up
of
young
models.
G
Applying
his
kind
of
20/80
rule
there
certainly
are
is
a
majority
of
networks
out
there.
That
is
not
used
to
more
sophisticated
policy.
Like
I
think
has
to
be
done,
and
that
has
to
be
considered,
but
I
think
that
should
be
addressed
by
something
like
providing
those
guys
with
calls
to
a
standard
policy
library,
rather
than
forcing
everybody
to
to
rely
on
their
vendors
to
do
exactly
the
right
thing.
Let
me
let
me
just
remark:
I
have
seen
no
export
not
being
recognized
by
vendor
software
in
certain
corner
cases.
Okay,
to
note.
First.
F
One
reader
I
can't
say
that
I
totally
agree
that
there
should
be
no
enforcement
in
the
code,
because
otherwise,
okay
I'm,
pretty
sure
that
Deutsche
Telekom
will
be
capable
of
doing
whatever
they
want
with
the
communities
with
signals
and
so
on,
I'm
pretty
sure
about
that
entity,
I'm,
not
pretty
sure
about
other
50,000
our
eyes
piece.
Another
note
is
that
I've
just
checked
one
of
the
open
source
software,
which
is
FRR
and
in
this
software
the
local
policy
is
already
over
writen.
B
B
Then
in
you
know,
like
ITF,
twenty-something
and
I
think
we
still
have
exactly
the
same
I
think
you're
you're
talking
about
exactly
the
same
issue
as
we
were
talking
about
then,
which
is
that
having
a
whole
bunch
of
different
criteria
and
trying
to
map
all
of
those
into
a
single
unit.
32,
you
lose
a
bunch
of
context
and
you
potentially
overwrite
one
another
and
I
think
Ruettiger
just
expressed
the
the
view
that
prevailed
then,
which
was
if
you
have
a
complicated
set
of
criteria
great.
We
have
a
complicated
policy
language.
B
E
Thank
you
for
coming,
who
are
we
technologies?
Speaking
for
myself,
just
want
to
echo
what
John
just
said:
I
think
that
yeah,
the
custom
community
dress,
I
think
addresses
some
of
this.
We
would
let
you
add
indicators
into
the
selection
process.
That
would
tell
you
in
battle
it
back
up.
You
know
other
things
around
that
the
draft
is
expired.
It's
not
on
your
list,
because
I
haven't
had
the
time
to
go,
rub
it
again,
but
I
will
just
so
that
it's
there
just
in
case
there
are
a
couple
of
implementations,
but
that's.
F
Thanks
yep,
but
I
would
like
to
repeat
that
my
main
concern
main
concern
that,
on
one
hand,
we
need
default
policies.
I
do
believe
that
we
really
need
them
Rudy
or
may
not
need
them,
but
the
community
may
need
them
really
much.
At
the
same
time,
the
default
policies
that
are
overriding
route
maps
gives
me
very
uneasy
feelings,
good.
G
A
fog
again,
I
think
I
think
that
a
concept
like
providing
a
library
of
standard
of
standards
prepared
policies
to
be
called
up
would
be
a
really
good
thing
for
helping
those
who
want
who
are
not
able
or
do
not
want
to
be
to
do
complicated
policies
all
themselves
and
okay.
If
I
had
such
a
library,
even
I
might
call
on
it
in
certain
cases,
but
really
really
really
understanding
exactly
what
happens
and
having
the
choice.
Myself.
F
B
H
Has
so
we're
running
into
really
two
different
things
here
is
like
one
of
the
things
we're
running
into?
Is
that
the
number
space,
despite
the
fact
that
is
gigantic-
has
gotten
a
little
bit
crowded
because
of
a
lot
of
defaults
that
we
had
from
very
early
in
the
days
and
this
actually
caused
issues
as
far
back
as
like
the
mid
stuff,
the
second
place
that
this
is
a
little
bit
messy,
is
that
what
we're
generally
describing
is
that
now
we
have
this
nice
procedure
inside
of
there
RFC's
and
say
here's
the
tiebreaking
process.
H
It's
well
understood.
People
know
where
things
go.
Go.
We
don't
really
have
something
that
is
very
similar
in
terms
of
run
policy
here
and
other
protocol
extensions
are
going
to
have
influence,
that's
going
to
have
impact,
so
we
talked
about.
For
example,
grace
will
shut
down
wanting
to
twiddle
with
the
local
preface
an
example.
We
have
know
our
cases,
for
you
know
the
stock
validation
wanting
to
do
things.
We
have
cases
we're
talking
about
here
that
have
similar
impact
and
what
might
be
a
useful
document
to
write
and
will
probably
be
the
reason
for
us.
H
The
Torah
hero
for
the
next
decade
is
simply
write
down
some
sort
of
abstraction
of
know.
The
tib
is
they
used
to
be
called
back
in
the
day
and
where
the
interaction
points
are
and
simply
enumerate
that,
even
if
people
don't
actually
implement
that
everything
means
they're
at
least
talking
about
the
same
thing.
H
I
So
the
last
update
was
presented
in
ITF
98
and
since
then
there
have
been
a
few
revisions.
We
added
a
number
of
things
in
these
revisions
would
like
to
collect
feedback
and
comments
from
the
workgroup
about
the
updates,
so
just
to
quickly
recap:
on
the
BGP
signal
segment,
routing
policies,
this
draft
really
defines
method
to
signal
segment.
Routing
policies
by
a
BGP
protocol
BGP
happens
to
be
signaling
a
candidate
path
of
the
SR
policies.
There
are
other
methods
to
program
the
candidate
paths
for
the
policy
such
as
PCF
and
locally
configured.
J
I
I
So
in
last
few
revisions
there
have
been
some
updates,
and
here
is
a
summary
of
updates.
So
first
thing
we
added
is
segment
types,
9
10
11,
to
cover
the
SR
v6
segments.
This
is
to
align
with
the
SR
policy
architecture
described
in
the
SR
policy
architecture
draft
in
screen
working
group.
We
also
corrected
the
C
type
3
unit
definitions
to
again
to
align
it
with
the
definitions,
mentioned
information
model
of
the
segment's
mentioned
in
the
circle,
C
architecture
and
its
few
news.
I
A
few
news
of
TL
B's
under
the
tunnel
type
s
our
policy
to
define
symbolic
name
to
assist
and
debugging
in
troubleshooting,
and
this
is
also
available
in
other
methods
of
signaling
the
candidate
path
added
as
a
policy
priority
sub
TLV.
This
is
to
provide
to
attach
a
priority
to
segment
routing
policies
signal
by
BGP
and
this
assistant
defining
priority
order
in
which
the
policy
should
be
converged
upon
the
topological
changes,
and
then
we
added
extra
signal
level
policies
of
TLV.
I
I
Okay
sure
thank
you
in
in
segment
type
definitions
from
three
to
a
eight.
We
added
field
to
to
add
SR
flex
algorithm
is
specification
so
that
on
the
head
and
a
prefix
can
be
resolved
to
a
specific
set
based
on
the
SR
flex.
Algorithm,
we
added
a
couple
of
new
flags
in
segment.
Types
of
TLV
first
is
V
flag.
This
is
to
enable
the
verification
of
set
supplied
by
the
controller
a
controller.
I
This
is
to
take
care
of
the
situation
when
controller
supplied
a
set,
but
hadn't
is
also
is
resolving
the
set
based
on
the
the
layer
that
it,
the
TE
D
we
available
to
it
and
operator,
would
like
to
would
like
headin
to
very
verify
whether
the
said
supplied
by
the
controller
matches
with
the
had
in
calculation
or
not
more.
Details
on
this
is
available
in
suitable
section
in
ASA
policy
architecture.
I
Draft
so
I
would
recommend
you
to
take
a
look
at
it,
edit,
a
flat
to
enable
the
SR
algorithm
bit
that
was
mentioned
shortly
before
then
in
binding,
said,
two
new
flags
are
added
as
flag
and
I
flag
as
flag
is
to
specify
to
enforce
the
behavior
of
a
specified
binding
set.
Only
that
means
if
the
binding
set
is
supplied
by
the
controller
and
headin
cannot
really
allocate
it.
It
should
not
try
to
locally
allocate
a
dynamic,
binding,
said
I
flag
is
to
enforce
a
drop
upon
invalid
behavior.
I
I
It's
so
next
up
a
dress
length
specification
is
being
tidied
up
earlier.
It
did
not
take
care
of
ipv4
and
ipv6
next
tops
in
in
in
either
Safi.
There
were
some
restrictions
defaults
for
policy
preference
and
weight
parameters
have
been
corrected.
Now
we
aligned
with
us
our
policy
architecture
draft
with
respect
to
the
defaults,
and
then
there
have
been
several
updates
in
various
sections
to
align
the
section,
references
and
terminology
with
segment
routing
policy,
architecture
draft
and
the
scim-immodule
policy
architecture.
I
So
as
next
steps,
we
would
like
to
address
any
comments
and
we'll
make
requests
for
in4
points
for
newly
defined
sub,
tlvs
and
flags,
and
then
we
think
it's
getting
ready
for
work.
Group
last
call
because
it's
fairly
mature,
but
based
on
the
feedbacks
coming
from
architecture
draft
and
after
the
adoption
of
architecture
draft.
Whatever
changes
may
be
required
in
VG
PT
draft.
We
would
accordingly
make
changes.
L
I
understand
nokia.
This
is
not
a
comment
on
this
draft
specifically,
but
in
the
wider
scope
of
things,
is
there
any
plans
on
advertising
the
acceptable
range
for
binding
said
that
can
be
used
for
the
head
end:
advertising
the
binding
side
range?
Yes,
so,
for
example,
if
you
have
a
controller
that
wants
to
push
down
a
binding
said
well,
what
label
range
should
that
controller
use,
for
example,
dedicated
specifically
for
this
purpose,
so.
M
Just
in
serie,
so
it
could
be
or
use
the
for
for
people
who
read
it.
You
provide
a
way
to
understand
how
feedback
loop
works,
because
machinery
scattered
across
different
drafts,
so
some
of
them
are
the
t
LSP
distribution.
There
are
some
other
stuff
that
provides
information
about
whether
resources
have
been
allocated
well,
there's
been
any
errors
so
having
references
where
you
define
how
you
do,
it
would
be
very
useful
from
structure
perspective.
Sure
thank
you.
D
One
thing
to
add
to
your
to-do
list
before
working
group
last
call
is
to
fill
in
the
security
considerations
on
this
on
this
particular
graft.
I'd
really
like
to
see
that
before
we
do
working
group
adoption,
because
there
will
be
policy-
is
always
one
of
those
things
please
put
in
the
security
sure.
N
A
San,
Jose,
fer
new
Kia
I,
have
a
general
comment.
This
regarding
signaling
as
a
policy
through
BGP
is
great,
but
it
the
consequence
has
some
issues
that
we
don't
have
it
in
P
sub,
for
instance.
One
is
that
there
is
no
feedback
that
there's
a
policy
words
actually
installed
so
I
know
there's
another
draft
addressing
that
which
pls
through
which
occurs,
but
the
other
one
is
that
if,
if
the
controller
is
appealing
with
rad
reflector,
there
is
no
way
for
controller
to
know
that
actually
these
routers
can
support
this.
I
N
I
B
N
B
Okay,
so
so
then
Andrew,
if
you
want
to
answer
that,
go
ahead
but
I
generally.
My
my
comment
here
is:
it
sounds
like
you
have
a
specific
puzzle,
send
text,
it's
a
working
group
document.
It's
you
know
it's
your
document
as
well
as
his.
If
you
have
a
proposal
for
how
to
change
it,
you
know
send
text
to
the
list
sure
sure.
O
B
K
Go
tell
our
cuz
I
just
wanted
to
say
that
you
know
I
had
given
the
same
comments
to
you
off
line
and
I.
Think
it'd
be
nice
to
have
a
section
here
that
describes
route
reflected
in
forwarding
path
versus
a
route
reflector
off
forwarding
part,
and
what
are
they
supposed
to
do?
Assuming
the
peering
correction
goes
through
the
route
reflector
to
the
client
versus
controller,
connecting
it
directly
to
a
Breezer
sure.
D
I
So
say,
bgp
signal,
routing
and
data
model
can
be
used
to
configure
and
manage
the
SR
extensions
in
BGP.
0/0
version
was
submitted
few
weeks
before
hi
f-102.
What
it
covers
right
now
is
prefix.
It
extensions,
egress,
PD
engineering,
extensions,
BGP
signal
as
our
policies,
extensions
in
the
context
of
BGP
automatic
steering,
related
extensions
and
SR
v6
VPN
extensions,
and
for
each
of
these
technologies,
the
corresponding
references
are
mentioned
here,
and
this
model
will
be
evolved
to
cover
more
and
more
SR
extensions
as
in
subsequent
revisions.
I
I
We
import
lot
of
common
data
types
from
routing
common
data
type
RFC,
and
it
is
also
expected
to
import
and
augment
sr
specific
data
types
from
either
base
sr
young
model
in
case
of
sr
policies,
basis
our
policy
model
and
sr
v6
young
model,
so
the
fix
it
will
not
go
into
too
much
details,
but
what
it
covers
really
is
in
the
context
of
young
model
is
two
things:
one
is
ability
to
set
a
label
index
with
her
out.
That
is
an
augmentation
in
route
policy
model,
then.
I
Secondly,
its
power
route,
state
information
related
to
the
perfect
set
that
is
received
with
every
doubt,
USB
or
engineering.
The
configuration
in
the
state
parameter
for
EP,
which
are
related
to
peer
node
set
here.
Adjacency
said
and
peer
set
set
also
a
static
and
dynamic
IP
configuration
and
backup
policy
and
associated
backup
set
configuration,
and
these
are
all
defined
by
define
shinto
neighbor
container
in
the
bait
from
the
base
be
GP
model
segment,
routing
policies
in
the
context
of
BGP.
I
I
In
interest
of
time,
our
way
to
the
end
of
the
talk
keep
going.
Ok
sure,
then
the
state
of
BGP
signal
is
our
policy
explicit
candidate
paths,
then
on
demand
s
our
policy,
candidate
paths
triggered
by
BGP
and
then
the
overall
s,
our
policy
state
in
the
context
of
BGP
to
support
automatic
steering.
So
for
s
our
explicit
policies.
It's
really
the
routes
on
the
Saffir
outs,
which
are
modeled
here,
and
I
would
like
to
point
out
that
the
lot
of
the
details
about
the
SL
policies,
such
a
segment
lists,
etc.
I
We
will
be
importing
those
from
system
s
or
policy
model,
but
very
basic
details
are
added
here
for
on-demand
policies.
There
are
two
things
set
of
authorized
policy,
colors
for
which
BGP
is
authorized
to
trigger
the
on
demand
policies
which
are
actually
instantiated
by
collaboration
with
PC
on
the
head
end
and
then
the
list
of
actual
instantiated
candidate
paths
in
the
context
of
BGP.
I
So
the
containers
are
and
lists
are
added
for
this
under
global
BGP
mode
again
from
the
base,
BGP
model
for
automatic
steering
visible
maintains
a
so
policy
state
overall,
regardless
of
the
method
of
instantiation.
Of
the
policy
and
then
when
it
receives
the
color
exchange
community
with
the
route
it
it
binds
that
route
to
the
SR
policy
binding
said
so.
The
useful
information
here
in
the
context
of
young
model
is
showing
the
state
of
steering
and
which
policy
that
out
is
staring
over
with
each
overlay
route.
I
So
what
we
did
is
the
suitable
address
family
list
entries
are
extended
here.
Per
route.
Information
is
added
with
a
new
container
for
automatic
steering
and
there
are
leaf
refs
to
the
sir
policy
state
for
SR
v6.
The
extensions
are
of
two
kinds:
one
is
a
service
exceed
allocation
mode
and,
secondly,
the
state
of
receive
set
and
local
sets
in
the
context
of
per
VPN
route.
I
So
this
is
what
it
covers
right
now
in
the
zero
zero
version,
and
there
are
several
DVDs
and
there's
bit
of
alignment
with
base
PGP
model
also,
and
we
have
to
import
the
SR
policy.
Specific
data
types
from
system
is
a
policy
model,
so
that
is
our
next
step
to
take
care
of
all
those
and
submit
the
revisions,
and
then
we
would
like
to
request
a
detailed
review.
Ok,
my
comments
thing.
B
D
Please
make
sure
to
also
work
with
the
rtw
G
group
on
the
policy
and
make
sure
you
harmonize
with
that.
Second,
please
look
at
Aires
extension
draft.
That
was
our
intended
for
the
BGP
model.
Perhaps
you
can
harmonize
and
get
a
bit
more
of
your
space
out.
Better,
better
refactoring
means
better,
a
better
question
and
the
last
are
you
basing
this
on
any
other
traffic
of
traffic
studies
outside
of
spring?
You
have
use
cases
in
spring,
but
do
you
have
non
use
cases
for
this
spring
use
cases
for
this?
I
So
forth
to
your
previous
points
policy.
Yes,
there
are
policy
related
extensions
in
this
in
the
context
of
SR
extensions
in
BGP,
and
the
approach
I
have
taken
is
to
define
this
in
this
model
instead
of
base
BGP
or
routing
policy
model,
but
it's
really
augmenting.
The
policy
constructs
from
the
policy
model
and
I
think
I'm
open
for
suggestions.
If
that
is
not
the
right
approach,
then
I
would
take
a
look
at
the
extension
BGP
extension
model,
especially
for
the
Beav
structure.
I
If
it
becomes
available
there,
then
the
structure
from
here
can
be
removed
in
rather
the
suitable
list
from
a
BGP
extension
model
can
be
used.
The
last
comment
is
yes,
it
is
in
the
context
of
spring,
because
this
is
a
segment
routing
related
extensions
in
BGP.
But
are
you
saying
that
this
should
be
no
I?
Just
talked
to
the
I?
May.
M
Thank
you
just
answer,
Scioscia
just
my
first
comment:
we
are
trying
to
align
all
the
policies
we
do
in
single
document,
rather
than
trying
to
using
worst
policy
in
BGP
document.
That
doesn't
mean
policies,
horrible
thing
to
do
really.
Can
we
call
it
something
else?
Our
policy
policy
restart
its
its
BGP.
We
know
what
policies
in
BGP
do
this
thing
is
not
policy
right.
No.
M
Establish
it
started
amending
your
wording
has
become
really
messy,
because
when
we
talk
about
the
GP
policy
mean
something
different
than
this
right,
so
BGP
policies
BGP
route
policy.
Yes,
so
if
you
name
it
somewhat
different,
you
had
something.
So
we
could
at
least
differentiate
when
it's
BGP
policy
versus
it's
our
policy.
Sure.
M
M
I
Common
common
types-
yes,
this
actually
uses
it
whatever
is
available
in
the
RFC.
It
does
use
to
the
extent
whatever
is
available
there
and
I
think
there
is
base
segment
outing
model
by
the
routing
young
architecture
team,
so
I
plan
to
use
things
from
there
as
well
order
effect,
would
be
making
request
to
add
common
data
types
there.
So.
M
J
So
here
I
make
sure
petition
for
the
pgpa
education,
for
the
interests
approaching
show.
This
is
the
second
time
tool
for
his
topic.
He'll
have
that,
based
on
the
comment
from
the
last
media,
the
content
of
the
first
digest
came
to
the
senior
reveal
and,
secondly,
update
the
solution.
The
sir
these
proposed
VDP
are
education
here.
I
just
give
the
signal
simple.
Since
Livia
Livia,
you
know
in
our
network.
J
We
have
a
one
bankable
and
hundreds
of
men
are
ITC
which
are
interconnected
with
many
bunch
of
links
when
we
deployment
the
PC
or
Sdn
controller
in
our
network.
We
want
to
collect
the
topology
within
each
domain
and
the
interconnecting
information
between
different
domain.
So
we,
this
is
the
senado
whether
we
want
to
so
one
two.
So
we
can
simply
simplify
this
now
in
the
in
to
the
graph
in
the
right
graph
as
a
user,
one
controller
to
get
the
table
information
from
different
amia
and
different
domain.
J
The
underlying
tamiya
measure
on
different
ITP
protocol
or
measure
on
the
distribute,
the
traffic
engineer.
So
the
controller
Callie
easily
gets
the
information
released
Amir
why
the
people
has
a,
but
there
are
some
some
more
steps
to
be
finished
to
on
against
the
interconnects,
and
you
can
interconnect
and
table
information
between
different
amia.
J
J
You
so
just
kill
our
solution.
This
is
certainly
the
update
from
the
last
meeting
very
key
resource
on
for
the
two
different
scenarios.
The
first
is
from
for
the
snare
in
HIPAA,
naturally
snarl.
The
second
is
for
the
interest
TVs
now
for
the
nativist.
Now
you
know
we
need
to
do
two
steps
to
get
the
inter
interest
interest
table
information.
The
first
thing
is
the
pseudo
led
support
the
inner
interest,
interconnect
links
that
were
as
alkyl
protocol,
because
we,
we
are
not
wrong.
J
J
The
second
solution
is
for
the
interest
is
now
a
mess,
and
there
are
two
are
see
how
to
find
the
some
TLO
way
to
transfer
the
interest
in
us
link
information.
But
these
information
are
not
reported
to
the
controller
why
the
PTR
so
her,
which,
as
a
proposal,
extend
the
beach
versatile
transfer
this
information.
J
So
after
the
PC,
you
can
PCOS
taken
together
this
information
and
they
can
get
the
progeny
contraction
accordion.
That
is
crippling
unity
slide.
The
first
thing
that
he
is
now
14
narrow
the
construction
process
is,
is
simple,
because
the
controller
has
longer
a
number
and
I
PVC
I.
Believe
I
mean
six
notoriety
at
associated
healings.
This
information
has
been
reported
in
the
btrs
and
Twitter
is
newly
reported.
The
human
saw
that
the
proper
units
after
the
I
steam
controller
cannula
deconstructed
the
interest
that
ecology
information
and
foreign
on
key
sir
sinara.
J
It
may
be
more
complex
for
the
contractor
the
interest
project.
The
the
first
process
is
a
descriptive
kisi
collected
Tara
information
is,
respectively
in
different
domain
and
the
issue
SP
REO
in
support
the
interest
linker
to
int,
which
domain
and
the
we
use
local
node
at
associated
with
the
provisions,
can
carry
the
original
information
of
this
interest
link
so
Basilica
anchor.
This
is
prefix
to
correspond.
Sdr
after
carries
information.
The
PC
can
they
control
the
interest
project
when
comparing
the
prefix
and
their
anchors.
J
This
process
is
also
same
for
the
interest
OSPF
top
rosetta.
We
have
prayed
in
Monday
for
the
supported
construction
process
a
similar
process.
So
here
we
just
want
to
know.
Is
there
any
new
comment
for
in
solution
and
if
you're
there?
You
know
new
comment.
They
want
to
ask
the
group
for
the
adoption
pool
yep.
B
B
O
M
M
O
Hi
Kate
ontological
Cisco
we're
presenting
this
on
behalf
of
the
quarters.
This
is
an
update
to
the
t,
LSP
distribution,
which
is
a
working
group
document.
What
what
this
document
does
is.
It
introduces
a
new
BG,
pls,
n,
NR,
I
type
for
T
policy.
Advertisement
covers
different
types
of
T
policies,
rsvp-te
segments,
routing
and
also
local
cross
connects
it
basically,
you
know,
indicates
the
path,
T
policy
path,
details
and
status,
the
major
updates
in
version-
oh
nine-
was
really
aligning
the
segment
routing
policy.
O
With
the
document
architecture
document
that
was
adopted
by
spring,
the
descriptors
have
been
descriptors
of
the
SR
policy
have
been
updated
to
align
with
the
SR
policy
architecture
and
the
attributes
have
been
updated,
not
just
to
advertise
the
segment
list,
but
also
other
key
attributes
and
status
of
the
SR
policy.
This
really
gets
some
sort
of
operational
kind
of
a
feedback
loop
when
it.
When
you
talk
about
signaling
via
BGP
SRT,
there
are
also
editorial
changes
and
edits
in
the
document
and
a
bit
of
section
reorganization.
Just
for
better
clarity.
O
There
are
multiple
TL
ways
introduced,
some
of
them
existed,
but
they
have
been
updated
to
signal
the
state
of
the
SR
policy.
There
is
the
binding
set
TLV
which
gives
the
binding
said
that's
in
use
and
also
some
other
details
like
whether
it's
belongs
to
srl,
be
the
status
and
so
on.
Then
there
is
a
candidate
path,
state
TLV,
which
actually
indicates
whether
that
particular
candidate
path
is
active.
It's
validation
status,
how
it
was
instantiated,
whether
you
know
PC,
initiated,
delegated
and
and
other
attributes.
O
We
also
included
s
our
candidate
path,
name
TLV,
because
that's
quite
useful
to
reference
to
our
policy
as
our
candidate
path
constraints,
which
in
which
is
in
use,
are
associated
with
the
candidate
path
is
also
signaled.
Here
there
are
multiple
constraints,
including
things
like
algorithm,
which
is
reported
now.
O
The
segment
list
TLV
has
been
updated
to
associate
or
describe
not
just
segments,
but
also
additional
information
about
how
the
path
was
computed,
whether
it
was
done
dynamically
or
was
it
an
explicit
path?
The
validation
of
the
said
wait
algorithm,
so
all
of
these
have
been
added
new
D.
Then
the
segment
TLB
itself
it
has
been
updated
to
require
reflect
all
the
segment
types
that
are
defined
in
the
SR
policy
architecture.
O
The
PG
pass
our
policy
draft,
so
the
reporting
wire
this
is
applicable
for
all,
regardless
of
what
is
the
source
origin
via
this
specification
and
the
procedures
also
described
which
attribute
TLV
is
to
use
and
how
to
advertise
the
state
of
the
policy.
So
there
are
a
significant
changes
to
the
SR
policy
reporting
aspect
so
would
request
the
working
group
to
review.
It's
also
been
requested
in
spring
and
appreciate
any
feedback
and
would
also
request
for
early
code
point
allocation,
so
that
we
can
have
implementations
for
this.
M
And
comment
to
your
presentation
so
anytime,
you
are
the
worst
eyes.
Something
would
be
good
if
you
reference
how
you
learn
it
and
with
regards
to
data
modeling,
we
should
consider
statute
conciliation
out
sighs
device
self,
because
now
we
are
getting
operational
state
that
is
not
on
the
device
itself
and
need
to
be
able
to
be
compared
to
configurational
state.
O
O
We
have
flexible
flex,
algorithm
extensions
in
IGP.
It
allows
really
IDPs
to
perform
constraint,
based
topology
computation
for
a
specific,
optimization,
objective
or
metric
type,
and
each
flex.
Algo
has
certain
definition.
Now
that
flex,
algo
definition
is
applicable
in
a
specific
IP
domain
and
we
have
scenarios
or
use
cases
where
the
PC
or
a
controller
learns
the
IP
topology
from
multiple
domains
and
needs
to
compute
end
to
end
as
our
policy
paths
across
them.
O
Now,
if,
along
with
the
topology,
if
the
PC
or
controller
also
understands
or
knows
what
is
the
definition
of
the
Flex
algo
in
a
particular
domain,
then
it
that
allows
it
to
pick
the
right
flex,
algo
seeds
for
forming
as
our
policy
with
a
smaller
seed
stack
across
multi
domain.
So
this
extension
is
really
to
be
able
to
give
that
flex,
algo
definition
from
a
particular
IGP
domain,
why
a
BGP
LS
to
the
PC
or
controller,
so
the
Flex
algo
definition
is
already
advertised
by
routers
one
or
more
routers.
O
In
a
domain
there
is
a
LSR
spec
which
does
this
in
for
both
OSPF
and
ISS.
This
graph
simply
proposes
to
advertise
the
same
as
part
of
node
attribute
by
a
bt
pls,
so
that
the
pc
or
controller
can
get
this
information.
So
there
is
really
the
flex
algo
definition
TLV,
which
is
signaled
as
an
attribute
of
the
node
and
NRI,
and
then
there
are
sub
TL
ways
to
convey
the
affinity
constraint.
This
is
very
much
in
line
with
the
base
igp
spec,
so
just
the
first
version
would
working
group
preview
and
any
feedbacks.
O
O
O
Again,
there
are
similar
to
the
previous
case.
There
are
use
cases
where
we
need
to
have
the
ability
to
discover
the
SPF
field
discriminators
across
IGP
domains,
this
seamless
MPLS-
and
there
is
also
as
our
policies
spanning
multiple
domains.
So
we
need
to
have
the
ability
to
learn
the
SB
of
T
discriminators
so
that
end-to-end
SPF
D
monitoring
can
be
done.
So
what
this
graph
does
is
really.
O
O
P
H
H
This
is
where
I
tried
to
give
the
working
group
four
minutes
back.
So
we
have
a
draft
on
extending
flows
back
to
Carrie
interface
sets
know,
basically
what
filters
and
what
interfaces
and
which
direction
a
flowspec
rule
set.
Snow
covers
Jeff
Houston
to
gave
us
a
substantial
feedback
our
last
year
on.
Oh
three,
a
lot
of
his
comments
were
basically,
this
is
weird
Sdn
stuff,
I'm,
not
sure
what
you're
doing,
but
the
actual
features
no
very
straightforward.
So
we
just
simply
simplified
things
to
the
base
use
case.
H
We
don't
actually
change
any
of
the
functionality
you
know
between.
Oh
four,
oh
four
from
oh
three,
we
do
add
the
comments
about
the
Ino
points
that
had
been
reserved
for
us.
We
have
exactly
two
open
issues
in
terms
of
how
we
should
actually
handle
the
Arabic
behavior
when
the
O&I
bits
are
both
left
to
zero.
We're
gonna
change
the
text
to
say
that
the
route
can't
become
active
and
that
should
be
treated
as
withdrawal.
The
text
is
silent
on
what
we
do
about
the
treatment.
The
a
s
number
field
in
there.
H
Nokia's
implementation
currently
ignores
this.
It's
interfaces
treated
basically
as
wild
card
es
group.
We
will
need
to
have
a
little
bit
of
discussion,
ideally
with
working
group
participation
as
to
what
we
should
do
here.
As
that
point
we'd
like
to
get
these
last
two
issues
cleared
out
and
then
resume
the
last
call
process.
Q
Q
The
extension
of
BGP
to
advertise
as
a
policy
is
defined
in
the
draft
idea,
our
Sacramento
routing
key
policy,
which
is
has
been
which
has
been
introduced
in
the
previous
presentation,
so
to
support
the
use
cases
such
as
like
performance
measurement
and
processes
and
engine
1+1
protection.
The
post
identification
is
required,
but,
however,
in
essa
amperes
the
egress
nodes
can
note
it
mean
the
the
pass
which
the
packet
come
from
so
since
is
no
label
on
the
last
label
were
remained
in
the
packets,
so
so
so
regress
can
no
understand
so
for
solve
this
problem.
Q
Similarly,
we
proposed
an
the
sixth
post
I
teach
island
I
didn't
identify,
identify
an
S
apart
as
a
v6
post
in
draft,
please
bring
passive
p.m.
for
an
office,
6:00
p.m.
so
for
advertising.
The
post
ID
information
with
Zenon
HP
as
a
policy
that
the
new
extension
is
required
right
also
for
collecting
the
post
ID
information
within
the
NASA
policy,
new
extension
in
which
PRS
is
knitted
as
well
so
propose
to
draft.
Q
So
second,
one
is
about
the
structure
of
our
segment
or
ID
in
Beach
PSAs.
Our
policy,
as
we
all
know
that
the
the
essa
policy
structure
in
PHP
has
been
defined
in
the
draft.
Ietf
idea
sack
my
routing
tea
policy
and
since
we
introduced
and
passed
segment
to
identify
the
pass
ID,
so
we
include
a
new
post,
ID
t
sub
gob
and
the
segment
least
tier
V.
So
this
is
the
format
of
the
post
ID
govt.
We
defined
several
flags
to
indicate
some
different
scenarios.
Q
Q
So
for
for
the
current
current
version,
we
divide
to
posterity
for
pairs
and
s
a
v6
network,
so
a
by
the
way
we
also
defined
as
a
policy
for
bi-directional
pause,
as
we
know
that
in
s
apart
in
essa
Network,
a
bi-directional
pass
can
be
like
represented
as
biding
of
to
you
dip
unidirectional
as
of
houses.
So
for
describe
this
kind
of
as
a
policy
we
defined
two
new
tell
T
RVs
the
first
one
is
bi-directional
past
year.
Sorry
and
the
second
one
is
reverse
a
segment
least
secure
V.
Q
So
the
second
draft
is
Li
idea
of
each
Pierre's
supports
upon
segment.
In
in
this
draft,
we
specifies
the
weight
of
collecting
the
configuration
and
stage
of
essa
policies
which
carries
the
posterity
and
by
rationale
pass
information
by
using
the
PHP
errors,
so
the
S
of
holes
can
be
like
described
by
the
the
key
policy
state
theory
to
fight
in
the
draft
we
mentioned
before
the
the
tdsp
distribution,
which
is
a
character
in
the
link
state
attribute.
Q
So,
rather
than
defined
the
new
theories,
we
reuse
the
equivalents,
sub
theories,
which
is
which
has
been
which
are
divided
in
the
draft
Lee
idea
as
a
holistic
document,
distribution
yeah,
which
is
the
previous
drafts
I
presented.
So
the
next
step
is
we
any
comments
and
confusions
are
very
welcome.
Thank
you.
R
Hi
everyone
I'm
from
hot
girl
from
who
are
they.
This
is
a
farewell
touch,
and
now
they
all
figure
18
seconds
and
the
happy
weekend
let's
go.
This
is
about
PPOs
extensions
for
advertising
pass
em
to
you.
This
is
a
background
and
problem
statement,
as
we
have
known
currently
and
q
is
not
included
in
the
second
row.
Team
vertical
and
Asami
contain
more
impurity
levels
as
the
Aristocats
headers
in
the
forwarding
packet
header,
and
this
may
lead
to
the
package.
R
Size
is
larger
than
the
traditional
package
and
without
the
MPO
information,
the
past
calculation
can
not
washer
the
park
besides
less
than
the
path
MTU,
especially
for
the
controller,
so
this
may
lead
to
in
the
Faculty
of
peridot
fragmentation
and,
in
our
say,
six
three
to
six
different
sub
theory
to
advertise.
The
link
MTO
in
Isis
domain,
the
Taleo
and
28
at
the
last
s3.
Under
this
new
draft,
try
to
differ
a
new
theory
to
end
the
fertile
the
MTU
value
through
pprs.
R
This
is
the
detailed
information
of
the
solution
and
the
format
of
the
structure
of
a
shown
at
below
the
title
field
to
be
defined
and
the
last
value
and
the
value
field,
the
consistent
with
our
GCS
3
to
6
and
also
whenever
there
is
a
changing
MTO
value.
The
PPR
through
the
edward
lee
atwater,
the
theory
to
the
controller
immediately
when
the
controller
can
calculate
the
path.
Mtu
nurse
steps
and
the
comments
welcome
co-authors.
M
M
S
Victor
coursing
just
more
like
a
question,
so
is
this
a
problem
that
we
perceive
will
likely
exist
in
SP
net
networks
because,
like
when
I
think
about
the
operator
networks,
the
label
stacking
that
typically
gets
you
to
a
large
increase
is
also
fully
controlled
by
that
SP,
which
typically
would
manage
their
MTU
across
our
network,
and
we
wouldn't
necessarily
expose
this
outside
of
the
domain.
So
is
this
something
where
we
have
operator
input
that
has
shown
that
this
is
likely
gonna
actually
happen.
Therefore,
we
feel
that
the
extensions
are
necessary
to
deal
with.
S
B
Okay:
well,
if
there
are
no
further
questions
or
comments,
I
believe
we
are
done.
So
thank
you.
Everybody
for
staying
till
the
bitter
end.
I
will
remind
you
that
we
are
planning
to
schedule
a
interim
to
talk
about
the
things
we
were
talking
about
yesterday.
If
you
have
any
suggestions
for
us
about
when
that
interim
should
shouldn't
be
scheduled,
and
all
that
you
can,
let
us
know
if
not
watch
your
email
thanks,
everybody
have
a
good
trip
home,
we'll
see
what
we
see.