►
From YouTube: IETF104-IDR-20190325-1610
Description
IDR meeting session at IETF104
2019/03/25 1610
https://datatracker.ietf.org/meeting/104/proceedings/
C
D
So
hello
welcome
to
IDR,
and
at
least
we
seem
to
have
a
room,
that's
big
enough
that
everyone
can
sit
down.
Who
wants
to
sit
down?
So
that's
something!
We
have
a
note.
Well,
it's
the
same
note
well
that
everybody
else
has
only
it's
on
a
different
template,
but
you
know
and
and
less
legible.
Like
says,
Jared.
E
Okay,
John
and
I
will
tag-team
this
we've
gone
through
a
couple
interesting
months.
We
thank
everybody
for
meeting
in
an
interim
before
Bangkok
so
that
we
could
continue
the
working
group
business.
We
have
several
holding
patterns
and
I
want
to
sort
of.
Let
people
know
that
there
are
holding
patterns.
E
There
may
be
chairs
on
the
in
the
in
in
the
difficult
seating
to
the
left.
Folks,
if,
if
you
want
to
find
some
so
we're
waiting
for
3575
bist
completion
and
this
miss
was
trying
to
get
the
current
status
of
the
5575
updated,
we
have
Christoph
called
for
feedback
on
implementations,
but
we
really
haven't
seen
that
and
I've
got
several
other
drafts
that
are
waiting
on
it.
E
We
really
need
to
know
how
long
we
should
hold
this
in
order
to
get
that
implementation
we'd
like
to
have
a
hundred
percent,
but
if
you
know
about
fifty
five
seventy-five
implementation
and
can
send
it
into
the
list,
we'd
appreciate
it
so
question:
how
long
do
we
wait?
I'm
going
to
suggest
tax
day
in
the
US
April
fifteenth?
That's
always
something
useful.
E
It's
a
date
that
the
US
people
always
remember
with
bated
breath.
We
have
the
early
allocation
we
extended
to
allocation
pieces
recently,
but
we're
coming
up
on
several
other
allocation.
John
and
I
would
be
thrilled
to
have
implementation
and
send
this
to
the
is
G.
So
we
don't
have
to
go
through
another
early
allocation,
but
we
welcome
sending
this
again.
We
just
need
to
know
that
there's
work
occurring.
Do
you
have
an
implementation?
Do
you
have
something
in
progress?
That's
what
we
needed
for
Eid
distribution.
E
Another
question,
since
we
have
two
implementations,
is
Eid
distribution
ready
to
go?
We
sent
it
through
a
working
group
last
call,
but
we
didn't
get
enough
responses.
So
please,
if
you've
got
this
code
base,
I
will
be
sending
out.
Note
saying:
are
you
ready
to
do
working
group
last
call,
because
these
these
early
allocation
drives
get
first,
first
bid
it
at
that
working
group,
less
cost?
E
Oh
well,
I
other
people
had
general
concerns
about
going
message,
size
and
error
handling
for
BG
p
LS,
if
it
impact,
if
it's
BGP
LS
information
is
impacting
the
path
you'll
find
that's
part
of
the
seventy
six.
Oh
six
car
Vout
and
there
are
many
small
BGP
LS
draft
to
gate
code
points.
We've
made
some
good
way
forward.
I'm
declaring-
and
you
can
come
talk
to
me
that
the
extended
messages
Draft
is
passing
working
group
last
call
I
will
send
this
to
the
list
tonight.
But
if
you
have
some
major
problem,
come
argue
with
me.
E
After
the
the
working
group
where
I
will
send
that
out,
Bruno
and
all
that
I've
seen
in
mail
that
I
could
read
seems
to
indicate
we've
got
some
changes
to
the
final
draft,
but
we're
will
come
to
sort
of
a
consensus
there.
It's
rough
until
we
get
another
round
on
the
draft.
So
please
watch
for
that
and
we
find
there'll
be
a
presentation
on
improved
of
seventy
seven.
Fifty
to
bits
by
Catan
today,
we
think
that
shows
good
progress
in
handling
the
air
conditioning.
E
So
we
think
this
is
a
good
progress
and
we're
just
going
to
let
all
the
drafts
for
the
BGP
LS
in
assuming
that
implementers
can
do
the
right
thing.
With
the
BGP,
LS
and
segment
routing,
we
do
propose
making
it
easier
for
drafts
which
are
going
from
the
IGP
and
we've
talked
to
the
LS.
Our
chairs
and
they'll
query
LS
are
so
that,
if
you
have
a
code
point
in
OSPF
is
is
that
you
can
just
append
that
draft.
Now,
that
is
for
simple
drafts,
and
these
drafts
will
be
Co
reviewed
by
IDR.
D
This
is
basically
for
the
class
of
drafts
where
something's
been
defined
in
the
IGP
is
and
there's
you
know,
we
can
there's
a
whole
little
zoo
of
IDR
drafts.
Basically
say
this
thing
over
here
in
the
IGP.
We
want
an
encoding
in
BG
pls.
Also.
You
know.
We
said
that
this
should
really
just
be.
You
know
in
one
document
just
give
us
the
is,
is
encoding
the
OSPF
encoding
and
the
BG
pls
encoding.
There's
no
need
to
have
a
second
document
for
rest.
D
E
E
If
you
are
ready
and
want
to
come
up
and
tell
me
that,
then
I
will
start
your
drafts
shortly.
Given
a
one-week
hiatus,
most
people
do
not
speak
to
us
a
week
after
ITF,
while
they
catch
up
on
everything
else,
so
I
will
start
it
on
the
six
or
so
of
April.
So
please,
let
me
know
there
is
another
adoption
across
from
heights.
Idr
MSTP
bgp
aggregation
after
we
do
the
presentation
today
we'll
get
a
sense
of
how
quickly
we
need
to
work
that
that
was
from
November.
E
Or
didn't
Jacob?
Do
you
have
another
presentation
on
this
this
time
or
did
I
miss
that?
Okay?
Then
we'll
start
the
adoption,
unless
you
have
something
you
want
to
say
about
it,
I'll
leave
that
to
open
time
on
on
Thursday.
In
case
you
wanna.
We
still
have
some
time
if
you
wanted
a
status
update
since
I
haven't
started
adoption,
but
my
plan
is
to
send
it
forward
to
adoption
request.
Is
that
good,
okay,
partial
implementation
reports?
This
is
where
we
get
stuck
and
I
need
some
input
from
the
group.
We
have
two
implementation.
E
E
Jeff
I
believe
it
was
still
a
partial
okay?
Then,
if
it's
enough,
please
let
me
know
and
I'll
go
forward,
I'm
intending
to
do
it,
because
this
has
been
sitting
there
for
six
or
so
years.
With
these
implementations
in
the
field,
we
have
BGP
tagged
implementations
again
with
two
Cisco's.
We
have
rumors
of
others.
We
do
need
some
indication
from
the
working
group
and
tunnel
and
caps
John
will
cover.
D
So
as
it
stands
right
now,
the
the
document-
you
know
it
has
everything
in
one
place,
so
great
smaller
document
set.
But
the
problem
is
that
not
only
does
nobody
have
a
full
implementation
of
the
whole
thing,
but
it's
unreasonable
to
expect
that
anybody
ever
will
have
an
implementation
of
every
single
tunnel
type.
D
That's
in
that
document,
so
my
feeling
is
that
our
you
know
a
requirement
for
implementation
on
that
should
be
that
you
know
we
sit
down,
look
at
the
document
and
say:
okay,
this
stuff
is
the
fundamental
stuff
and
do
we
have
implementation
of
that
and
at
least
on
top
of
it
and
I'd
be
glad
to
take
feedback.
You
know
on
that
strategy
either.
E
Jenna
and
I
really
need
your
feedback
on
these
partial
implementation
reports
because
we'd
like
to
clear
our
deck,
but
we
we
got
to
clearing
the
deck
and
we
found
sticking
points.
So
we
just
need
some
advice.
If
we
get
no,
if
we
do
not
receive
advice
from,
you
will
just
try
to
do
the
right
thing
and
you
can
complain
and.
E
They
sit
there
and
implementation
I
did
get
the
implementation
status
working
on
the
webpage.
So
you
note
that
it's
past
working
group
last
call
okay.
If
I
missed
yours,
it
is
possible.
Send
me
email
come
up
and
send
it
so
we
can
cycle
through
these
fairly
quickly.
We
will
do
working
group
adoption
or
last
call
pretty
promptly
in
two
weeks.
E
G
G
There
are
three
part:
the
first
thing
that
I
just
make
it
as
seen
our
summary.
As
for
for
a
person
to
be
first
to
first
meet.
Her
are
the
first
time
it
was
say
our
doctor.
Secondly,
in
the
object,
SaLuSa
and
listen
us
in
our
summary,
you
know
in
our
network
we
show
the
fully
topological
we
help
run
backbone
and
about
several
hundred
men
are
or
IDC
connected
to
the
backbone,
and
we
want
to
keep
our
only
position
controller.
So
we
run
true
to
the
end-to-end
traffic
in
the
area.
G
So,
first
we
must
get
the
underlying
apology
from
from
a
rotary
in
media
network.
So
what
country
that
pts
occur
only
gets
the
information
from
Oh
run
Tommy,
so
in
Nina
some
would
find
some
solution
to
the
truth,
interests
of
logic.
So
the
red
graph
is
just
the
abstract
apology.
You
know
there
are
two
two
different
ID
quit
AMI
and
the
connected
to
each
other
and
the
ITB
Mme
trunking
protocol.
G
G
True
scenario
for
this,
for
resistors
in
the
first
day
in
the
native
native
is
narrow.
This
is
the
original
solution
for
network
is
scenario.
They
just
want
to
lead
his
people
connect
interface
as
as
they
SPR
and
carrier,
or
argue
information.
We,
the
pts,
predict
an
eye
right,
so
the
controller
after
Kathy
needs
the
information
control
car.
They
constructed
the
taraji
and
between
different
days,
the
sickness
analogy
for
the
key
key
narrow.
G
G
Considering
the
some
communication
and
complex
in
complexity
of
the
PC
16
in
pragmatism,
we
we
hurry
judgment
to
a
pro
pro
program,
new
interest
because
a
ravine
to
Denise
is
you
know
if
we
put
the
information
in
the
organ
or
pgps
on
air.
Are
you
know,
because
the
trend
for
the
interest
link
located
in
the
different
IT
tamiya?
So
there
you
know
vehicle
for
the
limited,
not
even
myself.
You
know,
actually
the
the
interest
link
just
the
it
actually
one
single
in
the
link,
and
it
is
similarly
the
low
back
interface.
G
So
we
think
you
can't
you
know
defying
the
in
velocity
LR.
It
may
be
better
to
implementation
and
also
for
the
further
distinguish
be
interested
in
country,
in
short,
a
unique,
so
he
sees
the
benefit
for
the
newly
defined
you
know.
I
saw
the
first
thing.
Is
there
you
know
and
you
candy
I'm
guilty
I'm
guilty
for
the
Lincoln
right
and
the
second
is
a
meaningful
for
controller
to
filter
in
hers.
Lianca.
G
If
we
use
a
measure
described
in
the
previous
chapter,
we
must
pass
the
packet,
interlink,
descriptor
and
then
finally
interesting
and
the
interest
in
Troy's
League.
The
so
the
benefit
is
such
a
solution
can
also
be
used
for
native
eyepiece
scenario.
Eloquently
we
for
network
using
our
way,
just
your
the
distribution
and
different
this
different
approach
through
the
solution.
Sorry,
if
you
use
the
newly
defined
you
know
it
can
many
not
to
do
so.
G
We
just
need
to
the
usual
passive
mode
for
inherently
Inca,
so
the
pencil
mode
pencil
ink
also
character
as
one
end
link
so
based
on
this
is
Rosa.
We
can
unify
the
source
of
all
key
and
the
new
addition
arrow.
So
this
is
the
our
petition
for
the
interest
of
lodge
in
each
shoe.
So
any
comment
during.
D
H
So
right
now
we
know
for
PGP
unless
we
have
for
a
lot
of
informations,
such
as
negating
information
and
those
the
news
that
the
information
includes
te
so
right
now,
PGP
also
to
the
signal
routing
policy.
So
when
we
do
that,
we
also
a
locate
some
and
managing
some
resource
information.
So
from
this
front
view,
is
nature
and
also
beneficial
to
let
PGP
e
to
allocate
and
manager
SRP
basics
segment
only
IDs,
because
these
IDs
can
also
be
considered
as
a
some
kind
of
resource.
H
So
here
we
were
to
consider
some
extensions
to
allocate
two
kinds
of
IDs.
Why
is
for
SF
physics?
Note
note
second
alone
Heidi.
Another
one
is
for
SF
physics
agency
IDs.
So
basically
the
extension
is
based
on
bTW
pls.
So
for
PG
pls
we
just
good
collecting
informations
from
Network.
Here
we
go
on
another
direction,
so
we
allocate
ID
and
then
not
be
GPRS
sender,
those
IDs
to
some
elements
of
the
network.
So
here
we
just
introduced
a
new
product
ID.
H
So
for
segments
the
routing,
v6
ID,
so
we
just
using
the
existing
architecture
or
structure
for
the
SIV
for
collecting
SIDS.
So
here
with
just
the
strength,
it'll
be
the
extension
just
so
we're
here.
We
include
node,
ID
and
location
PRV,
so
both
trv
will
contain
the
information
for
sr
physics,
second-round,
ID
and
the
relating
informations.
Here.
H
Basically,
we
we
just
contain
a
to
t
RVs
1
t
RV
well
for
the
second
routing
ID
for
physics,
so
another
one
is
for
locators.
So
these
are
two
information,
so
will
be
enough
for
the
segment
segment,
routing,
v6
IDs,
so
another
type
of
IV
is
a
4h
agency
for
HSN
IDs
for
HSN
IDs.
We
also
use
using
this
same
structure
from
the
peach
pls,
but
here
we
use
also
we
use
a
new
product
ID.
So
this
new
product
ID
we
use
this
new
product
ID
and
then
that
information
via
KO
in
another
direction.
H
H
So
for
the
remote
side,
the
ID
label
well
tidy
because
we
have
two
different
protocols.
Wines
for
ISS
are
not
white
sauce
yet
so
because
those
are
ID,
the
lens
of
that
idea
is
different,
so
for
all
three
F,
which
is
a
user
for
robots.
So
for
SS
we
need
six
packs.
So
here
we
just
introduce
a
new
flag
cover,
all
all
means
of
maybe
also
here
so
we,
the
ID,
will
be
four
bytes
and
then,
if
we
is
not
oh
and
then
this
is,
is
the
sixth
face.
So
that's
the
difference.
I
You
could
Cisco
so
I'd
like
to
bring
out
one
aspect
of
this
draft
and
there
is
similar
draft
for
SR
MPLS,
which
is
also
for
adoption.
So
until
now,
all
the
pls
draft,
in
all
the
fluid
that
we
have
had
are
for
reporting
information
from
the
router
to
or
consumer
or
any
application
like
a
PC
or
something
like
that.
These
couple
of
drafts
are
are
using
PGP
LS
as
a
provisioning
tool
as
a
provisioning
mechanism.
I
E
J
In
fact,
we
discussed
with
the
customers.
So
do
you
have
this
concern
about?
This
is
the
scalability
of
the
SRA
six,
because
now
this
for
the
SR
v6
to
the
seed,
maybe
need
a
more
configuration
than
the
s
armchairs.
In
fact,
the
two
or
three
years
ago
we
proposed
as
a
draft.
That's
the
we
tried
to
yield
the
people
in
the
state
that
were
allocated
as
our
label
yeah,
but
here
we
try
that
who
probable
way
to
distributed
to
allocate
at
this
the
SR
seed,
essentially
to
release
the
concern
on
the
scalability.
J
That's
here,
but
here
I
seen
that
that's
here
you
would
the
people
in
the
CS
data
you
the
single-use
adjusted
who
introduced.
Oh
the
extended
TR.
We
like
this
one
yeah,
but
maybe
we've
seen
that
as
a
PDP
will
be
used
widely
for
the
Isar
implementation,
so
I
think
that
even
use
not
the
PDP
being
state.
Maybe
we
also
can
utilize
the
other
extensions
of
the
PDP
for
this
purpose
to
allocated,
as
I
said,
a.
K
Anyway,
anyway,
I
was
just
going
to
comment
that
we
have
I
mean
I,
don't
want
to
lock
anybody
into
one
operational
model,
but
we
do
have
these
things
in
the
SR
yang
model,
for
both
OSPF
and
is
is
so
that
would
be
one
wait.
It's
not
like
you
couldn't
do
that
I
mean
we
have
NP
RS
now,
but
there's
extended,
there's
also
SR
v6
as
well.
K
I
The
liquor
Cisco,
so
there
are
lots
of
things
to
be
provision
on
routers
and
lots
and
lots
of
them
the
mechanism
that
we
used
for
that
for
seeds
and
locators
and
all
they
are
fairly
more
like
a
provisioning
or
a
configuration
stuff.
They
are
not
like
dynamics
things
like,
for
example,
we
have
BGP
SRD
extension,
the
signal
s
are
policies,
but
they
are
more
dynamic,
control,
plane,
kind
of
a
thing
right
here.
It's
it's
relatively
more
stable.
I
H
Because
right
now
you
see
PGP
already
have
attention
for
a
second,
my
routing
policy.
So
those
are
when
we
do
Madeline.
We
also
needed
to
use
a
resource
and
also
elected,
which
was
right.
So
that's
a
those
segments.
Routing
staff
is
also
thanked
by
PPTP
and
also
the
PGP
wesen
those
information
to
the
equipment
in
the
network
right.
So
here
this
is
a
just
an
average
attention.
So
just
a
litte
bit
more
attention
to
do
need
more
scenes,
for
example,
signal
routing
IDE.
H
So
as
an
Robbie
mentioned
that
so
you
may
be,
we
we
do
extension
to
PG
BLS,
but
we
can
do
general
to
e
change
into
PGP.
So
this
is
a
another
way,
because
these
are
massive.
A
have
a
lot
of
enemies,
for
example,
is
most
scalable,
so
you
can
do
that
again,
CRI
or
whatever
young
model
yeah.
That's
that's
a
nice
way
of
course,
but
these
are
just
provider
and
answer
options.
This
option
they
have
more
benefits,
and
then
maybe
someone
like
this
one.
D
I
have
two
comments
to
make,
but
the
first
one
is
kind
of
me
as
an
individual
contributor,
and
it's
just
because
you
can
do
anything
with
any
protocol
doesn't
mean
you
should,
and
the
second
is
more
with
my
working
group
co-chair
hat
on,
and
it
is
that,
although
we
do
a
lot
of
SR
stuff
in
this
group-
and
you
know
the
IGP
groups
do
the
same-
we
do
you
know
we
have
a
spring
working
role.
Perches
chartered
with
the
segment
writing
architecture,
and
it
seems
to
me,
like
a
bunch
of
what
we've
been
talking
about.
D
H
D
H
Welcome
policy
distribution,
so
this
is
already
was
in
full,
so
this
one
I
think
the
first
option
we're
already
present
that
last
time
just
give
us
summarize
so
first
first
of
option,
just
we
extension
in
the
action
field,
so
we
just
introduced
a
new
piece,
so
this
until
I
copied
well,
when
this
new
flag
they
are
is
set.
Then
that
means
there
is
a
for
our
routing
policy
distribution.
H
So
those
are
rotten
policy
is
the
included,
by
extension,
a
little
bit
extension
to
the
white
community
so
that
we
use
a
new
athleisure
fee
and
then,
under
that
one
we
have
run
you
and
now
our
I.
So
this
tie
so
under
this
knot
and
now
our
I,
we
also
will
use
the
white
communities
or
why
the
community
is
the
same
for
two
options
so
for
attention
to
our
white
community.
H
We
just
you,
tended
a
cup
of
tea
RVs,
so
right
now
in
Y,
the
community
so,
though,
already
define
that
here
these
they
have
a
placard
Calvi
and
the
parameters
TLV.
So
for
the
faculty
RV,
we
interviewed,
we
define
a
new
wealth
attribute
ERV,
so
these
are
all
attribute
LV.
In
fact,
just
that
defies
the
matching
matching
conditions
so,
for
this
attribute
ERV,
we
devised
a
three
new
Saboteur
of
these.
This
suffered
through
several
degrees
of
one
user
for
IP
predicts,
and
that's
why
the
a
is
mass.
H
The
third
one
is
a
community
so
for
the
IP
prefix
operator
V,
we
just
define
this
IP
prefix,
the
matching
type
and
then
IP
address
and
then
mask
and
then
the
great
mask
and
then
the
last
mask.
So
we
couldn't
have
a
mod
for
this
of
visible
items,
so
this
star
between
V
will
define
the
matching
conditions.
So
here,
for
example,
for
about
matching
type
we
can
have
for
exactly
match.
Well,
we
can
have
a
range.
H
We
have
was
four
options.
So,
for
example,
if
we
have
an
exact
match
in
this
case,
we
just
gave
IP
address
and
then
the
mask
and
their
mask
mask
events.
So
in
this
case
with
doesn't
match
this
exact
IP
prefix
base
of
matching
condition
so
another
one.
You
tell
me
that
we
can
give
a
range
master
branch.
So
in
this
case,
we,
the
mask
type,
is
the
three
he
so
we
give
IP
address
masculine
24
and
then
the
grief
mask
is
also
24
and
then
the
last
master
is
a
32.
H
So
in
this
case
that
means
that
we
would
like
much
this
IP
prefix
18.1,
slash
24
so
from
masculine
24
grid
on
this
one
and
worse
than
32.
So
we
give
a
mask
already,
so
these
are
sample
TV,
just
the
define
one
couple
for
matching
conditions,
so
we
also
define
for
the
this,
for
so
for
ipv6.
Similar
Sabbat
lv
will
also
define
stop
deuce
upper
tier
v
called
the
passivity
of
V,
so
V
sub
T
of
V
just
gives
regular
expressions
for
the
matching
condition
to
suit
the
server
lines
for
communities.
H
So
this
one
just
the
Beast
and
Lambeau
from
communities,
so
the
mark
this
gives
us
a
much
matching
condition
is
that
we
need
to
satisfy
all
these
communities.
So
this
is
for
matching
condition
so
also
because
in
the
white
community
will
have
high
level
tier
V
order
parameters,
T
of
V,
so
I
promised
here
V
with
the
finest
to
new
service
to
Delta
V
is
the
pivot.
Just
indicates
the
operations,
so
one
operation
is
about
ma,
ma
ma
e
d
operation.
So
we
can
when
matching
condition,
satisfied
and
then
we
can
do
some
operations.
H
So
here,
for
example,
for
meed
we
can
have
raw
justice
at
the
m82
a
given
value
here
and
then
we
can
add,
and
then
we
can
stop
track.
So
this
is
a
operation
for
the
ME
ME
D.
So
another
one
is
a
some
kind
of
a
change
to
a
as
pass
so
we
can
add
a
sequence
of
s
to
existing
as
the
past,
so
these
are
sequences
of,
alas,
numbers
we
can
define
about.
C
H
H
L
H
H
H
Yeah,
yes,
a
machine,
for
example,
for
PGP
policy,
our
segment
of
policy,
and
then
we
distributed
the
talk
note.
How
can
we
verify
our
stuff?
Is
there
as
a?
What
have
we
expected
right
this
one,
a
similar
scene?
So
we
configured
some
kind
of
policy
which
is
dribble
there
and
what
happening
in
there
is
what
we
expected
under
those
equipment,
so
I
I
think
we
need
to
have
have
some
work
there
to
really
detect.
What's
there.
M
D
N
Yeah
actually
I
want
to
imagine
that
also
we
don't
have
this
feedback
for
many
existing
money
situations
like
a
flows
back
like
the
always
have.
Is
there
SRT
policy
we
need
as
a
maxim
to
give
the
feedback
to
the
back
to
the
controller.
So
I
think
this
is
such
a
narrow
case
for
this
one.
Maybe
also
need
to
consider
that
a.
K
Cylinder,
mass
Cisco,
Systems,
yeah,
I
I
think
in
response
to
that
the
good
thing
about
as
primitive
as
is
just
applying
a
policy
you
do
have
you're,
not
one
level
removed.
So
when
you
send
a
community,
you
don't
know
that
everybody
supports
it.
You
know,
whereas,
if
you
do
rest
confer
or
net
cough,
you
get
an
RPC
response
right
back
saying
whether
it
was
worked
or
not.
You
get.
K
H
That's
a
good
question,
I
think
in
the
you
know,
because
this
is
a
version
pol
I
think
in
the
previous
presentation.
People
already
take
a
why
we
need
this
one.
So
the
reason
is
that
you
know
those
who
trafficker
is
a
dynamic
and
then
the
policy
is
not
a
means
manually.
Sometimes
we
need
to
adjust
or
reoptimize
those
of
house.
H
So,
for
example,
we
have
a
statically
configure
some
pass
and
then
those
traffic
go
through
that
that
pass,
but
because
the
traffic
is
dynamic
and
then
maybe
that
pass
is
too
crowded
and
then
we
needed
to
revolt
with
select.
Another
possible
was
so
in
this
case
we
can
do
manually,
change
it
configuration
and
then
change
the
traffic.
And
then
here,
if
we
have
this.
K
One
right,
but,
but
you
know
there
are
you
know
there
are
products
that
do
this
today
with
proprietary
Co
eyes,
for
people
that
monitor
traffic
and
push
BGP
stuff
all
over
the
network,
and
do
this
already
ya
know
I
mean
in
any,
and
they
could
be
vastly
improved
just
by
using
just
by
using
say,
restaurants,
what
what
they're
doing
in
common
models
that
would
improve
them.
So
I
think
if
you
just
take
those
and
improve
it
with
res
comm.
You'd
have
the
same
advantage
with
none
of
the
complexity,
yeah.
H
J
By
the
way,
in
fact,
I
I,
we
also
have,
however,
used
as
the
CRI
or
the
net
comma
for
such
the
facetious,
such
as
the
perverse,
but
we
have
a
feast
asam,
the
Challenger,
the
first
DC
of
the
CRI
I,
think
there's
the
in
her
ability
usual
and
I.
Second,
why
use
a
performance
a
usual?
So
this
is
a
wide
way.
E
Robin
Robin
can
I,
can
I
just
get
a
tag
on
for
a
clarification
from
Robin.
If
he
comes
back
Robin,
is
it
due
to
the
multicast
feature
of
the
BGP
distributions
that
that
you
find
the
improvement
sort?
Is
it?
Is
it
the
fact
that
BGP?
It
is
point
you
know.
One
point
sender
goes
to
multi-point
receivers
that
provides
the
scalability
that
seem
to
be
in
your
response.
Is
that
did
I
understand
that
correctly,
I.
J
Think
that's
what
we
here.
We
have
this
as
a
father
as
a
policy
that
is
tribute
either
they
had
a
similar.
This
is
our
usual,
but
we're
seeing
Edessa.
You
know
already
less
such
as
solutions.
Yep,
okay,
I'll.
Take
that
as
a
solid.
E
Yes,
that
it's
already
buing,
that's
what
I've
picked
up
from
spring,
so
folks
I
think
that's
what
I
took
out
of
out
of
Robins
comment.
Is
there?
Is
this
one
sender
to
multicast
receivers
for
BGP
that
isn't
true
in
many
of
the
Netcom
situations?
Ac,
you
know
that
might
be
something
for
them
that
come
people
to
think
about
that
problem
of
scaling
and
I.
Think
that's!
That's
really.
What
you're
hearing
a
lot
of
feedback
on!
Thank
you,
Robin.
O
Take
apart
from
Cisco
Systems,
this
tendency
to
use
PGP
to
send
stuff
over
all
red,
that's
fine
and
not
having
the
receiving
the
response
back
now,
so
we
have
stuff
like
Nick,
come
to
duties
or
RPC
to
do
this
and
get
the
feedback
now.
The
reason
they
use
BGP
to
do.
Some
of
these
things
is
to
go
into
a
is
where
one
a
is
asks
for,
flowspec
to
be
installed
by
another,
a
is
and
that
a
is
may
or
may
not
accept
it
in
that's
his
prerogative
to
accept
it
or
not.
Accept
it
right.
O
H
H
D
P
Okay,
can
you
hear
me
all
right?
This
is
what
these
are
working.
Okay,
so
I'm
gonna
talk
a
little
bit
about.
Can.
E
P
P
There's
another
scenario
where
that,
like
typical
enterprise
today,
have
a
CPE
interconnect
by
the
provider
VPN
and
today
they
want
to
be
able
to
utilize
some
additional
bandwidth.
They
also
purchase
for
internet
access,
so
they
basically
can
upgrade
their
CPE
to
have
extra
ports
connect
to
the
internet
and
they
have
existing
ports
connecting
to
the
provider
VPN.
So
for
this
case,
where
that
traffic
going
through
the
existing
private
network
goes
through
them,
natively,
they
don't
need
to
do
encryption,
because
encryption
is
very
expensive.
P
In
addition
to
the
key
management,
the
encryption
self
is
very
process
intensive
and
only
the
traffic
go
to
the
untrusted.
Network
need
to
be
encrypted
and
the
users
it
is
really
the
use
of
policy
some
traffic
they
have
to
go
through
private
network.
Doesn't
matter
how
congested
you
are,
the
private
network
is,
some
traffic
can
go
to
either
one
if
the
private
network
has
bandwidth
goes
through
private
network
unencrypted
natively,
if
the
private
network
is
congested
or
reaching
certain
threshold
goes
through
the
public
network,
but
it's
very
important
to
be
encrypted.
P
So
that's
for
the
CPEs
perspective,
there's
also
service
providers
and
today
they're,
interconnecting
by
private
links,
private
lease
lines
and
for
some
transit
demand
for
increasing
bandwidth.
Instead
of
putting
the
infrastructure
to
add
the
bandwidth
on
today's
many
of
the
service
providers
do
want
to
utilize
available
public
network
so
for
their
PE.
They
can
add
a
port
which
can
interconnect
to
the
public
network
with
the
encryption.
So
so,
if
we
down
to
the
deep,
we
have
those
three
cases
so
for
the
first
case,
everything
encrypted
and
it's
relatively
easier
to
to
handle.
P
Basically,
in
addition
to
today's
l3,
VPN
or
VPN,
to
X,
to
manage
the
client
routes
and
everything
is
encrypted.
But
for
this
that
we
call
hybrid
network
where
you
have
some
ports
facing
the
private
some
ports
facing
the
Internet.
There
are
some
additional
challenges
to
be
brought
into
one
part
being
that
those
ports
facing
the
public
network,
their
IP
addresses,
can
be
assigned
by
the
ice
piece,
depending
on
who
you
buy
service
from
some
private.
Some
of
those
when
ports
can
be
dynamically
assigned.
P
Ip
addresses
some
of
those
web
ports
can
be
using
private
right,
so
those
web
ports
need
to
be
managed
managed
on
the
on-demand.
Basically,
so
one
part
of
them,
st-1
notes,
is
really
the
thermal
property,
meaning
note
can
be
instantiated
on
the
fly
and
being
removed
based
on
demand.
So
it
is
very
important
to
have
the
protocols
to
be
able
to
handle
those
when
ports
are
management.
P
So
the
wind
port
management
is
really
about.
Registering,
is
public
IP
address
private
IP
addresses
many
facing
the
wind
interface.
The
the
uplink,
not
the
private,
for
the
client
side
is
we're
using
the
same
mechanism
as
today,
so
each
CPEs
need
to
register
his
assigned
eyes.
We
assign
IP,
addresses
his
loopback
addresses
and
also
the
the
controller
need
to
be
able
to
manage
the
adjacency,
because
you
could
have
one
CPE
here
in
Park.
You
could
have
another
CPE
another
country,
and
so
the
controller
has
to
be
able
to
manage
the
adjacencies
through
the
public
network.
P
P
So
for
that
purpose
for
managing
the
Wang
ports,
we're
introducing
a
new
I
and
to
register
for
that
CP
to
register
to
the
controller.
So,
coupled
with
this
new
and
I,
we
have
this
newly
assigned
Safi
just
a
couple
with
just
solely
pot
for
the
purpose
of
managing
as
one
ports.
And
so
here
is
the
new
I
structure.
We
defined
them
as
t1
type.
We
defined
the
port
ID.
We
also
define
a
site
ID
site.
Id
is
really
a
property
shared
by
a
set
of
sty
nodes,
because
you
could
have
a
set
of
SD
windows.
P
Sharing
a
common
property,
the
property
could
be.
Regulatory
purpose
could
be
have
some
common
locations,
your
location,
some
traffic
has
to
go
through,
and
then
you
have
the
node
ID,
which
can
be
ipv4
ipv6
addresses
so
for
the
sd1
know,
since
they
can
be
far
apart
and
in
different
locations
who
connected
by
the
public
network.
It
is
depending
on
the
controller,
in
this
case
the
are
to
manage
the
peering
group,
so
that
see
here,
I
just
use
example,
one
CP
in
Dallas,
one
CP
in
Beijing,
and
they
actually
belong
to
one
group.
P
Another
group
may
be
is
in
different
locations,
so
all
those
when
port
address
propagation
is
policy
by
the
PPR
and
then
for
the
port
itself
like
when
you
want
to
register
your
color,
your
port
properties,
the
web
portal
T's.
You
will
have
your
address,
your
private
address.
If
you
use
net
and
what
kind
of
net
do
you
use,
we're
kind
of
and
your
public
address.
So
this
is
the
extended
port
properties.
So
that's
it.
And
if
you
have
any
questions
you
can
ask
me
and
we
have
what
general
the
sd1.
Q
A
Q
P
Okay,
the
reason
for
this
is
really
for
the
wind
port
management,
because
today,
when
you
have
a
CPE,
you
use
CLI
to
manage
all
the
ports
you
configured
at
the
run
ports
right.
You
configure
what
kind
of
interface
you
connected
to,
but
for
this
for
the
CPE
itself
for
the
sd1
CPE,
we're
talking
about
zero-touch
provisioning,
the
know
being
created
by
self
right
and
the
web
ports
they
could
have
dynamic
address
and
those
addresses
need
to
be
reported
to
the
controller.
So
this
is
a
totally
different
aspect
from
what
we've
been
discussing.
So
the.
Q
E
E
O
O
L
O
O
Timestamp,
you
know
when
you've
got
keys
within
your
process.
You
can
you
can
say:
oh,
the
keys
will
be
wrong
because
one
times
ten
to
the
next
time
stamp,
you
can
figure
out.
If
you
got
multiple
routers,
which,
between
you
travels
to
delay,
you
can
find
routing
loops
because
each
of
the
rattles
in
in
the
oscillation
each.
S
This
idea
is
popped
up
before,
at
least
for
the
time
stamp
piece.
Stefan
cater
and
myself
did
a
draft
three
years
back.
I
think
idea,
our
time
stamp.
You
want
to
go
dig
for
it
so
idea
it
we
thought
was
good.
We
ran
into
not
only
the
problems
that
you're
talking
about
here
in
terms
of
you
know,
like
incremental
deployments
as
ugly
things
to
state
compression,
because
you
have
time
stamp
sort
of
colliding.
It's
a
router.
You
have
to
pick
one
of
them
and
you
no
longer
able
to
compress
the
routes
quite
as
well.
S
So
the
idea
is
not
bad,
but
it
does
have
a
lot
of
interesting
fall
outs
and
that
sort
of
motivate
us
at
the
time
to
say
this
might
not
actually
be
worth
pursuing
happy
to
talk
to
you
about
what
we
figured
out.
Could
you
go
a
little
bit
more
into
the
checksum
thing,
because
that
one
seems
a
little
weird
to
be.
O
O
A
S
T
S
O
S
O
Yeah
I
know
these
are
ticks
on
in
TCP,
so
so
between
routers
well,
TCP
takes
on
already
catching,
but
this
is
BTP
interfaces
with
TCP
or
when
TCP
singing
something
to
the
standby,
and
you
get
segmentation
reassembly
going
on
inside
the
box.
This
is
more
so.
The
chicks
on
Pat
is
really
more
for
vendors.
J
J
O
Streaming
telemetry
tools:
you
can
use
more
and
more
change.
You
have
yeah
yeah,
so
your
question
should
be
propagated
on
issues
with
the
propagator
one,
the
next
one.
You
know
it's
up
to
him
so
so
now
you
can
see
the
propagation
between
routers
and
within
different
stages
as
well.
Like
gives
you
information
again,
you
don't
normally
turn
your
song
attendance
on
when
you
have
a
problem
and
you
can.
B
Focus
you
know
queue,
buildups
typically
are
very
transient,
so
it'd
be
interesting,
or
at
least
if,
if
you
have
a
justification
to
what
you
have
said
earlier,
if
you
have
a
use
cases
that
are
laid
out
in
that
draft,
that
would
be
nice
as
to
when
to
inject
this,
when
not
to
inject
this,
because
it's
really
hard
to
figure
out
queue
buildups
and
by
the
time
you
get
to
it.
Probably
the
problem
is
gone,
and
the
second
thing
is
what
robin
said:
if
you
were
to
sum,
do
something
like
this?
B
O
S
The
one
place
that
came
up
in
the
prior
versions
of
this
stuff
that
we
discussed
is
that
sure,
seeing
when
it
pops
out
on
the
wires
useful
thing
BM,
he
can
give
you
that
harder.
The
motivation
is:
where
do
you
do
the
time?
Stamping
do
you
do
it
before,
or
do
you
do
it
after?
This
was
the
thing
that
we
got.
We
discussed
because
part
of
what
you're
tracing
in
some
of
these
cases
is
the
flow
of
where
things
are
passing
through
individual
pieces.
S
That
Beach
be
pipeline
across
many
routers,
so
being
able
to
see
that
on
receipt,
you
got
it
at
a
time,
stack,
epochs
and
export.
You
do
x
y.
That
gives
you
an
idea
that
there's
inner
system
latency
of
some
sort
within
a
box-
and
you
can't
cleanly
get
that
sometimes
from
just
being
P
data.
So
there
is
motivation
for
something
just
beyond
BMP
yeah.
O
When
you
start
the
update
generation,
we
need
the
replication
information.
The
TCP
different
implementations
have
different
stages,
and
so
I
didn't
want
to
get
specific
about
standardizing
in
each
of
the
stage,
because
everybody's
a
little
different.
So
you
put
your
own
numbers
in
for
whatever
you
don't.
D
O
U
The
inter
a
is
te
extensions
for
the
BGP
LS
to
support
the
EPE.
Basically,
you
know
we
saw
the
draft
which
talks
about
what,
if,
since
I
GP
and
this
draft
is
not
about
ITB,
the
second
strap
is
about
what,
if
you
are
doing,
BGP
EPE
and
which
BLS
extensions
to
do
that
for
interest
facility.
Just
as
a
background.
There
are
these
two
drafts,
specifically
the
one,
that's
routing,
a
PE
which
I
believe
it's
refresh
to
18.
U
E
At
this
point,
having
reviewed
your
your
previous
staffed
on
this,
that
talks
about
the
inter
AAS,
was
it
known
that
fast
reroute
was
going
to
be
a
problem?
When
you
wrote
the
first
set
of
segments
routing
information,
you
know,
was
it
discovered
in
deployment,
or
was
this
just
always
planned
as
the
second
phase.
E
R
A
R
What
you're
saying
is
that
F
tells
me
which
link
I
could
use
for
the
backup
okay,
so
so
the
question
that
they
have
is
that
I,
when
I
did
my
review
of
the
EP
draft
I
asked
the
authors
of
that
draft.
So,
okay,
what
the
heck
do
you
do
with
the
beep
yet
because,
okay,
it's
a
little
backup,
but
so
what
right
and
the
answer
that
I
got
back
was
that
it's
implementation,
specific
somehow
you
figure
out
the
other
link
and
somehow
you
and
you
know,
I.
A
R
R
So
I'm
not
saying
that
you
shouldn't
progress
this
draft.
What
I'm
saying
is
that
the
working
group
should
think
about
this,
because
I
can't
say
that
ceiling
for
backup
eligibility
is
implementation
specific
and
that
we're
not
going
to
specify
what
to
do
and
then
we're
going
to
specify
what
right
so
either
we
specify
it
or
we
don't
and
because
that
draft
is
still
not
published,
and
we
still.
We
still
have
a
lot
of
time
to
discuss
that
here.
E
Targeting
off
of
lburrows,
you
know
he
and
I
probably
wondered
about
the
same
thing
as
it
as
how
it
would
actually
work
in
an
implementation.
I
couldn't
quite
imagine
but
I'm,
not
an
implementer
of
SR.
If
this
is
really
something
you've
discovered
an
implementation,
it
might
be
something
that
gives
more
meat
and
substance
to
that
particular
section.
So,
I'm
thrilled
to
see
this
draft
I'm
just
I'm
asking
like
alvaro
bid.
So
how
do
I
put
it
with
the
other
draft?
I
It
could
be
really
provision
by
the
operator
who
knows
how
the
pairings
are
done
and
as
such,
that
backup
is
saying.
So
all
that
would
be
bit
is
saying
that
this
is
protected
by
a
4r
and
that's
about
it.
It
doesn't
really.
We
don't
have
this
thing
where
it
tells
which
one
is
serving
as
a
backup,
and
neither
do
we
advertise
that
in
a
GPS
today.
So
just
okay.
U
The
second
problem
that
we
saw
is
again
in
the
same
scenario:
we
can
assume
multiple
ebgp
sessions,
multiple
lengths
between
the
two
routers
in
this,
when
we
are
doing
ebgp
multi-hop,
for
you
to
be
able
to
really
say
that,
how
do
we
make
this
work
from
our
centralized
consumer
right?
The
local
remote
be
to
be
peering
addresses,
are
not
sufficient
to
identify
today
as
such,
the
drafts
and
the
RFC
that
I
mentioned
before
do
not
clearly
convey
how
I
originally
wanted,
how
peering
is
possible.
So
what
we
are
proposing
is
this
peer.
U
So
let
me
repeat
so
what
we're
proposing
is
pay
Raj
said,
must
be
advertised
for
the
interest
links
and
it
should
contain
the
T
attributes.
Local
and
remote
interface
addresses
and
peer
note
said,
should
contain
the
local
IP
address
now.
The
reason
why
this
is
needed
is
because,
when
the
link
fails
becomes
you
more
can
then
correlate
which
of
the
links
are
connected
to
the
session,
because
it
is
a
multi
hop
session
which
of
this
is
correctly
session
and
therefore
take
appropriate
action.
U
I
R
Was
trying
to
read
really
quick
the
spring
draft
on
epe,
you
pretending
this
is
spring,
so
one
reason
investing
is
because,
if
I
remember
correctly,
the
main
case
that
it
talked
about
was
the
case
where
the
other
draft
is
addressing
right,
the
one
we
all
the
advertising
currently
those
those
external
links,
not
this
one.
Now
that's
not
a
problem,
but
it
may
be
that
the
spring
working
group
wants
to
describe
this
as
well.
That
draft
already
passed
say
a
GE
relation
all
stuff,
but
it's
sitting
waiting
for
something
else
that
hasn't
gone
to
the
ASU.
R
D
T
So
we
have
presented
this
document
before
idea
of
hundred
and
presented
the
first
version
of
it
presented
the
IDF
101,
the
version
3.
With
this
one
we
are
presenting
some
major
updates
to
the
document
after
the
lot
of
discussion
internally
and
implementation.
We
are
aligning
this
with
the
IG
piece,
which
is
actually
makes
the
implementation
simpler.
T
Also,
we
are
I
think
the
implementation
is
matured
enough
and
also
the
relevant
documents
are
mature
enough.
For
example,
the
SR
v6
architecture,
which
is
the
network
programming
document,
is
in
the
working
group.
Adoption
call
and
also
the
SRV
6ep
extensions
is
also
matured
as
a
v6.
Also,
the
technology
has
matured
over
time.
T
We
have
seen
the
deployment
of
SR
v6,
so
this
document
is
complementary
to
the
things
which
are
going
on
with
the
service
6
and
it
helped
with
the
overall
deployment
for
s
services
all
right
at
a
high
level,
the
we
have
noted
tributes
and
we
have
link
attributes
with
node
attributes,
we're
creating
a
new
TLB
to
determine
the
capability
of
the
node,
whether
the
node
actually
understands
the
service
X
or
not,
and
also
an
OEM
quick
capability.
I'll
talk
about
it,
the
MST
in
type
which
you
guys
have
seen
before
for
SR
MPLS.
T
Similar
type
has
been
introduced
for
we
leveraging
the
same
one,
which
is
already
there,
but
we
are
route
izing
with
the
services
the
algorithm
support.
So
what
kind
of
algorithm
is
being
used
with
link
attributes
again,
the
same
and
X
and
the
IGP
attributes
and
the
land
and
X
the
details
are
in
the
document
and
also
a
new
MST
type,
which
is
right
now
is,
is
the
same
using
the
same
MST
MST
TLD
with
prefix
attribute.
We
are
doing
the
SR
v6
locator,
it's
a
new
TLV,
so
I'll
talk
about
that.
T
T
T
So
yes,
our
v6
capability,
as
it
says,
indicates
the
node
is
actually
a
service
xscape
able
or
not
it's
creating
a
obut
which
tells
whether
it's
capable
for
OEM
we're
also
leveraging
the
new
MST
types
which
are
already
which
are
defined
over
here,
which
is
basically
the
ones
and
the
node
points
are
not
assigned
yet,
and
the
algorithm
TLV,
which
is
basically
defined
in
seven
752.
We
are
using
it
for
both
MPLS
and
for
our
services
with
a
contribute.
We
are
creating
n
dot,
X
city
LV.
This
should
not
come
as
a
surprise
to
anybody.
T
It's
pretty
much
standard
of
what
we
have
used
before
similar.
What
we
have
used
before
the
LAN
and
X
TLB
is
also
which
is
the
same
concept
which
we
used
with
MPLS,
and
this
is
MST
type,
which
is
same
as
what
I
described
earlier.
The
prefix
attribute
TLV.
This
is
basically
defining
the
locator
and
also
the
function,
the
metrics
and
the
associated
algorithm.
For
it
example,
you
could
have
a
flex
algo
associated,
which
is
associated
algorithm
with
that
and
some
of
the
flags
which
is
basically
the
down
bed
and
any
cost.
T
Then
lri,
which
I
was
describing
just
to
reduce
the
size
of
the
Noda
Lara
we're
describing
a
new
SR.
We
succeed
and
Lara
to
carry
the
survey
succeed.
Information
from
that
node
and
corresponding
descriptors
are
being
defined,
which
will
carry
the
information
TLV.
So
there
could
be
multiple
sub
dlv
is
carrying
all
the
seeds
of
that
node
and
learning
the
capabilities
which
that
node
is
capable
of,
and
thus
its
associated
with
that
so
and
then
there
is
a
already
a
multi
topology
identifier,
which
is
defined
as
77052
very
using
that
all
rights
it
attributes.
T
So
we
are
defining
the
function
and
the
algorithm
for
a
service.
It
said
it's
the
same
concept
for
the
function
that
algorithm,
which
has
been
described
before.
So
it's
pretty
straightforward
and
the
peer
note
said,
which
is
for
the
eb.
We
had
defining
the
peer
said
and
also
the
peer
set
said
same
concept
for
the
EP
document,
which
is
going
through
the
working
group
right
now,
all
right
with
that.
As
I
said,
it's
pretty
similar
to
the
concepts
which
we
have
used
before
for
sr.
T
We
are
just
extending
the
same
things
for
a
service
6
and
over
all
the
adoption
of
SR
v6
is
the
technology
has
improved
quite
a
bit.
We
even
as
linden
and
in
some
of
the
hyper
scales
we're
seeing
the
use
cases
for
keeping
it
simple,
I
think
the
technology
itself
has
seen
that
option.
Some
of
the
vendors
have
seen
the
implementation,
and
even
some
of
the
customers
have
deployed
it.
So
I
think
it's
with
this
SR
v6
be
TLS
extensions.
T
K
E
T
T
We
don't
define
you
musty,
it's
the
MSD
type,
which
is
already
well.
Actually,
there
is
a.
Let
me
go
back
to
that
slide.
Maybe
if
you
answer
correctly
just
it's
basically
the
same
concept,
which
is
there
for
the
MST.
We
are
using
it's
for
the
functions
which
we
need
for
segment
auditing
v6
to
work.
No.
R
T
T
N
T
I
The
I
GPS
a-gps,
we
have
very
limited
amount
of
said,
that's
advertised,
which
is
basically
the
end
said,
and
there
can
be
a
few
of
them,
whereas
in
BGP
LS
we
could
have
many
moods
and
it
again
goes
back
to
the.
If
all
of
these
seeds
service
exceeds
were
advertised
as
a
node
attribute.
In
the
same
way,
then
we
would
really
grow
the
BLS
message
size.
I
N
T
T
T
E
D
D
I
I
I
There
have
been
lot
of
questions
and
discussions
on
the
mailing
list
about
you,
know
bt
pls,
carrying
the
information
in
BGP
and
the
kind
of
checking
handling
error,
handling
semantic
checking,
and
all
of
that
that's
needed
to
be
done
so
to
set
the
context.
One
of
the
first
things
in
the
update
is
introduction
of
some
terminologies,
which
we
hope
will
help
describe
the
role
of
the
digital
implementation
and
what
needs
to
be
done,
you
know
as
BLS
is
information
is
propagated.
I
I
So
we'll
talk
about
that
in
in
a
bit
few
other
things
key
things
is
this
bTW
pls
attribute
and
as
we
keep
adding
more
and
more
TL,
B's
and
extensions,
there
is
a
concern
that
we
would
hit
the
4k
digital
update
limit.
So
we
talked
a
bit
about
that
at
this
point.
They
don't
really
practically
see
us
there,
but
potentially
this
is
definitely
possible.
I
So
it's
better
to
address
it
upfront
and
then
there
are
some
other
minor
editorial
changes
and
introduction
of
some
private
views
to
alvey's
so
to
start
off
and
set
the
context
updated
by
the
diagram
in
the
draft
a
little
bit
and
introducing
these
roles.
So
the
first
one
is
the
BG
pls
producer.
Now
this
is
a
node
as
a
BGP
speaker
which
originates
or
introduces
information
into
bicha.
Pls
I
mean
it
could
be
coming
from
the
IG
piece.
It
could
be
the
nodes,
local
properties.
All
of
that,
so
it's
really
originating
information.
I
Then
we
have
a
BGP
LS
consumer
is
shown
by
the
consumer
block.
Now
this
is
actually
an
application
or
a
process
or
a
controller
or
any
of
those
things
that
is
actually
using
the
BGP
LS
information.
As
information
signal
wire
to
do
some
functionality,
the
functionality
would
be
application-specific
in
that
now
technically.
This
is
would
like
to
kind
of
separate
it.
So
it's
not
really
the
BGP
speaker
of
the
BGP
implementation.
There
is
a
kind
of
fine
line
that
we
probably
need
to
draw
there,
because
this
consumer
application
is
born
the
scope
of
digitalis.
I
So
that's
one
of
the
key
aspects,
and
then
we
have
what
we're
calling
of
the
BGP
LS
propagator.
So
this
is
really
a
BGP
implementation
that
is
handling
the
BGP
update
messages
with
new
state
information
in
it
you
were
performing
best
path,
calculation-
and
you
know
it's-
it's
really
just
exchanging
or
transporting
the
BGP
or
less
information
kind
of
optically.
In
this
picture.
I
When
we
have
this
deployment
with
route
reflectors-
or
you
know,
information
going
across
multiple
s-
we
can
would
have
really
something
like
a
BGP
route
reflector
this
rrn,
which
is
really
simply
propagating
the
information
right,
but
but
the
propagator
piece
and
these
rules
are
not
really
neutrally
exclusive,
so
the
same
BGP
implementation
can
actually
be
originating
information
into
BGP
LS.
It
could
be
propagating
certain
other
information
and
maybe
also
handling
us.
I
Next,
we
come
to
the
link
state,
NL
arise
and
RFC.
77
52
has
defined
three
types,
but
we
have
more
being
introduced
by
other
drafts.
Some
of
them
are
working
with
documents.
Some
of
them
are
waiting
for
adoption,
but
what
needs
clarification
is
that
implementations
must
handle
unknown
NRI
types
in
opaque
manner,
so
they
should
be
able
to
process
and
propagate
these,
and
this
is
what
we
would
would
enable
us
to
introduce
new
extension
without
requiring
upgrade
of
the
BJP
infrastructure.
An
example
is
our
out
reflector.
I
Now
within
the
NLRs
we
have
a
bunch
of
tlvs
that
can
be
used.
They
are
called
descriptors,
so
node
descriptor,
prefix
name,
distributors
and
other
types.
So
the
proposal,
the
already
detects
in
RFC
7750
to
indicate
that
we
need
to
handle
it
unknown-
unsupported
tlvs
in
there.
But
what
we're
adding
is
that
they
don't
require
BGP,
because
a
BGP
implementation
proposed
semantic
validation
on
you
know.
What's
really
in
the
TLB
values
and
fields,
so
obviously
we
need
to
do
the
syntactic
validation,
so
that
lengths
and
all
of
these
informations
are
proper.
I
So
we
can
parse
and
process
the
BGP
messages,
but
not
really
going
to
the
semantics,
and
this
is
because,
as
more
and
more
again,
LVS
and
information
gets
added,
we
don't
want
to
bring
in
a
lot
of
these
new
complexities
or
things
into
the
base
budget.
Implementation,
like
you
know,
just
think
about
from
a
BGP,
LS
propagator
point
of
view.
I
The
only
rule
which
is
there
and
it
comes
in
the
existing
RFC
77
52-
is
that
the
tobey's
types
in
the
NLRA
are
organized
in
ascending
order,
and
this
is
required
so
that
we
do
not
have
multiple
instances
of
the
same
information
being
appearing
as
different
NLR
eyes
in
the
BGP
tables.
Just
because
you
know
somebody
is
arranging
it
in
any
order,
so
it
is
just
mainly
to
help
that
and
if
not
then
trying
to
clarify
that
it
could
be
considered
as
a
mile
from
NLRA.
I
Next,
we
talked
about
the
BG,
polis
attributes
and
even
within
this,
the
tlvs
are
proposed
to
be
handled.
Opaquely
I
mean
this
is
already
existing
thing,
which
is
there
we're
just
trying
to
clarify
this
in
document
here
there
is
no
need
for
ordering
by
TLB
type.
Any
of
those
limitations
are
there
and
any
unknown
unsupported,
even
unexpected.
The
enemies
know
should
be
handled
opaquely.
B
I
I
I
One
other
option
is
that
you
know
a
producer
can
have
our
implementation
can
provide
a
limit
at
a
producer
where
the
number
of
tlvs
or
what's
put
in
there
is
limited,
and
then
you
know
again,
it's
applications
dependent
on
what
tlvs
are
important
or
not
in
palm
important,
but
we
let
the
producer
decide
on
that
right
now,
it's
possible
that
we
have
done
that.
But
still
the
update
message
grows
as
it's
propagated.
Let's
say:
I
mean
s.
Path
is
added
or
some
other
thing.
I
So
here
we
are
talking
about
attribute
discard,
but
we'll
come
to
it
in
the
salt
management.
To
answer
Q's
question:
the
proposal
is:
when
we
discard
the
attribute,
we
still
propagate
the
actual
link,
state
and
lri
all
the
way
to
the
consumer.
So
when
a
consumer
sees
a
link
state
and
an
arrived
without
any
attribute
in
it,
that's
kind
of
like
say
a
hint
that
you
know
this
information
is
not
to
be
drawn.
E
D
I
Next
is
instance
identification
in
gujja
pls,
so
we
have
multi
domain
IJ,
P
topologies,
which
are
listed
objects
from
where
are
advertised
out
by
a
pls.
So
a
consumer
sitting
on
path
can
really
have
a
clear,
multi-domain
tautology
view
of
of
the
network.
Now,
in
order
to
do
so,
we
need
to.
We
have
something
like
we
have
64
bit
identifier
in
the
NL
RI,
and
this
is
called
a
bt
pls
instance
identifier.
I
So
this
can
be,
you
know,
is
applicable
both
for
multiple
IGP
domain,
so,
let's
say
multiple
routing
processes
on
the
same
node,
but
also
can
be
used
for
multi
instance,
where
we
have
multiple
instances
of
the
same
ip
running
on
a
single
link.
So
this
identifier
is
configured
at
a
GP
instance
level
on
the
producer,
such
the
load,
which
is
originating
the
information,
and
when
we
have
multiple
bt,
pls
producers
advertising
pathology
information
from
the
same
ip
domain.
I
I
I
So
specific
to
link
state
and
an
arise
now,
then
the
error
in
the
mean
state
and
lri
or
the
TLB,
is
in
there
is
such
that
we
cannot
really
parse
or
process
the
message.
Then
we
have
really
not
much
option
but
to
do
something
like
a
session
reset
right
are
in
case
where
it's
possible
and
supported.
When
we
have.
We
don't
have
such
an
isolation.
We
can
do
I,
think
disabled.
I
So
these
are
just
you
know,
recommendations
things
would
also
depend
on
by
on
the
implementation
aspect.
Right
now,
when
the
error
is
affecting
a
specific
NLRA
or,
let's
say
all
the
link
state
and
an
arise
in
that
in
that
update
message,
then,
but
we
can
really
identify.
We
don't
have
a
problem
in
parsing
or
processing
the
message.
Then
we
can
treat
it
as
traitors.
We
draw
right
or
ignore
this
thing.
I
Similarly,
for
the
BGP
LS
attribute
it's
it's
somewhat
similar
on
on
when
we
need
to
do
something
like
a
session
reset
or
as
we
disable
and
when
the
error
is
within
the
BGP
LS
attribute
itself,
so
some
TLP
within
it
has
doesn't
have
the
correct
length
or
so.
But
the
BGP
LS
attribute
length,
for
example,
is
is
fine,
I
mean
so
it
can
be
read.
Then
we
would
it's
the
really
the
attribute
discard,
which
is
there
in
the
existing
RFC
7750.
I
That's
a
recommended,
but
here
well,
looking
for
the
actual
NLRA
listed
and
I
rely
to
continue
to
propagate
without
the
BGP
LS
attribute,
so
that
the
consumer
does
not
misinterpret
this.
As
that
link
state
object,
let's
say
a
node
is
going
out
of
the
network,
so
it
still
sees
that
object
in
the
network,
but
it
doesn't
have
information
about
it
and
the
the
idea
there
is
that
it
probably
enables
some
sort
of
a
diagnostic
to
go
and
look
back,
and
you
know
figure
out
where
this
problem
happened.
I
One
other
clarification,
I
mean
it
might
be
obvious,
but
we
need
to
clarify.
Is
that
when
we
say
be
GPL
is
attribute
to
discarded
it's
not
for
individual
TVs,
the
entire
attribute
is
getting
discarded.
I
mean
there
might
be
some
kind
of
ambiguity
in
there,
sometimes
so
on
the
fault
management-
and
you
know,
error
handling,
obviously
appreciate
feedback
discussions
offline
or
on
the
mailing
list.
I
Next,
so
this
is
about
it's
not
something
which
has
been
discussed
on
the
mailing
list,
but
based
on
implementation
and
deployment
feedback.
I
want
to
run
through
this
example
and
it's
about
handling
of
unreachable
IP
nodes
in
a
network.
So
let's
take
this
picture
here
and
say
it's
running
OSPF
as
IGP
and
the
we
have
this
link
between
r2
and
r3
in
area
zero
and
all
the
other
links
are
in
area
one
and
we
have
R
2
and
R
3
as
the
bgp
LS
producers
who
are
advertising
the
information.
I
So
they
would
do
it
for
both
area
0
in
area
1
to
be
GP
r,
r
r0,
which
is
then
passing
it
on.
Let's
say
to
a
consumer,
so
consider
the
scenario
where
the
link
between
R
Phi
and
r6
goes
down.
Now.
This
is
a
link
state
I
GP.
But
what
happens
is
that
on?
Let's
take
look
at
r2
on
the
on
our
toe
in
the
link
state,
LS
d
b
FR,
it
still
continues
to
hold
the
the
router
LSA
of
r6.
I
Now,
in
this
router,
unless
a
of
r6,
the
link
from
r6
to
RF
is
still
present
in
that
router
LS
a
because
here,
if
you
see
when
the
link
is
broken,
the
area
1
is
getting
partitioned
into
two
thoughts
right.
So
R
2
still
has
the
router
LSA
of
our
six,
which
is
kind
of
stale,
but
that
continue
contains
the
link
from
our
six
to
our
five,
whereas,
since
alpha
is
still
connected
to
r2,
r2
receives
the
updated
router
Lisa
from
r5,
which
does
not
have
the
link
from
r5
r6
anymore.
I
Okay,
so
and
the
converse
happens
in
the
case
of
r3.
Now,
if
our
202
just
advertise
everything
that
was
in
LSD
B
and
on
on
its
IGP
node,
then
what
would
happen
is
that
r2
will
advertise
the
half
link
and
a
link
and
an
arai
from
r6
to
our
five,
which
is
it
gets
from
the
stained
router
a
lesser
of
r6
and
r3.
I
Does
the
reverse
now,
when
these
updates
go
on
to
the
BGP
route,
reflector
r0?
These
are
actually
two
different
and
LR
eyes,
and
you
know
they
would
just
go
through
to
the
consumer.
There
is
no
nothing
in
the
BGP
update
processing
which
will
you
know,
select
or
one
over
the
other.
So
when
it
goes
to
a
consumer,
consumer
actually
sees
a
complete
link
because
it
has
two
half
links.
It
sees
that
alpha
and
r6
are
connected
to
each
other,
so
it
does
not
really
get
a
true
picture
of
the
underlying
network.
Topology.
I
A
different
aspect
of
it
is
even
let's
say:
the
r3
is
based
on
the
BGP
best
path.
Processing
r3
is
the
preferred
node.
So
what
happens
is
for
all
the
nodes
are
one
r5,
r6
and
r4.
There
is
these
state
objects
are
being
advertised
by
both
r2
and
r3,
and
let's
say
that
in
the
same
broken
link
case,
r3
is
really
the
preferred
source
by
r0.
Maybe
the
next
stop
is
you
know,
that's
it's
a
better.
Next
stop.
I
So
the
solution
for
this
is
that
much
like
what
how
it's
done
in
the
IG
piece,
but
the
node
B
G
Palace
producer,
which
is
distributing
information
into
BGP.
The
drawers
information
pertaining
to
notes
which
are
unreachable
to
it
in
the
IGP,
so
IG,
please
do
not
use
information
or
NSA's
or
a
recipes
from
nodes
which
are
unreachable.
We're
asking
that
the
same
be
done
when
they're
originating
information
into
bujji
pls.
I
I
I
Some
things.
Little
to
OSP
of
route
type
needs
to
be
mandatory,
TL
v
for
the
prefix
analyze,
because
we
can
have
multiple
route
types,
some
new
things
which
have
come
up
like
OSPF
support
for
node
name.
This
is
been
added.
There
is
some
clarification
on
session
isolation
for
BG
pls.
That's
there.
In
the
operational
section,
operational
consideration
section
and.
I
I
B
Capital
arcus:
can
you
go
back
to
the
last
slide
yeah
my
suggestion,
my
suggestion
is
to
move
some
of
these
things
into
a
different
draft
as
a
not
include
as
part
of
the
base,
because
for
the
folks
who
have
implementations,
we
would
like
to
simply
fix
what
is
covered
in
the
base
and
still
be
conformed
to
the
RFC,
as
opposed
to
adding
the
new
set
of
information.
That's
been
proposed.
L
V
Change
the
rotten
or
luciana.
Actually,
we
did
have
an
implementation
of
BGP
others
and
we
find
two
specification
bugs
in
OSPF.
One
is
very
basic.
Basically,
for
this
year
the
nose
to
musk
is
missing
and
the
other
one
is
very
complicated,
just
a
little
bit
the
sameiras
coming
into
an
area,
and
then
they
have
the
router,
IDs
and
route
who
you're
supposed
to
ever
I
think
next
hub
field
or
something
of
that
sort.
That's
also
missing
get
to
the
details
on
that
sure.
I
I
D
So
right
so
now
you
can
catch
Catan.
You
know
between
now
and
Thursday,
I,
volunteered
and
yeah.
We'll
continue
on
Thursday.
Thank
you,
everybody
I
checked
and
on
Thursday
we
do
not
have
a
crazy
room
with
a
giant
column
in
the
middle
of
it.
So
there's
that
so
Thursday,
oh
and
if
anybody
hasn't
blue
shaded
to
please
blue
sheet,
because
that's
the
reason
we
get
these
tiny
rooms.