►
From YouTube: IETF112-IDR-20211110-1200
Description
IDR meeting session at IETF112
2021/11/10 1200
https://datatracker.ietf.org/meeting/112/proceedings/
A
B
A
Okay,
let
us
get
started
good
morning,
everybody
or
good
afternoon,
where
you
may
be
welcome
to
idr
for
ietf
112..
Before
we
get
ourselves
started.
We
see
that
sri
rama's
showing
his
hand
up
in
the
virtual
no
hand.
Cue
did
you
have
something
to
add.
A
It's
okay,
you've
proven
your
microphone
works.
Okay,
so
we
are
working
off
of
the
pre-shared
slides.
So
hopefully
this
will
be
nice
and
stable.
A
few
quick
administrative
points
early
this
morning.
You
know
the
ietf
note
well.
This
is
something
that
each
of
you
have
agreed
to
as
part
of
participating
in
iatf.
A
You
will
see
this
not
only
as
part
of
your
conference
materials,
but
ideally
as
part
of
every
one
of
our
slide
decks
if
you're
looking
for
you
know
details
about
what
each
of
these
things
mean
now
here
are
some
links
to
each
of
the
individual
bcps
covering
these
things.
You
are
bound
by
them
a
specific
thing
that
we
are
getting
a
little
bit
of
additional
emphasis
on
as
part
of
this
ietf
is.
A
The
iesg
has
requested
that
we
remind
everybody
that
ietf
does
have
a
code
of
contact,
and
specifically
it
also
has
an
anti-harassment
policy,
and
if
you
find
that
for
some
reason
that
you
are
experiencing
inappropriate
behaviors
in
ietf,
please
contact
you
know
the
itf
chair,
or
ideally
one
of
the
ombudsmans
in
general.
The
the
things
that
we
emphasize
are
what
a
friend
of
mine
used
to
call
kindergarten
skills.
We
expect
us
to
treat
everybody
with
respect,
ideally
speak
slowly
and
limit
used
to
slang.
We're
very
international
community
and
english
is
a
terrible
language.
A
Please
make
sure
that
you
use
good
logic
dispute
arguments,
no
with
no
reason,
use
good
engineering
judgment
and
ideally
look
for
solutions
that
are
best
for
the
whole
of
the
internet,
so
quick
status
for
the
working
group
since
ietf
111,
we've
received
published
several
rfcs,
a
couple
of
them
on
bhp
ls,
specifically
the
segment
routing
extensions
extension
specifically
for
egress,
pure
engineering
and
also
the
extended
attribute
groups.
A
We
also
published
the
optimal
reflection
rfc.
This
is
a
document
that
has
taken
a
long
time
for
us
to
get
out
and
you
know
happy
to
see
it
actually
hit
rfc
status
and
we
also
published
the
flowspec
guidelines
for
basically
relaxed
verification
of
addresses.
This
is
commonly
used
at
service
providers
and
it
was
a
very
important
thing
for
us
to
do
a
thing
that
happened
outside
of
idea,
but
very
relevant
to
our
work
is
the
routing
working
group.
I
published
the
ietf
yang
policy
module.
A
A
A
We're
at
the
process
of
quickly
iterating
as
itf
week
is
progressing
and
hopefully
we'll
have
that
resolved
by
end
of
week
the
srte
policy
module
is
waiting
for
a
shepherd
write
up
and
full
spec
rpd,
similarly
is
finished
with
the
least
working
group
last
call,
I
was
waiting
on
a
consensus
call
on
write
up
care.
I
think
you
had
that
one,
but
what
is
the
status
in
rpd.
E
Sorry
about
that,
can
you
hear
me
oh
super,
having
some
audio
problems.
At
my
end,
it
has
finished
up
the
working
group
last
call
and
it's
waiting
for
the
shepherd
writer
right.
A
Okay,
so
consensus
has
been
declared,
then
thank
you,
okay,
and
the
last
of
the
list
here
is
that
the
bhp
extended
community
registry
has,
you
know,
finished
as
working
through
ietf
last
call,
and
I
don't
think
we're
seeing
much
in
the
way
of
comments
there.
Hopefully,
that
will
be
published
very
quickly.
A
So
we
had
a
couple
of
interim
meetings
september
27th
we
had
a
intro
on
flowspec
v2
and
the
pattern
of
that
was.
We
discussed
the
functional
contents
for
the
upcoming
flowspec
v2
spent
some
time
discussing
the
problem
space
for
incremental
deployment,
and
we
also
got
a
presentation
on
this
or
v6
that
we
were
talking
about
in
the
prior
slide.
A
The
next
set
of
actions
that
we'll
have
there
is
to
complete
a
first
revision
of
the
flowspec
v2
document
and
resume
discussion.
The
mailing
list
there's
also
some
discussion
about
doing
an
interim
some
time
later.
We'll
talk
about
that.
In
a
moment
we
had
scheduled
a
interim
specifically
for
the
bhp
class.
Will
transport
and
colorware
routing
proposals.
A
Robert
brescia
did
a
presentation
on
auto
discovery
when
ixp
and
turned
out
to
not
be
necessarily
appropriate
for
data
center
context,
but
it
did
extend
on
our
work
that
we
know
that
auto
configuration
state
will
pop
up
in
many
other
contexts,
as
we
start
pushing
it
forward
as
a
feature.
So
it
was
a
good
presentation
to
have
in
the
layer
two
space
we
had
a
presentation
of
the
l3dl
proposal
by
randy
bush.
That
was
a
review
of
the
prior
proposal.
A
We
also
had
an
updated
proposal
from
shiva
from
juniper
for
draft
minto
and
is
a
non-auto-discovery
feature
since
we
had
time
during
the
interim
aishwaren
did
a
review
of
the
current.
The
forum
of
epnrf
and
company
would
absolutely
love
to
have
no
feedback
on
the
mailing
list
about
their
proposal.
A
Our
next
step
for
auto
configuration
is
that
we
are
probably
at
the
point
of
beginning
protocol
selection
discussion.
Although
there's
again
some
discussion
about
perhaps
having
additional
interims
to
maybe
advance
the
work
a
little
bit
further,
we
currently
have
a
interim
scheduled
for
december
6th
and
december
13th.
I
believe
sue
has
also
recently
added
a
possible
option
for
november
30th.
A
These
are
dates
that
are
all
just
getting
them
into
the
idea
of
you
know:
calendaring
system,
the
topics
that
we're
looking
to
have
interim
discussions
about
to
try
to
advance
the
work
out
of
the
ietf
meeting
cycle.
You
know
specifically
the
beach
bct
and
car.
A
We're
definitely
in
need
of
working
group
discussion
on
these
topics
since
they're
going
to
be
no
important
things
for
the
industry.
Clearly,
we
have
the
existing
work
for
flowspec,
v2
and
autoconf,
and
no.
This
also
gives
us
opportunity
to
discuss
things
as
part
of
just
simply
advancing
things
outside
of
ietf
meeting
cycles.
A
We'll
be
you
know,
doing
coordination
with
the
document
authors
to
find
acceptable
dates.
We
do
realize
that
end
of
year
is
a
challenging
time
in
terms
of
people's
holiday
schedules,
so
we'll
be
doing
what
we
can
to
you
know
be
most
accommodating.
A
A
brief
status
update
is
on
the
php
yang
module.
Mahesh
did
manage
to
get
know
some
advancement
of
the
work
you
know
since
the
last
ietf.
So
please
take
a
look
at
the
diff
there.
Just
checking
to
see
if
mesh
was
joined,
he
does
not
appear
to
be.
The
authors
are
intending
to
try
to
actually
push
you
know
for
functional
completion
of
the
document.
By
your
end,
this
has
been
tricky
work.
Just
simply
getting
you
know
the
contents
of
bgp
in
there
being.
A
You
know,
a
large
protocol
with
a
number
of
extensions
and
a
lot
of
need,
for
you
know,
maintainability
the
work,
the
stuff
that's
going
in
the
bhp
module,
not
only
heavily
leverages
things
based
on.
You
know
as
an
example,
the
routing
configuration
module
and
the
policy
module
that's
been
recently
published,
but
we'll
also
be
providing
the
fundamentals
for
things
like
several
of
the
vpn
models
to
use
later
on
and
extend
things
like
maintenance
extended
communities.
A
There
is
a
open
github
on
this.
The
authors
do
welcome.
You
know,
contribution
towards
working
on
the
issues,
and
that
said
we're
just
hoping
to
have
this
done
by
end
of
year.
We
are
going
to
need
help
for
impartial
reviewers,
because
you
know
over
the
lifetime
of
the
document,
everybody
that
has
been
asked
to
help
work
on.
It
has
become
a
working
chair
and
we'll
need
to
get
other
people
to
take
a
look
at
it.
A
These
you
know
things
are
crossing
between.
Primarily
you
know,
bess
and
ivr,
although
some
of
the
work
now
reaches
into
no
beer
spring-
and
you
know
motivated
in
many
cases
by
no
work
that
started
the
pym
group,
you
can
see
a
list
of
some
of
the
documents.
On
the
right
hand,
side
there
is
procedural
overlap.
You
did
see
a
recent
post
from
jeffrey
jung
from
juniper,
no
mentioning
why
his
specific
document
is
targeted
for
its
idr
versus
some
of
the
work.
That's
in
best.
A
The
mess
and
ivr
chairs
are
in
communication
about
this,
and
also
with
ads
and
trying
to
figure
out
how
we
best
motivate
review
and
coordination
on
the
documents
minimally
we'll
be
having
cross-working
group
review,
you
know
and
exactly
which
group
ends
up
adopting
a
specific
piece
of
work.
Is
you
know
the
thing
that
we
figure
out
as
we
go
along?
A
One
of
the
things
that
makes
this
a
little
bit
challenging?
Is
that
spring
is
not
chartered
to
do
multicast
work
really,
so
this
is
to
some
extent
pushing
some
of
the
work
outside
of
spring,
so
that
is
the
cherished
content.
We
are
currently
still
on
time,
we'll
pause
just
a
moment
here
to
see
if
we
have
any
agenda
bashing
before
we
proceed
with
our
first
presentation,
which
will
be
on
sr
policy,
extensions
for
ifit.
G
Okay,
good
yeah:
this
is
a
quick
update
about
the
dgps
policy.
Extensions
for
repeat
so
next
slide.
G
Just
just
a
recap
on
background
and
motivation,
so
I
think
refers
to
data
plane
on
patellar
techniques,
specifically
in
c2im
and
alternate
martin
are
the
relevant
methodologies
we
are
discussing
here.
You
know
that
anademic
informed
about
candidate
part
by
using
bgp.
There
is
the
relevant
document
in
ibr
the
segment
routing
key
policy
document
that
you
also
explained,
that
is
in
publication
phase,
so
it's
quite
advanced
in
itf,
and
these
documents
simply
complement
the
segment
routing
key
policy
draft
in
order
to
add
the
extensions
to
distribute
as
a
nasa
policy
carrying
ifit
information.
G
This
way
data
plane
particularly,
can
be
enabled
enabled
automatically
that's.
Why
yeah
just
a
few
words
about
the
lattice
changes,
we
specify
the
application
to
control
a
domain.
This
is
a
strong
requirement
that
was
also
discussed
in
other
working
groups
like
six
months
about
because
the
data
plane
documents
such
as
the
alternate
marketing
document,
inversion,
c2i
and
document,
and
the
this
application
is
done
according
to
rfc8799
that
for
this
kind
of
application
it
is
suggested
it
is
recommended
to
limit
the
application
to
control
a
domain,
and
we
also
improve
the
security
consideration.
G
G
We
simply
add
the
ifit
attribute
that
that
can
be
attached
at
the
candidate
that
level
as
a
subtilis,
and
we
define
five
subtleties
for
in
bandwagon
c2im
for
alternate
marking
next
slide.
G
G
G
Next
slide,
I
think,
is
the
last
one
yeah.
So
this
as,
as
I
said,
this
document
simply
complements
the
sr
policy
operation
described
in
segment,
rounding
key
policy
draft
by
adding
the
effect
attributes
since
the
segment
routing
t
policy
document
got
working
group
consensus
and
this
we're
waiting
for
right
up.
So
we
can
also
consider
to
progress
with
this
document
as
well,
since
it
is
strictly
related
to
the
other
one.
So
that's
all
welcome
question
comment.
Thank
you.
H
H
H
H
H
We
need
a
backup
backup
as
needed,
seamless,
bad
direction
or
forwarding
detector
needed
and
the
bfd
minimum
transport
transportation
interval
is
10,
sec,
10,
milliseconds
and
also
the
traffic
statistics
is
needed,
but
for
the
backup
path,
the
bfd
minimum
transfer
transfer
interval
is
20
milliseconds.
So
it's
the
tool
path
has
the
different
features.
H
So
there
are.
This
is
the
benefits
to
use
the
template.
First,
some
features
are
only
meaningful
to
controller
and
head
and
nose
bgp
protocol
known
in
the
two
nozom,
so
we
used
use.
The
template
can
show
the
information
that
bgp
no
need
to
know.
Second
features
maintained
if
frequently,
template
can
be
used
to
avoid
the
bdp
protocol
changes
too
frequently,
and
so
the
different
as
a
policies
with
the
same
feature
can
use
the
same.
Template
thus
can
simplify
configuration
and
improve
maintainability
next
slide.
Please.
H
So
we
use,
we
can
use
a
template.
For
example,
we
can
configure
two
templates
on
the
router
and
then
we
can
use
the
controller
to
download
the
to
deliver
the
b
to
deliver
the
sr
policy
with
different
template
id.
H
H
H
So,
in
order
to
fulfill
fulfill
the
template,
we
need
the
two
site.
We
need
some
extension
for
bgp
for
bgp
as
a
policy
protocol.
First,
we
need
the
two
updaters
as
a
policy
encoding
encoding
with
updated
template.
Idtl
variator
like
this
and
the
format
of
the
template.
Id
sub
twa
is
like
this
and
here
the
type
the
type
of
the
template
id
is
to
be
defender
and
the
length
is
a
fixed
value
of
six.
H
F
H
H
H
F
H
H
Okay,
if,
if
there
is,
I
think
for
the
the
template,
id
is
only
to
be
used
in
the
device
and
if
we
we
can
configure
a
template
with
a
template
id
if
the
controller
downloads
the
same
template
id,
maybe
the
attributes
can
be
overread
by
the
controller.
The
terminator
contents
can
be
overread
and
updated.
F
A
I
Yeah,
I
just
wanted
to
ask
in
in
thinking
about
this,
how
you
see
this
working
in
the
case
of
where
policy
is
being
sent
via
reflectors,
etc,
because
there
are
cases
where
policy
is
being
reflected,
provided
that
you've
got
correct
communities,
etc.
To
ensure
that
it's
accepted
when
you
introduce
this
templating.
Does
that
not
kind
of
require
that
the
templates
are
globally
synchronized
within
the
within.
I
Otherwise
things
are
going
to
get
very
messy,
which
means
that
your
template
id
kind
of
has
to
be
unique
and
properly
configured
across
the
entire
domain.
Otherwise
the
reflection
is
going
to
break.
Surely,
unless
I'm
misunderstanding,
something.
A
K
Okay,
I'm
up,
then
I
was
just
gonna
say
something
from
cisco.
I
was
just
gonna
say
you
know
with
the
policy
we
already
have
one
level
of
abstraction
and
we've
been
using
templates
and
management
platforms
for
decades
to
do
variations
of
a
similar
similarity.
You
know
objects
that
are
similar
to
the
template.
I
see
no
advantage
at
all
of
pushing
this
into
the
protocol
and-
and
in
fact
I
think
in
this
case
the
the
feature
is.
K
A
L
Yeah
my
comment
was
very
similar
to
what
ac
was
talking
about.
So
what
you
could
do
is
you
can
on
the
router,
you
configure
the
template
and
you
can
say
you
can
configure
another
policy
to
say
all
sr
policies
with
having
read
in
their
name
would
use
a
red
template
and
something
of
that
sort
and
that
solves
the
problem.
I
I
I
agree
with
ac
that
we,
I
don't
really
see
the
benefit
of
advertising
it
in
the
protocol.
A
Thank
you.
Please
check
the
chat,
there's
a
lot
of
comments
there
and
it
sounds
like
we
have
good
topics
for
email
list
discussion.
Our
next
presentation.
M
N
N
N
This
figure
shows
an
inter-demand
scenario.
The
end
end
to
end
pass
from
node
a
to
node
e
is
calculated
by
a
centralized
controller
along
this
path.
Load
balance
is
required.
The
header
node
in
domain
1
may
not
be
able
to
get
the
information
of
the
nodes
or
c's
in
command
2,
for
example
the
eiod
of
each
node.
In
this
case
it's
difficult
for
the
header
node
in
domain
1
to
decide
the
best
place
of
the
entropy
labels.
N
Another
choice
is
to
perform
the
computation
of
the
entropy
label
position
along
this
path
by
the
controller
and
after
computation
the
sr
path.
With
the
entropy
label
position,
information
can
be
learned
by
the
header
node
via
different
mechanisms
such
as
pcp
or
btp,
and
this
document
proposes
extensions
for
bgp
to
indicate
entropy
label
position
in
the
segment
list
when
distributing
as
a
policy
can
either
pass
using
pgp
next
slide.
N
N
And
here
are
the
summary
of
main
updates
of
the
draft
it
has
been
presented
in
itf
or
110,
and
comments
from
the
main
list
are
appreciated
from
jeff
and
robin,
and
we
add
more
descript
and
the
cloud
classification
and
clarifications
in
the
new
version.
Based
on
the
comments,
the
centralized
controller
would
be
useful
to
compute
both
sr
paths
and
the
placement
of
entropy
labels,
especially
in
the
entertainment
scenario,
and
this
draft
follows
the
considerations
for
entropy
label
position
in
ifc
8662.
N
A
N
N
It
is
introduced
in
the
sr
policy
architecture
that
kennedy
pass
may
be
used
for
pass
protection
and
the
backup
kennedy
pass
provides
protection
only
when
all
the
segment
lists
in
the
active
candidate
pass
are
invalid
and
scenarios
like
load
balancing
may
need
the
segment
lists
for
protection.
For
example,
candidate
pass,
one
is
active,
can
it
pass?
The
flows
are
load
balanced
between
the
segment
list.
One
and
two
and
cb2
will
only
take
place
when
both
at
least
one
and
list
two
are
invalid
and
in
some
scenario
we
may
want
to
protect
this
one.
N
So
after
list
1
fails,
flows
can
still
be
load
balanced
between
list
2
and
the
backup
list
of
list
1.
and
the
relation
and
the
protection
relationship
between
segment
lists
should
be
flexible
and
there's
already
a
working
group
document
in
pc
that
proposes
extensions
to
pcp
to
provide
backup
segment
lists
for
protection
based
on
the
above
considerations.
N
N
And
this
slide
shows
the
bgb
extensions
for
sr
policy.
If
the
b
flag
in
the
segment
list
sub
tov
is
set,
it
indicates
that
the
segment
list
act
as
in
backup
path,
and
this
identifier,
subtree,
is
used
to
identify
the
segment
list
and
it
contains
an
optional
subject.
This
protection
theory.
It
carries
the
protection
relationship
of
segment
lists
next
slide.
N
And
this
draft
also
proposes
extensions
of
bgp
os.
The
tlsp
distribution
draft
describes
a
mechanism
to
collect
the
hazard
policy
information
that
is
locally
available
in
the
node
and
advertise
it
into
bgb
os
updates.
It
includes
kennedy,
parts,
site,
tlv
and
segment
list.
Tov
the
s
flag
and
b
flag
are
originally
defined
in
kennedy,
past
state
tlv
and
two
new
flags
of
similar
meanings
in
segment
list.
Here
we
are
defined
in
this
draft.
The
s
flag
indicates,
the
segment
list
is
in
administrative
short
state
and
the
b
flag
indicates.
N
J
J
J
I
believe
that
something
that
should
be
kind
of
reviewed
and
updated
in
the
spring
working
group
before
this
protocol
extension
is
done.
So
what's
this,
what
you're
proposing
here
is
a
change
to
the
sr
policy
architecture,
and
you
know
it's
it's
fine
to
do
so,
but
I
would
suggest
to
do
that
first
in
spring,.
J
N
N
Okay,
I
think
that
since
there
are
already
many
draft
update,
adding
some
attributes
and
some
changes
as
our
policy
architecture
yeah
how
we
will
collect
more.
A
And
thank
you
we'll
make
sure
to
capture
that
point
in
the
minutes
and
you
know
coordinate
with
spring.
You
know
and
use
when
this
work
should
move
forward
in
bgb.
A
D
Can
can
you
folks
hear
me
hello?
We
can
hear
you
fine,
oh
okay,
sorry
I
have
some
audio
problems,
so,
if
anywhere
I
drop,
my
colleague
andrew
will
take
over
and
finish
the
presentation
with
that
said,
I
just
wanted
to
give
a
little
bit
of
update
with
regard
to
all
the
draft
that
we
are
out
there
for
point-to-multipoint
policy.
D
As
you
can
see,
there
is
two
mother
and
father
drafts.
There
is
a
replication
segment
and
then
there
is
a
point
to
multi-point
policy
under.
D
And
the
next
hops
on
the
data
path,
the
point
to
multi-point
policy
to
make
it
very
short
and
sweet
are
the
candidate
paths.
There
can
be
two
or
more
candidate
paths
and
the
candidate
pad
with
the
highest
preference
is
the
active
and
then
under
those
candidate
paths.
We
have
what
we
call
path
instances
and
the
path
instances
are
really
used
for
global,
optimization
of
a
candidate
pad
itself
moving
forward.
D
Obviously,
for
services
we
need
signaling
via
mpbgp,
which
the
mvpn
evpn
sr
point
to
multi-point
policy
draft
is
all
about,
and
also
there
is
a
yang
model.
And
then
there
is
this
idr
draft,
which
uses
the
bgp
point
to
multi-point
srte
policy.
If
you
will
to
download
the
instructions
from
controller
to
each
one
of
the
routers
or
nodes
to
set
up
the
data
path
from
the
root
all
the
way
to
the
leaf
which
we'll
talk
about.
There
is
a
pce
draft
which
accomplishes
the
same
thing
through
the
pce.
D
D
The
ping
draft
actually
provides
some
oem
functionality
on
the
data
pad
to
make
sure
that
the
tree
is
functional
from
the
root
to
the
leaf.
So
it
is
very
important.
One
point
I
want
to
put
on
the
table
here
with
regard
to
the
ping.
As
of
now
that
ping
draft
is
for
mpls
only
and
for
srv6
we
need
to
have
another
draft
depending
on
how
the
conversation
for
srv6
oem
pans
out
in
the
spring
later
next
slide.
Please.
D
So
going
quickly
over,
I
already
talked
about
some
of
these
concepts
of
the
point
to
multiplying
policy.
So
again,
it's
very
similar
to
unicast.
We
are
using
canada
paths.
You
can
have
many
candidate
paths
with
the
active
canada
pad
being
the
being
the
one
with
the
highest
preference.
You
can
engineer
your
candidate
paths
based
on
the
controller
and
download
them
as
a
sr
lg
separate
from
each
other.
You
can
do
all
these
tricks
with
each
one
of
the
candidate
paths.
D
If
you
will,
you
know
there
could
be
pcc
initiated
where
you
use
the
mvpn
procedures
to
discover
the
leaves
throughout
your
network
and
somehow
the
controller
needs
to
start
listening
to
this
bgp
ad
routes
going
back
and
forth
from
the
leaf
and
the
root
and
discover
these
leaves
and
based
on
that,
we
can
use
this
srte
point
to
multiply
as
rte
draft
to
download
the
instructions
to
the
router.
D
D
So
here's
a
visualization
of
what
I
just
talked
about-
sometimes
you
know
a
picture-
speaks
a
thousand
words
so
again
at
the
root.
You
have
the
canada
paths.
As
I
said,
you
can
have
multiple
candidate
paths.
The
one
thing
I
want
to
stress
here
is
the
instance
ids
or
the
instance
paths.
Basically,
the
instance
paths
are
the
lsps
the
point
to
multi-point
lsps
itself.
As
I
mentioned,
each
canada
path
can
have
two
at
least
two
instance
path,
and
the
reason
for
that
is
because
we
want
to
have
a
global
optimization.
D
So
if,
for
whatever
reason,
the
controller
decides
that
it
wants
to
optimize
a
canada
path,
it
downloads
a
second
point
to
multi-point
lsp
via
the
instance
pad
number
two,
and
then
we
do
mbb
procedures
from
one
instance
pad
to
another
instance
pad
on
the
candidate
path
itself.
And
then
you
have
the
replication
seats,
which
are
the
replication
points
and
obviously
these
replication
seats
can
be
steered
via
unicast
sr
policy
and
they
can
be
connected
via
unicast
segment
routing
throughout
the
network.
So
it's
a
very
powerful
concept.
D
You
only
do
the
replication
at
the
points
that
you
desire
anywhere
else.
We
can
use
all
the
goodies
of
unicast
as
our
policy
that
our
art
out
there
currently,
including
fast
reroute,
ecmp,
et
cetera,
et
cetera
next
slide.
Please.
D
So
we
made
some
changes
with
regard
to
the
bgp
nlri
and
route
type.
As
of
now,
there
is
a
single
nlri,
as
you
can
see
in
this
picture,
and
there
are
three
different
route
types,
so
one
rod
type
is
for
the
point-to-multipoint
policy
itself
to
download
the
canada
paths,
and
then
we
wanted
to
make
sure
that
this
draft
is
mimicking
the
unicast
policy
as
a
policy
very
closely,
and
as
such
we
change
the
route
types
for
the
replication
segment,
which
is
the
the
instructions
to
program
the
data
path
on
each
node.
D
So
we
came
up
with
a
route
type,
which
is
a
binding
seat.
The
binding
stick
is
really
the
ingress
label
coming
into
the
node,
which
identifies
the
replication
segment
and
on
the
egress
we
came
up
with
the
outgoing
interface
route
type,
so
that's
oif
route
and
basically,
what
it
is.
Is
it
downloads
each
single
outgoing
interface
as
an
individual
object?
If
you
will
and
doing
so,
it
makes
it
very
much
in
par
with
the
unicast
sr
policy
draft
that
is
already
in
the
idr
so
by
downloading
each
oif.
D
It's
as
if,
like
you're
downloading
a
unicast
for
one
of
the
branch
of
the
trees,
and
it
really
becomes
in
very
nicely
with
what
we
already
have
on
the
unicast
side
for
the
sr
policy
in
in
the
idea
next
slide.
Please.
D
So
I'm
not
gonna
go
too
much
into
this.
This
is
the
point
to
multiply
policy
for
the
candidate
path
itself.
As
you
can
see,
we
download
each
candidate
path
individually
and
then
you
have
the
path
instances
which
I
already
explained
that
are
used
for
make
for
for
optimization
of
each
canada
path.
There
is
an
optional
leaf
list,
that's
just
for
debuggability.
D
If
it's
a
control
initiated
three,
then
you
can
download
this
leaflets
to
the
router
as
well.
Just
so
that
the,
if
you
have
a
show
command
or
if
you
have
a
event,
the
router
can
actually
say
that
here
are
my
remote
leaf
list.
That's
the
only
reason
that
we
download
those
leaflets
as
such
their
option
nexus
slide.
Please.
D
D
The
one
outgoing
interface
at
a
time,
rather
than
downloading
the
entire
replication
segment
with
all
the
oifs
downloading,
a
single
oaf
at
the
time
will
allow
us
to
download
a
segment
list
just
for
that
oif
and
we
use
the
same
concepts
of
unicast,
which
is
the
ecmp
per
weight,
and
we
also
added
the
protection
in
there,
which
was
your
previous
presenter
kind
of
presented,
the
concept
of
unicast
sorry
for
the
concept
of
protection
for
unicast.
D
So
obviously,
as
always,
comments
are
welcome,
we
would
like
to
beef
up
the
draft
and
we
have
already
done
the
ipr
call
that
was
done
on
the
last
ietf
and
we
are
asking
for
adoption
again
in
this
itf
to
go
for.
Thank
you.
A
O
Hi,
I
just
want
to
comment
that
there
are
another
way
to
set
up
the
srp20p,
even
using
bgp
and
so,
and
that
is
not
listed
in
that
list
of
the
traps
in
one
of
the
earlier
slides.
I
just
want
to
point
out
that
there
is
another
option,
and
that
is
actually
what
jeff
was
talking
about
earlier.
That
there
are,
there
are
discussions
ongoing
on
where
the
work
should
take
place,
and
things
like
that
so
just
want
to
point
out,
but
that
there's
another
option
to
do
it
to
do
the
same.
A
P
P
P
P
So
we
describe
two
options
to
for
bgp
to
distribute
the
bht
plus
to
ingress
of
the
past,
so
both
options
are
straightforward,
so
we
would
like
to
ask
comments
and
also
we
would
like
to
request
or
drop
shares.
Thank
you.
O
P
You're,
referring
to
the
first
question,
so
two
options.
I
think
we
just
because
this
is
we
just
proposed
two
options.
I
think
both
options
will
be.
Work
will
be
equivalent.
P
From
my
point
of
view,
looks
like
the
first
option
is
a
is
preferred.
I
think
that
in
the
finally
well
one
option
will
be
will
be
selected,
so
that's
wha
we're
gonna,
first
of
all,
question.
So
the
second
question
is
about
the
application
of
this
one.
I
think
in
the
in
the
draft
or
in
the
first
presentation
in
the
nasa
master
idea.
I
think
we
describe
how
to
apply
these
extensions.
Basically,
my
understanding
is
to
your
question.
Is
that
how
do
we
distribute
the
the
equal
part
at
the
past
to
the
english?
O
So
my
comments
here
is
that
first
we
should
pick
why
which
way
to
go,
and
then
then
we
can
adopt
it,
and
I
I
haven't
read
that
draft
yet
so
I
assume
that
either
this
draft
or
another
draft
that
does
talk
about
the
use
case
and
typically
a
that
that
it
will
be
adopted
in
a
working
group
that,
where
the
use
cases
for,
for
example,
the
pnz
tunnel
attributes
was
initially
designed
for
mvpn,
and
that
was
in
the
in
the
best
working
group.
O
P
And
then
we
can
so
this
is
the
multicast
tunnels,
so
you
can
use
it
in
the
for
mvpn
and
also
it
can
be
used
to
just
carry
the
market
traffic
right.
P
Limited
to
one
applications
or
one
application
scenarios
or
cases.
O
Q
Q
Is
sue
just
a
minute
jeffrey,
some
of
your
logic
is,
is
not
necessarily
necessary
for
where
you're
going
to
place
the
document.
Some
of
the
things
have
to
do
with
what
specifications
they
modify.
So
don't
worry
about
the
working
group.
Q
This
is
going
to
be
reviewed
in
in
cases
where
you're
changing
the
tunnel,
encapsulation
draft
and
changing
multicast
functionality
odds
are.
This
would
be
one
of
those
drafts
which
would
need
to
be
reviewed
by
both
best
and
idea
where
it
starts
out.
Q
It
would
have
to
be
reviewed
and
probably
approved
by
both,
so
let's
not
focus
on
where
the
draft
ends
up
and
let
the
chairs
deal
with
that
as
we're
trying
to
deal
with
with
the
other
portions
of
the
multicast.
Let's
take
today's
discussion
and
focus
on
the
questions
on
the
technology.
Would
that
be
okay,
jeffrey.
O
Definitely
yeah,
it
is
okay
but
like
to
go
back
to
my
earlier
question.
Is
this
for
this
setting
up
a
tunnel
or
to
announce
how
the
tunnel
is
going
to
be
used.
P
Yeah,
this
is
about
a
distributed
tunnel
to
the
ingress,
so
just
like
those,
for
example,
distributed
panel,
as
I
mentioned
that
there
are
already
extensions
there
to
do
the
similar
work
to
distribute
the
panel
in
pgp
right.
This
is
a
straightforward
extension.
O
The
the
reason
I'm
asking
is
that,
when
we
are
using
the
pmc
timer
attribute,
that
is,
that
is
to
announce
what
kind
of
tunnel
to
use.
So,
depending
on
the
on
the
use
case
of
of
your
of
your
draft,
you
will,
you
will
have
have
bearing
on
which
option
to
go
so.
P
Yeah,
I
think
this
one
for
blt
tunnel
looks
like
a
straightforward,
so
we
just
because
I.
P
P
A
F
We
also
have
driven
them
like.
Thank
you,
yeah
thanks,
jeff
jeff.
My
comment
was
not
related
to
the
slide
per
se,
but
since
we
have
little
bit
time
on
the
agenda,
I
wanted
to
discuss
maybe
to
the
chairs
and
the
ad
looking
at
the
agenda
today.
Like
you
know,
all
the
six
presentations
that
were
presented
so
far
have
a
similar
work
happening
in
pc
working
group
as
well
and
as
a
pc
working
group
chair.
I
haven't
discussed
this
with
my
co-chair
yet,
but
I
just
this
thought
came
to
my
mind.
F
I
wanted
to
discuss
what
could
we
do
better
so
that
the
coordination
between
these
drafts
happened
a
little
bit
better,
because
I've
seen
like
there
have
been
cases
where
things
have
been
missed,
a
flags
have
been
missed,
and
now
we
are
writing
extensions
in
pc
working
group
to
add
those
flags
back
and
stuff
like
that.
So
what
can
we
do
so
that
the
work
which
is
common,
don't
miss
things
out?
There
is
still
coordination
between
them.
Should
we
do
a
wiki?
F
A
Okay
and
before
sue
speaks
based
on
what
we
have
left
in
the
scheduled
queue
if
it's
okay
with
sue
and
k,
or
I'd
like
to
reserve
at
least
15
minutes.
For
you
know
this
discussion,
I
know
it's
near
and
dear
to
alvaro's
heart
as
well,
so
please
go
ahead.
Q
So
if
you
look
at
the
idea
or
wiki
you'll
find
a
place
for
it.
A
Right
and
adding
to
sue's
comment:
we've
had
some
general
discussion,
as
we
mentioned
at
the
beginning
of
the
session,
that
the
best
and
idr
chair
is
already
starting
to
discuss
this
and
a
significant
portion
of
the
work
you're
seeing
in
the
first
portion
of
the
presentations
was
organized
because
of
exactly
these
sorts
of
issues.
We
want
to
be
able
to
have
good.
You
know
cross-working
group
coordination
for
features.
We
know
that
technologies
are
reaching
across
boundaries
considerably
more
these
days
and
bgp
is
a
somewhat
generic
bit
of
transport.
A
Plumbing,
for
some
of
these
mechanisms,
especially
for
tunneling,
is
something
that
we
end
up.
Rendezvousing
at,
I
think
you're,
seeing
something
very
similar
in
pce.
That
pce
has
a
programming
mechanism
for
ingresses
has
to
coordinate
as
well,
so
we're
looking
at
it's.
The
usual
combination
of
you
know
a
place
of
where
we
want
to
place
state
initiated
either
at
the
head
end
transported
around
the
network
and
routing
protocols
and
result
in
forwarding,
behaviors
and
alvaro
has
discussed
that
we
do
need
some
level
of
a
coordination
mechanism,
but
hasn't
given
us
a
specific
set
of
requirements.
A
Thank
you
dad
roof
jeffrey.
You
have
the
cue.
O
Question
for
drew
I'm
just
curious.
The
pce
working
group
is
it's
specifically
for
the
psap
protocol,
or
is
it
for
or
does
it
also
include
the
general
pcea
ae
pcc,
a
architecture
that,
when
peace,
peace
particle
is
not
used.
O
The
last
sentence,
the
architecture-
belongs
to
what.
O
Okay,
so
when
it
comes
to
srp20
tunnel
setup,
there
are,
there
is
a
psap
extension
and
then
to
to
to
to
set
up
the
tunnel
using
the
pc
protocol.
And
then
there
are
two
bgp
proposals
to
set
up
using
using
bgp.
O
E
O
The
presentation
that
the
woman
did
earlier
is
specifically
about
using
one
way
of
using
bgp
to
set
up
the
the
the
srp
tunnel,
but
indeed,
when
it
comes
to
srp
to
mp,
there
are,
there
are
different
ways
to
set
up,
including
the
psa
yeah.
F
A
Right,
that's
exactly
the
points
we
were
talking
about
earlier
at
the
beginning
of
the
session.
Alfredo
you
have
the
microphone.
R
Good
morning
or
good
afternoon,
whatever
you
are
yeah,
so
this
keeps
happening
more
and
more,
and-
and
I
just
posted
on
the
chat
that
we
keep
seeing
this
more
as
you
guys
have
already
mentioned,
you
know
that
that
multicast
multi-point
multipoint
work
that's
coming
up
in
bass,
idr
spring
there's
some
pc
work
as
well,
pim
beer,
etc.
R
We
need
to
find
better
ways
of
doing
this
and
martin
john-
and
I
have
been
you
know
talking
about
this,
and
we
don't
have
a
silver
bullet
to
be
honest
on
how
to
solve
the
problem
or
how
to
make
a
cross-working
group
work
better
coordinated.
R
It
would
be
really
nice
if
we
could
find
a
consistent
way
so
that
we
don't
have
to
reinvent
the
wheel
every
time
something
happens
or
every
time
something
comes
up,
but
so
that
we
have
as
not
just
working
group
participants
but
chairs.
You
know
the
ability
or
the
tools
to
to
find
that
better
coordination.
R
So
I
think
one
of
the
things,
for
example,
is
what
you
guys
mentioned
here
about
you
know
having
a
wiki
with
drafts,
etc.
Of
course,
we
then
need
to
know
how
to
find
that
wiki
and
we
need
all
the
authors
to
to
know
that
we've
been
talking
about,
and
jeff
mentioned,
that
up
in
the
chat
before
about
some
type
of
review
team
to
try
and
coordinate
things
across
working
groups.
Some
of
the
things
that
we're
seeing
is,
for
example,
based
on
the
point
of
multi-point
architecture
and
pim.
R
There
are
multiple
solutions.
My
opinion,
personal
opinion,
is
that
multiple
switches
around
is
really
bad,
but
we
need
to
coordinate
them
and
if
we're
going
to
have
multiple
solutions,
we
need
to
just
you
know:
make
sure
that
there
are.
There
are
properly
reviewed
across
multiple
places.
If
not.
R
If,
if
we're
going
to
make
the
decision
to
not,
then
we
also
need
to
make
that
decision
somehow,
so
we
need
to
to
figure
out
not
just
where
the
drafts
are
going
to
be
potentially
adopted
and
last
called,
and
everything
else,
obviously
we're
doing
bgp
extension
site.
Dr,
is
the
obvious
place
to
do
that,
but
we
would
need
of
course
review
from
other
places.
R
We
need
some
type
of
coordination,
so
we've
been
talking,
as
has
been
mentioned
here,
to
a
bunch
of
the
chairs,
to
try
and
gather
ideas
and
try
to
figure
out
what
is
the
the
best
way
going
forward.
R
This
point,
one
point
thing:
is
you
want
the
one
that
is,
I
guess
the
front
right
now
for
us
and
we'll
probably
try
something
I
don't
know
exactly
what
yet
and
and
maybe
that
will
become
the
consistent
way
in
the
meantime,
if
you
have
ideas
thoughts,
you
know
what
would
work
better
would
be
easier,
not
just
for
the
chairs,
but
for
the
participants
in
general
to
to
have
a
way
to
know
that
something
else
is
going
on,
besides
waiting
for
the
chance
that
it
might
come
up
at
the
routing
area,
open
meeting
for
example,
and
and
find
out
about
other
things,
please
let
us
know
talk
to
me
or
martin
or
or
john
or
all
of
us
at
the
same
time,
whatever
you
want
to
do,
and
I
will
be
happy
to
listen
to
that,
we're
still
looking
for
for
what
is
the
best
way.
R
But,
yes,
we
don't.
We
don't
have
a
silver
bullet.
I
just
want,
as
I
said,
to
find
a
consistent
way
so
that
we
don't
have
to
reinvent
the
wheel
every
time.
So
thank
you.
A
Okay,
before
we
move
on
to
human
waymo,
you
have
your
audio
open.
Were
you
wanting
to
speak
yeah.
P
A
D
Yeah,
so
just
to
comment
on
that
until
now,
what
I've
been
doing,
at
least
for
the
point
to
multiply
policy
absolutely
I
I
have
a
slide
that
I
try
to
update
every
single
working
group
with
regard
to
where
the
drafts
are
with
regard
to
at
least
this
technology,
but
the
way
I
was
seeing
it
until
now
again,
my
two
cents,
you
know
obviously
open
for
conversations
and
comments.
D
The
way
I
was
seeing
it
right
now
is
that
this
piece
is
exactly
like
unicast
and
it
it
has
worked
been
working
to
some
extent
that
you
know
pim
is
taking
the
the
lead
in
in
the
multicast
technology
itself
and
when
it
comes
to
all
these
other
bits
and
pieces
for
downloading
the
policies,
we've
been
just
going
to
the
appropriate
working
group
and
explaining
the
multicast
technology
with
the
multicast
experts
that
are
already
within
those
groups
and
from
tracking
purposes
we've
just
been
using.
D
That
first
slide
not
ideal,
but
I
just
wanted
to
make
sure
that
you
know
everybody
knows.
You
know
how
we've
been
tracking
this
work,
at
least
for
the
point
to
multiply
points.
A
And
I
agree
and
just
sort
of
adding
in
you
know,
sort
of
a
high
level
discussion
as
alvaro,
saying:
there's
nothing
in
current
ietf
process
that
really
governs
how
we
should
be
doing
this
sort
of
thing,
so
this
will
be
partially
making
it
up
as
we
go
along.
Certainly
if
people
have
other
experience
in
other
standards,
organizations
about
how
such
larger
work
gets
coordinated
we'd
be
happy
to
take
it.
A
Probably
the
best
thing
that
we
could
do
is
much
like
you're
talking
about
and
pick
up
some
level
of
interested
parties
that
are
doing
this
cross-area
work
and
to
simply
make
sure
that
they're
all
talking
to
each
other
find
a
common
place
to
write
it
down.
Certainly,
the
wikis
are
a
place
that
we
can
do
so,
but
you
know
figuring
out
where
is
mostly
a
matter
of
preference
rather
than
of
technology
and
you'll
pass
that
point
as
we
get
the
people
talking
to
each
other
and
get
all
the
stuff
coordinated.
A
As
soon
as
you
removed
your
hand,
okay,
thank
you
for
this
useful
diversion
we'll
make
sure
this
gets
captured
in
the
minutes
and
I'm
sure
that
part
of
this
topic
will
pop
up,
but
as
part
of
the
routing
area,
general
meeting
is
alvaro,
saying
our
going
back
to
our
next
presentation.
Item
number
seven.
B
Okay,
so
first
off
thanks
for
that
time
to
speak
today,
so
while
the
giraffe
that
we're
proposing
is
a
pretty
simple
vgpls
extension
for
isis
flight
reflectors,
I
just
wanted
to
spend
a
few
minutes
kind
of
driving
some
context
behind
it.
Next
slide.
Please.
B
So
the
problem
we're
trying
to
solve,
I
think
we
all
know
that
you
know
flat
single
area
igps
come
with
some
pitfalls.
You
know
lots
of
flooding.
Every
node
needs
to
know
it.
Lots
of
state
every
node
has
to
remember
and
maintain
it,
and
then
you
know
convergence
right.
Every
node
has
to
do
the
computation,
and
this
just
gets
worse
as
the
network
scale,
but
there
are
some,
you
know
desirable
properties
for
that
you
know,
especially
with
deployments
things
like
sr
next
slide.
Please.
B
So
just
trying
to
visualize
it
a
little
bit
just
a
you
know,
example:
topology,
relatively
small,
flat
level.
Two
isis
network,
you
know
stable
flooding
domain,
but
as
the
network
grows
and
grows,
scale
becomes
more
of
a
concern.
So
you
know
again
just
kind
of
driving
some
more
specificity.
To
what
was
mentioned.
You
know,
lots
of
state
you
know
have
to
maintain
adjacencies.
B
I
have
to
maintain
a
larger
lsdb
lots
of
flooding
to
distribute
all
that
link,
state
information
and
then
convergence
right,
more
runs
longer
run
times
and
that
just
gets
compounded
by
the
higher
resource
utilization
required
for
that
and
next
slide
and
what's
the
solution,
isis
flood
reflection,
of
course.
So
there
is.
This
is
based
on
existing
work.
In
lsr
it's
been
adopted,
but
basically
photograph
yeah,
sorry,
flood
reflectors
are
a
little
bit
like
bgp
route
reflectors
and
that
we,
you
know
we
choose
a
cluster
id.
B
B
Okay,
so
let's
kind
of
visualize
and
put
everything
together,
so
we
basically
split
the
level
two
into
multiple
flooding
domains
and
that
basically
just
means
we
take
level
one
and
level
two
and
we
establish
flood
reflector
adjacencies
in
level
two.
So
we
have
the
flood
reflectors
at
the
top
flood
reflector
clients
at
the
bottom,
and
we
use
that
level
one
in
the
middle
for
transit.
B
B
Just
a
quick
kind
of
before
and
after
I
just
think
it
helps
show
you
know
if
you
consider
larger
topologies
how
this
could
you
know
how
this
sort
of
work
is
beneficial
next
slide.
B
And
just
a
real,
quick
thing
here:
did
we
actually
improve
all
the
scaling
considerations?
Yeah?
Definitely
so
you
know
if
we
consider
just
a
simple
topology
of
six
level,
one
level
two
nodes
without
flood
reflection,
we
would
need
you
know
15,
adjacencies
and
level
two,
but
with
the
flood
reflection
we
two
flood
reflectors
to
the
top
four
clients
at
the
bottom.
We
only
need
eight
and
that
gets
us
out
of
redundancy.
Two
next
slide.
B
And
while
the
the
other
factors,
you
know,
vary
per
implementation,
you
know
hardware,
network,
size,
etc.
We
do
know
that
you
know
less
links
and
adjacencies
mean
less
lspdues,
less
lspd
using
less
flooding
and
therefore
less
spf,
computation
and
next
slide.
B
And
finally,
this
point
so
thanks
for
bearing
with
me
basically
we're
just
asking
for
some
bgpl
sclvs
from
the
node
link
and
prefix
and
attribute
descriptor
registry.
Just
so
we
can
kind
of
convey
that
information
about
flood
reflection,
topologies
to
the
controllers.
It's
pretty
straightforward
there
and
last
slide.
B
So,
what's
next
so,
with
the
existing,
the
existing
flood
reflection
work
already
being
adopted.
We
are
asking
for
adoption
here
for
this
draft
and
while
the
specific
definitions
of
how
the
tlbs
are
used
are
already
identified,
there
we'll
do
a
little
bit
of
supplemental
additions
to
kind
of
describe
how
it's
used
for
bgpls
and,
as
always,
comments
are
welcome.
A
Thank
you
for
the
presentation.
We
have
plenty
of
time
in
the
queues.
Do
we
have
any
questions
and
while
we're
waiting
for
any
hands
to
go
up,
this
is
a
place
where
I'll
note
that
you
know
we
have
had
discussions
with
lsr,
and
you
know
it's
perfectly
fine
to
have
a
separate
bgp
document.
You
know
we
could
also
have
unified.
You
know
bgp
ls
extensions
and
lsr
documents
and
it's
non-controversial
to
have
no
feature
pop
up
in
bgp
after
it's
already
been
through
lsr.
F
M
M
Okay,
there,
there
are
some
problems
in
using
pgp
link
button
wise
one
os
is
now
encoded
again
you
you
attended
the
community
attribute
using
c2
bits
of
rhodium
phonotype.
L
M
M
So
when
the
value
you
see
the
the
24
21st
part
of
two
it
can,
it
may
no
longer
be
accurate
after
conversion
to
full
of
loading
points
from
format.
Another
place.
M
Okay,
the
implementation
of
the
floating
component
conversion
makers,
some
problem
and
the
way
how
we
had
a
problem
earlier
I'll
show
you
in
the
figure,
establish
a
bgp
share
relationship
between
rotary
and
router
b,
router
configure
a
export
policy
for
bgp
pl.
The
policy
contains
said,
link
upon
wise
6566
k,
bps
and
straight
converts,
the
bandwidth
to
a
floating
point
number
and
advertise
the
gene
updates.
M
The
bundle
has
value
six
five.
Five,
six
six
kpps
is
converted
to
eight
one,
nine,
four,
seven,
five,
zero
bits,
encoder
and
encoded.
As
for
five,
five,
a
or
one
d
for
c
in
for
information
from
the
formation
on
rotary,
the
expected
the
bandwidth
value,
converted
back
up
from
lincoln
boundaries
utensils
community
energy
will
receive
the
bgp
opportunity
should
be
six
five:
five,
six
six
gps.
However,
in
some
intro
probability
tests
some
device
converted
youtube
back
as
the
65560
kpbs
differs,
differs
by
six
for
our
military
necessary.
Please.
M
Okay
proposal
is
used
to
use
the
convenience
of
units
and
unsigned
integers
to
accurately
represent
the
banana
wise
value,
such
as
a
link
compound
wise
you
see
in
bts
units
and
so
on.
Here
we
have
some
simple
usage
and
should,
as
shown
in
the
figure
routine
configure
x,
configure
access
policy
for
pgpr.
The
policy
contains
a
set
of
incompanies
the
1
500
microbial
bits
per
second
on
rotary
b,
the
link
of
analyze
value
is
obtained
directly
avoids
the
problems
with
the
floating
points
of
it
necessary.
Please.
M
K
Systems
I
I've
never
really
liked
the
floating
point,
but
I'm
wondering
if
changing
it
now
be.
I
know
it
was
the
you
know
the
integrated
services,
guys
who
decided
it
would
be
a
good
idea
to
put
floating
point
in
an
rsvp
and
we've
been
stuck
with
it
ever
since.
But
I'm
wondering
if
it'd
be
a
good
idea
now
to
change
it.
K
You
know
it's
so
we've
had
it
for
decades,
and
this
looks
really
good
for
like
link
bandwidth,
but
once
you
start
using
it
for
re,
you
know
things
other
things
like
unreserved
or
reserved
or
wherever
you,
you
know
the
units
you're
gonna,
you're
gonna
need
fractions.
You
know,
even
if
you
have
a
if
you
have
400
gig
to
start,
you
know
the
pieces
of
it
are
going
to
be
different
units
and
having
all
handling
all
these
units.
I
think
I
think
it
could
get
unwieldy.
K
A
So
I
would
actually
like
to
add
to
and
add
additional
things
for
what
ac
has
just
said
floating
point
as
a
representation
has
been
problematic
for
a
lot
of
reasons.
I
think
my
favorite
one
is
that
we'll
often
get
people
writing
naive,
implementations
for
simple
software-based
controllers
and
they'll
stick
in
something
that
is
basically
a
decimal
value,
so
they
keep
on
trying
to
use.
It
is
something
that
is
not
floating.
A
Point
second
problem
that
I
agree
with
that
ac
is
brought
up
the
floating
points
that
we're
using
are
low,
precision,
floating
points
and,
as
a
consequence,
sometimes
you
simply
can't
get
a
value
that
correctly
represents
what
you're
trying
to
do,
and
it
makes
comparisons
of
things
and
elements
like
policy
very
difficult
to
use.
A
A
So
as
an
example,
you
know,
as
shikhari
is
pointing
out
in
chat.
You
know
part
of
the
question
is:
are
these
powers
of
10,
or
you
know
these?
A
You
know
closer
to
standard
computer
based,
you
know
powers,
you
know
10
24,
rather
than
a
thousand
as
an
example,
but
on
top
of
that
we
also
have
the
detail
that
if
you
happen
to
have
two
bgp
communities
that
have
overlapping
semantics,
just
because
the
units
can
shift
around,
you
know
the
generic
community
code
and
most
implementations,
don't
know
what
they
do
with
that
and
on
top
of
all
that,
there's
a
class
of
extended
community
behaviors
that
are
effectively
singletons
you're
expected
to
have
you
know
one
link
bandwidth
attached
to
your
community
as
an
example
and
this
sort
of
metals
the
semantics.
A
So
I
think,
there's
good
discussion
to
be
had
here
in
terms
of
can
we
do
better
for
something
like
link
bandwidth?
We
have
to
figure
out
how
to
answer
that
question
as
well.
K
Yeah,
just
one
more
comment:
one
thing:
I've
always
I've
thought
many
times,
and
this
reminded
me
of
it
is,
I
think
it
I
think,
if
we're
gonna
switch
to
something
it'd
be
good
to
switch
it
across
all
the
places,
at
least
in
the
routing
area,
where,
where
link
bandwidth
is
encoded
in
protocols
and
what
I,
what
I
would
use
if
I
were
gonna,
if
I
were,
if
I
had
the
power
to
just
you
know,
have
a
flag
day,
I
would
use
a
64-bit
number
that
was
just
bits
per
second,
rather
than
having
all
these
different
units
that
I
think
that
that
this
is
this
is
this
is
this
is
not
something
that
people
are
gonna
wanna
this
wasn't
this
isn't
something
that
programmers
are
gonna
like
I'll
put.
K
Let
me
put
it
that
way
to
have
all
the
different
expression
of
all
these
different
units.
C
That
this
actually
came
up
in
bess
with
when
we
considered
reusing
this
extended
community
and
we
ran
into
very
quickly
the
issue
of
you
know
specifying
one
gigabit
per
second
or
you
know,
unit
gigabit,
one
and
then
unit,
megabit,
1000
and
so
in
in
the
the
best
equivalent
of
this
actually
just
normalized
to
one
unit.
C
I
think
it
was
megabit
per
second,
if
I'm
not
mistaken,
so
the
the
overlap
can
actually
be
problematic
right.
So
if
the,
if
the
byte
value
is
the
same
but
or
the
byte
per
second
value,
is
the
same
but
can
be
expressed
in
two
different
type,
comma
values,
then
you
know
what
do
you
have
to
define
whether
that
is
a
match
or
not
a
match?.
A
A
I
agree
and,
as
was
pointed
out
about
the
best
comment,
we
have
multiple
things
that
are
looking
at
this
there's
a
discussion
about
transitive
versus
non-transitive
as
well.
So,
certainly
thank
you
for
bringing
this
draft
to
idr.
I
think
it's
a
good
conversation
to
start
we're
seeing
this
again
across
more
than
one
working
group,
and
perhaps
you
know.
L
A
L
A
A
Okay,
so
that
being
said,
we
do
have
open
floor
time
for
general
discussion.
Is
there
a
topic
that
people
would
like
to
raise
to
the
working
group
that
they
would
like
a
broader
plenary
discussion
on.
A
Okay,
well,
it
appears
that
we
have
been
efficient
and,
given
that
we
have
people
in
many
places
around
the
planet,
that
would
be
happier
for
a
little
bit
of
extra
time
off.
I
move
that
via
adjourn.
Our
next
scheduled
session
is
for
tomorrow,
and
it
is
for,
I
believe,
the
third
session
of
the
day.
R
No,
I'm
we're
we're
fine
with
going
we're
doing
that
on
thursday
and
actually
yingsan
is
going
to
do
the
presentation
on
thursday.