►
From YouTube: IETF101-IDR-20180319-1550
Description
IDR meeting session at IETF101
2018/03/19 1550
https://datatracker.ietf.org/meeting/101/proceedings/
A
B
B
Which
means
he
gets
to
jump
the
line,
if
he's,
if
he's
carrying
questions
from
the
jabber
room,
we
have
a
new
note.
Well,
it's
different
from
the
one
at
the
last
meeting,
so
you
may
think
you
know
what
it
says,
but
you
may
actually
not
it's
not
my
job
to
explain
it
to
you.
It's
your
lawyers
job
or
it's
your
job,
to
read
it
to
yourself.
But
if
you
want
something
to
explain
it
to
you
and
tell
you
what
it
means
talk
to
your
lair
but
do
read
it
it
matters.
B
So
I
several
orders
of
business
for
the
chairs
this
time,
first
of
all,
just
to
repeat
for
those
who
are
still
filtering
in
sue
will
not
be
here
at
this
time
she
was
expecting
to,
but
had
a
last-minute
illness
hope
she
gets
well
soon
and
I'm
sure
many
of
you
would
also
like
to
send
her
a
you
know.
A
get
well
soon
hope.
B
One
of
the
things
they
want
to
know
about
is
Transport
Security
and
they
get
extremely
testy
about
the
fact
that
md5
is
unhip
deprecated
and
so
they
say
insecure
and
you
know
unfit
for
use
by
self-respecting
people,
and
this
makes
it
difficult
to
advance
advance
drafts
tends
to
make
extra
work
everything
for
us
and
for
them
actually
because
takes
two
to
tango
hard
to
argue
so.
The
the
MPLS
folks
have
to
deal
with
this
also,
as
do
several
other
groups,
and
so
from
their
perspective.
B
C
C
Security
obviously
wants
everything
completely
protected.
I
think
there
are
other
operational
realities
that
we
have
to
deal
with,
and
it
is
some
operational
reality
is
not.
Everyone
runs
authenticated
in
the
networks
and
that
maybe
we've
75
for
other
things,
not
necessarily
authentication
of
BGP
sessions,
but
you
know
to
make
sure
that
the
guys
didn't
fat-finger
their
configuration,
for
example.
C
So
we
have
been
talking
to
the
security
these
for
a
while,
in
fact,
back
in
Singapore,
we
had
a
meeting
with
them
and
with
the
routing
area
chairs
to
start
talking
about
this
and
I.
Would
we
agreed
on
is
to
start
some
kind
of
effort
to
better
communicate
with
them?
You
know
what
are
the
circumstances
of
the
issues
that
we
see,
because
I
personally
think
that
it's
not
just
a
matter
of
documenting
new
mechanisms,
I
mean
we
can
specify
anything.
C
We
want
TCP,
md5
or
Nazi
TCP
AO
has
been
specified
for
many
years
and
then
the
RFC
it
actually
says.
Well,
maybe
we
should
use
that,
even
though
it
didn't
make
it
mandatory,
but
it's
a
matter
of
implementation
and
deployment
of
the
things,
so
we
agreed
with
them
and
Deborah
Bremer.
The
other
ID
is
leading
this
effort.
Is
we
agreed
to
document
scenarios
and
I'm
gonna
call
them
use
cases
for
security
considerations
and
routing
so
that
when
we
say
things
like
well,
it's
senticles
because
I'm
running
inside
a
single
domain.
What
does
that
mean?
C
C
We
hope-
and
this
is
sort
of
a
stretch,
goal
that
we
might
come
up
with
some
templates-
that
we
can
say.
Oh
look
at
that.
Here's,
an
IG
P
or
here's
beach,
B
copy
that
template
and
put
it
in
the
security
considerations
so
that
the
security
area
knows
what
this
is.
This
happens
periodically
because
we
are
do
we
change
a
DS,
so
the
next
CD
is
gonna
come
and
ask
us
the
same
questions,
and
so
we
decided
that
it
would
be
a
good
chance
to
document
some
of
these
things.
C
This
all
doesn't
mean
that
we
shouldn't
do
new
work
or
that
we
should
never
worry
about
security
again
and
much
less
that
we
shouldn't
at
least
mention
security
considerations.
Is
there
something
that
could
happen
because
you
put
some
extra
bits
in
the
packet?
Well
think
bad
things
could
happen
if
we
put
extra
bits
in
someone
changes
up.
So
maybe
we
write
that
down
and
say:
well,
yes,
but
I'm
running
inside
my
single
domain.
So
it's
okay!
C
So
yes,
please
go
to
the
ampulla
session.
If
you
really
care
about
this,
please
talk
to
Deborah.
If
you
have
more
thoughts
or
ideas
or
want
to
participate
in
the
fighting
guidelines,
use
cases
whatever
we're
going
to
call
them.
This
may
end
up
in
a
document.
It
will
most
probably
end
up
in
a
wiki
somewhere
where
we
can
all
go
and
say
here's
the
considerations
and
put
them
there
and
add.
Then
specifics
for
your
block
clarification.
B
Question
yes,
so
as
far
as
I
understand,
which
I
don't
know
a
whole
lot
more
than
what's
written
on
this
slide
at
MPLS
they're
going
to
be
talking
about
this
draft-
and
you
know
stuff
closely
surrounding
this
draft.
What
you're
talking
about
now
is
a
separate
additional
effort.
This
draft
relates
to
it.
You
know
it,
but
this
is
so.
We
can
go
to
MPLS
and
talk
about
this.
We
can
find
Deborah
and
talk
to
her.
B
C
C
B
C
C
So
they're
gonna
talk
about
there
as
well
to
get
some
guidance
and
that
TBD
cryptographic
mechanism,
because
apparently
the
TCPA
Oh
RFC
doesn't
actually
mandate
what
the
crypto
should
be.
So
you
know
they're
going
there
to
get
some
guidance
on
on
what
should
we
put
there
I
mean:
do
we
put
sha
whatever
or
something
else
to
get
guidance
evidence
there
now
I
think
again.
This
is
these
are
good
things,
I
think
that
the
implementation
and
deployment
realities
are
different
than
us
just
producing
security
documents
and
then
getting
all
the
cryptography
in
there
in
place.
D
B
The
next
thing
is
to
start
to
think
about
where,
where
we
introduce
bottlenecks
into
those
processes
and
and
how
we
could
avoid
it,
and
there
are
two
specific
things
I
noticed,
one
is:
if
you
request
an
out
of
sequence
code,
point
FCFS,
then
you
get
punted
onto
the
exception
path.
Basically,
I
Anna
says
chairs.
Do
you
you,
okay
with
this?
B
That's
clear
and
it
usually
is
clear
if
you're
a
subject
matter
expert
and
have
carefully
read
the
entire
draft,
but
it's
not
at
all
clear
if
you're,
not
all
of
those
things
and
guess
what
Diana
people
don't
actually
want
to
read
your
draft
in
detail
to
understand
what
it
is
you're
asking
for.
That's.
Why
there's
a
separate
section
so
the
these
are
the
two
not
so
much
requests
from
the
chairs,
but
suggestions
from
the
chairs
to
make
things
move
smoothly,
which
is
have
a
clear
and
a
consideration
section.
B
B
You
know
once
you're
ready
to
actually
do
your
implementation
just
request
the
code
point
already.
So
that's
it
for
those
and
related
to
that
we
have
one
early
pending
early
allocation
request
that
I
know
of
right
now,
which
is
this
one
and
it
does
need
an
update
and
then
we
should
move
it
right
along.
So
I,
don't
think
that
will
take
too
long,
assuming
the
the
authors
are
responsive
on
that
one
yeah.
So
this
is
the
sort
of
document
status,
section
and
I.
Don't
necessarily
claim
that
I
have
caught
everything.
B
So
this
is
a
good
time
to
pay
attention
or
go
back
and
review
the
slides
later.
If
you
have
a
draft
of
the
year
or
wondering
John,
why
haven't
you
acted
on
my
draft
because
I've
been
waiting
for
a
long
time
you
might
go
and
see
if
the
name
of
your
draft
is
on
here
and
if
not
ping
me
either
on
the
list
or
you
know
cast
or
in
the
hallway
or
whatever
makes
you
most
comfortable.
So
we
have
several
working
group
last
calls
pending.
B
We've
got
the
the
segment
routing
X
dough
for
scheduled
to
end
in
two
days.
So
far
it
looks
well
supported.
There
was
some
discussion
on
the
list
about
semantic
validation
of
tlvs.
I
am
not
sure.
If
that's
you
know
fully
concluded
or
not,
but
right
now,
if
I
had
to
make
the
call
I
would
say,
there's
consensus
to
advance
it,
but
I
would
also
go
back
and
check
that
semantic
validation
discussion
more
in
more
detail
to
make
sure
that
has
closed
in
a
satisfactory
way.
B
There's
a
request
for
te
PM
bgp.
It's
been
asked
for
I'll
start
at
tomorrow,
and
then
there
was
a
last
call
for
extended
messages
a
few
months
ago
and
that
had
a
bazillion
messages
on
it
and
the
last
call
was
inconclusive.
Shelby
say
there
was
yeah
I'm,
not
gonna,
comment
more
except
to
say
that
we'll
try
to
figure
out
how
to
unbreak
that
log
jam.
B
Okay
and
then
prefix
said
we
I
sent
something
him
onto
the
list
on
this
too.
So
we
we
had
a
last
call
on
that
and
it
made
it
most
of
the
way
through
the
is
G,
and
then
it
came
back
to
us
with
some
comments
to
fix.
Ac
did
the
fixes
and
it
got
sent
back
out
there.
It
was
a
big
change
which
was
to
take
out
the
v6
said,
and
everybody
I
think
knew
about
that
cuz.
That
was
flagged
as
being
like
you
know
here.
B
B
Yet
it
did
stand
out
of
the
discussion
on
the
list,
which
is
great,
but
I
didn't
see
that
you
know
any
that
there
was
like
actually
a
thing
to
the
list.
That
said,
hey
by
the
way
you
know,
based
on
the
conversation
I
made,
this
change,
so
I've
sent
a
thing
to
the
list
pointing
this
out
and
I'm,
pointing
it
out
here
also,
which
is
that
the
version
16
text
had
an
either-or
option
for
what
to
do.
B
If
you
get
multiple
prefixes
with
the
same
label
index,
the
new
version
takes
away
the
either/or
and
it
just
says:
do
it
one
way
speaking
personally
I
like
do
it
one
way
better
than
you
know
a
menu
of
options?
So
I'm
happy
with
that,
but
I
just
wanted
to
make
sure
that
you
know
everybody
knows
about
this.
You've
been
warned
in
particular.
B
B
Okay,
there's
a
whole
bunch
of
stuff
where
we
concluded
a
working
group
last
call
and
it's
waiting
for
something
mostly
is
waiting
for
a
document
Shepard
to
finish
their
work
on
one,
the
optimal
route,
reflection
document.
The
document
Shepard
is
done
and
sent
a
bunch
of
questions
and
comments
to
the
authors
and
I
never
got
an
answer
to
that.
So,
hey
authors,
that's
it
for
me.
So
next
is
Shriram.
B
E
So
so
we
recently
submitted
uploaded
a
o8
draft
and
this
slight
points
out
what
the
differences
are
compared
to
the
oh
seven
version,
the
previous
version.
The
new
draft
primarily
focuses
on
the
RLP,
which
stands
for
route
leak,
protection
solution
which
is
and
this
our
LP
solution
is
an
inter
AAS
multi-hop
solution,
as
opposed
to
another
draft
that
that
is
also
currently
progressing
through
the
IDR,
that
is,
the
IDR
BGP
open
policy
draft
and
that
draft
covers
the
intra
AS
or
locally
as
solution.
E
So
what
do
you
do
within
na
s
locally
to
prevent
route
leaks
and
the
draft
that
I
am
talking
about
focuses
on?
What
do
you
do
when
it
out
Lee
goes
across
a
SS?
How
do
the
SS
coordinate
to
detect
and
and
then
stop
the
doubt,
leak
or
block
it?
What
we
have
done?
The
big
change
we
have
made
in
this
draft
in
this
new
revision
is
first
thing
to
just
focus
on
the
our
LP
solution
in
the
main
body
of
the
draft.
E
A
second
thing
there
were-
and
there
are
a
number
of
useful
other
sections-
those
those
sections
have
been
moved
into
the
appendices
and
the
reason
for
that
is
those
those
related
relate
to
things
which
are
not
required
to
describe
the
solution
so
first
forth,
so
they
contain
things
like
related
prior
work,
review,
design,
resist
rationale
and
discussion.
So
over
the
last
two
or
three
years
that
this
draft
has
been
active
in
this
group,
there
have
been
many
questions
in
a
lot
of
interesting
discussion,
so
that
section
captures
the
those
aspects.
E
The
questions,
as
well
as
the
design
rationale
the
discussions
in
this
working
group,
as
also
in
the
group
working
group.
Prior
to
this,
there
is
a
stop
solution
section
in
the
appendices.
You
can
take
a
look
at
that
in
try
a
solution.
You
could.
There
was
good
discussion
about
that
using
community
on
the
turnout
list
and
we
had
that
historically
in
the
draft,
so
we're
still
keeping
it
this
uses
community
and
the
Nano
discussion
was
was
very
informative,
very
helpful.
So
we
captured
the
essence
of
that
into
into
this
section
here.
E
The
intra
a
SS
leak
prevention
with
community.
So,
just
to
recall
like
what
what
is
the
problem
we
are
addressing
here
is
P
in
this
picture
is
P
1
or
a
s.
1
sends
a
prefix
route
to
the
customer.
The
customer
leaks
it
to
the
other
transit
ISP.
It
has
so
customer
is
multihomed
and
it
leaks
it
to
the
second
transit
is
B,
the
second
transit
ISP.
Does
it
doesn't
didn't
catch?
It
doesn't
catch
that
it's
a
leak
and
it
propagates
it
to
its
peers
and
other
neighbors
providers
customers.
E
E
Before
we
go
to
the
solution,
a
real-world
incident.
There
are
many
which
which
happen
once
every
few
months
or
so
so
in
this
incident,
Google
appears
with
Hathaway
and
shares
a
whole
bunch
of
prefixes
and
Hathaway
leaked
300
over
300
of
them
to
its
transit
provider,
Airtel
held
in
catch
it
and
it
the
the
leak
propagated
to
level
3,
orange
and
so
on
and
as
a
result,
many
Google
users
in
Europe
their
traffic
was
data.
Traffic
was
routed
through
Airtel
and
hathaway,
and
it
got
dropped
on
the
floor.
E
E
So
the
sending
router
uses
a
two
bit
field
and
this
field
can
be
carried
in
a
transitive
per
hop
attribute
in
BGP
or
in
the
flags
field
in
BGP
SEC,
when
we
have
BGP
psyche
of
a
labelled
down
the
road,
the
RLP
field
value
can
be
zero,
zero
default
value,
which
means
that
nothing
specified,
which
in
turn
means
that
the
route
can
be
propagated
to
a
customer,
transient,
trans
transit
provider
or
lateral
peer,
no
restrictions.
0
1
means
that
the
sender
is
saying
that
please,
don't
I
mean
don't
send
it
to
a
transit
provider.
E
E
So
the
solution
just
to
provide
some
more
insight
into
it.
It
works
this
way.
It's
been
a
while
so
I'm
just
doing
a
quick
review
of
this.
Although
you
have
heard
this
before
the
a
s1
is
propagating
prefix
P,
it
puts
in
our
LP
a
s11
which
means
that
mas
1
and
I
put
our
LP
indication
to
one
it
sends
it
since
it
to
a
s2
and
also
to
a
s4,
and
they
propagate
it
to
a
s
3
s.
E
3
is
a
transit
provider
of
a
s
2,
so
s
2
is
leaking
that
the
route
and
a
s
3
now
has
two
choices.
One
of
them
is
clean,
the
our
LP
bit
is
set
to
ones
and
it
is
coming
from
a
transit
provider.
So
s
3
is
receiving
from
a
s.
4
and
both
are
LP.
Fields
are
set
to
1,
which
means
that,
yes,
it
can
continue
to
propagate
towards
customer.
That's
fine,
so
a
we
can
can
accept
that,
but
but
the
other
update
from
es
tu
has
na
also
has
our
LP
set.
E
1
2
set
2
1
from
a
s
1.
So
s
3
knows
that
it's
a
case
coming
from
a
customer
and
somebody,
another
transit
provider
said
that
if
it
comes
from
your
customer
then
be
aware
it
could
be
a
route
leak.
So
s
3
can
distinguish
between
these
two
updates
and
it
can
discard
the
suspicious
one,
which
is
from
from
the
customer
and
accept
the
one
from
the
transit
provider
a
as
for
so
it
can
prioritize
and
eliminate
the
route
leak.
E
The
our
LP
attribute
is
the
r
LP
values
are
put
in
a
optional
transitive
attribute,
so
each
a
s
that
is
participating
can
put
this
tuple
a
s
number
and
the
RL
p
value,
so
so
partial
deployment
in
partial
deployment.
It
works
fine,
so
non-participating
a
SS
will
not
put
anything
in
here
and
it
is
transitive
and
the
way
I
mean
the
effectiveness
of
it.
E
99%
of
the
the
vertical
axis
is
the
route
leaks
that
are
not
detected
in
terms
of
percentage,
and
the
horizontal
axis
is
the
three
power
three
different
scenarios:
current
BGP
BGP,
with
the
proposed
RL
P
and
P,
and
a
BGP
SEC
with
the
proposed
RL
P.
So
basically,
the
99%
that
are
accidental
route
leaks
are
are
prevented
right
away.
If
you,
if
you
do
the
proposed
RL
p
and
the
if
you
if
it
is
secured
with
bgp
SEC,
then
also
the
malicious
attacks
are
prevented.
E
So
this
applies
in
general
to
even
BGP
SEC
the
building
blocks.
So
in
at
the
bottom,
you
start
off
with
out-of-band
communication,
which
tells
you
what
you
appears
about
you.
What
the
relationship
is
with
your
peer,
the
Reyes
number
interface,
I
IP
etcetera,
the
BGP
opened
their
BGP
role,
capability
negotiation.
That
is
done
with
the
help
of
the
other
draft,
the
BGP
open
policy
draft
that
allows
you
to
confirm
the
relationship.
At
that
point,
you
can
automatically
set
the
peering
relationship
or
for
each
peer,
and
you
can
do
it
by
prefix.
E
If
you
wish,
then
on
top
of
that
we
have
the
two
components:
the
intra
is
a
prevention
solution
that
is,
the
IOT,
see
same
draft
again.
Iot
C
is
a
internal
only
to
customer
attribute.
So
that
tells
you
that
I
mean
that
you
need
to
look
at
the
other
draft.
For
that
and
I'm
sure.
Many
of
you
are
familiar
with
that.
The
other
component
of
the
solution
is
the
is
what
I
have
described
the
our
LP
solution,
which
works
across
SAS
boundaries.
E
E
In
this
example,
the
prefix
P
propagates
from
a
s5s
customer
corn,
and
it
goes
across
a
peer-to-peer,
a
s1
and
if
in
s
once
customer
corn
pone
it
leaks
and
it
goes
into
a
s2
s,
customer
phone
or
even
it
might
turn
around
and
come
back
to
s1
on
another
customer
interface
in
either
case
either
a
s1
or
s2
are
able
to
detect
that
it's
a
route
leak
and
they
can
stop
it.
So
in
the
by
doing
that
it
is
not
propagating
from
across
these
ISPs.
So
these
are
participating
ISPs.
E
They
essentially
form
a
ring
of
security,
and
leaks
can
happen
if
their
customers
are
not
yet
upgraded.
Leaks
can
happen
locally
within
the
customer
phone,
but
they
won't
propagate
across
when
one
is
please
customer
corn
into
another,
so
that
is
the
advantage
of
early
adoption.
I
mean
benefit
with
early
adoption
and
it
encourages
deployment.
Thank
you
appreciate
some
questions
or
comments.
F
Alexander's
remove
accurate
ellipse,
first
of
all,
I'm
really
glad
to
see
that
you're
finally
linked
you
draft
to
open
policy,
it's
good
news,
but
there
is
another
draft
so
that
you
haven't
mentioned,
and
in
this
draft
there
is
different
design
of
what
you
called
our
LP
and
while
Hugh
requires
required
that
it
should
be
pairs
of
videos,
there
is
only
one
value
and
comparing
the
properties
of
these
attributes
the
pair's
a
set
of
a
set
of
pairs
that
does
not
bring
anything
then
complexity.
Second,
are
you
talking
about
the
flag?
The
single.
F
Use
yes,
I
was
thinking
about
a
or
TC.
The
second
thing
is
that,
in
your
draft,
the
side
effects
of
this
technology
are
not
mentioned,
and
they
are
important
to
mention.
Sorry,
what's
not,
because
both
geodesy
and
ROP
are
are
given
a
hints
about
joy,
about
relations
between
autonomous
systems
and
for
some
ice
bees.
It
will
make
a
great
a
concern.
F
A
year
ago,
I
invited
you
privately
for
a
discussion
to
merge
these
drafts
and
to
create
one
draft
which
will
be
will
be
some
kind
of
joint
solution,
and
today,
I
will
try
to
do
it
publicly.
So
I
invite
you
one
more
time
to
merge
these
ideas,
to
create
single
draft
and
to
ship
it
quickly,
because
the
problem
is
really
very
important.
Thank
you.
Thank.
E
The
appendices
that
I
mentioned
so
I
would
like
to
request
you
and
everyone
else
who
is
interested
to
take
a
look
at
that.
The
second
question
about
merging
the
truth:
Rudolph's
graphs.
Yes,
we
welcome
that
and
we
are
looking
so
so
the
so
draft
you
mentioned
that
is
relatively
new.
This
has
been
there
for
three
years.
The
draft
you
mentioned
is
relatively
new,
so
we
had
very,
very
much
welcome
to
and
we
have
discussed
it
which
not
that
I
haven't.
F
G
B
E
B
Would
like
to
ask
the
the
respective
authors
to
you
know:
try
to
have
this
discussion
concluded
before
the
next
meeting,
because
can
I
just
see
an
informal
show
of
hands
of
first
of
all,
how
many
people
think
they
understand
this?
Whether
you've
read
the
draft
or
not
I
mean
there's
detailed,
slides
that
you've
just
been
presented.
So
you
know
a
reasonable
number
of
people
think
they
understand
what
what
we're
talking
about?
How
many
people
think
that
this
is
something
that
they
would
consider
either
implementing
in
their
implementation
or
deploying
in
their
network?
B
H
I
Jared
Moss
from
Akamai
I
was
just
asking
a
see
if
he
was
interested
in
also
addressing
the
implementations
that
they
have
that
by
default
flood
all
the
learned
routes
immediately
out
all
the
sessions
as
well,
because
that
would
also
help
mitigate
this
issue,
which
is
a
very
common
configuration
thing,
and
it's
been
challenging
for
me
as
a
customer
of
some
of
my
equipment.
Vendors
in
this.
I
H
B
J
B
Just
a
point
of
order
and
not
point
of
water,
I
guess
chair
is
privileged
whatever
just
yeah,
since
you
were
so
kindly
kindly
mentioned
your
number
of
authors,
please
fix
it.
J
J
J
J
There
are
two
tlvs
which
have
been
defined:
the
capability
dlv
and
the
node
attribute
TLV,
it's
very
mostly
it's
very
basic,
so
I
would
encourage
you
to
just
read
it:
it's
it's
pretty
straightforward
and
I
present
it
the
same
in
the
in
9100
as
well
notes
it
TLV,
we
added
the
n-side
originated
from
the
BT
protocol.
We
added
some
function
flags
which
have
now
been
in
cropped
incorporated
into
the
main
set
TLV
earlier.
J
J
Peer
node
and
exit
is
similar
to
what
is
defined
for
SR
MPLS.
In
that
document
route
segment,
routing
epe.
We
are
defined
in
similar
thing
in
the
S
FRS
or
v6,
the
it
indicates
the
cross
connect
layer
3
for
the
specific
bgp
session
and
the
again
the
function.
Codes
are
defined
in
network
programming
documents.
J
J
You
remind
me
every
time
so
I'll
do
it
next
time,
bgp
extensions
for
SL,
v6
VPN.
We
as
I,
said
the
few
other
they're,
quite
a
few
providers
which
are
interested
again
for
this.
We,
we
recommend
to
read
two
separate
documents:
the
SR
v6
network
programming.
Again,
it's
a
comprehensive
document
which
talks
about
all
the
network.
Programming
ends,
functions
which
we
have
defined
and
the
segment
auditing
header,
which
is
the
basis
for
this
whole
work
and
the
prefix
word
document,
which
AC
was
authoring.
J
What
do
you
want
to
do
again?
We
want
to
enable
the
ipv6
data
plane
segment
routing
and
we
want
to
provide
the
VPN
or
global
services
on
top
of
it.
We,
the
goal
of
this
whole
document,
was
to
provide
the
or
reduce
the
overall
migration
brownfield
migration
deployments.
We
have
presented
the
first
cut
of
this
document,
which
is
l3
VPN
over
SRV
6ni,
ATF,
98,
Chicago.
J
How
are
we
doing
it?
We're
proposing
a
BGP
extension,
we
extending
a
prefix
it
attribute
in
the
base,
prefix
it
document
and
we
calling
it
as
a
v6
TLV,
and
that
has
it
looks
like
this,
so
it
has
a
CID
type
and
a
CID
value
associated
with
the
VPN
services,
which
you
would
want
to
signal
using
bgp
the
VPN
state
encoding
in
this
particular
case,
I'm
specifically
focusing
on
evpn
and
global
in
EVP.
J
In
case
the
type
would
be
to
the
type
one
will
be
corresponding
to
l3
VPN
label,
which
we,
the
mpls
and
the
type
two
will
be
corresponding
to
the
EVP
and
label,
in
other
words,
type
1.
Is
that
end
DX
functions
or
DT
functions,
which
is
equivalent
to
the
l3
services
and
type
2,
will
be
equivalent
to
the
l2
services,
which
is
provided
by
evpn
RFC
again
just
a
reminder:
the
details
are
in
that
network
programming
document.
J
So
how
does
the
encoding
looks
like
this
is
again
basis
of
SR
v6?
So
we
have
a
locator
a
function
and
argument.
The
locator
is:
how
do
you
write
route
to
that
particular
IP
address
the
function
would
be
the
VPN
labels,
or
in
this
particular
case
it
could
be
the
l2
VPN
or
a
VPN
function.
Equivalent
argument
argument
is
optional
in
case
of
ESR
filtering.
We
pass
the
argument
to
arm
so
it's
again
the
detailed
in
the
document
very
well.
This
is
just
an
example.
There
is
no
fixed
boundaries
of
any
of
these.
J
The
base
baseline
procedures,
which
were
defined
in
474
32,
has
not
been
changed.
We
have
just
extended
to
attach
this
attribute
for
the
cases
where
there
is
an
MPLS
label
for
the
evpn.
We
have
attached
and
sr.
We
succeed
to
associate
with
it,
and
we
also
believe
that
it
helps
in
the
migration
for
the
brownfield
deployments,
which
is
most
of
them
out.
There
example
of
the
EVP
and
l3
encoding,
so
the
top
one
shows
the
encoding,
which
is
there
in
the
7432
with
the
label
as
MPLS
l3
VPN
level.
J
We
also
want
to
achieve
a
BGP
free
core,
so
we
are
associating
the
v
p--
information
for
the
global
FES
as
well
and
for
the
L
three
cases,
and
we
just
associate
the
SR
v6
VPN
TLV
to
that
to
achieve
the
BGP
free
code
and
attach
that
to
the
base,
ipv4,
ipv6,
global
and
Lara
and
send
it
with
the
ipv6.
Next
stop.
K
A
Lisa
Jesse
Cisco
few
comments.
First,
this
draft
is
about
BGP,
enable
l2
and
l3
VPN
services
over
SR
v6
and
by
the
way,
last
time
I
checked.
There
was
a
working
group
called
BGP
enabled
services,
so
the
draft
should
be
renamed
and
I
think
it
should
be
presented
there,
because
majority
of
the
interest
is
going
to
be
over
there
to.
K
Second
and
the
giraffe
introduces
a
new
encapsulation
and
that
new
encapsulation
has
a
ramification
on
IP
VPN
and
a
VPN
RFC
for
this
7432
and
4364,
and
the
giraffe
gets
into
how
to
do
their
stuff
without
explaining
what
and
why,
basically
I'm
interested
in
knowing
why
we
need
a
new
encapsulation.
What
are
the
benefit
of
this
new
encapsulation?
K
J
J
K
You
can
do
that
with
sending
the
sending
a
VPN
an
IP
VPN
perfectly
over
SRB
six.
Why
do
we
have
to
mush
the
encapsulation
together
I
mean:
do
we
get
performance
improvement?
Do
we
get
better?
You
know
improvement
in
the
encapsulation.
If
that
these
are
the
case,
we
need
to
have
discussion,
sir.
Okay,
so
then
should
I
continue.
I.
B
Don't
know
should
I
finally
find
time
for
you
in
the
agenda.
How
many
many
points
do
you
have
I
think
tell
you
what
why
don't
you
go
to
the
back
of
the
line?
Let
the
two
people
behind
you
make
their
points,
but
they
may
have
one
one
point
each
and
then
you'll
still
have
some
time
to
make
your
recipe
of
points.
Yes,.
L
J
J
M
Rather
than
nokia,
yes,
I
have
some
few
comments
too,
and
some
of
them
shared
with
Ali,
so
the
first
one
is
absolutely.
This
has
to
be
presented
in
best,
and
we
already
made
a
comment
in
IETF
98
and
you
know
a
few
IDF's
later
here.
We
are
again,
that's
the
first
one.
The
second
one
is
a
question:
do
you
or
do
you
not
mandate?
The
advertisement
of
this
said
TLV
or
a
VPN
city
LV.
J
J
M
Is
for
all
the
routes
all
day
if
you
can
route
except
for
route
type,
4
right
now
in
reading
the
program
in
draft,
it
actually
talks
about
encoding
the
ESI
label
in
the
external
community
in
the
existing
type
1
extended
community,
which
is
by
the
way,
a
great,
a
great
great
idea,
and
this
is
where
I
would
suggest.
However,
this
seems
to
be
inconsistent
with
what
you
have
in
this
draft.
M
Don't
fix
it,
there
is
an
austere,
McCleary
bad
for
all
there
all
the
VPN
labels
tomorrow.
My
my
final
feedback
would
be
and
something
that
I
already
discussed
is.
If
you
make
this
locator
sorry
know
the
locator
the
function
and
the
argument
you
limit
the
length
to
three
bytes
each.
You
don't
really
need
to
have
a
new
TLV.
You
don't
need
to
create
this
new
attribute
and
you
can
actually
make
the
you
know
the
a
VPN
solution
compatible
with
SR
v6.
M
And
I
forgot,
the
last
one
is
in
VPN.
We
use
the
BGP
encapsulation
attribute
or
bgp
encapsulation
extended
community
to
signal
there
from
the
egress
p
the
the
tunnel
that
we
want
to
use
and
also
to
to
let
the
English
P
know
if
we
want
to
use
a
20
or
a
24
bit
VPN
label
identifier.
Now
here
you
are
doing
something
completely
different,
you're
saying
just
by
the
fact
that
I
I
am
including
this
new
TLV
I
I
want
to
signal
to
the
English
P
that
it
needs
to
use
a
service
X.
M
J
M
So
this
is
what
now
we
do
it
today
now
you
you're
saying:
no,
we
don't
need
that
and
we
are
defining
and
yet
another
way
to
signal
the
English
P,
what
label
it
has
to
use.
So
my
question
is:
why
don't
you
just
signal
the
BGP
encapsulation
advocate
or
the
extended
community,
and
you
include
there
there,
the
tunnel
type.
B
G
B
K
A
couple
of
my
comments
read
cover
by
Jorge,
but
he
is
saying
that
okay
I
asked
for
what
and
why
and
then
describe
to
how
and
once
we're
convinced
of
what?
What
and
why
you're
doing
these
things
with
respect
to
the
house,
or
he
is
saying
that
why
not,
you
know,
use
the
existing
field
in
the
route,
because,
if
we
go
with
the
attribute
is
gonna
impact
the
BGP
route
packing.
K
K
It
is
the
same
actually,
then
that's
fine,
but
the
question
is
with
respect
to
the
how
you
know
if
you
decide
to
go
with
this
new
encapsulation
question,
is
why
not
use
the
existing
mechanism
and
convey
the
inform
and
they
see
it
as
part
of
the
existing
EVP
and
rot
again?
This
is
contingent
on
the
ossification.
Why
we
need
the
encapsulation
and
there
are
implication
I'm
going
to
be
quick.
I
have
a
few
more,
but
I'm
gonna
skip
those.
Basically,
there
are
implications
with
the
III,
which
is
not
being
mentioned
in
the
giraffe.
K
K
N
B
O
Kalyra
I
am
a
given
from
China
Telecom
here
I,
what
my
experimental
search
some
solution
for
the
interest
table
chill
in
the
you
know,
our
really
our
network.
The
content
considered
the
four
parts
first
days,
the
scenario
that
we
encountered
in
our
network
and
the
requirement
for
a
solution,
and
we
also
search
for
the
kind
of
solution
compared
to
the
connoisseurs.
And
finally,
it
is
not
very
suitable
for
our
requirement,
so
we
held
proper
or
some
BTW
pls
the
extension
to
meet
this
requirement.
O
O
Kindly
we
are
deploying
department
to
the
STM
on
technology
civilian,
this
architecture,
we,
the
SDN
controller,
should
know
the
overall
topology
during
the
tiffany
domain,
so
we
needed
to
collect
the
topology
from
each
each
Tamiya
and
also
the
inter
domain
logic
as
well.
So
the
right
part.
We
have
some
simplified
scenario.
At
the
you
know,
we
have
two
different
IDP
domain
and
may
or
may
not
want
different
ITB.
The
protocol
and
million
is
the
underlying
network.
There
may
be
deployment.
O
So
of
for
this
another
way,
we
are
six
some
solution
for
the
four
committees
requirement.
The
first
thing
is
we
want
to
pre,
do
the
kind
that
ECB
or
the
protocol
unchangeable
else
possible
and
the
second
value
we
want
to
enhance
the
North
Portico
under
the
young
architecture
so
and
the
30
that
we
want
to
keep
her
department
a
simple
and
probably
called
we.
We
have
the
hundreds
of
the
ITP
domain
and
the
the
lastly
the
solution,
so
the
suitable
for
various
scenarios.
O
So
we
search
and
compare
the
current
solution
for
these
now
and
the
requirement
there
are
about
60
solution.
It
can
fulfil
part
of
our
requirement.
The
first
day
is
already
know
the
debated
protocol,
but
it
many
folks
on
the
ITB
topologically
amount
of
me,
and
there
is
no
interest
Pilate
information,
this.
The
second
is
a
sorry
P.
O
So
in
this
solution
the
SP
archons
he
puts
the
interest,
links
and
note
information,
but
if
we
adopt
this
solution,
the
Avs
spr
mustard
on
the
PTR
protocol,
so
they
must
appear
the
pv
neighbor
with
Rosalie
fret
of
e
the
BGP.
Will
the
SDN
controller
so
I
think
the
there
are
some
deployment
limitation.
O
The
third
is,
there
are
some
reporter
for
avidians
sr
extension,
so
you
know
easily
16
and
after
the
introduce
social
otter,
int
fixer
identified
her.
The
elevate
will
transfer
the
key
information
for
the
interest
apology,
but
the
solution
in
meaningful
isis,
isis
proto.
So
it
is
for
the
underlying
network
master.
O
On
the
I,
as
a
protocol,
the
the
there
are
another
tool
to
our
see
that
ridiculous
scenarios
in
reading
the
ISIS
and
OSPF
or
T
there
are
some
extension
to
transfer
information
about
the
interest,
links
and
nodes
parties
requirement
the
our
underlying
network
to
deploy
and
deprive
that
he
he
technology
within
each
domain-
and
you
know
you
will
be
even
with
deployment
the
T
technology
and
the
citing
recent
are
not
included
in
the
kind
PDA
universe'.
So
I
think
there
is
no
solution
tool
for
to
meet
our
scenario
and
requirement.
O
The
the
last
is
the
facility
IP
network
is
the
table
is
described
as
in
order
for
the
force
in
our
department
CCNA
to
IP,
but
there
is
no
solution
for
the
interest
table
issue,
so
this
is
kinda
loose.
I
think
there
are
some
various
limit,
listen
for
to
with
our
requirement.
So
here
are
our
proposed
solution.
The
first
lead
for
the
90.
She
knows
inland
region
until
99
his
analysis.
It
healed
acquired
the
hour
under
an
underlined
network
at
a
node
deployment,
the
t
technology.
O
Originator
of
the
interest
prefix
I
will
explain
later
for
the
region
to
to
to
tow
the
quality
information.
This
is
here
this
here
low.
We
can
get
the
information
from
a
different
protocol
first
realizes
it
is
DC
in
same
as
the
colonist
autumn
for
the
RFC
7-7
I-94,
and
the
next
row
is
for
Oh
LPB
me
to
our
web,
who
we
mystery
so
million
this
newly
defined.
That
here
way,
we
can
carry
different,
carry
the
similar
information
for
the
different
IT
protocol.
O
The
the
second
proposal
is
the
PPS
extension
and
I
resonated.
Currently,
there
are
untold
2rc
to
describe
of
the
the
theory
that
carry
the
remotely
infamous
and
the
the
motifs
are
as
prit
information
lady
in
the
IT
people
talk
about
the
information
and
in
who
can
even
be
reported
by
the
kind
be
very
spot.
Also
we
want
to
be
in
a
TC
narrowly.
O
The
current
draft
for
nineties
in
our
there
are
some
some
steps
to
reach
children.
Information
from
with
the
from
the
key
key
information
reported
by
the
PGP
has
protocol
here.
I
just
make
the
elicited
graph
and
the
procedure
to
Richard
halal
information.
You
know
what
we
want.
Monkey
de
is
the
red
links
at
the
beginning
in
the
different
different
commands,
so
the
steps
at
all
reconstruction,
the
interest
of
logic,
is
illogical
in
the
writer
graph.
The
first
thing
is:
PCV,
opt
of
logic
is
practically
in
the
different
domains.
O
This
camp
beef
party
interests
link
are
normally
not
included
because
we
will
not
run
the
ITV
protocol
in
the
inverse
links.
So
normally
we
will
really
super
that
the
universe
links
on
every
SBR
rotor.
You
know
at
widget
or
eg
Tamiya,
we
market
it
in
her
interconnection
within
our
underlying
network
and
currently
the
reduced
people
routes.
It
is
the
prefix
of
the
inter
interests.
Links
can
be
included
in
the
eunuch
and
BGP
Li
P
de
Parys
on
air
are,
and
but
the
there
is
no
information
about
the
originator
of
these
projects.
O
So
we
cannot
anchor
the
prefix
we
under
the
different
different
HDR's,
so
it
cannot
endure
all
the
SDN
controller
cannot
build
the
interest
ecology
within
the
current
P
de
Parys
information
so
with
our
newly
defined
BTS
tearaway.
So
the
PCE
can
anchor
the
prefix
to
a
correspond,
the
SPR
and,
at
the
end
the
PC
can
construct
the
interest
Pilate
when
comparing
the
yield
prefix
and
their
anchors.
So
this
is
a
top-load.
Is
the
contraction
process
process
within
that
would
different
scenarios.
O
So
we
also
summary
some
our
solution
benefit
for
our
canoes
and
hound
can
fit
many
submit
easy.
The
general
solution
for
the
interest
topology
each
here
and
it
is
T-
not
depend
on
the
proton
source
of
profit
of
the
prefix
anticipated
by
kinda,
the
pgps
protocols
and
pcs
knock
on
the
hill.
The
in
herd
approach,
interest
apology
automatically
according
to
a
procedure
and
determining
is
the
prettiest
and
the
originally
originally
information
reported
the
buyer,
the
newly
defined
theory,
okay,
a.
H
Solanum
Cisco
Systems
I've
read
the
draft
to
admit
that
so
I
saw
you
that
there
is
redistributed
route
original
Raider.
You
know
in
the
RFC
seventy
seven
fifty
to
prefix
prefixes
have
both
no
descriptors
and
prefix
descriptors.
You
know,
which
is
just
the
prefix
in
length
for
the
prefix
distributor,
maybe
topology
to
I,
can't
recall
why
wouldn't
the
route
originator
just
be
the
the
OSPF
router,
ID
or
ISI
assistant
idea
in
the
node
descriptor
I.
Don't
think
you
need
that
new
identifier,
you
fast.
O
H
The
node
descriptor,
because
why
would
you
put
anybody
other
than
the
node
descriptor
I
mean?
Why
would
you
put
anybody
but
the
originator
in
the
node
descriptor?
Why
wouldn't
you
put
the
originator
in
there?
I
mean
that's
what
it
should
be.
It's
not
gonna,
be
the
BGP
speaker,
you
don't
you
know
it
doesn't
need
to
be
I
mean
I
mean
the
the
BGP
speaker
doesn't
put
his
own
no
descriptors
in
here.
He
just
happens
to
be
the
one
of
the
BGP
LS
session
to
the
controller.
You
know.
O
H
H
Normally,
the
a
and
not
normally
always
for
non
for
regular
areas.
Deus
Ex,
ternal,
LS
A's,
are
flooded
throughout
the
routing
domain,
and
so
the
BGP
speaker
talking
the
controller
to
uniquely
identify
that
prefix.
You
just
take
it
out
of
his
out
links
de
database
and
use
the
he'd
used.
The
he'd
use
the
router
idea
of
the
or
system
ID
other
of
the
router
that
originated,
so
you
don't
need
an
identify
it.
We
should
take
this
offline,
it's
kind
of
we
found
if
it
seemed
to
be
in
a
circular.
P
O
You
know
the
newly
proposed
a
caraway
is
similar
with
kinda
sausage,
so
she
wrote
her
IT
the
other
way.
You
know
buddy
this
I
compared
it
here.
You
know
the
the
you
know:
sort
of
solutions,
a
sorry
XD
food
Yoshida
and
he
elevated
to
Treasuries
key
information,
but
it
is
mainly
for
the
ISIS
protocol
and
they
not
cover
and
other
protocols.
O
So
we
here
we
just
okay
with
the
through
central
account,
can
Cara
also
narrows
the
different
protocols
in
our
eg
domains
and
kindly
and
I
know
that
the
for
BT
better
protocol,
rather
the
wrong
the
BG
proposal
non
originator
of
these
prefix,
but
it
did
not
support
adipati
that
who
the
SDN
controller
so
I
can
conduct
or
not
now
the
orgy
or
origin
originator
of
these
previous.
So
we
cannot
build
the
interest
upload
automatically.
Q
Okay,
so
this
is
Jayden
from
Hawaii
and
then
my
presentation
is
about
new
BGP
extended
community
for
identifying
the
target
node,
so
we
have
causes
from
hobby
and
the
Nokia.
So
here's
a
motivation.
We
know
that
p2p
has
been
used
for
the
distribution
of
various
routing,
our
policy
information
and,
in
most
cases,
such
kind
of
for
disputes
to
the
whole
network.
But
in
some
other
use
cases
the
intended
target
node
may
be
just
the
one
or
several
particular
between
nodes
in
the
network.
Q
For
example,
this
in
the
BGP
flows
back
policy
distribution-
you
can,
you
may
just
want
to
distribute
the
policy
to
a
particular
node,
also
several
particular
nodes
and
currently
BGP
does
not
have
a
mechanism
to
to
do
this,
to
designating
the
talking
node
for
this
routing
information,
because
BGP
was
designed
for
the
point:
multiple
distribution
in
the
beginning,
and
currently
we
have
a
router
target
mechanism,
but
that
was
used
for
the
matching
of
waving
routes
to
the
brf's.
So
it's
not
a
general
mechanism
for
this
purpose.
Q
Here
the
propose
the
solution
when
the
network
he's
using
ipv4
address,
so
we
need
a
new
PGP
extend
community
to
carry
the
tagging
node
IP
address
and-
and
this
is
very
straightforward.
Currently
we
make
it
a
transitive
things.
You
can
use
thinning
community
because
we
need
to
we're
considering
both
entry
as
a
inter
and
interest,
maybe
in
the
future,
and
this
extinct
community
can
be
carried
multiple
commute.
Q
This
extinct
community
came
carried
in
the
update
message
to
designate
designated
Italian,
node
and
diagnose,
and
for
ipv6
we
need
to
define
a
new
ipv6
address,
a
cific,
it's
the
community
to
carry
this
tagging
node
and
it's
also
transitive
and
more
or
more
ipv6.
No
target
communities
can
be
carried
in
the
Abbadon
message.
Q
So
currently,
in
the
current
version
of
the
draft,
we
just
give
the
procedure
for
the
intro
es
scenario.
The
interest
case
will
still
in
further
study,
and
we
can
have
discussion
about
that.
Basically,
for
the
intro
es,
Dario
and
originator,
it
needs
to
encode
the
tagging
nodes,
IP,
v4
or
ipv6
addresses
into
this
newly
defined
in
node.
Huhgak
extend
immunity
and
send
it
to
the
update
on
the
receivers
receiving
site
for
the
non.
Are
our
speakers.
Q
It
just
need
to
check
this
new
extinct
community
and
to
find
whether
it
is
the
the
target
node,
but
this
local
node
is
Italian
or
not,
and
if
it
is
the
target
node,
if
the
routing
information
carried
in
the
update
can
be
used
by
this
node.
Otherwise
it
just
need
to
discard
us
an
update
message
and
on
the
road
reflectors.
It
is
a
in
addition
to
checking
this
and
local
match.
You
also
need
to
redistribute
is
received,
updated
a
further
to
these
clients
and
the
details
are
specified
in
the
draft.
Q
So
after
we
submit
this
draft,
we
have
already
got
some
feedbacks
comments
and
we
would
like
to
discuss
them
here.
The
first
one
is:
do
we
need
to
have
an
ipv6
no
target,
because
in
many
cases
is
a
control,
plane
may
still
be
ipv4
based,
but
maybe
we
need
to
consider
whether
we
should
support
the
pure
ipv6
Network,
which
in
which
case
both
the
data
plane,
the
controller
app
or
ipv6
and
another
one
is.
Maybe
we
need
to
add
some
restriction
to
the
target
IP
addresses.
Q
Q
Maybe
they
said
these
are
some
separate
discussion,
but
when
listing
as
here
for
the
discussion,
another
things,
maybe
if
we
want
to
support
post,
ipv4
and
ipv6
addresses,
we
can
restrict
the
rules
to
only
use
the
host
IP
addresses
on
the
routers.
Ok.
The
next
question
comments
is
whether
it
should
be
transitive
or
intransitive
extinct.
Q
So
here
are
the
next
steps
so
because
this
is
the
just
as
your
version
draft.
The
most
important
thing
is:
we
need
to
identify
whether
this
as
a
valley,
the
problem
to
be
solved
and
we
need
to
cover
both
ipv4
and
ipv6
and
whether
we
need
to
care
about
interests
and
interests.
And
after
this
we
will
fiskerton
the
polish
this
solution
and
together.
Q
K
Q
D
Jeff
has
I
have
a
few
comments,
so
your
slide,
where
you
point
out
previous
suggestions,
router
ID,
does
probably
make
sense
in
a
intra
AAS
scenario
partially,
because
there's
no
guarantee
that
they
give
an
address
on
the
router.
You
say:
use
the
collection
of
all
addresses,
there's
no
guarantee
that
those
might
be
unique,
especially
if
you're
a
VPN
router.
So
in
the
intra
a/s
case
that
works,
it
doesn't
work
for
the
inter
ASX
snow.
So
there's
some
points
of
discussion
there.
D
Your
procedure
suggests
that
you
discard
these
for
route
reflectors,
if
you're,
not
if
not
about
reflector
confederations,
are
also
another
case
where
you
have
to
worry
about
that.
Okay,
and
that
also
complicates
your
procedure
for
inter
AAS.
Yes,
the
biggest
piece
of
feedback
I
would
give.
Is
that
your
use
case?
The
the
obvious
use
case
is
for
things
like
flowspec
for
flowspec?
I
don't
think
this
is
a
good
fit.
The
problem
that
you're,
probably
attempting
to
solve,
is
you're
trying
to
say
address
this
to
a
set
of
routers,
where
your
numerating
them.
D
What
you're
better
off
doing
is
snow
trying
to
numerate
the
set
of
interfaces
that
want
to
receive
a
filter
or
a
set
of
no
routes.
For
that
use
case,
you
might
want
to.
You
know,
consider
the
interface
interface
at
draft.
That's
currently
active
and
see,
if
that's
a
better
fit
for
the
scenario
as
well.
Even
if
it
isn't
perhaps
consider
that
you're
trying
to
address
a
set
of
routers
that
a
group
ID
makes
more
sense
than
addressing
it
to
a
specific
router.
D
Q
L
Stephanie
Costa
from
Orange
sorry
I
haven't
had
it
hatched
yet,
but
I
will
do
I'm,
just
wondering
how
is
it
different
from
what
we
are
currently
doing,
for
example
in
M,
VPN
or
EVP,
and
procedures
where
we
are
sending
some
updates
that
are
targeted
to
a
specific
node?
So,
for
example,
in
the
explicit
tracking
for
the
MVP
and
ease
it
sounds
really
similar?
No,
we
are
just
using
regular
communities
to
do
this.
R
Will
your
folk
Dodge
telecom
JA,
essentially
jumping
on
that?
Your
claim
that
what
you
want
to
do
you
cannot,
you
have
don't
have
a
mechanism
in
the
current
PGP
I
think
is
false.
Like
Stefan
was
pointing
out.
The
thing
is
when
you
actually
use
your
policy
configuration.
Of
course
you
can
implement
all
kinds
of
weird
or
weird
filtering
and
so
on
and
with
the
expanded
code
space
that
we
have
available
in
the
regular
pot
in
the
irregular
community
attributes,
you
can
do
even
more
interesting
things.
R
B
P
Okay,
hi
get
ontological
to
present
the
strap
bTW
pls.
So
what
does
this
draft
propose?
We
have
bt
pls
in
RFC
77
52
for
northbound
distribution
of
topology
information
T
part,
but
the
focus
has
been
mainly
on
iGPS
how
to
do
this
from
a
GP
networks
for
the
segment
routing,
egress
PR
engineering
use
case.
We
first
introduced
the
protocol
BGP
so
that
link
state
information
for
three
from
BGP
could
be
advertised
out.
P
P
There
are
MSD
C's
which
run
BGP
as
the
only
protocol
today
and
RFC
79
38.
You
know,
I've
talked
about
this
in
these
networks.
Controllers
do
not
have
a
view
of
the
underlying
link
topology
in
the
network.
The
traffic
engineering
information-
that's
not
available.
You
know
similar
thing
is
there
today
with
a
GPS?
P
Why
do
we
need
this
information?
Well,
this
can
be
used
in
the
BGP
only
network
for
doing
traffic
engineering.
There
are
use
cases
defined
for
in
segment
segment,
routing
that
you
can
do
SRT
in
IMS
DC,
this
informational
traffic,
which
talks
about
that.
So
this
draft
also
uses
or
talks
about
a
use
case
where
segment
routing
T
paths
are
set
up
in
these
bgp
only
networks
using
the
topology
information
that
is
advertised.
P
P
The
draft
specifies
what
are
the
BGP
descriptors
to
be
used
for
each
of
these
different
NLRA
types
and
also
talks
about
different
existing
bt
pls
attributes,
which
are
already
defined
in
several
other
bgp
LS
crafts,
how
they
are
to
be
advertised
the
procedures?
All
of
that
at
this
point
in
this
0
0
version,
there
are
no
new
TL
v,
snooty
alvey's
or
additions
described,
but
they
may
come
in
a
future
versions.
P
So,
what's
the
use
case
or
how
is
this
seen
to
be
used?
So
this
is
a
really
talking
about
bgp
srt
in
a
bgp
only
network,
the
red
lines
really
are
the
links
and
show
the
paths
which
is
available
using
the
base.
You
know
BGP
decision
process.
So
let's
say
in
this
case
we
have
ipv4
labeled
unicast
with
BGP
prefix
seed,
and
this
provides
really
the
you
know
the
normal
digital
path
through
the
network.
P
But
in
the
use
case,
where
we
want
to
engineer
specific
flow
via
a
certain
path
through
the
network,
then
that
can
be
done
by
a
controller.
The
controller
now
has
the
view
of
the
entire
topology
all
the
links,
all
the
prefix
sets
for
the
nodes.
You
know
all
the
T
information
it
just
sets
up
SRT
policy
on
the
node
I
here
and
says
the
prefix
set,
which
is
go
to
let's
say
a
and
then
K,
and
then
you
know
out
forward.
P
P
What
is
not
change
and
the
pace?
Bgp
underlay
is
not
changed
here,
so
we
still
use.
You
know
whether
you
have
ipv4
or
ipv6
or
Lu,
with
SR
or
without
SR.
This
follows
the
you
know:
BGP
decision
process.
That's
the
best
thing
thing
not
to
use
existing
bgp
peering
models
are
continued
to
be
used.
The
draft
in
this
version
focuses
on
the
ebgp
single
hop
mechanism,
which
is
in
RFC,
79
38,
but
future
versions.
P
We
could
have
other
peering
models
included
based
on
the
you
know,
working
group
feedback,
the
BGP
LS
sessions,
are
formed
to
a
controller
using
the
reach
ability
that
is
provided
by
the
under
layer,
routing
right
and
as
I
mentioned
in
the
tea
use
case.
This
is
used
for
setting
up
the
SR
policies
here,
just
quickly
a
couple
of
slides.
So
this
is
really
the
topology
collection.
The
the
bottom
most
is
the
BGP
routers
and
how
they,
you
know,
work,
that's
unaffected.
No
change
is
there.
What's
new?
P
Is
the
BGP
LS
sessions
that
are
set
up
from
these
router
either
to
let's
say
a
BGP
speaker
like
a
centralized
speaker
which
is
consolidating
the
feed
from
the
routers
and
giving
it
to
a
controller
or
it
could
go
directly
to
a
controller?
So
that's
the
new
this
thing
the
underlay
is
as
mentioned.
It
is
unchanged
it
is
the
base.
P
Bgp
final
slide,
quick,
look
at
what
is
the
topology
information
and
the
details
are
in
the
draft,
but
we
have
information
about
a
node
which
includes
you
know
the
node
name,
sRGB
of
the
node
MSD
of
the
node
and
similarly
for
the
link
level.
We
have
the
basic
stuff,
which
is
the
like:
the
PPE
seeds
or
the
peering
suits
then
link
MSDS,
but
also,
we
can
add
the
T
attributes
for
the
links
you
know
these
can
be
run
even
in
a
data
center.
P
N
I
have
a
quick
question,
but
before
that
a
disclaimer
I
have
not
read
this
draft
as
I
understand
from
what
you
just
said,
there
are
no
new
TL
which
defined,
but
it
is
used
for
a
fabric
definition.
Is
this
just
a
informational
document,
or
is
this
doing
anything
specifically?
That
requires
an
interoperability
or
a
standardization
yeah.
P
N
P
As
far
as
attributes
is
concerned,
yes,
you
could
send
whatever
what's
more
important
is
that
the
links
and
nodes
are
described
with
the
right
descriptors
so
that
you
know
you
can
have
the
two-way
check
or
the
connection.
But
that
happens
regardless
right.
If
they
are
not,
if
they
are
done
differently
by
different
implementation,
then
you
would
not
be
able
to
correlate
I'm.