►
From YouTube: IETF-IDR-20221013-1400
Description
IDR meeting session at IETF
2022/10/13 1400
https://datatracker.ietf.org/meeting//proceedings/
B
B
B
B
So
the
agenda
bashing,
I'm
gonna,
go
through
a
chairs
report
and
slides
that'll
be
the
first
minute.
Then
we're
going
to
go
through
a
car
and
CT
section
where
I
go
through
a
progress
report.
The
progress
report
is
mostly
I
finally
finished
the
Forum
3
report
and
then
Jeff
is
going
to
answer
questions
or
on
procedures
for
route
bgp
routes
with
color.
This
is
the
diffract.
We
thought
we
might
have
some
more
additions
this
morning,
but
they
do
not
appear
to
be
ready.
So
we'll
have
more
of
that
at
itf-115.
B
Excuse
me,
let
me
take
a
step
back
the
best
chairs
a
while
back
when
we
swapped
to
three
chairs,
which
will
tell
you
how
long
ago
mentioned
that
it
would
be
really
good
to
provide
us
more
guidelines
on
the
bgp
next
stop.
So
after
we
hit
the
draft
scuddered
IDF
entry
fee
level,
we
had
a
useful
discussion.
Maybe
John
and
Bruno
have
come
to
some
merge
solution.
B
That
is
good
care
will
present
the
draft
IDR
bgp
attribute
announcement,
and
then
care
is
going
to
give
us
a
little
summary
of
lsvr
I
am
queering
and
going
to
take
a
a
moment
to
ask
folks
if
they
know
anything
about
what
the
best
chairs
were
interested
in
with
asking
us
to
help
with
bgp
Next
Top
changes
in
the
meantime,
between
now
and
itf1,
115
I
hope
to
meet
with
the
best
chairs
and
get
that
information.
Kali
Raj
has
a
proposed
set
of
information
on
IDR
multi-hop
next
attribute.
B
A
B
Let's
see
that
looks
like
I'm
back
then
I'm
gonna
go
ahead
to
the
chair
status.
I've
been
sending
Delta
status
out
I'll,
send
this
information
out
as
well
to
the
mail
list.
Today
we
have
since
the
last
interim
we've
adopted
three
drafts:
draft
Jang,
idrts
flow
spec,
V6
srv6
policy.
The
next
steps
Alvaro
you'll,
find
a
request
for
me,
I
hope
in
your
email.
If
not
I'll,
send
you
another
one
today.
B
If
you
don't
have
it
just
send
us
a
note
in
chat
on
whether
this
should
be
standards
or
informational?
There
are
four
Implement
people
who've
followed
this
policy,
and
so
they
could
go
immediately
to
work.
In
group
last
call
drafts,
Scudder,
bgp
entropy
label
was
merged.
With
draft
IDR
Next
Top
capability
draft,
spaghetti
deprecate,
8
9
10
was
adopted
to
keep
the
registry
cleaned
as
we
feel
those
that
was
useful,
but
we're
not
making
any
other
additional
statement
on
punishing
or
going
after
folks.
B
We
just
think
that
it's
important
to
keep
the
registry
appropriately
clean.
There
are
still
drafts
in
the
adoption
process.
Draft
done
by
IDR
5G
Edge
service
metadata
received
enough
in
desires
for
adoption,
but
there's
a
second
Ken
buff
and
the
Ada's
weight
is
asked
us
to
wait
for
the
result
and
John
Scudder
is
leading.
That
bar
is
the
80
for
that
buff
and
I.
Believe
Linda
is
still
leading.
That
off
is
draft
of
issue
draft
dung
idea.
No
target
excuse
extended.
B
Community
is
in
adoption
from
now
to
the
19th
I've
extended
it
because
apparently
I
did
a
poor
scheduling,
job
and
schedules
it
in
the
middle
of
Chinese
golden
week.
That's
like
sending
it
during
the
Christmas
holidays
in
the
U.S
and
then
I've
started
a
working
group.
Adoption
call
for
Haas
idea:
diffract
zero,
now
I'm
going
to
go
through
the
key
points
from
draft
John,
IDR
node,
Target,
extended
community
I
had
three
questions
in
the
call.
B
Will
this
new
transitive
and
extended
community
help
operational
networks?
What
conflicts
do
you
see
with
other
functions
and
do
you
have
any
concerns?
The
concerns
raised
were
withdraw
handling
priority
between
NT
and
RT
and
RTC,
and
what
happens
if
a
PE
and
an
RR
with
this
are
on
the
same
node,
I'm
sure
there'll
be
good
discussions
in
the
mail
list.
B
There
have
been
a
note
that
several
people
were
interested
in
deployment
SRV
6
networks,
Jeff
tensura
indicated
this
might
be
useful
in
data
centers
and
the
benefits
that
are
look
for
are
reduction
in
policy
distribution.
The
implementation
concerns
were
post
update
filtering
that
is
not
as
standard
defined
in
Roc
4271.
So
that's
where
we
are
with
the
call
we'll
continue
to
discuss
that
on
the
list,
but
I
thought
I'd
at
least
bring
you
up
to
speed
any
questions
about
the
status.
B
C
B
B
B
C
Yeah
I
want
to
say
that
we
have
update
the
charter
again
and
the
update
content
have
addressed
the
concert
still
in
the
adoption
call.
So
I
think
you
can
review
the
most
recent
draft
and
I
think.
Yes,
you
put
yeah
I
think
if,
if
possible,
we
can
discuss
it
at
the
an
Ito
media
physical
face
for
the
possible
first
problem:
okay,.
B
C
B
B
B
B
B
B
The
detailed
list
that
I
sent
out
yesterday,
both
in
email
and
in
put
on
the
wiki,
has
specific
descriptions
for
all
of
these
and
I
ask
only
if
you
have
any
questions.
The
long
list
is
for
the
authors
to
try
to
improve
their
documents,
so
we
can
get
to
working
group
last
call
quickly.
There
are
the
issues
for
CT.
There
are
the
issues
for
Carr
the
issues
around
CT
are
listed
here
on
the
left,
with
Safi
scaling,
CT
and
RTC
NRI
format,
and
these
are
the
titles
of
the
mail
list
sequence.
B
The
descriptions
give
the
actual
that
I
sent
out,
give
the
actual
things
that
should
be
loaded
to
GitHub.
These
are
the
car
car,
appendix
A7,
bgp
car
consensus
on
resolution,
screen
handling
of
LCM
car
routing
and
non-greening
domains
and
up
packing.
Now
the
details
give
enough
for
the
car
and
the
CT
folks
to
actually
have
some
action
items.
They've
been
reviewed
by
both
the
car
and
the
CT
editor
teams.
B
In
some
of
the
cases
we
had
work
issues
raised
by
the
working
group
sure
on
raised
a
really
good
issue
on
new
address
family
genong,
as
he
ran
raised.
A
good
issue
on
support.
Bruno
has
some
really
really
good
discussions
on
differences
in
scaling
and
can
ketan
mention
things
on
intent
for
service
and
Jeffrey
talked
about
some
implications
of
CT
and
Carr.
One
thing
that
was
extended
from
here
are
some
of
his
comments
where
other
domains
could
be
connected
to
bgp.
B
That
might
have
been
an
extension
by
the
chairs,
but
it
was
a
useful
topic
raised.
Swadesh
mentioned
something
on
what
are
the
pros
and
cons
on
Route
targets
and
there's
a
compatibility
of
bgp,
CT
and
car
test
srpc
and,
of
course,
scaling
and
that's
one
of
the
concerns
that
seems
to
repeat
over
and
over.
Some
of
these
issues
in
their
details
may
be
extreme
details
now.
B
What's
important
here
is
that
the
team,
the
editors
will
be
in
charge
of
resolving
these
things
on
the
IDR
GitHub,
the
RDR
GitHub
is
listed
on
the
idea
home
page.
You
go
to
the
top
and
make
sure
you
find
how
to
get
there.
You
can
add
lists
to
the
GitHub.
If
you
have
a
data
tracker,
if
you
have
any
problems,
contact,
Jeff,
I
or
care,
and
we
can
get
you
into
the
idea
GitHub,
the
GitHub
methodology
is
being
used
so
that
we
can
track
comments
made
on
the
list.
B
The
resolution
that
the
chairs
think
needs
to
be
done
and
then
what
changes
are
made
to
the
document
that
will
give
us
a
point
by
Point
discussion
on
the
document.
We've
used
that
also
for
ID
R's
work
on
Flow
spec,
that
was
on
a
private
GitHub
because
we
didn't
yet
have
the
IDR
GitHub
Kristoff
said,
helps
us
set
up
for
that.
The
authors
that
I
work
with
on
the
flow
spec
we
were
revising
the
spec.
B
We
found
that
to
be
very
helpful,
so
we
have
and
I
mentioned,
that
experience
to
Jeff
and
care
or
who
are
very
frequent
with
GitHub
use
in
their
businesses,
and
we
agreed
that
an
IDR
GitHub
would
be
useful
in
this
case.
Are
there
any
questions
about
the
document
I
sent
out
or
the
process
we're
going
through
with
car
and
CT.
B
Jeff
thought
this
might
be
a
a
quiet
time.
I
will
give
you
a
few
more
minutes,
I'm
going
to
remind
you.
This
is
what
car
said
it
was.
This
is
what
DJ
and
swadesh
said
the
first
thing.
They
thought,
though,
the
working
group
could
help
with
current
version
updates
and
Sr
flows,
updates
and
filtering
mechanisms
and
input
on
use
case,
one
of
the
things
that
we'll
need
here
and
I
hope,
Bruno
and
Chuan
and
Chin
running
ketan
and
Jeffrey
in
Swedish.
B
We
may
need
help
with
the
scenarios
that
were
described
there
and
in
the
detailed
list
for
these
issues.
Some
of
them
I
have
noted
that
a
chair
and
another
and
the
original
poster
will
need
to
work
on
getting
a
clear,
operational
description
and
so
I
hope.
I
can
count
on
all
of
the
posters
to
help
the
chairs
come
up
with
a
good,
solid
use
case.
Topology
description
for
the
authors
to
work
on
okay,
Jeff,
TT's
first
thing:
now
there
is
one
thing
with
CT
in
my
review.
B
Some
of
the
comments
that
are
working
on
are
looking
at
it
had
to
do
with
the
the
applicability
of
the
Sr
routing
architecture
to
non-sr
work
and
it's
architectural
link
to
things
which
are
not
srv6
in
bgp
I've
called
that
out
separately
and
asked
the
CT
folks
to
try
to
describe
what
they
think
should
be
the
limits
on
that
there's
also
a
best
srv6
best
Services.
There
seemed
to
be
some
discussion
on.
Where
is
the?
B
A
Okay,
thanks
Sue
two
quick
comments:
the
CTN
card
documents
both
have
GitHub
spaces
allocated
the
CT
authors
have
uploaded
theirs
and
swadesh.
Please
work
with
Kayer
to
get
your
document
uploaded.
That
will
be
part
of
the
important
part
as
we
go
through
the
review
portion
of
the
process
and,
as
we
start
flagging
issues
the
seed.
The
conversation
for
the
next
portion
of
the
interim,
where
we
talk
about
next
top
types,
I'm
going
to
be
partially
recovering
the
information
from
the
diffract
presentation
that
we
had
last
interim.
A
B
A
D
A
The
srv6
is
worth
I.
Think
additional
flagging
because
is
Sue
was
flashing
for
one
of
the
issues
on
that
CT
had
raised.
The
RFC
that
came
out
for
srv6
with
transposition
didn't
exit
the
best
RFC
process
without
some
level
of
controversy.
You
know.
Basically,
if
a
Next
Top
gets
reset,
there's
a
possibility
that
the
transposition
label
you
know,
may
no
longer
match
up
with
the
underlying.
A
You
know,
B2B
path
attribute
in
cases
where
the
system's
Downstream
didn't
necessarily
understand
things,
and
this
fundamentally
is
a
Next
Top
scoping
issue
very
similar
to
what
Bruno
had
raised
as
we
were
working
through.
You
know
the
bgp
open
policy
stuff,
and
what
do
we
do
in
cases
where
we
we
exit
a
given
zone
of
comfort
and
also
this
overlaps,
the
situation
that
we
have
for
the
entry
label
RFC?
The
original
RFC
that
went
out
had
exactly
the
scoping
issue,
and
that
was
exactly
what
deprecating
things
was
about.
A
Okay.
So
what
are
we
talking
about
for
interrupt
type,
behaviors
and
again
I'm
not
going
to
spend
a
huge
amount
of
time
on
this,
because
what
we're
trying
to
get
to
is
discussions
on
forwarding
behaviors?
You
know
you
know
for
a
given.
You
know
bgp
route,
you
know
in
the
very
formal
sense,
a
prefix
for
or
another
I,
whatever
that
happens
to
be
for
your
given
Fe
safy
and
it's
pairing
with
the
path
attributes
can
be
mapped
from
one
mechanism
to
the
other.
A
The
answer
is
yes,
we
can
do
that
mapping,
but
it
requires
some
level
occurring
of
breadcrumbs
State
between
them-
and
you
know,
color
is
obviously
one
of
the
things.
The
original
intent
idea
in
a
card
going
into
CT
is
one
of
the
things
and
vice
versa,
and
how
this
gets
mapped
quickly.
So
this
is
an
example
of
passing
between
multiple
domains.
As
one
of
the
use
cases
we'll
have
to
discuss.
A
Continue
going
through
this
very
quickly,
so
the
mapping
Machinery
here
is
largely
being
done
in
the
format
of
extended
communities.
One
of
the
things
that
is
a
update
to
the
document
that
needs
to
be
made
is
that
carrying
the
original
route
distinguisher
will
require
if
it
stays
an
extended,
Community
format.
You
know
three
mappings,
because
we
have
three
common
extended
communities
for
these
things.
A
The
critical
detail
here
is:
this
is
the
state
that
needs
to
be
mapped
and
if
extended
communities
don't
end
up
working
fine,
they
can
go
inside
of
a
path
attribute.
This
is
again
just
a
mechanism
for
carrying
the
information
to
sort
of
push
and
pop
the
state,
as
you
Traverse
one
domain
to
the
other,
and
we're
only
ever
looking
at
one
set
of
things
now.
A
Theoretically,
we
could
actually
do
something
very
similar
to
what
the
addresset
can
carry,
but
you
know
the
the
actual
detail
is
the
point
to
refined
now
the
procedures
in
terms
of
what
we're
doing
looks
they
give
you
your
path
attribute.
Is
a
discussion
point
going
to
bypass
the
slides
covering
the
individual
mappings?
A
The
critical
thing
is
that,
as
we
go
from
one
domain
to
the
next
n,
maybe
repeat
that
through
several
different
Cycles,
consistency
of
Route
selection
needs
to
be
preserved.
So
when
you're
inside
of
a
car
domain,
you
know
the
routes
that
you
may
have
learned
from.
Ct
need
to
compare.
You
know
equally
and
vice
versa,
and
this
means
that
we
have
to
have
consistency
in
what
the
Handler
I
keys
look
like,
as
things
are
remapped
no
over
multiple
processes.
A
I
had
discussed
in
the
original
presentation
again
leaning
towards
the
discussion
of
what
do
we
do
about
forwarding
behaviors
if
we
were
to
have
something
to
look
like
a
merge
solution,
RDS
have
enough
space
to
carry
a
color,
so
you
know
this
is
one
thing
that
we
can
potentially
look
like.
It
is
a
way
of
carrying
both.
You
know
car
original
intent.
You
know
for
operational
cases
where
that's
the
desire
or
CT
style,
operational
intent,
where
you
know
the
endpoint
devices
or
what
the
operator
is
interested
in.
A
A
Have
some
very
nice
properties?
Theoretically,
you
know
they
may
allow
us
to
have
a
level
of
generic
route.
Reflector
Behavior,
one
of
the
things.
That's
a
interesting
point,
which
we'll
have
to
probably
use,
is
one
of
our
primary
pivots.
If
we
decide
to
go
with
something
like
optional
RI
as
a
general
mechanism,
you
know
from
this
point
forward
in
IDR.
Is
that
RFC
700
606?
They
need
to
be
error,
handling
RFC.
A
So
we'll
have
to
you
know,
address
this
as
one
of
our
key
points
as
we
have
this
discussion
and
the
motivation
for
doing
any
of
these
interesting
things.
Is
you
know
how
do
we
actually
get
better
packing
the
problem
that
we
have
for
the
packing
discussion
and
I
do
see
that
there's
a
question
so
I'll
get
to
those
momentarily?
A
The
key
thing
about
packing
that
we
have
to
worry
about
is
that
we
know
that
packing
can
have
immense
performance
benefits
on
bgp
implementations,
so
there's
a
strong
incentive
for
us
to
use
better
packing
whenever
we
possibly
can
do
so
in
a
reasonable
fashion.
It's
it's
a
great
bit
of
accelerant
for
letting
bgp
perform
well,
the
challenge
that
we
have
you
know
in
the
terms
of
even
some
of
these
optimizations
we're
looking
at
car.
A
Being
an
example
is
that
when
we
allow
for
this
sort
of
thing
anything
that
causes
the
path
attribute,
sets
to
basically
stop
being
shareable
and
that's
usually
PHP
communities
or
other
attributes
that
may
go
on
there.
So
this
degrades
our
packing.
So
one
of
the
analysis,
spaces
that
we
should
have
is
we're
working
through
these
proposals
is
when
we
have
a
desire
for
packing.
What
is
the
likelihood
that
packing
can
actually
take
effect?
A
You
know
this
is
specifically
for
attributes
that
either
are
currently
present
or
may
be
present
in
the
future
and
to
give
an
example
of
a
in
the
future,
a
conversation
both
CT
and
Carr.
Currently
don't
talk
about
the
tunnel
encaps
attribute
is
one
of
the
things
that
they
can
carry
I.
It
seems
a
potential
feature
at
some
point
that
that
may
be
used
to
bias
the
tunnel
tunneling
information
for
each
of
those
proposals.
Clearly,
that's
not
there
yet,
but
that's
just
an
example
of
a
place
where
degradation
could
happen.
A
A
A
Error
handling:
do
we
want
some
new
Next
Top
type?
Do
we
care
about
next?
Stop
scoping.
This
ties
into
several
other
presentations
that
are
following,
or
do
we
look
at?
Maybe
this
is
a
time
for
us
to
look
at
maybe
a
update
to
the
bgp
mlri
itself.
Sorry,
not
the
lri,
the
PHP
update
packet
and
how
Next
Tops
get
encoded
an
example
of
how
this
might
be
able
to
be
done
can
be
compared
to
the
grow
BMP
feature
where
they're
tying
stuff
together.
A
You
know
through
basically
every
disease
inside
of
the
packet,
so
this
has
been
the
setup
for
most
of
the
rest
of
the
discussion
about
PHP
Next
Tops.
Reading
John's
comment
from
the
meat
chat.
He
agrees
that
keeping
the
MRI
simple
as
humanly
possible,
is
a
good
goal.
You
know
people
are
going
to
have
various
views
on
this,
and
this
is
where
we're
hoping
the
discussion
will
go
over
the
course
of
the
longer
presentations
so
before
we
move
into
that
next
set
of
presentations
with
this
as
a
setup,
any
questions
that
this
presentation
raises.
D
Thing
that
I
wanted
to
note
when
you
said
that
the
s56
problem
that
we
noted
was
only
related
to
scoping
of
the
next
hub
or
scoping.
It's
it's
only.
A
scoping
problem,
I
think
that
may
not
be
completely
accurate
because
it's
also
a
problem
of
how
that
Transportation
mechanism
interworks
with
mpls
devices
in
the
same
network
which
are
not
upgraded
because
they
may
misinterpret
the
transpose
transposed
portion
as
a
regular
mpls
label.
So
that
was
the
main
problem.
A
Exactly
and
it's
my
perspective,
that's
effectively
a
scoping
problem
in
the
sense
of
clearly
that
RFC
overloads
existing
behaviors
and
it's
a
problem
when
you
have
left
a
portion
of
the
network
that
understood
the
feature.
So
as
long
as
you
stay
within
the
little
bubble,
that's
defined
by
where
this
feature
Works.
Theoretically,
it
can
work
perfectly
fine,
but
the
mechanisms
for
ensuring
that
you
don't
leave
that
bubble
are
not
part
of
that.
Rfc.
A
C
A
Right
and
to
some
extent
when
Sue
had
started
the
discussion
about
you
know
the
best
chairs
and
discussions
about
Next
Tops,
the
there's
a
discussion
point
that
we're
seeing
being
more
and
more
relevant
across
especially
best
related
documents
and
even
IDR
itself
is
what
do
you
do
about
incremental
deployment?
You
know
how
do
you
make
sure
that
a
feature
doesn't
leak
out
of
a
place
that
it
doesn't
understand?
It
doesn't
have
bad
consequences
when
that
occurs.
A
B
Sue
I'll
just
introduce
the
speakers
by
John.
Your
first
stop
the
next
top
discussion
started
when
we
were
working
in
the
entropy
label
and
asking
about
adoption
of
that
I
believe
John
has
some
useful
details
on
that,
or
at
least
John
will
you
cover
it?
Net's
care
is
going
to
go
through
the
bgp
attribute
announcement,
which
is
a
pre.
Another
draft
we've
worked
on.
B
B
F
This
is
me
on
behalf
of
a
rather
large
now
group
of
really
productive
collaborators
and
I
would
like
to
say
a
very
sincere
thank
you
to
all
of
the
co-authors
and
contributors
listed
on
this
page.
It's
really
nice
when
the
ietf
process
works
the
way
it's
supposed
to
and
and
we
can
work
together,
collegiately
I
love
it
okay.
So
let's
start
with
a
little
background,
and
the
background
is
that
for
for
some
applications,
it's
really
helpful.
F
Really
so
you
know,
as
as
we'll
talk
about
more
the
the
current
draft
is
a
merger
of
the
the
elcb3
and
the
next
top
dependent
capability
is
drafts,
so
next
top
dependent
capability
is
the
you.
The
word
dependent
is
important.
There
we're
not
changing
anything
about
next
talk.
Processing
we're
using
the
next
hop
as
a
is
a
key
to
tell
us
if
the
attribute
applies.
F
So,
let's,
let's
talk
for
a
minute
about
document
development,
so
we
recently
had
a
working
group
adoption
for
ELC
V3
interview
label
capability
version
3.,
and
there
were
a
couple
of
suggestions
that
came
up
from
a
number
of
different
participants
in
the
group
and
the
the
two
themes
that
we
saw
were.
One
is
why
the
heck
isn't
the
lcv3
a
Next
Top
capability
and
in
fact,
if
you
look
in
the
next
top
capability
draft,
you
will
see
that
it
has
an
entropy
and
label
capability
in
there.
C
F
When
mergers
go
well,
they
take
something
from
each
of
their
sources,
and
this
merger
I
felt
like
went
very
naturally
and
it
took
you
know
one
major
ingredient
from
each
of
its
sources
from
elcb3.
It
took
the
strategy
for
making
the
attribute
transitive
while
still
being
able
to
couple
the
capabilities
to
the
next
top.
So
what's
the
strategy
it
is
to
carry
along
the
IP
address
that
was
originally
inserted
into
the
next
hop
by
the
the
Reds
originator.
F
You
take
that
you
copy
it
into
the
header
of
the
attribute
when
the
receiver
is
deciding
how
to
use
the
attribute.
It
has
a
look
at
the
pgp
Rob's
next
app.
It
has
a
look
at
what
it
sees
in
the
attribute
header
if
they
match
great
process
the
tlvs,
if
they
don't.
Oh,
this
wasn't
ever
supposed
to
reach
me
and
it
gets
discarded
and
then
from
the
NHC
draft
comes
pretty
much
everything
else.
The
tlb
is
and
the
rules
for
how
to
propagate
them.
F
This
is
what
and
I'm
not
showing
I'm,
not
showing
the
attribute
headers
in
here.
So
you
know
you
have
to
imagine
the
standard
bgp
attribute
header.
This
is
the
content
of
the
attribute,
so
ELC
V3
has
this
field
that
our
set
of
fields
that
identify
as
the
next
hop
and
the
proposal
in
El
cv3
was
the
existence
of
the
attribute
is
itself
the
signal
that
entropy
label
is
supported
by
the
tail
map.
F
F
F
The
implementation
is
supposed
to
put
the
npreach
attribute
in
first,
but
an
implementation
is
also
supposed
to
be
able
to
process
things
in
any
order.
So
what
that
means
is
that
winner
implementation
reaches
the
the
RCA
attribute,
there's
no
real
guarantee
that
it's
going
to
have
access
to
the
or
that
it
already
will
have
gleaned
the
context
to
tell
it
how
to
parse
the
lri
field
in
the
attribute
header
and
I
think
that
just
also
the
general
policy,
it's
it.
F
F
F
F
So
what's
in
a
name,
it
turns
out
that
you
know
naming
things,
although
it's
kind
of
boring
and
seems
arbitrary
and
silly,
sometimes
it
it
matters,
because
choosing
the
wrong
name
can
confuse
people
for
years
to
come.
So
we
we
currently
have
a
working
name.
Router
capabilities
attribute
here
are
some
of
the
other
things
that
were
discussed
or
thought
about.
F
So
you
know
Flores
is
open,
preferably
I.
Think
on
the
mailing
list
for
discussion
of
other
possibilities
and
I
see
carers,
put
something
in
the
chat
and
search
yet
I'll.
Look
at
that
by
and
by
and
then
second
point
is
it.
It
kind
of
rubs
me
the
wrong
way
that
we
call
these
things
capabilities
because
we
already
have
RFC
5492.
You
know
open
capabilities,
but
I
didn't
have
a
better
idea
and
we
wanted
to
shift
the
ship
the
draft.
F
Is
this
one's
C,
which
is?
Is
the
specification
stable
enough
that
we
can
allocate
this
code
point
and
know
that
it's
it's
not
gonna?
You
know
the
syntax
isn't
going
to
change
out
from
under
us
and
we
think
the
answer
is
probably
yes,
we
have
a
reasonable
amount
of
experience
in
the
field
with
the
strategy
of
using
the
the
header
depicted
on
the
previous
slides.
F
There
doesn't
seem
to
be
a
lot
of
debate
about,
using
that
there
may
or
may
not
be
disagreement
about
how
to
encode
the
entropy
label
capability
itself,
the
tlb,
but
the
wonderful
thing
there
is.
We
have
a
very
large
tlb
space,
so
any
changes
would
exactly
as
the
RFC
wants
it
to
be
would
be
Backward
Compatible.
F
A
I'm
double
muted
that,
hopefully,
is
better
I.
Think
I.
Think
that
might
deserve
a
little
bit
of
commentary.
Probably
could
be
the
easiest
thing
of
any
of
these
proposals.
Is
it's
always
going
to
be
the
discussion?
What
happens
when
the
mechanism
you're
using
the
detect
that
you've
left
the
scope
of
what
you're
expecting
this
to
work
has
failed?
A
What
do
you
do
and
I
think
the
general
flavor
of
at
least
the
original
ELC
was
well
for
this
one
specific
thing:
it's
okay,
just
do
standard
Top
by
half
behaviors
you're
losing
all
of
the
extra
signaling
that
came
along
with
the
LC.
Do
you
think
that
bit
of
thinking
will
hold
up
with
all
the
unknown
things
that
are
likely
to
be
packed
into
the
additional
capabilities
that
this
is
enabling.
F
F
What
you're
saying
the
spec
is,
if
you're
defining
capability,
you
don't
need
to
be
explicit
about
what
the
rules
are
for
transitivity
of
that
capability,
so
I
I
kind
of
think.
We
can't
do
better
than
that
without
knowing
specifics
of
the
capability,
I
think
with
specifically
with
respect
to
entropy
label.
F
C
So
that's
our
originator,
router
capability
and
and
then
there
can
also
be
I.
Don't
know
the
use
cases
right
now,
but
there
could
be
the
next
top
capabilities.
That
is
the
probably
the
next
stops,
which
you
know,
keep
changing
or
not
changing.
Should
we
not
differentiate
between
the
two?
So
one
is
the
originator
router
capability.
Another
is
more
of
a
you
know.
The
actual
bgp
Next
Top
capability.
Well.
F
I
I
guess
the
how
we
got
to
this
place.
To
begin
with
is
that
you
know
when
we
change
the
next
hop,
we
are
changing
the
expectation
of
how
the
thing
is
going
to
pass
through
the
forwarding
plan.
So
it's
not
really
the
originator
router
capability
per
se,
because
you
know
if
we
think
about
a
a
a
route
that
was
originated
someplace
across
the
internet
and
if
that
that
router
over
there
is
capable
of
processing
entropy
labels.
F
But
then
you
know
it
propagates,
through
the
internet
for
a
while
crosses
some
as
boundaries
gets
into
a
new
as
within
the
new
as
it
the
the
Border
router
there
sends
it
into
igp
ibgp
gets
over
to
different
border
router.
What
you
really
want
to
know
is
like
for
the
within
the
the
scope
of
applicability
of
that
particular
LSP
Can
the
tail
end
process,
entropy
labels
right
so
yeah,
the.
C
F
C
C
D
F
C
Okay,
okay,
so
the
second
comment
was
related
to
coverage
for
the
for
any
cast
scenario.
So
let's
assume
that
the
same
prefixes
you
know
advertise
that's
LSP
tail
and
any
cost
advertised
by
two
two
routers
right
and
then
they
come
to
one
router
where
who's
doing
a
next
stop
self.
Let's
say
so
now:
I
mean
it's,
maybe
probably
a
corner
case,
but
one
of
those
two
could
have
entropy
label.
The
other
could
not
have
an
entropy
level.
Is
that
something
to
be
considered?
F
D
So
just
reiterating
I
understand
it
right,
so
it
is
not
the
originating
router
capability
right,
it's
just
a
bgp
Next
Top
router
capability,
yep
yeah
and
the
second
question
the
question
I
had
was
so.
We
also
extract
the
next
top
IP
address
from
other
places
than
next
stop
attribute,
or
the
amplification
Lorry
like
redirect
to
IP
external
Community
is
one
place
or
there
are
some
places
inside
the
tunnel
and
GAP
attribute
or
the
color
on
the
community.
That
also
gives
us
our
next
stop.
So
does
this
next
stop
capability?
F
F
Well,
I
mean
I,
guess
it
depends
on
what
we
mean
by
originating,
but
you
know
when
I
was
answering
the
earlier
question
from
ketan.
You
know:
I
was
sort
of
spinning
a
example
where
some
route
is
originated
to
bgp
far
across
the
internet,
and
it
you
know,
goes
along
and
then
eventually
it
reaches
an
as
that
originate.
You
know
that
that
trip
sorry
propagates
it
into
ibgp,
so
I
wouldn't
call
that
border.
E
C
F
F
That
would
be
the
polite
thing
to
do.
If
it
doesn't
throw
away
the
attribute
and
it
doesn't
modify
the
attribute,
then
the
you
know,
the
receiver
will
look
at
it
and
say:
oh
the
next
top
doesn't
match
and
the
receiver
will
take
care
of
the
throwing
away
on
the
route
reflector's
behalf
and
that's
like
actually
the
whole
insertion
strategy
there
right
now.
F
C
B
E
A
B
B
B
E
B
B
D
B
B
D
A
B
B
B
E
E
E
The
main
motivation
for
writing
this
proposal
was
that
currently
there
is
no
mechanism
inside
bgp
to
scope
the
announcement
of
optional
attributes,
the
only
possible
way
to
do
that
is
either.
You
know
you
define
it
as
an
optionally
non-transitive
attribute,
which
means
by
definition
it
will
be
filtered
out
at
Ace
boundary.
You
have
some
error
handling
filters,
the
filters
that
you've
defined
for
malform
attributes
and
that
forces
it
to
drop
the
attributes
or
you
have
attribute
specific
rules
that
you
Define
per
attribute
and
that
will
do
the
need
for
right.
E
But
what
was
needed
or
what
is
needed
inside
bgp
is
to
have
a
scoping
mechanism
that
is
inbuilt
for
attributes,
wherein
you
can
automatically
scope
these
attribute
so
at
either
a
confed
boundary
es
boundary
or
at
multi-s
boundary,
and
there
were
certain
interesting
use
cases
where
you
could
have
done
this.
One
was
eternal
and
cap
attribute.
Next
Top
capabilities
attribute
was
another
one
where
you
could
automatically.
E
E
E
We
just
told
two
bits
from
the
attribute
Flags,
where
you
would
mark
this
Bits
And.
If
this
bits
are
set,
then
you
would
do
the
needful
and
we
wanted
to
go
to
INR
to
reserve
this
bits
in
the
attributes
and
that
would
do
the
need
for
filtering
right
again.
This
bits
should
only
be
set
if
the
optional
flag
is
set
on
the
attributes,
which
means
only
use
it
for
path,
attributes
that
are
optional.
E
D
D
E
I'm,
saying
is
all
I'm
saying
is
assume
two
ends
of
the
routers
at
two
points
at
the
edge
of
the
network
once
inserting
an
attribute
and
then
saying
hey.
This
should
be
filtered
across
the
es
boundary
now,
when
you
reach
actually
the
as
boundary
as
long
as
that
router
implements
this
Behavior
you'll
be
able
to
filter
it,
but
the
operator
needs
to
ensure
that
the
router
has
indeed
or
is
indeed
enforcing
and
filtering
this
right.
Otherwise
it
can
get
leaked
out.
D
E
Right
so
again,
this
is
more
along
the
same
lines
as
we
discussed
that
a
multi,
as
is
under
a
single
Opera,
operate
administrative
domain,
and
the
operator
of
that
administrative
domain
has
to
ensure
that
hey
this
is.
This
set
of
routers
are
actually
at
the
border
point
of
a
multi-as
domain
and
they
have
to
set
a
policy
that
says
you
know
the
filtering
has
to
be
done,
and
the
attribute
now
that
is
sitting
across
the
multi-ace
domain
should
be
filtered
right,
so
that
was
some
more
policy
defined
operation.
Okay,.
E
We
could,
but
this
was
a
path
attribute
flag,
so
yeah
we
could
do
that
or
you
could
set
it
as
a
local
implementation
policy
as
well.
That
says,
across
this
ebgp
connection,
you're
truly
transiting
across
a
multi-ace
domain
and
therefore
you
know
honor
the
path
attribute
which
is
bit,
which
is
said
that
hey
this
should
be
filtered
at
the
multi
as
just
honor
that
and
filter
it
out.
So
you
could
think
of
a
policy
that
has
been
set
and
based
on
the
attribute
bit
that
is
being
carried
in
the
packet.
D
C
A
A
So
discussion
point
that
we
have
here
is
basically
a
couple
of
different
things:
the
first
one
being
that
be
wanted
to
discuss
having
this
sort
of
thing
is
a
core
feature
in
BJP,
as
people
excited
different
ends
of
things
trying
to
do
this
after
the
fact
is
a
really
heavy
challenge
you
know.
So
this
is
almost
an
hp5
type
thing
really
deploying
it
is
going
to
be
very,
very
challenging,
I
think
one
of
the
biggest
problems
we
have
in
terms
of
the
reserved
bids.
A
You
tried
this
before
and
significant
number
of
implementations
on
the
internet
just
simply
treat
those
bits
and
cause
session
resets.
That's
that's
why
we
didn't
use
this
the
first
route,
so
the
question
we're
going
to
have
is
again:
you
know,
since
this
is
for
attribute
scoping,
can
we
figure
out
a
way
to
basically
put
the
necessary
safety
bubble
around
this,
so
that
we
can
make
use
of
these
additional
bits
that
we
have
available?
A
E
And
I
think
one
approach
to
that
could
be.
We
could
reconsider,
putting
in
a
capability
and
say
hey
if
the
capability
is
not
exchanged,
then
automatically
drop
the
picks
at
the
sending
site
or
something
along
those
lines
so
that
you
don't
send
this
bits
anymore,
but
the
filtering
will
not
be
honored
as
well
and
I
think
we
can
add
some
text
but
happy
to
discuss
that
and
brainstorm
it
and
and
see.
How
do
we
move
forward
with
that.
B
B
B
B
E
Okay,
so
folks,
I'm
gonna
talk
about
bgp
based
SPF.
This
is
the
work
that
has
been
done
in
lsvr
working
group.
Sue
had
asked
me
to
talk
about
this
in
context
of
Next
Top
implications
that
are
there
in
bgp,
since
folks
in
this
working
group
may
or
may
not
know,
I
thought
I'd,
give
you
a
general
overview
and
then
talk
about
what
are
the
implications
to
the
next
stop?
E
So
the
main
motivation
for
the
work
here
was
hey.
Look
in
msdc's,
some
kind
of
a
layer.
3
routing
has
been
implemented
till
date
that
is
being
used
as
a
fabric,
most
of
The
Operators
use
to
that
point,
bgp
as
a
layer,
3
routing
protocol,
one
difference
that
people
use
in
msdc
when
they
use
pgp
is
that
bgp
and
Route
reflectors.
E
More
specifically,
if
you
look
at
service
providers,
route
reflectors,
typically
that
are
not
in
forwarding
path
assumes
the
next
stops
will
get
resolved
over
aigp
of
some
sort
that
has
been
deployed
for
the
underly
connectivity
in
msdc.
There
is
no
igp,
and
the
way
that
has
been
done
is
through
Hopper
hop
peering
through
ebgp,
mostly
connections
that
are
been
used.
E
Typically,
when
you
do
hop-by-hop
routing
that
uses
distance
Vector.
Now
the
reason
to
use
SPF
over
a
traditional
distance,
Vector
algorithm
is
that
when
you
do
hop
by
hop
routing,
you
typically
don't
have
a
complete
view
of
the
topology,
which
is
what
you
want
as
an
underlay,
and
when
you
want
that,
you
also
want
hey.
How
do
you
do
fast
convergence?
How
do
you
sort
of
scale
it
better
and
when
you
look
at
these
characteristics,
you
know
it
is
almost.
E
It
is
very
clear
that
you
need
a
graph
based
algorithm,
which
is
pretty
much
an
SPF
to
to
get
you
where
you
want
to
be,
and
so,
if
you
are
going
to
deploy
an
SPF
like
solution,
then
and
use
bgp
as
compared
to
other
protocols
like
igp,
and
you
start
to
compare
them
with
what
is
out
there
with
igp.
You
can
see
that
the
advantages
of
a
traditional
bgp
based
solution
are
locked
in
sense.
That
again,
pgp
is
widely
understood.
E
It's
very
from
operational
standpoint.
It
is
fully
it
has
all
the
all
the
debugging
tools
it
and
the
analytics
in
place
so
very
well
understand,
understood
again.
The
transport
for
bgp
is
quite
reliable,
so
it
can
guarantee
in
order
delivery.
So
from
a
transport
Point
Viewpoint,
it
has
all
the
pieces
that
you
need
from
a
protocol
standpoint.
E
It
doesn't
do
flooding
and
it
also
lends
itself
to
a
multiple
peering
models
that
you
would
want
to
use.
Epgp,
ibgp
anything
and
therefore
combining
a
a
SPF
inside
bgp
looked
like
a
very
good
solution
to
to
start
with.
Now,
when
you
start
to
look
at
a
solution
like
that,
the
changes
that
are
needed
inside
the
protocol
are
the
following.
Obviously,
you
need
to
define
a
new
Safi
new
capabilities.
E
You
want
to
make
sure
multiple
peering
models
are
honored
and
you
want
to
change
the
algorithm
inside
bgp,
which
today
runs
distance,
Vector
to
actually
run
dixtra
so
that
you
can
calculate
the
SPF
when
you
start
to
do
that.
The
best
path
process
changes
accordingly.
So
next
you
have
the
decision
process
phase.
One
and
phase
two
are
completely
replaced
by
the
SPF
algorithm.
This
is
what
the
draft
talks
about
and
phase
three
is
decision.
E
Process
is
pretty
much
short,
circuited
you're
running
the
extra
you're
calculating
the
graph
for
given
prefixes,
and
since
you
calculate
the
graphs,
the
side
effect
of
that
is
that
you
pretty
much
can
now
build
the
underlay
topologies
that
you
are
looking
for.
It
supports
both
ipv4
as
well
as
IPv6.
Now,
since
you
are
running
SPF
and
calculating
SPF
next
stops
that
are
carried
inside
bgp
are
of
pretty
much.
You
know,
use
the
distance
Vector
algorithm
honors
when
you
do
hop
by
hop
routing.
E
There
is
a
since
it
is
only
carrying
underlay
route.
There
is
a
sort
of
packing
draft
by
draft
doesn't
impose
any
restriction.
It
is
almost
implied
that
you
may
carry
one
prefix
or
set
of
prefixes
that
are
specific
to
a
given
router
when
you
are
trying
to
announce
the
routes
out
or
connectivity
out,
but
the
biggest
Point
about
this
draft
is
that
hey
the
next
stops
are
not
honored.
Next
stops
are
ignored
because
you
are
looking
at
the
shortest
path.
E
Connectivity-
and
you
are-
is
a
byproduct
of
SPF,
whatever
the
next
stops
need
to
be
calculated
and
set
forward
to
the
peering
model.
Again
is
honored,
you
can
do
route
reflector
or
a
route
controller
like
peering
model.
Both
models
can
be
inline
or
not
in
the
forwarding
path,
and
SPF
computation
can
happen
itself
also
on
the
route
controllers,
as
well
as
on
the
leaves
and
spines
inside
the
data
center.
So
all
sorts
of
flexibility
is
still
provided
and
honored
as
part
of
a
traditional
pgp
offering.
E
E
Chairs
I
think
are
ready
at
some
point
to
move
this
draft
forward.
Multiple
implementations
exist
for
this
particular
solution
and
the
key
point
from
ideas
perspective
again
reiterating
is
that
the
that
that,
in
this
particular
Safi,
your
next
stops
are
not
going
to
be
honored,
so
you
can
carry
next
stops
and
next
stops
capabilities,
but
the
next
stops
in
itself
are
going
to
be
recomputed
as
part
of
the
SPF
process.
D
C
E
Yeah,
so
what
happens
is
since
you
are
running
dijkstra?
You
will
calculate
the
next
stop,
just
like
how
OSP
or
Isis
calculates
and
the
phase
three,
which
is
you
know,
hey
calculate
the
phase.
Three
of
the
decision
process
is
pretty
much
short
circuited,
because
it's
as
natural
outcome
of
calculating
next
stops
for
a
given
route.
You
will
then
go
and
install
that
in
rib
straight
away,
you
don't
need
the
decision
process
pretty
much.
You
can
optimize.
That
path
is
what
the
truck
says.
Okay,
thank
you.
Thank
you.
B
Thank
you,
we're
gonna,
the
pgp
best
draft
presentation,
simply
a
query
for
anyone
that
knows
of
Next
Top
problems.
We're
gonna
skip
that
presentations.
Please
send
me
any
known
problems
or
things
you'd
like
to
see
improved
with
best
to
me
directly.
I'll
continue
the
research
with
the
best
chairs
and
go
on.
In
the
meantime,
we
will
go
to
Kali
Rogers
presentation,
and
this
one
I
do
have
Kylie
Rodge.
If
you
just,
let
me
run
the
slides,
just
say
next
and
I'll
run
the
slides.
D
D
D
Let's
put
the
mpls
theme,
labels
or
flow
spec,
and
this
desktop
information
they
extracted
from
various
places,
various
portions
on
a
bgp
right
on
a
single
bgp.pdu,
and
this
can
be
broadly
classified
as
basically
the
endpoint.
That's
the
next
option
where
to
forward
this.
To
that
can
be
the
IP
address
that
we
extract
from
either
the
next
top
attribute
code,
0.3
or
the
NP
Regional
array
attribute
4.14.
D
The
next
stop
address
is
specified
there
or
it
can
be
in
the
redirect
to
iot
accident
I
want
to
attribute-
or
we
also
have
some
plbs
inside
and
cap
attribute
or
sometimes
the
pulmonary
Community
carries
a
value
that
is
encode
as
a
use
as
a
next
stop.
And
then
we
have
radar
to
vrf
extern
community
attribute,
which
says
redirect
to
this
vrf,
so
they
have
the
endpoint
in
our
IP
address,
but
still
saying
that
we
write
the
traffic
to
a
specific
vrf.
D
D
4.14
and
it
is
a
label,
is
the
NRA
portion
of
the
field
or
it's
carried,
as
said
in
the
prefixed
attribute,
or
the
current
cap
attribute
and
repair
label
attribute,
which
tries
to
Signal
two
labels,
one
for
backup
path,
another
one
for
the
prime
primary
path
is
carried
in
the
entry
or
they
can
be
like
srv6,
said
inside
the
projected
attribute,
and
also
we
have
constraints
to
the
route
so
which
basically
says
when
you
forward
this
traffic
to
a
next
stop.
How
do
you
want
to
do
it?
D
So
those
are
the
things
that
we
have
on
one
route
and
now
how
we
express
multiplicity
is
either
using
add
path
where
we
advertise
multiple
routes,
each
carrying
a
single.
Next,
stop
like
the
what
what
is
explained
in
the
previous
slide
and
at
path.
It
increases
our
rib
scale
and
rebound
scale.
Also
is
a
challenge
there,
and
then
we
combine
this
information.
D
We
get
either
from
multiple
peers,
single
routes
from
each
PR
or
same
peer,
multiple
routes
using
artwork,
and
then
we
use
local
configuration
like
multipath
or
Pig,
and
that
way
we
consume
everything
and
form
a
unique
cost
next
up
or
a
multi-path
next
up,
which
we
install
into
the
Fib.
So
these
mechanisms
have
you
know
sorry
organically
grown
over
the
period
and
information
is
spread
across
different
portions
of
the
bgp
route,
nlra
and
different
attributes.
Most
of
them
are
like
different
external
communities
and
also
local
configuration.
D
D
All
the
forwarding
action
is
not
easily
extensible,
and
even
when
we
use
that
path,
we
are
able
to
advertise
multiple
next
stops,
but
we
are
not
able
to
express
the
relationship
between
those
Next
Tops,
whether
we
need
to
do
active,
backup
or
ecmp
or
ucmp
what
proportions.
So
these
properties
they
are
important
or
they
can
be
useful
if
you
want
to
use
bgp
as
an
API
to
the
receiver's
field.
Basically,
we
want
to
say
for
IP
routes
or
actually
Market
or
mpls
routes.
D
D
So
if
you
want
to
express
that
kind
of
a
thing
in
vgp,
vgb
becomes
an
API
to
the
boxes,
forwarding
plane
for
any
kind
of
prefix
in
the
NRA,
so
because
we
don't
have
that,
we
cannot
use
bgps
and
API
there
and
the
inability
to
Signal
n-cap
information
uniformly
for
different
address
families.
So,
for
example,
we
use
bgp
free
code
for
labeled
letters,
families,
but
for
internet
because
we're
not
able
to
Signal
any
label
or
in
cap
information
directly
for
surf
A1
routes.
D
We
need
IP
or
Internet
routes
at
an
asbr
anywhere,
but
if
we
are
able
to
Signal
a
label
for
the
safety
one
routes
also,
then
the
code
becomes
completely
lightweight
and
the
service
routes
are
really
confined
to
the
edge.
So
that's
like
another
advantage
of
having
the
end
cap
or
the
next
stops
working
uniformly
across
different
Southeast
next
slide.
D
Please,
and
also
we
have
the
inability
to
express
multiple
labels
in
a
route
except
for
the
proposal
of
repair
label,
which
is
carried
as
a
separate,
excellent
community,
and
this
is
helpful
in
multi-home
scenarios
to
avoid
level
oscillation
and
then
the
semantics
of
a
downstream
allocated
label
is
not
known
to
the
receiver.
So
this
is.
This
is
like.
When
labels
are
advertised
in
a
bgp
label
family,
the
receiver
does
not
know
what
is
the?
What
is
the
properties
of
this
label
at
The
Advertiser?
D
Basically,
whether
this
is,
let's
say
for
the
EP
use
case.
If
we
know
that
towards
appear,
we
have
more
bandwidth
than
another
peer
than
the
controller
or
the
this
is
the
guy
who
is
making
the
addition
of
EP
can
forward
traffic
towards
the
right
label
based
on
knowing
what
that
label
means
at
The
Advertiser.
So
there
is
a
there
is
some
instances
that
this
can
be
used.
If
the
receiver
knows
the
semantics
of
the
label,
and
then
there
is
a
problem
that
is
slightly
unrelated.
Next
stops
it's
at
the
route
level.
D
So
what
I've
learned
from
some
interactions
with
customer
teams
is
that
so
in
option?
C
domain,
they
want
to
have
some
kind
of
local
preference
like
control,
but
they
cannot
use
local
preference
because
it's
not
allowed
over
as
boundaries,
and
this
is,
but
still
this
is
like
a
single
administratory
control
domain,
so
local
preference.
If
you
look
at
the
design
of
it,
it
intends
to
be
used
within
one
domain,
which
is
like
one
ASR,
a
confed
confrontation
system,
but
it
does
not
consider
option
C
domains
as
one
domain
because
it
has
ass.
D
So
if
we
have
scoping
information,
scoping
control
to
be
able
to
propagate
a
local
preference
domain
white
that
works
for
option
C
domains
also
and
still
have
the
Restriction
of
it
does
not
leak
out
of
that
option.
C
domain,
then
that
will
be
helpful.
So
these
are
the
problems
that
I
attempt
to
be
solved
by
the
multi
next
stop
attribute.
So
let's
see
how
it
works
next
slide,
please.
D
D
Even
if
peer
supports
the
capability,
the
attribute,
but
it's
it's
basically
not
willing
to
accept
this.
Then
so
it
is
negotiated
using
a
capability
and
it
is
actually
a
tlvs
format
which
is
extensible
for
newer
endpoint
types,
your
encapsulation
types
and
forwarding
action
types
and
you
can
carry
one
or
more
next
stop
instructions
and
it
can
be
used
as
API
of
bgb
based
API
for
Tool
of
the
receiversified
in
the
next
slide.
I'll
explain
the
format
of
it.
D
So
this
is
the
bird's
eye
view
of
the
attribute
itself,
so
it
has
a
propagation
scope
Checker.
So
this
propagation
spoke
scope.
Checker
is
what
controls
the
propagation
of
this
attribute,
and
this
is
like
similar
to
what
care
was
describing
in
the
previous
presentations,
and
here
it
is
at
the
level
of
mnh
attribute
and
if
the
conditions,
if
this
propagation
scope,
Checkers
functionality,
coincides
with
the
scope
Checker
that
can
use
draft
has
at
the
attribute
level,
it
would
be
perfectly
okay
to
lift
this
from
the
bgp
next
multinational
stop
attribute.
F
D
A
regular
attribute
level
I'll
describe
what
this
does
in
the
next
slide.
So
basically,
Mr
attribute
has
the
propagation
scope
Checker
and
a
list
of
MNS
tlbs,
and
each
MNS
tlv
is
of
a
certain
type,
and
it
has
next
up
forwarding
information.
So
this
next
up
forwarding
information
is
what
actually
describes
earnest,
which
is
a
container
for
a
list
of
forwarding
instructions
and
a
forwarding
instruction.
Tlv
has
a
forwarding
action
and
a
forwarding
argument
associated
with
it
one
or
more
forwarding
arguments.
D
D
So
this
is
the
propagation
scope,
so
it's
non-transitive
like
we
discussed,
and
it
also
carries
advertising
protocol
next
up,
which
can
be
used
to
do
Sonic
check
on
they
manage
to
see
if
it
is
valid.
Basically,
every
speaker
that
resets
the
next
stop
to
self
it
removes
this
attribute
and
when
it
is
really
Rising
the
route
with
itself
as
an
extra
or
a
new
laptop
it.
D
It
adds
this
attribute
based
on
the
local
intent,
whether
whether
it
wants
to
advertise
multiple
next
stops
on
the
new
route,
when
it
is
realizing
it
so
that
Rising
pnh
should
match
the
it
should
match
the
speaker,
which
is
advertising
the
mnh.
It's
just
a
sanitize
scientist
check
to
see
whether
it
is
getting
advertised
by
this,
the
speaker,
which
actually
reset
the
next
up
and
even
amongst
the
speakers,
are
understand
their
marriage.
D
So
the
lldas
list
is
just
a
list
of
four
as
four
octet
as
numbers
which
are
in
the
same
administrative
control.
So
this
is
the
option
C
domain.
So
basically
the
attribute
this
particular
psct
tlv.
It
contains
everything
that
is
required
for
restricting
the
scope
of
this
attribute
to
a
certain
domain,
and
this
enables
the
domain
local
preference
to
be
used
in
option.
D
C
domain
scope,
basically
domain
local
preferences,
another
and
mnh
tlv
of
type
of
a
certain
type,
and
it
just
carries
the
local
preference
value
and
it
because
of
having
the
scope
Checker.
We
are
sure
that
it
will
not
leak
outside
in
the
internet
or
outside
of
the
current
domain,
and
it
can
be
used
in
in
lieu
of
the
local
preference
so
just
like,
we
would
use
the
local
preference
when
we
are
receiving
from
an
ipgp
here
in
the
same
domain
same
as
domain.
D
So
these
are
the
types
of
Reminisce
tlv
that
is
described
defined
today.
So
the
first
thing
is
the
primary
forwarding:
next
stop
primary
forwarding
path.
So
this
is
what
you
want
to
advertise,
and
this
is
like
a
next
stop
tlv,
which
multiple
next
complex
and
then
you
can
also
advertise
backup
forwarding
path.
So
this
is
to
avoid
label
oscillation
problem,
so
this
is
described
more
in
more
detail
in
the
draft.
D
Whenever
they
receive
a
new
label
from
the
other
PE,
they
will
allocate
a
new
label
and
I'll
address
to
Dollar
PE
and
this
process
repeats,
and
this
can
be
solved
only
if
we
use
either
a
different
allocation
mode
inside
our
next
stop
allocation
mode.
We
have
to
be
able
to
advertise
a
separate
label
for
the
backup
forwarding
path
so
that
we
can
avoid
the
oscillation.
Basically,
the
label
primary
label
allocated
by
pe1
should
not
depend
on
the
primary
label
allocated
by
pe2
and
the
backup
label
advertised
by
a
PE.
D
It
depends
on
only
the
primary
path
towards
the
CE
or
the
other
router.
So
this
is
the
the
format
of
the
tlvc
is
like
exactly
same
as
the
primary
forwarding
path,
but
it
just
says
that
this
label
has
to
be
or
this
end
cap
information
has
to
be
used
as
a
backup
path.
When
you
are
using
that
alternate
path
for
repairing
traffic
and
then
there
is
a
downstream
signaled
label
distributor.
D
So
these
are
the
four
types
that
are
defined
today
and
unknown.
Tlv
types
router,
which
is
propagating
mnh
attribute.
It
is
expected
to
propagate
the
unknown
tlv
types
as
well,
and
it
it
error,
handling
wise.
It
should
not
bounce
the
session
or
anything
it
just
escapes
and
ignores
processing
it,
but
processor
advertises
it
forward
for
any
other
speaker
that
understands
that
new
tlb
next
slide.
Please.
D
So
this
is
the
next
forwarding
information
tlb,
which
actually
describes
the
next
stop
and
it
is
present
in
the
primary
path
or
the
forwarding
power.
The
backup
path,
MNS
tlvs-
and
it
contains
number
of
next
stops,
whichever
each
Next
Top
leg
element
is
described
by
a
forwarding
instruction,
Theory
exactly.
D
So
the
forwarding
instruction
tlv
it
comprises
of
a
forwarding
axle
and
one
of
more
arguments.
So
this
is
where
the
accessibility
comes
in.
So
basically
here
we
say
these
are
the
forwarding
actions
today,
that's
possible.
So
if
you
think
about
it
in
today's
bgp
protocol,
the
forwarding
action
that
we
imply
is
just
forward.
Basically,
we
have
a
route,
that's
coming
with
the
next
stop,
and
we
are
just
saying
forward
to
that
next
time
and
when
we
allocate
labels
and
advertise
to
others,
we
have
different
forwardings
for
those
Downstream
allocated
labels.
D
For
example,
replicate
is
not
a
forwarding
action
that
we
do
in
bgp
today
for
flow
spec.
It
is
defined
but
probably
not
implemented,
but
if
you
think
about
it,
if
you
want
to
do
kind
of
a
multicast
replication
forwarding
using
bgp,
it's
just
a
way,
you
can
express
it,
we
just
say
replicate
it
and
you
give
the
forwarding
arguments
which
will
be
the
end
points
to
whom
you
replicated
next
slide.
Please.
D
And
the
forwarding
arguments
still
be,
they
are
basically
the
arguments
that
are
required
to
complete
the
forwarding
action.
This
can
be
today.
They
are
just
ipv4
address
and
IPv6
address
and
in
some
flow
cases
we
also
have
the
forwarding
or
context
Rd.
That
is
the
data
vrf
kind
of
a
case,
and
there
may
there
are
some
cases
where
we
also
infer
the
next
hub
using
the
Rd.
D
There
are
some
drafts
or
the
allocated
label
and
the
mpls
label
is
it's
basically
when
there's
an
upstream
allocated
or
Global
scope
label,
like
you
may
in
some
forwarding
paradigms,
like
Sr
or
mpls
name
spaces,
you
can
identify
and
node
not
only
by
an
ipv4
address
or
ipv's
address,
but
I
also
using
MPS
label.
So
these
are
the
different
kind
of
identifiers
that
you
can
use
to
identify
the
place
where
you're
forwarding
your
traffic
to,
and
even
if
you
have
a
new
kind
of
identifier
tomorrow,
we
can
just
describe
one.
D
D
They
are
expected
to
be
directly
connected
and
ibgp
routes
are
expected
to
be
multi-hop,
that's
just
a
general
wisdom
and
if,
if
you
want
to
advertise
a
route
and
in
that
specify
as
an
API,
whether
you
want
a
strict
control
for
that
next
stop,
so
that
it
is
only
a
single
upper
way
or
whether
you
expect
it
to
be
multi-hop.
So
this
proximity
check
constraint
actually
specifies
or
allows
the
advertiser
to
control
that
when
the
S
bit
is
set,
it
restricts
the
path
to
guessing
log
so
that
the
receiver
confines.
D
You
doesn't
use
the
next
stop.
If
it
is
multiple
hops
away
and
if
mbase
is
set,
it
expects
it
to
be
multi-hop
and
if
both
are
set,
then
we
embed
text
percents
and
if
both
are
clear,
then
today's
rules
take
over
where
ebgp
is
single
up
and
ibjp
is
multi-hop
or
you
can
say,
based
on
the
configuration
ebgb
multi
or
whatever.
So
anyway,
local
configuration
Will
trump
any
of
these
signaling.
D
But
it's
it's
giving
ability
to
The
Advertiser
what
kind
of
proximity
check
he
wants
for
the
next
endpoint
being
advertise
in
the
route,
and
then
you
have
other
proximity
constraints,
path,
constraints
like
the
transport
transport
class
ID
or
the
load
load
balancing
Factor.
Basically,
when
you're
doing
load
balancing
how
much
percentage
of
traffic
you
want
to
go
for
each
of
the
next
complex
right.
Please.
D
And
we
also
have
another
forwarding
argument
here:
we
which
describes
a
payloads
encapsulation
info,
what
kind
of
encapsulation
we
want
to
do
towards
that
endpoint.
It
can
be
an
mpls
label
info
and
ins
inside
this.
Basically,
this
information
because
it
is
carried
on
each
Next
Top
leg.
So
so,
if
you
think
about
it
today,
we
take
the
label
from
the
prefix
and
the
next
half
from
somewhere,
and
we
combine
them
together
and
form
the
next
half.
D
So
here
we
are
getting
both
of
them
in
the
same
place
and
the
capabilities
that
we
were
discussing
earlier.
That
is
coming
as
a
separate
attribute.
That
is
also
getting
combined.
So
here
the
capabilities
like
ELC
will
be
part
of
the
MPS
level
info,
where
it
is
it
just
appropriately
scoped
closer
to
where
what
it
describes.
D
Info-
and
these
are
the
encapsulation
types
that
we
know
today
and
newer
ones
may
come
in
future,
so
it
just
accommodates
all
these
different
types
that
may
come,
and
also
there
is
like
this
endpoint
attributes
advertisement,
which
is
like
advertising.
What
is
the
property
of
this
next
topic
advertise
and
it
we
could
be.
We
could
want
to
advertise
multiple
properties
like
available
bandwidth
is
one
today.
It
is
advertised
by
a
link,
bandwidth,
Community
again,
it's
just
another
Community
or
attribute.
D
So
here
we're
just
giving
on
a
per
next
stop
leg
scope.
We
say
what
are
the
properties
of
this
next
stop.
We
want
advertise,
so
this
available
bandwidth
is
used
when
we
want
to
do
ucmp.
That
is
basically
an
equal
cost
load
balancing
and
when
this
is
when
the
prop
constraint
of
what
is
the
balance
percentage
is
required.
Is
there
then
that
is
used?
And
if
that
is
not
there,
then
this
this
one
is
used
to
implicitly
derive
on
the
ucmp
percentage.
D
Sure
and
the
error
handling
is
also
described
in
the
draft,
so
basically
as
a
whole.
It
follows
the
attribute
discard
approach
when
some
errors
are
encountered.
So
unless
there
is
a
length
issue
because
of
which
we
are
not
able
to
pause
at
all,
then
we
will
anyway
bounce
the
session,
but
unknown
tlvis
ignored
gracefully
with
enough
agnostic
data,
and
we
try
to
deal
with
the
era's
gracefully
by
either
ignoring
the
tlv
or
discarding
attribute
and
for
forwarding
actions.
D
D
D
B
E
There
is
eternal
attribute
and
then
there
is
a
bgp
nlri.
Also
that
carries
the
label.
So
in
some
ways,
if
you
can
somehow
work
with
what
is
existing
as
an
attribute,
that
would
be
super
good.
So
that
was
a
comment
and
then
the
question
I
have
is
you're
carrying
label
labels
very
interesting,
so
I'll
stick
to
label
for
a
sec
you're
carrying
a
label
with
next
hop.
E
D
D
And
about
which
address
families
it
is
carried
on
yes,
you're
right,
I
mean
it
may
be,
it
can
be
carried
on
Lu
also
it
can
be
carried
with
unicast
also
and
when
you
carry
it
with
unicast,
because
you
can
specify
a
label
for
unicast
Safi,
you
can
not
use
Lu
and
you
can
just
specify
a
label
with
this
attribute
for
unicast.
Also,
that's
one
application.
E
D
D
So
yeah
I
think
it
is.
It
has
been
kind
of
overwhelming
because
I've
tried
to
go
through
the
all
the
different
type
of
things
that
have
been
done
with
next
stops
in
bgp
so
far
and
put
this
in
format
which
is
like
not
too
involved,
but
still
it
is
extensible
and
flexible.
So
it's
a
lot
of
data
for
you
to
consume,
so
any
comments
offline
on
the
list.
Welcome.